Re: TLS renegotiation

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.

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