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

David Benjamin <davidben@chromium.org> 于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.Tschofenig@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 <davidben@chromium.org>
>> *Sent:* Wednesday, September 23, 2020 5:47 PM
>> *To:* Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
>> *Cc:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Filippo Valsorda <
>> filippo@ml.filippo.io>; Carrick Bartle <cbartle891@icloud.com>;
>> 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
>> <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=
>> 40akamai.com@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
>