Subject: dropping request for adoption of EDNS-PING, was Re: [dnsext] Point of order

From: bert hubert <[email-masked]>
Date: Sat, 16 May 2009 00:02:57 +0200

Hi everybody,

As I hope you all know, I care deeply about the practical & real life
security of DNS. It is for this reason that I started the forgery resilience
draft, and kept it alive for 2+ years, in the face of stern opposition.

Afterwards, it appears consensus was raised that RFC 5452 (as forgery
resilience became known) would not be able to provide sufficient protection
against 'Kaminsky Spoofing', and the WG opened up discussions on 'further
resilience' work, especially for the interim period until we would have full
DNSSEC deployment.

>From this discussion, several drafts emanated, of which EDNS-PING was picked
as one (among several others) to be discussed further.

In the course of the 'further resilience' discussions, the question if
further resilience would detract from DNSSEC work was often raised.

It has now become very clear that the perceived answer to this question is
'yes' - to the point that the IAB has been asked [1] to weigh in to see if
it should stop the 'dilution' of WG interest in DNSSEC.

Even though EDNS-PING never claimed to be anything but forgery-resilience
for clients & servers that supported it, it is now expected to provide
perfect security for everybody. Additionally, the draft is supposed to go
into great detail on how exactly to deploy this forgery-resilience tactic.
Such detailed drafts never become RFCs.

Also, EDNS-PING has now been labelled as 'complex' and 'costly', an expense
which could be spared by the speedy rollout of DNSSEC, which apparently is
neither. [2]

I have also been pointedly informed [3] that EDNS-PING, which requires an
EDNS option code, can't succeed as an individual draft either since only the
DNSEXT WG can authorize the issue of such an EDNS option code from IANA.

In addition, even though >1% of all DNS zones currently served respond to an
EDNS-PING request, I've been told that my 'home experiments' are no proof
that EDNS-PING can work.

In the face of such sage wisdom, I've decided to give up, and I withdraw my
request for adoption of draft-hubert-ulevitch-edns-ping.

DNS security for me is a work of love, and not a business activity. And to
be honest, the nature of the DNS community (as experienced on the lists) has
removed any joy I had from working on DNS standardisation.

I wish everybody good luck with their favorite ways to improve the security
of the domain name system.

I sincerely hope you succeed.

	Bert

PS: The IPR statement in draft-hubert-ulevitch-edns-ping holds, so anyone
wanting to take it over should feel free to do so.

[1] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00578.html
[2] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00577.html
[3] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00676.html

--
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: Bart Smit <[email-masked]>
Date: Sat, 16 May 2009 01:33:53 +0200

> request for adoption of draft-hubert-ulevitch-edns-ping.

I find it quite sad and ironic to see this happen on the very day that  
I've
decided to step in, for about the same reasons as Bert had to step  
out. The
words "too late" cross my mind.

Bart

---

From: [email-masked]
Date: Sat, 16 May 2009 00:03:13 +0000

> words "too late" cross my mind.

	the bar is set pretty high for any development work to be
	done, both at the WG level(*) and at the institutional (IETF/IESG)
	level.

	how many folks would be interested in spinning up a list to 
	discuss augmetnation/enhancement to the DNS that falls outside
	the (self-impposed) constraints of the IETF DNSEXT-WG?

--bill

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 15 May 2009 22:36:18 -0400

Dear colleagues,

This is a plea from one co-chair, speaking personally.

>    the (self-impposed) constraints of the IETF DNSEXT-WG?

Before this thread turns into a debate about whether DNS protocol  
development should happen elsewhere, I'd like to remind everyone that  
we have an open debate on a number of options, and no decision of any  
kind has been taken. We chairs set a deadline before which we wanted  
debate to proceed to see whether a consensus might emerge. That date  
is next week, and I can't see any strong reason to try to change it  
now. We also said we'd have a meeting in Stockholm if no consensus  
emerged.

Any option that was on the table remains there (and perhaps some new  
ones are introduced). That's true even if we are forced unhappily to  
accept that someone has walked away in frustration.

So, please, can we focus on the options before us (that is, the ones  
Olafur and I listed in out pre-meeting announcement and any that have  
come up since)?  Thanks.

A

---

From: Federico Lucifredi <[email-masked]>
Date: Sat, 16 May 2009 12:39:54 -0400

I would like to ask for DNSCURVE to be seriously considered by this
group, it seems a valid option along those that have been enumerated
previously.

Certainly, it seems to require much less overhauling than DNSSEC thus far.

No flames please - just asking for it to get a fair shake. I have worked
on DNSSEC, so I know more about this latter one than DNSCURVE, but if a
simpler or somehow solution is possible, it should be considered regardless.

dnscurve.org seems to have less information than I'd wish... are there
any further good docs on the matter?

 Best -Federico

> Andrew Sullivan wrote:
>> development should happen elsewhere, I'd like to remind everyone that we
>> have an open debate on a number of options, and no decision of any kind
>> has been taken. We chairs set a deadline before which we wanted debate
>> to proceed to see whether a consensus might emerge. That date is next
>> week, and I can't see any strong reason to try to change it now. We also
>> said we'd have a meeting in Stockholm if no consensus emerged.
>>

-- 
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked] - GnuPG 0x4A73884C

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 16 May 2009 10:45:56 -0700

>any further good docs on the matter?

I'm confused. You want the WG to consider DNSCURVE, but you then say that there is "less information than I'd wish". How can we consider it if we don't know what it is?

--Paul Hoffman, Director
--VPN Consortium

---

From: Matthew Dempsky <[email-masked]>
Date: Sat, 16 May 2009 11:52:50 -0700

> any further good docs on the matter?

What more information or documentation are you looking for?

The only thing that comes to mind as inadequately explained on
dnscurve.org is the definition of a "cryptographic box", which is a
term used by NaCl[1].  The existing documentation is admittedly terse,
but it was otherwise sufficient for us to have built a mostly working
DNSCurve forwarder[2] as well as a patch for djbdns to add support for
DNSCurve[3].

These implementations still need some polish and documentation, but
they're largely functional and just waiting on us to have some extra
free time to work on it more.  If you're interested in contributing,
contact me off list.

[1] http://nacl.cace-project.eu/
[2] http://github.com/mrd/dnscurve/tree/master
[3] http://shinobi.dempsky.org/~matthew/misc/djbdns-dnscurve.patch

---

From: Matthew Dempsky <[email-masked]>
Date: Sat, 16 May 2009 12:03:56 -0700

> I'm confused. You want the WG to consider DNSCURVE, but you then say that there is "less information than I'd wish". How can we consider it if we don't know what it is?

If you have questions about DNSCurve that are not adequately answered
by the dnscurve.org web site, then I'll be happy to try to answer them
here.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 16 May 2009 12:06:35 -0700

>by the dnscurve.org web site, then I'll be happy to try to answer them

Thanks! Where is the stable version of the protocol that we can use to determine if we should adopt it in this WG?

--Paul Hoffman, Director
--VPN Consortium

---

From: Federico Lucifredi <[email-masked]>
Date: Sat, 16 May 2009 15:15:33 -0400

> I'm confused. You want the WG to consider DNSCURVE, but you then say that there is "less information than I'd wish". How can we consider it if we don't know what it is?

I am presuming there is more published. I will look and report back, if
no one knows better here :)

 Best-F

---

From: Matthew Dempsky <[email-masked]>
Date: Sat, 16 May 2009 12:32:20 -0700

> Thanks! Where is the stable version of the protocol that we can use to determine if we should adopt it in this WG?

No DNSCurve developer is concerned yet with this WG adopting it, so if
you're genuinely interested in discussing DNSCurve, you'll have to
rely on the dnscurve.org web site for details for now.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 16 May 2009 18:11:36 -0700

>rely on the dnscurve.org web site for details for now.

I can't speak for others, but then I think the correct answer from the WG is "thanks but no thanks". Not having a stable reference is a pretty heavy impediment, particularly when the DNS-specific parts change. If a "DNSCurve developer" wants to spend the hour or two it takes to convert the disparate stuff from the web site into an Internet Draft, that would be lovely.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 16 May 2009 18:34:43 -0700

Paul and all,

  You can do so by learning on your own verition.  A rather simple
concept really.

> I'm confused. You want the WG to consider DNSCURVE, but you then say that there is "less information than I'd wish". How can we consider it if we don't know what it is?

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 16 May 2009 19:07:09 -0700

Paul and all,

  Well in this instance, thankfully your not speaking for others including
myself.  So we can begin minus Paul.

  Thank you Matt for the info.  Perhaps Paul will avail himself as well
as others of the information and begin the learning curve.  Perhaps
Paul will change his thinking and begin his journey of learning of
DNSCURVE when he feels he is up to the challenge...

Regards,

---

From: Matthew Dempsky <[email-masked]>
Date: Sun, 17 May 2009 00:36:14 -0700

On Sat, May 16, 2009 at 6:11 PM, Paul Hoffman <[email-masked]> wrote:
> I can't speak for others, but then I think the correct answer from the WG is "thanks but no thanks". Not having a stable reference is a pretty heavy impediment, particularly when the DNS-specific parts change.

I didn't suggest this WG adopt it.  I only offered that if anyone here
had questions, I would be willing to answer them from my experience in
building one and a half DNSCurve implementations.

> If a "DNSCurve developer" wants to spend the hour or two it takes to convert the disparate stuff from the web site into an Internet Draft, that would be lovely.

And if you wanted to spend the hour or two to actually read the web
site, that would be lovely too.  The entire site is less than 5000
words, so it shouldn't take you long.

Otherwise, please stop feigning interest in it.  You've complained
about the lack of a "stable" specification for some time now, even
though the pages haven't changed in six months.  What's so magical
about being in RFC format?  If you really want a guarantee that the
files you're looking at won't change, you can use

    http://shinobi.dempsky.org/~matthew/dnscurve.org-20090517/

I just mirrored the files from dnscurve.org here, and I promise not to
update them.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 May 2009 08:08:11 -0700

At 12:36 AM -0700 5/17/09, Matthew Dempsky wrote:
>I didn't suggest this WG adopt it. 

Understood.

>I only offered that if anyone here

This is part of a thread about the WG adopting the protocol.

>words, so it shouldn't take you long.

I have read it, fully, a few times; that's how I know that it is a moving target.

>Otherwise, please stop feigning interest in it. 

Interest != support. It *is* interesting, and it solves a number of the problems that DNSSEC has, and it also creates some of its own. The WG can decide how it wants to make that balance.

>You've complained
>though the pages haven't changed in six months. 

And it changed, significantly, a few times before that.

>What's so magical
>about being in RFC format? 

A universally-available, easily-referenced document that is not subject to in-place change by its authors.

>If you really want a guarantee that the

That works for me, if it is sufficient for others in the WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Sun, 17 May 2009 17:08:56 +0000

wrt dnscurve, there's no obvious (to me) technical reason not to pursue it.
however, that was also true of TUBA after the IPng decision was made, and i
think there can be obvious nontechnical reasons not to pursue something
that would compete for global market/mind/deployment share against DNSSEC.

nontechnical decisions of that kind are above the pay grade of this WG, yet
must still be made from time to time.  can an IETF process expert educate
us (or is it just me?) as to how we get a nontechnical ruling on this?

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 17 May 2009 11:35:54 -0700

Paul and all,

  Paul has this about right.  If Paul H doesn't want to pursue
DNSCURVE for anti-competitive reasons seems to me that
the discussion/debate is more about politically charged reasons
rather than more reasonable technical ones.

Paul Vixie wrote:

> archive: <http://ops.ietf.org/lists/namedrop

Regards,

---

From: Michael StJohns <[email-masked]>
Date: Sun, 17 May 2009 15:25:49 -0400

Generally, working group work items are either specified in the charter, OR adopted after the submission and discussion of an Internet Draft.  Rarely, they're adopted by the WG in plenary session prior to the submission of an ID to meet a well specified requirement - e.g. a hole filler.

Without making a judgement on the technical (or political - *shesh*) merits of DNSCURVE, I haven't seen any argument why it deserves special consideration to bypass the above. 

If the proponents of DNSCURVE want it to be considered by the working group, I suggest they would have better luck submitting an ID for the group's consideration rather directing the members to a web site that appears to be organized more as propaganda (Webster definition 2 - the spreading of ideas for the purpose of helping a cause) than as a solid technical proposal.

I'd further suggest, that absent such submission there's not a lot more to discuss that's appropriate for this mailing list.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 17 May 2009 15:48:35 -0400

<hat="moderator">

Dear colleagues,

On Sat, May 16, 2009 at 06:11:36PM -0700, Paul Hoffman wrote:

> the WG is "thanks but no thanks". Not having a stable reference is a
> pretty heavy impediment, particularly when the DNS-specific parts
> change. 

This is exactly where we got the last time DNSCurve was discussed on
this list.  See, for instance, the thread beginning at
http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01708.html,
where Roy pleaded that we either get a draft or stop discussing it.

Nobody is suggesting that the DNSEXT WG is the be-all and end-all of
DNS, but in the IETF we have exactly one way to proceed, and that is
to work on Internet Drafts.  If nobody is willing to write such a
draft, then we're out of luck.  By the same token, if someone _is_
willing to write such a draft, then we have something to discuss.

The same principle goes for the strategy involving TKEY and TSIG that
Paul Vixie has proposed, but at least there what we need is a
relatively simple draft explaining how to do something with an already
implemented and standardized technology.  I think if his suggestion
found support, it would not be too hard to find an editor for the
needed document.  DNSCurve is rather more complicated, however, and
the set of those who both understand it, and are likely to be willing
to contribute the work to see an I-D through this working group, is
small.  If you are such a volunteer, I encourage you to say so and
then to produce such a draft.

In the absence of such a draft or planned draft, however, we have
nothing to discuss adopting.  So we should not discuss the merits of
such adoption.  

Thanks,

Andrew

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

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 17 May 2009 14:04:23 -0700

Andrew and all,

  Yes, and the one size/method fits all is one of the central problems
with the IETF.  But it can and likely should be overcome to the
benifit of all.

Regards,

---

From: Paul Vixie <[email-masked]>
Date: Sun, 17 May 2009 21:33:07 +0000

> Date: Sun, 17 May 2009 15:25:49 -0400
> From: Michael StJohns <[email-masked]>
> ...
> If the proponents of DNSCURVE want it to be considered by the working
> group, I suggest they would have better luck submitting an ID for the
> group's consideration ...

i think the dnscurve folks have made clear that they don't care whether
IETF takes up their work or not.  but here we see some cracks in the IETF
model.  for one thing, lack of interest in IETF's processes on the part of
a technology's creators should not be a disqualifier.  (RFC 2616, i'm 
looking at *you*.)  if DNS CURVE or EDNS PING are championed by someone
other than their original authors, they could still make it to RFC.

but the more important crack exposed in the IETF model is that it doesn't
take IETF action to create a global interoperable technology.  (RFC 1001
and RFC 1002, i'm looking at *you*.)  if DNS CURVE or EDNS PING or similar
were variously/multiply implemented and then widely deployed (for example
by Google, Akamai, Microsoft, Apple, and at least one F/L/OSS package) it
would not matter whether IETF had thought it was a good idea, or not.

> I'd further suggest, that absent such submission there's not a lot more
> to discuss that's appropriate for this mailing list.

i'm desperately afraid that you may be right.  but in case not, let me ask
that the IETF practice some leadership which includes some vision and some
direction -- and not just act as a preventer/gatekeeper of ideas whose
authors may have other options besides getting an RFC published.  sometimes
leadership isn't universally popular -- for example i was a TUBA fan and i
knew that IPng could not possibly live up to its promises (and here we are!)
and i was angry about the IPng decision at the time.  however, i knew then
as i know now that if we want to move a whole world and its industry, we're
going to have to make some choices that favour one approach over another,
and which preclude an open-ended solution set, and which sometimes cause us
to finish multigenerational projects even when some people have different
goals, like end to end dns security (DNSSEC) vs. hop by hop dns security
(DNS CURVE and EDNS PING).

> Date: Sun, 17 May 2009 15:48:35 -0400
> From: Andrew Sullivan <[email-masked]>
> ...

what if someone is willing to write an internet draft but the idea they
want to advance is not strategically compatible with the IETF's stated long
term aims?  what's the review process on long term strategy?  if it isn't
meant to be discussed in the WG, then where do i need to go if i want to
discuss (and in this case make explicit) long term dns security strategy in
the IETF?

> Paul Vixie has proposed, but at least there what we need is a relatively
> simple draft explaining how to do something with an already implemented
> and standardized technology.  I think if his suggestion found support, it
> would not be too hard to find an editor for the needed document.

i'm not sure what this means.  several people supported EDNS PING in the
recent discussion here, and several have indicated support for DNS CURVE
as well.  of course, there were also detractors.  how does the WG propose 
to measure early support well enough to know whether to seek a document
editor?  right now we have a qualification for "accepting a document" which
counts only on five people willing to review it... with no mention of
whether those five should be generally supportive... and with no mention
of whether the idea itself should be compatible with the IETF's long term
strategy for related technologies.  i find the criteria and process "muddy."

> DNSCurve is rather more complicated, however, and the set of those who
> both understand it, and are likely to be willing to contribute the work
> to see an I-D through this working group, is small.  If you are such a
> volunteer, I encourage you to say so and then to produce such a draft.
> 
> In the absence of such a draft or planned draft, however, we have nothing
> to discuss adopting.  So we should not discuss the merits of such
> adoption.

i think several of us are wondering how to decide whether to write an I-D
at all.  that's why i'm asking leadership-related questions about strategy.
and all of that has to be worked out before we can say that without a draft
there is nothing to discuss.

paul

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 17 May 2009 15:38:59 -0700

Paul and all,

  Well said here...  >:)

Regards,

---

From: Florian Weimer <[email-masked]>
Date: Mon, 18 May 2009 09:42:55 +0200

> by the dnscurve.org web site, then I'll be happy to try to answer them

Why has DNSCURVE a fallback to port 53?  Why don't implementations
switch to a different port when they see DNSCURVE support in the NS
record?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 May 2009 09:58:26 +0200

On Sat, May 16, 2009 at 12:02:57AM +0200,
 bert hubert <[email-masked]> wrote 
 a message of 65 lines which said:

> I have also been pointedly informed [3] that EDNS-PING, which
> requires an EDNS option code, can't succeed as an individual draft
> either since only the DNSEXT WG can authorize the issue of such an
> EDNS option code from IANA.

> [3]
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00676.html

Yes, this is what is written in the message you mention but I am not
convinced.

RCF 2671 says:

     any published RFC (including Informational, Experimental, or BCP)
     should be grounds for allocation of an EDNS Option Code.

And the IANA registry <http://www.iana.org/assignments/dns-parameters> 
says:

Registry Name: DNS EDNS0 Options 
Reference: [RFC5001]
Registration Procedures: Specification required

And "Specification required" is defined in RFC 5226 as not even
requesting a RFC.

So, I really believe that the message you mention was wrong. EDNS-PING
can have its option code through an individual Informational
RFC. (There are, after all, 65535 possible option codes.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 May 2009 10:10:43 +0200

On Sat, May 16, 2009 at 06:11:36PM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 17 lines which said:

> If a "DNSCurve developer" wants to spend the hour or two it takes to
> convert the disparate stuff from the web site into an Internet
> Draft, that would be lovely.

Of course, an Internet-Draft is mandatory if the idea is to bring the
work to the IETF but, since it is not the case, I would be
sufficiently happy with a detailed description of the protocol (the
closest thing to a specification seems to be
<http://dnscurve.org/impl.html>) *and* to a serious improvement of the
FUD^H^H^Hadvocacy Web page at <http://dnscurve.org/dnssec.html>, for
instance by adding in the Security section lines like:

Type of security          DNSSEC                   DNSCURVE

Integrity despite         Protects against         Does not protect against 
rogue secondary name      it                       it
servers of resolvers

Ability to follow         The actual algo-         Only one algorithm,
the progress in           rithm is not hardwired   if it is broken, 
cryptography              in the protocol. New     everything is over.
                          algos can be added.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 May 2009 10:17:13 +0200

On Sun, May 17, 2009 at 03:48:35PM -0400,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 49 lines which said:

> draft, then we're out of luck.

Which leads to a question (which is not only related to DNScurve but
also to the EDNS-PING or cookies assassinations): what body is in
charge of the DNS security? Not this WG, which only examinates things
properly formatted as I-D, and is more and more a DNSSEC-only WG. So,
who? ICANN SSAC? ITU WG-nnn? DNS-OARC? US DHS? Microsoft with its
Conficker bounties?

I suspect the answer is "No one does, that's the Internet way" but it
may be too frightening for my little heart.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 May 2009 10:21:03 +0200

On Mon, May 18, 2009 at 10:10:43AM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> rogue secondary name      it                       it

Of course, it was "rogue secondary name servers OR resolvers".

---

From: "Aki Tuomi" <[email-masked]>
Date: Mon, 18 May 2009 11:40:23 +0300

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Stephane Bortzmeyer
> Sent: Monday, May 18, 2009 11:17 AM
> To: Andrew Sullivan
> Cc: [email-masked]
> Subject: [dnsext] Security of the DNS, holistic approach (Was: DNSCURVE
> 

I have a bad feeling that the correct answer (although they won't admit it) is that ISC is the one who decides. After all, their proponents seem to get the "final say" on how things are done. 
 
-- cm

h�{.n�+���zwZ��,j��v�y�覗������-��"z��"�a{
+v�칻�&ފv��x%zX�y�-�鞲Ơzױ��ɪ܆+ކ�i��)�'�~���X����jg���iz�?

---

From: [email-masked]
Date: Mon, 18 May 2009 09:25:57 +0000

> I have a bad feeling that the correct answer (although they won't admit it) is that ISC is the one who decides. After all, their proponents seem to get the "final say" on how things are done. 

s/ISC/Dominat DNS implementors/

--bill

---

From: Federico Lucifredi <[email-masked]>
Date: Mon, 18 May 2009 08:24:06 -0400

These two improvements would largely satisy what I'm looking for.

 Best-F

---

From: bert hubert <[email-masked]>
Date: Mon, 18 May 2009 10:21:07 +0200

> RFC. (There are, after all, 65535 possible option codes.)

I think I recall IANA stating there was some confusion. In general the
point is moot since both EDNS option code 4 and 5 are in actual &
somewhat wide use and I guess no-one would want to use these option
codes anymore since they are 'polluted'.

    Bert

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 May 2009 09:28:11 -0400

[no hat]

> s/ISC/Dominat DNS implementors/

i.e. those with running code?

A

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

---

From: [email-masked]
Date: Mon, 18 May 2009 13:45:25 +0000

> i.e. those with running code?

	one assumes that they achieve thier dominat position  based on
	use of running code - instead of being dominat in other traits,
	YMMV... :)

--bill

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 May 2009 09:49:06 -0400

Stephane (and Bert),

>      should be grounds for allocation of an EDNS Option Code.

Since I was the one who drafted [3], I need to clarify it.  Sorry that
the reasoning wasn't clear.

The simple fact is that and EDNS0 Option Code requires publication of
an RFC.  The draft for that RFC is going to require an IANA section,
and that IANA section will request the assignment of the option code.
Moreover, the  publication will require IETF consensus.  These are all
just process rules.

Now, one of two things are possible in the case the work does not come
out of the DNSEXT WG.  Either the sponsoring AD will send the work
here for review anyway, or else the sponsoring AD won't.  In the
former case, the work is back here, so we might as well come to some
conclusion before it goes to the IESG.  In the latter case, the
discussion moves to the IETF, where exactly the same debates that
might otherwise happen here are instead hashed out on the general
community list. At some point, someone on the IETF list will
(correctly IMHO) ask why, if the DNS people don't agree about this
yet, why the work isn't being discussed on the mailing list explicitly
devoted to working on the DNS protocol.

So, even though there is a _de jure_ way that the work need not
proceed through the working group, as a matter of practice this WG is
going to end up involved somehow in any EDNS0 Option Code assignment
that is the slightest bit controversial.  If anyone thinks this is
completely mistaken, however, I'd be interested to hear the argument.
(The argument would, I think, be a fairly knock-down proof that the WG
could be wound up more or less immediately.)

Best regards,

Andrew

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 May 2009 14:05:49 +0000

> Date: Mon, 18 May 2009 11:40:23 +0300
> From: "Aki Tuomi" <[email-masked]>
> ...
> I have a bad feeling that the correct answer (although they won't admit
> it) is that ISC is the one who decides. After all, their proponents seem
> to get the "final say" on how things are done.

frequent simultaneity does not necessarily require causality.  ISC has
hired the best people we could get, and we will continue to do so.  (CVs to
me plz) those people, due to their long experience, tend to have a lot to
say which is often intelligent and rational.  if you see ISC people winning
arguments or leading consensus, that may be because of our selection
criteria for employees, and not because of ISC's brand strength or BIND's
market size.

once in a while we do stuff that's controversial and we do it outside IETF.
for example, delegation only, and DNSSEC lookaside validation (DLV).  these
features are never enabled by default in our code base since they are not
part of the IETF DNS standard, to which we adhere strongly.  note that some
of the stuff IETF has come up with (DNSSEC, EDNS) has also been controversial
in the eyes of our user/customer base, but we default it to "on" when we can
do it without breaking existing configurations.

where we encounter problems in the field like open recursion, we try to work
with the IETF DNSEXT WG to get a draft RFC written, specifically so that we
can change the default BIND configuration.  (for open recursion, we wanted to
default to allowing queries only from the locally attached networks, and the
result was RFC 5358, and the BIND version that changed this default did in
fact break some working configurations, but it was absolutely unavoidable.)

a few years back when i saw this WG as moribund i tried to start a separate
entity called DNS-MODA that would push for new DNS technology and standards,
and for a while we (ISC, WIDE, Autonomica) thought we might get that going.
in the end we found a lack of institutional interest (that is, sponsorship
and active participation) in anything more ambitious than this working group,
so we shut DNS-MODA down.  i'm still interested in something like that, btw.

so to the extent possible, ISC works within the IETF standards process, and
we are bound by tradition to implement whatever DNS standards come from this
working group.  and we have some of the best DNS technologists in the field,
which is the reason you so often see ISC people getting consensus on stuff.
(getting consensus inside ISC is often a much rougher process than the 
debates and discussions you can see on namedroppers@, btw.)

note that this nonadmission of decisionmaking powers by ISC also contains an
alternative explaination for the appearance thereof.

paul vixie
president
isc

---

From: Edward Lewis <[email-masked]>
Date: Mon, 18 May 2009 10:24:40 -0400

>rely on the dnscurve.org web site for details for now.

I think (as in not really sure, but I think) that for something to be 
considered "by the IETF" there are IPR considerations.  When an 
Internet Draft is submitted, the process includes the submitter to 
agree to the Note Well statement.

If we discuss stuff that hasn't cleared that hurdle, there could be 
trouble.  (Like, "hey let's look at some proprietary software's 
documentation for ideas...")

At 18:11 -0700 5/16/09, Paul Hoffman wrote:

>I can't speak for others, but then I think the correct answer from the WG
>is "thanks but no thanks". Not having a stable reference is a pretty heavy
>impediment, particularly when the DNS-specific parts change. If a "DNSCurve
>developer" wants to spend the hour or two it takes to convert the disparate
>stuff from the web site into an Internet Draft, that would be lovely.

I wouldn't say we need stable reference.  That is a bar too high.  By 
that standard, we would never do anything but rubber stamp proposals.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 May 2009 07:49:23 -0700

At 10:24 AM -0400 5/18/09, Edward Lewis wrote:
>I wouldn't say we need stable reference.  That is a bar too high.  By that standard, we would never do anything but rubber stamp proposals.

Sorry, I overstated the requirement. We need a stable *document* of the current state of the proposal. I think we all agree to that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Mon, 18 May 2009 10:56:53 -0400

>RFC. (There are, after all, 65535 possible option codes.)

The registry is wrong, and that is partially my fault.
The registry was specified by RFC2671 but NOT created by IANA as the
WG and IESG let this document advance without IANA consideration section saying
IANA needed to create a registry.
RFC2671 says "Published RFC" as allocation mechanism for EDNS0 options
(see last paragraph in section 7).

Any individual RFC will be send to DNSEXT for comment by the IESG, thus
no end run is possible.

RFC5001 was the first RFC to register an option thus its publication
forced the issue to create the registry.

I'm hoping that the WG will turn its attention to work on RFC2671-bis
and in that context figure out what the right rule is and specify it.

         Olafur

         Olafur

RFC5001 was the first RFC to

---

From: Basil Dolmatov <[email-masked]>
Date: Mon, 18 May 2009 19:30:16 +0400

Stephane Bortzmeyer пишет:

> charge of the DNS security? 
Mine, for instance <grin>

dol@

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 18 May 2009 09:18:57 -0700

> switch to a different port when they see DNSCURVE support in the NS

I believe this decision was made to be backwards compatible with
existing firewall rules.  If a DNS cache can currently send queries to
servers, then it should also be able to immediately start using
DNSCurve without any firewall changes.

An example use case is running a local DNS cache on an untrusted
network where you cannot control the firewall settings.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 18 May 2009 18:21:23 +0200

> DNSCurve without any firewall changes.

The documentation also suggests that a separate IP address is required
in some cases, so this particular trade-off is rather dubious, IMHO.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 18 May 2009 09:26:21 -0700

> in some cases, so this particular trade-off is rather dubious, IMHO.

No, you can continue using the same IP address if you wanted.

I assume you're referring to the nytimes.com example, in which case
the reason to setup the DNSCurve forwarder on a new IP address is to
be able to test the forwarder without disrupting DNS traffic to the
old IP address.  If that was not a concern (e.g., if you're using some
load balancing to spread traffic across multiple hosts, or you just
don't receive enough traffic to worry about a single server being
down), then you could install the DNSCurve forwarder in place.

(In either case, you'll still have to publish the new NS records, of course.)

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 18 May 2009 09:51:57 -0700

On Mon, May 18, 2009 at 1:10 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> I would be
> <http://dnscurve.org/impl.html>)

Do you have specific examples of where you think additional details
would be helpful?  (I've implemented DNSCurve support in two separate
products so far, and I thought the existing documentation was
reasonably clear, but I realize what's clear to me may differ from
what's clear to others.)

> rogue secondary name      it                       it

Somewhat agree.  I don't have much more time to reply to emails right
now, so I'll just offer an IOU to expand upon this later.

> cryptography              in the protocol. New     everything is over.

The DNSCurve spec allows the public key to appear anywhere in the name
server's name.  If the security of Curve25519/XSalsa20/Poly1305
becomes questionable, it would be possible to put together a DNSCurve
2 spec using the same basic framework but new algorithms and new magic
string constants, and then for administrators to update their NS
records again to signal support for both (and then to eventually
transition to supporting just one again).

Similarly, if a DNSSEC algorithm's security becomes questionable,
there will be a transition period where servers will have to publish
public keys and/or have to sign records under both old and new
algorithms.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 18 May 2009 10:43:05 -0700

> transition to supporting just one again).

Correct me if I'm wrong, but doesn't DNSSEC's key encoding process  
effectively limit public key length?

Thus, isn't it reliant on ECC and specific elliptic curves, because of  
the need to fit a full public key (not just a fingerprint) in a 64  
character, case-insensitive DNS name?

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 18 May 2009 11:04:43 -0700

> effectively limit public key length?

You mean DNSCurve, not DNSSEC, right?  But, yes, it does.

> Thus, isn't it reliant on ECC and specific elliptic curves, because of the
> need to fit a full public key (not just a fingerprint) in a 64 character,
> case-insensitive DNS name?

Well, it needs to fit a full public key in a ~255 character
case-insensitive name.  Curve25519 public keys are small enough to fit
into a single label, so for simplicity, DNSCurve does just that.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 18 May 2009 11:13:31 -0700

> You mean DNSCurve, not DNSSEC, right?  But, yes, it does.

Yeah, thats what I meant.

> into a single label, so for simplicity, DNSCurve does just that.

But why use a name at all?

Since this uses changes on both authorities and resolvers, why not use  
the TKEY resource record?

I'm not a huge fan of DNSEC, but I'm even less a fan of DNSCurve,  
because the design seems based on a very primitive notion of DNS  
records, eg, by forcing the key encoding into a name rather than a  
real resource record.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 May 2009 11:17:25 -0700

At 10:43 AM -0700 5/18/09, Nicholas Weaver wrote:
>Thus, isn't it reliant on ECC and specific elliptic curves, because of the need to fit a full public key (not just a fingerprint) in a 64 character, case-insensitive DNS name?

It is reliant on ECC and *specific key sizes* to fit in a 64 character, case-insensitive DNS name. Any ECC key with a 256-bit key will work fine in the DNSCurve encoding scheme. For example, the coding would work fine with the NIST/NSA P256 curve. (And, for those who have lost their score chart, that's the equivalent of a 3048-bit RSA key.)

--Paul Hoffman, Director
--VPN Consortium

---

From: Alex Bligh <[email-masked]>
Date: Mon, 18 May 2009 19:44:08 +0100

--On 18 May 2009 11:17:25 -0700 Paul Hoffman <[email-masked]> wrote:

> It is reliant on ECC and *specific key sizes* to fit in a 64 character,
> case-insensitive DNS name. Any ECC key with a 256-bit key will work fine
> in the DNSCurve encoding scheme.

But, if I understand it, only one particular ECC scheme
is specified in DNSCurve (i.e. there is no algorithm agility) and
we don't have an IPR statement on it (or at least not in the IETF
required manner).

Also, if I understand it, any advantages to DNSCurve in raw crypto terms
could be duplicated by mandating equivalent ECC algorithms within
DNSSEC.

--
Alex Bligh

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 18 May 2009 11:47:50 -0700

> But why use a name at all?

You have to publish them somehow, and registrars already support
publishing them through names.

> Since this uses changes on both authorities and resolvers, why not use the
> TKEY resource record?

To meet the DNSCurve design goal of not requiring additional packets,
that would require modifying the DNS content servers to additionally
serve TKEY records with delegations.  Also, it would require modifying
web user interfaces to support entering TKEY records.

> I'm not a huge fan of DNSEC, but I'm even less a fan of DNSCurve, because
> the design seems based on a very primitive notion of DNS records, eg, by
> forcing the key encoding into a name rather than a real resource record.

Yeah, using new record types would be cleaner, but I think this is a
more pragmatic solution.

If this is a sticking point, I'd be happy to discuss ways to
distribute public keys without depending on the name server's name
(e.g., additional record types which would require content server and
admin dashboard changes).  However, to accelerate adoption, I think
the currently proposed encoding scheme has its merits.

---

From: Basil Dolmatov <[email-masked]>
Date: Mon, 18 May 2009 22:50:38 +0400

Paul Hoffman пишет:

For GOST 34.10-2001 it would work fine too.

dol@

archive:

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 18 May 2009 11:58:38 -0700

On Mon, May 18, 2009 at 11:44 AM, Alex Bligh <[email-masked]> wrote:
> is specified in DNSCurve (i.e. there is no algorithm agility)

Yes, the current DNSCurve spec only specifies Curve25519.  But like
I've said, there's no fundamental reason a future DNSCurve v2 spec
could be published using new algorithms.

> and

Dan has stated that he does not know of any patents that affect
Curve25519: http://cr.yp.to/ecdh/patents.html.  In his eSTREAM
submission, he made the same statements about Salsa20:
http://cr.yp.to/snuffle/ip.pdf  Off hand, I don't know of any
disclaimer about Poly1305, but I suspect he's willing to make the same
claim about it as well.

Additionally, there are optimized public domain implementations of
Curve25519, XSalsa20, and Poly1305 for many architectures in the NaCl
library at http://nacl.cace-project.eu/

> could be duplicated by mandating equivalent ECC algorithms within

That's not completely true.  Much of DNSCurve's benefits come from
being able to use secret-key cryptography for most normal work,
whereas DNSSEC has to use public-key cryptography for every
cryptographic operation.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 May 2009 12:09:40 -0700

>we don't have an IPR statement on it (or at least not in the IETF

This is why I was hammering to have a stable document (or, as we ended up with, a stable web site) that I could comment on. One of the primary questions for the *protocol* is whether different curves could be used. This WG might love the protocol but want to use a more heavily-reviewed curve such as P-256.

>could be duplicated by mandating equivalent ECC algorithms within

No, that's completely wrong. The DNSCurve protocol has completely different properties than DNSSEC. The DNSCurve protocol encrypts and authenticates all DNS queries and responses. DNSCurve queries and responses have cryptographic nonces to add integrity. The authoritative server is doing cryptographic calculations for every request (as compared to DNSSEC, where the authoritative server is just sending out pre-calculated responses).

--Paul Hoffman, Director
--VPN Consortium

---

From: Alex Bligh <[email-masked]>
Date: Mon, 18 May 2009 20:24:43 +0100

--On 18 May 2009 12:09:40 -0700 Paul Hoffman <[email-masked]> wrote:

> The authoritative server is doing cryptographic calculations for every
> request (as compared to DNSSEC, where the authoritative server is just
> sending out pre-calculated responses).

Ah -  I had (mis)remembered that the ECC algorithm itself was only used for
precalculated public key crypto in DNSCURVE.

--
Alex Bligh

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 18 May 2009 12:32:42 -0700

Aki and all,

  finnaly some truth telling.  Thank you Aki!  >:)

Aki Tuomi wrote:

> ¶‹§²æìr¸›zÇ§u©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš²Ø^™ë,j{[¡ÜšÈb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«s/==

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 18 May 2009 13:00:33 -0700

Andrew and all,

  Heaven and the ISC, not being necessarly mutually exclusive, forbid!  >:)

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 18 May 2009 13:02:32 -0700

Bill and all,

  Rather pursumptious my good fellow.  >:)

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 18 May 2009 13:14:09 -0700

Paul and all,

  In the real world, I/we fix what is broken to the best of our ability,
however limited or not that may be, and do not necessarily adhere to
ISC's advice or recommendations in doing so.  Nor do I/we consider
same as far as the IETF is concerned as in doing so would mean that
many broken DNS problems remain broken far too long and at far
too much exposure to the user unnecessarily, and in my view, irresponsibly
as well as on occasion dangerously.

  A few times in my recollection the ISC has been too far behind the
curve leaving users too exposed too long and far too dangerously  I can't
definitively say as to why...

Regards,

---

From: David Ulevitch <[email-masked]>
Date: Mon, 18 May 2009 22:16:13 -0700

On 5/18/09 6:49 AM, Andrew Sullivan wrote:

> an RFC.

That's not true.  As Bert pointed out, 4 & 5 are in use today.  The fact 
that IANA has no reasonable way to register them is not a problem with 
using EDNS0 Option Code's -- it's a problem with how IANA chooses to 
encumber registration of EDNS0 Option Code's for implementers and operators.

Really, the IANA ought to just mark EDNS0 Option Code 4 and 5 as 
registered for their respective uses and create a sane policy for future 
registrations.

IANA makes registering other, far more scarce, resources much easier and 
EDNS0 Option Code's should be no different.  At the end of the day, 
making the the process easy fosters innovation and development in a way 
that promotes interoperability and stability.

-David

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 May 2009 17:05:30 +0200

On Mon, May 18, 2009 at 10:56:53AM -0400,
 Ólafur Guðmundsson /DNSEXT chair <[email-masked]> wrote 
 a message of 62 lines which said:

> RFC2671 says "Published RFC" as allocation mechanism for EDNS0
> options (see last paragraph in section 7).

Yes, not "Standards Track RFC". The IANA registry says "Specification
Required" and this is the only error I find, it should be "RFC
Required" (the list of possible policies is in RFC 5226, section 4.1).

> Any individual RFC will be send to DNSEXT for comment by the IESG, thus

For comment, yes, it is reasonable, but it does not mean the comments
are binding.

> I'm hoping that the WG will turn its attention to work on
> RFC2671-bis and in that context figure out what the right rule is
> and specify it.

Why not, but in the mean time, the rules are set by RFC 2671 and it is
not up to the WG or its chairs or IANA to override them. The situation
is clear: any published RFC is sufficient to get an EDNS option
code. May be it will be different in the future, if a 2671bis is
published but, today, 2671 is the rule.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 May 2009 17:11:25 +0200

On Mon, May 18, 2009 at 10:16:13PM -0700,
 David Ulevitch <[email-masked]> wrote 
 a message of 20 lines which said:

> it's a problem with how IANA chooses to encumber registration of
> EDNS0 Option Code's for implementers and operators.

It's not IANA. The rules of *any* IANA registry are not set by IANA
but, for most of them, by the IETF, through RFC "IANA considerations"
section (see RFC 5226).

So, the rules allow registration of an EDNS option code, providing a
RFC is published (it can be an Experimental one).

> registered

They cannot, until a RFC is published (that's what RFC 2671 says, in
its "IANA considerations" section).

> IANA makes registering other, far more scarce, resources much easier
> and EDNS0 Option Code's should be no different.  At the end of the
> day, making the the process easy fosters innovation and development
> in a way that promotes interoperability and stability.

It's true that attempts to discourage registration of EDNS code points
are a problem and a risk for the quality of the registry (if people
start to pick EDNS option codes at random and just use it), but, as I
said, it is not IANA's fault. My suggestion would be to publish
EDNS-ping as Experimental or Informational and then IANA could not
refuse an official option code.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 19 May 2009 16:01:09 +0000

> Date: Tue, 19 May 2009 17:11:25 +0200
> From: Stephane Bortzmeyer <[email-masked]>
> ...

note that the iana considerations section of rfc 2671 came to the ID author
from the WG chairs as "the common wisdom of that moment".  it was not
intended to be prescriptive in the sense that doing it some other way would
cause the protocol itself to malfunction.  if there's a reason to do it
some other way then we should make a change.

> are a problem and a risk for the quality of the registry (if people start
> to pick EDNS option codes at random and just use it), but, as I said, it
> is not IANA's fault. My suggestion would be to publish EDNS-ping as
> Experimental or Informational and then IANA could not refuse an official
> option code.

that seems to be an easy way forward.  (SRV is still "experimental", FWIW.)

---

From: David Ulevitch <[email-masked]>
Date: Tue, 19 May 2009 09:06:23 -0700

On 5/19/09 9:01 AM, Paul Vixie wrote:
>> From: Stephane Bortzmeyer<[email-masked]>
>

Yep, that's a good plan forward.

Thanks,
David

---

From: Kim Davies <[email-masked]>
Date: Tue, 19 May 2009 09:17:44 -0700

> that promotes interoperability and stability.

To re-iterate the take away from Stephane's analysis < IANA does not decide
the registration policies of protocol registries. We do what we are advised
by the IETF standards process. With regards to maintaining IETF protocol
registries, IANA has very little latitude in how it interprets registry
maintenance requirements. Whenever there is any doubt, the IESG < or its
appointed subject matter experts < make the decisions.

With kindest regards,

Kim Davies
Internet Assigned Numbers Authority

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 May 2009 10:40:20 -0700

Hopefully, you are still following the discussion.

>DNSEXT WG can authorize the issue of such an EDNS option code from IANA.

As it turns out, that statement is correct but insufficient. As has been pointed out, all that is needed for an EDNS option code is an RFC.

You can submit an RFC as an *independent submission* directly to the RFC Editor. Such submissions do not come to the WG unless the Area Directors consider the document an "end run" against WG work. Clearly, the WG is not doing work on EDNS pings, so I doubt that would be the case here.

The result of independent submission (as compared to WG or individual submission) is always either and Experimental or Informational RFC, never a standards track RFC. Again, that is fine for getting an EDNS option, and the practical difference between the two is illusory at best.

Given that there is already deployment of the protocol, please consider revising your draft to clarify the areas that have been exposed so far, and then consider sending it to the RFC Editor as an independent submission as an Experimental RFC.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 19 May 2009 12:31:27 -0700

> codes anymore since they are 'polluted'.

I currently have EDNS option code 4 "on hold" with IANA, pending me  
finding the time to write the Internet Draft describing it. I  
described in in email last year (Subject "EDNS0 Option Code", Sun, 16  
Nov 2008) but IANA wants more than just an email :-) It's been in  
shipping Apple products for a while; I hope to get the Internet Draft  
submitted in the next couple of weeks.

What is code 5 being used for?

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 May 2009 21:42:37 +0200

On Tue, May 19, 2009 at 12:31:27PM -0700,
 Stuart Cheshire <[email-masked]> wrote 

> What is code 5 being used for?

#define DNS_OPT_PING            0x0005          /*%< PING opt code */

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 May 2009 13:38:11 -0700

>What is code 5 being used for?

The same thing that started this thread: draft-hubert-ulevitch-edns-ping-01.txt

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 May 2009 11:40:24 +1000

> that seems to be an easy way forward.  (SRV is still "experimental", FWIW.)

	Actually it is Standards Track as of RFC 2782.  When it was initially
	proposed it was experimental (RFC 2052).

Network Working Group                                     A. Gulbrandsen
Request for Comments: 2782                            Troll Technologies
Obsoletes: 2052                                                 P. Vixie
Category: Standards Track                   Internet Software Consortium
                                                               L. Esibov
                                                         Microsoft Corp.
                                                           February 2000

       A DNS RR for specifying the location of services (DNS SRV)

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 20 May 2009 08:12:39 -0500

> oubt that would be the case here.

That's the theory.

In practice, the independent-submission-through-the-RFC-editor route has 
a couple of pitfalls. (Without these impediments, I guess there would be 
much more RFCs originating from protocol developers who feel like Bert 
indicated.)

First, the RFC editor is a document editor, so it enforces *some* 
editorial rules, based on volunteer reviewers. This is not a 
time-limited activity since these volunteers are usually heavily 
involved in regular IETF activities.

Second, the interface between the RFC editor function (as an independent 
editor) and the IETF activities is perhaps not as clean cut as indicated 
above (whether the proposal is "an 'end run' against WG work"). The evil 
is in the details.

And beyond this, the activity reports from the RFC editor function (I'm 
not even referring to accountability) are such that it is impossible to 
identify corner cases (i.e. we miss the the age distribution of 
submissions in the queue according to the stage in the submission 
progress diagram). So much for transparency.

So, in short, there is the theoretical publication route that Bert is 
invited to investigate. In practice, it looks like little more than a 
means of taking the guilt out of DNSEXT WG participants for Bert desertion.

Although I am a supporter of DNSSEC deployment, the Bert's perpective on 
DNS security (including his DNSSEC skepticism) has consistently been at 
once useful, well supported, and expressed in an elegant language. 
Thanks to Mr. Hubert.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 May 2009 07:57:45 -0700

>>oubt that would be the case here.

...that happens nearly all the time. Please don't expect perfection here (or anywhere else...).

>In practice, the independent-submission-through-the-RFC-editor route has a couple of pitfalls. (Without these impediments, I guess there would be much more RFCs originating from protocol developers who feel like Bert indicated.)

We disagree here. Many protocol developers don't know about the independent submission stream. That should change within the next year.

>First, the RFC editor is a document editor, so it enforces *some* editorial rules, based on volunteer reviewers. This is not a time-limited activity since these volunteers are usually heavily involved in regular IETF activities.

For documents with no questions, the review process usually goes quickly, faster than the normal IETF process. For documents with questions, of course, it can slow down.

>Second, the interface between the RFC editor function (as an independent editor) and the IETF activities is perhaps not as clean cut as indicated above (whether the proposal is "an 'end run' against WG work"). The evil is in the details.

This feels like FUD. I have looked at the process, and it almost always works. Do you have examples in the DNS space where it has failed?

>And beyond this, the activity reports from the RFC editor function (I'm not even referring to accountability) are such that it is impossible to identify corner cases (i.e. we miss the the age distribution of submissions in the queue according to the stage in the submission progress diagram). So much for transparency.

True for now. It will change at the end of this year. <boring IETF process wonking elided>

>So, in short, there is the theoretical publication route that Bert is invited to investigate.

No, there is an *actual* publication route that Bert and others are invited to investigate.

>In practice, it looks like little more than a means of taking the guilt out of DNSEXT WG participants for Bert desertion.

Poppycock. You are attributing motives to me that are absurd in the extreme.

>Although I am a supporter of DNSSEC deployment, the Bert's perpective on DNS security (including his DNSSEC skepticism) has consistently been at once useful, well supported, and expressed in an elegant language. Thanks to Mr. Hubert.

My message was unrelated to either DNSSEC or his perspective on DNS security. The independent submission route is just as useful for good ideas as it is for bad ones. Its purpose is quite different than the purpose of the WG process.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 May 2009 10:18:08 +1000

> This feels like FUD. I have looked at the process, and it almost always
> works. Do you have examples in the DNS space where it has failed?

	RFC 4431 ( DLV record) was a independent submission that
	would have been more controversial than EDNS-PING if it had
	been taken to the WG.  The RFC Editor's expert rejected it
	on review*.  I then found a AD to sponsor it and then I
	needed to explain to the IESG that this was actually only
	a mechanism to publish a collection of trust anchors and
	such collections were a expected part of the DNSSEC operations.

	Mark

	* there is no appeal process for this decision.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]