Re: Evaluating DNSSEC transition mechanisms
Edward Lewis <edlewis@arin.net> Thu, 10 June 2004 15:37 UTC
Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13806 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 11:37:44 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYRZd-000ITu-25 for namedroppers-data@psg.com; Thu, 10 Jun 2004 15:34:37 +0000
Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYRZb-000ITe-CD for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 15:34:36 +0000
Received: by smtp2.arin.net (Postfix, from userid 5003) id 4725119B7BA; Thu, 10 Jun 2004 11:26:25 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5AEC619B7B8; Thu, 10 Jun 2004 11:26:24 -0400 (EDT)
Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1755469; Thu, 10 Jun 2004 11:34:33 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a06020431bcee2fb29e74@[192.136.136.83]>
In-Reply-To: <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se>
References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se>
Date: Thu, 10 Jun 2004 11:34:42 -0400
To: Jakob Schlyter <jakob@rfc.se>
From: Edward Lewis <edlewis@arin.net>
Subject: Re: Evaluating DNSSEC transition mechanisms
Cc: "Olaf M. Kolkman" <olaf@ripe.net>, Ólafur Guðmundsson <ogud@ogud.com>, IETF DNSEXT WG <namedroppers@ops.ietf.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
## 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 +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- Evaluating DNSSEC transition mechanisms Jakob Schlyter
- Re: Evaluating DNSSEC transition mechanisms Roy Arends
- Re: Evaluating DNSSEC transition mechanisms Roy Arends
- Re: Evaluating DNSSEC transition mechanisms Edward Lewis
- Re: Online signing Roy Arends
- Re: Evaluating DNSSEC transition mechanisms Edward Lewis
- Re: Evaluating DNSSEC transition mechanisms Derek Atkins
- Online signing (was: Evaluating DNSSEC transition… Roy Badami
- Re: Online signing (was: Evaluating DNSSEC transi… Roy Arends
- Re: Online signing Alex Bligh
- Re: Online signing Paul Vixie
- Re: Evaluating DNSSEC transition mechanisms Paul Vixie
- Re: Evaluating DNSSEC transition mechanisms Ben Laurie
- Re: Evaluating DNSSEC transition mechanisms Jakob Schlyter
- Re: Online signing Francis Dupont
- Re: Online signing Ben Laurie