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

[Martin Thomson]

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 documenting the intersection of ECH 
and SVCB (three so far have been suggested, all of which have drawbacks). This 
could be treated as a question of paper shuffling where document editors can be 
given some freedom, so I am happy to await the first proposed draft on the 
subject rather than try to litigate it here.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 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 incidence of QDCOUNT>1 in the real world
> is anyone’s guess. I suppose it’ll be difficult (and very subjective) to
> distinguish between “real” QDCOUNT>1 queries and the ones from junk
> implementations that are just part of the DNS’s background noise.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> 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 incidence of QDCOUNT>1 in the real world is anyone’s 
guess. I suppose it’ll be difficult (and very subjective) to distinguish 
between “real” QDCOUNT>1 queries and the ones from junk implementations that 
are just part of the DNS’s background noise.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 assumption is implicit in the document, but I've
> already lost faith in humanity :).
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
>
>
> > On 17. 2. 2023, at 17:20, Ray Bellis  wrote:
> >
> >  Forwarded Message 
> > Subject: New Version Notification for
> draft-bellis-dnsop-qdcount-is-one-00.txt
> > Date: Fri, 17 Feb 2023 08:12:18 -0800
> > From: internet-dra...@ietf.org
> > To: Joe Abley , Ray Bellis 
> >
> >
> > A new version of I-D, draft-bellis-dnsop-qdcount-is-one-00.txt
> > has been successfully submitted by Ray Bellis and posted to the
> > IETF repository.
> >
> > Name: draft-bellis-dnsop-qdcount-is-one
> > Revision: 00
> > Title: In the DNS, QDCOUNT is (usually) One
> > Document date: 2023-02-17
> > Group: Individual Submission
> > Pages: 6
> > URL:
> https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/
> > Html:
> https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.html
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one
> >
> >
> > Abstract:
> >   This document clarifies the allowable values of the QDCOUNT parameter
> >   in DNS messages with OPCODE = 0 (QUERY) and specifies the required
> >   behaviour when values that are not allowed are encountered.
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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-dnsop-svcb-https-10=draft-ietf-dnsop-svcb-https-11=--html


On Thu, Feb 23, 2023 at 4:25 PM Benjamin Schwartz  wrote:

> 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
> and appendices.  I think we would do well to avoid making it even longer.
> Also, the integration requirements touch on very different subject matter
> from the ECH draft.  In addition to defining and registering a SvcParamKey,
> the text in question also discusses how enabling ECH via SVCB alters the
> SVCB client retry logic and HTTP Alt-Svc processing, along with several
> examples.
>
> More broadly, I think it's logical for ECH, like TLS itself, to be
> specified without reference to DNS.  We have a very nice abstraction
> boundary here, and we might as well use it.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Benjamin Schwartz]

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
and appendices.  I think we would do well to avoid making it even longer.
Also, the integration requirements touch on very different subject matter
from the ECH draft.  In addition to defining and registering a SvcParamKey,
the text in question also discusses how enabling ECH via SVCB alters the
SVCB client retry logic and HTTP Alt-Svc processing, along with several
examples.

More broadly, I think it's logical for ECH, like TLS itself, to be
specified without reference to DNS.  We have a very nice abstraction
boundary here, and we might as well use it.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jeremy Saklad]

-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 the SVCB 
specification as it is right now.

The only real advantage of including ECH from the start, to my mind, is the 
ability to make the tag automatically mandatory. And we could do this without 
that spec being finished: since the meaning will be laid out in a future RFC, 
all implementations can simply ignore records with it for now.

I’m really excited to see this finalized: I consider it to be one of the most 
useful and exciting drafts in years.
-BEGIN PGP SIGNATURE-

iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY/e5PlYYJ2h0dHBzOi8v
b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw
NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIGwoCAP4j0zUf
ic1Q4+Sm4Zy3dk6MoVIPfQPfM2Ycj7BPMwdSzgEAm9Q9NYybxfwNtpBghIstxyZh
coru9N5waZBfCoaTJgE=
=2uvG
-END PGP SIGNATURE-
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[David Schinazi]

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, 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-ietf-dnsop-svcb-https has MUST-level requirements for how to handle
> ECH, so it isn't really possible to mark the dependency as informational.
>
> > If we are chopping the ECH parts out of SVCB, I would prefer to publish
> them later as a separate document, rather than stuffing them into ECH or
> opening a SVCB-bis.  I think that will be clearer for readers and will
> minimize further delays.
>
> Yes, an ecb-in-svcb document would be much better than a -bis, unless
> there are significant other changes to make in the -bis.
>
> --Paul Hoffman
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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-ietf-dnsop-svcb-https has MUST-level requirements for how to handle ECH, 
so it isn't really possible to mark the dependency as informational.

> If we are chopping the ECH parts out of SVCB, I would prefer to publish them 
> later as a separate document, rather than stuffing them into ECH or opening a 
> SVCB-bis.  I think that will be clearer for readers and will minimize further 
> delays.

Yes, an ecb-in-svcb document would be much better than a -bis, unless there are 
significant other changes to make in the -bis.

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Benjamin Schwartz]

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
them later as a separate document, rather than stuffing them into ECH or
opening a SVCB-bis.  I think that will be clearer for readers and will
minimize further delays.

On Thu, Feb 23, 2023 at 12:39 PM Warren Kumari  wrote:

> 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"
>  .  This is
> basically as long as it takes to make a whole person…
>
> There are multiple documents in the RFC Editor queue waiting on the
> svcb-https  document: https://www.rfc-editor.org/cluster_info.php?cid=C461
> .
>
> Unfortunately it now seems that tls-esni is not likely to be published
> anytime soon because they want deployment experience before advancing it,
> and that's not going to happen for some months.
>
> This means that the svcb-https document, and, by extension, the other
> documents in the cluster will be stuck for an indeterminate amount of
> time.
>
> The part of svcb-https  that "needs" tls-esni is sort of an optional
> feature, and none of the other documents in this cluster seem to rely on
> it.
>
> 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: The document progresses "normally" - it gets another WGLC, IETF LC,
> IESG Eval, etc. Hopefully this can be expedited - it's already gone though
> all of these steps once, and the updated document would be very similar to
> the original.
>
> 5: If / when tls-esni is published, the svcb-https authors submit a -bis
> (while will likely just be 'git checkout '), and we
> progress this just like any other WG document.
>
> I've discussed this with the authors of the documents, the DNSOP and TLS
> chairs, the relevant ADs and the full IESG.
>
> However, before doing all this, I'd like to confirm that the WG doesn't
> object to the plan….
>
>
> W
> [0]: Possibly modulo the annoyingly painful "AliasMode clarification"
> change:
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-10=draft-ietf-dnsop-svcb-https-11=--html
>
> [1]: While we prefer not do to this sort of thing, we have done it before
> - as an example:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/history/
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Christopher Wood]

+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, 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 document to the IESG & IETF[1]. 
>> 2: I return it to the WG.
>> 3: The authors remove the bits that rely on ESNI
>> 4: The document progresses "normally" - it gets another WGLC, IETF LC, IESG 
>> Eval, etc. Hopefully this can be expedited - it's already gone though all of 
>> these steps once, and the updated document would be very similar to the 
>> original.
>> 
>> 5: If / when tls-esni is published, the svcb-https authors submit a -bis 
>> (while will likely just be 'git checkout '), and we 
>> progress this just like any other WG document. 
>> 
>> I've discussed this with the authors of the documents, the DNSOP and TLS 
>> chairs, the relevant ADs and the full IESG. 
>> 
>> However, before doing all this, I'd like to confirm that the WG doesn't 
>> object to the plan….
> 
> This sounds like a good plan to me. 
> 
> 
> Joe
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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 document to the IESG & IETF[1].
> 2: I return it to the WG.
> 3: The authors remove the bits that rely on ESNI
> 4: The document progresses "normally" - it gets another WGLC, IETF LC,
> IESG Eval, etc. Hopefully this can be expedited - it's already gone though
> all of these steps once, and the updated document would be very similar to
> the original.
>
> 5: If / when tls-esni is published, the svcb-https authors submit a -bis
> (while will likely just be 'git checkout '), and we
> progress this just like any other WG document.
>
> I've discussed this with the authors of the documents, the DNSOP and TLS
> chairs, the relevant ADs and the full IESG.
>
> However, before doing all this, I'd like to confirm that the WG doesn't
> object to the plan….
>
>
> This sounds like a good plan to me.
>
>
> Joe
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

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: The document progresses "normally" - it gets another WGLC, IETF LC, IESG 
> Eval, etc. Hopefully this can be expedited - it's already gone though all of 
> these steps once, and the updated document would be very similar to the 
> original.
>
> 5: If / when tls-esni is published, the svcb-https authors submit a -bis 
> (while will likely just be 'git checkout '), and we progress 
> this just like any other WG document.
>
> I've discussed this with the authors of the documents, the DNSOP and TLS 
> chairs, the relevant ADs and the full IESG.
>
> However, before doing all this, I'd like to confirm that the WG doesn't 
> object to the plan….

This sounds like a good plan to me.

Joe

>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

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"
 .  This is
basically as long as it takes to make a whole person…

There are multiple documents in the RFC Editor queue waiting on the
svcb-https  document: https://www.rfc-editor.org/cluster_info.php?cid=C461.

Unfortunately it now seems that tls-esni is not likely to be published
anytime soon because they want deployment experience before advancing it,
and that's not going to happen for some months.

This means that the svcb-https document, and, by extension, the other
documents in the cluster will be stuck for an indeterminate amount of
time.

The part of svcb-https  that "needs" tls-esni is sort of an optional
feature, and none of the other documents in this cluster seem to rely on
it.

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: The document progresses "normally" - it gets another WGLC, IETF LC, IESG
Eval, etc. Hopefully this can be expedited - it's already gone though all
of these steps once, and the updated document would be very similar to the
original.

5: If / when tls-esni is published, the svcb-https authors submit a -bis
(while will likely just be 'git checkout '), and we
progress this just like any other WG document.

I've discussed this with the authors of the documents, the DNSOP and TLS
chairs, the relevant ADs and the full IESG.

However, before doing all this, I'd like to confirm that the WG doesn't
object to the plan….


W
[0]: Possibly modulo the annoyingly painful "AliasMode clarification"
change:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-10=draft-ietf-dnsop-svcb-https-11=--html

[1]: While we prefer not do to this sort of thing, we have done it before -
as an example:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/history/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Masataka Ohta]

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 1035's ambiguity on the matter needs clarification.

???

That is not a sincere response.


There is no ambiguity.


That you see no need for any clarification while others say
differently is


Because others ignore 1034.

IMHO, those mentioning ambiguity of 1035 without reading
1034 can have no opinion on the matter.

If people feel some ambiguity of 1035 merely because they
ignore 1034, there is no point to publish yet another RFC
for disambiguation, because the new RFC, either, won't
be read.

Read the RFCs.

Masataka Ohta


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop