Re: transaction security in the last mile

[Paul Vixie <vixie@isc.org>]

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> a) The ICMP unreachable message includes 64 _bits_ of the payload,
> according to RFC 792, not 64 bytes, so only the UDP header is covered,
> and so all UDP protocols have this issue.

oops.  my apologies, as usual, for displaying my ignorance so readily.

so, either there can be no fallback, or there must be additional configuration
information for the stub/RDNS relationship (beyond the RDNS's IP address; for
example it could include a TSIG shared-secret.)

all forms of complex setup including DTLS and TKEY are subject to the same
spoofed-ICMP downgrade attack, if there is a fallback.

TCP however is not subject to this kind of spoofed-ICMP induced failure.  so
perhaps i've been overthinking this.  what if we use TKEY-over-TCP/53 to set
up the trust relationship, and then TSIG-over-UDP/53 for queries thereafter,
and go back and do a new TKEY-over-TCP/53 if the TSIG ever stops working?

be it noted, there is still no authentication here.  the stub won't know what
actual entity is speaking from its RDNS' IP address.  but the stub could be
certain that it was the same entity from setup onward throughout.  that's my
bugaboo.

-- 
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.
archive: <http://ops.ietf.org/lists/namedroppers/>