Re: [TLS] Comments on the cached-info draft

Hi Stefan,

This new proposal of omitting the data sounds a bit simpler to me.   You say the new approach will limit the functionality in some way.  In what way is it limited?  

Do you think we could accommodate the case where the endpoint has intermediate CA certificates cached but not the end entity certificate? This would require parsing the certificate message, but the response could just omit the certs that were indicated in the cachedInfo.   The parsing of the cert message is a bit more complex, but it could satisfy some of the use cases discussed at the meeting.

Thanks,

Joe 

On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote:

> It was quite a while since I wrote the first version of this draft.
> Now that I bring it up to my attention I found a problem that I think
> should be fixed.
> 
> After a close examination I'm convinced that the current spec breaks TLS.
> 
> 
> The current approach is to exchange support for cached-info in client and
> server hellos.
> This includes hashes for cached objects (clients) and confirmation of
> cached objects (server).
> 
> In addition to this, this protocol allows the cached data in handshake
> messages to be swapped with cached object hashes.
> This is a violation of the syntax of these handshake messages.
> 
> Take the Certificate handshake message for example. The spec suggest here
> to replace the certificate_list vector to be replaced with a vector of
> CachedObejct structured data.
> This breaks the syntax of this handshake message. A strict processing of
> the certificate_list vector will expect an ASN.1 encoded binary containing
> a sequence of certificates, not a vector of data objects according to the
> CachedObject structure.
> 
> My first thought was that we actually need a new handshake message.
> However that is not helpful either.
> The TLS spec require the Certificate handshake message to be sent in case
> the chosen cipher suite demands it, so it MUST be sent.
> It can't be replaced by another handshake message.
> 
> My current belief is that we simply should omit the cached data, and that
> each cachedInfo type need to defined how to omit cached data.
> 
> In case of the certificate handshake message, the certificate list should
> be replaced with an empty sequence.
> 
> 
> There is actually no need to send the hash of the cached data in the
> handshake message. Not if the confirmation of the cached info is exchanged
> in the server hello. Sending the hash once more in the handshake message
> is then redundant.
> 
> 
> So I propose the following:
> 
> 1) Clients send hashes of cached objects in client hello.
> 2) Server responds with one or zero hashes per cachedInfo type, that a)
> matches a cached object sent by the client b) will be omitted by the
> server in the corresponding handshake message.
> 3) How information is omitted from the handshake message is defined per
> cached info type. For the current defined 2 types this is:
>  A) cached certificate cahins in Certificate: replace the sequence of
> certificates with an empty sequence.
>  B) certificate_authorities in Certificate Request: Send an empty list of
> DistinguishedName
> 4) Clients will act as if the cached objects (confirmed in server hello)
> were sent in the handshake messages.
> 5) Everything else according to the current spec
> 
> 
> The proposed approach will somewhat limit the functionality of the current
> spec, but it ads value in simplicity.
> I can't imagine a valid use case that would not be covered by this change,
> but I might overlook something.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls