Subject: [TLS] Comments on draft-ietf-tls-exported-authenticator-00

From: Watson Ladd <[email-masked]>
Date: Tue, 23 May 2017 12:40:16 -0700

Dear all,

I don't think this design needs to be as complex as it is. Why isn't
signing a party-dependent (server or client) exporter with the key of the
certificate, and then appending the certificate chain, enough? I am fairly
certain this gets the properties we need.  Further, the language around
jointly authoritative remains very opaque to me.

My other (much more minor) comment is that exporters labels should start
with "EXPORTER" in RFC 5705, and I don't see why this draft shouldn't do
it.

Sincerely,
Watson Ladd

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 23 May 2017 20:07:00 +0000

Hi Watson,

Some points that should help clarify your questions:
1) The certificate used in the construction is no the plain certificate
chain, it's the TLS 1.3 certificate message which could contain extensions.
2) The finished message is used to bind the certificate+certificateverify
to the connection state. It mirrors TLS 1.3 post-handshake authentication.
3) In TLS 1.3 post-handshake authentication, each successive certificate
added to the connection is incorporated into the handshake state. The last
certificate in a sequence of authentications would result in a connection
in which the party could say they were jointly authoritative a over
multiple identities. In exported authenticators, the only state that is
signed comes from the original handshake, so there's no way to order them.
Each exported authenticator is tied to the connection, but not tied
directly to another authenticator, and therefore there is no proof that the
party is "jointly authoritative". I welcome text changes to make this more
clear.
4) We can add the prefix in the next draft, thanks for the note.

On Tue, May 23, 2017 at 12:40 PM Watson Ladd <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 May 2017 15:11:56 -0500

On 05/23/2017 03:07 PM, Nick Sullivan wrote:
> 3) In TLS 1.3 post-handshake authentication, each successive
> certificate added to the connection is incorporated into the handshake
> state. The last certificate in a sequence of authentications would
> result in a connection in which the party could say they were jointly
> authoritative a over multiple identities. In exported authenticators,
> the only state that is signed comes from the original handshake, so
> there's no way to order them. Each exported authenticator is tied to
> the connection, but not tied directly to another authenticator, and
> therefore there is no proof that the party is "jointly authoritative".
> I welcome text changes to make this more clear.

I thought at least for "normal" post-handshake auth, the handshake hash
used was always just the initial handshake, and did not include
intermediate certificates that had been transmitted.

-Ben

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 23 May 2017 21:06:35 +0000

Ben,

Thanks for pointing that out, you are right. A client is jointly
authoritative if there was in-handshake client auth followed by a
post-handshake client auth. Subsequent client authentications can be
computed in any order and are disambiguated by the context id.

Nick