[tcpm] Faster application handshakes with SYN/ACK payloads
"Adam Langley" <agl@imperialviolet.org> Thu, 31 July 2008 19:52 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 9EB6E28C21B; Thu, 31 Jul 2008 12:52:12 -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 0D9F328C116 for <tcpm@core3.amsl.com>; Thu, 31 Jul 2008 12:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 uRc1KYCgzWko for <tcpm@core3.amsl.com>; Thu, 31 Jul 2008 12:52:08 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 6183E28C2CE for <tcpm@ietf.org>; Thu, 31 Jul 2008 12:52:08 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so623509rvf.49 for <tcpm@ietf.org>; Thu, 31 Jul 2008 12:52:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=bOui26ebn+WcNnB9SX6JO6k/GA/KPg/6rY/C8ZtTja8=; b=Djtcs/MPxOijIKAMbV7YgsqwPwe2Qxa7l0xMMXPqhABvrcOh4sQ2QVaIn1gweN/YKL Gp8bKMKR4juaX2vmnpWyIeWqXbuzXQwYLM31onEzR40Furl88orDvluBZUtAzcy60Kly 26VORqx6joGNP5T/CzxdXP7szvgTDHy/KAW+I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=OomUeBvHR5jbCqK3zavMuJkk/1qHW+47xy2spSMuSaOX2hiFQjnqhDeutqtYOqA36P HlH2PMiu5tz/yZuatLaH+y4QM4te+es1J+KqbyEkgDItNa9i75mcVe7ueCwex56s0lWm 1dKe2BnShuXciRfW1GtWwueC9n8qRysHrZ/aA=
Received: by 10.140.164.6 with SMTP id m6mr5499369rve.210.1217533945900; Thu, 31 Jul 2008 12:52:25 -0700 (PDT)
Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 12:52:25 -0700 (PDT)
Message-ID: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com>
Date: Thu, 31 Jul 2008 12:52:25 -0700
From: Adam Langley <agl@imperialviolet.org>
To: tcpm@ietf.org
MIME-Version: 1.0
Content-Disposition: inline
X-Google-Sender-Auth: fe372f10617d0f36
Subject: [tcpm] Faster application handshakes with SYN/ACK payloads
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
I posted this a while back and it gathered a little discussion: http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt (implementation in [1]) I would like to have this published as Experimental and to get an option number assigned. The spec itself includes a somewhat rambling justification because I wanted to decouple the spec, which is more general, from the exact reason that I wish to start testing this over the Internet at large. However, in order to provoke discussion I think I should explain my motivation: This spec allows for opportunistic encryption of TCP connections with no additional round trips. Details of the project can be found at [2], however a quick summary follows: Although SYN/ACK payloads could be used to accelerate many protocols, I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte random nonce and a 32-byte eliptic-curve public value. The client can then perform key agreement and send it's own public value, nonce and any encrypted payload in the final ACK. (Or in a following packet, that works fine too). Data is then encrypted using Salsa20/8 where the key is SHA256(diffie-hellman output + server nonce + client nonce) and the IVs are 0 and 2**63 for client->server and server->client, resp. Obviously, this open to both a downgrade and man-in-the-middle attack. For a specific user, it offers little real security. However, amortised over a large set of users, any ISPs performing these attacks on a large scale will be detected. (I plan on building a network of hosts probing for large scale attacks.) Thus, eavesdroppers are removed from the equation and, against the rest, it can protect most of the people, most of the time. I also plan to sign the resulting packets with TCP-AO at some point, if possible. However, given that that is still under development I'm going to make that part of the negotiation, above, so that it can be deployed without it for now. Obviously, this system can only prove itself in time. However, it can't prove itself with an option number assigned. And thus, I'm looking for a consensus that this is an interesting experiment. Thanks Having spoken to quite a few people about this, I now have an FAQ on the design which is included below: * Why Elliptic-curves? The payload must be short otherwise SYN-floods could use this as an amplification to backscatter DDoS another host. Also, the reduced computation cost (as compared to Diffie-Hellman over a multiplicative finite field) is very nice. * Why 25519? It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, the server's public value must be constant, otherwise an attacker could eat CPU time with a SYN flood and curve25519 is designed for that. Since this is constant for all connections, there is no perfect forward secrecy. * Can't you fit the client's public value in the SYN? A SYN generally has 20 bytes of free option space these days. (We can't use the payload space in a SYN). Since this can't be the last option ever, we need to leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the public value. The closest prime is 2**112-75. I'm a bear of little brain and picking my own curve is already a hell of a task, but assuming that I can: The best, general algorithm currently known for breaking the DH problem on elliptic curves is Pollard's Rho. The work involved in this attack is sqrt(n), which is 2**56 in this case. Critically, once you have solved a single instance you can precompute tables to speed up breaking more instances. With a petabyte of storage, you could break 112-bit curves in 2**12 operations, which is very fast. * Can't you use a smaller field anyway? Some speedup could be gained by using an EC with a field size around 200 bits. However the effort of defining such a curve is pretty huge. The standard NIST curves around that size are slower: http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table 6) * Why Salsa20/8? It encrypts at two cycles per byte on modern CPUs[1]. The best attack on this, reduced round, variant is 2**251. It's very unlikely that an attack would ever break it to the point that it's easier than performing a downgrade attack. http://cr.yp.to/streamciphers/phase3speed-20080331.pdf [1] http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload [2] http://code.google.com/p/obstcp/ -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] Faster application handshakes with SYN/ACK… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Lloyd Wood
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Michael Scharf
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- [tcpm] Faster application handshakes with SYN/ACK… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Murali Bashyam
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Matt Mathis
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Anantha Ramaiah (ananth)
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Stefanos Harhalakis
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Stefanos Harhalakis
- Re: [tcpm] Faster application handshakes with SYN… Adam Langley
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch
- Re: [tcpm] Faster application handshakes with SYN… Stefanos Harhalakis
- Re: [tcpm] Faster application handshakes with SYN… Stefanos Harhalakis
- Re: [tcpm] Faster application handshakes with SYN… Joe Touch