Stephen Farrell wrote:
> That'd be a fairly giant outer client hello
Well, is there a latency histogram?
The reality I've seen ignored in these discussions is that these large
handshake messages are in fact very slow or broken on older
implementations, but that it might not matter.
The very slo
sgtm
On Wed, Dec 13, 2023 at 4:36 PM Russ Housley wrote:
> Bas:
>
> Thanks. I've adjusted the proposed text to address your comments:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys. For protection
>against the
> By contrast the PQ version "just" has key size issues to worry about
> with the DNS advertising bits and maybe some structures that get
> tight.
>
I have the same intuition. Instead of guessing, we should plop Kyber in ECH
and see if it works.
If not then there are still other paths besides PSK
On Wed, Dec 13, 2023 at 10:29 AM Christian Huitema wrote:
>
> Doing a PQ version of ECH would be hard. On the other hand, doing an
> 8773-like enhancement to ECH should not be all that hard. It would
> require that the outer CH contains a PSK shared between the client and
> the fronting server, a
On 12/12/2023 2:50 PM, Stephen Farrell wrote:
Hiya,
On 12/12/2023 17:08, Russ Housley wrote:
Stephen:
I've been thinking about your point. Some people want to use RFC
8773 to protect data that is transmitted today and recorded from the
future invention of a quantum computer. To do this, t
Bas:
Thanks. I've adjusted the proposed text to address your comments:
Implementations must use a ciphersuite that includes a symmetric
encryption algorithm with sufficiently large keys. For protection
against the future invention of a CRQC, the symmetric key needs to be
at least 12
>
> PS: I do not want us to hold up producing the ECH RFC while
> we figure that out - we should get the current thing out the
> door first!
>
Completely agree.
Bas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hiya,
On 13/12/2023 13:18, Bas Westerbaan wrote:
Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
deployable, and whether its performance is acceptable, is something we
should figure out.)
I guess we're just interpreting "as-is" differently. What I
meant by "as-is" was a
>
> I think there is a companion point to be made. I suggest:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys. For protection
>against the future invention of a CRQC, the symmetric key needs to be
>at least 256
Stephen:
>
>> I've been thinking about your point. Some people want to use RFC
>> 8773 to protect data that is transmitted today and recorded from the
>> future invention of a quantum computer. To do this, the handshake
>> includes the identifier for the external PSK, and an observer can get
>>
Wednesday, 6 December
2023 at 14:50 To: TLS@ietf.org <mailto: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/2
Christian:
>>>
>>> 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.
>> As stated in draft
able 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 priv
John:
>
> 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.
Thanks for getting back to me on this.
Russ___
TLS mailing list
TL
0:08
To: John Mattsson
Cc: IETF TLS
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.ie
RFC 8773 S3:
> In the near term, this document describes a TLS 1.3 extension to
protect today's communications from the future invention of a
large-scale quantum computer by providing a strong external PSK as an
input to the TLS 1.3 key schedule while preserving the authentication
provided by
>
> Date: Wednesday, 6 December 2023 at 21:51
> To: John Mattsson <mailto:john.matts...@ericsson.com>>
> Cc: IETF TLS mailto:tls@ietf.org>>
> Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
>
> John:
>
> I respond to your three
ways get PFS.
Cheers,
John Preuß Mattsson
From: Russ Housley
Date: Wednesday, 6 December 2023 at 21:51
To: John Mattsson
Cc: IETF TLS
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 &
; on
behalf of Dan Harkins mailto:dhark...@lounge.org>> Date: Wednesday, 6 December 2023 at
14:50 To: TLS@ietf.org <mailto: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 stan
>>> 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 p
On 12/6/2023 10:59 AM, Russ Housley wrote:
Christian:
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
enoug
unge.org>> Date: Wednesday, 6 December 2023 at
14:50 To: TLS@ietf.org <mailto: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.
gt; John Preuß Mattsson
>
> [1]
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ
>
> From: TLS mailto:tls-boun...@ietf.org>> on behalf of
> Dan Harkins mailto:dhark...@lounge.org>>
> Date: Wednesday, 6 December 2023 at 14
Christian:
>
> 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.
As stated in draft-ietf-tls-877
.
Cheers,
John Preuß Mattsson
[1]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ
From: TLS on behalf of Dan Harkins
Date: Wednesday, 6 December 2023 at 14:50
To: TLS@ietf.org
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
Hi
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
On Tue, Dec 05, 2023 at 06:24:33PM -0800, Christian Huitema wrote:
>
> 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, the
On 12/5/2023 10:56 AM, Russ Housley wrote:
On Dec 5, 2023, at 12:01 PM, Christian Huitema 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
> On Dec 5, 2023, at 12:01 PM, Christian Huitema 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 S
Thanks. This is interesting, but I think we should have a higher standard
than informal reasoning.
We know that there have been challenges around the composition of PSK and
certificates in the past (see Appendix E.1 of RFC 8446), so I think that's
especially true in this case.
-Ekr
On Tue, Dec
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 ex
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 ext
+1
Reading RFC 8773, I feel at least a tension and maybe a contradiction
between the stated motivation, resisting to quantum analysis by
combining an [EC]DH derived secret and a PSK, and the use of the PSK
alone to derive the early secret. If the early secret is used for 0-RTT,
then the adver
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
Whoops wrong one, strike that
On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly
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 wrote:
>
>> What do we have in terms of formal analysis for this extension?
>>
>> -E
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 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 wrote:
>
>> I think this should move forwa
What do we have in terms of formal analysis for this extension?
-Ekr
On Fri, Dec 1, 2023 at 11:40 AM Russ Housley 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, Jos
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 wrote:
>
> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an
> External Pre-Shared Key) was ori
* 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… Please indicate if you approve of or object to this
transition to standards track status by December 15, 2023.
I supp
Hi,
Approve.
Cheers,
- Ira
On Wed, Nov 29, 2023 at 10: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 fo
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 impleme
41 matches
Mail list logo
