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

[Brian Smith <[e-mail]>]

Adam Langley wrote:
>
> 1) makes the extension symmetrical and it seems like there might be
> something in the future that the server would like to predict from the
> client. At the moment we suggest that the server might want to support
> predicting the client's certificate. Often a CertificateRequest
> handshake is a renegotiation and a higher level knows what certificate
> the client should be presenting.
>    
There's already the client certificate URL extension (RFC 3546 section 
3.3). I think that extension could/should be used for this specific use 
case, especially since it already defined the special CertificateURL 
message unless there's a specific reason it can't be used.
>    2) Both sides can list the types of objects for which they support caching.
>    
I agree, but this is kind of predicated on the idea that there are going 
to be more items for which this extension is appropriate. There 
shouldn't be many large items in the handshake, and this extension + the 
client certificate URL extension already cover the existing large items. 
This extension may not even be appropriate for future item caching; it 
isn't optimal for caching ephemeral key exchange parameters that can be 
specified by name, for example, because the hash would be larger than 
the cached value.
>    3) Both sides can list the hash types which they support.
>    
The hash negotiation for TLS seems to be designed so that every kind of 
usage of hashes can be negotiated separately. That's why TLS has a 
"supported_signature_algorithms" extension instead of a generic 
"supported_hash_algorithms" extension. To continue with that design 
would mean each type of cached item would need to have its own separate 
algorithm negotiation.
> 4) results from the fact that I don't think the current draft is clear
> enough about how the substitution occurs. Making new handshake types
> means that everything is very explicit and I prefer that. However, I
> can't think of anything technically wrong with just memcmp()ing for
> the hash values in the existing handshake messages, if it was
> precisely specified.
>    
I would say the message flow should just go something like this: If the 
server doesn't send a Certificate message, then use the cached 
certificate. If the server sends a CertificateRequest with an empty 
(zero-length) certificate_authorities then use the cached 
certificate_authorities. Then nobody has to do any substitution, it's 
much easier to specify, and much easier to implement than the 
substitution mechanism from the current draft or introducing new 
handshake messages would be. Note that this is how RFC5088 works (you 
have to infer what the server is saying based on what handshake messages 
it skips; for example, if the server doesn't send a Certificate right 
after its ServerHello then you have to infer that it's doing a 
resumption based on the given ticket).

Regards,
Brian