Christer, Thank you for the review. I'll attempt to address these in time for the submission window to open up again.
Best, Nick On Sun, Jul 7, 2019 at 3:58 AM Christer Holmberg via Datatracker < nore...@ietf.org> wrote: > 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." > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
