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 protected]> wrote: > I agree with Hannes’s reasoning. > > > > I am also concerned about devolving TLS to be just Web browser/server. > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
