[ietf-privacy] draft-cooper-ietf-privacy-requirements-00.txt

Eliot Lear <lear@cisco.com> Tue, 24 September 2013 10:42 UTC

Return-Path: <lear@cisco.com>
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 E8E9011E810B for <ietf-privacy@ietfa.amsl.com>; Tue, 24 Sep 2013 03:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.485
X-Spam-Level:
X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Pspyt3q2DBqV for <ietf-privacy@ietfa.amsl.com>; Tue, 24 Sep 2013 03:42:03 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9950011E8110 for <ietf-privacy@ietf.org>; Tue, 24 Sep 2013 03:41:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5334; q=dns/txt; s=iport; t=1380019319; x=1381228919; h=message-id:date:from:mime-version:to:subject; bh=WnxvAi3ZZIjM5SWS2+OqZ9d+3MxG28OsszDVrsr8+K4=; b=lqHDqc+8RCDxTGPCaWz/pfQsGBY6i+d5VKZni0AO4K6uSdz6VQhKkUMQ 6zueKYU353zoC3sz6GGqKjVY8XgDDPtZn5ehIapKFJ//3EmG+W6bhVfeT i5/dNpSPJy0eIGqwyplGsxe7CR0xGxgWcFjS48JnPFko934fmi167xqJl k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAFtrQVKQ/khR/2dsb2JhbABagweEM4VduGwWdIIlAQEBAx4GVQYaHRYLAgsDAgECASstCAEBh3sGm1CPA5JJkkCBNQOTXoQekXeDJjo
X-IronPort-AV: E=Sophos; i="4.90,970,1371081600"; d="scan'208,217"; a="159943717"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 24 Sep 2013 10:41:57 +0000
Received: from mctiny.local ([10.61.193.202]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8OAfnIo029449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-privacy@ietf.org>; Tue, 24 Sep 2013 10:41:54 GMT
Message-ID: <52416C71.9000903@cisco.com>
Date: Tue, 24 Sep 2013 12:41:53 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: ietf-privacy@ietf.org
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------050205010107090905020300"
Subject: [ietf-privacy] 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: Tue, 24 Sep 2013 10:42:09 -0000

Hi,

I've done a bit of back and forth with Stephen elsewhere, and I have a
few comments about the draft.

Opportunistic encryption really means different things to different
people.  It is actually NOT well defined in RFC 4322, and in that case
they're referring to encryption between L3 endpoints where you retrieve
keying information from the DNS using the KEY record and DNSSEC.  That
is not what is implied by the following paragraph:

>    While existing principles call for strong security, it is important
>    to note that strong security only in cases where the other party can
>    be authenticated does not by itself solve all privacy problems.  To
>    guard against dangers of large-scale privacy attacks, some protection
>    is needed also for other situations.  As a consequence, at minimum,
>    opportunistic encryption needs to be well-defined for almost all new
>    IETF standards track protocols.  In most cases it will be better to
>    (also) specify how to do mutually authenticated encryption.
>    Encryption provides one aspect of privacy protection, namely
>    confidentiality.

That is to say, the concepts of opportunistic and authenticated or
unauthenticated encryption are orthogonal. It is worth noting that by
the use of the term, one could reasonably argue that TLS is
opportunistic encryption because the encryption is not prearranged in
advance by two parties.  If that is the bare minimum, then IMHO that is
largely what is intended by RFC 3365 already.  I more than suspect
that's not what the intent of this draft is.

And so this raises three questions:

 1. First, what is really meant by opportunistic encryption in this case?
 2. What are the appropriate approaches for opportunistic encryption? and
 3. What are the best practices  (i.e., "Do"s and "Don'ts"; after all,
    this is meant to be a BCP)?

Also, some protocols have evolved to allow for sharing of private
information, for better and worse.  There are tradeoffs associated with
privacy versus security (such as the benefit of a transparent malware
scanner).  These tradeoffs should be discussed in security considerations.

Eliot