[TLS] AD review of draft-ietf-tls-exported-authenticator-13

[Roman Danyliw <[e-mail]>]

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