Subject: Re: comments on nsec3-01

From: [email-masked] (Ted Lindgreen)
Date: Tue, 1 Mar 2005 15:46:40 +0100

[Quoting Roy Arends, on Mar  1, 15:11, in "Re: comments on nsec ..."]
....
> > > The most destructive action an adversary can mount at this point is a
> > > denial of service.
> 
> 'zactly.

Ok...
 
> > If I understand this correctly, then this expands to:
> >
> >  We don't really need the authenticated denial of existance machinery
> >  at all, as the most destructive action is a DOS.
> 
> Nope. Not at all. You're jumping to the wrong conclusion.
> 
> Let me rephrase that so you might understand what was between the lines:

Sorry, I keep having difficulties with reading between your lines...

> The most destructive action an adversary can mount at this point is a
> denial of service, as opposed to altering a response in such a way that a
> resolver now regards data as 'cryptographically not secured'
> 
> > If this were true,
> 
> Which is not. Please re-read my message.

Does that reviel the unwritten lines in between? I doubt it...

>From what I understand sofar:

- there is a timeframe in which a good and correctly configured
  resolvers can not (are not able to) verify some part of the
  authenticated denial of existance machinery;
- Sam then argues that this would not be an incentive for a
  domainholder to get into this stuff;
- Roy writes that it isn't that bad as it's only a DOS.

What I understand is that, with a good and correctly configured
resolver, the resolver-user may encounter a part of the world where
authenticated denial of existance can not be verified. This gives
two choices:

1. Be strict and accept that this part drops from your world;
2. Be lenient, and accept reduced security.

>From the perspective of a domainholder, I think Sam is right:
if the domain is valuable, the domainholder will be reluctant
to risk that his domain becomes invisible.

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.

-- ted

--
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: Roy Arends <[email-masked]>
Date: Tue, 1 Mar 2005 16:29:50 +0100 (CET)

>   domainholder to get into this stuff;

Exactly.

> - Roy writes that it isn't that bad as it's only a DOS.

No. No. No. No. No.

Please quote the part where I say that.

Roy wrote that its a DoS.
Roy did NOT write it isn't that bad.

I agree with Samuel. I noted it is hard to roll the hash-function
field. So did he.

> 1. Be strict and accept that this part drops from your world;

Hence a denial of service.

> 2. Be lenient, and accept reduced security.

You call this lenient ? Lenient to whom ? I call this plain stupid.

> to risk that his domain becomes invisible.

Hmmmm. If the domain is valuable, wouldn't you want resolvers to be
strict ? Enforce the upmost scrutiny ? Therefor use a better hash-function
?

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

> are gaping security holes, or just risks, threats, or only minor

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.

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

Roy

---

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:

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

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

---

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

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

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Mar 2005 22:21:06 +0000

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

---

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