Re: [dane] Need better opportunistic terminology
Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 07 March 2014 00:44 UTC
Return-Path: <viktor1dane@dukhovni.org>
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 28C2A1A014E; Thu, 6 Mar 2014 16:44:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 tevUjjtw6wRg; Thu, 6 Mar 2014 16:44:38 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4F71A00CA; Thu, 6 Mar 2014 16:44:38 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 954212AB24D; Fri, 7 Mar 2014 00:44:32 +0000 (UTC)
Date: Fri, 07 Mar 2014 00:44:32 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140307004432.GH21390@mournblade.imrryr.org>
References: <CAMm+LwjF9To+w3K4RR=72BbLNE2hJa9CibWOEARYmODiuFNu9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+LwjF9To+w3K4RR=72BbLNE2hJa9CibWOEARYmODiuFNu9g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y1xNPGMRNWocdrbhZuuUgLbcLYU
Cc: saag@ietf.org
Subject: Re: [dane] 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: Fri, 07 Mar 2014 00:44:41 -0000
On Thu, Mar 06, 2014 at 09:23:23AM +0000, Phillip Hallam-Baker wrote: > The term opportunistic has become the new synonym for 'Good' but it is > being used for many different things. Since I am the primary perpetrator of the thought crime in question, :-) I'd like to explain the term we used, and why, and solicit a better term if the IETF has a better way of expressing the underlying idea. Background: In the Postfix community, we've historically used the term "opportunistic TLS": http://www.postfix.org/TLS_README.html#client_tls_may to refer to a client that employs TLS encryption without any authentication when the server's EHLO response includes STARTTLS. In this case the client is willing to otherwise send in the clear, and, in fact, will fallback to cleartext when the TLS handshake fails. In the (new) DANE SMTP draft the terminology section reserves the term "(pre-DANE) opportunistic TLS" for the above client behaviour. http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07#section-1.1 We introduce a new term (also listed in the terminology section) which is "opportunistic DANE TLS". The thought crime in question predates the last summer's pervasive monitoring disclosures. The work on the draft began in March 2013, and the new term was used (correctly or otherwise) from the outset. So you might ask what was the word "opportunistic" doing in our avant-garde use of the term "opportunistic DANE TLS"? The answer is that as with (pre-DANE) opportunistic TLS, the client is willing to send in the clear to any server for which no "secure" TLSA records are available. Thus, until the happy future when a significant fraction of domains are DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated "secure" TLSA records, in practice the protocol is essentially the same as with (pre-DANE) opportunistic TLS. The client employs the best security level available (including cleartext). What DANE does is raise the bar, so that for some destinations, the ones with secure TLSA records, the best available is authenticated TLS, and this status can be determined in a downgrade-resistant manner. I am open to any reasonable terminology that conveys to the user that the security policy is still "best effort", but when DANE is applicable we can do better than unauthenticated TLS with cleartext fallback. So Phillip is quite right that DANE gets us stronger semantics, but I would argue, that because the actual security posture is *conditional* on published receiving system capabilities, from the perspective of the sending system, this is just a "hardened" version of opportunistic TLS where, for just some destinations not known to the sender in advance, MITM attacks cannot trivially downgrade senders to plaintext or compromise transport integrity or confidentiality. So in Postfix documentation, we'll still describe the resulting security as a form of opportunistic TLS (this is how the email administrator should think about this "hardened" best-effort security). http://www.postfix.org/TLS_README.html#client_tls_dane In IETF documents, I'm open to anything that aligns reasonably well with other documents. We do not mean to cause any confusion. If there is a clear precedent or consensus for naming "opportunistic DANE TLS" in some other way, I for one have no objections. -- Viktor.
- Re: [dane] Need better opportunistic terminology Viktor Dukhovni
- [dane] Need better opportunistic terminology Phillip Hallam-Baker
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] Need better opportunistic terminology Viktor Dukhovni
- Re: [dane] Need better opportunistic terminology Michael Richardson
- Re: [dane] Need better opportunistic terminology Viktor Dukhovni
- Re: [dane] [saag] Need better opportunistic termi… Stephen Kent
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Michael Richardson
- Re: [dane] [saag] Need better opportunistic termi… Peter Palfrader
- Re: [dane] [saag] Need better opportunistic termi… Tony Finch
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Paul Lambert
- Re: [dane] [saag] Need better opportunistic termi… Stephen Kent
- Re: [dane] Need better opportunistic terminology Tony Finch
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Nico Williams
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Michael Richardson
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Michael Richardson
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Stephen Kent
- Re: [dane] [saag] Need better opportunistic termi… Stephen Kent
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch
- Re: [dane] [saag] Need better opportunistic termi… Viktor Dukhovni
- Re: [dane] [saag] Need better opportunistic termi… Phillip Hallam-Baker
- Re: [dane] [saag] Need better opportunistic termi… Derek Atkins
- Re: [dane] [saag] Need better opportunistic termi… Paul Lambert
- Re: [dane] [saag] Need better opportunistic termi… Derek Atkins
- Re: [dane] [saag] Need better opportunistic termi… Stephen Farrell
- Re: [dane] [saag] Need better opportunistic termi… Nico Williams
- Re: [dane] [saag] Need better opportunistic termi… Olle E. Johansson
- Re: [dane] [saag] Need better opportunistic termi… Tony Finch
- Re: [dane] [saag] Need better opportunistic termi… Joe Touch