Trust anchor rollover review

["dr. W.C.A. Wijngaards" <[e-mail]>]

Hi,

A couple of reviews of the trust rollover drafts I could find. Based on
the summaries and comments below my support is to the draft-threshold
(I value the query volume highly). The draft-timers comes second
(negative is the query volume, key priming could be added separately
just like the -threshold draft). These two drafts both satisfy the
requirements.

The technology for key rollover I like the most is the threshold and
timer solutions. Threshold has (slightly, 2x) lower communication costs.
More work should be done on message size (should keys be in their own
domain names to keep 'em small), and on priming key technology (history
playback mechanism to 'roll-forwards' the priming key or something).


Rated to requirements in draft-ietf-dnsext-rollover-requirements-02:
5.1. Scalable. -timers yes, -threshold yes. -laurie less so.
        - DLV solution does not scale.
5.2. IPR (from ietf IPR pages).
        -takrem has IPR claims, statement about licensing has
          '.. economic value of the technology appears to lie with
          the trust anchor issuer role. ..'. License for GPLv2 but
          no other OSS lisences.
        -timers and -threshold, IPR claims that have a free use grant.
        -laurie has no IPR issues at all.
5.3. General Applicability. All do.
5.4. Support Private networks. All do.
5.5. Detection of stale trust anchors. -laurie does not.
5.6. Manual operations permitted. All do
5.7. Planned and unplanned rollovers. All do (research for key in -laurie).
5.8. Timeliness. -laurie does not include a timed refresh operation.
5.9. High Availability. All do.
5.10. new RR types. Revocation bit in DNSKEY flags for -timers.
5.11. Support maintenance by adding new anchors. All do.
5.12. Recovery from compromise. -laurie does not.
        - DLV cannot recover from a compromised dlv key.
5.13. Non-degrading trust. All can, -laurie has an issue with low trust
links.


draft-laurie-dnssec-key-distribution-02.txt
-------------------------------------------

Summary:
Using certificates. Everyone signs their keys using certificates.
Cross-signing of others' keys. HTTP URLs (stored in cert) have
collections of keys, signed by certificates. Hightrust and Lowtrust
certificates. Resolver starts with trusted certs. Follows web of trust
of cross signing, collect all certificates, extract all trusted keys.

Comments:
- 'in band mechanism' can be used to keep anchors up to date.
  Refers to key-rollover within a zone?
- centers on trust web. Have to recurse all the trust web to find keys.
- PRO: decentralised.
- CON: scaling issues, with spidering the trust web.


draft-ietf-dnsext-trustupdate-timers-02.txt
-------------------------------------------

Summary:
Keys sign keys for verification at zone apex of trust point.
Timer to wait before add-key, or remove-key. Key compromise can be
detected during the wait time. Resolver must detect if key stays in
dnskey rrset for the entire duration of the wait time.
Resolvers ask for dnskeys at trust points every so often to refresh
keys. 'Revoke' bit in dnskey rrtype, sign it by that key and key is revoked.

Comments:
- KeyRem event, could that be due to truncation of a dns reply? If so,
  it should not have such harsh consequences.
- very pretty revocation idea, where you need key private data to
  revoke.
- CON queries for trust keys to refresh them, even if trust point is not
  in active use.
- PRO key compromise handled carefully.


draft-ietf-dnsext-trustupdate-threshold-01.txt
----------------------------------------------

Summary:
Trustanchor keys have 'SEP' flag set. Want to avoid bogus data because
keys are old, called stale keys. Keep a set of dnskeys and rrsigs by all
keys at zone apex. At least M trust anchors must verify a new set of
keys. The threshold from the title is M-N(number of keys).
Keys are flagged as SEP, KSK, ZSK or Priming, no further state for keys.

Nit: 3.4, paragraph starts with "If if".

Comments:
- PRO Handles key compromise
- PRO Provides method to escape a stale-keys state to no-keys.
- CON regular probes for new keys, less frequent than -timers, once
  per month. Need to give zone operator influence on this value.
- PRO Discusses initial key priming. To bootstrap security.
- CON priming keys idea is nice, but really moves all of the issues to
  the longer lived key. The technology for trust, revocation,
  parameters of that priming key is listed as external to the proposal.


draft-moreau-dnsext-takrem-dns-02.txt
-------------------------------------
Not reviewed. IPR claims on namedroppers. 'no derivative works' clause.