Re: [TLS] TLS renegotiation issue

[Martin Rex <[e-mail]>]

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.

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.


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.


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


>
> However, IMHO I would guess that once TLS is perhaps protected,
> then the attacker will simply attack at some other level as the
> HTTP/Web Application is still vulnerable. IMHO these other
> attacks might be easier to do and perhaps at the same time harder to
> detect.

Just a second!  The problem were addressing here is _NOT_ easily
detectable.  I think it is just the opposite.

There has always been an arms race.  And I don't see how or why
this would change in the future.

What exactly do _you_ suggest?

That we _not_ fix this issue in TLS, so that the apps can keep
pointing on us and do not have to fix their other problems?
Is that really going to help?


>          My view is that implying Retrospective Trust in TLS will lure
> application developers into incorrectly thinking they are now (or are
> still) safe and continue the IMHO dangerous practice of Retrospective
> Trust.  IMHO I would question why allowing the concept of Retrospective
> Trust into TLS is not inherently dangerous.

As inidicated at the beginning, there is some truth in what you're
saying.  But looking at all aspects of the problem, I don't feel
like not fixing this is the bigger evil.


But your criticism about the Retrospective Trust is quite valid.
It is a dangerous design, and it is questionable that the risk it
brings is worth the convenience it offers.

Compare it to this real-world scenario:


Today, many companies have tight control on who enters their office
buildings, and it helps them to manage their risk and gives them
some amount of audit and accountability.

The Retrospective Trust means that you get rid of that control
at the building entrance.  Instead, you solely rely on your
own perfection to reliably check each and everyone that leaves
an office with a binder in his hands.  Either he must show his
permission or leave without the binder.  You regularly find
someone without permission, but you're not allowed to ask his
name, and a few of them constantly do this and you have no
means to keep them out of your building.

I would not describe the latter as sensible risk management.
It doesn't look very reliable or robust.  But if you implement
some convenient "permissions check" (hey, rfid is fun, isn't it),
it might feel quite convenient for the people that work
there.  Having to pass a gate one-by-one during rush hour
(morning,lunch,evening) often creates a less appealing
user experience.


-Martin