Subject: Re: comments on nsec3-01

From: Roy Arends <[email-masked]>
Date: Tue, 1 Mar 2005 21:44:30 +0100 (CET)

On Tue, 1 Mar 2005, Paul Vixie wrote:

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

So, what exactly is wrong with this statement. I truly feel that lenience
towards security is not a smart thing.

> > You're confused. You're mixing valuable with visible.

Valuable and visible are two seperate things. He argued they were the
same, I gave a counter example.

> > Ted, contact me off-list if you need help with your learning curve.

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

Oh well.

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

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.

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

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.

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: Samuel Weiler <[email-masked]>
Date: Fri, 4 Mar 2005 03:25:12 -0500 (EST)

Let's have yet another thread.

Paul writes:

> 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.)

I'm working on a longer treatise on the subject, but since Paul asked
for "short"...

DNSSECbis (in -intro Section 5 and -protocol Section 4.3) describes a
slightly different set of states (or at least different labels).  It
uses "Secure", which looks like #1, and "Bogus", which is close to #3.
It also defines "Insecure"  and "Indeterminate", which I think are
both parts of #2.  There are a multitude of sub-states for each of
these, especially #3, but these three (combining Insecure and
Indeterminate) make a good starting point.

State #2, Insecure, is for cases where data isn't Secure through some
fault or lacking of the validator.  Perhaps the validator doesn't have
any trust anchors configured.  Perhaps it does have some, but none are
applicable to the zone in question.  Perhaps it doesn't implement any
of the algorithms used by the zone in question.  But it can figure out
what the deficiency is, and it knows that it has no reason to believe
the data ought to be in State #1.

State #3, Bogus, is for the rest of the cases, where the validator has
some reason to believe the data ought to be in State #1 (a trust
anchor for that zone, or a state #1 DS at the delegation point into
the zone, using a known algorithm), but the validation failed for some
reason.

To be clear, State #2 includes intentionally unsigned zones, where the
validator not having a trust anchor for those zones is a good thing.
Perhaps I shouldn't call that a lacking of the validator, and maybe
someone else will offer a better way to phrase the definition of state
#2.

Stay tuned for the longer version...

-- Sam

---

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

--On 04 March 2005 03:25 -0500 Samuel Weiler <[email-masked]> wrote:

> [ States are: Secure, Insecure, Bogus]

Am I correct in my assumption that EACH of the states above can support
both proof of existence and denial of existence.

IE you can have Secure existence, insecure existence, bogus existence, and
Secure denial of existence, insecure denial of existence, bogus denial of
existence.

If that is the case, then opt-in (at either end) gives insecure denial
of existence (using your taxonomy) for a query for a non-existent
name not covered by a signed interval, yes? (just so I understand
the taxonomy).

Are error conditions separate states from the above, or are they mapped to
one of the six possibilities above (sometimes / always)? and who does the
mapping (resolver or thing using resolver)? i.e. what happens if SERVFAIL
is returned / injected?

Alex

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 4 Mar 2005 11:27:47 -0500 (EST)

> Secure denial of existence, insecure denial of existence, bogus denial of

Generally, yes.  In some sub-states of 'Bogus', it may not be possible
to tell whether you're getting a claimed existence or non-existence
proof, but generally, yes.

> name not covered by a signed interval, yes? (just so I understand

Yes.

Normally, a resolver knows whether to expect data to be Secure on a
per-zone basis -- it knows, as it enters the zone, whether all data in
the zone is Insecure or whether it must do its DNSSEC magic to decide
between Secure and Bogus.

Opt-in changes that decision from being a per-zone thing to a
per-answer thing.  Opt-in allows Insecure answers (both non-existence
and existence) within an otherwise Secure zone.  I'm not sure what
you mean by "at either end".

I would prefer to avoid any case where NSEC3 does the same thing -- I
want a resolver to know, when it enters an NSEC3 zone, whether it is
marking the whole zone as Insecure or whether it is trying to decide
between Secure and Bogus -- I don't want it deciding, in middle of a
zone, between Bogus and Insecure.

> mapping (resolver or thing using resolver)? i.e. what happens if SERVFAIL

I'm not confident about the answer to this one -- perhaps others will
step in.  First pass: If you're in a zone that's supposed to be
Secure, all errors map to Bogus.  If you're in an Insecure zone,
everything maps to Insecure.  As for who does the mapping, I think
that's a question for the DNSSEC API designers.

-- Sam

---

From: Alex Bligh <[email-masked]>
Date: Fri, 04 Mar 2005 16:42:39 +0000

Sam,

--On 04 March 2005 11:27 -0500 Samuel Weiler <[email-masked]> wrote:

> and existence) within an otherwise Secure zone.

Agree - that is indeed a complication. My argument is that as (normally)
the security or otherwise of a zone (rather than a query) isn't presented
externally to the resolver, it is an internal complication to the resolver
only.

> I'm not sure what you mean by "at either end".

Me neither. Brain fart I think. Ignore.

> zone, between Bogus and Insecure.

Sure (meaning I understand what you say). But this is a result of any
proposal which includes opt-in like functionality (as NSEC3 as currently
drafted does). It has nothing to do with the hash properties, verification
states for unsupported hash algorithms, etc., does it? IE if one dropped
support for the opt-in like functionality in NSEC3, this problem would go
away for you. Similarly, if one introduced opt-in like functionality into
any other NSEC variant (like the original opt-in), this problem would arise
for you.

So the above issue is entirely connected with the support of
non-authenticated denial within otherwise secure zones, yes?
And it is an "internal to resolver" issues, yes? I'm not saying these
are non-issues, I am just trying to understand (a) their cause, and
(b) their scope.

>> Are error conditions separate states from the above, or are they mapped
>> to one of the six possibilities above (sometimes / always)? and who does
>> the mapping (resolver or thing using resolver)? i.e. what happens if
>> SERVFAIL is returned / injected?
>
> Secure, all errors map to Bogus.

Mmmm... that doesn't sound quite right if the effects are anything to go
by. Is it then impossible for a resolver's client to distinguish between a
SERVFAIL from the "real" server and a SERVFAIL injected by a
man-in-the-middle, on the basis that in a secure zone "all errors map to
Bogus" - if so, that seems like a rather obvious DoS vector.

Alex

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 4 Mar 2005 12:18:54 -0500 (EST)

> ... My argument is that as (normally) the security or otherwise of a
> zone (rather than a query) isn't presented externally to the
> resolver, it is an internal complication to the resolver only.

I really need to finish that longer rant (or just send it in its
present form).

I imagine, once we have a DNSSEC API and/or an ad-bit replacement,
that more security information will get passed up the stack.
Whether the security status of a zone, as such, is exposed, I'm not
sure.  I'm guessing it will be, since we're likely to expose the zone
cut at which validation failed (hence a security state of the final
answer's zone or its ancestor) or what trust anchor was used to
validate the answer (hence an inference about the security state of
all zones between that trust anchor and the answer).

> Me neither. Brain fart I think. Ignore.

No problem.  I had my own a few minutes ago, too (the need to disable
NSEC3 hash algorithms in resolvers), which you were very patient in
pointing out.

> are non-issues, I am just trying to understand (a) their cause, and

I was actually referring to reasons other than opt-in -- I could
imagine cases (like facilitating graceful roll-over to non-mandatory
hash algorithms) where one might mandate data in an NSEC3 zone being
treated as Insecure even though some other data in the zone was
Secure.  It sounds like there's agreement on treating unknown hash
algorithm NSEC3's as Bogus, not Insecure, so this concern is
addressed.

If we do opt-in as part of NSEC3 (which I wasn't thinking about, and
I'm not generally keen on), then, yes, we will see Insecure answers in
otherwise Secure/Bogus zones.  That's not what I was objecting to.

Perhaps this could be better stated as: I want a resolver to be able
to tell definitively whether a zone (or, with opt-in, a part of a
zone) is supposed to be Secure or not.  That determination should not
be based on what RRs it gets back in an answer UNLESS it knows
to expect those RRs and they can be validated.

> Bogus" - if so, that seems like a rather obvious DoS vector.

Welcome to DNSSEC.  (I don't like it either.)  I had a word for this,
but my management sat me down and asked me to quit using it.
Instead, I'll just say:

More gentle failures (than SERVFAIL) should be possible, especially
when we have richer interfaces (API's, AD-bit replacement) to the
validation results.  Another area to be explored is recovery from
validation failures -- are there ways for resolvers to "try harder" to
get a validatable answer?

-- Sam

---

From: Alex Bligh <[email-masked]>
Date: Fri, 04 Mar 2005 17:44:54 +0000

Sam,

> all zones between that trust anchor and the answer).

Hmmm... OK and thus the allegation is that the API is "changed" because the
API or users might otherwise assume that if the zone cut at which
validation failed was "secure", an insecure result should never be given?
Whilst I take this point, it seems to me (noting the "one we have a DNSSEC
API" comment) that this can be handled by a "do not assume this" comment in
the API document now - whether tri-state zones do or don't ever come into
play.

[side note: if you can indeed reliably expose the zone-cut at which
validation failed, it will solve, at least for DNSSEC, the 'how do I find
the zone cut' question posed here in relation to wildcard SRVs (ducks &
runs)]

> to expect those RRs and they can be validated.

Yes - I think we both agree, and that the above is satisfied (at least
without support for hash roll to non-mandatory hashes, which neither of us
now think is important).

>> by. Is it then impossible for a resolver's client to distinguish between
>> a SERVFAIL from the "real" server and a SERVFAIL injected by a

Hmmm... OK. I will avoid using similar words then ( :-) ), and just say
that in that case, if you consider:
A) that it's possible for a man in the middle to create such a DoS
   by injecting a SERVFAIL
B) now consider a protocol mod which allows injection by a
   man-in-the-middle of a packet that produces a resolver effect
   identical to the resolver receiving SERVFAIL (e.g. using an invalid
   protocol), and hence cause a similar DoS
it less than tenable say (A) is unproblematic whereas (B) is problematic,
given that for the interloper, (A) is rather easier to do than (B).

I can't remember who it was (now) that was arguing treating unknown
algorithm codes as a server error was dangerous (heh, perhaps it was
me), but in view of what you say it would seem to be an erroneous view.

Alex