Subject: DNSSECbis WGLC Conclusion

From: Olaf Kolkman <[email-masked]>
Date: Wed, 2 Jun 2004 13:53:01 +0200

Dear Colleagues,

This message concludes the working group last call on the DNSSEC-bis
document set.

   draft-ietf-dnsext-dnssec-intro-10.txt 
   draft-ietf-dnsext-dnssec-proto-06.txt 
   and
   draft-ietf-dnsext-dnssec-records-08.txt

We have been taking into account the discussion that started with
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00435.html

This note concludes the last call identifies open issues and sets a
way forward. 

Except for the two open issues below we conclude that the WG consents
on the DNSSEC bis documentation being complete and ready to be
forwarded to the IESG for publication as proposed standard.

Issues resolved.

Resolved Issue 1:
(initiated by:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00424.html)

in the security considerations:

   DNSSEC introduces the ability for a hostile party to enumerate all
   the names in a zone by following the NSEC chain. NSEC RRs assert
   which names do not exist in a zone by linking from existing name to
   existing name along a canonical ordering of all the names within a
   zone. Thus, an attacker can query these NSEC RRs in sequence to
   obtain all the names in a zone. While not an attack on the DNS
   itself, this could allow an attacker to map network hosts or other
   resources by enumerating the contents of a zone. There are non-DNS
   protocol means of detecting and limiting this attack beyond the scope
   of this document set.

There is consensus on dropping the last sentence.

Resolved Issue 2:
(Initiated by:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00623.html
)

 In -records section 3 (last para):
 "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset it
 covers."

 And in -proto section 2.2:
 "For each authoritative RRset in a signed zone there MUST be at least one
 RRSIG record that meets all of the following requirements:
 ....
 o The RRSIG RR's TTL is equal to the TTL of the RRset"

The proposed "MUST" language did not counter with objections and
forces RR-sets and their signatures to expire from caches at the same
time.

Open Issue 1:
See
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00785.html

This issue was posted June 1 and needs a little time to be
resolved. Please spend cycles on this issue over the next week.

Open Issue 2: NSEC2/NO++.

The working group consents on not including NSEC2 in DNSECbis.

The working group considers to take up "prevention of zone
enumeration" as a work item. (this may result in a solution other than
NSEC2, we'll refer to this work as NSEC2/NO++).

There is a proposal to use a type code roll with EDNS0 based signaling
to introduce NSEC2/NO++. There may be other, more gentle, mechanisms
to allow for co-existence with DNSSEC-bis. We allow the working group
a little over a week (up to June 12) to come to consensus on a
possible modification to the document to enable gentle rollover. If
that consensus cannot be reached the document will go out as-is and
type-code roll will probably be the only way forward.

To ease the process of getting consensus we would like to ask for a
few (3 or so) volunteers to make a summary of the proposed solutions
and analyze the pros and cons during the weekend. If you want to
volunteer please reply to both of us within 24 hours after posting of
this mail so we can appoint the volunteers by Thursday and have results
on Monday.

We realize we are going fast but want to have DNSSEC-bis at the IESG
before July 1.

If you are reading the documents and find editorial nits or
inconsistencies you should still bring them up. Either to
[email-masked] or to this list.

Olaf & Olafur
DNSEXT co-chairs.

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