Reviewer: Christer Holmberg Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-tls-exported-authenticator-09 Reviewer: Christer Holmberg Review Date: 2019-07-07 IETF LC End Date: 2019-07-16 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written. However, I have found some issues that the author may want to consider clarifying in the document. Major issues: N/A Minor issues: MIN_1: The last sentence of Section 1 says that the mechanism requires TLS version 1.2 or later. Would it be useful to state that in a dedicated Applicability section? MIN_2: Can the mechanism be used also for DTLS? MIN_3: The documents talk about additional certificates. If I only have one additional certificate, can I use that for multiple authenticators throughout the TLS session? MIN_4: Section 3 and 4 say that the authenticator request and authenticator SHOULD be sent using TLS, and Section 1 says that the proof of authentication can be sent out-of-band. I think it would be useful to clarify whether both the authenticator request and authenticator can be sent out-of-band ( i.e., not using the TLS connection that the additional authentication is associated with), and also to state whether it IS allowed to send the authenticator request and authenticator on the TLS connection they are associated with. MIN_5: Section 5 talks about an endpoint sending an empty authenticator. But, what if the sender of the authenticator request does not receive anything? Does it simply move on? Does it terminate the TLS session? Is the action based on local policy? MIN_6: Related to MIN_5, I can't find text about how endpoints inform each other about the support of the mechanism, so maybe a few words about that would be useful. And some words about backward compatibility with endpoints that don't support the mechanism. MIN_7: What happens if the validation of an authenticator fails? Does the requester simply move on? Does it terminate the TLS session? Is the action based on local policy? Nits/editorial comments: ED_1: The document uses "session", "TLS connection" and "TLS communication" terminology. Is that intentional, or wouuld it be possible to use consistent terminology? ED_2: Section 3 says: "The authenticator request is a structured message that can be created..." Section 4 says: "The authenticator is a structured message that can be exported..." In the 2nd paragraph of Section 4 it is stated that "authenticator" is sent based on an "authenticator request". I wonder if that could be stated already in the beginning of Section 4, to further clarify the difference between them. E.g., "The authenticator is a structured message, triggered by an authenticator request, that can be exported from either party of a TLS connection."
