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