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

[k claffy]

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 term, 
can we get that term in this document so that 
future uses can cite this document?

Alternatively, instead of deprecating, the last sentence of that 
paragraph could be "Because...and now is not specific or clear as 
to the intended meaning, sufficient context may be required to 
remove undesired ambiguity."  ( similar to 'validating resolver'? )

thanks for impressive document,
k



On Tue, Jul 18, 2023 at 11:37:44AM +1000, George Michaelson wrote:
 > 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 lame "is" (or rather "was" since we're deprecating
 > it)
 > 
 > cheers, and thanks for the work on this everyone concerned.
 > 
 > -G
 > 
 > On Tue, Jul 18, 2023 at 8:40???AM Benno Overeinder  
 > wrote:
 > >
 > > 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/iddiff?url2=draft- ietf-dnsop-rfc8499bis-08.
 > >
 > > This one-week Working Group Last Call is only about the definition of
 > > "lame delegation".  As mentioned above, the wording is the result of the
 > > interim meeting, where it was identified that the original definition of
 > > "lame delegation" does not cover current operational issues and that
 > > more precise terms are preferred.
 > >
 > > We believe the current wording reflects the views shared on the mailing
 > > list over the past two months, and we ask for confirmation.  If there
 > > are strong objections to the current definition in revision -08, we
 > > return to the original rfc8499 definition.  Regardless of the outcome,
 > > after this WGLC the document will be forwarded to the IESG for publication.
 > >
 > > This WGLC will end on Monday, 24 July.
 > >
 > > Best regards,
 > >
 > > Benno
 > > for the DNSOP co-chairs
 > >
 > > ___
 > > 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] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

[Linda Dunbar]

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-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 difficult to mention the specific examples of my earlier email in the 
draft, because those documents are not yet standards documents (just I-Ds).

However, I added a more generic perspective on other use cases, including a 
hypothetical example.

> [Linda] Your description is very helpful. Can you it to the draft? Thank you.

I added a paragraph in the opening of Section 3 (which introduces the 
bootstrapping protocol) to clarify that this method is not intended to be used 
for rollovers, just for bootstrapping.

The changes are here: 
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/10/files#diff-356ec8c295379536ae015166d01de308455cded000afc5476019b3effbb2ae43

Please let me know if these address your concerns!

Thanks,
Peter

--
https://desec.io/

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

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

[Paul Vixie]

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, but it applies just as well to this type of use of TXT
RDATA resident at the same name.


Agreed, but that horse had already left the barn when we published the 
first SPF RFC 4408.
RFC 4408 was folly. TXT in a subdomain (RFC 5507 s3.2) would suit domain 
verification well (wildcards aren't a factor) and would in no way be 
precluded by the SPF design. perhaps a sub-domain under 
._wellknown.$apex, to match current style in the w3c world.


--
P Vixie

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

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

[George Michaelson]

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 lame "is" (or rather "was" since we're deprecating
it)

cheers, and thanks for the work on this everyone concerned.

-G

On Tue, Jul 18, 2023 at 8:40 AM Benno Overeinder  wrote:
>
> 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/iddiff?url2=draft- ietf-dnsop-rfc8499bis-08.
>
> This one-week Working Group Last Call is only about the definition of
> "lame delegation".  As mentioned above, the wording is the result of the
> interim meeting, where it was identified that the original definition of
> "lame delegation" does not cover current operational issues and that
> more precise terms are preferred.
>
> We believe the current wording reflects the views shared on the mailing
> list over the past two months, and we ask for confirmation.  If there
> are strong objections to the current definition in revision -08, we
> return to the original rfc8499 definition.  Regardless of the outcome,
> after this WGLC the document will be forwarded to the IESG for publication.
>
> This WGLC will end on Monday, 24 July.
>
> Best regards,
>
> Benno
> for the DNSOP co-chairs
>
> ___
> 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] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[John R. Levine]

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 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, but it applies just
as well to this type of use of TXT RDATA resident at the same name.


Agreed, but that horse had already left the barn when we published the 
first SPF RFC 4408.



* You can't delegate the (application specific) domain validation record to
a 3rd party.

* Even if you don't delegate the name to another party, you may have a
shared DNS zone where you need to be able to provide record level
permissions to the specific team that is responsible for the application in
question. This can't be done if all the apps share the same domain name.


Both good points, worth mentioning in the draft.

Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[Paul Wouters]

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 people implementing this write in house code and are not DNS 
engineers, we won’t know. Again, for my $dayjob, where we are also in need of 
customer proof of ownership of domain, the engineers started mucking with 
python-dns DNS queries until I told them to use python-unbound. So yes, if they 
didn’t have a dns engineer on staff they would have ended up with partial UDP 
packets and possible false negatives in their code.

>>> It’s literally what happened to me in the first week of my current $dayjob. 
>>> I found 5 tokens that no one knew what they were, whom they were
>> for and whether or not they were still needed.
> 
> Um, no.

John, please do not make claims about my experiences. They are mine not yours.

> I believe you don't know what they were, but that doesn't mean
> anyone or anything thought that a token for A was a token for B.

I didn’t claim that. Perhaps reread what I wrote. I said no one within the the 
company knew what or whom these were for. I did not say anything about 
collisions.

> Anyway, we agree that adding a bunch of extra stuff to SPF results is a bad 
> idea and
> that's sufficient motivation to tell people to use _names for their tokens.

It’s interesting that you care about SPF TXT records needing to parse through 
other TXT  records, but didn’t seem to care about domain validation TXT records 
needing to parse through SPF TXT records. 

Paul, respectfully agreeing with Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter Thomassen]

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 difficult to mention the specific examples of my earlier email in the 
draft, because those documents are not yet standards documents (just I-Ds).

However, I added a more generic perspective on other use cases, including a 
hypothetical example.


[Linda] Your description is very helpful. Can you it to the draft? Thank you.


I added a paragraph in the opening of Section 3 (which introduces the 
bootstrapping protocol) to clarify that this method is not intended to be used 
for rollovers, just for bootstrapping.

The changes are here: 
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/10/files#diff-356ec8c295379536ae015166d01de308455cded000afc5476019b3effbb2ae43

Please let me know if these address your concerns!

Thanks,
Peter

--
https://desec.io/

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

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

[paul=40redbarn . org]

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 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 
>> “state has mass” appears to miss the point. 
> And most servers will never see a DoS attack. 

And most servers (particularly the ones that wouldn’t see a DoS attack) 
wouldn’t notice the strain of TCP-based DNS requests. So? 

> TCP also puts much more load on recursive servers.  It slows down the 
> resolution process.  DOT and DOH put even more load on recursive and 
> authoritative servers. 

Again, missing the point, unless you believe there are going to be fewer 
TCP-based DNS queries over time and RFC 7766 should be deprecated. 

Engineering to how the Internet was in the past may not be an optimal strategy. 

Regards, 
-drc 

___ 
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] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[David Conrad]

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 
>> “state has mass” appears to miss the point.
> And most servers will never see a DoS attack.

And most servers (particularly the ones that wouldn’t see a DoS attack) 
wouldn’t notice the strain of TCP-based DNS requests. So?

> TCP also puts much more load on recursive servers.  It slows down the 
> resolution process.  DOT and DOH put even more load on recursive and 
> authoritative servers.

Again, missing the point, unless you believe there are going to be fewer 
TCP-based DNS queries over time and RFC 7766 should be deprecated.

Engineering to how the Internet was in the past may not be an optimal strategy.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

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 important point and what got me involved with the draft.
>
> > But people have been putting tokens at the apex for years and I have
> never, ever, heard of token confusion.
>
> It’s literally what happened to me in the first week of my current
> $dayjob. I found 5 tokens that no one knew what they were, whom they were
> for and whether or not they were still needed.
>

I'm glad you found out about an issue well known to many DNS administrators
at large organizations! :)

"Stuffing" data for unrelated applications into the same DNS record
(whether at the apex or further down in the zone) has at least the
following other issues:

* 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 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, but it applies just
as well to this type of use of TXT RDATA resident at the same name.

* You can't delegate the (application specific) domain validation record to
a 3rd party.

* Even if you don't delegate the name to another party, you may have a
shared DNS zone where you need to be able to provide record level
permissions to the specific team that is responsible for the application in
question. This can't be done if all the apps share the same domain name.

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

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

[Linda Dunbar]

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.org
Subject: Re: 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 examples here on 
the list, or to have additional text included in the draft. I'll give some 
answers here; if any of it should be included in the text, please let me know.


In general, ._signal. is the "home" for whatever 
the DNS operator wants to securely publish about the child, with the 
information living within a signed zone under the operator's control (e.g. 
nameserver zone), and not in the customer's zone.

This signaling mechanism is specified in general terms (Section 2), 
independently of its applications. The use case is then determined by the 
prefix and the record type.

In the case of DNSSEC bootstrapping (specified in Section 3), the prefix 
"_dsboot" is used together with CDS/CDNSKEY-type records.

Currently, no other use cases are defined, but future use cases can simply 
reference the signaling mechanism from Section 2 if they use it.
[Linda] It would be very helpful if you can include those examples in the draft 
because the information is not really "arbitrary".


One potential such use case is the key exchange that DNS providers need to 
perform between each other when multiple DNS providers sign and serve the same 
zone ("multi-signer key exchange", see 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-thomassen-dnsop-mske%2F=05%7C01%7Clinda.dunbar%40futurewei.com%7C6503e8fa6d7c41a50dd408db87191c9f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638252314189159940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=37CMAnNuKUPD7igyreQbO%2FxDTyoU5pOZElSKsr9cB%2B0%3D=0).

Another one is the discovery of NOTIFY targets for generalized notifications, 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2FJ9Ib8BhTHIwJByIA32O6i_jqDLY%2F=05%7C01%7Clinda.dunbar%40futurewei.com%7C6503e8fa6d7c41a50dd408db87191c9f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638252314189159940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=UZ8AKHlofgRfr8NFJFS4Tvu9EYBYB1AZc0tQnati0As%3D=0
 In the context discussed there, the parent would use the mechanism to announce 
who is the child's registrar. For the domain "example.org", this could be done 
at "_notify.example._signal.org" or similar.

> - Section 3.2 (Page 6). The first step is not intuitive. does it mean
> nothing needs to be performed if the child is "securely delegated"?
> How does the "securely delegated" child publish information?
The protocol enables bootstrapping of secure delegations, that is, it allows 
the parent to validate the child's CDS or CDNSKEY records at a time where the 
child does not have a DNSSEC chain of trust yet.

When the child is already securely delegated, bootstrapping is no longer 
necessary. To update the delegation's DS records, the parent can then simply 
use the child's CDS/CDNSKEY records directly, as they will be accompanied by 
signatures that can be validated using the already established chain of trust 
(RFC 7344).

So, yes, if the child is securely delegated, nothing needs to be performed 
because the delegation does not need bootstrapping anymore. -- If the operator 
wants to publish information about the child in a signaling zone, that's still 
possible, of course (see other use cases above). However, that doesn't concern 
the steps described in Section 3.2, as those only relate to how the parent can 
perform bootstrapping for the child domain.

[Linda] Your description is very helpful. Can you it to the draft? Thank you.

If you have further questions, please let me know.

Thanks,
Peter

--
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdesec.io%2F=05%7C01%7Clinda.dunbar%40futurewei.com%7C6503e8fa6d7c41a50dd408db87191c9f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638252314189159940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=UNdCGBD8zn0bK0hXG0BXiHdLqC1TRRoiqWzd7jIp01E%3D=0

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

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

[John Levine]

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 tokens?)
>
>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.

>> 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. ...
>
>It’s literally what happened to me in the first week of my current $dayjob. I 
>found 5 tokens that no one knew what they were, whom they were
>for and whether or not they were still needed.

Um, no. I believe you don't know what they were, but that doesn't mean
anyone or anything thought that a token for A was a token for B.

Anyway, we agree that adding a bunch of extra stuff to SPF results is a bad 
idea and
that's sufficient motivation to tell people to use _names for their tokens.

R's,
John

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

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

[Paul Wouters]

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/mailman/listinfo/dnsop

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

[Mark Andrews]

> 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 that people don't start using TCP in a significant way is 
>>> putting your stability in a lot of other peoples' hands.
>> also -1. state has mass. avoiding it will remain worthwhile.
> 
> 
> “Please Friendly Malicious Actor, do not send too many TCP DNS requests as it 
> might overwhelm my infrastructure”?
> 
> 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 
> “state has mass” appears to miss the point.


And most servers will never see a DoS attack.  TCP also puts much more load on 
recursive servers.  It slows down the resolution process.  DOT and DOH put even 
more load on recursive and authoritative servers.  I saw servers the other day 
that where answering UDP in ms but TCP was taking 10s of seconds to answer.  
They appear to have fixed whatever the issue was but it still happened.

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

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

[Paul Wouters]

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 of tools crafting dns packets or using 
simplistic tools that are not able to do TCP or DNSSEC. Yes we really hope they 
would use libbind or libunbound or Python-unbound, but in general it is still 
good if a response doesn’t require a resend using TCP.


> 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 important point and what got me involved with the draft.

> But people have been putting tokens at the apex for years and I have never, 
> ever, heard of token confusion.

It’s literally what happened to me in the first week of my current $dayjob. I 
found 5 tokens that no one knew what they were, whom they were for and whether 
or not they were still needed.

A draft not triggering a retransmit is better than a draft commonly triggering 
a retransmit - even independent of this being TCP or UDP based check 
applications unaware of the TC bit because the writers weren’t DNS experts.

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

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

[Peter Thomassen]

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 examples here on 
the list, or to have additional text included in the draft. I'll give some 
answers here; if any of it should be included in the text, please let me know.


In general, ._signal. is the "home" for whatever 
the DNS operator wants to securely publish about the child, with the information living within a 
signed zone under the operator's control (e.g. nameserver zone), and not in the customer's zone.

This signaling mechanism is specified in general terms (Section 2), 
independently of its applications. The use case is then determined by the 
prefix and the record type.

In the case of DNSSEC bootstrapping (specified in Section 3), the prefix 
"_dsboot" is used together with CDS/CDNSKEY-type records.

Currently, no other use cases are defined, but future use cases can simply 
reference the signaling mechanism from Section 2 if they use it.


One potential such use case is the key exchange that DNS providers need to perform 
between each other when multiple DNS providers sign and serve the same zone 
("multi-signer key exchange", see 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-mske/).

Another one is the discovery of NOTIFY targets for generalized notifications, 
https://mailarchive.ietf.org/arch/msg/dnsop/J9Ib8BhTHIwJByIA32O6i_jqDLY/ In the context discussed 
there, the parent would use the mechanism to announce who is the child's registrar. For the domain 
"example.org", this could be done at "_notify.example._signal.org" or similar.


- Section 3.2 (Page 6). The first step is not intuitive. does it mean nothing
needs to be performed if the child is "securely delegated"? How does the
"securely delegated" child publish information?

The protocol enables bootstrapping of secure delegations, that is, it allows 
the parent to validate the child's CDS or CDNSKEY records at a time where the 
child does not have a DNSSEC chain of trust yet.

When the child is already securely delegated, bootstrapping is no longer 
necessary. To update the delegation's DS records, the parent can then simply 
use the child's CDS/CDNSKEY records directly, as they will be accompanied by 
signatures that can be validated using the already established chain of trust 
(RFC 7344).

So, yes, if the child is securely delegated, nothing needs to be performed 
because the delegation does not need bootstrapping anymore. -- If the operator 
wants to publish information about the child in a signaling zone, that's still 
possible, of course (see other use cases above). However, that doesn't concern 
the steps described in Section 3.2, as those only relate to how the parent can 
perform bootstrapping for the child domain.

If you have further questions, please let me know.

Thanks,
Peter

--
https://desec.io/

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

[DNSOP] WGLC rfc8499bis for revised lame delegation definition

[Benno Overeinder]

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/iddiff?url2=draft- ietf-dnsop-rfc8499bis-08.


This one-week Working Group Last Call is only about the definition of 
"lame delegation".  As mentioned above, the wording is the result of the 
interim meeting, where it was identified that the original definition of 
"lame delegation" does not cover current operational issues and that 
more precise terms are preferred.


We believe the current wording reflects the views shared on the mailing 
list over the past two months, and we ask for confirmation.  If there 
are strong objections to the current definition in revision -08, we 
return to the original rfc8499 definition.  Regardless of the outcome, 
after this WGLC the document will be forwarded to the IESG for publication.


This WGLC will end on Monday, 24 July.

Best regards,

Benno
for the DNSOP co-chairs

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

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

[David Conrad]

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 
>> putting your stability in a lot of other peoples' hands.
> also -1. state has mass. avoiding it will remain worthwhile.


“Please Friendly Malicious Actor, do not send too many TCP DNS requests as it 
might overwhelm my infrastructure”?

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 “state 
has mass” appears to miss the point.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Linda Dunbar via Datatracker]

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 the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

Summary:
The document describes the procedure for in-band method for DNS operators to
publish arbitrary information about the zones. The description is very clear
and has a very clear description of the Security Consideration.

Here are some minor issues with the draft:
- What kind of "arbitrary information about the zones"? any examples?
- Section 3.2 (Page 6). The first step is not intuitive. does it mean nothing
needs to be performed if the child is "securely delegated"? How does the
"securely delegated" child publish information?

Thanks, Linda Dunbar



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

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

[John R Levine]

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


There's only several decades of practice and no reports of collisions, 
ever.  Remember that since it is common to publish multiple tokens for the 
same service, what everyone does is to look for the specific token they 
want and ignore everything else so even in the unlikely event that two 
people use the same tag, in practice it doesn't matter.  If you know a way 
to make 128 bit hash tokens collide, uh, some people would like to talk to 
you.


The collision argument is implausible, Just drop it and we can make the 
sensible point that you don't want to bulk up SPF responses.


R's,
John

PS: Here's that Cisco example again, sorted so you can see the multiple 
tokens per prefix.


cisco.com descriptive text "926723159-3188410"
cisco.com descriptive text "MS=ms35724259"
cisco.com descriptive text "QuoVadis=94d4ae74-ecd5-4a33-975e-a0d7f546c801"
cisco.com descriptive text "SFMC-o7HX74BQ79k7glpt_qjlF2vmZO9DpqLtYxKLwg87"
cisco.com descriptive text 
"\\200atlassian-domain-verification=blI4HshP3kJO1PV8nZFlncJ6TwVviYYxBNhkMi9wIa9DTxUjY4p1GO7O5SjiioyT"
cisco.com descriptive text 
"adobe-aem-verification=www-devint-cloud.cisco.com/24859/366173/9418f2a2-ef45-4788-9de9-91c7d19038b9"
cisco.com descriptive text 
"adobe-aem-verification=www-idev-cloud.cisco.com/24859/366204/1b990ef7-ff88-4938-bdd9-8458cc152f57"
cisco.com descriptive text 
"adobe-idp-site-verification=c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5"
cisco.com descriptive text 
"amazonses:7LyiKZmpuGja4+KbA4xX3lN69yajYKLkHH4QJcWnuwo="
cisco.com descriptive text 
"amazonses:QbUv5pPHGQxRy1vKA0J7Y/biE9oR6MTxOTI1bZIfjsw="
cisco.com descriptive text 
"amazonses:mX+ylQj+fJAfh9pr03yIR7YvjKZ1bOo5ABegqM/5pvI="
cisco.com descriptive text "apple-domain-verification=qOInipPgso3W8cmK"
cisco.com descriptive text "asv=ac90e11808e87cfbf8768e69819b1aca"
cisco.com descriptive text 
"atlassian-domain-verification=2ldosmg0o2Mhpyok1OISaSGygWU9zk6fLLWdoczXtHap9luhaHA/pwEaj2Tk6ROK"
cisco.com descriptive text 
"atlassian-domain-verification=672RcADvt8BPqsb9gCN2ZC5DoTAhUT8abC1blYKQxi/MHMaGoA/BuvjFMaWRtgd7"
cisco.com descriptive text 
"atlassian-domain-verification=7JYRlY9ijBijTJ0YS5a8/58DU7OfKAHMYRufcy0TC57j2mNceH8rg4ajRzErc22Z"
cisco.com descriptive text 
"atlassian-domain-verification=AYTzL6wSVsW0IdyQp7gwv6lwtHdpMATnb8QriqyJ0niAaZct9kdSlXvfuE4GcoxU"
cisco.com descriptive text 
"atlassian-domain-verification=Gt2demeKDLmtNc9kPZhaAHFA37DEIcmFGUd6LARvB4yjLG70s3WZhaJJ15y499sb"
cisco.com descriptive text 
"atlassian-domain-verification=UwP1ncfiphlFs+wRx8wIBSXDScwNL7Jrw7tq2rnYz3+9T5+Md9eTDRgNPCikxtOx"
cisco.com descriptive text 
"c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5"
cisco.com descriptive text 
"docker-verification=4c56633a-274e-4858-88a2-2aeceffcfd66"
cisco.com descriptive text "docusign=5e18de8e-36d0-4a8e-8e88-b7803423fa2f"
cisco.com descriptive text "docusign=95052c5f-a421-4594-9227-02ad2d86dfbe"
cisco.com descriptive text 
"duo_sso_verification=6Q7pJwSZ3damWHBcB8TNd9I5oduLRAFDDhip2pTFaa3QoIZtZnCgzjyZr5teSOWS"
cisco.com descriptive text 
"duo_sso_verification=AxenLdoqIXzjl2RJzE1BlOfkawDbDFlnbyvjAt8vcjKHBkvYwEMySDRk5QmBd66v"
cisco.com descriptive text 
"duo_sso_verification=IYdVUIrb2L95JVejSXV3hfsJVDZolQKKOPBztlD6TIgfCRSKeMuf8WgbQuFLD4aL"
cisco.com descriptive text 
"duo_sso_verification=pG21Oj5OPCxRPsWXsfbauWT9oua82cKtYUPAmsQvovKNq3xqWEcsEMEAhtXy8AFr"
cisco.com descriptive text 
"duo_sso_verification=sKMGaTln2vmQuKwaE4hKtTEY1UYn2JzAaxSZzGjkgJrKuZChN344mhIptyczoNBA"
cisco.com descriptive text 
"facebook-domain-verification=1zoxo8z7t013gpruxmhc8dkerq47vh"
cisco.com descriptive text 
"facebook-domain-verification=qr2nigspzrpa96j1nd9criovuuwino"
cisco.com descriptive text 
"fastly-domain-delegation-e9a758d22183504af2d5ab4d9a9853da-20210127"
cisco.com descriptive text 
"fastly-domain-delegation-im0VCGY5X0axEEmhXJb2-347911-20210310"
cisco.com descriptive text 
"fastly-domain-delegation-w049tcm0w48ds-341317-20210209"
cisco.com descriptive text 
"fastly-domain-delegation-z9slsbDdX0-368365-2021-05-14"
cisco.com descriptive text 
"google-site-verification=9MlQU9MMQ1jHLMUkONKe6QzZ-ZIGRv0BCD1_rY1Zdmc"
cisco.com descriptive text 
"google-site-verification=V3t2K3dvr9fcd1YWwwanSmebEOO_UNTP06HR2_gUO5M"
cisco.com descriptive text 
"google-site-verification=WmdDuSXl3PMb-48qcY6VUbW9kzNPe46zn9uDwgB2wX0"
cisco.com descriptive text 
"google-site-verification=lW5eqPMJI4VrLc28YW-JBkqA-FDNVnhFCXQVDvFqZTo"
cisco.com descriptive text 
"google-site-verification=qPS9ZkoQ-Og1rBrM1_N7z-tNJNy2BVxE8lw6SB2iFdk"
cisco.com descriptive text 
"google-site-verification=r-K1CIdXkgRWxZstUHtVyM2UfwflnGgr4AR9_Qhk28Q"
cisco.com descriptive text 

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

[Paul Vixie]

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 traffic in a 
statistically meaningful way causes issues.


I see UDP as a legacy transport, required for backwards comparability 
but that's about it. The writing is very much on the wall, there.


-1.

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 putting your stability in a lot of other peoples' hands.

also -1. state has mass. avoiding it will remain worthwhile.

--
P Vixie

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

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

[Joe Abley]

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 way causes issues.

I see UDP as a legacy transport, required for backwards comparability but 
that's about it. The writing is very much on the wall, there.

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 putting 
your stability in a lot of other peoples' hands.

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

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

[Brian Dickson]

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-auth is much more of concern,
> particularly
> > when the underlying cause (large RRsets) is preventable.
>
> I take your point, but we're not talking about a lot of traffic.  If any
> particular token is checked as often as once a day, that's a lot.  At what
> scale does the TCP traffic become an issue?
>

The stuffed apex does not only include those tokens, e.g. SPF and friends,
which get queried A LOT.
So, adding validation tokens to the apex causes collateral damage via
non-token apex records.

TCP traffic is several orders of magnitude more expensive than UDP.
Anything that bumps up the proportion of TCP traffic in a statistically
meaningful way causes issues.

E.g. Suppose TCP is 1% of traffic. Something bumping it to 1.5% might seem
benign, but in reality is causing 50% extra cost.
Whatever the impact, if it does not have some corresponding benefit
overall, or particularly relative to op-ex vs revenue, that's a bad outcome.

DNSSEC is maybe a red herring, because there are operational benefits on
the overall query ecosystem.
Specifically, with aggressive NSEC, resolver-auth load (and particularly
DOS/DDOS triggered load) actually goes down A LOT, in the worst case
scenarios.


>
> >> 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.
> >
> > The technical term would be "collision" rather than "confusion".
> > One harm of collision is the impact on automation. Whether at the apex or
> > in underscore prefixes, the collision "space" suffers from the "birthday
> > paradox" scaling problem.
>
> The birthday paradox is relevant if you only have 366 birthdays, but not
> if people are using 20 character identifier strings which give you a
> 10^25 point name space.  (See the Cisco TXT records in my previous
> message.)  This is an aesthetic preference, not a technical one.
>

In the absence of the aforementioned draft, there is no specific guidance
that would lead ALL token issuers to use 20 character identifiers.
And without doing so, the likelihood of some issuers having conflicting
semantic choices (and thus token choices) is non-trivial.

E.g. any mail package that gets used, or hosting software, or third party
apps generally.

E.g. I've seen a software vendor "foo" with their registered domain
"foo.example", who have lots of customers running "foo" as a service.
The vendor was given guidance to use "_foo_example" (an encoding of their
domain) rather than "_foo", to protect themselves from collisions.
But there is also a likelihood of some non-zero subset of operators of "foo
as a service" picking "_foo" and causing collisions.
The draft would provide sufficient guidance to reduce the latter from being
relatively common (lots of assumptions etc., but better than no guidance.)

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

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

[John R Levine]

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 cause (large RRsets) is preventable.


I take your point, but we're not talking about a lot of traffic.  If any 
particular token is checked as often as once a day, that's a lot.  At what 
scale does the TCP traffic become an issue?



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.


The technical term would be "collision" rather than "confusion".
One harm of collision is the impact on automation. Whether at the apex or
in underscore prefixes, the collision "space" suffers from the "birthday
paradox" scaling problem.


The birthday paradox is relevant if you only have 366 birthdays, but not 
if people are using 20 character identifier strings which give you a 
10^25 point name space.  (See the Cisco TXT records in my previous 
message.)  This is an aesthetic preference, not a technical one.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[Brian Dickson]

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 there.
>
> 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?)
>

Hi, John,
I believe you've conflated two different things here.

DoT and DoH are (for the most part) used in client-recursive
communications. (I have no comment on those vis a vis TCP).

TCP being triggered on resolver-auth is much more of concern, particularly
when the underlying cause (large RRsets) is preventable.

DNSSEC impact is mitigated largely by migration to algorithms that are
sufficiently small in RRSIG and DNSKEY sizes to avoid triggering TCP, such
as alg 13.

As an auth operator (at scale), TCP being bad is very obvious (to us), and
I'd hope persuasive without having to provide detailed stats whenever this
question is raised.

Endorsing this (verification techniques draft) would likely result in the
eventual migration of such validation records out of the apex, i.e.
un-stuffing the apex (in multiple senses).
At a minimum it would "stop the bleeding" prior to actually stitching the
wound(s), figuratively speaking.


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

The technical term would be "collision" rather than "confusion".
One harm of collision is the impact on automation. Whether at the apex or
in underscore prefixes, the collision "space" suffers from the "birthday
paradox" scaling problem.
It isn't whether a particular token collides, it is whether any two (or
more) tokens collide.
That situation won't occur everywhere, but if it occurs anywhere (possibly
well after the token authors have used it for a lot of issued tokens), it
becomes a real operational issue for the domain owners.
The first collision might not happen for a while, and after it does, the
fix would require one or more of the token issuers to change what they are
using.
That in turn, would not be a pleasant situation to sort out. Consider the
impact if the token issuers are similar in size, or if both are "large" for
some value of large.
(Moving the name of the token to part of the name rather than the
TXT content doesn't actually change the collision situation, but the other
recommendations on selection of token do improve it.)


>
> But people have been putting tokens at the apex for years and I have
> never, ever, heard of token confusion.
>

You are looking for anecdotes (or claim to not have any).
IMNSHO, what you should be looking for is statistics.
Or you could just ignore this whole thing. I don't think it impacts you at
all, either way, but does impact lots of other folks.

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

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

[John R Levine]

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 argument 
that triggering TCP is bad stopped being persuasive a while ago.  (Don't 
we hope people sign the DNS responses with the tokens?)


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.


But people have been putting tokens at the apex for years and I have 
never, ever, heard of token confusion.  "It's ugly" isn't going to fly. I 
would take the whole thing out unless there is a technical basis I've 
missed.


$ host -t txt cisco.com
cisco.com descriptive text 
"workplace-domain-verification=Uhv7QPQ22nbuD3vG0jspf7R6LruYoS"
cisco.com descriptive text 
"google-site-verification=r-K1CIdXkgRWxZstUHtVyM2UfwflnGgr4AR9_Qhk28Q"
cisco.com descriptive text 
"google-site-verification=WmdDuSXl3PMb-48qcY6VUbW9kzNPe46zn9uDwgB2wX0"
cisco.com descriptive text 
"atlassian-domain-verification=UwP1ncfiphlFs+wRx8wIBSXDScwNL7Jrw7tq2rnYz3+9T5+Md9eTDRgNPCikxtOx"
cisco.com descriptive text 
"intercom-domain-validation=8806e2f9-7626-4d9e-ae4d-2d655028629a"
cisco.com descriptive text 
"google-site-verification=V3t2K3dvr9fcd1YWwwanSmebEOO_UNTP06HR2_gUO5M"
cisco.com descriptive text 
"google-site-verification=lW5eqPMJI4VrLc28YW-JBkqA-FDNVnhFCXQVDvFqZTo"
cisco.com descriptive text 
"atlassian-domain-verification=AYTzL6wSVsW0IdyQp7gwv6lwtHdpMATnb8QriqyJ0niAaZct9kdSlXvfuE4GcoxU"
cisco.com descriptive text 
"fastly-domain-delegation-e9a758d22183504af2d5ab4d9a9853da-20210127"
cisco.com descriptive text 
"duo_sso_verification=AxenLdoqIXzjl2RJzE1BlOfkawDbDFlnbyvjAt8vcjKHBkvYwEMySDRk5QmBd66v"
cisco.com descriptive text 
"fastly-domain-delegation-z9slsbDdX0-368365-2021-05-14"
cisco.com descriptive text 
"duo_sso_verification=sKMGaTln2vmQuKwaE4hKtTEY1UYn2JzAaxSZzGjkgJrKuZChN344mhIptyczoNBA"
cisco.com descriptive text 
"adobe-aem-verification=www-devint-cloud.cisco.com/24859/366173/9418f2a2-ef45-4788-9de9-91c7d19038b9"
cisco.com descriptive text 
"c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5"
cisco.com descriptive text 
"atlassian-domain-verification=7JYRlY9ijBijTJ0YS5a8/58DU7OfKAHMYRufcy0TC57j2mNceH8rg4ajRzErc22Z"
cisco.com descriptive text 
"\\200atlassian-domain-verification=blI4HshP3kJO1PV8nZFlncJ6TwVviYYxBNhkMi9wIa9DTxUjY4p1GO7O5SjiioyT"
cisco.com descriptive text 
"mZvHszGlmDhvPOUKL+6JMiw/VtckyOMKjcw1PLcjYowxM2PVLX2xG0ZSgdHRm8HXfaaGR2pMvhIrBX1tX3aKRQ=="
cisco.com descriptive text 
"adobe-idp-site-verification=c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5"
cisco.com descriptive text 
"onetrust-domain-verification=20345dd0c33946f299f14c1498b41f67"
cisco.com descriptive text 
"stripe-verification=217ec5836204d6fc0d236f5751724029c9b39530696e322a862b2f2f5fe75529"
cisco.com descriptive text 
"sending_domain731003=25e34fadea88da7e64f0fab1e32d094f1f1e0fb2b97622deac2521f7a2c5b2bc"
cisco.com descriptive text 
"atlassian-domain-verification=672RcADvt8BPqsb9gCN2ZC5DoTAhUT8abC1blYKQxi/MHMaGoA/BuvjFMaWRtgd7"
cisco.com descriptive text 
"google-site-verification=qPS9ZkoQ-Og1rBrM1_N7z-tNJNy2BVxE8lw6SB2iFdk"
cisco.com descriptive text 
"identrust_validate=ZMG4IyVxNwmt3vKpPoFmxSuWW+4fMc/M4kCCnBaPUMYv"
cisco.com descriptive text 
"atlassian-domain-verification=2ldosmg0o2Mhpyok1OISaSGygWU9zk6fLLWdoczXtHap9luhaHA/pwEaj2Tk6ROK"
cisco.com descriptive text 
"docker-verification=4c56633a-274e-4858-88a2-2aeceffcfd66"
cisco.com descriptive text "926723159-3188410"
cisco.com descriptive text 
"facebook-domain-verification=qr2nigspzrpa96j1nd9criovuuwino"
cisco.com descriptive text 
"wiz-domain-verification=af241e6396696eedf1b361891435f6b21bdebb5621941d99279298c076b5bf5f"
cisco.com descriptive text 
"duo_sso_verification=IYdVUIrb2L95JVejSXV3hfsJVDZolQKKOPBztlD6TIgfCRSKeMuf8WgbQuFLD4aL"
cisco.com descriptive text 
"duo_sso_verification=pG21Oj5OPCxRPsWXsfbauWT9oua82cKtYUPAmsQvovKNq3xqWEcsEMEAhtXy8AFr"
cisco.com descriptive text 
"adobe-aem-verification=www-idev-cloud.cisco.com/24859/366204/1b990ef7-ff88-4938-bdd9-8458cc152f57"
cisco.com descriptive text 
"miro-verification=53bf5ccd47cb6239fe5cf14c3b328050dd5679ac"
cisco.com descriptive text 
"fastly-domain-delegation-im0VCGY5X0axEEmhXJb2-347911-20210310"
cisco.com descriptive text "apple-domain-verification=qOInipPgso3W8cmK"
cisco.com descriptive text 
"facebook-domain-verification=1zoxo8z7t013gpruxmhc8dkerq47vh"
cisco.com descriptive text "v=spf1 redirect=spfa._spf.cisco.com"
cisco.com descriptive text "SFMC-o7HX74BQ79k7glpt_qjlF2vmZO9DpqLtYxKLwg87"
cisco.com descriptive text 
"amazonses:mX+ylQj+fJAfh9pr03yIR7YvjKZ1bOo5ABegqM/5pvI="
cisco.com descriptive text 
"duo_sso_verification=6Q7pJwSZ3damWHBcB8TNd9I5oduLRAFDDhip2pTFaa3QoIZtZnCgzjyZr5teSOWS"
cisco.com descriptive 

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

[Paul Wouters]

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

Paul

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

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

[Florian Obser]

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 result in fragmentation
>>
>>That's not correct. If the response does not fit into a single DNS UDP
>>packet, it's not a valid response and can't be send.
>>
>>New: If the size of the response is large enough that it does not fit
>>into a single IP packet this may result in fragmentation
>
> That's not right either. If it doesn't fit in a UDP packet, the

true

> response will be truncated and the client will retry over TCP. If the
> UDP packet exceeds PMTU, the packet will be fragmented in transit but
> there's no simple way to know that at the application level. There's a
> reason EDNS0 let the client suggest a packet size limit, and people
> have been tuning their use of it since 1999.
>
> 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.
>
> R's,
> John

-- 
In my defence, I have been left unsupervised.

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

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

[John Levine]

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 response does not fit into a single DNS UDP
>packet, it's not a valid response and can't be send.
>
>New: If the size of the response is large enough that it does not fit
>into a single IP packet this may result in fragmentation

That's not right either. If it doesn't fit in a UDP packet, the
response will be truncated and the client will retry over TCP. If the
UDP packet exceeds PMTU, the packet will be fragmented in transit but
there's no simple way to know that at the application level. There's a
reason EDNS0 let the client suggest a packet size limit, and people
have been tuning their use of it since 1999.

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
TCP, you already have worse problems, like DNSSEC doesn't work.

R's,
John

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

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

[Florian Obser]

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 of "one"
would be better. "One" sounds like there will ever be exactly one
temporary DNS record in the zone to prove ownership. Which is probably
not true if you need to prove ownership to multiple
services. Therefore:

old: Generally only one temporary DNS record is sufficient
new: Generally a temporary DNS record is sufficient

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 response does not fit into a single DNS UDP
packet, it's not a valid response and can't be send.

New: If the size of the response is large enough that it does not fit
into a single IP packet this may result in fragmentation

> Other possible issues may occur.  If a TXT record (or any other
> record type) is designed to be place at the same domain name...

s/place/placed/

5.2.  TXT Record
> when the DNS administrator receives the information, especially to
> consumers who are not DNS experts.

s/to consumers/from consumers/

5.2.1.  Metadata For Expiry
> Providers MUST provide clear instructions

I don't think there would be an interoperability issue or the protocol
would fail when providers provide unclear instructions or no
instructions at all, so: s/MUST/SHOULD/

I'd like to see a definition / reference for the time format. xkcd
1179 is relevant...

-- 
In my defence, I have been left unsupervised.

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

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

[Benno Overeinder]

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 incorporates the 
feedback.  Some issues may need to be addressed in a subsequent revision 
before the document is sent to the IESG.  We are coordinating this 
further with the authors.


Best regards,

-- Benno

On 11/07/2023 00:35, Viktor Dukhovni wrote:

On Mon, Jul 10, 2023 at 10:27:45PM +0100, Roy Arends wrote:


Right, but surely the monitoring agent can decide whether to solicit
such a prefix label or not.  That is whether an "_er" prefix label is
signalled is a *local matter* betweent the authoritative server
signalling the option and the monitoring agent.


I agree that a monitoring agent can specify a domain that may include
a separator as the least significant label. However, it also requires
the monitoring agent to understand that it should sometimes include
this separator, and that it may be redundant at other times.


If all the monitoring agent's "customers" (authoritative servers that
return its "suffix" in the new option) are informed to signal an
"_er.agent.example" name, there's no "sometimes".  The agent, by mutual
agreement with the nameservers it supports can choose whatever suffix
format meets its needs, fixed across all customers, or customer-specific.

I haven't yet seen a reason to insist on a fixed suffix pattern.  The
resolver just stutters back the suffix it was handed by the
authoritative server's extension payload.  What problem does mandating
the least significant label of the suffix solve, that can't be solved by
just signalling the desired suffix, special label and all?


It assumes that those running the authoritative server that returns
the agent domain and those that run the reporting agent are in sync.
Those are a lot of assumptions.


If they're not in sync, surely reporting will be broken, whether or not
an "_er" suffix label is used.


  Why should resolvers have to be responsible for this?


Because this separating label is trivial to include and avoids a lot of hassle.


The hassle in question remains unclear.  I see two relevant/likely
deployment models:

 * Self-hosted reporting, directly by the authoritative server:

 - Error reports are special by virtue of a dedicated qname
   suffix and perhaps qtype.

 - No special coördination required, the server both publishes
   and consumes the error reporting suffix.

  * Outsourced/centralised reporting, via server IPs dedicated to
error report processing.

  - Here again no need for "_er", because all queries are
presumptively error reports, and if the signal from the
"customer" auth server was wrong (whether or not an "_er"
label is included) the error report will not be handled
correctly.

   - If the signal has the correct (mutually agreed) suffix,
 again no problem.

   - And of course the monitoring agent can specify the use
 of "_er" (or whatever) if that's convenient.

What use-case actually benefits from the "_er" LSL (least-significant
label) in the signal?  How is this benefit not obtained by mutual
agreement between the monitoring agent and its customers?


The sole purpose of the leading “least-significant” “_er” is to
distinguish between qname-minimized queries (for lack of a better
term) and “full” queries. I understand that you argue that a
monitoring agent can determine this without the _er labels (as
described below), but that seem suboptimal to me.


The qname minimised query (whether or not a dedicated qtype is used)
will be for "A" or "NS" records, not TXT or the dedicated qtype, so
there's no need for "_er" in the first label, the qtype is sufficient.


RFC9156 contains no hard requirement to use A/NS. So I’m not confident
that all current and future qname-minimisation implementations use
A/NS.


This is where this document can specify that qname minimised error
reports MUST use a qtype other than the qtype for the final error
report.


However, to avoid forwarding junk reports to the monitoring agent, a
resolver may well sensibly choose to not forward such queries, and
only source them internally.


I’m not following.


If the qtype is "TXT", then an open resolver is easily subject to
proxying forged error reports purporting errors that the resolver did
not observe.  Some client of the open resolver sends an explicit query
for:

 . IN TXT ?

which then looks like an error report from *that* resolver to the
monitoring agent.  If instead we have a dedicated qtype for error
reports, it becomes a simple matter of refusing to iterate queries for

 . IN  ?

Any resolver wanting to report an error must do so directly, not via a
forwarder.  Especially because the 

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

[Paul Wouters]

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 of the
>  zone apex CERT MRs and associated RRSIGs is trivially denied  by
>  an on-path attacker.

Indeed, the lack of a chain of trust via DS records means the CERT and RRSIG 
records can just be removed from the answers.
Encoding the presence somehow in the NS names (aka dnscurve style) also doesn’t 
help because such an approach requires authenticated connections from the root 
down and doesn’t work through dns caches. The exact reason why dnscurve was 
non-viable.

And finally as with proposals to replace ipv6 with something better, it would 
take years for the software to be written and deployed so it questionable 
whether fragmenting the dns world into two different methods to accomplish the 
same thing would speed up the security of DNS. Better focus on removing 
roadblocks that causes people to postpone DNSSEC deployments.

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

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

[Peter van Dijk]

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 up Working Group Last
> Call comment period. We are looking for substantive comments regarding
> the changes made, and if they are enough to address concerns raised.  

As Vladimir also said in his dnsdir review, this document is in way
better shape than it was.

I do see one obstacle.

In section 3.1, the draft says:

> 2. UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF)
bit" [RFC0791] on IPv4.

Then in Appendix D (Known Implementations), all implementations have
indicated they do *not* set the DF bit. It seems wrong to RECOMMEND
something, especially in a document targeted for BCP, that nobody is
doing.

> This comment period will end Wednesday July 12, 2023.   If there
> are substantive comments raised, we can address these during the
> meeting.
> 
A friendly request: please indicate Last Calls in the Subject! I missed
this one until now.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop