Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted
"Brian Smith" <brian@briansmith.org> Tue, 02 February 2010 08:49 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 F2D293A6AEB for <tls@core3.amsl.com>; Tue, 2 Feb 2010 00:49:45 -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=[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 nWb2Nw0O7vhB for <tls@core3.amsl.com>; Tue, 2 Feb 2010 00:49:45 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id C502D3A6AEA for <tls@ietf.org>; Tue, 2 Feb 2010 00:49:44 -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 74C4B509B4 for <tls@ietf.org>; Tue, 2 Feb 2010 03:50:15 -0500 (EST)
From: Brian Smith <brian@briansmith.org>
To: tls@ietf.org
Date: Tue, 02 Feb 2010 02:50:15 -0600
Message-ID: <001901caa3e4$c0363750$40a2a5f0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: Acqj5L0WrvrvoyYbQTWjGIIV/BxgVg==
Subject: Re: [TLS] 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 08:49:46 -0000
I am very interested in the ideas that motivate the cached info extension. It obviously makes sense for the client to tell the server that it already knows the certificate, so that the server doesn't have to send the certificate. 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. Without the ability to include the ClientKeyExchange with the ClientHello, the cached-info extension would usually only slightly decrease the bandwidth needed for handshaking--by zero to two packets in the majority of cases, AFAICT. At the same time, it would provide no effect on latency. Latency from the extra round-trips required by TLS is a much worse problem than the handshake bandwidth for a lot of applications, especially mobile applications. Back in April, Martin Rex said that including the ClientKeyExchange immediately after the ClientHello was a bad idea, because it made it difficult for the server to fall back to a full handshake (see his message quoted below). I agree, but there is a simple workaround: embed the ClientKeyExchange (and/or the client Certificate message) in a hello extension. I attempted to do this, reusing as much of the infrastructure from the cached info extension as possible. In particular, I added the following CachedInformationTypes in order to support : enum { ..., dh_p(3), dh_g(4), ... } CachedInformationType; dh_p and dh_g would be for the hash of the cached values of the DH group from the server's ServerKeyExchange for EDH key exchange. Then, I created a new hello extension that is simply a wrapper around the ClientKeyExchange: Enum { ..., early_client_key_exchange, early_certificate, ... } ExtensionType; For EDH key exchange: The client includes cached dh_p and dh_g values, and includes the early_client_key_exchange extension. If the server agrees to use the same dh_p and dh_g as the client cached, then it can omit those values from its ServerKeyExchange message's ServerDHParams; the ServerDHParams in its ServerKeyExchange would then just contain dh_Ys. Further, since the server already has the client's server_key_exchange message, it can compute the master_secret, so it can send its ChangeCipherSpec and Finished messages immediately after ServerKeyExchange. If the server doesn't want to use the cached dh_p and dh_g, then it would fall back to a full ServerKeyExchange. If the client sees the ServerKeyExchange it knows it needs to generate its own ClientKeyExchange; otherwise it knows to omit it. RSA key exchange is similar, except the cached dh_p, dh_g (if any) would be ignored, and ServerKeyExchange obviously would not be sent. I noticed that a hash isn't always the best representative of the cached information. For example, for EDH key exchange, it would be better if there was the option of identifying well-known Diffie-Hellman groups by their 16-bit IANA id, for servers that use the IKE Diffie-Hellman groups. Then a client could realistically include the IDs of all the IANA-registered DH groups it supports in every (initial) ClientHello; using hashes for this would be unrealistic because they would make the ClientHello too big--in particular, the ClientHello would be much more likely to spill over into another packet. As another example, if the client "knows" the server will ask for a certificate, then it can preemptively/opportunistically include its certificate chain in another hello extension. In that case, it might wish to compress and/or (as is often requested) encrypt it's cert chain when it is wrapped in the hello extension. Or, the client and server could work together to mint a RFC4366 URL to use as the cached identifier for the client certificate chain. Consequently, I'm not sure that standardizing on a generic mechanism that only supports/requires hashes as identifiers for cached data is a good idea. Also, IMO, something should be done so that a client never needs to send multiple hashes of the same cached value in a ClientHello. For example, the client could tell the server which hash algorithms it will support caching for, and then the server can select which ONE of those algorithms it will support, and tell the client (just like it does for cipher suites). Or, the choice of algorithm could be fixed to be the same as the hash algorithm used for the signature of the certificate itself; the client is guaranteed to support and trust that algorithm if it is going to work with that server at all. Regards, Brian On *Wed, 29 Apr 2009* (a long time ago), Martin Rex wrote: > Nagendra Modadugu wrote: >> I'm joining the discussion a little bit late. Is there still time to >> consider 1-RTT version of the full-handshake described in "Fast-Track" >> paper? (i.e. client sends the ClientKeyExchange message speculatively before >> receiving the ServerHello). > > To me, this looks more like a flawed assumption rather than a > "speculative action", because it is impossible to recover. > > The idea behind the short cuts is that the server can continue > with the full handshake if the shortcut is not available for > whatever reason. Sending a ClientKeyExchange based on > assumptions what the contents of the ServerHello will be > precludes the Server from making decisions to which it is > entiteled in the original TLS protocol, and the result can > easily be a fatal error, which means that the network communication > channel must be closed and reopened -- a recovery at the > TLS protocol level is impossible. > > Having the Client send (protected) application data optimistically > following the Client Finished message without waiting for the > Server Finished seems like an acceptable optimization > if you badly need to cut down the number of round trips. > > Such an optimization, however, may have a significant impact > on the semantics of SSL_connect for APIs like that of OpenSSL. > > -Martin
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Michael D'Errico
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Nikos Mavrogiannopoulos
- Re: [TLS] Android's cut-through mode & "RequestTi… Brian Smith
- [TLS] Stream multiplexing extension RE: SPDY / Ne… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- [TLS] TLS Performance (was Re: draft-ietf-tls-cac… Michael D'Errico
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Kemp, David P.
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- [TLS] Cached-info substitution Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Kemp, David P.
- Re: [TLS] Cached-info substitution Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] Cached-info substitution Adam Langley
- Re: [TLS] Cached-info substitution Brian Smith
- Re: [TLS] Cached-info substitution Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] Cached-info substitution Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Kemp, David P.
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- [TLS] RFC 5077 (was Re: draft-ietf-tls-cached-inf… Michael D'Errico
- Re: [TLS] Cached-info substitution Adam Langley
- Re: [TLS] Cached-info substitution Wan-Teh Chang
- Re: [TLS] Cached-info substitution Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Kemp, David P.
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Marsh Ray
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-cach… Kemp, David P.
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Marsh Ray
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Yoav Nir
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Joseph Salowey (jsalowey)
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Donald Eastlake
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Joseph Salowey (jsalowey)
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Marsh Ray
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Michael D'Errico