Francesca Palombini has entered the following ballot position for draft-ietf-tls-exported-authenticator-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work on this document, and thank you to the doc shepherd for the in-depth background. Please find some comments below. Francesca 1. ----- TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED to implement the mechanisms described in this document. FP: Does this mechanism applies to DTLS as well? The sentence above, the normative reference to DTLS 1.2, and the IANA section 8.2 would imply so. However, this is the only time DTLS is mentioned in the body of the document, excluding IANA considerations. I would like it to be made explicit that this mechanism can be used for DTLS (if that's the case) both in the abstract and in the introduction, add any useful considerations about using this mechanism with DTLS vs TLS, and possibly add a sentence in the introduction stating that DTLS 1.X uses what specified for TLS 1.X. Two examples of why that would be useful are the following sentences: using an exporter as described in Section 4 of [RFC5705] (for TLS 1.2) or Section 7.5 of [TLS13] (for TLS 1.3). For TLS 1.3, the "signature_algorithms" and "signature_algorithms_cert" extension, as described in Section 4.2.3 of [TLS13] for TLS 1.3 or the "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of [RFC5246] for TLS 1.2. which makes it clear what applies for TLS but not for DTLS. 2. ----- used to send the authenticator request SHOULD use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as its as its FP: What are the implications of not using such a secure transport protocol? Why is it just RECOMMENDED and not MANDATED? nits: missing word "use a secure with" ; remove one of the duplicated "as its". (Note: this text appears again with the same typos for the authenticator in section 5) 3. ----- extensions (OCSP, SCT, etc.) FP: Please consider adding informative references. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
