RE: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)

Christian Huitema <huitema@microsoft.com> Thu, 21 August 2014 19:23 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF89B1A8545 for <ietf@ietfa.amsl.com>; Thu, 21 Aug 2014 12:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 yPKK2fdibYAG for <ietf@ietfa.amsl.com>; Thu, 21 Aug 2014 12:23:26 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FF51A89F4 for <ietf@ietf.org>; Thu, 21 Aug 2014 12:23:25 -0700 (PDT)
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (25.160.96.16) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Thu, 21 Aug 2014 19:23:16 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.00.1015.017; Thu, 21 Aug 2014 19:23:16 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>
Subject: RE: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)
Thread-Topic: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)
Thread-Index: AQHPvMProJWAbtkwsEyV/7MEdeHAT5vaPakAgAAEcICAAAdoAIAAnT6AgACEvLA=
Date: Thu, 21 Aug 2014 19:23:16 +0000
Message-ID: <0129ebb7121f4c0b9aef6fca1fa8b118@DM2PR0301MB0655.namprd03.prod.outlook.com>
References: <CAMm+Lwh1xzaxqqnnbdgFQrR0pWknsHru8zjnjCMVjihymXtKNw@mail.gmail.com> <alpine.LFD.2.10.1408202100590.6648@bofh.nohats.ca> <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie>
In-Reply-To: <53F5D303.1090400@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2001:4898:80e8:ee31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 0310C78181
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(99286002)(74502001)(99396002)(74662001)(21056001)(74316001)(81342001)(87936001)(86362001)(81542001)(31966008)(107046002)(95666004)(83322001)(101416001)(86612001)(2656002)(50986999)(80022001)(77096002)(54356999)(85306004)(20776003)(92566001)(76176999)(76576001)(108616004)(33646002)(79102001)(76482001)(93886004)(4396001)(83072002)(106116001)(77982001)(64706001)(106356001)(46102001)(105586002)(85852003)(90102001)(2501001)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/wDNuNbiE_TehzAVjXmjYCg2hDug
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 19:23:31 -0000

> Hmmm. I do not see broad concern. I do see persistent expression of concern from you about this being done 
> without sufficient something (care, seriousness, whatever). I also see some folks saying that we should just 
> publish and get it done. That is all in addition to the good and constructive discussion, involving you and others, 
> with which the above is intertwined, so for me at least, its not a big deal really, just some more mail to get through.

I think we should just "publish and get it done."

The draft has a very simple function: tell the community that it is OK to do some form of encryption even if in situations where we cannot do the perfect negotiation of really secure and authenticated keys. In fact, tell the community that is not OK to just fall back to plain text when one particular check was missed in the perfect negotiation.

Watching the discussion, I see three forms of objections:

1) Objection to the particular name that was chosen to designate this "design pattern."
2) Objection to the whole idea that we should settle for better than plaintext when we cannot do perfect. 
3) Objection to the particular wording of Viktor's draft.

Stephen just pointed the archives of the SAAG discussion that eventually converged on the "opportunistic security" term. Nobody is in love with that term. It was chosen as a second best after "opportunistic encryption," which was somehow conflicting with a particular usage of IPSEC. But we also got convinced that the name is good enough. 

The "better than plaintext" consensus is obviously rough. There are two classes of objections. One is the "false sense of security" argument, which is really an argument about the design of user interaction, and which is addressed in the draft. The other is the "middle box" argument, which says that if more traffic stays in plain text middle boxes can do a better job of analyzing or transforming the data in flight. But then, there was a clear consensus at Vancouver to do as much encryption as possible despite these middle boxes, and to evolve middle boxes towards an explicit relation with the end-to-end senders and receivers. So, that part of the consensus is going to remain rough no matter what.

Viktor's draft is basically fine. It is short and clear. The various rounds of edits tend to make it "different," but not better. IMHO, it is time to ship it.

-- Christian Huitema