Re: [TLS] Is there a way forward after today's hum?

Robin Wilton <wilton@isoc.org> Thu, 20 July 2017 09:58 UTC

Return-Path: <wilton@isoc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F27131950 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 02:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org
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 mPkqWGBahP3K for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 02:58:01 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0064.outbound.protection.outlook.com [104.47.37.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDC013157A for <tls@ietf.org>; Thu, 20 Jul 2017 02:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=owcY8ui8o5r4QxeiVc6LXtxJ8yzo7A52gbhVEKqln3w=; b=KINXspeA2Hx8jHv3Cuu+e0BvD5M1HPUXN2LwDPQVeElyGuGohAuSOe0DWhQwCjY78AJcu7fsKBoq/lAaEUBcUNzOoyKIko0vW5lEtS7NAYk5VBS5v+yFFb2GjgRTXzh9iAkOrO2f8/dYf4M4t1YxP+RYCdf2gxcy2a2/rC2PuGw=
Received: from BN6PR06MB3395.namprd06.prod.outlook.com (10.174.235.153) by BN6PR06MB3396.namprd06.prod.outlook.com (10.174.235.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Thu, 20 Jul 2017 09:57:59 +0000
Received: from BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) by BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 09:57:59 +0000
From: Robin Wilton <wilton@isoc.org>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Is there a way forward after today's hum?
Thread-Index: AQHTAT0e/02z4cJx9Eqsiy9o8ZfN6w==
Date: Thu, 20 Jul 2017 09:57:59 +0000
Message-ID: <BN6PR06MB3395E47F181D02D5772EEC81BFA70@BN6PR06MB3395.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=isoc.org;
x-originating-ip: [178.255.154.107]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR06MB3396; 7:u9vRhNLOgVT9Ub+5DQiFrX1O9nfKIgFNooV/MBZPLpiwt1oNyIvtAONps2bVFkWtmlz7XAPiIP0xHh6Doi/XebKBKyQVStRF5kW/OyTpZwv8eTQ+kZF6jpEOpTqKzJu8oiqU8UnqrFzV+W0Qw0FqadimjubpUps++YRQwVVG192UcfT+ZdgwSfG1Q+nmBbvJTUzS8YrH/WAyCHFv89C2QtedZJQ+p7t6oVky4o7jcHrJdFVSosr2oQ1Mx4Gb5vCsj9+br1l6fWQOc7sd8jiVhrwBy68G9yJtYz6L17ao2+w/fXhUscymkMy4jNZ47YUZLydGhTV7/2TqspvkvM+LQN0+UB65nGStOKYM/peswHgZ5ivklaoLmygrpFMxq6RC9x95YGqfmuif4eD6XCpVUy70ASxl1LGfHr94cXqOvf3tHIuy9sj+Zmtepa3guncGbuxJYs6fiF4tSSulCqEOX9BkClpJNavv6OFkHBaPjz1PpHD37VubfiAu3eZyWsMKwBtCa7X7LrtnT/mmCDabpCT2rYSXBcWmkbQU8Rgi9TofWv17w4K8L0Hm5eUl7V0UfrzU2sCjvvOhROW/NQCfpK39nSm7oIm8hteis2yLEWtDNZt8ES0Ayb+pDuRYuLqrE6dbxvIGetHArEsK5WS/bnqpgqn4GZ8aJEeOyG51mOolkSYSQW/VlUb5+P1AatH1fWx3cEKpYuZ0vjhdRP+Z+O4QE2pI3pDKSwcJot5SIH8HzXUX5PaF7DDvzUIJXSXvhSVNfErEKe1u6dhUSM3PQ9PuKVBl2g1kocNXGHIz5uE=
x-ms-office365-filtering-correlation-id: 58b1124c-5820-4fb4-2b9e-08d4cf55cdc6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR06MB3396;
x-ms-traffictypediagnostic: BN6PR06MB3396:
x-exchange-antispam-report-test: UriScan:(158342451672863)(236129657087228)(48057245064654);
x-microsoft-antispam-prvs: <BN6PR06MB339679CABE9A381CA1F03AB2BFA70@BN6PR06MB3396.namprd06.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB3396; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB3396;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(39400400002)(39410400002)(39450400003)(6506006)(2501003)(3660700001)(77096006)(478600001)(2906002)(8936002)(74316002)(8676002)(81166006)(1730700003)(86362001)(6606003)(6116002)(189998001)(6916009)(7736002)(229853002)(3846002)(6436002)(5660300001)(102836003)(7696004)(25786009)(3280700002)(53936002)(55016002)(33656002)(50986999)(561944003)(66066001)(19627405001)(2351001)(5640700003)(38730400002)(54896002)(54356999)(14454004)(110136004)(2900100001)(9686003)(99286003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3396; H:BN6PR06MB3395.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR06MB3395E47F181D02D5772EEC81BFA70BN6PR06MB3395namp_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 09:57:59.5225 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3396
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oSyOj1_uFgIlJkYHrlQ6Z5U1VMs>
Subject: Re: [TLS] Is there a way forward after today's hum?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2017 09:58:03 -0000

Apologies for not replying "in thread" on this occasion, for noob reasons... but here's the specific comment from Russ that I wanted to respond to:


________________________________

The hum told us that the room was roughly evenly split.  In hind sight, I wish the chairs had asked a second question.  If the split in the room was different for the second question, then I think we might have learned a bit more about what people are thinking.

If a specification were available that used an extension that involved both the client and the server, would the working group adopt it, work on it, and publish it as an RFC?

I was listening very carefully to the comments made by people in line.  Clearly some people would hum for "no" to the above question, but it sounded like many felt that this would be a significant difference.  It would ensure that both server and client explicitly opt-in, and any party observing the handshake could see the extension was included or not.

Russ


====


Stephen Farrell articulated a concern with that approach - namely, that if we are relying on a setting that is meant to ensure both parties must be aware that static DH is in use, then a bad actor would find ways to suppress that notification. In your proposal, Russ, the notification mechanism would take the form of an extension... so I think we would need to understand what the failsafe is, for instance if that extension is disabled, or not present, in a given deployment of TLS.


There's an implicit assumption about the threat model, too, which I just want to call out. The assumption is that a bad actor would suppress the notification so that the client is not aware that static DH is in use. For completeness, should we also consider whether there are attacks in which it's the *server* whose notification is suppressed? (I can't think of such an attack, off the top of my head, but then, that's probably why I'm not a hacker. ;^, )


Best wishes,

Robin