Re: [perpass] SMTP and SRV records

Eliot Lear <lear@cisco.com> Wed, 25 November 2015 12:05 UTC

Return-Path: <lear@cisco.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF151B2BF1 for <perpass@ietfa.amsl.com>; Wed, 25 Nov 2015 04:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.086
X-Spam-Level:
X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 qqCs-flNSn3l for <perpass@ietfa.amsl.com>; Wed, 25 Nov 2015 04:05:09 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286AA1B2BF0 for <perpass@ietf.org>; Wed, 25 Nov 2015 04:05:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2324; q=dns/txt; s=iport; t=1448453109; x=1449662709; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=dwNk+suQEiI0XbtDh+AHNlEezB/TjkQmXQsL2QM0qio=; b=av1md3T4an6L5p7dcHnom92tXQK5ccVQWa/zkfsVSphn4caGTu6F6meZ IIleU27HTAUM0T4ec4SGjZhLe8SjcZoIz/hrC5bThot0MHTPEgJwN1854 RXAHXHd26BhyIPEQcd86x9dkaZD0r+/Wl9Sj/hD0UKtdsfRnk/zM3ye4u w=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3BABIo1VW/xbLJq1ewSKED4M9glICgg8BAQEBAQGBC4Q1AQEDASNbCwsOEyECAg8CRgYBDAgBAYgiCK1HkDoBAQEBAQEBAwEBAQEBAQETCYtShCoRAYM5gUQFllWCWoFhiHeJH5M5Y4QFPYQfgUEBAQE
X-IronPort-AV: E=Sophos;i="5.20,342,1444694400"; d="asc'?scan'208";a="606754352"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Nov 2015 12:05:07 +0000
Received: from [10.61.212.99] ([10.61.212.99]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAPC57vS011167; Wed, 25 Nov 2015 12:05:07 GMT
To: Brian Trammell <ietf@trammell.ch>, perpass <perpass@ietf.org>
References: <20151124201103.GA9353@cowbell.employees.org> <5654D5AF.50700@cisco.com> <20151125071128.GA99066@cowbell.employees.org> <6FD77081-7C68-4266-9C26-3443C73F4EFA@trammell.ch> <20151125115248.GA75123@cowbell.employees.org>
From: Eliot Lear <lear@cisco.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5655A3F2.60900@cisco.com>
Date: Wed, 25 Nov 2015 13:05:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151125115248.GA75123@cowbell.employees.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="A1gSNtlkUGqtBnMicmM1hvePFGPcOsDPn"
Archived-At: <http://mailarchive.ietf.org/arch/msg/perpass/7hudnNRK8A6A8XBcrltWC5VIE4w>
Subject: Re: [perpass] SMTP and SRV records
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2015 12:05:10 -0000

Hi,

On 11/25/15 12:52 PM, Derek Fawcus wrote:

> Well,  one of the characteristics of the IPB is that it seems to require ISPs
> to maintain a database of all 'connections',  so assume of all TCP sessions,
> start/end times with src/dst addr+ports; and that TPTB can make a demand for a
> record matching a set of search keys (assume dst IP, port 25).
>
> So while the network level mechanisms may be able to monitor all traffic on the
> interface,  having port agility means that the request for a connection record
> potentially has to ask for all connections,  not just those to port 25,  and that
> the results are not necessarily immediately characterised as being email.

This smells a lot more like an attempt to inhibit lawful intercept than
it does to stop a bad guy spying on email.  I believe that is the wrong
goal.  Moreover, we have been pleading with SPs for DECADES to block
outbound port 25 in favor of 587 so that home systems do not relay email
directly.  With various BLs perhaps that advice is a little long in the
tooth, but bad guys don't need a lot of sites to fail to use BLs to get
stuff through.

Encryption combined with aggregating MSPs will obscure flows.  Small SPs
may be another matter.  Any evidence to the contrary that shows ability
to correlate messages in an encrypted environment would be welcome.

Eliot