Re: [Trans] CT for opportunistic STARTTLS in SMTP

[Ben Laurie <[e-mail]>]

On 26 February 2014 13:41, Phillip Hallam-Baker <[e-mail]> wrote:
>
>
>
> On Wed, Feb 26, 2014 at 6:13 AM, Ben Laurie <[e-mail]> wrote:
>>
>> On 25 February 2014 22:13, Trevor Freeman
>> <[e-mail]> 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.

Exactly, so it would be entirely possible to check with the log(s)
before proceeding with the connection. This is nice because we could
(I think!) even not require the SCT to appear in the TLS connection at
all - the client could look up the cert by hash...

> But that also means we
> can't pass credentials in-band as in SSL.

I'm not sure what you mean by this? Credentials pertaining to the
sender/recipient? Clearly server credentials can be sent in-band.

> 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/