Re: [Trans] CT for opportunistic STARTTLS in SMTP

[Trevor Freeman <[e-mail]>]

SMTP servers for large organizations and public email services do have performance considerations so I would not totally dismiss this issue. There likely is some tolerance of delays bit not a lot.


Typical case for TLS client auth with SMTP is server to server submission not client submission. The majority of email servers have self signed certificates for SMTP. However where organizations want TLS auth to work for SMTP they use CA issued SSL like certificates for the email servers.  The main difference with pure SSL certificates is typically an SMTP server support multiple SMTP domain so has multiple domain names in the certificates.


TLS server auth is also different for client and server submission. Again, both would be more tolerant of some delays.


________________________________
From: Phillip Hallam-Baker <[e-mail]>
Sent: 26 February 2014 07:29
To: Ben Laurie
Cc: Trevor Freeman; [e-mail]; Paul Hoffman; Daniel Kahn Gillmor
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

On Wed, Feb 26, 2014 at 8:46 AM, Ben Laurie <[e-mail]<mailto:[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/