Re: [TLS] First TLS cached information draft posted

[Stefan Santesson <stefan at aaa-sec.com>]

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




On 09-06-10 11:04 PM, "Simon Josefsson" <simon at josefsson.org> wrote:

> Martin Rex <Martin.Rex at sap.com> writes:
> 
>> 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).
> 
> 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
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls