Subject: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ?

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Wed, 22 Apr 2009 11:07:09 -0400

The WG has received a request to adopt this as a work item.
See draft:
http://www.ietf.org/internet-drafts/draft-hubert-ulevitch-edns-ping-01.txt

The current document falls under the "further Forgery Resilience" clause in
our charter.

If we are going to debate the merits of this proposal, the chairs think
it is going to beneficial to all that we have a common understanding of
what the  proposal is about and its implications.

<feel free to selectively answer the questions below>

Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ?

Q1.5: Is the cost of Ping caused by it being the first/second option to be
       standardized or will we have to suffer the same cost when options are
       added in the future ?

Q2: Does ENDS0 Ping offer additional protection to
         "Pre-DNSSEC DNS"   OR  "both DNSSEC and Pre-DNSSEC" ?

Q3: Are the benefits of ENDS0 Ping realized incrementally with deployment or
         only when the majority of code bases are deployed?

Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or the 
producer?

Q4: Will ENDS0 Ping delay/prevent DNSSEC deployment?  (explain)

Q5: Does ENDS0 Ping expose any new security risks?

Q6: Do you support that the WG adopt the document ?
  If your answer is NO is there any other mechanism you want considered ?
  Yes assumes you are willing to review future versions of the document.

Note: We have not asked any questions on the details on how the
option is implemented as that can be addressed after a
consensus on that EDNS0 is beneficial has been reached.

Note: Just like EDNS0 discovery is unreliable when dealing with any cast
clusters, EDNS Ping discovery will be unreliable during time it takes 
to upgrade
the whole cluster in all locations. This on its own is not an 
acceptable argument
against this particular proposal.

         Olafur for the chairs

[1] Implementation costs, State discovery, State Maintenance, deployment cost,
operational cost etc.

--
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: Nicholas Weaver <[email-masked]>
Date: Wed, 22 Apr 2009 09:08:34 -0700

> Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ?

Not when implemented on the authority side as well as resolver side:   
The state management is trivial for both resolver and authority, the  
packet size amplification is almost trivial, deployment cost is no  
worse than any other DNS server patch for server operators and its a  
very minor change for DNS server code implementers..

When not implemented on the authority side:  It depends on the  
fallback mode employed when EDNS0 ping data is not replied to, and  
this is a cost imposed on those NOT updating to support EDNS0-ping.   
Such a cost would only be apparent when a significant number of  
resolvers start using EDNS0-ping.

>        "Pre-DNSSEC DNS"   OR  "both DNSSEC and Pre-DNSSEC" ?

"Non-DNSSEC DNS":

for DNSSEC, EDNS0 ping adds no confidence:  it is targeted against out- 
of-path adversaries, while DNSSEC is targeted against both in-path and  
out-of-path adversaries.

Under an "attack", an EDNS0-Ping failure but DNSSEC success is still a  
DNSSEC success, and can be trusted if DNSSEC can be trusted.

While a DNSSEC failure but EDNS0-Ping success has no impact on  
security if your threat model is an in-path adversary, because an in- 
path adversary can always correctly forge the EDNS0-packet.

>        only when the majority of code bases are deployed?

It depends on default behavior and fallback policy.

If there is a duplication-based fallback policy for resolvers,  
resolvers can immediately and directly benefit upon upgrading, AND  
provide an incentive for authorities to upgrade.

If most authorities already echo back the EDNS0-ping payload as a  
"Don't know, don't care" default behavior, then the benefits for  
resolvers using EDNS0-ping can be achieved incrementally.

If there is no fallback-policy for EDNS0-ping not acknowledged AND  
most authorities do not currently reply, then the benefits are only  
achieved when a majority of the authorities will echo back the EDNS0- 
ping payload.

> Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or  
> the producer?

Consumer.

> Q4: Will ENDS0 Ping delay/prevent DNSSEC deployment?  (explain)

If DNSSEC advocates are honest?  No.

DNSSEC's biggest advantage to creating end-to-end secure applications  
is to secure Name->Key mappings.  EDNS0 Ping does nothing to secure  
Name->key mappings in any meaningful manner.

If DNSSEC advocates are dishonest?  Yes.

There is a non-trivial group of DNSSEC advocates who view attempts to  
secure DNS against out-of-path adversaries as weakening the case for  
DNSSEC deployment, because securing DNS for Name->Address mappings  
against in-path adversaries does not have a clear system security  
benefit (with the notable exception of securing against misbehaving  
recursive resolvers.)

These advocates may be correct:  Having ordinary DNS perceived as  
"completely insecure" is a good incentive for DNSSEC deployment.

> Yes assumes you are willing to review future versions of the document.

Yes.

I believe there is some supporting survey data that should be  
conducted (I have already corresponded with Bob Herbert on some  
suggestions), and I believe that fallback mechanisms should actually  
be discussed in the draft (not currently present).

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 22 Apr 2009 20:19:46 +0200

Some comments from my side:

> Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ?

While this answers not the question directly, I think we should consider
where the "expensiveness" happens:

The cost varies between the authoritative server and the resolver.

IMHO (and this is without having looked at the code), the server-side is
rather trivial. No state. Just echo that record back.

The resolver has the more difficult task: it has to keep state about the
EDNS0 support level, worry about down-grade attacks and potentially resend
the query without the EDNS0 ping.

Who benefits from EDNS0?

IMHO the resolver as he gets potentially better assurance that the answer
is not faked. This is good: the party that reaps the benefit also has the
most work to do. (e.g. ENUM is the other way round which killed its uptake)

>       standardized or will we have to suffer the same cost when options are

Updating the server side implementations to a better understanding on how
to react on unknown EDNS0 options will also help with future EDNS0 options.
(I haven't followed what happened to draft-ietf-dnsext-ends-unknown-00, but
when reading up on EDNS0 I found no clear rules on treating unknown EDNS0
codes.)

>         "Pre-DNSSEC DNS"   OR  "both DNSSEC and Pre-DNSEC" ?

Both, as in the second case it can be used between the stub resolver and
the validating recursor.

>         only when the majority of code bases are deployed?

Incrementally.

> Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or the

As mentioned above: the cost and the main benefits are on the client side.

Yes.

Reason: This is no panacea, but one way a simple code upgrade can
significantly increase the security. Certainly not up to the level that
DNSSEC could provide, but you just can't roll out DNSSEC with an automatic
software upgrade. EDNS0 ping could be. And that's really important.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: bert hubert <[email-masked]>
Date: Wed, 22 Apr 2009 20:28:02 +0200

2009/4/22 Nicholas Weaver <[email-masked]>:
> for DNSSEC, EDNS0 ping adds no confidence:  it is targeted against
> out-of-path adversaries, while DNSSEC is targeted against both in-path and
> out-of-path adversaries.

It does add some robustness. Our goal should not purely be
authenticity but also availability.

>> Yes assumes you are willing to review future versions of the document.

Thanks!

> I believe there is some supporting survey data that should be conducted (I
> have already corresponded with Bob Herbert on some suggestions), and I
> believe that fallback mechanisms should actually be discussed in the draft
> (not currently present).

Bob Herbert reporting :-) While I agree we should discuss strategies,
or perhaps even better, add wise words on potential fallback
mechanisms, I'm not convinced we can 'legislate' this in MUST or even
SHOULD language.

Olafur yesterday shared a great new idea with me on how to securely
probe for EDNS0 support in a non-downgradeable way. I'm sure even
better ideas will come along. I'd hate to require certain strategies
when what we should be enabling is the invention of even better
strategies.

    Bert

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 22 Apr 2009 12:17:19 -0700

> the query without the EDNS0 ping.

There is no real such thing as a downgrade attack on EDNS0 ping:

To do a downgrade, an attacker would need to be in-path.  And in-path  
attacker are not affected by EDNS0 ping.

Rather, what needs to be considered is "what if there is no support  
for EDNS ping" and IMO, I believe that should be in the draft..

> Both, as in the second case it can be used between the stub resolver  

If you want the benefits of DNSSEC, the stub, not the recursor, MUST  
be the validator.  Since the recursor is an untrustworthy part in  
DNSSEC.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Apr 2009 16:48:52 -0400

> of-path adversaries, while DNSSEC is targeted against both in-path and  

This is a question, and only a question (i.e. not a comment pretending
to be a question).  I'm asking this as co-chair, as part of an effort
to understand why you think the adoption is worth it.

I think you're saying that (1) we need to upgrade resolvers to do
EDNS0 Ping and (2) it does not really offer any benefit not already
offered by DNSSEC.  Is that right?  If so, then why do EDNS0 Ping at
all?  If not, what did I misunderstand in what you said?

A

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

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 22 Apr 2009 14:34:00 -0700

> all?  If not, what did I misunderstand in what you said?

Supporting EDNS Ping just requires upgrading resolvers and
authoritative servers.  It doesn't require any additional
configuration work from the administrators.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 22 Apr 2009 14:52:20 -0700

On Apr 22, 2009, at 1:48 PM, Andrew Sullivan wrote:

>> out-

IF we could, by magic, get DNSSEC adopted, my view is EDNS ping does  
nothing.

However, getting DNSSEC adopted is, I believe, a MUCH harder hurdle  
than EDNS0 Ping.

EDNS0 ping is a trivially small patch on the authority code side, and  
a very small patch on the resolver code side, and really requires no  
intervention from operators beyond installing the patch.

Since you need fallback/treatment on the resolver side when the  
authority doesnt' support it anyway, you don't even have to worry  
about the stupid firewalls (you'll just be in always-fallback in that  
case).

DNSSEC, on the other hand, has some severe problems, including turning  
many misconfigurations (eg, stale keys, etc) into full denial of  
service conditions.  There's no established roots of trust to actually  
trust, deployment on the authority side requires MANY headaches, and  
there doesn't even exist a proper API for applications to really use  
DNSSEC as gethostbyname() is obviously not the correct answer for  
DNSSEC, etc...

Thus although 1 and 2 are correct, it forgets 3: EDNS0 ping is orders  
of magnitude simpler, and thus can put the final nail in the coffin on  
out-of-path attackers in a practical, deployable manner today.

---

From: David Blacka <[email-masked]>
Date: Wed, 22 Apr 2009 19:42:40 -0400

> IF we could, by magic, get DNSSEC adopted, my view is EDNS ping does  

Doesn't it make it harder for an off-path attacker to DoS you?  Or is  
that problem already considered solved?

--
David Blacka                          <[email-masked]>
Sr. Engineer          VeriSign Platform Product Development

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 22 Apr 2009 16:53:38 -0700

On Apr 22, 2009, at 4:42 PM, David Blacka wrote:
>>
>> IF we could, by magic, get DNSSEC adopted, my view is EDNS ping  
>> does nothing.
>
> Doesn't it make it harder for an off-path attacker to DoS you?  Or  
> is that problem already considered solved?

An off-path attacker, even without port randomization, requires a huge  
amount of traffic to DOS, especially if on first-DNSSEC failure you do  
a retry, that an off-path attacker might as well just do a traffic DOS  
instead.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Apr 2009 09:25:39 +0200

On Wed, Apr 22, 2009 at 08:19:46PM +0200,
 Otmar Lendl <[email-masked]> wrote 

> rather trivial. No state. Just echo that record back.

There is another cost for the authoritative server which did not
upgrade to edns-ping: an increase in the number of queries by
edns-ping resolvers trying to find out if there was a downgrade attack
or if the authoritative server really does not support edns-ping. Not
a big problem, IMHO, but it should be mentioned for completeness.

---

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

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1uYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItDQo+IG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGFuZSBCb3J0em1leWVyDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyMywgMjAwOSAxMDoyNiBBTQ0KPiBUbzogT3RtYXIgTGVuZGwNCj4gQ2M6IG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogW2Ruc2V4dF0gUmU6IEFkb3B0IEVETlMwIFBpbmcsIGJlbmVmaXRzIHZzIGRpc2FkdmFudGFnZXMgPw0KPiANCj4gT24gV2VkLCBBcHIgMjIsIDIwMDkgYXQgMDg6MTk6NDZQTSArMDIwMCwNCj4gIE90bWFyIExlbmRsIDxsZW5kbEBuaWMuYXQ+IHdyb3RlDQo+ICBhIG1lc3NhZ2Ugb2YgNzAgbGluZXMgd2hpY2ggc2FpZDoNCj4gDQo+ID4gVGhlIGNvc3QgdmFyaWVzIGJldHdlZW4gdGhlIGF1dGhvcml0YXRpdmUgc2VydmVyIGFuZCB0aGUgcmVzb2x2ZXIuDQo+ID4NCj4gPiBJTUhPIChhbmQgdGhpcyBpcyB3aXRob3V0IGhhdmluZyBsb29rZWQgYXQgdGhlIGNvZGUpLCB0aGUgc2VydmVyLXNpZGUNCj4gaXMNCj4gPiByYXRoZXIgdHJpdmlhbC4gTm8gc3RhdGUuIEp1c3QgZWNobyB0aGF0IHJlY29yZCBiYWNrLg0KPiANCj4gVGhlcmUgaXMgYW5vdGhlciBjb3N0IGZvciB0aGUgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgd2hpY2ggZGlkIG5vdA0KPiB1cGdyYWRlIHRvIGVkbnMtcGluZzogYW4gaW5jcmVhc2UgaW4gdGhlIG51bWJlciBvZiBxdWVyaWVzIGJ5DQo+IGVkbnMtcGluZyByZXNvbHZlcnMgdHJ5aW5nIHRvIGZpbmQgb3V0IGlmIHRoZXJlIHdhcyBhIGRvd25ncmFkZSBhdHRhY2sNCj4gb3IgaWYgdGhlIGF1dGhvcml0YXRpdmUgc2VydmVyIHJlYWxseSBkb2VzIG5vdCBzdXBwb3J0IGVkbnMtcGluZy4gTm90DQo+IGEgYmlnIHByb2JsZW0sIElNSE8sIGJ1dCBpdCBzaG91bGQgYmUgbWVudGlvbmVkIGZvciBjb21wbGV0ZW5lc3MuDQo+IA0KPiANCg0KSSB0aGluayBhbnkgc29sdXRpb24gc3VmZmVycyBmcm9tIHRoaXMgZHJhd2JhY2ssIG5vdCBqdXN0IEVETlMwIFBJTkcuIA0KDQo+IC0tDQo+IHRvIHVuc3Vic2NyaWJlIHNlbmQgYSBtZXNzYWdlIHRvIG5hbWVkcm9wcGVycy1yZXF1ZXN0QG9wcy5pZXRmLm9yZyB3aXRoDQo+IHRoZSB3b3JkICd1bnN1YnNjcmliZScgaW4gYSBzaW5nbGUgbGluZSBhcyB0aGUgbWVzc2FnZSB0ZXh0IGJvZHkuDQo+IGFyY2hpdmU6IDxodHRwOi8vb3BzLmlldGYub3JnL2xpc3RzL25hbWVkcm9wcGVycy8+DQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Apr 2009 10:31:49 +0200

On Thu, Apr 23, 2009 at 11:01:22AM +0300,
 Aki Tuomi <[email-masked]> wrote 
 a message of 33 lines which said:

> I think any solution suffers from this drawback, not just EDNS0 PING. 

Before Paul Vixie steps in, I can quote his reasoning: with 0x20,
today, the majority of name servers is already compliant and will not
suffer for the increase of queries. With cookies or edns-ping, today,
the majority of name servers is not compliant.

Not a big deal, IMHO, the increased channel security is worth it, but
it is something to keep in mind.

---

From: "George Barwood" <[email-masked]>
Date: Thu, 23 Apr 2009 10:32:08 +0100

----- Original Message ----- 
From: "Ólafur Guðmundsson /DNSEXT chair" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 22, 2009 4:07 PM
Subject: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ?

> Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ?

I don't understand the intent of the question too well - but on the server
side it seems cheap.

>       standardized or will we have to suffer the same cost when options 

What cost?

>         "Pre-DNSSEC DNS"   OR  "both DNSSEC and Pre-DNSSEC" ?

I'm not sure, but may be some benefit to both.
It's a useful function, standardizing useful functions is sensible for a
standards body, even if the precise benefits are not clear.

>         only when the majority of code bases are deployed?

It's not clear, but there can be incremental benefits.

> Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or the 

I don't think this can be easily answered in general.

> Q4: Will ENDS0 Ping delay/prevent DNSSEC deployment?  (explain)

No, I don't think so. DNSSEC has certain advantages, and complex costs, but
it's deployment
is related more to complex political and security questions.

> Q5: Does ENDS0 Ping expose any new security risks?

No, but there could be performance risks. However the upgrade process will
be gradual, so the risk is not excessive.

> Q6: Do you support that the WG adopt the document ?

Yes.
Even if DNSSEC is adopted ( which is not certain ), plain DNS will continue
to be used for a long time.
The proposal increases the options for securing plain DNS over time.

> clusters, EDNS Ping discovery will be unreliable during time it takes to 
> upgrade
> the whole cluster in all locations. This on its own is not an acceptable 
> argument

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 23 Apr 2009 11:52:46 +0200

> it is something to keep in mind.

Hi,

Looking at this proposal as an implementor, I have to have answers from
the working group to questions (below) if this draft is standards-track.
 If the working group can answer them (in this draft or in others), then
the EDNS0 PING approach could be worth it, and then I support the group
working on EDNS0 PING.

*[Probe]  How do you probe for support of the EDNS0 PING option?  Tell
me about error returns, dropped messages, option ignored, option
disables EDNS0 (but not further query) processing, timeouts...

*[Fallback]  How do you fallback?  When the probe is not successful, how
do you fallback in a secure, non-antisocial manner.

*[Interop]  What fallback method(s) should be implemented?  If a
resolvercluster is using different fallback implementations, they can
get different answers, and thus start giving different answers to the
same query.  Interoperability problems between resolvers.

*[Downgrade]  Is the group convinced that there is no downgrade attack?

*[State]  The result of the probe, how to keep it around?  What is the
TTL of that state?  When do you re-probe?  Is the resolver fully
vulnerably when starting up?  What is the cache policy for the state,
i.e. when cache memory is full and new probes are done, what domains are
made insecure?

Thus, the idea of making the ID field longer is attractively simple.
The draft is not that simple, because it does not actually make the ID
field longer, but uses an EDNS0 option.  The EDNS0 PING idea as written
down here, in my opinion, works only in good weather.

Best regards,
   Wouter

---

From: "George Barwood" <[email-masked]>
Date: Thu, 23 Apr 2009 11:32:06 +0100

----- Original Message ----- 
From: "W.C.A. Wijngaards" <[email-masked]>
To: <[email-masked]>
Cc: "Stephane Bortzmeyer" <[email-masked]>; "Aki Tuomi" 
<[email-masked]>
Sent: Thursday, April 23, 2009 10:52 AM
Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ?

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

The full set of responses by non-upgraded servers will have to be determined 
by experiment.
I think most will return an error.

> do you fallback in a secure, non-antisocial manner.

Up to the client - many strategies on the client side are possible.
It might only be used when non-deterministic responses are observed.
I don't think the standard needs to specify all possible uses, or what 
strategies a resolver
should employ ( this might be a useful information document, but should not 
be a reason
to hold up the standard ).

> same query.  Interoperability problems between resolvers.

Again, up to the implementor, not the primary concern for a standards body.

> *[Downgrade]  Is the group convinced that there is no downgrade attack?

Depends on the fallback strategy in the client. Again, up to the 
implementor.

> i.e. when cache memory is full and new probes are done, what domains are

A normal position for a general purpose client  would be to insist that all 
results are secure
against out-of-path attacks. This requires extra queries, which has some 
performance
implications that EDNS ping solves ( when deployed on the server side ).

> down here, in my opinion, works only in good weather.

It is not a panacea, but provides an option that may be useful, especially 
for high performance
non-deterministic authorities, where optaining secure results is otherwise 
difficult/expensive
in term of packets required.

It may also be useful for securing the hop between a stub resolver and the 
recursive resolver.

My view is that it is sensible, we may not be able to forsee the benefits 
( which may take many years to materialise ),
but it is worth trying nevertheless.

Regards,
George

> Best regards,
>   Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAknwOm4ACgkQkDLqNwOhpPjRvQCfUGguJQBZ4wiYAYvjWlpQuUUi
> 774An3lqFmI7wQC3rOQ8p9A7n63Bj98m
> =fc7z
> -----END PGP SIGNATURE-----
>
> --

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 23 Apr 2009 14:08:14 +0300

> the EDNS0 PING approach could be worth it, and then I support the group

That's funny, because looking at this proposal as a (former) server
implementor, I would actually prefer the opposite, that the working
group _not_ get into such details as a prerequisite to standardizing
the PING option itself.

There is a myriad possible designs for how a resolver might handle
probing, fallback, downgrade attacks, state, etc.  There is probably
more than one good design (and many more bad ones).  Implementors
should be free to explore this design space and compete in making the
best possible use of the PING option (or not, if they so choose); that
will be far more effective than trying to come up with a single design
by committee, and it can be done in parallel with the roll-out of the
PING option on the authoritative server side.
-- 
Andreas Gustafsson, [email-masked]

---

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

> -----Original Message-----
> From: Andreas Gustafsson [mailto:[email-masked]]
> Sent: Thursday, April 23, 2009 2:08 PM
> To: W.C.A. Wijngaards
> Cc: [email-masked]; Stephane Bortzmeyer; Aki Tuomi

I suppose OPs question could be viewed as "reference" or "example" implementation to give insight of practical implications, instead of as something people should standardize. 

---
Aki Tuomi
TDC Oy

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

---

From: Shane Kerr <[email-masked]>
Date: Thu, 23 Apr 2009 14:50:46 +0200

Aki,

Aki Tuomi wrote:
>> From: [email-masked] [mailto:owner-
>> [email-masked]] On Behalf Of Stephane Bortzmeyer
>> Sent: Thursday, April 23, 2009 10:26 AM
>> To: Otmar Lendl
>> Cc: [email-masked]
>> Subject: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ?
>>

Not necessarily.

One idea is registering what features a name server supports in the DNS(*).

So, one could:

* create a new RTYPE to encode which EDNS0 options were supported
* create a new EDNS0 option which the parent server would use to
  report EDNS0 support from child records (as documented in the RTYPE)

So, as the operator of TIME-TRAVELLERS.ORG, my zone might have:

time-travellers.org.     NS        ns1.time-travellers.org.
                         NS        ns2.time-travellers.org.
ns1.time-travellers.org  A         1.2.3.4
                         EDNS0OPT  ( NSID PING )
ns2.time-travellers.org  A         2.3.4.5
                         EDNS0OPT  ( NSID PING )

The EDNS0OPT would be a new type of glue.

--
Shane

(*) This idea occurs to me after looking at DNSCurve. DNScurve encodes a
public key in the NS set for a zone. So your NS set may be:

example.com NS d4fdfsu8j3j331234faes32aaasdfGG.example.com
            NS lkj4444lkjsadfo89unasdfnasdlqu1.example.com

A clever idea, and one that can be extended here.

---

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

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaGFuZSBLZXJyIFttYWlsdG86c2hhbmVAY2EuYWZpbGlhcy5pbmZvXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMDkgMzo1MSBQTQ0KPiBUbzogQWtpIFR1b21pDQo+IENjOiBuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnDQo+IFN1YmplY3Q6IFB1Ymxpc2hpbmcgTlMgZmVhdHVyZXMgaW4gdGhlIEROUywgd2FzIFJlOiBbZG5zZXh0XSBSZTogQWRvcHQNCj4gRUROUzAgUGluZywgYmVuZWZpdHMgdnMgZGlzYWR2YW50YWdlcyA/DQo+IA0KPiBBa2ksDQo+IA0KPiBBa2kgVHVvbWkgd3JvdGU6DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG93bmVyLW5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci0NCj4gPj4gbmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXBoYW5lIEJvcnR6bWV5ZXINCj4gPj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDIzLCAyMDA5IDEwOjI2IEFNDQo+ID4+IFRvOiBPdG1hciBMZW5kbA0KPiA+PiBDYzogbmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbZG5zZXh0XSBSZTogQWRvcHQgRUROUzAgUGluZywgYmVuZWZpdHMgdnMgZGlzYWR2YW50YWdlcyA/DQo+ID4+DQo+ID4+IE9uIFdlZCwgQXByIDIyLCAyMDA5IGF0IDA4OjE5OjQ2UE0gKzAyMDAsDQo+ID4+ICBPdG1hciBMZW5kbCA8bGVuZGxAbmljLmF0PiB3cm90ZQ0KPiA+PiAgYSBtZXNzYWdlIG9mIDcwIGxpbmVzIHdoaWNoIHNhaWQ6DQo+ID4+DQo+ID4+PiBUaGUgY29zdCB2YXJpZXMgYmV0d2VlbiB0aGUgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgYW5kIHRoZSByZXNvbHZlci4NCj4gPj4+DQo+ID4+PiBJTUhPIChhbmQgdGhpcyBpcyB3aXRob3V0IGhhdmluZyBsb29rZWQgYXQgdGhlIGNvZGUpLCB0aGUgc2VydmVyLQ0KPiBzaWRlDQo+ID4+IGlzDQo+ID4+PiByYXRoZXIgdHJpdmlhbC4gTm8gc3RhdGUuIEp1c3QgZWNobyB0aGF0IHJlY29yZCBiYWNrLg0KPiA+PiBUaGVyZSBpcyBhbm90aGVyIGNvc3QgZm9yIHRoZSBhdXRob3JpdGF0aXZlIHNlcnZlciB3aGljaCBkaWQgbm90DQo+ID4+IHVwZ3JhZGUgdG8gZWRucy1waW5nOiBhbiBpbmNyZWFzZSBpbiB0aGUgbnVtYmVyIG9mIHF1ZXJpZXMgYnkNCj4gPj4gZWRucy1waW5nIHJlc29sdmVycyB0cnlpbmcgdG8gZmluZCBvdXQgaWYgdGhlcmUgd2FzIGEgZG93bmdyYWRlDQo+IGF0dGFjaw0KPiA+PiBvciBpZiB0aGUgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgcmVhbGx5IGRvZXMgbm90IHN1cHBvcnQgZWRucy1waW5nLg0KPiBOb3QNCj4gPj4gYSBiaWcgcHJvYmxlbSwgSU1ITywgYnV0IGl0IHNob3VsZCBiZSBtZW50aW9uZWQgZm9yIGNvbXBsZXRlbmVzcy4NCj4gPj4NCj4gPj4NCj4gPg0KPiA+IEkgdGhpbmsgYW55IHNvbHV0aW9uIHN1ZmZlcnMgZnJvbSB0aGlzIGRyYXdiYWNrLCBub3QganVzdCBFRE5TMCBQSU5HLg0KPiANCj4gTm90IG5lY2Vzc2FyaWx5Lg0KPiANCj4gT25lIGlkZWEgaXMgcmVnaXN0ZXJpbmcgd2hhdCBmZWF0dXJlcyBhIG5hbWUgc2VydmVyIHN1cHBvcnRzIGluIHRoZQ0KPiBETlMoKikuDQo+IA0KPiBTbywgb25lIGNvdWxkOg0KPiANCj4gKiBjcmVhdGUgYSBuZXcgUlRZUEUgdG8gZW5jb2RlIHdoaWNoIEVETlMwIG9wdGlvbnMgd2VyZSBzdXBwb3J0ZWQNCj4gKiBjcmVhdGUgYSBuZXcgRUROUzAgb3B0aW9uIHdoaWNoIHRoZSBwYXJlbnQgc2VydmVyIHdvdWxkIHVzZSB0bw0KPiAgIHJlcG9ydCBFRE5TMCBzdXBwb3J0IGZyb20gY2hpbGQgcmVjb3JkcyAoYXMgZG9jdW1lbnRlZCBpbiB0aGUgUlRZUEUpDQo+IA0KPiBTbywgYXMgdGhlIG9wZXJhdG9yIG9mIFRJTUUtVFJBVkVMTEVSUy5PUkcsIG15IHpvbmUgbWlnaHQgaGF2ZToNCj4gDQo+IHRpbWUtdHJhdmVsbGVycy5vcmcuICAgICBOUyAgICAgICAgbnMxLnRpbWUtdHJhdmVsbGVycy5vcmcuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBOUyAgICAgICAgbnMyLnRpbWUtdHJhdmVsbGVycy5vcmcuDQo+IG5zMS50aW1lLXRyYXZlbGxlcnMub3JnICBBICAgICAgICAgMS4yLjMuNA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgRUROUzBPUFQgICggTlNJRCBQSU5HICkNCj4gbnMyLnRpbWUtdHJhdmVsbGVycy5vcmcgIEEgICAgICAgICAyLjMuNC41DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBFRE5TME9QVCAgKCBOU0lEIFBJTkcgKQ0KPiANCj4gVGhlIEVETlMwT1BUIHdvdWxkIGJlIGEgbmV3IHR5cGUgb2YgZ2x1ZS4NCj4gDQo+IC0tDQo+IFNoYW5lDQo+IA0KPiAoKikgVGhpcyBpZGVhIG9jY3VycyB0byBtZSBhZnRlciBsb29raW5nIGF0IEROU0N1cnZlLiBETlNjdXJ2ZSBlbmNvZGVzDQo+IGENCj4gcHVibGljIGtleSBpbiB0aGUgTlMgc2V0IGZvciBhIHpvbmUuIFNvIHlvdXIgTlMgc2V0IG1heSBiZToNCj4gDQo+IGV4YW1wbGUuY29tIE5TIGQ0ZmRmc3U4ajNqMzMxMjM0ZmFlczMyYWFhc2RmR0cuZXhhbXBsZS5jb20NCj4gICAgICAgICAgICAgTlMgbGtqNDQ0NGxranNhZGZvODl1bmFzZGZuYXNkbHF1MS5leGFtcGxlLmNvbQ0KPiANCj4gQSBjbGV2ZXIgaWRlYSwgYW5kIG9uZSB0aGF0IGNhbiBiZSBleHRlbmRlZCBoZXJlLg0KDQpZZXMsIHdoaWNoIHJlcXVpcmVzIGV4dHJhIHJlcXVlc3RzLiBZb3Ugc3RpbGwgaGF2ZSB0byAocGVyaW9kaWNhbGx5KSBxdWVyeSB0aGUgb3RoZXIgcGFydHkuIFByb2JhYmx5IHF1aXRlIG9mdGVuLiBTbyB0aGVyZSBpcyBzdGlsbCBubyBmcmVlIGx1bmNoLiANCg0KLS0tDQpBa2kgVHVvbWkNClREQyBPeQ0KDQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Thu, 23 Apr 2009 14:07:56 +0100

> The EDNS0OPT would be a new type of glue.

Although since EDNS0 is a hop-by-hop mechanism this would only protect the 
recursive -> authoritative path, and only if the recursor can guarantee 
that no intervening box will interfere with EDNS0's correct operation.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Apr 2009 09:20:36 -0400

[no hat]

On Wed, Apr 22, 2009 at 12:17:19PM -0700, Nicholas Weaver wrote:

> If you want the benefits of DNSSEC, the stub, not the recursor, MUST be 
> the validator.  Since the recursor is an untrustworthy part in DNSSEC.

Only if you don't have a secure path to the recursor, of course.  (I
recognise that might be hard, however, in a DHCP environment.)

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

---

From: Shane Kerr <[email-masked]>
Date: Thu, 23 Apr 2009 15:23:53 +0200

Ray,

>>   report EDNS0 support from child records (as documented in the RTYPE)

Oh, the child would also use this!

The idea of using an EDNS0 option for this rather than a separate QUERY
is that, like NSID, you want it to be part of a "normal" query. In the
case of EDNS0OPT this would be something you want to do to avoid extra
traffic.

> recursive -> authoritative path, 

True, but that is probably the biggest target and concern. In fact, I
never really considered any other! :)

> and only if the recursor can guarantee 

Well, kind of. This is the kind of details that would come out in a
draft, but my expectation would be that EDNS0 would be an "upgrade" type
option. So, if *any* responses get from a server to a resolver
indicating the server has EDNS0 Ping support, then the resolver would
cache that result (using normal TTL expiration mechanisms).

--
Shane

---

From: Florian Weimer <[email-masked]>
Date: Thu, 23 Apr 2009 15:25:14 +0200

> The EDNS0OPT would be a new type of glue.

I think it's not really that much more work to put a DS record there
instead of an EDNS0OPT record, so I don't think this approach offers a
got trade-off.

If you want signalling, you have to put it into the name,
Dnscurve-style.

-- 
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: Nicholas Weaver <[email-masked]>
Date: Thu, 23 Apr 2009 07:29:05 -0700

> recognise that might be hard, however, in a DHCP environment.)

No.  The recursor itself IS the untrustworthy part!

OpenDNS:
[gala:~/archive/svn_nweaver/presentation] nweaver% dig www.google.com  
@208.67.222.222
...
;; ANSWER SECTION:
www.google.com.         30      IN      CNAME    
google.navigation.opendns.com.
google.navigation.opendns.com. 30 IN    A       208.67.219.231
google.navigation.opendns.com. 30 IN    A       208.67.219.230

Malicious Recursive Resolver (DNSchanger malcode):
[gala:~/archive/svn_nweaver/presentation] nweaver% dig  
ad.doubleclick.net @85.255.112.122

;; ANSWER SECTION:
ad.doubleclick.net.     26      IN      A       93.190.141.162

[gala:~/archive/svn_nweaver/presentation] nweaver% dig -x 93.190.141.162
;; QUESTION SECTION:
;162.141.190.93.in-addr.arpa.   IN      PTR

;; AUTHORITY SECTION:
141.190.93.in-addr.arpa. 3600   IN      SOA     ns1.worldstream.nl.  
hostmaster.w
orldstream.nl. 2009041900 10800 3600 604800 3600

This is why I mean "the recursive resolver is the only substantial in- 
path adversary for DNS traffic thats not in-path for the final  
application".

And why the stub, not the recursive resolver, MUST be the one to  
validate DNSSEC information, and why, on validation failure, I believe  
the stub should generate its own request, bypassing the recursive  
resolver completely, and accept that result, as the default behavior  
for the existing gethostbyname() API.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Apr 2009 15:03:51 +0000

> Date: Thu, 23 Apr 2009 10:31:49 +0200
> From: Stephane Bortzmeyer <[email-masked]>
> 

thanks for correctly channeling my spirit.  the other reasons i don't 
support adoption of cookies or edns-ping are: it adds a lot of complexity
in order to solve a problem that we're not having (hop by hop corruption)
while failing to solve a problem we are having (end to end corruption);
and, it changes the edns protocol due to an inherent downgrade attack.

> it is something to keep in mind.

it is a VERY BIG deal.  am i the only one here to groks the size of the
installed base?  changes we make to the hop-by-hop are amplified by the
number of endpoints.  channeling bob halley: "ok, it works in the lab,
now multiply all your numbers by six million."  except here it's 600
million.

---

From: bert hubert <[email-masked]>
Date: Thu, 23 Apr 2009 17:40:57 +0200

> in order to solve a problem that we're not having (hop by hop corruption)

We don't? I thought that this is what Kaminsky was all about..

> while failing to solve a problem we are having (end to end corruption);

You appear to labour under the idea that the people who are currently
corrupting some people's DNS (presumably these are the NXDOMAIN
redirectors, or perhaps OpenDNS), will stop doing so if you deploy
DNSSEC to authoritative resolvers and recursor. It won't work that
way.

> now multiply all your numbers by six million."  except here it's 600

You keep saying that but you don't have the numbers. You claimed
DNS-0x20 was trouble free yet it turned out that very important
domains (like google.com) failed for DNS-0x20 users.

"To measure is to know", and I do in fact have the EDNS-PING numbers.
The results are a very limited number of extra queries, and these are
100.00% aimed at those few servers which reject EDNS-PING carrying
queries instead of ignoring them. This includes none of the important
nameserver implementations, and appears to be limited to some load
balancers.

These would indeed suffer 1 extra query per hour or so do determine if
their support for EDNS(-PING) has changed (upwardly).
Most of these servers also reject EDNS queries anyhow.

So please stick to facts instead of this hand waving which does not
befit an engineer.

     Bert

---

From: Stefan Schmidt <[email-masked]>
Date: Thu, 23 Apr 2009 18:08:09 +0200

Hey Paul,

> now multiply all your numbers by six million."  except here it's 600

Well i don't know how you would implement EDNS PING but Bert's code does cache
who is a EDNS PING talker and who is not, so it's more like 1 extra packet
every hour or day than for every query.

I (too) briefly deployed Bert's PowerDNS recursor svn trunk code and did not
experience a noticable deal of extra packets altough in addition to roughly
700 authoritative EDNS PING talkers all of my own authoritatives were EDNS
PING enabled so a good deal of queries were already protected back then.

Of course it's not likely that we discovered all potential pitfalls, or even
all implementations that do EDNS wrong like those f5 loadbalancers mentioned
earlier, but IMO it's well worth the hassle.

What is beyond me is why EDNS PING would be such a big deal when DNSSEC is
likely to have several times the impact when we're talking compatability or
packets.

	Stefan
-- 
- Of course it's your fault! Everything that goes wrong around here is your
  fault! It says so in your contract.
Quark to Rom, "Heart of Stone.", ST-DS9

---

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

> and, it changes the edns protocol due to an inherent downgrade attack.

EDNS0 is really not about "hop by hop" vs "end-to-end", its "out of  
path" vs "in path"

What in-path corruption do we currently have that is NOT directly  
attributable to the recursive resolver itself?

> now multiply all your numbers by six million."  except here it's 600

Except that for aggregate traffic, DNS is in the noise.  So nothing *  
3 is still practically nothing (assuming the duplication-based  
fallback for non-support of EDNS0 ping).

Thus extra traffic ONLY matters for servers which are

a)  Refusing to apply a simple patch and
b)  Are already operating within a significant fraction of their  
theoretical maximum load.

How many cases do that apply?

---

From: "Antoin Verschuren" <[email-masked]>
Date: Thu, 23 Apr 2009 19:50:03 +0200

I must sort of express my support to Vixie's worries here, and say "me too"

I think ENDS0 PING and in fact any hop-by-hop security solution, including 0x20 btw, that we invent in this Kaminski era will become a true security burden later on when we might have deployed DNSSEC or another end-to-end security extension. DNS might end up becoming so complex that only a few on this earth will still understand it, and everyone else is just trying to understand it hoping they do the right thing. Making the protocol so full of minor improvements is not a good and robust design, and will result in operators making more errors.

So my first question would be, is it the intention to turn EDNS0 ping OFF once we have deployed DNSSEC so we can reduce the complexity and traffic again ?

And speaking of traffic, yes that's my greatest worry too. I think every bit counts. We should design an efficient protocol, and not an SS7 monster. Every extra query on the wire that can be avoided is a query too much. Speaking of the operational experience, I can say that excessive querying is a greater threat to the DNS at this moment than any Kaminski style attack. I have to deal with traffic incidents on our nameservers multiple times a month, and I've not seen a Kaminski attack live yet.

If the DNS infrastructure collapses because of the extra traffic caused by disabling or bypassing caching or re-querying there won't be any more responses to queries. Secure or insecure responses.

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E [email-masked]
W http://www.sidn.nl/

> [email-masked]] On Behalf Of bert hubert
> Sent: Thursday, April 23, 2009 5:41 PM
> To: Paul Vixie
> Cc: Stephane Bortzmeyer; Aki Tuomi; [email-masked]

---

From: Shane Kerr <[email-masked]>
Date: Thu, 23 Apr 2009 22:34:41 +0200

Aki,

Aki Tuomi wrote:
> Yes, which requires extra requests. You still have to (periodically) query the other party. Probably quite often. So there is still no free lunch. 

The idea is that this information would get passed along in the replies
to queries via a new EDNS0 option; no extra queries would be required to
get this information. Now that might not be a practical idea, but in
theory it can work. :)

I don't think there are extra requests. Certainly not for the DNSCurve,
and I think not for registering EDNS0 Ping support within the DNS
(although again, it's all quite vague without solid descriptions at this
point... I guess I'll have to hammer out a draft).

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Thu, 23 Apr 2009 22:45:36 +0200

Florian,

> instead of an EDNS0OPT record, so I don't think this approach offers a

Well, except that one needs to actually sign the parent zone for there
to be any point in putting a DS record in it, which *is* a lot more work.

> If you want signalling, you have to put it into the name,

I'm not sure what you mean by "signaling".

One could publish servers' level of DNS support in the name, of course.
It may be more elegant in some sense to do it that way - it requires no
software changes on authoritative servers, and nothing new for
registries/registrars to do.

But you don't *have* to do it that way.

--
Shane

---

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

>From: Shane Kerr [mailto:[email-masked]] 
>Sent: Thursday, April 23, 2009 11:35 PM
>To: Aki Tuomi
>Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re:
Adopt >EDNS0 Ping, benefits vs disadvantages ?
>>> (*) This idea occurs to me after looking at DNSCurve. DNScurve
encodes
>>> a
>> Yes, which requires extra requests. You still have to (periodically)
>query the other party. Probably quite often. So there is still no free
>lunch. 

>point... I guess I'll have to hammer out a draft).

Point of EDNS PING is to send 'nonce' along the query. Then the other
party will reply with the 'nonce' in the return packet, if supported. 

You'd have to do extra queries after receiving the EDNS OPTION RR, to do
this exchange. 

---
Aki Tuomi

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Apr 2009 17:03:14 -0400

> No.  The recursor itself IS the untrustworthy part!

In the presence of a secured stub-recursor connection, that reduces to
either "if you don't trust your ISP, you're in deep trouble" or "if
someone can redirect all your DNS queries, you're hosed".  Since the
latter reduces to "if someone has superuser access, you're hosed", I
agree.

It seems to me that if someone can rewrite your /etc/resolv.conf in
such a way as the latter case, then they can just as easily install
new root-zone keys and send you to any servers they like.  So that's
not a thing we're going to be able to protect against in any case.  So
it's not interesting.

What remains, then, is whether there is a problem we can solve if your
ISP can't be trusted.   Right?

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

---

From: "George Barwood" <[email-masked]>
Date: Thu, 23 Apr 2009 22:39:14 +0100

----- Original Message ----- 
From: "Antoin Verschuren" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 23, 2009 6:50 PM
Subject: RE: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ?

> And speaking of traffic, yes that's my greatest worry too. I think every 
> bit counts.

You should be aware that if EDNS Ping ( or equivalent ) is not introduced, 
traffic may at some point increase as clients deploy repeated requests to 
obtain security against spoofing.

It's impossible to predict when this might happen, but EDNS Ping provides a 
pre-engineered solution.

Therefore if you are concerned about every bit, you should support EDNS 
Ping.

---

From: [email-masked]
Date: Thu, 23 Apr 2009 21:42:48 +0000

> ISP can't be trusted.   Right?

	i think this is way over simplified.
	the only ISP i trust implicitly is the one servicing my house..
	(in the immortal words of King Louie... "Thats ME!")

	now my laptop is mobile (designed for it), granted not as mobile
	as it used to be, but there you go.  Do I trust my school network?
	heck no... there are network researchers on it.  the contract sites
	I visit?  only to the extent I have to.  IETF network... hardly.
	They're as bad or worse than the school net.  Hotels? Airports?
	Your house?  Absolutely not.  Untrustworthy ISP all.

	so what do I do?  carry around a full-blown DNS IMR/Validator with my own
	set of keys.  Yes, I'll end up getting an IP address from your handy
	DHCP/RA server (and apparently a bunch'o'worthless crap that I'll either
	dump or quarentine)  ...  And I'll happily build an IPSEC tunnel back to
	a trusted environment and go from there if you try and box me in. (Thanks
	Sam for pointing out how to run IP over DNS and Steve for how to run IP over
	HTTP)

	What young Nicholas might be touchy about goes back to the RVA discussions
	we held in sidebar IETFs about four years ago.  One outcome was Suresh's ID
	on a DNSSEC API. ... :)

--bill

---

From: Shane Kerr <[email-masked]>
Date: Fri, 24 Apr 2009 00:42:35 +0200

Aki,

> You'd have to do extra queries after receiving the EDNS OPTION RR, to do

No, the idea is to get this information when determining the IP
address(es) of the NS entry. This can possibly be done by adding it to
the ADDITIONAL section, or maybe by encoding it in an EDNS0 option.

--
Shane

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 24 Apr 2009 12:00:51 +0200

Hi,

I have asked questions too, and without answers on those topics, I do
not think this draft can become a working group document.  The reason
those answers are needed is that the issues are important for security
and interoperability.

You note F5 interoperability concerns, and I think there may be
interoperability issues using loadbalancers and different fallbacks.
Going from the lab to the DNS world, there are surely many more.

I believe that EDNS PING as specified in the current version of the
draft is _not_ secure.  Without documentation we cannot tell how to make
it secure, and thoughts by me and others (expressed on this list, some
as answers to my questions) are that EDNS PING suffers from severe
downgrade problems.  For a working group draft EDNS PING has to be
convincingly an addition to security.

Also I see deployment trouble, your words seem to indicate that you
retry non-EDNS-PING server probes every hour, but EDNS-PING capable
servers stay that way forever.  This means that once deployed, a site
can never ever change their server software or turn it off (once they
have other security in place, DNScurve or DNSSEC)?  Although I agree
with Andreas that overspecification is bad, text is needed to advise
implementors here.

Based on the arguments above I believe that EDNS PING, as specified now,
is (highly) experimental and not ready for standards track.  In fact, as
an implementor I will not implement the specification in the default
configuration if the fallback mechanisms are not properly described, I
believe that those lead to interoperability issues.

I am willing to spend energy in the working group to review, ask
critical questions, and consider solutions to problems.  But, I've not
yet been convinced that adding this extra bloat to the DNS, and the code
base is worth the effort.  I believe that ball is with the proposer to
address these tough questions.

Best regards,
   Wouter

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 24 Apr 2009 12:21:32 +0200

[email-masked] wrote:
> 	set of keys.  

While I agree that this is the best way to get secure DNS to your box, I
doubt that this approach is feasible for the general public.

I'm wondering what DNSSEC deployment scenarios we really expect to happen
over the next years, even if we presume that DNSSEC will take off.

Maybe the folks from Sweden and Brazil want to chime in, but from what I
heard, the vast majority of client-side DNSSEC validation is done by the
resolvers of ISPs. Yes, early adopters and geeks will run their own
validators (either client-side, or by running their own recursors), but the
majority of users rely on their ISPs. Most likely, they don't even know
that their ISP is doing DNSSEC validation.

Do we expect that to change? I don't really think so.

/ol

---

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

On Fri, Apr 24, 2009 at 12:21:32PM +0200, Otmar Lendl wrote:
> the vast majority of client-side DNSSEC validation is done by the
> resolvers of ISPs. 
[elided]
> Do we expect that to change? I don't really think so.

	why yes we do think so.

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 24 Apr 2009 13:01:30 +0200

Antoin Verschuren wrote:
>
> So my first question would be, is it the intention to turn EDNS0 ping OFF 
> once we have deployed DNSSEC so we can reduce the complexity
> and traffic again ?

It's the client's decision to include EDNS0 ping in a query. I could
imagine that a validating client chooses not to include that option when he
 knows that he's dealing with a DNSSEC-signed zone.

Remember: the hard part is on the client side. The server part is trivial.

> 
> And speaking of traffic, yes that's my greatest worry too. 

The additional bytes in the request don't bother me. If you want to
increase the size of the Query-ID, then it should be no surprise that you
need to send a few more bytes over the wire.

No, the only worry I have in that respect are the repeated queries caused
by probing / fallback (and thus duplicate requests).

Now, what amount of fallback queries is due to the fact that the server
side doesn't support EDNS0 at all? (versus no support for EDNS0 PING)?

We already see live out there in the normal traffic EDNS0 enabled queries
which need to be resent as the server side doesn't support EDNS0. So
whatever retransmits the EDNS0 PING requests generate need to be compared
to this base level of EDNS0 probing/fallback.

Whatever we do with EDNS0-PING, we should strive to get
draft-ietf-dnsext-rfc2671bis-edns0 done. If we get that published and
implemented, then the additional retransmits due to the EDNS0-Ping should
go to zero. Regardless of whether the the server supports EDNS0-ping or not.

/ol

---

From: bert hubert <[email-masked]>
Date: Fri, 24 Apr 2009 13:06:56 +0200

> the EDNS0 PING approach could be worth it, and then I support the group

Wouter,

The explicit goal of EDNS-PING is not to regulate too much, and only
provide a framework which can be used to achieve certain goals.

It is however important to point out how the framework *could* be used
to achieve these goals.

One goal is to make 'blind spoofing' or even 'triggered blind
spoofing' highly unlikely to succeed.

> disables EDNS0 (but not further query) processing, timeouts...

Protection extends only towards communications between implementations
that support EDNS0 PING. Any authoritative server that includes this
option does its bit.

This means that an originator of queries needs:
1) a solid way to determine EDNS-PING support, and
2) make sure that the knowledge of this support can't conceivably be downgraded.

Both items are not too hard to achieve - it is trivial to probe for
EDNS-PING support, and it is very hard for an attacker to influence
such a probe: it has only 1 chance to do so.
Once the level of support is known, store this knowledge for a random
period of time. Once the status expires, head back to '1'. Do not
believe any answers from this host that are not EDNS-PING adorned.

If you want to delve into details, I am more than happy to share the
various ideas being discussed to make the above highly robust.

> do you fallback in a secure, non-antisocial manner.

You don't - without EDNS-PING, there is no EDNS-PING. Urge the DNSSEC
community to get stuff deployed and out on the clients.

> same query.  Interoperability problems between resolvers.

Outside of the scope of the draft.

> *[Downgrade]  Is the group convinced that there is no downgrade attack?

Olafur invented (or, re-discovered) an interesting way to probe for
support securely. When talking to a remote about domain 'example.com',
send it a query for 'sdfkjhsdfkjshdfkshdfkjh.example.com' as a probe
to see if it support EDNS-PING, where 'ssdfsfsfsdfsdfsdfsdkjh' is of
course random. This serves as a long additional keyspace that an
attacker would have to guess in order to spoof in a reply that
indicates no EDNS-PING support.

I'm not even sure if this clever idea is necessary though - it does
provide an additional layer of safety though.

> i.e. when cache memory is full and new probes are done, what domains are

Up to implementors.

One of the things that is important to realise is that this draft
should not be measured by the same stick as DNSSEC - its goals are
more modest, and much more of the use of EDNS-PING is up to the
resolver implementors.

   Bert

---

From: "George Barwood" <[email-masked]>
Date: Fri, 24 Apr 2009 12:19:23 +0100

----- Original Message ----- 
From: "W.C.A. Wijngaards" <[email-masked]>
To: "bert hubert" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 24, 2009 11:00 AM
Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ?

> convincingly an addition to security.

EDNS PING is not in itself secure or insecure. As explained by Nicholas 
Weaver, it is possible to build a secure resolver using EDNS PING by falling 
back on query repetition.

You might say, if there is a secure fallback, why do we need EDNS PING at 
all?

The answer is efficiency - query repetition can be quite expensive for 
non-deterministic authorities (in some cases my resolver use 10 queries 
instead of one, even when glue is discarded), with some performance 
trade-offs (as explained in my draft), so defining an efficient way of 
securely communicating with these servers is sensible.

In the longer term, once deployment of EDNS Ping is near universal, a 
reasonable fallback will be to report failure (or possibly a warning), which 
is a much simpler solution.

> with Andreas that overspecification is bad, text is needed to advise

That would be an erroneous implementation.

> believe that those lead to interoperability issues.

Once the EDNS Ping specification is on the standards track, there will be 
plenty of time to research the best ways to use it on the client side. 
Clearly there will need to be plenty of testing performed before client side 
deployment can take place. However, it can be deployed server side quite 
early.

[snip]

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 24 Apr 2009 14:13:40 +0200

Hi Bert,

Thank you for answering.

It would be great to have some of this taken up in the draft (if
adopted).  To document some way to make it work securely.  So I would
like you to pick up (some of) your (or mine) stuff below and mention it
in the draft.

> provide a framework which can be used to achieve certain goals.

No problem here.

> It is however important to point out how the framework *could* be used

This is exactly what I was trying to point out.

> spoofing' highly unlikely to succeed.

Obvious, yes.

>> *[Probe]  How do you probe for support of the EDNS0 PING option?
> 

This looks good.  It would be good to note the probe simplicity
proposed.  Also the expire of state.  And ignoring bad PING replies (to
remind the silly programmers).

> community to get stuff deployed and out on the clients.

So this is food for downgrade worries.

To protect against you need to protect the probe.  Perhaps you should
emphasize the random timeout on the state a bit more.  And Olafur's idea
below.

Another problem to examine is startup, when the time of probes is known,
again to protect that probe.  For example, disrupting communications
while probing is done (no replies received by prober) would create a
downgrade.

>> *[Interop]  What fallback method(s) should be implemented?

You already stated 'fallback to non-EDNS PING query' above.  I want this
topic to be in the draft.

> provide an additional layer of safety though.

A very nice idea, proposing something like this has a good place in the
draft.  I note it shouldn't be too long, so that DNAME'd zones do not
run into YXDOMAIN errors on the probe.   If you get YXDOMAIN errors, try
multiple shorter-named probes (perhaps).

So a positive reply is usually very strong, with the PING in there and
maybe a long name.  So in that case good security gets provided (what I
previously referred to as 'only in good weather').

A negative reply, if it does not contain a long random query name, is
not so very secure.  I think the draft SHOULD recommend that the random
timeout be much lower in that case, for example, or something better.
(i.e. negative reply by timeout, by error without qname, ...).  It is
these replies that are most downgrade sensitive, turning EDNS PING into
'but you have to spoof twice in a row'.  I think they need to be handled
with care.

A negative reply with the long random query name (thank you Olafur!), is
very good.  It provides some higher level of confidence that this
negative "just don't use EDNS PING now, OK?" reply is not a spoof but
from the original source.

I note this extended-qname probe query is an extra query that is done.
To make sure not too many probes are sent, the values of the (random)
timeouts should also be documented, does not have to be MUST, but SHOULD
is OK.  Documenting may not be fun, but you really have to do it.

Perhaps analysis of which servers are expected to get how many probes,
and how many probes a real world resolver sends ...  For domains that
usually only every get one query per resolver, the probe can be expected
to double the load.  While for say .com servers, the increase is
smaller.  This is a little like the cookies draft we had some time ago
[eastlake].

>> *[State]  The result of the probe, how to keep it around? 
> Up to implementors.

The important bit you said above was that it expires.
This sort of stuff really needs to be in the draft.

> more modest, and much more of the use of EDNS-PING is up to the

Well, the idea is to add safety.  As it stands, bad choices can make for
very bad security.  And if you document the above, the expected security
from the EDNS PING option could improve considerably.  By protecting the
probe, making it timeout properly, and randomising the time it is sent,
the draft becomes much stronger in its security.  I think this really
needs to be part of the draft.

Again, thank you for addressing my concerns.  I still think downgrade
risk has to be analysed more thoroughly.  However, I understand this is
the first draft submission, and you intend to have it improved by the
working group.  So, with concerns (to be) documented in the draft, I
have no problem with the working group working on this draft.

Best regards,
   Wouter

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 24 Apr 2009 05:45:20 -0700

On Apr 24, 2009, at 4:06 AM, bert hubert wrote:

> On Thu, Apr 23, 2009 at 11:52 AM, W.C.A. Wijngaards <[email-masked] 
> > wrote:

The problem:  EDNS0 ping is only good for two things:

a)  Adding entropy into requests and

b)  Acting as "stateless state", a way for a client to offload state  
holding onto the server.

The latter is only useful with universal deployment, and the amount of  
state we are talking about is trivial.  So it really is only good for  
A: increasing request entorpy.

Thus saying "we don't want to regulate too much" and "its just a  
framework" does the proposal a disservice.  EDNS0 ping is ONLY a  
mechanism for increasing query entropy.

As such, I agree with Wouter:  I think it is a mistake not to specify  
exactly how to use EDNS0 ping to protect traffic, and security related  
RFCs should be complete cookbook:  IF you implement it in exactly this  
way, you achieve security goals X Y and Z.  Other ways MAY work, but  
your mileage may vary.

This is also why I think fallback behavior when EDNS0 ping is not  
responded to should be explicitly in the specification, as it is for  
0x20, because this allows surveys and expectations on how things can  
evolve, what load EDNS0 ping partial deployment will cause, etc etc etc.

The goal should be "If only SOME systems support EDNS0 ping, those  
resolvers using it should benefit REGARDLESS of the behavior of  
individual authorities".  Otherwise, as a double sided change, it has  
deployment headaches not present in say, 0x20 (which is a pseudo- 
single-sided change).

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 24 Apr 2009 05:56:06 -0700

> over the next years, even if we presume that DNSSEC will take off.

Actually, this is the most feasible approach as well, in my  
opinion...  Here's how.

The US government signs .gov and .mil, and all within it, and leans on  
the roots to finally sign something, so you have a path from root ->  
(.gov, .mil, sweeded, brazil, etc..)

And then leans on Microsoft to have the stub resolver in Windows  
whatever validate based on the signed root, by using its market power.

or

Verisign makes it a condition of EV certs that the browser also verify  
the address using DNSSEC (of course, this adds no real security, but  
hey, EV certs are stupid to begin with, "Pay us more to do the job we  
should have done right in the first place..."

etc.

If the recursive resolvers

a)  Are the only one checking DNSSEC and
b)  Still accept unsigned data fine,

authorities have almost no incentive to upgrade.

But if the user's computers are

a)  Checking DNSSEC
and
b)  Complaining when its absent

Now authorities are forced to deplay.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 24 Apr 2009 14:37:23 +0100

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "bert hubert" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; "W.C.A. Wijngaards" 
<[email-masked]>; <[email-masked]>; "Stephane Bortzmeyer" 
<[email-masked]>
Sent: Friday, April 24, 2009 1:45 PM
Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ?

[snip]

> deployment headaches not present in say, 0x20 (which is a pseudo- 

This goal is achievable.
An authority that implements EDNS0 ping achieves improved security with 
clients that probe.
That's because a blind attacker will need to spoof (or DOS) the probe AND 
spoof the subsequent unprotected query.
That's nice, because it gives a good motive for both authorities and clients 
to deploy.
Even if the client adopts a simple probe approach.
Such clients will still be vulnerable to spoofing when querying non-upgraded 
servers, which is why I would advocate duplication / repetition. But simpler 
strategies still achieve improved security, and give a different incentive 
for authorities to upgrade ( security versus load ).

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Apr 2009 11:14:09 -0400

Co-chair hat on.

> 	Sam for pointing out how to run IP over DNS and Steve for how to run IP over

None of the above argument (and I'm including others' posts in the
thread, too -- this is just a handy paragraph on which to hang the
remark) suggests even a little bit in the way of protocol work.  On
the contrary, this sounds very much like, "The protocol is done, and
we really need to get the integration and operations parts polished,
ready, and easy to use."  It's easy for Bill to do the above, but the
average laptop user would stop for sure at "IMR/Validator with my own
set of keys" and maybe at "DNS".  Perhaps we need howtos, operations
documents, BCP or Informational documents or such -- but this is all
deployment and coding, not new protocol.

That sounds to me like a very strong argument for _not_ doing any more
forgery resilience or other such work, and for this WG to stop
fiddling with the security parts of the protocol: it sounds like we need
to stop distracting people who could be working on polishing the
deployment tools with shiny new protocol knobs to turn.

A

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

---

From: [email-masked]
Date: Fri, 24 Apr 2009 19:26:08 +0000

> deployment tools with shiny new protocol knobs to turn.

	er - i think i've already weighed in on this on other threads...
	but to reiterate, the IETF's job is not to do operations or to 
	wait upon operational folks to pick up the tokens and run w/ them.

	the IETF's job is to explore and docuement technical solutions.
	if some others are distracted by the shiny objects being talked about
	in the IETF, then the IETF needs to be a bit stronger on defining 
	its standards activities....  

	if there is a move to restrict discussion - perhaps its time to consider
	other venues for doing DNS protocol work.

	IMHO of course.

--bill

---

From: David Conrad <[email-masked]>
Date: Fri, 24 Apr 2009 17:28:54 -0700

> doubt that this approach is feasible for the general public.

Given existing tools, I more than agree.  However if someone were to  
come up with a full validating resolver for (most critically) WIndows  
that required NO (not minimal, not easy, _no_) configuration for the  
normal case (a la Nominum's CNS) and which automatically fetched/ 
updated the root (or ITAR) trust anchor(s) in a secure(ish) fashion,  
the general public wouldn't even be aware they were using secure DNS.   
This is how it must be if we expect any level of security and  
penetration.

Of course, stupid DNS games played by hotspot providers makes this  
essentially impossible right now...

Regards,
-drc

---

From: "George Barwood" <[email-masked]>
Date: Sat, 25 Apr 2009 06:59:51 +0100

Andrew

> deployment tools with shiny new protocol knobs to turn.

I do wonder at some of the complacency being shown.
A couple of recent articles from The Register

<<

http://www.theregister.co.uk/2008/11/12/mockapetris_interview/

"An attack might be possible in five hours with the patch. That's much
better than the minutes an attack might have taken before but systems are
still not really protected. IT's bought time without solving the underlying
problem," Mockapetris told El Reg.

Mockapetris helped invent the DNS system in the 1980s. The original
intention was to get systems up and running and add security features later
but the process has proved far more protracted than he ever imagined.
Mockapetris now reckons DNSSec might eventually be applied in 2015 but given
he said five years ago that the technology would be "ubiquitous" by 2008 we
ought to treat such predictions with caution.

http://www.theregister.co.uk/2009/04/22/bandesco_cache_poisoning_attack/

One of Brazil's biggest banks has suffered an attack that redirected its
customers to fraudulent websites that attempted to steal passwords and
install malware, according to an unconfirmed report.

IMO we are fiddling while Rome burns.

We are not sure when DNSSEC will be fully deployed, but there is a real live
security problem here, and all of the options to fix it need to be explored.

If there is are options to fix this in less than 15 years, I think they
should be explored.

Personally I have deployed a resolver for myself personally and my company
that is not subject to spoofing, solving my problems today.

I would like to see such resolvers more generally available.

Official guidance from the IETF on this would help ( given than DNS is an
IETF standard ).

George Barwood

---

From: Alex Bligh <[email-masked]>
Date: Sat, 25 Apr 2009 08:43:34 +0100

> essentially impossible right now...

Stupid games played by hotspot providers would actually prove the case.
In your "no configuration Windows tool" scenario, a pretty box pops up
and says "Warning: your internet connection cannot be reliably secured"
and if you click "Advanced" it says "DNSSEC failure".

If / when the hotspot providers cease their stupid games so that at least
when you are paid up and logged on it correctly processes DNSSEC
(which is quite possible), this would only happen when being redirected
to their logon page.

IE surely interception and alteration of DNS is exactly what such a
tool should be seeking to identify?

Possibly slightly of topic, but it's ages since I looked at this, but
I had /thought/ that most hotspot providers did not futz with DNS any
more because various versions of Windows did not expire their DNS
cache properly, so the intercepted values (and values from earlier
sessions) stuck around. I had thought what they did was shut of access
on everything to anything outside their walled garden, did an HTTP
redirect on port 80 to their servers, but their resolving server
on port 53 would actually resolve external names correctly. This
explains why various methods of tunneling IP over DNS lookups
are more successful than one might have thought.

Alex

---

From: Florian Weimer <[email-masked]>
Date: Sun, 26 Apr 2009 11:19:00 +0200

* Shane Kerr:

> Well, except that one needs to actually sign the parent zone for
> there to be any point in putting a DS record in it, which *is* a lot
> more work.

It shouldn't be more work.  If you keep your keys online, it should
suffice to flip a switch in your primary name server.
(Implementations aren't quite there yet, though.)  You don't need any
external communication and any new interfaces for this step.  Once you
want to install a DS in the parent, it's going to be somewhat more
tricky.  The real fun starts if you want to publish DS records for
(many) child zones.  This used to be different when you were supposed
to keep your private key material off line, but times have changed.

To repeat, I think that any mechanism which requires new data in
parent zones is not much easier to implement than DNSSEC.

---

From: niels=[email-masked] (Niels Bakker)
Date: Sun, 26 Apr 2009 22:45:45 +0200

>suffice to flip a switch in your primary name server.
[..]
>This used to be different when you were supposed to keep your private 
>key material off line, but times have changed.

Wait, what?  Has the Internet really become a more secure place in the 
past 15 years?

	-- Niels.

--

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Apr 2009 11:20:17 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> (which is quite possible), this would only happen when being  

 From a security perspective, a UI that you habitually bypass is a  
disaster.   I *hope* nobody implements it like that.   It should be  
pretty easy to detect a hotspot redirect as a special event and do the  
right thing.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Apr 2009 09:39:57 -0400

Dear colleagues,

> I do wonder at some of the complacency being shown.

I want to make perfectly clear, since it apparently wasn't (I received
some other notes off-list about this as well) that my note was not
intended to be any kind of quasi-ruling on whether we should take on
this work.  I was instead intending to point out that the arguments so
far have been pretty weak.  

As I have been able to understand it, the primary argument in favour
of EDNS0 Ping (or 0x20, for that matter) is that it's easier to get
standardized and deployed than DNSSEC.  I don't find that argument
compelling:

    1.  Some people -- primarily, those who operate "infrastructure
    servers", for want of a better term -- are expressing considerable
    concern about the operational effects of the change.

    2.  None of these techniques have attracted anything that could be
    called consensus yet.  Instead, it appears there are two camps
    with some calling adoption actually harmful.

    3.  We have another technique (DNSSEC) that many people seem to
    think solves the same set of problems.  There is disagreement
    about the relative costs of the proposed techniques and DNSSEC
    deployment.  

    4.  DNSSEC is already standardized, and some deployment has
    started.

    5.  Others within the IETF might reasonably ask why we have
    multiple, redundant, 80% solutions for security problems that are
    already solved by an existing protocol.

The premises 1-5 make me think that the faster-and-cheaper claim about
these alternative techniques may be a stronger claim than is
warranted.  Since faster-and-cheaper is so far the only real premise
doing any work in the argument in favour of these alternative
techniques, if that premise isn't obviously true, then it's not
obvious we should take on the additional work.  This has nothing to do
with the merits of the individual approaches or anything like that:
it's an engineering trade-off question, where one has to ask whether
adding something new is a good idea given all other considerations.

If (3), above, is false -- that is, if any of these techniques solves
a problem that is currently not solved by DNSSEC -- then the arguments
change.  But so far, I haven't seen those arguing for the alternative
techniques on list making the claim that there's a hole in DNSSEC that
these alternatives can fill.  (There might be.)

In addition,

> security problem here, and all of the options to fix it need to be explored.

I find the above argument completely bizarre.  To beat the metaphor to
dealth, it's as though we're standing around in the midst of dozens of
pails of water, while Rome burns, and complaining that we don't have a
pail-refill protocol and we don't have any buckets of sand.  Also,
airlift helicopters haven't been invented.

One thing we could do is start using the water buckets we have.  We
have DNSSEC.  Rather than wringing our hands about not being sure when
DNSSEC will be fully deployed, _we could work on deploying it_.  We
could use the energy that this WG would direct into standardizing some
additional techniques, and direct that instead at deployment.  

All of that said, I want to be clear of two things.  First, my
personal reaction to any proposal that I suspect someone is going to
use is to publish an RFC for it, just because I think it better that
it be well documented somewhere and that different implementations do
the technique in the same way.  Second, even if I thought something
were a really bad idea, if the WG expressed a clear preference for that
same idea I would regard it as my duty to attempt to push it along the
appropriate IETF process (I'm aware that that's not strictly speaking
a duty WG chairs have -- it's just my approach to the task).

As a WG chair, it's also my duty to try to make sure the output of the
WG has some sort of coherence.  We decided that DNSSEC was done, and
we sent it out.  If we think it's either broken or undeployable, we
surely have a duty to do something about that.  The corollary, I
think, is that if we _don't_ think it's broken or undeployable, we
have an obligation to future users and deployers of the protocol not
to lard it with so many alternative security mechanisms that
interoperation is hard to achieve.

Best regards,

A

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Apr 2009 22:32:36 +0200

In your previous mail you wrote:

=> no [1]

=> only a very limited protection for pre-DNSSEC.

=> incrementally

=> consumer

=> no (the main operation issue with DNSSEC comes from EDNS so
EDNS-PING has the same)

=> no

=> no (we have no choice other than deploy DNSSEC). BTW I am willing
to review future versions of the document (IMHO it is not a bad idea,
it just does not provide a complete/efficient enough solution).
   
Regards

[email-masked]

PS [1]: I assume the unpredictability is well understood and will be
correctly implemented when I got proofs of the opposite...

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Apr 2009 11:43:48 +1000

> pretty easy to detect a hotspot redirect as a special event and do the  

	We should just stop trying to intercept things in hot spots
	and define a DHCP element that says where to go to register
	or did AAA do something like that.  I never followed AAA
	in enough detail to know.

	Yes it will take a few years for it to be wildly deployed
	but it is better than the stupid tricks being tried today
	which break lots of things.

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Apr 2009 23:04:00 -0500

> 	in enough detail to know.

"We" aren't intercepting DNS in hot spots.  I agree that it's the  
wrong thing to do, but the problem is that it's working, and when  
things work, it's hard to get the people benefiting from them to do  
something different, particularly when it requires coordinated  
deployment.   I think probably the guys at FON would be the ones to  
talk to if we want to do something through DHCP, but the problem is  
that we have very little to offer them unless Microsoft and Apple are  
willing to implement the other side of it.   Apple doesn't do DHCPv6,  
so it's going to be kind of hard to make progress there with a DHCPv6  
option.

So I agree in principle that what you are saying makes sense, but I  
don't see quite as clear a path forward as the one you suggest.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 29 Apr 2009 17:24:47 -0700

Ted and all,

  What do you recommend as a method of getting Microsoft and
Apple to cooperate with implementing DHCPv6?  What do you
also recommend that can be done if Microsoft and Apple are not
willing to cooperate on implementing DHCPv6, be done by providers
and/or Domain Name holders?  BTW, we have a solution that works
to prevent intercepting DNS, but I was interested in what you might
suggest as a solution....  We view the intercepting DNS as a security
breach and treat it accordingly.

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: Ted Lemon <[email-masked]>
Date: Wed, 29 Apr 2009 23:10:12 -0500

On Apr 29, 2009, at 7:24 PM, Jeffrey A. Williams wrote:
> Apple to cooperate with implementing DHCPv6?

Er, to be clear, Microsoft has an excellent DHCPv6 client  
implementation (possibly an excellent server as well, but I haven't  
tried it).   Apple's stated preference thus far, as I understand it  
(obviously I don't speak for them!), has been to use stateless  
autoconf and to extract other configuration information from RA  
packets.   Being a non-Apple employee, I have no information about  
Apple's plans with respect to DNSSEC validating resolvers in their end- 
user operating system offerings, although I will say that they are  
well-positioned to do so given their current name resolution  
implementation on Mac OS X.

In general, solutions to problems like this need to be driven by  
customer demand.  The U.S. government certainly did a very good thing  
when they drew a line in the sand and insisted that their vendors  
implement IPv6; I don't know how much influence that had on Microsoft  
and Apple implementing IPv6, but I'm sure it was a consideration.    
It's likely that the government could exert some influence here simply  
by being a customer that wants DNSSEC validating resolvers, and  
putting it into their procurement requirements.

> What do you also recommend that can be done if Microsoft and Apple  
> are not
> and/or Domain Name holders?

Boingo wireless and some of the other paid wifi hotspot vendors have  
clients they ask you to install on your computer, and they fall back  
to DNS capture if you don't use the client.   I don't know how these  
clients work, but perhaps a standards-based approach based on the same  
sort of technology would do the job.

If you were to use DHCP here, the DHCP authentication protocol already  
provides a viable solution in this case, since this is the one  
situation where you probably already have a shared secret that could  
be used.   In this case, the fact that Apple doesn't support DHCPv6  
natively might actually be an advantage, since you could install your  
own client without fear of interfering with the vendor's client.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 29 Apr 2009 22:14:10 -0700

Ted and all,

  Well Autoconfig has known security problems and should be
avoided.  So given your response, you don't have a recommendation.
Thank you for clarifying that.  BTW, in accordance with your
response below, "Well positioned" is a far cry from anything
resembling implementation or something that "Could" be
implemented.  Microsoft does not support RFC 3118. Microsofts
DHCPv6 is quite error prone and as such demonstrates pretty
clearly it's not yet ready for prime time use...  As such MS
platforms or client services are an obvious security problem
that begs a immediate and private industry solution if critical
and sensitive data is to be transported or transmitted over an IPv6
network safely.  Non-critical or non-sensitive data would be ok
for either Apple or MS platforms, but one would need to recognize
that at end points such data would be of questionable accuracy and
may contain various other harmful records that would cause other
data integraty and platform security problems of perhaps unknown
types and as such would be difficult to safely, if at all, erradicate
fully.

Regards,