Subject: [dnsext] Adoption of draft-dempsky-dnscurve-01

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Jul 2010 14:22:25 -0400

Dear colleagues,

We received a request to adopt draft-dempsky-dnscurve-01 as a WG item.  

Some have suggested that such an adoption is not consistent with our
existing charter.  The chairs take no position at the moment on the
correctness of that assertion, but note that the draft charter
previously circulated contains language that would explicitly put this
work under the (new) charter.

We ask WG participants who want this work adopted to express their
support of the work, their view that it is on-charter, and their
willingness to review the work.  The usual conventions requiring five
such reviewers apply.

There will be time in the Maastricht meeting to discuss this item.

Best regards,

Andrew

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

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Tue, 6 Jul 2010 12:39:20 +0200

On 2010-07-05 20:22, Andrew Sullivan wrote:

> existing charter.

Would it be possible to elaborate a little on that? Can you perhaps
point me to those opinions? I'd like to know what the arguments where.

> The chairs take no position at the moment on the

Is the URL below the new charter?

http://datatracker.ietf.org/wg/dnsext/charter/

In that case I can only agree with the above that the work is
on-charter. Furthermore I'd like to express my provisional support for
it as well as my willingness to participate in reviewing it to the best
of my abilities.

> willingness to review the work.  The usual conventions requiring five

Regards,

-- 
Marco
SIDN

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Jul 2010 11:37:07 -0400

> point me to those opinions? I'd like to know what the arguments where.

The current charter says this:

  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
        Advancing existing Proposed Standard RFCs to Draft/Full Standard
        Obsoleting RFCs.
        Maintaining a Wiki containing a guide to DNS protocol RFC's.
        Improving DNS zone synchronization mechanisms
        Examining transport protocols, possibly adding new ones.

It is by no means obvious that dnscurve falls under any of those
explicit exceptions (and someone -- no I won't say who -- has argued
to me that it does not).  

> http://datatracker.ietf.org/wg/dnsext/charter/

No, that's the current one.  The same day I posted the message you
responded to, I also posted another copy of the draft charter.

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 6 Jul 2010 09:10:25 -0700

> explicit exceptions (and someone -- no I won't say who -- has argued

How is dnscurve not simply an encrypted transport protocol for DNS?

dnscurve to me seems effectively useless [1], but it certainly seems in scope to me.

[1] EG, the security considerations section is woefully deficient, and any real examination of this section demonstrates why dnscurve is effectively useless.  Additionally, because the dnscurve packets themselves aren't following the DNS protocol, it can't reliably run over UDP port 53 because there is a lot of stuff out there which blocks non-DNS over DNS.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 6 Jul 2010 16:30:44 +0000

> How is dnscurve not simply an encrypted transport protocol for DNS?

Because it is not at layer 4 ? 

That said, neither would DNS over DTLS, should anyone ever propose that.

Ray

---

From: Brandon Black <[email-masked]>
Date: Tue, 6 Jul 2010 23:11:10 -0500

> How is dnscurve not simply an encrypted transport protocol for DNS?

Well regardless of whether it's technically an encrypted transport or
not, it seems within the scope of dnsext under the item "Hardening DNS
protocol".

> [1] EG, the security considerations section is woefully deficient, and any real examination of this section demonstrates why dnscurve is effectively useless.

Are you referring to objections to the newness of the crypto, or the
fact that it only protects the cache<->auth channel (as opposed to
securing cache<->cache and cache<->client, or securing against
untrusted caches)?  They're all valid discussions to have.  Assuming
nobody greatly objects to the crypto part, I think extending dnscurve
out to the cache<->cache and cache<->client channels is really just a
key distribution/rollover problem.  I think that could be fixed.
cache<->auth currently uses public keys encoded in nameserver names,
but there's no reason that couldn't be extended to use some sort of
specific key RR as well, and then we don't necessarily have to use
those ugly long nameserver names.

Protecting against untrusted caches seems to be completely outside the
scope of what dnscurve is trying to do though.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Jul 2010 01:47:06 -0400

> not, it seems within the scope of dnsext under the item "Hardening DNS

Just so this thread doesn't turn into a debate about what the charter
says (since we have a thread for that), I want to apologise for
introducing this distraction and try to phrase things more evenly:

If you support adopting the document _and_ are willing to review it,
please say so.

If you think it is on-charter under our current charter, please say
so.  Olafur and I will regard this say-so as entailing that you think
it will be on-charter even if the new charter is adopted, because
nothing in the proposed charter excludes anything covered by the old
charter.  If you think our view is wrong, please note it, and then
take discussion of the charter problem to the charter thread.

If you think it will be on-charter assuming the new charter will be
adopted _but not_ under the existing charter, we also would like to
know that.

Thanks,

A

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

---

From: Alex Bligh <[email-masked]>
Date: Wed, 07 Jul 2010 11:57:01 +0100

> adopted _but not_ under the existing charter, we also would like to

I think is is probably not in scope under the existing charter; given
this was meant to be a "put w/g to sleep charter", I had read the
line re transports as support for SCTP, rather than an entirely new
cryptographic framework. However, I think it should be in scope
under the new charter (i.e. I think it should be a subject for
discussion, not that I necessarily think it is a good idea).

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Wed, 07 Jul 2010 14:01:16 +0000

> > If you think it will be on-charter assuming ...

> Date: Wed, 07 Jul 2010 11:57:01 +0100
> From: Alex Bligh <[email-masked]>
> 
> I think is is probably not in scope under the existing charter; ...

is "on charter" the same as "architecturally consistent"? when IETF undertook
"Secure DNS" we made some choices. channel security turned out to be necessary
and sufficient for the last mile (thus TSIG) but not sufficient for server-to-
server (thus DNSSEC).

is this WG now going to formally adopt server-to-server channel security as a
necessary part of "hardening the DNS" and if so are we open to other methods
besides just dnscurve? i have suppressed several of my own designs over the
last 15 years because they were "off mission" even though "on charter".

i'm mystified by why we're deciding the "on charter" question, and if this is
really a referendum on our new proposed charter, then i'd like to revisit the
new proposed charter to add logic to the effect of "finish Secure DNS as 
currently understood, and don't confuse implementors and operators by also
formally adopting completely different approaches and/or changing the mission
statement to include things like server-to-server channel encryption."

before you answer, consider the high likelihood of a dozen or more "hardening"
related proposals, all clamouring for formal adoption, none fitting the model
we thought we had for Secure DNS.  i'm basically not interested in an "on
charter?" question if we're so blatently ignoring the "on mission?" question.

if IETF wants "Secure DNS" we're going to have to give the world a solid spec
and stop changing our minds about how we intend to accomplish it.  we're now
in the "build a market of products and services" phase, and the message we'd
be sending by reopening the basic requirements question would not help that.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Jul 2010 11:24:13 -0400

On Wed, Jul 07, 2010 at 02:01:16PM +0000, Paul Vixie wrote:

> is "on charter" the same as "architecturally consistent"? 

One would like to hope so.

> besides just dnscurve? 

Among other things, DNSCurve could be used as a tool for addressing
the item in the proposed new charter, "Mechanisms that complement, or
are alternatives to, TSIG and SIG(0)".  That proposed item is a significant
difference with our existing charter.  If the new charter were adopted
and there were other techniques proposed that matched that work item,
they would also be on charter, and subject to the usual adoption conventions.

I think you're right to ask whether, under the existing WG charter,
DNSCurve would fall under the "hardening the DNS" rubric.  One could
certainly make an argument it wouldn't: the point of that entry was
clearly to do non-DNSSECy things to improve protocol resilience, such
as the port randomization work we did some time ago.

> i'm mystified by why we're deciding the "on charter" question

The question of whether a given draft can be adopted is answered with
three criteria: whether it is on-charter (this is just a general IETF
constraint about whether a WG works on a given item), whether there is
interest in the draft (which this WG has generally measured by the
"five reviewers" convention), and whether there is not significant
strong opinion against adopting a work item.  The first and last of
these are usually implicit in the questions we ask about adoption, but
in this case we happen to be revising the charter at the same time as
considering the work item, so I thought it was important to make this
on-charter question more explicit.  If we were trying to be more
orderly, I suppose the right thing to do would be to adopt a new
charter before making these decisions, but I think that's sort of
artificial (since surely one wants to write a charter with an eye to
work one is planning actually to do).

> new proposed charter 

As I asked in a previous message, if you want to change the proposed
charter please take that discussion to that thread.  I appreciate that
these topics are interrelated (obviously, or I wouldn't have pointed
it out), but I'd like to keep the discussion focussed as much as
possible.

> charter?" question if we're so blatently ignoring the "on mission?" question.

Naturally, the point of a charter is to capture the goals we are
trying to achieve.  I do not support empty formalism in these process
matters.

A

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

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Wed, 7 Jul 2010 17:44:44 +0200

> is "on charter" the same as "architecturally consistent"? 

How inconistent would the DNS architecture become?

DNSSEC and DNSCurve don't have to be mutual exclusive in my opinion.
They could in fact happily co-exist. DNScurve could give me what Rod
Beckstrom thinks DNSSEC already gives us today: privacy by encryption.
I'd like that.

http://www.youtube.com/watch?v=733f7xK5yF4

-- 
Marco

---

From: Alex Bligh <[email-masked]>
Date: Wed, 07 Jul 2010 17:43:31 +0100

--On 7 July 2010 14:01:16 +0000 Paul Vixie <[email-masked]> wrote:

> is "on charter" the same as "architecturally consistent"? when IETF
> undertook "Secure DNS" we made some choices. channel security turned out
> to be necessary and sufficient for the last mile (thus TSIG) but not
> sufficient for server-to- server (thus DNSSEC).
>
> is this WG now going to formally adopt server-to-server channel security
> as a necessary part of "hardening the DNS" and if so are we open to other
> methods besides just dnscurve? i have suppressed several of my own
> designs over the last 15 years because they were "off mission" even
> though "on charter".

Well, I think it is possible to claim DNSCURVE falls within
 "* Mechanisms that complement, or are alternatives to, TSIG and SIG(0)"

I agree with you that it is an undesirable and significant architecture
change, i.e. does more than the above, but both those points seem to be
open for debate. I don't see the value in excluding even consideration
of DNSCURVE because it's "outside our mandate". Surely better to discuss
it, and (if appropriate) argue for its rejection on the basis you set
out.

> before you answer, consider the high likelihood of a dozen or more
> "hardening" related proposals, all clamouring for formal adoption, none
> fitting the model we thought we had for Secure DNS.

You seem to be worried about a DoS attack. If rejection is desirable,
can't we reject them at the stage they ask for formal adoption, rather
than reject them by setting the charter so narrow they can't get in?
After all, there is nothing to prevent people clamouring for adoption
even if proposals are out of charter, and there is nothing to prevent
people arguing for adoption of ridiculous proposals that are in charter.
I may have missed your point, but I'm not sure how this helps.

-- 
Alex Bligh

---

From: [email-masked]
Date: Wed, 7 Jul 2010 16:53:38 +0000

> > --On 7 July 2010 01:47:06 -0400 Andrew Sullivan <[email-masked]> wrote:

	The WG has two choices:

	) adopt the draft for discussion as a WG item (and the new charter
	  looks like this is ok)
	
	or

	) send a note to the IESG indicating that this is outside the WG charter
	  and the IESG should _not_ send it to the WG for consideration when
	  the author(s) submit this as an indivdual submission.

	Given the two choices, and based on the fact that the folks on the ML 
	encouraged the authors to write the draft and bring the work to the IETF,
	I beleive that we are beholden to take this draft on.

--bill

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 7 Jul 2010 10:56:11 -0700

> willingness to review the work.  The usual conventions requiring five

I think it would be great to see the work adopted, and would be
willing to review the work.

-- 
Colm

---

From: Alex Bligh <[email-masked]>
Date: Wed, 07 Jul 2010 19:57:16 +0100

--On 5 July 2010 14:22:25 -0400 Andrew Sullivan <[email-masked]> wrote:

> support of the work,

I didn't answer this bit. I think there is lots of good stuff
in the draft (e.g. the ECC implementation), but I don't actually see
what the architecture as a whole would buy us that would outweigh the
upheaval. Does adoption mean one thinks its worthwhile reviewing as
a consistent whole? Or that one thinks it might have good bits in
worth using?

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Wed, 07 Jul 2010 18:57:14 +0000

> Date: Wed, 07 Jul 2010 17:43:31 +0100
> You seem to be worried about a DoS attack. ...

no. i'm remembering when paul borman made a completely reasonable suggestion
about the ipv6 on-wire protocol, that being to change it to put the dstip6
first in order to shave some byte times off of the latency of cut-through
forwarding devices. the WG agreed that this would have been a good idea a
year earlier, but also that tinkering with ip6 forever would delay market
adoption.

the dnscurve proponents explicitly say that they don't need DNSSEC and that
crypto-authenticity in the server-to-server side is enough for them.  it
ought to be within this WG's charter to say "Secure DNS is important, and
you can either like it or not, but we're not going to admit alternatives
during the market adoption phase."  for some reason it is not (in our power)
and i'm mystified and disturbed by this.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Jul 2010 15:07:12 -0400

> a consistent whole? Or that one thinks it might have good bits in

Speaking only for myself and with no hat, it seems to me that if you
think something contains a useful idea but that it is otherwise a bad
idea, you'd be better off to lift that single idea out, write it up as
a separate I-D, and put a prominent acknowledgement in the resulting
I-D.  It is easier to write a new document than to try to pare out bad
ideas from a longer document, in my experience.

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jul 2010 12:50:45 -0700

>ideas from a longer document, in my experience.

FWIW, I have a not-fully-formed intention do this with DNScurve. The current draft of DNScurve has some really useful features that are not found anywhere else, but those are weighed down by some other misfeatures that can pared out.

More importantly, what DNScurve offers is of value beyond the DNS. At its core, it is an elegant hack that allows two parties to set up very light-weight encrypted and authenticated tunnels for transport. You can transport DNS, of course, but you can also transport anything that would normally go over layer 4.

More to the point of this thread: I don't think it is actually covered in the current charter, nor should it be. It is basically tunneling a completely different protocol over port 53. If DNScurve ran on a different port from normally-formatted DNS queries and responses, that would possibly be within the scope of the charter.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Jul 2010 15:58:37 -0400

> and i'm mystified and disturbed by this.

Sure it is.  That's why the question is before the WG.

A

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

---

From: "George Barwood" <[email-masked]>
Date: Wed, 7 Jul 2010 22:14:26 +0100

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 05, 2010 7:22 PM
Subject: [dnsext] Adoption of draft-dempsky-dnscurve-01

> willingness to review the work.  The usual conventions requiring five

I don't support adoption at this time, reaosns being:

(1) I think DNSCurve solves only some of the outstanding transport problems
associated with DNS. I have worked on a draft that addresses these issues, and 
consider that to be a more complete and architecturally correct solution 
( http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport-18 ).

(2) However even I don't propose the adoption of my own draft quite yet.
It has not yet been shown that the transport problems are sufficiently 
significant, and I believe that with some care, it is practical to deploy
DNSSEC on the current transport. I would like to see 
draft-ietf-dnsext-rfc2671bis-edns completed before adopting new transport
work ( in particular I think fragmentation issues should be addressed in bis-edns ). 
After that, I think a sensible pause while DNSSEC deployment proceeeds 
would be sensible. If at that point further work seems justified, that would
be the time to proceed.

Regards,
George Barwood

---

From: Joe Abley <[email-masked]>
Date: Fri, 9 Jul 2010 17:33:01 -0400

> 	  the author(s) submit this as an indivdual submission.

I don't understand why you think so.

We can decide not to adopt all manner of documents as working group items, but still offer to review them as individual submissions if they relate to the DNS. This is not materially different from reviewing individual submissions for which the question of wg adoption has not come up.

Joe