Re: [tcpm] Faster application handshakes with SYN/ACK payloads

"Anantha Ramaiah (ananth)" <> Mon, 04 August 2008 04:56 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id EC73A3A6BFB; Sun, 3 Aug 2008 21:56:58 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F10353A6BFB for <>; Sun, 3 Aug 2008 21:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.839
X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G2P4sZavA4OR for <>; Sun, 3 Aug 2008 21:56:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1727A3A69C0 for <>; Sun, 3 Aug 2008 21:56:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,302,1215388800"; d="scan'208";a="135314119"
Received: from ([]) by with ESMTP; 04 Aug 2008 04:57:10 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m744vAwU023503; Sun, 3 Aug 2008 21:57:10 -0700
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m744vArg009177; Mon, 4 Aug 2008 04:57:10 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Aug 2008 21:57:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 03 Aug 2008 21:56:01 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] Faster application handshakes with SYN/ACK payloads
Thread-Index: AcjzRwTQlivZSJ0cRuePYUMN2eCTGgCjQKZQ
References: <>
From: "Anantha Ramaiah (ananth)" <>
To: Adam Langley <>,
X-OriginalArrivalTime: 04 Aug 2008 04:57:10.0050 (UTC) FILETIME=[8D3A7820:01C8F5EE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7654; t=1217825830; x=1218689830; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20Faster=20application=20handsha kes=20with=20SYN/ACK=20payloads |Sender:=20; bh=pKOlTpXkFSC834VluhGpWlYZbNfKtnIgRaVwKOccpCw=; b=gzQS6GcyLR3HTUXiobSxApZke6nN+nNSaXAZXXG/V9p9ONRm4M0aSAgBOa 2k0jsi/33MFrHx3aVYNk3Yz9ccqL/5DPLxc57Ef54Ah6mpgyUl1Sh9CCINod Z5MvnU46m/v+/0Ebb/Wo4iR6B/xfZvKuI0sWjepEggIWKAK0wUtAg=;
Authentication-Results: sj-dkim-1;; dkim=pass ( sig from verified; );
Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

    I managed to read this draft on my return flight and had marked some
comments. I have only cursorily glanced at the other comments and hence
there could be a possibility of overlap with what has been already


- fix the sentence : "we should how this has...."

- you mention "cryptographic applications" would benefit with this
proposal, and give example of SSH in your draft. It would be really
interesting to know how many very commonly used TCP applications would
really benefit with this ? Atleast the draft can mention those..

- with the SSH example which you give, it appears that one of the
advantages of this proposal is that you can tear down the connection
before the connection moves to ESTAB if the authentication fails?  (For
eg:- some implementations don't create a full blown TCB before TWHS

Section 3 :

- Can you elaborate on the flags option? It simply mentions that the
meaning of this would be assigned by IANA? Again this is not infinite
(2+n, n is finite) since it should be bounded by the TCP header length
inclusive of options?

- the doc says (section 3 ) "host MUST not include data payload in
SYN+ACK resulting from a SYN frame without SYNACK payload permitted"
But RFC 793 does permit data in SYN which includes SYN+ACK, so this
statement raises a new level of ambiguity.

Section 4:

You mention 64 bytes of payload is enough to include sufficient crypto
material. Just wondering the interoperability of this statement with TCP
auth (TCP MD5 and TCP AO for example)

What about Kamikaze like packets ? where SYN, FIN are set the
applications can send data and also set the FIN bit in the oriinal SYN
(Not sure if 793 talks about it but Stevens book does mention it and so
as BSD implementatiosns which support this type of packets) Would those
still work within your proposal?

Also, the applications need to change to make use of this proposal (the
HTTP example which you mention below) In other words, it would be nice
if you can explain the "opportunistic encryption" scheme and how
applications (which all) can benefit from your proposal in more detail
in the draft.


> -----Original Message-----
> From: [] On 
> Behalf Of Adam Langley
> Sent: Thursday, July 31, 2008 12:52 PM
> To:
> Subject: [tcpm] Faster application handshakes with SYN/ACK payloads
> I posted this a while back and it gathered a little discussion:
> (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:
> .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.
> [1] 
> nack-payload
> [2]
> --
> Adam Langley 
> _______________________________________________
> tcpm mailing list
tcpm mailing list