Re: [TLS] Review of PR #209

[Martin Thomson <[e-mail]>]

On 16 September 2015 at 08:30, Ilari Liusvaara
<[e-mail]> wrote:
> Problem with pulling client auth out of the handshake is that it
> complicates applications that can't change identities involved with
> active connection.

Why would that be unsupported here?  The server can still send
CertificateRequest immediately after its Finished.  That looks exactly
like it does today, only the order has changed.

> As then the application needs to ensure that the authentication
> occurs between TLS handshake and actually starting up the protocol.

I'm not sure that is necessarily a problem.  If the claim is that the
authentication attests to everything prior to its appearance, then you
have no problem.  I think that claim is reasonable, but I'm happy to
discuss it.

>> 2. The client can send Certificate and CertificateVerify at any
>> time application data is permitted, regardless of whether the
>> server had previously sent CertificateRequest.
>
> CertificateRequest contains the permitted signature algorithms
> for the PoP signature, which TLS library needs to verify before
> dumping the certificate chain on application (which can then
> figure out things like trust anchors).
>
> Without CertificateRequest, one has little idea what algorithms
> are acceptable there.

Arguably, signature_algorithms covers that adequately.  Though I'll
grant that certificate chain validation often happens in a separate
component to the TLS stuff.

> Basically, one must clear the pipeline before changing identities,
> and with protocols like HTTP/2, this is extremely expensive (seemingly
> even more expensive than establishing a new connecion).

There's been some confusion about this with HTTP/2.  I think that if
you adopt the position that authentication applies to the entire
session - even retroactively - then the only remaining concern is the
correlation one.  If you have three tabs to the site open where all of
them are making requests and you see a certificate request, which one
do you pop the dialog on?

> Also, it should sign the certificate, to avoid possible weirdness
> due to signatures not properly binding the key (some schemes do,
> most don't).

I agree with this.