Re: [TLS] Renegotiation: trying to summarize

[Geoff Keating <[e-mail]>]

On 24 Jun 2014, at 4:43 pm, Martin Rex <[e-mail]> wrote:

> Geoffrey Keating wrote:
>> 
>> 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:
> 
> I believe that just the opposite is true, this opens a whole new can
> of worms.
> 
> Really, the existing renegotiation is both strong and simple.
> 
> 
> For most of our (customer's) usage scenarios, TLS session caching
> is a MUST, and the session caching concept with renegotiation is
> simple and clear.

I think there is strong evidence to the contrary: If it was simple and clear, the triple handshake attacks would not have been possible.

> A TLS session that authenticates only the server (certificate) within
> TLS has different properties than a TLS session that authenticates
> both, client&server.   With traditional renegotiation, these are
> distinct SSL sessions (as far as caching is concerned), and either
> one can be resumed.

So, in current TLS, if a session is established with no client authentication, and then there's renegotiation with a client certificate, and then the first session is resumed, has that resumed session been authenticated by the client certificate?  It seems like with the renegotiation fix, the entity that established the second session has signed data that associates them with the first session.  Did they mean to do that?  Will the server interpret it that way?  Is it safe for the server to interpret it that way?

> The most common use of renegotiation is to change the status of
> one (or both) peers from not authenticated in the existing session
> to authenticated in the renegotiated session.

Actually, it is used to change the status in *both* sessions.  In HTTPS, the protocol exchange does not go:

-> PUT authenticated path
<- please renegotiate, and now I want a client auth
<> renegotiation
<- thank you, but your previous request gets an error because it was sent before you authenticated
-> PUT authenticated path
<- OK, send me the data

what actually happens is:

-> PUT authenticated path
<- please renegotiate, and now I want a client auth
<> renegotiation
<- thank you, send me the data

The server uses the renegotiation to authenticate the request sent before the renegotiation.  (I used PUT here to make it clearer, but the same principle applies to a regular GET request.)