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

> On Jun 30, 2015, at 8:53 AM, Tony Finch <dot@dotat.at> wrote:
> 
> Olafur Gudmundsson <olafur@cloudflare.com> wrote:
> 
>> There is much simpler way.
>> Just add record to the rootzone that is only signed by the new key.
>> If resolver returns AD bit it has the new key.
> 
> I don't think this works.

> 
> If the new key is published in the root zone's DNSKEY RRset then it will
> be signed by the old key, so a validator will have a trust path from a
> stale trust anchor down to the special record (just like it does for
> records signed by ZSKs).
> 

> If the new key is not published in the root zone, then you are assuming
> that the validator uses DNSKEY records for its trust anchor configuration
> (but some validators use DS records) and that the validator will allow any
> RRset to be signed by the trust anchor (but RFC 4035 section 5 suggests
> only using the trust anchor to validate the apex DNSKEY RRset).
> 

I think it works some of the time i.e. 
if one or more of the following are true 
a) If the trust anchor is maintained by operator and operator saw advertisement and acted upon 
b) if the new key is advertised by 5011 protocol long before it is rolled and then removed 
c) If the New key is advertised via CDNSKEY and is picked up via trust anchor maintenance 
but most importantly: 

d) the Trust anchor is maintained by storing the DNSKEY when possible[*]

So this is not perfect mechanism, will give us an idea how many Validators picked up the new trust anchor 
and then we can start the real propaganda campaign. 

My bullet b) is a change from the root key rollover plan that assumes that new key is added just before it is used. 
I would propose that 5011 advertising  is done multiple times before the rollover and the new key is removed during the ZSK rollover,
to allow testing. 

I do not yet propose what name or record is used for this experiment but having it an “address of an object” would be good as that
enables testing from browsers. (CNAME is just as good as an address) 

    Olafur

Ps: based on my quick check of unbound and Bind both store DNSKEY’s,  I do not know how Nomininum, Microsoft and/or DNSMasq store it. Large public resolvers like Google are likely to do this via configuration 

> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Shannon, Rockall, Malin: South 5 to 7, occasionally gale 8 at first in
> Rockall, decreasing 3 or 4. Moderate or rough, occasionally very rough except
> in Malin. Rain then fog patches. Moderate, occasionally very poor.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop