Subject: no gradual NSEC3 hash transition scheme.

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

The transition scheme was designed to allow zone operators to perform a 
smooth and gradual transition (i.e. over several versions of a zone) from 
and old hash to a new hash. This transition scheme has no impact on 
implementations whatsoever, it is solely operational, and written as a 
courtesy to zone operators. In theory, such schemes have a better place in 
informational documents like RFC4641. In practice, this still needs to be 
dealt with anyway.

In absence of a smooth and gradual transition scheme for hash algorithms, 
zone operators have a simple method to go from an old hash to a new hash. 
Simply replace the old with the new hashed NSEC3 records while the zone 
remains unsigned. State wise, the zone will go from signed (NSEC3-sha1) to 
unsigned to signed (NSEC3-newhash).

My proposal is to replace the transition scheme in section 12.1.3 with the 
following note:

<new text>
12.1.3. Transitioning to a New Hash Algorithm

   Since validators are instructed to ignore NSEC3 RRs with unknown hash
   algorithms, simply using a new or unknown hash algorithm directly
   will lead to validation failures with clients that understand NSEC3
   but do not understand the hash algorithm.

   When transitioning to a new hash algorithm, care must be taken to
   prevent client validation failures during the process.

   Note that this is an operation procedure. 

   The procedure is as follows: 

   1.  Roll the zone to an Unsigned State. The actual method for safely
       and securely transitioning the zone to an unsigned state is 
       outside the scope of this specification.  However, the end result
       MUST be that validators see this zone as unsigned.

   2.  Replace the NSEC3 RRs containing the old Hash Algorithm from the 
       zone with signed NSEC3 RRs with the new Hash Algorithm to the zone.
       Add the NSEC3PARAM RRSet to the zone.

   4.  Roll the zone to a Signed State. The actual method for safely and
       securely transitioning the zone to a signed state is outside the
       scope of this Specification.

</new text> 

As said, the _ONLY_ reason we had a transition scheme is to allow a 
gradual change from NSEC3-sha1 to NSEC3-newhash. The above change to the 
document will not cause any change in implementation, since by default 
zone operators are able to roll back a zone from signed to unsigned and 
vice versa, see RFC4641.

If there is a need for a smooth and gradual transition scheme while the 
zone remains signed, we can leave that for the document that standardizes 
the new hash algorithm. Let me emphasize that a smooth and gradual 
transition scheme is not critical.

I see this as the one way to avoid a complete bankruptcy of the IETF 
standardization process around NSEC3. 

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Oct 2007 14:26:35 +0000

on the basis of this thread, my advice to the working group and to IESG is
to reject the NSEC3 proposal and ask that it be taken off the standards track
and returned to the working group for further development.  we're tinkering
with the final product on the outbound loading dock while the truck's motor
is running, and the things we're tinkering with are potentially explosive
after they reach the field.

note, i say this as a strong supporter of the goals of NSEC3.  but dnssec-bis
has to ship, and this thread has convinced me that NSEC3 is a dnssec-ter issue.
dnssec-ter should also include roy's version of DLV, and have another TCR,
and is clearly going to take a year or two of development.

re:

> To: [email-masked]
> Cc: [email-masked]
> Subject: no gradual NSEC3 hash transition scheme.
> X-Mailer: Lotus Notes Build V702MAC_11052006 November 05, 2006
> From: Roy Arends <[email-masked]>
> Date: Fri, 19 Oct 2007 12:42:28 +0200
> Sender: [email-masked]
>

---

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

> standardization process around NSEC3.

I'm not sure what problem you're seeing, but I encourage you to take 
an active role in improving the process you see as broken.

Personally, I see the current events as a resounding success of IETF 
process, demonstrating the benefit of broad cross-area review.

After the NSEC3 document was put forward for IETF review (IETF LC on 
May 9th), one AD identified hash agility[1] as being underdocumented 
(on June 5th).  On October 16th, we saw a new document that included a 
longer description of how to handle hash agility.  Within 48 hours of 
that document being published, a new problem was found with the 
mechanism described.  And the WG is actively discussing how to 
proceed.

-- Sam

[1]  Which, as far as I recall, is an completely untested part of the 
spec.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Oct 2007 11:57:40 -0400

Dear colleagues,

> after they reach the field.

I understand the point of the argument above, but I cannot say I agree
with it.  In my view, Roy has already pointed out something important
about the apparently controversial text: it's really just courtesy
advice to operators, and doesn't affect implementation or
interoperability as such.  It's also not critical to deployment.

It is true that mistakes by operators when performing delicate
operations around algorithm management (or, for that matter, key
management) could have very serious results for the Internet
community.  But that is surely not news.  If there is a weakness in
trying to "add security" to an existing widely-deployed system, it's
that the addition is usually a good place to really screw things up in
practice.  Since the alternative is apparently to replace DNS (in
effect "reformat and reinstall the Internet), it seems like we have
settled on the better of the two options; but it comes with a risk.

Given the complexity of NSEC3, I don't think it should be a surprise
either that advice to operators is not going to be perfect.  I don't
see how putting off obtaining any operational experience with this
protocol is going to yield better results than trying to come up with
a perfect solution to every possible, but unlikely, use case.  We have
users who are ready to try to deploy this, and we have running code.
I don't think we should hold up the documents over disagreements about
the precise words with which to advise operators, and I really don't
think we should go back to the working group for another year or two.
There comes a time to ship, and we're past it.

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

---

From: Roy Arends <[email-masked]>
Date: Fri, 19 Oct 2007 18:09:33 +0200

> an active role in improving the process you see as broken.

I'd love to, but it seems that my hands are full with NSEC3 right now.

> (on June 5th).

Many area directors chipped in. I've addressed all their comments. Given 
feedback on suggested text. Sending out reminders when the deafening 
silence remained for weeks. It finally took a conference call to hash out 
(no pun intended) the agility problem. But I do apologize for the delay on 
my side. I had a two week holiday.

> On October 16th, we saw a new document that included a 
> mechanism described.
> And the WG is actively discussing how to 
> proceed.

We have bend over backwards to organize several workshops, spend a 
considerable amount of money to get vendors to implement this, have spend 
over three years on the NSEC3 standardization process. We've baby-sat this 
document through SECDIR and IESG. We have exhausted the working group (and 
I can imagine the IESG) by this process, which resulted in the authors 
walking on eggs to keep folks interested. I see that as the modus operandi 
these days to get things standardized in the IETF. Expensive, exhaustive, 
it might even be worth the effort. 

What I meant with the complete bankruptcy of the ietf standardization 
process is that at any time the process can be put to a grinding halt to 
discuss mere trivialities and wording changes like the stuff about the 
rationale we've been going back on forth on. It would be good to have a 
process 'with defaults', i.e. If folks can't come to an agreement, we 
default to X. That would include a strong, active and unbiased shepherding 
process management. 

> [1]  Which, as far as I recall, is an completely untested part of the 

The transition mechanism was tested for NSEC to NSEC3-sha1. It will work 
for transition between NSEC3-sha1 to NSEC3-shanew. It doesn't work for 
validators that have NOT implemented sha1, and only sha256. IIRC THERE ARE 
NO SUCH IMPLEMENTATIONS. If there would be such implementations, then 
validation _for those_ would not work during transition, and by that time, 
a BCP document can deal with it. I should have put 'mandatory to 
implement' for SHA1 in the document early on. I can't stress this enough: 
it was an operation text, not an implementation text.

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 19 Oct 2007 20:59:06 +0200

Sam Hartman <[email-masked]> wrote on 10/19/2007 06:29:55 PM:

> I'm going to ask the security directorate to review your proposal.  My
> personal belief is that requiring a transition through insecure is not
> OK, but I want to get the opinion of other security experts.

There is no such thing as 'requiring a transition through insecure'. We 
don't require anything. The proposed text is one method of doing it 
"gradually". One of many, but guaranteed to work. Besides, going through 
insecure is an option. If operators can transition within one zone 
increment, the insecure state is unnecessary but it would not be 
gradually, it would be sudden. But that would be another method, and there 
a plenty of methods to pick from.

> If others agree with you, then your text is fine. 
>
> If we're still
> stuck, then we probably want to take a step back and see what the
> requirements are for algorithm agility.

If we're still stuck, then we probably want to address this either in a 
separate operational document, or in the document that allocates this new 
hash algorithm for NSEC3 purposes.

Roy

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2007 12:29:55 -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. ]

If others agree with you, then your text is fine.  If we're still
stuck, then we probably want to take a step back and see what the
requirements are for algorithm agility.

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Sat, 20 Oct 2007 11:06:41 -0400

<char-hat=on>
For what it is worth similar question was asked to the working group about
2 years ago and the answer was that going through unsigned state was
better than having in place an untested complicated automated algorithm.

Thus the text Roy posted was consistent with the working group consensus
on the subject of transition from NSEC to/from NSEC3.

See: start of thread:
http://psg.com/lists/namedroppers/namedroppers.2005/msg01087.html

Highlighted messages:
http://psg.com/lists/namedroppers/namedroppers.2005/msg01107.html
http://psg.com/lists/namedroppers/namedroppers.2005/msg01156.html

Summary by Sam Weiler:
http://psg.com/lists/namedroppers/namedroppers.2005/msg01161.html

SamH, due to the distributed nature of DNS and the non-existence of negotiating
handshake, DNS is different from most other protocols and needs to be evaluated
as a special case.

<chair-hat=off>
DNS (IMHO) MUST be tuned to the more frequent operations and adding
code complexity to handle rare events should be discouraged and only done
when absolutely necessary.
IFF you/security-directorate think SHA1 is too weak and is going to have to be
replaced soon, at this point we can change the digest algorithm to one
of your choice, as there is no deployed base.

         Olafur

---

From: [email-masked]
Date: Sun, 21 Oct 2007 15:00:27 +0200

Olafur Gudmundsson wrote on 10/20/2007 05:06:41 PM:

> replaced soon, 

Hash functions for NSEC3 do not require collision resistance. The 
important cryptographic property here is pre-image resistance. IFF this 
property is considered somewhat weak in SHA-1, keep in mind that it can be 
mitigated by some factor using a higher iterations value. 

However, I have yet to see evidence that the pre-image resistance property 
of SHA1 is broken or even weak in such a way that it can be used to 
violate the  NSEC3 design requirement "DNSSEC-ter should not make it 
easier to enumerate zones than it is with plain DNS.".

> at this point we can change the digest algorithm to one

I refuse to change the digest algorithm at this point for arbitrary 
reasons. There is no deployment exactly because folks want to make last 
minute changes long after any last calls have ended. 

Roy

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2007 10:09:01 -0400

>>>>> "roy" == roy  <[email-masked]> writes:

    roy> Olafur Gudmundsson wrote on 10/20/2007 05:06:41 PM:
    >> IFF you/security-directorate think SHA1 is too weak and is
    >> going to have
    roy> to be
    >> replaced soon,

    roy> Hash functions for NSEC3 do not require collision
    roy> resistance. 
True.

    roy> The important cryptographic property here is
    roy> pre-image resistance. IFF this property is considered
    roy> somewhat weak in SHA-1, keep in mind that it can be mitigated
    roy> by some factor using a higher iterations value.

I disagree that preimage-resistance is sufficient for NSEC3's needs.
I agree that a hash that does not have primage-resistance is broken
for NSEC3.  However you're looking for something stronger.  In
particular, you want to hide as much information as possible about the
input.  Pre-image resistance only guarantees that I cannot actually
find the input; it doesn't say too much about how much information
about the input is leaked by the hash.  Now, there are upper-bounds on
how much you can leak and still get preimage-resistance.

However it's safe to say that the cryptographic requirements of NSEC3
are kind of complicated and that we have no good formal model for them
or thinking about whether hashes satisfy them short of random oracle.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2007 09:16:23 -0400

>>>>> "Andrew" == Andrew Sullivan <[email-masked]> writes:

    Andrew> Dear colleagues,
    Andrew> On Fri, Oct 19, 2007 at 02:26:35PM +0000, Paul Vixie wrote:
    >> on the basis of this thread, my advice to the working group and
    >> to IESG is to reject the NSEC3 proposal and ask that it be
    >> taken off the standards track and returned to the working group
    >> for further development.  we're tinkering with the final
    >> product on the outbound loading dock while the truck's motor is
    >> running, and the things we're tinkering with are potentially
    >> explosive after they reach the field.

    Andrew> I understand the point of the argument above, but I cannot
    Andrew> say I agree with it.  In my view, Roy has already pointed
    Andrew> out something important about the apparently controversial
    Andrew> text: it's really just courtesy advice to operators, and
    Andrew> doesn't affect implementation or interoperability as such.
    Andrew> It's also not critical to deployment.

I actually think it is critical to deployment because it is critical
to security.

One of the most critical aspects of security deployment is the ability
to deal with security problems and to fix them in a secure manner.
So, yes, deciding what we require of NSEC3 for algorithm agility and
convincing ourselves that we have the facilities to meet that is in
fact a necessary exit condition to standardize NSEC3 or any other
security sensitive technology.

In principle, if we were convinced that we knew how to solve the
problem and that we had the right facilities, we might not need to
actually write up the solution in this document.  However we're not
yet convinced we have the right facilities or even that we understand
what problem we're solving.

--Sam

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Oct 2007 14:05:49 -0400

Dear colleagues,

> to deal with security problems and to fix them in a secure manner.

If I understand the arguments so far -- and I do not pretend to be a
security expert -- the above is precisely the premise others are
denying.  That is (as I understand it) if you _really really_ had a
problem that demanded immediate withdrawal of an algorithm in use, then
the fall-back answer is to go through the insecure state.  That is not
ideal, but it appears anyway to be a corner case for which nobody has
yet provided a precedent, and that makes us no worse off than we
are today while possibly getting us some advantages.

> what problem we're solving.

The above sounds to me like a claim that the requirements for agility
are not yet known, and the problem itself is not completely
understood.  So the proposal is to refuse to standardise on a
technology that appears to solve most cases, because it is possibly
incomplete.  In addition, it seems there is an implicit proposal to
get a requirements document for agility, which would entail
understanding the problem completely.  

So, in favour of adoption is that we can deploy in the shorter
term, and gain experience; and if the worst happens, we are no worse
off than we are today.  Whereas if we do not publish the documents
now, we open the can of worms again, and we wait a couple more years
for any benefit.  Against standardisation on what we have now is
that it may not be completely bulletproof, and is certainly not
provably so.

I believe that security is not an absolute value, but a trade-off.
The present trade-off seems worth it to me, and I have yet to see a
strong argument that the advantage is not worth the admitted risk in
adopting what we have.  I'm totally prepared to admit I may be missing
something, but so far as I can tell, those advocating more design work
are arguing that anything less than a comprehensive solution -- one
that covers cases we have never seen and that some think are
irrelevant -- is not enough.  

I don't feel comfortable saying anything more on this topic, since I'm
not a security expert.  But if someone can describe why the above
characterisation of the two points of view is mistaken, I'd really
appreciate it.

Best regards,
A

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2007 17:25:04 -0400

Andrew> Dear colleagues,
    Andrew> On Mon, Oct 22, 2007 at 09:16:23AM -0400, Sam Hartman wrote:

    >> One of the most critical aspects of security deployment is the
    >> ability to deal with security problems and to fix them in a
    >> secure manner.

    Andrew> If I understand the arguments so far -- and I do not
    Andrew> pretend to be a security expert -- the above is precisely
    Andrew> the premise others are denying.  That is (as I understand
    Andrew> it) if you _really really_ had a problem that demanded
    Andrew> immediate withdrawal of an algorithm in use, then the
    Andrew> fall-back answer is to go through the insecure state.

Note that I'm not talking about quick withdrawal of an algorithm.  I'm
talking about a phased withdrawal of an algorithm.  You decide SHA-1 is
problematic today, and want everyone to be done using it say within
five years.  By that point, people will start considering SHA-1 as
insecure even if you have not yet withdrawn it.

>From my standpoint, the problem with Roy's new text is that it
requires people to go through an insecure state for every
transition--even gradual transitions where the desire to start the
transition is years ahead of the point when you want to withdraw the
algorithm.

I agree that dnsext participants seem to disagree with my claim that
deployment of new security should happen only after you have
transition strategies in place.  However, I think there is a broad
consensus in the security community behind something similar to my
original claim.  I believe that consensus is sufficiently broad that
we do not have a rough consensus of the IETF to publish a new protocol
with a security mechanism that has an inadequate algorithm agility
solution.

I think the question of whether Roy's new proposed text provides an
adequate strategy remains open.  My personal opinion is that it is not
adequate.  However the input I'm getting from the security directorate
is not providing particularly strong support for my position.  If
others don't join that discussion in the next day or two, I'll
conclude that I'm in the rough on this issue.

Here's one argument why you might prefer to publish nothing rather
than to publish something with an incomplete transition
strategy. Today, people don't depend on NSEC3.  People get whatever
level of security they have without assuming the availability of NSEC3
Typically this means they use something other than DNS to provide
security.

If we publish something without a transition strategy, we could box
ourselves into a situation where people depend on NSEC3 but where we
don't have the ability to incrementally deploy new algorithms.
Personally, I'd consider that situation significantly worse than
today's situation.  Arguments similar to this are what motivates the
concern within the security community behind algorithm agility.

I actually think the text in 12 is better than Roy's new text, even
given that it does not cover the corner case Sam found.  We probably
could fix Sam's corner case if we spent more time.

--Sam

---

From: Sam Weiler <[email-masked]>
Date: Mon, 22 Oct 2007 20:13:46 -0400 (EDT)

On Fri, 19 Oct 2007, Andrew Sullivan wrote:

> In my view, Roy has already pointed out something important
> interoperability as such.

I disagree: this goes beyond "courtesy advice".[1]

In the past, this WG has found it worthwhile to make certain that 
future extensiblity, including introducing new crypto algorithms, was 
accomodated by our protocols.  In at least one of those cases, we 
determined that not making changes to the protocol would greatly 
inhibit the introduction of new crypto algorithms.

Someone could try to make this case that this is a different beast and 
we don't need to specify a hash agility mechanism at all, but that's 
not what the WG appears to have choosen to do so far.  (I'll note that 
I proposed exactly this in February 2005.[2])

Absent such a case being made, it's entirely appropriate to ask if the 
hash agility mechanism we've defined actually works.  We seem to have 
determined that the mechanism documented in -12 doesn't work.  Let's 
fix it or make a case that we don't need it after all.

> I don't see how putting off obtaining any operational experience 
> with this protocol is going to yield better results than trying to 
> come up with a perfect solution to every possible, but unlikely, use 
> case.  We have users who are ready to try to deploy this, and we 
> have running code.

OK, then deploy it.  Obtain operational experience.  There are no 
protocol police.

-- Sam

[1] The fact that this is currently just operational guidance is an 
artifact of the hash agility mechanism chosen.  It's entirely possible 
that other mechanisms (perhaps ones that work better) will, in fact, 
impact the on-the-wire protocol and the implementations.

[2] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00400.html

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2007 20:56:59 -0400

>>>>> "Sam" == Sam Weiler <[email-masked]> writes:

nt such a case being made, it's entirely appropriate to
    Sam> ask if the hash agility mechanism we've defined actually
    Sam> works.  We seem to have determined that the mechanism
    Sam> documented in -12 doesn't work.  Let's fix it or make a case
    Sam> that we don't need it after all.

To be clear, we have determined that the mechanism in -12 cannot
handle a particular situation .

In my opinion that situation is more common than the authors believed.
I'm not entirely convinced that situation is sufficiently common that
the mechanism in -12 is broken.

In particular, I think that the mechanism in -12 works assuming that
you perform your transition during the long period when practically
all validators accept both hash algorithms.