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

[Salz, Rich]

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.

I disagree.  It will show that some concerns have been heard, if not addressed. 
Comity is all to rare these days.
___
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

[Tim Wicinski]

On Fri, Oct 4, 2024 at 11:39 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.
>
>
Agree with Stephen, these changes seem reasonable.

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

[Stephen Farrell]

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.


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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

[Salz, Rich]

On 10/4/24 15:58, Salz, Rich wrote:
> I disagree. It will show that some concerns have been heard, if not
> addressed. Comity is all to rare these days.

On 10/4/24, 11:03 AM, "Stephen Farrell"  wrote:
> Sorry, what's the "it"? (Apologies if I missed some
> specific proposal that was made.)

https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 "Discuss the impact of 
resolver selection on security"


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

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

[Arnaud Taddei]

Hi Eric
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 14:07, Eric Rescorla  wrote:
> 
> 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.
Fundamentally same line for me

> 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."
Sounds pragmatic

> 
> 
> -Ekr
> 
> 
> On Thu, Oct 3, 2024 at 9:41 AM Salz, Rich  > 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 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

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

[Stephen Farrell]

On 10/4/24 15:58, Salz, Rich wrote:

I disagree.  It will show that some concerns have been heard, if not
addressed. Comity is all to rare these days.


Sorry, what's the "it"? (Apologies if I missed some
specific proposal that was made.)

Ta,
S.


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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

[Erik Nygren]

It might make sense to expand on this to:

> ECH ensures that TLS does not disclose the SNI, but the same information
is also present in the DNS queries used to resolve the server's hostname.
This specification does not conceal the server name from the DNS resolver.
If DNS messages are sent between the client and resolver without
authenticated encryption, an attacker on this path can also learn the
destination server name. A similar exposure applies when the DNS resolver
is closely correlated with the requesting client, as an on path attacker
may be able to infer the destination server name or information about it by
observing traffic to DNS authorities [rfc9076].

On Fri, Oct 4, 2024 at 3:06 PM 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

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

[Rob Sayre]

Yeah, I have to agree with Ekr and Rich here. However, if the issues are so
widespread to make a deal breaker as some say, that will inhibit adoption.
After all, the IETF can't make people use ECH, and it's easy enough to
strip the ECH extension at the cost of interoperability. Obviously, the WG
thinks people will use it.

thanks,
Rob


On Fri, Oct 4, 2024 at 5:08 AM Eric Rescorla  wrote:

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

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

[Stephen Farrell]

Hiya,

On 10/4/24 19:30, Paul Wouters wrote:

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.


There's a tension between that and getting better forward-secrecy
by rotating ECH keys regularly. I don't think we're yet at a point
where we'd have something that useful to recommend in terms of
resolving that tension. (And that's ignoring the tension between
wanting, and disliking, ECH;-)

Maybe one to consider in a year or two when there's more operational
experience.

Cheers,
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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

[Erik Nygren]

On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell 
wrote:

>
> On 10/4/24 19:30, Paul Wouters wrote:
> > 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.
>
> There's a tension between that and getting better forward-secrecy
> by rotating ECH keys regularly. I don't think we're yet at a point
> where we'd have something that useful to recommend in terms of
> resolving that tension. (And that's ignoring the tension between
> wanting, and disliking, ECH;-)
>

This is explicitly prohibited rfc9460 as it would provide linkability.
See rfc9460 section 12: "Clients MUST ensure that their DNS cache is
partitioned for each local network, or flushed on network changes, to
prevent a local adversary in one network from implanting a forged DNS
record that allows them to track users or hinder their connections after
they leave that network."

As an example, an attacker could return ech values with tracking
information and use that to correlate clients across network changes.
This seems like a much worse outcome since it could be done server-side and
could impact all users, not just users
trying to get privacy from their local network operator.

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

[Salz, Rich]

  *   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

[Watson Ladd]

On Fri, Oct 4, 2024 at 11:32 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.
>
> 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.
>
> 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.

If deploying in DNS, ECH can be supported: the resolve has the
destination name. The issue is with SNI blocking hardware doing the
block instead of DNS.

At least that's what I understand from this conversation.
>
> Paul W
>
>>
>>
>> --Ben
>> 
>> From: Eric Rescorla 
>> Sent: Friday, October 4, 2024 8:07 AM
>> To: Salz, Rich 
>> Cc: Arnaud Taddei ; Ben Schwartz 
>> ; Paul Vixie ; Paul Wouters 
>> ; draft-ietf-tls-svcb-ech.auth...@ietf.org 
>> ; TLS@ietf.org ; 
>> dn...@ietf.org WG 
>> 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
>> 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 
>>  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
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

___
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

[Erik Nygren]

On Fri, Oct 4, 2024 at 3:48 PM Salz, Rich  wrote:

> This is explicitly prohibited rfc9460 as it would provide linkability.
>
>
>
> So what?  We’re not the protocol police and if someone wants to track,
> RFC9460 compliance isn’t going to stop them. Especially for something as
> controversial as ECH.
>
>
To clarify, I meant that we shouldn't encourage long TTLs for this purpose.
The thing prohibited by rfc9460 is retaining HTTPS/SVCB RRs across network
switches.
Sure a client could do it, but if they do that they're going to have both
linkability
(and maybe performance) issues.

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

[Salz, Rich]

This is explicitly prohibited rfc9460 as it would provide linkability.

So what?  We’re not the protocol police and if someone wants to track, RFC9460 
compliance isn’t going to stop them. Especially for something as controversial 
as ECH.

___
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

[Eric Rescorla]

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

[Ben Schwartz]

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

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.

--Ben

From: Eric Rescorla 
Sent: Friday, October 4, 2024 8:07 AM
To: Salz, Rich 
Cc: Arnaud Taddei ; Ben Schwartz ; 
Paul Vixie ; Paul Wouters ; 
draft-ietf-tls-svcb-ech.auth...@ietf.org 
; TLS@ietf.org ; 
dn...@ietf.org WG 
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

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

[Paul Wouters]

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.

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.

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 
> *Sent:* Friday, October 4, 2024 8:07 AM
> *To:* Salz, Rich 
> *Cc:* Arnaud Taddei ; Ben Schwartz <
> bem...@meta.com>; Paul Vixie ; Paul Wouters <
> paul.wout...@aiven.io>; draft-ietf-tls-svcb-ech.auth...@ietf.org <
> draft-ietf-tls-svcb-ech.auth...@ietf.org>; TLS@ietf.org ;
> dn...@ietf.org WG 
> *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
> 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  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
>
>
___
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

[Eric Rescorla]

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 
>> *Sent:* Friday, October 4, 2024 8:07 AM
>> *To:* Salz, Rich 
>> *Cc:* Arnaud Taddei ; Ben Schwartz <
>> bem...@meta.com>; Paul Vixie ; Paul Wouters <
>> paul.wout...@aiven.io>; draft-ietf-tls-svcb-ech.auth...@ietf.org <
>> draft-ietf-tls-svcb-ech.auth...@ietf.org>; TLS@ietf.org ;
>> dn...@ietf.org WG 
>> *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
>> 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 > 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
>>
>>
___
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

[Erik Nygren]

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