Re: transaction security in the last mile

[Florian Weimer <fw@deneb.enyo.de>]

* Paul Vixie:

> ..

... whereas the last mile (on the IP layer) is no longer transparent for
53/UDP packets, which significantly limits further protocol evolution,

> here are some possible roads, and the reasons they're each hard to
> follow.

First of all, I think it's mostly pointless to protect stub to local ISP
resolver communications.  This only requires local source address
validation, so it's something the ISP can and should implement today.

However, there are at least two applications for a DNS last mile that
does not end at the customer ISP: external DNS services with enhanced
data (new roots etc.), and DNS forwarders which are DNSSEC-transparent
and suitable for end-to-end validation.

There's an incentive for ISPs to stop the first application, by some
sort of DNS proxy.  The port number does not really matter: If it's
well-known. it will be proxied.  Unfortunately, this type of proxy will
not be DNSSEC-transparent, so the second application is affected as
well.

So we need crypto.  And crypto for connection-less services means DTLS.
It could be that DTLS requires too much server-side state (to avoid
running the relatively expensive private RSA operation too often), or
that a really good cipher suite hasn't been specified, but these things
should be fixable.

Diffie-Hellman is probably too expensive for key agreement (and the ECC
variants too encumbered by patents).

(Just a few thoughts -- I'm really interested in this topic because we
need to solve it before we can enable some form of DNSSEC validation on
mobile devices.)

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