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

From: Joseph Salowey <[email-masked]>
Date: Thu, 6 Aug 2015 10:24:12 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Aug 2015 13:33:51 -0700

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 <[email-masked]> 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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Aug 2015 18:38:52 +0200

Hi Martin,

thanks for your review.

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

Good catch. A copy-and-paste error.

> description of what is covered is a little too terse (and badly

There are multiple message type / message length fields included in the
message and I am not sure which of those you rare referring to.

The msg_type and msg_length from the record layer is not part of the
fingerprint calculation. The spec only focuses on the certificate
message in Section 4.1 and the CertificateRequest message in Section
4.2. These message do, however, also contain length information.

I included an example into the document. See Appendix A:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt

> for the hashes that are used here.

We had a negotiation capability in earlier versions of the document but
it appeared to be an overkill.

What is there now is essentially an indication of the hash algorithm
based on what the client presents with the CachedInformationType
structure. If you need support for a new algorithm then add a new type
(and the implementation). We could make it easier to add new algorithms
(via the expert review process). We could also register another
algorithm already now, if found necessary.

>  Though I think the chances of a
> that much flexibility.

While there is indeed a possibility for hash collisions those will still
lead to a failed exchange since the TLS server will not possess the
correct private key that corresponds to the cached certificate.

>  If the current design is retained, I would
There are three designs possible for referencing the cached state, namely

1) The client creates the reference.

This is the current approach. The client creates a reference (via the
use of the hash function) and tells the server that it has seen certain
parameters before and that there is no need to re-transmit them.

2) The server creates the reference.

In this design the server allocates the reference and sends it to the
client. The client

3) There is no reference at all.

The client just tells the server not to send certain payloads because it
has cached something already previously. While the server does not get
told what has been cached the worst thing that can happen is that the
exchange fails (in which case the client has to fall back to a full
exchange).

Which approach do you prefer? We had various iterations of this
throughout the lifetime of the document.

Independently of these three approaches it is certainly true that fewer
bytes transmitted over the wire are preferable.

Ciao
Hannes

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Aug 2015 11:35:46 -0700

Hi Hannes,

> 4.2. These message do, however, also contain length information.

I refer to the msg_type and length from the handshake message, which
are the only things with that name in the TLS spec.

You use the name `CertificateRequest`, which leads me to conclude that
you mean the struct identified as such, which is *inside* the
handshake message.  (I'm fine with hashing that part, I just want to
have it be very clear.)

> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt

This includes the msg_type and length.  Which means that you should
talk about hashing `Handshake` instead.

> it appeared to be an overkill.

Yeah, that's why I'm thinking that this can use the PRF hash.

> structure.

I don't see that anywhere.  The algorithm seems to be fixed to SHA-256
in the current draft (and your copy).

> correct private key that corresponds to the cached certificate.

Right, this might be all that the analysis requires.

> 3) There is no reference at all.

I'm not suggesting that you change the design, just provide a
description of the properties that it provides - and those that it
relies on.

On the surface at least, it seems OK to rely on a weak guarantee of
collision resistance from the hash.  Failure only results in handshake
failure, after which the client can fall back.  That suggests that a
truncated hash output could be used, potentially saving quite a few
bytes in the client's first flight.  I'd like to do that if it is
possible.

However, I'm concerned that eliding identity will lead to a weakness
somewhere.  For instance, if the client uses a shorter hash, then the
server might pick up different certificates.  Or, it means that
identity is not bound to the session hash as directly.  If, as you
say, we can rely on this being a direct selector for a private key
where the security is bound to that private key, then maybe it's OK.