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

Eric Rescorla <ekr@networkresonance.com> Wed, 13 August 2008 17:17 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4881428C0E7; Wed, 13 Aug 2008 10:17:32 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621493A68B9 for <tcpm@core3.amsl.com>; Wed, 13 Aug 2008 10:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.836
X-Spam-Level:
X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwvZd7LtbedS for <tcpm@core3.amsl.com>; Wed, 13 Aug 2008 10:17:30 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6E2063A6A31 for <tcpm@ietf.org>; Wed, 13 Aug 2008 10:17:30 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id AA7A650846; Wed, 13 Aug 2008 10:27:52 -0700 (PDT)
Date: Wed, 13 Aug 2008 10:27:52 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Adam Langley" <agl@imperialviolet.org>
In-Reply-To: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com>
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080813172752.AA7A650846@romeo.rtfm.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

$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
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm