Re: [Gen-art] Genart last call review of draft-ietf-tls-exported-authenticator-09

[Nick Sullivan <[e-mail]>]

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 <
[e-mail]> 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."
>
>
>