> On Dec 5, 2023, at 12:01 PM, Christian Huitema <huit...@huitema.net> wrote: > > On 12/5/2023 8:13 AM, Russ Housley wrote: >> At IETF 104, I presented a slide with informal reasoning about TLS 1.3 >> Security. >> Authentication: >> The certificate processing is exactly the same. It is not better or worse. >> Key Schedule computation of Early Secret: >> – Initial Handshake >> Without extension: HKDF-Extract(0, 0) >> With extension: HKDF-Extract(ExternalPSK, 0) >> – Subsequent Handshake No changes. >> Conclusion: Any entropy contributed by the External PSK can only make the >> Early Secret better; the External PSK cannot make it worse. > > That's true, but that's not the only point. Your introduction section argues > that adding entropy will enable resistance to quantum attacks. > We assume that quantum attacks can break symmetric encryption using meet in > the middle algorithm, which means the "safe" size for a quantum resistant > symmetric key is probably 256 bits, not the commonly used 128.
Agreed. > If the PSK is also used to encrypt early data, and if that PSK is not strong > enough, the quantum attacker will do a two steps: use the early data as an > oracle to break the PSK, then use the now discovered PSK to break the [EC]DH > + PSK combination. The external PSK is inserted in the key schedule in the initial handshake. The resumption PSK is used in subsequent handshakes. So, I am missing something in your concern. > At a minimum, this kind of consideration should be added to the security > section if we move this RFC to standards track. I am pleased to add some text about the size of the external PSK. Russ > > -- Christian Huitema > > >> I will be glad to work with someone that already has things set up for TLS >> 1.3 without this extension to do a more formal analysis. >> Russ >>> On Dec 3, 2023, at 5:00 PM, Eric Rescorla <e...@rtfm.com> wrote: >>> >>> To respond directly to the call: I think we should require some level of >>> formal analysis for this kind of extension. >>> >>> If there is some, I think the WG should look at it to determine whether >>> it's sufficient. If there isn't I think this should remain at experimental. >>> Not having a normative downref is not a good reason; those are trivial to >>> manage. >>> >>> -Ekr >>> >>> >>> On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly <durumcrustu...@gmail.com >>> <mailto:durumcrustu...@gmail.com>> wrote: >>>> Whoops wrong one, strike that >>>> >>>> On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly <durumcrustu...@gmail.com >>>> <mailto:durumcrustu...@gmail.com>> wrote: >>>>> At least one bit of work: >>>>> https://dl.acm.org/doi/abs/10.1145/3548606.3559360 >>>>> >>>>> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla <e...@rtfm.com >>>>> <mailto:e...@rtfm.com>> wrote: >>>>>> What do we have in terms of formal analysis for this extension? >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley <hous...@vigilsec.com >>>>>> <mailto:hous...@vigilsec.com>> wrote: >>>>>>> I think this should move forward. I am encouraged that at least two >>>>>>> people have spoken to me about their implementations. >>>>>>> >>>>>>> Russ >>>>>>> >>>>>>>> On Nov 29, 2023, at 10:51 AM, Joseph Salowey <j...@salowey.net >>>>>>>> <mailto:j...@salowey.net>> 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 >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > 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
