[dnssec-deployment] Write ups on root key schemes

[Ólafur Guðmundsson]

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
>responses on
>
>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.

Abbreviations:
         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 
rot[]       depends[]
5. Recovery 
Process:    manual[]        restart[]       ???             manual[]
6. Scaling              bad[]           linear[]        ???             good[]
7. Learning new 
TA's    Manual          Manual[]        ???             automatic[]

Notes
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
       it.

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
       periodically

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
         zone.
       - 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
       channel

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
       resolvers).

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.