Subject: [dnsext] Forgery resilience and meeting in Stockholm

From: Andrew Sullivan <[email-masked]>
Date: Fri, 8 May 2009 14:14:22 -0400

Dear colleagues,

Your Chairs have been observing the discussion around adoption of
various drafts for techniques to mitigate forgeries and cache
poisoning.  It appears to us that the WG is not converging on
consensus.

We currently have a request open to adopt EDNS0 ping.  The discussion
of adopting the document appeared to expose a fault in the community,
where some expressed strong opposition to undertaking any further forgery
resilience work when DNSSEC is already available, while others argued
that DNSSEC is not getting deployed and therefore we need other urgent
action.

Meanwhile, some other mechanisms, including "0x20" and those outlined
in draft-wijngaards-dnsext-resolver-side-mitigation-01.txt seem to be
showing up in various implementations.

We think it would be better if we came to some more or less shared
agreement on what to do in this space (including nothing).  The
portion of the meeting we had in Dublin that was dedicated to this
topic seems not to have inspired consensus.  Therefore, we would like
to present five options for consideration:

1.  Do nothing, and take all energy that might be devoted to this
effort and direct it towards DNSSEC deployment.

2.  Adopt draft-wijngaards-dnsext-resolver-side-mitigation-01.txt, and
include in it recommendations to do nothing else except what that
document contains.  Remove from section 3 any strategies we do not
want to adopt.  (Note that this latter condition entails decisions
about the next two options.)

3.  Adopt draft-vixie-dnsext-dns0x20-00.  If we do (2), then perhaps
this gets included in that document, or perhaps it proceeds as part of
a set of documents.  Let's leave the editorial process issues out of
the discussion, and just focus on whether we want to include this
strategy in the tool box.

4.  Adopt draft-hubert-ulevitch-edns-ping-01.txt.  As in (3), this
might be included as part of (2) or processed individually, but that
doesn't matter.

5.  Officially adopt nothing, but support (2) and (3) going ahead as
individual submissions on the Informational track.  (2) would
obviously need to be modified slightly to keep out any protocol items
that might be entailed.  The reason (4) can't just go ahead on the
individual track is that the assignment of an EDNS0 code point
requires standards action, so the work would come back here anyway.

We will plan to request a meeting session in Stockholm to discuss this
issue (and possibly some other topics before us).  If the WG can come
to a clear consensus on-list before then (and we have no other
business), then obviously we will be in a position to cancel the
Stockholm session.  If we have not come to a conclusion by 20 May, we
will keep the session scheduled.

In the absence of strong arguments in favour of action and at least an
apparently broad constituency to do the work within the WG, the Chairs
are inclined to take option (1), because the WG is supposed to be
sleeping.  This is by no means to say that we are prejudiced in favour
of that option.  It is rather to say that we are procedurally bound,
by our charter, to a default of "No" for at least some of these
documents.  Adding a new standards-track item to the WG work requires
rechartering, please note, and given one other request we have open we
may therefore need to recharter anyway.

Best regards,

Olafur and Andrew

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

--
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: Fri, 8 May 2009 14:26:45 -0700

> about the next two options.)

I'd argue against one, simply because in 2 there are some really key  
ideas, especially in section 3.2 and 3.3.

Notably, 3.2 and 3.3 (or variant approaches) eliminate the race-until- 
win nature of out-of-path attacks, which increase attacker complexity  
in time rather than packets.

They also only directly affect resolvers from a protocol viewpoint  
(all the additional queries are within specification), and the only  
open questions are those of load on authorities and the additional  
queries from resolvers.

Preliminary evaluations I did on a slightly different way of phrasing  
3.3 suggested that the load magnification was tolerable, and if  
desired, I could investigate doing a more comprehensive analysis of  
the increased load on various portions of the resolution chain.

---

From: bert hubert <[email-masked]>
Date: Sun, 10 May 2009 22:19:26 +0200

> effort and direct it towards DNSSEC deployment.

This seems rather grand. Quite a number of people are interested in
low hanging fruit kind of improvements versus the world of complexity
known as DNSSEC. Not investing in EDNS0 and other measures will not
necessarily mean a significant boost to DNSSEC work.

Furthermore, as is well known (although sometimes denied) DNSSEC
remains just as vulnerable to spoofing at the delegation point as
normal DNS. The difference is that with DNSSEC, spoofing at that level
only leads to prolonged downtime.

In other words, DNSSEC benefits from EDNS0 in a significant way.

In reality, however much people feel progress is being made, DNSSEC is
still years and years, if not a decade, away.

If this WG declares consensus on 'doing nothing', it may prove prudent
as has been noted earlier, to proceed work elsewhere.

    Bert

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 11 May 2009 09:47:14 +0200

Hi Bert,

bert hubert wrote:
<snip off='Bert does not want DNSSEC' />
> only leads to prolonged downtime.

I am sorry, but spoofing at the delegation level does not lead to
prolonged downtime with DNSSEC.  Validators usually wait a short while
before the bogus data is flushed out of the cache, but this is not
'prolonged'.  Can you give details on this denial-of-service?

Best regards,
   Wouter

---

From: bert hubert <[email-masked]>
Date: Mon, 11 May 2009 10:14:30 +0200

> <snip off='Bert does not want DNSSEC' />

If you want to talk about it, that is fine. I indeed think that DNSSEC
won't ever be meaningfully deployed (auth, caches and stubs), and I
think everybody here is wasting his time and his organization's money
continuing the myth that DNSSEC will solve any real problem.

But I have no position on whether one should want the existence of
DNSSEC or not.

Verging over the edge of what should be discussed here, but I do want
to make it clear, I've been informed there are rumors I have a
financial incentive to derail DNSSEC

I am told that this is so because it would lose me business. This is
as far from the truth as can be. In fact, if anybody really wanted
DNSSEC in PowerDNS, I would have built it a long time ago.

In fact, if someone wants to sponsor this work, I'll do it gladly.
Sadly no one has stepped up, although sponsors have stepped up to
sponsor other features the industry is waiting for.

So everybody please believe me I am arguing for other security
measures simply because I think DNSSEC won't be deployed on any real
scale to make a difference.

> 'prolonged'.  Can you give details on this denial-of-service?

Take for example the DNSSEC signed .se zone, which provides excellent
security for www.dnssec.de:
dnssec.se.              86400   IN      NS      secondary.se.
dnssec.se.              86400   IN      NS      ns.dnssec.se.
dnssec.se.              86400   IN      NS      primary.se.
dnssec.se.              3600    IN      DS      2467 5 2
94DC01F2763CCB12F4B66AC63910830BC34082F6FE95CD75DAA3C5B3 7F99DD81
dnssec.se.              3600    IN      DS      2467 5 1
B318215EB224C094B638605C96ABAA6DF372CEFD
dnssec.se.              3600    IN      RRSIG   DS 5 2 3600
20090516111828 20090510001806 48006 se.
ZaLF6Rp2eDx1e39jeblBqNRiW5x08wuouTsptk/ztoEFyGmFzGU3SYtd
kyPjcni0X1N4MA5VWSZd4Zauzm6n+o5MwNyKRXezO+dpSTxjFW47Of7w
8hdqagGuFSwfsxTOvb1UyPKIjw4N5LijPWLfGdJpTXZjvu12sTcktdPt 8zE=

Or does it? The RRSIG covers only the DS records. I can easily
(well...) spoof the NS records at the delegation point and make them
point to any address of my choosing - leading to prolonged downtime.
No cryptography is involved, no bogus data.

Even more interesting, the DNSSEC signed .se zone does truly provide
excellent protection for domains that don't exist:
;www.dnssec-is-easy.se.         IN      A

;; AUTHORITY SECTION:
se.                     7200    IN      SOA
catcher-in-the-rye.nic.se. registry-default.nic.se. 2009051103 1800
1800 2419200 7200
se.                     7200    IN      RRSIG   SOA 5 1 172800
20090516201933 20090511061306 48006 se.
fCZuLwyfJrP+uGLlvRHeQjxI9VJwMTRi3xLWQCpfihcAtLkEVx6yolV1
se.                     7200    IN      NSEC    0-0.se. NS SOA TXT
RRSIG NSEC DNSKEY
se.                     7200    IN      RRSIG   NSEC 5 1 7200
20090517090715 20090510201806 48006 se.
ovDL7FOIBbMUaIWM8iH/UxTqWnnzMLSTg5Nvv/6+q2lqBgXGK3bAgOjj
dnssec-gotlandica.se.   7200    IN      NSEC    dnssectest.se. NS DS RRSIG NSEC
dnssec-gotlandica.se.   7200    IN      RRSIG   NSEC 5 2 7200
20090516015224 20090509201806 48006 se.
lY1t0wKdsaVyqqhXRflVeyh+P+SY2ZNdd8lXGgvvvCEMIz/36qPpdExO

This is completely protected, and I can't do anything interesting here
as an attacker. All .se's non-customers can feel secure!

A query for any other kind of domain in the DNSSEC signed .se zone
however is offered no protection at all:
;www.powerdns.se.               IN      A
powerdns.se.            86400   IN      NS      ns2.powerdns.se.
powerdns.se.            86400   IN      NS      ns1.powerdns.se.
powerdns.se.            7200    IN      NSEC    powerdoc.se. NS RRSIG NSEC
powerdns.se.            7200    IN      RRSIG   NSEC 5 2 7200
20090516052931 20090509161806 48006 se.
BQkQS3FSDWE5+TOVhYXcAo2zHZ3d8i1AgpyFmnM4vkSjHrnUZLD8wbS/

So even though the .SE people have turned on DNSSEC, 99% of their
domains have gained no protection at all.

Protection they would have had if EDNS0 or another measure were available.

     Bert

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 May 2009 11:15:53 +0200

> 'prolonged'.  Can you give details on this denial-of-service?

The DNSSEC model assumes that data from the validator is not fed back
into the recursor.  In fact, this is impossible if the validator runs
on the end system (along with the stub), and the upstream recursor has
fewer trust anchors than the end system.  It is possible to change the
model (and I think that's inevitable if it's determined that we need
DNSSEC soon), but I think that, officially, we still work under the
assumptioon validator == trusted, recursor == untrusted.

As an experiment with a valdiator/recursor combination in the same
process (where feedback is theoretically possible), I've installed a
trust anchor for www.bfk.de in Unbound 1.2.1 and BIND 9.6.0.
www.bfk.de is in a zone which is not signed, so both recursors return
SERVFAIL to queries for this name.  BIND seems to climb up to the root
from time to time, and queries all servers for bfk.de (but not for
. or de).  Unbound does not seem to perform additional upstream
transactions, even after waiting a few minutes between queries.  Of
course, this has to be taken with a grain of salt because usually, a
signed delegation will be involved (which is more difficult to test
for me).

I'm not sure which is better.  Aggressive querying further up the tree
might give you correct data, but increases DNS load globally
(especially if you publish bad data and the whole world starts
agressive probing).  It is also very difficult to implement in a way
that actually offers protection against attackers who can bypass
channel security, but have not full control over your communications.
On the other hand, not sending further queries means you rely on
channel security.

-- 
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: Matthijs Mekking <[email-masked]>
Date: Mon, 11 May 2009 11:26:29 +0200

Bert,

> No cryptography is involved, no bogus data.

Yes, you can still spoof the NS record. But if at the malicious server
no DNSKEY is found that:
1) matches the DS.
2) is properly signed.

, the data served from that server is handled as if it was bogus. Like
it should. So in order to successful spoof the delegation, you need to
have the private key of the child zone.

> catcher-in-the-rye.nic.se. registry-default.nic.se. 2009051103 1800

They have secured the domain names they are owner of. For TLDs, 99% of
the time they are not authoritative for their data: they mainly have
delegations.

Because .se don't own the zone powerdns.se., they don't own the zone
data, .se is in no position to secure the powerdns.se. zone. If it is
important for powerdns.se. to secure their zone data, they should turn
on DNSSEC as well. Luckily, .se provided that possibility for them!

Best regards,

Matthijs Mekking
NLnet Labs

---

From: bert hubert <[email-masked]>
Date: Mon, 11 May 2009 11:37:00 +0200

> Yes, you can still spoof the NS record. But if at the malicious server

Indeed, and this generates the downtime I mentioned. I am not talking
about inserting unauthenticated content. See also what Florian said
(with the aside he mentioned that he was talking about trust anchors
and not DS).

>> domains have gained no protection at all.
(...)
> data, .se is in no position to secure the powerdns.se. zone. If it is

Indeed - this is exactly my point, the design of DNSSEC precludes
securing a delegation to an unsigned zone. And this puts it
significantly apart form other approaches which confer 'automatic'
protection, albeit a less potent form.

And this is why I think we should now not steer away from EDNS0 or
Wouter's work, or other ways to improve DNS security in the short
term.

     Bert

---

From: [email-masked]
Date: Mon, 11 May 2009 09:41:49 +0000

> assumptioon validator == trusted, recursor == untrusted.

	not everyone agrees with or uses that particular model.

> On the other hand, not sending further queries means you rely on

	for a reasonable number of delegations, there is room
	and to spare for extra query load.  More agressive querying
	is inevitable.  As is better channel security.  This is not
	a zero-sum game.  Both will happen.

> Kriegsstra_e 100              tel: +49-721-96201-1

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 11 May 2009 12:05:31 +0200

> (with the aside he mentioned that he was talking about trust anchors

I have heard this so many times that I am getting little bit tired.

Yes, you can spoof NS records, but it is same in plain DNS and in DNSSEC
zone. It doesn't create any prolonged downtime as compared to plain DNS.

But the important thing is that you cannot get spoofed records from child
zone. And that's the reason for DNSSEC.

Ondrej
-- 
Ondrej Sury
technicky reditel/Chief Technical Officer
-----------------------------------------
CZ.NIC, z.s.p.o.  --  .cz domain registry
Americka 23,120 00 Praha 2,Czech Republic
mailto:[email-masked]  http://nic.cz/
sip:[email-masked] <[email-masked]> tel:+420.222745110
mob:+420.739013699     fax:+420.222745112
-----------------------------------------

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 11 May 2009 12:15:45 +0200

Unfortunately, you cut away the advantages I stated.

> (with the aside he mentioned that he was talking about trust anchors

The downtime is still better than ending up in giving away information
to the wrong guy, in my opinion.

> protection, albeit a less potent form.

I haven't seen any 'automatic' protection solutions yet. Even with
patching, it needs cooperation of many organizations in order to add the
extra security.

With DNSSEC, organizations have the opportunity to cryptographically
secure their data. If the root and all TLDs are signed, it makes the
process easier, although the organization has a workaround by using a
public trust anchor repository.

It would be nice that all resolvers also accept the security extension,
without ignoring it. Guess you found at least one person that wants
DNSSEC in PowerDNS ;-).

> Wouter's work, or other ways to improve DNS security in the short

For clarification, my e-mail was not advocating that we should steer
away from this work.

Matthijs

---

From: "Roy Arends" <[email-masked]>
Date: Mon, 11 May 2009 12:34:01 +0200

> only leads to prolonged downtime.

So with DNSSEC, the spoof is detected and protects the user from visiting 
a bogus site?

Regards,

Roy Arends
Sr. Researcher
Nominet UK

---

From: bert hubert <[email-masked]>
Date: Mon, 11 May 2009 12:47:12 +0200

> So with DNSSEC, the spoof is detected and protects the user from visiting

If we step back to beginning, you might find that I stated immediately
after the bit you quoted that even DNSSEC would benefit from EDNS-PING
or other measures.

"In other words, DNSSEC benefits from EDNS0[-PING] in a significant way."

Please do not see this as a 'battle' between DNSSEC and EDNS-PING.

The two have very different goals.

     Bert

---

From: Stefan Schmidt <[email-masked]>
Date: Mon, 11 May 2009 13:16:42 +0200

Hello Olafur, Andrew and all,

> effort and direct it towards DNSSEC deployment.

Clearly you mean development, for
"DNS operations are out of scope for the WG."

> requires standards action, so the work would come back here anyway.

I can only assume that by EDNS0 code point you mean an Option Code.

RFC2671 7 - IANA Considerations states
     IESG approval should be required to create new entries in the EDNS
     Extended Label Type or EDNS Version Number registries, while any
     published RFC (including Informational, Experimental, or BCP)
     should be grounds for allocation of an EDNS Option Code.

However as EDNS PING mandates authoritative and recursive server behaviour i
would rather see it on the standards track than anywhere else.

Actually i don't see the harm in adopting 2., 3. and 4. as they are rather
documenting the status quo and neither of these documents say DNSSEC should
not be deployed.
Let's remember we're engineers, not politicians.

	Stefan

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 May 2009 14:01:54 +0200

> (with the aside he mentioned that he was talking about trust anchors

I've hacked something together for a signed DS: resolver has trust
anchor for se, nic.se answers without any DNSSEC-related records,
query is for www.nic.se.

BIND 9.6.0 sends queries to each ns{,2,3}.nic.se server at a rate
which seems to be 1/(sum of RTTs), apparently based on feedback from
the validator to the recursor.  When I correct the broken delegation,
it starts returning correct answers immediately.  There are sporadic
queries to the .se servers, too (but the rate is in the centihertz
range, it seems).

Unbound 1.2.1 behaves according to a strict valdiator/recursor
separation.  The whole zone remains dead for an extended period of
time.  Cache misses ($RANDOM.nic.se) result in upstream queries, but
the SERVFAIL is sticky.  Perhaps it caches the non-existence of the
DNSKEY record?

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 May 2009 14:18:00 +0200

> might be included as part of (2) or processed individually, but that

Both drafts are not worth the WG's efforts, IMHO.

On the other hand, it seems to me that the current DNSSEC
implementations require a certain level of channel security to work
reliably.  If it turns out that source port randomization is really
not good enough, DNSSEC is affected as well (even if it's just a
denial of service).

---

From: [email-masked]
Date: Mon, 11 May 2009 12:31:46 +0000

> So with DNSSEC, the spoof is detected and protects the user from visiting 

	Roy, you know better than that... You shoul dhave stopped here:

	"So with DNSSEC, the spoof is detected"

	What happens -after- detection is up to the application/user.

--bill

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 11 May 2009 05:48:59 -0700

> Both drafts are not worth the WG's efforts, IMHO.

I can see such an argument against EDNS0-ping, but what is your  
argument against 0x20?

0x20 is just about as validated-as-you-can-get already within the  
current DNS operations.

> not good enough, DNSSEC is affected as well (even if it's just a

I don't think this denial of service is all that significant, because  
there are easy fallbacks for such failures to generate new requests  
(it sounds like thats what Bind does already), and any resolver with  
DNSSEC is still going to need source port randomization for all the  
stuff that isn't DNSSEC yet.

There are far better things for an attacker to do than waste 2^30+  
packets in that way.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 May 2009 15:14:37 +0200

> I can see such an argument against EDNS0-ping, but what is your

Among other things, it only adds two bits of security for ccTLDs, and
zero bits for the root.  Consequently, you need the full range of
cache hardening before 0x20 turns effective.  I find it hard to
believe that we'll see significant movement in that direction.  In
fact, I fear that EDNS0 PING is easier to implement.

[DNSSEC and channel security]

> I don't think this denial of service is all that significant,

If you actually need to send those 2**30 packets, I'd agree.  But who
knows if you have to for a particular network setup?

> because there are easy fallbacks for such failures to generate new
> requests (it sounds like thats what Bind does already)

I'm not sure if this is a feasible general strategy because it results
in high load for incorrectly signed zones (as observed with
isc.dlv.org, see Michael Graff, "Unplanned DLV zone outage on
2009-Apr-06", <[email-masked]>, posted to the dns-operations
mailing list).

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 11 May 2009 06:25:57 -0700

> knows if you have to for a particular network setup?

If its "no port randomization, full race-until-win, 2^16 packets",  
this would be a seriously broken DNS resolver.  How often do you  
expect such seriously broken DNS resolvers to properly implement DNSSEC?

And how many of those would be worth DoSing?

> 2009-Apr-06", <[email-masked]>, posted to the dns-operations

If you want DNSSEC deployed, mechanisms which punish incorrectly  
signed zones with significant load should be regarded as a feature,  
not a bug.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 May 2009 15:32:45 +0200

> signed zones with significant load should be regarded as a feature,

I think this joke in rather bad taste.  Certainly, fear of accidental
self-DoS (and not just zone unavailability, but actual packetting)
will not help deployment at all!

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 May 2009 14:28:26 +0000

> Date: Mon, 11 May 2009 09:47:14 +0200
> From: "W.C.A. Wijngaards" <[email-masked]>
> 

if dnssec isn't secure then we'll have to fix it.  but this would not be
an argument for dropping it in favour of hop-by-hop measures.  at best we
may have to do more hop-by-hop to make sure end-to-end is safe.  but for
the future of dns itself we need end-to-end security at whatever cost.

somebody pointed out to me a week ago that one of the kaminsky variants
works fine across a dnssec-secured delegation point where the parent and
child are both signed and the signatures are all valid, since the NS RRset
coming from the parent does not have signatures in the delegation response.
so, a query for $random.$victim opens a race window during which a poison
NS RRset could be inserted for $victim.  perhaps this is the flaw referred
to above.

i very much wish that i had learned the lesson of SRV naming more
completely.  had we put our NSEC[3]'s, RRSIG's and DS's at
_$type._DNSSEC.$object rather than at $object, they would be in-zone even
at delegation points, and the only ambiguity would be that the two NS
RRsets (one in parent, one in child) would each have its own RRSIG, and it
would be nec'y to remember the context in which it had been heard when
deciding what signature it had to match.  we would then be able to query
for them if they expire or are purged earlier than the objects they cover.
and more importantly after kaminsky's 2008 summer of fear, delegations
would all be signed.  i apologize for not thinking of this five years ago.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 May 2009 10:53:49 -0400

Dear colleagues,

This is just to clarify the options before us.  No decision is made;
neither is any bias implied.

> "DNS operations are out of scope for the WG."

No, we meant deployment.  It means that there would not be work for
_this working group_ to do.  We labour under the assumption that the
talented, DNSSEC-clueful participants in this WG would direct their
energies towards deployment if they did not have this WG distracting
them with new protocols to develop.  This is perhaps a faulty
assumption.  

In any case, we have heard more than once that people outside the
DNSEXT WG are waiting for the DNS weenies to settle finally on
something, so they can deploy whatever they're going to deploy only
once.  I don't know whether that is true, but supposing it is, that
might be another way of directing energy towards deployment (again,
without this WG actually doing anything.  Standing still and being
silent is also doing something, after all).

> I can only assume that by EDNS0 code point you mean an Option Code.

Yes.  This mistake in wording is my fault, not Olafur's.  I should
have been more precise.  My apologies, and thank you for the clarification.

A

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 May 2009 14:51:15 +0000

> From: bert hubert <[email-masked]>
> Date: Mon, 11 May 2009 12:47:12 +0200
> ...

my reasons for not pursuing a longer QID during the original EDNS work, and
my reasons for not pursuing an optional QID extension during kaminsky's 2008
summer of fear, are that EDNS is always optional, and always has fallback,
and the only state storage is a recommendation not a requirement, and that
recommendation has symmetric value to requestors and responders.  i'm sorry
that i've been somewhat pissy about the people who assume i was ignorant of
the need for a larger QID when EDNS was prepared, or that the omission was
not completely deliberate on my part.  i'll try to adopt a better tone.

my reasons for not supporting the EDNS0 PING work is that it changes all of
those things.  folks who worry about the extra traffic from the extra queries
when EDNS0 PING is ignored are missing an even larger problem, which is that
in a rapidly changing zone (for example where the target RRset changes on
every query, with corresponding monotonic increases in SOA.SERIAL) will never
converge.  so even if every initiator was willing to add mandatory state for
a requery when a response came back without EDNS0 PING (which isn't likely)
we'd be faced with undefined conditions.  in other words if a response comes
back without EDNS0 PING then you still have to believe it -- so why bother?

however, i am intrigued by what bert said above about DNSSEC benefitting from
something like EDNS0 PING.  what if instead of the DO bit, the signalling
for DNSSEC awareness had been a DO+PING?  i think it's early enough in the
deployment of DNSSEC that a new rule like "delegation responses from servers
who don't also answer PING will cause a requery, and if the responses aren't
the same, return SERVFAIL for now and try again later."  note that this makes
the dangerous assumption that NS RRsets won't delta on every response in the
way that other RRsets are known to do.  that may be fatally overoptimistic
and i am not myself sure whether i'm in favour of this idea.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 May 2009 17:10:45 +0200

> NS RRset could be inserted for $victim.  perhaps this is the flaw referred

All data is signed somewhere, so you could use DNSSEC to detect this.
It's difficult to get this right without running in too many circles,
but it should be be possible if it is done early (that is, not just
when validation fails).

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 11 May 2009 08:21:28 -0700

> will not help deployment at all!

This actually isn't entirely a joke.

If DNSSEC is to do anything at all, such a case would be a DOS anyway:  
you names just don't resolve.  Otherwise, why have DNSSEC on the  
resolver at all if you simply ignore signature failures?!?

It is this silent failure on misconfiguration/screwup is the real DOS  
worry: its incredibly frustrating to get "your name isn't resolving"  
as feedback but no idea why.  As the author of a deliberately standard- 
incompliant DNS authority, trust me on this...

At least if the site sees load as a result of the screwup, this acts  
as an implicit notification that there is a problem, which is far more  
useful than a silent failure.

Anyway, with an exponential backoff on retries, this isn't a real DoS  
anyway, just really enough to get your attention, unless you are a  
really really big site and running on the ragged edge.

Likewise, proposals which cause load on those who don't sign at all  
really should be viewed as features: explicit punishment for not  
upgrading to DNSSEC is one of the biggest incentives for people to  
want to deploy DNSSEC, especially when deploying DNSSEC wrong IS a DoS  
of your name.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 May 2009 15:29:46 +0000

> From: Florian Weimer <[email-masked]>
> Date: Mon, 11 May 2009 17:10:45 +0200
> 
> * Paul Vixie:
> 
> > works fine across a dnssec-secured delegation point where the parent
> > and child are both signed and the signatures are all valid, since the
> > NS RRset coming from the parent does not have signatures in the
> > delegation response.  so, a query for $random.$victim opens a race
> > window during which a poison NS RRset could be inserted for $victim.
> > perhaps this is the flaw referred to above.
> 

sadly, the data in this case is not signed anywhere.  there's no "empty DS"
in a delegation to tell a validator that a delegation isn't signed.  the
way DNSSEC expresses an unsigned delegation is an NS RRset in the authority
section, which can be substituted by an kaminsky-inspired attacker.  there
may not be any DNSSEC data at the child.  so there's no way for a validator
to differentiate between a legitimate unsigned delegation, as against a
poisoned unsigned delegation designed to replace a legitimate
signed/unsigned delegation.

> but it should be be possible if it is done early (that is, not just

after reading the rest of this thread i agree with bert that this problem
exists.  however, i also agree with roy that this is a corner case and does
not by itself invalidate the DNSSEC model.  there are two benefits to
DNSSEC, one being to protect the infrastructure (which includes the
delegation chain) and one is to enable a new class of internet applications
who behave differently in the presence of end-to-end dns security (such as
a new way of deciding whether to trust an SSL key).  it's sad that we have
to believe an unsigned delegation even though it could be spoofed.  but a
signed delegation leading to provably authentic data is still in force.

also, source port randomization more or less rules this attack out.  do i
wish we had a longer QID?  you betcha.  will i lose sleep over it?  not so.

if somebody *is* losing sleep over this, then channel (hop by hop) security
is only one possible option.  and DNSSEC-only channel security (like DO+PING)
should be considered, since this is a DNSSEC problem.

by the way, ed lewis kindly pointed out that my SRV-related message had the
wrong number of labels in its example.  i meant to say that if all DNSSEC
metadata were under a _DNSSEC subdomain at the zone apex, then none of it
would share nodes with children or with the targets.  so instead of a DS RR
at "DNSSEC.SE" there would be a DS RR at DNSSEC._DNSSEC.SE.  and there
would be an RRSIG RR at DNSSEC._DNSSEC.SE covering the NS RR at DNSSEC.SE
in the .SE zone.  sorry for being fast and loose before.  and note that
this is not a proposal for changing DNSSEC, so much as denoting a missed
opportunity.  (the _DNSSEC subdomain would never be a delegation point, nor
have delegation points below it, and it would always be at the zone apex.)

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 11 May 2009 11:31:26 -0400

>would all be signed.  i apologize for not thinking of this five years ago.

Historical note:
This is similar to what NO draft proposed:
         http://tools.ietf.org/html/draft-ietf-dnsext-not-existing-rr-01

         Olafur

---

From: [email-masked]
Date: Mon, 11 May 2009 15:28:10 +0000

On Mon, May 11, 2009 at 02:28:26PM +0000, Paul Vixie wrote:
> i very much wish that i had learned the lesson of SRV naming more completely.

	good thing you never stop learning.

> i apologize for not thinking of this five years ago.

	you are not personally responsible here. the design model was fixed
	last century - so the haq you enumerated only corrects someof the
	symptoms.  To truely correct the problem, DNSSEC should have RRset
	granularity, not zone granularity... but thats a much larger discussion.

--bill

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 May 2009 17:59:05 +0200

* Paul Vixie:

> in a delegation to tell a validator that a delegation isn't signed.

Huh?  There's an NSEC with no bit set for the DS RRset.  Are you sure
you don't look at it when validating?  I can't believe this.

(I think this has been proposed as the "SO" variant of DNSSEC.)

> the way DNSSEC expresses an unsigned delegation is an NS RRset in
> the authority section, which can be substituted by an
> kaminsky-inspired attacker.  there may not be any DNSSEC data at the
> child.  so there's no way for a validator to differentiate between a
> legitimate unsigned delegation, as against a poisoned unsigned
> delegation designed to replace a legitimate signed/unsigned
> delegation.

Right, DNSSEC does not offer any protection for zones which aren't
signed.  However, you can make attacks somewhat harder if you validate
the NS set of the parent zone (including its addresses), to make sure
that you get the data from the right place.  This would defuse one
Kaminsky-style attack where you target the authority information in
the parent zone (which you'll never notice if the attacker dutifully
answers with correct DNSSEC data to queries with the DO bit---so
perhaps "always set DO" isn't such a bad policy after all).

So with careful resolver implementation, there is *some* benefit for
unsigned children of signed parents, too.

> not by itself invalidate the DNSSEC model.

Yes.  We only have a problem if implementors refuse to work around it,
and it turns out that the level of channel security we've got is not
sufficient.

> there are two benefits to DNSSEC, one being to protect the
> infrastructure (which includes the delegation chain)

And we need it.

> and one is to enable a new class of internet applications who behave
> differently in the presence of end-to-end dns security (such as a
> new way of deciding whether to trust an SSL key).

Masataka Ohta offered a very succinct answer to such claims about new
applications:

| 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.

I think he's right with regard to new applications, but he's wrong as
far as infrastructure protection is concerned.

> in the .SE zone.

Yes, this makes more sense, I suspected this.  The major benefit would
have been that you could delegate _DNSSEC.SE to a different server and
offload any DNSSEC-related activity from your main, production
servers.

(We still could have something similar with a DLV+NS combo.)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 May 2009 18:47:32 +0000

> Date: Mon, 11 May 2009 17:59:05 +0200
> ...
> > sadly, the data in this case is not signed anywhere.  there's no "empty
> > DS" in a delegation to tell a validator that a delegation isn't signed.
> 

i am not sure, no.  but the person who told me to worry about this is more
of a dnssec protocol expert than me, and so i'd like others here to chime
in on this question.

---

From: Matt Larson <[email-masked]>
Date: Mon, 11 May 2009 15:53:08 -0400

> of a dnssec protocol expert than me, and so i'd like others here to chime

I'm not understanding your original comment, either, Paul.  A referral
to an unsigned delegation includes a signed NSEC with no DS bit as
Florian described, which is an unambiguous assertion that the
delegation exists and is unsigned.  The situation is similar but not
exactly the same in an NSEC3/Opt-Out zone, where the NSEC3 record(s)
prove only that the delegation is unsigned.  (I.e., it is possible to
spoof an unsigned delegation into existence in an Opt-Out zone.)

Matt

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 May 2009 21:09:51 +0000

> Date: Mon, 11 May 2009 15:53:08 -0400
> From: Matt Larson <[email-masked]>
> 
> I'm not understanding your original comment, either, Paul.  A referral to
> an unsigned delegation includes a signed NSEC with no DS bit as Florian
> described, which is an unambiguous assertion that the delegation exists
> and is unsigned.  The situation is similar but not exactly the same in an
> NSEC3/Opt-Out zone, where the NSEC3 record(s) prove only that the
> delegation is unsigned.  (I.e., it is possible to spoof an unsigned
> delegation into existence in an Opt-Out zone.)

so, a MiTM could in this case substitute different nameservers for the real
ones and so this case (unsigned delegation) is not protected by DNSSEC.
that's not news and it's not the end of the world.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 May 2009 09:29:03 +1000

> signed/unsigned delegation.

	If there is no DS then there *is* a NSEC/NSEC3 RRset which
	indicates the delegation isn't signed or is in a optout
	range.
 
	This is not to say the NS and glue address records in a
	delgation can't be spoofed.

	I have said before that the delegating NS RRset and glue
	records in a signed parent zone should also be signed.  This
	allows the delegation to be validated before it is followed.
	This also allows for arbitary glue to be used and all
	possible delegation models to be supported as you now have
	a mechanism to chase back bad glue to the source.

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

---

From: Bert <[email-masked]>
Date: Mon, 11 May 2009 10:33:49 +0200

> <snip off='Bert does not want DNSSEC' />

But Bert does...

--Bert's secretary
   http://bert.secret-wg.org/Root/

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 May 2009 18:21:00 +0300

On 11-May-2009, at 16:14, Florian Weimer wrote:

> zero bits for the root.

This is only true if the QNAME is only . or <cctld>.

Spoofing responses for those names is a concern, but I would posit  
that those queries are pretty rare for most resolvers. Much more  
likely that someone is looking for ticketmaster.ca. than just ca. or  
just ".". 0x20 adds as many bits as their are characters in all labels  
of the QNAME.

> In fact, I fear that EDNS0 PING is easier to implement.

ENDS0 ping has the potential to expose a wide user base for whom  
either EDNS0 or a network which doesn't make 20-year-old inferences  
from the size of a UDP DNS packet (or both) are not available.

Shane and I once did some work on coming up with some real-world  
metrics for EDNS0 support, but we got distracted and didn't follow up.  
We should do that.

I don't know how to measure the impact of broken firewalls, but I'd  
really like to.

Joe

---

From: Florian Weimer <[email-masked]>
Date: Wed, 13 May 2009 17:42:28 +0200

> This is only true if the QNAME is only . or <cctld>.

There's also 123. or 1234.EXAMPLE.  Unfortunately, there's an
unlimited supply of those names.

> just ".". 0x20 adds as many bits as their are characters in all labels

You also need to protect against bad data in the authority and
additional sections of a response to 12345.EXAMPLE.  This is the part
which is hard to implement.  It makes some sense to do this even
without 0x20 because it prevents a particular style of TTL evasion,
and Unbound already does this (I think---perhaps not by default).
Other resolvers don't.

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 May 2009 18:48:31 +0300

> unlimited supply of those names.

So are you saying that there's no point specifying something unless it  
will surpass a threshold of usefulness for all possible QNAMEs?

Or are you saying that most QNAMEs are numeric, or otherwise don't  
benefit from 0x20?

Or something else?

Just trying to understand your objection.

Joe

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 May 2009 17:55:48 +0200

All,

> metrics for EDNS0 support, but we got distracted and didn't follow up.  

Oh yeah. :)

We did see that most name servers supported EDNS0, but only about half
of the domains did.

My wild-ass-guess is that lots of people hosting lots of domains use
can't fit them in RAM, so they use either tinydns or home-brew software,
neither of which are likely to implement something as modern as EDNS0.

> I don't know how to measure the impact of broken firewalls, but I'd  

We could do something like putting an image on a popular web page
(perhaps icann.org) which is something like:

http://www.edns0-domain.icann.org/0.jpg

The edns0-domain.icann.org site could be delegated like this:

edns0-domain.icann.org. NS ns1.edns0-only.info.
                        NS ns2.edns0-only.info.

We could then set up ns[12].edns-only.info to *only* answer queries with
EDNS0 enabled. Then we measure the number of HTML pages retrieved, and
the number of JPG retrieved. We can can also throw a JPG from a site
that does not require EDNS0, for comparison.

This would give some rough indication of the impact of EDNS0 in the real
world.

Just an idea. :-P

--
Shane

---

From: Florian Weimer <[email-masked]>
Date: Wed, 13 May 2009 17:59:36 +0200

> will surpass a threshold of usefulness for all possible QNAMEs?

A succesfull attack piggybacked on 1234.EXAMPLE. also affects
BIGCORP.EXAMPLE., not just 1234.EXAMPLE. and its children.  Something
like this:

;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40853
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;1234.example.                  IN      A

;; ANSWER SECTION:
1234.example.           172800  IN      A       192.0.2.1

;; AUTHORITY SECTION:
example.               1728000  IN      NS      evil.example.net.

;; ADDITIONAL SECTION:
evil.example.net.      1728000  IN      A       192.0.2.2

If the resolver updates its cache from the authority section (which it
traditionally does), EVIL.EXAMPLE.NET. has gained controlled over
EXAMPLE., including BIGCORP.EXAMPLE.

It does not matter if 1234.EXAMPLE. actually exist, you only need
successful spoofing (whose possibility we can assume for the sake of
argument, otherwise why bother about 0x20?).

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 May 2009 18:05:56 +0200

> Just trying to understand your objection.

Me too.

Root gets no extra protection. We get it. Really. It makes sense.

Yes we know that DNSSEC is the best solution. Yes we should encourage
people to sign their domains and encourage people to run validating
resolvers.

None of this means that 0x20 should not be adopted. 0x20 helps where it
helps, and doesn't help in other places. We should adopt it because it
improves security with a minimal cost.

Full disclosure: my vanity domain has 17 alphabetic characters, so I
would be *thrilled* at the extra 17 bits of entropy. Finally a benefit
to such a cumbersome name!!! :)

--
Shane

---

From: Florian Weimer <[email-masked]>
Date: Wed, 13 May 2009 18:17:55 +0200

> This would give some rough indication of the impact of EDNS0 in the real

It's totally legitimate to switch on EDNS0 only if you need it (after
receiving a truncated response, or for setting the DO bit).  So the
results will certainly be misleading.

I think you'd be measuring an uninteresting number anyway.  You'd need
to stuff EDNS0 responses so that they exceed some reasonable limit
(1500 bytes), while responding to non-EDNS0 queries with something in
the 512 byte window.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 May 2009 16:44:28 +0000

because dns-0x20 only asks that a interpretation of 1035 be relaxed that
nobody was interpretting the other way anyhow, and only affects recursive
servers who want to deploy it, it's a very low cost proposal.  i'm in
favour of adopting it as a WG item independent of anything else we do or
don't do for hop-by-hop or end-to-end security.

(if not for the need to relax an interpretation of 1035, this could be a
BCP or FYI or experimental, rather than a standards track RFC.)

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 13 May 2009 09:43:10 -0700

Shane and all,

  I concur.  But than again I did some 7 years ago and implimented
accordingly.  Seems ICANN et., al., is behind the curve as usual.

 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: Nicholas Weaver <[email-masked]>
Date: Wed, 13 May 2009 15:24:19 -0700

On May 13, 2009, at 8:21 AM, Joe Abley wrote:

> just ".". 0x20 adds as many bits as their are characters in all  
> labels of the QNAME.

Except that an attacker targeting the auth record for .ca would query  
as 123.ca, 124.ca, 125.ca etc.

So that is a valid complaint.

---

From: "Antoin Verschuren" <[email-masked]>
Date: Thu, 14 May 2009 10:55:34 +0200

0x20 helps in some cases, but at a small cost.
It's a cost we can avoid if we deploy DNSSEC.
Being Dutch and on the penny :-), I'm in favor of saving every penny we can.

To be more precise, the cost of 0x20 is:
-Increased complexity of the protocol, meaning harder to debug and to understand DNS
-once deployed, no future protocol extension that needs the case (in)sensivity can be deployed
-Increased code and computation

All of this on top of the cost of DNSSEC.

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/

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Shane Kerr
> Sent: Wednesday, May 13, 2009 6:06 PM
> To: namedroppers
> Subject: Desperate plea for 0x20, was Re: [dnsext] Forgery resilience and
> meeting in Stockholm
>

---

From: "Antoin Verschuren" <[email-masked]>
Date: Thu, 14 May 2009 11:13:04 +0200

If it's real World numbers you're after, isn't DSC computing these correctly then ?
See f.e http://public.dsc.dns-oarc.net/grapher?plot=edns_version&server=ns-ext.isc.org
Don't know how they are computed, but when I look in one of the graphs of DSC for the .nl infrastructure, I see that DSC reports that about 50% is doing EDNS0 and 50% is doing No EDNS. I assume this is mostly recursive resolvers, not stubs, which is even more worrisome, although some part may be due to botnet scripts.

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

> [email-masked]] On Behalf Of Florian Weimer
> Sent: Wednesday, May 13, 2009 6:18 PM
> To: Shane Kerr
> Cc: Joe Abley; [email-masked]
> Subject: Re: [dnsext] Forgery resilience and meeting in Stockholm
> 
> * Shane Kerr:
>

---

From: Federico Lucifredi <[email-masked]>
Date: Thu, 14 May 2009 23:59:29 -0400

[ 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. ]

At athe cost of sounding flame-y (not my intention), I must point out
that as far as complexity and pennies go, DNSSEC is the unrivaled champion.

Yes, apparently we have no better solution (maybe DNSCURVE? I have not
looked at that yet), but arguments against cheap hardening based on
trivial coat and overhead (compared to DNSSEC) seem very unfair.

 Best -F

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

---

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

> don't do for hop-by-hop or end-to-end security.

0x20 has a hidden cost: If you include 0x20 as a supported feature in
a resolver, any phenomen which allows you to spoof under a different
QNAME/QTYPE combination is a security vulnerability because it breaks
the additional protection offered by 0x20.

Both your draft and the paper provide no indication how to deal with
this problem, unfortunately.

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 20 May 2009 16:58:16 +0200

A bit late, but whatever, here is my input:

> effort and direct it towards DNSSEC deployment.

no.

> about the next two options.)

Wouter's draft is a good summary, especially the re-query for RRSETs
learned from the Auth section. Definitely adopt it.

> strategy in the tool box.

Just try to get the server side written down somewhere. That doesn't add
any cost, and leaves the option to do the client part open.

> might be included as part of (2) or processed individually, but that

The draft as it stands is far from perfect, but the generic idea that we
should try to somehow extend the query-ID is a very worthwhile one.

IMHO there are a few different aspects to this:

* The server-side is rather trivial, the only question is whether to
  go for a stateless or a stateful design on the server.

* Use a new pseudo-RR or go for an EDNS0 option.

What I'm really missing is a clear cut description on the client side
algorithm and fall-back strategies.

These huge email threads here have included both interesting schemes and
assertions that this is impossible to get right. That's not good basis for
a decisions, I'd really like to have a concrete proposal on the algorithm
so that any attacks against it can be properly documented and examined.

As with 0x20, I'm not sure whether we shouldn't split it up in a short
and relatively painless (and not just informational) spec on what that
extended qID looks on the wire and what the server-side is supposed to do,
and an informational/experimental draft on how this can be leveraged to
increase the security by the client.

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

---

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

With less than one day left before the chairs need to make a determination.
The purpose of this message is to point out that the discussion has
possibly been derailed by heated arguments about the merits of a subset of the
options, at the detriment of other options.

At this point we have enough support to say EDNS0 Ping is acceptable for
further study, even though there is a large number detractors.
(option #4)

It is close call for option #3 x20

There is no public support for option #2, and no one has argued for option #1.

If you are in favor of options #1, #2 or #5 now is the time to speak up.

As an experiment I have set up a poll for the different options,
http://www.doodle.com/7yvife73qvwtnr5m

Feel free to post to namedroppers or participate in the pool.
When you participate in the poll use a name that I can correlate to
a namedroppers subscription i.e. no AB or BA names.

thanks
         Olafur

    Olafur

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 May 2009 15:34:35 +0000

i'm in favour of option #6 (TKEY-DH plus TSIG) and i'm willing to write it up.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 20 May 2009 09:00:37 -0700

> i'm in favour of option #6 (TKEY-DH plus TSIG) and i'm willing to  

Note please that much of what is in option #2 (Wooter's draft) with  
regard to glue policy is orthoginal to the increasing of entropy.

Additionally, there are multiple DNS resolvers which implement such  
more paranoid glue policies.

I would appreciate that this discussion be separated from the other  
portions of the debate on mechanisms to increase query entropy and/or  
secure the communication channel which represent protocol extensions.

---

From: Peter Koch <[email-masked]>
Date: Thu, 21 May 2009 23:47:53 +0200

> to present five options for consideration:

Not sure that these five make the right "partitioning" of the problem space,
but it's hard enough already.

> effort and direct it towards DNSSEC deployment.

Essentially this is probably the best option, even though the "energy" in or of
this group is likely neither necessary nor sufficient to aid DNSSEC deployment.
At some point, one needs to consider a protocol done.  If deployment is slow,
creating more distraction by presenting a plethora of "alternatives" is
not going to accelerate the effort but will rather have a negative effect.

> about the next two options.)

Addressing the tactics used in the summer 2008 attack scenarios is an achievable
and worthwile goal, so I'd like to see this draft being worked on.
However, I believe that some of the tactics(!) presented and documented
in the draft have side effects on a global scale and are potentially
harmful.  As examples, I consider both RTT banding and explicit NS RRSet
queries as "challenging", to put it mildly.
It is extremely important that the overall architecture and operational
environment not be changed lightly.

> strategy in the tool box.

With my response to (2), this could and should be postponed to the discussion
of the 'resolver side mitigation' draft.  Documenting the hack would be
nice, but I'm not supportive of deployment of 0x20.

> might be included as part of (2) or processed individually, but that

I believe the situation is different from (3) as this is not "resolver side"
mitigation only.  As I stated in an earlier mail, the draft itself doesn't
do much more than "reserve" a code point.  Judging from other sources
and the list discussion, an EDNS based QID space extension is clear and
straightforward. However, the downgrade vector and the general issue
of hop-by-hop vs end-to-end security don't let me sympathize here. 

> documents.  Adding a new standards-track item to the WG work requires

Not that this would make much of a difference, but resolver side mitigation might
be more of a BCP than a Standards Track document.

-Peter

PS: I've also responded to the doodle poll, but I am a bit confused by
    "This is a experiment for the working group to vote w/o posting to mailing list.
     In particular this is to cut down on +1 and -1 messages"
    Hopefully the term "vote" was a clerical error.

---

From: [email-masked]
Date: Thu, 21 May 2009 22:31:54 +0000

> not going to accelerate the effort but will rather have a negative effect.

	beg to differ.  if deployment is slow and the gravity well too deep,
	one might ask why? truely useful things seem to spread like wildfire...
	warts and all. which argues for encouraging alternatives.

>     Hopefully the term "vote" was a clerical error.

+1 :)

--bill

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 May 2009 16:20:01 -0700

> 	warts and all. which argues for encouraging alternatives.

This would be a great argument in a comparison of apples and apples.    
For instance, protocols like Skype's proprietary VoIP protocol have  
indeed spread far and wide not because the IETF pushed them, but  
because customers adopted them.   HTTP spread similarly.   SSH and SSL  
as well.

What's the difference?   I can turn up Skype or ssh or http or ssl any  
time I want simply by installing an http server or a copy of skype or  
what have you on my own machines.   I don't need anyone else's  
cooperation.   If the protocol proves popular, lots of people will  
turn it up on their individual machines, and life will be good.

Contrariwise, the IETF has completed a number of protocol suites  
recently that don't have this quality.  You can't simply turn up  
DNSSEC on your own servers and get value out of it.   Without the  
infrastructure, DNSSEC isn't helpful.   This is also true of IPv6, and  
is one of the reasons why IPv6 adoption is slow.

The problem is that stuff that can be turned up unilaterally does, as  
you say, spread like wildfire if it is useful.   Stuff that requires  
massive cooperation between people with competing interests doesn't  
spread like wildfire, whether it's useful or not.   Deploying stuff  
like this is hard, and takes concentrated effort over time.   The fact  
that it isn't spreading like wildfire, therefore, is no reason to  
claim that it is not useful.

---

From: [email-masked]
Date: Fri, 22 May 2009 02:41:24 +0000

> turn it up on their individual machines, and life will be good.

	actually, it requires at least a pair.

> recently that don't have this quality.  

	historically that was not true... but then, when one has abandon the
	E2E principle in favor of centralized locus of control... thats what
	you get.

> You can't simply turn up  
> infrastructure, DNSSEC isn't helpful.   

	there are those who might argue that point w/ you.

> Deploying stuff  

	i never said it was not useful ... i'm suggesting that we 
	not abandon development efforts for another decade... that
	one sure way to cement your OBE status.

--bill

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 22 May 2009 10:48:44 -0400

> >     Hopefully the term "vote" was a clerical error.
s/vote/voice opinion/

         sorry

         Olafur