Subject: Re: Reminder WGLC DNSSECvbis and NSEC++

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 5 Jan 2004 15:50:26 +0100

I wrote:
> Please scheadule some time to read and comment on the drafts.

For completeness; the deadline on these WGLCs is January 15, 2004.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

--
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: "Scott Rose" <[email-masked]>
Date: Mon, 5 Jan 2004 11:20:46 -0500

One thing I noticed.  The text in the DNSSECbis -records draft discusses
what to do with compressed names in the "next domain name" field.  It is
dropped in the NSEC++ draft.  It is not important there, since I assume the
specs on compressed names were already agreed upon on -records, that text
would remain.

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 05 Jan 2004 16:49:09 +0100

[ Moderators note: Post by non-subscriber.  With the massive amount of
  spam, it is easy to miss and therefore delete relevant posts 
  by non-subsrcibers. Please fix your subscription addresses. ]

4. Security Considerations

   The change introducted here does not affect security, since it only
   updates the RDATA format and encoding.

I feel this is insufficient.  I believe the document should discuss
all security considerations related to the NSEC RR.  Here is suggested
text for one item that I believe should be included:

  The NSEC RR make it possible to enumerate all existing names and
  types within a zone, so called "chaining".  DNS administrators that
  for some reason restrict access to their entire DNS zone file (by,
  e.g., disabling DNS zone transfer) may want to consider the effects
  of adding NSEC records in their zone, as supporting them may lead to
  a similar information leakage as DNS zone transfer does.

Also, some nits: the abstract does not parse as English to me
(defines/updates?).  The document does not mention "NXT" at all, which
seems like a useful thing to do.  The document says RFC 2535 define
the NSEC RDATA, and it reference RFC 2535 for the semantics of NSEC,
none of which 2535 cover.

Thanks,
Simon

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 5 Jan 2004 11:43:39 -0500

The "zone walking" security risk is listed in the Security Considerations of
the DNSSECbis docs.  Maybe a reference to those would suffice?  Or cut and
paste.

Scott

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 12 Jan 2004 04:08:03 -0500 (EST)

abstract:
	Strike "defines"

	"cover" is vague unless someone already knows what you're
	talking about. How about: "allow signing of records with any
	typecode" or "remove the limitation ..." ot somesuch

intro, paragraph 2:
       "once the first 127 type codes are allocated," isn't quite
       right, since 2929 specifies a private range that's available
       for use now, independent of IANA assignment.  I think the
       bigger problem is that the current behavior in the pressence of
       big types is unspecified -- we don't know how to handle them
       (as an authoritative server or as a resolver).

intro, paragraph 3:
       s/ This document introduces a new format for the type bit map/
       ...type list/  (since it's no longer a bit map, exactly)

       s/all possible type/all possible types/

       replace semi-colons with commas, and add an "and"

section 2:
	Should "authoritative" be used here?  Even non-authoritative
	RRsets are in the NSEC chain (delegations w/o DS records).
	Yes, the parent is authoritative for their existance, but
	that's a subtlety that may be lost on some readers.

	Also, "the owner name of the next authoritative RRset" sounds
	wrong.  It's the next name -- there can be multiple RRsets at
	a name.

section 2.1.2
      The term "window blocks" doesn't sound right to me.  Can we
      think of something better?

      "ignored upon reading" puzzles me.  Can that be better
specified?

section 2.2
	raw numbers not allowed?  want to impose any ordering
	constraints here?

And I concur with Simon's suggest to mention NXT, especially when
citing 2535.  The chain of changes just gets too long.

I don't see a need to change the security considerations section.

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 14 Jan 2004 20:19:43 -0500

Olaf Kolkman wrote:

> References:
> draft-ietf-dnsext-nsec-rdata-03.txt

I support moving draft-ietf-dnsext-nsec-rdata-03 forward (as
appropriate, or killing it because dnssec-records-06 fully incorporates
it). I do request consideration of the following 2 minor editorial nits:

  - Sec. 1: The first paragraph indicates that NSEC RR was descibed in
RFC2535.  It is actually NXT that is defined there.
  - Sec. 2.3: In the second paragraph is says, "The A, MX, RRSIG and
NSEC mnemonics indicate there are A, MX, RRSIG, NSEC and TYPE1234
RRsets...".  This probably should begin "The A, MX, RRSIG, NSEC and
TYPE1234 mnemonics..."

> draft-ietf-dnsext-dnssec-intro-08
> draft-ietf-dnsext-dnssec-protocol-04

I support moving draft-ietf-dnsext-dnssec-intro-08 and
draft-ietf-dnsext-dnssec-protocol-04 forward as written.

> draft-ietf-dnsext-dnssec-records-06

I support moving draft-ietf-dnssext-records-06 forward, with the minor
comment above for nsec-rdata-03, sec. 2.3 applied to sec. 4.3

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: same               Boxborough, MA  01719-2205

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 14 Jan 2004 20:36:55 -0500 (EST)

This document has nits that need to be fixed before it is progressed
(see my earlier message), but it is technically complete.  I support
its publication, contingent on another editting cycle.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 14 Jan 2004 21:49:23 -0500 (EST)

intro-08 is a beautiful and very complete document.  The editors have
done a marvelous job, and they've been very responsive to previous
suggested changes.  I applaud them.

In addition to the usual minor nits, I see some things that I expect
to cause IESG delays, and I do not support the advancement of this
document until they are addressed.  To be clear, I will support the
document during IETF last call (the document is technically sound).  I
just think it would be prudent for DNSEXT to fix these things before
advancing the doc.

First, there's an inconsistency in this document re: which direction
the authentication happens in (FROM a preconfigured key, as in section
5, or TO a preconfigured key as in section 3.1).  It doesn't really
matter, but the inconsistency does show up and may confuse people,
including the IESG.

Section 2, definitions

   The distinction between "authenticated" and "validated" is
   subtle and may be inconsistent, which makes these definitions
   look cavalier.  If we can't clean this up, perhaps we need to
   add a disclaimer about these being "rough" definitions, lest
   the IESG throw this back.

   In the zone signing key definition, please repeat the warning
   re: the ZSK/KSK distinction not mattering for validation.  The
   second paragraph of 3.1 also confuses this a little (more
   detail sent to editors).

Section 3.1 third paragraph

   The attempt at DS->DNSKEY chaining formalism misses the
   optional DNSKEY->DNSKEY indirection inside the zone.

11.  Security considerations

   More should be said about DNSSEC's potential for making zones
   less reachable and for otherwise causing DNS to appear to
   break.  And it should be stressed that DNSSEC does not
   necessarily help a resolver to find good data (it may, but we
   haven't developed those technologies yet).

   In the second paragraph, is "intermediate" really defined
   elsewhere?  It looks to me like it's both undefined and
   overloaded.

Local policy is discussed several times in this document, but with
limited examples.  I'd like to see more examples (ie. disabling an
algorithm and the impacts thereof).

Many minor nits have been sent privately to the editors.

-- Sam

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 15 Jan 2004 11:00:06 -0500

----- Original Message ----- 
From: "Samuel Weiler" <[email-masked]>

>    second paragraph of 3.1 also confuses this a little (more

Probably will need some wording changes.  All of us know the material
already, so we know what it's saying, even though it is written differently.

> algorithm and the impacts thereof).

We might wander dangerously close to specificiations (which was to be
avoided in this doc).  I think local policy, resolver actions, etc. might
lead to a deep rathole.   Maybe even a seperate doc on how a resolver might
intereact with a secure name system.

Scott

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 15 Jan 2004 13:58:13 -0500 (EST)

>From records-06, section 3.1.5, first paragraph:

   The Signature Expiration and Inception fields specify a validity
   period for the signature.  The RRSIG record MUST NOT be used for
   authentication prior to the inception date and MUST NOT be used for
   authentication after the expiration date.

To accomodate local policy, I think these should be SHOULD NOTs.

I can imagine some resolvers wanting to knowingly use expired RRSIGs.
Perhaps the error when a RRSIG has expired but otherwise validates
will be more gentle (or more user overridable) than an error when the
RRSIG is missing or doesn't validate at all.  Perhaps a given zone
will be known to have bad RRSIGs, and that could be configured on a
per-zone basis.  Perhaps the resolver lacks any sense of the current
time, and doesn't want to check times at all.  Perhaps the resolver
knows that its clock is wildly inaccurate and wants to globablly allow
for five hours of slop in either direction.  Perhaps there will be a
default local policy that states: for a given zone, unless you've seen
more recent RRSIGs, keep accepting the old ones -- once any newer
RRSIG appears, reject the old ones.

These are all local policies, the merits of which can be debated (we
probably shouldn't do that here and now), but I see no need to
prohibit them wholesale.

-- Sam

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 16 Jan 2004 08:53:18 -0500

----- Original Message ----- 
From: "Samuel Weiler" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 15, 2004 1:58 PM
Subject: prohibiting use of expired RRSIGs

> probably shouldn't do that here and now), but I see no need to

I think there is a danger if the specifications say it is ok to go "off the
reservation" and accept certain errors.  Unless an application and user is
willing to accept risky responses (example:  RRSIG verified, but time was
off, or RRSIG in an algorithm the resolver cannot understand), it can
request that, but it should be able to rely on a some base security checks.

Since we are talking resolver local policy, there really is nothing stopping
a resolver implementation from offering that service as an option, but not
as default, where it takes liberty with application requests, and hands back
responses that were "close enough", but maybe not to the application's
wishes.

I would rather see a base "MUST NOT accept expired SIG" as the default
operation, and anything beyond that as an option an app can specify, rather
than "SHOULD NOT" and have an application not be sure what the resolver is
doing.

Scott

---

From: Mike StJohns <[email-masked]>
Date: Fri, 16 Jan 2004 12:31:37 -0500

MUST be configurable as to whether to accept expired records,  SHOULD be 
configurable to as to the maximum out of date expired records can be to be 
acceptable.  MUST default to not accepting expired records.

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 16 Jan 2004 14:17:09 -0500 (EST)

Going back to 2119:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

> acceptable.  MUST default to not accepting expired records.

Configurability is not a MUST.  At most it's a SHOULD, and probably a
MAY.  I'm not even sure about the default...

I'm happy with taking the original text, replacing MUST with SHOULD,
and moving on.

-- Sam

---

From: Mike StJohns <[email-masked]>
Date: Fri, 16 Jan 2004 14:47:31 -0500

How about

MAY be configurable as to whether to accept expired records.  If 
configurable,  SHOULD be
configurable to as to the maximum out of date expired records can be to be
acceptable.  And if configurable, MUST default to not accepting expired 
records.

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 23 Jan 2004 14:06:48 +0100 (CET)

> acceptable.  And if configurable, MUST default to not accepting expired

Much better, but this loses the main sentiment of the original,
namely that one MUST NOT or SHOULD NOT use out-of-date (expired or
not yet active) RRSIGs.  The text above would allow a non-configurable
resolver to accept out-of-date records.

I have a broader proposal, which I'm about to post.

-- Sam

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 26 Jan 2004 10:50:07 +0900

Samuel Weiler;

> resolver to accept out-of-date records.

Allowing an insecure option is not appropriate.

If a protocol is allowed to be operated with less security, most
people will do so and still believes they have advertised (full)
security.

It seems to me that the problem is that people recognizes it
essentially impossible to deploy DNSSEC.

As a result, requirements in protocol specification is reduced
to make DNSSEC not really secure. But, it does not really address
the problem and only to make the result useless.

						Masataka Ohta