On 12/5/2023 10:56 AM, Russ Housley wrote:
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.
Yes. Both are used to compute the "early secret" -- external PSK for the
initial handshake, resumption PSK in subsequent handshakes. If the
secrets are "short" and the attacker can use early data as some kind of
oracle, then the attacker can probably crack the PSK for the initial
handshake, or the resumption PSK in subsequent handshakes. If the PSK is
cracked, it probably does not add much effective entropy to the key
computed via 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.
I am pleased to add some text about the size of the external PSK.
Thanks. I am not 100% sure that we actually have an attack against the
[EC]DH+PSK combination, but I am confident than if the PSK secret is
weak, the attacker can get to the early data. If only for that, it is
prudent to use long enough PSK.
-- Christian Huitema
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
