Re: [Gen-art] Generate review of draft-ietf-tls-cached-info-20

[Jouni <[e-mail]>]

Hi Hannes,


> On 21 Dec 2015, at 11:31, Hannes Tschofenig <[e-mail]> wrote:
> 
> Hi Jouni,
> 
> thanks for your review. Please find my response inline:
> 
> On 11/30/2015 04:46 AM, Jouni wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document: draft-ietf-tls-cached-info-20 Reviewer: Jouni Korhonen 
>> Review Date: 2015-11-29 IETF LC End Date: 2015-12-04 IESG Telechat
>> date: 2015-12-17
>> 
>> 
>> Summary: --------
>> 
>> Ready for publication with some nits.
>> 
>> Comments: ---------
>> 
>> The document was good read and easy to understand.
>> 
>> Minor issues/nits: ------------------
>> 
>> * IDnits spits out some warning & comments that all seem to be bogus.
>> However, the normative reference to RFC 4634 needs to be replaced
>> with RFC 6234.
> Fixed.
> 
>> 
>> * The document describes in few places how the mechanisms specified
>> extends/updates the Certificate and CertificateRequest structures. So
>> maybe the draft should also state that in its boilerplate “Updates:
>> 5246, 7250” ?
>> 
> 
> I believe it only explains the interworking with other, related
> specifications but it does not really update them.
> 
> Regarding RFC 7250: With RFC 7250 the Certificate payload may contain a
> SubjectPublicKeyInfo payload rather than a certificate. I wanted to
> point this out in the description.
> 
> Regarding RFC 5246: The specification re-uses existing TLS 1.2 payloads
> and defines extensions for them but it does not change the behavior of
> the underlying TLS 1.2 mechanism.

Ok. 

> 
> 
> 
>> * Line 99: s/its’/its
> 
> OK.
> 
>> 
>> * Line 164: s/data\.\./data\.
> OK.
> 
>> 
>> * Section 5 talks about “input data” for the hash & fingerprint
>> calculation. What the “input data” exactly is becomes obvious after
>> reading the Appendix A. However, for non-TLS WG activist it was not
>> obvious from the first sight. Suggest adding a forward reference to
>> Appendix A example.
> 
> Fine with me.
> 
>> 
>> * Section 6 uses [0], [1], .. [4]. While these are perfectly correct
>> they can be mixed with references in the first sight -> few seconds
>> of confusion ;) I would suggest using (0), .. (4).
> 
> Sounds reasonable.
> 
>> 
>> * The document uses referencing all styles “RFC 7250 [RFC7250]”, “RFC
>> 7250” and “[RFC7250]”. Pick one.
> Ok.
> 
>> 
>> * It is unclear to me what happens & what are the procedures when two
>> different “input data”s generate the same fingerprint.
> 
> Since the client caches information previously provided by the server,
> such as the certificate, it is the server that can detect that such a
> collision can occur. If it occurs the server operator has two options,
> namely not to use the extension or to resolve the conflict.
> 
> Does this description make sense?

Yes. You should probably add the above in some form to the draft. It is a good clarification.

- Jouni


> 
> Ciao
> Hannes
>