Subject: Alea iacta est

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 5 Apr 2005 10:55:23 +0200

Dear colleagues,

RFC 4033, 4034 and 4035, specifying the DNSSEC bis protocol have been
published and announced. The publication of these RFCs have been a
major milestone for this group and we are happy to see that we have
been able to produce a high quality document set.

DNSSEC remains a work item for this group. But it has a very solid,
and deployable, foundation. That it took 10 years to develop is
regrettable but we feel that the dnssec-bis editors team have given a
good example on how editors can determine the pace of the work in a
working group.  In addition to the work by the editors it was the
constructive and consensus seeking approach of the working group
members, seen over the last years, that helped us produce a high
quality document.

Thanks for your efforts; We are proud to be a part of this development.

Olaf and Olafur.
DNSEXT 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/>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 05 Apr 2005 16:27:28 +0000

> been able to produce a high quality document set.

me too.  and i want to thank the dnssec-editors group, with special
attention to rob austein, for their efforts toward this milestone.

however, i have some disagreements as to how history should be written:

> and deployable, foundation.

i don't think that's true.  a number of TLDs have said that without
opt-in and/or without protection against zonewalking, dnssec-bis is
undeployable; these are "foundational" issues and the fixes for them
could mean it'll take dnssec-ter (and another flag day) before this
functionality will be globally deployed.

> That it took 10 years to develop is regrettable

it would be, even if it were only 10 years.  but 11 years ago on this
date, jim galvin (then WG chair of the dns-security working group)
published meeting minutes from the seattle ietf meeting in march 1994.
(see attached; it's fascinating reading for protocol history buffs.)

> but we feel that the dnssec-bis editors team have given a good example
> on how editors can determine the pace of the work in a working group.

if by that damningly faint praise you mean that setting up an editors
subgroup to try to make more rapid and focused progress didn't work out
like randy and olafur hoped, and that individual authors and design teams
have not been discredited as the right/best way to make stuff like this
happen, and that the need for DNS-MODA is more urgent now than ever, i
agree.  if you mean pretty much anything else, then i don't understand.

> In addition to the work by the editors it was the constructive and
> consensus seeking approach of the working group members, seen over the
> last years, that helped us produce a high quality document.

given that we would have had opt-in, and therefore a high likelihood of
a known deployment horizon in certain huge TLD's, if not for the
destructive and unilateral actions and words of a few working group
members, we're really hanging on the "last years" qualifier here, right?

> Thanks for your efforts; We are proud to be a part of this development.

me too, in spite of everything.  but i'm reminded of a well known quote:

"Laws are like sausages. It's better not to see them being made."
      Otto Von Bismarck 1815 - 1898.

oh and here's the 11-year-old WG summary i promised:

Subject: DRAFT Minutes of DNS Security March 1994 (Seattle) Meeting
From: James M Galvin <[email-masked]>
To: [email-masked]
Date: Tue, 05 Apr 1994 13:40:10 -0400

Enclosed below is my record of the meeting held during the last IETF
meeting.  Corrections from those who attended the meeting are hereby
solicited.  In particular, there is one issue that I had regarded on the
slides for which I can not remember either the context or the
resolution.  I'd appreciate if someone could remind me.

I will submit the revised minutes for the record on Monday, April 11 (or
these if I get no comments).

Thanks,

Jim

		    DNS Security WG Meeting Minutes
			   March 1994 Seattle

Recorded by Jim Galvin, Chair

The DNS Security Working Group met on Tuesday morning for a 2.5 hour
meeting.  Charlie Kaufman and Donald Eastlake had previously submitted a
proposal (as an internet draft) for enhancing the DNS to support a
digital signature security service.  This meeting was dedicated to a
review of that proposal.

The meeting began with a review of the desired requirements identified
at the BOF meeting held at the November 1993 Houston meeting.  Charlie
and Donald then led a presentation and discussion of their proposal.
The following issues were discussed and resolved as indicated.

o choice of algorithm

  The proposal currently specifies the SHA and RSA algorithms.  It was
  agreed to replace SHA with MD5, the current Internet preference.

o revisit DNS architecture

  The addition of SIG RRs increases the probability that the maximum UDP
  payload per packet may be exceeded.  The requirement that we remain
  backward compatible with the existing installed base and the lack of
  empirical data to support the premise caused us to agree to leave the
  DNS architecture alone.

o where do SIG RRs go in the reply

  A question was raised as to whether which section of the reply the SIG
  RRs should be placed.  This is an issue because it was noted that, if
  necessary, implementations may ignore (and truncate) the additional
  records portion of a reply.

  It was agreed to query Paul Mockapetris in particular and to followup
  on the mailing list.

o key per zone or key per server

  The proposal currently specifies that a public/private key pair is
  assigned to a zone, which is responsible for signing its data.  In
  this way the data may be distributed by any server and, in fact, the
  actual signing of the data may (and should) occur as an off-line
  function.  In addition, a specification is included for servers to
  optionally sign responses to queries.

  At this time it was agreed to leave the optional alternative in the
  document.  We will revisit this issue after we have some
  implementation experience.

o split the document

  It was suggested that the document may be better organized as several
  related documents.  It was agreed Donald and/or Charlie would initiate
  a discussion of this issue on the mailing list.

o use of the NTP time service

  The proposal currently emphasizes (if not requires) the use of a
  reliable time service, in particular NTP.  It was agreed that DNS
  should not depend on synchronized clocks.  The authors agreed to
  rework this aspect of the proposal to not depend on synchronized
  clocks.

o partial and/or hash records

  (** HELP HERE **)

  I have this item recorded on the slides but I don't recall the issue
  or the resolution.  Can someone provide some context, please?

o key management

  It was observed that an integral part of the proposal is the
  specification of a key management protocol.  As the new security area
  director was present at the meeting he was asked if the security area
  believed it was appropriate to specify another key management
  protocol, observing that both PEM and SNMP Security have also
  specified key management protocols.  The response was that this key
  management protocol was sufficiently different from the other two that
  it was valuable in its own right and should remain part of the
  proposal.

The meeting concluded with Jim Galvin noting that TIS would be
implementing the proposal using the bind implementation of the DNS as a
baseline.  This software would be openly available to the Internet
community.

This group expects to meet in Toronto.

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 7 Apr 2005 11:14:05 -0400 (EDT)

> functionality will be globally deployed.

The argument that "fixing" zone walking could require a flag day is at
odds with this WG's informed decsion last summer that gentle
transition mechanisms are likely to work.  If you would like to
suggest that the WG reconsider that decision, a deeper technical
analysis would be helpful.

http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01231.html

On the other hand, I suppose you could have been using "globablly
deployed" to mean "every DNS-capable device groks DNSSEC", in which
case I agree that a flag day will be needed.  That said, I don't think
this WG has ever dreamed that DNSSEC (-bis, -ter, or otherwise) will
be "globally deployed", in part because we've felt that having a flag
day is unrealistic.  DNSSECbis doesn't need one.  The type code roll
(RFC3755) helped sidestep any need for a flag day -- it just left
2535-aware code behind.

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Apr 2005 15:32:04 +0000

> > ... could mean it'll take dnssec-ter (and another flag day) before ...
> 

i think the operative word in my text that you quoted is: "could".

> http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01231.html

i don't see any larch proofs in either of those messages.  if you have any
kind of rigorous proof that a zonewalking fix exists and is implementable
and will not have a flag day, you should share that, it'll save time.

all we know at the moment is that informed objective experts in the subject
matter agree that such a solution can be found.  but since we're the same
people who passed RFC 2065 and RFC 2535 up to the IESG, i don't trust us,
and so, my choice of words, very careful in this case, was the word: "could."

> (RFC3755) helped sidestep any need for a flag day -- it just left

let me be clearer, then.  dnssec-ter might not be backward compatible with
dnssec-bis, thus invalidating all dnssec-bis deployment up to that date,
which is not precisely a "flag day" since the dnssec-bis empire will not
end on that day.  but dnssec-ter may end up having to be a parallel
infrastructure.  note the operative word "might" which is equivilent in
this case to my earlier use of the word "could".

that having been said, my own course (and isc's course) will be as follows:

     1. push bind9's dnssec-bis implementation toward completeness and
        usability and deployment.  this includes making DLV happen, sadly.

     2. work with anyone interested in resolving the zone walking problem,
        with as little insertion force as possible, preserving as much of
	the dnssec-bis code and protocol and installed base as possible.