Subject: [dnsext] Draft DNSEXT charter

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Fri, 29 May 2009 11:56:59 -0400

Dear colleagues,

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.

Milestones are preliminary and will be updated based on WG discussion.

Comments please,

         Olafur & Andrew

----- DNSEXT draft charter v20090527 -------

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 against forgery attempts,
         Advancing existing Proposed standard RFC's to Draft/Full standard
         Obsoleting RFC's.

Before formal adoption of any such items at least 5 working group
participants must publicly state that the items 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
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  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

---

From: [email-masked]
Date: Fri, 29 May 2009 19:13:57 +0100

> Milestones are preliminary and will be updated based on WG discussion.

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

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

--
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: [email-masked]
Date: Fri, 29 May 2009 23:11:46 +0000

> I'm unable to find a suitable place to drop this into the current text, 

	Ray steps on a very slippry slope here.  Clearly the intent
	is good, but there is the problem of ensuring a correct specification
	on which to measure an implementation.

--bill

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 29 May 2009 21:22:58 -0400

> 	on which to measure an implementation.

Is there something about the correctness of implementation that is
different from "clarifications" to the protocol?  Under the principle
of charity, one could easily assume that any case where an implementer
has deviated from the published specifications is attributable to some
lack of clarity on the part of those standards.  Under a broad meaning
of "clarification", for instance, we could understand the dnsproxy
draft as clarifying the implications of the protocol in respect of
certain other systems or protocols.  It's strictly a focus on the
protocol's implications, and trying to make clear exactly the
protocol's meaning.  

Thoughts?

A

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

---

From: [email-masked]
Date: Sat, 30 May 2009 04:28:51 +0000

> protocol's implications, and trying to make clear exactly the

certainly.

	a protocol is defined by specifications.
	a spec is written down on paper.
	an implementation is code built from a spec.

	clarification to a protocol are supposed to be
	reflected in the spec.  and implementations are 
	supposed to by updated based on changes to the spec.

	or you could take the view that the code is the protocol
	spec and clarifications are changes to the code.

	I think the IETF has a particular bias toward one of
	these two models.

	The concern here is how one defines a "correct" implementation.
	compliant with a specification?  If so, how does one assure
	the specification is "correct"?

	To my knowledge, the IETF has rarely, if ever, stepped into the
	implementation compliance validation role.  If DNSEXT should chose
	this path, please do so with eyes (and legal council) wide open.

--bill

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 30 May 2009 08:08:50 -0700

>	this path, please do so with eyes (and legal council) wide open.

This sounds like FUD. It is perfectly reasonable for a standards body to say "In spec A, we said B. After we published A, some implementers interpreted this as B'. Regardless of their reason for doing so, we are updating A to be clearer on what B is, and that it is not B'."

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Sat, 30 May 2009 16:28:31 +0000

> This sounds like FUD. It is perfectly reasonable for a standards body to say "In spec A, we said B. After we published A, some implementers interpreted this as B'. Regardless of their reason for do…

	thats updating a spec, not doing implementation conformance.
	but perhaps I am old fashioned... i think of an inplementation
	as code based on a published spec.
	
	it seems that some think the implementation is the spec.  

	B will always be B, any update to A will create B' and B != B'

	my problem here is not B or B', my problem is with understanding
	who gets to say what is "correct".

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

	the standards body can certainly declare RFC 1034 to be vague and
	subjective and rife with ambiguity... but its going to have a tough
	time claiming an implementation is not correctly implementing RFC 1034.

	I am pretty sure that it is going to be impossible to be completely 
	objective in  defining a protocol or specification that envisions
	and encompasses all possible edge/corner cases into perpetuity.

	and as long as there is a subjective facet, we will have to deal w/
	"rounding errors".   correctness argues for mathmatical proof.
	
--bill

---

From: Francis Dupont <[email-masked]>
Date: Sat, 30 May 2009 22:49:56 +0200

In your previous mail you wrote:

   Milestones:
   
=> perhaps I've missed something but I can't find the RSA-SHA256 for
DNSSEC (i.e., draft-ietf-dnsext-dnssec-rsasha256) here?

Regards

[email-masked]

PS: I am sure you know it is critical to get this published and
implemented before 2010.

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Sat, 30 May 2009 17:41:26 -0400

At 15:51 29/05/2009, George Barwood wrote:
>Is hardening DNS protocol against other attacks intended to be excluded?
>
>While forgery seems the most pressing concern, there are might be 
>concerns about
>authoritative DNSSEC servers being used as DoS amplifiers, for example.
>
>i.e. possibly substitute "forgery attempts" with "attacks" ?

How about just leaving it at "Hardening the DNS protocol"

         Olafur

---

From: Ted Lemon <[email-masked]>
Date: Sat, 30 May 2009 16:28:49 -0700

> 	correctly and yet not be interoperable.

When this happens, it means that the spec needs further work before it  
can progress to standard.   Which is, in fact, pretty much what Paul  
said that you seem to be disagreeing with.   A spec that can produce  
conforming but not interoperable implementations does not document  
either B or B', and it is not a standard.   It's entirely in scope for  
the IETF to decide to clarify the spec so that it unambiguously  
documents B, and excludes B'.   That's what it means for a spec to  
progress on the standards track.

---

From: [email-masked]
Date: Sun, 31 May 2009 00:36:42 +0000

> progress on the standards track.

	or - as in the case above, it is a standard, but a flawed one.
	no arguement about the IETF role as you indicate.  where I think
	things run off the rails is when the IETF tells implementations
	that they are non-conformant.

	the IETF has never done conformance testing of implementations.
	it does protocols and specs.

	the trick (as Roy called for) was who and how "correctness" is
	decided for either a protocol, a spec, or an implementation.

	if we (the IETF) are truely rigourous in our specifications,
	multiple independent implementations will be virtually identical.

	math proofs are kind of like that.

--bill

---

From: Florian Weimer <[email-masked]>
Date: Sun, 31 May 2009 10:02:12 +0200

> PS: I am sure you know it is critical to get this published and

This time frame is impossible to achieve due to the dependency on
NSEC3.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 31 May 2009 23:52:10 +0200

=> can you detail? Do you mean it is impossible to get it published
in time? implemented? Or the issue is begin/end of 2010 (in
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
the wording is "after 2010" so perhaps we have until the end of 2010
but for deployment in a limited context, so harder target too)?

Thanks