Subject: Re: comments on nsec3-01

From: Alex Bligh <[email-masked]>
Date: Fri, 04 Mar 2005 10:29:30 +0000

Paul,

--On 03 March 2005 21:27 +0000 Paul Vixie <[email-masked]> wrote:

>> that's a reasonable requirement if by "use the new feature" you mean
>> "use NSEC3 not NSEC" provided you also add "and do not deliberately
>> use options that arguably make you more vulnerable" (e.g. opt-in).
>
> and yet, none of these takes account of what i meant by
> dnssec-of-the-month.
>
> every time we roll the hash algo for NSEC3, the problem recurs.
>
> if it was just that adding NSEC3 made zones less secure while validators
> were yet to upgrade, then there'd be a flag day.
>
> we're talking about a flag-tuesday.  every tuesday from now on.  is that
> ok?

I'm must be missing the point of what you saying, and/or there's
more agreement here than people realize.

I am saying that the introduction of new features in NSEC3 (which at
least by specification gives non-enumerability and opt-in) should not
weaken security for those who migrate from NSEC to NSEC3, but opt not
want to use features the very purpose of which is to reduce security
(e.g. opt-in) - i.e. if you migrate, you should have the option of being
unaffected. [*]

Now that INCLUDES any hash-roll algorithm that is in place within NSEC3.
So, taking the hypothetical case, IF NSEC3 introduced a hash-roll
algorithm that reduced security during a hash-roll, and (taking a
hypothetical case which I believe to be counterfactual, but...)
hash-roll is actually useful and likely to be used in more than a
test environment, THEN the NSEC3 does *not* meet criteria '*' above.
I think this is what you are asking by "is this OK" and, with the
previous assumptions the answer is "no".

This implies (in my book) we either have to
a) find a non-security-weakening form of hash-roll (which Ben seems to
   think he has already) OR
b) abandon hash-roll

For reasons I've set out elsewhere, whilst (a) sounds like a fun
engineering task (perhaps one already completed, perhaps not), I actually
don't see the point of hash-roll at all, in which case (b) is fine.

In the specific context of your question, I don't think hash roll (and I'm
talking about here not 'changing the hash algorithm to one the resolver
MUST support' or 'changing the salt' [**], but 'changing the algorithm to
one which which the resolver MAY not support') is going to be common at all
- why should it be every Tuesday? Are we not happy with "if all mandatory
hash algorithms are broken, we give up and have a flag day then". I think
that buys us a good 20 years rather than 7 days.

[**]=for these types of roll, surely there is no issue?

Alex

--
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, 04 Mar 2005 10:43:48 +0000

> don't see the point of hash-roll at all, in which case (b) is fine.

I agree. Just because NSEC3 has a field to specify the hash algorithm, 
it doesn't mean we have to be ready to update its meaning on-the-fly.

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: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 04 Mar 2005 11:53:44 +0100

> it doesn't mean we have to be ready to update its meaning on-the-fly.

But we do have to specify what applications do if they see that field 
having a value that they do not understand and we have to understand 
what happens if the applications receive such packets.

The problem in this case is that if the vallue of the hash field is 
critical in the verification of the answer. And if the field  is unknown 
the NSEC3 cannot be reliably coupled to the original QNAME.

--Olaf

---

From: Ben Laurie <[email-masked]>
Date: Fri, 04 Mar 2005 10:58:23 +0000

> the NSEC3 cannot be reliably coupled to the original QNAME.

Correct.

Cheers,

Ben.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 04 Mar 2005 11:12:50 +0000

>> the NSEC3 cannot be reliably coupled to the original QNAME.

& so the answer (where there is no hash roll to non-mandatory algorithms)
is that the server MUST NOT put a value in the hash algorithm field which
is not that of a specified mandatory algorithm in the NSEC3 docs (as
released), that the resolver MUST implement all such mandatory algorithms
(if that isn't tautology), and hence that if the resolver finds a value in
the algorithm field which does not map to such a mandatory algorithm, it
knows the server is behaving out of protocol.

According to Sam's exposition, the data is not insecure due to "some fault
in the validator", it is because the server is out of protocol. So the
correct interpretation here is state #3 (Bogus). That seems correct to me
(given that we are not trying to support roll).

Alex

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 04 Mar 2005 13:16:43 +0100

> (given that we are not trying to support roll).

I agree.

--Olaf
   (namedropper)