Subject: Re: [TLS] Review of draft-ietf-tls-cached-info-11

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 12:45:53 +0300

(added the TLS working group to share the review feedback)

Hi Ondrej, 

thanks for your feedback.

> What I found to to be missing is an example or use-case that would illustrate
> what the extension is good for. Basically an extended version of what you were
> talking about during your tls session presentation.
> 
> For example, it could look like (if I understood correctly):
> 
> 1. Bootstrap: the client does the "usual" TLS handshake, stores the
> certificates and/or their hashes
> 
> 2. On each subsequent connection, the client uses the new extension to say
> that it knows about one specific chain
> 
> 3. In case the chain changes, the client does full regular handshake (i.e. goto 1)
> 

In can add text as you suggested. 

> Question regarding this paragraph:
> 
>   When the CachedInformationType identifies a certificate_chain, then
>   the hash_value field MUST include a hash calculated over the
>   certificate_list element of a server side Certificate message,
>   excluding the three length bytes of the certificate_list vector.
> 
> My interpretation: the hash is computed over the chain retrieved from
> handshake (i.e. excluding any "possible fancy validation-path-building code"
> at the client's side)

The hash is only computed over the message structures and not over any code. 

Did I understood your concern correctly? 

> 
> Question about "trusted_cas" and the trust anchors' fingerprint: I can't
> figure out what it is supposed to accomplish from the draft.

TLS exchanges different payloads and some of them could be larger (and they rarely change) and there it makes sense to only exchange a hash over them and to send the hash instead of repeatedly sending the value. Bob, in his review, noted that there are a few extensions being developed that could also benefit from this cached extension functionality, such as draft-pettersen-tls-ext-multiple-ocsp. 

Ciao
Hannes

> 
> If you'd like we could discuss it today (Thursday).
> 
> 
> Ondrej
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJPc5fTAAoJEAy6xNgMZCEgTj4H/1yf2sytbkm475n8XLUKuSBy
> Y6QG3+T3MNgjDb09GVj16sNsmE0DstGNsyilytJfSwSIZTVhKY7GxKn0M14wVijs
> sqHT7B/haKveE1dDTK7NyTRB0Kcq43FQEb4bfInAWl0NE7z3tGmV971tPcTPfBlj
> QUJ4WYTO8R8CHZ+eXv/v5JHt8aOZNeEn4BNfQ3XEihGzLvOGd2ZMV7HMx6N7UX9U
> 1kpmnAx4YusUzWIMUOp/LvsJpr0b/YdSlHw8JtZkKxC2vyR0vEV+ItXUVHrXjovQ
> w118+6gD/dNPq4VZ0BsFAIOqpotUoVAMbqAmzwmuDP108Ct3Sxn3KbHov1/JLWc=
> =Kd+Z
> -----END PGP SIGNATURE-----