Subject: Re: comments on nsec3-01

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Mar 2005 16:50:36 +0000

--- nontechnical content first:

in keeping with the peer-moderation philosophy that's sweeping some other
forums at the moment, i just want to say...

> You call this lenient ? Lenient to whom ? I call this plain stupid.
...
> You're confused. You're mixing valuable with visible.
...
> Ted, contact me off-list if you need help with your learning curve.

...that this is out of line, should never occur, and shouldn't be tolerated.

moreover, ted is right when he says:

>> However, more important than above details is, IMHO, that NSEC3 is
>> making DNSSEC so much more complicated that it becomes difficult for
>> even the people working on DNSSEC to comprehend what exactly are
>> gaping security holes, or just risks, threats, or only minor
>> inconveniences.

and i take his point to be that experts are still arguing over terminology
and fundamental assumptions, and the dnssec-bis data and security models now 
have so many subtle points that there is no way to validate it or prove it
to the satisfaction of any multi-person team.  the fact that roy...

> NSEC3 is complex, just a little more then DNSSEC.  Complicated is a
> personal view.  People who are working on DNSSEC and can't distinguish
> between gaping security holes, or just risks, can contact me anytime.

...believes that he understands it all, does not constitute validation or
provability.  and i disagree that complexity is a personal issue.  dnssec-bis
is objectively complicated, not just subjectively complicated.  but in any
case, no instance of us insulting eachother has ever been constructive.

--- technical content second:

i've been struggling recently to integrate sam's and marka's remarks about
the trivalued solution space for dnssec validation.  for one thing, it bears
heavily on the design of DLV.  for another thing, i don't think about it the
same way as they talk about it.

by tri-valued i mean that a validator can come to three possible conclusions:

   1. i can prove that this answer is secure
   2. i can prove that this answer is unsecure
   3. i cannot prove anything either way

to my way of thinking, it's a bivalued solution space, having #1 and #3 above
but no #2.  the subtlety comes in at delegation points, where #2 is important.
i call upon sam weiler, who has an excellent record for de-mystifying these
topics for me, to write a short piece explaining what #2 is and why it matters.

(the reason being, #3 is equivilent to a DoS, and #2 is not, and that's where
ted and roy aren't meeting up.)

--
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: Tue, 01 Mar 2005 22:21:06 +0000

> Yeah, borderline, but in the same level of "Does that reviel [sic] the
> unwritten lines in between? I doubt it..." > > Oh well.

that's a lot of he-said she-said, which i'm not interested in.  you're
welcome to feel that i've singled you out or chosen an example at random;
the fact will remain that we have to uplevel our behaviour if we want to
make progress (or for other reasons not directly relevant to the charter.)

> > ... i take [ted's] point to be that experts are still arguing over
> > terminology and fundamental assumptions, and the dnssec-bis data and
> > security models now have so many subtle points that there is no way
> > to validate it or prove it to the satisfaction of any multi-person
> > team.
> 
> If there is something wrong with the terminology and/or fundamental
> assumptions in the DNSSEC-bis documentation, please say so, its not an
> RFC yet.

i didn't say it was wrong, i said it was complicated.  complicated enough
that reasonable experts are still disagreeing over the meaning of it all.
and my point is not that the rfc's need to be changed but that we all need
to show a little compassion when we encounter terminological or conceptual
chasms.

> I hope I understand it all, but that was not the point.  The point is
> that NSEC3 is not a different planet compared to DNSSEC.  It is more
> complex, sure, but not an order of complexity greater as one might
> perceive.

then you are too close to it and may lack perspective.  dnssec-bis is
extremely complex on its own, and while NSEC3 might not be a large change,
it is at best a moderate change to something that's already very complex.
i'd caution you to remember that your familiarity with NSEC3 was not gained
overnight nor have you ever tried to consider NSEC3 without already being
an expert on dnssec-bis.  this stuff is complicated.  show some compassion.