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

[Christer Holmberg <[e-mail]>]

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