Re: [TLS] First TLS cached information draft posted
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] First TLS cached information draft posted
Martin Rex <Martin.Rex at sap.com> writes:
> Simon Josefsson wrote:
>> >
>> > Not quite.
>> >
>> > The caching extension is supposed to be generic, and the to-be-cached
>> > real data may in some situations be quite short or even the same size
>> > than the hash value (probably not for the server certificate caching,
>> > but maybe for the list of certification authorities in the certificate
>> > request message, which consists of distinguished names only, and
>> > there could be just one very short DName (or none at all with TLS v1.1+)
>>
>> Then why use the extension? The point of the extension, as I understood
>> it, is to replace large data with a small hash of the same data. If the
>> data is small, the extension doesn't serve any purpose and should not be
>> used. That is why I liked your suggestion to limit the use of the
>> extension when the data is larger than 3x hash size.
>
> Look at this:
>
> Server supports caching of certificate_authorities list and runs with
> a large list
>
> Client connects, caches the long list and announces the hash of the
> cached information on future reconnects
>
> Server configuration is updated, certificate_authorities list
> is cut down and now only contains one very short name.
>
> Client connects again (having still cached the previous long list),
> server indicates to support caching of that value in principle,
> but returns the real data since the hash proposed by the client
> no longer matches.
>
> Client should now realize that the short data is the new real
> data, should probably drop the cached value, and refrain from
> further caching of the short value.
Right. That is how I think it should work as well.
I believe that adding a limit of 4x hash size (or similar) is still
useful, though, since it would be pointless for the client in your
example to update its cached hash with a hash of the new string, and
send that hash in the future. Doing so would result in a handshake that
is potentially _larger_ than if the cached data were sent.
/Simon
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.