Re: [TLS] Android's cut-through mode & "RequestTickets" extension ([was draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted)

"Brian Smith" <brian@briansmith.org> Tue, 02 February 2010 16:19 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E903A682A for <tls@core3.amsl.com>; Tue, 2 Feb 2010 08:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 NvfeBLlqdUou for <tls@core3.amsl.com>; Tue, 2 Feb 2010 08:19:25 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 4305B3A67CF for <tls@ietf.org>; Tue, 2 Feb 2010 08:19:25 -0800 (PST)
Received: from T60 (unknown [70.245.64.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 27598509DB; Tue, 2 Feb 2010 11:19:57 -0500 (EST)
From: Brian Smith <brian@briansmith.org>
To: 'Adam Langley' <agl@google.com>
References: <001901caa3e4$c0363750$40a2a5f0$@org> <a84d7bc61002020545n4a29f141na182b463d1de7ece@mail.gmail.com>
In-Reply-To: <a84d7bc61002020545n4a29f141na182b463d1de7ece@mail.gmail.com>
Date: Tue, 02 Feb 2010 10:19:57 -0600
Message-ID: <000a01caa423$92dc1d30$b8945790$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: AcqkDf2dC81nPusETtufhZ+h+sc+4AADP5ug
Cc: tls@ietf.org
Subject: Re: [TLS] Android's cut-through mode & "RequestTickets" extension ([was draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2010 16:19:26 -0000

Adam Langley wrote:
> On Tue, Feb 2, 2010 at 3:50 AM, Brian Smith <brian@briansmith.org>
> wrote:
> > But, if the client already knows the certificate, then it
> > already knows the server's public key. Consequently, it is
> > wasteful for the client NOT to send the ClientKeyExchange
> > along with the client hello.
> 
> Given a client-speaks-first protocol like HTTP (which I happen to be
> mostly concerned with), this could cut the full handshake from two to
> one round trips.
> 
> However, there's a much easier way of doing this: cut through mode. In
> this scheme the client starts sending application data records without
> waiting for the server's Finished message so long as the ciphersuite
> is sufficiently strong. Android already does this.

Interesting. Please send me links to some info about the Android way, if you have any. In particular, have you run into any compatibility problems with this approach? AFAICT, my (private) implementation would abort the connection if there was anything following the ClientHello before it sent its ServerHello.

I am more interested the ephemeral modes, which would always require one round-trip even in cut-through mode. That is why I think The "cut-through" mode Android is using says "I don't care if the ServerHello was tampered with, because the parts that affect security (ciphersuite, protocol version) are good enough for me." I agree that seems like a safe optimization in many cases. However, I think the exact details have to be very thoroughly researched and documented very well if this is an optimization that we are going to encourage. I feel my suggestion is preferable because it has NO material effect on the security properties of TLS at all. Plus, it works for server-speaks-first protocols like SMTP and IMAP (also relevant for you, AFAICT) where the server speaks first.

More below.

> However, with cached certificates it's possible to get a full
> handshake down to 0-RTT if the client can choose the server's random.
> This means that the server has to be able to assert that it will never
> reuse the same random, but that's doable if you assume some degree of
> clock synchronisation and client-cached epoch values.

Hopefully soon I will get around to proposing another extension: the "RequestTickets" extension. Basically, the client includes an empty extension with extension_type=RequestTicket in ClientHello. The server responses with the same in its ServerHello if it supports it. If the server does so, then at any time *AFTER* the ChangeCipherSpec messages, the client can send a message with record_type=RequestTickets, which contains a single byte, <N>. That byte indicates that the client wants the server to give it <N> RFC5077 session tickets. The server responds with its own RequestTickets record, which contains a vector of RFC5077 session tickets for use on subsequent connections. The purpose of this extension is to allow a client to resume a session with a server, without outside observers being able to tell *which* session is being resumed (IMO, this is a major flaw with RFC5077; I don't understand why RFC5077 didn't at least put the NewSessionTicket handshake message after the server change_cipher_spec message).

You could easily extend this RequestTickets mechanism so that the server returns a vector of (ServerRandom, Session Ticket) pairs. Then the server could still choose its own random value, but it would do so ahead of time. The session ticket should include an authenticator for the ServerRandom. Then, resuming connections would include an "early_server_random" extension alongside the SessionTicket extension, and the client could send client_hello||change_cipher_spec||finished||application_data in its resuming connections. But, then you are open to replay attacks, AFAICT.

> This idea has been banging about for a while now and you're the second
> person that I've seen mention something similar in a week. I intend to
> start experimenting with this, hopefully this quarter.

Keep in touch. Sometime this quarter I hope to do a proof-of-concept implementation server implementation for OpenSSL.

Regards,
Brian