Re: [TLS] TLS renegotiation issue

[Nicolas Williams <[e-mail]>]

On Fri, Nov 06, 2009 at 02:05:45AM +0100, Martin Rex wrote:
> Michael Gray wrote:
> > 
> > Eric Rescorla <[e-mail]> wrote:
> > > http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
> > 
> > IMHO The proposed fix looks to be also introducing the concept of
> > Retrospective Trust into TLS.  This being necessary due to the problem
> > highlighted in the HTTP protocol in that it will process messages that
> > arrived prior to authentication etc.

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

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.

> To some degree I share your concern.  
> 
> However, I do believe that the the proposed fix to provide secure
> renegotiation primarily fixes a problem in the TLS protocol, which
> does not live up to its own promises on security of a TLS session
> renegotiation.
> 
> Admittedly, the momentum behind this effort is the prospective
> blessing this will provide on the current awful practice in this
> area, because first of all, vendors _and_ implementors are trying
> to maintain the current level of look&feel / usability -- or maybe
> we should call it "convenience".
> 
> If we forgive the applications today, they are going to do even
> more daring things tomorrow -- and that could be things that
> we cannot fix easily.

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.

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.  They use a security tool, and as far
as they knew they used it correctly.  It is not their fault, but ours,
that we did not document the lack of this binding, or that we didn't
provide it to begin with (I'm using the royal we; I'm not to blame! :)

> In real life, however, security is much more about risk management
> than absolute security.  Bruce Schneier has written at least a dozen
> good articles about that topic.  The more difficult security is to
> use, the more often people will work around it.

What's the relevance of that here?  IIUC, you think delaying
authentication was purely for convenience, and that convenience is the
mother of all security bugs -- that convenience is almost a sin.  Right?
But if so, I don't agree.  Security features have to be convenient in
order to stand a chance of being used properly or at all.  That doesn't
mean that we should accept convenience over security, but that where we
can get both, we should.

> I think we should improve on guidance, rather than be totally anal
> about who goofed which part.

In this case we need to improve the design, not the guidance.  Granted,
we could choose to not improve the design and rely only on guidance.
However, it's much better to make the problem just go away.

Nico
--