Re: [Trans] CT for opportunistic STARTTLS in SMTP
Ben Laurie <benl@google.com> Wed, 26 February 2014 13:46 UTC
Return-Path: <benl@google.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 E86B01A033F for <trans@ietfa.amsl.com>; Wed, 26 Feb 2014 05:46:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.326
X-Spam-Level:
X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_48=0.6, RP_MATCHES_RCVD=-0.547, 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 WNhujaaeIEcE for <trans@ietfa.amsl.com>; Wed, 26 Feb 2014 05:46:48 -0800 (PST)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6D32D1A035B for <trans@ietf.org>; Wed, 26 Feb 2014 05:46:43 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id lf12so931345vcb.17 for <trans@ietf.org>; Wed, 26 Feb 2014 05:46:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ItI8wsAgZgFrt7TfYuGO80wJ6q6c45i+KdIOYUpOsWQ=; b=C9gVHUksOHeRMqCcUuTIZ3TSj0/t3x9QdBkitNrcn53pSljbhgK7TzDIS73WohYKPR EsM4JsNEdy1krfzgTiqGDT0+7PzPk4MUpmTXFc2bJd9oz0edNULbpUaGhqreREOowfdv eU1aTzddD1l9iUVtNvjpdHfmvbmCuVEnoE6rFNZytOl9NWklNXLSBOYZV4U/spdI0tz0 qghimBx2oHosethSnmYxxE1wJ6u9obxR6rqWlshvn5Hd4RUFIyiCQTNVAkrXFnNaJZQU S68zDPnMhKGZ8EkAN4fhtKz9nrMLH79hZHQBqU+0gDHIGnIcBnUryB6cDdF/lItNVIIN h/Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ItI8wsAgZgFrt7TfYuGO80wJ6q6c45i+KdIOYUpOsWQ=; b=f5Q+y/a+2l+l1AP0OtpLvIaaksFa+29xiO7QcTRt07HNQi5flTmL6Dj1J9GPbA2CX2 aYWnIAVWLJNjbiGPRP3uJFsY0aXyc13LCm27adjqW2cQSdTbjYLY0JvjRxUijBv/zH04 gWjBWdnpa534Qrh5zjNsSj+TJJSxEYfhbWdDKPQzv/gOXSNrgiAK2wyT9E2p14pTGO06 Ry7RyV2K/AvWMxAqQqfwIAB0wn/ynnfZFDPYXit40RCWXPU166YthJ3E2z32ClSyVQmr eFTLrgQLmR0PpIV+c8qOu6IxTmYe8LlRpntcxHbLSgsFXr7CR+UkjdcHANvowqhGcYNY tdIA==
X-Gm-Message-State: ALoCoQm9dDmkngQVl7d5VEfaCHJ5ggziFqsWkFO7igvg+V6yv0PpwkhAem/+n2TU3FcIed6DTa7A3XeIKZ4vquQSaF/tpGjTqcy96RaXP/NT6fSz3ixPmgSgIiAb45Fq2nruk/BOYXnD60PFbaREIaGADJ4ukrZNw6gi/JZBcv/yKn73zfSVdKPwpw6WhQkQj7TZoNYXwhpb
MIME-Version: 1.0
X-Received: by 10.220.175.198 with SMTP id bb6mr990310vcb.31.1393422402024; Wed, 26 Feb 2014 05:46:42 -0800 (PST)
Received: by 10.52.230.105 with HTTP; Wed, 26 Feb 2014 05:46:41 -0800 (PST)
In-Reply-To: <CAMm+LwjEr5M14+Ycb1PRZa7Wb0hx=4EjC52PXxaN2p95aQuV4A@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> <CAMm+LwjEr5M14+Ycb1PRZa7Wb0hx=4EjC52PXxaN2p95aQuV4A@mail.gmail.com>
Date: Wed, 26 Feb 2014 13:46:41 +0000
Message-ID: <CABrd9SSJMPhYLGAMfrF_JVGz=2DsxpiDGO9T21QtMi+Owo_jfw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/gBwHUZyq83kiPZ3DPKNPaeCUtmA
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:46:51 -0000
On 26 February 2014 13:41, Phillip Hallam-Baker <hallam@gmail.com> wrote: > > > > 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. 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... > 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. > 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