Re: [TLS] TLS ECDSA nonce reuse attack?

[Pascal Urien]

More biased nonce attacks for ECDSA
But in my mind the worst threat is Kleptogram for ECDSA (malicious random
number generator, such as Dual EC DBRG ?)

 biased nonce attack for ECDSA
=
] J. Breitner and N. Heninger, "Biased nonce sense: Lattice attacks against
weak ECDSA signatures in cryptocurrencies", in Proceedings of Financial
Cryptography and Data Security, September 2019, pp 3–20,
doi.org/10.1007/978-3-030-32101-7_1
https://eprint.iacr.org/2019/023.pdf


Kleptogram for ECDSA
==
Stephan Verbücheln,"How Perfect Offline Wallets Can Still Leak Bitcoin
Private Keys", January 2, 2015
https://arxiv.org/pdf/1501.00447.pdf

Pascal

Le mar. 16 août 2022 à 02:00, Robert Moskowitz  a
écrit :

> I contact pointed me to the following:
>
>
> https://medium.com/asecuritysite-when-bob-met-alice/the-state-of-tls-ecdsa-nonce-reuse-1489ab86e488
>
> The article is unclear if this is a TLS 1.2 and/or 1.3 problem.  It does
> claim that 1.3 does not fix all problems with TLS.
>
> It also seems this is a libraries implementation problem.  Lack of care
> in nonce selection.
>
> So I do need to get back to the person that is wanting to know, and I
> have come up empty in any other information on this problem.
>
> Thanks!
>
> Bob
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] tls@ietf114: Agenda Topics

[Pascal Urien]

Dear chair

I would like to request a slot for presentigs these two drafts that were
introduced at IETF 112 Hot RFC
https://datatracker.ietf.org/doc/draft-urien-tls-im/06/
https://datatracker.ietf.org/doc/draft-urien-tls-se/04/
These drafts have open implementations available at github

Best Regards
Pascal

Le mar. 5 juil. 2022 à 23:29, Sean Turner  a écrit :

> The TLS WG will meet at IETF 114. A 2 hour slot that has been scheduled
> for Monday, 25 July 2022, 1900-2100 UTC [0]. The chairs would like to
> solicit input from the WG for agenda topics. Please send your agenda topics
> request and an estimate for how much time you will need to
> tls-cha...@ietf.org. Please note that we will prioritize existing WG
> items. Please also review the guidance for TLS WG presenters that can be
> found at [1].
>
> Cheers,
> Chris, Joe, and Sean
>
> [0] https://datatracker.ietf.org/meeting/agenda
> [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] internet of secure elements

[Pascal Urien]

Hi All

The project "internet of secure element" (iose) aims at providing to
internet users storage and computing resources, with high security and
trust levels.
See https://datatracker.ietf.org/doc/draft-urien-coinrg-iose/02/
I am looking for interested people to create this open infrastructure.

Secure elements currently have an Evaluation Assurance Level of EAL6 (for a
max value of EAL7), their memory size is about 100KB, and they compute most
cryptographics  algorithms in less than 100ms. Furthermore they are able to
process TLS1.3 protocol in about 1000ms

The idea is to deploy secure elements embedding TLS1.3 servers, TLS-SE,
see https://datatracker.ietf.org/doc/draft-urien-tls-se/02/ )
whose access is protected by pre shared keys. TLS-SE servers are identified
by server name (SN)
In the service plane trusted resources are used thanks to dedicated URIs
The administration plane, which performs application downloading in secure
element, could be based on the RACS protocol
See https://datatracker.ietf.org/doc/html/draft-urien-core-racs-14
Open code for TLS-SE secure elements
https://github.com/purien/TLS-SE
Open Code for TLS-SE servers
https://github.com/purien/keystore
Open code for RACS server
https://github.com/purien/racs_0_1

Pascal Urien
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IET110: Agenda Topics

[Pascal Urien]

Dear Chair

I would like to shortly presents these two drafts

https://www.ietf.org/archive/id/draft-urien-tls-se-01.txt
https://www.ietf.org/archive/id/draft-urien-tls-im-04.txt

Best Regards
Pascal Urien

Le mar. 5 janv. 2021 à 03:55, Sean Turner  a écrit :

> The TLS WG will meet at IETF 110. The chairs have requested a 2 hour slot
> [0] and would like to solicit input from the WG for agenda topics. Please
> send your agenda topics request and an estimate for how much time you will
> need to tls-cha...@ietf.org. Please note that we will prioritize existing
> WG items. Please also review the Guidance for TLS WG presenters that can be
> found at [1].
>
> Cheers,
> Chris, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/4kpjPDr-5fW2miu-3QmEs8LlQKw/
> [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Pascal Urien]

Hi Hannes

The TLS-SE code is now published
 https://github.com/purien/TLS-SE

It also comprises software tools for testing

This code is a TLS1.3 ECDH-PSK server for a javacard as specified in
https://tools.ietf.org/html/draft-urien-tls-se-01

It has been tested with several javacard 3.04

This code also implements https://tools.ietf.org/html/draft-urien-tls-im-03

Pascal


Le lun. 21 sept. 2020 à 17:05, Hannes Tschofenig 
a écrit :

>
>
> Ping me when it becomes available or post a link to the UTA mailing list.
>
>
>
> *From:* Pascal Urien 
> *Sent:* Monday, September 21, 2020 4:18 PM
> *To:* Hannes Tschofenig 
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>
>
>
> Not at this moment but the code will be pusblished on github
>
>
>
> Le lun. 21 sept. 2020 à 15:30, Hannes Tschofenig <
> hannes.tschofe...@arm.com> a écrit :
>
> Thanks for the details.
>
>
>
> Is the code for the tls13 server on the javacard open source?
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> *From:* Pascal Urien 
> *Sent:* Monday, September 21, 2020 2:54 PM
> *To:* Hannes Tschofenig 
> *Cc:* Filippo Valsorda ; tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>
>
>
> tls-se memory footprint is
>
> flash 《 40KB
>
> ram   《 1KB
>
>
>
> time to open a tls session 1.4 seconds
>
>
>
>
>
> Le lun. 21 sept. 2020 à 14:47, Pascal Urien  a
> écrit :
>
> hi Hannes
>
>
>
> no openssl or wolfssl are used as client in order to check
> interoperability with tls-se server
>
>
>
> tls-se is of course a specific implémentation for tls13 server in
> javacard..it is written in java but an ôter implémentation is written in c
> for constraint notes. as written in the draft tls-se implementation has
> three software blocks: crypto lib, tls state machine, and tls lib
>
>
>
>
>
>
>
> Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig <
> hannes.tschofe...@arm.com> a écrit :
>
> Hi Pascal,
>
>
>
> are you saying that the stack on the secure element uses WolfSSL or
> OpenSSL? I am sure that WolfSSL works well but for code size reasons I
> doubt OpenSSL is possible. Can you confirm?
>
>
>
> In case of WolfSSL, you have multiple options for credentials, including
> plain PSK, PSK-ECDHE, raw public keys, and certificates as I noted in my
> mail to the UTA list:
>
> https://mailarchive.ietf.org/arch/msg/uta/RJ4wU77D6f7qslfwrc16jkrPTew/
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* Pascal Urien 
> *Sent:* Monday, September 21, 2020 2:01 PM
> *To:* Hannes Tschofenig 
> *Cc:* Filippo Valsorda ; tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>
>
>
> Hi Hannes
>
>
>
> Yes it has been tested with several  3.04 Javacards  commercially available
>
>
>
> In the draft https://tools.ietf.org/html/draft-urien-tls-se-00   Section
> 5-ISO 7816 Use Case, the exchanges are done with the existing implementation
>
>
>
> TLS-SE TLS1.3 PSK+ECDH server works with ESP8266 or Arduino+Ethernet
> boards
>
>
>
> For client software we use OPENSSL or WolfSSL
>
>
>
> Pascal
>
>
>
>
>
>
>
>
>
> Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig <
> hannes.tschofe...@arm.com> a écrit :
>
> Hi Pascal,
>
> Thanks for the pointer to the draft.
>
> Since I am surveying implementations for the update of RFC 7925 (see
> https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) I was
> wondering whether there is an implementation of this approach.
>
> Ciao
> Hannes
>
>
> From: Pascal Urien 
> Sent: Monday, September 21, 2020 11:44 AM
> To: Hannes Tschofenig 
> Cc: Filippo Valsorda ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>
> Hi All
>
> Here is an example of PSK+ECDHE for IoT
>
> https://tools.ietf.org/html/draft-urien-tls-se-00  uses TLS1.3 server
> PSK+ECDHE for secure elements
>
> The security level in these devices is as high as EAL5+
>
> The computing time is about 1.4s for a PSK+ECDHE session (AES-128-CCM, +
> secp256r1)
>
> The real critical resource is the required RAM size, less than 1KB in our
> experiments
>
> The secure element  only needs a classical TCP/IP interface (i.e. sockets
> like)
>
> Trusted PSK should avoid selfie attacks
>
> Pascal
>
>
>
> Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig  hannes.tschofe...@arm.com> a écrit :
> Hi Filippo,
>
> • Indeed, if the SCADA industry has a particular need, they should profile
> TLS for use in that industry, and not require we change the rec

Re: [TLS] The future of external PSK in TLS 1.3

[Pascal Urien]

Hi all

Payment terminal use TLS (see for example
https://www.pcisecuritystandards.org/documents/Use-of-SSL-Early-TLS-for-POS-POI-Connections.docx
)

They are not WEB browser...may be IoT devices ? because they are connected



Le jeu. 24 sept. 2020 à 16:12, Filippo Valsorda  a
écrit :

> 2020-09-24 12:02 GMT+02:00 Peter Gutmann :
>
> Taking "SCADA/IoT/etc" to be a placeholder for M2M or more
> generally "non-web use", [...]
>
>
> "The web" and "resource-constrained use cases which can't afford ECDH"
> feels like a false dichotomy, and it sounds unlikely that most M2M cases
> would fit the latter description.
>
> Anyway, David has made a better case than I did for marking psk_ke as N,
> like TLS_PSK_WITH_AES_128_GCM_SHA256 already is, so I don't want to
> distract from that thread.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Pascal Urien]

Hi Achim

Your local network "light bulb" is likely not a big issue

But what about heath devices, autonomous cars, nuclear plants, blockchain
transfers ?. Maybe, they are not in the IoT scope...

Best Regards

Pascal


Le lun. 21 sept. 2020 à 19:57, Achim Kraus  a écrit :

> Hi Pascal,
>
> that using these ISO 7816 card is fast and save, doesn't say too much
> about the use-case without that card, or? For sure, there are
> micro-controller, which are also equipped with hw-ecc or hw-rsa. And
> there are more secure-devices protecting credentials. But there are also
> still ones without.
> I'm not sure, if I want spend too much money in my local network "light
> bulb". Isn't it always a question of what to protect in which environment?
>
> best regards
> Achim
>
> Am 21.09.20 um 14:53 schrieb Pascal Urien:
> > tls-se memory footprint is
> > flash 《 40KB
> > ram   《 1KB
> >
> > time to open a tls session 1.4 seconds
> >
> >
> > Le lun. 21 sept. 2020 à 14:47, Pascal Urien  > <mailto:pascal.ur...@gmail.com>> a écrit :
> >
> > hi Hannes
> >
> > no openssl or wolfssl are used as client in order to check
> > interoperability with tls-se server
> >
> > tls-se is of course a specific implémentation for tls13 server in
> > javacard..it is written in java but an ôter implémentation is
> > written in c for constraint notes. as written in the draft tls-se
> > implementation has three software blocks: crypto lib, tls state
> > machine, and tls lib
> >
> >
> >
> > Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig
> > mailto:hannes.tschofe...@arm.com>> a
> écrit :
> >
> > Hi Pascal, 
> >
> > __ __
> >
> > are you saying that the stack on the secure element uses WolfSSL
> > or OpenSSL? I am sure that WolfSSL works well but for code size
> > reasons I doubt OpenSSL is possible. Can you confirm? 
> >
> > __ __
> >
> > In case of WolfSSL, you have multiple options for credentials,
> > including plain PSK, PSK-ECDHE, raw public keys, and
> > certificates as I noted in my mail to the UTA list: 
> >
> >
> https://mailarchive.ietf.org/arch/msg/uta/RJ4wU77D6f7qslfwrc16jkrPTew/
> >
> > __ __
> >
> > Ciao
> >
> > Hannes
> >
> > __ __
> >
> > *From:* Pascal Urien  > <mailto:pascal.ur...@gmail.com>>
> > *Sent:* Monday, September 21, 2020 2:01 PM
> > *To:* Hannes Tschofenig  > <mailto:hannes.tschofe...@arm.com>>
> > *Cc:* Filippo Valsorda  > <mailto:fili...@ml.filippo.io>>; tls@ietf.org  tls@ietf.org>
> > *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
> >
> > __ __
> >
> > Hi Hannes
> >
> > __ __
> >
> > Yes it has been tested with several  3.04 Javacards
> > commercially available
> >
> > __ __
> >
> > In the draft https://tools.ietf.org/html/draft-urien-tls-se-00
> >   Section 5-ISO 7816 Use Case, the exchanges are done with the
> > existing implementation
> >
> > __ __
> >
> > TLS-SE TLS1.3 PSK+ECDH server works with ESP8266 or
> > Arduino+Ethernet boards 
> >
> > __ __
> >
> > For client software we use OPENSSL or WolfSSL
> >
> > __ __
> >
> > Pascal
> >
> > __ __
> >
> >     __ __
> >
> > __ __
> >
> > __ __
> >
> > Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig
> > mailto:hannes.tschofe...@arm.com>> a
> > écrit :
> >
> > Hi Pascal,
> >
> > Thanks for the pointer to the draft.
> >
> > Since I am surveying implementations for the update of RFC
> > 7925 (see
> >
> https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/)
> > I was wondering whether there is an implementation of this
> > approach.
> >
> > Ciao
> > Hannes
> >
> >
> > From: Pascal Urien  > <mailto:pascal.ur...@gmail.com>>
> > Sent: Monday, September 21, 2020 11:44 AM
> >  

Re: [TLS] The future of external PSK in TLS 1.3

[Pascal Urien]

tls-se memory footprint is
flash 《 40KB
ram   《 1KB

time to open a tls session 1.4 seconds


Le lun. 21 sept. 2020 à 14:47, Pascal Urien  a
écrit :

> hi Hannes
>
> no openssl or wolfssl are used as client in order to check
> interoperability with tls-se server
>
> tls-se is of course a specific implémentation for tls13 server in
> javacard..it is written in java but an ôter implémentation is written in c
> for constraint notes. as written in the draft tls-se implementation has
> three software blocks: crypto lib, tls state machine, and tls lib
>
>
>
> Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig <
> hannes.tschofe...@arm.com> a écrit :
>
>> Hi Pascal,
>>
>>
>>
>> are you saying that the stack on the secure element uses WolfSSL or
>> OpenSSL? I am sure that WolfSSL works well but for code size reasons I
>> doubt OpenSSL is possible. Can you confirm?
>>
>>
>>
>> In case of WolfSSL, you have multiple options for credentials, including
>> plain PSK, PSK-ECDHE, raw public keys, and certificates as I noted in my
>> mail to the UTA list:
>>
>> https://mailarchive.ietf.org/arch/msg/uta/RJ4wU77D6f7qslfwrc16jkrPTew/
>>
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>>
>> *From:* Pascal Urien 
>> *Sent:* Monday, September 21, 2020 2:01 PM
>> *To:* Hannes Tschofenig 
>> *Cc:* Filippo Valsorda ; tls@ietf.org
>> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>>
>>
>>
>> Hi Hannes
>>
>>
>>
>> Yes it has been tested with several  3.04 Javacards  commercially
>> available
>>
>>
>>
>> In the draft https://tools.ietf.org/html/draft-urien-tls-se-00   Section
>> 5-ISO 7816 Use Case, the exchanges are done with the existing implementation
>>
>>
>>
>> TLS-SE TLS1.3 PSK+ECDH server works with ESP8266 or Arduino+Ethernet
>> boards
>>
>>
>>
>> For client software we use OPENSSL or WolfSSL
>>
>>
>>
>> Pascal
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig <
>> hannes.tschofe...@arm.com> a écrit :
>>
>> Hi Pascal,
>>
>> Thanks for the pointer to the draft.
>>
>> Since I am surveying implementations for the update of RFC 7925 (see
>> https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) I
>> was wondering whether there is an implementation of this approach.
>>
>> Ciao
>> Hannes
>>
>>
>> From: Pascal Urien 
>> Sent: Monday, September 21, 2020 11:44 AM
>> To: Hannes Tschofenig 
>> Cc: Filippo Valsorda ; tls@ietf.org
>> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>>
>> Hi All
>>
>> Here is an example of PSK+ECDHE for IoT
>>
>> https://tools.ietf.org/html/draft-urien-tls-se-00  uses TLS1.3 server
>> PSK+ECDHE for secure elements
>>
>> The security level in these devices is as high as EAL5+
>>
>> The computing time is about 1.4s for a PSK+ECDHE session (AES-128-CCM, +
>> secp256r1)
>>
>> The real critical resource is the required RAM size, less than 1KB in our
>> experiments
>>
>> The secure element  only needs a classical TCP/IP interface (i.e. sockets
>> like)
>>
>> Trusted PSK should avoid selfie attacks
>>
>> Pascal
>>
>>
>>
>> Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig > hannes.tschofe...@arm.com> a écrit :
>> Hi Filippo,
>>
>> • Indeed, if the SCADA industry has a particular need, they should
>> profile TLS for use in that industry, and not require we change the
>> recommendation for the open Internet.
>>
>> We have an IoT profile for TLS and it talks about the use of PSK, see
>> https://tools.ietf.org/html/rfc7925
>>
>> On the “open Internet” (probably referring to the Web usage) you are not
>> going to use PSKs in TLS. There is a separate RFC that provides
>> recommendations for that environmnent, see RFC 752. That RFC is currently
>> being revised, see
>> https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/
>>
>> Ciao
>> Hannes
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>> __

Re: [TLS] The future of external PSK in TLS 1.3

[Pascal Urien]

hi Hannes

no openssl or wolfssl are used as client in order to check interoperability
with tls-se server

tls-se is of course a specific implémentation for tls13 server in
javacard..it is written in java but an ôter implémentation is written in c
for constraint notes. as written in the draft tls-se implementation has
three software blocks: crypto lib, tls state machine, and tls lib



Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig 
a écrit :

> Hi Pascal,
>
>
>
> are you saying that the stack on the secure element uses WolfSSL or
> OpenSSL? I am sure that WolfSSL works well but for code size reasons I
> doubt OpenSSL is possible. Can you confirm?
>
>
>
> In case of WolfSSL, you have multiple options for credentials, including
> plain PSK, PSK-ECDHE, raw public keys, and certificates as I noted in my
> mail to the UTA list:
>
> https://mailarchive.ietf.org/arch/msg/uta/RJ4wU77D6f7qslfwrc16jkrPTew/
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* Pascal Urien 
> *Sent:* Monday, September 21, 2020 2:01 PM
> *To:* Hannes Tschofenig 
> *Cc:* Filippo Valsorda ; tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>
>
>
> Hi Hannes
>
>
>
> Yes it has been tested with several  3.04 Javacards  commercially available
>
>
>
> In the draft https://tools.ietf.org/html/draft-urien-tls-se-00   Section
> 5-ISO 7816 Use Case, the exchanges are done with the existing implementation
>
>
>
> TLS-SE TLS1.3 PSK+ECDH server works with ESP8266 or Arduino+Ethernet
> boards
>
>
>
> For client software we use OPENSSL or WolfSSL
>
>
>
> Pascal
>
>
>
>
>
>
>
>
>
> Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig <
> hannes.tschofe...@arm.com> a écrit :
>
> Hi Pascal,
>
> Thanks for the pointer to the draft.
>
> Since I am surveying implementations for the update of RFC 7925 (see
> https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) I was
> wondering whether there is an implementation of this approach.
>
> Ciao
> Hannes
>
>
> From: Pascal Urien 
> Sent: Monday, September 21, 2020 11:44 AM
> To: Hannes Tschofenig 
> Cc: Filippo Valsorda ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>
> Hi All
>
> Here is an example of PSK+ECDHE for IoT
>
> https://tools.ietf.org/html/draft-urien-tls-se-00  uses TLS1.3 server
> PSK+ECDHE for secure elements
>
> The security level in these devices is as high as EAL5+
>
> The computing time is about 1.4s for a PSK+ECDHE session (AES-128-CCM, +
> secp256r1)
>
> The real critical resource is the required RAM size, less than 1KB in our
> experiments
>
> The secure element  only needs a classical TCP/IP interface (i.e. sockets
> like)
>
> Trusted PSK should avoid selfie attacks
>
> Pascal
>
>
>
> Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig  hannes.tschofe...@arm.com> a écrit :
> Hi Filippo,
>
> • Indeed, if the SCADA industry has a particular need, they should profile
> TLS for use in that industry, and not require we change the recommendation
> for the open Internet.
>
> We have an IoT profile for TLS and it talks about the use of PSK, see
> https://tools.ietf.org/html/rfc7925
>
> On the “open Internet” (probably referring to the Web usage) you are not
> going to use PSKs in TLS. There is a separate RFC that provides
> recommendations for that environmnent, see RFC 752. That RFC is currently
> being revised, see
> https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> TLS mailing list
> mailto:TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Pascal Urien]

Hi Hannes

Yes it has been tested with several  3.04 Javacards  commercially available

In the draft https://tools.ietf.org/html/draft-urien-tls-se-00   Section
5-ISO 7816 Use Case, the exchanges are done with the existing implementation

TLS-SE TLS1.3 PSK+ECDH server works with ESP8266 or Arduino+Ethernet boards

For client software we use OPENSSL or WolfSSL

Pascal




Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig 
a écrit :

> Hi Pascal,
>
> Thanks for the pointer to the draft.
>
> Since I am surveying implementations for the update of RFC 7925 (see
> https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) I was
> wondering whether there is an implementation of this approach.
>
> Ciao
> Hannes
>
>
> From: Pascal Urien 
> Sent: Monday, September 21, 2020 11:44 AM
> To: Hannes Tschofenig 
> Cc: Filippo Valsorda ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>
> Hi All
>
> Here is an example of PSK+ECDHE for IoT
>
> https://tools.ietf.org/html/draft-urien-tls-se-00  uses TLS1.3 server
> PSK+ECDHE for secure elements
>
> The security level in these devices is as high as EAL5+
>
> The computing time is about 1.4s for a PSK+ECDHE session (AES-128-CCM, +
> secp256r1)
>
> The real critical resource is the required RAM size, less than 1KB in our
> experiments
>
> The secure element  only needs a classical TCP/IP interface (i.e. sockets
> like)
>
> Trusted PSK should avoid selfie attacks
>
> Pascal
>
>
>
> Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig  hannes.tschofe...@arm.com> a écrit :
> Hi Filippo,
>
> • Indeed, if the SCADA industry has a particular need, they should profile
> TLS for use in that industry, and not require we change the recommendation
> for the open Internet.
>
> We have an IoT profile for TLS and it talks about the use of PSK, see
> https://tools.ietf.org/html/rfc7925
>
> On the “open Internet” (probably referring to the Web usage) you are not
> going to use PSKs in TLS. There is a separate RFC that provides
> recommendations for that environmnent, see RFC 752. That RFC is currently
> being revised, see
> https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> TLS mailing list
> mailto:TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Pascal Urien]

Hi All

Here is an example of PSK+ECDHE for IoT

https://tools.ietf.org/html/draft-urien-tls-se-00  uses TLS1.3 server
PSK+ECDHE for secure elements

The security level in these devices is as high as EAL5+

The computing time is about 1.4s for a PSK+ECDHE session (AES-128-CCM, +
secp256r1)

The real critical resource is the required RAM size, less than 1KB in our
experiments

The secure element  only needs a classical TCP/IP interface (i.e. sockets
like)

Trusted PSK should avoid selfie attacks

Pascal



Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig 
a écrit :

> Hi Filippo,
>
>
>
>- Indeed, if the SCADA industry has a particular need, they should
>profile TLS for use in that industry, and not require we change the
>recommendation for the open Internet.
>
>
>
> We have an IoT profile for TLS and it talks about the use of PSK, see
> https://tools.ietf.org/html/rfc7925
>
>
>
> On the “open Internet” (probably referring to the Web usage) you are not
> going to use PSKs in TLS. There is a separate RFC that provides
> recommendations for that environmnent, see RFC 752. That RFC is currently
> being revised, see draft-sheffer-uta-rfc7525bis-00
> 
>
>
>
> Ciao
>
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] draft-urien-tls-im-02.txt & test

[Pascal Urien]

Dear All
I tested the identity module for tls1.3, whose features and code for
javacard 3.04, are described in draft-urien-tls-im-02, with the WolfSSL
TLS13 stack.
As many stacks, pre-shared key is available thanks to a callback that
returns the psk value in clear form. I believe this is a bad practice from
a security point of view.
The main idea of draft-urien-tls-im-02 is to avoid psk exposure. In order
to prevent hijacking, psk is only used thanks to dedicated HDSK procedures,
based on psk value.
>From a sofware point of view the identiy module requires a dedicated
callback at several points in the TLS13 stack. Given this pre-requisite the
draft-urien-tls-im-02 works and protects the preshared key.
In the WolfSSL TLS13 stack there is a callback to compute asymmetric
signature when certificates are used.  The identity module can perform this
operation (as described in draft and code) and so avoid the private key
hijacking.
This seems to be the common TLS13 mistake: private key is protected from
eavesdropping but not psk.
It should be great to test identity module at next IETF hackatons…it is
easy to make an identity module with a commercial javacard..i can provided
UART interface devices for embedded platform

Rgs
Pascal
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DH security issue in TLS

[Pascal Urien]

Hi All

I found in NIST Special Publication 800-56A Revision 3
5.6.2.3.1 FFC Full Public-Key Validation Routine
2. Verify  that  1 = y q mod p.

This test is implemented in OPENSSL

This test relies on the fact  that q and p are prime

Pascal



Le mer. 4 déc. 2019 à 18:16, Antoine Delignat-Lavaud <
anto...@delignat-lavaud.fr> a écrit :

> Hi Pascal,
>
> TLS 1.2 does not mandate servers to use safe DH primes. As a client, you
> get g and p from the server. You don't know if p is a safe prime, or
> indeed if it is a prime at all. You don't even know if g is a generator
> of Zp* - it could also be a generator for a small order subgroup. In
> that sense, RFC 7919 is correct in that, in general TLS 1.2, clients
> could pick any private exponent between 2 and p-2 when you have no
> information on p and g. When using an arbitrary server-selected prime
> and generator there is no guarantee that the server selected a share
> that is not in a small subgroup, and similarly there is no guarantee for
> the server that the client share is not of small order. In fact you
> don't even have this guarantee either with ECDH (where the curves are
> chosen from a fixed list) because some curves also have small subgroups.
>
> If you want the guarantee that your DH key exchange is contributive,
> that is, that neither single party can determine with high-probability
> the DH secret produced by the key exchange, you can either 1. use one of
> the safe groups defined in RFC7919. When using these groups, you should
> pick an exponent between 2 and q-1. 2. Figure out all of the low-order
> elements of Zp* and check that the DH secret is not one of them.
>
> Most implementations will do (2), i.e. they check that g^xy is not 0, 1,
> p-1. This is sufficient if p is a safe prime, but it is too expensive to
> check that p and p-1/2 are prime. For X25519 most implementations now
> check that x(yG) <> I, as it is much simpler than checking xG and yG for
> the 8 small order elements. You may be interested in checking Section
> III.B of [1]
>
> Best,
>
> Antoine
>
> [1] http://antoine.delignat-lavaud.fr/doc/ndss15.pdf
>
> On 2019-12-04 16:23, Pascal Urien wrote:
> > Hi all
> >
> > https://tools.ietf.org/html/rfc7919 seems somewhat confusing because
> > the order of the generator (2) is q=(p-1)/2 and not  (p-1 )
> >
> > So in place of
> >
> > "Traditional finite field Diffie-Hellman has each peer choose their
> > secret exponent from the range [2, p-2]."
> > It should suggest to use
> >  "Traditional finite field Diffie-Hellman has each peer choose their
> > secret exponent from the range [2, q-1]."
> >
> > I put below some basic background that could help to understand the DH
> > security
> >
> > If a safe prime p=2q+1 is congruent to 7 modulo 8, then it is a
> > divisor of the Mersenne number
> > with its matching Sophie Germain prime (q) as exponent.
> > a Mersenne prime is a prime number that is one less than a power of
> > two.
> > That is, it is a prime number of the form Mn = 2**n - 1 for some
> > integer n.
> >
> > 2**q-1 = kp;
> > 2**(p-1)/2 = 1 mod p
> > Therefore 2 is a generator of order q=(p-1)/2
> >
> > (p-1) is a generator of order 2, since (p-1)**2 = (p**2+1-2p) = 1 mod
> > q
> >
> > Example
> > p=7 = 2x3 +1, q=3
> > p = 7 mod 8
> > 6 = 2x3
> > 1 group of order 6, phi(6)= 2 generators (q-1)
> > 1 group of order 3, phi(3)= 2 generators (q-1)
> > 1 group of order 2, phi(2)= 1 generators
> >
> > 2 4 1
> > 3 2 6 4 5 1
> > 4 2 1
> > 5 4 6 2 3 1
> > 6 1
> >
> > Le mer. 4 déc. 2019 à 02:52, Andrey Jivsov  a
> > écrit :
> >
> >> https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=(p-1)/2
> >> because this results in a peer's public key g^x= 1.
> >>
> >> Allowing this makes some man-in-the middle attacks on TLS easier,
> >> because the attacker can predict the value of the ephemeral secret
> >> key on another leg of the connection.
> >>
> >> On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer)
> >>  wrote:
> >>
> >>> See SRF
> >>>
> >>> FROM: TLS  ON BEHALF OF Pascal Urien
> >>> SENT: Tuesday, December 03, 2019 5:16 PM
> >>> TO: tls@ietf.org
> >>> SUBJECT: [TLS] DH security issue in TLS
> >>>
> >>> I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2
> >>> implementation ?
> >>>
> >>> In RFC https://tools.ietf.org/html/rfc7919
> >>> "Negotiated Finite Fie

Re: [TLS] DH security issue in TLS

[Pascal Urien]

Hi all

https://tools.ietf.org/html/rfc7919 seems somewhat confusing because the
order of the generator (2) is q=(p-1)/2 and not  (p-1 )

So in place of
"Traditional finite field Diffie-Hellman has each peer choose their secret
exponent from the range [2, p-2]."
It should suggest to use
"Traditional finite field Diffie-Hellman has each peer choose their secret
exponent from the range [2, q-1]."

I put below some basic background that could help to understand the DH
security

If a safe prime p=2q+1 is congruent to 7 modulo 8, then it is a divisor of
the Mersenne number
with its matching Sophie Germain prime (q) as exponent.
a Mersenne prime is a prime number that is one less than a power of two.
That is, it is a prime number of the form Mn = 2**n - 1 for some integer n.

2**q-1 = kp;
2**(p-1)/2 = 1 mod p
Therefore 2 is a generator of order q=(p-1)/2

(p-1) is a generator of order 2, since (p-1)**2 = (p**2+1-2p) = 1 mod q

Example
p=7 = 2x3 +1, q=3
p = 7 mod 8
6 = 2x3
1 group of order 6, phi(6)= 2 generators (q-1)
1 group of order 3, phi(3)= 2 generators (q-1)
1 group of order 2, phi(2)= 1 generators

2 4 1
3 2 6 4 5 1
4 2 1
5 4 6 2 3 1
6 1

Le mer. 4 déc. 2019 à 02:52, Andrey Jivsov  a écrit :

> https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=(p-1)/2
> because this results in a peer's public key g^x= 1.
>
> Allowing this makes some man-in-the middle attacks on TLS easier, because
> the attacker can predict the value of the ephemeral secret key on another
> leg of the connection.
>
> On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer) <
> sfluh...@cisco.com> wrote:
>
>> See SRF
>>
>>
>>
>> *From:* TLS  *On Behalf Of * Pascal Urien
>> *Sent:* Tuesday, December 03, 2019 5:16 PM
>> *To:* tls@ietf.org
>> *Subject:* [TLS] DH security issue in TLS
>>
>>
>>
>> I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2
>> implementation ?
>>
>> In RFC https://tools.ietf.org/html/rfc7919
>> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for
>> Transport Layer Security (TLS)"
>>
>> "Traditional finite field Diffie-Hellman has each peer choose their
>> secret exponent from the range [2, p-2].
>> Using exponentiation by squaring, this means each peer must do roughly
>> 2*log_2(p) multiplications,
>> twice (once for the generator and once for the peer's public key)."
>>
>> Not True !!!
>> Even for p= safe prime (i.e.. Sophie Germain prime, p=2*q+1, with p & q
>> prime number) secret exponent x= (p-1)/2 is a security issue since :
>>
>> g**xy = 1   with y an even integer
>> g**xy = g**x   for y an odd integer
>>
>>
>>
>> SRF: actually, g**xy  = 1 in both cases, as g**x = 1 (for the g, p values
>> specified in RFC7919); this is easily seen as all listed p values are safe
>> primes, and in all cases, g=2 and p=7 mod 8.
>>
>>
>>
>> In any case, why would that be a security issue?  If both sides are
>> honest (and select their x, y values honestly), the probability of one of
>> them selecting (p-1)/2 as their private value is negligible (even if our
>> selection logic allowed that as a possible value – it generally doesn’t).
>> If we have two honest parties with an adversary replacing one of the side’s
>> key share with g**(p-1)/2, well, the protocol transmits signatures of the
>> transcript, and so that’ll be detected. If you have an honest side
>> negotiating with a dishonest one, well, the dishonest one could select
>> (p-1)/2 as its private value – however, they could also run the protocol
>> honestly (and learn the shared secret and the symmetric keys, which are
>> usually the target), and there’s nothing the protocol can do about that.
>>
>>
>>
>> Now, if an honest party reused their private values for multiple
>> exchanges, a similar observation would allow an adversary to obtain a
>> single bit of the private value.  He would do that by performing an
>> exchange with the honest party mostly honestly, selecting a value x as his
>> private value, but instead of transmitting g**x as his key share, he would
>> transmit -g**x.  Then, the shared value that the honest party would derive
>> is:
>>
>>
>>
>>   g**xy  with y an even integer
>>
>>   -g**xy  with y an odd integer
>>
>>
>>
>> The adversary can compute both these values, and determine which is being
>> used later in the protocol.
>>
>>
>>
>> So, the adversary can learn a single bit of the private value (which
>> doesn’t translate to him learning any bit of the shared secret, much less
>>

[TLS] DH security issue in TLS

[Pascal Urien]

I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2
implementation ?

In RFC https://tools.ietf.org/html/rfc7919
"Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport
Layer Security (TLS)"

"Traditional finite field Diffie-Hellman has each peer choose their secret
exponent from the range [2, p-2].
Using exponentiation by squaring, this means each peer must do roughly
2*log_2(p) multiplications,
twice (once for the generator and once for the peer's public key)."

Not True !!!
Even for p= safe prime (i.e. Sophie Germain prime, p=2*q+1, with p & q
prime number) secret exponent x= (p-1)/2 is a security issue since :

g**xy = 1   with y an even integer
g**xy = g**x   for y an odd integer

If p is not a safe prime (like in RFC 5114) other issues occur...

Pascal
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Pascal Urien]

Hi All

There is a smart way to recover DH secret by a third party

It is DH tripartite base on EC paring

https://tools.ietf.org/html/draft-urien-tls-dh-tripartite-00

Rgs

Pascal



2016-09-25 23:20 GMT+02:00 Ackermann, Michael :

> I understand your concern over what the nation-state actors are doing but
> it is not the same as what Enterprises do to manage their private servers,
> networks and clients.
>
> Your final paragraph is quite a constructive question.   "What
> specifically would you have us do? What do you want in the protocol that
> enables your needs, but doesn't make it possible for everyone in the world
> to be surveilled?  Please, make some specific suggestions."
>
> My personal perspective would be, that the approach to achieving an answer
> to that important question, would start with:
>
> 1.  Gathering  protocol neutral requirements from all involved factions,
> (with help and suggestions from people on the TLS list)
>
> 2.   Brainstorming session(s) with people on the TLS list as well
> potential users/operators, with objectives that include the design of a
> solution that meets (hopefully) all known requirements.
>
> What I would like to see come out of the debate we seem to be currently
> involved in,  is the realization that significant operational/management
> issues exist with TLS 1.3 and that the IETF is taking them seriously enough
> to at least begin dialogue intended to address these issues, and
> potentially work together to craft related solution(s).   In my view this
> issue is far too complex &  pervasive to believe that any one person or
> group's perspective would produce a viable overall solution.
>
> Again, let me restate,  I don't think anyone is saying that we MUST have
> RSA.But, we, as the clients of the IETF TLS protocol, would like to
> work with you to assure we have workable, manageable  and affordable
> solutions,  that meets our needs as well as the needs of others.
>
> -Original Message-
> From: Salz, Rich [mailto:rs...@akamai.com]
> Sent: Saturday, September 24, 2016 10:10 PM
> To: Ackermann, Michael ; Pawel Jakub Dawidek <
> p.dawi...@wheelsystems.com>; tls@ietf.org
> Subject: RE: [TLS] Industry Concerns about TLS 1.3
>
> >   This lack of scope, depth and detail [in MITM infrastructures] are
> > what drove us to install the packet collection infrastructures
> > (debugging networks I think some are saying).
>
> At the risk of repeating myself and flogging this dead horse...  What you
> are doing is exactly what the nation-state actors are doing.  I bet that
> some even use that exact phrase of "packet collection infrastructure."
>
> I understand that if you want to use TLS 1.3, it is going to be expensive
> and/or inconvenient; you're going to have to educate regulators and get
> bespoke TLS endpoint solutions from vendors. Perhaps you can get the NSA's
> to stop collecting everyone's Internet traffic for future decoding?
>
> Less flippantly, what specifically would you have us do? What do you want
> in the protocol that enables your needs, but doesn't make it possible for
> everyone in the world to be surveilled?  Please, make some specific
> suggestions.
>
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS

[Pascal Urien]

Hi

a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt
the client certificat with an extra key computed from the master
secret

see
https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01

Rgs

Pascal

2015-08-24 22:56 UTC+02:00, Viktor S. Wold Eide viktor.s.wold.e...@gmail.com:
 Hi,

 I am looking for a way to achieve identity hiding for DTLS 1.2, which also
 hopefully can be used in (D)TLS 1.3, when available.

 From what I understand, for (D)TLS 1.2 it would be possible to perform an
 anonymous unencrypted handshake and then to renegotiate the connection with
 authentication within the encrypted channel, e.g., according to the expired
 draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation
 will be removed in the upcoming 1.3 version.

 What is likely to be the recommended way to achieve identity hiding for
 (D)TLS 1.3, if any?

 [1] Transport Layer Security (TLS) Encrypted Handshake Extension,
 draft-ray-tls-encrypted-handshake-00, expired in 2012
 [2] The Transport Layer Security (TLS) Protocol Version 1.3,
 draft-ietf-tls-tls13-07


 Best regards
 Viktor S. Wold Eide


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls