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

From: Nick Sullivan <[email-masked]>
Date: Wed, 9 Oct 2019 17:47:18 -0700

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 <
[email-masked]> 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
>
>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 10 Oct 2019 12:26:11 +1100

I think that the DTLS thing doesn't require as much rewriting as observed.  Just say that when you say "TLS" you mean "TLS or DTLS" somewhere up front.

As to what a transport needs to provide, I think that there is no real text to add regarding DTLS.  You *could* say that as the application protocol is responsible for carrying the messages, might find that using a DTLS connection introduces new problems.  Specially, these are big messages and they are likely to require fragmentation and reassembly if DTLS is used.  Also, if the protocol depends on these messages being reliably delivered, it will want to provide some sort of loss recovery mechanism.

On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote:
> 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 
> <[email-masked]> 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 think the answer is yes. I don't see any reason to disallow the use of Exported Authenticators in DTLS.
> >  >>
> >  > 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 
> >  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?
> 
> >  >>>> 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.
> >  >>
> >  > 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
> >  >>> The issue is that servers can generate spontaneous exported authenticators without
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 10 Oct 2019 07:07:39 -0700

The main concern I had about including DTLS explicitly in this document was
because exporters are not officially defined for DTLS. However, some other
documents assume they are portable so maybe this is an overly conservative
choice.

On Wed, Oct 9, 2019 at 6:26 PM Martin Thomson <[email-masked]> wrote:

> I think that the DTLS thing doesn't require as much rewriting as
> observed.  Just say that when you say "TLS" you mean "TLS or DTLS"
> somewhere up front.
>
> As to what a transport needs to provide, I think that there is no real
> text to add regarding DTLS.  You *could* say that as the application
> protocol is responsible for carrying the messages, might find that using a
> DTLS connection introduces new problems.  Specially, these are big messages
> and they are likely to require fragmentation and reassembly if DTLS is
> used.  Also, if the protocol depends on these messages being reliably
> delivered, it will want to provide some sort of loss recovery mechanism.
>
> > >  >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.
> > >
> > >  > 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
> > >  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?
> >
> > >  >>> Yes, there is nothing disallowing the creation of multiple
> exported authenticators with the same certificate.
> > >  >>
> > >  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:
> > >

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Oct 2019 07:36:14 -0700

Well, DTLS is one of the primary consumers of exporters
https://tools.ietf.org/rfcmarkup?doc=5764, so as a practical matter I think
we've accepted that. I'm not aware of a practical problem with exporters
and DTLS, but if there is one, we should document it and address it.

-Ekr

On Thu, Oct 10, 2019 at 7:08 AM Nick Sullivan <nick=
[email-masked]> wrote:

> The main concern I had about including DTLS explicitly in this document
> was because exporters are not officially defined for DTLS. However, some
> other documents assume they are portable so maybe this is an overly
> conservative choice.
>
>> > >  >>> I think the answer is yes. I don't see any reason to disallow
>> the use of Exported Authenticators in DTLS.
>> > >  >>
>> > >  > 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.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Oct 2019 06:59:59 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

---

---

---

Ok. Looks good.

Regards,

Christer