Re: [perpass] SMTP and SRV records

[Derek Fawcus <[e-mail]>]

On Wed, Nov 25, 2015 at 11:19:52AM +0100, Brian Trammell wrote:
> > On 25 Nov 2015, at 08:11, Derek Fawcus <[e-mail]> 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.

DF