Re: [TLS] First TLS cached information draft posted

[Simon Josefsson <[e-mail]>]

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.