refactoring crypto handshakes (SSL in 3 easy steps)

[travis+ml-cryptography at subspacefield.org]

On Tue, Nov 13, 2007 at 08:35:52AM +0200, Pasi.Eronen at nokia.com wrote:
> The "extra messages" might be irrelevant for cryptography,
> but they're not irrelevant for security or functionality.
> E.g. in SSL, you have capability/feature negotiation
> (cipher suites, trusted CAs, in TLS 1.2 also signature
> algorithms, etc.)

So, this is a good place to attempt to use this method.

Data to be sent:

1) supported capabilities on the client
2) supported capabilities on the server
3) negotiated capabilities

Dependencies:

1) No dependencies (first message from client to server)
2) No dependencies (first message from server to client)
3) Depends on #1 and #2

Results:

3 messages
1-1.5 RTTs (one if there's a simultaneous open, which is rare)

So unless I'm missing something, we're still at 3 messages.

Aside:

I would like to point out that TCP-based protocols have the latency
disadvantage of having to do a 3-way handshake before transferring any
data.  If you were to design a new IP protocol, you could do the key
exchange within the handshake, which would save 3 messages, but may be
vulnerable to a resource-consumption attack on the CPU.

I wonder if we here could develop a handshake that was
cryptographically secure, resistant to CPU DoS now, and would be
possible to adjust as we get faster at doing crypto operations to
reduce latency even further.  Basically an easy knob for balancing
high latency and DoS resistance vs. crypto overhead and low latency.
It should be adjustable on either end without altering the other.

-- 
Life would be so much easier if it was open-source.
<URL:https://www.subspacefield.org/~travis/> Eff the ineffable!
For a good time on my UBE blacklist, email john at subspacefield.org.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20071114/ef6cda53/attachment.pgp>