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

2024-10-04 Thread 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 EC

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

2024-10-04 Thread 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 s

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

2024-10-04 Thread 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 mailin

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

2024-10-04 Thread 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 bet

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

2024-10-04 Thread 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 key

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

2024-10-04 Thread 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 th

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

2024-10-04 Thread 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

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

2024-10-04 Thread 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,

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

2024-10-04 Thread 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 inte

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

2024-10-04 Thread 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 seem

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

2024-10-04 Thread 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 >

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

2024-10-04 Thread 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, th

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

2024-10-04 Thread 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] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

2024-10-04 Thread 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:

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

2024-10-04 Thread 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 digi

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

2024-10-04 Thread 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] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech

2024-10-04 Thread 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. --

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

2024-10-04 Thread 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-lit

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

2024-10-04 Thread 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 th