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

"Adam Langley" <agl@imperialviolet.org> Wed, 13 August 2008 18:45 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 37F5D3A6B76; Wed, 13 Aug 2008 11:45:14 -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 A18243A69E8 for <tcpm@core3.amsl.com>; Wed, 13 Aug 2008 11:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.544
X-Spam-Level:
X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.433, 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 wHZvkuWi8eqr for <tcpm@core3.amsl.com>; Wed, 13 Aug 2008 11:45:04 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id C19B13A6907 for <tcpm@ietf.org>; Wed, 13 Aug 2008 11:45:03 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so93327rvf.49 for <tcpm@ietf.org>; Wed, 13 Aug 2008 11:45:07 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=XRMZLLKrJHxGgsh5m2VNoZJbBecJ3gLaN3RsTWALdDg=; b=vhLgVkLZnQrvtZWPklGZWmeQUHjL0XEjrzdDwDuyXr+iR83NwWpTHkfZ9WLn2Euyil ITF5YV6e/4OTQ0Sme39IXrcXgU+mHxetVahQ4E8XFLIEmXh+56VOeU+jFmRCb2AH6UdV easpyFKnKttGNDjwOpOY9ZPqgNxfXhiBTQ4Ao=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; 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=P8DjGCjvtbn1QErlO/z+2M7eS8MiQxBaag/A2SD4Rn4HEzwNy6jzmCuUTR9JqckJAI IEoBXQgeTtowQ2uqsiip58Ru0TXDDqWwy4kqv3jFQFdqxsY0h8OVhOL7n09nxTNWqUjv qFwtY7P/vr/TkYrCJT2jisiKyNdWehLTo4Zio=
Received: by 10.141.163.12 with SMTP id q12mr128498rvo.190.1218653107397; Wed, 13 Aug 2008 11:45:07 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 11:45:07 -0700 (PDT)
Message-ID: <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com>
Date: Wed, 13 Aug 2008 11:45:07 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Eric Rescorla" <ekr@networkresonance.com>
In-Reply-To: <20080813181630.A1E6750848@romeo.rtfm.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <20080813172752.AA7A650846@romeo.rtfm.com> <396556a20808131047q781675a3if23d727ef5ae918f@mail.gmail.com> <20080813181630.A1E6750848@romeo.rtfm.com>
X-Google-Sender-Auth: 094beb542436a443
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

On Wed, Aug 13, 2008 at 11:16 AM, Eric Rescorla
<ekr@networkresonance.com> wrote:
> I'm srory, I don't understand what you're saying here. Does this
> data appear to the application to be part of the data stream
> or not?

Yes, the data is part of the application stream. However, including a
payload in the SYN/ACK frame is permitted by TCP. Thus application
protocols in which the server speaks first could include payloads in
the SYN/ACK today, with no changes. Admittedly many stacks will only
ACK the SYN flag and not the data, so the data has to be
retransmitted, but the changes needed don't need any standard work.

The option proposed here is just for "client speaks first" to escape
that mode and switch to a "server speaks first" mode.

> OK, this wasn't entirely clear from reading the draft.

I didn't include it in the draft because it seemed out of scope, but
maybe I should since attentive readers are obviously picking up on it.

> But the premise of this scheme is that people don't do TLS
> because of either (1) latency or (2) lack of opportunistic
> negotiation. As far as I can tell, neither is correct. Rather,
> it's concerns about server performance. And server performance
> can be improved by a number of mechanisms within TLS that
> are (1) backward compatible with TLS and (2) don't require
> modifying the kernel.

(1) is certainly a concern today. Even a single round trip. Most
actual numbers on this are considered secrets by the organisations in
a good place to gather them, but here's one soundbite:

"every 100ms of latency costs Amazon 1% of profit"
http://radar.oreilly.com/2008/08/radar-theme-web-ops.html

(2) is also a concern: simply put, users type http by habit.
Additionally, getting TLS certificates is a pain for small sites. As
for server load, curve25519 can be performed in 240us on a Core2 and
Salsa20/8 runs at 2 cycles/byte (same hardware). That reduces server
load.

But, really, I don't really know the reasons why TLS isn't ubiquitous
even with ubiquitous support. But, given that it isn't, I'm looking to
the best that I can with a very low-cost (i.e. computation, latency)
system.

I should also add another point of the opportunistic encryption scheme
that isn't covered in the draft:

When in effect, servers may return an X-ObsTCP: header that specifies
an https URL to a document that contains a list of Diffie-Hellman
public values and validity time periods for each. (The hostname is
required to match.) It's hoped that client's can cache it and validate
keys in the future. (Credit to Markus Gutschke from the Google
security team for that.

However, as you point out, there's another route here: additional TLS.
One of the tags that I have penciled in for the SYNACK payloads is
"TLS upgrade" - e.g. the server can advertise TLS support without a
round trip. With client-side context caching, that can be setup with
only one extra RTT in the optimal case (2 otherwise I believe).

The reason that I didn't include that as an explicit example is
because it can be downgrade attacked (obviously) and so, it might
actually be counter productive because it wouldn't teach users to type
"https".

However, if you have ideas for a zero RTT TLS, please send them my way
(possibly off list in that case). If there's a possibility to use
something standard(ish) with no additional latency I'll use it.

> That said, if you're willing to burn even very small amounts
> of data in the SYN, you can do something TLS-compatible by
> passing a compressed ClientHello of some kind + FastTrack.
> This only works with static RSA one the server side, but
> so does the scheme you propose.

I can reasonably fit 14 bytes in a SYN frame. I did consider trying to
get RSA in the SYN (because then the computation costs could be mostly
put on the server), but I don't think I can fit anything useful in
there. (Not even a good elliptic key).



AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm