refactoring crypto handshakes (SSL in 3 easy steps)

[Pasi.Eronen at nokia.com]

There's a dependency from "negotiated capabililities"
to the cryptographic things included in the first message
from client to server (since e.g. what algorithm is 
used by the client, or even what certificate is selected,
depends on these "non-crypto" capability/feature parts.)

But as James pointed out, you could probably handle this 
in "optimistic" mode; i.e. make a guess what the "negotiated
capabilities" are likely to be, and fall back to more
RTTs if the guess is wrong.

(BTW, usually we also want the capability negotiation
to be secure; SSL simply exchanges MACs of all messages
once the key for MAC has been agreed on. Would this
add 0.5 or 1RTT? Or perhaps there's some clever
way to do it without additional RTT?)

Best regards,
Pasi

> -----Original Message-----
> From: ext travis+ml-cryptography at subspacefield.org 
> [mailto:travis+ml-cryptography at subspacefield.org] 
> Sent: 14 November, 2007 21:46
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: cryptography at metzdowd.com
> Subject: Re: refactoring crypto handshakes (SSL in 3 easy steps)
> 
> 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.
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com