Re: [Trans] CT for opportunistic STARTTLS in SMTP
Phillip Hallam-Baker <hallam@gmail.com> Wed, 26 February 2014 13:41 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89801A02F5 for <trans@ietfa.amsl.com>; Wed, 26 Feb 2014 05:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMrGsDvvb2JQ for <trans@ietfa.amsl.com>; Wed, 26 Feb 2014 05:41:47 -0800 (PST)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD501A01E8 for <trans@ietf.org>; Wed, 26 Feb 2014 05:41:47 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id gf5so625140lab.35 for <trans@ietf.org>; Wed, 26 Feb 2014 05:41:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.112.39.167 with SMTP id q7mr86406lbk.82.1393422105634; Wed, 26 Feb 2014 05:41:45 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Wed, 26 Feb 2014 05:41:45 -0800 (PST)
In-Reply-To: <CABrd9SSPjfFfO3LPX1PSeBTyL0gLxz0DPR7te06r3fVmzCD13w@mail.gmail.com>
References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <CAMm+LwjANZrgKXxRD-f4POdn7vz9_f1W2Mj8xTGEFVO9-3Unng@mail.gmail.com> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net> <CABrd9SQeReQ_LMFxYJhA2NBCPKCsUXiHjmaF5UgOUEvi-ZJovg@mail.gmail.com> <DEEC5007-F38F-4A20-ADA3-A612C31326C4@vpnc.org> <CABrd9ST9U_KK1bTGAGeUFyr8Gx7GWkau9HiPfcgyOwjnozXuFA@mail.gmail.com> <200B1469-C0AB-4560-B799-F09D4C7221EA@vpnc.org> <2c3b987f362f479fa0d437513b65efa5@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <CAMm+LwgicNZnYtphb5Kp=1bR8G8mMR=ZrVzAgB1DQGsYUPB7cw@mail.gmail.com> <4289ed5e74314d56ad59be2e92d0ccb3@DFM-TK5MBX15-07.exchange.corp.microsoft.com> <CABrd9SSPjfFfO3LPX1PSeBTyL0gLxz0DPR7te06r3fVmzCD13w@mail.gmail.com>
Date: Wed, 26 Feb 2014 08:41:45 -0500
Message-ID: <CAMm+LwjEr5M14+Ycb1PRZa7Wb0hx=4EjC52PXxaN2p95aQuV4A@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary="001a1134d7aea0f49804f34f5dd7"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/nl64bsnSV6LvKDrtrAV6iF5127Y
Cc: "trans@ietf.org" <trans@ietf.org>, Trevor Freeman <trevorf@exchange.microsoft.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 13:41:50 -0000
On Wed, Feb 26, 2014 at 6:13 AM, Ben Laurie <benl@google.com> wrote: > On 25 February 2014 22:13, Trevor Freeman > <trevorf@exchange.microsoft.com> 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. -- Website: http://hallambaker.com/
- [Trans] Draft agenda Melinda Shore
- Re: [Trans] Draft agenda Eran Messeri
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] Draft agenda Melinda Shore
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Melinda Shore
- Re: [Trans] Draft agenda Phillip Hallam-Baker
- Re: [Trans] Draft agenda Eran Messeri
- Re: [Trans] Draft agenda Daniel Kahn Gillmor
- Re: [Trans] Draft agenda Phillip Hallam-Baker
- Re: [Trans] Draft agenda Melinda Shore
- Re: [Trans] Draft agenda Daniel Kahn Gillmor
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] Draft agenda Phillip Hallam-Baker
- [Trans] CT for opportunistic STARTTLS in SMTP Paul Hoffman
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Ben Laurie
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Paul Hoffman
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Trevor Freeman
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Phillip Hallam-Baker
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Trevor Freeman
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Ben Laurie
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Rob Stradling
- [Trans] running code (was: Re: Draft agenda) Stephen Farrell
- Re: [Trans] Draft agenda Carl Wallace
- Re: [Trans] running code (was: Re: Draft agenda) Ben Laurie
- Re: [Trans] running code Stephen Farrell
- Re: [Trans] running code Ben Laurie
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] Draft agenda Carl Wallace
- Re: [Trans] Draft agenda Tomas Gustavsson
- Re: [Trans] running code Stephen Farrell
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Phillip Hallam-Baker
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] running code (was: Re: Draft agenda) Phillip Hallam-Baker
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Ben Laurie
- Re: [Trans] running code Ben Laurie
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Phillip Hallam-Baker
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Trevor Freeman