Subject: Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Jul 2015 18:36:40 -0400 (EDT)

On Tue, 30 Jun 2015, Warren Kumari wrote:

>> I have been planning to write a draft to address 1 by having validators send
>> the DS of known TA's in an edns0 option code. This info, could then be
>> logged by the authoritative nameservers.
>
> Inserting it in edns0 implies (I think) that all of the queries will
> contain this, which seems like a fairly big query size / efficiency
> hit. I guess you could just do it every N queries, or M time, or
> something. Very similar idea though...

Why? You would only add it to the question for DNSKEY of the root.
Maybe only after you determined a validation failure, so you clearly
have the wrong trust anchor.

It seems in general, having some special record signed by only the
new key seems a nicer solution, as it allows for large network
monitors (eg atlas) to use unmodified dns servers. But it will require
some kind of legal/contractual change :(

Paul

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Jul 2015 10:30:33 +0100

Paul Wouters <[email-masked]> wrote:
>
> You would only add it to the question for DNSKEY of the root.

Yes.

> have the wrong trust anchor.

No, the point of this option is to signal to the root what trust anchors
are in use by the population of validators, before a rollover happens.

It is like the algorithm signalling option, RFC 6975. (Which seems to be
mostly unimplemented... why?)

> new key seems a nicer solution,

That cannot work.

http://www.ietf.org/mail-archive/web/dnsop/current/msg14664.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight, Portland, Plymouth: Cyclonic, mainly southwest, 4 or 5. Slight
or moderate. Thundery showers. Moderate, occasionally poor.

---

From: Bob Harold <[email-masked]>
Date: Tue, 7 Jul 2015 14:12:37 -0400

On Mon, Jun 29, 2015 at 8:03 PM, manning <[email-masked]> wrote:

> Why, yes, I still do.  (and it can be found in the IEtF archives)
> https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01
>
> As to why,  perhaps I am missing the obvious, but if SUDSTA proceeds, does
> it matter if the origin IP of the root zone being served
> is sporadically distributed?   It seems that one could not presume to have
> the data to assert the penetration of the new keys nor the
> origin of the stale keys, if that information was diffused through the IP
> address space.
>
>
> manning
> [email-masked]
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
>
>
>
> On 29June2015Monday, at 16:28, David Conrad <[email-masked]> wrote:
>
> > Bill,
> >
> >> This looks very much like the draft that Olaf, Johan, and I wrote at
> the same time MSJ was proposing what we have now.
> >> You might want to talk to either Olaf or Johan for more details.
> >
> > Don't suppose anyone has a copy of that draft?
> >
> >> And yes, this will fail if any of the loopback drafts are deployed.
> >
> > Sorry, I must be missing something obvious. Why?
> >
> > Regards,
> > -drc
> >
>
> Either method seems usable, but we really need one of them deployed

Local root on loopback - if they update the root zone regularly, it should
just work, right?  If they don't update, they will keep validating with the
old root keys - will the next level break as soon as the old root key is
gone, or only when a subzone rolls their key based on the new root key?

-- 
Bob Harold