Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms

From: Sam Weiler <[email-masked]>
Date: Mon, 10 Jul 2006 19:58:38 -0400 (EDT)

At first glance (having looked at the diff to -03 but not fully reread 
the document), the comments I made in November 2005 have not been 
fully reflected in the document, despite, IIRC, some agreement from 
the editors that they were a good idea. 
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01704.html

In addition to the comments I sent to namedroppers, there are some 
editorial rough spots that I'd like to see addressed before the 
document is advanced.  I've reminded the editors of those.

Accordingly, I continue to believe that the document is not ready for 
WGLC.

-- Sam

--
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: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 18 Jul 2006 08:57:53 -0400

Reminder,

So far no one has commented or posted a review of this document.
Please help your chairs by reviewing this document.

         thank you
         Olafur

At 09:30 07/07/2006, Ólafur Guðmundsson /DNSEXT wrote:

>Dear colleagues,
>
>This message starts at 3 week last call for this document ending
>on midnight July 30'th 2006 (Reykjavik time).
>The URL for the document is:
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.txt
>
>The document is a collection of different approaches to flag
>extensions/changes in DNSSEC.
>The document is a cumulative list of pros and cons as well
>as impact and issues for each possible mechanism.
>This document is to be published as Informational to capture the
>current knowledge of the state of art of signalling changes in
>the DNSSEC protocol.
>
>The document process rules in this group, require that at least
>5 members of the working to state that they have read the document
>and support it being published.
>
>         Olafur & Olaf
>
>
>
>--

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 18 Jul 2006 14:09:09 -0400

I noticed Sam commented on it, but I went through the archive and re-read
it.  I'm not sure if it is a valid issue to worry about or not.

I do think it is odd that the document suggests on-demand synthesis of NSEC
RRs while acknowledging it is not a path to versioning.  It seems like a
quick fix for the zone enumeration problem, but has a really big flaw in
that it is a DoS attack vector, especially true for smaller enterprises.
Maybe it should be mentioned again in the Security Considerations section.

Other than that (since it is purely informational) I don't have any
objection to this draft.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ólafur Guðmundsson
> Sent: Tuesday, July 18, 2006 8:58 AM
> To: [email-masked]
> Subject: Re: DNSEXT WGLC: Evaluating DNSSEC Transition Mechanisms
>
>
> Reminder,
>

---

From: "Stuart E. Schechter" <[email-masked]>
Date: Thu, 20 Jul 2006 13:25:31 -0400

> From: Ólafur Gu›mundsson <[email-masked]>

>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.txt

2.1.1.4. Cons [of Dynamic NSEC Synthesis]

   The need to keep a signing key on the server is mentioned in 2.1.1.1, but
should probably be explicitly mentioned in this Cons section.

2.1.2.1.
   "Since the Since the versioning is done inside the NSEC RR, different
versions may coexist."
   I'd add the words "within a zone" before the end of that sentence.
   
   I'd also wonder if this could lead to ambiguities and different
interpretations.

   "to be defined" -> "to-be-defined"

2.1.2.2.
   "a single RR type authenticated denial" ->
   "a single RR type for authenticated denial"
   
   "as opposed to e.g.  NSEC-alt,"
     When you expand out "e.g." to "example given" this doesn't parse.  Some
folks are OK with this.

2.1.2.3
   "while specifying behavior in case of" =>
   "while specifying the recommended client behavior when presented with"

2.1.2.4.
   I'm not sure what "clean and clear" imply.  Straightforward?  "clear and
clean" (the two words reverse) are used in 2.1.2.5.

   "without versioning DNSSEC"
      You are versioning a component of DNSSEC, which could be argued is
versioning DNSSEC.  Perhaps something along the following lines would be
more accurate: "without introducing versioning into other components of
DNSSEC"

2.1.3.1.
  "NXT, NSEC, RRSIG or other outdated RR types"
     RRSIG is outdated?

2.1.6.*
   This mechanism is described as equivalent to that of 2.1.5 (see
2.1.6.5.).  
   However, In 2.1.6.1. you say that "NSEC is simply turned off."  In
contrast, 2.1.5 allows NSECs to exist for denial of existence for records
(but not domains). 

2.1.6.2.
   "A next to"
      "A next step"?

2.1.6.5. "Official version of the 'trick' presented in Section 2.1.5."
   I think you mean to say that it is an formal and explicit indication
mechanism that obtains the same ends as the informal mechanism (hack)
described in 2.1.5.

2.1.7.1.4.
   Isn't one of the Cons the performance of online signing each denial of
existence record?  Potential denial of service attack?

   Cheers

   Stuart

---

From: "dr. W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 26 Jul 2006 10:53:31 +0200

>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.txt

Hi,

I've read the draft. I think it is technically sound. As such I have no
objections to it.

1. Introduction
I do object to the reference to the 2004 discussion. I think that the
document should stand on its own, and instead in the introduction have
the paragraph under 'This summary includes:'. So, remove the references
to the process of last-call in 2004, and state the need for transition
mechanisms.

Delete paragraphs 'This is an edited excerpt..', 'To ease'. Replace with
a rewrite of the 'this summary includes:' paragraph, i.e. this document
provides a list of pros and cons for mechanisms to transition to future
work on authenticated denial of existence. The authors aim to provide a
mechanism that is least disruptive to the DNSSEC-bis specifications as
they stand and keep an open path to other methods for authenticated
denial of existence.

With regard to the last paragraph in the introduction:
@  The descriptions of the proposals in this document are coarse and do
@  not cover every detail necessary for implementation.  In any case,
@  documentation and further study is needed before implementaion and/or
@  deployment, including those which seem to be solely operational in
@  nature.

The coarseness is a bit of a cop out, the document considers the
alternatives and compares them. It does not list every detail necessary
for implementation of the alternatives.

'implementaion' is a typo.

The 'solely operational in nature' is confusing. What is solely
operational in nature? Seems like a grammar/editing artifact to me. And
why do they only seem to be operational in nature? Are you trying to
say: 'Transition has operational consequences and further study on these
operational consequences is needed once an alternative is selected' ?

3. Recommendation
I agree with Scott, the recommendation for online signing could benefit
from some limitation, i.e. This recommendation is temporary until a
denial solution becomes available that does not suffer from such strong
security problems such as online key maintenance and denial of service
to servers that online signing suffers from.

Best regards,
   Wouter

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Jul 2006 16:15:56 -0400

Dear colleagues,

I have read that document.  I have no technical objection, and can
support the document going forward.  I do have some comments,
however.

Like another reader, I would like to suggest that the Introduction be
altered to remove the references to discussion in 2004, previous last
calls, &c.  It would be enough to note that there were some issues
identified in RFCs 4033, 4034, and 4035; that the issues have to do
with "zone walking"; and that the document intends to be a (not
exhaustive) survey of the proposals to address the problem.  I won't
withdraw my support if this isn't done, but it would make the
document a little more convincing, I think.  Here is proposed text:

   The DNSSEC specification in [[RFC4033], [RFC4034], and [RFC4035]
   (hereafter referred to as DNSSEC-bis) entails that it is possible to
   enumerate the contents of a DNSSEC-bis signed zone.  This is
   sometimes called the "zone walking problem".  Several mechanisms have
   been proposed to address this problem.  This memo provides a summary
   of the various mechanisms, and an outline of the advantages and
   disadvantages of each.  This memo is not an exhaustive survey; it is
   merely an attempt to outline the possibilities for future work, in
   an effort to provide a guide for what approaches are likely to be
   fruitful if pursued.

If the document is to be edited anyway, I think it could use a good
going-over for usage and style.  At the moment, it sort of reads like
the distillation of an email thread, with some poorly-constructed
sentences (two at random: the last sentence in section 2.1.3
[simpliciter], where the reference of "it" is not totally plain; "Keys
have to be held and processed online with all security implications"
in section 2.1.7.4).

Nit: s/role/roll second sentence in 2.2.2.4

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