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

[Salz, Rich]

>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

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



___
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

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

[Filippo Valsorda]

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

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

[Hannes Tschofenig]

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 
Sent: Thursday, September 24, 2020 12:02 PM
To: Filippo Valsorda ; Hannes Tschofenig 
; Carrick Bartle 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Filippo Valsorda  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.


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

[Peter Gutmann]

Filippo Valsorda  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.


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

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

[Lanlan Pan]

David Benjamin  于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.
>
> 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...
>

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


> (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 <
> hannes.tschofe...@arm.com> 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 
>> *Sent:* Wednesday, September 23, 2020 5:47 PM
>> *To:* Salz, Rich 
>> *Cc:* Hannes Tschofenig ; Filippo Valsorda <
>> fili...@ml.filippo.io>; Carrick Bartle ;
>> tls@ietf.org
>> *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
>> , 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 > 40akamai@dmarc.ietf.org> wrote:
>>
>> I agree with Hannes’s reasoning.
>>
>>
>>
>> I am also concerned about devolving TLS to be just Web browser/server.
>>
>>
>>
>> ___
>> TLS mailing list
>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls