Re: [TLS] TLS renegotiation issue

[Marsh Ray <marsh at extendedsubset.com>]

Nicolas Williams wrote:
> What is "Retrospective Trust"?  A search for that finds unrelated items.
> A search for "Retrospective Trust security" finds restrospectives on
> workshops and what not.

I think the term "retroactive authentication" is a bit better to
describe what HTTPS servers does for dynamic client certs.

> In any case, assuming that you mean that authenticating something said
> earlier is bad, I disagree, provided that one actually does that (as
> opposed, as in the case of this bug, merely thinking that one is
> authenticating something already said but not really).
> 
> There are, in fact, a number of places in our protocols where we
> authenticate something said earlier.  In many of those cases we have no
> choice but to do that!  Consider TLS, SSHv2, IKv2, etcetera.  They all
> start with an unprotected negotiation and key exchange, followed by an
> exchange of messages that authenticates the unprotected negotiation
> using the exchanged keys.  That's a matter of bootstrapping security,
> yes, but that happens often.

My feeling is that it is extra-tricky to get right, and any mistakes
seem to default to resulting in a security vulnerability. Seeing this in
some webserver code was one of the things that originally led me to the
problem.

However, I do not agree that the concept is fundamentally broken. After
all, signing a document at the bottom of a page is not worse than
signing it at the top. What you have to worry about is the possibility
that your signature on the last page may not cover all the pages in a
multi-page document. All the attacker may need in that case is a staple
remover.

> I don't think what the apps do, particularly HTTP, is bad at all.
> What's bad is the lack of binding between the disparate TLS connections
> that result.
> 
> What's so bad about deferring authentication of the user until after you
> know that it's needed?  Nothing, _provided that_ you also ensure that
> the request that required authentication came from the same entity that
> you subsequently authenticated.

That is a good point I think.

Even though the first session had an "anonymous" level of
authentication, that doesn't mean that the subsequent authenticated
session didn't need to authenticate the original request!

In this case, the client of that first anonymous session is implicitly
assigned an identity, but is not authenticated properly. He needs to be
authenticated as being "the same party as the client in this other session".

> I think it's fair to say that folks using TLS expected the binding,
> which we now know wasn't there, to be there -- or at least that they
> intuitively expected such a binding, even if the explicit thought of it
> never entered their consciousness.

The "binding" was effectively there in SSLv2 because it was guaranteed
that there was only one session. The SSLv3 spec quietly introduced the
concept of renegotiation and multiple sessions without ever addressing
the fact that this would translate into security vulnerabilities unless
every existing application changed its internal model for handling SSL
connections.

- Marsh