Re: [Trans] CT for opportunistic STARTTLS in SMTP

Phillip Hallam-Baker <> Wed, 26 February 2014 15:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C83FB1A068B for <>; Wed, 26 Feb 2014 07:29:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LnVwcPbo93n5 for <>; Wed, 26 Feb 2014 07:29:07 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::236]) by (Postfix) with ESMTP id CC06F1A010C for <>; Wed, 26 Feb 2014 07:29:06 -0800 (PST)
Received: by with SMTP id n15so723874lbi.41 for <>; Wed, 26 Feb 2014 07:29:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O8UrHvcuGKNmoxyYLWc7jtLJJ6uE1vctbh60N2/kYBI=; b=WNBXb144vL0XlHpUIKrhFoCDUr7BKKJbaaV4oH6WGb9Lz/flmfRmINBjCFsSXYJn1u fii/ACKZZbWObEaaAnejEC8/FCubJLi6cV5W/RqreUsl5fdcKdcouP6j0gGwUZm017DW OFiHCo8K/BN2yg5kthsWw/AdmwGkSwHx+rHKCW/6Lpvtrolu1t/QQMlpME45dMjwLbqY 1WBocmY0ynlvBH/NOjvm0ratBa26qwLfy8DD3MNPEQ+GuGh5H5IUgEA/7W11w0V5oTCp CresHL+3gPFMX8CuFlXD6B0tIRvIg8CrdYyEyYSyDPn+yuM4VSjcY/1O4C8BhpDhDNUB OVEA==
MIME-Version: 1.0
X-Received: by with SMTP id qt9mr2708097lbb.34.1393428544891; Wed, 26 Feb 2014 07:29:04 -0800 (PST)
Received: by with HTTP; Wed, 26 Feb 2014 07:29:04 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 26 Feb 2014 10:29:04 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Ben Laurie <>
Content-Type: multipart/alternative; boundary="089e012297107031f904f350ddd9"
Cc: "" <>, Trevor Freeman <>, Paul Hoffman <>, Daniel Kahn Gillmor <>
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2014 15:29:11 -0000

On Wed, Feb 26, 2014 at 8:46 AM, Ben Laurie <> 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.