Re: [TLS] Renegotiation: trying to summarize

[Geoffrey Keating <[e-mail]>]

Andrei Popov <[e-mail]> writes:

> This is a good summary, thanks Martin. It also seems that #1 and #2
> break (or significantly complicate) existing TLS client auth
> scenarios, while #3 and #4 allow these client auth scenarios.

I believe there was also a proposal to allow client auth at any point
during the session, but not renegotiate: no new ciphers, no new keys,
just send CertificateRequest and get back Client Certificate and
CertificateVerify.  This does prevent use of client certificates with
encryption-only algorithms, but it seems such a thing should be used
from the start of the connection anyway.

Compared to renegotiation this allows many simplifications:
- It can't affect the confidentiality of the session
- The server's identity cannot change
- The authentication is of the whole handshake from the start, so
  there's no possibility of some earlier unauthenticated state
  affecting the rest of the session
- You can request multiple authentications and all of them apply to
  the entire session so far including previous authentications
  (a property that current TLS is vague about)
- No random numbers are needed (at least for RSA certificates)