Re: Evaluating DNSSEC transition mechanisms

[Roy Arends <[e-mail]>]

Just to be clear, we don't propose these mechanisms, they're just
there. What we _do_ recommend (propose) is partial TCR++.

More comments inline.

On Thu, 10 Jun 2004, Edward Lewis wrote:

> ##                 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.)

Okay, -01 will include this text.

> ## 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.

Okay. Someone send text pls.

> ## 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.

There are no encouragements here !!! see my first comment above.

> ## 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)

Will include.

> ## 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?

This is not opt-in........

> ## 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...)

No, not at all. Different versions. Unless ofcourse you'd see IPv6 as a
replacement op IPv4. Both can coexist, no ?

> ## 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.

Does too !   :-)

dnssec-ter falls back to dns, not to dnssec-bis in case newer era servers
babble with older era clients.


> ## 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.

See my previous comment.

> 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).

You got it mister ! And I learned a new word !

> ## 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?

You don't. Parent has either for a delegation. old-era-resolver will
ignore DS2 and mark the delegation usigned due to absence of DS. new

> ## 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?

Yes. It would be trivial.

> Would (not) a DOS attack be trivial?

Yes, a cypto DOS attack would be a little more trivial then just plain
query storms, sure.

> Now time for some rambling...

Oh, goody ;-)

> 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?)

Are you suggesting we don't yet publish -bis. Hold the code. Rewrite NSEC ?

My current thinking is that partial TCR is still the best long-term
solution. If folk can't wait for that, use on-demand-nsec-signing. ymmv.

Roy

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