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

I agree that you can't trust a resolver that you only know about from ADD. -Ekr On Tue, Oct 8, 2024 at 8:31 AM Paul Wouters wrote: > I agree with your points. Our only difference of opinion seems to be about > how much one should trust a TRR. > I still prefer to need to trust them the least po

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

I agree with your points. Our only difference of opinion seems to be about how much one should trust a TRR. I still prefer to need to trust them the least possible, meaning I would want DNSSEC validation to at least detect tampering at the TRR. With more ECH deployed, and less visibility of SNI, th

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

> Distribution trimmed down > to just dnsop, where the question is most pertinent. > > Paul Wouters writes: > > Of course even better is using RFC 7901 Chain Query and run the few > > signature validations yourself. > > Related, is there any notable software out there that does 7901? > I started

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

Paul, I don't understand your threat model here. 1. As already noted upthread, ECH inherently leaks the name you are resolving to the resolver. This leak doesn't depend on the resolver tampering with the response, so DNSSEC verification on the client doesn't help here [0]. 2. If the client accep

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

Distribution trimmed down to just dnsop, where the question is most pertinent. Paul Wouters writes: > Of course even better is using RFC 7901 Chain Query and run the few > signature validations yourself. Related, is there any notable software out there that does 7901? I started implementing it i

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

On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote: > > > On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote: > >> >> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote: >> >>> This is explicitly prohibited rfc9460 as it would provide linkability. > See rfc9460 section 12: "Clients MUST ens

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

On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote: > > On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote: > >> 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 networ

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

On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote: > 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 adve

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-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 forg

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

On Sun, Oct 6, 2024 at 9:09 AM Paul Wouters wrote: > [kind of off-topic here, and also speaking as just an individual] > > On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote: > >> >> On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell >> wrote: >> >>> >>> On 10/4/24 19:30, Paul Wouters wrote: >>> > Wh

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

[kind of off-topic here, and also speaking as just an individual] On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote: > > 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

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

>>> Sent: Friday, October 4, 2024 8:07 AM >>> To: Salz, Rich mailto:rs...@akamai.com>> >>> Cc: Arnaud Taddei >> <mailto:arnaud.tad...@broadcom.com>>; Ben Schwartz >> <mailto:bem...@meta.com>>; Paul Vixie >> <mailto:p...@redbarn.org>

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

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

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

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. ___ DNSOP mail

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

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

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

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

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

* 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

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

< >> 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>; t...@ietf.org ; >> dnsop@ietf.org WG >> *Subject:* Re: [DNSOP] Re: [TLS] Re: Re: Re: AD r

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

etf.org < > draft-ietf-tls-svcb-ech.auth...@ietf.org>; t...@ietf.org ; > dnsop@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;

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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