Subject: NSEC3, version 12,

From: Roy Arends <[email-masked]>
Date: Wed, 17 Oct 2007 09:42:58 +0100

I tried to send this yesterday as well, but I haven't seen it come up yet 
on the list. 

Namedroppers and IESG folk,

The authors of the NSEC3 document have just released the latest version of 
the NSEC3 draft, version 12.

The previous version went through extensive IESG review, which 
subsequently brought the need for clarification on some topics. This mail 
will highlight the mayor changes to the document. The rfc-diff file is 
included as well.

1) The NSEC3PARAM Record.

There was confusion about the NSEC3PARAM record, in that it was thought to 
be processed in validators and resolvers. We have now made it explicit 
that the NSEC3PARAM is solely needed by authoritative servers to determine 
proper parameters.

2) Transitioning to a New Hash Algorithm

In section 12.1.3 ("Using New or Unknown Hash Algorithms"), the statement 
"It is suggested that a similar technique to the one being used in this 
specification to protect older clients be employed (see Section 2.)" was 
unclear. We have now rewritten that section (12.1.3) and it now contains a 
transition scenario. This is the exact same scenario as was suggested in 
the previous text. Subsequently, this caused the DNSKEY alias algorithm 
allocated in this specification to be used with SHA1 (for NSEC3 
algorithms) only. 

Thanks,

Roy

---

From: Matt Larson <[email-masked]>
Date: Wed, 17 Oct 2007 15:03:25 -0400

Roy,

> allocated in this specification to be used with SHA1 (for NSEC3 

These two changes look quite reasonable to me.

What's the next action?  Can the IESG to move forward with the
document now?

Matt

--
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: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Wed, 17 Oct 2007 20:10:12 -0400

Dear colleagues,

During the IESG evaluation of this documents a number of clarifications
were suggested to the document. As Roy stated in his message there is no
change in what the working group agreed to before sending the document
to the IESG.

See IESG discussion at:
https://datatracker.ietf.org/idtracker/draft-ietf-dnsext-nsec3/?

For complete history of changes to the document see:
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-nsec3/

For process reason this message starts a 1 week, comment period where 
members of
the WG can raise issues with word changes in the document or explain why
the new text differs from prior working group consensus.

At the end of this comment period on Oct 25'th the chair plans to notify the
IESG that the working group has no issues with the changes in the document, and
request the DISCUSS on the document be cleared.

Silence will be taken as an agreement that the textual changes are improvements
in documentation, and do not affect the working group consensus.
Statements saying you have reviewed the changes are greatly appreciated.

         Olafur

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 18 Oct 2007 09:52:37 +0200

> Statements saying you have reviewed the changes are greatly appreciated.

I have reviewed the -12 and -11 changes and they are fine. I note that
the changes do not affect my existing implementation.

>> that the NSEC3PARAM is solely needed by authoritative servers to

Indeed, that would not work, since a validator, due to time and caching
may get NSEC3PARAMs with different content than the NSEC3-parameters
that it gets in other (older or newer) messages.

Best regards,
   Wouter

---

From: Peter Koch <[email-masked]>
Date: Thu, 18 Oct 2007 10:55:24 +0200

> 2) Transitioning to a New Hash Algorithm

FWIW, I support these two clarifications.

-Peter

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Oct 2007 13:39:51 +0200

> change in what the working group agreed to before sending the document

My post was referring to changes between version 11 and 12.

Between version 10 and version 11, there was a change as well.

The original text in the rationale of version 10 reads:

   A second problem is that the cost to cryptographically secure
   delegations to unsigned zones is high for large delegation-centric
   zones and zones where insecure delegations will be updated rapidly.
   For these zones, the costs of maintaining the NSEC RR chain may be
   extremely high relative to the gain of cryptographically
   authenticating existence of unsecured zones.

The new text in the rationale of version 11 and 12 reads:

   A second problem is that the cost to cryptographically secure
   delegations to unsigned zones is high, relative to the perceived
   security benefit, in two cases: large, delegation-centric zones, and
   zones where insecure delegations will be updated rapidly.  In these
   cases, the costs of maintaining the NSEC RR chain may be extremely
   high and use of the "Opt-Out" convention may be more appropriate (for
   these unsecured zones).

The history and rationale behind that change is as follows:

1) During the security directorate review, Stephen Kent noted: 

"The second argument appears to be based on a tradeoff analysis between 
the costs of signing the NSEC RRs and the perceived security from use of 
this mechanism. This seems to be an apples/oranges sort of argument that 
requires much more justification."

The authors agreed with that, and asked Stephen Kent to rewrite that 
section, which resulted in the new text in the rationale.

2) During the IESG review, Sam Hartman asked us to either iterate that 
change back to the WG and measure consensus on it, or roll back the change 
to the previous version. 

To the authors, rolling back the change to the original version would 
re-raise Stephen Kent's point, hence we went for the first option, and 
thus this post is a result of Sam Hartman's request.

Since I'm not in a position to call for consensus on this textual change, 
I'd like you to consider it as part of Olafur's request: 

> members of the WG can raise issues with word changes in the document
> or explain why the new text differs from prior working group 
> consensus.

Thanks,

Roy

---

From: Scott Rose <[email-masked]>
Date: Thu, 18 Oct 2007 08:05:34 -0400

> Statements saying you have reviewed the changes are greatly appreciated.

I read the changes and I agree with them.  I think the new text is good.

Scott

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Thu, 18 Oct 2007 09:15:18 -0400

As has been pointed out to me version -11 should also be included in this
thread as version 10 was what the WG sent to the IESG.
See:
http://psg.com/lists/namedroppers/namedroppers.2007/msg00132.html
and
http://psg.com/lists/namedroppers/namedroppers.2007/msg00157.html

Consider the changes highlighted below as part of the changes you can 
comment on.
Remember we are only looking for issues that VIOLATE the WG consensus or
CHANGE the protocol.

In section 1. second paragraph was added as background:
    The enumeration is caused by the set of NSEC records that exists
    side signed zone.  An NSEC record lists two names that are ordered
    canonically, in order to show that nothing exists between the two
    names.  The complete set of NSEC records lists all the names in a
    zone.  It is trivial to enumerate the content of a zone by querying
    for names that do not exist.

In "3.1.2.1.  Opt-Out Flag" the following was added

    If the Opt-Out flag is set, the NSEC3 record covers zero or more
    unsigned delegations.

    If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
    delegations.

In 7.1 a new step was added to the algorithm:
    1.  Select the hash algorithm and the values for salt and iterations.

In 10.1 following was added as clarification:
    As an example, SHA-1 produces a hash of 160 bits.  The base-32
    encoding of 160 bits results in 32 characters.  The 32 characters 
are
    prepended to the name of the zone as a single label, which 
includes a
    length field of a single octet.  The maximum length of the zone 
name,
    when using SHA-1, is 222 octets (255 - 33).

In 10.3 the table for DSA was removed based on comments from the security
directorate review that it added nothing. The surrounding text was
modified to reflect this change.

IANA consideration section 11. was updated to be more explicit.

Following was added to the end of 12.1.1
    The salt SHOULD be at least 64 bits long and unpredictable, so that
    an attacker cannot anticipate the value of the salt and compute the
    next set of dictionaries before the zone is published.

Other changes are simple grammatical fixes.

         Olafur

---

From: Sam Weiler <[email-masked]>
Date: Thu, 18 Oct 2007 11:11:47 -0400 (EDT)

> allocated in this specification to be used with SHA1 (for NSEC3

I'm not convinced the documented scenario works.  Perhaps I'm just 
missing something, and I've be delighted to hear that.

I think the problem stems from a difference in required support: we 
require that NSEC3-capable resolvers also support NSEC, but we aren't 
(as far as I can tell) requiring that an NSEC3-SHA256-capable resolver 
also support NSEC3-SHA1.  (And I think that's a reasonable state of 
affairs, for sundry reasons, mostly related to the fact that we might 
want to entirely deprecate some hash algorithms in the future.)

Imagine a resolver that only supports NSEC3-SHA256 (or some other new 
hash algorithm), but not NSEC3-SHA1 (or whatever the zone is currently 
using).

Step 1: move to new DNSKEYs (with the new alg. identifiers for 
NSEC3-SHA256).

Step 2: add the SHA256 NSEC3 RRs.

Between steps 1 and 2, that resolver has some issues: it sees a zone 
signed with algorithms it groks, but it can't find appropriate 
NSEC3's.  Validation failures happen.

A resolver that supports both the old and new hash algorithms might 
even have a few difficulties, too.

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Thu, 18 Oct 2007 11:34:54 -0400 (EDT)

On Thu, 18 Oct 2007, Roy Arends wrote:

> Between version 10 and version 11, there was a change as well. ...

Thank you for calling this out.

I think the new text makes some slightly more definitive, and arguably 
incorrect, statements about the value of NSEC than the previous text, 
and it seems to encourage the use of opt-out.  I'd like to see this 
change rolled back or the paragraph recrafted to be at least as 
neutral as the previous version.  My proposed replacement text:

    "Certain large, delegation-centric zones wish to avoid the cost of
    cryptographically securing delegations to unsigned zones,
    particularly when these delegations will be updated rapidly.  The
    "Opt-Out" convention described in the document was designed to help
    them avoid that cost."

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Thu, 18 Oct 2007 11:36:06 -0400 (EDT)

Just informational...

On Thu, 18 Oct 2007, Ólafur Guðmundsson /DNSEXT  chair wrote:

[looking at diff from -10 to -11]

>   The enumeration is caused by the set of NSEC records that exists

FWIW, The above paragraph changed slightly between -11 and -12 as 
well.

> Other changes are simple grammatical fixes.

It appears that section C.2.3., "Possible Hash Value Truncation 
Method", was removed between -10 and -11, also.

-- Sam

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Oct 2007 18:20:17 +0200

> hash algorithm), but not NSEC3-SHA1 (or whatever the zone is currently 

I can't imagine a resolver supporting a not yet specified hash algorithm, 
while not supporting the current specified hash algorithm.

> NSEC3's.  Validation failures happen.

Yes, and so be it, for this extremely unlikely case.

Roy

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Oct 2007 18:39:35 +0200

> incorrect, statements about the value of NSEC than the previous text,

Could you please hightlight which statement is incorrect, and explain to 
us why it is incorrect?
 
> and it seems to encourage the use of opt-out.

Not at all. We strongly recommend that Opt-Out be used sparingly (section 
12.2).

I think the wording change is benign, and is actually more readable than 
the original text. 

What do others think ?

Roy

---

From: "Blacka, David" <[email-masked]>
Date: Thu, 18 Oct 2007 13:39:24 -0400

> want to entirely deprecate some hash algorithms in the future.)

I suppose.  I do find it hard to imagine a situation where you would
rather not validate the response than validate it using the old hash
algorithm.  Keep in mind this is the NSEC3 hash here, not a hash used in
the signature.

> hash algorithm), but not NSEC3-SHA1 (or whatever the zone is currently

Sam,

You do bring up a valid point.  The documented procedure (as written,
anyway) is only safe if  the validators are backwards compatible.

There are basically two events that are important here:

1) Changing the DNSKEY and DS sets.
2) Changing the NSEC3PARAM record (I'm using this as the point when the
servers start returning the new NSEC3 RRs in responses).

After #1, non-forward-compatible validators stop validating the zone.
After #2, the migration is complete.

We could, of course, change the procedure to do #2, then #1.  That would
work for your proposed non-backwards-compatible validator.  However, it
would break the zone for all of the non-upgraded validators, which, I
hope you would agree, would be a worse situation.

> A resolver that supports both the old and new hash algorithms might even
> have a few difficulties, too.

The procedure is designed for such validators, so I don't think they
would have any problems.

There is a way to change the algorithm so that it would work in your
scenario (as unlikely as I believe it to be):

1) Generate the new NSEC3 records.
2) Start serving both old and new NSEC3 records.  At this point, old
validators will ignore the NSEC3 RRs, new validators might ignore the
old NSEC3 RRs.
2) Change the DNSKEY and DS RRsets.  At this point, old validators stop
validating responses from this zone, so it is safe to cease returning
the old NSEC3 RRs.
3) Change the NSEC3PARAM and stop serving the old NSEC3 RRs.

Personally, I don't think it is worth changing the procedure, though.  I
think the scenario is very unlikely, and, if it *does* come about, the
document describing the new NSEC3 hash can outline a similar procedure.

-- 
David Blacka                          <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: "Blacka, David" <[email-masked]>
Date: Thu, 18 Oct 2007 14:58:55 -0400

Sam Hartman wrote:
>>>>>> "Blacka," == Blacka, David <[email-masked]> writes:
> 
>     Blacka,> 1) Generate the new NSEC3 records.  
> 
> 2) Start serving both
>     Blacka,> old and new NSEC3 records.  At this point, old validators
>     Blacka,> will ignore the NSEC3 RRs, new validators might ignore
>     Blacka,> the old NSEC3 RRs.  
> 
> I agree that 8.1 says that unknown hash algorithms should be ignored.
> However the text in 8.2 says that I can treat a zone as bogus if the
> response contains different hashes for some of the nsec3 records.  I
> think that if you make the change to the algorithm you need to change
> the text in 8.2 to make it clear that it is OK to have more than one
> hash provided that all the necessary nsec3 records can be validated
> with a single hash.

Hm, good point.  I guess I was thinking that if you were ignoring them
based on 8.1, then they wouldn't count based on 8.2.  But if you
understood both, then maybe there is a problem.

> 2) Change the DNSKEY and DS RRsets.
>     Blacka,> At this point, old validators stop validating responses
>     Blacka,> from this zone, so it is safe to cease returning the old
>     Blacka,> NSEC3 RRs.  3) Change the NSEC3PARAM and stop serving the
>     Blacka,> old NSEC3 RRs.
> 
>     Blacka,> Personally, I don't think it is worth changing the
>     Blacka,> procedure, though.  I think the scenario is very
>     Blacka,> unlikely, and, if it *does* come about, the document
>     Blacka,> describing the new NSEC3 hash can outline a similar
>     Blacka,> procedure.
> 
> I'd appreciate a response to my message about why I think this is
> reasonably likely.

I have not seen that message.

Just to be clear, the scenario that I consider unlikely is that both a)
a new NSEC3 hash algorithm is defined and b) validators are deployed
that actively refuse to validate an NSEC3 record using SHA1.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Oct 2007 13:17:31 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Roy, consider what happens when we decide a hash algorithm is weak.
What you seem to be saying is that we need to deploy the new hash
algorithm everywhere before we can start withdrawing it anywhere.

That seems problematic.  It seems that after a certain point you're
going to want to set validator policies that the old algorithm is no
longer sufficient and should be treated as insecure.  However under
the current strategy it actually ends up bogus rather than insecure.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Oct 2007 14:27:55 -0400

2) Start serving both

---

From: Matt Larson <[email-masked]>
Date: Thu, 18 Oct 2007 15:42:51 -0400

> I think the wording change is benign, and is actually more readable than 

I think either the -10 or -11 text is fine and I am opposed to any
further changes: let's just stay with what's in -12.  Quibbling about
this is passive-aggressive nit-picking and a waste of our time and
energy.  Let's move on.

Matt

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Oct 2007 19:54:08 +0000

> >     Blacka,> 1) Generate the new NSEC3 records.   ...
> > 
> > However the text in 8.2 says that I can treat a zone as bogus ...
> 
> based on 8.1, then they wouldn't count based on 8.2.  But if ...

gentlemen, the dnssec train was stopped to let NSEC3 on, and i'd take it
as a personal favour if the design could be finished, tested, proved out,
and made ready for deployment, so that we can restart that train.  basic
arguments about feature level and design implications have no place at
the 11th hour.  is this thing close to being ready to go, or not?

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Oct 2007 22:20:18 +0200

> the current strategy it actually ends up bogus rather than insecure.

I agree that the transition strategy fails in the scenario where the weak 
algorithm is not implemented in validators.

So, I suggest the most simple transition scenario possible, guaranteed to 
work with current implementations, does not cause a bogus state.

1) transition from NSEC3-OLD to unsigned.
2) transition from unsigned to NSEC3-NEW.

Roy

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Oct 2007 16:36:21 -0400

Dear colleagues,

> I think the wording change is benign, and is actually more readable than 

I agree.  I get Sam's point, but I don't think the document as
written encourages the use of the opt-out mechanism.  I also think
that another round on this will delay an otherwise useful document
even further, which seems to me to be a poor cure for a disease I
can't detect.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Oct 2007 16:38:35 -0400

Dear colleagues,

> Statements saying you have reviewed the changes are greatly appreciated.

I have read and compared the -10, -11, and -12 drafts of
draft-ietf-dnsext-nsec3.  I have no objections to any of the changes
between -10 and -12.

Best regards,
Andrew

---

From: Sam Weiler <[email-masked]>
Date: Thu, 18 Oct 2007 18:06:18 -0400 (EDT)

On Thu, 18 Oct 2007, Andrew Sullivan wrote:

> I also think that another round on this will delay an otherwise 
> useful document even further, which seems to me to be a poor cure 
> for a disease I can't detect.

Since we're already looking at (yet) another round on the document to 
address the hash algorithm agility concerns, dealing with this 
shouldn't really add any time.

-- Sam

---

From: "Blacka, David" <[email-masked]>
Date: Thu, 18 Oct 2007 18:46:12 -0400

> algorithm everywhere before we can start withdrawing it anywhere.

I don't understand this statement.

> the current strategy it actually ends up bogus rather than insecure.

This statement seems a bit misleading, but maybe it is just me.  I read
it as "once you declare the old hash algorithm as bad, my validator is
going to see all NSEC3-OLDALG-signed zones as bogus".  Which isn't true.

I'll agree that in the procedure outlined in 10.4, the zone will be seen
as bogus between steps 1 and 3, which is probably not a very long time.
 But the end state is fine.

I am quite curious, however, as to what sort of thing we are going to
have to find out about SHA1 to actually want to treat zones using signed
using NSEC3-SHA1 as insecure?

I'll just point out that NSEC3 doesn't use SHA-1 in quite the same way
as in RSASHA1 (e.g.), so the same attack scenarios don't necessarily
apply.  For example, I don't think that a collision attack is
particularly relevant.  However, I'm not a crypto expert, so I may be
talking out of my hat.

---

From: "Blacka, David" <[email-masked]>
Date: Thu, 18 Oct 2007 18:47:44 -0400

> 2) transition from unsigned to NSEC3-NEW.

Ah, simpler and even better.

---

From: Roy Arends <[email-masked]>
Date: Fri, 19 Oct 2007 16:28:42 +0200

> the 11th hour.  is this thing close to being ready to go, or not?

The design is finished, tested, proved out and made ready for deployment.

The only subject at hand is an operational consideration. I've send text.

Roy

---

From: Sam Weiler <[email-masked]>
Date: Fri, 19 Oct 2007 11:12:26 -0400 (EDT)

> 2) transition from unsigned to NSEC3-NEW.

No objection.  It might be worth noting that an alternative to 
"unsigned" is "use NSEC".  That also avoids the 2119 MUST ("...the end 
result MUST be that validators see this zone as unsigned.").

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Fri, 19 Oct 2007 11:18:19 -0400 (EDT)

On Thu, 18 Oct 2007, Roy Arends wrote:

>> I think the new text makes some slightly more definitive, and 
>> arguably incorrect, statements about the value of NSEC than the 
>> previous text,
>
> Could you please hightlight which statement is incorrect, and 
> explain to us why it is incorrect?

Sure.  Thanks for asking.

When talking about costs relative to the gain of signing, the old text 
makes a conditional statement, but the new text makes an unconditional 
statement.  (Paraphrasing and adding emphasis: OLD: "The cost MAY BE 
extremely high relative to the gain." v. NEW: "The cost IS high 
relative to the benefit")

(The paragraphs also make different statements about the absolute 
cost, but I'm not objecting to those.  (OLD: "... cost ... is high..." 
v. NEW: "... cost ... may be extremely high ..."))

The rearrangement of phrases in the two paragraphs can make it a 
little hard to decipher.  Each paragraph has one conditional ("may 
be"), one relative cost sentence/clause, one absolute cost 
sentence/clause, one "high", and one "extremely high".  Reshuffling 
those five items does not always lead to the same result.  :-)

To be clear: I don't attribute this change to malice.  I think it was 
a sincere attempt to improve the readability of the paragraph.  I just 
think it changed the meaning somewhat.

Answering the second question: Using the more definitive statement is 
(arguably) incorrect since the relative benefit may vary per zone and 
depending on one's perspective.  If you believe (as some do), that 
DNSSEC is all about protecting the resolver (or consumer of the DNS 
data): each consumer may have a different view of the value of the 
protection offered.

-- Sam

---

From: Danny Mayer <[email-masked]>
Date: Sat, 20 Oct 2007 23:19:22 -0400

> the 11th hour.  is this thing close to being ready to go, or not?

I agree with Paul on this. Also I don't think this group really has a
charter any more to make changes.

Danny

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2007 08:12:30 -0400

Blacka,> Sam Hartman wrote:
    >> Roy, consider what happens when we decide a hash algorithm is
    >> weak.  What you seem to be saying is that we need to deploy the
    >> new hash algorithm everywhere before we can start withdrawing
    >> it anywhere.

    Blacka,> I don't understand this statement.  Let's say we find
some problem with SHA-1.  We'll probably specify a new hash--perhaps
SHA-256.  Unless things are really grim for SHA-1 (a situation I
consider so unlikely as to ignore), we'll start by recommending that
people accept both hashes.

However the eventual goal will be to retire SHA-1.

However as attacks progress on SHA-1, we will eventually get to a
point where its use is counter-indicated and that sites with strong
security policies want to instruct their validators to treat SHA-1 as
insecure.

In order to avoid sites seeing SHA-1 to SHA-256 transitions as bogus,
we need to have everyone transition before the first sites make a
reasonable security policy decision that SHA-1 is insecure.

    >> That seems problematic.  It seems that after a certain point
    >> you're going to want to set validator policies that the old
    >> algorithm is no longer sufficient and should be treated as
    >> insecure.  However under the current strategy it actually ends
    >> up bogus rather than insecure.

    Blacka,> This statement seems a bit misleading, but maybe it is
    Blacka,> just me.  I read it as "once you declare the old hash
    Blacka,> algorithm as bad, my validator is going to see all
    Blacka,> NSEC3-OLDALG-signed zones as bogus".  Which isn't true.

    Blacka,> I'll agree that in the procedure outlined in 10.4, the
    Blacka,> zone will be seen as bogus between steps 1 and 3, which
    Blacka,> is probably not a very long time.  But the end state is
    Blacka,> fine.

    Blacka,> I am quite curious, however, as to what sort of thing we
    Blacka,> are going to have to find out about SHA1 to actually want
    Blacka,> to treat zones using signed using NSEC3-SHA1 as insecure?

    Blacka,> I'll just point out that NSEC3 doesn't use SHA-1 in quite
    Blacka,> the same way as in RSASHA1 (e.g.), so the same attack
    Blacka,> scenarios don't necessarily apply.  For example, I don't
    Blacka,> think that a collision attack is particularly relevant.
    Blacka,> However, I'm not a crypto expert, so I may be talking out
    Blacka,> of my hat.

    Blacka,> -- David Blacka <[email-masked]> Sr. Engineer
    Blacka,> VeriSign Infrastructure Product Engineering

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Oct 2007 08:16:51 +1000

>     Blacka,> VeriSign Infrastructure Product Engineering

	This whole discussion is predicated on a resolver that
	doesn't support a DNSKEY algorithm which indicates a weak
	NSEC3 hash but supports a DNSKEY algorithm which indicates
	a stronger NSEC3 hash.

	The solution is to not publish the DS record, thereby
	preventing a secure transition to the child zone, until the
	contents of the child zone are complete.  The zone is then
	provable insecure to that resolver.  This is already part
	of the requirements to publish a DS record.

	You don't make a per zone choice.  You make a per resolver
	choice.

	If you do want to make a per zone choice you need to attempt
	with the stonger algorithm and if that fails you do a
	insecurity proof of that algorithm before attempting with
	the weaker algorithm.  This behaviour falls within the base
	DNSSEC as it is equally applicable to NSEC zones as it it
	to NSEC3 zones.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Wed, 24 Oct 2007 00:33:10 -0400 (EDT)

Short Answer:

It doesn't look like it going to work.  I seem to recall there being a
requirement for running code before shipment.  There was also a
requirement to ensure we don't box ourselves into a corner.  I suggest
that perhaps someone could implement this, experiment with some new
(just different) hash, and work out the transition details, and any 
necessary changes.

So, I say, drop this document, and lets get the DNSSEC train moving 
again.

Some more detail supporting my view:

I had a professor at MIT who always said to ask yourself if things make 
sense. Its easy to crank away at meaningless numbers.  So let's step 
back and see if this makes sense.

I'm just a bit confused by the purpose. From draft 12 Section 1:

   An enumerated zone can be used, for example, as a source of probable
   e-mail addresses for spam, or as a key for multiple WHOIS queries to
   reveal registrant data which many registries may have legal
   obligations to protect.  Many registries therefore prohibit copying
   of their zone data; however, the use of NSEC RRs renders these
   policies unenforceable.

   This document presents the NSEC3 Resource Record which can be used as
   an alternative to NSEC to mitigate these issues.

With regard to the second and third paragraphs that I quoted above, its
not at all clear to me how NSEC3 solves these problems, or why NSEC (the
no '3' version) is needed instead of NXDOMAIN.  But I don't pretend to
follow the DNSSEC issues very closely, and I'm not a cryptographer.  As
the rest of the participants have addressed the crypto issues, I'll
leave that for people better versed on the subject. But, it seems that,
judging from the discussion, it doesn't solve these problems well.

But looking at the first paragraph I quoted above, is it not clear that
these goals are even legitimate problems to be solved in DNS or DNSSEC.
Finding email addresses in zones, or finding whois keys in zones are
both important and _public_ information, and I'm not sure why we care or
even _who_ is protected from finding out public information.

That's what I'm not sure of. I am sure of some few things:

I AM SURE that NSEC most certainly DOES NOT adversely affect the
obligation of a Registry to protect data. Registries deny zone transfers
because of their privilege to deny this, and because they can sell this
information. There is no _obligation_ for them not to do so. And I AM
SURE that we cannot prevent the guessing of email addresses. These don't
seem to be worthwhile purposes of all the effort going into making this
draft work.

Second, RFC3833 outlined things that were out-of-scope for DNSSEC:  
(RFC3833 Section 1):

   - While some participants in the meeting were interested in
     protecting against disclosure of DNS data to unauthorized parties,
     the design team made an explicit decision that "DNS data is
     `public'", and ruled all threats of data disclosure explicitly out
     of scope for DNSSEC.

So, it would seem that this proposal is, by RFC3833's definition, out of 
scope of DNSSEC work.

Work on this document 'doesn't make sense', and we should drop it.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Oct 2007 13:54:13 -0400

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:

    Mark> 	The solution is to not publish the DS record, thereby
    Mark> preventing a secure transition to the child zone, until the
    Mark> contents of the child zone are complete.  The zone is then
    Mark> provable insecure to that resolver.  This is already part of
    Mark> the requirements to publish a DS record.

    Mark> 	You don't make a per zone choice.  You make a per
    Mark> resolver choice.

I do agree that there is a solution in that space.  I think the text
in 8.2 should be cleaned up to allow for this solution.

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 24 Oct 2007 10:19:44 -0200

Mr. Anderson,

With all due respect, what doesn't make sense is waste others people
time with your misunderstanding of the subject in this thread or your
taste for realy bad jokes.

NSEC3 is needed, it's more than proofed to work and there are large
deployments that are only waiting the final document version to go
live.

Fred

> Short Answer:
...
> judging from the discussion, it doesn't solve these problems well.
...

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Wed, 24 Oct 2007 08:23:04 -0400

>(just different) hash, and work out the transition details, and any

Dean, for the record,
there is running code (but not released to the public) see:
http://www.nsec3.org/cgi-bin/trac.cgi/wiki/WorkshopReport

         Olafur

---

From: John Dickinson <[email-masked]>
Date: Wed, 24 Oct 2007 14:25:06 +0100

I have read the -12 draft and reviewed all the changes between -10  
and -12 and I agree with them. In particular I am happy with the -12  
wording in sections 1.1 and 12.1.3.

Section 1.1: The new text is an improvement on the old and taken with  
section 12.2 does nothing to encourage Opt-out.

Section 12.1.3: I am convinced that the transition mechanism works.  
As far as worrying about validators that understand SHANEW but not  
SHA1 - this is a corner case for which we now have at least four  
alternative solutions outlined in this thread. Clearly this is a,  
very unlikely, operational concern which DNSSEC and NSEC3 are more  
than flexible enough to cope with, so lets move on...

I also note that there has been working code for well over a year  
now, we know this stuff works and we know the transitions work.

BTW - I did find one typo:

Section 1.1: "The enumeration is enabled by the set of NSEC records  
that exists in a side signed zone." doesn't read quite right - should  
it be "The enumeration is enabled by the set of NSEC records that  
exist inside a signed zone."?

John
---
John Dickinson
[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Wed, 24 Oct 2007 16:18:24 -0400 (EDT)

One is not supposed to change the meaning of a message by selective 
quoting.

		--Dean

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Fri, 26 Oct 2007 11:18:21 -0400

DNSEXT WG and IESG members,

<wg-chair-hat=on>
The one week comment period has ended.
Number of issues where raised during this discussion.

There seems to be strong consensus that this document is done.
One typo was identified in an informational section, that can be handled
during the RFC-editing process.

On other issues there is either no consensus or the issue did not require
changes.

<document-shepherd-hat=on>
Sam Hartman has cleared his discuss on the document and version 12 can be
sent to the RFC-editor.

<wg-chair-hat>
Having said that, there is unease in the working group on how to handle
transition from one NSEC3 digest algorithm to another.
The working group chair identifies this as an issue that MUST be addressed
before a new NSEC3 digest algorithm is standardized.

         Olafur

At 21:22 17/10/2007, Ólafur Guðmundsson /DNSEXT wrote:
>For process reason this message starts a 1 week, 
>comment period where members of