Re: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt

[Martin Thomson <[e-mail]>]

On 7 May 2015 at 10:24, Bodo Moeller <[e-mail]> wrote:
> Sending client certs in the clear may not be a good idea, but that issue
> seems entirely orthogonal to what False Start is all about. Do you see an
> actual problem about sending a client's signing cert specifically in a False
> Start handshake?


If a client is willing to send their certificate in the clear, I see
no reason to prevent them from sending this during False Start.  The
main risk with False Start is that the server has an increased risk of
being impersonated.  But the certificate is in the clear, so it's
unclear what a client could lose by this.

It's different if they were holding out for TLS 1.3 in the hopes that
they might have confidentiality for the certificate.  But that's a
stack problem more than anything else.  A stack might be configured
for client certificate confidentiality and use TLS 1.3, or TLS <= 1.2
and renegotiation to accomplish that end depending on the ServerHello
that it sees.

If the client certificate is to be enciphered in an immediate
renegotiation handshake, and both initial and renegotiation use False
Start, the client should probably check the Finished message on the
first before completing the renegotiation. Unless there are issues
delaying the Finished delivery, the client should have that prior to
when it needs to send the certificate.