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

[Nick Sullivan <[e-mail]>]

Thanks again for your review! The PR is on Github (
https://github.com/tlswg/tls-exported-authenticator/pull/50) and will be
incorporated into a new version of the document that addresses both your
comments and those by Yaron Sheffer.

On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg <
[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
>
>
>