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

Best regards,

Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
M2P 2A8
jabber: +1 416 646 3304 x4110

to unsubscribe send a message to with
the word 'unsubscribe' in a single line as the message text body.