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

"Adam Langley" <> Tue, 15 July 2008 21:14 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id A0DD93A6AD9; Tue, 15 Jul 2008 14:14:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A9833A6AA3 for <>; Tue, 15 Jul 2008 14:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VqBXrWyuagxo for <>; Tue, 15 Jul 2008 14:14:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 506FE3A67BD for <>; Tue, 15 Jul 2008 14:14:57 -0700 (PDT)
Received: by with SMTP id b25so4747660rvf.49 for <>; Tue, 15 Jul 2008 14:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=OlpuRNT+9kTRmStumez1gwyLkV0yUOX0DvYVh7FEzlA=; b=qKOdgti3xxsAjxSohwPkicunTzw8MpOJI6gr5wq0q04Ic5I3hpaGa9afKQF8z+CUDh gqCfPGAvTEoIZ9MEN6dW+cLXhyT+fnn1itwbXttF0Jc8uMuSyG5hp88ypoxdwkox7FtJ b1JZ0Tf3gstu4KFTWluM6Wljv8g81hGwweQK8=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=hBNLfDnb3N+TWgpNS9SRZRdHRFD0ECtwDGYwnAyro9xHs/1FY6ypr4wypi4qFDRRna DNPVR9sET5yoJk2B+TpDcd6a1DkrNdEvSRl96mKFSofRXPi9bzmwUl138rMaDSp7qQwO AqjZSuXXJi/dwexFBPofer08Y6uSHMfD5NrUQ=
Received: by with SMTP id i1mr7761594rvf.102.1216156513731; Tue, 15 Jul 2008 14:15:13 -0700 (PDT)
Received: by with HTTP; Tue, 15 Jul 2008 14:15:13 -0700 (PDT)
Message-ID: <>
Date: Tue, 15 Jul 2008 14:15:13 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <> <>
X-Google-Sender-Auth: ea19e2ee436e7f05
Cc:, Lloyd Wood <>
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

On Tue, Jul 15, 2008 at 1:52 PM, Joe Touch <> wrote:
> Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's
> just ignored. So this option is just a hint to the server that the
> client won't ignore that data. It doesn't change any rules about data
> delivery; once the SYN/ACK arrives, the client can send that data up to
> the user as per conventional rules, AFAICT.

Although I've not tested it, I suspect that you're correct here. I
should reword that section of the draft.

> I'm really not sure what buying a single RTT will do for TCP, though.
> Very few exchanges that need reliable transfer of a single packet need

Although it could be used for single packet exchanges from the server,
I would be surprised if any one did. My expectation is that protocols
would use it to shave a RTT from the TCP connection setup latency. My
personal motivation for this draft is hinted at in section 2:

"This also allows existing protocols to be extended with encryption
with no additional round trips and with transparent fallback."

Consider a web browser which sets the SYNACK permitted bit and a web
server which includes an elliptic-curve Diffie Hellman key in it's
static SYNACK payload. When connecting to a normal webserver, the
browser will see that no SYNACK payload was received and carry on as
normal. But for augmented webservers, the browser calculate a shared
key and include its own ECDH key just before the HTTP "GET" request,
carried in the final ACK of the 3-way. Thus we have opportunistic
encryption and no additional latency in either case.

(Also, that's not just idle speculation: the firefox build that I'm
writing this email in is such a web browser and the lighttpd I have
running at home is such a web server.)



Adam Langley
tcpm mailing list