Re: [TLS] WGLC: draft-ietf-tls-cached-info

[Eric Rescorla <[e-mail]>]

 Comments below. Generally, I think some work is still needed here.

I'm starting to wonder whether this piecemeal design is really
the one we want here. I.e., it's possible for the client
to let the server cache X and Y but not Z. I wonder
if we instead want the server to advertise "This is
configuration XXX and the client just says OK" rather
than letting the client pick and choose. How much
more bandwidth would that really lose?


Conversely, if we're going to have a pick and choose design,
we should think about adding the client's cert since that
can be large.


I think the text needs to be tightened up to be clear on what's
going on. As I understand it:

- The client can offer as many cached items as it wants including
  multiples of the same type.

- The server can respond with at most one of each type. If he
  offers a value that the client offered that means he is
  going to omit that value. If he offers a value that the
  client didn't offer, that means he would be willing to let
  the client cache that value.

Is this correct? If so, these seem like kind of confusing
semantics, since it means that, for instance, if the client
offers:

 certificate = X

and the server responds with:

 certificate = X

Then it means that the server will omit the cert but if the server
offers certificate = Y it means "I would be willing to omit cert Y"
but I didn't omit X. I trust it does not mean "I omit Y".
That seems confusing.


Section 3.
I Suggest renaming the "trusted_cas". That seems like a bad name
for this.

Do we want to add OCSP responses to this.



Section 4:
   Following a successful exchange of the "cached_information"
   extensions in the client and server hello, the server omits sending
   the corresponding handshake message.

My understanding was that you in fact shrank the message but didn't
omit it.


Section 4.2.

   When a fingerprint for an object of type 'trusted_cas' is provided in
   the client hello, the server MAY send a DistinguishedName in the
   Certificate Request message with an actual length field of zero
   (=empty vector).

This is a sequence of DistinguishedNames. So do you
send a list with one empty DN in it or an empty list?

Is there a reason not to just compress the entire message?
Surely the types and algorithms are just as stable.


Section 5:
   namely 'trusted_cas' (also defined in this document), and the 'foo-
   bar' extension (i.e., an imaginary extension that yet needs to be
   defined).

Nit: extensions generally have underscores.


Please make these diagrams match the style in RFC 5246.


Section 6:
   The hash algorithm used in this specification is required to have
   reasonable random properties in order to provide reasonably unique

You don't mean "random", right?


I also share AGL's concerns about the security analysis.









On Tue, Jul 29, 2014 at 5:48 AM, Sean Turner <[e-mail]> wrote:

> This is the working group last call for draft-ietf-tls-cached-info:
>   http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/
> Please send comments on this draft to the TLS list before August 19, 2014.
>
> J&S
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>