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

[Sean Turner <[e-mail]>]

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