Hannes, Go ahead and post the -20 version so we can get this ball rolling.
spt On Aug 24, 2015, at 09:38, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > 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 >> > > _______________________________________________ > 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
