[Trans] CT for opportunistic STARTTLS in SMTP
Paul Hoffman <paul.hoffman@vpnc.org> Tue, 25 February 2014 17:02 UTC
Return-Path: <paul.hoffman@vpnc.org>
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 F0B0B1A016C for <trans@ietfa.amsl.com>; Tue, 25 Feb 2014 09:02:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.152
X-Spam-Level: *
X-Spam-Status: No, score=1.152 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_48=0.6] 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 FYNOTBE6SeAu for <trans@ietfa.amsl.com>; Tue, 25 Feb 2014 09:02:02 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C71C31A00EA for <trans@ietf.org>; Tue, 25 Feb 2014 09:02:02 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1PH1uQd083767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 10:01:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CABrd9SQeReQ_LMFxYJhA2NBCPKCsUXiHjmaF5UgOUEvi-ZJovg@mail.gmail.com>
Date: Tue, 25 Feb 2014 09:01:56 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEEC5007-F38F-4A20-ADA3-A612C31326C4@vpnc.org>
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>
To: Ben Laurie <benl@google.com>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ISeKvWU0PWy33Z2-hdB0XXJAxKI
Cc: "trans@ietf.org" <trans@ietf.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: [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: Tue, 25 Feb 2014 17:02:04 -0000
Sorry for using a valid subject line. :-) On Feb 24, 2014, at 11:28 PM, Ben Laurie <benl@google.com> wrote: > On 24 February 2014 21:43, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: >> On 02/24/2014 04:25 PM, Melinda Shore wrote: >> >>> As for relevance, right now therightkey is the best place >>> for discussion of other approaches to fixing PKI, while trans >>> is specifically for discussion of certificate transparency. >>> The only thing that's in our charter at the moment is 6962bis. >>> That doesn't mean that other applications of CT are out-of- >>> scope, but that we'd need to recharter to take them on >>> as work items. >> >> I think you're saying you want the slot in London to focus on getting >> the mechanism right, and not trying to propose policy, which is >> completely reasonable. I'm happy to stay focused. >> >> There's nothing in RFC 6962 (and i hope there won't be in 6962bis) that >> is HTTPS-specific, though; it's defined as a mechanism for logging X.509 >> certificates for use in TLS, regardless of the application layer traffic >> within the TLS session. >> >> So i hope that the use of CT in SMTP+STARTTLS isn't seen as an "other >> application" -- it's still TLS. If we suspect that CT is somehow valid >> only for X.509 certs used by HTTPS servers, we should make that more >> explicit in the draft (but i hope we don't!) > > I agree. One observation: CT as applied to HTTPS uses the CA signature > as a spam limitation mechanism. > > I believe most SMTP certs are not CA issued, so the question arises: > how would you propose to limit spam? At the earlier CT meeting, I think someone proposed that there could be a check that the cert was in actual use at the place it said it was. > I am open, by the way, to running CT logs at Google with alternate > spam limitation mechanisms to allow this kind of usage. I think that > not having a spam limitation mechanism is dangerous. Spam limitation is needed for both attacks on CT to weaken it and accidental misconfiguration that could look a lot like an attack. --Paul Hoffman
- [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