Subject: Re: HEREIS "draft-vixie-dnssec-ter-00.txt"

From: Ben Laurie <[email-masked]>
Date: Wed, 02 Jun 2004 12:39:28 +0100

Paul Vixie wrote:
>    2.5. It is possible that DNSSEC-TER metadata could be synthesized using
>    only DNSSEC-BIS metadata.  For example, an NSEC2 RR which offers the
>    benefit of domain name confidentiality might use name hashes rather than
>    domain names to bracket a range of name nonexistence, and it might be
>    possible to compute these hashes using an existing NSEC RR.  Therefore,
>    a DNSSEC-TER specification might permit caching forwarders to synthesize
>    NSEC2 RRs using NSEC RRs, thus improving the number of round trips
>    otherwise called for in section 2.3 above.

I'd note that you'd need a complete copy of the zone to do this.

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

--
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: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 10:23:11 -0400

On Wednesday 02 June 2004 7:39 am, Ben Laurie wrote:
> Paul Vixie wrote:
> >    2.5. It is possible that DNSSEC-TER metadata could be synthesized
> > using only DNSSEC-BIS metadata.  For example, an NSEC2 RR which offers
> > the benefit of domain name confidentiality might use name hashes rather
> > than domain names to bracket a range of name nonexistence, and it might
> > be possible to compute these hashes using an existing NSEC RR. 
> > Therefore, a DNSSEC-TER specification might permit caching forwarders to
> > synthesize NSEC2 RRs using NSEC RRs, thus improving the number of round
> > trips otherwise called for in section 2.3 above.
>

And the private key.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: Derek Atkins <[email-masked]>
Date: Wed, 02 Jun 2004 10:28:45 -0400

> I'd note that you'd need a complete copy of the zone to do this.

It's worse than that -- the signature needs to be recreated as well
because you need to sign the hash-name instead of the original
domain-name.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: [email-masked]
Date: Wed, 2 Jun 2004 17:05:44 +0200 (CEST)

> because you need to sign the hash-name instead of the original

What Ben was referring (Ben ?) to is that the canonically ordered list of
ownername(X) and its projected canonically ordered list of
HASH(ownername(X)) are non-linear. In other words, X NSEC Y and HASH(X)
NSEC2 HASH (Y) have different Y for the same X.

If it were linear, binary search would make hashing purposes trivially obsolete.
If it were linear, it is not a one-way-hash function.

If a cache does want to convert NSEC to NSEC2, it needs knowledge of the
entire zone, the zones' private key, hash each individual owner name,
rebuild the NSEC2 chain using the ordered hashed ownernames and resign
each individual record.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Thu, 03 Jun 2004 12:02:37 +0100

> NSEC2 HASH (Y) have different Y for the same X.

Indeed I was.

Cheers,

Ben.