Subject: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG

From: SM <[email-masked]>
Date: Sat, 05 Dec 2015 21:24:50 -0800

Hello,

I took a look at the proposed charter [1].  The proposed work looks 
like a Received header field shutup.  Is that based on RFC 7624?  The 
discussion in that RFC, specifically Section 3.3.4, focuses on IP 
addresses.  The proposed charter mentions leaking address and timing 
information.  Is that IP addresses?

   "Header fields in Email messages can reveal private information to an
   observer that might be used for attacking an organization or an"

An attack on organization is a security issue; it isn't a privacy 
issue.  The privacy issue is about mail-related metadata which can be 
collected by state surveillance agencies.  Will the proposed working 
group attempt to fix that?

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/shutup/current/msg00001.html

---

From: Chris Lewis <[email-masked]>
Date: Sun, 6 Dec 2015 01:34:53 -0500

> group attempt to fix that?

Privacy is only about state surveillance?  That seems to be a, um, 
remarkably narrow definition, and completely ignores the privacy issues 
that people usually get harmed by.  Furthermore, state surveillance 
doesn't need to scrape headers, they just get the providers to reveal 
the contents of their logs, which no amount of header obfuscation can hide.

The NSA didn't get their 5 years worth of universal phone penlogs from 
tapping wires, they did it with taps right into the provider's 
equipment.  No amount of on-the-wire fussing would have done a thing.

This harks back to a big investigation I was involved with in the late 
1970's/early 80's[*], prompted by a huge public uproar over (supposed) 
LE access to medical information from Canada's (Ontario's) health 
insurance programme (and later spread to Workman's Compensation).

Our investigation showed that there were indeed a few (on the order of 
a dozen or two) LE-related incidents, and as far as I remember, not one 
of them involved medical information (they were current address searches 
in order to serve warrants).  The real problem was 3rd party private 
insurers accessing full medical information of thousands of people (we 
proved out more than 5000 incidents with one insurer alone) that could 
result in severe financial or in some cases medical harm.  At least one 
suicide resulted, probably more.  Oh, and yes, some of the access claims 
were entirely bogus (eg: claims of accessing information that didn't and 
couldn't exist) - made up by people who were happy to lie to the 
journalists and get their own tiny bits of fame and a few beers.

The biggest fault with the charter that there is no mandate whatsoever 
to explore/mention/define the risks (of either revealing the information 
or omitting it).

I can see a BCP on privacy protection arising out of this effort, but 
without any serious attempt to give the reader guidance on pro/con, 
it'll do more harm than good.

[*] The Royal Commission of Enquiry into the Confidentiality of Health 
Records in Ontario.  I was the computer security consultant/advisor ro 
the commission.  The first "Krevor Commission".  Most Canadians will 
associate Justice Krevor (Ontario Supreme Court Judge) with the tainted 
blood Commission years later.

We plugged quite a few policy/procedural holes, the Ministry of Health 
got bruised and battered by it, but survived.  A lot of really good 
things happened from that Commission and carried over to other 
jurisdictions and even other countries, I'm quite proud of my minor 
contributions.

---

From: Chris Lewis <[email-masked]>
Date: Sun, 6 Dec 2015 01:40:22 -0500

Repeating a point that may have gotten lost in my previous posting.

As I see it, the fatal fault in the proposed charter is NO mention 
whatsoever of exploring/documenting the risks of eliding/not-eliding 
such information.  Whatever document that comes out of this effort has 
to give the reader reasonable guidance of what the risks are, both from 
providing the "privacy-dangerous" information, and not providing it.

Without it, a provider would not be able to make a reasonable judgment 
whether they should implement some/all of the recommendations or not.

---

From: Ned Freed <[email-masked]>
Date: Sat, 05 Dec 2015 22:52:17 -0800 (PST)

> group attempt to fix that?

As I pointed out on the perpass list when the Received: field draft was first
posted, there are definitely privacy issues associated with Received: fields, 
but metadata collection by state actors really isn't one of them. Why bother
with Received: fields when you can simply collect transaction logs from
ISPs/MSPs.

And unless I'm missing something, the generation and collection of
transaction logs is far beyond the purview of the IETF.

				Ned

---

From: SM <[email-masked]>
Date: Sat, 05 Dec 2015 23:48:52 -0800

Hello,
At 22:34 05-12-2015, Chris Lewis wrote:
>remarkably narrow definition, and completely ignores the privacy 
>issues that people usually get harmed by.  Furthermore, state 
>surveillance doesn't need to scrape headers, they just get the 
>providers to reveal the contents of their logs, which no amount of 
>header obfuscation can hide.

It is indeed a narrow definition.  I am limiting my discussion of the 
proposed charter to what has previously been discussed on the perpass 
mailing list [1] and on this mailing list.  It is up to the 
participant working for provider which was asked to reveal the 
contents of its logs to argue for including that aspect in the 
proposed charter if the participant wishes to do so.

>The NSA didn't get their 5 years worth of universal phone penlogs 
>from tapping wires, they did it with taps right into the provider's 

That is not mentioned in RFC 7258.

>The biggest fault with the charter that there is no mandate 
>whatsoever to explore/mention/define the risks (of either revealing 
>the information or omitting it).
>
>I can see a BCP on privacy protection arising out of this effort, 
>but without any serious attempt to give the reader guidance on 
>pro/con, it'll do more harm than good.

I am still trying to understand the problem(s) which the proposed 
working group might work on.  I am unable to say anything useful 
about the above at the moment.

Regards,
-sm

1. https://www.ietf.org/mail-archive/web/perpass/current/maillist.html

---

From: Chris Lewis <[email-masked]>
Date: Sun, 6 Dec 2015 03:26:49 -0500

On 12/06/2015 02:48 AM, SM wrote:
> mailing list [1] and on this mailing list.  It is up to the participant
> working for provider which was asked to reveal the contents of its logs
> to argue for including that aspect in the proposed charter if the
> participant wishes to do so.
>

I don't see how that matters.

Also, as others have remarked, legal/regulatory log access is 
out-of-scope for the IETF (a legal/regulatory issue not a technical 
one), so how could RFC7258 mention it?  Out of scope is out of scope, 
whether the provider wants to include it or not.

I'll also note that the second page of RFC7258 specifically states:

"The motivation for PM can range from non-targeted nation-state
surveillance, to legal but privacy-unfriendly purposes by commercial
enterprises, to illegal actions by criminals."

IOW: if this is about pervasive monitoring (perpass), you can't leave 
out 2/3rds of the actors (and far more than 2/3rds of the demonstrated 
risk) and expect to have any useful validity.

By limiting us to the actors who don't care about headers, knowing you 
can't include log access in whether you want to or not, this WG is 
completely without a purpose.  Or was that your point? ;-)

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 6 Dec 2015 09:37:14 -0800

> with Received: fields when you can simply collect transaction logs from

Ned, you are basically saying, "why bother plugging one leak when the same
data can leak somewhere else." Well, I think it is actually important to
plug all the privacy leaks, much like in security it is important to plug
all the holes.

You are making the argument that authorities can commandeer data by imposing
on mail providers. They can, but in countries with decent rule of laws there
are limits, such as requesting probable cause and not going through fishing
expeditions. We have seen rogue agencies attempt to bypass these limits by
just taking the data whichever way they can, and we want to stop that. We
also worry that what these agencies can do today, organized gangs can do
tomorrow, and petty criminals after that.

The email traces are particular because they are carried to multiple places,
not just the submission site but also every relay and every mail recipient.
That multiplies the chances of compromise. My email provider has some reason
to try maintain my trust, but relays and recipients may not. For me, it
makes a great deal of difference whether the information can be obtained
from just one place or from many.

As I wrote in a previous message, we have a specific problem with the
correlation between IP address and user identity. Once that correlation is
established, it becomes possible to attribute 5-tuple traces to specific
individuals. You may think that the relation between someone's home IP
address and their identity is static, but in many case it is not. Some ISP
can provide you with addresses that deliberately vary over time. You can use
VPN. You can use Wi-Fi hot spots. That's exactly what privacy conscious
users do. And that's why I find the listing of submission IP in traces
problematic.

I understand that there are good use of the information, and that managing
email systems is hard. I also understand that the problem is complex. For
example, precise timestamp information can be used for debugging and
validation. But it can also be used to retrieve the IP address of a message
sender, by looking in the 5 tuple traces what addresses were sending packets
to the email provider at that time. We need to surface these issues, to
understand both the cost of the value of the information, and to propose
solutions.

-- Christian Huitema

> _______________________________________________
> Shutup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shutup

---

From: SM <[email-masked]>
Date: Sun, 06 Dec 2015 05:23:48 -0800

Hello,
At 00:26 06-12-2015, Chris Lewis wrote:
>one), so how could RFC7258 mention it?  Out of scope is out of 
>scope, whether the provider wants to include it or not.

The topic of pervasive surveillance did not gather much interest 
prior to a few months before RFC 7258 was published.

>enterprises, to illegal actions by criminals."

Ok.

>IOW: if this is about pervasive monitoring (perpass), you can't 
>leave out 2/3rds of the actors (and far more than 2/3rds of the 
>demonstrated risk) and expect to have any useful validity.
>
>By limiting us to the actors who don't care about headers, knowing 
>you can't include log access in whether you want to or not, this WG 
>is completely without a purpose.  Or was that your point? ;-)

The proposed charter does not mention mail logs.  I mentioned 
pervasive monitoring as there were news articles about email metadata 
being captured.  Looking at this in terms of the text in the proposed 
charter, it is about what is in the mail headers being transmitted 
during a SMTP session.  The comment [1] which I sent was about 
that.  I am was not limiting that to one or more entities who might 
be able to collect that information on an international scale or an 
entity which could collect that on a national scale.

I was not trying to make a point about the proposed working group 
being completely without purpose if log access was out of 
scope.  There were three questions in my initial email to this 
mailing list.  Ned provided some input about the Received header 
field question [2].  I read his comments about the draft which is 
mentioned in the proposed charter; the comments were informative.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/shutup/current/msg00146.html
2. http://www.ietf.org/mail-archive/web/shutup/current/msg00149.html

---

From: Chris Lewis <[email-masked]>
Date: Sun, 6 Dec 2015 14:59:54 -0500

> plug all the privacy leaks, much like in security it is important to plug

This came out of a thread started on the supposition that this effort 
was only aimed at pervasive monitoring by state actors and that all 
other aspects were out of scope as per RFC7358, including whether it was 
a good idea or not.

1) You can't fight state actors with protocol tweaks.  If a state is 
interested in these headers, they simply have to order providers to 
ignore anything we do.  They already have.

2) State actors have a much easier time of doing this at the network 
level than email headers.  The great firewall of china and the big red 
"disconnect" switch makes such measures as proposed irrelevant.

3) At best this effort becomes a game of whack a mole, where the mole 
gets to scurry around unmolested while "we" take 5 years or more to 
swing the bat each time.

4) I agree that making general improvements to privacy is generally a 
good thing.  But it cannot be if we artificially limit the discussion to 
areas where anything we could do hardly matters in the first place. 
Secondly, the results can be catastrophic failures if we refuse to 
acknowledge the drawbacks in other areas (operational problems, suicide 
prevention, handling of threats of violence, harrassment, or anti-fraud, 
anti-privacy violation efforts).

This work cannot be done in isolation.

> just taking the data whichever way they can, and we want to stop that.

Yet, the best/most famous example we have to date is that of a country 
with decent rules of law, it was explicitly made legal, and that 
suppression of the source "address" equivalent (eg: callerid) wouldn't 
have made the slightest bit of difference.  Nor would it with the great 
firewall.

I contend that relying on, say, a handful of illicit wire connects, 
sporadic access to relay logs, and/or "informer" recipients, is by its 
very definition not "pervasive monitoring", and is thus also 
out-of-scope by the article that began this thread.

For our effort to be useful, the scoping has to be wider, as does the 
considerations of the downsides to doing it.

I shall relate a highly relevant real-world experience: As part of the 
privacy investigation I mentioned in another posting, we were tasked at 
trying to track down a rather prolific sexual harrassment caller who 
seemed to have a surprisingly high level of intimate and accurate 
health/medical detail about the victims.

Over the span of the investigation, we verified more than 1500 (yes, 
1500!) of these calls by one guy, to as many separate individuals (well, 
subtract one, one woman was savvy enough to trick the guy into phoning 
again and taped the conversation).  1500 calls - one guy.  The 
consequences of some of these calls were pretty damaging to the women 
and their families - some were quite traumatised.

[The calls usually started out with the perp identifing themselves as a 
doctor asked to follow up on some sort of gynecological "issue" revealed 
by a recent test/procedure, scaring the women into believing that 
something was seriously wrong, and then getting their jollies by asking 
intimate questions about sexual practises and progressing to worse 
things.  Very very nasty.]

This was before callerid.

I was in the interview where we solidly identified who it was doing it 
(after brainstorming between me, other members of the commission, and 
the LE tasked with running/supervising the effort) and asking a small 
group of female workers in the "common factor" office to see if they 
could identify the voice on tape.

[I was and am still impressed by the sensitivity shown by the senior 
Detective Sergeant of the OPP who led that interview.  The officer asked 
me to be there to act as a technical bridge between him and the office 
staff, and otherwise shut up and be a sympathetic listener.]

It turned out to be a rogue insurance company employee inside a secured 
processing area harvesting the "to be shredded and incinerated" bins. 
Nailed the SOB and the calls ended.  Callerid would have made it so much 
easier.

I was never so glad as to see something as the wide-scale deployment of 
callerid a few years later.  The same (occasionally strident and 
emotional) privacy arguments we hear now about MSA submission addresses 
were made then.  Accommodations were made (facilities at threat, per-use 
suppression etc), and how many privacy advocates are tilting at callerid 
these days?  Approximately zero.  We already have the equivalent 
accommodations (tor, anon remailers, etc. etc. etc) that callerid 
developed!

Harrassment calls almost completely vanished country-wide despite the 
fact that you could opt-out of callerid.  Unfortunately, I fully expect 
them to have been on the rise again with the wide-spread spoofing of 
callerid that VOIP et. al. makes possible.  Certainly phone spammers are 
doing it already.

Be careful what you ask for, you might get it.

---

From: Martijn Grooten <[email-masked]>
Date: Sun, 6 Dec 2015 21:10:39 +0000

On Sun, Dec 06, 2015 at 02:59:54PM -0500, Chris Lewis wrote:
> I was never so glad as to see something as the wide-scale deployment
> of callerid a few years later.

But for Caller ID to work in cases like the one you describe, you
wouldn't need to know the phone number (which often includes the
location) of the caller; a "cryptographic blob" identifying their phone
line would suffice.

I am not a lawyer, but I believe IP addresses are considered personal
data in some countries; the European Court of Justice is currently
looking into the issue. I don't think it's impossible for a court to
decide that because of this, providers should strip (submission) IP
addresses from emails.

Or perhaps one of the many tracking companies is already using this to
correlate emails sent to website visits. This could lead to outrage
among privacy activists and a call for providers to strip submission IP
addresses.

Hence I believe it is worth seeing if we can come up with guidelines on
what information can be removed/redacted/cryptographically blobbed in
email headers, so that senders' privacy is improved, yet the ability to
block and fight abuse isn't significantly harmed.

I do think the proposed charter is a bit too strong on the need to
remove headers which, given comments here, probably isn't very helpful.
I would be in favour of a more open-minded charter, but I do think there
is a need for a WG like this one.

Martijn.

---

From: Chris Lewis <[email-masked]>
Date: Sun, 6 Dec 2015 19:15:29 -0500

> location) of the caller; a "cryptographic blob" identifying their phone

The proper analog is "Call Trace".  You dial a * code, and the calling 
number gets recorded by the telco, but it can only be retrieved via a LE 
process (I do not believe it requires a full search warrant, but, 
joe-blow citizen certainly can't get it).  It cannot be disabled (but 
presumably spoofable) by the caller.

> decide that because of this, providers should strip (submission) IP

Anything's possible.  What's also possible that when presented in its 
entirety, a court may still agree that the operational/other benefits of 
providing them in this case outweighs the potential risk.  Nothing is an 
absolute.  There are always edge cases where informed judgment is 
required, and you rely on courts and judges to provide guidance through 
precedent.

What I also know is that when asked, regulators over here in PIPEDA land 
are most emphatic in saying that IP addresses are not PII.  And this 
_includes_ the Privacy Commissioner.

> among privacy activists and a call for providers to strip submission IP

That's in part why we have governments - to prevent public panics of the 
uninformed driving public policy.

We had one when callerid happened.  Callerid got "fixed" not killed.

We had one when the newspaper stories about the leaks (that ultimately 
led to the Commission I was a member of).  They were (mostly) bogus. 
But we fixed the problems that were really there and weren't in the 
newspaper stories.

We have a panic _now_.  How would you feel about security/privacy policy 
being driven by Trump and his followers?  If that doesn't scare you, it 
should.

What would really be fascinating is to get one or more people highly 
respected in their knowledge of the law, public policy and privacy to 
take on the question of passing through SUBMIT addresses.  Bring out all 
the pros and cons.  Put it on trial as it were.

> is a need for a WG like this one.

I agree, but the WG charter is too strong on the mechanics of "how" and 
has nothing at all on the mechanics of "will it do anything?" and the 
real downsides.  The charter needs to be expanded, and the WG work begun.

Perhaps one of the most important things in the WG is to decide whether 
the output is a document, and whether the document is an informational, 
a BCP or standard or STD.  My current thinking is that we're going to 
hit BCP at best.

An alternate approach occured to me - rather than trying to defacto 
impose it everywhere (which is sorta what the existing documentation is 
pushing towards), what about some sort of informational/BCP or even full 
RFC defining a "privacy enhanced interface" and outline what it needs to 
do w.r.t. email, and other service privacy?  Existing environments could 
make it an option, makes an opportunity for niche providers, and 
describes in concrete terms what it needs to do?

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2015 02:34:26 -0000

>a BCP or standard or STD.  My current thinking is that we're going to 

This is increasingly looking like a RG, not a WG.  There's a lot of
speculation about what aspects of mail messages and SMTP sessions have
what privacy implications, with an extremely premature focus on IP
address logging.  I'd much rather back up a step or two and see if we
can catalog the aspects of mail messages with estimates of the privacy
benefits and risks of each, keeping in mind the context.  

For example, how much new information is there in the date stamp in a
Received header in the usual case that it's a few seconds after the
timestamp in the Date: header?  On the other hand, most Received
headers have a unique ID that's really handy to identify the message
and the path it took (That's how you tell who's sending spam reports
from AOL and Yahoo, even though they redact all the addresses.)

That would be a useful catalog, and we can think about models that
look at the net personal information, and diagnostic and anti-abuse
information provided by various combinations of features or the lack
thereof.  That would be interesting on its own, and would give us a
much better foundation from which to consider changes that could
produce an actual overall privacy improvement.

R's,
John

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Sun, 6 Dec 2015 21:54:06 -0500

At 19:15 -0500 on 12/06/2015, Chris Lewis wrote about Re: [Shutup] 
Proposed Charter for the "SMTP Headers Unhealt:

>The proper analog is "Call Trace".  You dial a * code, and the 
>calling number gets recorded by the telco, but it can only be 
>retrieved via a LE process (I do not believe it requires a full 
>search warrant, but, joe-blow citizen certainly can't get it).  It 
>cannot be disabled (but presumably spoofable) by the caller.

The *-code you are referencing is *57 (1157 from a dial phone) and 
records the ANI (Call Setup and Routing) information not the 
spoof-capable CALLERID information. I think about am not sure that 
the information is accurate and can not be spoofed/faked. Note that 
the called party must use the code before another call comes in and 
the TelCo charges you when you use it.

Here is a Wikipedia article on the code/feature. 
https://en.wikipedia.org/wiki/Malicious_caller_identification

---

From: Ted Lemon <[email-masked]>
Date: Mon, 07 Dec 2015 03:44:04 +0000

> from AOL and Yahoo, even though they redact all the addresses.)

Bear in mind that the date header field isn't modified in transit, so it can in principle be in the encrypted blob, and not in the postcard headers.

> produce an actual overall privacy improvement.

Agreed, but I don't see why you think this is an RG and not a WG.

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

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Dec 2015 20:35:13 -0800

> Agreed, but I don't see why you think this is an RG and not a WG.

Please re-read his note and one or another of my earlier notes.  They
explain why.

At the moment, proposals for taking specific actions represent a random
walk down a large and complex set of possibilities, with no serious
analysis of benefits, risks, likelihoods or anything other than intuition.

Before modifying infrastructure operations of a critical Internet
resource, perhaps we should develop some credible basis for taking any
specific action?

Individuals are free to take whatever random path strikes their whimsy.
 Standards groups should have rather more basis for moving the whole
ship in a particular direction.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Martijn Grooten <[email-masked]>
Date: Mon, 7 Dec 2015 07:44:14 +0000

> benefits and risks of each, keeping in mind the context.  

I would be in favour of such a RG.

Martijn.

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Dec 2015 02:31:28 -0500

--On Monday, December 07, 2015 02:34 +0000 John Levine
<[email-masked]> wrote:

>...
> This is increasingly looking like a RG, not a WG.  There's a
> lot of speculation about what aspects of mail messages and
> SMTP sessions have what privacy implications, with an
> extremely premature focus on IP address logging.  I'd much
> rather back up a step or two and see if we can catalog the
> aspects of mail messages with estimates of the privacy
> For example, how much new information is there in the date
> stamp in a Received header in the usual case that it's a few
> seconds after the timestamp in the Date: header?  On the other
> hand, most Received headers have a unique ID that's really
> handy to identify the message and the path it took (That's how
> you tell who's sending spam reports from AOL and Yahoo, even
> though they redact all the addresses.)
> 
> That would be a useful catalog, and we can think about models
> that look at the net personal information, and diagnostic and
> anti-abuse information provided by various combinations of
> features or the lack thereof.  That would be interesting on
> its own, and would give us a much better foundation from which
> to consider changes that could produce an actual overall
> privacy improvement.

This strikes me as a really good idea.  This is probably what
John has in mind but, to be explicit, if it could also catalog
(not just allow "thinking about"), for each item, the
substantive uses to which any relevant aspect or datum is being
legitimately put today, differentiating things that are
specifically anti-spam from anti-phishing and mitigation of
malware and other types of attacks, that would be even better.
As many people have suggested in the previous threads, "more
privacy", whether about location or other information, is not
free but involves tradeoffs with other priorities and it is
important to consider the tradeoffs and balance.   

For me at least, Dave Crocker's subsequent comments reinforce
that view.

     john

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 10:50:42 +0000

On 07/12/15 02:34, John Levine wrote:
> This is increasingly looking like a RG, not a WG.

Hmm, not sure. A good RG is one that'd attract an active
research community and be relatively long lived whereas
this seems like a bit of work where we need to do a relatively
small and discrete amount of research on one topic. (Which
is roughly "What'd happen if you mucked with received headers
the MSA passes on to the rest of the mail infrastructure?")

The way I think of it is a good RG would produce a stream
of academic publications and then some stuff that'd be of
use to the IETF. This sounds more like one paper's worth
of research then stuff would be done in the IETF or not,
depending on the findings.

So I don't think an RG would be a good plan and a WG
can be chartered to investigate things before proposing
things.

But if folks think an RG is better, the first step would be
to talk to Lars about it.

S.

---

From: Ned Freed <[email-masked]>
Date: Sun, 06 Dec 2015 11:31:44 -0800 (PST)

> data can leak somewhere else."

Stop. Right. There. In the text you quoted, I said, "there are definitely
privacy issues associated with Received: fields". That in no way, shape, or
form equates to my saying that Received: fields are not worth worrying about.
In fact in this message:

   http://mailarchive.ietf.org/arch/msg/perpass/olIpnc_N1Vu46k0X_Rc74XMlYZE

I said:

  ... there is a real privacy gain in not including [IP addresses]
  in messages. State actors with subpeona powers may have easy access to ISP/MSP
  logs, but other players, including legitimate message recipients, do not. And
  my location at the time I send a piece of mail really isn't the concern of any
  of the message's recipients unless I choose to reveal it.

That's almost the exact opposite of the position you claim I held.

You really need to start reading what people are actually saying.

> Well, I think it is actually important to

And if that was the only factor in play it would be a no-brainer to simply
remove the IP addresses. But it isn't the only factor.

> on mail providers.

That's a statement of fact, not an argument.

> They can, but in countries with decent rule of laws there

The claim has been made - and still is made in the draft under consideration - 
that IP addresses in  Received: field are of significant value to state actors
and should be removed for that reason alone. But that claims fails because
state actors have the ability to get a better version of that information from
transaction logs.

Unless you can demonstrate that state actors have an easier time going after
message content - and that's demonstratably false in the United States and
probably most of other jurisdictions - the specifics of what restrictions apply
to state actors overall are entirely irrelevant.

And once again, this does *not* constitute an argument that there aren't
*other* privacy implications for IP addresses in Received: fields that are
worth considering. It's an argument against a specific claim that has been and
continues to be made.

> from just one place or from many.

Yes, I believe I have some small awareness of how email works.

> users do. And that's why I find the listing of submission IP in traces

And I also believe I have some small awareness of how modern networking
works.

> email systems is hard.

Except that you apparently refuse to acknowledge it, preferring instead to put
words in other people's mouths, not to mention assuming they don't understand
the most basic operational characteristics of modern email.

Even more important, you also apparently refuse to acknowledge some of those
uses have significant privacy implications of their own. A lot of people here
are saying that the inclusion of IP addresses in Received: fields is of
use in shutting down phishing attacks. And phishing is tremedounsly damaging
to user privacy.

So what we have here is a tradeoff. On the one hand, if we include client IP
addresses in Received: fields, we leak information about message senders which
may be exploited by message recipients, service providers etc. (but not state
actors). But on the other hand, if we don't include client IP information, we
make it harder to prevent spam and phishining attacks from reaching mail
recipients, which when those attacks are successful - as some percentage always
are - utterly compromises user privacy.

And this is going to be a very difficult tradeoff to weigh for a bunch of
reasons. For one thing, it's something of an applies to oranges comparison - a
small loss of privacy for a large group in aggregate is difficult to compare to
a major loss of privacy to a much smaller group. And that's assuming we can
find the means of assessing the sizes and characteristics of the groups. And in
the case of phishing attacks, if the past is any indication, the efficacy of
using a particular piece of information like client IP is going to change over
time as attackers change their strategy.

But none of this is helped by your failure to actually read what other people
are saying, and your frankly insulting assumptions that I don't understand
the most basic principles of how email and networks work.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 17:04:39 +0000

Hiya,

> state actors have the ability to get a better version of that information from

I don't think I've seen substantiation of "significant value" to
state actors for the specific case of message author's IP addresses in
Received: fields.

OTOH, access to transaction logs should depend on the jurisdiction in
which those are located though whereas if SMTP is not (or badly)
protected via STARTTLS then those fields will be visible to monitoring
devices. And it also seems likely that that data will be stored if it
can be stored [1] as one real pattern seems to be that those doing PM
will attempt to get data via every possible avenue, even when they have
a way to convince or force service providers to co-operate.

   [1]
http://leaksource.info/2015/02/25/pony-express-cse-spying-on-canadians-emails-to-government/

So while I've not seen specific information that these fields have
been used after e.g. having been recorded via tempora or similar,
it seems credible to assume that that can be done (and hence is
being done).

> worth considering. It's an argument against a specific claim that has been and

Right. There's also the case of leaked data, e.g. in the hacking team
leak case, ([2] search down the page for "homing pigeon"), those fields
in that tranche of stolen/leaked data did expose specific information
that might otherwise not have been extractable. I'm not sure if I'd call
that additional information significant or not, given all the rest of
the things the folks who did [2] could deduce from the data.

   [2] http://labs.rs/en/metadata/

(Note that I'm assuming that when [2] says "email headers reveal the
IP address of the sender" they mean from Received: fields, and not
something else.)

And to be clear, none of the above is meant to contradict the arguments
folks have made about using this information for reasonable purposes.
I figure this is just a part of the analysis of the trade offs that a
WG would have to do. (Or that someone could just go and do now before
there's a WG.)

Cheers,
S.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 7 Dec 2015 10:29:49 -0800

> the most basic principles of how email and networks work.

Ned, I am sorry if my message felt insulting. That was definitely not my
goal. We may disagree on the relative priority of plugging this or that hole
to thwart pervasive monitoring, but I never meant questioning your technical
competency. If you felt insulted, please accept my apologies.

-- Christian Huitema

---

From: Chris Lewis <[email-masked]>
Date: Mon, 7 Dec 2015 14:41:13 -0500

> depending on the findings.

One could envision a RG constituted to long-term specifically work on 
privacy implications of IETF RFCs in general, with a view towards 
improving privacy via future RFCs.  There is at least some precedent 
given the requirements about security area oversight of new RFCs, and 
the required SECURITY sections of RFCs now.  Which would be a "good 
thing", but huge, unwieldy, and perhaps unsustainable long-term (given 
that most people may only have narrow topic-area interests).

You could, instead, have it focus on specific areas for periods of time. 
  Like, "today SMTP, 6 months from now web" etc.  May still be 
unwieldy/ineffective for the same reasons.

Or finally, make it narrow - "RG on email privacy leakage" - a WG with a 
stronger research/analysis mandate.

OTOH, if we stayed with the WG approach, the mandate still has to be 
adjusted to do the research for guiding output documents w.r.t. privacy 
vs other tradeoffs.

I'm tending more towards RG on email privacy leakage.  Even just a 
document outlining where the potential leaks are, and outlining the 
threat landscape tradeoffs (both privacy and other) of 
eliding/not-eliding the info.

So put me up as a strongish vote for a narrow RG.

---

From: Hector Santos <[email-masked]>
Date: Mon, 07 Dec 2015 14:59:42 -0500

> can be chartered to investigate things before proposing

+1.

I think a working group is sufficient with faster high quality results 
than a longer term research effort.  We have enough 
ietf-industry-man-years, especially in the mail industry, to determine 
what is necessary.

The charter started out with ambitious goals that included 
"well-engineered improvements to the SMTP protocol."

But then it limited itself to specific work items, including DMARC 
related items which is not enough. I believe this effort requires 
liaison with the IETF-SMTP and DNS communities, as well as the DMARC 
and SPF communities.

How about:

   o RFC5321BIS, RFC5322BIS  Working Groups
   o "Email Bible" BCP for Hosting Mail Services Working Group

The latter would produce an Modern Integrated ESMTP guide like RFC1123 
was the "hosting bible" for many internet application hosting 
implementers.

But then again, I can see how the charter may want to keep it simple 
too with the specific work items:

  o New I-D to relax the STD10/RFC5321.Received MUST requirement,
  o New I-D for "Cryptographic Protection of E-mail Headers" (memoryhole)
  o Soliciting new ideas (any I-Ds?) for Loop Detections.

-- 
HLS