Re: [dnsext] Forgery resilience and meeting in Stockholm

[Otmar Lendl <[e-mail]>]

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

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

no.

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

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

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

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.

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

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 <[e-mail]>, T: [phone] - 33, F: - 933 //

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>