Subject: [TLS] HTTP, Certificates, and TLS

From: Mike Bishop <[email-masked]>
Date: Thu, 21 Jul 2016 09:38:59 +0000

Hi, folks -

Martin and I had come previously to the TLS WG to discuss our work with handling client certificates at the HTTP layer.  Based on that discussion, we revised our model to cover signatures of an exporter value and carry the proof in an HTTP/2 frame.  During BA, the HTTP WG expressed interest in flipping the model in the opposite direction - carrying additional server identities as well.  That means we now have a proposal for carrying both client and server certificates above TLS, found at https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.

We have also discussed that it might be preferable to pull part of this capability back into TLS, expanding post-handshake authentication to allow providing multiple certificates in either direction.  Since that would necessarily require additional work on that part of the TLS 1.3 spec, we discussed the possibility of splitting post-handshake authentication into a separate spec so that the core TLS 1.3 spec could proceed to WGLC as scheduled and take a little longer on the second draft.

Having spoken to some other TLS WG members, some people would prefer to move post-handshake authentication entirely to our layer.  While that's probably not feasible (HTTP/1.1 still needs post-handshake auth from TLS, regardless of what HTTP/2 does), we can retain our application-layer authentication.  This has the advantage of leaving TLS 1.3 unchanged, but keeps a security draft in a non-security working group.  We are concerned that, by doing this at the HTTP layer, we'll be missing necessary security expert review as this moves forward.  (EKR already suggested some necessary improvements to our signature model to prevent some pretty trivial attacks; these aren't reflected in the current draft.)  If that's the route we go, I would greatly appreciate some TLS folks visiting the HTTP WG and helping us review this draft.

I was on the "time permitting" list to present in the TLS meeting on Tuesday, and we didn't get a chance to.  We'll be discussing the actual draft tomorrow morning in HTTP; I'd be happy to have some TLS folks there to discuss the draft, and I'd like to get a sense from the TLS WG whether there's a preference for us to do this at the application layer or pass additional requirements to post-handshake auth.

Thanks!
-Mike Bishop

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 Jul 2016 17:57:13 +0200 (CEST)

Mike Bishop wrote:
> 
> That means we now have a proposal for carrying both client and server
> certificates above TLS, found at
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.
> 
> We have also discussed that it might be preferable to pull part of this
> capability back into TLS,

You are facing a MUST NOT in rfc6066 for this particularly bad idea.

I'm currently wondering what kind of (weird) TLS session caching strategy
would actually allow you to create such client or server behaviour.
You're definitely in severe conflict with the "principle of least surprise"
in respect to deterministic behaviour of your TLS clients and TLS servers.

-Martin

---

From: Mike Bishop <[email-masked]>
Date: Thu, 21 Jul 2016 16:08:51 +0000

I assume you're referring to Section 3, SNI's ServerNameList MUST NOT contain more than one name of a given type?  Technically, we're not violating that, since we're not changing SNI.  The client requests a single identity in the TLS handshake, which the server provides.  Additional identities can be demonstrated later, regardless of where.

Or are you referring to the (lower-case) must not resume if SNI and the certificate used in the resumed session differ?  For HTTP, we're leaving resumption out of the picture, requiring that any secondary certificates be proved anew for each connection.  You're certainly correct that if the logic were moved to TLS, the semantics of resumption would have to be defined.  That may be a solid argument on why it should remain at the application layer.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Thursday, July 21, 2016 5:57 PM
To: Mike Bishop <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] HTTP, Certificates, and TLS

Mike Bishop wrote:

> We have also discussed that it might be preferable to pull part of

> this capability back into TLS,

I'm currently wondering what kind of (weird) TLS session caching strategy would actually allow you to create such client or server behaviour.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 Jul 2016 18:41:40 +0200 (CEST)

Mike Bishop wrote:
>
> I assume you're referring to Section 3, SNI's ServerNameList MUST NOT
> contain more than one name of a given type?
>
> Or are you referring to the (lower-case) must not resume if SNI and the
> certificate used in the resumed session differ?

My (online) copy of rfc6066 has a (fully reasonable) upper-case MUST NOT.

Last paragraph on page 7, rfc6066 (TLS extension server_name_indication)

https://tools.ietf.org/html/rfc6066#page-7

   A server that implements this extension MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session.

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Jul 2016 18:44:59 +0200

>    different name.  Instead, it proceeds with a full handshake to

If that's the only barrier to doing this, I'd be surprised.  The
prospect of having to overcome this is not at all daunting.

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 Jul 2016 19:08:04 +0200 (CEST)

> prospect of having to overcome this is not at all daunting.

No, that is only the tip of an iceberg, and you're going Titanic here.

Really, this is about TLS session cache management (which is something
very close to TLS) vs. Endpoint identification, i.e. interpreting
end-entity certificates -- which is something that is explicitly
outside of the scope of TLS (e.g. rfc2818 and rfc6125).

Could you please describe the approach to session cache management that
you're conceiving here?  In the original TLS architecture (up to TLSv1.2)
TLS sessions are read-only after creation, and identities (certificates)
are locked down.  Forgetting to cryptographically bind the communication
identities into the session properties allowed the triple-handshake-attack.

If you want to change any session properties (including certificates),
you MUST perform a new full handshake, which creates a new session with
new properties and a new session ID / session cache entry.

Session resumption (and session resumption proposal) should operate
based on requested properties (is there an existing session with the
requested properties?) and this is conceptually independent from the
app-level endpoint identification (such as rfc2818/rfc6125).

The wording in rfc6066 is not optimal.  It should have better said:
whenever a full handshake would result in selection of a different
server certificate, then the server MUST perform a full handshake,
in order to produce predictable/deterministic behaviour that is
not side-effected by session cache management / session cache lifetime
effects.  The principle of least surprise.

-Martin

---

From: Mike Bishop <[email-masked]>
Date: Thu, 21 Jul 2016 17:14:21 +0000

That argument seems like it would apply to all post-handshake authentication, unless there's something different about that.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, July 21, 2016 7:08 PM
To: Martin Thomson <[email-masked]>
Cc: [email-masked]; Mike Bishop <[email-masked]>; [email-masked]
Subject: Re: [TLS] HTTP, Certificates, and TLS

Really, this is about TLS session cache management (which is something very close to TLS) vs. Endpoint identification, i.e. interpreting end-entity certificates -- which is something that is explicitly outside of the scope of TLS (e.g. rfc2818 and rfc6125).

Could you please describe the approach to session cache management that you're conceiving here?  In the original TLS architecture (up to TLSv1.2) TLS sessions are read-only after creation, and identities (certificates) are locked down.  Forgetting to cryptographically bind the communication identities into the session properties allowed the triple-handshake-attack.

If you want to change any session properties (including certificates), you MUST perform a new full handshake, which creates a new session with new properties and a new session ID / session cache entry.

Session resumption (and session resumption proposal) should operate based on requested properties (is there an existing session with the requested properties?) and this is conceptually independent from the app-level endpoint identification (such as rfc2818/rfc6125).

The wording in rfc6066 is not optimal.  It should have better said:
whenever a full handshake would result in selection of a different server certificate, then the server MUST perform a full handshake, in order to produce predictable/deterministic behaviour that is not side-effected by session cache management / session cache lifetime effects.  The principle of least surprise.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 21 Jul 2016 20:59:56 +0300

On Thu, Jul 21, 2016 at 07:08:04PM +0200, Martin Rex wrote:
> you're conceiving here? 

Well, I guess it would be reasonable to remember the server identites
on client side, but clear client identities on server side.

Especially the client identies are highly important: If the server
thinks any identity is valid that client thinks is invalid, that will
lead to attacks.

> In the original TLS architecture (up to TLSv1.2)

No, THS was caused by failing to bind the exchange keys (I consider the
abstract of EMS RFC to be quite misleading).

> new properties and a new session ID / session cache entry.

And thanks to all sorts of crypto restrictions, exchange keys have
nothing to do with certificates of any kind (all modes where they
have anything to do are banned), and that the exchange keys are properly
bound.

> effects.  The principle of least surprise.

Within context of HTTP, the server authentication is about what
authorities the server is allowed to assert. And in responses, the
server always needs to pick the authority it asserts.

As long as one takes care that no authorities get lost, or that lost
authorities can be recovered if needed (and authroized), then the
behaviour will remain deterministic (modulo possibly few extra RTTs
to recover the lost authroties).

Now, client authentication is entierely different beast. The client
won't inherently assert its authority in HTTP, so the server view
of client authority damn better be subset of what client intended,
or you WILL get privilege escalation attacks.

>From that it follows that the client needs per-request control of
authorities it holds (if to assert them or to disclaim them).

-Ilari