[DNSOP] Re: WGLC for draft-ietf-dnsop-compact-denial-of-existence

On Fri, 4 Oct 2024, Vladimír Čunát wrote: special handling" should say that resolvers MUST implement the response code restoration in 4.1 unless the client sends the EDNS0 Compact Answers OK option. You can't restore the RCODE by default.  This topic is repeating.  Such answers must not pass

[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

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

[DNSOP] Re: WGLC for draft-ietf-dnsop-compact-denial-of-existence

> The bits on the wire are fine, but I am unhappy with the implication > that reasonable people should be happy with fake NODATA but if > you're a pedant who demands NXDOMAIN, well OK, if you insist. Real > things like query minimization depend on NXDOMAIN. If I query for > a.b.c.d.example and d.ex

[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: WGLC for draft-ietf-dnsop-compact-denial-of-existence

On 04/10/2024 19.03, John R Levine wrote: I suppose we could cheat slightly and say it's OK to restore NXDOMAIN to clients that don't ask for DNSSEC but that doesn't seem like a great direction to go. That is discussed in the very beginning of section 4. _

[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

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: [Ext] draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

On Oct 4, 2024, at 12:24, Russ Housley wrote: > > This document is related to draft-ietf-dnsop-rfc8624-bis. We ask the DSNOP > WG to adopt it. I support the adoption of this document before the WG finishes with draft-ietf-dnsop-rfc8624-bis. The two are tightly related, and might even be comb

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

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

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

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

[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

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] draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

This document is related to draft-ietf-dnsop-rfc8624-bis. We ask the DSNOP WG to adopt it. Russ > A new version of Internet-Draft > draft-crocker-dnsop-dnssec-algorithm-lifecycle-01.txt has been successfully > submitted by Russ Housley and posted to the > IETF repository. > > Name: draft-

[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: Re: Re: AD review draft-ietf-tls-svcb-ech

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

[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: WGLC for draft-ietf-dnsop-compact-denial-of-existence

It appears that Philip Homburg said: >> things like query minimization depend on NXDOMAIN. If I query for >> a.b.c.d.example and d.example does not exist, fake NODATA will make >> the client leak the entire name with multiple wasted queries. > >It seems to me that main purpose of query minimizati

[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: draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

> > On Oct 4, 2024, at 15:28, Russ Housley wrote: > > This document is related to draft-ietf-dnsop-rfc8624-bis. We ask the DSNOP > WG to adopt it. The document seems like a theoretical ideal of an algorithm life cycle. There have been many kind of considerations in play that have determine

[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: WGLC for draft-ietf-dnsop-compact-denial-of-existence

On 04/10/2024 05.20, John Levine wrote: Editorially, I would move the stuff about approaches not taken to an appendix to avoid confusing people. That includes the second and last paragraphs of section 2. Yes, please. Hence, in the penultimate paragraph in section 2, the sentence that starts

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

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 >

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

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

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

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,