Subject: [perpass] SMTP and SRV records

From: Derek Fawcus <[email-masked]>
Date: Tue, 24 Nov 2015 20:11:03 +0000

Given the current UK IPB bill,  I got pondering about SMTP again.

SMTP uses MX DNS records,  and so its always known to be on port 25,
would there be much value in moving to using SRV records,  such that
it could move off port 25,  making TPB's task a bit more difficult?

DF

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Nov 2015 22:25:03 +0100

Hi Derek,

What benefit would this add to the average user?

Eliot

On 11/24/15 9:11 PM, Derek Fawcus wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Nov 2015 22:23:44 +0000

> What benefit would this add to the average user?

It's the germ of an interesting idea.   The theory would be that a sniffer at the backbone would have to listen to all traffic, not just traffic on port 25.   However, it's not as good as SMTP+TLS, and has the same adoption problem, plus SMTP+TLS has a _big_ head start, so it's probably better to concentrate our efforts on making that work even better.

--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 24 Nov 2015 14:41:06 -0800

On Tue, Nov 24, 2015 at 2:23 PM, Ted Lemon <[email-masked]> wrote:

> It's the germ of an interesting idea.   The theory would be that a sniffer
> at the backbone would have to listen to all traffic, not just traffic on
> port 25.

​I don't think that's quite right.  A port-specific sniffer would have to
know what SMTP port was correct for a specific domain.  Depending on the
TTL of the record, that might turn into a table lookup for setting the
sniffers rather than listening to all traffic.

That said, I rather suspect that listening to all traffic is pretty much in
the program of most signals intelligence agencies anyway, because the
ephemeral ports can be be used by VoIP and other media traffic. DPI on that
would tell you which ones were SMTP and which others pretty rapidly.

 However, it's not as good as SMTP+TLS, and has the same adoption problem,
> plus SMTP+TLS has a _big_ head start, so it's probably better to
> concentrate our efforts on making that work even better.
>
>
​Yes, focusing on getting encryption underneath it seems like a better use
of energy; at most, port shifting is minor security through obscurity, and
that doesn't tend to give you a lot of bang for your buck.

Just my two cents,

Ted​

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Nov 2015 07:47:28 +0100

Yeah, this is what I would suggest as well, especially for SMTP.  There
are a host of operational problems with attempting to vary the port.

Eliot

On 11/24/15 11:41 PM, Ted Hardie wrote:
> On Tue, Nov 24, 2015 at 2:23 PM, Ted Lemon <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     It's the germ of an interesting idea.   The theory would be that a
>     sniffer at the backbone would have to listen to all traffic, not
>     just traffic on port 25. 
>
>
> ​I don't think that's quite right.  A port-specific sniffer would have
> to know what SMTP port was correct for a specific domain.  Depending
> on the TTL of the record, that might turn into a table lookup for
> setting the sniffers rather than listening to all traffic.
>
> That said, I rather suspect that listening to all traffic is pretty
> much in the program of most signals intelligence agencies anyway,
> because the ephemeral ports can be be used by VoIP and other media
> traffic. DPI on that would tell you which ones were SMTP and which
> others pretty rapidly.
>
>      However, it's not as good as SMTP+TLS, and has the same adoption
>     problem, plus SMTP+TLS has a _big_ head start, so it's probably
>     better to concentrate our efforts on making that work even better.
>
>
> ​ Yes, focusing on getting encryption underneath it seems like a
> better use of energy; at most, port shifting is minor security through
> obscurity, and that doesn't tend to give you a lot of bang for your buck.
>
> Just my two cents,
>
> Ted ​
>
>  
>
>
>     --
>     [email-masked] <mailto:[email-masked]>

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 25 Nov 2015 07:11:28 +0000

> What benefit would this add to the average user?

1. the snoopers have to potentially listen to all ports
2. it makes traffic analysis (for SMTP) more awkward to implement
3. doesn't require use of a certificate / encryption.

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

---

From: Brian Trammell <[email-masked]>
Date: Wed, 25 Nov 2015 11:19:52 +0100

> On 25 Nov 2015, at 08:11, Derek Fawcus <[email-masked]> wrote:
> 

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

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 25 Nov 2015 11:52:48 +0000

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

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Nov 2015 13:05:06 +0100

Hi,

> 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

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 25 Nov 2015 12:27:13 +0000

On Wed, Nov 25, 2015 at 01:05:06PM +0100, Eliot Lear wrote:
> it does to stop a bad guy spying on email.

Hardly,  they can still intercept it,  it would just be encrypted.
 
There are multiple levels of privacy:
 
1) A communicated with B,  but the nature of the comms is uncharacterised.
2) A communicated with B (using email)
3) A communicated with B, the email had contents X
 
Encryption should defeat 3,  leaving 1 & 2.
 
I'm suggesting a way to also defeat 2,  or at least make its recognition
more difficult.  None of these prevent 1.

This is an attempt to make bulk interception,  and its offline post facto
analysis more awkward.  It'll have no effect upon targetted inteception.
(since there one could see the DNS queries,  and know which were for SMTP).

But,  if there is not interest in this;  I guess I'll drop it.

DF

---

From: Robin Wilton <[email-masked]>
Date: Wed, 25 Nov 2015 13:28:03 +0000

Hi Derek -

Brief comment in-line...

> But,  if there is not interest in this;  I guess I'll drop it.

Whether or not this functionality ends up in an RFC or implemented, I think it is exactly this level of clarity over “levels of privacy” (and corresponding levels of protection vs levels of interception capability) that we need to be discussing as a community.

I’m sure I’m not the only one who has been depressed by a lot of the public discourse on this topic (present list definitely excepted!), and the lack of clarity/understanding demonstrated by much of it (this being a lamentable case in point: http://www.telegraph.co.uk/technology/12008689/Why-is-Silicon-Valley-helping-the-tech-savvy-jihadists.html ).

I think an important antidote to that is our own clarity about the protective mechanisms that can be applied at the various layers of the protocol stack, and the nature and extent of the protection they each provide.

This is entirely in line with my understanding of RFC7258.

> DF

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Nov 2015 13:56:29 +0000

subject line change...

On 25/11/15 13:28, Robin Wilton wrote:
> I’m sure I’m not the only one who has been depressed by a lot of the
> public discourse on this topic (present list definitely excepted!),
> and the lack of clarity/understanding demonstrated by much of it
> (this being a lamentable case in point:
> http://www.telegraph.co.uk/technology/12008689/Why-is-Silicon-Valley-helping-the-tech-savvy-jihadists.html
> ).

While I agree that that kind of article is a pain, it's entirely
predictable, partly understandable but IMO, as it's an attempt to
defy logic and what are basically laws of physics (crytpo is just
math in the end and the rest is a mere matter of programming), it
is also bound to fail, in most places and for most of the time.

We and others have written about why such ideas are wrong,
and will continue to do so, but I don't think we should worry
too much about every single flurry of articles like that. And
there will be such a flurry after every unfortunate or
deplorable incident, as that is also in the nature of things.

But, just to take one example, I'd bet the UK govt will wise up
somewhat when they finally get that they risk exporting their
financial services industry if they muck with crypto in the ways
that article would indicate. (I had a chat with some Irish
industrial dev. types, and that was the angle that most interested
them:-)

Cheers,
S.

PS: And anyway it's the telegraph - did we expect tech clue? :-)

---

From: Robin Wilton <[email-masked]>
Date: Wed, 25 Nov 2015 14:32:17 +0000

Robin Wilton

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

> deplorable incident, as that is also in the nature of things.

Absolutely; the focus shouldn’t be on countering clueless journalists so much as ensuring that we are clear about our terms, that our discussion and outputs reflect that clarity, and that we make it easier for more and more people (in diverse audiences) to understand the relevant nuances.
> industrial dev. types, and that was the angle that most interested

+1… but even the “economic policy” argument can get derailed (or at least lose force) if govt types don’t get, for instance, the difference between link and E2E encrypted comms.
> PS: And anyway it's the telegraph - did we expect tech clue? :-)

No. No we did not.  ;^\