Subject: Client Certificates - re-opening discussion

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Sep 2015 18:10:49 -0400

Hi,

We've talked about client certificates in HTTP/2 (and elsewhere) for a while, but the discussion has stalled.

I've heard from numerous places that this is causing Pain. So, I'd like to devote a chunk of our time in Yokohama to discussing this.

If you have a proposal or thoughts that might become a proposal in this area, please brush it off and be prepared. Of course, we can discuss on-list in the meantime.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Sep 2015 15:24:47 -0700

There is work ongoing in TLS 1.3 that I can report on with greater
certainty after the interim completes next week.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Sep 2015 16:56:53 +0100

> On 17 Sep 2015, at 23:10, Mark Nottingham <[email-masked]> wrote:
> 
> Hi,
> 

Apart from the proposals as the proposal by Martin Thomson 
and the follow up work  referenced earlier in this thread
by Mike Bishop [1], I'd like to mention more HTTP centric 
prototypes which would rely perhaps not so much on certificates, 
but on linked public keys, that build on existing HTTP 
mechanisms such as WWW-Authenticate, which if they pass security 
scrutiny would fit nicely it seems to me with HTTP/2.0 . 

• Andrei Sambra's first sketch authentication protocol           
  https://github.com/solid/solid-spec#webid-rsa

• Manu Sporny's more fully fleshed out HTTP Message signature     
  https://tools.ietf.org/html/draft-cavage-http-signatures-04

These and the more TLS centric protocols require the user 
agent to be able to use public/private keys generated by 
the agent, and signed  or published by that origin, to 
authenticate or sign documents across origins. 

This is where one often runs into the Same Origin Policy (SOP) 
stone wall. There was an important discussion on 
[email-masked] [1] and [email-masked] 
entitled 

  "A Somewhat Critical View of SOP (Same Origin Policy)" [2]

that I think has helped clarify the distinction between Same Origin 
Policy, Linkability, Privacy and User Control, and which I hope 
has helped show that this policy cannot be applied without 
care nor can it apply everywhere. 

The arguments developed there should be helpful in opening discussion
here and elswhere too I think. In a couple of e-mails  in that 
thread, I went into great detail showing how SOP, linkability and User
Control and privacy apply in very different ways to 4 technologies: 
Cookies, FIDO, JS Crypto API and client certificates [3]. This shows 
that the concepts don't overlap, two being technical and the two 
legal/philosophical, each technology enabling some aspect of the 
other, and not always the way one would expect. 

Having made those conceptual distinctions I think the path to
acceptance of solutions proposed by this group will be much eased.

Looking forward to following and testing work developed here,

All the best,

	Henry

[1] • starting: 
    https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0558.html
     • most recent by Mike Bishop  
   https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0310.html
[2] https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/
[3] https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0101.html
 which is in part summarised with respect to FIDO in a much shorter
 email
   https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0119.html

Social Web Architect
http://bblfish.net/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Sep 2015 13:05:14 -0400

Hi Henry,

Thanks, but this is a much more narrowly-scoped discussion -- how to make client certs as they currently operate work in HTTP/2. At most, I think we'd be talking about incrementally improving client certs (e.g., clarifying / optimising the scope of their applicability -- and that really just is an example, not a statement of intent).

Cheers,

> On 18 Sep 2015, at 11:53 am, Henry Story <[email-masked]> wrote:
> 
> 
> [1] • starting: https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0558.html

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Sep 2015 20:45:30 +0300

On Thu, Sep 17, 2015 at 06:10:49PM -0400, Mark Nottingham wrote:
> Hi,
> 
> We've talked about client certificates in HTTP/2 (and elsewhere)
> for a while, but the discussion has stalled.
> 
> If you have a proposal or thoughts that might become a proposal
> in this area, please brush it off and be prepared. Of course, we
> can discuss on-list in the meantime.

Basically, the ways I know one could do client certs in HTTP/2 have
both been floated before:

1) Signal about client cert being needed, client can establish
new connection for the authenticated stuff.

2) Do client cert at HTTP level, using the usual HTTP authentication
headers and TLS channel binding mechanisms[1] (but certificates
themselves require some special handling, due to size[2]).

[1] SPDY/3 did something like this, except with its own frame
types.

[2] Bit crazy idea: PUT with .well-known resource.

-Ilari

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Sep 2015 19:11:20 +0100

> On 18 Sep 2015, at 18:45, Ilari Liusvaara <[email-masked]> wrote:
> 

You mean: don't send the certificate, link to it on the web?
Then you are close to WebID-TLS 
  http://www.w3.org/2005/Incubator/webid/spec/
WebID-TLS only published the public key, but one could
also publish the full certificate. ( people had suggested
that before, but we were waiting for larger use cases to
consider it )

The advanage following that pattern is you put the certificate 
anywhere you like, not just in .well-known.

You can think of the WebID-profile document as a certificate 
linked on the web. Then we are close to the WebID-RSA and 
HTTP-signature proposals I mentioned earlier, but Mark pointed 
out that its out of scope in this thread. I could open another 
thread to discuss those when/if people are interested. 

Henry

Social Web Architect
http://bblfish.net/

---

From: Mike Belshe <[email-masked]>
Date: Fri, 18 Sep 2015 11:20:05 -0700

In a strange twist of fate I find myself doing a lot of PKI work these
days, and I've considered a fair bit about how client-certs might help with
some of my application-level needs.

However, just like HTTP's basic-auth, I wonder HTTP or TLS level
client-certs will just never be used?  My concern, of course, is that we
build something that has a user experience similar to HTTP's basic-auth.
It's so bad that nobody can use it and authentication gets pulled into web
pages (where ironically, it is less secure!).

Mark - you said there is "pain".  Is there a set of use cases to be solved
here?  Let me know if I missed them - I may be able to contribute.

My suspicion is that we really need crypto features moved up a level from
the protocol, as it will be very difficult to make satisfactory user
interfaces from the protocol level alone.  Perhaps for machine-to-machine
auth it would be okay.

Mike

On Fri, Sep 18, 2015 at 10:05 AM, Mark Nottingham <[email-masked]> wrote:

> Hi Henry,
>
> Thanks, but this is a much more narrowly-scoped discussion -- how to make
> client certs as they currently operate work in HTTP/2. At most, I think
> we'd be talking about incrementally improving client certs (e.g.,
> clarifying / optimising the scope of their applicability -- and that really
> just is an example, not a statement of intent).
>
> Cheers,
>
>
> > On 18 Sep 2015, at 11:53 am, Henry Story
> <[email-masked]> wrote:
> >
> >
> >> I've heard from numerous places that this is causing Pain. So, I'd like
> to devote a chunk of our time in Yokohama to discussing this.
> >>
> >> If you have a proposal or thoughts that might become a proposal in this
> area, please brush it off and be prepared. Of course, we can discuss
> on-list in the meantime.
> >>
> >> Cheers,
> >>
> >> --
> > [3]
> https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0101.html

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Sep 2015 14:27:07 -0400

> On 18 Sep 2015, at 2:20 pm, Mike Belshe <[email-masked]> wrote:
> 
> In a strange twist of fate I find myself doing a lot of PKI work these days, and I've considered a fair bit about how client-certs might help with some of my application-level needs.
> 
> However, just like HTTP's basic-auth, I wonder HTTP or TLS level client-certs will just never be used?  My concern, of course, is that we build something that has a user experience similar to HTTP's basic-auth.  It's so bad that nobody can use it and authentication gets pulled into web pages (where ironically, it is less secure!).
> 
> Mark - you said there is "pain".  Is there a set of use cases to be solved here?  Let me know if I missed them - I may be able to contribute.  

By "pain", I meant that sites that use client certs (which turns out to be more common than many thought) want to update to HTTP/2, but can't.

Cheers,

> 
> My suspicion is that we really need crypto features moved up a level from the protocol, as it will be very difficult to make satisfactory user interfaces from the protocol level alone.  Perhaps for machine-to-machine auth it would be okay.
> 
> Mike
> 
> 
> 
> 
>

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Sep 2015 18:31:39 +0000

We have historically had cases where customers were either legally mandated to use client certificate authentication specifically, or more generally had an IT requirement to use two-factor authentication to access enterprise resources.  I’ll research the details of some of these, and see whether I can share some details to frame this conversation in Yokohama.  Internally, we use it regularly – the certificate lives on a smartcard, the TPM, or was simply issued to the machine when it enrolled for device management.

For us, at least, the “pain” is that we can’t support a legal requirement without falling back to HTTP/1.1 and generating even more round-trips.  Our HTTP/2 investments don’t apply as soon as we’re talking to the auth server.

From: Mike Belshe [mailto:[email-masked]]
Sent: Friday, September 18, 2015 11:20 AM
To: Mark Nottingham <[email-masked]>
Cc: Henry Story <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Client Certificates - re-opening discussion

Mike

On Fri, Sep 18, 2015 at 10:05 AM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
Hi Henry,

Cheers,

> On 18 Sep 2015, at 11:53 am, Henry Story <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>> On 17 Sep 2015, at 23:10, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
> [email-masked]<mailto:[email-masked]> [1] and [email-masked]<mailto:[email-masked]>
> entitled
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Sep 2015 21:33:47 +0300

> that before, but we were waiting for larger use cases to

No, I meant sending the certificate chain. But if the equivalent to
the certificate chain is just a single raw public key, one could
stick it to headers (but I suppose for implementability reasons
one would not do that).

> anywhere you like, not just in .well-known.

Which causes all the security issues from retretiving URLs. And
also, most of the users probably won't have any place to stick
the cert to.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Sep 2015 13:48:50 -0700

On Fri, Sep 18, 2015 at 10:05 AM, Mark Nottingham <[email-masked]> wrote:

> client certs as they currently operate work in HTTP/2.

Is this a question about HTTP/2's limitations versus HTTP/1.1 or about
deficiencies
in HTTP/1.1 that HTTP/2 has not fixed?

-Ekr

At most, I think we'd be talking about incrementally improving client certs
> (e.g., clarifying / optimising the scope of their applicability -- and that
> really just is an example, not a statement of intent).
>
> Cheers,
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Sep 2015 23:57:34 +0300

> in HTTP/1.1 that HTTP/2 has not fixed?

I think this is about the extra limitations of HTTP/2 regarding client
authentication caused by major design differences between HTTP/1.1 and
HTTP/2.

Client certs in HTTP/1.1 aren't too great, but at least those don't
seem to even remotely have the same problems as client certs in HTTP/2
(especially when in web environment).

-Ilari

---

From: Stefan Eissing <[email-masked]>
Date: Sat, 19 Sep 2015 09:18:59 +0200

> Am 18.09.2015 um 22:57 schrieb Ilari Liusvaara <[email-masked]>:
> 

Just to have everyone on the same page. The problems - as we see them in httpd - are 

1. http/1.1 requests may trigger client certs which may require renegotiation. Processing is no longer  sequential with http/2, causing conflicts. Even if mutexed what does connection state and h2 stream have to say to each other and for how long? 

2. connection reuse for different hosts is much more likely as a lot of sites have a long list of subjectAltNames. That raises the likelihood of conflicts as described above. 

Any advice on how to address this in an interoperable way is appreciated. 

//Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Sep 2015 11:17:36 -0700

On Sat, Sep 19, 2015 at 12:18 AM, Stefan Eissing <
[email-masked]> wrote:

> 1. http/1.1 requests may trigger client certs which may require
> renegotiation. Processing is no longer  sequential with http/2, causing
> conflicts.

Well, presently renegotiation is illegal in HTTP/2, so this is a
non-problem.

However, I suppose if we land TLS 1.3 PR#209 it will come back.

-Ekr

> Even if mutexed what does connection state and h2 stream have to say to
> each other and for how long?
>
> 2. connection reuse for different hosts is much more likely as a lot of
> sites have a long list of subjectAltNames. That raises the likelihood of
> conflicts as described above.
>

---

From: Mike Bishop <[email-masked]>
Date: Sat, 19 Sep 2015 22:10:38 +0000

Kind of a non-problem, but it’s also the problem itself.  The HTTP layer will call different APIs in TLS, but the API HTTP exposes (get client certificate) won’t necessarily change.

·        HTTP/1.x + TLS <=1.2 – Client certs work via renegotiation

·        HTTP/x + TLS 1.3 – Client certs work via new TLS feature that isn’t renegotiation

·        HTTP/2 + TLS 1.2 – How do client certs work?

It’s a time-scoped problem, since we hope everyone will eventually be on TLS 1.3, but it’s a nearly-universal problem at the moment.  There are many proposed kludges for HTTP/2 over TLS 1.2 in the meantime, but we need to find something with broader support than any idea currently has.

From: Eric Rescorla [mailto:[email-masked]]
Sent: Saturday, September 19, 2015 11:18 AM
To: Stefan Eissing <[email-masked]>
Cc: Ilari Liusvaara <[email-masked]>; Mark Nottingham <[email-masked]>; Henry Story <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Client Certificates - re-opening discussion

On Sat, Sep 19, 2015 at 12:18 AM, Stefan Eissing <[email-masked]<mailto:[email-masked]>> wrote:

> Am 18.09.2015 um 22:57 schrieb Ilari Liusvaara <[email-masked]<mailto:[email-masked]>>:
>

1. http/1.1 requests may trigger client certs which may require renegotiation. Processing is no longer  sequential with http/2, causing conflicts.

Well, presently renegotiation is illegal in HTTP/2, so this is a non-problem.

-Ekr

Even if mutexed what does connection state and h2 stream have to say to each other and for how long?

//Stefan

---

From: Yoav Nir <[email-masked]>
Date: Mon, 21 Sep 2015 00:49:08 +0300

Hi, Mike

> On Sep 20, 2015, at 1:10 AM, Mike Bishop <[email-masked]> wrote:
> 

I’m not sure I see how PR #209 solves the issue.

HTTP/2 prohibited renegotiation because HTTP/2 is non-sequential. A bunch of requests may be in process and it is non-deterministic which responses will be generated before, during and after the client authentication. One resource might trigger the renegotiation, but several others might receive different responses based on whether or not the user is authenticated.

Now suppose we replace renegotiation with the mechanism proposed in PR #209. Some resource triggers the TLS layer, but instead of triggering a re-negotiation by sending a HelloRequest, it triggers client certificate authentication by sending a CertificateRequest. This is different in some senses: there is no change to the master secret; the old channel bindings are still valid; session keys are not replaced. I don’t see what difference this makes. The connection still changes from a state where the client is anonymous to a state where the client is authenticated. Requests sent by the client still may have been responded to before, during or after the change of state. 

Maybe I’m missing something, but I don’t see what #209 does that renegotiation did not.

Yoav

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 Sep 2015 03:30:50 +0000

Better than renegotiation?  Nothing – which is the point.  Renegotiation worked, and our first step is parity with downlevel.  Renegotiation, however, attempted to bring many functions together, some of which made the TLS WG uncomfortable.  This PR creates a more scoped feature targeted at only the presentation of client credentials to the server, which is the feature we actually need.

It sounds like, in part, we have different understandings of why renegotiation was prohibited in the first place.  You argue it was prohibited because there’s some inherent indeterminacy, particularly if the application layer doesn’t stall.  I’d argue that that indeterminacy can and should be handled by the application that knows what resources care about the client’s identity and which don’t.

If multiple requests cause the server application to query the HTTP layer for the client’s certificate, then all those requests will wait until the client authentication has completed, just as they would have on a non-multiplexed connection.  Where multiplexing adds a new wrinkle is that, under HTTP/1.1, those connections that didn’t require authentication would proceed without interruption until they’re used for a protected request.

Perhaps the fundamental question is, when does the client need to know that the server had seen the certificate prior to generating the response?  In HTTP/1.1 over TLS 1.x, it could know that the server had seen it, but couldn’t know whether the server cared.

From: Yoav Nir [mailto:[email-masked]]
Sent: Sunday, September 20, 2015 2:49 PM
To: Mike Bishop <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; Stefan Eissing <[email-masked]>; Ilari Liusvaara <[email-masked]>; Mark Nottingham <[email-masked]>; Henry Story <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Client Certificates - re-opening discussion

Hi, Mike

On Sep 20, 2015, at 1:10 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 21 Sep 2015 09:09:18 +0300

> On Sep 21, 2015, at 6:30 AM, Mike Bishop <[email-masked]> wrote:
> 
> Better than renegotiation?  Nothing – which is the point.  Renegotiation worked, and our first step is parity with downlevel.

So if this working group rejected renegotiation (which worked), why would this new mechanism be acceptable?

> Renegotiation, however, attempted to bring many functions together, some of which made the TLS WG uncomfortable.  This PR creates a more scoped feature targeted at only the presentation of client credentials to the server, which is the feature we actually need.

That’s a good thing, but IMO it doesn’t matter to httpbis.

> It sounds like, in part, we have different understandings of why renegotiation was prohibited in the first place.  You argue it was prohibited because there’s some inherent indeterminacy, particula…

Having the application layer stall doesn’t help. The client requests resources A, B, and C. Resource B requires client authentication. By the time the application stalls, waiting for the client authentication, resources A and C may not have been noticed, or the requests may have been serviced, with A and C in a buffer waiting to be encrypted, or the requests may have been serviced and encrypted and on the way back to the client. A and C may be received in the authenticated or the non-authenticated context. Imagine, for example, that A is a bit of HTML that says “Hello, guest” in the unauthenticated context, or “Hello, Mike” after authentication. You can get the certificate picker and still see the “Hello, guest” on the page.

What’s more, I think HTTP authentication has the same issue. If one request gets processed and generates a 401 with WWW-Authenticate, other resources may or may not have been serviced. You can fix this by carefully designing the application so that you don’t load resources that are different based on state at the same time as the authentication is going on.

> Perhaps the fundamental question is, when does the client need to know that the server had seen the certificate prior to generating the response?  In HTTP/1.1 over TLS 1.x, it could know that the s…

Does it matter for the client?

Yoav

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 21 Sep 2015 09:12:21 +0100

First I am really thankful for this discussion as  I had not been able
to understand what exactly the problem with client certs and 
HTTP/2.0 were. This is very helpful.

> On 21 Sep 2015, at 07:09, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>> On Sep 21, 2015, at 6:30 AM, Mike Bishop <[email-masked] <mailto:[email-masked]>> wrote:
>> 

This seems to show that this is not a client certificate problem but another problem.

In a data driven web, where the client generates the page in Single Pages apps (SPA), the 
identifying  information about the user would be in a seperate resource. As that information 
became available to the SPA would redraw itself, to take that into account.

The way you state the problem it seems to be related to a resource being both public
and protected simultaneously, with the protected version of the resource returning more 
information than the public one. How would a web server indicate to the client that
it should re-download certain resources that now contain more information? Is this even
good practice?  Those are interesting questions.

>> If multiple requests cause the server application to query the HTTP layer for the client’s certificate, then all those requests will wait until the client authentication has completed, just as the…

makes sense to me.

Social Web Architect
http://bblfish.net/

---

From: Kyle Rose <[email-masked]>
Date: Mon, 21 Sep 2015 08:22:48 -0400

> Having the application layer stall doesn’t help. The client requests
> resources A, B, and C. Resource B requires client authentication. By the
> time the application stalls, waiting for the client authentication,
> resources A and C may not have been noticed, or the requests may have been
> serviced, with A and C in a buffer waiting to be encrypted, or the requests
> may have been serviced and encrypted and on the way back to the client. A
> and C may be received in the authenticated or the non-authenticated context.
> Imagine, for example, that A is a bit of HTML that says “Hello, guest” in
> the unauthenticated context, or “Hello, Mike” after authentication. You can
> get the certificate picker and still see the “Hello, guest” on the page.
>
> What’s more, I think HTTP authentication has the same issue. If one request
> gets processed and generates a 401 with WWW-Authenticate, other resources
> may or may not have been serviced. You can fix this by carefully designing
> the application so that you don’t load resources that are different based on
> state at the same time as the authentication is going on.
>
> If multiple requests cause the server application to query the HTTP layer
> for the client’s certificate, then all those requests will wait until the
> client authentication has completed, just as they would have on a
> non-multiplexed connection.  Where multiplexing adds a new wrinkle is that,
> under HTTP/1.1, those connections that didn’t require authentication would
> proceed without interruption until they’re used for a protected request.

How did this work in practice with HTTP/1.1, with browsers having
multiple simultaneous connections open to the same server?

If I had to guess, I'd say that the primary resource requiring
authentication was typically the root HTML for a page, which would
then of course stall every subsequent request for subresources without
any specific support required in the client: neither multiplexing H2
nor simultaneous HTTP/1.1 connections would be subject to a race
condition in this case, requests for the URLs from previously-loaded
pages that vary on authentication notwithstanding. Otherwise, I'm
guessing the user would have a sub-par UX (e.g., multiple certificate
chooser dialogs).

Kyle

---

From: Yoav Nir <[email-masked]>
Date: Mon, 21 Sep 2015 16:04:28 +0300

> On Sep 21, 2015, at 3:22 PM, Kyle Rose <[email-masked]> wrote:
> 
> pages that vary on authentication notwithstanding.

Of course that’s how sane people built the web sites. If fact only the root HTML of some page (that you reached by clicking a button that said “Log in with a Certificate”) triggered renegotiation. After renegotiation on one particular connection, the server would plant a COOKIE, which would “bless” all the other connections.

The difference is that now the sane design is mandatory, else you get unpredictable results. A sane design works with renegotiation, #209 and HTTP-layer authentication.

Yoav

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 21 Sep 2015 15:19:27 +0200

> Am 21.09.2015 um 15:04 schrieb Yoav Nir <[email-masked]>:
> 
>> 
>> [...]
> The difference is that now the sane design is mandatory, else you get unpredictable results. A sane design works with renegotiation, #209 and HTTP-layer authentication

Not even then. Client may reuse connections on matching certs. There are installations out there that have a cert for +3 domain names, lets say A, B and C. A has anonymous access, B and C both require different client certs. Depending on which tab the browser load first, the one or the other cert gets loaded in, leading the other site to fail since the cert is not accepted.

The only approach available seems, inside the server, to check when renegotiation is triggered by a request: is the authority the same as in the SNI for this connection? If not, return a 421.

But that overloads 421, which is not trivial to implement correctly and efficient in the client. Maybe client developers can add some wisdom to this discussion.

As to the approach: "there is no problem, since renegotiation is forbidden in http/2!" Well. I can tell people to disable h2 if they have client certificates, sure. But I would prefer enabling http/2 and give clients a return code when they need a new connection, maybe even indicating the base URL *path* for that connection.

//Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Kyle Rose <[email-masked]>
Date: Mon, 21 Sep 2015 10:28:13 -0400

> Not even then. Client may reuse connections on matching certs. There are installations out there that have a cert for +3 domain names, lets say A, B and C. A has anonymous access, B and C both requ…

Yeah, this is a huge issue that doesn't appear in HTTP/1.1. It sounds
to me like the real problem is trying to shoehorn application-layer
client authentication into the transport layer.

Kyle

---

From: Mike Belshe <[email-masked]>
Date: Mon, 21 Sep 2015 08:22:49 -0700

On Fri, Sep 18, 2015 at 11:31 AM, Mike Bishop <[email-masked]>
wrote:

> We have historically had cases where customers were either legally
> mandated to use client certificate authentication specifically, or more
> generally had an IT requirement to use two-factor authentication to access
> enterprise resources.  I’ll research the details of some of these, and see
> whether I can share some details to frame this conversation in Yokohama.
> Internally, we use it regularly – the certificate lives on a smartcard, the
> TPM, or was simply issued to the machine when it enrolled for device
> management.
>
>
>
> For us, at least, the “pain” is that we can’t support a legal requirement
> without falling back to HTTP/1.1 and generating even more round-trips.  Our
> HTTP/2 investments don’t apply as soon as we’re talking to the auth server.
>

Thanks, this sounds about right.  The usability of browser-based
client-auth was so awful, that unless "mandated" by some law, no real user
or website would use it :-)  If anyone on this thread hasn't tried client
auth, you should, and then imagine turning that on for any real website.

I hope the legal requirement doesn't require that client auth be done in
the HTTP protocol layer, just that the certificate based auth be done.  My
own opinion is that HTTP/1.1/TLS's client auth was a mistake, and my
evidence is the usability of both client-auth and basic-auth authentication
schemes at the protocol layer.  Neither is used in significant amounts.
The latter was definitely moved by millions of websites into the
application layer, and I see no reason why browsers shouldn't offer support
for client-auth like primitives which will help customers move
certificate-based client auth up a level too.

Given the flexibility of HTTP2s framing layer, it will be tricky to avoid
major security bugs in HTTP2 if we try to enable client-auth at the session
below the framing.

Mike

>
>
> *From:* Mike Belshe [mailto:[email-masked]]
> *Sent:* Friday, September 18, 2015 11:20 AM
> *To:* Mark Nottingham <[email-masked]>
> *Cc:* Henry Story <[email-masked]>; HTTP Working Group <
> [email-masked]>
> *Subject:* Re: Client Certificates - re-opening discussion
>
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 21 Sep 2015 16:43:49 +0100

> On 21 Sep 2015, at 15:28, Kyle Rose <[email-masked]> wrote:
> 

How is this different from say if one authenticated to each resource
using public keys at the HTTP layer [1]. We could imagine here A, B and C,
being resources on the same server even with A only accessible by somone 
who can prove he is over 18, the other by someone how is a member of this 
working group, ( provable using either a WebID or an OpenID ), etc.... 

There are two signals the server can set up to help the user agent select
a certificate: A 401 not Authorized, and perhaps a link to an access
control resource that would describe who can have access [2].  The client
needs some logic to help select a certificates or credential to respond 
to the request while putting the user in control, and without being too
much of a pain.

As I understand Martin Thomson  suggested an HTTP header

WWW-Authenticate: Certificate

sent at the HTTP layer, that could then start the certificate 
connection at the TLS layer.  The client could also try to narrow 
down from the ACL list to see if it is even worth bothering the 
user to ask him for a Certificate, and perhaps warn him that some 
links cannot be  followed, because of the lack of access.

It is true that authentication at the TLS layer is much rougher, as 
I think the client can only authenticate with 1 certificate not more,
per connection.

But part of the problem you mention has more to do with the logic of
the user agents credential selection and the problems of protected
resources across origins ( which everybody is familiar when looking
at YouTube links that are viewable in one country but not in another ).

Henry

[1] As suggested by one of the following 

[2] Following work described here for example
  http://www.w3.org/wiki/WebAccessControl

Social Web Architect
http://bblfish.net/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Sep 2015 17:25:50 +0100

On 17/09/15 23:10, Mark Nottingham wrote:
> I've heard from numerous places that this is causing Pain. So, I'd
> like to devote a chunk of our time in Yokohama to discussing this.
> 
> If you have a proposal or thoughts that might become a proposal in
> this area, please brush it off and be prepared. Of course, we can
> discuss on-list in the meantime.

As an occasional developer, I'm not fussed about how HTTPS with client
certificate based authentication works, but I have made use of this
in various server-server use-cases. It's really handy to be able to
e.g. setup a new virtual host and to be able use or test that via
curl. I suspect I'm not alone in having done that and don't recall
seeing it mentioned in this thread. (Apologies if I'm repeating stuff.)

While I could probably do all I need to without HTTP, it's easier
and I get more code/tool re-use to use client certificates. (Note,
for all cases I care about myself I can roll a new CA and certify
all the parties so I have no dependency on a 3rd party PKI like the
WebPKI.)

And while continuing to use HTTP/1.1 would be just fine for me, I'd
prefer to use standard configurations for tools, which means at some
point wanting this feature for HTTP/2 as well.

Cheers,
S.

PS: In case it's not clear, the above is wearing no IETF-hat:-)

> 
> Cheers,
> 
> -- Mark Nottingham   https://www.mnot.net/
> 
> 
> 
> 
> 
>

---

From: Kyle Rose <[email-masked]>
Date: Mon, 21 Sep 2015 12:58:53 -0400

> I think the client can only authenticate with 1 certificate not more,

Right, and the inability to support this leads to a bunch of
kludgey-feeling solutions, like 421s. This situation was always
possible with HTTP/1.1, but is a lot more likely with H2.

Pushing the authentication into the application layer seems like it
could be cleaner. Provide browser support for setting a
CertificateVerify header (e.g., based on a signature of the channel
binding), something that can be cached by the client and server and
reused on all relevant streams over the same connection. Signalling
for "you need to authenticate" and sending the client certificate to
the server would then be entirely at the application layer, possibly
with the support of HTTP status codes, and TLS client certificate
authentication wouldn't be used in this case.

This sort of application layer approach may also make a better client
UX more natural, by moving the logic for prompting the user for a
certificate into the web app UI.

Kyle

---

From: Jason Greene <[email-masked]>
Date: Mon, 21 Sep 2015 12:51:30 -0500

> On Sep 21, 2015, at 10:22 AM, Mike Belshe <[email-masked]> wrote:
> 
> 
> 
> On Fri, Sep 18, 2015 at 11:31 AM, Mike Bishop <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks, this sounds about right.  The usability of browser-based client-auth was so awful, that unless "mandated" by some law, no real user or website would use it :-)  If anyone on this thread hasn't tried client auth, you should, and then imagine turning that on for any real website.

Hmm I always thought it was fairly straight-forward. Although the thing is, the major use-case for client certs is provisioned authorized equipment. So the end-user of the browser typically doesn’t interact with it at all.

> 
> I hope the legal requirement doesn't require that client auth be done in the HTTP protocol layer, just that the certificate based auth be done.  My own opinion is that HTTP/1.1/TLS's client auth was a mistake, and my evidence is the usability of both client-auth and basic-auth authentication schemes at the protocol layer.  Neither is used in significant amounts.  The latter was definitely moved by millions of websites into the application layer, and I see no reason why browsers shouldn't offer support for client-auth like primitives which will help customers move certificate-based client auth up a level too.

How does this help the usability of the browser? It seems to me that however you do it, the overall management of client certificates in the browser is roughly the same. You have to have a mapping of site to cert stored somewhere.

-Jason

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 21 Sep 2015 19:06:11 +0100

> On 21 Sep 2015, at 17:58, Kyle Rose <[email-masked]> wrote:
> 

So there is another question: are the two incompatible? 

It may also be worth having the old solution for a transition period,
until new answers come up. Then as they prove themselves, which should
be easy as they will be a lot more flexible ( but also therefore in
danger of more misimplementations ), the older TLS certificate
system can go away.

> reused on all relevant streams over the same connection.

The idea would be for example that a 401 with a 

 WWW-Authenticate: Certificate, upload="/certs" 

The client could then POST the (x509?) certificate to that location,
and receive a Location: header containing a URL that it could re-use
on future connections, and which it could use for authentication 
with something like draft-cavage-http-signatures [1]

The nice thing, is that this would allow one to also use URLs
of certificates  on remote servers, to avoid the whole process of 
certificate uploads. ( but the problem of people not having a
server would be solved by the POST described above )

Also this provides an easy way to disable certificates by removing
them from that URL.

You could then further do content negotiation on that URL and allow
many different formats to be returned, enabling a 
move to JSON certificate formats a la JOSE or based on
JSON-LD.

> Signalling

Would that require the client to also be able to independently get
access to the channel binding? 

Wether the WebAPP UI can do this will depend on wether the WebApp
can intercept the 401's sent by the server. This is the type of thing
that could be done by ServiceWorkers [2] I am told, but figuring that
out from the spec is not really easy. I am going to send a message
to the WebApps group to verify that this is possible across origins.

Still even if WebApps were able to do this authentication across
origins, it would still be very useful for the browsers themselves
to be able to authenticate to a remote origin without going through
these WebApps, so that one could test out resources outside of an 
App. Ie. I think there will always be a need for browsers to provide
cross origin authentication mechanisms. WebApps will be more flexible
to innovate, but the successful ones should be rolled into the browser.

Henry

[1] https://tools.ietf.org/html/draft-cavage-http-signatures-04

[2] Which just started gone into Candidate Recommendation and feedback is 
saught
https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/

Social Web Architect
http://bblfish.net/

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 Sep 2015 18:23:40 +0000

I have no issue with defining something at the application layer that becomes a viable alternative to move toward.  In the meantime, though, we want a way for applications built on the old/current model to use HTTP/2.

For your forward-facing model, there will need to be something more than just posting the cert -- there has to be a proof that the private key is owned.  But the general model of doing it at the app level is a direction to explore.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 21, 2015 11:06 AM
To: HTTP Working Group <[email-masked]>
Subject: Re: Client Certificates - re-opening discussion

>> It is true that authentication at the TLS layer is much rougher, as I 
>> think the client can only authenticate with 1 certificate not more, 
>> per connection.
> 

It may also be worth having the old solution for a transition period, until new answers come up. Then as they prove themselves, which should be easy as they will be a lot more flexible ( but also therefore in danger of more misimplementations ), the older TLS certificate system can go away.

The client could then POST the (x509?) certificate to that location, and receive a Location: header containing a URL that it could re-use on future connections, and which it could use for authentication with something like draft-cavage-http-signatures [1]

The nice thing, is that this would allow one to also use URLs of certificates  on remote servers, to avoid the whole process of certificate uploads. ( but the problem of people not having a server would be solved by the POST described above )

Also this provides an easy way to disable certificates by removing them from that URL.

You could then further do content negotiation on that URL and allow many different formats to be returned, enabling a move to JSON certificate formats a la JOSE or based on JSON-LD.

> certificate into the web app UI.

Would that require the client to also be able to independently get access to the channel binding? 

Wether the WebAPP UI can do this will depend on wether the WebApp can intercept the 401's sent by the server. This is the type of thing that could be done by ServiceWorkers [2] I am told, but figuring that out from the spec is not really easy. I am going to send a message to the WebApps group to verify that this is possible across origins.

Still even if WebApps were able to do this authentication across origins, it would still be very useful for the browsers themselves to be able to authenticate to a remote origin without going through these WebApps, so that one could test out resources outside of an App. Ie. I think there will always be a need for browsers to provide cross origin authentication mechanisms. WebApps will be more flexible to innovate, but the successful ones should be rolled into the browser.

Henry

Social Web Architect
http://bblfish.net/

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 22 Sep 2015 11:08:31 +0200

> Am 21.09.2015 um 20:23 schrieb Mike Bishop <[email-masked]>:
> 

Thanks, Mike. My feelings exactly.

We want sites to enable HTTP/2. We do not want them to crash and go down in flames, because the existing HTTP/1 config was not suitable. We'd like predictable (or at least defined) behaviour of clients when running into whatever the server sends back in such scenarios.

In order to completely avoid renegotiations on HTTP/2 (and I think we all agree on that), one approach would be to force the client back to HTTP/1.1 using another (new or open) connection. The response should indicate the realm where this restriction applies.

Note that servers may be unable to trigger client certs on connection setup. This often happens on the first request, triggering a renegotiation. Often specific TLS parameters only apply to special locations on a server (in existing configurations - I do not say that this is a good approach).

This may be done by extending the 421 response with additional headers to indicate the desired behaviour. It would be good to hear from people on the client side what their thoughts about this are.

//Stefan

<green/>bytes GmbH

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 22 Sep 2015 11:24:37 +0100

> On 22 Sep 2015, at 10:08, Stefan Eissing <[email-masked]> wrote:
> 
> 

Ok, this does make the use case much clearer: how does one allow a company with an HTTP/1.1 enabled web site using client certificates to switch to HTTP/2.0 without the site acting very differently ( e.g. with parts of the page showing the user as not logged it whilst still showing in other parts information only that user can see ).

The problem is that there also is another use case: a web site that wishes to use all the advantages of HTTP/2.0 (SPDY) to build sites that use it for what it was designed for: namely highly data driven Single Page Application that requires a lot of connections, and that takes into account the asynchronous nature of HTTP/2.0 by redrawing the web page as data becomes available to create a coherent view.

So one would ideally like a TLS+Certificate answer that can satisfy both use cases. 

Is that a correct summary?

Henry

Social Web Architect
http://bblfish.net/

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 22 Sep 2015 13:58:40 -0600

On 09/22/2015 04:24 AM, [email-masked] wrote:

> Ok, this does make the use case much clearer: how does one allow a
> company with an HTTP/1.1 enabled web site using client certificates
> to switch to HTTP/2.0 without the site acting very differently.

Please replace "site" with "server". Existing HTTP proxies, including
some large CDN-like proxy hierarchies, use client certificates for
client-proxy and proxy-proxy authentication.

Alex.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Sep 2015 10:09:51 +1000

Stefan,

> On 22 Sep 2015, at 7:08 pm, Stefan Eissing <[email-masked]> wrote:
> 
> 

See:
  http://httpwg.github.io/specs/rfc7540.html#rfc.section.9.2.1
  http://httpwg.github.io/specs/rfc7540.html#HTTP_1_1_REQUIRED

"""
This effectively prevents the use of renegotiation in response to a request for a specific protected resource. A future specification might provide a way to support this use case. Alternatively, a server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to request the client use a protocol that supports renegotiation.
"""

Cheers,

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 23 Sep 2015 10:50:35 +0200

Mark, thanks for pointing this out to me. 

On the one hand, sending a RST_STREAM with HTTP_1_1_REQUIRED seems at the right layer. On the other hand, the client gets no information where this restriction might apply. Or is it intended to be used in a GOAWAY and the client should only use HTTP/1 for this server? The description "Use HTTP/1.1 for the request" seems to pint to RST_STREAM.

One could advise a client that HTTP_1_1_REQUIRED indicates that the request uri ref indicates the server realm where this restriction applies. For Apache httpd at least, client cert renegotiation is a directory based configuration.

Further, a client thus falling back to HTTP/1.1 to trigger the proper TLS params, *could* try to "Upgrade:" to h2 again on the same request, given that all security requirements are fulfilled. This is outside the spec atm, right?

(I had already one site with "421 Ping Pong" reported, where the client got a 421, teared down the connection, opened a new one, got a 421 on a later request, teared down again, opened exactly as in the beginning a new one... all this does not match exactly this case, but it shows that there are interop issues lurking.)

Cheers,

  Stefan

> Am 23.09.2015 um 02:09 schrieb Mark Nottingham <[email-masked]>:
> 
> Stefan,
> 

<green/>bytes GmbH

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Sep 2015 08:25:58 -0700

On Sep 23, 2015 1:55 AM, "Stefan Eissing" <[email-masked]>
wrote:
> One could advise a client that HTTP_1_1_REQUIRED indicates that the
request uri ref indicates the server realm where this restriction applies.
For Apache httpd at least, client cert renegotiation is a directory based
configuration.

The notion that you might infer something about other resources based on
some unspecified dissection of a URL and a response seems to fragile to be
wise. That suggests something explicit, which leads back to 421.

> Further, a client thus falling back to HTTP/1.1 to trigger the proper TLS
params, *could* try to "Upgrade:" to h2 again on the same request, given
that all security requirements are fulfilled. This is outside the spec atm,
right?

Yeah, TLS implies ALPN.

> (I had already one site with "421 Ping Pong" reported, where the client
got a 421, teared down the connection, opened a new one, got a 421 on a
later request, teared down again, opened exactly as in the beginning a new
one... all this does not match exactly this case, but it shows that there
are interop issues lurking.)

Redirect loops happen too, so I imagine that this can be handled in a
catchall.

The ideal solution is to find ways to address all use cases in HTTP/2. For
that, I agree that client authentication in response to a request will be
needed.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Sep 2015 15:58:56 +0000

I agree, it would have been nice to specify some level of scope on the HTTP_1_1_REQUIRED – but then again, the server code may not even know the scope of resources that trigger it, and fallback to HTTP/1.1 is always permissible.  If we receive H1R for one or more resources, we open a 1.1 connection and retry it/them.  If they succeed on 1.1, we’ll switch entirely to 1.1 for the remainder of that session.  (With some additional implementation-specific stuff around the client-cert case and not wanting to stall renegotiation waiting for UI.)

From: Martin Thomson [mailto:[email-masked]]
Sent: Wednesday, September 23, 2015 8:26 AM
To: Stefan Eissing <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Client Certificates - re-opening discussion

> One could advise a client that HTTP_1_1_REQUIRED indicates that the request uri ref indicates the server realm where this restriction applies. For Apache httpd at least, client cert renegotiation i…

The notion that you might infer something about other resources based on some unspecified dissection of a URL and a response seems to fragile to be wise. That suggests something explicit, which leads back to 421.

Yeah, TLS implies ALPN.

> (I had already one site with "421 Ping Pong" reported, where the client got a 421, teared down the connection, opened a new one, got a 421 on a later request, teared down again, opened exactly as i…

Redirect loops happen too, so I imagine that this can be handled in a catchall.

The ideal solution is to find ways to address all use cases in HTTP/2. For that, I agree that client authentication in response to a request will be needed.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Sep 2015 23:35:28 +0300

I agree that it makes the most sense from the client’s perspective to close the HTTP/2 connection and move entirely to HTTP/1 once the H1R response is received.

It’s kind of sad, because most applications that I’ve seen have just one resource that triggers the renegotiation (ours is called “login_with_certs.html”), and everything else is authorized by the cookie that is set by the response to that request. The HTTP/2 connection could be safely used for everything else on the site.

But there is no way for the browser to know that. And trying each resource with the HTTP/2 connection and optionally moving it to the HTTP/1 connection sounds like a really poor idea.

Yoav

> On Sep 23, 2015, at 6:58 PM, Mike Bishop <[email-masked]> wrote:
> 
> On Sep 23, 2015 1:55 AM, "Stefan Eissing" <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 23 Sep 2015 15:08:26 -0700

On Wed, Sep 23, 2015 at 1:35 PM, Yoav Nir <[email-masked]> wrote:

> I agree that it makes the most sense from the client’s perspective to
> close the HTTP/2 connection and move entirely to HTTP/1 once the H1R
> response is received.
>

​This is exactly what Chrome does, FWIW.​