David Benjamin <david...@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.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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
