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