Re: [Trans] CT for opportunistic STARTTLS in SMTP

Phillip Hallam-Baker <hallam@gmail.com> Tue, 25 February 2014 21:48 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 8A6321A02CA for <trans@ietfa.amsl.com>; Tue, 25 Feb 2014 13:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 eJamTC4HLFyL for <trans@ietfa.amsl.com>; Tue, 25 Feb 2014 13:48:17 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 01F991A02A0 for <trans@ietf.org>; Tue, 25 Feb 2014 13:48:16 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id pv20so11959lab.30 for <trans@ietf.org>; Tue, 25 Feb 2014 13:48:15 -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=TqvrMmJByGK1xNpiKGzvuhJz/5+xPi24l8t4ee6ccTM=; b=csnPrcyxIOLF5yXgf4B2DJ+CIvWfyu4q/ViFIvOmaVqA8DYz2GixOaBrM9pH57xlIm 55GWC0BLEeOrgG9bIb0/3JFnwEcRifj6lm3N4s7cofk3JGaJiK6hT2BrK2BZf8YrKDZw 2Zi/eI2CHSOCfSVeIb/W7jDjgzZpp0My/VbeOKhZq8cNbx2re+EkMBYX4i2ylRoV2Hf5 5aXUbzPdQwQJs9T+I7MITNDHqJ3nfYMYsrXBC4P8+d4druPzbN4Eq1LclkPLuVoU7jes gdOaTzLBGA1bZuzlo5DJHS1CmdiusVMZdNmmUCZsJxS73z5JXVdEhjIn5JDkf7nqbJWq CcwQ==
MIME-Version: 1.0
X-Received: by 10.112.171.136 with SMTP id au8mr1138935lbc.0.1393364895384; Tue, 25 Feb 2014 13:48:15 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Tue, 25 Feb 2014 13:48:15 -0800 (PST)
In-Reply-To: <2c3b987f362f479fa0d437513b65efa5@DFM-TK5MBX15-05.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>
Date: Tue, 25 Feb 2014 16:48:15 -0500
Message-ID: <CAMm+LwgicNZnYtphb5Kp=1bR8G8mMR=ZrVzAgB1DQGsYUPB7cw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Trevor Freeman <trevorf@exchange.microsoft.com>
Content-Type: multipart/alternative; boundary="001a11c377a4a1c9fd04f3420b84"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/QdgFr4exE7fke4ogfP3hccbQAps
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 21:48:22 -0000

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> 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] On Behalf Of Paul Hoffman
> Sent: Tuesday, February 25, 2014 9:54 AM
> To: Ben Laurie
> Cc: 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> 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
> https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>



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