Subject: Re: [TLS] Root certificates in server certificate chains

From: Marsh Ray <[email-masked]>
Date: Wed, 01 Sep 2010 00:47:30 -0500

On 08/31/2010 10:05 PM, Blumenthal, Uri - 0668 - MITLL wrote:
> Probability (greater than 1/2^80) comes into play when you need to
> make a decision based on incomplete information

Here's the one bit of information we don't have:
Is this an attack, or is it legitimate access?

Shall we flip a coin?

Shall we look at historical rates of attack?
OK, 9999/10000 similar access attempts have been accepted as legitimate 
without incident, therefore go ahead and let this one in. Note that the 
bad guy can inundate you with attacks (both obvious and subtle) tomorrow 
and completely redefine that ratio. So now you're put in the unfortunate 
position of having to choose between denying a large set of 
previously-accepted requests from legitimate users, or letting one or 
more of the attacker's attempts slip through with near certainty.

> - and responses like
> "call back when you have your form DD-xxxx and token YYY in hand,
> until then take a hike" are not acceptable.

And why not? In fact, I'd go farther than to say such a response is 
acceptable, I'd say it's a necessary feature of any secure system.

The fundamental mechanism by which access controls implement security is 
by denying access to the protected resource!

I know this is at odds with almost every other part of the system which 
shares the wonderful goals of making the system powerful and easy to 
use. It can be lonely at times, but when we work on security we must 
come to terms with the fact that the entire purpose of auth-n and auth-z 
is to unambiguously say "NO" when the requirements for access are not met.

Any system for which it is the least bit difficult to receive an "access 
denied" result is simply not providing a meaningful degree of access 
control. It is not a reasonable design goal that "the user never sees 
any failures" and any attempt to "design for usability" in this respect 
is probably crossing the line and resulting in a misguided weakening of 
security.

The best that can be achieved from a usability standpoint is when the 
user is able to comply with the requirements of the access control 
mechanisms with as little additional complexity and overhead as 
possible. This may involve usability hints "oh by the way your caps lock 
is on" but it must avoid ever leaking protected information "this is a 
valid username but the supplied password was wrong".

> Re. How can an unattended system know - by the virtue and power of
> flexible dynamic and complex policy that takes these aspects into
> consideration. The required complexity of such policies is one reason
> they now exist mostly in theory. I personally think such complex
> policies are inevitable, but their time (and our ability to deal with
> them) hasn't come yet. In fact we still have problems with simplistic
> policies.

Complexity favors the attacker.

I'm not saying there's not a place for  a "3 out of 5" scheme or even a 
"one item from column A or two from column B" scheme. But in my 
experience, any "flexible and dynamic policy" is going to end up both 
incomprehensible for humans ("so why exactly did the system decide to 
grant access in this case and what switch do we flip to reliably disable 
it for next time?") and it will have all the interoperability magic of a 
90s-era "flexible" HTML parser.

When was the last time you got a corrupted application data record out 
of a properly set up connection over TLS or IPsec?  Possibly never? 
These protocol layers simply reject the imperfections and possibly drop 
the connection, at most reporting a syslog message. They would never 
bubble up a checksum error all the way to the user and ask if he wants 
to use the bad data anyway.

It would be ludicrous for a DNS resolver library to ask the user:

"A response was received which looks like it could match a recent query, 
but one or more of the transaction ID and source port do not match the 
expected values. Would you like to use this possibly attacker-supplied 
query response anyway? [Cancel], [OK] [x] don't ask me again".

That's why functional DNS is nearly universal, yet the net is full of 
https links to servers presenting non-validatable trust chains. DNS is 
now being looked to to solve the key distribution problems of TLS and 
SSH by publishing them in signed DNSSEC records. How ironic that DNS 
wasn't supposed to be the cryptographically secure protocol here anyway! 
It was TLS and IPsec that were supposed to be the things that saved you 
from hijacking at the IP and DNS layers.

> We can discuss home-grown CA offline if you wish.

OK

- Marsh