Re: [Trans] CT for opportunistic STARTTLS in SMTP

Trevor Freeman <trevorf@exchange.microsoft.com> Tue, 25 February 2014 22:13 UTC

Return-Path: <trevorf@exchange.microsoft.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 04DF91A0257 for <trans@ietfa.amsl.com>; Tue, 25 Feb 2014 14:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 o3Tz2YwAuTw2 for <trans@ietfa.amsl.com>; Tue, 25 Feb 2014 14:13:27 -0800 (PST)
Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) by ietfa.amsl.com (Postfix) with ESMTP id CDA9C1A0298 for <trans@ietf.org>; Tue, 25 Feb 2014 14:13:26 -0800 (PST)
Received: from BL2SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.109.147) by BL2SR01MB592.namsdf01.sdf.exchangelabs.com (10.255.109.163) with Microsoft SMTP Server (TLS) id 15.0.898.5; Tue, 25 Feb 2014 22:13:24 +0000
Received: from BY1FFOFD002.ffo.gbl (2a01:111:f400:7c00::90) by BL2SR01CA102.outlook.office365.com (2a01:111:e400:c01::19) with Microsoft SMTP Server (TLS) id 15.0.898.5 via Frontend Transport; Tue, 25 Feb 2014 22:13:24 +0000
Received: from hybrid.exchange.microsoft.com (131.107.147.100) by BY1FFOFD002.mail.o365filtering.com (10.1.16.84) with Microsoft SMTP Server (TLS) id 15.0.898.4 via Frontend Transport; Tue, 25 Feb 2014 22:13:23 +0000
Received: from DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Feb 2014 14:13:13 -0800
Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) by DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Feb 2014 14:13:13 -0800
Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com ([157.54.109.46]) by DFM-TK5MBX15-07.exchange.corp.microsoft.com ([169.254.7.103]) with mapi id 15.00.0847.030; Tue, 25 Feb 2014 14:13:13 -0800
From: Trevor Freeman <trevorf@exchange.microsoft.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Thread-Topic: [Trans] CT for opportunistic STARTTLS in SMTP
Thread-Index: AQHPMktUK1TcKUm7rUKelX8JKB3CNJrGwbEAgAAE1oD//5WxkIAAq+CA//99JXA=
Date: Tue, 25 Feb 2014 22:13:12 +0000
Message-ID: <4289ed5e74314d56ad59be2e92d0ccb3@DFM-TK5MBX15-07.exchange.corp.microsoft.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>
In-Reply-To: <CAMm+LwgicNZnYtphb5Kp=1bR8G8mMR=ZrVzAgB1DQGsYUPB7cw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.59.235.233]
Content-Type: multipart/alternative; boundary="_000_4289ed5e74314d56ad59be2e92d0ccb3DFMTK5MBX1507exchangeco_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.147.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(13464003)(51704005)(24454002)(377454003)(15404003)(199002)(189002)(512954002)(19580395003)(19580405001)(83072002)(79102001)(81342001)(81686001)(33646001)(93516002)(85852003)(15395725004)(90146001)(77096001)(15975445006)(77982001)(44976005)(81816001)(74706001)(56816005)(92566001)(76786001)(76796001)(74876001)(6806004)(54316002)(56776001)(15202345003)(81542001)(76482001)(59766001)(80976001)(74502001)(47446002)(74662001)(19300405004)(53806001)(54356001)(94946001)(93886001)(84676001)(31966008)(94316002)(2656002)(87936001)(20776003)(63696002)(71186001)(80022001)(87266001)(65816001)(84326002)(50986001)(93136001)(83322001)(49866001)(85306002)(47736001)(46102001)(16236675003)(95666003)(69226001)(1411001)(95416001)(47976001)(51856001)(66066001)(4396001)(74366001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB592; H:hybrid.exchange.microsoft.com; FPR:BCFCF1BC.AFE64CCA.6DEDB347.4AECF871.203D2; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Forefront-PRVS: 01334458E5
X-OriginatorOrg: exchange.microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/XyyfwPIAzz0c2qgFeN_9enmWocI
Cc: "trans@ietf.org" <trans@ietf.org>, Ben Laurie <benl@google.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: Tue, 25 Feb 2014 22:13:34 -0000

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?

Besides the whole STARTTLS negation is already subject to downgrade attacks. Some firewalls actively block the STARTTLS negotiation.

From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
Sent: Tuesday, February 25, 2014 1:48 PM
To: Trevor Freeman
Cc: Paul Hoffman; Ben Laurie; trans@ietf.org; Daniel Kahn Gillmor
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

The idea seems to be that there is an append only log server that clients are gong to be checking. So we can use that to stuff security policy information into the system.

The problem is that the client only checks the CT logs in the normal case after it has decided to use TLS.

So there is certainly a value in using an append only log to publish security policy data and in fact I do this in PPE. But it is only a solution to the downgrade attack problem with a lot of extra infrastructure. For example an Omnibroker scanning the CT log and using that to build the connection profile.




On Tue, Feb 25, 2014 at 2:47 PM, Trevor Freeman <trevorf@exchange.microsoft.com<mailto:trevorf@exchange.microsoft.com>> wrote:
I don't see the relevance of CT to opportunistic STARTTLS.

Opportunistic STARTTLS is a feature of the sender whereby the sender picks STARTTLS if offered, but otherwise will send the email.  If the alternative was send unprotected over plain TCP, you may as well negotiate TLS if offered.  Moreover, if TLS negotiation fails for whatever reason, the send remembers the fact and done not attempt to negotiate next time.

The sender does have a list of SMTP domains where it requires TLS authentication, but that is mandatory  STARTTLS.

-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org<mailto:trans-bounces@ietf.org>] On Behalf Of Paul Hoffman
Sent: Tuesday, February 25, 2014 9:54 AM
To: Ben Laurie
Cc: trans@ietf.org<mailto:trans@ietf.org>; Daniel Kahn Gillmor
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

On Feb 25, 2014, at 9:36 AM, Ben Laurie <benl@google.com<mailto:benl@google.com>> wrote:

>> 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.
>
> That does not seem effective to me.

It is more effective than doing nothing; it may not be effective enough to prevent overwhelm by spam. I was just pointing it out as something that was proposed, not well-thought-out.

--Paul Hoffman
_______________________________________________
Trans mailing list
Trans@ietf.org<mailto:Trans@ietf.org>
https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
Trans@ietf.org<mailto:Trans@ietf.org>
https://www.ietf.org/mailman/listinfo/trans



--
Website: http://hallambaker.com/