Subject: Re: [TLS] First TLS cached information draft posted

From: Min Huang <[email-masked]>
Date: Wed, 10 Jun 2009 14:59:38 +0800

Hi,Simon

This "heuristic" determination works well in most scenarioes, 
but the client still be confused in some specific cases. I think
adding a type-specific tag as you mentioned is a doable method, 
and it can solve the problems by now. 

And if we will construct a type-specific tag, the new "datasize" 
field in CachedInformationHash is still necessary? It seems not 
necessary any more. It can be a policy conformed by the client 
when caching data or sending a CachedObject.

regards,
Min

simon wrote:

Here is a modified idea.  Replace the CachedInformationHash with this
structure:

struct {
           HashAlgorithm hash;
           uint32 datasize;       /* NEW.  Size of hashed data.
                                     MUST be >= 4 * hashsize(hash) */
           opaque hash_value<0..255>;
      } CachedInformationHash;

The server respond by indicating whether it supports cached data in
principle, but defers until later in the handshake to decide whether to
replace data or not.  This addresses Martin's concern.

Then add text to say that datasize MUST be >= 4 * hashsize(hash) where
hashsize is the hash output size, i.e., 20 for SHA-1.  Smaller objects
cannot be cached with this extension.

The server can decide, when constructing later handshake packets, whether to
replace the generated data with a hash or not.  Typically, the server would
generate the data as normal.  Then if the client provided a cache extension
type for the object, it will compare a hash of the generated data with the
hash provided by the client.  If they match, it will send the
CachedInformationHash value instead of the generated data.

The client parses the response, and can by looking at the size of each
object decide whether it is a hash or real data.

This runs into a problem if the server instead of returning a hash returned
data that was considerably smaller than the value cached by the client.  The
client could then be confused whether the returned data is real data or a
hash value.  A type-specific tag could be constructed here -- for both
certificate_list and certificate_authorities it could be some invalid ASN.1
followed by the CachedInformationHash.

This is a compromise, but it seems difficult to solve both Martin's concern
and my concern that clients needs to reliably be able to decode incoming
data.  Better ideas welcome.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 10 Jun 2009 18:02:00 +0200

Min Huang <[email-masked]> writes:

> but the client still be confused in some specific cases.

Hi.  Yes.  I don't like TLS implementations playing guessing games on
the intended interpretation of received data, though, and that is my
primary concern with this document right now.  I'm wondering how other
implementers feel about this, is it acceptable?

> I think adding a type-specific tag as you mentioned is a doable
> method, and it can solve the problems by now.
>

Right.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Jun 2009 20:40:38 +0200 (MEST)

Simon,

> implementers feel about this, is it acceptable?

What you could do, is to unconditionally use an additional framing
for that being-cached parts of the TLS handshake messages for
for which the Client requested caching in the ClientHelloExtension
and and the Server acknowledged caching support in the
ServerHelloExtension.

(I'm not really accustomed to TLS spec language, so please
 apply common sense / corrections yourself):

enum {
   original_data(1),
   hash_over_original_data(2),
   omitted_hash_over_original_data(3),
   original_data_and_suggestion_to_not_cache(4),
   (255)
} CacheControlContentType;

struct {
   CacheControlContentType    type;
   opaque                     content<0..2^16-1>;
} CacheControlContent;

...and drop the things that are not needed (but mentioned for completeness)

This approach would unconditionally change the (affected) PDU if caching is
negotiated but hashes do not match (as well).  It facilitates to omit
the actual hash value at this point in a non-ambiguous fashion
(the hash should be part of the handshake once, but having it
three times looks like waste). 

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 10 Jun 2009 23:04:15 +0200

> three times looks like waste). 

I like this approach, it addresses both your and my original concerns.
Stefan, what do you think?

The resulting protocol is more complex with the above, but given that
the original proposal is unreliable, I think the complexity is warranted
here.

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Jun 2009 23:32:28 +0200

Thanks for all the analysis and proposals.

Unfortunately I have been on constant travel and meetings since Monday
morning and it is not over until tomorrow night when I get home again.

I will go through this more carefully then and get back to you no later than
Monday.

/Stefan

On 09-06-10 11:04 PM, "Simon Josefsson" <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Jun 2009 16:57:53 +0200

Hi,

I have now carefully read through this thread and spent some time thinking
of it.

I don't like the extra complexity of the proposed structure and I fail to
see the problem of recognizing the hash as replacement of data.

First of all, the worse case scenario if everything fails miserably and
client mistake a hash for real data or the other way around, is a failed
handshake.

This is followed by a normal handshake where the client will reset it's cash
for that server.

This safe fallback allows us to accept reasonable risk of failure.

Now, how hard is it to recognize a hash as replacement for cashed data and
what is the risk of collision?

In my world this is not hard at all. The hash code is a unique
identification key, provided by the client. If these bits appear where the
cached data was supposed to appear, it is a clean replacement. This is not
hard to detect and risk of collision is negligible.

It is totally irrelevant if the hash in theory can take the form of legal
ASN.1, XML or anything. We know where the bits start in the handshake
protocol, the hash bits was further chosen by the client and if the server
or MitM tries to change them, it will only result in a failed handshake.

In the sum of all, I would like to keep the current protocol syntax.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Jun 2009 17:54:52 +0200 (MEST)

Stefan,

> what is the risk of collision?

I agree that probability of an accidental exact match (length and value)
between a hash value over previous real data and the representation
of new real data after a config change of the server is EXTREMELY low.
Personally, I it consider it negligable.

I do not agree with the reasoning about the recovery -- a requirement
to close a communcation channel entirely and restart from scratch
is something that is likely going to break a lot of apps (I wish
it did not, but unfortunately, it does).  Designing the protocol
in a robust fashion so that there is no abiguitiy, and unnecessary
risks of failure are avoided, is usually a sensible thing to do.
I personally do not think we have such a risk here, it is more
about clean architecture and avoiding heuristics in a protocol parser.

Since I am no real TLS implementor myself, I do not have any
personal preference on whether or not to use an extra framing, and
want to leave the discussion and in particular the decision to the author
and those implementors who intend to implement this extension and those
that are familiar with the requirement of small/constrained clients
or low-bandwidth connections that expect a benefit from using this
extension.

-Martin