Subject: comments on rollover requirements

From: Edward Lewis <[email-masked]>
Date: Wed, 17 May 2006 11:38:02 -0400

Referring to: 
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-01.txt

The document doesn't describe the usage scenarios that we will face - 
such as close-knit anchor management versus DLV-type anchor 
management, or complete compromise versus singleton compromise of a 
zone's key set.

Quite frankly, if amazon.com has three keys and one is compromised, I 
won't be able to discern which one.  The news will probably be 
broadcast on some TV station - what news anchor will be able to spit 
out which key is the compromised one.  Maybe if this were all 
automated, the difference between complete and singleton compromises 
is significant, but if there's any manual intervention, I don't thin 
there is a significant difference.

On to comments on section 5...

5.1  Scalability

This section ignores scalability from the point of view of the zone 
operator.  The only mention is how many anchors a resolver will 
configure.

No solution ought to be dependent on how many resolvers have the 
anchor configured.  There's not necessarily a relationship between a 
zone operator and the resolver operators.  E.g., the resolvers run at 
AOL (probably) do not have a special arrangement with .ZA.  No 
business link (like even TLD to registrar) at all.

5.2 IP Encumberance

Is this really the second most important point?  That's my only 
comment on this.

5.3 General applicability

IOW, don't special case the root zone.  What more is there to the requirement?

5.4 Support private networks

That sounds like 5.3.  All zones ought to be eligible to be anchors. 
And all zones have parents except the root.  (Where would a DS RRSet 
for the root zone sit?)

Is this section supposed to be a stub for split-zone anchoring?  Can 
the support be to "turn off" validation, as in a null DS record?

5.5 Detection of Staleness

When you live on top of an unreliable protocol (UDP), you can never 
"detect" anything reliably.  The lack of an obtainable DS RRSet may 
be the result of a disconnected network and not removal of it.

5.6 Manual operations permitted

I think that it should be obvious that an operator can always 
disable/ignore any automatic attempt to update the configuration of 
their server.  Even the software updating mechanisms for my laptop 
always ask permission before enacting an upgrade or using upgraded 
software.

5.7 Planned and unplanned

In an automated protocol, there's not much difference, is there?

5.8 Timeliness

"Distributed to security-aware resolvers" "timely" highlights the 
missing portion of 5.1 on scaling.

5.9 High Availability

This is needed, and made me wonder why we don't rely more on the CERT RR.

5.10 New RR types

5.11 Support for maintenance

This sounds like the functional requirements.

5.12 Recovery from compromise

This section is lacking substance.  It basically says "if the problem 
is easy to solve, then it should be solvable."  No discussion on 
whether there is a discernable difference between singleton failures 
or mass failures.

After reading this, in general, what is the interop problem?  It is 
"how does a zone make it's public key (data) known?"

On the one hand, I don't want to reinvent the wheel - meaning, why 
not rely on the CERT RR, a CA infrastructure, and maybe even a MIB 
for servers?  (Yeah, yeah, I know DNS'ers have this thing about MIBs.)

On the other hand, how much of this is a detail for implementers? 
Each server has it's own configuration interface, and trust anchors 
are just configuration entries?

On another hand, do I want to let something as sensitive as trust 
data be able to be silently updated, especially if it is something I 
may not understand?  (Reading cryptobytes is plaintext hard.)

On the other another hand, if I can do this in band, then the trust 
data passes along a path as safe as the application data (i.e., fates 
are shared).  But the down side is that if the app data can't get 
through, the trust data can't either.

I guess I am still leery of putting this mechanism only in to the 
port 53 traffic stream.  But it has it's advantages.

I just don't see this document describing the problem we are setting 
out to solve.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

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

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 18 May 2006 09:03:57 -0400

Thanks Mr. Lewis for your observations.

I somehow share your overall concerns, so I don't repeat.

I give some specific feedback below.

Edward Lewis wrote:

> such as close-knit anchor management versus DLV-type anchor management, 
> or complete compromise versus singleton compromise of a zone's key set.

DLV versus TAK rollover is a resolver issue. Currently only relevant to 
BIND resolver source code, if at all. Raising DLV interoperability with 
TAK rollover to a full-blown requirement is a step I would rather not see.

"complete compromise versus singleton compromise of a zone's key set" (I 
assume this refers to the KSK subset of the zone's key set, for the root 
or an island of trust, since other cases are not related to TAK 
management) You seem to adopt the security model of e.g. 
draft-ietf-dnsext-trustupdate-timers-02.txt, while a more abstract 
notion of "catastrophic failure mode" is more encompassing as a 
framework for formulating requirements. No scheme is devoid of a 
catastrophic failure mode, the idea is to select a scheme where the 
catastrophic failure can be made less likely.

> won't be able to discern which one.  The news will probably be broadcast 
> on some TV station - what news anchor will be able to spit out which key 
> is the compromised one.  Maybe if this were all automated, the 
> difference between complete and singleton compromises is significant, 
> but if there's any manual intervention, I don't thin there is a 
> significant difference.

The DNSEXT WG is chartered to work on an automated trust anchor key 
rollover solution, and the "complete compromise" (i.e. "catastrophic 
failure") is indeed significant as a circumstance where the automation 
does not work.

> [[...]]

The DNS heartbeat is paced by TTL values. The DNSSEC notions of 
inception and expiration times may be used to pace the planned automated 
  TAK rollover (e.g. in draft-moreau-dnsext-sdda-rr-02.txt). An 
emergency/unplanned rollover may be forced by manually "flushing the 
cache" in a DNS resolver, for the relevant section of the DNS state 
information (i.e. relevant to TAK management). This would be a suggested 
system management action following a specialized press report that some 
TAK has been compromised.

In other words, scheduled/planned rollover should perform the same 
security sanitization as expecteded from an emergency/unplanned rollover 
-- the difference is the possible manual trigger for the emergency case, 
avoiding the latency from the DNS resolver polling heartbeat.

> [[...]]

Regards,

-- 

- Thierry Moreau

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

Tel.: (514)385-5691
Fax:  (514)385-5900

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