Re: [TLS] Renegotiation: trying to summarize

On Tue, Jun 24, 2014 at 4:43 PM, Martin Rex <mrex@sap.com> 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.
>
> 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.

Yes, this is a problem that has to be carefully considered if we
permit state changes in TLS.

>
>
> 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.
>
> There was a problem with TLS implementations *NOT* nailing down
> an authenticated identiy to _not_change_ during renegotiation, unless
> the application has specifically requested for this to be allowed
> through new/non-standard API calls (this is nothing that should happen
> to an application by mere configuration tweaks).  This problem has
> already been described in the security considerations of rfc5746
> and it was the interim workaround suggested to browsers for the
> triple-handshake-attack (which seem to have boldly ignored the
> issue from the rfc5746 security considerations section...).

There is nothing a client can do about the original renegotiation
issue. With Triple-Handshake some usages (tls-unique channel bindings)
are doomed, and others (web authentication) have to take special care
that server names don't change on renegotiation, even though it was
"fixed".

It's not surprising that people ignored the need for client-side
fixes, because rfc5746 had an extension that claimed to fix the
problem without rewriting code.

However, end of the day we have to deal with the implementations and
code that we have. 90% of it cannot handle renegotiation correctly in
the most general form. So we need to restrict the semantics, and how
we do that I don't know, because I don't know what the expected
semantics are.

Sincerely,
Watson Ladd
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin