Re: TLS for the link handshakes/encryption

[Zach Brown <zab@zabbo.net>]

> | Based on looking at the chainsaw [1] cvs and docs, it seems ZKS was
> | very excited about Oakley key exchange [2], and also about Photuris,
> | which has since been finalized into rfc 2522 and 2523.
> | 
> | Part of the benefit here is they have cookies built into the protocol
> | to keep adversaries from hammering the servers. ("Alice sends 128 zeros
> | and the server does an RSA decrypt" is a bad DoS issue.)

Yes, that was a big part of it.   Though in another recent hobbiest
crypto tunneling adventure I used a mix of the secret negotiation
described in 'Practical Cryptography' and Adam Back's hashcash.  I can
go back and look at the code and my notes and ramble about to anyone who
may be interested.

> | They seem to be designed for UDP (I'm not sure if that means they're
> | less suitable/impressive for TCP).

These negotiatons should all still work well over TCP -- the messages
still get traded back and forth and the messages certainly don't rely on
the transport for any auth*.

Using UDP for the negotiation as well as the eventual tunnel transport
was intentional, though..

> We at ZKS were always fans of putting IP packets in an unreliable
> transport so as to avoid double TCP retransmits on packet loss.  I
> don't know if we ever tested this theory, but it sure was widespread.

right, the dueling retransmission timers are particularly irksome.

Once you're using UDP for the transport, it can be compelling to also
use UDP for the negotiation to simplify things -- particularly the
interaction with NAT.  It also seems a waste to spend those round-trips
building up TCP state that won't be used again.  We were concerned at
the time with the number of round-trips involved in the build-up which
is why Jerome shaved some round trips off the Photorus design when
cooking the negotiation chainsaw ended up with.

- z