Hi Nick, Thanks for your reply! Please see inline. >>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? > > I'm disinclined to include an applicability section considering how short it would be. > I'm open to being convinced otherwise with examples. If others think it's clear enough (or, that it doesn't need to be that clear, because earlier versions will anyway disappear), I am fine to keep in in Section 1. --- >> MIN_2: >> Can the mechanism be used also for DTLS? > > I think the answer is yes. I don't see any reason to disallow the use of Exported Authenticators in DTLS. Would it be useful to clarify that? --- >> 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? > > Yes, there is nothing disallowing the creation of multiple exported authenticators with the same certificate. Would it be useful to clarify that? --- >> 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. > > Good point. I can clarify this a bit. Both the authenticator and authenticator request can be sent > through either the TLS connection they were derived from or another TLS connection altogether. > The important part is that they are sent over an encrypted and authenticated connection. Thanks! --- >> 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? > > The TLS layer is stateless. The decision to time out or fail the connection if an authenticator request > is not responded to is left to higher-level protocols that leverage EAs. > >> 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. > > Adding an extension to signal support for exported authenticators was discussed at some point, > but it was decided that the higher-layer application should handle the signaling. > >> 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? > > This is also up to the application-layer protocol. I'll add text covering MIN_5, MIN_6 and MIN_7. Thanks! --- >> ED_1: >> The document uses "session", "TLS connection" and "TLS communication" >> terminology. Is that intentional, or wouuld it be possible to use consistent >> terminology? > Good note. I'll standardize on "connection". Thanks! --- >> 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." > > The issue is that servers can generate spontaneous exported authenticators without > an authenticator request. Where is this written? Did I miss it? > Given this, the updated sentence would be: > > "The authenticator is a structured message, sometimes triggered by an authenticator > request, that can be exported from either party of a TLS connection." > Which I'm not sure is an improvement to readability. I agree that "sometimes triggered" does not improve readability, but doesn't there still always have to be at least one authenticator request before any authenticator is sent? Regards, Christer
