Re: TLS renegotiation

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