[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09
From:       Christer Holmberg <christer.holmberg=40ericsson.com () dmarc ! ietf ! org>
Date:       2019-09-20 6:29:04
Message-ID: 57E5EB36-6A59-45A7-A2F4-1E1626391742 () ericsson ! com
[Download RAW message or body]

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?

---

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


[prev in list] [next in list] [prev in thread] [next in thread]