Subject: comments on draft-arends-dnsnr-00

From: "Scott Rose" <[email-masked]>
Date: Mon, 12 Jul 2004 13:02:03 -0400

Just went over the DNSNR draft quickly.  Some comments -

1.  The acronym MNR and NMR are used, but I don't see them defined anywhere.
It isn't the authoritative only bit, is it?  Because the ascii
representation says it can have the value of '3'.

2.  The next owner name is represented as a domain name - what if it's a
hash value?

3.  TTL recommendations - Section 2 says there are none, but DNSSECbis has
the NSEC RR's TTL value be the SOA min.  Is there a good reason not to have
it be that value?

I would like to see this become a WG document as a possible replacement for
NSEC.  If it can address zone owners' concerns with zone enumeration.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy Arends
> Sent: Monday, July 12, 2004 11:17 AM
> To: [email-masked]
> Subject: draft-arends-dnsnr-00
>
>
> Hi, I've just submitted draft-arends-dnsnr-00.txt as an individual draft.
> This draft sollicits acceptance by the DNSEXT working group. The draft
> can be found at http://www.logmess.com/~roy/draft-arends-dnsnr-00.txt
>
> Abstract:
>
>    This document describes the DNSNR Resource Record (RR) for the
>    Non-Repudiation (NR) of Existence service in the context of the DNS
>    Security Extensions (DNSSEC).  The DNSNR is an alternative to NSEC or
>    "Authenticated Denial of Existence" Resource Records.
>
>    A signed DNSNR RR protects security-aware DNS components against
>    false denial of existence of RRsets by providing the RR types that
>    exist for its ownername, which optionally includes a
>    non-authoritative delegation point NS RR type.  Labels in the
>    ownername and the RDATA may be a hash-value as a defense against zone
>    traversal.
>
>    The DNSNR is an alternative to current NSEC or "Authenticated Denial
>    of Existence" records.
>
> Thanks,
>
> Roy
>
> --
> 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/>
>

--
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: Ben Laurie <[email-masked]>
Date: Fri, 16 Jul 2004 16:50:13 +0100

>    "Authenticated Denial of Existence" Resource Records.

I would argue against the use of the term "non-repudiation" in any case 
(for detailed reasons, see http://www.apache-ssl.org/tech-legal.pdf) but 
in this particular case, regardless of its lack of merit, it has the 
opposite meaning to that intended - that is, you are trying to repudiate 
existence.

In 2.1.5 you say "The Type bit for the DNSNR and RRSIG MUST be set 
during generation, and MUST be ignored during processing." - I don't see 
why?

3.2.2 says "The probability of finding a second preimage is 1 in 2^160 
for SHA-1 on average." - it would be more proper to say "the probability 
of a random string being a second preimage is 1 in 2^160..." (I can make 
the probability of _finding_ one as close to 1 as I like, by searching 
for longer).

Also, you have not dealt with wildcards at all.

If there is interest in allowing for opt-in in NSEC2 (optionally), btw, 
I am quite happy to modify it to do so.

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: Roy Arends <[email-masked]>
Date: Fri, 16 Jul 2004 19:43:16 +0200

> opposite meaning to that intended - that is, you are trying to repudiate 

As I understand, non-repudiation is a property achieved through 
cryptographic methods which prevents denying having performed an action 
related to the data.

The DNSNR record prevents denying of having performed signing a record 
set. This specific property is used for proving existence and absence.

> during generation, and MUST be ignored during processing." - I don't see 

Oh, thats the ol' silly state discussion. The first MUST follows from 
the fact that both record exist for a name, and must therefore be set in 
the DNSNR. The second MUST is to prevent future abuse when some idiot 
comes up with the idea of redefining interpretation of these specific bits.

> the probability of _finding_ one as close to 1 as I like, by searching 

Yeah, but not on average ;-) I'll rewrite that part as per your 
suggestion. Thanks !

> Also, you have not dealt with wildcards at all.

If there is special processing due to wildcards that is different from 
NSEC, I'll put it in. I haven't found one though.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Jul 2004 14:44:18 +0100

Roy Arends wrote:

>> I would argue against the use of the term "non-repudiation" in any 
>> case (for detailed reasons, see 
>> http://www.apache-ssl.org/tech-legal.pdf) but in this particular case, 
>> regardless of its lack of merit, it has the opposite meaning to that 
>> intended - that is, you are trying to repudiate existence.
> 
> set.

I cannot see how it achieves this. Specifically, I can trivially have a 
DNSNR record without ever having signed any record sets at all (except 
the DNSNR record, of course).

Cheers,

Ben.

---

From: "Roy Arends" <[email-masked]>
Date: Mon, 19 Jul 2004 16:13:55 +0200

----- Original Message ----- 
From: "Ben Laurie" <[email-masked]>
To: "Roy Arends" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 19, 2004 3:44 PM
Subject: Re: draft-arends-dnsnr-00

> the DNSNR record, of course).

If you would have signed a record set, the DNSNR prevents you denying
having signed that record set.

If you would not have signed a record set, the DNSNR prevents you claiming
that you did.

That is non-repudiation for DNS.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Thu, 22 Jul 2004 15:39:16 +0100

Roy Arends wrote:

>>>>>   Security Extensions (DNSSEC).  The DNSNR is an alternative to NSEC
> 
> or
> 

I don't see how - I could sign a DNSNR that denied the very record set I 
had actually signed.

> If you would not have signed a record set, the DNSNR prevents you claiming

Again, I can sign the DNSNR without having signed the record set.

Cheers,

Ben.

---

From: Roy Arends <[email-masked]>
Date: Thu, 22 Jul 2004 16:49:36 +0200 (CEST)

> I don't see how - I could sign a DNSNR that denied the very record set I

There are many ways of shooting yourself in the foot. The point is that
someone can't shoot you in the foot.

> Again, I can sign the DNSNR without having signed the record set.

Again, there are many ways of shooting yourself in the foot. If you would
do so (I don't recommend it, this is an analogy and purely hypothetical),
you are not complying with the DNSNR proposal.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 Jul 2004 18:17:11 +0100

> someone can't shoot you in the foot.

Well, that's not what you said: "the DNSNR prevents you denying having 
signed that record set."

If you want it to mean it prevents someone else denying it, I would 
argue even more strongly against the use of "non-repudiation" to 
describe this, since almost no-one would expect it to mean what you want 
it to mean!

---

From: Roy Arends <[email-masked]>
Date: Sat, 24 Jul 2004 01:23:47 +0200 (CEST)

> Well, that's not what you said: "the DNSNR prevents you denying having

Ben. It is very simple:

If _you_ state that _you_ signed record type AAAA and record type MX for a
given name, while not actually signing record type AAAA and record type
MX, that would be violating the spec.

Just as you can write an implementation that publishes a CNAME and an A
record type for a give name. Sure you can do it. But that would be
violating the spec.

> If you want it to mean it prevents someone else denying it,

Not 'someone else', but anyone.

> I would argue even more strongly against the use of "non-repudiation" to

That is arrogant.

Let me ask you this, if you see a record type for Non Repudiation of
existence of DNS data, what do you expect it to mean ? How is that
different from what I actually wrote ?

Roy

---

From: Roy Badami <[email-masked]>
Date: Sat, 24 Jul 2004 01:29:32 +0100

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

    Roy> Ben. It is very simple:

    Roy> If _you_ state that _you_ signed record type AAAA and record
    Roy> type MX for a given name, while not actually signing record
    Roy> type AAAA and record type MX, that would be violating the
    Roy> spec.

I'm going to have to agree with Ben here.  For it to consitute
non-repudiation as commonly understood, then doing as you describe
would have to be provable by a third party by means of the
cryptographic protocol, not merely a violation of the specification.

Non-repudiation of signing would mean that if you signed something you
can't later deny that you've signed it.  Or rather, that if you try, a
third party can prove that you're lying.  But that's a defining
property of signing and noone would explicitly state it; anyone can
check the signature and prove that you did indeed sign the data.
(Here "you" actually means someone who has access to your private key,
but that's an implicit assumption in these things.)

But that's not what we're taling about, I think.  What we're talking
about is signing some statement (some kind of NSEC++ record) that
asserts that a record doesn't exist.  It's just signing a negative
statement; it's not asserting that you didn't sign something; and it
has nothing to do with either non-repudiation or repudiability.

Indeed (not that it's relevant to the argument) but you *might* have
signed such a record in the past, that doesn't mean you can't now sign
a statement to the effect that the record no longer exists.

I am not a cyptologist, but AIUI, non-repudiation means that some
other party (either the other party in the transaction, or some third
party) is able to prove that the transaction did take place.

FWIW, the converse, repudiability, means that if you and I engage in a
cryptographic transaction, no third party observer (and perhaps even
neither of us) has evidence that would prove that the transaction
actually took place.

I really don't see either non-repudiation or repudiablity as being
relevent to the protocols we're discussing here.  We're simply talking
about making a signed statement that a particular record does not
exist.

    -roy

---

From: David Blacka <[email-masked]>
Date: Fri, 23 Jul 2004 22:18:49 -0400

> cryptographic protocol, not merely a violation of the specification.

Good lord, people.  You are arguing about the *name* of Roy's proposal. 
  Can't we be a little more productive and, say, suggest an alternate 
name? And perhaps discuss the *content* of the proposal?

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

---

From: Roy Arends <[email-masked]>
Date: Sat, 24 Jul 2004 10:25:30 +0200 (CEST)

> name? And perhaps discuss the *content* of the proposal?

Thank you. Meanwhile, to avoid further distraction by and discussion on
the name, I'll change it to NSEC3.

Roy

---

From: Paul Vixie <[email-masked]>
Date: 26 Jul 2004 00:40:22 +0000

> name? And perhaps discuss the *content* of the proposal?

we could do that, and we're apparently (as in NSEC3) going to do that.

however, based on the disagreements about the meaning of the name roy
chose, i think that there's still disagreement about what kind of negative
proofs ("should the middle be excluded?") people actually think is needed.

in other words, the disagreement about the name could be the tip of the
iceberg.
-- 
Paul Vixie

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 26 Jul 2004 09:47:09 +0200

I would have liked to keep this genie in its bottle but it occurs that
Roy's proposal is a mixture of NSEC2 and OPT-IN specs. I would say
that the same security properties of OPT-IN apply to the Roy's
proposal. I.e. the record provides proof that a certain part of the
namescpace is insecure. In that part of the insecure namespace you can
happily spoof names away or spoof a microzoft.com response.

If we want to have both obscured names and "non-secured" intervals in
your zone, so that during initial deployment you only have to create
and sign a handful of NSEC variants than Roy's proposal is worth
investigating.

If you want a choice between "fully  secured" zone with obfuscated NSECs 
and a zone with "insecure ranges" with obfuscated NSECs than NSEC2 with
an "OPT-IN" type flag seems to be the way forward.

--Olaf
  (no hats)

PS. For a name: Hashed Insecure Interval: HII RR

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Roy Arends <[email-masked]>
Date: Mon, 26 Jul 2004 10:43:00 +0200 (CEST)

On Mon, 26 Jul 2004, Olaf M. Kolkman wrote:

> proposal.

The NSEC2 specs in my proposal are different, but in general, yes, hashed
names and OPT-IN.

> I.e. the record provides proof that a certain part of the

Opt-in is an option.

> an "OPT-IN" type flag seems to be the way forward.

I don't understand what you are suggesting, since you start with the
notion that NSEC3 is a mixture of NSEC2 and OPT-IN, and you end with the
notion that NSEC2 with OPT-IN is different then NSEC3 (If/If).

Leaving opt-in aside for the moment, lets compare NSEC2 and NSEC3.

NSEC3 is backwards compatible with NSEC (using hash value 0), allowing
operators to first switch to DNSSEC-ter at some point in time, and after
that, whitch to hashed ownernames. NSEC2 is either-or. There is no bw
compatibility with NSEC2. If an operator wants to switch to plain labels,
not only does it need to switch to NSEC, also it needs to switch to
DNSSEC-bis.

NSEC3 does not 'flatten' empty-non-terminals, where-as NSEC2 emulates
empty non-terminals with an extra EXIST record type. This is because NSEC3
hashes individual labels, where NSEC2 hashes owner-names.

NSEC3 does not include 'hash-iterations' since the gain in obscuring does
not outweigh the additional cost in authoritative nameservers.

In general, the purpose of both records are the same: increase the cost of
zone-enumeration.

NSEC3 has NSEC2 properties. Additionally it is bw compatible with NSEC,
allows OPT-IN and does not need extra records like NSECINFO and EXIST.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Mon, 26 Jul 2004 10:46:54 +0100

> not only does it need to switch to NSEC, also it needs to switch to

I do not propose that NSEC2 should _replace_ NSEC, I propose that an 
operator can choose which of the two record types is supported.

> hashes individual labels, where NSEC2 hashes owner-names.

I am not wedded to the idea that the whole owner name should be hashed, 
but there are at least two considerations here:

a) Hashing individual labels will make the records _much_ bigger.

b) EXIST is only needed if the zone is more than one name deep (i.e. 
names within the zone contain dots), which strikes me as a rare situation.

> not outweigh the additional cost in authoritative nameservers.

Of course, you can set it to 1 in NSEC2 if you believe this.

> allows OPT-IN and does not need extra records like NSECINFO and EXIST.

NSECINFO does not appear in NSEC2-01.

Cheers,

Ben.

---

From: Roy Arends <[email-masked]>
Date: Mon, 26 Jul 2004 12:34:22 +0200 (CEST)

> operator can choose which of the two record types is supported.

I understand that. But both record types exist in different versions of
DNSSEC. To avoid switching back to previous versions of DNSSEC I included
bw compatibility. I would not encourage retaining NSEC and NSECX in a
single version of DNSSEC.

> names within the zone contain dots), which strikes me as a rare situation.

The tradeoff is as follows:

For one label deep, both proposals have the same cost. NSEC3 hashes one
label, NSEC2 uses a single hash.

For the 'rare situation' of more labels deep, NSEC3 has a larger ownername
due to multiple hashes, while NSEC2 has additional EXIST, RRSIG(EXIST),
NSEC2, RRSIG(NSEC2).

The thing to consider is that with NSEC2, empty-non-terminals disappear
and are now emulated by EXIST records (which are non-empty).

I won't use the hash-truncation argument, since it is presumed
controversial, and can be applied to both proposals.

> Of course, you can set it to 1 in NSEC2 if you believe this.

If an authoritative nameserver receives a query for a non-existent name,
it has to iterate the hash function on the QNAME until it can include the
overlapping NSEC2, right ? To me, that is a DoS factor.

> NSECINFO does not appear in NSEC2-01.

That is an improvement, but from the abstract of NSEC2-01:

   This document proposes an alternate scheme which hides owner names
   while permitting authenticated denial of existence of non-existent
   names.  The scheme uses three new RR types: NSECINFO, NSEC2 and
   EXIST.

Roy

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 27 Jul 2004 11:38:02 -0400 (EDT)

Avoiding the terminology discussion entirely...

I'm confused about how DNSNR is supposed to work with hashed next
names.  Perhaps I'm missing something.  I'd like to be enlightened.

It looks like you're continuing to use DNSNR/NSEC3 owner names which
match "actual owner names", to borrow Ben's terminology.  For example
(and I'd love to see an example with hashed owner names in the doc):

example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+alpha)) types
alfa.example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+beta)) types
beta.example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+apex)) types

(Which ignores the authoritative-only bit and doesn't say how much of
the next name you're hashing, since I don't understand that part of
the discussion.)

What answer is given in response to a query for c.example.com?  The
beta DNSNR tells me nothing, since I can't tell what name was used to
create the hash, and I can't tell if c.example.com would be covered by
the DNSNR or not.

In other matters, I find the discussion of the authoritative only bit
in 2.1.1 confusing, if not misleading.  If you want to not have DNSNRs
for unsecure delegations (or optionally not have them), just say
that.  Make it clear whether the authoritative only bit is a per-zone
thing or applies per-span, like opt-in.  And the incomplete citation
in the first paragraph of 2.1.4 is likely to be inconsistent with not
requiring DNSNRs at each name (including those unsecure delegations).

Also, the presentation format of the hash value is inconsistent
between 2.1.2 (third paragraph) and 2.2.

-- Sam

---

From: Roy Arends <[email-masked]>
Date: Tue, 27 Jul 2004 18:44:43 +0200 (CEST)

> Avoiding the terminology discussion entirely...

thanks

> (and I'd love to see an example with hashed owner names in the doc):

Examples will be in -01.

> create the hash, and I can't tell if c.example.com would be covered by

Assume a hash function that hashes

hash[34abc]:      G39291 (this is a hash over the salt value)
hash[34abc+www]:  A38565
hash[34abc+mail]: Q83881
hash[34abc+test]: L21772

and the following records in zone example.com:

example.com      SOA   ...
example.com      NS    ...
example.com      A     ...
example.com      DNSKEY ...
mail.example.com MX    ...
test.example.com HINFO ...
www.example.com  A     ...

After DNSNR/NSEC3 processing (probably part of 'zone-signing') the
following NSEC3 records are added:

A38565.example.com NSEC3 1 3 34abc G39291.example.com A
G39291.example.com NSEC3 1 3 34abc L21772.example.com SOA A NS DNSKEY RRSIG NSEC3
L21772.example.com NSEC3 1 3 34abc Q83881.example.com HINFO RRSIG NSEC3
Q83881.example.com NSEC3 1 3 34abc A38565.example.com MX RRSIG NSEC3

A query for 'c.example.com', say type A returns

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;c.example.com.    IN A

;; AUTHORITY SECTION:
example.com  SOA example.com ...
example.com  RRSIG SOA ...
L21772.example.com  NSEC3 1 3 34abc Q83881.example.com HINFO RRSIG NSEC3
L21772.example.com  RRSIG NSEC3

To check if this NSEC3 record in the authority section covers
'c.example.com', the 'c' labels is hashed.

hash[34abc+c]: P44889

Indeed, P44889.example.com is covered by L21772.example.com NSEC3 record.
It is within the interval of L21772 -- Q83881 provided by NSEC3.

> that.

I'll try to clarify that.

> Make it clear whether the authoritative only bit is a per-zone
> thing or applies per-span, like opt-in.

Per-span, I'll make that clear.

> And the incomplete citation in the first paragraph of 2.1.4 is likely to
> be inconsistent with not requiring DNSNRs at each name (including those
> unsecure delegations).

I'll update that.

> between 2.1.2 (third paragraph) and 2.2.

I don't see that, could you give me a pointer ?

Thanks,

Roy

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 27 Jul 2004 15:08:44 -0400 (EDT)

Thanks for the clarifications.  And thanks for your note on Monday
comparing NSEC2 and NSEC3.  I'm looking forward to reading -01.

Perhaps the reason I was confused starts with this line in Section 2:

   The DNSNR resource record lists RR types present at the DNSNR RR's
   ownername.

If the DNSNR owner name is a hash, this isn't quite true.  And this
line in 2.1.4:

   The value of the Next Owner Name field in the
   last DNSNR record in the zone is the name of the zone apex (the
   ownername of the zone's SOA RR).

Which implies that you're retaining the old (non-hashed) canonical
ordering.  Perhaps this doc needs the same thing I suggested for
NSEC2, a high-level description of what's changing.  It needs to be
very, very explicit that you may or may not have NSEC3's at the same
names as other records.  Like his doc, there needs to be a discussion
of what happens when the salt or hash algorithms change.

> Per-span, I'll make that clear.

You need to be explicit, then, that it's per-span in the (possibly)
hashed namespace, which means the names covered by a single NSEC3 will
vary depending on the hash algorithm and salt chosen.  If you have
some spans opt-in and some opt-out, this means the names in the
"protected" space will vary depending on the salt and hash algorithm.
This is a very interesting property, though it makes my head spin.

Thinking about "perfect hash functions" from the land of data
structures is leading me to wonder if one can create a hash algorithm
and salt such that you can force a set of names (ie. all of the
unsecured delegations in your zone) to be in one span, so you can mark
only that one span as opt-in yet secure the rest of the zone.

> I don't see that, could you give me a pointer ?

I think I misread this the first time, and then I didn't even
correctly describe the problem I thought I saw.  (I thought 2.1.2
said the salt was presented in base32.)  In any case, the third
paragraph of 2.1.2 is still unclear.  It reads as:

	... the hash function .... is presented by a base32 value.

I think you mean that the owner name and next owner name fields are in
base32, but that's not what the sentence says.  (Since the hash
function field is an unsigned integer, per 2.2.)

Again, I'm looking forward to seeing the next version.  I'd also
really like to see a discussion of wildcard handling, as Ben
suggested.

-- Sam

---

From: Roy Arends <[email-masked]>
Date: Wed, 28 Jul 2004 09:45:39 +0200 (CEST)

>    The DNSNR resource record lists RR types present at the DNSNR RR's

Ah yes, I tried to generalise. I will rewrite that.

> ordering.

Yes. The paragraph you are referring to starts with "If the Hash Function
Field has value 0,", which means that the ownernames of the NSEC3 records
are not hashed.

> Perhaps this doc needs the same thing I suggested for
> names as other records.

Okay.

> Like his doc, there needs to be a discussion

The revision will be similar to dnssec-bis-proto

 o Zone signing
   - Including NSEC3 RRs in a Zone
   - Example of a Secure Zone
 o Serving
   - Including NSEC3 RRs In a Response
   - Example DNSSEC-ter Responses
 o Resolving
   - Response Caching
 o Authenticating DNS Responses
   - Authenticated Denial of Existence
   - Authentication Example

> This is a very interesting property, though it makes my head spin.

My apologies, it is Per-Zone. Per-span does not work. Due to the pre-image
resistence of hash-functions it would be hard to augur which span covers
what qname, therefor the property needs to be applied to all NSEC3 in a
zone, not independantly. Plain ownernames (as opposed to hashed owner
names) do not have pre-image resistance, so the requirement could be
relaxed here, but then this proposal becomes very complex.

I'll make it explicitly "Per-Zone".

> only that one span as opt-in yet secure the rest of the zone.

This is very hard, due to the same issues as I've written above. A
workaround can be to query twice, but that is very ugly. It is far more
easy to declare it per-zone and be done with. If that would impose
irreconcilable constraints to a security policy, then the alternative
would be to not use it at all.

> function field is an unsigned integer, per 2.2.)

Ah, thanks. Will fix.

> really like to see a discussion of wildcard handling, as Ben

The wildcard handling in Bens draft is needed because NSEC2 obscures
empty-non-terminals, and therefor introduces EXIST. That makes handling of
wildcards different then current NSEC. NSEC3 handles wildcard exactly as
NSEC does, since empty non-terminals are not obscured. I will put in a
note saying that, but I do not see the purpose of discussing wildcard
handling when it is exactly as NSEC.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Jul 2004 16:30:51 -0400

I hope there's time to talk about this in San Diego (outside the 
meeting) - reading the doc and the ensuing thread has given me a 
headache. ;)  I thought the draft was introducing a new requirement 
for authoritative non-existence,  not needing to cover unsecured 
delegation points.  I thought this was about lightening the load on 
"widely delegated" zones (eliminating the need to include "NXT's" for 
un-DS'd delegations).

But the thread started on this non-repudiation thing I couldn't make 
heads of tails of.  To someone - you're right.  To many negatives in 
the there somewhere.

Of course I can sign "www.example.com A" and *then* sign a statement 
that I didn't - and still be valid.  It's okay so long as I remove 
the "www.example.com A" when I sign again.  ;) And, through the magic 
of caching, both statements can be floating in the ether 
simultaneously.  And that's why the non-repudiation stuff makes no 
sense to me.

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

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

---

From: Roy Arends <[email-masked]>
Date: Fri, 30 Jul 2004 09:58:02 +0200 (CEST)

On Thu, 29 Jul 2004, Edward Lewis wrote:

> headache. ;)

Lets do beer.

> I thought the draft was introducing a new requirement for authoritative
> non-existence, not needing to cover unsecured delegation points.  I
> thought this was about lightening the load on "widely delegated" zones
> (eliminating the need to include "NXT's" for un-DS'd delegations).

Yes. That is one of the requirements.

> heads of tails of.  To someone - you're right.  To many negatives in

I don't thing you're not right. ;)

So, yeah, I changed the name to NSEC3 to avoid confusion.

> that I didn't - and still be valid.

You can, but it wouldn't be valid. It is not that atomic. If you'd sign
"www.example.com A" you should sign a statement that you did, then serve
it as a whole. A MUST, not even a SHOULD.

Since that is called "authenticated denail of existence", a statement like
Authenticated denial of existence is a statement that is either
true or false. A one bit thing. Inverse the statement and it would be
authenticated proof of existence. The law of the Excluded Middle as Paul
Vixie pointed out.

So I looked for a meta-term that did not have the word 'existence',
'absence' nor 'denial' since that would discriminate half of the
statement.

Since a statement was signed to proof absence or existence, as a method to
avoid that statement being repudiated by anyone (by simply replacing a
positive response by negative response), I used the term non-repudiation.
Maybe ill-chose, maybe not, it doesn't matter, the term is now NSEC3.
Small gesture for the purpose of clarity.

> It's okay so long as I remove the "www.example.com A" when I sign again.
> ;) And, through the magic of caching, both statements can be floating in
> the ether simultaneously.

Yes, that is an operational thing. If it hurts to much, fiddle TTL.

> And that's why the non-repudiation stuff makes no sense to me.

No more non-repudiation for me. I'm a little scared to be drowned in the
marina for bringing back Opt-In.

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 30 Jul 2004 10:01:54 +0200 (CEST)

> avoid that statement being repudiated by anyone (by simply replacing a
             ^^^^^^^^^
             RRsets

Roy