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

"Adam Langley" <agl@imperialviolet.org> Wed, 13 August 2008 20:07 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 5B0D628C16E; Wed, 13 Aug 2008 13:07:48 -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 F3E613A6990 for <tcpm@core3.amsl.com>; Wed, 13 Aug 2008 13:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=0.371, 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 3ubUMx+qvt73 for <tcpm@core3.amsl.com>; Wed, 13 Aug 2008 13:07:41 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 494F33A6870 for <tcpm@ietf.org>; Wed, 13 Aug 2008 13:07:41 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so122269rvf.49 for <tcpm@ietf.org>; Wed, 13 Aug 2008 13:07:45 -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=oWKAuBb4cadRYIF9nY7V9ss57WFm5sLL4WViyoLW280=; b=Ll/d1dIilYZVag6s8s3O5pqzAJaMsyrkb3Ph535QdQ3IL8WZZ7n0TLGYXHIXaAk6P4 SL0+sZPZjYtQ/eXA+iCjMx3AZDWRrL3DRCn770mDqjWnof2RVKLyaQbRg6PUIxOxz+N+ dTANPGwgugNF4T2/juqE8BXzmOTUTfc7CBr/Y=
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=lNGL4M+1ri+DCBH24auZHLNb2W/MLggvoVePRA46NyKvL5wSMq+v8pG+2jJV3qaBVq KLsOk9T0NBaEnPiQYF7say4/LOSJlV7cRtX4Y4oAubuqGZJdtFECE7vEl3caiNwrykPN wVkLhKAt9IioXyUsLwMPllmuiyINOA1CGOYQ8=
Received: by 10.140.163.3 with SMTP id l3mr184401rve.55.1218658065099; Wed, 13 Aug 2008 13:07:45 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Wed, 13 Aug 2008 13:07:45 -0700 (PDT)
Message-ID: <396556a20808131307r65a9f6a0oe4365be029620b2c@mail.gmail.com>
Date: Wed, 13 Aug 2008 13:07:45 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Eric Rescorla" <ekr@networkresonance.com>
In-Reply-To: <20080813195027.C4C5B50848@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> <396556a20808131145y1be0fb4saeb7bbf74d078268@mail.gmail.com> <20080813195027.C4C5B50848@romeo.rtfm.com>
X-Google-Sender-Auth: 440909a7c5e1257d
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 12:50 PM, Eric Rescorla
<ekr@networkresonance.com> wrote:
> Right, but this has application-level semantics because the content
> of the server's data is not what an unmodified client expects. So,
> it's not just a timing issue: the server sends different data
> to the client if this option is included or not.

Yes, it absolutely has application level semantics, that's its purpose:

"Modifications to take advantage of SYNACK payloads would then require
changes to the application level protocol ... Because of this, we also
describe a TCP option that lets the application layer on both sides
... agree to use an alternative protocol which takes advantage of it."

> Well, this is just an unsupported claim in the presentation, so I have
> no idea what the underlying data is. However, superficially I find it
> deeply implausible.

As I suggested, this data is considered secret by the organisations
who have it. But I can say that, had I suggested an opportunistic
system that required an extra round trip, various teams here (at
Google) would have (rightfully) laughed at me. I know that sucks as an
argument, but I can't release company data. I'm a bit stuck here
sadly.

>> (2) is also a concern: simply put, users type http by habit.
>
> And the servers could say "use TLS next time" and the browsers could
> remember that.

And that's not a bad idea either. If I get around to it I might sketch
something like that out and see what the Mozilla folks think of it.

> But the client can techncially start sending data as soon as it has
> sent Finished, so that leaves us with:
>
>
>      ClientHello                  -------->
>                                                      ServerHello
>                                                     Certificate*
>                                               ServerKeyExchange*
>                                              CertificateRequest*
>                                   <--------      ServerHelloDone
>      Certificate*
>      ClientKeyExchange
>      CertificateVerify*
>      [ChangeCipherSpec]
>      Finished                     -------->
>      Application Data
>
> Which is the same number of messages as in your example. The problem
> is now sending them before the 3-way handshake completes.
>
> The Server's first message can be stuffed in the SYN/ACK payload, but
> the ClientHello cannot be stuffed in a SYN option. But if you were
> willing to define compressed versions of the most common ClientHello
> options, you could just say in the SYN option "I speak package 9" and
> then the server could send the ServerHello right away. You'd need to
> move some of the ClientHello (e.g., the Random) to the Client's first
> real message, but that's technically feasible.

At which point, I think we have basically the same scheme, but with
different names!

ClientHello (1 bit)  ---->
<----- ServerHello, ServerHelloDone
ClientRandom, Finished, Application Data ----->

For implementation reasons I'm reducing the "I speak package 9" to a
single bit. The sockets API makes it very painful to have applications
process each SYN frame. One could imagine giving the kernel a list of
different payloads to send in the case of different options in the
SYN, but I didn't for complexity reasons. The major advantage would be
that we could more easily recover from primitive compromise but, as
I've outlined in a previous email, the tagged nature of the payload
makes it doable anyway.

We can't fit any certificates in the ServerHello and (unless we're
moving this into the kernel) the key agreement value has to be
constant. So we define a new cipher spec for a Diffie-Hellman function
that works in the face of constant public values and is very fast
(curve25519).

I, indeed, put the client's random in the first real message. I could
support client certificates with the tagged structure, currently I
don't.

So, given the space constraints, it's largely isomorphic, right? If
there's anything important that I've missed please put me straight.


Cheers

AGL

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