[TLS] HTTP, Certificates, and TLS

Mike Bishop <Michael.Bishop@microsoft.com> Thu, 21 July 2016 09:39 UTC

Return-Path: <Michael.Bishop@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 9691412DC25 for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 02:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
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_H4=-0.01, 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=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 y2lyj0Tc_nos for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 02:39:02 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0095.outbound.protection.outlook.com [104.47.37.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2BE12DC16 for <tls@ietf.org>; Thu, 21 Jul 2016 02:39:02 -0700 (PDT)
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; bh=js+vQh67Q2iEHNzu8iYAo9p6O7pCSYp5IxlzAFBkZlM=; b=FDnqtMktxb+rQfPs4c9KdaVWuZ0ynwzhgntNLb23PuVeOLmN6ljk9cPfyt79SG0fplG92NzWQfPifY121m7SGJjN8AMGQvK46Bc0Fo9FuMJwh7nrcBxGD8OVlClSL8z1esAA/38bCZp4Fi8+tQXrK4v0Rkp0rg1GBlAUdYZvpx0=
Received: from BLUPR03MB1330.namprd03.prod.outlook.com (10.163.80.20) by BLUPR03MB1332.namprd03.prod.outlook.com (10.163.80.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.539.14; Thu, 21 Jul 2016 09:39:01 +0000
Received: from BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) by BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) with mapi id 15.01.0544.014; Thu, 21 Jul 2016 09:38:59 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: HTTP, Certificates, and TLS
Thread-Index: AdHjLHxhCRnLx2FySaWyrgvomVV7sw==
Date: Thu, 21 Jul 2016 09:38:59 +0000
Message-ID: <BLUPR03MB1330AB57841AE0A68F460A9987090@BLUPR03MB1330.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2001:67c:370:176:fd36:414d:818e:cc12]
x-ms-office365-filtering-correlation-id: 7fd64161-50c5-4125-f8e3-08d3b14ad7a4
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1332; 6:01hAaguqa2fo6ijpdnOD3+/tf43ihJMVgL8D0Im4SyDw5XQm6U5iFwenpVpTXfLxxQlJY210xOduksblU2KSI5tTUvNeDvIwRmRRvj8wYkZSSY7Hw5VcfH/nWMqQvOMqYI9X+uhAflbiy49Au4354D27ddM8V8GvEaX8tnzWGprPbxiveaZBe8+dhLVh4H8RvbO+fUHceQZRI2z+yQfeVBUtCnVCEQeVPcSPp7lAZHnm6u0bADtPJKLWx5fpJcgR4zrvhF9a3vmnJXsgrda0z7BM6pRTbzVOvQ/t0mOMFGGVJuuTEN/l93oP2uPE+mhoqy0g9/SrpoGTSL0c0T2VeQ==; 5:I8xB54yyWWiT3KzagWPFBvjUENZH//b2b7fqHtHatqC4XG/K5zOudIN099slwYt/Pi/z4IaWgjOtylWNXtPuwgEJP0hXueU0Pld38hKCdL6cf0+XM4gGvINM2URuPUkEU9b5IKGwgvfQ6Ey0YY6uwQ==; 24:bRHj3PgVq/Gr2NXXQaoCneT2BzWx51ivh8NFPfedODq5H9Yfs1RsEFwk2Z5C2lt4S+77DdO1YGDlqtS4NLYop24OZBqkhlmTT94o/y7s2Qk=; 7:qKbqpQDJ5JVKM/3MdxVGP3k4qDvCb7ePrhnU2paa9qBVIlJwj2nOGOFx3+vXpYor36nXKS0F/ASnyJeuGt+7Egt5d1nJBRxH4acAsB+xIGdaHUSDg/QD7yJ6wCIiSmY5qTlLMy3yVfutbVylq0oiwD9fA6w4mEc7qU7w7lXNhGfEdzEwXVpbBQFd5oon1xjgKr4T1ShOWqwgomKN+gRoh0zepHqgEZt0thtAmoB55NmvzQ63Z8sjtrzZs2CzBFV1
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1332;
x-microsoft-antispam-prvs: <BLUPR03MB13324383AE33628FDC0C191E87090@BLUPR03MB1332.namprd03.prod.outlook.com>
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:BLUPR03MB1332; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1332;
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(110136002)(68736007)(99286002)(189998001)(102836003)(6116002)(790700001)(10090500001)(4326007)(76576001)(92566002)(8676002)(1730700003)(105586002)(2906002)(10400500002)(586003)(19580395003)(10290500002)(5005710100001)(2501003)(5640700001)(97736004)(8990500004)(122556002)(5630700001)(19300405004)(3280700002)(15975445007)(8936002)(229853001)(16236675004)(33656002)(2351001)(81156014)(81166006)(5003600100003)(86612001)(87936001)(7736002)(7696003)(561944003)(106356001)(5002640100001)(19625215002)(86362001)(77096005)(3660700001)(9686002)(54356999)(2900100001)(7846002)(101416001)(50986999)(74316002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1332; H:BLUPR03MB1330.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 09:38:59.0559 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1332
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ayQ6yjTD5SbWmn0Pjat5fseVgQA>
Subject: [TLS] HTTP, Certificates, and TLS
X-BeenThere: tls@ietf.org
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." <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, 21 Jul 2016 09:39:07 -0000

Hi, folks -

Martin and I had come previously to the TLS WG to discuss our work with handling client certificates at the HTTP layer.  Based on that discussion, we revised our model to cover signatures of an exporter value and carry the proof in an HTTP/2 frame.  During BA, the HTTP WG expressed interest in flipping the model in the opposite direction - carrying additional server identities as well.  That means we now have a proposal for carrying both client and server certificates above TLS, found at https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.

We have also discussed that it might be preferable to pull part of this capability back into TLS, expanding post-handshake authentication to allow providing multiple certificates in either direction.  Since that would necessarily require additional work on that part of the TLS 1.3 spec, we discussed the possibility of splitting post-handshake authentication into a separate spec so that the core TLS 1.3 spec could proceed to WGLC as scheduled and take a little longer on the second draft.

Having spoken to some other TLS WG members, some people would prefer to move post-handshake authentication entirely to our layer.  While that's probably not feasible (HTTP/1.1 still needs post-handshake auth from TLS, regardless of what HTTP/2 does), we can retain our application-layer authentication.  This has the advantage of leaving TLS 1.3 unchanged, but keeps a security draft in a non-security working group.  We are concerned that, by doing this at the HTTP layer, we'll be missing necessary security expert review as this moves forward.  (EKR already suggested some necessary improvements to our signature model to prevent some pretty trivial attacks; these aren't reflected in the current draft.)  If that's the route we go, I would greatly appreciate some TLS folks visiting the HTTP WG and helping us review this draft.

I was on the "time permitting" list to present in the TLS meeting on Tuesday, and we didn't get a chance to.  We'll be discussing the actual draft tomorrow morning in HTTP; I'd be happy to have some TLS folks there to discuss the draft, and I'd like to get a sense from the TLS WG whether there's a preference for us to do this at the application layer or pass additional requirements to post-handshake auth.

Thanks!
-Mike Bishop