Re: [dnsext] Forgery resilience and meeting in Stockholm

[Peter Koch <[e-mail]>]

On Fri, May 08, 2009 at 02:14:22PM -0400, Andrew Sullivan wrote:

> topic seems not to have inspired consensus.  Therefore, we would like
> 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.

> 1.  Do nothing, and take all energy that might be devoted to this
> 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.

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

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.

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

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.

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

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. 

> 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

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.

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