[TLS] Francesca Palombini's No Objection on draft-ietf-tls-exported-authenticator-14: (with COMMENT)

[Francesca Palombini via Datatracker <[e-mail]>]

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.