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

[Sean Turner <[e-mail]>]

I have entered these as an issue in the repo:
https://github.com/tlswg/tls-exported-authenticator/issues/66

spt

> On Oct 2, 2020, at 12:50, Roman Danyliw <[e-mail]> wrote:
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls