Re: [perpass] draft-josefsson-email-received-privacy

[Simon Josefsson <[e-mail]>]

Hi Ned,

Thanks for looking at the document!

We are happy to make this more inline with what you and others are doing
or suggest to do.  With the -00 we wanted to get the ball rolling, to be
able to discuss what to do about the problem.  We don't care strongly
what the particlar approach is as long is it does its job.  Given the
responses so far, I believe we even have some work to do on getting the
problem statement itself right, let alone the proposed solution.

I agree with you about the problem related to loop detection (RFC 5321
section 6.1), so agree that it is a valid argument for not making the
header optional.

Jacob Appelbaum brought up that the trace information about what
authentication parameters were used can be interesting and does not
appear to be a significant privacy violation.  So that's another
argument for retaining the header.  He also mentioned that timestamp
information are problematic due to netflow related data.

I agree with your recommendation to retain the Received header but
modify what to put in it.  I believe the FROM clause should be removed
completely, or we put in a "magic" (syntactically valid but semantically
invalid) IPv4 or IPv6 address in it.  Similarily, implementations could
put a magic time-stamp value in the field if they don't want to reveal
when they received a particular message.

When I look at the ABNF for Received in RFC 5322 I'm confused as I don't
see how the normally used Received: headers on the Internet (i.e., with
'FROM', 'BY' etc clauses) actually conform to the 'received' ABNF token
or the 'obs-received' token.  Is this a RFC 5322 bug?  The BNF in RFC
822 and RFC 2822 appears to work.

We could use your help here :-)

/Simon

[e-mail] writes:

>> Hi,
>
>> draft-josefsson-email-received-privacy-00 has been submitted, see
>> https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/
>
>> I'd be interested in hearing what people on the perpass list think of
>> this.
>
> It looks to me like the IETF is belatedly coming up to speed on a problem that
> the email community - the large scale providers at least - is already in the
> process of solving. And while it would be nice to write down some best
> practices here so everyone knows what to do, the method described  in this
> draft is *not* that best practice in any way, shape or form.
>
> In fact its adoption would cause widespread damage to the email infrastructure.
>
> Getting down to specifics: This proposal effectively makes the addition of
> Received: fields optional: You only do it when you feel like it. The
> obstensible purpose of this change is to prevent exposure of the sender's IP
> address in the context of pervasive  surveillance.
>
> However, this removal, were it to occur, is not terribly effective in achieving
> this specific goal. Why? Because this does nothing prevent the IP address from
> being logged elsewhere. And those logs often enjoy far less legal protection -
> in some cases no protection at all - than actual message content. And good luck
> convincing ISPs and MSPs not to collect this information.
>
> If anything the removal of this information from messages for this claimed
> result may create a false sense of security in regards to persuasive
> surveilance.
>
> All that said, there is a real privacy gain in not including this information
> 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.
>
> So where is the information stored and how can eliminate it safely? It's in the
> from clause of the Receved: field generated by the SUBMIT server. The from
> clause is mandatory, but there's noting that says the clause has to actualy
> contain anything meaninful. So the obvious solution is to dummy information.
> (My personal preference would be to define a well known name or names for this
> purpose and use that without any IP address information at all, which the ABNF
> in RFC 5321 explicitly allows.)
>
> And this approach has already been deployed, successfully AFAICT. (To be fair,
> gmail appears to have done it by dropping from clauses entirely - a syntax
> violation.) We added an option to override the from clause to our product a few
> months ago. (And I'm told we're fairly late to this particular party.)
>
> Now, received fields are, as the draft notes, generated at other times, and the
> name/address information in them can reveal internal network topology to some
> extent. This concern is, IMNSHO, considerably overblown, but sanitizing from
> clauses generated by internal relay steps may make sense in some specific cases.
>
> And what about other aspects of the Received: field? The remainder of the (all
> optional) clauses that Received: fields support also reveal information to some
> extent and a detailed security analysis of all of them should be undertaken as
> part of any work undertaken in this area.
>
> That leaves the presence of the Received: field itself and the timestamp. The
> former is critical to the proper functioning of the email transport
> infrastructure: Received: field counting is the primary mechanism used to
> prevent mail loops. And there's ample operational experience in the field with
> the bad things that happen when the requirement to add Received: fields is
> ignored or agents remove them willy-nilly.
>
> The timestamp is quite useful in tracking routing delays after the fact. It
> also doesn't reveal all that much given how it's going to be brackted by the
> Date: field and the IMAP internaldate.
>
> In summary, the present proposal as presently written is a nonstarter because
> it breaks critical email functionality: The ability to detect and block mail
> loops. In also unnecessarily causes the removal of highly useful timing and
> trace information. An approach based on current inductry practices should be
> considered instead and specific guidance on when the mechanism should be
> employed needs to be given.
>
> 				Ned
>
> _______________________________________________
> perpass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perpass