Subject: TLS renegotiation

From: Martin Thomson <[email-masked]>
Date: Sat, 25 Jan 2014 08:28:47 +0100

Brian raises a fairly important set of points around negotiation:

https://github.com/http2/http2-spec/issues/363

I think that I can distill this down to two major concerns:

1. renegotiation causes problems with mapping server authentication to
requests; false start means that this is true even with renegotiation
immediately after connecting

2. client certificates are tricky because they often rely on
renegotiation and they can interact with any coalescing feature we
define

Discuss.

---

From: Mike Belshe <[email-masked]>
Date: Sat, 25 Jan 2014 05:01:23 -0800

As the bug points out, TLS renegotiation has trouble in HTTP/1.x.  Its just
not well thought through and is inherently racey, regardless of the
protocol which is running atop it. Unfortunately, I don't think there is
any good answer.  If the client starts chattering and doesn't give the
server a chance to reneg, its just going to break.  I suppose you could try
to force some client-side flow control blocker so that it can issue a
renegotiate, but when the renegotiate is done, you'll probably have to drop
all the in-flight streams.

On the good news side, almost nobody uses client auth or renegotiation.
 This is in part due to the fact that it just doesn't work well with any
protocol, HTTP/1 or otherwise.

Mike

---

From: Brian Smith <[email-masked]>
Date: Tue, 28 Jan 2014 13:37:25 -0800

> protocol, HTTP/1 or otherwise.

With that in mind, here's a strawman:

1. When "h2" has been negotiated (through ALPN/NPN/whatever), then TLS
renegotiation MUST NOT be done on the connection.

This would mean that if HTTP/2 is negotiated during the initial
handshake then TLS renegotiation will never happen on the connection,
and if HTTP/2 is negotiated during a renegotiation then no more
renegotiation handshakes will be done.

2. If the server negotiates the protocol "h2r" then the client MUST
immediately initiate a renegotiation, offering only the "h2" protocol,
the client must wait for the renegotiation once it receives the
hello_request, and the client MUST NOT send any application data or do
any coalescing until the renegotiation handshake has completed.

3. Clients that offer the "h2" protocol during the initial handshake
and that support TLS renegotiation for HTTP/1 connections SHOULD offer
the "h2r" protocol during the initial handshake. Clients that do not
support renegotiation MUST NOT offer the "h2r" protocol.

The effect would be that there may only be one renegotiation on a
HTTP/2 connection and that renegotiation must happen at the very
beginning of the handshake, before any coalescing has been done and
before any data has been sent.

Note that "h2r" would implicitly disable False Start.

The main advantage of this proposal is that it provides a way for
servers that require client certificate authentication to work with
HTTP/2, increasing backward compatibility. The secondary advantage of
this proposal is that it prevents the issues that clients currently
have of mapping requests/responses to client and/or server
certificates. The primary disadvantage of this proposal is that it
requires the application to be more aware of renegotiations than it
previously was.

Unlike the "http-tls-relaxed" option negotiation that I objected to
before, the "h2r" option for negotiating renegotiation doesn't
disclose any security-sensitive information, unless knowing that the
client supports renegotiation or not is security-sensitive. AFAICT, it
is an additional fingerprinting risk but it isn't otherwise
security-sensitive assuming a correct and secure implementation of
renegotiation by both parties (a big assumption).

Cheers,
Brian

---

From: "Ludin, Stephen" <[email-masked]>
Date: Tue, 28 Jan 2014 20:47:46 -0600

FWIW, "almost nobody” is not nobody.  We at Akamai have a significant customer base that use client certificates, has used them for years, and fully intends to continue to use them.  I would expect to find something similar in the enterprise use case as well.  For the most part, what I have noticed is organizations that have their clients or employees using client side certificates have strict control or requirements around browser used which simplifies the compatibility question.  This is evidence that the functionality is important enough for them to take such steps.

My point is simply that we cannot dismiss the use case without careful consideration of the existing functionality as well as alternatives.  It would be a shame to isolate another user base from HTTP/2 because of design decisions that, though I am sympathetic towards, eliminate something that an existing user base relies upon for daily operations.

-stephen

From: Mike Belshe <[email-masked]<mailto:[email-masked]>>
Date: Saturday, January 25, 2014 at 5:01 AM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: TLS renegotiation
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Saturday, January 25, 2014 at 5:02 AM

As the bug points out, TLS renegotiation has trouble in HTTP/1.x.  Its just not well thought through and is inherently racey, regardless of the protocol which is running atop it. Unfortunately, I don't think there is any good answer.  If the client starts chattering and doesn't give the server a chance to reneg, its just going to break.  I suppose you could try to force some client-side flow control blocker so that it can issue a renegotiate, but when the renegotiate is done, you'll probably have to drop all the in-flight streams.

On the good news side, almost nobody uses client auth or renegotiation.  This is in part due to the fact that it just doesn't work well with any protocol, HTTP/1 or otherwise.

Mike

On Fri, Jan 24, 2014 at 11:28 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Brian raises a fairly important set of points around negotiation:

Discuss.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 29 Jan 2014 10:57:24 +0200

+1

A good portion of our SSL-VPN customers use certificates. There are also a
bunch of government web sites in various countries, and some banks.

It is very common for connecting BYOD mobile phones to the enterprise
network for emails, intranet and such.

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.

My suggestion would be to allow renegotiation, but disallow ALPN/NPN in a
renegotiated TLS. If the applications can negotiate moving to another
application, they can switch without a handshake. If they can't do it
without TLS, they won't be able to do it with TLS - there are no "markers"
in the application stream as to when a renegotiation occurred. 

Yoav

From: Ludin, Stephen [mailto:[email-masked]] 
Sent: Wednesday, January 29, 2014 4:48 AM
To: Mike Belshe; Martin Thomson
Cc: HTTP Working Group
Subject: Re: TLS renegotiation

FWIW, "almost nobody" is not nobody.  We at Akamai have a significant
customer base that use client certificates, has used them for years, and
fully intends to continue to use them.  I would expect to find something
similar in the enterprise use case as well.  For the most part, what I have
noticed is organizations that have their clients or employees using client
side certificates have strict control or requirements around browser used
which simplifies the compatibility question.  This is evidence that the
functionality is important enough for them to take such steps.

My point is simply that we cannot dismiss the use case without careful
consideration of the existing functionality as well as alternatives.  It
would be a shame to isolate another user base from HTTP/2 because of design
decisions that, though I am sympathetic towards, eliminate something that an
existing user base relies upon for daily operations.

-stephen

From: Mike Belshe <[email-masked]>
Date: Saturday, January 25, 2014 at 5:01 AM
To: Martin Thomson <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: TLS renegotiation
Resent-From: <[email-masked]>
Resent-Date: Saturday, January 25, 2014 at 5:02 AM

As the bug points out, TLS renegotiation has trouble in HTTP/1.x.  Its just
not well thought through and is inherently racey, regardless of the protocol
which is running atop it. Unfortunately, I don't think there is any good
answer.  If the client starts chattering and doesn't give the server a
chance to reneg, its just going to break.  I suppose you could try to force
some client-side flow control blocker so that it can issue a renegotiate,
but when the renegotiate is done, you'll probably have to drop all the
in-flight streams. 

Mike

On Fri, Jan 24, 2014 at 11:28 PM, Martin Thomson <[email-masked]>
wrote:

Discuss.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 29 Jan 2014 09:08:24 -0500

+1 for me, too.  Client certificates are often used with IPP (layered over HTTP/HTTPS) for authentication.

On Jan 29, 2014, at 3:57 AM, Yoav Nir <[email-masked]> wrote:

> +1
>  
> A good portion of our SSL-VPN customers use certificates. There are also a bunch of government web sites in various countries, and some banks.
>  
> It is very common for connecting BYOD mobile phones to the enterprise network for emails, intranet and such.
>  
> 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.
>  
> My suggestion would be to allow renegotiation, but disallow ALPN/NPN in a renegotiated TLS. If the applications can negotiate moving to another application, they can switch without a handshake. If they can’t do it without TLS, they won’t be able to do it with TLS – there are no “markers” in the application stream as to when a renegotiation occurred.
>  
> Yoav
>  
>  
> On Fri, Jan 24, 2014 at 11:28 PM, Martin Thomson <[email-masked]> wrote:

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Jan 2014 09:41:18 -0800

On 29 January 2014 00:57, Yoav Nir <[email-masked]> wrote:
> I know it’s not popular in content and social networking, but client

I expected to hear something like this.

Now.  The challenge for those people is to articulate what
restrictions are acceptable.

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?

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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 29 Jan 2014 20:55:53 +0200

> domains that could be coalesced.

Here are my thoughts on this:

Renegotiating to change client certificates makes me feel uneasy
(the "I feel that there will likely be issues here but I'm not sure
what those are" feeling).

Two ways to do client certificates without renegotiation:

1) Signal certificate requirements using HTTP Part7 authentication
and have client establish a new connection (and then decide what to
do with the existing one, perhaps keep it around for coalesced
requests).

-> Simple bit inefficient. Also works with HTTP/1.1.

2) Have a way to attach certificate to existing HTTPS connection,
with a way to signal the certificate to use on request. This is
highly nontrivial[1]. SPDY3 had such feature (the CREDENTIALS
frame)[2].

-> Hairy but efficient. HTTP/2.0 specific.

[1] In the few homebrew crypto protocols I have done, binding
authentication has been the biggest source of security problems
(of the "bad crypto" kind not "implementation bugs" kind) that
I know of.

[2] SPDY3 CREDENTIALS reminds me of one of my homebrew crypto
stuff... Before it was security-patched...

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Thu, 30 Jan 2014 00:38:04 +0200

> restrictions are acceptable.

Let's start with the requirement. If the server requests a client 
certificate, the browser has to show a certificate picker. This could 
the the regular OS picker, or some admonition to insert a USB dongle, or 
smartcard. They're an ugly but necessary part of using certificates. But 
nobody wants a certificate picker on their "https://www.example.com" 
landing page, so the server does not include a certificate request in 
the TLS handshake.

Somewhere on the landing page there is going to be some button or link 
saying "log in with a certificate". The user clicks that, and this 
causes the certificate picker to appear.

That's the user experience that we need. There's more than one way to 
get it:

 1. The browser does a normal handshake if necessary and when the server
    receives "GET /login_with_certs" it calls for a renegotiation that
    is done with a certificate request.
 2. The link actually looks like this: <a
    href="https://certauth.example.com">log in with a certificate</a>
    and this other server (or a different name for the same server) does
    have certificate requests from the start.
 3. Or we can invent some new mechanism where certificate are passed in
    HTTP.

#2 is more complicated in that it requires an extra server or an extra 
DNS name, and more complicated configuration. That's why it's mostly #1

Ilari suggested that some HTTP response will cause the client to start a 
new connection. This gets us around the coalescing issue. But how can 
the server know that this is a new connection that should include a 
certificate?  Are we bound to make a new TLS extension saying  "I want 
to mutually-authenticate" ? Maybe another SCSV? Either way, I don't see 
a way to do this without changing TLS or else forcing everyone to use #2.

If we're not dismissing renegotiation, I think it's fine that 
renegotiation won't be allowed to change application, and I think it's 
fine that renegotiation will only be allowed to make the transition from 
unauthenticated client to authenticated client - never from 
authenticated client to anything else, especially not another 
authenticated client.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 30 Jan 2014 01:05:31 +0200

On Thu, Jan 30, 2014 at 12:38:04AM +0200, Yoav Nir wrote:
> Ilari suggested that some HTTP response will cause the client to
> start a new connection. This gets us around the coalescing issue.
> But how can the server know that this is a new connection that
> should include a certificate?  Are we bound to make a new TLS
> extension saying  "I want to mutually-authenticate" ? Maybe another
> SCSV? Either way, I don't see a way to do this without changing TLS
> or else forcing everyone to use #2.

Oh yeah, the problem is that the client can't properly send a
certificate without server sending CertificateRequest first, and
sending CertificateRequest seems to have unwanted side effects...

So that won't work.

-Ilari