Subject: [dnsext] we need an IAB statement on Secure DNS

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Apr 2009 18:20:04 +0000

Chairs, please invoke some kind of review process by the IAB so that we can
get some direction on Secure DNS.  We've got TSIG and TKEY and GSS TSIG and
SIG(0), and we've got DNSSEC, and we've got SPR.  To me that's enough, it's
a complete system supporting both end to end (DNSSEC) and hop by hop (SPR,
TSIG, or or TKEY+SIG(0)) security.  However, the engineering mindset that
dominates this working group is now way into its customary overshoot
(DNS-0x20, EDNS PING, cookies) and there is at least one major
non-working-group project (dnscurve) in the works.

The effect of this overshoot is to dilute interest in existing Secure DNS
technologies.  Fence sitters can say "well clearly the wheels are still
turning, let's see how it shakes out before we make any investment."  This
fulfills the prophecy of these overshooters ("DNSSEC is too hard to deploy,
so clearly we need to continue investigating other solutions.")  What the
Secure DNS effort needs is some nontechnical governance.  I'd like the IAB
to weigh in on the question: "Is Secure DNS complete?" so that the working
group can know a priori and on nontechnical grounds whether to continue
accepting new work items in this area.

(Note that I have personally quashed three mindblowingly better solutions
to things that DNSSEC got wrong, because at some point you have to cut and
print.)  (Also note that I've been working on Secure DNS for close to 15
years now, and the apparent endlessness of it is starting to get on my
nerves, and is NOT a simple artifact of protocol quality, which is why I'm
indicting the engineering mindset prevalant in the DNSEXT working group.)

Paul Vixie

--
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: Edward Lewis <[email-masked]>
Date: Thu, 23 Apr 2009 15:07:10 -0400

At 18:20 +0000 4/23/09, Paul Vixie wrote:
>Chairs, please invoke some kind of review process by the IAB

Yes, Chairs, please do.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Nicholas Weaver <[email-masked]>
Date: Thu, 23 Apr 2009 12:47:48 -0700

> non-working-group project (dnscurve) in the works.

Actually, I'd argue differently, as someone who wants a secure  
Internet, not "Secure DNS":

Hop by hop cryptographic protection is unnecessary and unuseful for  
general purposes (as opposed to distributing zone files or similar  
within a group of systems, which is what TSIG is for, but an SSH  
tunnel works just as well...).

Hop by hop protections only need to protect against out-of-path  
attackers, as the one key in-path attacker is the recursive resolver  
itself, which hop to hop protections do not defend against.

Yet hop-by-hop cryptographic systems have all the problems otherwise  
associated with cryptographic systems, including key management,  
changes to authority management, etc etc etc.

Thus I believe "Secure" DNS should consider...

A)  Hop-by-hop protection against out-of-path attackers ONLY.  Such  
protection should be deployable with changes to only the code base of  
the authorities and/or resolvers, NOT the management of the systems.

This is why 0x20 and EDNS0 Ping are so attractive, and why I believe  
that TKEY+SIG(0), dnscurve, etc, are just fine thrown in the trash can  
for general use.

In fact, general cryptographic protections for hop-by-hop data for DNS  
are WORSE than useless: they provide an illusion of "security",  
without providing a significant increase in system security in most  
cases.  [1]

B)  End-to-end cryptographic protection, validated by the END HOST  
(not the recursive resolver), targeted at authenticating Name->data  
mappings for application use (mostly for keys), not Name->Address  
mappings [2].

A is 0x20 and EDNS0-ping.  B is DNSSEC with a better API and some  
usage conventions.

> indicting the engineering mindset prevalant in the DNSEXT working  

And at the same time, I'm not willing to sacrifice achievable and  
deployable protection against out-of-path adversaries today for the  
hope of protection against in-path adversaries tomorrow.

0x20 and EDNS0-ping should not be obstacles for DNSSEC deployment, and  
if they are viewed as obstacles by some, this is reflecting poorly on  
DNSSEC's value proposition.  DNSSEC has had years to try to win  
adoption in the market.

So I'd personally state:

End to end integrity for name->data mappings is the goal.  DNSSEC, if  
deployed, provides this.

Since we are obviously lacking DEPLOYED end-to-end integrity  
mechanisms for DNS, it is important that we ensure hop-by-hop  
protection against out-of-path adversaries with protection of 1 in  
2^40 (minimum), 1 in 2^64 (ideal), with changes that are code-only: no  
changes to authority or resolver management but only the code running  
on those servers.

So yes, by all means do a review process.

But such a review should include use cases and deployability concerns.

It should not be "If this all was deployed.." but also
"Why isn't the existing stuff deployed?"
and
"Should we do something less if it can be deployed today?"

[1] In the same boat goes DNSSEC validation on the recursive  
resolver.  Validating DNSSEC at the recursive resolver offers  
effectively NO security benefits, and IMO, that model should be  
discarded.

If I'm able to do in-path attacks on the DNS packets between the  
authority and the recursive resolver, I'm probably able to do the same  
attack on the user's TCP connections (see http://lists.immunitysec.com/pipermail/dailydave/2009-March/005601.html 
  )

[2] I can always get "as secure as my network is for the data itself"  
name->address mappings by simply generating my own iterative request.   
And the externality of such behavior doesn't affect me, just the  
authorities.

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 23 Apr 2009 13:27:19 -0700

On Thu, Apr 23, 2009 at 12:47 PM, Nicholas Weaver
<[email-masked]> wrote:
> A)  Hop-by-hop protection against out-of-path attackers ONLY.

For my benefit at least, would you mind clarifying exactly what you
mean by "out-of-path attackers"?  In particular, are routers that just
forward IP packets along the path from the source to the destination
considered "out-of-path" or not?

E.g., if I run "traceroute ns1.google.com" from my computer right now,
I see there are 14 routers between my computer and ns1.google.com.  If
I then run "dig www.google.com @ns1.google.com" and one of these 14
routers were to act maliciously, would they be considered
"out-of-path" or not?

(I ask only because I've found the use of "hop-by-hop" on this mailing
list to mean "from-DNS-application-to-next-DNS-application" rather
than "from-IP-host-to-next-IP-host" confusing at times, and it might
alter the interpretation of "out-of-path".)

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Apr 2009 16:40:48 -0400

No hat.

On Thu, Apr 23, 2009 at 12:47:48PM -0700, Nicholas Weaver wrote:

> deployable protection against out-of-path adversaries today for the hope 
> of protection against in-path adversaries tomorrow.

It seems to me that the proposed technologies are not "achievable and
deployable" "today", because the techniques aren't yet standardized and
we don't have actually shipping, tested-interoperable code
implementing all of it.  I think it is important for the purposes of
this discussion to remember that we have a very hard time getting
adequate review in this WG, and that difficulty will surely apply to
these drafts and techniques as to others.  Moreover, we have to
realise that even if we like them, getting these techniques through
the RFC process may run into roadblocks when we get to the IETF last
call.  There will be security people who ask why we are recommending a
half-measure when the full measure is already standardized and into
the deployment phase.  That's not a silly question to ask, in my opinion.

> DNSSEC's value proposition.  DNSSEC has had years to try to win adoption 
> in the market.

I believe that, whether we like it or not, the relevant community is
not those in the IETF, but those who regard the DNS as a massive
headache, impossible to understand, that occasionally changes in
mysterious and frustrating ways.  If that community hears, "The DNS
protocol people are still working on it to improve its security," the
message is likely to be interpreted as, "Do not deploy DNSSEC just
now, because the DNS weenies are still figuring out what to do about
it."

This is all just my personal opinion.

> Since we are obviously lacking DEPLOYED end-to-end integrity mechanisms 
> for DNS, it is important that we ensure hop-by-hop protection against 
> out-of-path adversaries with protection of 1 in 2^40 (minimum), 1 in 2^64 
> (ideal), with changes that are code-only: no changes to authority or 
> resolver management but only the code running on those servers.

I have doubts that large DNS operators, when confronted with
as-yet-unknown changes to their traffic patterns due to these
alternative techniques, will really regard this as a code-only change.
In places I have worked with operations on any scale, extensions to
any protocol automatically entailed changes to operations.  At the
very least, I'd bet a number of monitors in some sites would have to
be adjusted.  I am therefore quite sceptical of claims that the
proposed techniques are a code-only change.  We hear one large
operator expressing doubts also; it would be valuable to me to have
informed input from other operators as to whether they regard the
proposed techniques (to the extent they are completely defined) as a
code-only change, or whether they think the techniques might impose
operations changes too.

Again, just my personal opinion.

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 23 Apr 2009 13:48:11 -0700

> considered "out-of-path" or not?

An out of path attacker is not able to directly observe the DNS  
request or reply, but may know that such a request exists because the  
attacker caused the request to be generated.

An in-path adversary is directly able to observe the packets.

> routers were to act maliciously, would they be considered

That would be an in-path adversary.

> alter the interpretation of "out-of-path".)

The reason why I care about the distinction:

In-path adversaries are the killer, and the attacker's goal is to  
become an in-path adversary on the final application:

But if the final application is not end-to-end seceure, who cares if  
the name->address mapping is correct when the already in-path  
adversary can directly attack the final application?

And if the final application IS end-to-end secure, it never really  
trusted the name->address mapping, because it never trusted the name- 
 >address mapping anymore than it trusted the network (namely, not at  
all).

But with the HUGE exception of the recursive resolver itself being an  
adversary, an in-path adversary for the DNS packets is also likely to  
be an in-path adversary for the data packets.

EG, on your example, if I traceroute to ns1.google.com and www.google.com 
, the traceroutes only deviate within the final network owned by  
Google, in the 12th hop.  Up until that point, the packets follow  
exactly the same path.

This is why I believe it is sufficient for hop by hop defenses to only  
focus on out-of-path adversaries, because focusing on in-path  
adversaries misses the real problem: the applications themselves are  
insecure against in-path adversaries yet all hop by hop protections  
can't protect against the recursive resolver itself, which has proven  
itself to be an adversarial party.

And if the DNS community goes through all the hastles involved with  
cryptographic keying, the resulting system should be able to resist  
ALL in-path adversaries, not "All in path adversaries except the one  
that counts: the recursive resolver".

DNSSEC can.  Any hop-by-hop mechanism can not.

---

From: "Aki Tuomi" <[email-masked]>
Date: Thu, 23 Apr 2009 23:27:18 +0300

>-----Original Message-----
>From: [email-masked]
[mailto:owner->[email-masked]] On Behalf Of Paul Vixie
>Sent: Thursday, April 23, 2009 9:20 PM
>To: [email-masked]
>Subject: [dnsext] we need an IAB statement on Secure DNS
>

Dear Paul,

Perhaps people do not want Secure DNS; they want secure enough internet.
In my personal opinion, DNSSEC is completely overkill solution to this
problem, hard to maintain and functions as job security instrument. 

EDNS, 0x20 etc. provide simple way of gaining sufficient security and
would solve the major issues introduced by Kaminsky. I fail to see the
rationale of taking DNSSEC into use. It would increase the amount of
queries, amount of CPU power spent on calculating verifications. Yet in
the same breath you complain other solutions spending intoleratable
amount of bytes to gain the same practical solution. 

I sympathize that you've spent 15+ years of time to get this thing off
the ground, and I feel your frustration for your solution not being
embraced globally. But, for all I can see, is that DNSSEC et al are just
too heavy and overcomplicated solution to this problem. Perhaps more
focus should be placed into "secure internet" than "secure DNS", which
seems to be the trend now. In my opinion, DNSSEC and others are the
overshoot.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 23 Apr 2009 14:16:03 -0700

On Apr 23, 2009, at 1:40 PM, Andrew Sullivan wrote:
>> mechanisms

I would say that this HAS been validated for 0x20:  The widespread  
survey of Dagon et al for the CCS paper, plus manual intervention in  
the one high-profile non-deployer (google is now 0x20 compliant),  
shows that 0x20 is indeed a resolver only, code only change.

A similar survey should be conducted for EDNS0-ping, (i've suggested  
as much to the authors) to see how the existing authority population,  
already deployed, will react.

It also appears plausible to do a survey of authority load:  Send a  
short burst of queries to an authority, should hopefully find any  
bottlenecks in the network and the capacity of those bottlenecks.

You can indeed validate many such proposed changes in this manner.

---

From: bert hubert <[email-masked]>
Date: Thu, 23 Apr 2009 23:36:18 +0200

On Thu, Apr 23, 2009 at 11:16 PM, Nicholas Weaver
<[email-masked]> wrote:
> A similar survey should be conducted for EDNS0-ping, (i've suggested as much
> to the authors) to see how the existing authority population, already
> deployed, will react.

This is in progress. I've just contacted the last major source of
EDNS0 problems, and I've been assured they'll look into it.

In addition, it turned out to be possible to work around the F5
problem from the resolver side.

I am actively replaying the billions of packets various access
providers have donated, and comparing the pre- and post EDNS-ping
results. I will post these soon.

> It also appears plausible to do a survey of authority load:  Send a short
> burst of queries to an authority, should hopefully find any bottlenecks in
> the network and the capacity of those bottlenecks.

The overhead of an EDNS-PING is 8 bytes btw.

    Bert

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 23 Apr 2009 14:38:13 -0700

> results. I will post these soon.

Excellent.

>> short

What is the fallback position, however?  EDNS-PING may be small, but  
when an authority does not support it, then what?

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 24 Apr 2009 06:57:23 +0900

Paul Vixie wrote:

> TSIG, or or TKEY+SIG(0)) security.

Wrong.

DNSSEC is not secure end to end and is useless.

DNSSEC is secure, at most, zone hop by zone hop, which is as secure as
plain old DNS with NZ hop by NS hop security.

							Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Apr 2009 17:09:55 -0500

> adversary can directly attack the final application?

So suppose I'm in-path between you and some portion of the DNS, and I  
succeed in convincing you that www.bankofmordor.com is at  
123.45.67.89.   Even though I don't control the path between you and  
bankofmordor.com, I can still get your traffic to bankofmordor.com,  
because I've managed to control your DNS.   Just because DNS traffic  
goes through a suborned path, does not mean that all traffic goes  
through a suborned path.   And vice versa.   So it makes sense to  
protect both.

---

From: bert hubert <[email-masked]>
Date: Fri, 24 Apr 2009 00:14:47 +0200

>> results. I will post these soon.

People might notice - my testing from one server replays the traffic
in realtime as recorded from several million customers.

> What is the fallback position, however?  EDNS-PING may be small, but when an
> authority does not support it, then what?

It is my personal opinion that the fallback position is entirely up to
the implementor. Conceivably, you might not even have one. If you do
the math, it is not overly easy to spoof a suitably source port
randomized server - see
http://blog.netherlabs.nl/articles/2008/08/05/calculating-the-chance-of-spoofing-an-agile-source-port-randomised-resolver

    Bert

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 23 Apr 2009 16:37:37 -0700

Nicholas and all,

  Reluctantly I agree with your view Nick.  But I am sure you
know that sooner rather than later governmental folks will
question such an approach.

> And the externality of such behavior doesn't affect me, just the

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: Paul Vixie <[email-masked]>
Date: Fri, 24 Apr 2009 01:03:36 +0000

> Date: Thu, 23 Apr 2009 23:27:18 +0300
> From: "Aki Tuomi" <[email-masked]>
> 
> problem, hard to maintain and functions as job security instrument.  ...

it may be as you say.  let's find out.  this working group was rechartered
some years ago to take on the remaining work of the old DNSSEC WG, among
which was to finish defining DNSSEC and making it deployable.  now that i
have seen it take more than a decade to make IPv6 market-ready and so far
one and a half decades to make DNSSEC market-ready, i understand current
events in the following context.

1. almost everybody is bored stiff by the never-ending secure dns work.
2. almost nobody remembers what we're doing or why, or signed up for it.
3. almost everybody can think of better ways to do some/all of Secure DNS.
4. many people have smaller needs than what the Secure DNS vision addresses.
5. cool new technology like elliptic curve looks a lot more interesting.

i mention these contextual elements in case it seems like i don't "get it."
but, Secure DNS is a multigenerational project -- the engineers who started
it will in many cases retire or take a different project before it's
finished.  that requires some discipline.  i'm not saying that folks who
want a secure internet shouldn't have one!  i am saying that "we" started
this and "we" should either finish it or abandon it BEFORE we start a whole
bunch of potentially competing/overlapping work.

so i'm calling for some adult supervision to help get us / keep us on track.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Apr 2009 22:24:38 -0500

On Apr 23, 2009, at 9:00 PM, Nicholas Weaver wrote:
> The cases where you are on the naming path but not the data path,
> EXCEPT when you control the recursive resolver itself, are fairly far-
> between.

First of all, I don't have to suborn your cache.   I can suborn one of  
the servers that publishes .COM.   I can then attack selectively, only  
sending wrong data to certain high-value IP addresses, only for  
certain high-value NS records.   I can send correct data to all  
others, so that the fact that I've got control over .COM is difficult  
to detect, even if you detect bad data in your cache.   Are you  
prepared to say that this attack is impossible, or even unlikely?    
Even after the recent news about how criminals have been able to get  
ATM card PIN data using a very, very similar attack?   I'm sorry, but  
that's naive.

Secondly, resolvers often run on machines that can be rooted.   It may  
be relatively easy, or relatively hard, to root one of these machines,  
as compared to gaining control over your ISP's routing infrastructure,  
but I think it's (again, forgive me) naive to suggest that there will  
not be situations where suborning your cache is easier or more cost- 
effective than suborning your routing infrastructure.   Indeed, I  
would argue that this is very likely to be the case, since the IP  
address of your cache is public knowledge, and you probably have fewer  
caches than routers.

Forgive me for being obstinate about this - you sound very convincing  
with your on-path versus off-path rationalizations.   But on closer  
analysis, what you are really saying is that despite the alarmingly  
competent and successful attacks we've seen recently in the form of  
things like ATM PIN siphoning and the the recent analysis of the  
Conficker.C virus, it's still okay to use a low-effort, less-is-more  
approach to preventing attacks on the DNS.

I don't think you want to become famous for championing this idea.

---

From: "Aki Tuomi" <[email-masked]>
Date: Fri, 24 Apr 2009 08:51:04 +0300

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Vixie
> Sent: Friday, April 24, 2009 4:04 AM
> To: Aki Tuomi
> Cc: [email-masked]
> Subject: Re: [dnsext] we need an IAB statement on Secure DNS
> 

First of all, I agree, let's find out. I am all for asking the chairs to evaluate. The motivation behind my initial email was the perceived attitude in your email as you blatantly stated that "DNNSEC good, others bad". This is indeed the message you sent by stating that the 0x20, EDNS PING, DNSCurve etc. are "customary overshooting". It would be courteous to at least acknowledge that these are serious attempts, and not just some wishy washy engineering attempt that should be regarded as no more than mere noise. As in, you could have extended a courtesy of acknowledging that these are seriously considerable solutions. 

But I agree. Some adult supervision seems to be necessary to calm down both parties, but I just hope you'd show some courtesy and respect to the other suggested solutions, instead of labeling them as noise. 

---
Aki Tuomi
������r��zǧu���Ơz�'jg���iz�+z����)�'�~���+a����n�˛���m�jȧ�W��w���^��,j�{[�ܚ��b��m�����"z����l�v�y�覗��

---

From: [email-masked]
Date: Fri, 24 Apr 2009 10:47:16 +0000

I'm not persuaded that we need the IAB to "declare victory and move on".
There is a defined process to move protocol work to full standard and while
that happens, I do not think it reasonable or practical to declare a 
moratorium on new ideas, proof of concept work, or technological advances.

I'm pretty sure I want to see the ideas that folks have brought forward, 
discussed, documented, and tried out.  Thats my impression of what the IETF
should be doing...  for -ALL- the ideas, not just the ones that happen to fit
some current thinking on what is marketable, commercial, or even deployable on
an interplanetary scale.

What I am seeing is an over-agressive winnowing of ideas on how things might be
done better/differently in favor of some fairly narrowly focused - "we have to 
have this stamped with the IETF imprinture so we can sell it" protocols.

Please do not attempt to stiffle inovation just so the operational community
can catch up to the protocols that are already defined.   If the defined protocols
are good enough, have intrinsic value, they will be adopted and can move along
the standards track to full IETF standards.  If they are not, then we really 
ought to allow alternatives to emerge and take their place.

If the 15+years of DNSSEC development turns out to be non-operationally maintainable
(again)... then i'm willing to consider cutting my losses and moving on to a more
realistic, attainable goal...  or find other ways to deploy naming integrity and
authenticity in a more grass-roots fashion than the rather cumbersome choices that
we currently face w/ DNSSEC deployment (and no, a signed root, or widescale adoption
of DLV is not the paneca that one might think)

So - I'm not in favor of the IAB making any sort of pronouncement about DNSSEC, other
than to move it along the IETF standards track.

--bill

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 24 Apr 2009 07:00:44 -0500

Dear all:

I guess the important portion from the Paul's post below is "I'd like
the IAB to weigh in on the question: 'Is Secure DNS complete?'"

Otherwise, Paul wrote a DNSSEC deployment promotion message. I have a
few issues with the way Paul addresses the community. See inline below.

> non-working-group project (dnscurve) in the works.

So far, not so bad. Using proper English capitalization is good
salesmanship! But perhaps this delves too much into technical details.
Indeed, this paragraph triggered further technical discussions. A basic 
rule of salesmanship is to avoid creating doubt and/or confusion.

> print.)

I will neither ask what are these "better solutions" nor question
whether "things that DNSSEC got wrong" are actually detrimental to the
overall scheme.

 From the above statement, I become puzzled about the confidence that 
IETF outsiders may lose in the IETF processes that brought the DNSSEC 
specifications. I mean a) the IETF process is collective engineering 
based on consensus, b) Paul, a well-known DNS expert, claims *personal* 
attribution of three unspecified "things that DNSSEC got wrong," c) 
perhaps the IETF process that led to the DNSSEC specifications was 
overwhelmingly influenced by Paul.

Philosophically, DNSSEC being a security solution, there is a "security
assurance requirement" (à la Common Criteria), according to which a
secure system design must not only be sound, it must have been designed
by a process about which soundness assertions must be validated.

I hope Paul, if asked by someone more influential than merely myself,
can bring pointers to a significant IETF consensus in each of the three
alluded instances alluded above, so the lack of confidence in the
soundness of IETF process does not turn into lack of "security
assurance" in the DNSSEC solution. So, some integrity confidence in the
IETF process can be salvaged despite the above statement.

> (Also note that I've been working on Secure DNS for close to 15

As I understand it, DNSSEC engineering is essentially done, other
elements of Secure DNS don't require the same level of deployment
coordination as required by DNSSEC, and hence the endlessness of its
starting now lies outside of the IETF and the IAB.

And I doubt DNSEXT working group volunteers are indebted towards Paul to
the point where they should abstain from bringing forward new ideas.
They don't *have to* keep quiet while Paul's ideas are being adopted.

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: Stefan Schmidt <[email-masked]>
Date: Fri, 24 Apr 2009 14:43:20 +0200

> moratorium on new ideas, proof of concept work, or technological advances.
...

I would have written about the same but probably with a worse choice of words,
so thank you Bill for beeing faster.

> than to move it along the IETF standards track.

I concur with everything Bill wrote in his previous mail, so all there is left
for me to say now on this issue is: Me too.

	Stefan
-- 
"And how would we hide a 30,000-ton submarine?"
"You hide a submarine by sinking it," Painter said angrily.
"They're designed to do that, you know."
- Ryan and Adm. Painter, "The Hunt for Red October" (Tom Clancy)

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 24 Apr 2009 22:02:29 +0900

[email-masked] wrote:

> There is a defined process to move protocol work to full standard

The problem is not on moving on but on not moving on.

There is no way to delcare some protocol hopeless in IETF as long as
some people are actively support the protocol in related WGs.

							Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Fri, 24 Apr 2009 16:19:48 +0000

> Date: Fri, 24 Apr 2009 08:51:04 +0300
> First of all, I agree, let's find out. I am all for asking the chairs to
> evaluate.  The motivation behind my initial email was the perceived
> attitude in your email as you blatantly stated that "DNNSEC good, others
> bad".

"having a plan is good, shooting into the dark is bad."  if IETF wants to
abandon DNSSEC and/or redefine the problem explicitly, i might hate the new
plan but i'd be happy knowing that there was, at least, a plan.

> This is indeed the message you sent by stating that the 0x20, EDNS PING,
> DNSCurve etc. are "customary overshooting".  It would be courteous to at
> least acknowledge that these are serious attempts, and not just some
> wishy washy engineering attempt that should be regarded as no more than
> mere noise. As in, you could have extended a courtesy of acknowledging
> that these are seriously considerable solutions.

it was never my intent to hurt your feelings, and i'm sorry if i've done so.
as the co-proponent of DNS-0x20 and the author of that Internet-Draft, i'm
throwing myself down the same mineshaft: this working group is thrashing now.

> But I agree. Some adult supervision seems to be necessary to calm down
> both parties, but I just hope you'd show some courtesy and respect to the
> other suggested solutions, instead of labeling them as noise.

i can dial down the invective, and i will; thanks for your guidance on that.

however, i want you (not just Aki but everyone) to consider that at some
point IETF made a choice to develop what is now IPv6, and by doing so, they
(we?) explicitly rejected more work on the competing alternatives.  this
was not done to conserve effort -- indeed, the people who wanted to work on
the competing alternatives did by and large not "switch sides", they just
gave up found a different topic to work in.  rather, this was done in order
to serve the community with a clear IPv4 migration message.  good or bad,
love it or hate it, we all know that the future is IPv6.

we need a plan for Secure DNS, and we do have one: the plan of record is
DNSSEC end to end, SPR hop by hop.  if it's time to scrap that plan and
start over then that's what IETF should do.  if on the other hand it's time
to focus on the missing pieces and only admit new work items to this WG
that fill in such missing pieces (for example, defining a use profile for
TKEY-over-TCP and either TSIG or SIG(0) for hop-by-hop, or adding DNS-0x20
or EDNS-PING to hop-by-hop) then that's what we should do.  if on the other
hand time has moved on and DNSCurve is the way we should go, then we should
go that way and abandon everything else.

my indictment of the engineering mindset yesterday (and continuing) is not
that engineers are evil or incompetent by nature (recall that i wrote the
I-D for DNS-0x20) but rather than the engineering mindset, running rampant,
is not a good way to get a product completed and out the door and into
customer hands.  "put all the boats in the water and see what floats best
or catches the best wind" really just means "let's wait for microsoft and
cisco and verisign to decide what they want to do."  let's NOT do it that way.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 24 Apr 2009 16:07:58 -0700

Stefan, Bill, and all,

  I also concur fully!

Regards,