Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

Joe Abley wrote: 1035 clearly allows QDCOUNT>1 for responses to IQUERY and 1034 clearly specifies QDCOUNT=1 for standard queries and responses. It sounds like you agree with the archaeology and the proposed clarification in the draft. Even though my statement above is made against: > RFC 10

[DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

Hi there all, I was really hoping that it wouldn't come to this, but… We approved draft-ietf-dnsop-svcb-https on 2022-05-22, and has been stuck in MISREF state ever since[0], waiting on draft-ietf-tls-esni - "TLS Encrypted Client Hello" .

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

On Thu, Feb 23, 2023 at 12:39, Warren Kumari wrote: > Instead of just having all of these document stuck indefinitely, I'm > proposing that we: > 1: Ask the RFC Editor to return the document to the IESG & IETF[1]. > 2: I return it to the WG. > 3: The authors remove the bits that rely on ESNI > 4

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

Thanks Warren for chasing all this process. Tim On Thu, Feb 23, 2023 at 12:54 PM Joe Abley wrote: > > On Thu, Feb 23, 2023 at 12:39, Warren Kumari wrote: > > Instead of just having all of these document stuck indefinitely, I'm > proposing that we: > 1: Ask the RFC Editor to return the documen

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

+1 to this plan. Once the ECH content is removed from this draft, the authors of draft-ietf-tls-esni will work to incorporate it there as necessary. Best, Chris > On Feb 23, 2023, at 12:57 PM, Tim Wicinski wrote: > > Thanks Warren for chasing all this process. > > Tim > > > On Thu, Feb 23

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

I'm OK with this, although personally I'm happy to just wait for ECH. I had hoped for a simpler solution (like marking SVCB's dependency on ECH as Informative), but I can understand if the IESG thinks there's no other way. If we are chopping the ECH parts out of SVCB, I would prefer to publish th

Re: [DNSOP] [Ext] Breaking the logjam that is draft-ietf-dnsop-svcb-https

On Feb 23, 2023, at 10:14 AM, Benjamin Schwartz wrote: > > I'm OK with this, although personally I'm happy to just wait for ECH. I had > hoped for a simpler solution (like marking SVCB's dependency on ECH as > Informative), but I can understand if the IESG thinks there's no other way. draft-i

Re: [DNSOP] [Ext] Breaking the logjam that is draft-ietf-dnsop-svcb-https

Moving the ECH/ESNI bits from draft-ietf-dnsop-svcb-https to draft-ietf-tls-esni seems to be the simplest option by far here. I strongly support that. David On Thu, Feb 23, 2023 at 10:38 AM Paul Hoffman wrote: > On Feb 23, 2023, at 10:14 AM, Benjamin Schwartz wrote: > > > > I'm OK with this, al

Re: [DNSOP] [Ext] Breaking the logjam that is draft-ietf-dnsop-svcb-https

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I don’t expect ECH to be the only security improvement enabled by SVCB, and the specification itself is designed to allow additions like that without being baked in from the start. Any issues posed by adding ECH later are indicative of issues with

Re: [DNSOP] [Ext] Breaking the logjam that is draft-ietf-dnsop-svcb-https

On Thu, Feb 23, 2023 at 1:41 PM David Schinazi wrote: > Moving the ECH/ESNI bits from draft-ietf-dnsop-svcb-https > to draft-ietf-tls-esni seems to be the simplest option by far here. I > strongly support that. > David > Currently, draft-ietf-tls-esni runs to 40 pages excluding the references an

Re: [DNSOP] [Ext] Breaking the logjam that is draft-ietf-dnsop-svcb-https

I agree with the "ecb-in-svcb" document over a -bis, as the (soon to exist) registry states only expert review. The one thing we have not discussed is Warren's comment [0] Possibly modulo the annoyingly painful "AliasMode clarification" change: https://author-tools.ietf.org/iddiff?url1=draft-ietf

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

How much DNS traffic is even still inspectable these days? On Wed, Feb 22, 2023 at 6:19 PM Ondřej Surý wrote: > Given the uneasy history with firewall implementors, I think it would be > best > to expand the document to explicitly say somewhere that messages with > QDCOUNT=0 are valid. The assum

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

> On 23 Feb 2023, at 22:36, Ted Lemon wrote: > > How much DNS traffic is even still inspectable these days? Depends on the definition of DNS traffic Ted. DNS-OARC has many TB of pcaps and query logs from the DITL project. Whether that data could be good enough to meaningfully measure the inc

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

I suspect legit qdcount > 0 queries on the global internet are nonexistent, since the answers are alway wrong. :) On Thu, 23 Feb 2023 at 17:53, Jim Reid wrote: > > > > On 23 Feb 2023, at 22:36, Ted Lemon wrote: > > > > How much DNS traffic is even still inspectable these days? > > Depends on th

Re: [DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

On Fri, Feb 24, 2023, at 05:03, Christopher Wood wrote: > +1 to this plan. Once the ECH content is removed from this draft, the > authors of draft-ietf-tls-esni will work to incorporate it there as > necessary. Warren's proposed plan is good. I'm less sure about the various options for documen