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

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Dec 2015 14:56:54 +0200

Thank you very much for the review, Jouni! Authors, do you have observed these comments?

Jari

On 30 Nov 2015, at 05:46, Jouni <[email-masked]> 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.
> 
> * 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” ?
> 
> * Line 99: s/its’/its
> 
> * Line 164: s/data\.\./data\.
> 
> * 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.
> 
> * 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).
> 
> * The document uses referencing all styles “RFC 7250 [RFC7250]”, “RFC 7250” and “[RFC7250]”. Pick one.
> 
> * It is unclear to me what happens & what are the procedures when two different “input data”s generate the same fingerprint.
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Dec 2015 17:04:17 +0100

Yes, I have seen the review comments and will address them in the next
few days.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Dec 2015 19:04:50 +0200

Thanks!

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Dec 2015 20:31:24 +0100

Hi Jouni,

thanks for your review. Please find my response inline:

On 11/30/2015 04:46 AM, Jouni wrote:
> 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: --------
> 
> Comments: ---------
> 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.

> 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

---

From: Jouni <[email-masked]>
Date: Mon, 21 Dec 2015 19:36:48 -0800

Hi Hannes,

> On 21 Dec 2015, at 11:31, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Jouni,
> 

Ok. 

> Does this description make sense?

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

- Jouni