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

[Eric Rescorla <[e-mail]>]

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=
[e-mail]> 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.
>
> On Wed, Oct 9, 2019 at 6:26 PM Martin Thomson <[e-mail]> 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.
>>
>> 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
>> > <[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
>> > >
>> > >
>> > _______________________________________________
>> > TLS mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>