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 > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
