Re: [TLS] Working Group Last Call for ECH

[Sean Turner]

Addressed via:
https://github.com/tlswg/draft-ietf-tls-esni/pull/613

spt

> On Apr 2, 2024, at 10:46, Russ Housley  wrote:
> 
> Signed PGP part
> Thanks.
> 
> This URL gives access without a paywall: 
> https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf
> 
> Russ
> 
>> On Apr 2, 2024, at 10:31 AM, Stephen Farrell  
>> wrote:
>> 
>> 
>> Hiya,
>> 
>> On 02/04/2024 15:17, Russ Housley wrote:
>>> Joe:
>>> The ECH Internet-Draft includes this reference:
>>>[ECH-Analysis]
>>>   "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
>>>   Client Hello", November 2022.
>> 
>> I'm guessing that'd be:
>> 
>> @inproceedings{bhargavan2022symbolic,
>>  title={A symbolic analysis of privacy for tls 1.3 with encrypted client 
>> hello},
>>  author={Bhargavan, Karthikeyan and Cheval, Vincent and Wood, Christopher},
>>  booktitle={Proceedings of the 2022 ACM SIGSAC Conference on Computer and 
>> Communications Security},
>>  pages={365--379},
>>  year={2022}
>> }
>> 
>> Cheers,
>> S.
>> 
>>> This reference does not provide enough information for anyone to locate the 
>>> document.  I think a reference that everyone can locate is needed here.
>>> Russ
 On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:
 
 This WGLC has concluded.  There is consensus to move this document 
 forward.  I think there are one or two minor changes proposed that should 
 be incorporated into the revision we forward to the IESG.
 
 Joe
 
 On Thu, Mar 28, 2024 at 6:23 AM Sean Turner >>> > wrote:
> Just a reminder that this WGLC ends soon!
> 
> spt
> 
>> On Mar 11, 2024, at 18:00, Joseph Salowey > > wrote:
>> 
>> This is the working group last call for TLS Encrypted Client Hello [1].  
>> Please indicate if you think the draft is ready to progress to the IESG 
>> and send any comments to the list by 31 March 2024.  The comments sent 
>> by Watson Ladd to the list [2] on 17 February 2024 will be considered 
>> last call comments.
>> 
>> Thanks,
>> 
>> Joe, Deirdre, and Sean
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
>> [2] 
>> https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>>> ___
>>> 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

[Russ Housley]

Thanks.

This URL gives access without a paywall:
https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf

Russ

> On Apr 2, 2024, at 10:31 AM, Stephen Farrell  
> wrote:
> 
> 
> Hiya,
> 
> On 02/04/2024 15:17, Russ Housley wrote:
>> Joe:
>> The ECH Internet-Draft includes this reference:
>>[ECH-Analysis]
>>   "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
>>   Client Hello", November 2022.
> 
> I'm guessing that'd be:
> 
> @inproceedings{bhargavan2022symbolic,
>  title={A symbolic analysis of privacy for tls 1.3 with encrypted client 
> hello},
>  author={Bhargavan, Karthikeyan and Cheval, Vincent and Wood, Christopher},
>  booktitle={Proceedings of the 2022 ACM SIGSAC Conference on Computer and 
> Communications Security},
>  pages={365--379},
>  year={2022}
> }
> 
> Cheers,
> S.
> 
>> This reference does not provide enough information for anyone to locate the 
>> document.  I think a reference that everyone can locate is needed here.
>> Russ
>>> On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:
>>> 
>>> This WGLC has concluded.  There is consensus to move this document forward. 
>>>  I think there are one or two minor changes proposed that should be 
>>> incorporated into the revision we forward to the IESG.
>>> 
>>> Joe
>>> 
>>> On Thu, Mar 28, 2024 at 6:23 AM Sean Turner >> > wrote:
 Just a reminder that this WGLC ends soon!
 
 spt
 
> On Mar 11, 2024, at 18:00, Joseph Salowey  > wrote:
> 
> This is the working group last call for TLS Encrypted Client Hello [1].  
> Please indicate if you think the draft is ready to progress to the IESG 
> and send any comments to the list by 31 March 2024.  The comments sent by 
> Watson Ladd to the list [2] on 17 February 2024 will be considered last 
> call comments.
> 
> Thanks,
> 
> Joe, Deirdre, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Stephen Farrell]

Hiya,

On 02/04/2024 15:17, Russ Housley wrote:

Joe:

The ECH Internet-Draft includes this reference:

[ECH-Analysis]
   "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
   Client Hello", November 2022.


I'm guessing that'd be:

@inproceedings{bhargavan2022symbolic,
  title={A symbolic analysis of privacy for tls 1.3 with encrypted 
client hello},
  author={Bhargavan, Karthikeyan and Cheval, Vincent and Wood, 
Christopher},
  booktitle={Proceedings of the 2022 ACM SIGSAC Conference on Computer 
and Communications Security},

  pages={365--379},
  year={2022}
}

Cheers,
S.



This reference does not provide enough information for anyone to locate the 
document.  I think a reference that everyone can locate is needed here.

Russ



On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:

This WGLC has concluded.  There is consensus to move this document forward.  I 
think there are one or two minor changes proposed that should be incorporated 
into the revision we forward to the IESG.

Joe

On Thu, Mar 28, 2024 at 6:23 AM Sean Turner mailto:s...@sn3rd.com>> wrote:

Just a reminder that this WGLC ends soon!

spt


On Mar 11, 2024, at 18:00, Joseph Salowey mailto:j...@salowey.net>> wrote:

This is the working group last call for TLS Encrypted Client Hello [1].  Please 
indicate if you think the draft is ready to progress to the IESG and send any 
comments to the list by 31 March 2024.  The comments sent by Watson Ladd to the 
list [2] on 17 February 2024 will be considered last call comments.

Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
[2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/



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


OpenPGP_0xE4D8E9F997A833DD.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

[Russ Housley]

Joe:

The ECH Internet-Draft includes this reference:

   [ECH-Analysis]
  "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
  Client Hello", November 2022.

This reference does not provide enough information for anyone to locate the 
document.  I think a reference that everyone can locate is needed here.

Russ


> On Apr 1, 2024, at 6:12 PM, Joseph Salowey  wrote:
> 
> This WGLC has concluded.  There is consensus to move this document forward.  
> I think there are one or two minor changes proposed that should be 
> incorporated into the revision we forward to the IESG.  
> 
> Joe
> 
> On Thu, Mar 28, 2024 at 6:23 AM Sean Turner  > wrote:
>> Just a reminder that this WGLC ends soon!
>> 
>> spt
>> 
>> > On Mar 11, 2024, at 18:00, Joseph Salowey > > > wrote:
>> > 
>> > This is the working group last call for TLS Encrypted Client Hello [1].  
>> > Please indicate if you think the draft is ready to progress to the IESG 
>> > and send any comments to the list by 31 March 2024.  The comments sent by 
>> > Watson Ladd to the list [2] on 17 February 2024 will be considered last 
>> > call comments.
>> > 
>> > Thanks,
>> > 
>> > Joe, Deirdre, and Sean
>> > 
>> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
>> > [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for ECH

[Joseph Salowey]

This WGLC has concluded.  There is consensus to move this document
forward.  I think there are one or two minor changes proposed that should
be incorporated into the revision we forward to the IESG.

Joe

On Thu, Mar 28, 2024 at 6:23 AM Sean Turner  wrote:

> Just a reminder that this WGLC ends soon!
>
> spt
>
> > On Mar 11, 2024, at 18:00, Joseph Salowey  wrote:
> >
> > This is the working group last call for TLS Encrypted Client Hello [1].
> Please indicate if you think the draft is ready to progress to the IESG and
> send any comments to the list by 31 March 2024.  The comments sent by
> Watson Ladd to the list [2] on 17 February 2024 will be considered last
> call comments.
> >
> > Thanks,
> >
> > Joe, Deirdre, and Sean
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> > [2]
> https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
> >
> >
> > ___
> > 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

[Sean Turner]

Just a reminder that this WGLC ends soon!

spt

> On Mar 11, 2024, at 18:00, Joseph Salowey  wrote:
> 
> This is the working group last call for TLS Encrypted Client Hello [1].  
> Please indicate if you think the draft is ready to progress to the IESG and 
> send any comments to the list by 31 March 2024.  The comments sent by Watson 
> Ladd to the list [2] on 17 February 2024 will be considered last call 
> comments.
> 
> Thanks,
> 
> Joe, Deirdre, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
> 
> 
> ___
> 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 20, 2024 at 10:39 PM Raghu Saxena  wrote:

>
> On 3/15/24 00:02, Eric Rescorla wrote:
> >
> >
> > So, if I understand correctly, for my domain "abc.com
> > ", I could
> > purposely choose to have my ECHConfig public_name be "google.com
> > ", and
> >
> >
> > As I said earlier, using "google.com " would be
> > unwise because it
> > would allow Google to mount an attack where they terminated
> > the connection and replaced the ECHConfig. You should instead
> > use a name that is either unregistrable or that you control.
>
> Just so I understand correctly - the scope of the attack if they were to
> really intercept the TLS handshake and replace the ECHConfig, would
> allow them to "just" decrypt my ClientHelloInner, correct? Since
> ultimately the real origin I am connecting to (e.g. "mydomain.com") is
> not something they control, and so they can't present a valid cert for
> it and complete the full TLS connection (i.e. impersonate the true origin).
>

Correct.

-Ekr


At least this is what I understand from Section 6.1.7, specifically:
> "Note that authenticating a connection for the public name does not
> authenticate it for the origin. The TLS implementation MUST NOT report
> such connections as successful to the application."
>
> Regards,
>
> Raghu Saxena
>
>
___
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/15/24 00:02, Eric Rescorla wrote:



So, if I understand correctly, for my domain "abc.com
", I could
purposely choose to have my ECHConfig public_name be "google.com
", and


As I said earlier, using "google.com " would be 
unwise because it

would allow Google to mount an attack where they terminated
the connection and replaced the ECHConfig. You should instead
use a name that is either unregistrable or that you control.


Just so I understand correctly - the scope of the attack if they were to 
really intercept the TLS handshake and replace the ECHConfig, would 
allow them to "just" decrypt my ClientHelloInner, correct? Since 
ultimately the real origin I am connecting to (e.g. "mydomain.com") is 
not something they control, and so they can't present a valid cert for 
it and complete the full TLS connection (i.e. impersonate the true origin).


At least this is what I understand from Section 6.1.7, specifically: 
"Note that authenticating a connection for the public name does not 
authenticate it for the origin. The TLS implementation MUST NOT report 
such connections as successful to the application."


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

[Salz, Rich]

Is there value in citing the security analysis for ECH as an informative 
reference?

Yes!

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

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Sun, Mar 17, 2024 at 11:53 PM Karthikeyan Bhargavan <
karthikeyan.bharga...@inria.fr> wrote:

> Is there value in citing the security analysis for ECH as an informative
> reference?
>
> [image: 3548606.cover.jpg]
>
> A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello |
> Proceedings of the 2022 ACM SIGSAC Conference on Computer and
> Communications Security
> 
> dl.acm.org 
> 
>
>
> I expect this is quite late in the process for that:
>

Not at all, I think we just need to update the existing reference:

   [ECH-Analysis]
  "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
  Client Hello", November 2022.

Care to send a PR?


-Ekr


>
>
>
> On 12 Mar 2024, at 01:21, Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
> security
>
>
> ___
> 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

[Karthikeyan Bhargavan]

Is there value in citing the security analysis for ECH as an informative 
reference?

https://dl.acm.org/doi/abs/10.1145/3548606.3559360
A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello | 
Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications 
Security
dl.acm.org


I expect this is quite late in the process for that:



> On 12 Mar 2024, at 01:21, Christopher Patton 
>  wrote:
> 
> security

___
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 PM Raghu Saxena  wrote:

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

As I said earlier, using "google.com" would be unwise because it
would allow Google to mount an attack where they terminated
the connection and replaced the ECHConfig. You should instead
use a name that is either unregistrable or that you control.


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?
>

As long as your server completes ECH, then it doesn't matter that
the certificate it presents is not valid for the public_name. However,
if you are unable to complete ECH (e.g., you have forgotten the
key and want to do the recovery mechanism), then this will
cause an error on the client.

-Ekr


> 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
>
> ___
> 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

[Dennis Jackson]

+1 to shipping it.

On 11/03/2024 22:00, Joseph Salowey wrote:
This is the working group last call for TLS Encrypted Client Hello 
[1].  Please indicate if you think the draft is ready to progress to 
the IESG and send any comments to the list by 31 March 2024.  The 
comments sent by Watson Ladd to the list [2] on 17 February 2024 will 
be considered last call comments.


Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
[2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/



___
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

[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

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

[涛叔]

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] 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] 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 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 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

[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

[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] 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

[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=draft-ietf-tls-esni-18=--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

[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

[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

[Watson Ladd]

On Tue, Mar 12, 2024 at 10:20 PM Raghu Saxena  wrote:
>
> Are comments restricted strictly to members of the working group? If so,
> please ignore this E-Mail.
>
> I'd previously tried to raise an issue regarding requirements of a
> public_name in the ECHConfig in the mailing list [0], and when I didn't
> get much response there, even on Github [1], where I was further met by
> silence. I assumed this meant since I am not in the working group I am
> not allowed to participate in discussions, but seeing the "Last Call" I
> thought I'd try one last time.

Please read https://www.ietf.org/about/introduction/. To put it
shortly there is no such thing as WG membership beyond participation.

>
> My concern relies around the fact that by requiring a public_name in the
> ECHConfig, and clients "SHOULD" pass it, means we are losing basically
> all the benefit we initially had with ESNI, since now some part is
> leaked anyway. This was not an issue in original ESNI. Although the
> draft allows for a client to not use this value, and/or for a server to
> not validate it ("SHOULD" rather than "MUST"), in practice all of the
> most popular clients (i.e. browsers) will probably end up using /
> sending it. We saw this for SNI, where even websites which don't need it
> (e.g. a very popular adult website), browsers will still send it, and
> this becomes a vector for censorship / blocking.

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.

>
> If this requirement is unlikely to change, my question then becomes - it
> is  "acceptable", as a website operator who does not wish to leak the
> domain name in the ECHOuter's plaintext SNI, to specify the
> "public_name" in the ECHConfig as something random (e.g. "example.com"),
> acknowledging the fact that as a server operator, I will disregard any
> value the client passes for the SNI in the ClientHello anyway? Or is
> there another recommended approach if I do not want the actual domain to
> be leaked on the wire. This is coming as an individual operator, with no
> CDNs to hide behind (e.g. `cloudflare-ech.com`).

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.
>
> Lastly, I also struggle to understand the value of this field. From
> reading the RFC, it seems it is mostly only applicable if the server
> rejects ECH. I would think this happens if the server does not support
> ECH, and therefore should not have had an ECHConfig published anyway- or
> the client is unable to satsify the server's ECH requirements. In both
> cases, I would think it is on the client to fallback an purposely
> initiate a non-ECH TLS handshake, rather than "downgrade" the
> connection. Forgive me if I am missing something obvious, but as someone
> who used ESNI successfully back when it was in draft status, and was
> happy with no SNI being leaked, I am unhappy that it has returned.

DNS does not propagate atomically with webserver configuration
changes. It's thus necessary to deal with mismatches.

Sincerely,
Watson Ladd
-- 
Astra mortemque praestare gradatim

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

Re: [TLS] Working Group Last Call for ECH

[涛叔]

I have risen similar discussion before and have tried to suggest some 
solutions, but none of them got any support.

Here is the previous discuss thread, just FYI

https://mailarchive.ietf.org/arch/msg/tls/HlwYX16Y4W2BevKTpI6a81eO1JE/

> On Mar 13, 2024, at 13:20, Raghu Saxena  wrote:
> 
> Are comments restricted strictly to members of the working group? If so, 
> please ignore this E-Mail.
> 
> I'd previously tried to raise an issue regarding requirements of a 
> public_name in the ECHConfig in the mailing list [0], and when I didn't get 
> much response there, even on Github [1], where I was further met by silence. 
> I assumed this meant since I am not in the working group I am not allowed to 
> participate in discussions, but seeing the "Last Call" I thought I'd try one 
> last time.
> 
> My concern relies around the fact that by requiring a public_name in the 
> ECHConfig, and clients "SHOULD" pass it, means we are losing basically all 
> the benefit we initially had with ESNI, since now some part is leaked anyway. 
> This was not an issue in original ESNI. Although the draft allows for a 
> client to not use this value, and/or for a server to not validate it 
> ("SHOULD" rather than "MUST"), in practice all of the most popular clients 
> (i.e. browsers) will probably end up using / sending it. We saw this for SNI, 
> where even websites which don't need it (e.g. a very popular adult website), 
> browsers will still send it, and this becomes a vector for censorship / 
> blocking.
> 
> If this requirement is unlikely to change, my question then becomes - it is  
> "acceptable", as a website operator who does not wish to leak the domain name 
> in the ECHOuter's plaintext SNI, to specify the "public_name" in the 
> ECHConfig as something random (e.g. "example.com"), acknowledging the fact 
> that as a server operator, I will disregard any value the client passes for 
> the SNI in the ClientHello anyway? Or is there another recommended approach 
> if I do not want the actual domain to be leaked on the wire. This is coming 
> as an individual operator, with no CDNs to hide behind (e.g. 
> `cloudflare-ech.com`).
> 
> Lastly, I also struggle to understand the value of this field. From reading 
> the RFC, it seems it is mostly only applicable if the server rejects ECH. I 
> would think this happens if the server does not support ECH, and therefore 
> should not have had an ECHConfig published anyway- or the client is unable to 
> satsify the server's ECH requirements. In both cases, I would think it is on 
> the client to fallback an purposely initiate a non-ECH TLS handshake, rather 
> than "downgrade" the connection. Forgive me if I am missing something 
> obvious, but as someone who used ESNI successfully back when it was in draft 
> status, and was happy with no SNI being leaked, I am unhappy that it has 
> returned.
> 
> Regards,
> 
> Raghu Saxena
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/HUG1CU0Q4PorZ7fD0yafVfj7VUY/
> 
> [1] 
> https://github.com/tlswg/draft-ietf-tls-esni/issues/572#issuecomment-1780859252
> 
> On 3/12/24 06:00, Joseph Salowey wrote:
>> This is the working group last call for TLS Encrypted Client Hello [1].  
>> Please indicate if you think the draft is ready to progress to the IESG and 
>> send any comments to the list by 31 March 2024.  The comments sent by Watson 
>> Ladd to the list [2] on 17 February 2024 will be considered last call 
>> comments.
>> 
>> Thanks,
>> 
>> Joe, Deirdre, and Sean
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
>> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>> 
>> 
>> 
>> ___
>> 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

[Raghu Saxena]

Are comments restricted strictly to members of the working group? If so, 
please ignore this E-Mail.


I'd previously tried to raise an issue regarding requirements of a 
public_name in the ECHConfig in the mailing list [0], and when I didn't 
get much response there, even on Github [1], where I was further met by 
silence. I assumed this meant since I am not in the working group I am 
not allowed to participate in discussions, but seeing the "Last Call" I 
thought I'd try one last time.


My concern relies around the fact that by requiring a public_name in the 
ECHConfig, and clients "SHOULD" pass it, means we are losing basically 
all the benefit we initially had with ESNI, since now some part is 
leaked anyway. This was not an issue in original ESNI. Although the 
draft allows for a client to not use this value, and/or for a server to 
not validate it ("SHOULD" rather than "MUST"), in practice all of the 
most popular clients (i.e. browsers) will probably end up using / 
sending it. We saw this for SNI, where even websites which don't need it 
(e.g. a very popular adult website), browsers will still send it, and 
this becomes a vector for censorship / blocking.


If this requirement is unlikely to change, my question then becomes - it 
is  "acceptable", as a website operator who does not wish to leak the 
domain name in the ECHOuter's plaintext SNI, to specify the 
"public_name" in the ECHConfig as something random (e.g. "example.com"), 
acknowledging the fact that as a server operator, I will disregard any 
value the client passes for the SNI in the ClientHello anyway? Or is 
there another recommended approach if I do not want the actual domain to 
be leaked on the wire. This is coming as an individual operator, with no 
CDNs to hide behind (e.g. `cloudflare-ech.com`).


Lastly, I also struggle to understand the value of this field. From 
reading the RFC, it seems it is mostly only applicable if the server 
rejects ECH. I would think this happens if the server does not support 
ECH, and therefore should not have had an ECHConfig published anyway- or 
the client is unable to satsify the server's ECH requirements. In both 
cases, I would think it is on the client to fallback an purposely 
initiate a non-ECH TLS handshake, rather than "downgrade" the 
connection. Forgive me if I am missing something obvious, but as someone 
who used ESNI successfully back when it was in draft status, and was 
happy with no SNI being leaked, I am unhappy that it has returned.


Regards,

Raghu Saxena

[0] https://mailarchive.ietf.org/arch/msg/tls/HUG1CU0Q4PorZ7fD0yafVfj7VUY/

[1] 
https://github.com/tlswg/draft-ietf-tls-esni/issues/572#issuecomment-1780859252


On 3/12/24 06:00, Joseph Salowey wrote:
This is the working group last call for TLS Encrypted Client Hello 
[1].  Please indicate if you think the draft is ready to progress to 
the IESG and send any comments to the list by 31 March 2024.  The 
comments sent by Watson Ladd to the list [2] on 17 February 2024 will 
be considered last call comments.


Thanks,

Joe, Deirdre, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
[2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/



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


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

[Martin Thomson]

 Ship it.

On Tue, Mar 12, 2024, at 09:00, Joseph Salowey wrote:
> This is the working group last call for TLS Encrypted Client Hello [1]. 
>  Please indicate if you think the draft is ready to progress to the 
> IESG and send any comments to the list by 31 March 2024.  The comments 
> sent by Watson Ladd to the list [2] on 17 February 2024 will be 
> considered last call comments.
>
> Thanks,
>
> Joe, Deirdre, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>
>
> ___
> 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

[Loganaden Velvindron]

I also support seeing the document moving forward.

On Tue, Mar 12, 2024, 16:37 Salz, Rich 
wrote:

> I support advancing this document.
>
> ___
> 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

[Arnaud Taddei]

+1

will do my best to help within the timeline

From: TLS  on behalf of Salz, Rich 

Date: Tuesday, 12 March 2024 at 13:37
To: Stephen Farrell , Rob Sayre 
Cc: tls@ietf.org 
Subject: Re: [TLS] Working Group Last Call for ECH
I support advancing this document.

___
TLS mailing list
TLS@ietf.org
https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/tls=gmail-imap=171085186100=AOvVaw3echo5ObGk7b7iiYkm4H7k

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


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

[Salz, Rich]

I support advancing this document.

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

Re: [TLS] Working Group Last Call for ECH

[Stephen Farrell]

Hiya,

On 12/03/2024 01:25, Rob Sayre wrote:

The one that got to me was:

"It SHOULD place the value of ECHConfig.contents.public_name in the
"server_name" extension. Clients that do not follow this step, or place a
different value in the "server_name" extension, risk breaking the retry
mechanism described in Section 6.1.6 or failing to interoperate with
servers that require this step to be done; see Section 7.1."

So, that seemed like it might be a problem for the previous analysis.


I guess that's a reasonable question to ask, though I'd be
surprised if it that case were represented in the analyses.

If asked, (and who'd ask me:-), I'd probably argue that it
doesn't affect the security properties of ECH though, as a
server could always have been presented with an outer CH
that has some random SNI value, so I'd guess that change
ought not affect the security properties of ECH. Clients
that follow the SHOULD get the same as before, as do those
that don't, and servers should in any case have been able
to handle unexpected values in inputs.

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.

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=draft-ietf-tls-esni-18=--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






OpenPGP_0xE4D8E9F997A833DD.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

[Rob Sayre]

The one that got to me was:

"It SHOULD place the value of ECHConfig.contents.public_name in the
"server_name" extension. Clients that do not follow this step, or place a
different value in the "server_name" extension, risk breaking the retry
mechanism described in Section 6.1.6 or failing to interoperate with
servers that require this step to be done; see Section 7.1."

So, that seemed like it might be a problem for the previous analysis.

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=draft-ietf-tls-esni-18=--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

Re: [TLS] Working Group Last Call for ECH

[Stephen Farrell]

On 12/03/2024 00:49, Rob Sayre wrote:

On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton 
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=draft-ietf-tls-esni-18=--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


OpenPGP_0xE4D8E9F997A833DD.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

[Rob Sayre]

On Mon, Mar 11, 2024 at 5:21 PM Christopher Patton 
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=draft-ietf-tls-esni-18=--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.

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

Re: [TLS] Working Group Last Call for ECH

[Watson Ladd]

On Mon, Mar 11, 2024 at 3:00 PM Joseph Salowey  wrote:
>
> This is the working group last call for TLS Encrypted Client Hello [1].
Please indicate if you think the draft is ready to progress to the IESG and
send any comments to the list by 31 March 2024.  The comments sent by
Watson Ladd to the list [2] on 17 February 2024 will be considered last
call comments.

My understanding is that these comments got resolved in
https://github.com/tlswg/draft-ietf-tls-esni/pull/607 before the upload of
the draft that we're now talking about. I'm not sure what proceedural
difference it makes to consider them WGLC comments that got resolved or
not, but I just want to make sure we're all on the same page that they got
addressed.

>
> Thanks,
>
> Joe, Deirdre, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>
>
> ___
> 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

[Christopher Patton]

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=draft-ietf-tls-esni-18=--html

Chris P.

On Mon, Mar 11, 2024 at 3:12 PM Rob Sayre  wrote:

> On Mon, Mar 11, 2024 at 3:08 PM Rob Sayre  wrote:
>
>> I also believe there was supposed to be some formal proof work done, and
>> I'm not sure that's complete
>>
>
> Ah, I see this was done:
> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>
> So, I guess the only question is whether this needs to be done again for
> the latest specification.
>
> 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

Re: [TLS] Working Group Last Call for ECH

[Christopher Patton]

Hi chairs,

I believe ECH is good to go.

Chris P.

On Mon, Mar 11, 2024 at 3:00 PM Joseph Salowey  wrote:

> This is the working group last call for TLS Encrypted Client Hello [1].
> Please indicate if you think the draft is ready to progress to the IESG and
> send any comments to the list by 31 March 2024.  The comments sent by
> Watson Ladd to the list [2] on 17 February 2024 will be considered last
> call comments.
>
> Thanks,
>
> Joe, Deirdre, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>
>
> ___
> 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

[Stephen Farrell]

Hiya,

On 11/03/2024 22:08, Rob Sayre wrote:

I think it is ready and can live with the current draft.


Same here. The protocol's well baked. The text good
enough. I've written code to implement it, done the
interop with others, deployed test services and done
PoC integrations of my openssl ECH stuff and various
applications and it all works.

I do plan to give it a read-through again to see if
there are any bits that might be so confusing as to
need fixing, but I don't expect to find much, given
I've been over that text fairly often.

Cheers,
S.



OpenPGP_0xE4D8E9F997A833DD.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

[Rob Sayre]

On Mon, Mar 11, 2024 at 3:08 PM Rob Sayre  wrote:

> I also believe there was supposed to be some formal proof work done, and
> I'm not sure that's complete
>

Ah, I see this was done:
https://dl.acm.org/doi/abs/10.1145/3548606.3559360

So, I guess the only question is whether this needs to be done again for
the latest specification.

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

Re: [TLS] Working Group Last Call for ECH

[Rob Sayre]

I think it is ready and can live with the current draft. I agree with
Watson Ladd that the ordering is awkward. If you get past that part, it all
works, but you have to read the whole thing before you really get it. Then,
you must start in the middle to begin your implementation. I guess the
criticism is that it's not a very good guide as you implement, but it all
makes sense as you try things in a different order than the draft indicates.

I also believe there was supposed to be some formal proof work done, and
I'm not sure that's complete.

thanks,
Rob


On Mon, Mar 11, 2024 at 3:00 PM Joseph Salowey  wrote:

> This is the working group last call for TLS Encrypted Client Hello [1].
> Please indicate if you think the draft is ready to progress to the IESG and
> send any comments to the list by 31 March 2024.  The comments sent by
> Watson Ladd to the list [2] on 17 February 2024 will be considered last
> call comments.
>
> Thanks,
>
> Joe, Deirdre, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>
>
> ___
> 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