Re: TLS renegotiation

[re-awakening this thread]

On 29/1/14 7:41 PM, Martin Thomson wrote:
> On 29 January 2014 00:57, Yoav Nir <synp71@live.com> 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