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 <martin.thom...@gmail.com> 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 > <hannes.tschofe...@gmx.net> 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 < > hannes.tschofe...@gmx.net> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
