[dnsext] Forgery resilience and meeting in Stockholm

[Andrew Sullivan <[e-mail]>]

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
[e-mail]
Shinkuro, Inc.

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