<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Inline...<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 3/29/2019 11:54 AM, Michael
Richardson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3619.1553874848@dooku.sandelman.ca">
<pre class="moz-quote-pre" wrap="">
Lars-Johan Liman <a class="moz-txt-link-rfc2396E" href="mailto:liman@netnod.se"><liman@netnod.se></a> wrote:
ebersman> It is not the IETF's job to tell large ISP that they must do
ebersman> 5011. We need to consider that the world will never be all 5011
ebersman> and that alternate automation methods are valid and how we'd
ebersman> address that in an emergency.
mcr> I don't really understand the long-term reasons for not doing 5011.
mcr> Can you explain this further?
> <a class="moz-txt-link-abbreviated" href="mailto:list-ksk-rollover@dragon.net">list-ksk-rollover@dragon.net</a>:
>> Phased rollout and control of when things change.
> Aye.
> I agree that we shouldn't prescribe how people automate, or even that
> they do it at all. 5011 is _one_ way to do it, and I happen to like it,
> but that doesn't mean that it is good for $everybody.
In particular, it fails when the device is not on/connected during the period
that the 5011 adds the new key, then it can not use 5011. </pre>
</blockquote>
<p>No - that's not correct. It fails if it wasn't able to see the
old key signing the new key for the add hold down period. If
you're following my recommendations in 5011, then the new key C is
going to be signed by A for a while, then B for a while, before it
becomes the active key. <br>
</p>
<p>E.g. 2 key steady state starts with A, B gets added and is signed
by A for a year. Then C is added, and is signed by A (A signs the
DNSKEY RRSET), then A is revoked and B signs the RRSet for another
6 months to a year. When its finally time for C to be the active
key, its been signed by the other two keys for quite a long time.</p>
<p>The "adds the key" is a resolver state change, NOT a publisher
activity.<br>
</p>
<blockquote type="cite"
cite="mid:3619.1553874848@dooku.sandelman.ca">
<pre class="moz-quote-pre" wrap="">
I think that an alternative to straight 5011 is needed.
As far as I understand 5011, the only reason we can't leave the entire chain
of keys in at the trust point is because the RRset would get unreasonably
large, causing other failures.</pre>
</blockquote>
No.<br>
<blockquote type="cite"
cite="mid:3619.1553874848@dooku.sandelman.ca">
<pre class="moz-quote-pre" wrap="">
It seems that the problem is solved if the history of the DNSkey can be
placed at some other place.</pre>
</blockquote>
<p><br>
</p>
<p>5011 was designed to cause resolvers to make state changes to
their trust anchor set based on information gathered over a period
of time. No resolver makes a "add anchor" state change based on
seeing one signature - it makes it after it sees at least two
signatures over the DNSKEY RRSet over a period of time. Once the
state change is made, the "history" of the signature is
irrelevant. This important because it causes the state changes to
be tied to particular time ticks in a way that later lies can
safely be ignored.<br>
</p>
<p>As I said at the mike, you can't just trace the signatures, you
need to trace the entire state of the trust anchor set - and that
is vastly different than the contents of the DNSKEY RRSet and its
associated signatures.</p>
<p>I've spent a lot of time thinking about this and I don't think it
can be done using just information from the DNS. Basically, a key
compromised at any time can rewrite the state history for any
point from the time the key was valid forward. Even revoking the
key doesn't help. An attacker who is able to provide the client
who is trying to verify the history the attacker's version of that
history can cause that client to set up its trust anchor set state
the way the attacker wants it to.</p>
<p>Someone banned the use of the term "blockchain" in the
discussion, but something like that is probably the right
approach. BUT - blockchains like Bitcoin work because many
entities write transactions to the global block chain, and
repudiating the history to start from a previous point would be
easily detected. Given that the contents of the root key set are
being written by a single entity with a single chain of trust, I
think we're going to need mix in some other non-DNS data to gain
the same level of trust and prevent rewind of the root DNSKEY
trust anchor state. <br>
</p>
<p>Mike</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:3619.1553874848@dooku.sandelman.ca">
<pre class="moz-quote-pre" wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ksk-rollover mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ksk-rollover@icann.org">ksk-rollover@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/ksk-rollover">https://mm.icann.org/mailman/listinfo/ksk-rollover</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>