Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-03.txt

John Mattsson <john.mattsson@ericsson.com> Thu, 04 April 2019 09:32 UTC

Return-Path: <john.mattsson@ericsson.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 9716D12047B for <tls@ietfa.amsl.com>; Thu, 4 Apr 2019 02:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 g7diWZsNsqQd for <tls@ietfa.amsl.com>; Thu, 4 Apr 2019 02:32:32 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10082.outbound.protection.outlook.com [40.107.1.82]) (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 F3175120479 for <TLS@ietf.org>; Thu, 4 Apr 2019 02:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XE9ouXo5D+lA1IX0GnJudijksetrqpvOsVgDzw921Xo=; b=USlq2jFw6RVyLnwD1AFWQiZwWNzzowb2djNeNw765FkilN0dmY5EkbREcsv2nXHCmUTkj3OX6s5MlgVHwiD2+jhSfKJA/O6kAXMOPoqJ7cJjrZlsWs+GSAwb377ovUmh4kMBf2mUWgJy5Yhk66eQ5nUkZ8BKg1vkJYmqSqmHp88=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4394.eurprd07.prod.outlook.com (20.176.167.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Thu, 4 Apr 2019 09:32:28 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc%5]) with mapi id 15.20.1771.007; Thu, 4 Apr 2019 09:32:28 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-03.txt
Thread-Index: AQHU6slRzH8y+q8uF0qL4CX3/sObuQ==
Date: Thu, 04 Apr 2019 09:32:28 +0000
Message-ID: <3E47BF4C-48DA-4FEB-8845-A449EABA274D@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.1.190326
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [82.214.46.143]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b1dab7c3-8e2d-4016-5941-08d6b8e07491
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4394;
x-ms-traffictypediagnostic: HE1PR07MB4394:
x-microsoft-antispam-prvs: <HE1PR07MB4394BFAF57ABDA5568F0120B89500@HE1PR07MB4394.eurprd07.prod.outlook.com>
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(366004)(39860400002)(346002)(189003)(199004)(8936002)(33656002)(14444005)(256004)(5660300002)(106356001)(26005)(97736004)(99286004)(6486002)(81156014)(81166006)(68736007)(6436002)(476003)(2616005)(71200400001)(486006)(2906002)(71190400001)(66066001)(36756003)(478600001)(83716004)(7736002)(53936002)(25786009)(102836004)(305945005)(82746002)(58126008)(229853002)(8676002)(44832011)(15650500001)(5640700003)(86362001)(105586002)(6246003)(6916009)(2351001)(3846002)(6116002)(2501003)(316002)(6506007)(14454004)(6512007)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4394; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: YMT30yclgg9WyDxkMn1i9BMjH+bRYv7h9e4QDxl/poztHcaw1EWgGYd7O/i+o1GmqG9wfr9nrrky2OqIBCYQXZY3P9s2uTRgZMNmR5ftrY/YPctOZAUCMzkuT32C+Xc/HtOs4+Od+tsgWYZO88wHsGo+hH/wR1MhAMMVtBBTtgywh7LKWrHGVhz8QzGT25c6xM5qzjPq3LFuJEbGAC39q98KNWdhUEAtDH+ABQnDUtxoHxNz0k55kAxlqIA7jUissG9QvZ0F4UCWISfJrwox7awasSpq7bmGwWufu7XenrUWGsHsv06con4bfTuXWpqv1eo9CHayw8GC4z29QoUJxq4kGc3SrNDOOkAanYzIV9DDbzywwy8CZ2DyyGI/UYRHbrwkj5glLaLnLf/l57yqzwBpxoIp0FTPpg1gnlc7pi4=
Content-Type: text/plain; charset="utf-8"
Content-ID: <A8AA9A8F79F8D647B051B652EE85A626@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b1dab7c3-8e2d-4016-5941-08d6b8e07491
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 09:32:28.5660 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4394
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GtNWs3YmIKM8LFMXsT-stPg5P-Q>
Subject: Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-03.txt
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, 04 Apr 2019 09:32:34 -0000

Hi,

This draft is very well written, I mainly have high level comments:

- I think there is an overlap between draft-ietf-tls-subcerts and draft-tschofenig-tls-cwt, which also propose a form of delegated credentials. CWT is an existing format, that draft supports delegation on both the client and server side, and does not require the certificate to be sent. On the other hand the CWT draft lacks a lot of the security considerations of the DC draft. Could these ideas be combined? Having two delegated credential formats in TLS does not seem optimal unless the belief is that they serve very different use cases.

- Only supporting delegated credentials for the server seems very limiting. What if I have a virtualized TLS client talking to a virtualized TLS server? I see that this was recently added as issue #24, I support solving issue #24.

- Abstract: "without breaking compatibility with clients that do not support this specification."

I do not see how... The deployment scenario is that the CDN or remote data center has the DC private key, but not the certificate private key (as it is not trusted enough). LURK/Keyless SSL clearly benefits from DC, but while LURK/Keyless SSL can be used without DC, use of DC with any clients not supporting DC more or less requires LURK/Keyless SSL. Not giving guidance on how to do the interface between Front-end and Back-end seems like a bad idea. 

I think the text about compatibility need to be changed. I think it needs to be clear that until 100 % of clients support DC, LURK/Keyless SSL is a requirement.

- Section 1 - Could add "The server operator can only use validity periods supported by the CA" to the examples as that is one of the benefits of DC highlighted below.

- Section 3.1 "if the extension is not present, the server MUST NOT send a delegated credential."

As often requested by Jim Schaad, could you formulate this as a positive sentence instead. What should the server do in this case, terminate the connection? Use LURK? 

Security considerations:

- "TLS private key" is not defined and in fact TLS uses many different private keys.

- Add "The extension creates an unencrypted signal that might be used to identify which clients support delegated credentials." (text borrowed from the sic extension)

Cheers,
John