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

From: John Mattsson <[email-masked]>
Date: Sat, 19 Sep 2020 11:30:13 +0000

Hi,

Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric keys for authentication and key exchange made me think about the future role of external PSK in TLS.

https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/

I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy systems. Due to the major privacy, security, and deployment limitations with PSK, I see little need to use PSK (besides resumption) in new systems, except for the use case in RFC 8773.

LAKE recently removed PSK authentication completely as it does not produce smaller messages and comes with severe privacy and deployments problems. Increasing code size (a few kB) and slightly increased computation/latency was not seen as a big problems.

Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and especially psk_ke are both marked as RECOMMENDED. If used in the initial handshake, both modes have severe privacy problems, and psk_ke does not give PFS, thus making pervasive monitoring much easier. If groups keys are used, additional security problems arise. All TLS 1.2 cipher suites without (EC)DHE has for good reasons been marked as NOT RECOMMENDED.

I have recently seen several people arguing that the inclusion of PSK in TLS 1.3 means that the use external PSKs are now recommended. I don't think that was the intension of the TLS WG.

I strongly think psk_ke should be NOT RECOMMENDED, except for resumption. Irrespectively of what ‘Y’ in the recommended column actually means, people are and will read it as recommended to use.

Cheers,
John

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Sep 2020 11:48:13 +0000

John Mattsson <john.mattsson=[email-masked]> writes:

>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,

PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
just because there's a concern for one specific environment doesn't mean it
should be banned for any use.  In particular, I think if a specific industry
has a particular concern, they should profile it for use in that industry but
not require that everyone else change their behaviour.

Peter.

---

From: "Filippo Valsorda" <[email-masked]>
Date: Sat, 19 Sep 2020 18:00:00 +0200

> not require that everyone else change their behaviour.

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.

Setting Recommended to N is not "banning" anything, it's saying it "has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases". SCADA sounds like a pretty specific use case.

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke wouldn't be marked N like all suites lacking PFS.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 19 Sep 2020 17:10:47 -0400

On Sat, Sep 19, 2020 at 06:00:00PM +0200, Filippo Valsorda wrote:

> Setting Recommended to N is not "banning" anything, it's saying it
> "has not been through the IETF consensus process, has limited
> applicability, or is intended only for specific use cases". SCADA
> sounds like a pretty specific use case.
> 
> I don't have a strong opinion on psk_dhe_ke, but I see no reason
> psk_ke wouldn't be marked N like all suites lacking PFS.

Is there actually a problem here?  "Nobody" is using external PSK "on
the open Internet", because, perhaps not surprisingly, you need to have
a pre-shared key for that.  Thus, browsers and the like just don't have
pre-shared keys with each and every web-server the user might direct
them at.

By the time external PSK (i.e. not resumption session tickets) is actually
in use, we're already well outside the use cases where we're protecting
the privacy of Joe-consumer using commodity software.

Perhaps in the IoT space one can envision some device "calling home" to
the manufacturer or supplier in a manner that identifies the device
slightly more than just the source and destination IP addresses, ...
but I don't see this as motivating a compelling need to change the
registry.

-- 
    Viktor.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Sep 2020 11:18:51 +0000

John,

The use of plain PSK makes a lot of sense because it provides the lowest footprint solution for really constrained systems. Given that the LAKE group wanted to focus on constrained IoT devices makes the decision by the group questionable.

As you know, TLS 1.3 merged the handling of PSKs previously found in three different RFCs, namely session resumption, ciphersuites with PSK, and session resumption without server-side state into one solution. As such, there is not even extra cost associated with external PSKs.

I have been arguing that a solution that uses PSKs with ECDHE, as you proposed in RFC 8442, is less useful because very constrained are not going to use the asymmetric crypto needed for the ECDHE. Those deployments could instead go directly to a raw public key solution instead.

Ciao
Hannes

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of John Mattsson
Sent: Saturday, September 19, 2020 1:30 PM
To: [email-masked]
Subject: [TLS] The future of external PSK in TLS 1.3

Hi,

Cheers,
John

_______________________________________________
TLS mailing list
[email-masked]
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.

---

From: Carrick Bartle <[email-masked]>
Date: Sun, 20 Sep 2020 20:30:37 -0700

I'm also fine with marking psk_ke as not recommended to be consistent with the non-PFS ciphers, but there are plenty of valid use cases that justify keeping dhe_psk_ke as recommended for external PSKs. Several of these use cases are detailed in draft-ietf-tls-external-psk-guidance-00.

> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda <[email-masked]> wrote:
> 
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann <[email-masked] <mailto:[email-masked]>>:
>> John Mattsson <john.mattsson=[email-masked] <mailto:[email-masked]>> writes:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Sep 2020 09:22:25 +0000

Hi Carrick,

Can you justify your reasoning?

The challenge I have with the work on IoT in the IETF that the preferences for pretty much everything changes on a regular basis.

I don't see a problem that requires a change. In fact, I have just posted a mail to the UTA list that gives an overview of the implementation status of embedded TLS stacks and PSK-based ciphersuites are widely implemented.

Ciao
Hannes

From: TLS <[email-masked]> On Behalf Of Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

On Sep 19, 2020, at 9:00 AM, Filippo Valsorda <[email-masked]<mailto:[email-masked]>> wrote:

2020-09-19 13:48 GMT+02:00 Peter Gutmann <[email-masked]<mailto:[email-masked]>>:

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke wouldn't be marked N like all suites lacking PFS.
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Sep 2020 09:28:45 +0000

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<https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/>

Ciao
Hannes

---

From: Pascal Urien <[email-masked]>
Date: Mon, 21 Sep 2020 11:43:35 +0200

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 <[email-masked]>
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.
>
>
>
> 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
> <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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Sep 2020 10:35:34 +0000

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 <[email-masked]>
Sent: Monday, September 21, 2020 11:44 AM
To: Hannes Tschofenig <[email-masked]>
Cc: Filippo Valsorda <[email-masked]>; [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Hi All

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

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)

Pascal

Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig <mailto:[email-masked]> 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.

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

mailto:[email-masked]

---

From: Pascal Urien <[email-masked]>
Date: Mon, 21 Sep 2020 14:01:23 +0200

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 <[email-masked]>
a écrit :

> 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
>
>
> • 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.
>
> being revised, see
> https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/
>
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Sep 2020 12:35:50 +0000

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

Sent: Monday, September 21, 2020 2:01 PM

Hi Hannes

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

Pascal

Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> a écrit :
Hi Pascal,

Ciao
Hannes

From: Pascal Urien <[email-masked]<mailto:[email-masked]>>
Sent: Monday, September 21, 2020 11:44 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: Filippo Valsorda <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Hi All

Pascal

Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig <mailto:[email-masked]<mailto:[email-masked]>> a écrit :
Hi Filippo,

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:[email-masked]<mailto:[email-masked]>
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.

---

From: Pascal Urien <[email-masked]>
Date: Mon, 21 Sep 2020 14:47:04 +0200

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 <[email-masked]>
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:
>
> *From:* Pascal Urien <[email-masked]>
> *Sent:* Monday, September 21, 2020 2:01 PM
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* Filippo Valsorda <[email-masked]>; [email-masked]
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>
>
>
> Hi Hannes
>
>
>
> Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig <
> [email-masked]> a écrit :
>
> Hi Pascal,
>

---

From: Pascal Urien <[email-masked]>
Date: Mon, 21 Sep 2020 14:53:53 +0200

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 <[email-masked]> a
écrit :

> hi Hannes
>
> no openssl or wolfssl are used as client in order to check
> interoperability with tls-se server
>
> Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig <
>> https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) I
>> was wondering whether there is an implementation of this approach.
>>
>> Ciao
>> Hannes
>>
>>
>> • Indeed, if the SCADA industry has a particular need, they should

---

From: Carrick Bartle <[email-masked]>
Date: Mon, 21 Sep 2020 09:19:13 -0700

> Can you justify your reasoning? 

Which part?

> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Carrick, 
>  
> I don’t see a problem that requires a change. In fact, I have just posted a mail to the UTA list that gives an overview of the implementation status of embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 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

---

From: Achim Kraus <[email-masked]>
Date: Mon, 21 Sep 2020 19:57:13 +0200

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:
> Le lun. 21 sept. 2020 à 14:47, Pascal Urien <[email-masked]
> <mailto:[email-masked]>> a écrit :
>
>     hi Hannes
>
>     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
>     <[email-masked] <mailto:[email-masked]>> 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 <[email-masked]
>         <mailto:[email-masked]>>
>         *To:* Hannes Tschofenig <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* Filippo Valsorda <[email-masked]
>         <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>         *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
>         <[email-masked] <mailto:[email-masked]>> a
>         écrit :____
>
>             Hi Pascal,
>
>             https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/)
>             I was wondering whether there is an implementation of this
>             approach.
>
>             Ciao
>             Hannes
>
>
>             Cc: Filippo Valsorda <[email-masked]
>             <mailto:[email-masked]>>; [email-masked]
>             <mailto:[email-masked]>
>             https://tools.ietf.org/html/draft-urien-tls-se-00  uses
>             TLS1.3 server  PSK+ECDHE for secure elements
>
>             Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig
>             <mailto:[email-masked]
>             <mailto:[email-masked]>> 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
>             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
>             mailto:[email-masked] <mailto:[email-masked]>
>             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.
>
>

---

From: Achim Kraus <[email-masked]>
Date: Mon, 21 Sep 2020 20:13:28 +0200

Hi John,

I can only fully agree with Hannes's arguments!

PSK is in my experience for some constraint devices currently the only
choice. Devices, which are able to execute a PSKs with ECDHE handshakes,
will be able to use RPK.

I'm not sure, if sometimes the arguments, not to recommend something,
should be more differentiated. Pretty sure, outside IoT, there may be no
reason left to use that. But inside IoT, it may take some more time
until almost all device can use it.

best regards
Achim

---

From: Pascal Urien <[email-masked]>
Date: Mon, 21 Sep 2020 22:57:03 +0200

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

---

From: Achim Kraus <[email-masked]>
Date: Tue, 22 Sep 2020 07:21:45 +0200

Hi Pascal,

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

Agreed. Therefore I wrote

 >> Isn't it always a question of what to protect in which environment?

Maybe, one column with recommended (Y/N/<blank>), is not enough.

##############################
Note

     If an item is not marked as "Recommended", it does not
     necessarily mean that it is flawed; rather, it indicates that
     the item either has not been through the IETF consensus process,
     has limited applicability, or is intended only for specific use
     cases
##############################

best regards
Achim

Am 21.09.20 um 22:57 schrieb Pascal Urien:
> 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 <[email-masked]
> <mailto:[email-masked]>> a écrit :
>
>     Hi Pascal,
>
>      > Le lun. 21 sept. 2020 à 14:47, Pascal Urien
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>>
>     a écrit :
>      >
>      >     hi Hannes
>      >
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>>> a écrit :
>      >
>      >         Hi Pascal, ____
>      >
>      >         __ __
>      >
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >         In the draft
>     https://tools.ietf.org/html/draft-urien-tls-se-00
>      >         <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>> a
>      >         écrit :____
>      >
>      >             Hi Pascal,
>      >
>      >             Since I am surveying implementations for the update
>     of RFC
>      >             7925 (see
>      >             From: Pascal Urien <[email-masked]
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >             To: Hannes Tschofenig <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>
>      >             The secure element  only needs a classical TCP/IP
>     interface
>      >             (i.e. sockets like)
>      >
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>> a écrit :
>      >             Hi Filippo,
>      >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     attachments

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Sep 2020 11:49:17 +0000

Hi Carrick,

you note that SCADA is a pretty specific use case. SCADA sounds specific but TLS is used widely in the IoT market. It is even used in devices that use smart cards, which use TLS with PSK to protect their provisioning protocol.

I am worried that marking a ciphersuite as N with the meaning that it "has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases" is hard for readers to understand which of these three cases were actually the reason for marking it as “N”. The "has not been through the IETF consensus process" will scare off many people.

For most people the web is the generic case and everything else is a “specific use case”. Sure, the web is very important but TLS is a generic protocol used in many environments.

I don’t understand John’s motivation. The LAKE group makes a decision to remove PSK support. That’s good for them. Does this imply that the TLS group also needs to make the same decision?

Ciao
Hannes

From: Carrick Bartle <[email-masked]>
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Carrick Bartle <cbartle891=[email-masked]>; Filippo Valsorda <[email-masked]>; [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Which part?

On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carrick,

Ciao
Hannes

From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] The future of external PSK in TLS 1.3

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 23 Sep 2020 12:45:13 +0000

I sincerely hope that the TLS group will NOT make the same decision [as LAKE - to drop PSK].

Regards,
Uri

> On Sep 23, 2020, at 07:50, Hannes Tschofenig <[email-masked]> wrote:
> 
> 
> Hi Carrick,
>

---

From: "Filippo Valsorda" <[email-masked]>
Date: Wed, 23 Sep 2020 15:39:14 +0200

> For most people the web is the generic case and everything else is a “specific use case”. Sure, the web is very important but TLS is a generic protocol used in many environments.  

By this reasoning, what is a specific use case? My interpretation is "anything you shouldn't use unless you have specific requirements". Compatibility with smart cards is clearly a specific requirement, and you should definitely use an ECDH PSK if you can. What's your interpretation?

The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards, regardless of whether they talk to browsers or other services.

> I don’t understand John’s motivation. The LAKE group makes a decision to remove PSK support. That’s good for them. Does this imply that the TLS group also needs to make the same decision?

(Again, no one is suggesting dropping anything, as far as I can tell.)

> *From:* Carrick Bartle <[email-masked]> 
> *Sent:* Monday, September 21, 2020 6:19 PM
> *Cc:* Carrick Bartle <cbartle891=[email-masked]>; Filippo Valsorda <[email-masked]>; [email-masked]

>> *From:* TLS <[email-masked]> *On Behalf Of *Carrick Bartle
>> *Sent:* Monday, September 21, 2020 5:31 AM
>> *To:* Filippo Valsorda <[email-masked]>
>> *Cc:* [email-masked]

---

From: David Woodhouse <[email-masked]>
Date: Wed, 23 Sep 2020 14:53:50 +0100

On Sat, 2020-09-19 at 11:30 +0000, John Mattsson wrote:
> Hi,
> 
> Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric
> keys for authentication and key exchange made me think about the
> future role of external PSK in TLS.
> 
> I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy
> systems. Due to the major privacy, security, and deployment
> limitations with PSK, I see little need to use PSK (besides
> resumption) in new systems, except for the use case in RFC 8773.

Some VPN protocols (e.g. Cisco AnyConnect) attempt to establish a DTLS
session in parallel with an existing TLS session, to avoid TCP-over-TCP 
where possible.

Cisco does it by fabricating a DTLS session (details exchanged over the
existing authenticated TLS channel) and then "resuming" it. Using this
method, the DTLS protocol version and all options are hard-coded when
the session is fabricated. This makes me sad.

In the open source implementation of client/server we have extended the
protocol to exchange a PSK over the existing TLS session, then
negotiate DTLS the "normal" way using that PSK.

That's a lot cleaner (IMO) and seems like a valid use case for PSK.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Sep 2020 14:44:15 +0000

Hi Filippo,

I worry that labelling ciphersuites that is deployed in parts of the industry as “not recommended” will confuse those who look at the IANA website.

Only those readers who look at the note will then learn that not recommended means three things, whereby the option "has not been through the IETF consensus process" should not give readers great confidence either.

I hope this explains my concern.

There is no problem with the use of these PSK ciphersuites, so why mark them as “not recommended”?

Ciao
Hannes

From: Filippo Valsorda <[email-masked]>
Sent: Wednesday, September 23, 2020 3:39 PM
To: Hannes Tschofenig <[email-masked]>; Carrick Bartle <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

2020-09-23 13:49 GMT+02:00 Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>:

Hi Carrick,

Ciao

Hannes

From: Carrick Bartle <[email-masked]<mailto:[email-masked]>>
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: Carrick Bartle <cbartle891=[email-masked]<mailto:cbartle891=[email-masked]>>; Filippo Valsorda <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Which part?

Hi Carrick,

Ciao

Hannes

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Sep 2020 15:36:18 +0000

I agree with Hannes’s reasoning.

I am also concerned about devolving TLS to be just Web browser/server.

---

From: David Benjamin <[email-masked]>
Date: Wed, 23 Sep 2020 11:47:27 -0400

There are two different code points involved in TLS 1.3 PSK, and I think
there may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication
method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
the handshake mixes an additional (EC)DH exchange into the key schedule.
We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
seems to me psk_ke with an external PSK should be similar. Handshakes using
psk_ke with an external PSK incorporate no secrets in the key exchange
apart from a (often long-lived) external symmetric secret. Compromise that
secret, and all traffic ever authenticated with that PSK is compromised.
Resumption PSKs use short-lived keys, so psk_ke is less immediately
disastrous but given the equivalent construction in TLS 1.2 has forward
secrecy issues <https://www.imperialviolet.org/2013/06/27/botchingpfs.html>,
marking it as N across the board seems a good idea to me. (BoringSSL does
not implement psk_ke for this reason. Looks like Go and NSS do not
implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so
I don't feel very strongly here.

David

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Sep 2020 16:03:36 +0000

Hi David,

my problem is that the IANA registry only says “not recommended” but it does not say for what environments these ciphersuites are not recommended. Worse, it also wants to indicate whether the specification has gone through the IETF process.

Ciao
Hannes

From: David Benjamin <[email-masked]>
Sent: Wednesday, September 23, 2020 5:47 PM
To: Salz, Rich <rsalz=[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Filippo Valsorda <[email-masked]>; Carrick Bartle <[email-masked]>; [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

There are two different code points involved in TLS 1.3 PSK, and I think there may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether the handshake mixes an additional (EC)DH exchange into the key schedule. We've already marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it seems to me psk_ke with an external PSK should be similar. Handshakes using psk_ke with an external PSK incorporate no secrets in the key exchange apart from a (often long-lived) external symmetric secret. Compromise that secret, and all traffic ever authenticated with that PSK is compromised. Resumption PSKs use short-lived keys, so psk_ke is less immediately disastrous but given the equivalent construction in TLS 1.2 has forward secrecy issues<https://www.imperialviolet.org/2013/06/27/botchingpfs.html>, marking it as N across the board seems a good idea to me. (BoringSSL does not implement psk_ke for this reason. Looks like Go and NSS do not implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so I don't feel very strongly here.

David

On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich <rsalz=[email-masked]<mailto:[email-masked]>> wrote:
I agree with Hannes’s reasoning.

---

From: David Benjamin <[email-masked]>
Date: Wed, 23 Sep 2020 12:31:56 -0400

It sounds like the registry may be confusing, so perhaps we, independent of
the existing criteria for Y vs N, need to do a better job of presenting the
information. That sounds like an orthogonal issue to whether psk_ke should
be marked as recommended. There are plenty of recommended = N cipher suites
in the registry that went through the IETF process. Security expectations
evolve or we may make mistakes, and this is one tool we have for realigning
things when that happens.

Regarding how psk_ke should be marked, we have already marked the analogous
cipher suite in TLS 1.2, TLS_PSK_WITH_AES_128_GCM_SHA256, as N. There is
indeed a problem with the use of that mode. TLS 1.3 was intended to provide
forward secrecy, and psk_ke does not do so. This is especially problematic
with external PSKs, such as the smartcards folks mentioned, because it
means all traffic hinges on a long-lived shared secret. The one footnote is
that TLS 1.3 uses the same code points for external PSKs and resumption,
and the precedent is less clear for resumption. But TLS 1.2 resumption's
lack of fresh key exchange is a well-documented problem that we happily
fixed with psk_dhe_ke, so I'm perfectly fine extending the status to psk_ke
with resumption.

This is separate from psk_dhe_ke, which is analogous to TLS 1.2's
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256. That one is still recommended Y. For
that matter, psk_dhe_ke is used in ECDH-ful resumption, so if the WG wants
to say something stronger about external PSKs, we'd need a new values in
that column anyway...

(An aside, psk_dhe_ke and psk_ke are PSK key exchange modes, not cipher
suites.)

On Wed, Sep 23, 2020 at 12:03 PM Hannes Tschofenig <
[email-masked]> wrote:

> Hi David,
>
>
>
> my problem is that the IANA registry only says “not recommended” but it
> does not say for what environments these ciphersuites are not recommended.
> Worse, it also wants to indicate whether the specification has gone through
> the IETF process.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* David Benjamin <[email-masked]>
> *Sent:* Wednesday, September 23, 2020 5:47 PM
> *To:* Salz, Rich <rsalz=[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; Filippo Valsorda <
> [email-masked]>; Carrick Bartle <[email-masked]>;
> [email-masked]
> secrecy issues
> <https://www.imperialviolet.org/2013/06/27/botchingpfs.html>, marking it
> as N across the board seems a good idea to me. (BoringSSL does not
> implement psk_ke for this reason. Looks like Go and NSS do not implement it
> either.)
>
>
>

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 23 Sep 2020 10:52:27 -0700

I didn't mention SCADA at all. Did you mean to address this question to Filippo or Peter?

> On Sep 23, 2020, at 4:49 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Carrick, 
>  
> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Carrick, 
>  
> From: TLS <[email-masked] <mailto:[email-masked]>> On Behalf Of Carrick Bartle
> To: Filippo Valsorda <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>

---

From: Lanlan Pan <[email-masked]>
Date: Thu, 24 Sep 2020 16:40:30 +0800

David Benjamin <[email-masked]> 于2020年9月24日周四 上午12:32写道：

> It sounds like the registry may be confusing, so perhaps we, independent
> of the existing criteria for Y vs N, need to do a better job of presenting
> the information. That sounds like an orthogonal issue to whether psk_ke
> should be marked as recommended. There are plenty of recommended = N cipher
> suites in the registry that went through the IETF process. Security
> expectations evolve or we may make mistakes, and this is one tool we have
> for realigning things when that happens.
>
> Regarding how psk_ke should be marked, we have already marked the
> analogous cipher suite in TLS 1.2, TLS_PSK_WITH_AES_128_GCM_SHA256, as N.
> There is indeed a problem with the use of that mode. TLS 1.3 was intended
> to provide forward secrecy, and psk_ke does not do so. This is especially
> problematic with external PSKs, such as the smartcards folks mentioned,
> because it means all traffic hinges on a long-lived shared secret. The one
> footnote is that TLS 1.3 uses the same code points for external PSKs and
> resumption, and the precedent is less clear for resumption. But TLS 1.2
> resumption's lack of fresh key exchange is a well-documented problem that
> we happily fixed with psk_dhe_ke, so I'm perfectly fine extending the
> status to psk_ke with resumption.
>

+1,  psk_ecdhe_ke is  useful at IoT scenario without certificate.

maybe we can just mark N for those who doesn't provide forward secrecy.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 24 Sep 2020 10:02:29 +0000

Filippo Valsorda <[email-masked]> writes:

>The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS
>or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards

How do you know that?  I don't know of any data supporting that (I'd love to
see it if you've got it, non-web use of TLS is the submerged part of the
iceberg).  Taking "SCADA/IoT/etc" to be a placeholder for M2M or more
generally "non-web use", an awful lot of TLS gets done outside the web, which
uses it it completely different ways than web users do.  For example pretty
much all of the fancy features in TLS 1.3, both in the core protocol and the
endless add-ons, have no purpose or function in M2M communications.  So
perhaps the answer is to have two sets of requirements, one for web use, one
for everything else.  If you try for a one-size-fits-all approach you'll
either get the currently widespread "TLS == the web" or have to include two
mostly nonintersecting sets of options to cover web vs. M2M use.

Peter.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Sep 2020 10:19:00 +0000

Nicely said, Peter.

To add: this is also the reason why the UTA group has been working on two sets of documents to capture profiles for the web (+email+IM) and IoT:
1) RFC 7590 and now draft-ietf-uta-tls13-iot-profile-00
2) RFC 7525 and now draft-sheffer-uta-rfc7525bis

-----Original Message-----
From: Peter Gutmann <[email-masked]>
Sent: Thursday, September 24, 2020 12:02 PM
To: Filippo Valsorda <[email-masked]>; Hannes Tschofenig <[email-masked]>; Carrick Bartle <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Filippo Valsorda <[email-masked]> writes:

>The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls
>or NSS or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards

How do you know that?  I don't know of any data supporting that (I'd love to see it if you've got it, non-web use of TLS is the submerged part of the iceberg).  Taking "SCADA/IoT/etc" to be a placeholder for M2M or more generally "non-web use", an awful lot of TLS gets done outside the web, which uses it it completely different ways than web users do.  For example pretty much all of the fancy features in TLS 1.3, both in the core protocol and the endless add-ons, have no purpose or function in M2M communications.  So perhaps the answer is to have two sets of requirements, one for web use, one for everything else.  If you try for a one-size-fits-all approach you'll either get the currently widespread "TLS == the web" or have to include two mostly nonintersecting sets of options to cover web vs. M2M use.

Peter.

---

From: "Filippo Valsorda" <[email-masked]>
Date: Thu, 24 Sep 2020 16:11:09 +0200

2020-09-24 12:02 GMT+02:00 Peter Gutmann <[email-masked]>:
> 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.

---

From: Pascal Urien <[email-masked]>
Date: Thu, 24 Sep 2020 16:38:58 +0200

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 <[email-masked]> a
écrit :

> "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.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Sep 2020 15:03:02 +0000

>or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards

Even if this is true (proof by assertion): So what?  Do those users not get to be a participant?

---

From: Pascal Urien <[email-masked]>
Date: Mon, 28 Sep 2020 13:12:23 +0200

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 <[email-masked]>
a écrit :

>
>
> Ping me when it becomes available or post a link to the UTA mailing list.
>
>
>
> *Sent:* Monday, September 21, 2020 4:18 PM
> Not at this moment but the code will be pusblished on github
>
>
>
> Le lun. 21 sept. 2020 à 15:30, Hannes Tschofenig <
> Thanks for the details.
> Is the code for the tls13 server on the javacard open source?
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> *Sent:* Monday, September 21, 2020 2:54 PM