Re: [perpass] SMTP and SRV records

[Brian Trammell <[e-mail]>]

> 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.

Cheers,

Brian

> So assume that tcpinc (or SMTP+TLS) gets wide deployment,
> that still leaves 1 & 2 above.
> 
> Maybe at the moment most users take advantage of an ISP's smart
> host,  and so there would seem to be little benefit wrt 2 above.
> 
> However one of the impacts of the IPB looks to be encouraging
> more people to run their own SMTP server,  or at least one with
> a restricted set of users,  when point 2 becomes more significant.
> 
> DF
> 
> _______________________________________________
> perpass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perpass