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 <david...@chromium.org> Sent: Wednesday, September 23, 2020 5:47 PM To: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> Cc: Hannes Tschofenig <hannes.tschofe...@arm.com>; Filippo Valsorda <fili...@ml.filippo.io>; Carrick Bartle <cbartle...@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....@dmarc.ietf.org<mailto: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<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
