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

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]>
Sent: Monday, September 21, 2020 2:01 PM
To: Hannes Tschofenig <[e-mail]>
Cc: Filippo Valsorda <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, September 21, 2020 11:44 AM
To: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Cc: Filippo Valsorda <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <mailto:[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>
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.