Re: [Secdispatch] Request for a slot in the agenda of secdispatch on the 26th

[Arnaud Taddei <[e-mail]>]

Dear all, am coming back here late as I have a bad COVID and it hurts 

As such, I answered Eric, Steven and Michael separately yesterday, and I was so confused, I didn’t realise I hit Reply and not Reply all 

Anyway, the net net is that 
I will withdraw my request for a slot in secdispatch agenda
This work could have been good for OPSEC especially given the work on IOCs but their agenda is now full
This work is NOT a critique for ECH, it is a ask for what ECH can do to help enterprises when it will happen there (just a matter of time)
This work as it is, is premature for TLS group and I need to do some extra research on my claim that it brings new arguments (right now I insist it does)
I will rejoin the TLS working group and mailing list and engage prior to IETF 115
For the moment, Lars supports the idea this work as it is can go to HotRFC so I will pursue this direction for a brief intervention

Thank you for the 3 email threads and the good perspective exchanges separately

Best Regards



> On 12 Jul 2022, at 19:44, Eric Rescorla <[e-mail]> wrote:
> 
> Document: draft-taddei-ech4ent-introduction-00.txt
> 
> Hi Arnaud,
> 
> This seems to be largely a critique of ECH, so as far as SECDISPATCH
> goes, the answer is that this should go to TLS. With that said, I
> believe most of the points that you are raising were already
> considered when we decided to do ECH, so I wouldn't expect this to
> change the trajectory of the WG. You could, of course, also make these
> as Last Call comments. I don't think this needs an agenda slot at
> SECDISPATCH.
> 
> 
> As far as the substance goes, I would make two points.
> 
> First, I think there is perhaps a disconnect about the way that ECH is
> likely to be deployed, especially in Enterprise
> environments. Specifically:
> 
> 1. Because ECH depends on DNS, if clients us the Enterprise DNS,
>    then that server can simply strip the ECH records from
>    DNS responses. I believe this applies to non-Firefox browsers,
>    as they use the DHCP-advertised resolver.
> 
> 2. Although ECH is not yet widely deployed in clients, I would
>    expect it to be configurable via enterprise policies. You
>    mention intercepting proxies a number of times in S 3.5,
>    but enabling those proxies requires control of the endpoint,
>    which should be sufficient to disable ECH.
> 
> My point here is that in both cases the Enterprise has the opportunity
> to disable ECH, so there shouldn't be any real impact. Of course,
> this doesn't apply to BYOD, but the solution there is to actually
> get management of the device--at least enough to disable ECH.
> 
> 
> Second, in cases where the client is untrustworthy, then SNI cannot be
> trusted, even if it is in the clear. The client can put an innocuous
> SNI in the ClientHello. The same applies to the server certificate
> because the client and server don't need to comply with RFCs 2818 or
> 6125. If what you are worried about is malware connecting to C&C, then
> SNI is insufficient.  It's true that SNI is useful for compliant
> clients and servers, however, for instance if you want to prevent
> people from browsing specific sites.
> 
> 
> -Ekr
> 
> 
>    
> 
> On Mon, Jul 11, 2022 at 8:33 PM Arnaud Taddei <arnaud.taddei=[e-mail] <mailto:[e-mail]>> wrote:
> Dear all, I would like to request a slot in the agenda of secdispatch on the 26th at IETF114 to present the I-D draft-taddei-ech4ent-introduction-00.txt 
> 
> I came back to IETF113 after an air gap of 2 years, so I am certainly very rusty but I could do some investigations since March and I would like the chance to share some ideas regarding ECH in the context of Enterprises and Organizations
> 
> I will be there remotely
> 
> Thank you for your consideration
> 
> 
> 
> 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._______________________________________________
> Secdispatch mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/secdispatch&source=gmail-imap&ust=1658252684000000&usg=AOvVaw0dD-NVhIVELuk4OwFaJjrw>


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