On Tue, Nov 13, 2007 at 08:35:52AM +0200, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
pgp8fMSK6gOb3.pgp
Description: PGP signature
