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
- Adept Encryption: Was: [saag] DANE should be more… Phillip Hallam-Baker
- Re: Adept Encryption: Was: [saag] DANE should be … Paul Wouters
- Re: Adept Encryption: Was: [saag] DANE should be … Stephen Farrell
- Re: Adept Encryption: Was: [saag] DANE should be … Nico Williams
- Re: Adept Encryption: Was: [saag] DANE should be … Dave Crocker
- Re: Adept Encryption: Was: [saag] DANE should be … Scott Kitterman
- RE: Adept Encryption: Was: [saag] DANE should be … l.wood
- Re: Adept Encryption: Was: [saag] DANE should be … Stephen Farrell
- Re: Adept Encryption: Was: [saag] DANE should be … Phillip Hallam-Baker
- Re: Adept Encryption: Was: [saag] DANE should be … Stephen Kent
- Re: Adept Encryption: Was: [saag] DANE should be … Viktor Dukhovni
- Re: Adept Encryption: Was: [saag] DANE should be … Viktor Dukhovni
- Re: [saag] Adept Encryption: Was: DANE should be … Nico Williams
- RE: Adept Encryption: Was: [saag] DANE should be … Christian Huitema
- Re: Adept Encryption: Was: [saag] DANE should be … Nico Williams
- RE: Adept Encryption: Was: [saag] DANE should be … l.wood
- Re: [saag]: Review of: Opportunistic Security -03… Viktor Dukhovni
- Re: [saag] Adept Encryption: Was: DANE should be … Nico Williams
- RE: [saag] Adept Encryption: Was: DANE should be … l.wood
- Re: Adept Encryption: Was: [saag] DANE should be … Stephen Farrell
- Re: [saag] Is opportunistic unauthenticated encry… Viktor Dukhovni
- Re: [saag]: Review of: Opportunistic Security -03… Paul Wouters
- Re: [saag] : Review of: Opportunistic Security -0… Stephen Kent
- Re: [saag] Adept Encryption: Was: DANE should be … Stephen Kent
- RE: [saag] Is opportunistic unauthenticated encry… Bernard Aboba
- Re: [saag] Is opportunistic unauthenticated encry… Theodore Ts'o
- RE: [saag] Is opportunistic unauthenticated encry… Christian Huitema
- Re: [saag] Is opportunistic unauthenticated encry… Nico Williams
- RE: [saag] Is opportunistic unauthenticated encry… Bernard Aboba
- Re: [saag] Is opportunistic unauthenticated encry… Stephen Farrell
- RE: [saag] Is opportunistic unauthenticated encry… Bernard Aboba
- Re: [saag] Is opportunistic unauthenticated encry… Viktor Dukhovni
- Re: [saag] Is opportunistic unauthenticated encry… Stephen Farrell
- Re: [saag] Is opportunistic unauthenticated encry… Fernando Gont
- Re: Is traffic analysis really a target (was Re: … Eric Burger
- Re: Is traffic analysis really a target (was Re: … Michael StJohns
- Re: [saag] Is opportunistic unauthenticated encry… Dave Crocker
- Re: Is traffic analysis really a target (was Re: … Brian E Carpenter
- Re: [saag] Is opportunistic unauthenticated encry… joel jaeggli
- Re: [saag] Is opportunistic unauthenticated encry… Fernando Gont
- Re: [saag] Is opportunistic unauthenticated encry… joel jaeggli
- Re: [saag] Is opportunistic unauthenticated encry… Fernando Gont
- Re: Is traffic analysis really a target (was Re: … Mark Andrews
- Re: [saag] Is traffic analysis really a target (w… Henry B (Hank) Hotz, CISSP
- Re: Is traffic analysis really a target (was Re: … Ted Hardie
- RE: [saag] Is opportunistic unauthenticated encry… Hosnieh Rafiee
- Re: Is traffic analysis really a target (was Re: … Brian E Carpenter
- Re: Is traffic analysis really a target (was Re: … Nico Williams
- Re: Is traffic analysis really a target (was Re: … Eric Burger