[dnssec-deployment] Write ups on root key schemes
ogud at ogud.com
Wed Jun 23 11:41:22 EDT 2004
At 11:24 22/06/2004, Steve Crocker wrote:
>Last week's DNSSEC call ended with writing assignments:
>O SEVERAL people (Johan Ihren, Olaf Kolkman, Olafur Gudmundsson or Mike
>St. Johns, Rob Austein, Paul Vixie, Mark Kosters, Matt Larson, if I
>recall correctly, but I may have mangled this list) EACH writing short
>O FOUR root key distribution schemes (manual, revoke bit, M-of-N, DLV)
>O Against FIVE criteria (is it a protocol change, is a permanent or
>temporary solution, does it also include trust anchors, what is the
>impact if operators do not attend to roll-over notices, what is the
>recovery process if the automatic system fails).
>That's 20 pieces of text from each person.
Given that I only know the details of manual, Revoke and DLV I will
ignore or guess what n-m does.
I added two more criteria: Scaling and Learning of new TA's.
I also have to report regrets for the next 4 teleconferences,
this week and next I may join late (depending on traffic),
the first two in July I will miss.
TA: Trust anchor
TAM: Trust Anchor Maintainer
A B C D
Manual Revoke N-M DLV
1. Protocol Change: NO Yes & NO (no) Yes
2. Permanent: Hope
Not YES (yes) decreasing
3. Includes TA's. yes & no yes yes yes
4. Inattention Impact: key rot  key rot key
Process: manual restart ??? manual
6. Scaling bad linear ??? good
7. Learning new
TA's Manual Manual ??? automatic
1B: The proposal reserves a bit in the DNSKEY flags field, this bit
is similar to the KSK bit that it is not used by DNSSEC
validator during DNSSEC verification but by DNSSEC support
tools. Thus this is a change on the wire but it does not affect
DNSSEC validation process. The use of this bit is by a separate
entity/function Trust Anchor Maintainer (TAM). this can be part of
resolving nameserver or separate. The output from the TAM is
used to configure Trust Anchors for DNSSEC validator(s).
The real interesting effect of the Revoke bit is that as it is set
the key becomes unusable by Validator, but TAM can still use
1C My guess is that this schema involves TAM as well.
1D DLV adds a logic to resolvers to learn Trust Anchors from a
separate tree. This logic is needed in every resolver.
2A Manual process is needed for TA's under domains that do not
use DNSSEC, hopefully this group shrinks with time. In most
cases manual is only worth it to configure important partner TA.
As the process requires manual communication each time there is
change in TA this is likely to break down unless there is high
value in keeping the TA up to date.
2B. Revoke bit proposal requires manual insertion of TA's in the
beginning, after that the process keeps track and updates TA's
as long as originator follows the process of publication. Revoke
bit schema can learn new TA's that are below existing TA's thus
mitigating failures in the higher TA.
2D. DLV lookups are only needed when there is not a path from a
known trusted key to the key being validated. Over time as
larger and larger parts of the tree become signed fewer and
fewer domains need to have their TA's listed in DLV. There are
scenarios where DLV will never go away but these all involve
TLD's that refuse to deploy DNSSEC.
3A. Manual process requires the configuration of every new TA, and
the maintenance of it. The process can be combined with tools
to learn new TA's below the already configured ones. Or there
might be trusted publishers of TA's that are downloaded
3B. New TA's need to be introduced (does not require actual key)
only the fact this TA is of interest. The TAM learns to trust
TA's over time, and after certain time has elapsed the TA is
added to the TA list.
3D. Only one TA per DLV tree needs to be configured after that
discovery of TA's is automatic and handled by DLV operator.
4A. Key Rot: As keys get removed from use and new ones introduced
these changes must be reflected in the list of TA's. Thus any
keys changed but not updated will cause that domain to become
bogus/insecure. The failures can happen on both sides.
4B. Key rot should not happen unless one of the three factors happen:
- TAM is not executed periodically or the output is not shared
with resolving validator
- Zone does not follow procedure for retirement of TA's
preventing TAM's from learning the new keys.
- Zone stops using DNSSEC.
4C. I assume impact is the same as in 4B
4D. DLV has more complex failure model,
- IF "user" does not update DLV master TA as it changes, the
failure is complete loss of TA's that are not below trusted
TA's (similar failure as to not updating the root key)
- If DLV operator stops monitoring and updating TA's under
contract there is failure similar to 4B.
- If zone does not follow guidelines from DLV operator about key
publication and changes DLV may have wrong key or no key for
- If DLV operator stops to function it is similar to the first
one but possibly different.
5A. Reestablish TA via communication with other zone or other
5B. If TAM was not running, restarting that process will recover
most errors in specified time (30 days). Some TA's may need
manual recovery operation (depending on TAM policy)
If zone did not follow procedure, TAM's may (if policy allows)
learn to trust new TA for that zone over time.
5D. If DLV master TA fails, putting in the new TA will complete recovery.
If DLV operator stops to function here is no recovery
If DLV operator does not do their job there is decreasing value
in the information published.
If DLV consumer (TA publisher) does not follow procedure only
their data is affected and only they and DLV operator can
perform recovery action.
6A. Scaling is bad as all changes need some manual action, it is
possible that a variant of this schema that uses trusted TA
publishers will allow more scaling and less manual work (but
that has similar effects as DLV but storing more information in
6B. Scaling is good, as new TA's are learned/lost the system can adjust
what TA's to maintain. TA's can be learned down, only upwards
TA's need to be configured (once).
6D. DLV holds the promise that one KEY will validate many, thus
there is not need to maintain TA lists. The bad effects here are
multiple DLV tree's cause slowness of lookups, possibly
inconsistent data, and more TA's to maintain.
7A. Manual may require trust relationship.
7B. Manual up, automatic one level down, Manual multiple level down
7C. Should hold same properties as 7B.
7D. Automatic as the DLV operator handles this process and maintains trust
relationship with the zone.
More information about the Dnssec-deployment