Re: NSEC3, version 13

[Peter Koch <pk@DENIC.DE>]

On Sat, Dec 01, 2007 at 05:46:15PM +0100, Olaf M. Kolkman wrote:

> So the change is that the basic-4 steps procedure was removed and  
> replaced with text that amounts to "We'll solve this when we get to  
> this".

I agree with the changes proposed for -13 in Roy's message dated 30 NOV.

> problem that starts with the premisses in Sam Weiler's observation:
>    "but we aren't (as far as I can tell) requiring that an NSEC3- 
> SHA256-capable resolver also support NSEC3-SHA1"

This is one underlying assumption, although it doesn't _have_ to be
that way.  The new algorithm could as well mean "SHA256 or SHA1".
Theoretically this would allow a downgrade attack, but that could be
mitigated by doing a double transition (where the intermediate state
might even be infinitesimally small):
	NSEC3-SHA1 -> NSEC3-SHAng-or-SHA1 -> NSEC3-SHAng
Alternatively, for the transition phase, both hash algs could be signalled
in the DS RR.  Either of these could again have corner cases, but locating
and arguing them is not my point.  I am confident that the WG as a whole
understands signalling and rollover well enough to address the issue
once it becomes necessary. Hash algorithm is expected to be a _rare_
event, as opposed to key rollover, so extra manual intervention or
timing constraints appear acceptable IMHO.
The exact scheme will also depend on the operational environment at that
future date and thus could be dealt with later better anyway.

> Anyhow, as far as I am concerned, this is a corner case that can be  
> dealt with later. The current text does sufficiently flag this is an  
> issue and I am confident there is at least one blunt way to solve the  
> issue.

Seconded. Please make -13 happen.

-Peter

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>