Re: [Trans] CT for opportunistic STARTTLS in SMTP

Phillip Hallam-Baker <> Wed, 26 February 2014 13:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C89801A02F5 for <>; Wed, 26 Feb 2014 05:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qMrGsDvvb2JQ for <>; Wed, 26 Feb 2014 05:41:47 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::230]) by (Postfix) with ESMTP id 8AD501A01E8 for <>; Wed, 26 Feb 2014 05:41:47 -0800 (PST)
Received: by with SMTP id gf5so625140lab.35 for <>; Wed, 26 Feb 2014 05:41:45 -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=0jFdeHrbh1Ot7yzPdGVcPXvpsrATOBo6m+W8lP3v+y0=; b=X/icqpZcEr7czbpzfRyZOgbBWK1/G7I7dfGZ/94ZM6b0w/xvzdRBXbf9fLlQ5Ja8ty rGFxBw/wY65xsfmVx+ob7FRCLq5jSDIUO40ycu0L0v+EQTm9hTjJvSnm39qsz0Vd9c2Z DFCoDXq9dmApg4RQoZbksPusVExX7bz9IEMwAFUD3kBnPNvXViOmjXAVLJH4BIPpeHWf B2MEZZT/k/2QOGp/4OSrG7CvVbFAruC6ZQqlA01P2jPxSBmIlVidMsz7UzSe0eXg3CVj l/4C2IWsrsDyrrDxX2yQH2fpmhUUMTHcb7yMYalbchG54HhANYdRODnTUuv+Pcf1l+pF KzoA==
MIME-Version: 1.0
X-Received: by with SMTP id q7mr86406lbk.82.1393422105634; Wed, 26 Feb 2014 05:41:45 -0800 (PST)
Received: by with HTTP; Wed, 26 Feb 2014 05:41:45 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 26 Feb 2014 08:41:45 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Ben Laurie <>
Content-Type: multipart/alternative; boundary="001a1134d7aea0f49804f34f5dd7"
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 13:41:50 -0000

On Wed, Feb 26, 2014 at 6:13 AM, Ben Laurie <> wrote:

> On 25 February 2014 22:13, Trevor Freeman
> <> 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. But that also means we
can't pass credentials in-band as in SSL.

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.