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

[Eric Rescorla <[e-mail]>]

Sorry it's taken me so long to respond, but I'm not convinced that it's not
necessary
to have a secure digest here. Do you have a security analysis that
demonstrates
that that's the case?

-Ekr

On Thu, Sep 10, 2015 at 7:59 AM, Martin Thomson <[e-mail]>
wrote:

> Hi Hannes,
>
> I've followed a similar chain of thought myself.  I think that the
> right answer here is similar to what you describe: the security of TLS
> does not depend on the presence of the certificate at all, rather it
> depends on the use of a private key that the client trusts.  That most
> clients rely on the certificate for getting the information they need
> to make that trust decision and that the certificate happens to be
> carried in TLS in most cases is largely consequential.
>
> On that basis, I would be happy then to accept any hash, even a
> truncated hash in both directions.  In most cases, I suspect that 8
> bits would be plenty, though I imagine that clients will want to send
> a few more than that just to reduce the odds of having to receive a
> certificate.
>
> --Martin
>
>
> On 10 September 2015 at 04:14, Hannes Tschofenig
> <[e-mail]> wrote:
> > Hi Martin,
> >
> > thanks for your feedback. I have discussed the topic with my co-worker
> > Manuel.
> >
> > Another way of seeing the use of the hash by the client is to help the
> > server to select the pick certificate (or other cached data). It does
> > not have a security purpose as such, it is only a way to prevent the
> > server accidentally including the wrong information. For example, this
> > can happen when the server has multiple certificates to choose from then
> > it should pick the right one (and I am not talking about the SNI case
> > here).
> >
> > Without the possibility for picking the wrong value we could have as
> > well omitted the hash altogether. The actual function used to compete
> > the fingerprint isn't that important as long as it helps to make sure
> > that the correct value can be chosen with a reasonable probably. In the
> > worst case, the wrong value is chosen and the exchange failed. The
> > client will then have to re-start the exchange without the cached info
> > feature.
> >
> > As such, you are certainly right that the hash does not need to be long
> > since the changes of selecting the wrong information is very low. In
> > case of the certificate the security actually comes from the private
> > key: the server needs to demonstrate that it knows the privacy key in
> > the exchange.
> >
> > Regarding the use of the TLS PRF I am not sure that this will work since
> > the actual function is the result of the negotiated cipher and not known
> > at the time when the client and the server exchange their hello messages.
> >
> > Ciao
> > Hannes
> >
> > PS: Additing extra text with information about what is included in the
> > hash will be added to make sure that implementers compute the hash over
> > the correct fields of the message.
> >
> >
> > On 08/24/2015 08:35 PM, Martin Thomson wrote:
> >> Hi Hannes,
> >>
> >> On 24 August 2015 at 09:38, Hannes Tschofenig <
> [e-mail]> wrote:
> >>>> 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).
> >>>
> >>> 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 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.)
> >>
> >>> 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
> >>
> >> This includes the msg_type and length.  Which means that you should
> >> talk about hashing `Handshake` instead.
> >>
> >>>> I'm not sure that I like the lack of both negotiation and signaling
> >>>> 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.
> >>
> >> Yeah, that's why I'm thinking that this can use the PRF hash.
> >>
> >>> What is there now is essentially an indication of the hash algorithm
> >>> based on what the client presents with the CachedInformationType
> >>> structure.
> >>
> >> I don't see that anywhere.  The algorithm seems to be fixed to SHA-256
> >> in the current draft (and your copy).
> >>
> >>>>  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.
> >>>
> >>> 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.
> >>
> >> Right, this might be all that the analysis requires.
> >>
> >>>>  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.)
> >>>>
> >>> There are three designs possible for referencing the cached state,
> namely
> >>>
> >>> 1) The client creates the reference.
> >>> 2) The server creates the reference.
> >>> 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.
> >>
> >
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>