Hi Russ, Seem like good suggested updates.
Russ Housley wrote: >Can you point me to the 3GPP document that makes use of RFC 8773? It should >probably be referenced in Section 3.1 >as another example along with >[I-D.ietf-emu-bootstrapped-tls]. Hi, Section 5.3 of TS 33.222 specifies "Shared key-based UE authentication with certificate-based NAF authentication". Other sections specified “Shared key-based mutual authentication” and “Certificate based mutual”. It was recently discussed in 3GPP if 5.3 should be updated to refer to RFC 8773. But now when I look at TS 33.222 personally, I see that Section 5.3 actually uses HTTP Digest for the Shared key-based client authentication, not TLS PSK authentication. Must have been some misunderstanding. 3GPP does not use RFC 8773. Cheers, John Preuß Mattsson From: Russ Housley <hous...@vigilsec.com> Date: Friday, 8 December 2023 at 20:08 To: John Mattsson <john.matts...@ericsson.com> Cc: IETF TLS <tls@ietf.org> Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track John: Thanks for you thoughtful review. Russ Housley wrote: > Appendix E.6 of [RFC8446] discusses identity-exposure attacks on > PSKs. Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses > tracking prevention. The guidance in these sections remain relevant. > > If an external PSK identity is used for multiple connections, then an > observer will generally be able track clients and/or servers across > connections. The rotation of the external PSK identity or the use of > the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate > this risk. That seems like a good start. I think it would be good the TLS WG came up with additional guidelines/mechanisms/requirements for doing External PSK in a secure way that does not enable tracking. Using the same External PSK identifier for a long time should be discouraged. Maybe ECH is the solution. That would however be outside the scope of RFC 8773. Some additional comments on RFC8773(bis): - I think the abstact and introduction should talk about client authentication as well. Right now it only talks about server authentication. The external PSK provides both client and server authentication. The 3GPP use case for RFC 8773 is to use certificates for the server authentication and PSK for the client authentication. Can you point me to the 3GPP document that makes use of RFC 8773? It should probably be referenced in Section 3.1 as another example along with [I-D.ietf-emu-bootstrapped-tls]. Suggested Abstract update: This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with a combination of a certificate and an external pre-shared key (PSK). Suggested Introduction update: The TLS 1.3 [RFC8446] handshake protocol provides two mutually exclusive forms of server authentication. First, the server can be authenticated by providing a signature certificate and creating a valid digital signature to demonstrate that it possesses the corresponding private key. Second, the server can be authenticated by demonstrating that it possesses a pre-shared key (PSK) that was established by a previous handshake. A PSK that is established in this fashion is called a resumption PSK. A PSK that is established by any other means is called an external PSK. A TLS 1.3 server that is authenticating with a certificate may optionally request a certificate from the TLS 1.3 client for authentication as described in Section 4.3.2 of [RFC8446]. This document specifies a TLS 1.3 extension permitting certificate- based authentication to be combined with an external PSK as an input to the TLS 1.3 key schedule. - When RFC 8773 was published, we did not have ML-KEM and ML-DSA, now we do. I think RFC8773bis should explain how and why the solution with External PSK is needed now that we have ML-KEM and ML-DSA. Is it needed when we get standard track ML-KEM and ML-DSA? CNSA 2.0 seems to indicate that ML-KEM and ML-DSA is enough for TOP SECRET, but I know that some european governments like to always combine External PSK with asymmetric crypto just to be on the safe side and to always get PFS. I suggest an additional paragraph in Section 3.1: Quantum-resistant public-key cryptographic algorithms are becoming standards, but it will take many years for TLS 1.3 ciphersuites that use these algorithms to be developed and deployed. In some environments, deployment of a strong external PSK provides protection until these quantum-resistant algorithms are deployed. Russ Cheers, John Preuß Mattsson From: Russ Housley <hous...@vigilsec.com<mailto:hous...@vigilsec.com>> Date: Wednesday, 6 December 2023 at 21:51 To: John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Cc: IETF TLS <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track John: I respond to your three suggested changes below: (1) How about a title of "TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key" (2) None of the normative references are paywalled. Two references are not RFCs or RFC errata or I-Ds or IANA web pages: [GGM1986] is free access at https://dl.acm.org/doi/10.1145/6490.6503<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-aef859da111c15a9&q=1&e=8b806035-f71c-4c87-ae4f-a3492b6bc616&u=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F6490.6503> [K2016] I found the same paper at https://eprint.iacr.org/2016/711<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-d749c4274f4cadbd&q=1&e=f8567c67-e0dc-46bd-a090-f1ec71dd4d35&u=https%3A%2F%2Feprint.iacr.org%2F2016%2F711>. I'll point here.<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6e0c9e24a3cecc9b&q=1&e=8b806035-f71c-4c87-ae4f-a3492b6bc616&u=https%3A%2F%2Feprint.iacr.org%2F2016%2F711> (3) The privacy considerations already talk about Appendix E.6 of [RFC8446]. I am please to add a pointer to ECH, but I do not think that ECH use should not be mandated. I suggest: Appendix E.6 of [RFC8446] discusses identity-exposure attacks on PSKs. Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses tracking prevention. The guidance in these sections remain relevant. If an external PSK identity is used for multiple connections, then an observer will generally be able track clients and/or servers across connections. The rotation of the external PSK identity or the use of the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate this risk. Russ On Dec 6, 2023, at 11:51 AM, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>> wrote: Hi, I am quite convinced that the security properties are not worse than a mixture of PSK authentication, PSK key exchange, (EC)DHE key exchange, and signature authentication. In some cases, this is very good. You get the quantum-resistance of the PSK together with the PFS of ECDHE, and the entity authentication and security policies of certificates. In other cases, it is not so good as the reuse of a PSK identifier enables tracking and potentially identification of both the client and the server. I don’t think that such a field enabling tracking belongs in modern TLS, but reuse of a PSK identifier is already in RFC 8446 so this document does theoretically not make the worst-case worse. If RFC 8773 is updated. I think the following things should be updated: - The title and abstract only talks about PSK authentication. The key exchange is likely more important to make quantum-resistant than the authentication. I think the title and abstract should talk about PSK key exchange. - I think the paywalled references should be removed. I think paywalled references are both a cybersecurity risk and a democracy problem [1]. I don’t think they belong in RFCs unless absolutely necessary. RFC 8446bis recently removed all paywalled references. - The document should refer to section C.4 of RFC8446bis that now includes a short discussion on that reuse of an PSK identifier enables tracking. I think RFC8773bis should have a warning early that the privacy properties are much worse than the normal certificate-based authentication. This could be completely solved by mandating ECH. Alternatively, it could be solved by sending the PSK identifier after flight #1 when things are encrypted. 3GPP specified the use of server certificate authentication combined with PSK authentication and key exchange for TLS 1.2. As that mode was not available in RFC 8446, 3GPP does not specify this mode for TLS 1.3 but there have recently been discussions in 3GPP about adding RFC 8773. I think the really bad privacy properties of PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy properties of TLS 1.3 with PSK have also been discussed several times in EMU WG. I think a mode that sends the PSK identifier encrypted would make a lot more sense for standard track. I am not supportive of standard track unless the tracking problem is solved. If the privacy problems are solved, I am however very supportive. Adding an extra roundtrip is a small price to pay for privacy. Adding a field (psk identifier) that can be used for tracking to current certificate-based TLS is making privacy worse. I don’t think that is a good idea or worthy of standards track. Cheers, John Preuß Mattsson [1] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-1dad7286c4a2ace2&q=1&e=8b806035-f71c-4c87-ae4f-a3492b6bc616&u=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc-forum%2Fc%2FW2VOzy0wz_E%2Fm%2F6pgf5tFaAAAJ> From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of Dan Harkins <dhark...@lounge.org<mailto:dhark...@lounge.org>> Date: Wednesday, 6 December 2023 at 14:50 To: TLS@ietf.org<mailto:TLS@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track Hi, I approve of this transition to standards track and I am implementing this as well. regards, Dan. On 11/29/23 7:51 AM, Joseph Salowey wrote: > RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with > an External Pre-Shared Key) was originally published as experimental > due to lack of implementations. As part of implementation work for the > EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there > is ongoing implementation work. Since the implementation status of RFC > 8773 is changing, this is a consensus call to move RFC 8773 to > standards track as reflected in > [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). > This will also help avoid downref for the EMU draft. Please indicate > if you approve of or object to this transition to standards track > status by December 15, 2023. > > Thanks, > > Joe, Sean, and Deirdre > > _______________________________________________ > TLS mailing list > TLS@ietf.org<mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
