Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 04 February 2014 16:18 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C511A01BE for <uta@ietfa.amsl.com>; Tue, 4 Feb 2014 08:18:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 ZOEXPVWbNgPi for <uta@ietfa.amsl.com>; Tue, 4 Feb 2014 08:18:31 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 771421A0167 for <uta@ietf.org>; Tue, 4 Feb 2014 08:18:31 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s14Fvx6e081517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Feb 2014 08:58:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAKhHsXE77Nu6Z_P5W3JwW==_cOU5ey_ShBpVf8+hMwa8Bys4WA@mail.gmail.com>
Date: Tue, 04 Feb 2014 08:18:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9DDA725-C767-4C1F-A849-DCB6886D1F61@vpnc.org>
References: <20140203045910.9714.53880.idtracker@ietfa.amsl.com> <B8691415-07F3-4081-8247-E103A60E5CF0@vpnc.org> <700ECF7E-253E-4CCC-BD73-6008216E5429@edvina.net> <CAKhHsXFmbc_CxPHSfzji-J7mJTUh4MOfwVFjnOdk-B+bA9miqA@mail.gmail.com> <D9374419-5EFE-455D-B348-F2698001BDF6@vpnc.org> <CAKhHsXHvme7-26MFHwsdvR-osqhy4L1dk6gZve9YR5jPduNi1A@mail.gmail.com> <52EFD1E4.6020200@fifthhorseman.net> <CAKhHsXGHdC9-3hM4JuXnt=TQfY9YVbUX_fnTBPz=te05dNrfCw@mail.gmail.com> <C32D6057-55E5-4825-93ED-F54556DE1CD0@vpnc.org> <CAKhHsXE77Nu6Z_P5W3JwW==_cOU5ey_ShBpVf8+hMwa8Bys4WA@mail.gmail.com>
To: Alan Johnston <alan.b.johnston@gmail.com>
X-Mailer: Apple Mail (2.1827)
Cc: uta@ietf.org
Subject: Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 16:18:32 -0000

On Feb 4, 2014, at 7:02 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:

> Help me understand.  You are saying authentication of the server by the client in TLS is not optional.  I suspect you mean that the client must try to authenticate the server.  

No, I mean that the TLS RFC says that the client must authenticate the server unless one of the anonymous ciphersuites is used.

> I guess what I'm saying is that from a non-TLS expert's perspective, it appears that authentication is optional by TLS, at least the way it is used with web browsers.

Yes, exactly.

> I guess this is the problem of trying to define opportunistic for a single protocol, rather than trying to define the term generically and then apply it to a given protocol.  For example, it is possible that TLS can only support opportunistic encryption with PKI authentication, but this doesn't mean that we should change what we mean by opportunistic encryption to fit the particulars of how TLS is designed.
> 
> On the other hand, if the word opportunistic has too much baggage, then maybe we just need to treat it as a generic feature name which mean different things in different contexts.  In this case, we would need a new term for the concept that you describe in the first sentence of your definition, IMO.

The IETF has a long history of trying to come up with new terms when the old ones get too confusing. I'm pretty sure every effort has been a failure.

--Paul Hoffman