Hi Martin, thanks for your review.
On 08/06/2015 10:33 PM, Martin Thomson wrote: > 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. Good catch. A copy-and-paste error. > > 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 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 > > 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. 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 > 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. > 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. 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 > > On 6 August 2015 at 10:24, Joseph Salowey <j...@salowey.net> 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
