Re: [TLS] draft-rescorla-tls-subcerts

Andrei Popov <> Fri, 15 July 2016 00:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27F4612D140 for <>; Thu, 14 Jul 2016 17:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hwh_-h6gws-T for <>; Thu, 14 Jul 2016 17:28:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30C6A12D0C5 for <>; Thu, 14 Jul 2016 17:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oSIZlPr307vIFatIY/pJ+WS2jdXE86XHy6qUq5u9lrw=; b=b0dji+TmVIOEj4xuP6SYwMQOGbdYHy9RJ/Rc8Oa3U23keZYb7LwcZES0yIufoB1SOhj1wrbS7dkPWpcVd/CZY9MFy+9ZXfkPa4gmKYNluMAnj2NNqt1gHjN70+6s7ZeYOS9cPb02YaF/0UJZRHro0hXOU1aWjmsF4v7CcXXaYLI=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Fri, 15 Jul 2016 00:28:19 +0000
Received: from ([]) by ([]) with mapi id 15.01.0534.023; Fri, 15 Jul 2016 00:28:19 +0000
From: Andrei Popov <>
To: Eric Rescorla <>, "" <>
Thread-Topic: [TLS] draft-rescorla-tls-subcerts
Thread-Index: AQHR2IXi5/u6A9XC6UWhBIud7iIL56AYq7cg
Date: Fri, 15 Jul 2016 00:28:18 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:e::1d2]
x-ms-office365-filtering-correlation-id: 81c5b733-fc02-49a6-f025-08d3ac46eb9d
x-microsoft-exchange-diagnostics: 1; CY1PR03MB2153; 6:KRDBhsMBjBantk6Llx/9QzqCMFVAQ4SRSFiEEipV416rOqqPF9KC9BfgpLYOoT7aBqnqPjCOcqPlszh7XEjimQ059fPw5LT+bwKDtmGMs16wx0a+R+q+fIIlXmFlsyYm9Cn8gwKAAnsUnDSIFqmjip6C6G+CQ+YrGKEyF+KClSb0ySG1Q8nNUYImycieH8T9vMIUD7RdkAw+m66J6y9+bFxjP8Uj3ylf4IiLMjBtc3X69K48RJps0v3Y4iNHMrtrB3PUJRgymPNkv6xHtMR7fD/3Umb00CRjzfZn4vo2XQXl7svQ7r7Jem0d2b/DKLaLgMVfUsjFzAl6i7r4LfuMLQ==; 5:tjpTawuqYgQmiS89sNSlRfYDEAXWSW8R0FtjNAypRBM72cONtjuR379C/y2o2LGAS74Yq3Q8uM54myqgncMLCyZsYGIAThhTPC4yeWj1qbMZLu4/AO2RJMNYh79vMsTLPqm6fwSlGUvpNEUrQRn+Vw==; 24:aPnkYbIfEOFdeaFEZ0TAIfEePSxVpH9bXniKrGwYfikZceWhkJMr3bhW+Fx7FAK1de0/WhLB4mfGrXNBlNtTMx0VIMTFQdkqc+S+8QrfTFU=; 7:QhSys6CJIOX6mve/PrUffsVSHQjs9CBaRYW80R46eOXgQgsFvTmcafckjabu3rDgU//TOFmDjRQfWcsgJyuxbOLqWaX8EY/71nmV+b/TeYkR3BpJQruV8FiczytZFhcpaKFFu+PzxcTeSVejTHhny+BjfbCNVO5eeOT+Uy0xSJEx56FGvSy+8IFDVoAIPLNwtEAABZg9/MQ9u+j8WacPLNYqJun6+MfUi14bHunZqPCJmFREiTfDYlnECaY810If
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2153;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2153;
x-forefront-prvs: 00046D390F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(8936002)(7846002)(99286002)(9686002)(3660700001)(19617315012)(74316002)(10290500002)(7696003)(7736002)(5003600100003)(97736004)(68736007)(5002640100001)(189998001)(7906003)(3280700002)(92566002)(11100500001)(8990500004)(107886002)(10090500001)(19580395003)(2501003)(5005710100001)(230783001)(10400500002)(8676002)(19580405001)(106356001)(76576001)(54356999)(106116001)(105586002)(586003)(5001770100001)(2900100001)(2906002)(87936001)(81156014)(77096005)(86362001)(2950100001)(81166006)(50986999)(33656002)(19609705001)(101416001)(15975445007)(19300405004)(86612001)(102836003)(122556002)(790700001)(6116002)(19625215002)(16236675004)(76176999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2153;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21551F88A99C2CEF07548A2D8C330CY1PR03MB2155namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2016 00:28:18.8475 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2153
Archived-At: <>
Subject: Re: [TLS] draft-rescorla-tls-subcerts
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Jul 2016 00:28:23 -0000

Naïve question: why not simply get a constrained CA certificate and issue short-validity end entity certs? Unless I’m missing something, this would work with existing TLS implementations, no extensions required.

Short-lived credential approach seems more viable than draft-mglt-lurk-tls-requirements-00 (which requires an additional round-trip between the Edge Server and Content Provider).



From: TLS [] On Behalf Of Eric Rescorla
Sent: Thursday, July 7, 2016 12:29 PM
Subject: [TLS] draft-rescorla-tls-subcerts

We've talked several times about designing some sort of TLS delegation
mechanism. A few of us got together and put together some initial thoughts
about the options at:

The general idea here is to have some mechanism for allowing what
are effectively end-entities to issue short-lived credentials that allow other
entities to act on their behalf (e.g., for CDN use cases).
Comments welcome.

In terms of the security analysis, it's obviously very important that this mechanism
not present a risk to existing TLS servers. The mechanism designed here is
intended to be future safe in that sense, though perhaps we've missed something.

I also wanted to clarify a couple points about attacks where the certificate that signs the delegated credential is also used for ordinary TLS operation (which generally is a practice that's pretty scary). As noted above it's important that existing certs not be usable this way, but maybe future certs would be.

1. It's important to construct the delegated credential in such a way that you can't use a TLS server as a signing oracle. If you choose "option 2" where you define a new structure, then it's probably sufficient to use the TLS 1.3 "context-including" digitally-signed production proposed by AGL. If you you choose "option 1" where the delegated credential is an X.509 cert, then you'd need to make some rules about fixing portions of the cert that the TLS client can't control.

2. If you're concerned about attacks like those of Jager et al. which exploit RSA decryption, what's important is that the attacker not be able to get the server to do TLS 1.2-style static RSA with the key. Playing with the usage bits definitely makes it harder to configure the server this way (because it's likely to cause bustage) but may not be enough, because sufficiently busted clients and server might be willing to use them that way anyway.

In the next rev, we'll update the draft to make these points more clearly.