[DNSOP] Resolver cooperation (re: key tags but not only key tags)

[Brian Dickson]

Thinking about the KeyTrap problem, and the discussions here about
potential approaches to mitigation of "bad stuff", one thought that came to
mind was that everyone would necessarily have the same data to crunch (or
avoid), and there might be ways to leverage the work required.

This is just an initial though, and might have obvious shortcomings, but
those might have suitable ways of being avoided.

The general idea would involve:

   - Some kind of identification and trust for resolvers or resolver
   operators
   - Attestation of specific tuples as being problematic
   - Specification on what the problem is
   - Possibly proof of work or similar
   - A place to publish those results for the benefit of other resolver
   operators
   - Local policy on whether/how to trust the published results
   - Methods for both manual and automated publication

The example use case would be a few operators of large well-known resolver
sets, publishing to some well-known location when DNS entries are found
which exhibit specific criteria. Other operators could have local
configurations of quorum (how many reports by different operators are
required), which operators to trust (or rules for establishing trust such
as GPG-type things).

If the details can be worked out and such a system were deployed, it would
have the potential to significantly raise the bar for attackers.
It could also provide mechanisms that scale, for warning operators of new
attacks (presuming some sort of language or encoding for what the problem
seen is or which DNS tuples are problematic.)
The attestation etc would be intended to prevent attackers causing DOS via
false positives. There might be benefit to revocation of reports based on a
counter-quorum, if that activity is expected or observed.

There are obviously scaling issues in adding this to things resolvers need
to do. Suitable scaling approaches for publication and signaling might be
able to be established, or perhaps software vendors could add ways for
publication/consumption on their respective packages, similar to e.g. code
signing or fingerprint publications.

Any reactions and feedback are welcome, or just discuss it in a thread...

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

Re: [DNSOP] [Ext] About key tags

[Mark Andrews]

But we can state that they should be avoided when generating new DNSKEYs. BIND 
has been avoiding key tag collisions for 2 decades now when generating new 
keys. Multi-signers all have to have the current published DNSKEY RRset which 
includes *all* DNSKEYs as part of their publication process. Key generation 
just needs to avoid key tag collisions with this set of DNSKEYs. The broker can 
reject new duplicate key tags if they happen to occur at the combining stage 
forcing a new key generation.  Unless multi-signers synchronise DNSKEY 
generation the later should be a rare event.

> On 16 Feb 2024, at 07:53, Bob Harold  wrote:
> 
> I don't think we can completely avoid tag collisions in a multi-signer 
> situation.  They could detect and correct a collision, but due to the long 
> TTL's in many TLD's, that could take 24 hours.  So I think resolvers should 
> allow for at least a few collisions and not fail on the first one.
> 
> -- 
> Bob Harold
> 
> 
> On Thu, Feb 15, 2024 at 3:39 PM Ralf Weber  wrote:
> Moin!
> 
> On 15 Feb 2024, at 11:35, Paul Hoffman wrote:
> > Resolvers can already have policies that don't allow them; that has been 
> > true for 20 years. There is nothing stopping any resolver from saying "I 
> > found a keytag collision so I'm not going to validate". Fortunately, we're 
> > seeing resolvers instead saying "I'll bound the amount of work I do when I 
> > see colliding keytags".
> 
> I don’t know which resolver had key tag collision limits for 20 years, but am 
> happy to be educated. Anyway outlawing key tag collisions was and IMHO still 
> is on the table. It’s just that we didn’t want to break anything immediately.
> 
> 
> > Compare that to "we're going to change a 20-year-old spec, wait for years 
> > for the changes to be implemented, and only then change the way validators 
> > work". The current situation is much more sustainable.
> 
> We have had in recent history a lot of drafts that even were implemented 
> before they became RFC and had much larger failure ratios. I see no reason to 
> not immediately implement and RFC that says key tag collisions are not 
> allowed.
> 
> So long
> -Ralf
> ——-
> Ralf Weber
> 
> ___
> 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

-- 
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] [Ext] About key tags

[Ted Lemon]

A key tag collision could trigger a cache flush.

Op do 15 feb 2024 om 15:53 schreef Bob Harold 

> I don't think we can completely avoid tag collisions in a multi-signer
> situation.  They could detect and correct a collision, but due to the long
> TTL's in many TLD's, that could take 24 hours.  So I think resolvers should
> allow for at least a few collisions and not fail on the first one.
>
>
> --
> Bob Harold
>
>
> On Thu, Feb 15, 2024 at 3:39 PM Ralf Weber  wrote:
>
>> Moin!
>>
>> On 15 Feb 2024, at 11:35, Paul Hoffman wrote:
>> > Resolvers can already have policies that don't allow them; that has
>> been true for 20 years. There is nothing stopping any resolver from saying
>> "I found a keytag collision so I'm not going to validate". Fortunately,
>> we're seeing resolvers instead saying "I'll bound the amount of work I do
>> when I see colliding keytags".
>>
>> I don’t know which resolver had key tag collision limits for 20 years,
>> but am happy to be educated. Anyway outlawing key tag collisions was and
>> IMHO still is on the table. It’s just that we didn’t want to break anything
>> immediately.
>>
>>
>> > Compare that to "we're going to change a 20-year-old spec, wait for
>> years for the changes to be implemented, and only then change the way
>> validators work". The current situation is much more sustainable.
>>
>> We have had in recent history a lot of drafts that even were implemented
>> before they became RFC and had much larger failure ratios. I see no reason
>> to not immediately implement and RFC that says key tag collisions are not
>> allowed.
>>
>> So long
>> -Ralf
>> ——-
>> Ralf Weber
>>
>> ___
>> 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] About key tags

[Bob Harold]

I don't think we can completely avoid tag collisions in a multi-signer
situation.  They could detect and correct a collision, but due to the long
TTL's in many TLD's, that could take 24 hours.  So I think resolvers should
allow for at least a few collisions and not fail on the first one.

-- 
Bob Harold


On Thu, Feb 15, 2024 at 3:39 PM Ralf Weber  wrote:

> Moin!
>
> On 15 Feb 2024, at 11:35, Paul Hoffman wrote:
> > Resolvers can already have policies that don't allow them; that has been
> true for 20 years. There is nothing stopping any resolver from saying "I
> found a keytag collision so I'm not going to validate". Fortunately, we're
> seeing resolvers instead saying "I'll bound the amount of work I do when I
> see colliding keytags".
>
> I don’t know which resolver had key tag collision limits for 20 years, but
> am happy to be educated. Anyway outlawing key tag collisions was and IMHO
> still is on the table. It’s just that we didn’t want to break anything
> immediately.
>
>
> > Compare that to "we're going to change a 20-year-old spec, wait for
> years for the changes to be implemented, and only then change the way
> validators work". The current situation is much more sustainable.
>
> We have had in recent history a lot of drafts that even were implemented
> before they became RFC and had much larger failure ratios. I see no reason
> to not immediately implement and RFC that says key tag collisions are not
> allowed.
>
> So long
> -Ralf
> ——-
> Ralf Weber
>
> ___
> 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] About key tags

[Ralf Weber]

Moin!

On 15 Feb 2024, at 11:35, Paul Hoffman wrote:
> Resolvers can already have policies that don't allow them; that has been true 
> for 20 years. There is nothing stopping any resolver from saying "I found a 
> keytag collision so I'm not going to validate". Fortunately, we're seeing 
> resolvers instead saying "I'll bound the amount of work I do when I see 
> colliding keytags".

I don’t know which resolver had key tag collision limits for 20 years, but am 
happy to be educated. Anyway outlawing key tag collisions was and IMHO still is 
on the table. It’s just that we didn’t want to break anything immediately.


> Compare that to "we're going to change a 20-year-old spec, wait for years for 
> the changes to be implemented, and only then change the way validators work". 
> The current situation is much more sustainable.

We have had in recent history a lot of drafts that even were implemented before 
they became RFC and had much larger failure ratios. I see no reason to not 
immediately implement and RFC that says key tag collisions are not allowed.

So long
-Ralf
——-
Ralf Weber

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

Re: [DNSOP] [Ext] About key tags

[Ralf Weber]

Moin!

On 15 Feb 2024, at 11:17, Paul Wouters wrote:
> Resolvers would have disabled dnssec to remain alive.

So you are saying we should disable security features when under attack? Should 
we have disabled http/2 when the rapid reset attack came around? Sorry but I 
don’t think that is sound advice, and it also would have take some time to 
figure that out.


> Also not at all something nice to happen, but the Internet in fact would not 
> have died.

The whole Internet not, large portions of it yes. I don’t think people not 
involved have grasped the severity of the KeyTrap vulnerability, but maybe this 
will sink in once people read and understood the paper. I still remember my 
pale face when they showed us what a single packet could do. This was the worst 
DNS vulnerability since Kaminsky 2008 and it attacked the mechanism we decided 
to use to defend against Kaminsky (DNSSEC).


> The IETF isn't the protocol police. It does not do "flag days" although
> the DNS community has certainly run a few events like that (all of which
> I opposed other than the EDNS0 workaround issue). While there is a good
> use case for flag days for cutting of a long tail of RFC violating legacy,
> eg like cutting EDNS0 workarounds after 20 years, there has not yet been
> an RFC stating that keytags are not allowed to be duplicate. As such,
> a flag day is not appropriate. If you publish an RFC, then wait 20 years,
> then a flag day could be appropriate. Of course, that's just the view of
> the IETF that does not do flag days.

Hmm I thought if we publish an RFC that updates the DNSSEC RFCs to not allow 
keytag collisions I could change my resolver tomorrow and be RFC compliant. 
There is no need to wait 20 years or did I miss something?

So long
-Ralf
——-
Ralf Weber

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

Re: [DNSOP] [Ext] About key tags

[Paul Hoffman]

On Feb 15, 2024, at 10:03, Ralf Weber  wrote:
> 
> Moin!
> 
> On 15 Feb 2024, at 9:53, Paul Hoffman wrote:
>>> A fairly simple way to deal with this issue is a Flag Day. As Ralf said in 
>>> a later post, the number of zones with colliding key tags is relatively 
>>> small.
>> 
>> Anything above zero is significant.
> 
> If you are waiting for zero you might wait forever.

Yes, exactly.

>>> It would certainly be reasonable to declare that at some time in the 
>>> future, colliding keys will not be handled by validators.
>> 
>> Why? Many people on this thread have said they have or will implement caps 
>> on how many collisions for a key set they will allow. An operational change 
>> such as that is vastly easier to implement than a flag day, and gets better 
>> results.
> 
> There is a difference between what a lot of people on this thread did to keep 
> the Internet alive and what is a good solution going forward. I think long 
> term Brian and Petr are right that key collisions should not be allowed.

Resolvers can already have policies that don't allow them; that has been true 
for 20 years. There is nothing stopping any resolver from saying "I found a 
keytag collision so I'm not going to validate". Fortunately, we're seeing 
resolvers instead saying "I'll bound the amount of work I do when I see 
colliding keytags". 

Compare that to "we're going to change a 20-year-old spec, wait for years for 
the changes to be implemented, and only then change the way validators work". 
The current situation is much more sustainable.

--Paul Hoffman

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

Re: [DNSOP] [Ext] About key tags

[Paul Wouters]

On Thu, 15 Feb 2024, Ralf Weber wrote:


There is a difference between what a lot of people on this thread did to keep 
the Internet alive


Resolvers would have disabled dnssec to remain alive. Also not at all
something nice to happen, but the Internet in fact would not have died.
I am super happy this got prevented and kudos to everyone who got
together to do this. I assume at this point, the public DNS resolvers
upgraded, but most other software/services is still in the pipeline,
and the internet is still with us.

The IETF isn't the protocol police. It does not do "flag days" although
the DNS community has certainly run a few events like that (all of which
I opposed other than the EDNS0 workaround issue). While there is a good
use case for flag days for cutting of a long tail of RFC violating legacy,
eg like cutting EDNS0 workarounds after 20 years, there has not yet been
an RFC stating that keytags are not allowed to be duplicate. As such,
a flag day is not appropriate. If you publish an RFC, then wait 20 years,
then a flag day could be appropriate. Of course, that's just the view of
the IETF that does not do flag days. The IETF instead nudges people to
do the right thing using BCPs (eg DNSSEC algorithm guidance of RFC8624,
maximum NSEC3 iterations in RFC9276), bis document updates, moving RFCs
to Historic status, and moving RFCs from Experimental to Standard track.

Other communities could surely decide to violate the RFCs and get together
and issue a flag day event in the near future. It would be the wrong
thing to do.

Paul

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

Re: [DNSOP] [Ext] About key tags

[Edward Lewis]

On 2/15/24, 12:49, "Wellington, Brian"  wrote:
>A fairly simple way to deal with this issue is a Flag Day.  As Ralf said in a 
>later post, the number of zones with colliding key tags is relatively small.  
>It would certainly be reasonable to declare that at some time in the future, 
>colliding keys will not be handled by validators.

Thinking:
1) Operators need to be able to tell if they have colliding key tags.  
(Mitigating is as simple [or complex] as a key roll.)
2) The recent colliding-key-tag TLD outage was related to key management, not 
validation.
3) Resource consumption issues in validation is wider than key tag collision.

I'd save a flag day for a more general treatment of validator resource 
consumption - imposing limits on key tags, number of signatures to try, levels 
of dnssec-signed indirection (CNAME chains), and so on.

Getting validators to "ban" collisions doesn't seem the to be the right 
direction, given that validators are fine with "sane" levels of collisions.  
Realizing "sane" is a very subjective word.


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

Re: [DNSOP] [Ext] About key tags

[Ralf Weber]

Moin!

On 15 Feb 2024, at 9:53, Paul Hoffman wrote:
>> A fairly simple way to deal with this issue is a Flag Day. As Ralf said in a 
>> later post, the number of zones with colliding key tags is relatively small.
>
> Anything above zero is significant.

If you are waiting for zero you might wait forever.


>>  It would certainly be reasonable to declare that at some time in the 
>> future, colliding keys will not be handled by validators.
>
> Why? Many people on this thread have said they have or will implement caps on 
> how many collisions for a key set they will allow. An operational change such 
> as that is vastly easier to implement than a flag day, and gets better 
> results.

There is a difference between what a lot of people on this thread did to keep 
the Internet alive and what is a good solution going forward. I think long term 
Brian and Petr are right that key collisions should not be allowed.

So long
-Ralf
——-
Ralf Weber

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

Re: [DNSOP] [Ext] About key tags

[Wellington, Brian]

> On Feb 15, 2024, at 9:53 AM, Paul Hoffman  wrote:
> 
> On Feb 15, 2024, at 09:48, Wellington, Brian 
>  > wrote:
>> 
>> 
>> 
>>> On Feb 15, 2024, at 6:02 AM, Paul Wouters  wrote:
>>> 
>>> On Feb 15, 2024, at 04:37, Petr Špaček  wrote:
 
 If you think colliding keys should be allowed, please propose your own 
 limits for sensible behavior.
>>> 
>>> I do think they need to be allowed because they have always been allowed so 
>>> far. Reasons for not allowing them seems to be implementation details. 
>>> Sure, if the RFCs had warned implementers this wouldn’t have happened, and 
>>> we can learn from that (and I gained appreciation and validation for 
>>> whining about security and operational consideration sections)
>>> 
>>> You seem willing to (statistically) throw 1/65536 zones under the bus. That 
>>> would roughly be 2500 .com domains if all of .com was signed (without key 
>>> sharing)
>>> 
>>> I don’t see why we should do this.
>> 
>> A fairly simple way to deal with this issue is a Flag Day. As Ralf said in a 
>> later post, the number of zones with colliding key tags is relatively small.
> 
> Anything above zero is significant.

Obviously.  That’s why I suggested a Flag Day in the future, not an immediate 
change.  That would give operators and implementors enough time to update 
existing zones and software.

> 
>> It would certainly be reasonable to declare that at some time in the future, 
>> colliding keys will not be handled by validators.
> 
> Why? Many people on this thread have said they have or will implement caps on 
> how many collisions for a key set they will allow. An operational change such 
> as that is vastly easier to implement than a flag day, and gets better 
> results.

One reason is to avoid having another discussion like this after the next issue 
related to key tag collisions.  Another is to simplify validator 
implementations, which reduces the risk of bugs.  Another is to simplify 
operational debugging; it’s a lot easier to figure out why something’s failing 
if keys are uniquely identified within the protocol.

Brian

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

[Paul Hoffman]

On Feb 15, 2024, at 09:48, Wellington, Brian 
 wrote:
> 
> 
> 
>> On Feb 15, 2024, at 6:02 AM, Paul Wouters  wrote:
>> 
>> On Feb 15, 2024, at 04:37, Petr Špaček  wrote:
>>> 
>>> If you think colliding keys should be allowed, please propose your own 
>>> limits for sensible behavior.
>> 
>> I do think they need to be allowed because they have always been allowed so 
>> far. Reasons for not allowing them seems to be implementation details. Sure, 
>> if the RFCs had warned implementers this wouldn’t have happened, and we can 
>> learn from that (and I gained appreciation and validation for whining about 
>> security and operational consideration sections)
>> 
>> You seem willing to (statistically) throw 1/65536 zones under the bus. That 
>> would roughly be 2500 .com domains if all of .com was signed (without key 
>> sharing)
>> 
>> I don’t see why we should do this.
> 
> A fairly simple way to deal with this issue is a Flag Day. As Ralf said in a 
> later post, the number of zones with colliding key tags is relatively small.

Anything above zero is significant.

>  It would certainly be reasonable to declare that at some time in the future, 
> colliding keys will not be handled by validators.

Why? Many people on this thread have said they have or will implement caps on 
how many collisions for a key set they will allow. An operational change such 
as that is vastly easier to implement than a flag day, and gets better results.

--Paul Hoffman

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

Re: [DNSOP] [Ext] About key tags

[Wellington, Brian]

> On Feb 15, 2024, at 6:02 AM, Paul Wouters  wrote:
> 
> On Feb 15, 2024, at 04:37, Petr Špaček  wrote:
>> 
>> If you think colliding keys should be allowed, please propose your own 
>> limits for sensible behavior.
> 
> I do think they need to be allowed because they have always been allowed so 
> far. Reasons for not allowing them seems to be implementation details. Sure, 
> if the RFCs had warned implementers this wouldn’t have happened, and we can 
> learn from that (and I gained appreciation and validation for whining about 
> security and operational consideration sections)
> 
> You seem willing to (statistically) throw 1/65536 zones under the bus. That 
> would roughly be 2500 .com domains if all of .com was signed (without key 
> sharing)
> 
> I don’t see why we should do this.

A fairly simple way to deal with this issue is a Flag Day.  As Ralf said in a 
later post, the number of zones with colliding key tags is relatively small.  
It would certainly be reasonable to declare that at some time in the future, 
colliding keys will not be handled by validators.

Brian

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

[Edward Lewis]

From: Ben Schwartz 
Date: Wednesday, February 14, 2024 at 11:34
To: Edward Lewis , Manu Bretelle 
Cc: "dnsop@ietf.org" 
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting 
expectations in protocol definitions

> For the "testing" flag, the descriptive information is basically "this 
> endpoint does not carry my SLA".

>You can see a variation on this problem in draft-ietf-tls-svcb-ech



In the DNS environment, we assume no SLA.  The protocol assumes the worst.  
That’s why there are so many retries, so many alternative sources and so much 
tolerance for error.  It would be hard to tell if a service is in testing or 
not, so the protocol doesn’t try.



For the ECH example, it sounds like it matters in that environment - and that 
is fine.  It’s different.



Which leads me back to - I don’t see the use case for “The "testing" flag for 
Service Binding (SVCB) Records” in the context of DNS or DELEG.  A flag is a 
flag, having it mean “I’m testing” I get.  But I don’t see that notice helping 
the DNS, and applying the banner of the “DNS Camel”, I don’t think it should be 
added.



…OTOH, seeing that this is a SVCB flag, perhaps you have other environments 
where such a flag would be useful.  I just don’t see it in the DNS.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

[Paul Wouters]

On Thu, 15 Feb 2024, Ralf Weber wrote:


So to put some real numbers out there. I recently for testing did download all 
the zone data I could get from ICANN CZDS and tried to get DNSKEYs for every 
domain. So that data set had 256479639 domains (256 million) and out of those 
18726163 (18 million or 7.3 percent) actually had DNSKEYs. Out of those 153 had 
key collisions which is 0.0008 percent or roughly half of what you expected.


There must be at least one implementation that already was checking for
this then? :) I know at my previous-previous-job our signer code did drop
a clashing keytag during generation to generate a new one. But it only
accounted for a few small TLDs and has since died quietly :)


As for limits, I would say 3 or 4, to account for rare KSK+ZSK keyrollover at 
the same time with clashing key tags.


I think 2 is fine as signers also can be updated to generate new keys when they 
have collisions


I know they can, and I know that is BCP, but it is not the spec. I don't
think counter-meassures now being implemented should be a breaking
change. If you want a breaking change, write a standards track RFC for
it. (but warning, that would likely see pushback)


but I can see in a multi (dual) signer setup that standby keys could collide 
when they made public


If we move towards supporting multi-signer in ways where parties would
not collaborate, then we can't exclude collissions from happening at
all.

Which is why I like unbound's limit of 4. It supports all known valid
(yet unwise) use cases and seems to cap the malicious use cases at a
reasonable workload. No change needed to any RFCs. Has any vendor done
actual attacks on their updated settings and gotten some real world
measurements to help guide this discussion?

Paul

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

Re: [DNSOP] [Ext] Intdir telechat review of draft-ietf-dnsop-dns-error-reporting-07

[Carlos Pignataro]

Thank you, Roy!

On Tue, Feb 13, 2024 at 7:39 PM Roy Arends  wrote:

> Hi Carlos,
>
> > On 9 Dec 2023, at 14:43, Carlos Pignataro via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Reviewer: Carlos Pignataro
> > Review result: Ready with Nits
> >
> > draft-ietf-dnsop-dns-error-reporting
> >
> > Hi!
> >
> > I was assigned a review of draft-ietf-dnsop-caching-resolution-failures,
> for an
> > INTDIR Telechat Review.
> >
> > Review of   draft-ietf-dnsop-dns-error-reporting
> > TypeTelechat Review
> > TeamInternet Area Directorate (intdir)
> > Deadline2023-12-09
> > ReviewerCarlos Pignataro
> >
> > In general, I found the document to be useful and clear, effectively
> organzied,
> > and easy to follow for an implementor.
> >
> > Please find below only some minor nits for consideration:
> >
> > 1. Append a comma after "i.e.".
> >
> > 2. Change "Well known" to "Well-known".
> >
> > 3. Capitalization of "RRset" vs. "RRSet", although RFC 8499 mentions
> both.
> >
> > 4. Should RFC 2199 be a Normative reference instead of Informative?
>
> Ah, good catch. Will fix ‘em all
>
> Thanks!
>
> Roy
>
>
>
>
> > Thanks!
> >
> > Carlos.
> >
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

[Ralf Weber]

Moin!

On 15 Feb 2024, at 6:02, Paul Wouters wrote:
> You seem willing to (statistically) throw 1/65536 zones under the bus. That 
> would roughly be 2500 .com domains if all of .com was signed (without key 
> sharing)
>
> I don’t see why we should do this.

So to put some real numbers out there. I recently for testing did download all 
the zone data I could get from ICANN CZDS and tried to get DNSKEYs for every 
domain. So that data set had 256479639 domains (256 million) and out of those 
18726163 (18 million or 7.3 percent) actually had DNSKEYs. Out of those 153 had 
key collisions which is 0.0008 percent or roughly half of what you expected.

> As for limits, I would say 3 or 4, to account for rare KSK+ZSK keyrollover at 
> the same time with clashing key tags.

I think 2 is fine as signers also can be updated to generate new keys when they 
have collisions, but I can see in a multi (dual) signer setup that standby keys 
could collide when they made public, but if we are able to threat the multi 
signer paths different with DELEG maybe don’t need to care about key collisions 
at all, but that is a bit off topic.

So long
-Ralf
——-
Ralf Weber

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

[DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one

[Suzanne Woolf]

Hi,

The qdcount draft is brief and straightforward, and there have been no new 
changes proposed or issues introduced since the -01 version was posted. We 
think there’s likely consensus to advance it for publication.

This note starts a Working Group Last Call for draft-ietf-dnsop-qdcount-is-one.

Current version of the draft is available here: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/

The Current Intended Status of this document is: Proposed Standard

Please review the draft and offer relevant comments.

For WGLC, we need positive support and constructive comments; lack of objection 
is not enough. So if you think this draft should be published as an RFC, please 
say so.

If you feel the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends on:  29 
February, 2024.

thanks,
Suzanne (for the chairs)


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

Re: [DNSOP] [Ext] About key tags

[Philip Homburg]

> Hmmm, key tags were intended to simplify computation, somehow it
> seems that they've gone the other way.

It seems that key tags set a trap for signers. 

A signer needs a way to identify keys to do key management. This mechanism
needs to be robust such that the signer cannot get confused about which key
is which.

Where it went wrong is that signers started using the key tag to identify
keys. And somehow this practice continued even though we know that
the chance of collision is high.

The obvious thing to do is to publish a document on how signers should 
identify keys. And then try to fix all signers to not use key tags anymore.

If we look at validators, the design of DNSSEC does not include systematic
analysis of denial of service potential and design to avoid that. This is 
mostly absent, often wrong basically left to the implementor.

So it should not come as a surpise that key tags (as currently specified)
do not really help to avoid denial of service attacks.

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

Re: [DNSOP] [Ext] About key tags

[Edward Lewis]

On 2/15/24, 04:37, "DNSOP on behalf of Petr Špaček"  wrote:
>If you think colliding keys should be allowed, please propose your own limits 
>for sensible behavior. I will take popcorn and watch.

Hmmm, key tags were intended to simplify computation, somehow it seems that 
they've gone the other way.

Having, setting, or discussing, limits for sensible behavior deserves its own 
thread, independent of colliding keys.  I'd see this benefitting from a 
panel-of-implementers topic in operator fora (RIPE's DNS working group as an 
example, DNS-OARC as another) to gather operator-informed parameters, leading 
to a general document (IETF) on the recommendations.


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

Re: [DNSOP] [Ext] About key tags

[Paul Wouters]

On Feb 15, 2024, at 04:37, Petr Špaček  wrote:
> 
> If you think colliding keys should be allowed, please propose your own limits 
> for sensible behavior.

I do think they need to be allowed because they have always been allowed so 
far. Reasons for not allowing them seems to be implementation details. Sure, if 
the RFCs had warned implementers this wouldn’t have happened, and we can learn 
from that (and I gained appreciation and validation for whining about security 
and operational consideration sections)

You seem willing to (statistically) throw 1/65536 zones under the bus. That 
would roughly be 2500 .com domains if all of .com was signed (without key 
sharing)

I don’t see why we should do this.

As for limits, I would say 3 or 4, to account for rare KSK+ZSK keyrollover at 
the same time with clashing key tags.

Paul

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

Re: [DNSOP] [Ext] About key tags

[Petr Špaček]

On 14. 02. 24 15:49, Shumon Huque wrote:
On Wed, Feb 14, 2024 at 8:54 AM Petr Špaček > wrote:


On 14. 02. 24 14:37, Joe Abley wrote:
 > Op 14 feb 2024 om 13:46 heeft Edward Lewis
mailto:edward.le...@icann.org>> het
volgende geschreven:
 >
 >> On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček"
mailto:dnsop-boun...@ietf.org> on behalf of
pspa...@isc.org > wrote:
 >>
 >>>    In my mind this is good enough reason to outlaw keytag
collisions -
 >>>    without them it would be _much_ easier to implement
reasonable limits
 >>>    without risk of breaking legitimate clients.
 >>
 >> That would make key tags meaningful. ;--)
 >>
 >> The question is how, in a multi-signer friendly way.
 >
 > To be honest it feels like there as many opportunities for
accidents by imposing restrictions on publishing duplicate keytags
as there are by consuming them. Your text summarised a few of them
quite nicely, Ed, without even considering the new opportunities for
failure due to the interplay between systems following any new rules
that might be imposed and those that don't.
 >
 > Is the triggering incident not just another cautionary note that
we learn from?
 >
 > Why is this particular incident a sign that we need to change the
protocol when so many others have not been?
 >
 > These seem like questions that deserve convincing answers before
jumping ahead to how a new restriction might be structured.

Let me turn the question around:

How many keytag collisions are you willing to allow & at the same time
protect validators from 2023-50387?


Does the KeyTrap vulnerability exploit colliding keytags? The paper 
isn't public yet and the CVE does not mention this.


Obviously, resolvers need to sensibly bound the work they are willing to 
do to resolve queries, especially so in the face of misconfigurations 
(or malicious configurations). And that basic principle should apply to 
keytag collisions too.


In fact, bounding work is the documented top priority of a resolver from 
RFC 1034 (published 1987).


"The recommended priorities for the resolver designer are:

    1. Bound the amount of work (packets sent, parallel processes
       started) so that a request can't get into an infinite loop or
       start off a chain reaction of requests or queries with other
       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
       SOME DATA.

..."

(My usual addendum to this paragraph is that the resolver should also 
bound the time spent too).


Oh yes, this is basically what
https://www.isc.org/blogs/2024-bind-security-release/
tries to explain at length.

--
Petr Špaček
Internet Systems Consortium

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

Re: [DNSOP] [Ext] About key tags

[Petr Špaček]

On 14. 02. 24 16:45, Shumon Huque wrote:
On Wed, Feb 14, 2024 at 7:46 AM Edward Lewis > wrote:


On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček"
mailto:dnsop-boun...@ietf.org> on behalf of
pspa...@isc.org > wrote:

 >    In my mind this is good enough reason to outlaw keytag
collisions -
 >    without them it would be _much_ easier to implement reasonable
limits
 >    without risk of breaking legitimate clients.

That would make key tags meaningful. ;--)

The question is how, in a multi-signer friendly way.


Yes, enforcing non-colliding keytags in a multi-signer configuration is 
more challenging, since coordination across multiple independent parties 
may be needed. But a process could be developed to deal with that.


But I'm not sure how worried I am about it, as a practical matter. Even 
if by some remarkable coincidence all keys collided in a 2 party KSK+ZSK 
multi-signer configuration, Unbound with its 4-keytag limit would still 
be able to deal with it.( I guess some additional room for pre-published 
rollover keys may be needed if they also collided).


What colliding keytag limits are other resolver implementers placing?


Right now BIND tolerates 1 validation failure before hard-failing. This 
counter is not limited to colliding key tags.


In generic terms, the amount of work scales like:
#DNSKEYs * #RRSIGs
(for matching key tags)

Ed's example in the other thread with 1 DNSKEY and 10 bad RRSIGs is 
certainly a problem - thus the limit on number of validation failures.


The high-level trouble is that (currently legally) colliding keys make 
it hard to find a nice threshold which does not break legal setups and 
at the same time prevents resolvers from doing excessive work.


Of course even with perfectly valid RRSIGs and just one key the amount 
of work can be large - CNAME chains etc. etc. For that reason we 
currently also limit number of validations to 16 per fetch.


And that leaves us more or less with basic random subdomain attack, so 
we are back where we started :-)



If you think colliding keys should be allowed, please propose your own 
limits for sensible behavior. I will take popcorn and watch.


--
Petr Špaček
Internet Systems Consortium

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

Re: [DNSOP] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Nils Wisiol]

knot-dns now supports bootstrapping via mod-authsignal, see
https://gitlab.nic.cz/knot/knot-dns/-/commit/50d84030772f09dd6f92c086e0c2098dde328209

Thanks,
Nils

-- 
deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

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