[SSL Observatory] Witnessed Google certificate change again (includes details like certs, CRL...)

Ondrej Mikle ondrej.mikle at gmail.com
Wed Jan 19 19:37:36 PST 2011


On 01/20/11 01:00, Chris Palmer wrote:
> I want to limit the extent to which we trust crypto and in particular I reject the trusted third party model because third parties tend not to be/cannot be trustworthy from the point of view of parties 1 and 2 (at least not at the same time). Therefore I want SSH-style host authentication only (persistence of cryptographic pseudonym), or any other system with no third party. Andy, as a site operator, wants the flexibility to change cryptographic identities while maintaining a constant real-world identity, and TTPs are one way to get that feature.
> 
> Obviously, I am never wrong :) but even more obviously, Andy is not wrong either --- especially given that the pwnability of hosts means that persistence of pseudonym is not a slam-dunk win for clients. I personally think it's better, or could be better, but we can't imagine it is perfect.


@Andy Steingruebl:
> For example, SSH currently fails pretty badly on the usability scale when there is a key rotation, as regular non-security-aware users don't know how to verify keys, tell whether they are being attacked, etc. 
> 
> Equally bad is the current situation where any CA can hand you a cert for a domain, and you have no way to tell that they are "authorized" to make said assertion.
> 
> I think that solutions to both of these problems can coexist, and ultimately user-choice is important, but that to be deployable we have to have meaningful and easy-to-use defaults.  Otherwise, as we've seen, attacks like sslstrip fool most people and they get owned.  

Now I seem to understand the core of dispute: we are talking about different
threat models.

First (end-user) model:

1) key rotation should be done "flawlessly"
2) end-users should not be confused when keys rotate
3) citing Andy: "ultimately user-choice is important, but that to be deployable
we have to have meaningful and easy-to-use defaults" (would like to stress this
point)
4) cryptographic primitives are expected to hold (for some time)


My threat model:

@Chris Palmer:
> Although I also don't advise that we design our network/security protocols with unknowable threats in mind, the plain fact is that some trusted third parties are also surveillance vendors, incompetent, weird, acting in excess of their expected authority, or otherwise untrustworthy from the point of view of at least some relying parties. So a good security system must indeed take those problems into account.

This. I expect an attacker strong enough to circumvent crypto by physical
access/army of hackers finding holes/coercion/etc. Then, the question is, what
is the incident response? More specifically, I want attacker to not know (or
make it hard to know) at what time I realize that I have been compromised. Why?
In order to provoke the attacker into leaking intel (make a mistake).

Of course, once crypto is bypassed, you are left in "security by obscurity
realm". You can then only count on statistics, experience, "gut feeling". (If I
had to guess, Godel incompleteness theorem stands against both attacker and
defendant here.)

That's why I call for "Overnet of Perspectives" and checkpointing. Its
implementation can coexist with current models.

And of course, this latter threat model has no definite solution, but
mitigations by side channels can exist.

(Not sure this mailinglist is a good place for the discussion of the latter
model. I might be "biting off a too big piece to chew", so to say. Or be plain
wrong.)

OM



More information about the Observatory mailing list