Subject: RE: NXT design choices

From: "Loomis, Rip" <[email-masked]>
Date: Tue, 3 Aug 2004 16:42:30 -0400

Halloo Ed--

> To provide authenticated denial, the first choice made is whether to:
> 
> 1) Sign a tailored response to the query you are saying No to
> 2) Pre-compute all of the responses you will give out
> 
> Choice 1 was ditched because this meant that we needed on-line keys. 
> In the early days of DNSSEC (DNSSEC WG) the emphasis was more 
> security minded than operations minded, the thought of on-line keys 
> was abhorrent.

Choice one was ditched for more reasons, because not only were
on-line keys needed but the signing of a tailored response needed
to be done in real time.  It may be less significant an issue now,
but at the time the extra CPU cycles spent for "real time" crypto
as compared to "pre-computed" crypto were a major concern.

> (It seems like this 
on line storage of keys? (since your "this" isn't a clear reference)

> may be coming back in vogue.  But the concerns I 
> have are the transfer of the secret material between servers and the 
> role of encrypting it.  Back in the first DNSSEC implementations, 
> crypto export controls and patents combined to discourage encryption. 
> This is one reason why BIND's dnssec-keygen leaves the private key 
> file in plaintext.  I'm not up to date on crypto-business, so maybe 
> the old concerns are out moded.)

There are a much longer list of issues and concerns that need to
be expressed somewhere, some of which are unrelated to the NXT/NSEC
design choices (but I'm throwing 'em in anyway):

 - For zones that want to allow dynamic update of a signed zone,
   at least the master (or stealth master) server must have a
   zone-signing key available.  With several common usages of
   SRV records and/or DHCP, I see dynamic updates of signed zones
   to be extraordinarily likely.

 - For methods of authenticated denial that involve "real time"
   crypto, *all* authoritative servers must each have at least
   one zone-signing key available.  That makes life much harder
   to deal with securely than the dynamic update case above.

 - Hardware crypto devices may be able to provide both acceptable
   secure storage and speed (CPU) improvements to allow realistic
   signing of both zone data and authenticated denial responses
   in real time.

 - From my viewpoint, the organizations which are most concerned
   about zone-enumeration-through-NSEC are also those best able
   to afford a hardware crypto device to assist with things.

 - The fact that a hardware crypto device might be useful (and
   that a DNSSEC-TNG designed around them might be far superior
   to the current design) does not mean either that further delays
   in fielding DNSSECbis are acceptable, or that the current
   DNSSECbis design is broken.
 
[...]
> Choice 2b2 has been discarded because the community was happy with 
> the costs of choice 2b1 - not because choice 2b1 was optimal.

Well, I would describe it as "the community accepted the costs of..."
since I don't think happy was the best adjective to describe things.

[...]
> I personally don't think it's a matter of how important or why zone 
> enumeration is a problem/distasteful.  Zone enumeration is not and 
> has never been a desired feature of DNSSEC.  It was ignorable by the 
> original designers, so it persists.  

I agree with your statement above about zone enumeration. At the same
time, I agree with Paul and others who point out that obscurity of
DNS data has never been a designed-in feature of DNS (although it
may have been and may remain a desired feature.)

[...]
> Today we have Choice 2b1.  If we want to avoid zone enumeration, 
> we'll have to give something else up, what will that be?  On-line 
> keys?  Replay defense?  Muddled name space?  Even if we combine 2b1 
> with on-line keys - we need to break an old assumption (no keys 
> on-line).

I think that there are solutions that address perceived issues with
zone enumeration without requiring on-line keys.  If we can find
a method that meets "enough" of the requirements and desirements,
then I believe it's probably worth doing--but if it requires on-line
keys on all the authoritative servers for a zone for real-time
crypto then I believe it doesn't meet at least one of *my*
requirements.  I guess I'd better get with my esteemed co-editor
and get that added to the initial requirement/desirement list.

  --Rip

--
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: Edward Lewis <[email-masked]>
Date: Tue, 3 Aug 2004 14:15:25 -0700

>Halloo Ed--

(I was told you weren't in San Diego because you were on vacation. ;) 
Either you've blown your alibi or you need to get back to the pool.)

>as compared to "pre-computed" crypto were a major concern.

Yeah, speed too.  I forgot about that when I was composing the message.

>on line storage of keys? (since your "this" isn't a clear reference)

Yes - a verbal mention of this a few times around the IETF meeting 
rooms.  (I realize now that this idea hasn't been expressed on the 
mailing list.)

>be expressed somewhere...

Yeah (I deleted your list for brevity only)...

>may have been and may remain a desired feature.)

I'm happy, err, content with zone enumeration myself because it's not 
a goal of DNS to "hide" data.  On the other hand, ARIN servers don't 
permit AXFR.  On yet the other hand, our data is rather easy to 
enumerate.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: [email-masked]
Date: Tue, 3 Aug 2004 22:29:24 +0000

> permit AXFR.  On yet the other hand, our data is rather easy to 

	the data is available other ways tho.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 04 Aug 2004 02:44:47 +0100

>    to deal with securely than the dynamic update case above.

Not necessarily - they could relay the response (or the request) to a 
server that has the key (note that I'm not necessarily advocating this, 
just pointing out that it is possible).

> and get that added to the initial requirement/desirement list.

In fact it has already been added - it was in Nominet's list (that 
wasn't copied to you, unfortunately).

Cheers,

Ben.

---

From: "Roy Arends" <[email-masked]>
Date: Wed, 4 Aug 2004 03:05:25 +0200

From: "Ben Laurie" <[email-masked]>
To: "Loomis, Rip" <[email-masked]>
Cc: "'Edward Lewis'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 04, 2004 3:44 AM
Subject: Re: NXT design choices

> server that has the key (note that I'm not necessarily advocating
> this, just pointing out that it is possible).

Or, as an alternative:

each authoritative nameserver generates a keypair within timeframe X, and
uses secure-dynamic update to the primary to update their specific zone-key
to the primary, followed by an incremental zonetransfer. If configured
correctly, the incremental zonetransfer follows automatically, since the
primary increases SOA and notifies secondaries.
This method does not require oob key propagation.

Roy