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

[Martin Thomson <[e-mail]>]

I've read this draft before, but this is considerably different to
what I read, and I haven't been following the discussion, so consider
this as a review with fresh eyes.

First the high points.  I think that this is useful, the right scope,
and reasonably well formulated.  I have a couple of minor points

Figure 2 is in error: it shows CertificateRequest instead of Certificate.

I'd like to see the document explicitly note that msg_type and length
from the handshake message are not covered by the hash.  The
description of what is covered is a little too terse (and badly
formatted).

I'm not sure that I like the lack of both negotiation and signaling
for the hashes that are used here.  Though I think the chances of a
collision being found, or that a collision would lead to an attack,
are slim, I would rather see this use the PRF hash so we have at least
that much flexibility.  If the current design is retained, I would
like to see a little discussion of this in the document.  A little
analysis of the properties we expect the hash to provide would also be
good.

I think that truncated hashes might be advantageous from the server
side.  Given that the server only uses hashes to identify which of the
offered (available, known?) cached information is in use, is there any
reason you can't save additional space by arbitrarily truncating the
hash?  In many cases I would imagine that the client would be offering
only one option and even if there were a small number of options
presented, a single byte would suffice to disambiguate.

I'm trying to think why you might want the full-length hash on the
client side, but I believe that the only problem there is that there
might be a collision between the certificates that a server might
offer if you truncate too aggressively.  The connection still relies
on the server presenting proof of knowledge of a key that the client
extracts from a certificate bound to the server identity, so I believe
that it would be equally secure if you removed all mention of
certificates from the protocol.  And that makes me nervous, because
I'm fairly sure that Karthik will tell me that I'm wrong very shortly;
since we've put in a lot of work to cover key fields in the handshake
hash, and I'm concerned that this could be exploited somehow.

The more I think about this, the more I think that we need a little
more analysis on this point (i.e., what properties the hash function
needs to provide and why).  If it has already happened, mention of
that in the security considerations is needed.

(I think that truncation on the server side is safe if the client uses
a strong hash function to identify the certificate, but I'm frequently
wrong about these things.)


On 6 August 2015 at 10:24, Joseph Salowey <[e-mail]> wrote:
> Hi Folks,
>
> This is the Working Group last call for draft-ietf-tls-cached-info-19.  This
> document has undergone modification since last WGLC so another WGLC is
> appropriate.  This document is a dependency for the DICE working group
> TLS/DTLS profile. Please send your comments to the TLS list by September 2,
> 2015.
>
> Thanks,
>
> J&S
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>