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

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

Re: [DNSOP] [Ext] About key tags

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.

Re: [DNSOP] [Ext] About key tags

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.

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

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 >

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

> 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

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

> 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

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

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

Re: [DNSOP] [Ext] About key tags

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

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

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

Re: [DNSOP] [Ext] About key tags

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.

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

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

Re: [DNSOP] [Ext] About key tags

> 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

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

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

Re: [DNSOP] [Ext] About key tags

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

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

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