Re: [TLS] Working Group Last Call for SSLKEYLOG File

[Yaakov Stein]

This document does a good job of documenting current practice,
and hence I support
(and my thanks to Martin for addressing an issue I communicated to him
off-list).

I think that timestamping and/or autosegmenting entries in the file format
would be a useful extension
(current implementations, such as Wireshark, need to linearly search
through potentially large SSLKEYLOG files).

Y(J)S (usually just lurking on this list)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Raghu Saxena]

On 3/13/24 14:51, Watson Ladd wrote:

The reason the public_name exists is so that the connections can all
have the same SNI field. Since we can't do what ESNI did, there must
be something there and it should all be the same.


Could you elaborate a bit on this? Sorry I'm unfamiliar with some design 
decisions, but why connections all need to have the same SNI field 
instead of just excluding it altogether, i.e. what ESNI did?



I'm not sure what problem you want us to solve here. In the case of
server offering a single domain, an attacker can determine that
connections to that domain go to the server and cheaply block based on
IP. As a result the threat model is one of distinguishing between
connections to two different inner names.


An IP can be cheaply recycled as well, for instance restarting a VPS on 
a cloud provider. Furthermore, IP based blocking may even be discouraged 
at a higher level, for the exact reason that IPs can change pretty 
easily. As an operator, I might be able to migrate my hosting to a new 
server provider (and hence IP) trivially, but informing my users of a 
domain change is much harder.



DNS does not propagate atomically with webserver configuration
changes. It's thus necessary to deal with mismatches.
While this is true, if there is a configuration mismatch (and hence ECH 
cannot work), why is the decision made for the server to transparently 
"downgrade" it to non-ECH, instead of sending some kind of alert that 
signifies the client to retry without ECH?


Regards,

Raghu Saxena



OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[John Mattsson]

Hi,

   "ECH is not in itself sufficient to protect the identity of the
   server.  The target domain may also be visible through other
   channels, such as plaintext client DNS queries or visible server IP
   addresses.  However, DoH [RFC8484] and DPRIVE [RFC7858] [RFC8094]
   provide mechanisms for clients to conceal DNS lookups from network
   inspection, and many TLS servers host multiple domains on the same IP
   address.  Private origins may also be deployed behind a common
   provider, such as a reverse proxy.  In such environments, the SNI
   remains the primary explicit signal used to determine the server's
   identity."

This text only discusses that the identity of the server may be revealed by
"other channels". I strongly think the document needs to mention that the
identity of the server may also be reveled by the unencrypted information
in the ServerHello. In particular a reused KeyShare is problematic.

Suggested addition:

The identity of the server may also be reveled by the unencrypted information
in the ServerHello. Most of the current information in ServerHello is not 
unique.
The exception is KeyShare, which if reused provides a unique identifier of the 
server.

Cheers,
John Preuß Mattsson
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Karthikeyan Bhargavan]

> Hopefully, some of the people who did the analyses will
> chime in on the WGLC though, it'd be good if they had the
> time to do that.

I am not sure this specific case was covered in our analysis, but I will confer 
with our co-authors.

Best,
Karthik


> 
> Cheers,
> S.
> 
>> thanks,
>> Rob
>> On Mon, Mar 11, 2024 at 6:12 PM Stephen Farrell 
>> wrote:
>>> 
>>> 
>>> On 12/03/2024 00:49, Rob Sayre wrote:
 On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton <
>>> cpat...@cloudflare.com>
 wrote:
 
> I don't believe there were any changes from draft 13 to 18 that would
> invalidate security analysis for draft 13:
> 
> 
>>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-13&url2=draft-ietf-tls-esni-18&difftype=--html
> 
 
 Hmm. It does look like there are few substantial changes in that diff
>>> that
 might be worth re-checking, but I'm not trying to delay things with
 nitpicking. If others feel the analysis of -13 is enough, then let's go.
>>> 
>>> Not quite answering the question, but I don't recall any code
>>> changes affecting the crypto plumbing or interop since -13.
>>> 
>>> Cheers,
>>> S.
>>> 
 
 thanks,
 Rob
 
 
 ___
 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] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena  wrote:

> On 3/13/24 14:51, Watson Ladd wrote:
>
> > I'm not sure what problem you want us to solve here. In the case of
> > server offering a single domain, an attacker can determine that
> > connections to that domain go to the server and cheaply block based on
> > IP. As a result the threat model is one of distinguishing between
> > connections to two different inner names.
>
> An IP can be cheaply recycled as well, for instance restarting a VPS on
> a cloud provider. Furthermore, IP based blocking may even be discouraged
> at a higher level, for the exact reason that IPs can change pretty
> easily. As an operator, I might be able to migrate my hosting to a new
> server provider (and hence IP) trivially, but informing my users of a
> domain change is much harder.
>

Yes, but the attacker can easily learn these IPs merely by querying
the DNS. Moreover, they can learn the associated domains by sending
a CH with no SNI at all and seeing what's in the certificate.


> DNS does not propagate atomically with webserver configuration
> > changes. It's thus necessary to deal with mismatches.
> While this is true, if there is a configuration mismatch (and hence ECH
> cannot work), why is the decision made for the server to transparently
> "downgrade" it to non-ECH, instead of sending some kind of alert that
> signifies the client to retry without ECH?
>

Three reasons:

1. Such an alert would be insecure because an attacker could forge it,
thus causing the client to send ECH in the clear.

2. It allows the server to be completely ECH unaware rather than needing
to special case an ECH alert.

3. It allows the server to securely provide a new ECHConfig.

-Ekr



> Regards,
>
> Raghu Saxena
>
> ___
> 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] Working Group Last Call for ECH

[Amir Omidi]

I'd like to understand how the behavior of the latest draft will be under
an adversarial condition.

One of the things that really excited me about ESNI back in the day was
effectively making it near impossible for countries, like my home country
Iran, from being able to effectively censor the web. AFAIK Iran's main
censorship mechanism revolves around looking for ClientHello's and then
sending a TCP reset when that SNI matches a censored domain.

I'm wondering, are we losing that ability from ESNI with this plain text
field? Maybe there can be an understanding in the RFC that the client may
omit, or falsify this plaintext field for a bit of extra adversarial
security in these circumstances?

On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:

>
>
> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
> wrote:
>
>> On 3/13/24 14:51, Watson Ladd wrote:
>>
>> > I'm not sure what problem you want us to solve here. In the case of
>> > server offering a single domain, an attacker can determine that
>> > connections to that domain go to the server and cheaply block based on
>> > IP. As a result the threat model is one of distinguishing between
>> > connections to two different inner names.
>>
>> An IP can be cheaply recycled as well, for instance restarting a VPS on
>> a cloud provider. Furthermore, IP based blocking may even be discouraged
>> at a higher level, for the exact reason that IPs can change pretty
>> easily. As an operator, I might be able to migrate my hosting to a new
>> server provider (and hence IP) trivially, but informing my users of a
>> domain change is much harder.
>>
>
> Yes, but the attacker can easily learn these IPs merely by querying
> the DNS. Moreover, they can learn the associated domains by sending
> a CH with no SNI at all and seeing what's in the certificate.
>
>
> > DNS does not propagate atomically with webserver configuration
>> > changes. It's thus necessary to deal with mismatches.
>> While this is true, if there is a configuration mismatch (and hence ECH
>> cannot work), why is the decision made for the server to transparently
>> "downgrade" it to non-ECH, instead of sending some kind of alert that
>> signifies the client to retry without ECH?
>>
>
> Three reasons:
>
> 1. Such an alert would be insecure because an attacker could forge it,
> thus causing the client to send ECH in the clear.
>
> 2. It allows the server to be completely ECH unaware rather than needing
> to special case an ECH alert.
>
> 3. It allows the server to securely provide a new ECHConfig.
>
> -Ekr
>
>
>
>> Regards,
>>
>> Raghu Saxena
>>
>> ___
>> 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] Time to first byte vs time to last byte

[Ben Smyth]

On Sat, 9 Mar 2024 at 10:23, Bas Westerbaan  wrote:

> Given that especially for the web, CDNs used much higher initcwnds,
>
>
> Please, let us not assume every website is behind a CDN.
>

Isn't that assumption reasonable? At least for global websites --- without
CDN performance sucks.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

[Blumenthal, Uri - 0553 - MITLL]

 

On Sat, 9 Mar 2024 at 10:23, Bas Westerbaan 
 wrote:

Given that especially for the web, CDNs used much higher initcwnds,

 

Please, let us not assume every website is behind a CDN. 

 

Isn't that assumption reasonable? At least for global websites --- without CDN 
performance sucks.

 

Of course it isn’t. 

Though this probably was a troll, and I shouldn’t bite… 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[A A]

I think we should change outer SNI randomly and periodicity (e.g 1 hours), if it change fast enough, censor will need to pay a price to block it,13.03.2024, 23:40, "Amir Omidi" :I'd like to understand how the behavior of the latest draft will be under an adversarial condition.One of the things that really excited me about ESNI back in the day was effectively making it near impossible for countries, like my home country Iran, from being able to effectively censor the web. AFAIK Iran's main censorship mechanism revolves around looking for ClientHello's and then sending a TCP reset when that SNI matches a censored domain.I'm wondering, are we losing that ability from ESNI with this plain text field? Maybe there can be an understanding in the RFC that the client may omit, or falsify this plaintext field for a bit of extra adversarial security in these circumstances?On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena  wrote:On 3/13/24 14:51, Watson Ladd wrote:
> I'm not sure what problem you want us to solve here. In the case of
> server offering a single domain, an attacker can determine that
> connections to that domain go to the server and cheaply block based on
> IP. As a result the threat model is one of distinguishing between
> connections to two different inner names.

An IP can be cheaply recycled as well, for instance restarting a VPS on 
a cloud provider. Furthermore, IP based blocking may even be discouraged 
at a higher level, for the exact reason that IPs can change pretty 
easily. As an operator, I might be able to migrate my hosting to a new 
server provider (and hence IP) trivially, but informing my users of a 
domain change is much harder.Yes, but the attacker can easily learn these IPs merely by queryingthe DNS. Moreover, they can learn the associated domains by sendinga CH with no SNI at all and seeing what's in the certificate. 
> DNS does not propagate atomically with webserver configuration
> changes. It's thus necessary to deal with mismatches.
While this is true, if there is a configuration mismatch (and hence ECH 
cannot work), why is the decision made for the server to transparently 
"downgrade" it to non-ECH, instead of sending some kind of alert that 
signifies the client to retry without ECH?Three reasons:1. Such an alert would be insecure because an attacker could forge it,thus causing the client to send ECH in the clear.2. It allows the server to be completely ECH unaware rather than needingto special case an ECH alert.3. It allows the server to securely provide a new ECHConfig.-Ekr

Regards,

Raghu Saxena

___
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 listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 8:40 AM Amir Omidi  wrote:

> I'd like to understand how the behavior of the latest draft will be under
> an adversarial condition.
>
> One of the things that really excited me about ESNI back in the day was
> effectively making it near impossible for countries, like my home country
> Iran, from being able to effectively censor the web. AFAIK Iran's main
> censorship mechanism revolves around looking for ClientHello's and then
> sending a TCP reset when that SNI matches a censored domain.
>
> I'm wondering, are we losing that ability from ESNI with this plain text
> field? Maybe there can be an understanding in the RFC that the client may
> omit, or falsify this plaintext field for a bit of extra adversarial
> security in these circumstances?
>

I don't think it's realistic for a generic client (e.g., a standard
browser) to omit or falsify this field.

The public_name is necessary to make the recovery mechanism defined in S
6.1.6. It may be the case that there are servers that only have one
identity --  though as both Watson and I noted, ECH doesn't provide much
value in those cases -- and not care about recovery, but there is no way
for the client to know that. With that said, I don't think that anything
prevents a server from placing a non-registrable value (e.g.,
`esni.invalid`) in `public_name`, which has roughly the same impact if
people converge on a small number of such names. [0]

-Ekr

[0] The value must be non-registrable -- or at least controlled by the
server -- otherwise an attacker might register it and obtain a valid
certificate, thus initiating the 6.1.6 recovery mechanism.


> On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
>> wrote:
>>
>>> On 3/13/24 14:51, Watson Ladd wrote:
>>>
>>> > I'm not sure what problem you want us to solve here. In the case of
>>> > server offering a single domain, an attacker can determine that
>>> > connections to that domain go to the server and cheaply block based on
>>> > IP. As a result the threat model is one of distinguishing between
>>> > connections to two different inner names.
>>>
>>> An IP can be cheaply recycled as well, for instance restarting a VPS on
>>> a cloud provider. Furthermore, IP based blocking may even be discouraged
>>> at a higher level, for the exact reason that IPs can change pretty
>>> easily. As an operator, I might be able to migrate my hosting to a new
>>> server provider (and hence IP) trivially, but informing my users of a
>>> domain change is much harder.
>>>
>>
>> Yes, but the attacker can easily learn these IPs merely by querying
>> the DNS. Moreover, they can learn the associated domains by sending
>> a CH with no SNI at all and seeing what's in the certificate.
>>
>>
>> > DNS does not propagate atomically with webserver configuration
>>> > changes. It's thus necessary to deal with mismatches.
>>> While this is true, if there is a configuration mismatch (and hence ECH
>>> cannot work), why is the decision made for the server to transparently
>>> "downgrade" it to non-ECH, instead of sending some kind of alert that
>>> signifies the client to retry without ECH?
>>>
>>
>> Three reasons:
>>
>> 1. Such an alert would be insecure because an attacker could forge it,
>> thus causing the client to send ECH in the clear.
>>
>> 2. It allows the server to be completely ECH unaware rather than needing
>> to special case an ECH alert.
>>
>> 3. It allows the server to securely provide a new ECHConfig.
>>
>> -Ekr
>>
>>
>>
>>> Regards,
>>>
>>> Raghu Saxena
>>>
>>> ___
>>> 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] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 8:49 AM A A  wrote:

> I think we should change outer SNI randomly and periodicity (e.g 1 hours),
> if it change fast enough, censor will need to pay a price to block it,
>

This won't work because the public_name is part of the recovery mechanism
for misconfiguration, which means that the server needs to have a valid
certificate with that identity.

-Ekr


>
> 13.03.2024, 23:40, "Amir Omidi" :
>
> I'd like to understand how the behavior of the latest draft will be under
> an adversarial condition.
>
> One of the things that really excited me about ESNI back in the day was
> effectively making it near impossible for countries, like my home country
> Iran, from being able to effectively censor the web. AFAIK Iran's main
> censorship mechanism revolves around looking for ClientHello's and then
> sending a TCP reset when that SNI matches a censored domain.
>
> I'm wondering, are we losing that ability from ESNI with this plain text
> field? Maybe there can be an understanding in the RFC that the client may
> omit, or falsify this plaintext field for a bit of extra adversarial
> security in these circumstances?
>
> On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:
>
>
>
> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
> wrote:
>
> On 3/13/24 14:51, Watson Ladd wrote:
>
> > I'm not sure what problem you want us to solve here. In the case of
> > server offering a single domain, an attacker can determine that
> > connections to that domain go to the server and cheaply block based on
> > IP. As a result the threat model is one of distinguishing between
> > connections to two different inner names.
>
> An IP can be cheaply recycled as well, for instance restarting a VPS on
> a cloud provider. Furthermore, IP based blocking may even be discouraged
> at a higher level, for the exact reason that IPs can change pretty
> easily. As an operator, I might be able to migrate my hosting to a new
> server provider (and hence IP) trivially, but informing my users of a
> domain change is much harder.
>
>
> Yes, but the attacker can easily learn these IPs merely by querying
> the DNS. Moreover, they can learn the associated domains by sending
> a CH with no SNI at all and seeing what's in the certificate.
>
>
> > DNS does not propagate atomically with webserver configuration
> > changes. It's thus necessary to deal with mismatches.
> While this is true, if there is a configuration mismatch (and hence ECH
> cannot work), why is the decision made for the server to transparently
> "downgrade" it to non-ECH, instead of sending some kind of alert that
> signifies the client to retry without ECH?
>
>
> Three reasons:
>
> 1. Such an alert would be insecure because an attacker could forge it,
> thus causing the client to send ECH in the clear.
>
> 2. It allows the server to be completely ECH unaware rather than needing
> to special case an ECH alert.
>
> 3. It allows the server to securely provide a new ECHConfig.
>
> -Ekr
>
>
>
> Regards,
>
> Raghu Saxena
>
> ___
> 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Amir Omidi]

> I don't think it's realistic for a generic client (e.g., a standard
browser) to omit or falsify this field.

Why not? From my understanding the issue that happens in this situation is
that the website becomes less reliable for these TLS clients?

If so, let that be a problem for the client to deal with. All this change
would do is something in security considerations along the lines of "to
make this protocol more censorship resistant, a TLS client MAY choose to
omit, or randomly generate the contents of `public_name`. A TLS Server
SHOULD handle these situations gracefully, and not actively reject the
client".

I do not like the idea of saying "some website can choose to do this". In
practice, very few websites will go down that route.

Are there any concerns if this approach is used?

On Wed, Mar 13, 2024 at 12:03 PM Eric Rescorla  wrote:

>
>
> On Wed, Mar 13, 2024 at 8:49 AM A A  wrote:
>
>> I think we should change outer SNI randomly and periodicity (e.g 1
>> hours), if it change fast enough, censor will need to pay a price to block
>> it,
>>
>
> This won't work because the public_name is part of the recovery mechanism
> for misconfiguration, which means that the server needs to have a valid
> certificate with that identity.
>
> -Ekr
>
>
>>
>> 13.03.2024, 23:40, "Amir Omidi" :
>>
>> I'd like to understand how the behavior of the latest draft will be under
>> an adversarial condition.
>>
>> One of the things that really excited me about ESNI back in the day was
>> effectively making it near impossible for countries, like my home country
>> Iran, from being able to effectively censor the web. AFAIK Iran's main
>> censorship mechanism revolves around looking for ClientHello's and then
>> sending a TCP reset when that SNI matches a censored domain.
>>
>> I'm wondering, are we losing that ability from ESNI with this plain text
>> field? Maybe there can be an understanding in the RFC that the client may
>> omit, or falsify this plaintext field for a bit of extra adversarial
>> security in these circumstances?
>>
>> On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:
>>
>>
>>
>> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
>> wrote:
>>
>> On 3/13/24 14:51, Watson Ladd wrote:
>>
>> > I'm not sure what problem you want us to solve here. In the case of
>> > server offering a single domain, an attacker can determine that
>> > connections to that domain go to the server and cheaply block based on
>> > IP. As a result the threat model is one of distinguishing between
>> > connections to two different inner names.
>>
>> An IP can be cheaply recycled as well, for instance restarting a VPS on
>> a cloud provider. Furthermore, IP based blocking may even be discouraged
>> at a higher level, for the exact reason that IPs can change pretty
>> easily. As an operator, I might be able to migrate my hosting to a new
>> server provider (and hence IP) trivially, but informing my users of a
>> domain change is much harder.
>>
>>
>> Yes, but the attacker can easily learn these IPs merely by querying
>> the DNS. Moreover, they can learn the associated domains by sending
>> a CH with no SNI at all and seeing what's in the certificate.
>>
>>
>> > DNS does not propagate atomically with webserver configuration
>> > changes. It's thus necessary to deal with mismatches.
>> While this is true, if there is a configuration mismatch (and hence ECH
>> cannot work), why is the decision made for the server to transparently
>> "downgrade" it to non-ECH, instead of sending some kind of alert that
>> signifies the client to retry without ECH?
>>
>>
>> Three reasons:
>>
>> 1. Such an alert would be insecure because an attacker could forge it,
>> thus causing the client to send ECH in the clear.
>>
>> 2. It allows the server to be completely ECH unaware rather than needing
>> to special case an ECH alert.
>>
>> 3. It allows the server to securely provide a new ECHConfig.
>>
>> -Ekr
>>
>>
>>
>> Regards,
>>
>> Raghu Saxena
>>
>> ___
>> 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
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Wed, Mar 13, 2024 at 9:20 AM Amir Omidi  wrote:

> > I don't think it's realistic for a generic client (e.g., a standard
> browser) to omit or falsify this field.
>
> Why not? From my understanding the issue that happens in this situation is
> that the website becomes less reliable for these TLS clients?
>
> If so, let that be a problem for the client to deal with. All this change
> would do is something in security considerations along the lines of "to
> make this protocol more censorship resistant, a TLS client MAY choose to
> omit, or randomly generate the contents of `public_name`. A TLS Server
> SHOULD handle these situations gracefully, and not actively reject the
> client".
>

But this will actually cause hard failures for any server which shares an
IP.


I do not like the idea of saying "some website can choose to do this". In
> practice, very few websites will go down that route.
>

Yes, because it's not of benefit for websites which share an IP.



> Are there any concerns if this approach is used?
>

There are two questions here:

1. What the specification says
2. What implementations choose to do within the envelope of that
specification.

The specification needs to prescribe a set of behaviors that promote
interoperability, which means that whatever it tells the client to do must
be compatible with what it tells servers to do. Presently, the
specification tells clients to put whatever is in ECHConfig.public_name in
ClientHelloOuter.sni (S 6.1) and tells the server that it may check and
reject it otherwise (S 7.1). We extensively debated whether to forbid
checking in PR #575 and concluded that we should do so. The primary
arguments were the same ones being offered here balanced against the
ecosystem benefits of encouraging the client to correctly populate
ClientHelloOuter.sni to enable the  recovery mechanism. The WG could of
course revisit that decision.

With that said, even if the specification explicitly allowed clients to
omit/falsify ClientHelloOuter.sni, I don't believe that generic clients
(e.g., the kind of Web browsers that most people use) would choose to do
so. The reason is that, as noted above, it would break the recovery
mechanism, and that's more important than the modest increment in
concealing the public_name of servers on non-shared IPs. One might imagine
that some special purpose clients would choose to do so, but that's not the
case I'm talking about.

-Ekr


> On Wed, Mar 13, 2024 at 12:03 PM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Mar 13, 2024 at 8:49 AM A A  wrote:
>>
>>> I think we should change outer SNI randomly and periodicity (e.g 1
>>> hours), if it change fast enough, censor will need to pay a price to block
>>> it,
>>>
>>
>> This won't work because the public_name is part of the recovery mechanism
>> for misconfiguration, which means that the server needs to have a valid
>> certificate with that identity.
>>
>> -Ekr
>>
>>
>>>
>>> 13.03.2024, 23:40, "Amir Omidi" :
>>>
>>> I'd like to understand how the behavior of the latest draft will be
>>> under an adversarial condition.
>>>
>>> One of the things that really excited me about ESNI back in the day was
>>> effectively making it near impossible for countries, like my home country
>>> Iran, from being able to effectively censor the web. AFAIK Iran's main
>>> censorship mechanism revolves around looking for ClientHello's and then
>>> sending a TCP reset when that SNI matches a censored domain.
>>>
>>> I'm wondering, are we losing that ability from ESNI with this plain text
>>> field? Maybe there can be an understanding in the RFC that the client may
>>> omit, or falsify this plaintext field for a bit of extra adversarial
>>> security in these circumstances?
>>>
>>> On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla  wrote:
>>>
>>>
>>>
>>> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena 
>>> wrote:
>>>
>>> On 3/13/24 14:51, Watson Ladd wrote:
>>>
>>> > I'm not sure what problem you want us to solve here. In the case of
>>> > server offering a single domain, an attacker can determine that
>>> > connections to that domain go to the server and cheaply block based on
>>> > IP. As a result the threat model is one of distinguishing between
>>> > connections to two different inner names.
>>>
>>> An IP can be cheaply recycled as well, for instance restarting a VPS on
>>> a cloud provider. Furthermore, IP based blocking may even be discouraged
>>> at a higher level, for the exact reason that IPs can change pretty
>>> easily. As an operator, I might be able to migrate my hosting to a new
>>> server provider (and hence IP) trivially, but informing my users of a
>>> domain change is much harder.
>>>
>>>
>>> Yes, but the attacker can easily learn these IPs merely by querying
>>> the DNS. Moreover, they can learn the associated domains by sending
>>> a CH with no SNI at all and seeing what's in the certificate.
>>>
>>>
>>> > DNS does not propagate atomically with webserver configuration
>>> > changes. It's thus necessary to deal with 

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Rebecca Guthrie]

Greetings Deirdre and TLS,



I read through draft-connolly-tls-mlkem-key-agreement-00 (and 
https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
 and I have a few comments. First, though, I want to say thank you for writing 
this draft. I'll echo some of what has already been voiced on this thread and 
say that, while some plan to use composite key establishment, it makes sense to 
also specify the use of standalone ML-KEM in TLS 1.3 as another option. Other 
WGs (lamps and ipsecme) have already begun to specify the use of standalone 
FIPS 203, 204, and 205 in various protocols. With respect to this draft, there 
is certainly interest from National Security System vendors in using standalone 
ML-KEM-1024 in TLS 1.3 for CNSA 2.0 compliance (as CNSA 2.0 does not require 
nor recommend hybrid solutions for security).



A few specific comments:



1. In Section 1.1 (or Introduction - Motivation in the github version), I would 
suggest that the second sentence ("Having a fully post-quantum...") is not 
needed, i.e. that there need not be a justification for why it is necessary to 
specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be appropriate to 
contextualize the specification of ML-KEM w.r.t the advent of a CRQC, though I 
also don't think that is necessary. As an example, we can compare to the 
Introduction in draft-ietf-lamps-cms-kyber-03.



2. Section 3 (Construction on github) currently reads, "We align with [hybrid] 
except that instead of joining ECDH options with a KEM, we just have the KEM as 
a NamedGroup." I think it is a more useful framing to base this specification 
(for the use of a standalone algorithm) off of RFC 8446 instead of the draft 
spec for a hybrid solution. I understand wanting to align the approach with the 
approach taken for the hybrid solution, but I don't think that fact needs to be 
explicitly documented in this draft. When this draft is standardized, I think 
it's important that it is able to be read, understood, and implemented without 
needing to refer to the hybrid draft. It could be stated (how it is in the 
hybrid draft), "ML-KEM-512 (if included), ML-KEM-768, and ML-KEM-1024 are 
represented as a NamedGroup and sent in the supported_groups extension."



3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the phrase 
"groups" to refer to key exchange algorithms -- for example, the 
supported_groups extension -- since all key exchange algorithms in TLS 1.3 are 
Diffie-Hellman-based.  As a result, some parts of this document will refer to 
data structures or messages with the term "group" in them despite using a key 
exchange algorithm that is not Diffie-Hellman-based nor a group."

This seems okay, but on the IANA registry for TLS Supported Groups, it 
indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511 are 
for FFDH groups. Where does ML-KEM fit in? Do ranges need to be re-evaluated? 
As an example, for IKEv2, RFC 9370 changes the name of Transform Type 4 from 
Diffie-Hellman Group to Key Exchange Method in order to accommodate QR KEMs.



4. In the Discussion section (on github), does the portion on failures need to 
contain more information about how a failure should be handled in TLS? Should a 
decrypt_error alert be sent?



5. In Section 4 (or Security Considerations on github), this may be a silly 
question, but is the definition of "commits" well-understood (in the first 
sentence on datatracker; in the first sentence of Binding properties on 
github)? It is not used in RFC 8446 so it might be worth explaining the meaning 
or using different phrasing in this sentence.



Also, what are the WG's thoughts on including standalone PQC signatures in the 
same draft?



Thanks in advance!



Rebecca

Rebecca Guthrie
she/her
Center for Cybersecurity Standards (CCSS)
Cybersecurity Collaboration Center (CCC)
National Security Agency (NSA)

From: TLS  On Behalf Of Deirdre Connolly
Sent: Tuesday, March 5, 2024 9:15 PM
To: TLS@ietf.org
Subject: [TLS] ML-KEM key agreement for TLS 1.3

I have uploaded a preliminary version of ML-KEM for TLS 
1.3  
and have a more fleshed 
out version to be 
uploaded when datatracker opens. It is a straightforward new `NamedGroup` to 
support key agreement via ML-KEM-768 or ML-KEM-1024, in a very similar style to 
-hybrid-design.

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.

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

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

Also, what are the WG's thoughts on including standalone PQC signatures in the 
same draft?

 

I think that including standalone PQC sigs would be very desirable.

 

 

From: TLS  On Behalf Of Deirdre Connolly
Sent: Tuesday, March 5, 2024 9:15 PM
To: TLS@ietf.org
Subject: [TLS] ML-KEM key agreement for TLS 1.3

 

I have uploaded a preliminary version of ML-KEM for TLS 1.3  and have a more 
fleshed out version to be uploaded when datatracker opens. It is a 
straightforward new `NamedGroup` to support key agreement via ML-KEM-768 or 
ML-KEM-1024, in a very similar style to -hybrid-design.

 

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.

 

Cheers,

Deirdre



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Wed, Mar 13, 2024 at 3:07 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> I think that including standalone PQC sigs would be very desirable.
>

I don't think there is any particular reason to include PQC signatures in
the same draft as PQ key establishment. In TLS 1.3, key establishment and
signature are orthogonal concepts, and it will be easier to review if they
are kept in separate documents.

-Ekr


>
>
>
> *From:* TLS  *On Behalf Of *Deirdre Connolly
> *Sent:* Tuesday, March 5, 2024 9:15 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>
>
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
>
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
>
>
> Cheers,
>
> 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

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

[Ben Smyth]

> Given that especially for the web, CDNs used much higher initcwnds,
>
> Please, let us not assume every website is behind a CDN.
>
> Isn't that assumption reasonable? At least for global websites --- without
> CDN performance sucks.
>
> *Of course* it isn’t.
>

As a reference point:

Consider reading the New York Times in Canberra,

doesn't happen without CDN

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

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie  wrote:

> Greetings Deirdre and TLS,
>
>
>
> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
> and I have a few comments. First, though, I want to say thank you for
> writing this draft. I'll echo some of what has already been voiced on this
> thread and say that, while some plan to use composite key establishment, it
> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
> another option. Other WGs (lamps and ipsecme) have already begun to specify
> the use of standalone FIPS 203, 204, and 205 in various protocols. With
> respect to this draft, there is certainly interest from National Security
> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
> security).
>

I wanted to address this CNSA 2.0 point, as I've now seen it brought up a
couple of times.

The IETF, together with the IRTF, needs to make an independent judgement on
whether using PQ-only algorithms is advisable, and if we do not think so,
then we should not standardize them, regardless of what CNSA 2.0 requires.
The supported groups registry policies are designed explicitly to allow
people to register non Standards Track algorithms, so nothing precludes the
creation of an ML-KEM only code point if some vendors find that necessary,
without the IETF standardizing them or marking them as Recommended=Y.
-Ekr




>
> A few specific comments:
>
>
>
> 1. In Section 1.1 (or Introduction - Motivation in the github version), I
> would suggest that the second sentence ("Having a fully post-quantum...")
> is not needed, i.e. that there need not be a justification for why it is
> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
> appropriate to contextualize the specification of ML-KEM w.r.t the advent
> of a CRQC, though I also don't think that is necessary. As an example, we
> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.
>
>
>
> 2. Section 3 (Construction on github) currently reads, "We align with
> [hybrid] except that instead of joining ECDH options with a KEM, we just
> have the KEM as a NamedGroup." I think it is a more useful framing to base
> this specification (for the use of a standalone algorithm) off of RFC 8446
> instead of the draft spec for a hybrid solution. I understand wanting to
> align the approach with the approach taken for the hybrid solution, but I
> don't think that fact needs to be explicitly documented in this draft. When
> this draft is standardized, I think it's important that it is able to be
> read, understood, and implemented without needing to refer to the hybrid
> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
> included), ML-KEM-768, and ML-KEM-1024 are represented as a NamedGroup and
> sent in the supported_groups extension."
>
>
>
> 3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the
> phrase "groups" to refer to key exchange algorithms -- for example, the
> supported_groups extension -- since all key exchange algorithms in TLS 1.3
> are Diffie-Hellman-based.  As a result, some parts of this document will
> refer to data structures or messages with the term "group" in them despite
> using a key exchange algorithm that is not Diffie-Hellman-based nor a
> group."
>
> This seems okay, but on the IANA registry for TLS Supported Groups, it
> indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511
> are for FFDH groups. Where does ML-KEM fit in? Do ranges need to be
> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of
> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order
> to accommodate QR KEMs.
>
>
>
> 4. In the Discussion section (on github), does the portion on failures
> need to contain more information about how a failure should be handled in
> TLS? Should a decrypt_error alert be sent?
>
>
>
> 5. In Section 4 (or Security Considerations on github), this may be a
> silly question, but is the definition of "commits" well-understood (in the
> first sentence on datatracker; in the first sentence of Binding properties
> on github)? It is not used in RFC 8446 so it might be worth explaining the
> meaning or using different phrasing in this sentence.
>
>
>
> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> Thanks in advance!
>
>
>
> Rebecca
>
>
>
> Rebecca Guthrie
>
> she/her
>
> Center for Cybersecurity Standards (CCSS)
>
> Cybersecurity Collaboration Center (CCC)
>
> National Security Agency (NSA)
>
>
>
> *From:* TLS  *On Behalf Of * Deirdre Connolly
> *Sent:* Tuesday, March 5, 2024 9:15 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>
>
>
> I have uploaded a preliminary version of ML-KEM for TLS 

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

[Rob Sayre]

On Wed, Mar 13, 2024 at 3:29 PM Ben Smyth  wrote:

>
> As a reference point:
>
> Consider reading the New York Times in Canberra,
>
> doesn't happen without CDN
>
> #SpeedOfLightSlow
>

I thought about it this way: who does the CDN connect to, and what happens
if the traffic is personalized?

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

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

Also, what are the WG's thoughts on including standalone PQC signatures in the 
same draft?

 

I think that including standalone PQC sigs would be very desirable.

 

I don't think there is any particular reason to include PQC signatures in the 
same draft as PQ key establishment. In TLS 1.3, key establishment and signature 
are orthogonal concepts, and it will be easier to review if they are kept in 
separate documents.

 

On the one hand – you’re correct. On the other hand, though, considering 
implicitly-authenticated protocols, such as MQV, HMQV etc…?

Yes I’m aware that they don’t use explicit signatures, except to validate 
certificates.

 

From: TLS  On Behalf Of Deirdre Connolly
Sent: Tuesday, March 5, 2024 9:15 PM
To: TLS@ietf.org
Subject: [TLS] ML-KEM key agreement for TLS 1.3

 

I have uploaded a preliminary version of ML-KEM for TLS 1.3  and have a more 
fleshed out version to be uploaded when datatracker opens. It is a 
straightforward new `NamedGroup` to support key agreement via ML-KEM-768 or 
ML-KEM-1024, in a very similar style to -hybrid-design.

 

It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) 
ready to go when users are ready to use them.

 

Cheers,

Deirdre

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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Eric Rescorla]

On Wed, Mar 13, 2024 at 4:10 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> I think that including standalone PQC sigs would be very desirable.
>
>
>
> I don't think there is any particular reason to include PQC signatures in
> the same draft as PQ key establishment. In TLS 1.3, key establishment and
> signature are orthogonal concepts, and it will be easier to review if they
> are kept in separate documents.
>
>
>
> On the one hand – you’re correct. On the other hand, though, considering
> implicitly-authenticated protocols, such as MQV, HMQV etc…?
>
*Yes I’m aware that they don’t use explicit signatures, except to validate
> certificates.*
>

TLS 1.3 does not support MQV or HMQV.

-Ekr


>
>
> *From:* TLS  *On Behalf Of *Deirdre Connolly
> *Sent:* Tuesday, March 5, 2024 9:15 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>
>
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
>
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
>
>
> Cheers,
>
> 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

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

[Blumenthal, Uri - 0553 - MITLL]

Please, let us not assume every website is behind a CDN. 

Isn't that assumption reasonable? At least for global websites --- without CDN 
performance sucks.

Of course it isn’t.

 

As a reference point:

 

Consider reading the New York Times in Canberra,

 

Well, if you have nothing better to do there… ;-)

 

doesn't happen without CDN

 

Of course. The whole point is not to assume every website is behind CDN. Which 
part of “every” is unclear? 

Of course there are sites behind a CDN of some kind. And there are sites that 
are not.  It is stupid unwise to ignore that.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

Agreed with ekr.

On Wed, Mar 13, 2024 at 6:27 PM Eric Rescorla  wrote:

>
>
> On Wed, Mar 13, 2024 at 3:07 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
>> Also, what are the WG's thoughts on including standalone PQC signatures
>> in the same draft?
>>
>>
>>
>> I think that including standalone PQC sigs would be very desirable.
>>
>
> I don't think there is any particular reason to include PQC signatures in
> the same draft as PQ key establishment. In TLS 1.3, key establishment and
> signature are orthogonal concepts, and it will be easier to review if they
> are kept in separate documents.
>
> -Ekr
>
>
>>
>>
>>
>> *From:* TLS  *On Behalf Of *Deirdre Connolly
>> *Sent:* Tuesday, March 5, 2024 9:15 PM
>> *To:* TLS@ietf.org
>> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>>
>>
>>
>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>> 
>> and have a more fleshed out
>>  version to
>> be uploaded when datatracker opens. It is a straightforward new
>> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
>> very similar style to -hybrid-design
>> .
>>
>>
>>
>> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
>> compatible) ready to go when users are ready to use them.
>>
>>
>>
>> Cheers,
>>
>> 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

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

Some considerations for ML-KEM alone (or another trusted PQ-only key
agreement) are mainly looking towards the desired next step after hybrid
key agreement, and instead of leaving that fuzzy and far off, talking about
it in the present. This is also motivated by -hybrid-design allowing
several traditional NamedGroups to be negotiated on their own, as hybrid
NamedGroups with ML-KEM (although currently both are specified as Kyber but
those will change), but no option to negotiate the other side of the hybrid
alone, the PQ algorithm alone, Shaking out all the negotiation decisions is
desirable as well as 'drawing the rest of the owl' for the pure PQ option
implied in the negotiation (are we going to copy the same ~1000 bytes for
the PQ and hybrid name groups, when sharing an ephemeral KEM keypair?).

For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS, but
a note that a non-trivial segment of users of standard TLS that have been
traditionally compliant will not be in a few years, and they will come
knocking anyway. This is trying to skate where the puck is going.

But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
agreement in the next ~6-9 years is a strong vote of confidence in any
protocol doing this at all, so, TLS wouldn't be out on a limb to support
this, basically.

I don't have a strong opinion on whether this should be Recommended = Y.

On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:

>
>
> On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie  40uwe.nsa@dmarc.ietf.org> wrote:
>
>> Greetings Deirdre and TLS,
>>
>>
>>
>> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
>> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
>> and I have a few comments. First, though, I want to say thank you for
>> writing this draft. I'll echo some of what has already been voiced on this
>> thread and say that, while some plan to use composite key establishment, it
>> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
>> another option. Other WGs (lamps and ipsecme) have already begun to specify
>> the use of standalone FIPS 203, 204, and 205 in various protocols. With
>> respect to this draft, there is certainly interest from National Security
>> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
>> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
>> security).
>>
>
> I wanted to address this CNSA 2.0 point, as I've now seen it brought up a
> couple of times.
>
> The IETF, together with the IRTF, needs to make an independent judgement
> on whether using PQ-only algorithms is advisable, and if we do not think
> so, then we should not standardize them, regardless of what CNSA 2.0
> requires. The supported groups registry policies are designed explicitly to
> allow people to register non Standards Track algorithms, so nothing
> precludes the creation of an ML-KEM only code point if some vendors find
> that necessary, without the IETF standardizing them or marking them as
> Recommended=Y.
> -Ekr
>
>
>
>
>>
>> A few specific comments:
>>
>>
>>
>> 1. In Section 1.1 (or Introduction - Motivation in the github version), I
>> would suggest that the second sentence ("Having a fully post-quantum...")
>> is not needed, i.e. that there need not be a justification for why it is
>> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
>> appropriate to contextualize the specification of ML-KEM w.r.t the advent
>> of a CRQC, though I also don't think that is necessary. As an example, we
>> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.
>>
>>
>>
>> 2. Section 3 (Construction on github) currently reads, "We align with
>> [hybrid] except that instead of joining ECDH options with a KEM, we just
>> have the KEM as a NamedGroup." I think it is a more useful framing to base
>> this specification (for the use of a standalone algorithm) off of RFC 8446
>> instead of the draft spec for a hybrid solution. I understand wanting to
>> align the approach with the approach taken for the hybrid solution, but I
>> don't think that fact needs to be explicitly documented in this draft. When
>> this draft is standardized, I think it's important that it is able to be
>> read, understood, and implemented without needing to refer to the hybrid
>> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
>> included), ML-KEM-768, and ML-KEM-1024 are represented as a NamedGroup and
>> sent in the supported_groups extension."
>>
>>
>>
>> 3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the
>> phrase "groups" to refer to key exchange algorithms -- for example, the
>> supported_groups extension -- since all key exchange algorithms in TLS 1.3
>> are Diffie-Hellman-based.  As a result, some parts of this document will
>> refer to data structures or messages with the term "group" in them despite
>> u

Re: [TLS] Working Group Last Call for ECH

[涛叔]

Hi, Eric,

> On Mar 14, 2024, at 00:45, Eric Rescorla  wrote:
> 
> There are two questions here:
> 
> 1. What the specification says
> 2. What implementations choose to do within the envelope of that 
> specification.
> 
> The specification needs to prescribe a set of behaviors that promote 
> interoperability, which means that whatever it tells the client to do must be 
> compatible with what it tells servers to do. Presently, the specification 
> tells clients to put whatever is in ECHConfig.public_name in 
> ClientHelloOuter.sni (S 6.1) and tells the server that it may check and 
> reject it otherwise (S 7.1). We extensively debated whether to forbid 
> checking in PR #575 and concluded that we should do so. The primary arguments 
> were the same ones being offered here balanced against the ecosystem benefits 
> of encouraging the client to correctly populate ClientHelloOuter.sni to 
> enable the  recovery mechanism. The WG could of course revisit that decision.
> 
> With that said, even if the specification explicitly allowed clients to 
> omit/falsify ClientHelloOuter.sni, I don't believe that generic clients 
> (e.g., the kind of Web browsers that most people use) would choose to do so. 
> The reason is that, as noted above, it would break the recovery mechanism, 
> and that's more important than the modest increment in concealing the 
> public_name of servers on non-shared IPs. One might imagine that some special 
> purpose clients would choose to do so, but that's not the case I'm talking 
> about.

The public_name is required, not naturally because it will be used by ECHConfig 
recovery, but because if the client
omit it or fill some none domain value like ensi.test, the observer could 
identify traffic equipped with ECH or normal
TLS traffic.

However, the problem we are discussing here is if you want to deploy ECH you 
have to own a dedicated domain name
and get a valid SSL certificate for it so that you can resend the latest 
ECHConfig to the client that use the outed configuration.
The process is only chosen by the draft. But it is not the only way to do it.

Here are some immature ideas.

One method is to public another public_key for signing along side with 
ECHConfig, let's call it Recovery Signing Key. 
This key will only be used to sign the latest ECHConfig during the recovery 
process. So there is not need to rotate it
as frequently as the ECHConfig itself. The client should use DNS to lookup the 
ECHConfig and the Recovery Signing Key.
If the ECHConfig is outdated, the server will respond the latest ECHConfig with 
signature signed the Recovery Signing Key.
By the way, the client could verify whether the recovered ECHConfig is valid.

Here is another immature ideas.

If the WG insist to use the outer TLS negotiation to recovery ECHConfig, it may 
works to use the self-signed certificate.
In order to let client trust the self-signed certificate only in the process of 
ECHConfig recovery, we can publish the hash of
the self-signed certificate along side the ECHConfig in the HTTPS RR. If the 
server need to recover the latest ECHConfig,
it can finish the outer TLS negotiation with its self-signed certificate. As 
the client already knows the server's self-signed
certificate by the DNS lookup, it can trust it once int this negotiation 
process and get the latest ECHConfig.

By this ways, the public_name in ECHConfig.public_name could not have to be a 
real domain, and there is no need to own it
or buy a SSL certificate for it. It is only an ID of ECHConfig, and just looks 
like a domain. And we can rotate it and the ECHConfig
as soon as need. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

Oh and one more consideration: hybrid brings complexity, and presenting the
pure-PQ solutions and their strictly lesser complexity (at the tradeoff of
maybe taking more risk against newer schemes no matter how good we feel
about their fundamental cryptographic foundations) is worthwhile in my
opinion.

On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly 
wrote:

> Some considerations for ML-KEM alone (or another trusted PQ-only key
> agreement) are mainly looking towards the desired next step after hybrid
> key agreement, and instead of leaving that fuzzy and far off, talking about
> it in the present. This is also motivated by -hybrid-design allowing
> several traditional NamedGroups to be negotiated on their own, as hybrid
> NamedGroups with ML-KEM (although currently both are specified as Kyber but
> those will change), but no option to negotiate the other side of the hybrid
> alone, the PQ algorithm alone, Shaking out all the negotiation decisions is
> desirable as well as 'drawing the rest of the owl' for the pure PQ option
> implied in the negotiation (are we going to copy the same ~1000 bytes for
> the PQ and hybrid name groups, when sharing an ephemeral KEM keypair?).
>
> For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS, but
> a note that a non-trivial segment of users of standard TLS that have been
> traditionally compliant will not be in a few years, and they will come
> knocking anyway. This is trying to skate where the puck is going.
>
> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
> agreement in the next ~6-9 years is a strong vote of confidence in any
> protocol doing this at all, so, TLS wouldn't be out on a limb to support
> this, basically.
>
> I don't have a strong opinion on whether this should be Recommended = Y.
>
> On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie > 40uwe.nsa@dmarc.ietf.org> wrote:
>>
>>> Greetings Deirdre and TLS,
>>>
>>>
>>>
>>> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
>>> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
>>> and I have a few comments. First, though, I want to say thank you for
>>> writing this draft. I'll echo some of what has already been voiced on this
>>> thread and say that, while some plan to use composite key establishment, it
>>> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
>>> another option. Other WGs (lamps and ipsecme) have already begun to specify
>>> the use of standalone FIPS 203, 204, and 205 in various protocols. With
>>> respect to this draft, there is certainly interest from National Security
>>> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
>>> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
>>> security).
>>>
>>
>> I wanted to address this CNSA 2.0 point, as I've now seen it brought up a
>> couple of times.
>>
>> The IETF, together with the IRTF, needs to make an independent judgement
>> on whether using PQ-only algorithms is advisable, and if we do not think
>> so, then we should not standardize them, regardless of what CNSA 2.0
>> requires. The supported groups registry policies are designed explicitly to
>> allow people to register non Standards Track algorithms, so nothing
>> precludes the creation of an ML-KEM only code point if some vendors find
>> that necessary, without the IETF standardizing them or marking them as
>> Recommended=Y.
>> -Ekr
>>
>>
>>
>>
>>>
>>> A few specific comments:
>>>
>>>
>>>
>>> 1. In Section 1.1 (or Introduction - Motivation in the github version),
>>> I would suggest that the second sentence ("Having a fully post-quantum...")
>>> is not needed, i.e. that there need not be a justification for why it is
>>> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
>>> appropriate to contextualize the specification of ML-KEM w.r.t the advent
>>> of a CRQC, though I also don't think that is necessary. As an example, we
>>> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.
>>>
>>>
>>>
>>> 2. Section 3 (Construction on github) currently reads, "We align with
>>> [hybrid] except that instead of joining ECDH options with a KEM, we just
>>> have the KEM as a NamedGroup." I think it is a more useful framing to base
>>> this specification (for the use of a standalone algorithm) off of RFC 8446
>>> instead of the draft spec for a hybrid solution. I understand wanting to
>>> align the approach with the approach taken for the hybrid solution, but I
>>> don't think that fact needs to be explicitly documented in this draft. When
>>> this draft is standardized, I think it's important that it is able to be
>>> read, understood, and implemented without needing to refer to the hybrid
>>> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
>>> included), ML-KEM-768, and ML-KEM-1024 ar

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

Thank you very much for the notes!

A few specific comments:



> 1. In Section 1.1 (or Introduction - Motivation in the github version), I
> would suggest that the second sentence ("Having a fully post-quantum...")
> is not needed, i.e. that there need not be a justification for why it is
> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
> appropriate to contextualize the specification of ML-KEM w.r.t the advent
> of a CRQC, though I also don't think that is necessary. As an example, we
> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.


Noted, tweaked on github slightly.



> 2. Section 3 (Construction on github) currently reads, "We align with
> [hybrid] except that instead of joining ECDH options with a KEM, we just
> have the KEM as a NamedGroup." I think it is a more useful framing to base
> this specification (for the use of a standalone algorithm) off of RFC 8446
> instead of the draft spec for a hybrid solution. I understand wanting to
> align the approach with the approach taken for the hybrid solution, but I
> don't think that fact needs to be explicitly documented in this draft. When
> this draft is standardized, I think it's important that it is able to be
> read, understood, and implemented without needing to refer to the hybrid
> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
> included), ML-KEM-768, and ML-KEM-1024 are represented as a NamedGroup and
> sent in the supported_groups extension."


Good point, tweaked 👍

3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the
> phrase "groups" to refer to key exchange algorithms -- for example, the
> supported_groups extension -- since all key exchange algorithms in TLS 1.3
> are Diffie-Hellman-based.  As a result, some parts of this document will
> refer to data structures or messages with the term "group" in them despite
> using a key exchange algorithm that is not Diffie-Hellman-based nor a
> group."
> This seems okay, but on the IANA registry for TLS Supported Groups, it
> indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511
> are for FFDH groups. Where does ML-KEM fit in? Do ranges need to be
> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of
> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order
> to accommodate QR KEMs.


This is a good point: -hybrid-design allocates 0x6399 and 0x639A for the
two hybrid `NamedGroup`s so far. I don't have a strong opinion here, I
basically followed -hybrid-design's lead and picked 0x0768 and 0x1024 for
ML-KEM-768 and ML-KEM-1024.



> 4. In the Discussion section (on github), does the portion on failures
> need to contain more information about how a failure should be handled in
> TLS? Should a decrypt_error alert be sent?


Oh very good point, DH doesn't usually fail like this; either because of
fundamental (incredibly unlikely) decapsulation failure rates, or just a
bug, this is good to handle, and we should probably update -hybrid-design
to match. I've tracked this in this GitHub issue

for now. For my own sake, here's the `decode_error` defintion from RFC
8446:

decode_error:  A message could not be decoded because some field was

  out of the specified range or the length of the message was

  incorrect.  This alert is used for errors where the message does

  not conform to the formal protocol syntax.  This alert should

  never be observed in communication between proper implementations,

  except when messages were corrupted in the network.



5. In Section 4 (or Security Considerations on github), this may be a silly
> question, but is the definition of "commits" well-understood (in the first
> sentence on datatracker; in the first sentence of Binding properties on
> github)? It is not used in RFC 8446 so it might be worth explaining the
> meaning or using different phrasing in this sentence.


Noted
;
I
will either define in-line or consistently use 'bind' in the X-BIND-P-Q
sense (RFC 8446 uses 'bind' with the same colloquial sense but does not
appear to define it).

On Wed, Mar 13, 2024 at 5:36 PM Rebecca Guthrie  wrote:

> Greetings Deirdre and TLS,
>
>
>
> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
> and I have a few comments. First, though, I want to say thank you for
> writing this draft. I'll echo some of what has already been voiced on this
> thread and say that, while some plan to use composite key establishment, it
> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
> another option. Other WGs (lamps and ipsecme) have already begun to specify
> the use of standalone FIPS 203, 204, and 205 in various pro

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

[Kampanakis, Panos]

I think we are getting distracted from the point which is to consider the whole 
connection time when assessing handshake impact. Even an extra RTT due to 
initcwnd=10 becomes less and less significant when we are talking about 5+ RTTs 
to establish the conn and transfer >50KB of data.

Interestingly enough, for the example page size in question (72KB), the total 
connection time includes the same number of RTTs (assuming initcwnd=10~=15KB):
- Classical case: 1 for the TCP handshake + 1 for the TLS handshake + 3 for the 
data (15+30+27)
- PQ case: 1 for the TCP handshake + 2 for the TLS handshake + 2 for the data 
(30+42)
OK, this is just because of how 72KB aligns with the TCP congestion window 
increasing.


From: Blumenthal, Uri - 0553 - MITLL 
Sent: Wednesday, March 13, 2024 7:16 PM
To: resea...@bensmyth.com
Cc: Bas Westerbaan ; Kampanakis, Panos 
; TLS@ietf.org; Childs-Klein, Will 
Subject: RE: [EXTERNAL] [EXT] Re: [TLS] Time to first byte vs time to last byte

Please, let us not assume every website is behind a CDN.
Isn't that assumption reasonable? At least for global websites --- without CDN 
performance sucks.
Of course it isn’t.

As a reference point:

Consider reading the New York Times in Canberra,

Well, if you have nothing better to do there… ;-)

doesn't happen without CDN

Of course. The whole point is not to assume every website is behind CDN. Which 
part of “every” is unclear?
Of course there are sites behind a CDN of some kind. And there are sites that 
are not.  It is stupid unwise to ignore that.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Raghu Saxena]

On 3/14/24 00:45, Eric Rescorla wrote:

There are two questions here:

1. What the specification says
2. What implementations choose to do within the envelope of that 
specification.


The specification needs to prescribe a set of behaviors that promote 
interoperability, which means that whatever it tells the client to do 
must be compatible with what it tells servers to do. Presently, the 
specification tells clients to put whatever is in 
ECHConfig.public_name in ClientHelloOuter.sni (S 6.1) and tells the 
server that it may check and reject it otherwise (S 7.1).


So, if I understand correctly, for my domain "abc.com", I could 
purposely choose to have my ECHConfig public_name be "google.com", and 
configure my server to handle it (or ignore the SNI in outer client 
hello altogether), and a client SHOULD NOT try and cancel the ECH 
attempt on seeing that the public_name in ECHConfig does not match the 
host the user is attempting to connect to?


I guess this makes sense, since in the Cloudflare case, every ECHConfig 
advertises public_name as "cloudflare-ech.com", and the user is 
obviously connecting to a different website. In this case I guess it 
isn't as bad, since as a server operator I _could_ choose to just 
piggyback on the public_name of some popular CDN, even though I am not 
using it, to "hide" my real SNI / domain. I think this is a feasible 
workaround.


Regards,

Raghu Saxena



OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Raghu Saxena]

On 3/14/24 11:38, Raghu Saxena wrote:

I think this is a feasible workaround.


Actually I think it is almost better, since I can "fool" naive censors 
etc. into thinking users of my website are visiting "google.com" or 
something, since as a server operator I control the public_name.


Regards,

Raghu Saxena



OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls