Subject: RE: NXT design choices

From: Edward Lewis <[email-masked]>
Date: Tue, 3 Aug 2004 14:15:25 -0700

At 16:42 -0400 8/3/04, Loomis, Rip wrote:
>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.)

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

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

>>  (It seems like this
>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.)

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

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

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

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.

--
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: [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

Loomis, Rip wrote:
>  - 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.

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

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

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