Hi! I've assumed the role of responsible AD on this document. As such, I performed an AD review of draft-ietf-tls-exported-authenticator-13. This document has seen a few WG LCs and reviews. Thanks for working out the details for this feedback. I have a few questions and suggestions for process and editorial clarity described below. Given that, I'm going to advance this document to IETF LC and the feedback below can be discussed/addressed concurrently.
** Section 1. Editorial. Provide a reference to TLS 1.3 when it is first mentioned. OLD Post-handshake authentication is defined in TLS 1.3 NEW Post-handshake authentication is defined in Section 4.6.2 of TLS 1.3 [TLS13] ** Section 1. Editorial. Provide references to for (D)TLS 1.2 OLD TLS (or DTLS) version 1.2 or later are REQUIRED NEW TLS (or DTLS) version 1.2 [RFC5246][RFC6347] or later are REQUIRED. ** Section 5. The application layer protocol used to send the authenticator SHOULD use TLS or a protocol with comparable security properties as its underlying transport I saw the additional text added here after the LC on -09 (and the discussion that this can't be MUST-use-TLS because of use cases like QUIC). However, what is the envisioned flexibility by using SHOULD (instead of MUST) given the addition of the "or a protocol with comparable security properties"? When would I want to use a protocol with reduced security properties? ** Section 5.1. Editorial. These values are derived using an exporter as described in [RFC5705] (for TLS 1.2) or Sec. 7.5 of [TLS13] (for TLS 1.3). -- Please provide the relevant section in RFC5705 (just like was done for [TLS13]) -- s/Sec. 7.5/Section 7.5/ ** Section 5.2.2. Editorial. Per "The definition for TLS 1.3 is:" begs the question of what that format might be for TLS 1.2. Can you please make it clearer that the format is the same. ** Section 5.2.2. Otherwise, the signature algorithm used should be chosen from the "signature_algorithms" sent by the peer in the ClientHello of the TLS handshake. -- Editorial. For clarity, s/ Otherwise, the signature algorithm used .../Otherwise, with spontaneous server authentication, the signature algorithm used .../ -- Would it make sense to make this "should" and normative "SHOULD"? ** Section 5.2.4. When validating an authenticator, a constant-time comparison SHOULD be used. What's the concern here? IMO, this guidance seems better in Section 7.4 ** Section 7.*. As Section 7 states that 7.* is informative: -- Section 7.3. Downgrade the single normative "RECOMMENDED" to be "recommended". -- Section 7.4. Downgrade the single normative "SHOULD" to be "should" ** Section 8.1. Why shouldn't this document also be added to the "Reference" column to explain the addition of "CR" to the "TLS 1.3" column? ** Section 8.2. With these additions to "Exporter Labels" registry, please describe the values of the other fields: -- How should the "DTLS-OK" and "Recommended" columns be set? -- The obvious text that this document should be the "Reference" Regards, Roman _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
