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 <m...@lowentropy.net> 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 > > <christer.holmb...@ericsson.com> 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 > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
