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.
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.
At a minimum, this kind of consideration should be added to the security
section if we move this RFC to standards track.
-- 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
