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

[Hannes Tschofenig <[e-mail]>]

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.



> * 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?

Ciao
Hannes