Re: [TLS] ETSI releases standards for enterprise security and data centre management

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 06 December 2018 21:08 UTC

Return-Path: <Andrei.Popov@microsoft.com>
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 C3D2D130F30 for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 13:08:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Level:
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 wr5qGS6E7wGp for <tls@ietfa.amsl.com>; Thu, 6 Dec 2018 13:08:01 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790114.outbound.protection.outlook.com [40.107.79.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37CE130ED7 for <tls@ietf.org>; Thu, 6 Dec 2018 13:08:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5+SEFoyJgfSuohsuTdwUXCbrUj9z571KQgcZR125NU4=; b=TD688XAn/GrMvkTDgEJwJXIEJ4xekxZuOtJXNp0u1PVYNfvFfVJ00Mx70KOsyVfcgTJkgyTCj9FW+/VzsVY5EPS/zu2N7hnNoRvFvzR0u+1tENodOurH36KiYB3wjJOfnw58/EtPZEBQS9mvxOPOCQzIyy1YvBqvGrrzGWOx894=
Received: from SN6PR2101MB1055.namprd21.prod.outlook.com (52.132.115.16) by SN6PR2101MB1006.namprd21.prod.outlook.com (52.132.117.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1425.0; Thu, 6 Dec 2018 21:08:00 +0000
Received: from SN6PR2101MB1055.namprd21.prod.outlook.com ([fe80::2902:9c4b:abe3:5710]) by SN6PR2101MB1055.namprd21.prod.outlook.com ([fe80::2902:9c4b:abe3:5710%2]) with mapi id 15.20.1425.009; Thu, 6 Dec 2018 21:08:00 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] ETSI releases standards for enterprise security and data centre management
Thread-Index: AQHUiVXbSQd8ESeelkaHiH5z15w1GaVqCxWAgAIRyACAAqqFAIABCW0AgAARrwCAABOTgIAAAw6AgAALxACAAFddgIAACkUAgACRLzCAATkngIAABUEA
Date: Thu, 6 Dec 2018 21:08:00 +0000
Message-ID: <SN6PR2101MB105593ED12E9110068F9808F8CA90@SN6PR2101MB1055.namprd21.prod.outlook.com>
References: <CADqLbzKd-AgDRv2suZ-0Nz4jNUqKg0RNT8sgQd-n793t+gEN3g@mail.gmail.com> <CAHOTMVKZT1ScvHeP3=Kv2zodVimHkaAtG-2DTq6ojnF+q-OMSQ@mail.gmail.com> <20181202233553.GD15561@localhost> <CAHOTMV+vPkM-=Qsto-8-ipFuGsNKkH_U=BEY_mB=7CM7tto3Mw@mail.gmail.com> <38D10A65-B4EE-4E81-8EA4-D69514F7F47B@gmail.com> <51754d91-c00c-0cad-ecd6-8db74544d26a@cs.tcd.ie> <A7423BAF-398B-4BBE-81AC-364CE748D6B1@gmail.com> <9344c0e1-f484-2b4b-8594-1d29731f6b7a@cs.tcd.ie> <01429BF7-BF1D-4F1C-9E18-D796A5585E62@gmail.com> <2F72F9A9-1556-4F44-8BBA-4D4CDD1A310C@akamai.com> <cd138d5d-37be-acee-297c-011227e98b99@nomountain.net> <SN6PR2101MB1055D37EB2DD393B9DB042238CA90@SN6PR2101MB1055.namprd21.prod.outlook.com> <87d0qee736.fsf@fifthhorseman.net>
In-Reply-To: <87d0qee736.fsf@fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:8:28b5:a023:971b:e42c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1006; 6:JhTPoFffdbMC74biAsrYijlHf7vUzjQxHbiUTGc784JXm3aRvumEQ9dyyQ3HpgsTBmX8TawaQlcEEySs0GPpoo0fstzbZ/iu4AB5yMDVbp+jUVUFB3cx37e6h5zC0yxsCJKYRtNB1DfecuCOmiB4WnegXqVHJV9LHT8HrpDk+UUQwC90AU6KbTqEgLPqd6dh3bBDPYpd94Kjp+ShI1z61jJBQNRutyKQBa3cUkEBYKPRgPIRG+g1QqE4TmhRZSzIou/Sp/zcyBvOkjgUhZ7MWXMQ97D79bcrbd/2G9dU5tfgnqP7FsfNzf6Mg/fs5CT6MMMVGjl12kdelYVajI7GDvIxakBSxaGJY6N8DN1Oro9w5wxTdCnpL8QmYFrV1POLzdY1Ft5PBWXOvQOgHvDSiiUEdMD01b81vu4fgn4RBQ8fBv5BAa0p6NzEqI1QczzkgWNY4CrW1wMcUEnPWt25RA==; 5:yU5tj5KXQBrhfK1u5sEa/LREOvuf1hyGv7mYzT12jMkn3J8xN07u+IaN9Fb1SCrDs390H2DugZE7w/JzNkr4BW9IPmzKu4Szq4RRKf/qpAkB6dfggfdyd4suOONyHtNTBqlejvyo96MDe/9kPMV2PnIpk5VIdD4tFA04P433sCQ=; 7:UywFJq3VbGVpz284A5mxZd/mJ6LfC/c5vSDQkoqMGTQFqpPvcPWicmvurovrphfFGpKi0CDpdpDP975dEkYwrBw/MBz1FuUKzKEZVKIQuHvTUpxrDMOTiJnuveaQhswK15qwiAhReSdZrY2R0Y19Ig==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c0028397-d37d-42db-b2e7-08d65bbee778
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:SN6PR2101MB1006;
x-ms-traffictypediagnostic: SN6PR2101MB1006:
x-ms-exchange-purlcount: -3
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-microsoft-antispam-prvs: <SN6PR2101MB10067D5350415F09B06E4F2B8CA90@SN6PR2101MB1006.namprd21.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230008)(999002)(6040522)(8220035)(2401047)(8121501046)(5005006)(3231463)(944501520)(4982022)(2018427008)(10201501046)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:SN6PR2101MB1006; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1006;
x-forefront-prvs: 087894CD3C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(396003)(136003)(366004)(376002)(13464003)(199004)(189003)(74316002)(316002)(102836004)(46003)(10290500003)(22452003)(53546011)(68736007)(14454004)(6246003)(6506007)(186003)(72206003)(478600001)(229853002)(110136005)(106356001)(5660300001)(7696005)(6436002)(8676002)(76176011)(81156014)(8936002)(86362001)(93886005)(305945005)(7736002)(105586002)(2501003)(86612001)(11346002)(99286004)(2906002)(25786009)(33656002)(9686003)(55016002)(81166006)(71200400001)(8990500004)(446003)(10090500001)(256004)(15650500001)(6116002)(486006)(97736004)(71190400001)(53936002)(476003)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1006; H:SN6PR2101MB1055.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Q6JDKTuIaMe0SEo0v01APGZlDlMETspaKjzng/qfRgpcFjMgteslaBlqcyvw2a12ANDR2o92T1s326NOP+mQjQc2sq4i2t0xuavzN9Wy2DKXj+XGmDu4/9G0wXajnQ0vcwcjAN/7SD8e2MFH86VuRbM8jc97ODGYwOLTZD5X27YKWBKlb3Y57bvAvFBUV+d/wyrndznkKGcq1PIEDMWvz3Eyswv0vLGIZfgEc69yMWrBY6EZT9OLgiIEBcUB9qYtYruPwnqliQ3FX330FPoDzmJwQixMXH+4uKBgW1p/BTDfXIs7tLFwLpevBzJpJiDbTCOGC+3r+aHECNbS0RflYQK4CtHEMaJpQJOa35B0LUI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0028397-d37d-42db-b2e7-08d65bbee778
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2018 21:08:00.3393 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1006
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VsUTHGBCmzncUM2l5G-v_jz8_14>
Subject: Re: [TLS] ETSI releases standards for enterprise security and data centre management
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Dec 2018 21:08:05 -0000

> What kind of load are we talking about?  
~2500 full handshakes per sec, basic workstation HW.

> Which server implementation?
HTTP.SYS/IIS.

> If the amortization is spread across, say, all handshakes within 2 seconds, is the performance impact still significant?
In a specific quick test that I did, there was no significant perf impact with key reuse time > 1 sec. And I could probably get it down to sub-seconds on my HW. But HW specs differ between TLS servers; our current "ephemeral" key lifetime is a generous 30 sec., mainly because we saw no reason to push for a lower key lifetime.

> So it's conceivable that truly malicious servers would do this, of course,...
"Truly malicious" is perhaps an overstatement for this easy workaround explicitly permitted by the "Enterprise TLS" spec:
"In some essential circumstances, the visibility information field may be omitted."

Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing connections to "enterprise TLS" servers would probably qualify as "essential circumstances", at least to some operators.

Cheers,

Andrei

-----Original Message-----
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>; 
Sent: Thursday, December 6, 2018 12:25 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>;; tls@ietf.org
Subject: RE: [TLS] ETSI releases standards for enterprise security and data centre management

Hi Andrei--

On Thu 2018-12-06 02:10:06 +0000, Andrei Popov wrote:
> I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will cost servers some perf:
>
>    "Given the concerns in Section 2 and the necessary client mitigations
>    in the subsections above, servers need to avoid giving the appearance
>    of using non-ephemeral DH.  Servers MUST NOT reuse ephemeral DH
>    shares."
>
> In our tests, we see significant drop in handshakes/sec on a busy TLS 
> server with ephemeral DH share reuse time < 1 sec.

interesting, i'd love to see more details on those tests if you can share them.  What kind of load are we talking about?  Which server implementation?

The cost here is in the fixed-base operation, iiuc, which is the cheapest part of the handshake -- DH share reuse allows you to skip this one step per handshake (or rather, to amortize the one step across multiple handshakes).

You mention a cutoff of 1 second.  If the amortization is spread across, say, all handshakes within 2 seconds, is the performance impact still significant?

If the draft's server guidance were to be amended to suggest avoiding DH reuse for more than 2 seconds, and the guidance for clients to track added a buffer of 2 seconds before rejection, would that satisfy your concerns about performance under load?

> Also, won't the "enterprise TLS" server just create a bunch of static 
> DH shares and send different ones at different times, thereby avoiding 
> detection by most clients?

I don't think that the intent of the ETSI spec is to encourage non-visible use.  They've specifically stated visibility to clients as a primary goal, and acknoweldged that "Annex A" servers would be in violation of their own goals.

So it's conceivable that truly malicious servers would do this, of course, but they might also just publish the master secret on twitter too, and the client wouldn't know how to detect that inband either.  But for the misbehavior that we *can* detect in-band, a responsible client should be aware of it and avoid it, right?

       --dkg