[Cryptography] "Trust in digital certificate ecosystem eroding"

[Michael Kjörling]

On 3 May 2015 15:45 -0000, from johnl at iecc.com (John Levine):
>> It would take _considerable_ (re-)training of users to actually take
>> security warnings seriously, and to reduce the number of false
>> warnings.
> 
> All the studies I've seen say that no amount of training will make
> users take security warnings seriously.  Partly it's the number of
> false alarms, partly it's a not totally irrational tradeoff between
> the risk of what might happen and the desire to get their work done.
> 
> If this stuff is going to work at all, it has to work automatically.

That's basically my point, and to my mind it completely invalidates
Howard Chu's suggestion that "Every time you hit a new web site,
prompt for whether to trust it's chain or not". The user simply isn't
in a position to make such a determination, and much less so when the
certificate chain _changes_, perhaps in the middle of a session. And
that's assuming that the chain actually changes _and_ that the change
of the certificate chain actually means something important. Look at
how several CAs are currently changing from a non-SHA256 to a SHA256
cert, labelled as such in the certificate CN. That's a change of the
certificate chain, but to something like five or six nines of the
users, it's a complete non-issue.

As for www.funnymovieswithcutekittens.com specifically, feel free to
substitute anything. The user wants to get the job done (whatever "the
job" might happen to be). So now "ValiCert, Inc." (just to take one
example out of my browser's trust store) is vouching for their bank's
web site rather than "VeriSign, Inc."; the vast majority of users are
unlikely to even recognize what a change of CA means, much less be
able to make an informed decision about what to do, and as you point
out the user likely just wants to get the job done. So we _cannot_ put
the burden on the user; it has to be placed somewhere else.

As for what that "somewhere else" might actually be: Widely deployed
HSTS and DNS-based certificate pinning (with a service identifier of
some kind, perhaps per-port) in combination with DNSSEC for reasonably
high-value sites seems to me to at least have a chance of working,
because at least it puts the authoritative information where it
belongs: with the owner of the site. HTTPS is already per-hostname
(with allowances for multiple host names, but not for sub-hostname
subdividing of certificates) so DNS seems a quite acceptable metadata
delivery mechanism, and DNSSEC (while imperfect) can help against
spoofing of DNS responses and is something that we actually _have_
albeit not widely deployed at present. I don't know what the current
status on DNS-based certificate pinning is, but this seems like
something that, _if the desire to do so exists_, we could deploy
widely (both in client software and on servers) within a matter of a
few weeks to a few months. Aside from DNSSEC, it's a fairly minimal
change on the server side, and some client code to do an additional
DNS request and do something intelligent with the response. (It would
also be a non-breaking change; all present clients would keep working
the same way they do currently, and new clients could take advantage
of the site owner's statement of which certificate(s) to trust.) It
also seems to allow for intelligent handling for non-interactive
services, including SMTP STARTTLS.

It almost certainly wouldn't be perfect, but it seems to me to be
something that we could actually do with what we currently have to
improve the ecosystem situation a great deal.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)