Re: Evaluating DNSSEC transition mechanisms

[Edward Lewis <[e-mail]>]

##                 Evaluating DNSSEC Transition Mechanisms
##                  draft-ietf-dnsext-dnssec-trans-00.txt

## 2.1 Mechanisms Updating DNSSEC-bis
##
## 2.1.1 Dynamic NSEC Synthesis
##
##    This proposal assumes that NSEC RRs and the authenticating RRSIG will
##    be generated dynamically to just cover the (non existent) query name.
##    The owner name is (the) one preceding the name queried for, the Next
##    Owner Name Field has the value of the Query Name Field + 1 (first
##    successor in canonical ordering). A separate key (the normal ZSK or a
##    separate ZSK per authoritative server) would be used for RRSIGs on
##    NSEC RRs. This is a defense against enumeration, though it has the
##    presumption of online signing.

To protect off-line signed data from exposure of the on-line private key,
you have to require that the key signing non-auth denial data ALWAYS be
different from the other zone data.  If you don't, all data is vulnerable
because of the on-line key, making the distinction worthless.  (This idea
was tried a long time ago, see the "signatory" field in the KEY RR flags
in RFC 2065, section 3.3.)

## 2.1.1.2 Limitations

I've been told that performing public key crypto on the fly is still
prohibitively costly.  It would be good if someone who knows more about
this added some hard data to that.

## 2.1.2 Add Versioning/Subtyping to Current NSEC
##
## 2.1.2.1 Coexistence and Migration
##
##    Since the versioning is done inside the NSEC RR, different versions
##    may coexist. However, depending on future methods, that may or may
##    not be useful inside a single zone. Resolvers cannot ask for specific
##    NSEC versions but may be able to indicate version support by means of
##    a to be defined EDNS option bit.

That would be a violation of the RR set rules in RFC 2181.  Servers can't
break up RR sets.  I'd strongly recommend making a zone stick to one
version, otherwise the semantics really get sticky for very little return.

You need to define the way in which older-era clients deal with the absence
of older-era NSEC records in a zone, if the server is unwilling to make
use of the older-era version.

## 2.1.2.2 Limitations

One limitation is that in the dns-choices draft, subtyping is strongly
discouraged.  There are reasons documented there.  Also, there is a strong
push to limit subtyping for applications - why encourage it for DNSSEC?
The latter isn't a first-order issue, the limitations documented in Patrick
and Rob's draft are.

## 2.1.2.4 Cons

I think "clean and clear" are not the right words.  E.g., we had subtyping
in the KEY RR and that went nowhere.  We need to learn from out mistakes.

## 2.1.2.5 Pros
##
##    Does not introduce an iteration to DNSSEC while providing a clear and
##    clean migration strategy.

I disagree with that - the very need to do what's in the previous section is
an iteration.

## 2.1.3 Type Bit Map NSEC Indicator

## 2.1.4 New Apex Type
## 2.1.4.2 Limitations

Requires special processing - to be included in responses as needed.

## 2.1.4.4 Cons

This proposal has died before, in 1999. (SEC RR)

## 2.1.5 NSEC White Lies
## 2.1.5.5 Pros
##
##    Hardly any amendments to DNSSEC-bis. Operational "trick" that is
##    available anyway.

Although I think this is an absurd proposal,  I'd be curious about the
operational "trick".  Absurd ideas need to be documented so we don't
revisit them.  (Signatory bits, subtyping, SEC RR, to name a few.)

## 2.1.6 NSEC Optional via DNSSKEY Flag
##
##    A new DNSKEY may be defined to declare NSEC optional per zone.

You can't have "optional" authenticated denial.  It's either on or off.
Perhaps the intent is that it is optional to use - and this has to be
specified in-line with the verification process (DS or DNSKEY record).

How (much) does this differ from the opt-in proposal?

## 2.2 Mechanisms not Updating DNSSEC-bis
##
## 2.2.1 Partial Type-code and Signal Rollover

That sounds like an update to DNSSECbis.  (Replacing it...)

## 2.2.1.2 Limitations

Does not take into account the interaction between newer era servers and
older era clients, assuming the newer era servers can't down-version their
responses.

## 2.2.2 A Complete Type-code and Signal Rollover

This assumes that newer era servers are capable of talking both old-era and
new-era (multiple for all eras) DNSSEC.  I.e., that any server that is
supposed to speak only new NSEC is willing to speak old NSEC too.

My assumption is that the motivation to use a new NSEC is that the old NSEC
is abhorrent to the administrator.  If that's true, then the old-era zone
must appear unsecured (as opposed to giving away the information).

A side effect is that resolvers need to know what era a key is from.  If
I install a trusted key for the root that matches the "new-era" in an
old-era resolver, problems ensue.  We've seen that in testbeds and is what
gave rise to the first TCR.

## 2.2.2.1 Coexistence and Migration
##
##    Both spaces can co-exist. They can be made completely orthogonal.

But are a burden on operations, or at least a potential burden.  How to I tell
my parent to gimme a DS but not a DS2?  An admin will have to support all
orthogonal security spaces until they are unwilling to support the older
era fan base.

## 2.2.3 Unknown Algorithm in RRSIG

## 3. Recommendation
##
##    The authors recommend that the working group commits to and starts
##    work on a partial TCR, allowing graceful transition towards a future
##    version of NSEC. Meanwhile, to accommodate the need for an
##    immediately, temporary, solution against zone-traversal, we recommend
##    On-Demand NSEC synthesis.

Is on-demand NSEC synthesis (specifically signing it's RRSIG) achievable?
Would (not) a DOS attack be trivial?

Now time for some rambling...

I do think that zone enumeration is a problem, but not a privacy problem.
This is based on "attacks" that use expected and dictionary-like attacks on
domains to hit them with email and/or other directed traffic.  So I think
we do need to think about the issue.

I'm increasingly skeptical that there is a good solution to the migration
problem though.  Besides recent reactions to the issue, having re-read the
SEC RR stuff, I realize I've had this concern since the late 90's.  One
big reason for the SEC RR was to version NXT.

The only possibility for migration into the future seems to me to follow
the accepted idea of key roll over (super-cession) in which data is offered
up in both old and new styles for some time.  The dual-mode time is needed
because of the slow adoption rate of data through caches and code through
enterprises.

But, with authenticated denial we have two strikes against us.  The reason
for going forward is that the old style is unacceptable.  And you can't
make authenticated denial records optional - that makes it too easy to
attack them.

I think.

I think that if there is to be a defense against zone enumeration, then
the NSEC as defined is DOA and is not worth adopting.  Can we drop it now
and later add the feature?  Well, no, thanks to the DS RR.  We need to
have authenticated denial to tie the tree (islands of security) together.

I doubt that a TCR will help.  The only reason is worked this time is that
no one is using the old DNSSEC.  Anyone signing zones according to 2535 is
not ever going to coexist with current-era code.  Resolvers won't understand
the difference in the trusted keys, and nothing has an understanding of the
DS record.

I really wish that we could do on the fly signing of responses for "no data"
and "name error."  To do that thought we need a NSK (negative signing key) to
go along with ZSK and KSK.

I just don't see how we can define old-era resolvers (DNSSECbis) to ever
handle any new (unforeseen) versions of NSEC assuming that the new code
won't back down to the old-era.  How do the old-era resolvers authenticate
new-era records?  (How should they know to panic?  How should they know which
way to panic?)

Aye, aye, aye, aye, aye...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

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