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 <r...@cert.org> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
