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

[Christer Holmberg <[e-mail]>]

Hi,

>Thanks again for your review! The PR is on Github (https://github.com/tlswg/tls-exported-authenticator/pull/50<https://protect2.fireeye.com/url?k=44e4cb6c-186d1140-44e48bf7-0cc47ad93da2-d674bd41a094d4bb&q=1&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Ftls-exported-authenticator%2Fpull%2F50>) and will be incorporated into a new
>version of the document that addresses both your comments and those by Yaron Sheffer.

Looks good.

Regards,

Christer

On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

>Some answers to your questions inline. I'm not sure further changes along the lines suggested here are needed, but I'm open to arguments that point in that direction.

I am mostly fine with your answers. Just a couple of comments inline still.

---

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?
>
> Going through what the modified text would look like, it seems like a substantial amount of re-writing (even the title!) for what amounts to an unclear use case.
> Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't directly define exporters, I'm disinclined to define how EAs would work with DTLS. If someone
> has a strong use case for EA in DTLS, it may be worth considering it.

Would it then be useful with a statement saying that it might be possible to use exporters also with DTLS, but that such usage is outside the scope of the document and needs to be specified in a separate document?

I added a line to this effect.

---

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?
>
> I'm not convinced this is a realistic use case. Since exported authenticators are based on the exporter, there is no inherent ordering.
> If you re-authenticate with the same certificate, there's nothing asserting freshness of the second certificate. Is there something in
> the text that suggests that using a certificate multiple times is disallowed? If there's no suggestion that this is not possible that
> needs to be corrected, I don't see the benefit of calling out this specific use case.

I don't think there is any text suggesting that it is disallowed. But, if you don't think it is a realistic use case I'll take your word for it :)

---

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?
>
> Section 4:
>   An authenticator message can be constructed by either the client or
>   the server given an established TLS connection, a certificate, and a
>   corresponding private key.  Clients MUST NOT send an authenticator
>   without a preceding authenticator request; for servers an
>   authenticator request is optional.  For authenticators that do not
>   correspond to authenticator requests, the certificate_request_context
>   is chosen by the server.

Ok. Looks good.

Regards,

Christer