Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted

["Brian Smith" <[e-mail]>]

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