[ietf-privacy] "Opportunistic encryption" and a need for a definition

Stephane Bortzmeyer <bortzmeyer@nic.fr> Tue, 19 November 2013 09:34 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3C91AD84D for <ietf-privacy@ietfa.amsl.com>; Tue, 19 Nov 2013 01:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.075
X-Spam-Level:
X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-ySLVzPJku9 for <ietf-privacy@ietfa.amsl.com>; Tue, 19 Nov 2013 01:34:20 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE901AD7C1 for <ietf-privacy@ietf.org>; Tue, 19 Nov 2013 01:34:20 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id AFAFA280230 for <ietf-privacy@ietf.org>; Tue, 19 Nov 2013 10:34:13 +0100 (CET)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id AC18B2801B6 for <ietf-privacy@ietf.org>; Tue, 19 Nov 2013 10:34:13 +0100 (CET)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id AAD3EB3800C for <ietf-privacy@ietf.org>; Tue, 19 Nov 2013 10:33:43 +0100 (CET)
Date: Tue, 19 Nov 2013 10:33:43 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: ietf-privacy@ietf.org
Message-ID: <20131119093343.GA9282@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Operating-System: Debian GNU/Linux 7.2
X-Kernel: Linux 3.2.0-4-686-pae i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [ietf-privacy] "Opportunistic encryption" and a need for a definition
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Nov 2013 09:34:22 -0000

[Long quiet time on this list, time to resume discussions.]

In draft-cooper-ietf-privacy-requirements-01, I find:

   "Opportunistic encryption" is defined as encryption without any pre-
   arrangement specific to the pair of systems involved (e.g., by using
   a Diffie-Hellman exchange).  See [RFC4322].

I find this definition confusing (specially the reference to DH)
because it does not match the rest of the text which says:

   Where both opportunistic and one-sided or mutually
   authenticated encryption are specified, protocols MUST also protect
   against downgrade attacks so that scenarios where authentication is
   required cannot easily be manipulated into using opportunistic
   encryption which will often be subject to man-in-the-middle
   attacks.

The second paragraph seems to use OE as meaning "encryption without
authentication" (which is indeed vulnerable to man-in-the-middle
attacks). This is also how "opportunistic" is used in RFC 5386.

The first paragraph (and RFC 4322) have a different meaning, OE being
"encryption without peer-specific setup" (and therefore being
authenticated, and not vulnerable to man-in-the-middle attacks).

The discussions in Vancouver were very confused as well. Everyone was
talking about OE but with a different definition in mind. I strongly
suggest that we need either to have one definition and to stick with
it (the current draft is self-contradictory). Or to give in and to
stop using the term OE, poorly defined, and too loaded.

Do not that Wikipedia has a third definition of OE (encryption with a
fallback to an unencrypted
mode) http://en.wikipedia.org/wiki/Opportunistic_encryption