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