Re: [Lurk] [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

"Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com> Tue, 18 July 2017 11:40 UTC

Return-Path: <thomas.fossati@nokia.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C3131897; Tue, 18 Jul 2017 04:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=nokia.onmicrosoft.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 st73GRmZsS9s; Tue, 18 Jul 2017 04:40:44 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0124.outbound.protection.outlook.com [104.47.0.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F501317BE; Tue, 18 Jul 2017 04:40:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qHvBAJ3korO/NIuGyHqWvAmuBmxN4k3CG5JBcalNEhY=; b=MUHd/y8SHG9L9lEpc4tMhSQorS888mbsXg9GkHe2wLSPYBnJBmzI/gEFld3EPornzRCM/d4UmlFyzPIImIGVH3JVVpH+8l+Mq2SqnaYY0TcNjmuTVgEGDOpB4R2ijVcWNQ8ExYbIDHXtpOeXAp4HxcLeJwnJN3MV0N4LvMMSfQI=
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1215.eurprd07.prod.outlook.com (10.163.169.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Tue, 18 Jul 2017 11:40:40 +0000
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::d0a5:5d5d:c414:4b10]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::d0a5:5d5d:c414:4b10%14]) with mapi id 15.01.1282.008; Tue, 18 Jul 2017 11:40:40 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
To: Nick Sullivan <nicholas.sullivan@gmail.com>, Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
CC: "lurk@ietf.org" <lurk@ietf.org>, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
Thread-Topic: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
Thread-Index: AQHS0CpTH+tPQf6rjUes9Cw+A0SKZqJZy5mAgAAaMYA=
Date: Tue, 18 Jul 2017 11:40:40 +0000
Message-ID: <61435CE8-3A17-4773-8329-54908985FB80@nokia.com>
References: <601C7C89-F149-4E97-A474-C128041925EA@sn3rd.com> <0956863E-7D11-47A7-BD67-5D9DB3A3574A@sn3rd.com> <CAOjisRwm=YRigbTuNSuXUAK_iQkPZnA=R8OSwHRDBGU477vzjg@mail.gmail.com>
In-Reply-To: <CAOjisRwm=YRigbTuNSuXUAK_iQkPZnA=R8OSwHRDBGU477vzjg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [81.134.152.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB1215; 7:NLWmWGuiC1CXxDn678PD6o1suwea3ShILEJXbBlMgEL28pwVPO3dZDVEySi6nRoRoW9E1WOniPdfIPOgJwBUL81Jw+OoS2zGtMlcBVrK2zt6aAlqZGBpgLgmC+PQqblIQDUbSbDVmPp21/vKGVLOamYBPvi3fd4mOnaI0SHjcTvdHFkGf911sVpC8QjiP+a9tvv9XJ5pTNXiObNkLYT245zwLP0A5iMrNS3tHkmLey07WH8sG4TEB8fPkDR0wBR1/wNzcUiv25k5GBpRfMquDGBH0zUogaDNwV8aQdGU+JIhWu/Rwbz6E+AGJDr2dmBCpGQa+jxXM/41qUqutP5chWHPd4ZU6Iwmt1Vdm00n69vyrtKEUQ6bzONYbsBQgavJkKbw24eqXrQO8u+zMR2iH6sWTrr8ZJ+r9Wnz8AhjXQtZiG6y020IADwDio19vOPlZabV+LSinIK5DcSDzDZ3JP9pOsEAJEU3PSaxjJTka16pobIJtDMbz94czoGS2WGDn8w6P8k95zJ7fL30gTBA26kyeTyVC7T9jyYgqJjFZP1UMGRMT2NZd6uXb1N+CLcXTDRQ8fGbZDBOqgvUcinuC15rc6K3i9JRKJl6oeI3IDxW9wRMJFdYgfeC976kW84UMcyIIg+XG/BaTcSGB6o77TuuhDHe2imYALtPa8EdFPofzyNa0gXtMceTk3z4m//7THP5TidFy8JV63L5qavJx6qoWJfvET9wVZq4NIU7oIrgkG27YMabeLlCvz9aPwMJfHWRQO442mh2Wf6ya3yvkh4gh1WkipgYtAg58i59Hn0=
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(24454002)(377454003)(39060400002)(5660300001)(6486002)(3846002)(6506006)(53936002)(6246003)(38730400002)(236005)(107886003)(6436002)(4001350100001)(53546010)(229853002)(83506001)(83716003)(54896002)(66066001)(6306002)(99286003)(54906002)(7736002)(6512007)(14454004)(33656002)(5250100002)(3280700002)(54356999)(36756003)(3660700001)(25786009)(606006)(2906002)(478600001)(8936002)(2950100002)(189998001)(6116002)(102836003)(86362001)(81166006)(230783001)(50986999)(76176999)(2900100001)(82746002)(966005)(9326002)(4326008)(8676002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1215; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-office365-filtering-correlation-id: 37a92acb-1af3-4ceb-a048-08d4cdd1d0e0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR07MB1215;
x-ms-traffictypediagnostic: VI1PR07MB1215:
x-exchange-antispam-report-test: UriScan:(151999592597050)(133145235818549)(120809045254105)(26388249023172)(236129657087228)(150554046322364)(48057245064654)(148574349560750)(21748063052155);
x-microsoft-antispam-prvs: <VI1PR07MB121599FCEA8383B3AEE5140F80A10@VI1PR07MB1215.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1215; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1215;
x-forefront-prvs: 037291602B
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_61435CE83A174773832954908985FB80nokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 11:40:40.0604 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1215
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/gXWhBenkQrRYs3O5JtCjZ70x_j4>
Subject: Re: [Lurk] [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jul 2017 11:40:47 -0000

Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing per se.

I had expressed a couple of concerns at the time the call for adoption was first issued [1], which I think are still valid.

Could you please comment on / add them to your pro-cons analysis?

Cheers, thanks,
t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org> on behalf of nicholas.sullivan@gmail.com<mailto:nicholas.sullivan@gmail.com>> wrote:

Sean,
We've had some additional discussions in person here at IETF 99 with folks who were in the proxy certificates and short-lived certs camp, and we think there is now more agreement that the mechanism described in this draft is superior to the alternatives. I've included a summary of some of the pros and cons of the approaches:
Proxy certificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
Con proxy certificates:
- Proxy certificates adds additional complexity to the delegation other than limiting the time period (full X.509, additional constraints  such as hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as part of TLS:
-- There have been problems and inconsistencies around pathlen and constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated creds (which can easily be implemented in TLS as demonstrated by the 3 interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE cert. This is a binding weaker than delegated credentials which includes a signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
Pro short-lived certs:
- Short lived certs work with existing libraries, no new code changes.
Con short-lived certs:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be logged in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must provide proof of domain possession to CA vs. internally managed credential minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials you can fall back to a LURK-style protocol with the long-lived certificate key.

Given these comparisons, we think the proposed draft is the superior option and would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner <sean@sn3rd.com<mailto:sean@sn3rd.com>> wrote:
All,

During the WG call for adoption, a couple of questions were raised about comparison/analysis of sub-certs versus proxy and/or short-lived certificates.  There is some discussion currently in the draft, but the chairs feel that these issues need further discussion (and elaboration in the draft) prior to WG adoption.  So let’s keep the conversation going.

J&S

> On Apr 12, 2017, at 15:31, Sean Turner <sean@sn3rd.com<mailto:sean@sn3rd.com>> wrote:
>
> All,
>
> At our IETF 98 session, there was support in the room to adopt draft-rescorla-tls-subcerts [0].  We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170429.  If you object to its adoption, please let us know why.
>
> Clearly, the WG is going to need to work through the trade-offs between short-lived certificates and sub-certs because both seem, to some, to be addressing the same problem.
>
> Cheers,
>
> J&S
>
> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls