Minimalist TAK automated rollover procedure in DNS resolver

[Thierry Moreau <[e-mail]>]

Dear dnsext wg participants:

The TAK automated rollover protocol consists of a zone
administrator procedure (reflected in the responses provided by
authoritative nameservers for the zone), and a resolver
procedure. The present message raises the question of a
minimalist resolver procedure that "does the job" in every
operational conditions *that are to be expected in practice*, and
conceptually could survive operational mismanagement of the zone
which would, paradoxically, be detrimental to resolvers
implementations of the full TAK rollover specification.

The minimalist TAK automated rollover procedure in DNS resolver
is as follows:
   o  A trust anchor key is a DNSKEY RR that is flagged as such in
      the current DNS resolver state.
   o  Whenever a DNSKEY RRset is validly signed by an RRSIG RR
      using a trust anchor key, every DNSKEY RR in the RRset
      becomes a trust anchor key.
   o  Also when a DNSKEY RRset is validly signed by an RRSIG RR
      using a trust anchor key, the DNS resolver implementation
      may drop any current trust anchor key for the same zone but
      absent from the RRset.

Such minimalist procedure may be implemented in a resolver on the
basis of either local policy support, software release
expeditiousness, or even software design criteria prioritizing
operational resilience over ultimate security.

There are two categories of operational conditions that are
relevant to the question of a minimalist resolver procedure:
   1) false validation in minimalist resolver implementation:
           security incidents that would be properly handled
           (either successfully recovered or detected with loss of
           valid trusted key) by the fully compliant resolvers
           implementations, but bringing minimalist resolver
           implementation to an *undetected* breached state,
   2) false invalidation in fully compliant resolver
      implementation:
           unusual operational sequence of a zone administration
           (devoid of ill intentioned behavior) that would bring
           the fully compliant resolvers to a loss of valid
           trusted key (or other type of false alarm) but would be
           handled gracefully (i.e. the resolver maintains a non-
           empty set of trust anchors with one of them allowing
           zone contents verification at any single point in
           time).

The main argument for operating a minimalist resolver
implementation is the small likelihood of operational condition
1) above. After all, a zone administrator for an island of trust,
including the root, somehow commits to properly handle any DNSSEC
private signature key.

The operational condition 2), if it ever occurs once resolver
implementations of the two kinds are deployed, would be very
detrimental to the acceptance of fully compliant resolver
implementations. This suggests a test strategy for a TAK
automated rollover scheme: in a lab setup, operate the two types
of resolvers, and exercise diversified zone administration
actions (irrespective of compliance to the rollover
specification); detect and document any corner case leading to
the operational condition 2) above.

For the purpose of this post, a fully compliant resolver
implementation may be associated with timers-based TAK automated
rollover procedure (draft-ietf-dnsext-trustupdate-timers-03.txt).

The TAKREM TAK automated rollover procedure
(draft-moreau-dnsext-sdda-rr-02.txt,
draft-moreau-dnsext-takrem-dns-02.txt) does not interoperate with
the minimalist TAK automated rollover procedure in DNS resolver
(except perhaps for awkward resolvers polling the DNSKEY RRsets
for islands of trust at a high frequency). If promotion of good
quality DNSSEC implementation at the resolver side is desirable,
this TAKREM lack of interoperability with a less secure resolver
implementation is a good thing.

The fundamental issue is that an implementation claim of DNSSEC
compliance is an interoperability claim (claim supported by
empirical evidence), while the DNSSEC stated goal is end-to-end
data assurance mechanism which, by definition, implies resistance
to security incidents that are unlikely to be observed (by virtue
of the deterrent effect of security measures). There is no
software quality or security standard that can be readily applied
to a DNSSEC resolver implementation to provide assurance that
Internet clients actually experience increased security from
DNSSEC support.

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