Re: [TLS] HTTP, Certificates, and TLS

Mike Bishop <Michael.Bishop@microsoft.com> Thu, 21 July 2016 16:08 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 5B32012D528 for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 09:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 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, T_KAM_HTML_FONT_INVALID=0.01] 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 pQcfA7orMlvh for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 09:08:55 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0118.outbound.protection.outlook.com [104.47.37.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA17E12D50E for <tls@ietf.org>; Thu, 21 Jul 2016 09:08:54 -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=5bxMHk/ngWLvtfTv6JLUupNyzXHlmocgCzgNnSLIYjo=; b=KT8EfGa6WmrbiX1HHasVN7locx7Cy7P3hiqxthLNnFXNGkuqFs+AnVyzEnqM8QwbCTtGXL8PjV6HeQB05ngD23vgrUhlp7WwMcxpT9zT0kELtQ8utQgaSMAaPAKOGNcJECmvIPMW0I66GPMmIcNxaT6vJvpa7OJnLPa7tMrS0qM=
Received: from BLUPR03MB1330.namprd03.prod.outlook.com (10.163.80.20) by BLUPR03MB1329.namprd03.prod.outlook.com (10.163.80.19) 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 16:08:52 +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 16:08:51 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [TLS] HTTP, Certificates, and TLS
Thread-Index: AdHjLHxhCRnLx2FySaWyrgvomVV7swAPA9OAAAARPNA=
Date: Thu, 21 Jul 2016 16:08:51 +0000
Message-ID: <BLUPR03MB1330C3D2AEC4876A9E74635387090@BLUPR03MB1330.namprd03.prod.outlook.com>
References: <BLUPR03MB1330AB57841AE0A68F460A9987090@BLUPR03MB1330.namprd03.prod.outlook.com> <20160721155713.795ED1A504@ld9781.wdf.sap.corp>
In-Reply-To: <20160721155713.795ED1A504@ld9781.wdf.sap.corp>
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:31a0:98ff:53f5:8cf7]
x-ms-office365-filtering-correlation-id: 93d1c3c7-6bfb-4647-0dca-08d3b1814eb8
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1329; 6:g+CF8chI68xH6BWkmJGSkyEVLVd/BgH2RHgOGEnfjOHUNXpZParY7crW38KtLDB4v6EdN378P4hogFiLnb+naSebaF1mwXL9zcIeHLXZAR67kJz9Nn17tf2olszU2qjpjIV70prFSyplT+NSxLPksbkbfmIlstdR/dtrRSlnib1F4VVHupSWZvZNDYpVA6dD3z0fJjhgk5zZgygt1AACmzY4NBtZ3nqhaTRCc/O85JXvPslhSyVy9LPPgdo7x+sokzSMigsYGmG/di215aBmbDXX02H/4DUlv2lh5yJhBzVswk9ASoMy89enebQy7N6aDJom69ZU3oMTSYj1Yw59Vw==; 5:myOTjeC7PkMkOZOx41gfPzVHwlEc1rE0M4E33GztTA5COT7i+evoDAvBUl31eo3nGCpkS/9b3vdAxmWJYtUByzii34NiYtlkjSF0dv4Wavd5mos8aMMfSyVh/i82Iw+/kJfzzEDQRHcgNSt99NZ0XQ==; 24:UTiTAjp1ym78+EHq6Tsdz/B7YDqeH1FiphPl4UCY/H8Pvh8jJ+RLQoTDbcTe8ey6GiiXIyqcEf351t/cm5ELMXSi0dqK+8/csXDTlbgUvSs=; 7:ze8d08wqbWKvUU+qQ+P3RH66AJcrZbvKqkYoNlQGaFIJPeLPwEvjdgHQcEh9vPCVtAmoRIeBP9cdoEm4EtOku+kVEDQKn6ppaTP+BC9M/1k0jaiUcAPanoFCp205J/TrdbGUd8DGB1ju+CxBg3KyUlx7BdjAfOVPdi7/DLsbdTcBoR4IjTTUr2iRqg9E/K4UMgazOJAZ2Z2+W0TelZ3uNLfB/N2/SyE3r1Ly+KTnHfexxa9wK/IJfk37GOJV8TLa
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1329;
x-microsoft-antispam-prvs: <BLUPR03MB1329D0FD6721B85C63F700D487090@BLUPR03MB1329.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(55761251573089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1329; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1329;
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(377454003)(189002)(13464003)(86612001)(99286002)(97736004)(2950100001)(2900100001)(2501003)(8676002)(561944003)(189998001)(101416001)(16236675004)(81156014)(9686002)(68736007)(8936002)(87936001)(33656002)(1730700003)(92566002)(81166006)(50986999)(76176999)(54356999)(3280700002)(122556002)(110136002)(19625215002)(19300405004)(7906003)(7696003)(74316002)(7846002)(5003600100003)(5005710100001)(7736002)(8990500004)(10400500002)(8666005)(86362001)(19580405001)(790700001)(3660700001)(5002640100001)(10090500001)(10290500002)(2351001)(102836003)(6116002)(5640700001)(586003)(5630700001)(77096005)(105586002)(15975445007)(4326007)(2906002)(76576001)(19580395003)(19617315012)(106356001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1329; 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_BLUPR03MB1330C3D2AEC4876A9E74635387090BLUPR03MB1330namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 16:08:51.5962 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1329
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/njiQf4tvB8owdYDQsK_k06R96GE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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 16:08:57 -0000

I assume you're referring to Section 3, SNI's ServerNameList MUST NOT contain more than one name of a given type?  Technically, we're not violating that, since we're not changing SNI.  The client requests a single identity in the TLS handshake, which the server provides.  Additional identities can be demonstrated later, regardless of where.



Or are you referring to the (lower-case) must not resume if SNI and the certificate used in the resumed session differ?  For HTTP, we're leaving resumption out of the picture, requiring that any secondary certificates be proved anew for each connection.  You're certainly correct that if the logic were moved to TLS, the semantics of resumption would have to be defined.  That may be a solid argument on why it should remain at the application layer.



-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com]
Sent: Thursday, July 21, 2016 5:57 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>;
Cc: tls@ietf.org
Subject: Re: [TLS] HTTP, Certificates, and TLS



Mike Bishop wrote:

>

> 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,



You are facing a MUST NOT in rfc6066 for this particularly bad idea.



I'm currently wondering what kind of (weird) TLS session caching strategy would actually allow you to create such client or server behaviour.

You're definitely in severe conflict with the "principle of least surprise"

in respect to deterministic behaviour of your TLS clients and TLS servers.



-Martin