Subject: RE: NSEC+ and NO

From: Ted Hardie <[email-masked]>
Date: Tue, 25 May 2004 10:52:41 -0700

At 10:06 AM -0700 05/25/2004, Hallam-Baker, Phillip wrote:
>
>>From a pure security perspective NSEC buys you very little of value.
>This is because DNS is not just a protocol, it is a component in
>a system. In a system there is no useful distinction between
>a subsystem that replies 'It does not exist' and one that says
>'I cannot find it'.

I strongly disagree with this.  From an application designer's perspective,
getting back a *trustable* "this does not exist" is very different from getting
"I cannot find it".  You may be thinking in terms of human driven activities
like browsing, in which there is a human to apply heuristics to an error
code; in some of those the human tends to apply the same guesses
to what to do next in response to both.  But this is not the only class
of applications, and for many of the discovery elements of those,
I believe reliable data for non-existence is required.

Speaking personally,
			regards,
				Ted Hardie

--
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: Edward Lewis <[email-masked]>
Date: Tue, 25 May 2004 13:50:00 -0700

At 10:06 -0700 5/25/04, Hallam-Baker, Phillip wrote:
>Hold it right there. This issue has been raised repeatedly, but I
>have yet to hear a substantive answer. All I have seen or heard is
>pointers to claims that it has been answered before.

First a plea for civility.

I've yet to see any response (on-line, I did get one verbal response) 
to my NSEC2 examples.  In my mind they listed the issues I perceive - 
"in my mind."  If what I have written is unclear or misinformed as 
far as premise, I'd appreciate comments on the examples.

The messages are:

   http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00608.html
and
   http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00610.html

(To keep threading clean, if you have comments on the messages, reply 
to those, not this message.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: Roy Badami <[email-masked]>
Date: Tue, 25 May 2004 23:00:42 +0100

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:

    Edward> I've yet to see any response (on-line, I did get one
    Edward> verbal response) to my NSEC2 examples.  In my mind they
    Edward> listed the issues I perceive - "in my mind."  If what I
    Edward> have written is unclear or misinformed as far as premise,
    Edward> I'd appreciate comments on the examples.

Of course, the Nominet zones (at least) have no wild cards, and this
is true of most TLDs.  And the immediate example that springs to mind
of a TLD that currently uses wildcards is .museum, which uses the
wildcards to take a browser to an index page listing names in the
museum gTLD -- so they presumably would have no concerns about
enumeration.

So a simplified NSEC2 that prohibited wild cards in the zone might
well satisfy the concerns of the vast majority of TLD operators, and
perhaps others, too.

I'm sure someone elsewhere in this thread implied in passing the idea
that zones might be given a choice of mechanisms for authenticated
denial: one with the properties of NXT/NSEC, or an alternative that
lacked the perceived enumeration problem but constrained the zone to
contain no wildcards.

However I think I concur with something that I think someone else in
this thread (sorry, I forget who) had in mind a while back: _if_ any
changes are going to be made to the spec at this stage, the one change
that should seriously be contemplated is introducing a mechanism
allowing a zone to declare (on a per-zone basis) what authenticated
denial mechanism they use.

I'm inclined to believe that authenticated denial should remain a
mandatory feature for secure zones, but a flag indicating what
mechanism the zone uses would make any future introduction of an
alternative to NSEC much more painless.

If an alternative authenticated denial proposal gains support
subsequent to DNSSEC deployment, then such a flag would allow
resolvers not supporting the new mechanism to (correctly) return an
unauthenticated NXDOMAIN response (or a null answer in the case of an
empty non-terminal) rather than returning SERVFAIL.

	-roy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 25 May 2004 19:09:28 -0400

> alternative to NSEC much more painless.

If possible, this pick-your-poison approach sounds good to me.

-andy

---

From: [email-masked]
Date: Wed, 26 May 2004 10:25:54 +0200 (CEST)

> denial mechanism they use.

You can't declare anything 'by zone'. A resolver is _completely_clueless_
about zone concept. A zone in merely space delegate to an entity minus
subspace delegated by that entity.

If, big if, anything can be declared by zone (similar like SOA), how would
you proof that record exist ? or not exist ?

Roy

---

From: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 11:19:38 +0100

>>>>> "roy" == roy  <[email-masked]> writes:

    roy> You can't declare anything 'by zone'. A resolver is
    roy> _completely_clueless_ about zone concept.

We may be talking at cross purposes, but surely DNSSEC declares keys
on a per-zone basis, with DNSKEY records stored at the zone apex?  How
would this be different?

      -roy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 26 May 2004 11:18:15 +0200

Roy,

> well satisfy the concerns of the vast majority of TLD operators, and

Dispatching wildcards from NSEC2 would not be an option.

The DE-zone has entries of the form

*.abc.de   some stuff

Ed's analysis (which I've collated and regard as sound) applies for these 
cases, too. However, the linear growth of server work and answer size in 
hands of the client doesn't seem that dangerous to me.

Regards,
Marcos

---

From: [email-masked]
Date: Wed, 26 May 2004 12:27:26 +0200 (CEST)

> on a per-zone basis, with DNSKEY records stored at the zone apex?  How

I can deploy a test.dnss.ec zone where silly.test.dnss.ec is signed by the
dnss.ec DNSKEY.

Roy

---

From: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 11:48:51 +0100

>>>>> "roy" == roy  <[email-masked]> writes:

    roy> I can deploy a test.dnss.ec zone where silly.test.dnss.ec is
    roy> signed by the dnss.ec DNSKEY.

You can?  

-proto 2.1 requires a delegated secure zone to contain a DNSKEY record
at the apex.  And 2.2 requires RRsets to be signed with at least one
RRSIG where the Signer's Name equals the name of the zone containing
the RRset. -records 3.1.7 requires the Signer's Name in an RRSIG to
match the name of the zone containing the RRset.

      -roy

---

From: [email-masked]
Date: Wed, 26 May 2004 13:35:11 +0200 (CEST)

>     roy> signed by the dnss.ec DNSKEY.

Yes, you can.

> match the name of the zone containing the RRset.

I know, I've heard of those docs. The problem is that a validator has no
way to check that.

Roy

---

From: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 13:00:21 +0100

>>>>> "roy" == roy  <[email-masked]> writes:

    roy> If, big if, anything can be declared by zone (similar like
    roy> SOA), how would you proof that record exist ? or not exist ?

Place a new RR at the zone apex, that specifies the authenticated
denial algorithm(s) used by the zone. You can validate it by its
RRSIG.  Make the RR mandatory for all zones that use something else
instead of (or in addition to) NSEC.  By definition, therefore, the
only secure zones that lack this RR will be able to deny its existence
using NSEC.

Require that any zone that doesn't support NSEC MUST return this new
RR as part of its authenticated denial proof.

   -roy

---

From: [email-masked]
Date: Wed, 26 May 2004 14:02:52 +0200 (CEST)

Lets stop this sillyness, and get back to Authenticated Denial Flags.

The point is, something about authenticated denial mechanism needs to be
signalled. It cannot be done by a record per_zone, since that would
introduce a circular probem. (The NSECINFO in the NSEC2 draft has this
problem).

Another way to go is to subtype this into the NSEC2 record. A version
field. Where and 8 bit version field holds either:

0 ffu
1 clear label (plain old DNSSEC)
2 reserved (later:hashed labels)
3 reserved (later:hashed ownernames)
4 reserved (later:opt-in)

etc.

And we simply document version 0, clear label. With the restriction that
version !1 MUST be discarded as being proof if version is not implemented
(AND signature verifies) and all NSEC records in a zone have the same
version.

Ofcourse future versions are not backwards compatible, so the
need-to-denial-check-aggression-cost of not compatible resolvers is placed
at those who deploy future versions.

How does that sound ?

Roy

---

From: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 14:24:46 +0100

>>>>> "roy" == roy  <[email-masked]> writes:

    roy> Lets stop this sillyness, and get back to Authenticated
    roy> Denial Flags.  The point is, something about authenticated
    roy> denial mechanism needs to be signalled. It cannot be done by
    roy> a record per_zone, since that would introduce a circular
    roy> probem. (The NSECINFO in the NSEC2 draft has this problem).

Hmmm, I think I've just spotted a bigger problem with any
authenticated denial flag.

If a zone (.org.uk, say) decides not to use NSEC, then (obviously) old
resolvers that don't understand the authenticated denial mechanism
chosen by .org.uk won't be able to verify non-existence proofs
presented for .org.uk, and will have to treat them much as NXDOMAIN
responses from insecure zones.  I'd been assuming that this isn't
necessarily a Very Bad Thing.

Unfortunately,  with   DS,  provably  insecure   delegations  rely  on
authenticated denial to prove the non-existence of a DS record.

So in this scenario, assuming that gnomon.org.uk is a secure zone,
someone could spoof data in my zone by spoofing an insecure delegation
from .org.uk and old resolvers would be unaware that anything untoward
had happened.

    -roy

---

From: [email-masked]
Date: Wed, 26 May 2004 21:36:39 +0200 (CEST)

> from .org.uk and old resolvers would be unaware that anything untoward

Yes. So it would fall back to vanilla DNS. That is what org.uk is now.

In fact, there is nothing lost.

Lets say example.com is required to use NSEC2 by their
constituency/lawyer/etc.

2 scenarios:

1) DNSSEC deployment is heldup until NSEC2 is done. "example.com" can
   deploy DNSSEC in 24-36 months. until then, vanilla DNS only for world.

or

2) DNSSEC deployment continues. NSEC2 development continues. "example.com"
   can deploy DNSSEC in 24-36 months, while world can adopt DNSSEC with
   NSEC in (say) 6 months.

My pick would be scenario number 2.

Note: this only works with a version field in NSEC. We simply state V1 is
NSEC as we know it. !V1 must then be interpreted as plain DNS (verify the
NSEC SIG, so the resolver knows the NSEC is legit, treat the delegation or
denial as unsecured).

Roy

---

From: Roy Badami <[email-masked]>
Date: Wed, 26 May 2004 23:30:56 +0100

>>>>> "roy" == roy  <[email-masked]> writes:

    roy> 2) DNSSEC deployment continues. NSEC2 development
    roy> continues. "example.com" can deploy DNSSEC in 24-36 months,
    roy> while world can adopt DNSSEC with NSEC in (say) 6 months.

The problem is that a signed (NSEC2) zone can have a secure delegation
to another zone (NSEC1 or NSEC2).  People will naturally expect that
delegated zone to be safe; they need to be made aware that the subzone
is not secure as far as NSEC1 resolvers go, unless it is configured as
a trust anchor.

Note that this problem is new to DS; in RFC2535 provably insecure
delegations did not depend on authenticated denial.

Maybe this is an acceptable state of affairs, but it makes me nervous.

      -=roy

---

From: Roy Badami <[email-masked]>
Date: Thu, 27 May 2004 01:15:44 +0100

To be more specific, here is what I'm talking about.

Alice is an authoritive nameserver for tld.  She uses NSEC2.

Bob in an authoritive nameserver for sld.tld delegated from tld by
means of a DS record.  (It doesn't matter whether he uses NSEC1 or
NSEC2.)

Charlie is a security-aware resolver.  However, he only understands NSEC1.

Charlie has a secure entry point into tld (either as a trust anchor,
or delegated from a signed root).  He does not have sld.tld configured
as a trust anchor, but uses the DS record as his secure entry point.

Mallory wishes to tamper with the contents of sld.tld, as seen by
Charlie.  He therefore tampers with the DNS response from Alice
refering Charlie to Bob.  In particular, he removes the DS record, and
inserts a randomly chosen NSEC2 record from tld, together with its
RRSIG.

Charlie sees the lack of a DS record as indicating an insecure
delegation.  He can see an NSEC2 record, and he can verify that it is
signed by tld's ZSK, but he can't tell whether it proves the lack of a
DS record.  He simply has to assume that sld.tld is insecure.  At his
point Mallory can tamper with responses from Bob to Charlie with
impunity.

One fix would be to introduce a null DS record, which is semantically
identical to having no DS record, and to require NSEC2 zones to
include null DS recods for all insecure delegations.

An NSEC1 resolver then can always verify a claim of an insecure
delegation: either there will be an NSEC1 record proving the lack of
DS record, or there will be a null DS record.

   -roy

---

From: David Blacka <[email-masked]>
Date: Wed, 26 May 2004 21:00:56 -0400

> Charlie is a security-aware resolver.  However, he only understands 

Then, to Charlie, tld is, for all intents and purposes, not secure.

You can repeat this exercise with algorithms instead of different NSEC 
types: tld is signed by algorithm A, sld.tld is signed with B, Charlie 
only understands B...

Except with NSEC2, it is possible that Charlie will be able to 
establish a chain of trust to sld.tld, if no one tampers with anything.

Versioning DNSSEC, by its very nature, will fragment DNSSEC islands of 
security.

That is not much of an issue if the fragmentation happens towards the 
leaf nodes, but, at the TLD level, it will force all clients to 
understand all of the versions in order to be useful.

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Roy Badami <[email-masked]>
Date: Thu, 27 May 2004 02:19:01 +0100

>>>>> "David" == David Blacka <[email-masked]> writes:

    David> Then, to Charlie, tld is, for all intents and purposes, not
    David> secure.

Not quite.  All records in tld can be verified by Charlie, so tld is
secure for some purposes.  Obviously, authenticated denial is not
available for RRsets in tld.  But less obviously, all delegations from
tld are insecure.  This last point is fixable.

    David> You can repeat this exercise with algorithms instead of
    David> different NSEC types: tld is signed by algorithm A, sld.tld
    David> is signed with B, Charlie only understands B...

    David> Except with NSEC2, it is possible that Charlie will be able
    David> to establish a chain of trust to sld.tld, if no one tampers
    David> with anything.

If the purpose of versioning is to allow later deployment of NSEC2,
then it would be good to consider the implications of such a
deployment strategy, and to consider fixing things that are fixable.

As a domain holder in a ccTLD that will probably choose to deploy
NSEC2 rather than NSEC, I don't much like the prospect that my
delegation will not be secure for the installed base of DNSSEC
resolvers.  If that's the case, the cost of NSEC2 is too high...

    -roy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 May 2004 22:48:10 -0400

When I think on this topic there are a few assumptions I make.

One is that record synthesis (aka wild cards) is an integral part of 
the protocol.  It doesn't matter to me if a proposed solution has a 
problem domain that doesn't use record synthesis, the proposed 
solution must be compatible with the synthesis process.

Two is that the DNS is a very constrained lookup service.  Queries 
consist of three factors and three factors only as far as the data 
space is concerned.  Flags can be used to turn on/request processing 
at the server, but the answers returned with special processing must 
be coherent at any DNS moment.

Three is that the DNS is simple, a non-negotiated protocol.  The 
client can't indicate that it understands certain processing schemes 
and the server can't tailor an answer to the querier's dialect.

Because of these assumptions, when I see proposals that say "well, we 
don't want to use wild cards" I react negatively.  Abstractly, this 
is like defining "A and !B" operations and "!A and B" operations. 
What happens when someone in the future tries to do "A and B" 
operations?  Either we have to apply a lot of epoxy to define what 
happens when the erroneous "A and B" operations occur or we will have 
to be willing to see divergent implementations.  I.e., corner cases 
will ensue.

In the past I have tried to add a security options record to a zone, 
this proposal came out in summer 1999, just before the IETF in Oslo 
(to help fix the era in the memory of folks).  One of the pitfalls of 
this is that the record becomes one more issue for inclusion in the 
non-answer section of a reply.  I am off-line now so I can't find the 
dns-security archives, but I recall a message from John Gilmore 
rejecting the proposal "with prejudice" for another reason.  (I 
recall because I had to ask him what that meant.)

Here's the problem with having multiple approaches to negative 
answers, especially if they are not introduced simultaneously. 
NSEC-era resolvers will panic when seeing NSEC2 records - they will 
have no chance understanding the semantics.  For example, let's say 
"com." uses NSEC2 and not NSEC.  At all delegations to non-secured 
zones, a NSEC2 record will be used to prove the absence of a DS 
record.  The proper response by a NSEC-era verifier to the lack of 
either a DS set or a NSEC demonstrating no DS set is an error, 
resulting in a service failure (SERVFAIL).  It doesn't matter if we 
play a trick with key algorithms.  The older NSEC-era resolvers will 
panic, unless we retool the error handling for that state.

If we were able to include both NSEC and NSEC2 as workable solutions 
in one step, I think that would also be unwise.  DNS isn't about 
choices, it's supposed to be a lightweight system.  (Look at the 
relatively slow adoption of IPsec - too many knobs to turn and align 
right.)  DNS isn't supposed to be a feature-rich service.  (Remember 
the lessons from the A6 deprecation.)  I'd rather see just one 
defined and the other forgotten.

The WG has a technically sound set of documents pending promotion. 
The WG has also heard some concerns about new requirements that the 
current document set does not meet.  The dilemma is that the WG 
represents the collective wisdom of DNS oriented engineers and that 
the new requirements are still seemingly incompletely defined in the 
WG's realm of expertise.  (Meaning that TLD's in different legal 
jurisdictions have different requirement sets.)

A solution to the question "how do we proceed" is for the WG to 
deliver the documents to the IETF and IESG.  The broader community of 
the IETF, with guidance and expertise contacted by the IESG, will 
then have in their hands a sound approach to securing DNS within a 
given set of assumptions and requirements made by the WG.  With a 
broader base of review, the perceived new requirements can be 
evaluated and judged and a determination can then be made the WG's 
documented solution is good enough or that the WG must go back to the 
chalk board and update the design.

---

From: David Blacka <[email-masked]>
Date: Thu, 27 May 2004 01:02:41 -0400

> tld are insecure.  This last point is fixable.

It is possible that you are using a different set of assumptions than I 
am.  I'm assuming that Charlie, when it doesn't understand NSEC2, 
operates under the current DNSSECbis specs.

That assumption sort of rules out null DS records, I think.  I make 
this assumption because if, for instance, Charlie would have to 
understand both NSEC and null DS, then it might as well understand 
NSEC2 as well.

> deployment strategy, and to consider fixing things that are fixable.

I absolutely agree with this.  However, even though we may now think we 
know what NSEC2 looks like, if we pursue this versioning path, we will 
have to assume that we do not actually know what future NSEC-like 
records will look like.  That makes it pretty difficult to figure out 
how to compensate for it, I think.

---

From: Roy Badami <[email-masked]>
Date: Thu, 27 May 2004 10:23:16 +0100

>>>>> "David" == David Blacka <[email-masked]> writes:

    David> It is possible that you are using a different set of
    David> assumptions than I am.  I'm assuming that Charlie, when it
    David> doesn't understand NSEC2, operates under the current
    David> DNSSECbis specs.

Possibly.  I am assuming that DNSSECbis is modified so NSEC RRs
contain a version field, which is set to 1 (say).  I am also assuming
that when a DNSSECbis resolver sees a response in which all the NSEC
RRs have a version greater than 1 (and those RRs are correctly
signed), it treats the response as insecure, rather than bogus.

The question is, would this allow the subsequent introduction of a
version 2 NSEC record in a relatively painless manner?

I assert that the null DS record would make such introduction more
painless.  The main cost (increased zone size) is borne by those who
want to use later versions of NSEC, though it does of course add a
(small) additional complexity to DNSSECbis resolvers.

    David> I absolutely agree with this.  However, even though we may
    David> now think we know what NSEC2 looks like, if we pursue this
    David> versioning path, we will have to assume that we do not
    David> actually know what future NSEC-like records will look like.
    David> That makes it pretty difficult to figure out how to
    David> compensate for it, I think.

That's true.  But null DS records don't rely on having any NSEC-like
records at all.  So it would seem to me that they can complensate for
_any_ change to NSEC.

      -roy