Re: [dane] [saag] Need better opportunistic terminology

"Olle E. Johansson" <oej@edvina.net> Thu, 13 March 2014 07:59 UTC

Return-Path: <oej@edvina.net>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353321A094F; Thu, 13 Mar 2014 00:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
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 aHR9EsNpaNBL; Thu, 13 Mar 2014 00:59:22 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C6F4B1A094E; Thu, 13 Mar 2014 00:59:21 -0700 (PDT)
Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6195793C2A2; Thu, 13 Mar 2014 07:59:13 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <sjmlhwfxk16.fsf@mocana.ihtfp.org>
Date: Thu, 13 Mar 2014 08:59:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDEFFAA5-AF1B-442B-B820-62A57BB9E03D@edvina.net>
References: <CAMm+LwjF9To+w3K4RR=72BbLNE2hJa9CibWOEARYmODiuFNu9g@mail.gmail.com> <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <sjmlhwfxk16.fsf@mocana.ihtfp.org>
To: Derek Atkins <derek@ihtfp.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/H6SoTuEIwEAE-py9Cr7R47Qv900
Cc: dane@ietf.org, saag <saag@ietf.org>, Joe Touch <touch@isi.edu>
Subject: Re: [dane] [saag] Need better opportunistic terminology
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 07:59:24 -0000

On 12 Mar 2014, at 21:02, Derek Atkins <derek@ihtfp.com> wrote:

> Joe Touch <touch@isi.edu> writes:
> 
>> Why not just use the term "unauthenticated encryption", when that's
>> exactly what's happening?
> 
> Well, it's not necessarily what's happening.  The data itself might
> still have "integrity protection" (which is a form of authentication.
> You're just not authenticating the endpoint, which means you could be
> subject to a MitM attack.  Alternate terms could be "Unauthenticated
> Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to
> what's going on.

To get any movement in this area among developers and sysadmins, 
we need a language that any sysadmin or developer understands. 
I believe we can easily get them to understand "Opportunistic encryption"
but if we go into explaining "keying" or "key exchange" they will be lost in 
the OpenSSL documentation maze again.

We might have to separate a "marketing name" of the overall concept
from a set of technical definitions we can refer to when explaining this in
RFCs. For me, I can happily accept using OE as the unclear marketing
bullshit term for a set of solutions that set up an encrypted communication
channel - regardless of URI or configuration, without any indication to
the user in the phone UI or browser UI - no locks!

I can understand that this may be hard to accept in a technical community, but
we have a huge educational effort ahead of us in order to get this done.
The general concept has to be easy to explain.

In summary, I propose that we keep OE as the overall term and define
a set of more precise terminology to explain what goes on in the background.
As Victor pointed out, there may be different solutions in different
protocols.

As a side note:

https://tools.ietf.org/html/rfc5630

Use the term "best-effort TLS" to describe that a SIP ua is perfectly
allowed to set up a TLS session based on policy regardless if there
is a "sips:" URI. I don't know where that terminalogy came from. It's
always used with quotation marks in the RFC. This "best-effort TLS"
still requires verification of the certificate though.

Cheers
/O