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= 40cloudflare....@dmarc.ietf.org> 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 <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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
