Return-Path: 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 ; 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 ; 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 ; 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 To: "mrex@sap.com" Thread-Topic: [TLS] HTTP, Certificates, and TLS Thread-Index: AdHjLHxhCRnLx2FySaWyrgvomVV7swAPA9OAAAARPNA= Date: Thu, 21 Jul 2016 16:08:51 +0000 Message-ID: References: <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: 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: Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 16:08:57 -0000 --_000_BLUPR03MB1330C3D2AEC4876A9E74635387090BLUPR03MB1330namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I assume you're referring to Section 3, SNI's ServerNameList MUST NOT conta= in more than one name of a given type? Technically, we're not violating th= at, since we're not changing SNI. The client requests a single identity in= the TLS handshake, which the server provides. Additional identities can b= e demonstrated later, regardless of where. Or are you referring to the (lower-case) must not resume if SNI and the cer= tificate used in the resumed session differ? For HTTP, we're leaving resum= ption out of the picture, requiring that any secondary certificates be prov= ed anew for each connection. You're certainly correct that if the logic we= re moved to TLS, the semantics of resumption would have to be defined. Tha= t 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 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 w= ould 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 --_000_BLUPR03MB1330C3D2AEC4876A9E74635387090BLUPR03MB1330namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 d= emonstrated 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 th= at any secondary certificates be proved anew for each connection.  You’re certainly correct that if the logi= c were moved to TLS, the semantics of resumption would have to be defined.&= nbsp; That may be a solid argument on why it should remain at the applicati= on 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 carryi= ng both client and server

> certificates above TLS, found at =

> https://tools.ietf.or= g/html/draft-bishop-httpbis-http2-additional-certs.

>

> We have also discussed that it might be pref= erable to pull part of

> this capability back into TLS,

 

You are facing a MUST NOT in rfc6066 for this par= ticularly 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 &qu= ot;principle of least surprise"

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

 

-Martin

--_000_BLUPR03MB1330C3D2AEC4876A9E74635387090BLUPR03MB1330namp_--