Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition

I agree it would greatly help to include the more precise terms. Note that Scott's current EPP draft is still using this term, citing the definition in 1912. Should the term be removed from Scott's draft, or acknowledged that it is now historic? If Scott replaces it with another more precise

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

Peter, Thank you. The change is good. Linda -Original Message- From: Peter Thomassen Sent: Monday, July 17, 2023 7:57 PM To: Linda Dunbar ; sec...@ietf.org Cc: dnsop@ietf.org; draft-ietf-dnsop-dnssec-bootstrapping@ietf.org Subject: Re: [DNSOP] Secdir early review of draft-ietf-dnso

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

John R. Levine wrote on 2023-07-17 18:22: On Mon, 17 Jul 2023, Shumon Huque wrote: ... This is not a new issue. It is the well known record subtyping problem that was advised against in RFC 5507 (IAB; "Design Choices When Expanding the DNS"). That advice was targeted to new RR type design, bu

Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition

To the definition and future use of lame, I think this is reasonable editorial. I think the draft could use some linkage to the "better terms" so it's clear what terms are now held to refer to what we formerly called "lame" -But that would be connective, not substantive to the definition of what l

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Mon, 17 Jul 2023, Shumon Huque wrote: * Verifiers can't query for the specific data they need from the DNS. They need to get a potentially large blob of data and look for what is applicable to them by examining the rdata for each record in the RRset. This is not a new issue. It is the well kno

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Jul 17, 2023, at 20:10, John Levine wrote: > >> I’m sure there are still plenty of tools crafting dns packets or using >> simplistic tools that are not able to do TCP or DNSSEC. > > I'm sure there used to be, but in 2023? Really? An example or two would be > intersting. As most of the p

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

Linda, On 7/18/23 01:58, Linda Dunbar wrote: Thanks for the reply. It is very helpful to better understand the draft. See my suggestions below: [...] [Linda] It would be very helpful if you can include those examples in the draft because the information is not really "arbitrary". It's diffi

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

You are right. My state mass observation was meant for the prior -1 where Joe referred to udp as a legacy protocol. Apologies for the slop. p vixie On Jul 17, 2023 17:15, David Conrad wrote: Mark, On Jul 17, 2023, at 4:23 PM, Mark Andrews wrote: >> Joe is (correctly, IMHO) pointing out

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

Mark, On Jul 17, 2023, at 4:23 PM, Mark Andrews wrote: >> Joe is (correctly, IMHO) pointing out that given there is a need to support >> TCP-based DNS queries (see RFC 7766), prudent engineering would suggest you >> need to prepare for attacks against that infrastructure. As such arguing >> “s

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Mon, Jul 17, 2023 at 7:20 PM Paul Wouters wrote: > On Jul 17, 2023, at 14:12, John R Levine wrote: > > > The only somewhat plausible argument I see against stuffing the apex is > that if people are sloppy, they might invent tokens that could be confused > with each other. > > This is an impor

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

Peter, Thanks for the reply. It is very helpful to better understand the draft. See my suggestions below: -Original Message- From: Peter Thomassen Sent: Monday, July 17, 2023 5:57 PM To: Linda Dunbar ; sec...@ietf.org Cc: dnsop@ietf.org; draft-ietf-dnsop-dnssec-bootstrapping@ietf.or

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

It appears that Paul Wouters said: >On Jul 17, 2023, at 14:12, John R Levine wrote: >> >>  >> In view of the wide use of DNSSEC and DoT and DoH, I think the argument that >> triggering TCP is bad stopped being persuasive a while ago. >(Don't we hope people sign the DNS responses with the tok

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Jul 17, 2023, at 15:50, Joe Abley wrote: > >  > I see UDP as a legacy transport, required for backwards comparability but > that's about it. I think you will be proven wrong QUICly 😀 Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

> On 18 Jul 2023, at 08:10, David Conrad wrote: > > Paul, > > On Jul 17, 2023, at 12:52 PM, Paul Vixie > wrote: >>> If the stability of anybody's infrastructure depends on people choosing a >>> particular transport, I would suggest they might have reason to be worried. >>> Simply hoping th

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Jul 17, 2023, at 14:12, John R Levine wrote: > >  > In view of the wide use of DNSSEC and DoT and DoH, I think the argument that > triggering TCP is bad stopped being persuasive a while ago. (Don't we hope > people sign the DNS responses with the tokens?) I’m sure there are still plenty o

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

Hi Linda, Thank you very much for your review! Comments below. On 7/17/23 22:32, Linda Dunbar via Datatracker wrote: Here are some minor issues with the draft: - What kind of "arbitrary information about the zones"? any examples? I'm not sure if the objective of your question is to have such

[DNSOP] WGLC rfc8499bis for revised lame delegation definition

Dear WG, With the DNSOP interim meeting last June, we reworded the definition of "lame delegation". This new definition of "lame delegation" has been shared on the mailing list and included by the document authors in the latest revision of the rfc8499bis draft, https://author-tools.ietf.org/

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

Paul, On Jul 17, 2023, at 12:52 PM, Paul Vixie wrote: >> If the stability of anybody's infrastructure depends on people choosing a >> particular transport, I would suggest they might have reason to be worried. >> Simply hoping that people don't start using TCP in a significant way is >> putti

[DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

Reviewer: Linda Dunbar Review result: Has Nits Reviewer: Linda Dunbar Review result: Ready with some questions I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for th

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Mon, 17 Jul 2023, Brian Dickson wrote: The stuffed apex does not only include those tokens, e.g. SPF and friends, which get queried A LOT. I forgot about SPF. Good point. In the absence of the aforementioned draft, there is no specific guidance that would lead ALL token issuers to use 20

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

Joe Abley wrote on 2023-07-17 12:50: On Mon, Jul 17, 2023 at 21:41, Brian Dickson > wrote: TCP traffic is several orders of magnitude more expensive than UDP. Anything that bumps up the proportion of TCP tr

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Mon, Jul 17, 2023 at 21:41, Brian Dickson <[brian.peter.dick...@gmail.com](mailto:On Mon, Jul 17, 2023 at 21:41, Brian Dickson < wrote: > TCP traffic is several orders of magnitude more expensive than UDP. > Anything that bumps up the proportion of TCP traffic in a statistically > meaningful

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Mon, Jul 17, 2023 at 12:20 PM John R Levine wrote: > Just to be clear, I think it's quite reasonable to encourage people to put > tokens at _name but I still see it as a matter of taste, not a technical > issue. > > On Mon, 17 Jul 2023, Brian Dickson wrote: > > TCP being triggered on resolver-

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

Just to be clear, I think it's quite reasonable to encourage people to put tokens at _name but I still see it as a matter of taste, not a technical issue. On Mon, 17 Jul 2023, Brian Dickson wrote: TCP being triggered on resolver-auth is much more of concern, particularly when the underlying ca

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Mon, Jul 17, 2023 at 11:05 AM John R Levine wrote: > >>> TCP, you already have worse problems, like DNSSEC doesn't work. > > > > Triggering TCP is still not good, even if it all works. It is still > > better avoiding by not stuffing the APEX. So I think we still want > > to leave something in

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

TCP, you already have worse problems, like DNSSEC doesn't work. Triggering TCP is still not good, even if it all works. It is still better avoiding by not stuffing the APEX. So I think we still want to leave something in there. In view of the wide use of DNSSEC and DoT and DoH, I think the arg

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On Mon, 17 Jul 2023, Florian Obser wrote: The entire discussion of response size seems like a throwback to the 1990s and I would remove it. These days if your DNS doesn't handle yeah, that might be best. TCP, you already have worse problems, like DNSSEC doesn't work. Triggering TCP is stil

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

On 2023-07-17 12:40 -04, "John Levine" wrote: > It appears that Florian Obser said: >>I gave this a once-over. >>3. Common Pitfalls >>> If the size of the response is large enough that it does not fit into >>> a single DNS UDP packet (UDP being the most common DNS transport >>> today), this may

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

It appears that Florian Obser said: >I gave this a once-over. >3. Common Pitfalls >> If the size of the response is large enough that it does not fit into >> a single DNS UDP packet (UDP being the most common DNS transport >> today), this may result in fragmentation > >That's not correct. If the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

I gave this a once-over. 1. Introduction > Generally only one temporary DNS record is sufficient for > proving domain ownership, although sometimes the DNS record must be > kept in the zone to prove continued ownership of the domain. I understand what it's trying to say, but I think "a" instead

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

Dear WG, This ends the WGLC for draft-ietf-dnsop-dns-error-reporting. The last call has been extended a bit longer than initially planned, but valuable feedback has been received from the WG on the the draft. Thank you very much. The authors published a -05 revision a week ago that incorpor

Re: [DNSOP] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop agenda?

On Jul 16, 2023, at 15:53, Viktor Dukhovni wrote: > >  > I should perhaps have stated the technical criteria on which I consider > the proposal non-viable. To whit: > >- The proposed protocol lacks all downgrade resistance. >- Without a signed delegation from the parent, the existence

Re: [DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-13.txt

On Wed, 2023-07-05 at 18:51 -0400, Tim Wicinski wrote: > All > > The authors of draft-ietf-dnsop-avoid-fragmentation worked with > different implementers to expand upon the index of Known > Implementations, and what they implement specifically.  > > The chairs would like to have a one week follow