On 25/08/10 11:04 PM, Richard Salz wrote:
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In fact, the RTT costs
are now more prohibitive than the crypto costs. I was quite surprised to
hear this; he was stunned to find it out.
Yes, it is inherent in the design assumptions of the early 1990s. At
the time, the idea was to secure HTTP, which was (is) a request-response
protocol layered over TCP. Now, some of the design features that the
designers settled on were:
+ ignore HTTP and secure TCP
+ make SSL look just like TCP
+ third-party authority authentication
+ no client-side caching of certs
And those features they delivered reasonably well.
However, if they had dug a bit deeper at the time (unlikely, really
unlikely) they would have discovered that the core HTTP protocol is
request-response, which means it is two packets, one for request and one
for response.
Layering HTTP over TCP was a simplification, because just about everyone
does that, and still does it for whatever reason. However it was a
simplification that ultimately caused a lot more cost than they
realised, because it led to further layering, and further unreliability.
The original assumptions can be challenged. If one goes to pure
request-respose, then the whole lot can be done over datagrams (UDP).
Once that is done properly, the protocol can move to 4 packets startup,
then cached 2 packets mode. The improvement in reliability is a gift.
This is possible, but you have to think outside the box, discard the
obsession of layering and the mindtrap of reliable TCP. I've done it,
so I know it's possible. Fast, and reliable, too. Lynn as well, it
seems. James points out the architectural secret, that security has to
be baked into the app, any security below the app is unreliable.
Look at the "tlsnextprotonec" IETF draft, the Google involvement in SPDY,
SPDY only takes the low-hanging fruit, IIRC. Very cautious, very
conservative, hardly seems worth the effort to me.
and perhaps this message as a jumping-off point for both:
http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY
I was happy to see that the interest is in piggy-backing, not in changing
SSL/TLS.
If you're content with slow, stick with TLS :) Fast starts with a clean
sheet of paper. It is of course a complete rewrite, but IMHO the work
effort is less than working with layered mistakes of the past.
iang
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
