Subject: [TLS] draft-sullivan-tls-exported-authenticator-01

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Apr 2017 10:44:01 +0200

I have read draft-sullivan-tls-exported-authenticator-01 and have a few
questions. I haven't followed this work previously but have been
wondering whether this functionality would be useful for "me".

The described functionality sounds like post-handshake authentication
from TLS 1.3 (although it does not use that term throughout the
document). I would have thought that this functionality is a replacement
to the TLS 1.2 renegotiation but then there is also the TLS 1.3 content
in there which raises the question about how this relates to the
post-handshake authentication functionality.

What does the following sentence mean and what is the use case for it?

"
  This proof of authentication can
   be exported and transmitted out of band from one party to be
   validated by the other party.
"

Who are the parties?

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Apr 2017 13:52:14 +0300

> post-handshake authentication functionality.

There are two things that can't be accomplished with PHA:

- Authenticating the server for more identities.
- Transmitting application context with the certificate.

TLS 1.2 renegotiation also is incapable of either of those.
 
>    validated by the other party.

Most probably TLS client and server.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Apr 2017 17:42:08 +0200

Hi Ilari,

thanks for your feedback. Remarks inline:

> TLS 1.2 renegotiation also is incapable of either of those.

In what situations would I want those features? The draft is rather
brief on the motivational side.

> Most probably TLS client and server.

Maybe the draft should say that.

Ciao
Hannes

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Apr 2017 10:13:27 -0700

> brief on the motivational side.

Part of the reason TLS client certificate UX sucks is the absence of
hints as to which certificates are offered. It's a lot easier to add
that to HTTP then to TLS. It also fixes bugs where authentication
state doesn't line up nicely with HTTP request state.

The other application is to servers which want to indicate they have
certificates for other sites, so as to enable connection reuse for a
latency and performance win.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 24 Apr 2017 20:30:02 +0300

> brief on the motivational side.

- Client authentication in HTTP/2 after handshake.
- Dynamically adding server identities in HTTP/2 in order to hide
  services (SNI encryption is _HARD_).

-Ilari