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

Re: TLS renegotiation

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 3 Feb 2014 09:23:08 -0800
Message-ID: <CABkgnnVRCbNmi0BYYbawVxPDqfc-wpv8O_tDmAjj5iLrJMWx7Q@mail.gmail.com>
To: Yoav Nir <synp71@live.com>
Cc: "Ludin, Stephen" <sludin@akamai.com>, Mike Belshe <mike@belshe.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 3 February 2014 04:20, Yoav Nir <synp71@live.com> wrote:
> 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.

I wasn't going to leap to solutions so soon.  What about CONNECT?

It's not a lack of possibilities that is the problem here.  It's a
lack of clarity around what the desired behaviour is.  If, as you
suggest, this is a problem that can be detected for a given request,
how do we then extrapolate that to other interactions with the same
origin?  Why would we?  This is, of course, always the issue with
client certificates.

I'm still not 100% certain that we've already stated all the
assumptions here yet.
Received on Monday, 3 February 2014 17:23:35 UTC

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