RE: TLS renegotiation

+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:sludin@akamai.com] 
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 <mike@belshe.com>
Date: Saturday, January 25, 2014 at 5:01 AM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: TLS renegotiation
Resent-From: <ietf-http-wg@w3.org>
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 <martin.thomson@gmail.com>
wrote:

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.