Re: transaction security in the last mile

[Eric Rescorla <ekr@networkresonance.com>]

[ 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. ]

At Sun, 20 Jul 2008 15:59:25 +0000,
Paul Vixie wrote:
> 
> > 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.)

True. Though it could also just contain the one bit of information
that the server will do a secure channel, right?


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

Because the ISN is in the first 64 bits and ISNs are hard to predict?



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

Without taking a position on this particular design, I think
there's a high order question about whether you'd like to
authenticate the server of just get continuity, right? If
you do, then you should do the initial key establishment via
some public key authentication mechanism, at minimum SSH-style
leap of faith.

On a slightly different note, wouldn't another possibility be
to simply ignore ICMP unreachables and rely on timeouts? As
you know, enough firewalls and NATs block ICMP that you can't
trust them anyway, so you have to be prepared to fall back
to timeout. And if you were to cache the initial information
that the server was/wasn't prepared to do the new security protocol
(a la SSH), then you would only have timeout issues when
you contacted a new server. (You could reprobe periodically...)

-Ekr




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