Subject: [ietf-privacy] PPM Review of RFC 5068

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 May 2014 10:33:47 +0100

Trying to eat my own dog food, I drew this one...

- I guess this could be updated to say "don't offer an MSA that ever
allows for cleartext submission" but UTA will probably get to that.

- Section 4 does actually mention privacy which is good!

- I also generally dislike how MUAs ask for both username and password
before they do MSA discovery - I always worry that the MUA is liable to
be sending those to the n/w insecurely, so maybe a BCP could suggest
something there.

- Not sure if RFC4954 is still something we'd recommend (but I didn't
read it, so maybe it is), seems like TLS is the right thing today for this.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 May 2014 05:14:58 -0700

Hello,

I took a quick look at RFC 5068.  In Section 3.1:

   "For a reasonable period of time after submission, the message
    SHOULD be traceable by the MSA operator to the authenticated
    identity of the user who sent the message."

There is a typo in the above for NSA operator. :-)

   "Such tracing MAY be based on transactional identifiers stored in
    the headers (received lines, etc.) or other fields in the message,
    on audit data stored elsewhere, or on any other mechanism that
    supports sufficient post-submission accountability.  The specific
    length of time, after message submission, that traceability is
    supported is not specified here.  However, issues regarding transit
    often occur as much as one week after submission."

The problem in the above (and the previously quoted paragraph) is 
traceability and accountability.  It should be possible to address 
that without causing significant problems to the email infrastructure 
as it does not entail protocol changes.  There is already an identity 
in the message header.  It would be difficult to tackle 
that.  However, there isn't a need to disclose other identity 
information (authenticated identity) in the message headers.

Section 4 mentions the following (Stephen mentioned that in his message):

   "Examples include active privacy protection against third-party
    content monitoring, timely processing, and being subject to the most
    appropriate authentication and accountability protocols."

The problem here is that the user can be tricked into using a local 
submission proxy.  It is worthwhile to review that section and 
provide some guidance if active privacy protection is the goal.

In Section 5:

   "Mechanisms might also have to be used in combination with each other
    to make a secure system.  Organizations SHOULD choose the most secure
    approaches that are practical."

The following does not provide much guidance to the 
organization.  The next paragaph in that section does mention that 
"transmitting user credentials in clear text over insecure networks" 
should be avoided.

The Security Considerations might not pass an Evaluation 
nowadays.  Note that I did review RFC 5068 previously and as I look 
back I could say that I didn't do a good job. :-)

Regards,
S. Moonesamy

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 May 2014 14:47:01 +0100

Thanks SM good points (better than mine).

Cheers,
S.

PS: I'm looking forward to your up-to-date (re)reviews of
other old RFCs:-)

On 20/05/14 13:14, S Moonesamy wrote:
> traceability and accountability.  It should be possible to address that
> without causing significant problems to the email infrastructure as it
> does not entail protocol changes.  There is already an identity in the
> message header.  It would be difficult to tackle that.  However, there
> isn't a need to disclose other identity information (authenticated
> identity) in the message headers.
> 
> submission proxy.  It is worthwhile to review that section and provide
> some guidance if active privacy protection is the goal.
> 
> In Section 5:
> 
> The following does not provide much guidance to the organization.  The
> next paragaph in that section does mention that "transmitting user
> credentials in clear text over insecure networks" should be avoided.
> 
> The Security Considerations might not pass an Evaluation nowadays.  Note
> that I did review RFC 5068 previously and as I look back I could say
> that I didn't do a good job. :-)
> 
> Regards,
> S. Moonesamy
> 
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy
> 
>

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 May 2014 10:25:35 -0700

Hi Stephen,
>Thanks SM good points (better than mine).

I would look at it as everyone puts in a little something and the 
work gets done.  As such your points are as good as mine. :-)

There would be some progress if anyone interested in perversive 
monitoring posts a review.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 May 2014 08:22:02 -0400

> Trying to eat my own dog food

I've always wondered how "eat our own cooking" became "eat our own dog
food," which makes no sense at all.  Ah, well...

> allows for cleartext submission" but UTA will probably get to that.

UTA should address a lot of this.  But the biggest problem with MSA
authentication is how it's often done.  There's still a lot of "this
IP address is on our network, so it's authenticated" going on.  And
one of the most common used to be "POP before submission," though I
don't know how common that is any more.  Great fun.

Barry

---

From: Scott Brim <[email-masked]>
Date: Thu, 22 May 2014 08:32:16 -0400

> food," which makes no sense at all.  Ah, well...

http://en.wikipedia.org/wiki/Eating_your_own_dog_food