Subject: RE: Scope of discussion (was Re: Proposal to fix NSEC)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 23 May 2004 17:25:11 -0700

> In my previous mail I have listed two possibilities. Taking 
> up work to 
> prevent zone enumeration while holding the DNSSEC bis document-set or 
> shipping DNSSEC bis and forgetting about solving the enumeration 
> problem. Off course there are other options. Ship the document 
> DNSSEC-bis document set and work out the enumeration problem 
> later (but 
> commit on finding a solution).

I strongly suggest option 3 with one proviso:

Where the docs say MUST use NSEC say "MUST use a mechanism that
provides proof of non-existence"

> There may be other ways of going forward, stalling 
> development of NSEC2 
> but introduce a mechanism into DNSSEC-bis that introduces 
> versioning of 
> NSEC, if you see the signal you should expect the new features (say 
> NSEC2) or treat the zone as unsecured. That would delay too, 
> but maybe not that long.

Better than trying to go forward with deployment and discovering
that there is a protocol deficiency that cannot be fixed after
the fact.

People get paranoid about crypto specs, I used to. Then I started
an essay where I tried to prove this, only when I started to look
at the evidence SSL is in much better shape than anything else
despite being a disaster in original form, likewise with WEP.

Throw the stuff over the fence and see what sticks. Empirically
that is the best way to get to security.

--
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: "Loomis, Rip" <[email-masked]>
Date: Mon, 31 May 2004 11:42:44 -0400

Previously, the WG chairs asked for input  by 01 June
on WGLC and related issues, given the concerns raised
about NSEC and zone enumeration.  Since I'm going to
be out-of-pocket for two weeks and the chairs never
rescinded that request, here's my input.

Olaf wrote:
> I think it is clear at this point that the current
> DNSSEC-bis protocol spec eases content enumeration;
> I think it is clear that this causes a number of TLDs
> (and other players) to believe that they cannot deploy 
> DNSSEC in its current form.

I think that a capability that was not part of the DNS
protocol, but which many folks have made use of (and
may believe they rely on) is going to be undermined by
(most realistic schemes for) signed proof of non-
existence.  However, I would state that the "content
enumeration" bugaboo is to me just that--a bugaboo.

> Please refrain from further discussion of these two
> points; this is a real issue.

Sorry that I can't follow instructions, but I did want
to clarify the extent to which this is a "real issue"
in my mind.

> The question on the table is what this WG needs to do.
> 
> [slight editing follows to clearly state Olaf's options]
> Option 1. Taking up work to prevent zone enumeration
>    while holding the DNSSEC bis document-set
> Option 2.  shipping DNSSEC bis and forgetting for now
>    about solving the enumeration  problem.
> Option 3. Ship the DNSSEC-bis document set and work out
>    the enumeration problem later (but commit on finding
>    a solution).

I would prefer Option 2.  Option 2 doesn't mean that
issues with zone enumeration can never be addressed, but
it does make it less likely that major changes will be
made (because it makes the changes more painful to
implement).

I can live with Option 3, particularly if Opt-In (or
whatever a better name for it) is added back into the
mix of possible solutions.

I absolutely can't live with Option 1.  If I ever want
to have a prayer of having DNSSEC signed zones supported
in some fairly major software, we have *got* to get
DNSSECbis wrapped up and out the door.  It is deployable
today and I have no interest in waiting another 18
months for DNSSECbis-TNG (A/K/A DNSSECter).

Or, to put it more succinctly, I agree with recent messages
from Ted Lindgreen and Jim Reid that included the statement:

    Ted> So, I think that the working group should NOT delay DNSSECbis
    Ted> by trying to fold in NSEC2 this late in the process. If NSEC2
    Ted> needs to be worked out it should be done in a separate track.

  --Rip