towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)

Ian G iang at systemics.com
Thu Aug 26 10:17:44 EDT 2010


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 majordomo at metzdowd.com



More information about the cryptography mailing list