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

Re: TLS renegotiation

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Mon, 3 Feb 2014 17:05:29 +0200
To: Yoav Nir <synp71@live.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "Ludin, Stephen" <sludin@akamai.com>, Mike Belshe <mike@belshe.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20140203150529.GA5378@LK-Perkele-VII>
On Mon, Feb 03, 2014 at 02:20:26PM +0200, Yoav Nir wrote:

> 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.

Special ALPN string:
I think technically works, dunno if needs a trip through TLS WG.

Extension:
I think technically works, definitely needs a trip through TLS WG.

SCSV:
A bad idea. SCSVs are for situations where extensions can't be relied
upon, which isn't a problem here due to fundamential requirement on
ALPN, which is in itself an extension. 

> 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.

My earlier idea was to literally use WWW-Authenticate.

> 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.

Here be dragons. This is quite nontrivial to do.

Well, basically it is just a signature plus a certificate blob, but
a signature over what?

Grabbing a string using TLS-EXTRACTOR and signing that is vulernable
to a MITM attack unless client or server enforces contributory
Diffie-Hellman (quite nasty to do with non-EC DH).

Adding apparent certificate of the server to signature would require
such attacker to have the server's private key.

TLS-UNIQUE (which isn't vulernable to above attack) is only 96 bits,
which seems bit small nowadays...

Sure, it would be quite a bit more flexible than doing it on TLS
layer...


-Ilari
Received on Monday, 3 February 2014 15:06:00 UTC

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