Hands-off DNS root zone security proposal

[Thierry Moreau <[e-mail]>]

Dear all:

The political aspects of signing the DNS root zone seem to be
recurring with little indication that some progress in this
direction can be made in a predictable time.

Echoes from a recent centr meeting (i.e. an association of ccTLD
registries, at http://www.centr.org) indicate that "There seems
to be a need for a Trust Anchor Distribution mechanism  with
which one can distribute multiple trust-anchors (e.g. those of
TLDs) without the need for the mechanism itself to rely on [the
DNS root] trust anchor." (- Olaf M. Kolkman).

The present proposal is inspired from an approach has been taken
by the ICAO (International Civil Aviation Authority) for their
"PKI for Machine Readable Travel Documents [i.e. electronic
passports]" (which bears little relation to the IETF PKI given
the amount of simplification they did in the PKI model).

Basically, the overseeing organization (ICAO as a treaty
organization / ICANN as a domain manager overseeing TLDs) merely
collects public key information from its constituency ("member
states" for ICAO / TLD managers for ICANN), puts it together in a
computer file, and makes it available to the public (ICAO Public
Key Directory / ICANN "TLD TAK-i file" explained below). No
digital signature by the overseeing organization, hence little
mixed signals about the overseeing organization operational
liability implied by a "digital signature." Those interested in
the institutional paperwork and MoUs can look at
http://www.icao.int/icao/en/atb/fal/mrtd/tagmrtd16/Tagmrtd16_026_
en.pdf. Important third parties will be interested in reading the
computer file for configuring signature verification systems (for
ICAO, airlines for passenger identification at boarding time /
for ICANN, DNS resolver software developers and vendors for
embedding trust anchor key material in software release initial
configuration).

In the case of ICANN, it is operationally more difficult (i.e.
unrealistic) to update the configuration in signature
verification systems (i.e. fielded resolver software) than in the
case of ICAO member states (i.e. border control equipment) and
airlines (boarding control systems). Accordingly, the present
proposal assumes a clear separation of Trust Anchor Key
initialization (TAK-i) from Trust Anchor Key rollover (TAK-r).
The TLD TAK-i file maintained by ICANN would thus be concerned
only with TAK-i related public data. Accordingly, the update
operations on the TLD TAK-i file  would be limited to:
   o  adding TAK-i related public data for a TLD that will support
      DNSSEC,
   o  updates in the case of TLD redelegation incidents, i.e. when
      a TLD is redelegated and the TAK-i private data counterpart
      does not follow the redelagation.

The above is intended to be independent of a specific TAK-i and
TAK-r solution. Nonetheless, the TAKREM for DNS
(draft-moreau-dnsext-takrem-dns-00.txt) is indeed well suited to
the present proposal, notably:
   o  TAKREM meets the required separation of TAK-i from TAK-r,
   o  TAKREM allows the preparation of TAK-i public data well in
      advance of the decision to make a TLD DNSSEC-aware,
   o  the TAK-i private data counterpart is easily transferred
      from one organization to its successor in the case of a
      mutually agreed TLD redelegation.

So, the above is presented as a path to DNSSEC deployment without
full support of DNSSEC in root zone management. Perhaps the
institutional arrangement can be described as "the root zone
provisioning by ICANN is augmented with the collection of Trust
Anchor Key public information from TLDs but the root zone DNS
operation is not modified." So it is hands-off, i.e. no hands-on
handling of private key material by ICANN or root zone operator.

Hope it can be useful.

Regards,

-- 

- 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/>