Re: [dnsext] Support for EDSN0 PING

[Paul Vixie <[e-mail]>]

> Date: Fri, 15 May 2009 12:16:57 +0200 (CEST)
> From: "Bart Smit" <[e-mail]>
> 
> As a relative outsider, but with experience in DNS operations and
> security, I've been following the discussions in this wg since around
> 2005 and I wonder why the renewed interest in forgery resilience work in
> the wake of Kaminsky has subsided so fast. I really had expected that
> last year's experience of having to rush out a solution would serve as a
> sort of reality check to parties involved, but this effect is markedly
> absent.  In fact, I now even sense the opposite. A prominent wg member
> recently suggested that all such (non-dnssec) work should be swept into
> the rubbish bin. I find this incomprehensible and somewhat disturbing.

since i mentioned a rubbish bin recently but the above is not a fair summary
let me say that TKEY-DH plus TSIG is an existing (already specified but not
widely implemented) method of holding session state between pairwise UDP/53
speakers that would absolutely and totally protect hop by hop communications
between cooperating initiator/responder pairs.

the stuff that i directed toward the rubbish bin was every other current
proposal, including my own (dns-0x20).

> For this reason, although I hardly feel qualified (in wg context that is)
> to do review, I would like to express my support for adopting
> draft-hubert-ulevitch-edns-ping.txt as a working group document. And yes,
> I'll gladly do review.

PING is a layering violation for EDNS and does not add any real security.
(as the author of EDNS [RFC2671] i already tried to add an extended QID and
found that it could not be done; nothing as changed since RFC2671 came out.)

> There is an interest in being able to use the ping option (it's already
> being done), so there's a clear need to formalize the option code.
> Moreover, suggested use of this option strongly works for meeting forgery
> resilience demands, so I don't see why the document should not be adopted,
> or why it should be worth all the heated debate. It describes an option,
> support for which is entirely optional. This really ought to be
> uncontroversial.

it's controversial because it only works when it works, and when it fails,
there's no distinction between an attack and a failure.  we were not idiots
back in the old days when EDNS was being crafted.  we knew we needed a
larger QID.  we tried hard to include it.  there's no way to do it and
still properly negotiate EDNS.

secure protocol engineering is apparently not as easy as it looks.

> Bart Smit
> 
> Network Engineer at BKWI, The Netherlands
> (on personal title)

paul vixie
author, RFC 2671, http://www.ietf.org/rfc/rfc2671.txt
co-author, DNS-0x20, http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

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