i really like the simplicity of the "just use dtls" approach. it can be
done without a X.509 certification hierarchy, just ephemeral self-signed
certs. it can be done without secrecy-encryption, using the null cipher.
there are libraries that implement it on several popular platforms. there
is an internet draft. it avoids all questions involving DNS payload or
format changes. it would be way easier to implement than TKEY+TSIG, not
in processor cycles mind you, but in number of lines of code a DNS guy
would have to write.

the thing that bothers me about it is fallback, which i consider to be
absolutely necessary for universal deployment. fallback has to be made
unforceable by an off-path attacker. this means ignoring ICMP (which can
be forged) and using long timeouts and/or multiple retries (to outlast
congestion based attacks). if i could be sure that ignoring ICMP was
possible on all common modern platforms, i'd be willing to suggest the

ICMP errors must always be sent and must always be seen. that is, before
any DNS/DTLS negotiation packet is sent, an ICMP error message must be
crafted (in BSD we call this a "raw" socket and it's how the "ping" utility
works) and transmitted. and no incoming DTLS negotiation packet would be
processed unless it was preceded by an ICMP error. the specific ICMP type
and subtype would be chosen pseudorandomly from among a defined set of
those which can make recvfrom() return -1.

in this way, anyone who isn't prepared to ignore ICMP, can't do DTLS DNS.
as an optimization, once someone has proved that they can ignore ICMP by
getting beyond the initial session negotiation, these messages can cease to
be sent and no longer required. thus normal queries would not have them,
nor would session maintainance packets (key rollovers, if any) after the
initial setup is complete.

what i need to know is, is there at least one common modern platform on
which it is not possible to ignore ICMP messages?

note, we may have to restrict the transmission of ICMP to just the
responder, which is more likely to have the nec'y privileges than is the
initiator; and in this case, we'd only require the reception of ICMP
in the initiator. this could deserve further study if we get that far.

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.