On Wed, Feb 26, 2014 at 6:13 AM, Ben Laurie <[email protected]> wrote: > On 25 February 2014 22:13, Trevor Freeman > <[email protected]> wrote: > > The point with opportunistic TLS is its OPPORTUNISTIC, if there is any > > failure it will fall back to send without TLS. In opportunistic TLS the > > sender does no checks whatsoever on the certificate so why would it care > > about CT? > > Then perhaps the word "opportunistic" should be removed from the > question. What is the relevance of CT to SMTP+STARTTLS?
The work factor for getting a bogus certificate is fixed in time. Without CT the cost of getting a bogus certificate is $X. With CT the cost is still $X but only up to the point where the certificate is notarized at which point the cost of forging that certificate has gone to breaking the cryptography (assumed to be infinity). If we presume the existence of a common CT infrastructure such that it is possible to query all the logs at one point then we have a mechanism for requesting all the certificate information on a domain. We can extend that approach in several ways: * More types of certificate: S/MIME certs and PGP endorsements. * Policy statements signed under a notarized certificate. I am not sure that it makes a lot of sense to consider them in the same pot though because email has very different protocol requirements and constraints. It is asynchronous which means that we don't really care about latency much, certainly not at the sub second level. But that also means we can't pass credentials in-band as in SSL. What I am looking to do in PPE is that when keys are generated, a self-signed certificate is posted to a Cryptographic Advisor (CA for short) which can interface to whatever next gen PKI emerges. When sending a message the sender can pull information from their CA. Both groups are using the Omnibroker protocol for this which is simply a JSON version of a generalized XKMS, the question being 'how does X connect to Y to do Z' So an Omnibroker answer could be 'encrypt the message under S/MIME using this cert and force the use of STARTTLS for the transport.' The question I haven't addressed yet in code is where those statements come from. My belief is that this will involve the user signing a policy statement to say what their end-to-end security statement is. It seems to make sense for the site to also make a signed policy statement to say that they always offer SSL on SMTP (and possible make the statement for some other protocols like http). But this is not that difficult to specify. The only real choice is ASN.1 or JSON and I think the preference is clear. So at the very least I expect any S/MIME / PGP / Policy notary infrastructure to feed into the same metanotary infrastructure as CT. It is also quite possibly the incentive that would cause browsers besides Google Chrome to consider implementing CT. Except for the case in which an attacker knows that the target only uses IE or Firefox or Safari any bogus cert is going to be detected in the Chrome CT client side check. -- Website: http://hallambaker.com/
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
