Re: [tcpm] SYN/ACK Payloads, draft 01

[Eric Rescorla <[e-mail]>]

$Id: draft-agl-tcpm-sadata-01-rev.txt,v 1.2 2008/08/13 16:15:00 ekr Exp $

I don't really have a strong opinion about whether this extension
should be approved for use with TCP; that's for the TCP experts
to decide. However, I don't find motivational use cases--particularly
the cryptographic use cases listed in S 4 and S 4--particularly
motivating.



S 4. Opportunistic HTTP Encryption

As the draft states, this is intended to provide opportunistic 
security without burning any round trips in the application
layer.

As I understand this mechanism, what's being proposed is this:

      Client                           Server
      ------                           ------
      SYN + PPExt ->
      
          <- SYN/ACK + PPExt + [Crypto stuff]
      
      [Crypto Stuff] ->
      [HTTP Req]    

Do I have that right?

I see a number of issues here:

1. The PPExt payload is overloaded here. First, it's signalling
   a transport message "it's OK to put stuff in the SYN/ACK". Second,
   it's signalling an application layer message "It's OK to send me
   a crypto handshake as the first thing you send." Note that in
   an ordinary HTTP connection, this data would be invalid. 

   This overloading seems fairly unwise, since it would preclude
   any other use of this SYN/ACK payload in the future. If the
   server is going to send non-HTTP compliant data in response to
   this option, then more information needs to be signalled than
   just "I would accept data".

2. It's not clear to me that opportunistic security for HTTP is that
   great. Unlike, for instance, SMTP, HTTP fetches are nearly always
   the result of some URI, so it's very easy to simply indicate 
   in the URI that the server supports HTTPS. This is superior
   from a security perspective for the usual reasons (referential
   integrity, etc...)

3. There are a number of mechanisms for optimizing the performance
   of TLS vis-a-vis round trips that have not yet been explored
   (e.g., Fast-Track [BSR04]). It's not clear if we can shave
   things down to zero RTTs (though I've got some ideas), but 
   it seems that if we're really concerned about crypto setup 
   time it would be worth exploring this before we start with
   a new security layer, especially because of point (2) above.

4. Some of the latency benefit you're getting here is from not
   negotiating the crypto algorithms; this is why in TLS the
   client speaks first. This isn't an issue for the symmetric
   algorithm since the server could provide a list, but it's
   a real issue for the asymmetric algorithm, since it provides
   no agility in the case of upgrade or compromise. If, for
   instance, someone successfully attacks this curve but there
   are other, strong curves available, then we'd be hosed.



S 5. Faster SSH Connections

It's true that SSH latency is really bad, but it's really much
worse than you suggest, since the authentication handshake takes
several exchanges as well. [GutXX] It's not clear to me that removing 
1 RTT helps here. I'm skeptical that there are really that
many applications that involve bringing up and tearing down
a lot of SSH connections. 

Moreover, since SSH involves a lot of connections between the same
pair of nodes, it seems like a TLS style session caching mechanism
would improve the situation a lot more, optimizing out nearly all
round trips for subsequent connections, while also reducing public
key load while again requiring no changes to the kernel.


S 6. Compressed HTTP Headers
I don't know how much value this adds, but note that the server's
indication that it supports compressed headers lives in the same
section of the datastream as the crypto stuff from S 5. So, we
now need some sort of framing mechanism for this data to allow
clients which know about opportunistic crypto but not compressed
headers to ignore that advertisement. 



[BSR04] H. Shacham, D. Boneh, and E. Rescorla. "Client-Side Caching for
TLS." ACM Trans. Info. & Sys. Security, 7(4):553-75,
Nov. 2004.

[GutXX] P. Gutmann, "Performance Characteristics of Application-Level
Security Protocols," Work in Progress.

-Ekr
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm