Re: [Trans] CT for opportunistic STARTTLS in SMTP

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Feb 26, 2014 at 8:46 AM, Ben Laurie <[e-mail]> wrote:

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


Yes, CT might be applicable but it is designed to meet constraints that
probably don't apply.



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


PPE is mostly focused on end-to-end encryption.

We can pass certs for SSL in-band. But right now CA issued certs are only
required for email clients doing SUBMIT and the implementations are weak.
OK so it turned out that Apple's wasn't meant to ignore the server cert
like I assumed. But I have an attack that negates the CA cert checking on
at least one other platform.


So adding CT to STARTTLS as is makes no sense unless the scope of CT is
wider than CA issued SSL certs. It means we either have to do security
policy or end-to-end encryption with client certs.

I do have a plan to do both but each requires more moving pieces and they
each require the same additional pieces. So there if we are going to invest
for one we might as well do both.


-- 
Website: http://hallambaker.com/