Subject: Re: TLS renegotiation

From: Yoav Nir <[email-masked]>
Date: Mon, 3 Feb 2014 14:20:26 +0200

[re-awakening this thread]

On 29/1/14 7:41 PM, Martin Thomson wrote:
> On 29 January 2014 00:57, Yoav Nir <[email-masked]> wrote:
>> I know it’s not popular in content and social networking, but client
>> authentication does have its uses, and often cannot be done sanely (with
>> existing protocols) without renegotiation.
> I expected to hear something like this.
>
> Now.  The challenge for those people is to articulate what
> restrictions are acceptable.

I don't think I can speak for all of those people, but I can speak for 
some.  Client certificates on the web usually involve some user 
interaction. Even when not, they're rare. So I think we can live with 
needing another, non-coalesced connection for the certificate 
authentication. This would require some way for the server to know 
during the TLS handshake that this handshake requires a TLS handshake. 
Special ALPN string? An extension? An SCSV? Either way, the client would 
have to signal the server that it wants to present a client certificate. 
It would also require server-to-client signaling that client 
authentication is required at the HTTP (rather than TLS) layer.

> Preventing application protocol changes as a result of renegotiation
> seems reasonable; and we have an
> http://http2.github.io/http2-spec/#INADEQUATE_SECURITY now that can be
> used if any other property degrades as a result of renego.  And
> obviously, neither peer needs to accept an attempt at renegotiation.
> Is that enough?

I think so.
>
> About the connection coalescing feature that has been part of SPDY and
> will likely be made formal in HTTP/2 (see #359).  What behaviour do we
> expect from a client when a connection is renegotiated?
>
> The first cost that I'm aware of with respect to client certificates
> is that if a server that might be the target of coalescing it will be
> unable to have separate client authentication for the different
> domains that could be coalesced.

IMO when a client gets a signal from the server (could be similar to a 
WWW-Authenticate or really a WWW-Authenticate), it stops sending new 
requests on that connection. If coalesced, other application may 
continue to use it. The client then opens a new connection to the server 
with some indication that client authentication is available. This will 
also tell future TLS proxies that support HTTP/2 and client certificates 
to not unify that connection with others to the same server. Future 
interactions with that server would happen on this new non-coalesced 
connection.

Alternatively, we could move the user authentication even when it's done 
with certificates into HTTP. This has advantages and disadvantages, but 
it should be discussed. We can't make user authentication out of scope.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 3 Feb 2014 17:05:29 +0200

On Mon, Feb 03, 2014 at 02:20:26PM +0200, Yoav Nir wrote:

> during the TLS handshake that this handshake requires a TLS
> handshake. Special ALPN string? An extension? An SCSV? Either way,
> the client would have to signal the server that it wants to present
> a client certificate.

Special ALPN string:
I think technically works, dunno if needs a trip through TLS WG.

Extension:
I think technically works, definitely needs a trip through TLS WG.

SCSV:
A bad idea. SCSVs are for situations where extensions can't be relied
upon, which isn't a problem here due to fundamential requirement on
ALPN, which is in itself an extension. 

> IMO when a client gets a signal from the server (could be similar to
> a WWW-Authenticate or really a WWW-Authenticate), it stops sending
> new requests on that connection.

My earlier idea was to literally use WWW-Authenticate.

> Alternatively, we could move the user authentication even when it's
> done with certificates into HTTP. This has advantages and
> disadvantages, but it should be discussed. We can't make user
> authentication out of scope.

Here be dragons. This is quite nontrivial to do.

Well, basically it is just a signature plus a certificate blob, but
a signature over what?

Grabbing a string using TLS-EXTRACTOR and signing that is vulernable
to a MITM attack unless client or server enforces contributory
Diffie-Hellman (quite nasty to do with non-EC DH).

Adding apparent certificate of the server to signature would require
such attacker to have the server's private key.

TLS-UNIQUE (which isn't vulernable to above attack) is only 96 bits,
which seems bit small nowadays...

Sure, it would be quite a bit more flexible than doing it on TLS
layer...

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Feb 2014 09:23:08 -0800

On 3 February 2014 04:20, Yoav Nir <[email-masked]> wrote:
> I don't think I can speak for all of those people, but I can speak for some.
> Client certificates on the web usually involve some user interaction. Even
> when not, they're rare. So I think we can live with needing another,
> non-coalesced connection for the certificate authentication. This would
> require some way for the server to know during the TLS handshake that this
> handshake requires a TLS handshake. Special ALPN string? An extension? An
> SCSV? Either way, the client would have to signal the server that it wants
> to present a client certificate. It would also require server-to-client
> signaling that client authentication is required at the HTTP (rather than
> TLS) layer.

I wasn't going to leap to solutions so soon.  What about CONNECT?

It's not a lack of possibilities that is the problem here.  It's a
lack of clarity around what the desired behaviour is.  If, as you
suggest, this is a problem that can be detected for a given request,
how do we then extrapolate that to other interactions with the same
origin?  Why would we?  This is, of course, always the issue with
client certificates.

I'm still not 100% certain that we've already stated all the
assumptions here yet.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 4 Feb 2014 09:25:17 +0200

On 3/2/14 7:23 PM, Martin Thomson wrote:
> I wasn't going to leap to solutions so soon.

And you call yourself an engineer?  :-)
You did ask what restrictions would be acceptable.

> origin?  Why would we?  This is, of course, always the issue with

This is an issue with all forms of client or user authentication. Once 
I've entered my password for GMail (where I need to be authenticated so 
as to get my messages rather than yours), I seem to get personalized 
service from other Google services. At least my name appears everywhere. 
And there are those creepy content sites where the list of my Facebook 
friends who have read or liked this article appears on the right.

The issue here is not the form of user authentication. It's the form of 
session management that we use based on cookies. Once the user has 
authenticated, her browser gets a cookie, and all future requests are 
"blessed" as part of the same session.

I guess for websites with user authentication, regardless of whether 
that authentication happens at the TLS layer with client certificates, 
at the HTTP layer with Basic, Digest or MutualAuth, or at the 
application layer with forms, the process is something like this:

  * A user connects to the web site. For the moment I'll ignore
    connection coalescing and assume that website=origin.
  * Depending on the website, we either establish a non-authenticated
    session (by planting a cookie) or not. Either way, to get at the
    really interesting stuff, the user needs to log in.
  * So they can fill in a form, or click something that causes the
    authentication dialog box to pop up, or click something that causes
    the certificate picker to pop up.
  * Once they complete the authentication, they get to an authenticated
    session. That means that authorization for future requests in the
    same session are handled according to user permissions.

There are several issues with the current mechanism for session 
management: Other browser windows shared the same cookie, so you can't 
have two or more different sessions simultaneously with the same origin. 
Also the user cannot terminate a session unless the application provides 
this capability. But without going (again) into all of the reasons why 
we should have a serious look at how HTTP sessions are managed, there is 
nothing special about client certificates.

Yoav