Subject: [TLS] Cached-info draft open issues

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 20 Feb 2013 22:44:14 +0000

According to my notes we have the following open issue with the draft-ietf-tls-cached-info-13.

1)  Whether to include the confirmation of cached objects in the response from the server and what to include in the server hello. We had some discussion earlier on the list.   While it didn't seem that we had strong consensus I think this is roughly where things are at:

+ The inclusion or elimination of the hashed values in some messages could cause ambiguities.  Martin Rex raised the issue that the certificate_authorities field may be empty or contain small values that could be confused with a hash.  
+ The server can indicate which cached objects it accepts in the server hello.  
+ The server can then send an empty field in place of the objects it would normally send
+ The spec would have to define how the empty field was defined for each type.  
+ In order to handle the caching of intermediate certificates a cached object type would be defined for it and the spec would define how the server certificate message is formatted to account for the cached certificates.  

I'm looking for comments on this approaches and contributions of text for the document.

Thanks,

Joe

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 21 Feb 2013 12:15:55 +0100

Hi Joe, 

thanks for your mail. Here is a proposal for a simplification: 

 client_hello,
 cached_info=(certificate)   -> // [1]
                        <-  server_hello,
                            cached_info= // [2]
                               (certificate)
                            server_key_exchange,
                            server_hello_done

 client_key_exchange,
 change_cipher_spec,
 finished                  ->

                        <- change_cipher_spec,
                           finished

 Application Data        <------->     Application Data

[1] This would indicate that the client supports the TLS cached info extension and that he has a certificate for the server cached. 

Note that I simplified the exchange a bit and just say that the certificate payload altogether has been cached rather than individual parts of it.

The hash of the certificate would still be carried in the client hello cached_info extension to give the server an idea what had been cached. 

[2] The server indicates that it also supports the certificate payload omission. It would then omit the certificate payload from the response message. (Alternatively, we could return an empty payload.)

When the client receives the server hello it uses the cached certificate payload. 

Ciao
Hannes

> -------- Original-Nachricht --------
> Datum: Wed, 20 Feb 2013 22:44:14 +0000
> Von: "Joseph Salowey (jsalowey)" <[email-masked]>
> An: "<[email-masked]>" <[email-masked]>
> Betreff: [TLS] Cached-info draft open issues
> 

Thanks,

Joe

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 21 Feb 2013 23:48:13 +0000

> When the client receives the server hello it uses the cached certificate payload. 

[Joe] I think we want to support two cases 1) the whole certificate message is cached.  2) just the intermediate certificate(s) in the chain are cached.  I think your description works well for the first case.  I believe it would support the second if it could return a certificate message with just the end-entity cert and any intermediate certs that were not cached.  We could use the same cached info type for both these cases.  I would be OK with that.   I'd also be OK with using two different cached info types for the two different cases.