On Wed, Feb 26, 2014 at 8:46 AM, Ben Laurie <[email protected]> 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/
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
