Subject: [quicwg/base-drafts] Text banning post-handshake client auth is unclear (#2367)

From: David Schinazi <[email-masked]>
Date: Wed, 23 Jan 2019 17:03:58 +0000 (UTC)

draft-tls section 4.4 (Peer Authentication) states:
> A server MUST NOT use post-handshake client authentication (see Section 4.6.2 of [TLS13]).

This sounds like there are security implications, but what they are is unclear. As a reader of the document, this makes me doubt my understanding of the protocol.

If we don't have a good justification for banning this, we shouldn't be banning it.

(This is me reopening #2294 since that was closed for being a question.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2367

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Jan 2019 11:56:28 -0800

Is the text unclear, or are you asking to re-enable post-handshake authentication?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2367#issuecomment-456943871

---

From: MikkelFJ <[email-masked]>
Date: Wed, 23 Jan 2019 12:58:22 -0800

At least I am curious about the reasoning behind this, not that I am against it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2367#issuecomment-456963448

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Jan 2019 15:04:02 -0800

@mikkelfj, The best way to understand the rationale is to try to work through how a particular protocol might use this feature.  Read [HTTP/2 secondary certificate authentication](https://httpwg.org/http-extensions/draft-ietf-httpbis-http2-secondary-certs.html), look at the design and discussion and see the sorts of problems it tries to address.  In that case, some of the problems are with server-authentication, which you can safely ignore, but the general class of problems related to concurrency and how that relates to the status of authentication produce a fairly complex design.

Now I might concede that it is possible to build a protocol that uses this TLS feature well, but I would still hold that [exported authenticators](https://tlswg.github.io/tls-exported-authenticator/draft-ietf-tls-exported-authenticator.html) are a far superior design.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2367#issuecomment-457001043

---

From: MikkelFJ <[email-masked]>
Date: Wed, 23 Jan 2019 15:19:15 -0800

@martinthomson Thanks for the explantion and pointers. On exported authenticators I guess there is some overlap with OAuth2, Fido, and temporary web service tokens once you get past the handshake.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2367#issuecomment-457004662

---

From: David Schinazi <[email-masked]>
Date: Wed, 23 Jan 2019 15:57:14 -0800

@martinthomson if we have a good reason (which it sounds like we do), then this issue tracks adding that reason to the draft.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2367#issuecomment-457013361