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

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 21 Dec 2012 17:03:57 +0100

Hi Stefan, 

I agree with you that the design could be different. Good that you suggested the current design :-)
 
Currently, the client hello contains the hash and then the server provides the hash of the data back to the client instead of the full payload. As you suggested it is possible to omit the second hash. 

To your other point that the current description breaks TLS is IMHO not true. The entire purpose of the extension (and many other extensions) is that the client indicates the support for new functionality and the server (if it supports it) returns different information.

In the example you provide below regarding the certificate structure the server includes a vector of hashes rather than the list of full certificate payloads. Since the client previously indicated that it supports the extension what would break?

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 07 Nov 2012 11:42:19 -0400
> Von: Stefan Santesson <[email-masked]>
> An: [email-masked]
> CC: Hannes Tschofenig <[email-masked]>
> Betreff: Comments on the cached-info draft

> 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.
> 
> 
> 
> 
> 
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
>