Re: [TLS] First TLS cached information draft posted

[Stefan Santesson <[e-mail]>]

Thank's Simon,

Good comments and I agree to both of them.

1) Yes the intension is that if the server returns only 1 out of 2 objects,
only the object returned will be replaced

2) If the server has indicated support of a cached object in the server
hello, the requirement to replace that object with a hash should be a MUST.

It turns out that it was not to late to cancel the submission, so I have
already incorporated this in the 00 draft and resubmitted.

If you follow the same link and hit "refresh" you will see the changes.

/Stefan



On 09-06-05 1:38 PM, "Simon Josefsson" <[e-mail]> wrote:

> Stefan Santesson <[e-mail]> writes:
> 
>> I have finally incorporated the agreed changes to what previously was called
>> the cached certs extension, now changed to the cached information extension,
>> and submitted the first (00) TLS draft.
>> 
>> The draft is available from the following staging URL until it¹s made
>> available as a TLS draft.
>> http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-00.txt
> 
> I support this.  I've seen 40kb handshakes due to the server return a
> list of acceptable CAs, and that has generated some interop problems
> with GnuTLS [1].
> 
> The document appears to be in good shape.  I believe I could implement
> the document if two (minor) concerns were resolved.
> 
> First, this paragraph:
> 
>    Servers that receive an extended client hello containing a
>    "cached_information" extension, MAY indicate that they support one or
>    more of the cached information objects by including an extension of
>    type "cached_information" in the (extended) server hello, which SHALL
>    contain at least one CachedObject received from the client.
> 
> The intention here appears under-specified.  What does it mean if the
> client sent two CachedObject's and the server just returned one of them?
> One plausible interpretation would be that the server did not support
> the hash/type-combination that were not returned.  Enforcing that
> interpretation is needed to resolve my second concern.
> 
> I suggest to add a sentence:
> 
>    The CachedObject's returned by the server MUST include the types the
>    server supports and has accepted to replace with cached data.
> 
> Secondly, this paragraph:
> 
>    After negotiation of the use of cached certificates has been
>    successfully completed (by exchanging hello messages including
>    "cached_certs" extensions), the server MAY replace the cached
>    information objects in its handshake messages with a corresponding
>    hash_value from CachedInformationHash that was included in the
>    cached_information extension of the server hello message.
> 
> Why a MAY here?  How would a client distinguish whether the server did
> replace the data or not?  Why not use the extended server hello to
> return the supported types (as suggested above)?  This appears to add
> complexity for no particular reason, at least as far as I can
> understand.
> 
> I suggest to replace MAY with MUST here.
> 
> Thanks,
> /Simon
> 
> [1] GnuTLS refuses large handshakes due to DoS concerns, and we had to
> increase the limit.