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

bert hubert <bert.hubert@netherlabs.nl> writes:

> On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote:
>> Diffie-Hellman is probably too expensive for key agreement (and the ECC
>> variants too encumbered by patents).
>
> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. 

d-h is very expensive to set up.  it's even a tiny bit worse than tcp.  it
would, as i said at the outset, be important for both stubs and RDNS' to keep
state.  however, since it's application layer state, rather than kernel state,
it's reasonable to consider it for an RDNS serving millions of stubs.  which
bitswizzler is used in the various one-way transforms inside the D-H is just a
detail at this stage of the discussion.

wrt DTLS (http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security or
http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html have background
and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm
concerned about two elements of that protocol.  first, it appears that the
handshake can be made to fail using spoofed ICMP-Unreach messages, which may
not be a problem for most protocols, but in our case the fallback is UDP/53
and so this is a downgrade vector.  this is because the first 64 octets of
the IP payload, which means the UDP headers and the start of the UDP payload,
do not include the randomized bits (so, DTLS' nonce is not within ICMP's
nonce).  second, and less troubling, DTLS has message secrecy as a goal,
which is a red herring that will cause huge debates if we try to standardize
on DTLS for stub/RDNS transactions.

i'd like it very much if a DTLS expert could show me how the initial handshake
messages put highly random content into the part of the IP datagram that must
be present in an ICMP-Unreach message.  if not, then the fact that stub/RDNS
will fallback to UDP/53 on DTLS failure means that some other handshake will
have to be designed to carry the D-H exchange.
-- 
Paul Vixie

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