Survey of Rollover Mechanisms

[Thierry Moreau <[e-mail]>]

Dear all:

In order to assist the discussion, here is a survey of
trust anchor key mechanisms. The 1 1/2 Internet drafts
that are being discussed are in survey entries 2.a) and
2.b). Other entries do not appear in the current IETF
agenda but may be relevant since they address the same
rollover requirement.

As a reminder, trust anchor key rollover relates to the
need to change the KSK of a DNSSEC-aware DNS zone when
the parent zone is DNSSEC-obvlious. It will apply to
the root zone if and when it becomes DNSSEC-aware, and
to "islands of trust" in the meantime.

Trust anchor key rollover is a tough problem, linked
ultimately to the trust anchor key initial
distribution. Any rollover mechanism has a catastrophic
failure mode, so there is no good solution: if a
security incident falls in the catastrophic failure
mode definition, the rollover mechanism becomes
insecure and the trust anchor key initial distribution
must be re-done.

For now, I leave to the readers the task of identifying
the catastrophic failure mode definition for each
entry, but for the easiest one.

1.   Outside Certification

Description: outside certification relies on the
digital signatures in a context different from the DNS
hierarchy. In terms of security fundamentals, it shifts
the "root" to some other set of rules.

1.a) Ben Laurie's "Distributing Keys for DNSSEC" use
      X.509 security certificates for outside
      certification of trust anchor keys. See
      reference [1].

1.b) DLV is not presented as a rollover mechanism,
      but it does fit the definition of outside
      certification. DLV uses a "lookaside" digital
      signature by a "DLV operator" who more or less
      replaces the higher part of the DNSSEC
      hierarchy until "islands of trust" vanishes
      because the root and TLDs become DNSSEC-aware.
      For DNSSEC-aware resolvers, the DLV approach
      makes use of familiar DNSSEC protocol elements.
      See references [2] and [3].

2.   Plurality of trust anchor keys

Description: with these two schemes, a trust anchor
should be materialized with a set of public keys, and
the rollover operation is done by the zone manager a
subset at a time, so that the DNS resolvers can rely on
the "not-rolled" keys to get confidence in the new
keys.

2.a) The threshold mechanism being discussed
      currently in the DNSEXT working group, despite
      being an expired draft. See reference [4].

2.b) The timing mechanism also discussed now in
      DNSEXT. See reference [5].

3.   Pre-announcement with plurality of digests

Description: upon trust anchor key initial
distribution, a list of cryptographic digests of future
keys is distributed as well. The DNS resolvers validate
a key rollover against the digest originally received.

3.a) The TAKREM mechanism, which I introducte to
      DNSEXT as a pre-draft document with discussion,
      rationales. See reference [6].

3.b) The same TAKREM mechanism may be used with a
      "plain" hash function (e.g. SHA-1) instead of a
      parameterized one like MASH
      (ISO/IEC 10118-4:1998).

4. Long-lasting trust anchor keys

Description: if no rollover method is found adequate, a
long-lasting trust anchor key is an easy to specify
method. With this method, any type of incident falls
under the definition of catastrophic failure mode,
while other methods leave some type of incidents in
this category.

5. Out-of-band Validated Rollover

Description: the "textbook" rollover method is to
distribute the key to DNS resolvers and use an out-of-
band channel to let the end-users validate the new key.
There isn't the slightest chance that this is
operationally feasible in any context. The out-of-band
validated rollover method is documented to support the
long-lasting trust anchor key method.

The above survey is the easy part. The tough part is to
determine what would be reasonable requirements for
DNSSEC good fate, while no good solution exist.
Thereafter, these requirements may, or might not, or
might partly, be considered within the scope of the
IETF mandate. For instance, the DLV promoters would
like to have a DLV RR type assigned to the DLV method,
but leave every other aspects of the specification
outside of the IETF activities.

Hope it helps.

References:

[1]  Ben Laurie, "Distributing Keys for
      DNSSEC"draft-laurie-dnssec-key-distribution-00,
      September 30, 2004

[2]  Mark Andrews, Sam Weiler, "The DNSSEC Lookaside
      Validation (DLV) DNS Resource Record"
      draft-andrews-dlv-dns-rr-00 June 23, 2005

[3]  Sam Weiler, "DNSSEC Lookaside Validation (DLV)" 22
      May 2005, http://www.watson.org/~weiler/dlv/
      draft-weiler-dnssec-dlv-pre00.txt

[4]  J. Ihren, O. Kolkman, B. Manning, "An In-Band
      Rollover Mechanism and an Out-Of-Band Priming
      Method for DNSSEC Trust Anchors",
      draft-ietf-dnsext-trustupdate-threshold-00, October
      18, 2004

[5]  Mike StJohns, "Automated Updates of DNSSEC Trust
      Anchors", draft-ietf-dnsext-trustupdate-timers-01,
      August 15, 2005

[6]  Thierry Moreau, "'Trust Anchor' Integrity
      Mechanisms for Internet DNS Security" 2005/08/24
      http://www.connotech.com/takrem_for_dnssec_01.pdf

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>