Subject: Re: [dnsext] Draft DNSEXT charter

From: Paul Vixie <[email-masked]>
Date: Sat, 30 May 2009 21:24:57 +0000

> Date: Fri, 29 May 2009 11:56:59 -0400
> From: Ólafur Guðmundsson /DNSEXT 
>  chair <[email-masked]>
> 
> Milestones are preliminary and will be updated based on WG discussion.
> 
> Comments please,
> ...
> Milestones:
> Jun  2009  TSIG/MD5 Obsoleting to IESG.
> Jul  2009  AXFR Clarify to IESG
> Sep  2009  EDNS0 Ping Option advanced to IESG
> Oct  2009  Resolver side Forgery Resilience advanced to IESG
> Oct  2009  DNSSEC Errata document to IESG
> Nov  2009  GOST DNSKEY and DS support advanced to IESG
> Dec  2009  ENDS0-bis update advanced to IESG

IMHO, EDNS0 Ping would not add any actual security.  can this be changed to
say something like "Sep 2009 - forgery resilience protocol advanced to IESG"
so that we're open to defining an SCTP transport profile, and we're open to
defining an TKEY-DH + TSIG use profile, and still hit the objective?

btw, i'm looking for co-authors for an DNS over SCTP transport profile doc,
and a TKEY-DH + TSIG use profile doc.  i'll want to get both done in the
first three weeks of july (before blackhat/defcon).  help?

--
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: Olafur Gudmundsson <[email-masked]>
Date: Mon, 01 Jun 2009 10:22:54 -0400

>defining an TKEY-DH + TSIG use profile, and still hit the objective?

This is a good suggestion, but if we open up the space to new transports
I will move this milestone a little back how about:

Dec 2009 Hardening against on-the-wire Forgery advanced to IESG

         Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 1 Jun 2009 10:51:12 -0400

On Sat, May 30, 2009 at 04:28:31PM +0000, [email-masked] wrote:

> > >On Fri, May 29, 2009 at 09:22:58PM -0400, Andrew Sullivan wrote:

> > > > Is there something about the correctness of implementation that is
> > >> different from "clarifications" to the protocol? 
 
> 	thats updating a spec, not doing implementation conformance.

So you seem to be sort of answering the question I asked by saying
that any time one checks implementations, finds that they are all
conforming and yet different in behaviour, and issues a clarification
to pick one behaviour, one changes the specification.  You seem to
think this is ok, and that it is within the purview of the WG.
Correct?

> 	two different implementations of RFC 1034 can follow that spec
> 	correctly and yet not be interoperable.

Do you think that such a case is something we want to fix -- to
disambiguate, thereby decreeing which interpretation of the
apparently-ambiguous RFC is to be the one to use?  If so, do you think
it is work this WG should have under its chartered responsibilities,
or do you think that work should go elsewhere?

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 08 Jun 2009 13:57:54 -0400

At 14:13 29/05/2009, [email-masked] wrote:
> > Attached is our first draft of an updated charter that allows us
> > to add the items pending adoption. (GOST DNSSEC algorithms, Forgery
> > Resilience)
> >
> > Instead of having to re charter every time a new draft is deemed worthy
>of
> > the working groups effort we have created narrow categories
> > that allow us to perform "protocol maintenance" as needed.
> >
>I would like to see the charter allow for work items that advise on
>correct _implementation_ (as opposed to _operation_) of the DNS protocols,
>such as my DNS Proxy BCP draft.
>
>I'm unable to find a suitable place to drop this into the current text,
>though.
>
>Ray

Next version will contain in list of topics new documents can have:
         Hardening DNS protocol and providing guidance to implementors

         Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 08 Jun 2009 14:15:30 -0400

>first three weeks of july (before blackhat/defcon).  help?

First on the EDNS0 Ping option: we have enough 
people supporting that undertaking
to adopt the document, at the same time number of people arguing strongly
against the document. The chairs feeling is we 
should have a round of discussion
once the document is updated to reflect comments received, then dispose of it.

On Transport issues: last week the dns-proxy 
document was discussed by the IESG,
one of the main issues raised was on various transport related wording in the
document. There seems to be a need to specify how DNS implementations use the
two transports available to them.
In addition there seems to be interest in examining and specifying how to use
an additional transport protocol.
The next version of the charter will contain these work items and milestones
for two documents. The chairs are looking for 
editors for "DNS transport clarify"
document.

Uses of TKEY/TSIG can to prevent spoofing can fall under "hardening DNS" clause
in our charter.

         Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 08 Jun 2009 14:28:30 -0400

At 13:03 29/05/2009, Ólafur Guðmundsson /DNSEXT wrote:

>Dear colleagues,

Here is an updated version based on feedback from the working group.
Diffs from prior version below.

         Olafur and Andrew

<version 20090608>

The DNS has a large installed base and repertoire of protocol
specifications. The DNSEXT WG group will actively advance DNS
protocol-related RFCs on the standards track while thoroughly
reviewing further proposed extensions. The scope of the DNSEXT WG is
confined to the DNS protocol, particularly changes that affect DNS
protocols "on the wire" or the internal processing of DNS data. DNS
operations are out of scope for the WG.

The WG will limit itself to review of proposals for new extensions
and clarification to the DNS protocol, including DNSSEC. Adoption of
new work targeted for standards track will require changes to this
charter.

The working group can nevertheless undertake work in following
subjects without a charter change:
         DNSSEC and TSIG/TKEY algorithm maintenance
         Hardening DNS protocol and providing guidance to implementors
         Examining transport protocols possibly adding new ones.
         Advancing existing Proposed Standard RFCs to Draft/Full Standard
         Obsoleting RFCs.

Before formal adoption of any such items at least 5 working group
participants must publicly state that the item is within charter and is
worthwhile item for further study.

The DNSEXT WG will conduct the specified RFC5395 review of RR
templates as they are posted, and EDNS0 Option templates if EDNS0-bis
updates registration requirements.

The WG does not intend to hold face to face meetings, though
may do so if deemed necessary for resolution of a specific issue at
hand.

Milestones:
Jun  2009  TSIG/MD5 Obsoleting to IESG.
Jul  2009  RSA/SHA256 to IESG.
Jul  2009  AXFR Clarify  to IESG.
Sep  2009  EDNS0 Ping Option advanced to IESG
Oct  2009  Resolver side Forgery Resilience advanced to IESG
Oct  2009  DNSSEC Errata document to IESG
Nov  2009  GOST DNSKEY and DS support advanced to IESG
Dec  2009  EDNS0-bis update advanced to IESG
Feb  2010  DNS existing transport protocol 
recommendations/clarifications  to IESG
Jun  2010  DNS <new> transport protocol specification

---------- diffs-------------
--- charter-20090527.txt        2009-05-29 11:56:40.839081600 -0400
+++ charter-20090608.txt        2009-06-08 14:24:11.974524800 -0400
@@ -1,4 +1,4 @@
-
+<version 20090608>

  The DNS has a large installed base and repertoire of protocol
  specifications. The DNSEXT WG group will actively advance DNS
@@ -15,17 +15,18 @@

  The working group can nevertheless undertake work in following
  subjects without a charter change:
-       DNSSEC and TSIG/TKEY algorithm maintenance,
-       Hardening DNS protocol against forgery attempts,
-       Advancing existing Proposed standard RFC's to Draft/Full standard
-       Obsoleting RFC's.
+       DNSSEC and TSIG/TKEY algorithm maintenance
+       Hardening DNS protocol and providing guidance to implementors
+       Examining transport protocols possibly adding new ones.
+       Advancing existing Proposed Standard RFCs to Draft/Full Standard
+       Obsoleting RFCs.

  Before formal adoption of any such items at least 5 working group
-participants must publicly state that the items is within charter and is
+participants must publicly state that the item is within charter and is
  worthwhile item for further study.

  The DNSEXT WG will conduct the specified RFC5395 review of RR
-templates as they are posted, and ENDS0 Option templates if ENDS0-bis
+templates as they are posted, and EDNS0 Option templates if EDNS0-bis
  updates registration requirements.

  The WG does not intend to hold face to face meetings, though
@@ -35,11 +36,13 @@

  Milestones:
  Jun  2009  TSIG/MD5 Obsoleting to IESG.
-Jul  2009  AXFR Clarify  to IESG
+Jul  2009  RSA/SHA256 to IESG.
+Jul  2009  AXFR Clarify  to IESG.
  Sep  2009  EDNS0 Ping Option advanced to IESG
  Oct  2009  Resolver side Forgery Resilience advanced to IESG
  Oct  2009  DNSSEC Errata document to IESG
  Nov  2009  GOST DNSKEY and DS support advanced to IESG
-Dec  2009  ENDS0-bis update advanced to IESG
-
+Dec  2009  EDNS0-bis update advanced to IESG
+Feb  2010  DNS existing transport protocol 
recommendations/clarifications  to IESG
+Jun  2010  DNS <new> transport protocol specification

---

From: "Bart Smit" <[email-masked]>
Date: Wed, 10 Jun 2009 16:45:51 +0200 (CEST)

(already sent to Olafur; forgot to cc the list)

> Jun  2010  DNS <new> transport protocol specification

Does putting EDNS0 Ping on the list of milestones imply that
draft-hubert-ulevitch-edns-ping will be adopted as a wg doc? If not,
what's holding back adoption? Also, do we have any indication that Bert is
still willing to author it, despite having withdrawn his request?

Bart

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 10 Jun 2009 12:11:13 -0400

>still willing to author it, despite having withdrawn his request?

As I have said before.
There is enough support in the WG to adopt the work, there is disagreement
on if this is useful or not. ==> WG will adopt the document after it is updated
have one more round of discussion and then dispose of the document
(as someone asked dispose == advance or kill).
David Ulevitch has agreed to hold the editing token.
As Bert does not hold any IPR on this idea, the form of his participation is
immaterial, what matters is the idea not the people proposing it.

Once a document is formally adopted the editor of the document is supposed
to reflect the will of the working group, also editors serve at the 
"pleasure" of
the chairs.

The milestone is there to remind chairs to get the documents done.

         Olafur

---

From: "Bart Smit" <[email-masked]>
Date: Fri, 12 Jun 2009 11:21:45 +0200 (CEST)

>>what's holding back adoption?

> on if this is useful or not. ==> WG will adopt the document after it is

Maybe I don't understand the way things work around here, but on the one
hand you're saying that there is enough support to adopt and on the other
that the draft should be updated first.

So are we now in a situation where a draft is awaiting comments before
having been adopted, or is the somewhat arbitrarily delimited set of
comments received thusfar regarded as an amendment to the draft?

I ask because keeping in line with my understanding of this wg's
operation, I would be withholding any (hypothetical) comments I might have
until the draft has been adopted.

I just want to understand the procedures.

Bart

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Jun 2009 10:05:08 -0400

> until the draft has been adopted.

No need to do this.  Comment away, please.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.