[messaging] CT and key validity binding semantics

[Ximin Luo]

On 19/08/14 19:00, elijah wrote:
> I agree CT is off topic, but on topic to the degree to which it keeps
> being suggested for user keys...
> 

I didn't mean to suggest it's off-topic - just to point out some issues with discussions about it.

> On 08/19/2014 05:45 AM, Ximin Luo wrote:
> 
>> I think people keep making the same mistake of treating CT as 
>> "providing key validity". It does *not* provide key validity, nor 
>> binding; it provides transparency *to enable systems that do provide
>>  the former*. In other words, via the auditing and monitoring 
>> components, then you gain "some confidence probability" that the key
>>  is valid.
> 
> ....
> 
>>> (1) The web server problem: a present server needs to prove itself
>>>  to a present visitor. Addressed by CT, etc.
> 
>> CT does not address (1) any more than it addresses (2) or (3). It is
>>  the auditing and monitoring surrounding CT that provides (1), and 
>> even currently there are known gaps and it is only half-implemented 
>> (no gossip protocol). As you say, "ultimately only the recipient 
>> knows for sure which public keys are correct for the recipient". This
>> is true *for webservers as well*.
> 
> You are making a distinction between the cryptographic log operations CT
> and the monitor and auditor operations. I have not heard anyone describe
> the monitors and auditors as "not CT". Is this semantic distinction
> accurate?
> 

Perhaps not, but monitors/gossip for non-X509 CT logs will need to do different things, yet people tend to neglect the specifics of this when they talk about using CT for a different application. The failure modes would be different, too.

>> Overall however, this is not a cryptographic problem, but a 
>> logistical one. (This is why I choose the term "key validity", to 
>> distinguish it from cryptographic "authenticity" once you have 
>> actually validated the key.)
> 
> I thought the point of CT was that it is a logistical approach that
> includes cryptography, but it does not provide cryptographic
> authentication. By your distinction here, CT does provide "key
> validity" but not "key authenticity", yes?
> 

Not sure what you mean by either concept. Let me try to define things from basics. Alice wants to talk to Bob. From Alice's POV there's a few things:

1. Bob in the real world
2. Bob's current key
3. The stuff she wants to send to Bob

We need to bind 1 -> 2, this is what I mean by "key validity". Then, 2 -> 3 is a standard cryptographic authentication (that assumes you already know the right key). In PGP and OTR and others, you can bind 1 -> 2 by meeting up physically and comparing keys. This is the strongest way of doing bindings.

Some systems do things differently, they have

1a. Some URI to contact Bob by.

Alice is expected to bind 1 -> 1a by various social/human/non-crypto means (e.g. reading lots of independent secure websites with the same contact details), and the system tries to bind 1a -> 2.

CT helps to bind 1a -> 2 by forcing all binding-claims ("certificates") 1a -> 2 to be published in a log. This way, Alice can be confident that Bob can also see all claims 1a -> 2. Then, we need some way for Bob to denounce[1] bad claims, such that this denouncement can itself be bound back to Bob, and for Alice to ensure that her view is fresh. This isn't well-specified nor finalised yet even in plain CT, and is the bulk of the issue (more so than the log itself), in terms of both importance and difficulty.

And, how secure can a binding of the form 1a -> 2 be? I think that we don't have anything that *actually does this*. For X509, the claim is from a "trusted" third party that they performed some (non-standard, vendor-specific) verification process, that itself is probably open to attack (especially if using email or DNS; they are insecure). Often there is some other entity that controls 1a *by logistics* and therefore is always able to forge the binding (e.g. your email provider). So even if the CA is acting in good faith and does everything competently, they might still make false bindings of the form 1a -> 2. How to react, in this case?

So, we have two bindings 1 -> 1a and 1a -> 2, each with less-than-perfect levels of assurance. For sure, often this is "good enough" when considered against convenience, but one ought to be precise in reasoning about which parts of it have holes, because only then can we improve security. One simple improvement is to have multi-signed certs, as well as stricter standards for CAs. [2] is actually pretty decent already, but could be more strict (e.g open-source verification code, continual verification) if we had some way to actually enforce the policy for the "too big to fail" CAs.

For small-scale personal communications though, I would rather take my bets on the 1 -> 2 binding, so I argue that every end-to-end strong-security system should offer this option.

X

(Re-reading your email, I think the point about unique entries for user-keys is not that important. The system must be able to identify badly-bound keys *that are already in the log*, this is needed for vanilla-CT too. OTOH if a user wants to have multiple short-lived keys, they can issue bindings that have expiry dates just like PGP.)

[1] This is not the same as revocation - only the person that issued a cert can revoke it.
[2] https://wiki.mozilla.org/CA:Recommended_Practices

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140820/3be8ddec/attachment.sig>