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

S Moonesamy <> Tue, 20 May 2014 12:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3FC5D1A06D9 for <>; Tue, 20 May 2014 05:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 32s0e6yG_WdL for <>; Tue, 20 May 2014 05:28:07 -0700 (PDT)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id 2BD6E1A06D0 for <>; Tue, 20 May 2014 05:28:07 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id s4KCRspe028869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Tue, 20 May 2014 05:28:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail2010; t=1400588885; bh=riIXh1ZVz06470G+/LJ+Lo0tLn46KXDubv5kYJmfR54=; h=Date:To:From:Subject:In-Reply-To:References; b=2KLcR7RamPsJeYnBuXzW8DRIlk9vTgg0xY9hXQna8pQMxzLoMjgmb7DKclGvktlek jvNJuwdManoZ9WmynRPWFuimTW7LdvXn1n9aXVrygmW8/ajkQjtID6P3gv3jvkCbmv 0WzWqLDn3BzbHUEr6y3JBRrlXS7UB/ru3Qf9hztI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1400588885;; bh=riIXh1ZVz06470G+/LJ+Lo0tLn46KXDubv5kYJmfR54=; h=Date:To:From:Subject:In-Reply-To:References; b=hBbKwgYDJVTD3h9SqHUCIrw8KW2ak09fw+nzSUNjmHZZxcRUh5EpGAZVTPYhbKZjt r24du/An76L2t+IPo+DXAMm8isx7lY1Tok9n48ySHTpx5RuM95x3fibJSBz05EBtEw wIhfWlq8Ys6pwHBhZfTH3YFNYlH+xliS8QwQWSxg=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 20 May 2014 05:14:58 -0700
From: S Moonesamy <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [ietf-privacy] PPM Review of RFC 5068
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 May 2014 12:28:08 -0000


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

S. Moonesamy