Stephen: Maybe. ECH would need to be updated to use PQC algorithms to get that protection.
Ill add that point: 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] with algorithms that a secure against a CRQC can mitigate this risk. Russ > On Dec 6, 2023, at 4:00 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > Hiya, > >> (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. > > While I'm a fan of ECH, does it actually do the trick here? > If the adversary has a CRQC then we'd need an updated ECH > that's not vulnerable in that scenario, and we don't have > that now. (And it might be hard to get to, given MTU sizes.) > > Cheers, > S. > >> 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> 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 >>> >>> 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 > <OpenPGP_0xE4D8E9F997A833DD.asc>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
