Subject: Remarks on draft-stjohns-dnssec-sigonly

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Dec 2006 16:09:32 -0500

Dear colleagues,

At the meeting in San Diego, the chairs asked that the group review
draft-stjohns-dnssec-sigonly with a view to deciding whether to adopt
it as a workgroup item.  While subsequent discussion (see
e.g. http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01512.html)
makes me suspect that the draft will stick around for a while anyway,
I still think it a good idea for the group to make a statement one way
or the other.

I have read http://tools.ietf.org/html/draft-stjohns-dnssec-sigonly-00
(henceforth referred to as "signonly").  I want to commend the author
on a clear, readable document.

In spite of my general sympathy for the argument in signonly; my
concern, notwithstanding the results of interoperability testing,
that NSEC3 is complicated enough that implementers may get it very
badly wrong; and my desire for something deployable soon I have
reluctantly concluded that the group should not adopt signonly as a
working group document.  This conclusion is based on two premises. 
First, the Chairs in San Diego said that they think the NSEC3
documents are completed, and that they'll proceed soon.  Second, we
have a threat-assessment document that explicitly makes PNE a
requirement for DNSSEC.

Given that the group has, it seems, nearly reached consensus that
NSEC3 is finished, it is easy to make the argument that NSEC3 will be
ready for deployment sooner than the alternatives.  To the extent that
the group is supposed to finish work on a topic and then move on, that
means that a no-zone-walking DNSSEC proposal will be available.  Even
if it is complicated, it satisfies the mandate of the group.
If the group suggests that it is going to investigate another
implementation, it will undoubtedly cause possible implementors
uncertainty.  I am aware that this argument finds little sympathy
among people who observe, quite rightly, "I've heard that before."
One has to declare an end to investigation some time, though, and if
the Chairs really think the NSEC3 work is done, I can think of no
reason to doubt them.

In addition, RFC 3833 is quite clear, in section 2.6, that PNE is
indeed one of the tasks of DNSSEC.  I happen to think that section is
among the weakest of the RFC 3833 (to begin with, every other threat
described is one that is present and apprehended, whereas the
discussion in section 2.6 is of a hypothetical threat that is
presumed bound to emerge in future).  Nevertheless, it is a product
of the working group.  It met the working group's standard for review
and rough consensus, and therefore expresses the views of the group.

I note that both of these reasons are lousy technical reasons for the
decision, but sound political reasons (in the broadest sense of the
word "political").  It bothers me some that I can only think of
political reasons not to adopt the document, but that is sometimes the
cost of working in groups. 

I now offer some comments on the signonly draft itself.

First, I think that signonly is correct in claiming that intermediate
validation may be more troublesome than people seem to think, to the
point of quite possibly being a very bad idea.

I really like the way the proposal allows a very simple upgrade to
DNSSEC-bis from SO.  To me, if there were a reason to adopt this work,
this would be it: start with SO, with -bis optional to implement.
That is also a weakness, of course, because it undoubtedly means even
more drag on the long-term prospects of DNSSEC-bis implementation.

It is probably my own deficiency that I still don't see why some sort
of off-tree mechanism could not be added to DNSSEC-bis.  In addition,
I don't understand why something very similar to draft-laurie-
dnssec-key-distribution-02 won't work well enough.  While it isn't
actually off-tree, it's certainly a way around the apparent
requirement that the whole chain from the root needs to be there for
DNSSEC to be useful.  So while I accept the argument of this draft on
the topic of off-tree signatures, I think that the argument may
proceed from a faulty premise that only a completely off-tree
solution will do.

I also don't buy the following claim, in signonly:

   o  Zones must be signed on an "all or nothing" basis.  It's
      impossible to sign just a portion of the data in the zone.

DNSSEC-bis could have been made to work this way, as the opt-in
proposal (now being advanced as experimental) shows.  Since opt-in is
included in NSEC3, it is certainly possible to sign just a portion of
the data in the zone, at least for some meaning of "sign just a
portion."  Perhaps I have misunderstood the intent or import of this
claim.

Best regards,
A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

--
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: Mike StJohns <[email-masked]>
Date: Wed, 20 Dec 2006 17:01:28 -0500

Hi Andrew -

Thanks for the thoughtful analysis.

With respect to off-tree signatures - a zone admin could add an 
off-tree pointer at any point in a hierarchy and then you could rely 
upon the pointer if the validator actually got it.  The problem is 
that without some external flag (in PNE - that's the set of trust 
anchors) - the resolver doesn't even know the hierarchy should be 
signed; a simple deletion of the off-tree pointer would put the zone 
back into unsecure status.  If you added this, you'd be basically 
creating something about half way between PNE and SO - maybe a 
reasonable idea, but my guess is that it makes the PNE validator even 
more complex.  :-)  It would definitely change the security model at 
least as much as SO does.

With respect to the item below and 
draft-ietf-dnsext-dnssec-opt-in-09.txt:  If I'm reading this document 
correctly, I think my statement still stands (for 4033-4045 for sure 
and for this document maybe).  What the document does is replace a 
chain of NSEC (delegation here, but no DS) records with a single NSEC 
(no DS records in the span).  The entire namespace of the zone does 
continue to be signed, but in a summary way.  (Of course, you can put 
other things in the span besides delegations, but as I read the 
document - that's not the intent. The document is silent on the 
treatment of other records in the "opt in span".  It would be 
interesting to try and figure out what the proper behavior for a 
normal, non-delegation (e.g. not NS, not DS, not glue A) record in 
that space would be - my guess is that anything in the span is 
subject to a deletion attack.

What I meant by partial signing was the ability to sign only one or a 
few RRSets (e.g. the MX records plus the referred to A records plus 
the DNSKEY records)  - the ones I really might want people to care 
about - and still have a validly signed zone.    I *think* if you did 
opt in, and did an opt nsec record "zonename nsec zonename" - you 
*might* get the same behavior?  Again, hard to tell as the document 
really doesn't talk about non-delegation records.

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Dec 2006 17:16:55 -0500

On Wed, Dec 20, 2006 at 05:01:28PM -0500, Mike StJohns wrote:
> signed; 

Right.  I took the Laurie draft, though, to suggest a mechanism for
that distribution, such that the resolver gets the data indirectly. 
It's not perfect, but it's a bootstrap that I _think_ would work.

> continue to be signed, but in a summary way.  (Of course, you can put 

Right, ok, then something else _was_ what you meant.  I think the
practical difference isn't that big, but you're strictly right that
it's still impossible to do partial signing.

A

---

From: Roy Arends <[email-masked]>
Date: Thu, 21 Dec 2006 00:19:42 +0100

MSJ wrote on 12/20/2006 11:01:28 PM:

> document - that's not the intent. 

That's indeed not the intent.

> The document is silent on the treatment of other records in the "opt in 
span". 

From 
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-09.txt

4.1.1.  Delegations Only

   This specification dictates that only insecure delegations may exist
   between the owner and "next" names of an Opt-In tagged NSEC record.
   Signing tools MUST NOT generate signed zones that violate this
   restriction.  Servers MUST refuse to load and/or serve zones that
   violate this restriction.  Servers also MUST reject AXFR or IXFR
   responses that violate this restriction.

Regards,

Roy Arends
Nominet UK

---

From: Mike StJohns <[email-masked]>
Date: Mon, 25 Dec 2006 16:56:03 -0500

Sorry - I missed this section on a quick read-through, but the 
section isn't sufficient.

>    responses that violate this restriction.

There's a number of problems with the way this is stated.  Zones 
aren't actually signed - records are.  Zones aren't necessarily 
loaded monolithically.  For example, as I understand IXFR - you might 
not actually get all the right records during a given interaction to 
ensure this restriction is maintained.  The originating zone may 
maintain this set of restrictions, but the IXFR transaction isn't 
atomic to the zone so the receiving zone might only get part of the 
information (e.g. a new record is added to the gap, but the deletion 
of the optin NSEC isn't included in that specific transaction, or the 
optin NSEC is deleted before the addition of the in-the-gap 
records.)  And finally, people aren't protocol elements and may build 
zones by hand by adding records one at a time rather than loading the 
zone in its entirety.

What you really need to do here is state the behavior of the 
resolver, not of the server.

Consider a zone with opt-in with multiple servers using IXFR.
Consider a range in the zone from "optedout" to "pzone" with an opt-out nsec

Zone owner adds an A record "optedoutnew" to the zone at the master 
and re-writes the NSEC records
(So for some period of time the master and the secondaries are out of sync)

Depending on when a client asks the question, the client can be told 
that the answer doesn't exist (old optin NSEC), that it does exist 
(signed A record), or that it should exist but doesn't (new NSECs but 
no signed data).

It gets worse.  Say the client has the signed optedoutnew in its 
cache.  It now asks for "optedoutagain" and because of the vagaries 
of how DNS works ends up getting the old optin record (from a 
secondary with the original data) which says that "optedout" to 
"pzone" was empty - - but that conflicts with the cached signed optedoutnew.

What does the a caching name server with this data do when asked a 
question in this space?  If there's a covering non-existence NSEC, 
does a caching resolver even attempt to retrieve data in the covered 
non-existence arc?

One possible solution is something like:

a) All data gets cached for its TTL
b) In the conflict between validated existing data and non-existence 
proofs, the existing data is considered valid.
c) Validated existing data without related NSEC records is considered 
valid only for the specific RR type.
d) non-existence is only cached for a specific type and name queried 
and refers back to the NSEC - but the presence of the NSEC is never 
considered as negative caching for any other covered names.  (E.g. if 
you got a covering NSEC for asking about "foo" that also covers 
"bar", you still attempt to query for "bar" - each are negatively 
cached separately).

or something like this.