[TLS] Re: [DNSOP] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

[Arnaud Taddei]

Just to be clear, I agree with Eric and the text proposed is clear, I do not 
want either to delay this document

My intervention in this email thread was simply to give support to Paul Vixie 
and give real world information vs some of the statements I was reading in the 
email thread. 

Let’s move on 

Arnaud Taddei
Global Security Strategist | Enterprise Security Group

mobile: +41 79 506 1129 
Geneva, Switzerland
arnaud.tad...@broadcom.com  | broadcom.com

> On 4 Oct 2024, at 20:32, Eric Rescorla  wrote:
> 
> 
> 
> On Fri, Oct 4, 2024 at 11:30 AM Paul Wouters  > wrote:
>> 
>> On Fri, Oct 4, 2024 at 10:06 AM Ben Schwartz > > wrote:
>>> I've updated PR#16 to reframe this paragraph as a statement of fact: 
>>> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files 
>>> 
>> Speaking as individual,
>>  
>>> 
>>> It seems strange to me to describe a vulnerability without explaining how 
>>> to mitigate it, but I'm willing to move forward if this is all we have 
>>> consensus for.
>> 
>> I also find it a bit odd that we don't warn people the entire purpose of the 
>> draft would be in vain, if one did not use a properly secured DNS transport 
>> to a DNS server with a compatible privacy policy.
> 
> I think the text I proposed makes this clear.
>  
>> 
>> Perhaps a short Operational Considerations section could be added explaining 
>> the use of ECH at the Enterprise network and networks deploying DNS filter 
>> security services could be blocked for security reasons at the cost of 
>> privacy loss to the network? And that the enduser might not have a choice 
>> based on the DNS constrains within those networks.
> 
> I would not be in favor of this. This is been intensely controversial and I 
> want the document done.
> 
> -Ekr
> 
>> 
>> Of course I myself am now thinking I want a DNS module that pulls these DNS 
>> records based on previous queries and stashes these in my own DNS resolver 
>> so that I can move onto these kind of networks and use ECH without requiring 
>> to do further DNS lookups :P
>> 
>> Maybe just an aggressive prefetch of ECH related records :P
>> 
>> Which makes me wonder if it makes sense to advise long TTLs on these records 
>> so that they move along on your phone/laptop even if you enter these kind of 
>> networks.
>> 
>> Paul W
>>  
>>> 
>>> --Ben
>>> From: Eric Rescorla mailto:e...@rtfm.com>>
>>> Sent: Friday, October 4, 2024 8:07 AM
>>> To: Salz, Rich mailto:rs...@akamai.com>>
>>> Cc: Arnaud Taddei >> >; Ben Schwartz >> >; Paul Vixie >> >; Paul Wouters >> >; draft-ietf-tls-svcb-ech.auth...@ietf.org 
>>>  
>>> >> >; TLS@ietf.org 
>>>  mailto:tls@ietf.org>>; dn...@ietf.org 
>>>  WG mailto:dn...@ietf.org>>
>>> Subject: Re: [DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech
>>>  
>>> I don't really think it's helpful to re-litigate the broader topic of the 
>>> merits of ECH; nothing we say in security considerations will make a 
>>> material difference there.
>>> 
>>> With that said, I don't love the last sentence as we know users don't 
>>> really choose their resolvers. How about simply stating the facts:
>>> 
>>> "This specification does not effectively conceal the target domain name 
>>> from an untrusted resolver."
>>> 
>>> 
>>> -Ekr
>>> 
>>> 
>>> On Thu, Oct 3, 2024 at 9:41 AM Salz, Rich 
>>> mailto:40akamai@dmarc.ietf.org>> 
>>> wrote:
>>> I do not think this conflict of views can be resolved. The draft is 
>>> intended to show how it ECH should be used to preserve it’s security 
>>> guarantees, and there are groups in the DNS community who say this prevents 
>>> their normal course of operation, and providing the features that they 
>>> provide.  I apologize in advance if anyone finds my wording clumsy or, 
>>> worse, offensive. I was trying to use neutral words throughout.
>>> 
>>>  
>>> 
>>> I think we just acknowledge that in the security considerations and declare 
>>> the issue closed.
>>> 
>>> ___
>>> DNSOP mailing list -- dn...@ietf.org 
>>> To unsubscribe send an email to dnsop-le...@ietf.org 
>>> 


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

[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

[Andrew Campling]

If appropriate, we could pick up this issue in our ECH Deployment 
Considerations draft.  Happy to discuss in Dublin if there is interest in 
adding to our existing text.

Andrew

On 4 Oct 2024, at 19:39, Salz, Rich  wrote:



  *   I would not be in favor of this. This is been intensely controversial and 
I want the document done

I agree.  The PR acknowledges the issue and that’s enough in my view. Any 
additional work on how to deploy something in DNS will require close 
coordination with the DNS folks and add an interminable delay.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

[Arnaud Taddei]

Hi Erik, 

Agree it is out of the scope of this draft, but we have another vehicle that 
would be ideal to capture what you write 

We didn’t push it too much in the past 9+ months as per agreement with ADs and 
Working Group chairs, Eric and others to wait for ECH to be ratified first and 
on our side we stick to our agreement

Yet you can consult: 
https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/

And if you feel to make a PR with your below content or raise an issue in our 
GitHub it will certainly appreciated 

Indeed I left an editor note as a placeholder to precisely describe how 
enterprises can do this at the end of 5.3.2

Any feedback welcome but if so, let’s start another email thread to not mix 
things


Arnaud Taddei
Global Security Strategist | Enterprise Security Group

mobile: +41 79 506 1129 
Geneva, Switzerland
arnaud.tad...@broadcom.com  | broadcom.com

> On 4 Oct 2024, at 21:06, Erik Nygren  wrote:
> 
> The suggested text seems inoffensive to me as well, but we may also want to 
> expand it to cover the recursive-to-authoritative path for resolvers 
> associated with the client.   (ie, just using DoH to your home router isn't 
> going to help when it uses Do53 to the authorities.).
> 
> On the topic of DNSSEC, it's worth noting that rfc9460 (for SVCB) has some 
> text there as well which provides some recommendations.
> Some of those were general and were intended to provide some degree of 
> coverage for the ECH use-case (before this was
> split out to its own draft).
> 
> 
> I do share the concerns that Enterprise environments are going to need to be 
> able to disable ECH.
> That seems out of the scope of this draft, and it seems like they could do 
> this in a few ways:
> * Stripping SVCB/HTTPS RRs entirely
> * Removing (or replacing) ech entries from the SVCB/HTTPS RRs, especially if 
> used along with devices that do terminating TLS MitM.
> * Managed device client-side policy configured as part of the OS/client 
> environment.
> None of these are in the remit of the IETF or things we want to be 
> standardizing, so seem out of scope here,
> and also none of them truly defend against hostile/compromised clients that 
> ignore the enterprise policies
> and are trying to establish covert channels.  It seems like leaving things on 
> this front out of the draft is preferable.
> 
>  Erik
> 
> 
> 
> On Fri, Oct 4, 2024 at 11:37 AM Stephen Farrell  > wrote:
>> 
>> 
>> On 10/4/24 16:09, Salz, Rich wrote:
>> > https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 
>> > 
>> >  "Discuss
>> > the impact of resolver selection on security"
>> 
>> That suggested text seems inoffensive to me fwiw.
>> 
>> S.
>> ___
>> TLS mailing list -- tls@ietf.org 
>> To unsubscribe send an email to tls-le...@ietf.org 
>> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org


-- 
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.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org