Re: [perpass] SMTP and SRV records

Derek Fawcus <> Wed, 25 November 2015 11:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ECE591B2BD2 for <>; Wed, 25 Nov 2015 03:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B5fRiPRVa4q7 for <>; Wed, 25 Nov 2015 03:52:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BC3F1B2BD1 for <>; Wed, 25 Nov 2015 03:52:49 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 98563D7883; Wed, 25 Nov 2015 03:52:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=Pl6FPREDMIVA0hSYCApY6MuexEQ=; b=bb X64Mx6AYFB5TSfyFkSnp6VJNnwpOpfHoAhjoksV0GOv8PcQy2MtLJ3ZiQN/owZgu cIJKx3BUSY5C4qLjuoWbGkOnzngQ8TiJ0hF+qGmrWMVcLmXmQb49eOiM2FZZWpU3 aeH3wmSF/cd2t0zGF+QANIFgHa+0MtA4sNCaYQRTk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=KHn/QJbcomcoMiR3sfqu8Gnig6Bj k9EDwaXGG+FTbkii3haL1xFcRiV9Xnd9lvAopFmcpAuPZ2OZ5ge1qFD8M8Fn/sDE gM1D87WYcVndn6ZmYV90TpM1dDx02X6lraeWmRwBaXSEBRCYX1gPzHlkQnT0Az0c aSMlqVQgIduoIk0=
Received: by (Postfix, from userid 1736) id 89CECD7882; Wed, 25 Nov 2015 03:52:48 -0800 (PST)
Date: Wed, 25 Nov 2015 11:52:48 +0000
From: Derek Fawcus <>
To: Brian Trammell <>
Message-ID: <>
Mail-Followup-To: Brian Trammell <>, perpass <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Cc: perpass <>
Subject: Re: [perpass] SMTP and SRV records
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Nov 2015 11:52:51 -0000

On Wed, Nov 25, 2015 at 11:19:52AM +0100, Brian Trammell wrote:
> > On 25 Nov 2015, at 08:11, Derek Fawcus <> wrote:
> > On Tue, Nov 24, 2015 at 10:25:03PM +0100, Eliot Lear wrote:
> >> Hi Derek,
> >> 
> >> What benefit would this add to the average user?
> > 
> > 1. the snoopers have to potentially listen to all ports
> This adds *zero* cost. The granularity of packet capture for most technologies I know of is interface-level. Ports don't exist here: you have to capture the packet to parse the transport header to know what the port is. Filtering on ports (e.g. with bpf) is a nice bit of syntactic sugar that allows you to have the kernel not bother you with ports you don't care about, but the work of parsing has to be done anyway.
> > 2. it makes traffic analysis (for SMTP) more awkward to implement
> You simply have to attempt to match SMTP over all the traffic as opposed to just that on port 25. This parallelizes *really* well, though, and I doubt this costs more than a few millipennies of AWS time per gigabit of traffic, because you can reject non-SMTP very early in the flow.
> > 3. doesn't require use of a certificate / encryption.
> Not necessarily a feature, but I do get that SRV record management is somewhat easier than cert management.
> Don't get me wrong, using SRV records for port agility is in general a good idea; MX is simply a pre-SRV hack and it would be cool to see it deprecated (sometime in the late 2030s, perhaps). But I don't know that I'd try to sell it as a privacy technique.

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.

I was assuming that this would usually be in addition to encryption,  not simply
a replacement for it,  as such DPI detection of SMTP on a different port
would not simply be trivial.

Or are you suggesting the inspector s/w can recognise it via the pattern of
encrypted packet exchanges?

The contents of the IPB seem to be about collecting information for fine grained
traffic analysis,  rather than content per-se (or at least that seems to be what
it purports to be about),  as such I was looking to make traffic analysis a bit
more difficult,  since encryption by itself doesn't prevent it.