Re: [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 25 September 2013 14:41 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EC321F99F0 for <ietf-privacy@ietfa.amsl.com>; Wed, 25 Sep 2013 07:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+d9zHoKjiVT for <ietf-privacy@ietfa.amsl.com>; Wed, 25 Sep 2013 07:41:52 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 28C9811E8108 for <ietf-privacy@ietf.org>; Wed, 25 Sep 2013 07:41:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 81BADBE58; Wed, 25 Sep 2013 15:41:44 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0wDRG8N8lyL; Wed, 25 Sep 2013 15:41:44 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 63B6BBE57; Wed, 25 Sep 2013 15:41:44 +0100 (IST)
Message-ID: <5242F629.2080008@cs.tcd.ie>
Date: Wed, 25 Sep 2013 15:41:45 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Avri Doria <avri@acm.org>, ietf-privacy@ietf.org
References: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> <523C7912.1060206@cs.tcd.ie> <87F3E6B1-1A51-424A-A3BA-EE65425550B9@acm.org>
In-Reply-To: <87F3E6B1-1A51-424A-A3BA-EE65425550B9@acm.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2013 14:41:57 -0000

Hi Avri,

On 09/25/2013 01:08 PM, Avri Doria wrote:
> Hi
> 
> Very much support the draft and the idea of creating a BCP.
> 
> Have also appreciated the discussion on opportunistic encryption,
> which I consider akin to a holy grail.  Been thinking about it in a
> DTN context for a while, but don't feel like I ever got very far.
> 
> I am, however, looking at another part of the text.  I appreciate
> that the requirements are a MUST and that reads well, but, doesn't
> including a statement "Note that this is contingent on practicality"
> really downgrade it to a  SHOULD?

Well, I'd rather keep the MUST, but yes, it needs some kind of
modulation and so is quite like a SHOULD. However, there are a
bunch of people in the IETF who (wrongly, but nonetheless) only
ever pay attention to MUSTs.

What I think we're aiming for is something that's fairly strict
but usable for new protocols but doesn't cause us silly problems
e.g. if we want to revise RFC5322 again. We also want something
that doesn't become an RFC6919 "MUST, but we know you won't."

That's a tricky balance to achieve.

> I think that "really has to be sent in clear for a protocol to be
> able to operate" is too hand wavy as a guideline.    Perhaps the
> draft could go deeper in the kinds of conditions that indicate that:
> 
> a) it was really necessary - what are the reasonable conditions for
> necessity? b) an indication of what practical actions have been taken
> to avoid this insurmountable obstacle and a discussion of which
> particular  requirements could not be met. c) a guideline that
> indications be given on how can these instances be mitigated
> 
> This could well be a clue to what sort of information is needed to
> meet the requirement of explaining why the protocol does not fill the
> other requirements for protecting private data.
> 
> While I think that perhaps that I should go a little further breaking
> down a-c above, Irealized I would not get this sent of for several
> weeks if I were to try and go further and actually recommend text on
> a-c above.

Good points. I suspect we won't be done with this one in the next
week so if you can get the time to propose something that'd be
great. BCP107 does that by saying you MUST have auomated key
management if any of <6 conditions> are met, not sure if that's
a way to go about this though.

S.


> 
> 
> avri
> 
> _______________________________________________ ietf-privacy mailing
> list ietf-privacy@ietf.org 
> https://www.ietf.org/mailman/listinfo/ietf-privacy
> 
>