date:20231205

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

2023-12-05 Thread John Mattsson

Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
needed to have.  I already asked for that in
https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/

In addition, I would also like to information if the cipher suite can be used 
in QUIC.

(It is very hard for someone to find out which cipher suites are usable for TLS 
1.3, DTLS 1.3, and QUIC)

Cheers,
John

From: TLS  on behalf of Salz, Rich 

Date: Thursday, 20 April 2023 at 21:17
To: tls@ietf.org 
Subject: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?
I’m starting to write the draft about TLS 1.2 being frozen.

It occurred to me that every TLS registry might need a “notes” column.  If 
someone defines a new crypto algorithm, sat AEGIS being considered in CFRG, we 
want to assign it a number but have a note saying “only for TLS 1.3 and later”
We could make it be a simple yes/no column, like “Pre-1.3?” but I think that’s 
needlessly terse.

Does that make sense?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-05 Thread Deirdre Connolly

At the TLS meeting at IETF 118 there was significant support for the draft
'TLS 1.2 is in Feature Freeze' (
https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
is to confirm this on the list.  Please indicate if you support the
adoption of this draft and are willing to review and contribute text. If
you do not support adoption of this draft please indicate why.  This call
will close on December 20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-05 Thread Christian Huitema

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 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 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 mailto:durumcrustu...@gmail.com>> wrote:

Whoops wrong one, strike that

On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 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 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 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 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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-05 Thread Russ Housley



> 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 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  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 >> > wrote:
 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?
>> 
>> -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, 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
>> 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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-05 Thread Eric Rescorla

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 5, 2023 at 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.
>
> 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  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 
> wrote:
>
>> 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?

 -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, 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
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-05 Thread Christian Huitema

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 wrote:

To respond directly to the call: I think we should require some level of formal
analysis for this kind of extension.

-Ekr

On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly mailto:durumcrustu...@gmail.com>> wrote:

Whoops wrong one, strike that

On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 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 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 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 mailto:j...@salowey.net>> wrote:

Thanks,

Joe, Sean, and Deirdre

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-05 Thread Russ Housley

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.

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  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  > wrote:
>> 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?
 
 -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, 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
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

[TLS] Adoption call for 'TLS 1.2 Feature Freeze'

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

7 matches

Site Navigation

Mail list logo

Footer information