[cryptography] Diginotar Lessons Learned (long)

[Lucky Green]

I can't help but chuckle about Diginotar's very public display of
security incompetence. I mean, who in our line of work can be expected
to keep a straight face when reading gems such as this one taken from
the report by Diginotar's incidence response rapporteur:

"The separation of critical components was not functioning or was not in
place. We have strong indications that the CA-servers, although
physically very securely placed in a tempest proof environment, were
accessible over the network from the management LAN.

The network has been severely breached. All CA servers were members of
one Windows domain, which made it possible to access them all using one
obtained user/password combination".

http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1/rapport-fox-it-operation-black-tulip-v1-0.pdf

We are also seeing a near universal call for "fixes" of the broken PKI
paradigm. I couldn't agree more that fixes - and indeed redesigns - are
badly needed and have been for some 15+ years. Pretty much since the day
the word PKI was coined. What I hear much more rarely are discussions if
the proposed fixes actually solve the problem. What I hear hardly ever
are discussions as to which unintended consequences the proposed (and in
some cases already implemented fixes) may bring.

When designing an improvement to a system, it helps to keep in mind the
original requirements the system was intended to address.

In the case of SSL server certs, those requirements roughly were:

- provide Joe Browser user with the ability to connect to a site with
which Joe has no prior relationship while giving Joe sufficient
confidence that the site is who they say they are without MITM for Joe
to part with his credit card number. The public CA infrastructure,
high-profile failures notwithstanding, has done a reasonable job meeting
that requirement.

- shift liability for this authentication from the browser vendors to a
third-party (CA). The current system has done a flawless job at this.
Defenses such as HSTS and cert pinning cannot do better and likely will
do worse, since the browser vendors are getting more actively involved
in the decision which sites to protect with the "best" level of
security. Indeed, security designers and auditors for financial services
firms that fail to demand inclusion of their site in HSTS and cert
pinning lists are arguably falling behind on best practices.

It is not inconceivable that we will see litigation against a browser
vendor initiated by a website that was compromised by a bad cert after
the browser vendor refused to include the website in their HSTS lists.
Note that there is no chance that browser vendors will be willing to
create the infrastructure and build up staffing levels such that all
legitimated websites are protected by in-browser HSFS lists. Yet the
more sites a browser vendor adds to their HSTS or cert pinning lists,
the higher the risk of litigation becomes.

- avoid the server vendor (at the time those requirements were
identified the sever vendor was equal to the browser vendor) from
incurring the costs of having to verify the authenticity of each website
or domain.

The labor cost of adding cert pinning for a domain from a browser
vendor's perspective is identical to that of adding to the browser the
hash of a CA operated by that domain. Which is identical to the cost a
browser vendor would incur authenticating each website. Not going to happen.

At scale, any such list cannot be handled via code updates, but has to
be dynamically provided as a service by the browser vendor. Meaning the
browser vendor becomes isomorphic to a root CA from the perspective of
the users of that browser.

- limit the cost of security to the server operator.
Website and other encrypted service operators are annoyed as it is
obtaining certificates from one CA. It is unreasonable to ask a website
operator to engage in separate dealings with each browser vendor.
Instead, both the website operator and the browser vendors will prefer
dealing with a single entity (or small number) of trusted third parties
(TTP). Such as a public CA.

- no single trusted entity.
Whether you design a security protocol or software counting widgets,
there really is only one of three numbers that your design needs to be
able to accommodate: one, a few, or a great many.

In the public server authentication space, "one" translates to a global
authority issuing credentials. It is not clear who that authority would
be. Presumably the United Nations. What is clear is that national
interests preclude the use of a single global authentication authority.
It is conceivable for each country to have a local authentication
authority, which would require each country to operate some
authentication authority. There is no agreement how many countries exist
on our planet, but the number is somewhere around 200. More than there
are root CAs in the browsers today. Which gets us to the next number: "a
few".

A few represents the status quo. Under the status quo, a few CAs are
issuing certs. Some CAs have a better security track record than others,
though most CAs with an unblemished security record have simply not yet
been attacked, failed to disclose attacks, or don't issue certs to
customers on the Internet at large and therefore can afford to operate
in a purely offline environment. The latter option is not available to
CAs or other services that authenticate a large number of domains.

When operated by national governments rather than global vendors, one
can envision designs in which national CAs issue certificates only for
entities located within the nation's borders. Such designs quickly lead
to a requirement for a global database (see "one" above) or to a
scenario in which Iran's national authority can issue certificates for
gmail.com. Moreover, such a design carries the high risk of leading to a
need for each site to obtain separate certs for each country in which it
operates. That outcome would be welcomed by certain governments, be
perhaps organizationally manageable for a large server operator such as
Google, but be intractable for many other sites. In addition to likely
being detrimental to both the exchange of ideas and security of the
Internet as a whole.

The "a great many" scenario translates to designs in which each browser
reports the certs seen up to a central database, alerting the user if
the cert presented by a server doesn't match (most) of those certs that
were seen by users of the same service. Meaning the browser vendors or
some global entity have to operate a server that more or less logs each
https access. I am not sure how I feel about that. What I do know is
that it creates a whole new attack surface for other types of attacks. I
also believe that for example Tor users, a known target for fake SSL
server certs, would unlikely consider such a design to be an improvement.

Other designs in the "a great many" category log SSL server certs only
locally, alerting the user when a certificate for a particular site
previously visited has changed. I can see value in that features. But we
need to realize that this feature will add to the SSL server cert alert
fatigue users are already experiencing. Time and large field trials will
tell if such a feature is a security net positive. It may increase the
security posture of very security conscious Tor users. It will not solve
the problem for the average Gmail user. Not even for the average Gmail
user in Iran.

- generate recurring revenue
Often mentioned as the primary reason for the existence of CAs,
generating recurring revenue is a driver for significant percentage of
those in the CA business, but as we have seen above the overall number
of entities that derive revenue from issuing certs is quite small. It
is, well, "a few".

The perceived benefits to the issuer are a powerful driver in the client
cert space, where the desire for attribution makes the sum total of
drivers in the SSL server cert space tiny by comparison. But we are not
talking about client certs here. Most CAs do not make a significant
amount money from issuing server certs and the handful of CAs that do
likely would do just as well operating alternative authentication
systems, be that on behalf of a national SSL server cert authority or on
behalf of a browser vendor needing to maintain an HSTS list. The cost
structure is dominated by validation costs at any rate and that holds
true whether the end result is a signed cert or an entry in a browser's
HSTS or cert pinning list.

There are additional requirements that drive the existance of SSL server
certs and public CAs. The requirements I outlined in this post will
suffice to illustrate my point: unless some proposed SSL/CA
replacement/augmentation system will do at least as well at meeting
those requirements as the status quo, the design is unlikely to succeed
in the marketplace. As you are being bombarded with design proposals
promising improvement over the status quo in the next weeks and months -
and are prehaps are working on designs of your own - it will be helpful
to validate those designs against the requirements prior to chosing to
implement the design.

--Lucky Green
_______________________________________________
cryptography mailing list
cryptography at randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE