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

[Stefan Santesson <[e-mail]>]

All,

Going back to address this original mail which I think is the only one
proposing any alteration of the current draft.

Brian,

The client don't know if the cached server certificate is acceptable for the
handshake before the server has acknowledged that is is correct. Sending a
ClientKeyExchange with a Client Hello is therefore successful only if the
client has cached a server certificate and that certificate is acknowledged
by the server.

I'm not saying that your optimization isn't interesting, but it is not
generic to the cashed-info draft and would make the current draft
significantly more complex. I would prefer not to go there.

I think this draft is ready for WGLC without modifications.

/Stefan



On 10-02-02 9:50 AM, "Brian Smith" <[e-mail]> wrote:

> 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
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls