Re: [TLS] security considerations for draft-rescorla-tls-subcerts

Subodh Iyengar <subodh@fb.com> Wed, 05 April 2017 16:07 UTC

Return-Path: <prvs=5268bd8a47=subodh@fb.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 9B32412704B for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 09:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=GINeeFaC; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Cg3O6caa
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 tBYIeuJ7oZWy for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 09:07:43 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 BB2DC126C89 for <tls@ietf.org>; Wed, 5 Apr 2017 09:07:43 -0700 (PDT)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35G3upE009144; Wed, 5 Apr 2017 09:07:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=e1dbtvAvbSOAs47NigregXFpU5R9rkB2P+o9egVyA2c=; b=GINeeFaC9QVQ+IVHHVUxVpc2xBCwceJrMH42JxWnJBSafIHdF0TODbIV9vSWqIlUsSpR mu2XXQJY3Z8E9f73RXyk0t+CZ1s9M3UOJ6EGYrGmVSutSWy6oVtZmOUu84Er15f5wrsb BnTHZi/pzfBug5yqGETmTFX0sklkIT3v3As=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 29n3qt01c6-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 05 Apr 2017 09:07:20 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 5 Apr 2017 12:07:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e1dbtvAvbSOAs47NigregXFpU5R9rkB2P+o9egVyA2c=; b=Cg3O6caaNNhAkVCS4xT/uT7cGH2Omc1ei7uUdakOP8RedLfpvsvhwYoel85fQInY0trnO5H6LD1m/GLoPngM1WpFHE1duVl6K154mRclYExaCv/D9N7uOivcQJho3DJdFauUPN+SBXiw/gzAexb+y7+H79iv5i/oOWyNPuP29Nc=
Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Wed, 5 Apr 2017 16:07:16 +0000
Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1005.020; Wed, 5 Apr 2017 16:07:16 +0000
From: Subodh Iyengar <subodh@fb.com>
To: Simon Friedberger <simon.tls@a-oben.org>, "tls@ietf.org" <tls@ietf.org>, Richard Salz <rich.salz@gmail.com>, "Kaduk, Ben" <bkaduk@akamai.com>
Thread-Topic: [TLS] security considerations for draft-rescorla-tls-subcerts
Thread-Index: AQHSqaBOocVmAQvSZkGxKH7FNtBXA6GxLuRegASs84CAAOJSgIAAAPGAgAAA7ICAAC8aDw==
Date: Wed, 05 Apr 2017 16:07:16 +0000
Message-ID: <MWHPR15MB145571244E36DA811C5F6CDCB60A0@MWHPR15MB1455.namprd15.prod.outlook.com>
References: <m27f362zxm.fsf@dhcp-89ad.meeting.ietf.org> <MWHPR15MB1455F0758BE196CAB4BDF8BDB6360@MWHPR15MB1455.namprd15.prod.outlook.com> <c5799647-4568-4cbf-1708-52934a961f67@akamai.com> <d93fe5c1-5236-f86c-34d0-2606204d672d@a-oben.org> <f4aeff835aa4437f8d2996cba926bc11@usma1ex-dag1mb1.msg.corp.akamai.com>, <df23dab4-d8cd-7d7e-3372-1dfed4457d45@a-oben.org>
In-Reply-To: <df23dab4-d8cd-7d7e-3372-1dfed4457d45@a-oben.org>
Accept-Language: en-US
Content-Language: en-US
X-Mentions: rich.salz@gmail.com,bkaduk@akamai.com
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: a-oben.org; dkim=none (message not signed) header.d=none;a-oben.org; dmarc=none action=none header.from=fb.com;
x-originating-ip: [25.173.47.4]
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 7:d3BnZLv7/o4eMXd5oW5Z1iPG8UNg13VcFK4feYOpRPK4s/E5u93TiwznHVQuqn3WlNTeLyvD+QsW1LSuKvdDza5hKD5VX0UZZ5V2VDRxWqTPww8SC9sAFdnIVVYOgaHD9Be4SR73fIZLSgQ40Z1y23miNTn2SMpH9YAiMIdW852KyCMGHzOCJSjLWj0eItX1Y0zMBtEA4i3rx0NDy0r299NpA2GQ7cYk5TUL+XaQjl5/oiExRSwI6FGbM++KgBaz1JKJfg0kOO8cmVcBrdQ2JNj+S5qw0i8p/flaYFX2nIQlighaTUw8aLCWFwYhBR09Ky9Ags4mCQGF5e5kaxliwQ==; 20:0H0bxgCxUqU+w4OVz9bwaMR0ciYvWwdY0/icI7u7bLK4OdWB9exonqADNewT4OL3iI3fKWDqsMHv4urT3/mmmw3NMSGNNru2SZyiEh48lXTHCrknbKL2TkkwE+Hx8AENQSqJoOsMO2Y1u9M+VWM3320JYwiDq/sw8QmN+abqack=
x-ms-office365-filtering-correlation-id: 3854855c-03f7-4b9f-d630-08d47c3dd4a3
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MWHPR15MB1455;
x-microsoft-antispam-prvs: <MWHPR15MB14556F73053AE79A13A17C0BB60A0@MWHPR15MB1455.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1455;
x-forefront-prvs: 0268246AE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39840400002)(39450400003)(39850400002)(39410400002)(24454002)(377454003)(6246003)(66066001)(33656002)(53546009)(25786009)(5660300001)(229853002)(7736002)(15650500001)(74316002)(7906003)(38730400002)(39060400002)(86362001)(575784001)(6116002)(189998001)(3846002)(102836003)(7696004)(3280700002)(93886004)(6306002)(54896002)(236005)(9686003)(122556002)(2950100002)(6506006)(2906002)(2900100001)(53936002)(50986999)(76176999)(54356999)(6436002)(606005)(8676002)(77096006)(81166006)(230783001)(8936002)(55016002)(2501003)(99286003)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB145571244E36DA811C5F6CDCB60A0MWHPR15MB1455namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 16:07:16.6317 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_12:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wp8_e85kSJVZDycJskjtvH5_yA0>
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts
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: Wed, 05 Apr 2017 16:07:46 -0000

> There is also an alternate world in which the TLS terminators should not have certificates/keys on them but it is okay to give them delegated credentials.  Here, one benefit is clear: performance.  But the attacker capabilities against which this is supposed to be useful/acceptable remain unclear.


@Kaduk, Ben<mailto:bkaduk@akamai.com> I thought I expressed this in the use cases, but I might not have been concise enough, so I'll try again.

In our original use case when I say less-trusted I mean a CDN running in a different country or a ISPs data center which has a different physical security constraints. The less-trusted and trusted hosts do trust each other, i.e. they could trust each other with the keys however physical security constraints would prevent this.

The threat model here is that since if a less-trusted host having a key is compromised for a certain period of time without detection, and an attacker can steal private keys during that period. In many situations we are fine with giving the TLS terminator a certificate / key, i.e. they actually have a trust relationship, however we want a compromise to only give the attacker a limited power to use the credential. Revocation is arguably effective, so we would not be okay with giving a less trusted host a long term private key. However we'd be okay with giving a less-trusted host a short term key.

> My apologies for being blunt, but that text reads like a solution in search of a problem.  That is, what is expected to be achieved by having shorter-lived credentials?  Is there a threat model for which having them brings security advantages, or are there operational concerns, or ... ?


Hopefully the threat model above should answer this question. I thought I was clear about the use cases. I think just being able to deploy shorter lived credentials to even higher trust areas has an advantage beyond the use cases of less trusted locations in case they are compromised.


>  But as currently specified, that low-trust short-lived certificate, if captured, can be used to spoof the operator anywhere else in the world.  Yes, for a shorter time than the long-lived "true" key, but this still seems like a footgun.

@Richard Salz<mailto:rich.salz@gmail.com> There is no footgun that delegated credentials adds beyond what operators can do right now. Operators can go get a short lived CA issued certificate and deploy it, however the latter is much harder to deploy. See the original email for rationale about this.

>  To me the increase in security weighted with the difficulty of obtaining
such short-lived certificates from a CA probably does not justify the extra
complexity of adding subcerts.

@Simon Friedberger Do you feel that short lived CA certificates are actually deployable in large server deployments? I do not see that to be the case. I see a security gain here but just being able to deploy short lived credentials to not only less trusted locations, but also to more trusted locations as well which is another use case that I want to use this for.


Subodh



________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Simon Friedberger <simon.tls@a-oben.org>
Sent: Wednesday, April 5, 2017 5:39:17 AM
To: tls@ietf.org
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts

I agree, that's why I only see a security gain if the theft of the
certificate remains undetected.


On 05/04/17 14:35, Salz, Rich wrote:
>>    Server operators
>>    often want to create short-lived certificates for servers in low-
>>    trust zones such as CDNs or remote data centers.
> But as currently specified, that low-trust short-lived certificate, if captured, can be used to spoof the operator anywhere else in the world.  Yes, for a shorter time than the long-lived "true" key, but this still seems like a footgun.
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=tBKp_cuV26a4AtN1WOEPpqNTgBQUE4Cg9cqS-Fdw5nI&s=2JwQdlzcb8E6z6hDnhnxLFQZOabIRGTGcJmtBCTj46s&e=