Subject: Graceful transition evaluation team volunteers

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Jun 2004 16:17:57 +0200

Dear Colleagues

With reference to 
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html

 "To ease the process of getting consensus we would like to ask for a
  few (3 or so) volunteers to make a summary of the proposed solutions
  and analyze the pros and cons during the weekend. If you want to
  volunteer please reply to both of us within 24 hours after posting of
  this mail so we can appoint the volunteers by Thursday and have results
  on Monday."

We have selected Peter Koch, Roy Arends and Jakob Schlyter from the
available volunteers. They will create this inventory. Thanks to the
others that volunteered.

Rob, Peter and Jakob are tasked with:

 - Making an inventory of the proposed mechanisms to make a
   transition to future work on authenticated denial of existence.

 - List the known Pros and Cons, possibly provide new arguments, and
   possible security considerations of these mechanisms.

 - Provide a recommendation on a way forward that is least disruptive to
   the DNSSEC bis specifications as they stand and keep an open path to 
   other methods for authenticated denial existence.

-- Olaf & Olafur
   DNSSEXT Co Chairs.

--
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: Jakob Schlyter <[email-masked]>
Date: Thu, 10 Jun 2004 09:48:14 +0200 (CEST)

I have just submitted our draft on 'Evaluating DNSSEC transition 
mechanisms' to the Internet Drafts editor for publication. while it's 
being processed, it can also be found at the following URL:

   http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-dnssec-trans-00.txt

 	jakob

---

From: Roy Arends <[email-masked]>
Date: Thu, 10 Jun 2004 17:14:15 +0200 (CEST)

>    http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-dnssec-trans-00.txt

To kickstart discussion, this is what we recommend:

   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 accomodate the need for an
   immediate but temporal solution against zone-traversal, we recommend
   On-Demand NSEC synthesis.

   This approach does not require any mandatory changes to DNSSEC-bis,
   does not violate the protocol and fulfills the requirements.  As a
   side effect, it moves the cost of implementation and deployment to
   the users (zone owners) of this mechanism.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Jun 2004 11:34:42 -0400

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

---

From: Roy Arends <[email-masked]>
Date: Thu, 10 Jun 2004 18:24:25 +0200 (CEST)

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.

> in RFC 2065, section 3.3.)

Okay, -01 will include this text.

> this added some hard data to that.

Okay. Someone send text pls.

> The latter isn't a first-order issue, the limitations documented in Patrick

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

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

Will include.

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

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

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

> older era clients, assuming the newer era servers can't down-version their

Does too !   :-)

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

> supposed to speak only new NSEC is willing to speak old NSEC too.

See my previous comment.

> must appear unsecured (as opposed to giving away the information).

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

> 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

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

> new-era records?  (How should they know to panic?  How should they know which

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 10 Jun 2004 17:32:07 +0100

> this added some hard data to that.

A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50 1024 
bit RSA signatures a second and less than 10 2048 bit signatures.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 10 Jun 2004 21:42:49 +0200 (CEST)

On Thu, 10 Jun 2004, Ben Laurie wrote:

> A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50 1024 bit 
> RSA signatures a second and less than 10 2048 bit signatures.

a decent crypto accelerator can do 4000+ 1024-bit RSA sigs/sec.

 	jakob

---

From: Roy Arends <[email-masked]>
Date: Thu, 10 Jun 2004 22:11:32 +0200 (CEST)

> a decent crypto accelerator can do 4000+ 1024-bit RSA sigs/sec.

Would you really want to use 1024-bit RSA for those short-lived denial of
existence records, which have a TTL of SOA minimum and prolly a
sig-lifetime that is equally low (in the order of minutes, instead of
days) ?

Roy

---

From: Derek Atkins <[email-masked]>
Date: Thu, 10 Jun 2004 16:15:21 -0400

Jakob Schlyter <[email-masked]> writes:

>> A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50
>> 1024 bit RSA signatures a second and less than 10 2048 bit
>> signatures.
>

My laptop, a 2-year-old Thinkpad, can do 145 1024-bit RSA private-key
operations per second using the openssl library:

                  sign    verify    sign/s verify/s
rsa  512 bits   0.0015s   0.0001s    673.1   6759.4
rsa 1024 bits   0.0068s   0.0004s    148.0   2565.7
rsa 2048 bits   0.0392s   0.0012s     25.5    826.5
rsa 4096 bits   0.2589s   0.0041s      3.9    246.7

A $400 dell that I just bought a couple months ago is significantly
faster (about 200 1024 sigs/sec):

                  sign    verify    sign/s verify/s
rsa  512 bits   0.0010s   0.0001s    995.4  11585.9
rsa 1024 bits   0.0050s   0.0003s    201.8   3878.2
rsa 2048 bits   0.0293s   0.0009s     34.1   1146.5
rsa 4096 bits   0.1998s   0.0031s      5.0    322.2

If the server starts getting resource constrained genering NSEC
records it can always just implement RED and return SERVFAIL ;)

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Roy Arends <[email-masked]>
Date: Thu, 10 Jun 2004 22:25:10 +0200 (CEST)

> records it can always just implement RED and return SERVFAIL ;)

I just received a private message stating their nitrox-II-cn2560
accelerator card can do about 40.000 1024-bit RSA ops/sec.

I think we're done with subject now, are we ?

Roy

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 21:24:53 +0000

> records it can always just implement RED and return SERVFAIL ;)

i'm glad you put a ";)" symbol on that, indicating that you're joking,
because otherwise someone would have to explain what bimodality is and
why it's bad to let an attacker control one's mode.

---

From: Roy Badami <[email-masked]>
Date: Fri, 11 Jun 2004 01:53:44 +0100

>>>>> "Roy" == Roy Arends <[email-masked]> writes:

    Roy> Would you really want to use 1024-bit RSA for those
    Roy> short-lived denial of existence records, which have a TTL of
    Roy> SOA minimum and prolly a sig-lifetime that is equally low (in
    Roy> the order of minutes, instead of days) ?

Apologies if parts of this breach radio silence, but it feels on topic
given the recommendation of online signing in the proposal we're
discussing...  Please take this offline if you want to discuss the
details of what I suggest (rather than the transition implications).

If I were architecting a system with online signing, I agree that I
would go for really short key lifetimes to allow me to safely use
shorter keys than I'd otherwise need to -- I'd roll over hourly if not
more frequently.  This in turn implies automated rollover, and hence
the keys that sign those keys must also be online.

So we'd need a key heirarchy where the short term online keys are
signed by a long term online key which is in turn signed by a
potentially offline key (probably the ZSK, which is of course in turn
signed by the KSK).  And you'd want a mechanism to prevent either of
the online keys being used as a normal ZSK.  I don't think you can
achieve this directly within the current DNSSECbis (which is not to
say the current proposal is a bad idea; just that DNSSECbis doesn't
currently provide an optimal framework for online signing).  Is there
an easy way of adding such a key heirarchy to DNSSECbis later?

As a slight aside, if I were architecting such a system from scratch,
I'd be inclined to consider combining it with Bloom filters, and only
signing denials where there was a collision in the Bloom filter -- in
other cases the Bloom filter itself could be used to prove
non-existence.

I'm reasonably confident that the combination of these two measures
would make the computational overhead of online signing a non-issue
for a normal query load, and they'd remove the concerns of offline
dictionary attacks.  Whether or not they'd be adequate to deal with
DoS scenarios is less obvious to me...

I realize we're in radio silence about the details of DNSSECter, so I
don't want to get into a detailed discussion about this idea.  I
mention it only because I haven't seen such an idea mentioned, and if
we're seriously considering online signing then it's worth bearing in
mind the possible shapes that a DNSSECter based on online signing
might take to help inform the current extensibility analysis...

     -roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 10:34:21 +0200 (CEST)

> might take to help inform the current extensibility analysis...

Bloom filters in DNSSEC is not new. SMB introduced them:
 www.research.att.com/~smb/papers/draft-bellovin-dnsext-bloomfilt-00.txt

The combination with ad-hoc signing of synthesised NSEC where
otherwise it would have been a false positive is new.

Anyway, I think crypto acceleration cards ops/sec are currently faster
then a DNSSEC capable aparatus can serve in q/sec.

I hope the assumptions one might have about a crypto-driven DDoS attack
is hereby tuned to a non-issue.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 09:51:47 +0100

> I think we're done with subject now, are we ?

In the sense that we know that crypto accelerators would be necessary, 
and that one exists of sufficient power (though not, as far as I can 
see, availability in a useful form) but unknown cost, then yes.

Cheers,

ben.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 10:03:48 +0100

> is hereby tuned to a non-issue.

I can't agree that having to deploy expensive crypto accelerators makes 
anything a non-issue. What I would agree is that it makes it a soluble 
issue.

Cheers,

Ben.

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jun 2004 11:56:41 +0200 (CEST)

> anything a non-issue. What I would agree is that it makes it a soluble

Sun commercial grade crypto accelerator 1000 board, part number x6762a,
currently costs around 2K euro (1339 GBP). A single board is capable
around 4300 ops/sec for 1024-bit RSA.

Roy

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Jun 2004 12:19:57 +0200

In your previous mail you wrote:

=> you can buy it for lower price at Broadcom or at some integrators:
http://www.broadcom.com/products/product.php?product_id=CryptoNetX+SSL4000
http://www.interfacemasters.com/products/nic/niagara2100pc-5/index.html

BTW I have two CryptoNetX IPS200A in DELL small servers so if someone
has a benchmark proposal...

Regards

[email-masked]

PS: IMHO 64-bit CPUs are a more efficient way. The only very fine thing
you can get only with crypto boards is not-ridiculous bandwith random
number generators, i.e., no more hard choice between bad quality or
very low bandwith (/dev/urandom or /dev/random).

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 17:28:22 +0000

> anything a non-issue.

then you're having a different conversation than the rest of us.

> What I would agree is that it makes it a soluble issue.

anything that can be solved outofband is a nonissue for dnssec-bis @IESG.

the conversation at hand is, can we send dnssec-bis to the IESG.

you appear to be saying "yes", both in the above "makes it soluble" comment
and in your agreement with my dnssec-ter-01 draft.

any issue like "the crypto boards will cost too much" isn't relevant.  any
issue like "online NSEC synthesis will expose the signing key to attacks
because the attacker can force the victim to do unsalted crypto" is relevant.

i realize that these issues are equally near and dear to you.  but they are
very different from the point of view of our chairs, who only want to know
if they can forward the dnssec-bis docset to the IESG.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 11 Jun 2004 18:45:29 +0100

--On 11 June 2004 17:28 +0000 Paul Vixie <[email-masked]> wrote:

> who only want to know

did they not ask for comments on -trans?

I am assuming here that it is relevant point to make, that although the
consensus on the WG is not to fix NSEC in -bis, this will likely cause
certain operators not to deploy until -ter; isn't that what transition
is all about?

Alex

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 17:53:58 +0000

> > who only want to know if they can forward the dnssec-bis docset to
> > the IESG.
> 

yes.  but -trans is just a straw poll on forwarding dnssec-bis to iesg,
so even though it has a different name, it's the same conversation.

> I am assuming here that it is relevant point to make, that although
> the consensus on the WG is not to fix NSEC in -bis, this will likely
> cause certain operators not to deploy until -ter; isn't that what
> transition is all about?

yes.  but saying "deploying -bis with nsec synthesis would cause me to
buy more hardware than i want given my anycast configuration" is not,
in and of itself, an argument not to forward -bis.  it is in fact a
tacit approval since it makes the case that under known and reachable,
though undesirable, circumstances, someone could deploy -bis without
waiting for -ter.  that's even better than "i can't deploy until -ter
but i agree that there's a reasonable way of getting to -ter from -bis"
which is mostly what the -trans (and -ter) authors are hoping for.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 11 Jun 2004 19:19:13 +0100

> which is mostly what the -trans (and -ter) authors are hoping for.

For the avoidance of doubt, my argument was not (given w/g consensus etc.)
that -bis should not be forwarded to IESG; my argument was that (a) -trans
should be fixed to show the "wait for -ter" option (as -trans considers
interim options), lest anyone get the impression that online synthesis was
such a no-brainer that "don't deploy until -ter" shouldn't be considered,
and (b) that the cons of synthesis should be fully documented. Neither
synthesis nor "don't deploy until -ter" require of themselves any change to
-bis, so if anything it's an argument *to* forward to the IESG.

Re your point on funding, my current view is I would far rather put funding
up to fix the issue properly (see Ben's work on NSEC2 & BIND), in terms of
protocol development, proof of concept, or getting production code cut,
than put funding up for synthesis; but I am listening to argument. This is
what I meant by the "distraction" argument.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Jun 2004 20:09:44 +0100

> if they can forward the dnssec-bis docset to the IESG.

Its not clear to me that the crypto boards will even exist, but that's 
not the important issue, as you say. What is important is exposure of keys.

However, I'm leaning towards the vastly cheaper and safer option of 
having a single (or two) NSEC record(s) that can be used for all denials 
as the interim measure of choice.

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Jun 2004 16:39:56 -0400

>there. What we _do_ recommend (propose) is partial TCR++.

I realized that.  My comments were meant to cover things I didn't see 
in the commentary.

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

Always glad to help.

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

Rambling means "I don't know." ;)

>solution. If folk can't wait for that, use on-demand-nsec-signing. ymmv.

As far as TCR being a strategy, how does a -bis era verifier detect 
that there is a new authenticated denial record replacing the one it 
expects to see?

Let's say NSEC is type code X, and NSEC14 is type code Y.  Y replaces 
X, but how does the verifier know that?  Maybe because it sees a Y 
where there ought to be an X?  Then what keeps someone from stuffing 
in a Z, not replacing X, but it looks like it to the verifier?  (Yet 
another rambling argument.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 21:29:30 +0000

> ..., I'm leaning towards the vastly cheaper and safer option of having
> a single (or two) NSEC record(s) that can be used for all denials as the
> interim measure of choice.

this will open you up to replay attacks.  anyone who receives one of these
NSECs, signed by you and clearly covering a large range of existing names,
would be able to use it along with queryid-guessing to make someone believe
an existing domain name does not exist.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 21:29:30 +0000

---

From: [email-masked] (Geoffrey Sisson)
Date: Sat, 12 Jun 2004 00:00:00 +0100 (BST)

> an existing domain name does not exist.

True . . . but NSEC RR replay attacks may be deeply less interesting
than other DNS m{an,onkey}-in-the-middle attacks.  So, many of the
benefits of DNSSECbis could be realised (including operational
experience) without the increased exposure of private keys which
dynamic NSEC synthesis would entail.  Of course this would be a -trans
mechanism only; authenticated denial-of-existence is ultimately an
important objective of DNSSEC.

Regards

Geoff