Re: TLS renegotiation

+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 <synp71@live.com> 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
>  
>  
> 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.
> 
>  

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair