W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: TLS renegotiation

From: Yoav Nir <synp71@live.com>
Date: Thu, 30 Jan 2014 00:38:04 +0200
Message-ID: <BLU0-SMTP20928FE16A452925177A0D1B1AC0@phx.gbl>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "Ludin, Stephen" <sludin@akamai.com>, Mike Belshe <mike@belshe.com>, HTTP Working Group <ietf-http-wg@w3.org>
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






Received on Wednesday, 29 January 2014 22:38:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC