From nobody Sat Oct 1 04:23:13 2016 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 F22D012B08E for ; Sat, 1 Oct 2016 04:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 KGQoAmjZdftt for ; Sat, 1 Oct 2016 04:23:10 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEBD12B04B for ; Sat, 1 Oct 2016 04:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1475320989; x=1506856989; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=s6iRo1EVgWuxGLA3rLXNxqRvBuLhX5q3GUkCJbsqjFk=; b=sQiVjTIJ6T+B0qG9SrFf0at+/RApHg1BMSJXeSqIcAthUXiv1HvCykbw 1lgEK411vVE6HuA/idQom04zykQtDMgChQKMhxYpYjb3bPBO0QI2suSIe X+kNJyAKvA+AlvdyuLpNNnNfflXY6goWq8Qw4ZPamYA896LtFdj0GSXXq UolCMghSdH9nPaqt3J6cSygQrtn0QGzmgbXxy9NnJWd2eS6KLoO3/AEmy 1/VAf9t0uc1EmePRagVaCQhM+MWf/ygYQECq4yWUswMFt2cSYnXkY6fgZ 62cgVCjlurGuFA1tjeeIrKZc1ZtcrXvgSVph4CAAde1pk5MmGX7mBFJz8 A==; X-IronPort-AV: E=Sophos;i="5.31,426,1473076800"; d="scan'208";a="108210274" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Oct 2016 00:23:06 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 2 Oct 2016 00:23:05 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::8081:99e3:dee2:203]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::8081:99e3:dee2:203%14]) with mapi id 15.00.1178.000; Sun, 2 Oct 2016 00:23:05 +1300 From: Peter Gutmann To: Ryan Carboni , "tls@ietf.org" Thread-Topic: [TLS] Industry Concerns about TLS 1.3 Thread-Index: AQHSGh9MM9WBapZoQzyfqxiOaK25faCTd8yU Date: Sat, 1 Oct 2016 11:23:05 +0000 Message-ID: <1475320974979.29940@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Sat, 01 Oct 2016 11:23:12 -0000 Ryan Carboni writes:=0A= =0A= >I've never quite understood what TLS was supposed to be protecting against= ,=0A= >and whether or not it has done so successfully, or has the potential to do= so=0A= >successfully.=0A= =0A= It's the Inside-Out Thread Model (also shared by a number of other security= =0A= protocols, it's not just TLS), "our defence is SSL/TLS/IPsec/PKI/=85 and o= ur=0A= threat model is whatever that happens to defend against". DNSSEC is a clas= sic=0A= example of this, the DNSSEC requirements doc was published *a decade* after= =0A= DNSSEC itself. Mind you, other protocols are still waiting for their=0A= requirements doc to be published. PKIX specifically actively declined to= =0A= consider use cases because heck, this is a standards committee dammit, we= =0A= can't be expected to take into account what people want to do with it.=0A= =0A= Mind you, in the absence of any success criteria, no-one can say you've=0A= failed...=0A= =0A= Peter.= From nobody Mon Oct 3 10:47:16 2016 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 1302E129447 for ; Mon, 3 Oct 2016 10:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 z_JzFJzuMQGu for ; Mon, 3 Oct 2016 10:47:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF77129443 for ; Mon, 3 Oct 2016 10:47:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B39F7B80C3B; Mon, 3 Oct 2016 10:47:12 -0700 (PDT) To: d3e3e3@gmail.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161003174712.B39F7B80C3B@rfc-editor.org> Date: Mon, 3 Oct 2016 10:47:12 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, vincentleest@gmail.com, tls@ietf.org Subject: [TLS] [Editorial Errata Reported] RFC6066 (4817) 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: Mon, 03 Oct 2016 17:47:14 -0000 The following errata report has been submitted for RFC6066, "Transport Layer Security (TLS) Extensions: Extension Definitions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6066&eid=4817 -------------------------------------- Type: Editorial Reported by: ResponderIDs type is not defined anywhere. Section: 8 Original Text ------------- In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP responders that the client trusts. Corrected Text -------------- In the OCSPStatusRequest, the "ResponderID" provides a list of OCSP responders that the client trusts. or clearer In OCSPStatusRequest, the "responder_id_list" provides a list of "ResponderID", OCSP responders that the client trusts. Notes ----- ResponderIDs is not defined anywhere within the document. Quote of this section in RFC6961 section 2.2 (p.4) seem to have fixed this. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6066 (draft-ietf-tls-rfc4366-bis-12) -------------------------------------- Title : Transport Layer Security (TLS) Extensions: Extension Definitions Publication Date : January 2011 Author(s) : D. Eastlake 3rd Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Oct 3 13:45:46 2016 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 464BD129533 for ; Mon, 3 Oct 2016 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fsroundtable.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 ilQMURdvxCsa for ; Mon, 3 Oct 2016 13:45:40 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0089.outbound.protection.outlook.com [104.47.36.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F147129508 for ; Mon, 3 Oct 2016 13:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsroundtable.onmicrosoft.com; s=selector1-fsroundtable-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vp9UXzfalXL5l1R2eFzz4ylxpJOBQb1mQNoYfvY2VoU=; b=fUYVe+nLTAE9VE2cONOwU5eFnDa/Bn9w5mQ7kltBoR9Nny7xvaLilF9GL99eIiMfrNWXd33HRyslkFn8J5OiNXKrQMWf7Fc9QxkLT2UNOIyFw8oxtBz3LX2dwHbOwV6yudHl0evulbaWn2fSvERKAfwCvn2zFb8uG9Zcno6gZIk= Received: from DM5PR11MB1419.namprd11.prod.outlook.com (10.168.104.21) by DM5PR11MB1420.namprd11.prod.outlook.com (10.168.104.22) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.649.16; Mon, 3 Oct 2016 20:45:38 +0000 Received: from DM5PR11MB1419.namprd11.prod.outlook.com ([10.168.104.21]) by DM5PR11MB1419.namprd11.prod.outlook.com ([10.168.104.21]) with mapi id 15.01.0619.020; Mon, 3 Oct 2016 20:45:38 +0000 From: BITS Security To: Seth David Schoen Thread-Topic: [TLS] Industry Concerns about TLS 1.3 Thread-Index: AdIU8WqWM9WBapZoQzyfqxiOaK25faCNrW8AgAACpQCACY+AcA== Date: Mon, 3 Oct 2016 20:45:38 +0000 Message-ID: References: <20160927183022.GM25826@demorgan> In-Reply-To: <20160927183022.GM25826@demorgan> 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=BITSSecurity@fsroundtable.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [165.117.248.226] x-ms-office365-filtering-correlation-id: 724c8bb0-4f2f-4cf8-9d61-08d3ebce3b9d x-microsoft-exchange-diagnostics: 1; DM5PR11MB1420; 7:Dcdk0LjCGTuxK69mysrQAbAhFgeapmH5LBC5O5T1sywT1+zhhtJgNd+g7Mw14tiUdMoT+3f1RfYdHt89HjbEIZBZlGK6rxWRqK8YxanOVsgjseW8zCNeFVDv/zFB/p4kx2ysnlMdCgGq60wO1dpC8+awNQam6x6SYxT0HO5ft68O3zqiwEnlIVLtPwJMXKLtR0h5L9uFRUJtpW+llkyfg+6GH2sD6yj4fMS/9TSWoQ0PzwZcCqsa2cMRN1qi+wJFPLHiDZDCs2PB002RHs7VkC8sx9UE3UsuRY6cS+CMvgXAnpXfhNrnoaxZltPcOVxVu+IOCTLQO6E2Fi7r+Nx0hA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR11MB1420; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(264723453828037)(192374486261705)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:DM5PR11MB1420; BCL:0; PCL:0; RULEID:; SRVR:DM5PR11MB1420; x-forefront-prvs: 008421A8FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(13464003)(199003)(189002)(76576001)(5002640100001)(80792005)(87936001)(122556002)(19580405001)(110136003)(74316002)(7696004)(97736004)(7736002)(2906002)(19580395003)(15975445007)(305945005)(189998001)(3280700002)(86362001)(93886004)(101416001)(2950100002)(3660700001)(7846002)(77096005)(4326007)(9686002)(6916009)(106356001)(105586002)(11100500001)(6116002)(92566002)(76176999)(10400500002)(66066001)(8676002)(54356999)(68736007)(33656002)(50986999)(99286002)(102836003)(2900100001)(81156014)(5660300001)(81166006)(3846002)(586003)(8936002)(19400905002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1420; H:DM5PR11MB1419.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fsroundtable.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fsroundtable.org X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2016 20:45:38.2364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 841de5a0-73e8-4cbc-8142-f80b225ef22d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1420 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Mon, 03 Oct 2016 20:45:44 -0000 > > The various suggestions for creating fixed/static Diffie Hellman keys r= aise interesting possibilities. We would like to understand these ideas be= tter at a technical level and are initiating research into this potential s= olution. We need to understand the potential ramifications and other imple= mentation details. This solution would have to be implemented in servers, = firewalls, load balancers, Internet proxies, and mainframes. If vendors br= oadly refuse to support then it is not much a solution but at this point lo= oks like it is worth exploring. =20 > Bear in mind that, if you do that, anyone who gets a copy of that secret = will be able to retrospectively decrypt all of your organization's TLS traf= fic. However, that's presumably true of any solution that satisfies the re= quirement that you describe: there will always be _some_ secret that the or= ganization possesses that, if obtained by an adversary, would let the adver= sary retrospectively decrypt traffic. We can put private keys in an HSM and implement other processes to protect = them. This is what some are doing with RSA today. If you look at the Veri= zon breach report and other similar resources, breaches from stolen network= packets and/or stolen private keys is not a discernible trend (though I wi= ll cede past results don't predict future performance).=20 > This configuration might be a bit dangerous because it means that "server= s, firewalls, load balancers, Internet proxies, and mainframes" would all possess the information needed to decrypt _each other's_ traffic,= so someone inside or outside the organization who can steal that informati= on can then read all of the traffic, even traffic that was originated by de= vices they don't know about or have a relationship to. > So organizational unit X can read the traffic of organizational unit Y, e= ven if X wasn't meant to be in a supervisory or audit relationship over Y, = because the ability to emit decryptable traffic of this kind also implies t= he ability to decrypt others' sessions. We've heard this a different way, for example not every layer of the data c= enter would have the same key or that key is always available. I have to ad= mit to some ignorance here which is why we want to explore this potential o= ption. Even if it works (which it might not as you say) there still is the= question of if vendors would being willing to support. =20 > It also provides a way that other parties outside of the organization can= , even through passive eavesdropping, recognize the organization's traffic = as associated with that organization -- kind of like a global cookie inside= the TLS handshake. People could use that to target surveillance or advert= ising even if they didn't know or recognize the organization's IP address r= anges. Something else important to check on that could undermine this solution. A= ppreciate it. =20 - Andrew=20 -----Original Message----- From: Seth David Schoen [mailto:schoen@eff.org]=20 Sent: Tuesday, September 27, 2016 2:30 PM To: BITS Security Cc: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 BITS Security writes: > The various suggestions for creating fixed/static Diffie Hellman keys rai= se interesting possibilities. We would like to understand these ideas bett= er at a technical level and are initiating research into this potential sol= ution. We need to understand the potential ramifications and other impleme= ntation details. This solution would have to be implemented in servers, fi= rewalls, load balancers, Internet proxies, and mainframes. If vendors broa= dly refuse to support then it is not much a solution but at this point look= s like it is worth exploring. =20 Bear in mind that, if you do that, anyone who gets a copy of that secret wi= ll be able to retrospectively decrypt all of your organization's TLS traffi= c. However, that's presumably true of any solution that satisfies the requ= irement that you describe: there will always be _some_ secret that the orga= nization possesses that, if obtained by an adversary, would let the adversa= ry retrospectively decrypt traffic. This configuration might be a bit dangerous because it means that "servers,= firewalls, load balancers, Internet proxies, and mainframes" would all possess the information needed to decrypt _each other's_ traffic,= so someone inside or outside the organization who can steal that informati= on can then read all of the traffic, even traffic that was originated by de= vices they don't know about or have a relationship to. So organizational unit X can read the traffic of organizational unit Y, eve= n if X wasn't meant to be in a supervisory or audit relationship over Y, be= cause the ability to emit decryptable traffic of this kind also implies the= ability to decrypt others' sessions. It also provides a way that other parties outside of the organization can, = even through passive eavesdropping, recognize the organization's traffic as= associated with that organization -- kind of like a global cookie inside t= he TLS handshake. People could use that to target surveillance or advertis= ing even if they didn't know or recognize the organization's IP address ran= ges. -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 From nobody Mon Oct 3 14:21:35 2016 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 F0E60129586 for ; Mon, 3 Oct 2016 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fsroundtable.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 tJaDY15Vvszl for ; Mon, 3 Oct 2016 14:21:29 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0087.outbound.protection.outlook.com [104.47.40.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56ABE129592 for ; Mon, 3 Oct 2016 14:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsroundtable.onmicrosoft.com; s=selector1-fsroundtable-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2ASaWt/jBRssaQeiAvyg1k0r2p2tVVSv2EkMMJz5leQ=; b=G3LdbqqZbYe2Ly5G1oOHhoimm3yLJ/KfjC95G2O3yIlj0MwD77KS0cnmhFI0HGK1Sg5QsaVF35+Ro1lpGv/Hc2N7PPb21SUOlgvGOAMMHAu/t1o7POc2OEGSC+WhbH5tj/2d4xfhDPBhoecBRhiq9aqUs/K+GkaPW2B3pWSqH14= Received: from DM5PR11MB1419.namprd11.prod.outlook.com (10.168.104.21) by DM5PR11MB1417.namprd11.prod.outlook.com (10.168.104.19) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Mon, 3 Oct 2016 21:21:09 +0000 Received: from DM5PR11MB1419.namprd11.prod.outlook.com ([10.168.104.21]) by DM5PR11MB1419.namprd11.prod.outlook.com ([10.168.104.21]) with mapi id 15.01.0619.020; Mon, 3 Oct 2016 21:21:09 +0000 From: BITS Security To: Tony Arcieri Thread-Topic: [TLS] Industry Concerns about TLS 1.3 Thread-Index: AdIU8WqWM9WBapZoQzyfqxiOaK25fQADrwVgABxJhIAADgIdgAAAS/+AAAFEjIAAAGtwAAAHxtLQAADiU4AAAeJj0AAFTeiAAI3SNcAANQvmgAEuwRLg Date: Mon, 3 Oct 2016 21:21:08 +0000 Message-ID: References: <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <126ee1b6-fc88-bf4e-c366-60d59a9b3350@gmail.com> In-Reply-To: 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=BITSSecurity@fsroundtable.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [165.117.248.226] x-ms-office365-filtering-correlation-id: e7e229c6-95bc-4ecc-f92a-08d3ebd33178 x-microsoft-exchange-diagnostics: 1; DM5PR11MB1417; 6:udcEp7PMGd4RWdmwVlTnOEmw8wIfbiTyq4pOsIB4bBm8JnffSZ0s58a6NFpr1SpTyLwCuKZpZFS6mT21b429uHEM+Zu48nVWdFSMS4kuUYZvJg25443ii5I2qU42ZdRiMbB7MzUBOyk5NvnKHuh9kuVD0lu3JQopM/dm4aHZ9zAcWSOJOPtAzrIzknBviqwhn/Gqy9bbS/0BocLRVGFfQPn+B+vjaSiP5V7Q0/FgZpEDlIfjgI8TvJzzQog2XNQn24r0Fn1er0Svdty5nk9u40ZJO1R0+k+UtlWAWxINLO/mNmWFha5rck5proKClVi/; 5:GSGUAjodioZB1ofvUgE4W1eyFqMz+qwSfkfqmWJy+KLLVVxG2EtgZ0g6T6ORCC6Fza1b8z5HtmvHCTUq1ibYZuDGLMIPAGumQICBVIBb9u9Yp+jvztOArVD2GF7GM+YcBqNWVqpz4aUfNa83nN8yaA==; 24:njUh0dSunggiZ5imPsZB1AOPi6zjkp268W7BpTuqWDtGZrGe/pBQwNaeaUaOGAG+60y8vrxXgJbC2xGU69IS1T4JfZtsKdn4i8UJBKXlauQ=; 7:bByLYT/1g97iMdiJflUGcUZ6LJcMwNNmhlN2NTdzOV5iXNq94W82yt3bBSZmecUcKgQkwkP87AZvS8LCDHTdtqWujJvAq4SV5xpJiQvH5At7k783kzBGO1F0yW0ks0baX5iNlen2DdCkUgoeID+xUw+XH1Hl5lcKNeGff4ZXgrvOL2AWBDZXdFU/C1kqqh5ZK1Qh63x9mUQ0ca1S/mKJEXOePTRsy/OcazvhiTVVkDcaEk1niujoLICFseSc+l44AVLTF+gBSBh8fnhNWEJ5S3msqQ2hivS55XB5E1j0OY+s+3o/jsPeV2G7LlyVluwc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR11MB1417; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(192374486261705)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6042046)(6043046); SRVR:DM5PR11MB1417; BCL:0; PCL:0; RULEID:; SRVR:DM5PR11MB1417; x-forefront-prvs: 008421A8FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(24454002)(55674003)(377454003)(122556002)(8936002)(1411001)(2950100002)(81166006)(5660300001)(11100500001)(6116002)(3660700001)(50986999)(586003)(3846002)(102836003)(74316002)(6916009)(76576001)(92566002)(8676002)(9686002)(68736007)(189998001)(33656002)(7696004)(110136003)(54356999)(3280700002)(76176999)(2906002)(7736002)(77096005)(97736004)(87936001)(19580395003)(19580405001)(66066001)(99286002)(101416001)(106356001)(93886004)(2900100001)(5002640100001)(81156014)(10400500002)(80792005)(4326007)(305945005)(7846002)(105586002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1417; H:DM5PR11MB1419.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fsroundtable.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fsroundtable.org X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2016 21:21:08.7958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 841de5a0-73e8-4cbc-8142-f80b225ef22d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1417 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Mon, 03 Oct 2016 21:21:32 -0000 PiBJIHdvcmsgZmlyc3RoYW5kIGVuZm9yY2luZyB0aGVzZSByZXF1aXJlbWVudHMgYXQgYSBwYXlt ZW50cyBjb21wYW55LiBBZ2FpbiwgSSBkbyBub3Qgc3BlYWsgb24gYmVoYWxmIG9mIG15IGVtcGxv eWVyLiAgIA0KPiBJdCB3YXNuJ3QgdW50aWwgbGFzdCB5ZWFyIHRoYXQgUENJIGRlY2lkZWQgdG8g ZGVwcmVjYXRlIFRMUyAxLjAsIGF0IHRoZSB0aW1lIGEgMTYgeWVhciBvbGQgc3RhbmRhcmQuIEkg dGhpbmsgeW91ciBzZW5zZSBvZiBlbWVyZ2VuY3kgaXMgaGlnaGx5IG92ZXItZXhhZ2dlcmF0ZWQu ICAgDQo+IEkgZmluZCBpdCBoaWdobHkgdW5saWtlbHkgdGhhdCBhbnkgZ3JvdXAgc3VjaCBhcyB0 aGUgUENJIENvdW5jaWwgd2lsbCBiZWdpbiBtYW5kYXRpbmcgVExTIDEuMyBhbnkgdGltZSBzb29u LiBJIHdvdWxkIGdvIGFzIGZhciBhcyB0byBjYWxsIHlvdXIgY29uY2VybnMgImltYWdpbmFyeSIu ICANCg0KSWYgUENJIGhhcyBtYW5kYXRlZCB1cGdyYWRpbmcgVExTIGJlY2F1c2Ugb2YgdnVsbmVy YWJpbGl0aWVzLCB0aGV5IGFyZSBsaWtlbHkgdG8gZG8gaXQgYWdhaW4gYW5kIGluIGZhY3QgaGF2 ZSBwcm92aWRlZCBzdHJvbmcgaGludHMgdG8gdGhlIG1hcmtldCB3aGVyZSB0aGV5IHNob3VsZCBi ZSBiZXlvbmQgdGhlIG1pbmltdW0gcmVxdWlyZW1lbnQgaXRzZWxmLiAgSSBkb24ndCBzZWUgdGhh dCB0aGUgdGltaW5nIHJlYWxseSBtYXR0ZXJzIGJlY2F1c2UgaXQgaXNuJ3QgYmFzZWQgb24gdGhl IGFnZSBvZiB0aGUgc3RhbmRhcmQsIGl0IGlzIGJhc2VkIG9uIHRoZSBzdGFuZGFyZCBiZWNvbWlu ZyBvdXRkYXRlZC4gIFdlJ3JlIHRyeWluZyB0byBnZXQgYWhlYWQgb2YgZm9yZXNlZWFibGUgcHJv YmxlbSBzb21lIHdpbGwgaGF2ZS4gDQoNCkZ1cnRoZXIsIFBDSSBkb2VzIG5vdCByZXF1aXJlIFRM UyBlbmNyeXB0aW9uIGF0IGFsbCBpbiBhIHByaXZhdGUgZGF0YSBjZW50ZXIsIGF0IGxlYXN0IG5v dCB0ZWNobmljYWxseS4gIEhvd2V2ZXIsIGluIHByYWN0aWNlIHRoZXkgc3Ryb25nbHkgcmVjb21t ZW5kIHNlZ21lbnRpbmcgdGhlIENhcmRob2xkZXIgRGF0YSBFbnZpcm9ubWVudCwgd2hpY2ggSSBz dXNwZWN0IG1vc3QgZmluYW5jaWFscyBoYXZlIGRvbmUsIGFuZCBtYW55IGhhdmUgdXNlZCBUTFMg YXMgcGFydCBvZiB0aGVpciBzdHJhdGVneSBmb3Igc2VnbWVudGF0aW9uIChlbmNyeXB0ZWQgUENJ IHRyYWZmaWMgZmxvd2luZyB0aHJvdWdoIGRldmljZXMgZG9lcyBub3QgYnJpbmcgdGhlc2UgZGV2 aWNlcyBpbnRvIHNjb3BlIGZvciBhdWRpdCkuICBTbyBhY2NvcmRpbmcgdG8gY3VycmVudCBwcmFj dGljZSwgYXVkaXRvcnMgYXJlIGdvaW5nIHRvIHJlcXVpcmUgY2VydGFpbiBsZXZlbHMgb2YgVExT IGluIG9yZGVyIGZvciBvdXIgc2VnbWVudGluZyBzdHJhdGVnaWVzIHRvIHdvcmsuDQoNCj4gSWYg eW91IGFyZSB3b3JyaWVkIGFib3V0IHN1Y2ggYW4gZXZlbnR1YWxpdHksIHRoZSBJRVRGIGlzIHRo ZSB3cm9uZyBwbGFjZSB0byBjb21wbGFpbi4gSXQgaXMgZmFyLCBmYXIgdG9vIGxhdGUgaW4gdGhl IFRMUyAxLjMgcHJvY2VzcyB0byBiZSB2b2ljaW5nIHRoZXNlIGNvbmNlcm5zLiBXaGVyZSB3ZXJl IHlvdSAyKyB5ZWFycyBhZ28gd2hlbiBpdCB3YXMgdGhlIGFwcHJvcHJpYXRlIHRpbWUgaW4gdGhl IFRMUyBkZXZlbG9wbWVudCBjeWNsZSB0byB2b2ljZSBzdWNoIGNvbmNlcm5zPyBJIHRoaW5rIHRo ZSB2aWV3IG9mIG1vcmUgImZvcndhcmQgdGhpbmtpbmciIHBheW1lbnRzIGNvbXBhbmllcyBpcyBU TFMgMS4zIGhhcyB0YWtlbiB0b28gbG9uZyBhbHJlYWR5LCBhbmQgdGhleSB3b3VsZCBsaWtlIHRv IHN0YXJ0IGRlcGxveWluZyBpdCBpbiBpdHMgY3VycmVudCBmb3JtIGFuZCB3b3VsZCBwcmVmZXIg dW5uZWNlc3NhcnkgaG9sZHVwcy9kaXN0cmFjdGlvbnMgd2hpY2ggaGF2ZSBhbHJlYWR5IG9jY3Vy cmVkIHRocm91Z2hvdXQgdGhlIHByb2Nlc3MuDQoNClBDSSByZXF1aXJlbWVudCBwcm92aWRpbmcg SW50cnVzaW9uIERldGVjdGlvbiBhdCB0aGUgZW50cmFuY2UgdG8gQ2FyZGhvbGRlciBEYXRhIEVu dmlyb25tZW50cyBhcyB3ZWxsIGFzIGF0IGNyaXRpY2FsIHBvaW50cyBpbnNpZGUgdGhlIENhcmRo b2xkZXIgRGF0YSBFbnZpcm9ubWVudC4gIEludHJ1c2lvbiBEZXRlY3Rpb24gcmVxdWlyZXMgZGVj cnlwdGlvbiBvZiBUTFMuICBGb3Igc29tZSBsYXJnZSwgY29tcGxleCBvcmdhbml6YXRpb25zIHRo aXMgY2FuIGJlIGEgbGFyZ2UgbnVtYmVyIG9mIHBoeXNpY2FsIGluc3BlY3Rpb24gcG9pbnRzLCBt b3JlIHRoYW4gY2FuIGJlIGFjY29tbW9kYXRlZCBieSBNSVRNLiAgSSB1bmRlcnN0YW5kIHRoaXMg bWF5IG5vdCBiZSBhIHByb2JsZW0gZm9yIHlvdXIgY3VycmVudCBlbnZpcm9ubWVudCBidXQgb3Ro ZXJzIGRvIG5vdCBoYXZlIHRoYXQgbHV4dXJ5Lg0KDQo+IFRoYXQgc2FpZCwgdGhlcmUgaXMgc3Rp bGwgcGxlbnR5IG9mIHRpbWUgdG8gZW5zdXJlIHRoYXQgZ3JvdXBzIGxpa2UgdGhlIFBDSSBDb3Vu Y2lsIGRvIG5vdCBwdXQgaW4gcGxhY2UgcmVxdWlyZW1lbnRzIHdoaWNoIHdvdWxkIGFmZmVjdCB0 aGUgY2VudHJhbGl6ZWQgdHJhZmZpYy1kZWNyeXB0aW5nIE1pdE0tY2FwYWJpbGl0eSBvbiB5b3Vy IHBheW1lbnRzIHN0YWNrLiBQZXJoYXBzIHlvdSBzaG91bGQgYmUgdm9pY2luZyB5b3VyIGNvbmNl cm5zIHRoZXJlPyBJZiB5b3UgYXJlIHdvcnJpZWQgYWJvdXQgYSBUTFMgMS4zIG1hbmRhdGUgcHJl dmVudGluZyB5b3VyIE1pdE0gY2FwYWJpbGl0eSwgdGhlIG9udXMgaXMgb24geW91IHRvIGNvbnZp bmNlIHRoZSByZWxldmFudCBwYXltZW50cyBzdGFuZGFyZHMgYm9kaWVzIHRoYXQgbWFuZGF0aW5n IFRMUyAxLjMgaXMgYSBiYWQgaWRlYSBmb3IgdGhlIHBheW1lbnRzIGluZHVzdHJ5LiBJIHRoaW5r IHRob3NlIG9yZ2FuaXphdGlvbnMgYXJlIGJldHRlciBwb2lzZWQgdG8ganVkZ2Ugd2hldGhlciBz dWNoIGFuIGFwcHJvYWNoIHJlZmxlY3RzIG9uIG5lY2Vzc2FyeSByZXF1aXJlbWVudHMgdmVyc3Vz IHBlcnZhc2l2ZSBhbnRpcGF0dGVybnMgYW1vbmcgY29tcGxhY2VudCBjb21wYW5pZXMgdW5wcmVw YXJlZCBmb3IgdGhlIGZ1dHVyZSBhbmQgcmlwZSBmb3IgYSBkYXRhIGJyZWFjaC4NCg0KV2UgY2Fu IGltcGxvcmUgUENJIGFsbCB3ZSB3YW50LCBidXQgaWYgZXZlbnRzIG92ZXJ0YWtlIHVzLCBzdWNo IGFzIHRoZSBpbnRyb2R1Y3Rpb24gb2YgbmV3IHNlY3VyaXR5IHJpc2tzLCB3ZSBoYXZlIHRvIGJl IHByZXBhcmVkIGZvciBldmVudHVhbGl0aWVzIGxpa2UgVExTIDEuMyBiZWluZyB0aGUgbWFuZGF0 ZSBhbmQgbXVzdCBiZSBwcmVwYXJlZCBwZXJmb3JtIElEUy9JUFMgcm91dGluZXMgYXQgc2NhbGUg c3VjaCBhbiBlbnZpcm9ubWVudC4NCg0KPiBJbiB0aGUgbWVhbnRpbWUsIHlvdSBoYXZlIGRpc2Ns b3NlZCBhIHZlcml0YWJsZSB0cmVhc3VyZSBtYXAgdG8gYSB0cmFmZmljLWRlY3J5cHRpbmcgc2lu Z2xlIHBvaW50IG9mIGZhaWx1cmUgd2hpY2ggb3N0ZW5zaWJseSBleGlzdHMgYXQgYWxsIG9mIHRo ZSBjb21wYW5pZXMgeW91IHJlcHJlc2VudCB3aGljaCBhdHRhY2tlcnMgY291bGQgbGV2ZXJhZ2Ug dG8gcmVjb3ZlciBhbGwgcGF5bWVudCBjcmVkZW50aWFscy4gVGhhdCBzb3VuZHMgbGlrZSBhIGh1 Z2Ugc2VjdXJpdHkgdGhyZWF0Lg0KPiBXb3VsZCB5b3UgbWluZCBkaXNjbG9zaW5nIHdoaWNoIGNv bXBhbmllcyB5b3UgcmVwcmVzZW50LCBzbyBJIGNhbiBlbnN1cmUgZm9yIHRoZSBzYWZldHkgb2Yg bXkgb3duIG1vbmV5IHRoYXQgSSBkbyBub3QgdXNlIHRoZW0/DQoNCkkgZG9uJ3Qga25vdyBob3cg dGhpcyBsaXN0c2VydiBvcGVyYXRlcyBpbiBwcmFjdGljZSBidXQgaXQgaXMgdGhpcyB0eXBlIG9m IHNvcGhpc3RyeSB0aGF0IGhhcmQgYm9pbHMgbXkgZWdncyB0byBwdXQgaXQgcG9saXRlbHkuICBQ ZXJoYXBzIHRoaXMgaXMganVzdCB0aGUgcmVndWxhciBjb3N0IG9mIHBhcnRpY2lwYXRpb24gYnV0 IHRoYXQgd291bGQgYmUgdW5mb3J0dW5hdGUuICANCg0KSWYgeW91IGxvb2sgYXQgdGhlIGluZHVz dHJ5IHJlcG9ydHMgbGlrZSB0aGUgVmVyaXpvbiBQQ0kgQnJlYWNoIGFuZCBDb21wbGlhbmNlIFJl cG9ydHMsIHByaXZhdGUga2V5cyBzaW1wbHkgYXJlbid0IGJlaW5nIHN0b2xlbi4gIE1heWJlIHRo ZXJlIGlzIGFuIG91dGxpZXIgb3IgdHdvIGJ1dCB0aGVyZSBjZXJ0YWlubHkgaXNuJ3QgYSBkb2N1 bWVudGVkIHRyZW5kIEkgY2FuIGZpbmQuICBJZiB5b3UgaGF2ZSBjb250cmF2ZW5pbmcgaW5mb3Jt YXRpb24gdG8gcHJvdmlkZSBJIGFtIGFsbCBlYXJzLiANCg0KLSBBbmRyZXcgDQoNCg0KDQpGcm9t OiBUb255IEFyY2llcmkgW21haWx0bzpiYXNjdWxlQGdtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5 LCBTZXB0ZW1iZXIgMjcsIDIwMTYgNDoxNyBQTQ0KVG86IEJJVFMgU2VjdXJpdHkgPEJJVFNTZWN1 cml0eUBmc3JvdW5kdGFibGUub3JnPg0KQ2M6IFBldGVyIEJvd2VuIDxwemJvd2VuQGdtYWlsLmNv bT47IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIEluZHVzdHJ5IENvbmNlcm5zIGFi b3V0IFRMUyAxLjMNCg0KT24gTW9uLCBTZXAgMjYsIDIwMTYgYXQgMTI6MDEgUE0sIEJJVFMgU2Vj dXJpdHkgPEJJVFNTZWN1cml0eUBmc3JvdW5kdGFibGUub3JnPiB3cm90ZToNClRoZSBQQ0kgRFNT IGlzIGFscmVhZHkgcmVxdWlyaW5nIFRMUyAxLjIgZm9yIGZpbmFuY2lhbCBpbnN0aXR1dGlvbnMg dGhhdCBwYXJ0aWNpcGF0ZSBpbiB0aGUgUGF5bWVudCBDYXJkIEluZHVzdHJ5LsKgIC5CQU5LIChl eGNsdXNpdmUgdG9wIGxldmVsIGJhbmtpbmcgZG9tYWluKSBpcyBhbHNvIHBsYW5uaW5nIHRvIHJl cXVpcmUgVExTIDEuMi7CoCDCoFdlJ3JlIGFudGljaXBhdGluZyB0aGF0IGEgcmVndWxhdG9yeSBi b2R5IGxpa2UgdGhlc2Ugd2lsbCByZXF1aXJlIFRMUyAxLjMgYXQgc29tZSBwb2ludCBpbiB0aGUg ZnV0dXJlLsKgIEZpbmFuY2lhbCBpbnN0aXR1dGlvbnMgdGhlbiBoYXZlIHRvIGNvbXBseSBpZiB0 aGV5IHdhbnQgdG8gY29udGludWUgdG8gZG8gYnVzaW5lc3Mgd2l0aCB0aGUgY29tcGFuaWVzIHJl cHJlc2VudGVkIGJ5IHRoZSByZWd1bGF0b3J5IGJvZHkgKGxpa2UgbGFyZ2UgY3JlZGl0IGNhcmQg Y29tcGFuaWVzIGluIHRoZSBjYXNlIG9mIFBDSSkuDQoNCkhlbGxvIGFnYWluLA0KDQpJIHdvcmsg Zmlyc3RoYW5kIGVuZm9yY2luZyB0aGVzZSByZXF1aXJlbWVudHMgYXQgYSBwYXltZW50cyBjb21w YW55LiBBZ2FpbiwgSSBkbyBub3Qgc3BlYWsgb24gYmVoYWxmIG9mIG15IGVtcGxveWVyLg0KDQpJ dCB3YXNuJ3QgdW50aWwgbGFzdCB5ZWFyIHRoYXQgUENJIGRlY2lkZWQgdG8gZGVwcmVjYXRlIFRM UyAxLjAsIGF0IHRoZSB0aW1lIGEgMTYgeWVhciBvbGQgc3RhbmRhcmQuIEkgdGhpbmsgeW91ciBz ZW5zZSBvZiBlbWVyZ2VuY3kgaXMgaGlnaGx5IG92ZXItZXhhZ2dlcmF0ZWQuDQoNCkkgZmluZCBp dCBoaWdobHkgdW5saWtlbHkgdGhhdCBhbnkgZ3JvdXAgc3VjaCBhcyB0aGUgUENJIENvdW5jaWwg d2lsbCBiZWdpbiBtYW5kYXRpbmcgVExTIDEuMyBhbnkgdGltZSBzb29uLiBJIHdvdWxkIGdvIGFz IGZhciBhcyB0byBjYWxsIHlvdXIgY29uY2VybnMgImltYWdpbmFyeSIuDQoNCklmIHlvdSBhcmUg d29ycmllZCBhYm91dCBzdWNoIGFuIGV2ZW50dWFsaXR5LCB0aGUgSUVURiBpcyB0aGUgd3Jvbmcg cGxhY2UgdG8gY29tcGxhaW4uIEl0IGlzIGZhciwgZmFyIHRvbyBsYXRlIGluIHRoZSBUTFMgMS4z IHByb2Nlc3MgdG8gYmUgdm9pY2luZyB0aGVzZSBjb25jZXJucy4gV2hlcmUgd2VyZSB5b3UgMisg eWVhcnMgYWdvIHdoZW4gaXQgd2FzIHRoZSBhcHByb3ByaWF0ZSB0aW1lIGluIHRoZSBUTFMgZGV2 ZWxvcG1lbnQgY3ljbGUgdG8gdm9pY2Ugc3VjaCBjb25jZXJucz8gSSB0aGluayB0aGUgdmlldyBv ZiBtb3JlICJmb3J3YXJkIHRoaW5raW5nIiBwYXltZW50cyBjb21wYW5pZXMgaXMgVExTIDEuMyBo YXMgdGFrZW4gdG9vIGxvbmcgYWxyZWFkeSwgYW5kIHRoZXkgd291bGQgbGlrZSB0byBzdGFydCBk ZXBsb3lpbmcgaXQgaW4gaXRzIGN1cnJlbnQgZm9ybSBhbmQgd291bGQgcHJlZmVyIHVubmVjZXNz YXJ5IGhvbGR1cHMvZGlzdHJhY3Rpb25zIHdoaWNoIGhhdmUgYWxyZWFkeSBvY2N1cnJlZCB0aHJv dWdob3V0IHRoZSBwcm9jZXNzLg0KDQpUaGF0IHNhaWQsIHRoZXJlIGlzIHN0aWxsIHBsZW50eSBv ZiB0aW1lIHRvIGVuc3VyZSB0aGF0IGdyb3VwcyBsaWtlIHRoZSBQQ0kgQ291bmNpbCBkbyBub3Qg cHV0IGluIHBsYWNlIHJlcXVpcmVtZW50cyB3aGljaCB3b3VsZCBhZmZlY3QgdGhlIGNlbnRyYWxp emVkIHRyYWZmaWMtZGVjcnlwdGluZyBNaXRNLWNhcGFiaWxpdHkgb24geW91ciBwYXltZW50cyBz dGFjay4gUGVyaGFwcyB5b3Ugc2hvdWxkIGJlIHZvaWNpbmcgeW91ciBjb25jZXJucyB0aGVyZT8g SWYgeW91IGFyZSB3b3JyaWVkIGFib3V0IGEgVExTIDEuMyBtYW5kYXRlIHByZXZlbnRpbmcgeW91 ciBNaXRNIGNhcGFiaWxpdHksIHRoZSBvbnVzIGlzIG9uIHlvdSB0byBjb252aW5jZSB0aGUgcmVs ZXZhbnQgcGF5bWVudHMgc3RhbmRhcmRzIGJvZGllcyB0aGF0IG1hbmRhdGluZyBUTFMgMS4zIGlz IGEgYmFkIGlkZWEgZm9yIHRoZSBwYXltZW50cyBpbmR1c3RyeS4gSSB0aGluayB0aG9zZSBvcmdh bml6YXRpb25zIGFyZSBiZXR0ZXIgcG9pc2VkIHRvIGp1ZGdlIHdoZXRoZXIgc3VjaCBhbiBhcHBy b2FjaCByZWZsZWN0cyBvbiBuZWNlc3NhcnkgcmVxdWlyZW1lbnRzIHZlcnN1cyBwZXJ2YXNpdmUg YW50aXBhdHRlcm5zIGFtb25nIGNvbXBsYWNlbnQgY29tcGFuaWVzIHVucHJlcGFyZWQgZm9yIHRo ZSBmdXR1cmUgYW5kIHJpcGUgZm9yIGEgZGF0YSBicmVhY2guDQoNCkluIHRoZSBtZWFudGltZSwg eW91IGhhdmUgZGlzY2xvc2VkIGEgdmVyaXRhYmxlIHRyZWFzdXJlIG1hcCB0byBhIHRyYWZmaWMt ZGVjcnlwdGluZyBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZSB3aGljaCBvc3RlbnNpYmx5IGV4aXN0 cyBhdCBhbGwgb2YgdGhlIGNvbXBhbmllcyB5b3UgcmVwcmVzZW50IHdoaWNoIGF0dGFja2VycyBj b3VsZCBsZXZlcmFnZSB0byByZWNvdmVyIGFsbCBwYXltZW50IGNyZWRlbnRpYWxzLiBUaGF0IHNv dW5kcyBsaWtlIGEgaHVnZSBzZWN1cml0eSB0aHJlYXQuDQoNCldvdWxkIHlvdSBtaW5kIGRpc2Ns b3Npbmcgd2hpY2ggY29tcGFuaWVzIHlvdSByZXByZXNlbnQsIHNvIEkgY2FuIGVuc3VyZSBmb3Ig dGhlIHNhZmV0eSBvZiBteSBvd24gbW9uZXkgdGhhdCBJIGRvIG5vdCB1c2UgdGhlbT8NCg0KLS0g DQpUb255IEFyY2llcmkNCg== From nobody Mon Oct 3 14:37:49 2016 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 B57FF12958A for ; Mon, 3 Oct 2016 14:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 X24i6R8fdH9S for ; Mon, 3 Oct 2016 14:37:47 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62CC3129572 for ; Mon, 3 Oct 2016 14:37:47 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 188so46868669iti.1 for ; Mon, 03 Oct 2016 14:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=jwEKR6SOmo5wV2wansTBKN8ZNzuEcEw2yRdbhjVRmN0=; b=kebEwBauBGzpMTEoCYPjJVguf8q98O7l95OSMqRcZcynjG2/mOp9cy2w8JnIhRpoom baJWslUa7RAAtIUxvXXqm8uG0IO1ghFULHDcqb7MRK7OZoe8ab0FDGZ6H99HRSuqlYG8 YbArGsyhYCHDeEFHSFEbdiiIOMVXLSCRSSZ9uvIxhZaj95fbjwwGh1kAfOquOiMHgVik kSS2Zi7qkzDbd0Wdy7rRxvYBt4UknVno8AFaqXIq7GjnkVI9hvz+58aIqxnvF4i4cvgf YxgxKeVfcGKIZBDvYYWh4xbCbllBnyxCCpWeVd3cZ5eskAoDypYUBqV9p5DU/ZJa8EFm QIEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=jwEKR6SOmo5wV2wansTBKN8ZNzuEcEw2yRdbhjVRmN0=; b=AXcfKcZb7LHMjiVqBqloprNuEIPBB6wDCuS3TVpCRxHv0FafGSaUMmbu6bFzKB1Fn2 7AeGkvmAj2cz+attNtDPYBPJUBMUZ1Y4Np5I3p4TPfkMg4zui2vSVfwMSBetu0oWkSCj 9kYo1qPYw15NihPsCM210HZ4cOp0zhNiqw4lHM1AOFDVEucbwnatJ3Ye+SClPBOBg6Xe oHoLjCwCEmjMHsbb5cyF2LKp1CvkW3iQ46kCuIkLmSY2K5pcTZraOeRf+uI+0UQJEsSQ ppshEwxMeHGkaiEqnJYgwHzkb37DC9wcIbRCQoMczKql/zSOXqR3z0xlz7HEk7qMQTjp ljHg== X-Gm-Message-State: AA6/9RmYAEFYcQAF0l9Ox/xHBbNqgZf6OEiCqWbB4L0EO/Dz4m7Bpcmc/b+jhW/NnEYmV6GFvB+8qIsRt2jLrg== X-Received: by 10.36.33.17 with SMTP id e17mr829314ita.41.1475530666787; Mon, 03 Oct 2016 14:37:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.13.145 with HTTP; Mon, 3 Oct 2016 14:37:46 -0700 (PDT) In-Reply-To: References: <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <126ee1b6-fc88-bf4e-c366-60d59a9b3350@gmail.com> From: Jeffrey Walton Date: Mon, 3 Oct 2016 17:37:46 -0400 Message-ID: To: BITS Security Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Industry Concerns about TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com 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: Mon, 03 Oct 2016 21:37:49 -0000 > PCI requirement providing Intrusion Detection at the entrance to Cardhold= er Data Environments as well as at critical points inside the Cardholder Da= ta Environment. Intrusion Detection requires decryption of TLS. For some = large, complex organizations this can be a large number of physical inspect= ion points, more than can be accommodated by MITM. I understand this may n= ot be a problem for your current environment but others do not have that lu= xury. > This may be less than an ideal requirement. Malware wants to do three things (with some hand waiving): (1) spread, (2) collect data, and (3) egress data. I think Step (1) and intrusion detection is a worthy cause, but not at the cost of breaking the secure channel. Perhaps it would be better to focus on (2) and (3). (2) can be tricky based on how deeply the malware is burrowed in. (3) is much easier since the malware needs to open a socket. Policies for (3) are really just whitelist/blacklist approaches. I'm guessing egress points are wide open at the moment, and the PCI requirement is fostering blacklists and causing the organization to be reactive. If the egress points are closed at the organizational boundary, then the organization is proactive and using a whitelist approach. Would it be possible to have the PCI folks re-examine their position since it seems to be boxing BITS members into something untenable? Jeff From nobody Mon Oct 3 14:46:41 2016 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 27E9312958B for ; Mon, 3 Oct 2016 14:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gJFSqiLS1NnI for ; Mon, 3 Oct 2016 14:46:38 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF88D12957F for ; Mon, 3 Oct 2016 14:46:34 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id b186so37575964vkb.1 for ; Mon, 03 Oct 2016 14:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YN8c0IQcyBFeAQUE2rv5XCZlybrzzTxx2/67vytlp+Y=; b=k4XkUNpEATDsksmORlzBTDBepcQTvOS1M08sGtw4xxaeTzYm5TJ6oPhUU20EQN19ez AvqZn9G7KWQzh769i15fwz5ygeH6QvPtU1uQnjTs9/y3OrgETk2WpO+mlXzmuZE6fz0H Tny0rE1O8Ehk7Spj0TUl6DLtYqAOsnswHIiI7EuBXJL1NKjCjZVaKKZuxH8oxy5EmZEc Lgk+gCaFc2Qh7Vgid0YbOt4ECTbjXTzXDgSS+gIW24NpMQwEKG4gdGKzrxagDReTPKeV y+VyHySQJoJC4Vup9xDC3BQaNSH0AxbKVtdFcT8dxpUFH0JijLpS6GukWokDW+9xo+SU KXoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YN8c0IQcyBFeAQUE2rv5XCZlybrzzTxx2/67vytlp+Y=; b=doVHs+wc85pm1GxuKyOYZXsZzuJ9ef650ywkDnCmglQUsvKtYP2OdQzmVqtuMJqhdT 5k+JLAHihfJuusmrk37Tj9fFz/nKXYPNR/1S53gaVtq0AF/3RaELIZ7TWOM/19uRpDhQ LAck+ACJbEdlqbqbLF8vsEOBYcuhNgygMKzvRRfXuzAE+WP6kzaneqwmyHNCio5kmMch Sd2ko0OKRSd0QI29ygThJg20Af7ohqU9Q91vwSE+p5qElSr0GCmUcg4RTT3G3TDucMUp drFFQ8mDhRZAwCfOqjzXD2w/ZZs/KAzoB3o5P0WDxF9juNpQ97N3TIZfop0wD0d5TgUs blBw== X-Gm-Message-State: AA6/9Rlnh4kkm7cBGujD3eaaj04kAmHs/Uw7GzP7NNASscJeyQgvMyofUFnfLu8t3v7jGWwHl7sRZtGh8cN92A== X-Received: by 10.31.151.78 with SMTP id z75mr151311vkd.41.1475531193901; Mon, 03 Oct 2016 14:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.102 with HTTP; Mon, 3 Oct 2016 14:46:32 -0700 (PDT) Received: by 10.176.4.102 with HTTP; Mon, 3 Oct 2016 14:46:32 -0700 (PDT) In-Reply-To: References: <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <126ee1b6-fc88-bf4e-c366-60d59a9b3350@gmail.com> From: Watson Ladd Date: Mon, 3 Oct 2016 14:46:32 -0700 Message-ID: To: BITS Security Content-Type: multipart/alternative; boundary=001a1140e662aae9c7053dfce086 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Mon, 03 Oct 2016 21:46:40 -0000 --001a1140e662aae9c7053dfce086 Content-Type: text/plain; charset=UTF-8 > > If you look at the industry reports like the Verizon PCI Breach and Compliance Reports, private keys simply aren't being stolen. Maybe there is an outlier or two but there certainly isn't a documented trend I can find. If you have contravening information to provide I am all ears. Surely you remember the day when all SWIFT provided devices had to be replaced thanks to some fun in the random number generators. Then there is POISON NUT. The Shadow brokers leak included tools to extract VPN keys from Cisco routers. TJ Maxx involved breaking WEP. > > - Andrew > > > > From: Tony Arcieri [mailto:bascule@gmail.com] > Sent: Tuesday, September 27, 2016 4:17 PM > To: BITS Security > Cc: Peter Bowen ; tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 > > On Mon, Sep 26, 2016 at 12:01 PM, BITS Security < BITSSecurity@fsroundtable.org> wrote: > The PCI DSS is already requiring TLS 1.2 for financial institutions that participate in the Payment Card Industry. .BANK (exclusive top level banking domain) is also planning to require TLS 1.2. We're anticipating that a regulatory body like these will require TLS 1.3 at some point in the future. Financial institutions then have to comply if they want to continue to do business with the companies represented by the regulatory body (like large credit card companies in the case of PCI). > > Hello again, > > I work firsthand enforcing these requirements at a payments company. Again, I do not speak on behalf of my employer. > > It wasn't until last year that PCI decided to deprecate TLS 1.0, at the time a 16 year old standard. I think your sense of emergency is highly over-exaggerated. > > I find it highly unlikely that any group such as the PCI Council will begin mandating TLS 1.3 any time soon. I would go as far as to call your concerns "imaginary". > > If you are worried about such an eventuality, the IETF is the wrong place to complain. It is far, far too late in the TLS 1.3 process to be voicing these concerns. Where were you 2+ years ago when it was the appropriate time in the TLS development cycle to voice such concerns? I think the view of more "forward thinking" payments companies is TLS 1.3 has taken too long already, and they would like to start deploying it in its current form and would prefer unnecessary holdups/distractions which have already occurred throughout the process. > > That said, there is still plenty of time to ensure that groups like the PCI Council do not put in place requirements which would affect the centralized traffic-decrypting MitM-capability on your payments stack. Perhaps you should be voicing your concerns there? If you are worried about a TLS 1.3 mandate preventing your MitM capability, the onus is on you to convince the relevant payments standards bodies that mandating TLS 1.3 is a bad idea for the payments industry. I think those organizations are better poised to judge whether such an approach reflects on necessary requirements versus pervasive antipatterns among complacent companies unprepared for the future and ripe for a data breach. > > In the meantime, you have disclosed a veritable treasure map to a traffic-decrypting single point of failure which ostensibly exists at all of the companies you represent which attackers could leverage to recover all payment credentials. That sounds like a huge security threat. > > Would you mind disclosing which companies you represent, so I can ensure for the safety of my own money that I do not use them? > > -- > Tony Arcieri > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a1140e662aae9c7053dfce086 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


>
> If you look at the industry reports like the Verizon PCI Breach and Co= mpliance Reports, private keys simply aren't being stolen.=C2=A0 Maybe = there is an outlier or two but there certainly isn't a documented trend= I can find.=C2=A0 If you have contravening information to provide I am all= ears.

Surely you remember the day when all SWIFT provided devices = had to be replaced thanks to some fun in the random number generators. Then= there is POISON NUT.

The Shadow brokers leak included tools to extract VPN keys f= rom Cisco routers. TJ Maxx involved breaking WEP.

>
> - Andrew
>
>
>
> From: Tony Arcieri [mailto:bascul= e@gmail.com]
> Sent: Tuesday, September 27, 2016 4:17 PM
> To: BITS Security <BITSSecurity@fsroundtable.org>
> Cc: Peter Bowen <pzbowen@gmail= .com>; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <BITSSecurity@fsroundtable.org> wrote:=
> The PCI DSS is already requiring TLS 1.2 for financial institutions th= at participate in the Payment Card Industry.=C2=A0 .BANK (exclusive top lev= el banking domain) is also planning to require TLS 1.2.=C2=A0 =C2=A0We'= re anticipating that a regulatory body like these will require TLS 1.3 at s= ome point in the future.=C2=A0 Financial institutions then have to comply i= f they want to continue to do business with the companies represented by th= e regulatory body (like large credit card companies in the case of PCI). >
> Hello again,
>
> I work firsthand enforcing these requirements at a payments company. A= gain, I do not speak on behalf of my employer.
>
> It wasn't until last year that PCI decided to deprecate TLS 1.0, a= t the time a 16 year old standard. I think your sense of emergency is highl= y over-exaggerated.
>
> I find it highly unlikely that any group such as the PCI Council will = begin mandating TLS 1.3 any time soon. I would go as far as to call your co= ncerns "imaginary".
>
> If you are worried about such an eventuality, the IETF is the wrong pl= ace to complain. It is far, far too late in the TLS 1.3 process to be voici= ng these concerns. Where were you 2+ years ago when it was the appropriate = time in the TLS development cycle to voice such concerns? I think the view = of more "forward thinking" payments companies is TLS 1.3 has take= n too long already, and they would like to start deploying it in its curren= t form and would prefer unnecessary holdups/distractions which have already= occurred throughout the process.
>
> That said, there is still plenty of time to ensure that groups like th= e PCI Council do not put in place requirements which would affect the centr= alized traffic-decrypting MitM-capability on your payments stack. Perhaps y= ou should be voicing your concerns there? If you are worried about a TLS 1.= 3 mandate preventing your MitM capability, the onus is on you to convince t= he relevant payments standards bodies that mandating TLS 1.3 is a bad idea = for the payments industry. I think those organizations are better poised to= judge whether such an approach reflects on necessary requirements versus p= ervasive antipatterns among complacent companies unprepared for the future = and ripe for a data breach.
>
> In the meantime, you have disclosed a veritable treasure map to a traf= fic-decrypting single point of failure which ostensibly exists at all of th= e companies you represent which attackers could leverage to recover all pay= ment credentials. That sounds like a huge security threat.
>
> Would you mind disclosing which companies you represent, so I can ensu= re for the safety of my own money that I do not use them?
>
> --
> Tony Arcieri
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a1140e662aae9c7053dfce086-- From nobody Mon Oct 3 15:52:12 2016 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 4B844129413 for ; Mon, 3 Oct 2016 15:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 it9AFV9DuyCT for ; Mon, 3 Oct 2016 15:52:09 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B1A1293FE for ; Mon, 3 Oct 2016 15:52:09 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id u68so22549665uau.2 for ; Mon, 03 Oct 2016 15:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RIsitqjmWA1zUKunOHYQaamtmL/Dy6z9lEnYBeMnbcQ=; b=AxbjS6bNyU58nj46yiBvW0o+gjsifFqJwYDS6Z3wRllhf6l/MXP/mYRREIdxkMWJ0G H3TkPaH5Tl5SzWoEIv1lXI1ceTQ+UQw7PrVskHcRexoKeTF5v0FZYF276yWV9i+JqRUq +sa2IT6F+kggWBTbZKHtCvq/3+vU2Jtd4p96O6fjjwgOUkeNBLdor+6g39j3W+CUMmCy J9CBrCrMi9pXbmvsfDRFzRPAiJDaZxkQs+XAVqTQF8XtZPdpFV70EZneh7ZKBKy7tSkT TRpu0XgLyFgyq3zdZx/s0bAYr5VWdR4ZBJH5w+Mdm6DjQdWA5OmtmJqr1YAtCKZd6em9 q5SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RIsitqjmWA1zUKunOHYQaamtmL/Dy6z9lEnYBeMnbcQ=; b=JsJvPCjqrEUQsyVtCNLgTkqHqeYqGX6BXofDPbjs+oKverBfkbDT7nQNNRn87mP2Zy LQJ/b1Vs7Vw3TkBgFxi6afhU+wDZUmFYD9SGJsUm1NMLOg4FXqv00V8Fk7RBlr+tWNNN /CFadC1stP/Olxd4/f1CJcACOAqiaIbzR8QXVTCPfjiWEYyJrvZMPPcUtuD/mV9dIpoV 9qtMezsNbkT2BB+dgGMRUybMmN+ABpUqF5kLFXhxOeRaD5F/giwXXzORUosEUVxeVeoJ sM8TBu/aMxLqBUodLTrZtGo9fLzLun8yyYsUzYuP//fG6JUiTEzkGQgHHa2YmwITRgL5 rKTw== X-Gm-Message-State: AA6/9RmFdeasz5YtYZpsO9lig3SNP6GLNHZ4kRFac58Cn9ByK/4NaWuY9WnamfJQUOgz/2+1WjGVWn3WUdTE4g== X-Received: by 10.159.49.83 with SMTP id n19mr319374uab.113.1475535128656; Mon, 03 Oct 2016 15:52:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.153.195 with HTTP; Mon, 3 Oct 2016 15:51:48 -0700 (PDT) In-Reply-To: References: <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <126ee1b6-fc88-bf4e-c366-60d59a9b3350@gmail.com> From: Tony Arcieri Date: Mon, 3 Oct 2016 15:51:48 -0700 Message-ID: To: BITS Security Content-Type: multipart/alternative; boundary=f403045dce8a328416053dfdcb1a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Mon, 03 Oct 2016 22:52:11 -0000 --f403045dce8a328416053dfdcb1a Content-Type: text/plain; charset=UTF-8 On Mon, Oct 3, 2016 at 2:21 PM, BITS Security wrote: > If PCI has mandated upgrading TLS because of vulnerabilities, they are > likely to do it again and in fact have provided strong hints to the market > where they should be beyond the minimum requirement itself. This is simply not true. In 2015 the PCI council was pushing for updating to TLS 1.1+ in short order, but backed off out of "industry concerns" similar to the ones you are voicing here, and have delayed the mandatory rollout of TLS 1.1 until 2018. That's at least two years away. After that, they will deprecate TLS 1.1. That will probably take at least a year. So in 2019 (again, pure speculation as to the earliest time this will possibly happen), TLS 1.2 will be mandatory. After that, they may deprecate TLS 1.2 if it is demonstrated to be insecure. There is no reason to suspect at this point that that will even happen. TLS 1.2 is generally recognized as secure, and the "LTS" profile should fix whatever low-priority security concerns remain. > I don't see that the timing really matters because it isn't based on the > age of the standard, it is based on the standard becoming outdated. That is absolutely not true. The PCI's motivation for TLS version upgrades has been real-world security vulnerabilities, and again, it took them 15 years to deprecate TLS 1.0. There is absolutely no evidence that the PCI council plans on making TLS 1.3 mandatory any time soon, and if we follow a version-a-year cadence (which they're NOT presently working on, based on the one deprecation data point we have it's ~3 years per version) it will be 2020 at the earliest before it happens. You are asking the IETF to make a serious compromise regarding the security of the Internet based on *pure speculation*. A minimum degree of due diligence here would be to first ask the PCI council what their plans for mandating TLS 1.3 actually are, and if they *actually* give you a date that scares you, that might be a reason to voice concern so late in the process. I think what you're proposing is actively harmful to Internet security and you should be working with the PCI Council, not the IETF, to address your concerns. -- Tony Arcieri --f403045dce8a328416053dfdcb1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 3, 2016 at 2:21 PM, BITS Security <BITSSecurity@fsroun= dtable.org> wrote:
If PCI has mandated upgrading TLS because of vulnerabilities, th= ey are likely to do it again and in fact have provided strong hints to the = market where they should be beyond the minimum requirement itself.

This is simply not true. In 2015 the PCI council wa= s pushing for updating to TLS 1.1+ in short order, but backed off out of &q= uot;industry concerns" similar to the ones you are voicing here, and h= ave delayed the mandatory rollout of TLS 1.1 until 2018.

That's at least two years away.

After t= hat, they will deprecate TLS 1.1. That will probably take at least a year. = So in 2019 (again, pure speculation as to the earliest time this will possi= bly happen), TLS 1.2 will be mandatory.

After that= , they may deprecate TLS 1.2 if it is demonstrated to be insecure. There is= no reason to suspect at this point that that will even happen. TLS 1.2 is = generally recognized as secure, and the "LTS" profile should fix = whatever low-priority security concerns remain.
=C2=A0
I don't see that the timin= g really matters because it isn't based on the age of the standard, it = is based on the standard becoming outdated.

That is absolutely not true. The PCI's motivation for TLS version upgr= ades has been real-world security vulnerabilities, and again, it took them = 15 years to deprecate TLS 1.0.

There is absolutely= no evidence that the PCI council plans on making TLS 1.3 mandatory any tim= e soon, and if we follow a version-a-year cadence (which they're NOT pr= esently working on, based on the one deprecation data point we have it'= s ~3 years per version) it will be 2020 at the earliest before it happens.<= br>

You are asking the IETF to make a serious comp= romise regarding the security of the Internet based on *pure speculation*. = A minimum degree of due diligence here would be to first ask the PCI counci= l what their plans for mandating TLS 1.3 actually are, and if they *actuall= y* give you a date that scares you, that might be a reason to voice concern= so late in the process.

I think what you're p= roposing is actively harmful to Internet security and you should be working= with the PCI Council, not the IETF, to address your concerns.
--
Tony Arcieri
--f403045dce8a328416053dfdcb1a-- From olivier.levillain@ssi.gouv.fr Mon Oct 3 10:16:59 2016 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 C8C7E129421 for ; Mon, 3 Oct 2016 10:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Xa03T9WEySvP for ; Mon, 3 Oct 2016 10:16:57 -0700 (PDT) Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1624012941D for ; Mon, 3 Oct 2016 10:16:56 -0700 (PDT) Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 8560390B8CD for ; Mon, 3 Oct 2016 19:16:54 +0200 (CEST) References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> <1470648042.3026.44.camel@redhat.com> <1474278590.144982.255.camel@infradead.org> From: Olivier Levillain X-Enigmail-Draft-Status: N1110 To: tls@ietf.org Message-ID: <57F291BC.9010604@ssi.gouv.fr> Date: Mon, 3 Oct 2016 19:13:32 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 03 Oct 2016 20:51:00 -0700 Subject: Re: [TLS] TLS1.3 + PSK with multiple identities 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: Mon, 03 Oct 2016 17:39:20 -0000 Hi list, I have been working in the labs at ANSSI (the French Network and Information System Agency) for several years and I just defended my PhD thesis on the TLS ecosystem (documents are available at http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/). >> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote: >>> On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote: >>>> More compact and makes the option where server sends some bad option >>>> more clear. >> Note that if we really want to be more compact, we might also observe >> that there is a redundant length field in the extension as sent by the >> client: >> case client_hello: >> PskIdentity identities<6..2^16-1>; >> >> Each extension has at least four bytes on the wire — the extension_type >> itself, and the length field of the extension_data in a uint16. >> >> If I am interpreting the spec correctly, then the data for the >> PreSharedKeyIdentity extension in the ClientHello then follows that >> with another uint16, which is *always* a value two lower than the one >> which immediately precedes it. >> >> e.g. >> >> 0x00 0x29 // ExtensionType extension_type == 41 >> 0x00 0x14 // opaque extension_data<0..2^16-1> >> // This length field is entirely redundant: >> 0x00 0x12 // PskIdentity identities<6..2^16-1> >> // First identity: >> 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode >> 0x00 0x04 // opaque identity<0..2^16-1> >> 0x44 0x61 0x76 0x65 // "Dave" >> // Second identity: >> 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode >> 0x00 0x06 // opaque identity<0..2^16-1)> >> 0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë" >> >> Do we care that the '0x00 0x12' bytes on my third line above are >> entirely redundant on the wire? Or have I interpreted it wrong? >> > Not enough to fix it, this is just the way TLS rolls. Sorry if I am a little late to the party, but I noticed that even if this is generally true, I believe it has not always been enforced in TLS extensions. In 2006, the IETF standardised the session tickets extension, allowing for session resumption without server-side state (RFC 4507). However, no TLS stack implements the specification correctly: even if the specification described the _content_ of the extension as a variable-length object (that is an opaque object prefixed by its length), every implementation ignores this second (useless) length field. The RFC 5077, published in 2008, fixes the gap between the specification and the implementations. RFC 4507 : The SessionTicket extension has been assigned the number 35. The format of the SessionTicket extension is given at the end of this section. struct { opaque ticket<0..2^16-1>; } SessionTicket; 00 23 Ticket Extension type 35 01 02 Length of extension contents 01 00 Length of ticket FF FF .. .. Actual ticket RFC 5077 The SessionTicket extension has been assigned the number 35. The extension_data field of SessionTicket extension contains the ticket. 00 23 Ticket Extension type 35 01 00 Length of extension contents (ticket) FF FF .. .. Actual ticket Best regards, olivier From nobody Tue Oct 4 03:19:16 2016 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 37225129799 for ; Tue, 4 Oct 2016 03:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yNuwp7SygpBM for ; Tue, 4 Oct 2016 03:19:13 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E3D129780 for ; Tue, 4 Oct 2016 03:19:13 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id k125so197930549wma.1 for ; Tue, 04 Oct 2016 03:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=rhm+QSWevaCgFM34wln66tVXSP3wClReO0ZIr69p440=; b=vdTNBJCF9pemqmTwsl9JEo2bPQj5IB7/immAJJqmyZW5VVVy6J6Agdlrtm6z2Zjsk+ h3idXUs6Ua+WswxR1BzgCmxpsJEu3mrIeLTXnvmHSEXv1tG9cHPQrR0GC9RRic99RY4C uma8jYIotVTWN7Cs0Dx8PdXYya2ADjHXuYmAMD117O12U3iayUA/0ZDVEZ6nfUTBUg9x hvnPAxj5ElBxkqhIIM0sjQy+T0Ws0wfKfaHNx295OcQtD4q6fdpYr8BSHTtvIlPtbWPh mrXYvYDoJsZTWEDR8FC8/BWHnuIWBSiDp0rUIUYSqV1k0DprWgXHY3dJPxCC8L19jaSA qXow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rhm+QSWevaCgFM34wln66tVXSP3wClReO0ZIr69p440=; b=bcB4fewe821o53dhyrWD9JwpH/WoZqBrmfcVCtQNkj01QnkOU/1l5+ER7bKxzhOk9P F2VUjwUokPz/FRlUhlYbfPhXkzxid0w/J2dFcTkLZTH3nL2/dLrDncj+oSw5xbPgB8l6 Q7QAszhXHYnjAFYX6UhFrucA3twmeA0opV4aD8h3KD5e/HsyV2N05lNoflS5D6wSEvhv cLFXe5IcgFLYkgbZwddOgUkdq35GxX7iE8vKpIcKumM/eJa24KXymTvxpARZ2+t0uLC7 oRMj8dzFF8PzwY9r0zifu8kTv46eUeyoqlNZqTIxPfo32v9QfdwBhi+COkL4ed72Ltsp /LGg== X-Gm-Message-State: AA6/9Rnbj1jYYN1rjxDyUdR0cDVRhMDB6FrDXiSaSdoHpJ0dQjogeQ80+vhF/GFp+SQ6/A== X-Received: by 10.28.47.87 with SMTP id v84mr13035357wmv.50.1475576351676; Tue, 04 Oct 2016 03:19:11 -0700 (PDT) Received: from [10.0.0.10] (bzq-109-67-151-176.red.bezeqint.net. [109.67.151.176]) by smtp.gmail.com with ESMTPSA id rk14sm2759116wjb.6.2016.10.04.03.19.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2016 03:19:10 -0700 (PDT) References: <147557521091.12876.13022923747840220361.idtracker@ietfa.amsl.com> To: "tls@ietf.org" From: Yaron Sheffer X-Forwarded-Message-Id: <147557521091.12876.13022923747840220361.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 4 Oct 2016 13:19:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147557521091.12876.13022923747840220361.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-03.txt 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: Tue, 04 Oct 2016 10:19:15 -0000 Daniel and I just submitted a new version of this draft. Other than numerous editorial improvements and clarifications, the main changes are to the cryptographic operations, to bring them in-line with the latest version of TLS 1.3. Thanks, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-sheffer-tls-pinning-ticket-03.txt Date: Tue, 04 Oct 2016 03:00:10 -0700 From: internet-drafts@ietf.org To: Yaron Sheffer , Daniel Migault A new version of I-D, draft-sheffer-tls-pinning-ticket-03.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheffer-tls-pinning-ticket Revision: 03 Title: TLS Server Identity Pinning with Tickets Document date: 2016-10-04 Group: Individual Submission Pages: 23 URL: https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-03.txt Status: https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/ Htmlized: https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-sheffer-tls-pinning-ticket-03 Abstract: Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate, but none is currently in wide use. This document proposes to extend TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership if the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Oct 4 18:32:23 2016 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 14C75129421 for ; Tue, 4 Oct 2016 18:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 95cuvnXKRHhR for ; Tue, 4 Oct 2016 18:32:21 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF6D129415 for ; Tue, 4 Oct 2016 18:32:20 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o68so66391163qkf.3 for ; Tue, 04 Oct 2016 18:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=DEdFp/JIj3FUGBIwlp0eXn2Cl5JHQEEPtTjoMtOIkro=; b=hjIJXNsaO8nTPU2T+JOedfwu1EagfyMQX3PksCUOFhM/t0xD/ioMqlanjm4cl0VVp+ yroStKxa5fv7fQkfW5fq9D34FK/f84fmdqxxgBf2wqG7LqBFwprCRb3Jiin0i/FVpRTm AFL3dJVikdcu/1prAfiby9+TFvv0LK0IOSlEYFrle7QqwXJYSqk40qyReSIWyV6d3LS7 SLxtoaHa2S7wjzVwNA7zZjJtEV9lWOfX2OBj+DsNdpfxIWIm6WSBt/BEg/mhZJ375wR4 nyHGmS7Cdt4y18eTPXL/3go1Qwly6Xzokh1N+jQaKOn4oy1xhME5IiH+XED5Tk0dte+7 sTqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DEdFp/JIj3FUGBIwlp0eXn2Cl5JHQEEPtTjoMtOIkro=; b=gfy4zjc9zmDpAdmTRigns4HP1nCATlQR3/5t7AT0rBPYPo/FaBwt5QwgTB+pv9JH7o e4VO4XU4Cjw30Gki0vMoS/Zj8GGLPEI5lVa+f7upwe6w9t3T7lPr0ul/LEAKzXzApfJP OA+ESJqq8gPxgNC8bxS+P5fLXeeXidtiXxkwNQ9KBmwhEFA1iXtmu938Isd0vqaiXtfi aMqZrmMwgr6JcwNelIk/Oj4Ujc41q8OXqta2HJ/TngS1y1c8wxXtYNR60lVsBMxjeXDP XjyavR+CqH8iP4akoALRaUCPR1AOnJk9HQwMzAFFNj2fDk8nqNSULFXCgbznzOpCIx8E B96w== X-Gm-Message-State: AA6/9RnlWKgmZtgfI6xRmuG75SCHYHxFslXNUmyPYRfWhzEj4nkP2ZvQwgF4kdU+wyVkVNOh62keoebpgu21kg== X-Received: by 10.55.167.149 with SMTP id q143mr6360071qke.97.1475631140013; Tue, 04 Oct 2016 18:32:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Tue, 4 Oct 2016 18:32:19 -0700 (PDT) From: Martin Thomson Date: Wed, 5 Oct 2016 12:32:19 +1100 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Exporter output size 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: Wed, 05 Oct 2016 01:32:22 -0000 After a bunch of discussion about the consequences of having insufficient output from various stages of the hash functions... Could we make an amendment to TLS 1.3 to force the output size of the exporter to be the size of the underlying hash output? That is, remove the length parameter. Or is a change to the API too disruptive? From nobody Tue Oct 4 20:49:42 2016 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 9AC9F128874 for ; Tue, 4 Oct 2016 20:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 ziG0tPpW5EJb for ; Tue, 4 Oct 2016 20:49:40 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCD3129492 for ; Tue, 4 Oct 2016 20:49:39 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id e20so48440ybb.0 for ; Tue, 04 Oct 2016 20:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vPYmlh6xrGREq8+4XNCrKbaYwKP3dgHOzg7CLDi436A=; b=ZfpFq2PnVL779byfpr/hado9wAZbUY14nR0iMhw4ppLq5yIO07tKeYpcm0+p2fpEb7 9tPnfSw2Muixih6fC9zU7QjHOudkT3TH2AxbqY+3dr83Iwh0nkHv0aL13Z5kdLZhoL/o gG0yr05yc1p8LE0pDgZVGffGhbRAPghLtduvf/bBCqZLDrYOgc/dM4obSo+LTE8Dminb lhVziEF742I3+Vp5CuEfPWWiKKfnKL8SYJOHrJ6n2yMnEZ95+TCm1me8Uy1CGKVQOMEE yY+CiL7zJB+bJY9D20vXmyDGvwc0xD5wEuWcZfgBWag6qavS6g2X4Xeyp9vIXRe9Peg2 myvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vPYmlh6xrGREq8+4XNCrKbaYwKP3dgHOzg7CLDi436A=; b=gip6KTHGZLXr2IGbWhjxAJLDb+RLQRtZu6A/iqzj8O7TqUJUtsgz5INutCs2ZDDi40 /pb8gDPeCOvEIRLFpw2RQ8k2u/Z0tcwzR3Qa5+oHu9upazobDSuQUn5HtUjQsYPGyH7Q a+r3Ep4kb3jSvtUvENJn+su1EVkeH4P/itL3w5r39TTwMs8PLOfbefoOP7sEHRtOr9FH wpuwdjaIeIwmYWjf/MRU7gg7eq57uJnJd8HMjz2K55kwxKUtOpW+kEp74JSQEhEVtOOC rJI/V9T2vp61FKmAI+OfhttoI1ZNdo/6THZSHfjenpjTU/pjxQwP1f17l32GCXJjwFKT 2bWQ== X-Gm-Message-State: AA6/9Rli1GtkgPN8BO5mGEeLepHPejXFT4JIWIVe43gG4pduS7aq6XT9XNcuCYhCOl0TC09E5Tcid/SYrOFIiA== X-Received: by 10.37.3.132 with SMTP id 126mr5380331ybd.64.1475639378484; Tue, 04 Oct 2016 20:49:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.160.10 with HTTP; Tue, 4 Oct 2016 20:48:58 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 4 Oct 2016 20:48:58 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c06d52f8f7ff053e1610b4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Exporter output size 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: Wed, 05 Oct 2016 03:49:41 -0000 --001a11c06d52f8f7ff053e1610b4 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 4, 2016 at 6:32 PM, Martin Thomson wrote: > After a bunch of discussion about the consequences of having > insufficient output from various stages of the hash functions... Could > we make an amendment to TLS 1.3 to force the output size of the > exporter to be the size of the underlying hash output? That is, > remove the length parameter. Or is a change to the API too > disruptive? > I don't think this is a good idea. There are plenty of reasons why you would want to export values != hash_len (e.g., cryptographic keys). Putting a restriction here just pushes the problem around -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c06d52f8f7ff053e1610b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 4, 2016 at 6:32 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
After a bunch of = discussion about the consequences of having
insufficient output from various stages of the hash functions... Could
we make an amendment to TLS 1.3 to force the output size of the
exporter to be the size of the underlying hash output?=C2=A0 That is,
remove the length parameter.=C2=A0 Or is a change to the API too
disruptive?

I don't think this is a= good idea. There are plenty of reasons why you would want to
exp= ort values !=3D hash_len (e.g., cryptographic keys). Putting a restriction = here just
pushes the problem around

-Ekr=


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

--001a11c06d52f8f7ff053e1610b4-- From nobody Wed Oct 5 05:03:29 2016 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 175D01296BF for ; Wed, 5 Oct 2016 05:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.995 X-Spam-Level: X-Spam-Status: No, score=-4.995 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, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de 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 wVBs-5P8GQuX for ; Wed, 5 Oct 2016 05:03:22 -0700 (PDT) Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DC51296B6 for ; Wed, 5 Oct 2016 05:03:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id 8B534F42767 for ; Wed, 5 Oct 2016 14:03:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1475668996; x= 1476532997; bh=swUFYeMvzx+pfJFOBWsN3BTDZfgGRYpE6GFS1Wh/Wws=; b=G nyXhtAeVHkwdHtv5I5oP8wjcUVg9xMtb29pOsoShKY/U2iTraB6waLFgYSZDLMhN lA90Xd4/3KnwSrMSpY26suSomDmSAeJpWlqo8TUPSY4Wfx2d6LYWGYF2Q+n+gkXo wqvnkb5HEyDxNa1c0amZ+goUo/M+pqssYU1RCSOlpE= X-Virus-Scanned: amavisd-new at hs-offenburg.de Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLfBQEbYy-jh for ; Wed, 5 Oct 2016 14:03:16 +0200 (CEST) Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 8F4FAF4275A for ; Wed, 5 Oct 2016 14:03:16 +0200 (CEST) Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Wed, 05 Oct 2016 14:03:16 +0200 Message-Id: <57F50825020000AC0011D029@gwia2.rz.hs-offenburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.1 Date: Wed, 05 Oct 2016 14:03:17 +0200 From: "Andreas Walz" To: References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> <1470648042.3026.44.camel@redhat.com> <1474278590.144982.255.camel@infradead.org> <57F291BC.9010604@ssi.gouv.fr> In-Reply-To: <57F291BC.9010604@ssi.gouv.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part32049C15.0__=" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS1.3 + PSK with multiple identities 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: Wed, 05 Oct 2016 12:03:27 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part32049C15.0__= Content-Type: multipart/alternative; boundary="=__Part32049C15.1__=" --=__Part32049C15.1__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Olivier, your findings are interesting as they pretty much match with what we have found when studying TLS implementations for embedded systems. In many implementations there is a tendency to ignore redundant length fields (or at least to not enforce consistency). There has been some discussion about this on the list, see thread "Suspicious behaviour of TLS server implementations". We are currently refining our study and in the process of writing a paper. I hopefully can give more details on results soon. Cheers, Andi ___________________________________ Andreas Walz Research Engineer Institute of reliable Embedded Systems and Communication Electronics (ivESK) Offenburg University of Applied Sciences, 77652 Offenburg, Germany >>> Olivier Levillain 10/04/16 5:51 AM >>> Hi list, I have been working in the labs at ANSSI (the French Network and Information System Agency) for several years and I just defended my PhD thesis on the TLS ecosystem (documents are available at http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/). >> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote: >>> On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote: >>>> More compact and makes the option where server sends some bad option >>>> more clear. >> Note that if we really want to be more compact, we might also observe >> that there is a redundant length field in the extension as sent by the >> client: >> case client_hello: >> PskIdentity identities<6..2^16-1>; >> >> Each extension has at least four bytes on the wire — the extension_type >> itself, and the length field of the extension_data in a uint16. >> >> If I am interpreting the spec correctly, then the data for the >> PreSharedKeyIdentity extension in the ClientHello then follows that >> with another uint16, which is *always* a value two lower than the one >> which immediately precedes it. >> >> e.g. >> >> 0x00 0x29 // ExtensionType extension_type == 41 >> 0x00 0x14 // opaque extension_data<0..2^16-1> >> // This length field is entirely redundant: >> 0x00 0x12 // PskIdentity identities<6..2^16-1> >> // First identity: >> 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode >> 0x00 0x04 // opaque identity<0..2^16-1> >> 0x44 0x61 0x76 0x65 // "Dave" >> // Second identity: >> 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode >> 0x00 0x06 // opaque identity<0..2^16-1)> >> 0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë" >> >> Do we care that the '0x00 0x12' bytes on my third line above are >> entirely redundant on the wire? Or have I interpreted it wrong? >> > Not enough to fix it, this is just the way TLS rolls. Sorry if I am a little late to the party, but I noticed that even if this is generally true, I believe it has not always been enforced in TLS extensions. In 2006, the IETF standardised the session tickets extension, allowing for session resumption without server-side state (RFC 4507). However, no TLS stack implements the specification correctly: even if the specification described the _content_ of the extension as a variable-length object (that is an opaque object prefixed by its length), every implementation ignores this second (useless) length field. The RFC 5077, published in 2008, fixes the gap between the specification and the implementations. RFC 4507 : The SessionTicket extension has been assigned the number 35. The format of the SessionTicket extension is given at the end of this section. struct { opaque ticket<0..2^16-1>; } SessionTicket; 00 23 Ticket Extension type 35 01 02 Length of extension contents 01 00 Length of ticket FF FF .. .. Actual ticket RFC 5077 The SessionTicket extension has been assigned the number 35. The extension_data field of SessionTicket extension contains the ticket. 00 23FF FF .. .. Actual ticket Best regards, olivier _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --=__Part32049C15.1__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML =0Abody p =0A{ =0A margin: 0px; =0A}=0AHi Olivier,

your findings are interesting as = they pretty much match with what we have found when studying TLS implementa= tions for embedded systems. In many implementations there is a tendency to = ignore redundant length fields (or at least to not enforce consistency). = There has been some discussion about this on the list, see thread = "Suspicious behaviour of TLS server implementations".

We are = currently refining our study and in the process of writing a paper. I = hopefully can give more details on results soon.

Cheers,
Andi

_________________________________= __

Andreas Walz
Research Engineer
Institute of reliable = Embedded Systems and Communication Electronics (ivESK)
Offenburg = University of Applied Sciences, 77652 Offenburg, Germany


>>= ;> Olivier Levillain <olivier.levillain@ssi.gouv.fr> = 10/04/16 5:51 AM >>>
Hi list,

I have been = working in the labs at ANSSI (the French Network and
Information System = Agency) for several years and I just defended my PhD
thesis on the TLS = ecosystem (documents are available at
http://paperstreet.picty.org/~yeye= /2016/phdthesis-Levillain16/).

>> On Mon, 2016-09-19 at 10:29 = +0200, Nikos Mavrogiannopoulos wrote:
>>> On Mon, 2016-08-08 = at 11:28 +0300, Ilari Liusvaara wrote:
>>>> More compact = and makes the option where server sends some bad option
>>>>= more clear.
>> Note that if we really want to be more compact, = we might also observe
>> that there is a redundant length field = in the extension as sent by the
>> client:
>> = case client_hello:
>> PskIdentity identities<6..= 2^16-1>;
>>
>> Each extension has at least four bytes = on the wire =E2=80=94 the extension_type
>> itself, and the = length field of the extension_data in a uint16.
>>
>> If = I am interpreting the spec correctly, then the data for the
>> = PreSharedKeyIdentity extension in the ClientHello then follows that
>= > with another uint16, which is *always* a value two lower than the = one
>> which immediately precedes it.
>>
>> = e.g.
>>
>> 0x00 0x29 // ExtensionType extension_ty= pe =3D=3D 41
>> 0x00 0x14 // opaque extension_data<0..2^= 16-1>
>> // This length field is entirely redundant:
>= ;> 0x00 0x12 // PskIdentity identities<6..2^16-1>
>= > // First identity:
>> 0x00 0x00 = // PskKeyExchangeMode, PskAuthenticationMode
>> 0x00 = 0x04 // opaque identity<0..2^16-1>
>> 0x44 = 0x61 0x76 0x65 // "Dave"
>> // Second = identity:
>> 0x00 0x00 // PskKeyExchangeMode, = PskAuthenticationMode
>> 0x00 0x06 // opaque identity&l= t;0..2^16-1)>
>> 0x43 0x68 0x6c 0x6f 0xc3 0xab // = "Chlo=C3=AB"
>>
>> Do we care that the '0x00 0x12' bytes = on my third line above are
>> entirely redundant on the wire? Or = have I interpreted it wrong?
>>
> Not enough to fix it, = this is just the way TLS rolls.

Sorry if I am a little late to the = party, but I noticed that even if
this is generally true, I believe it = has not always been enforced in TLS
extensions.

In 2006, the = IETF standardised the session tickets extension, allowing
for session = resumption without server-side state (RFC 4507).
However, no TLS stack = implements the specification correctly: even
if the specification = described the _content_ of the extension as
a variable-length object = (that is an opaque object prefixed by its
length), every implementation = ignores this second (useless) length
field. The RFC 5077, published in = 2008, fixes the gap
between the specification and the implementations.
RFC 4507 :

The SessionTicket extension has been assigned
th= e number 35. The format of the SessionTicket
extension is given at the = end of this section.

struct {
opaque ticket<0..2^16-1>= ;;
} SessionTicket;

00 23 Ticket Extension type = 35
01 02 Length of extension contents
01 00 Length = of ticket
FF FF .. .. Actual ticket

RFC 5077

The = SessionTicket extension has been assigned
the number 35. The extension_= data field of
SessionTicket extension contains the ticket.

00 23 = Ticket Extension type 35
01 00 Length of extension = contents (ticket)
FF FF .. .. Actual ticket


Best = regards,
olivier

_______________________________________________<= br>TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinf= o/tls
--=__Part32049C15.1__=-- --=__Part32049C15.0__=-- From nobody Wed Oct 5 05:19:57 2016 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 145441296D1 for ; Wed, 5 Oct 2016 05:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.206 X-Spam-Level: X-Spam-Status: No, score=-7.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no 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 F95i8CPvFolP for ; Wed, 5 Oct 2016 05:19:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100E11296D2 for ; Wed, 5 Oct 2016 05:19:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSL04271; Wed, 05 Oct 2016 12:19:45 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 5 Oct 2016 13:19:42 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.156]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Wed, 5 Oct 2016 17:49:30 +0530 From: Raja ashok To: Andreas Walz Thread-Topic: Prospects of draft-jay-tls-psk-identity-extension Thread-Index: AQHSHwIon0PqHYk2kUCZjGs0ELNAXaCZxq1w Date: Wed, 5 Oct 2016 12:19:30 +0000 Message-ID: References: <57F50AEF020000AC0011D039@gwia2.rz.hs-offenburg.de> In-Reply-To: <57F50AEF020000AC0011D039@gwia2.rz.hs-offenburg.de> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18F96D5BLREML509MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.57F4EFE3.00A4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.156, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bf4821274f0e3ea4359196cbb0dc973c Archived-At: Cc: "jayaraghavendran@gmail.com" , "tls@ietf.org" Subject: Re: [TLS] Prospects of draft-jay-tls-psk-identity-extension 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: Wed, 05 Oct 2016 12:19:56 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18F96D5BLREML509MBXchi_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18F96D5BLREML509MBXchi_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18F96D5BLREML509MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5kcmVhcywNCg0KTGFzdCB3ZWVrIHJlY2VpdmVkIHNvbWUgY29tbWVudHMgZnJvbSBJbGFy aSBhbmQgRGF2aWQuIFdlIGFyZSB3b3JraW5nIG9uIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhpcyBk cmFmdC4gV2Ugd2lsbCB1cGxvYWQgaXQgc29vbi4NCg0KUmVnYXJkcywNCkFzaG9rDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KUmFqYSBBc2hvayBWSw0K5Y2O5Li65oqA5pyv5pyJ 6ZmQ5YWs5Y+4IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpbQ29tcGFueV9sb2dvXQ0K DQpQaG9uZToNCkZheDoNCk1vYmlsZToNCkVtYWlsOg0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4s IEx0ZC4NCkJhbmdhbG9yZSwgSW5kaWENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4 uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4 reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgQ0K5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu7 5L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE 6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitDQrnmoTkv6Hmga/jgILlpoLm npzmgqjplJnmlLbkuobmnKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrn n6Xlj5Hku7bkurrlubbliKDpmaTmnKzpgq7ku7bvvIENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0 YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdo aWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRy ZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFs IG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikg YnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hp Yml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQh DQpGcm9tOiBBbmRyZWFzIFdhbHogW21haWx0bzphbmRyZWFzLndhbHpAaHMtb2ZmZW5idXJnLmRl XQ0KU2VudDogMDUgT2N0b2JlciAyMDE2IDE3OjQ1DQpUbzogamF5YXJhZ2hhdmVuZHJhbi5rQGh1 YXdlaS5jb207IFJhamEgYXNob2sNClN1YmplY3Q6IFByb3NwZWN0cyBvZiBkcmFmdC1qYXktdGxz LXBzay1pZGVudGl0eS1leHRlbnNpb24NCg0KRGVhciBhdXRob3JzIG9mIGRyYWZ0LWpheS10bHMt cHNrLWlkZW50aXR5LWV4dGVuc2lvbiwNCg0KSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgdGhlcmUg aXMgYW55IHBsYW4gdG8gcmV2aXZlIHlvdXIgZHJhZnQgb24gdGhlIFRMUy1QU0staWRlbnRpdHkt ZXh0ZW5zaW9uLiBJIHZlcnkgbXVjaCBsaWtlZCB0aGUgaWRlYSBhbmQgd2UgYWxzbyBoYXZlIGEg dXNlIGNhc2Ugd2hlcmUgaXQgbWlnaHQgYmUgdmVyeSBoZWxwZnVsLg0KDQpUaGFua3MgZm9yIHlv dXIgYW5zd2VyLg0KDQpXaXRoIGJlc3QgcmVnYXJkcywNCkFuZGkgV2Fseg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpBbmRyZWFzIFdhbHoNClJlc2VhcmNoIEVuZ2lu ZWVyDQpJbnN0aXR1dGUgb2YgcmVsaWFibGUgRW1iZWRkZWQgU3lzdGVtcyBhbmQgQ29tbXVuaWNh dGlvbiBFbGVjdHJvbmljcyAoaXZFU0spDQpPZmZlbmJ1cmcgVW5pdmVyc2l0eSBvZiBBcHBsaWVk IFNjaWVuY2VzLCA3NzY1MiBPZmZlbmJ1cmcsIEdlcm1hbnkNCg== --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18F96D5BLREML509MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7 DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrljY7mlofnu4bpu5E7 DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWNjuaWh+e7hum7kSI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpzcGFuLmdyb3Vwd2lzZXJlcGx5aGVhZGVyDQoJe21zby1zdHlsZS1u YW1lOmdyb3Vwd2lzZXJlcGx5aGVhZGVyO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjIwNTAiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmRyZWFzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGFzdCB3ZWVr IHJlY2VpdmVkIHNvbWUgY29tbWVudHMgZnJvbSBJbGFyaSBhbmQgRGF2aWQuIFdlIGFyZSB3b3Jr aW5nIG9uIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhpcyBkcmFmdC4gV2Ugd2lsbCB1cGxvYWQgaXQg c29vbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFz aG9rPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk65a6L5L2TO2NvbG9yOiMxRjQ5N0QiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAl IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+WNjuaWh+e7hum7 kSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmFqYSBBc2hvayBWSzxicj4N CjxzcGFuIGxhbmc9IlpILUNOIj7ljY7kuLrmioDmnK/mnInpmZDlhazlj7g8L3NwYW4+IEh1YXdl aSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuPGJyPg0KPC9zcGFuPjwhLS1baWYgZ3RlIHZtbCAxXT48 djpzaGFwZXR5cGUgaWQ9Il94MDAwMF90NzUiIGNvb3Jkc2l6ZT0iMjE2MDAsMjE2MDAiIG86c3B0 PSI3NSIgbzpwcmVmZXJyZWxhdGl2ZT0idCIgcGF0aD0ibUA0QDVsQDRAMTFAOUAxMUA5QDV4ZSIg ZmlsbGVkPSJmIiBzdHJva2VkPSJmIj4NCjx2OnN0cm9rZSBqb2luc3R5bGU9Im1pdGVyIiAvPg0K PHY6Zm9ybXVsYXM+DQo8djpmIGVxbj0iaWYgbGluZURyYXduIHBpeGVsTGluZVdpZHRoIDAiIC8+ DQo8djpmIGVxbj0ic3VtIEAwIDEgMCIgLz4NCjx2OmYgZXFuPSJzdW0gMCAwIEAxIiAvPg0KPHY6 ZiBlcW49InByb2QgQDIgMSAyIiAvPg0KPHY6ZiBlcW49InByb2QgQDMgMjE2MDAgcGl4ZWxXaWR0 aCIgLz4NCjx2OmYgZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVsSGVpZ2h0IiAvPg0KPHY6ZiBlcW49 InN1bSBAMCAwIDEiIC8+DQo8djpmIGVxbj0icHJvZCBANiAxIDIiIC8+DQo8djpmIGVxbj0icHJv ZCBANyAyMTYwMCBwaXhlbFdpZHRoIiAvPg0KPHY6ZiBlcW49InN1bSBAOCAyMTYwMCAwIiAvPg0K PHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxIZWlnaHQiIC8+DQo8djpmIGVxbj0ic3VtIEAx MCAyMTYwMCAwIiAvPg0KPC92OmZvcm11bGFzPg0KPHY6cGF0aCBvOmV4dHJ1c2lvbm9rPSJmIiBn cmFkaWVudHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9InJlY3QiIC8+DQo8bzpsb2NrIHY6ZXh0 PSJlZGl0IiBhc3BlY3RyYXRpbz0idCIgLz4NCjwvdjpzaGFwZXR5cGU+PHY6c2hhcGUgaWQ9InJp ZEltZyIgbzpzcGlkPSJfeDAwMDBfczEwMjYiIHR5cGU9IiNfeDAwMDBfdDc1IiBhbHQ9IkNvbXBh bnlfbG9nbyIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRv cDowO3dpZHRoOjc2LjVwdDtoZWlnaHQ6MjRwdDt6LWluZGV4OjE7dmlzaWJpbGl0eTp2aXNpYmxl O21zby13cmFwLXN0eWxlOnNxdWFyZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjA7bXNvLXdyYXAt ZGlzdGFuY2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6MDttc28td3JhcC1kaXN0YW5j ZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDpsZWZ0O21zby1wb3NpdGlvbi1ob3Jp em9udGFsLXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1w b3NpdGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTpsaW5lJyBvOmFsbG93b3ZlcmxhcD0iZiI+DQo8djpp bWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDIxRjMwLkQxRkE3OEIwIiBvOmhyZWY9 ImZpbGU6Ly8vQzpcVXNlcnNccjAwOTAyNzM2XEFwcGxpY2F0aW9uJTIwRGF0YVxNaWNyb3NvZnRc U2lnbmF0dXJlc1xjb21wYW55X2xvZ28uanBnIiAvPg0KPHc6d3JhcCB0eXBlPSJzcXVhcmUiIGFu Y2hvcnk9ImxpbmUiLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48aW1nIHdp ZHRoPSIxMDIiIGhlaWdodD0iMzIiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQyMUYzMC5EMUZB NzhCMCIgYWxpZ249ImxlZnQiIGFsdD0iQ29tcGFueV9sb2dvIiB2OnNoYXBlcz0icmlkSW1nIj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5Y2O5paH57uG6buRJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8 YnI+DQpQaG9uZTogPGJyPg0KRmF4OiA8YnI+DQpNb2JpbGU6IDxicj4NCkVtYWlsOiA8YnI+DQpI dWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxicj4NCkJhbmdhbG9yZSwgSW5kaWE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDvljY7mlofnu4bpu5EmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPmh0dHA6Ly93d3cuaHVhd2VpLmNvbTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOiMxRjQ5N0QiPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZM7Y29sb3I6IzFG NDk3RCI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFu PjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDvljY7mlofnu4bpu5EmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Z3JheSI+5pys6YKu5Lu25Y+K5YW26ZmE5Lu25ZCr 5pyJ5Y2O5Li65YWs5Y+455qE5L+d5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ5LiK6Z2i 5Zyw5Z2A5Lit5YiX5Ye655qE5Liq5Lq65oiW576k57uE44CC56aBPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75Y2O5paH57uG6buRJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmdyYXkiPjxicj4NCjxzcGFuIGxhbmc9IlpILUNOIj7mraLk u7vkvZXlhbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7l hajpg6jmiJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bk uK08L3NwYW4+PGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iPueahOS/oeaBr+OAguWmguaenOaCqOmU meaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteivneaIlumCruS7tumAmuefpeWPkeS7 tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gTwvc3Bhbj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmdyYXkiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQo8YnI+ DQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNz IGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCjxicj4NCmluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRv dGFsIG9yIHBhcnRpYWwNCjxicj4NCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2Vt aW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+DQpyZWNpcGll bnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KPGJyPg0KcGhvbmUgb3IgZW1haWwgaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSBpdCE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW5k cmVhcyBXYWx6IFttYWlsdG86YW5kcmVhcy53YWx6QGhzLW9mZmVuYnVyZy5kZV0NCjxicj4NCjxi PlNlbnQ6PC9iPiAwNSBPY3RvYmVyIDIwMTYgMTc6NDU8YnI+DQo8Yj5Ubzo8L2I+IGpheWFyYWdo YXZlbmRyYW4ua0BodWF3ZWkuY29tOyBSYWphIGFzaG9rPGJyPg0KPGI+U3ViamVjdDo8L2I+IFBy b3NwZWN0cyBvZiBkcmFmdC1qYXktdGxzLXBzay1pZGVudGl0eS1leHRlbnNpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RGVhciBhdXRob3JzIG9mIGRyYWZ0LWpheS10bHMtcHNrLWlkZW50aXR5LWV4 dGVuc2lvbiw8YnI+DQo8YnI+DQpJIHdhcyB3b25kZXJpbmcgd2hldGhlciB0aGVyZSBpcyBhbnkg cGxhbiB0byByZXZpdmUgeW91ciBkcmFmdCBvbiB0aGUgVExTLVBTSy1pZGVudGl0eS1leHRlbnNp b24uIEkgdmVyeSBtdWNoIGxpa2VkIHRoZSBpZGVhIGFuZCB3ZSBhbHNvIGhhdmUgYSB1c2UgY2Fz ZSB3aGVyZSBpdCBtaWdodCBiZSB2ZXJ5IGhlbHBmdWwuPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5 b3VyIGFuc3dlci48YnI+DQo8YnI+DQpXaXRoIGJlc3QgcmVnYXJkcyw8YnI+DQpBbmRpIFdhbHo8 YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iZ3JvdXB3aXNlcmVwbHloZWFkZXIiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJn cm91cHdpc2VyZXBseWhlYWRlciI+QW5kcmVhcyBXYWx6PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNz PSJncm91cHdpc2VyZXBseWhlYWRlciI+UmVzZWFyY2ggRW5naW5lZXI8L3NwYW4+PGJyPg0KPHNw YW4gY2xhc3M9Imdyb3Vwd2lzZXJlcGx5aGVhZGVyIj5JbnN0aXR1dGUgb2YgcmVsaWFibGUgRW1i ZWRkZWQgU3lzdGVtcyBhbmQgQ29tbXVuaWNhdGlvbiBFbGVjdHJvbmljcyAoaXZFU0spPC9zcGFu Pjxicj4NCjxzcGFuIGNsYXNzPSJncm91cHdpc2VyZXBseWhlYWRlciI+T2ZmZW5idXJnIFVuaXZl cnNpdHkgb2YgQXBwbGllZCBTY2llbmNlcywgNzc2NTIgT2ZmZW5idXJnLCBHZXJtYW55PC9zcGFu PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18F96D5BLREML509MBXchi_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18F96D5BLREML509MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Wed, 05 Oct 2016 12:19:29 GMT"; modification-date="Wed, 05 Oct 2016 12:19:29 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18F96D5BLREML509MBXchi_-- From nobody Wed Oct 5 05:33:58 2016 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 ED4BB1296C3 for ; Wed, 5 Oct 2016 05:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2AWSQGBzX7Bj for ; Wed, 5 Oct 2016 05:33:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF6E1296AD for ; Wed, 5 Oct 2016 05:33:51 -0700 (PDT) Received: from [192.168.91.133] ([195.149.223.37]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M1FAK-1b2yBn2vf6-00t8hp; Wed, 05 Oct 2016 14:33:39 +0200 To: Andreas Walz , olivier.levillain@ssi.gouv.fr References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> <1470648042.3026.44.camel@redhat.com> <1474278590.144982.255.camel@infradead.org> <57F291BC.9010604@ssi.gouv.fr> <57F50825020000AC0011D029@gwia2.rz.hs-offenburg.de> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Wed, 5 Oct 2016 14:33:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <57F50825020000AC0011D029@gwia2.rz.hs-offenburg.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qTHaijN7MrfAeRHuKdOIjkN8Opmhct94J" X-Provags-ID: V03:K0:l8X/MMhHP3kOhKuqyfDdCZk2P+wnGGWROwPWrmAk0aTtzFMDUj0 5d0Fcd7aE3OqqxVl6gSdk2UyTRRqDe4BQZaAgC78JNJd8jlxJMwV5KlVSCOVOy2r5fFJ+z6 f/8iya6p2/vUQFJDIZiY6kjEkA57SxA3TikIOhfdjiPu2D5PUcYJnNEw3rYzETO4LPRGRsb bXTGtRdsnvLdazw8OsR6A== X-UI-Out-Filterresults: notjunk:1;V01:K0:6igHGr43n80=:UkgCsM1zdOlL6uC0CRweVi sLKf86Aa3Jx9wtoTjFI8zt9BxPtTKZukXd8YFYjhRJIRhx9pNdtC60oJpgelFEFfx1gIQVD7A VPquKC5OMlyJcQhcciU0+tWiFvpfppVLUT9+g6F4gEeHSoeL2oyvlImNqDpEH5FFiUP5PeI+4 6C4D1aycDAf9oQCxafxFOPGU/obRBjzH21IF426XKuAnXYRabiYCXRBlQ0LbYbeS1XTLys4oa Lb7/sVX3U6372M8nMut1aUQc7YfGoZ4/Mk4KIlnxABJ1ewczH2tijzm5/OI+2wgL5+mFE5WuE ghH9J4EDNjpMNfzV5iKfPnfViO/Q1RDqWWXZ7NoQkGGZr/xnTzq1/Bx7vrnwK0XAt2EofBPeF 116L0c3cCFqELCSbkPdbe1ne3JpKlIqw78LFlWTekRJLt9yULvWIw8xXW5L+DlL3rqDNO6wu4 CAW+DOYuYgg5EQjQqsMb/J8zK92pmIqm4NZkgVc52MAhUfcM9f30ZeNsqfTh/wgAqvbfXveuX Qy5tRNOPwFTi7+MO2evdiFlOxseThlSLbGeFhvlcnEa0ZQGV2Ts3SpqjIu5XokdRbCtmrSUZq MCu6BEFmnPIEsJrTRvGpDu1N1TFUf4NAXdPb+OebI342fsgJlj0SFz6PBP8CyL+nYiUB6da4X yy68Gb6djFwefYZFYjy3ZGrbUSC03LObJvB4hwkDslycpYNzbVAgxBo9Or7FSLCUhHuk6kgf/ KWPtQm72K9M9OFZhqqVGwzLm1M4ufQp11SNLVyYw77UlLwIQY46rAIAltmE= Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS1.3 + PSK with multiple identities 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: Wed, 05 Oct 2016 12:33:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qTHaijN7MrfAeRHuKdOIjkN8Opmhct94J Content-Type: multipart/mixed; boundary="sFNsHgipLVWbG4ESq9rap94cLCh8HHeLN"; protected-headers="v1" From: Hannes Tschofenig To: Andreas Walz , olivier.levillain@ssi.gouv.fr Cc: tls@ietf.org Message-ID: Subject: Re: [TLS] TLS1.3 + PSK with multiple identities References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> <1470648042.3026.44.camel@redhat.com> <1474278590.144982.255.camel@infradead.org> <57F291BC.9010604@ssi.gouv.fr> <57F50825020000AC0011D029@gwia2.rz.hs-offenburg.de> In-Reply-To: <57F50825020000AC0011D029@gwia2.rz.hs-offenburg.de> --sFNsHgipLVWbG4ESq9rap94cLCh8HHeLN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Andreas, I am not sure that people ignore the redundant length fields on purpose. I think that the strange syntax that TLS uses invites these types of mistakes and I had run into those myself as well. Ciao Hannes On 10/05/2016 02:03 PM, Andreas Walz wrote: > Hi Olivier, >=20 > your findings are interesting as they pretty much match with what we > have found when studying TLS implementations for embedded systems. In > many implementations there is a tendency to ignore redundant length > fields (or at least to not enforce consistency). There has been some > discussion about this on the list, see thread "Suspicious behaviour of > TLS server implementations". >=20 > We are currently refining our study and in the process of writing a > paper. I hopefully can give more details on results soon. >=20 > Cheers, > Andi >=20 > ___________________________________ >=20 > Andreas Walz > Research Engineer > Institute of reliable Embedded Systems and Communication Electronics (i= vESK) > Offenburg University of Applied Sciences, 77652 Offenburg, Germany >=20 >=20 >>>> Olivier Levillain 10/04/16 5:51 AM >= >> > Hi list, >=20 > I have been working in the labs at ANSSI (the French Network and > Information System Agency) for several years and I just defended my PhD= > thesis on the TLS ecosystem (documents are available at > http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/). >=20 >>> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote: >>>> On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote: >>>>> More compact and makes the option where server sends some bad optio= n >>>>> more clear. >>> Note that if we really want to be more compact, we might also observe= >>> that there is a redundant length field in the extension as sent by th= e >>> client: >>> case client_hello: >>> PskIdentity identities<6..2^16-1>; >>> >>> Each extension has at least four bytes on the wire =97 the extension_= type >>> itself, and the length field of the extension_data in a uint16. >>> >>> If I am interpreting the spec correctly, then the data for the >>> PreSharedKeyIdentity extension in the ClientHello then follows that >>> with another uint16, which is *always* a value two lower than the one= >>> which immediately precedes it. >>> >>> e.g. >>> >>> 0x00 0x29 // ExtensionType extension_type =3D=3D 41 >>> 0x00 0x14 // opaque extension_data<0..2^16-1> >>> // This length field is entirely redundant: >>> 0x00 0x12 // PskIdentity identities<6..2^16-1> >>> // First identity: >>> 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode >>> 0x00 0x04 // opaque identity<0..2^16-1> >>> 0x44 0x61 0x76 0x65 // "Dave" >>> // Second identity: >>> 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode >>> 0x00 0x06 // opaque identity<0..2^16-1)> >>> 0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chlo=EB" >>> >>> Do we care that the '0x00 0x12' bytes on my third line above are >>> entirely redundant on the wire? Or have I interpreted it wrong? >>> >> Not enough to fix it, this is just the way TLS rolls. >=20 > Sorry if I am a little late to the party, but I noticed that even if > this is generally true, I believe it has not always been enforced in TL= S > extensions. >=20 > In 2006, the IETF standardised the session tickets extension, allowing > for session resumption without server-side state (RFC 4507). > However, no TLS stack implements the specification correctly: even > if the specification described the _content_ of the extension as > a variable-length object (that is an opaque object prefixed by its > length), every implementation ignores this second (useless) length > field. The RFC 5077, published in 2008, fixes the gap > between the specification and the implementations. >=20 > RFC 4507 : >=20 > The SessionTicket extension has been assigned > the number 35. The format of the SessionTicket > extension is given at the end of this section. >=20 > struct { > opaque ticket<0..2^16-1>; > } SessionTicket; >=20 > 00 23 Ticket Extension type 35 > 01 02 Length of extension contents > 01 00 Length of ticket > FF FF .. .. Actual ticket >=20 > RFC 5077 >=20 > The SessionTicket extension has been assigned > the number 35. The extension_data field of > SessionTicket extension contains the ticket. >=20 > 00 23 Ticket Extension type 35 > 01 00 Length of extension contents (ticket) > FF FF .. .. Actual ticket >=20 >=20 > Best regards, > olivier >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --sFNsHgipLVWbG4ESq9rap94cLCh8HHeLN-- --qTHaijN7MrfAeRHuKdOIjkN8Opmhct94J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX9PMiAAoJEGhJURNOOiAta0AH/iryeV4aVtgba24f3xvl3/o5 OFnT2qr+8ppw+TdFjPBiH+xKTjcttj0xcDSa/MC8bYk89RQMoQTQimxA61lr4ISy +iNPbzddjgUEIGp0FDtBa0v1wPDNAt/A12Z/LjLVQkCeR07wxQZXG3J3CHu9hRR9 z2BEQ+lyIQePQ/fzH0rrkqAeSuwH55QEYZIMoI5e7m/5WaLp7aPHMza+3APZzESz VjQoCs4O34ricsoa3Jr43FU1c843rfXZKk5SeZZoSJkXOYDdK0Bn7onfKhgha9/k DP6xY83VeyedPlk5csEVPVGZp/J7trOCmqDSQfkL/3dQ8rNeW6zsheoBZRZ+jR4= =rdUF -----END PGP SIGNATURE----- --qTHaijN7MrfAeRHuKdOIjkN8Opmhct94J-- From jayaraghavendran@gmail.com Wed Oct 5 05:30:14 2016 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 271061296DE for ; Wed, 5 Oct 2016 05:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nNKXQF7h5iIR for ; Wed, 5 Oct 2016 05:30:08 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C881296CF for ; Wed, 5 Oct 2016 05:23:45 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id z126so219514008vkd.0 for ; Wed, 05 Oct 2016 05:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y15GUgq3o6fOAk9TFASR8X8MBgoNvZBxdn2BtCKF+3M=; b=bTGaFVqEhMdPrAUrBY7XLWG4W/x/PH9gt1VYcyDDNSERkeGd/us/DutAJgpWaxc9jQ lQ7dhmmSBO9NFVBSfT05hOkbHjtYZfaUgvS0BY2CJuryQtm/VWwpmWmybuFkly00Dkg9 lyDwMjU88KJqjkCDZxA1iW2qhYUGaYEmLBfQ2eKfGpcWqsZIYc49oO9SANSYatQhsvZO 7k/g6wc05nmbQMs7Y6V7FnSw8t68huW2FxMhXBgQmh23Zs1KtX+vmLnUbj96cTLu1C/1 hXoDHKSURPacnaSnf1tpSeKLOFzSF3X/t1AFgM7DlR71RwvhVQ35v4kElh13CwIktxPh QPLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y15GUgq3o6fOAk9TFASR8X8MBgoNvZBxdn2BtCKF+3M=; b=G9R5hdE6SVK4LBXSKqQu9k1UEz/mZj0pIdeaNYdBjMFZPCrn5iiq03Xmz6m4orlJ1Y 8bFYvh773+WrxIeyoBOvZ5hySf9A9a6hIoTYzMLbOKoJDeKpgd+88lkxA5dhDwLq2wZ2 NDcZ56BBJdfgcD9PWKlGZpIs0yOoFlLjHhzRHJdFenHNpbX12Ahwc7CkddzV8nfQznzm O8wOTv8okgBdftxLPeVYepNm1wjA8EOz67msb8ypulmMeN5DiOXrf0aT9mMdaa5z0j+D Xzr6PpwAncJi+cczfo0VdBRuJKKB8rTNpbPwx9SBrrz+UOX7qQgUE8TU4+3dKZg3Bomk BZlQ== X-Gm-Message-State: AA6/9RlSgFuMQ16p3creyWCf758zRoGQ3awk4Rbo5Gjaeg/f1X3NHg8TDZXNaAwkuiZAoCA3wIUYuUCTQnSZsQ== X-Received: by 10.31.156.131 with SMTP id f125mr5186299vke.50.1475670224218; Wed, 05 Oct 2016 05:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.183 with HTTP; Wed, 5 Oct 2016 05:23:43 -0700 (PDT) In-Reply-To: References: <57F50AEF020000AC0011D039@gwia2.rz.hs-offenburg.de> From: Jayaraghavendran k Date: Wed, 5 Oct 2016 17:53:43 +0530 Message-ID: To: Raja ashok Content-Type: multipart/related; boundary=001a1140fd9a8549ea053e1d3fd9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Prospects of draft-jay-tls-psk-identity-extension 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: Wed, 05 Oct 2016 12:38:34 -0000 --001a1140fd9a8549ea053e1d3fd9 Content-Type: multipart/alternative; boundary=001a1140fd9a8549e6053e1d3fd8 --001a1140fd9a8549e6053e1d3fd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andi, Thanks for your interest in the draft. Yes. We will be definitely reviving the draft. Just held up with some work. We should be able to upload the modified draft in a week or two. Regards, Jay On Wednesday 5 October 2016, Raja ashok wrote: > Hi Andreas, > > > > Last week received some comments from Ilari and David. We are working on > the next version of this draft. We will upload it soon. > > > > Regards, > > Ashok > ------------------------------ > > Raja Ashok VK > =E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 = Huawei Technologies Co., Ltd. > [image: Company_logo] > > Phone: > Fax: > Mobile: > Email: > Huawei Technologies Co., Ltd. > Bangalore, India > > http://www.huawei.com > ------------------------------ > > =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB= =E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4= =BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB= =99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84= =E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 > =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB= =E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4= =BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88= =86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96= =E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD > =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99= =E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7= =AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F= =A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE= =E4=BB=B6=EF=BC=81 > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > *From:* Andreas Walz [mailto:andreas.walz@hs-offenburg.de > ] > *Sent:* 05 October 2016 17:45 > *To:* jayaraghavendran.k@huawei.com > ; Raja > ashok > *Subject:* Prospects of draft-jay-tls-psk-identity-extension > > > > Dear authors of draft-jay-tls-psk-identity-extension, > > I was wondering whether there is any plan to revive your draft on the > TLS-PSK-identity-extension. I very much liked the idea and we also have a > use case where it might be very helpful. > > Thanks for your answer. > > With best regards, > Andi Walz > > ___________________________________ > > Andreas Walz > Research Engineer > Institute of reliable Embedded Systems and Communication Electronics > (ivESK) > Offenburg University of Applied Sciences, 77652 Offenburg, Germany > --001a1140fd9a8549e6053e1d3fd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andi,

Thanks for your interest in the draft.

Yes. We will be definitely reviving the draft.=C2=A0
=

Just held up with some work.=C2=A0We shoul= d be able to upload the modified=C2=A0draft in a week or two.

Regard= s,
Jay

On Wednesday 5 October 2016, Raja ashok <= raja.ashok@huawei.com> wrot= e:

Hi Andreas,=

=C2=A0

Last week received some c= omments from Ilari and David. We are working on the next version of this dr= aft. We will upload it soon.

=C2=A0

Regards,

Ashok

Raja Ashok = VK
=E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90= =E5=85=AC=E5=8F=B8 Huawei Technologies Co., Ltd.
3D"Company_logo"

Phone:
Fax:
Mobile:
Email:
Huawei Technologies Co., Ltd.
Bangalore, India

http://www.huawei.com


=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA= =E4=BB=A5=E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5= =8C=85=E6=8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88= =96=E9=83=A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5= =88=B6=E3=80=81=E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB= =B6=E4=B8=AD
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C= =E6=82=A8=E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE= =E4=BB=B6=E9=80=9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9= =99=A4=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=81
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!=

=C2=A0

Dear authors of draft-jay-tls-psk-ide= ntity-extension,

I was wondering whether there is any plan to revive your draft on the TLS-P= SK-identity-extension. I very much liked the idea and we also have a use ca= se where it might be very helpful.

Thanks for your answer.

With best regards,
Andi Walz

___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics = (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany

--001a1140fd9a8549e6053e1d3fd8-- --001a1140fd9a8549ea053e1d3fd9 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 31bb7a66f4e54ec8_0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --001a1140fd9a8549ea053e1d3fd9-- From nobody Wed Oct 5 09:44:58 2016 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 9BF301297A6 for ; Wed, 5 Oct 2016 09:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 mVukMrEnyv4Z for ; Wed, 5 Oct 2016 09:44:54 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C81B129796 for ; Wed, 5 Oct 2016 09:44:54 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id t7so224110050qkh.2 for ; Wed, 05 Oct 2016 09:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kmHaaWHtKC3xZyVcsnTviU/XezvTqEHAyO4+DR2sVtk=; b=L+GhvkzRstNVaIcC9MtqQOayKiNaFnRfIatWfq5/axXlL13hA2EqJ1dQAu+Pspk8LJ aRLziBS9nPMMEX4SxG5VipbZlMOCNMyemWkW2CiadKEPIHEZcldTJIVYvBA3l0qB2IRu 0Po/VEtD4FUgJiuO7IE2s4rRpPY2SvtR5IRG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kmHaaWHtKC3xZyVcsnTviU/XezvTqEHAyO4+DR2sVtk=; b=XWJ95D9lsy47HaeznzO99DGFUWkWV0Ku7NULeR/RS8OwckMHg6+gHQAYnWgrtUMX89 MCWG2dkr36Ki1QDITVZL1wCk+eE/y6+2Z9GsO/pm5dEiLWkC8dbKu4Fvp65mdFndeZHc KSi394N9u1b56PQni2EF+Xu7GleHMOOktrVBIUhcg0nf91BS42Y+feAkffDwCKXupbFT MzX/7zJvhKdMG2p62l3sI92J19HgSZtpgQQuNXJtmnCpzY5cfXyi1DtN+YcLERT9jEOU RqHzeZDnMkdS1EoNUbu27S8n1FVv2VsjIA5bHsLd9pBSj+due4CtPLmJMYL6GbPygft3 kLWw== X-Gm-Message-State: AA6/9RnOIx3FTGoKqGa4KaGfjWFHzEuSzAD1C2VlJiyQgxTzelUTqvvw4ga4opEb8VHbKA== X-Received: by 10.55.11.131 with SMTP id 125mr9911141qkl.112.1475685893272; Wed, 05 Oct 2016 09:44:53 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id 22sm3768747qkj.15.2016.10.05.09.44.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Oct 2016 09:44:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20161003174712.B39F7B80C3B@rfc-editor.org> Date: Wed, 5 Oct 2016 12:44:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161003174712.B39F7B80C3B@rfc-editor.org> To: Stephen Farrell , Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: d3e3e3@gmail.com, vincentleest@gmail.com, "" Subject: Re: [TLS] [Editorial Errata Reported] RFC6066 (4817) 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: Wed, 05 Oct 2016 16:44:55 -0000 Looks like this one can safely be accepted. spt > On Oct 03, 2016, at 13:47, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6066, > "Transport Layer Security (TLS) Extensions: Extension Definitions". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6066&eid=3D4817 >=20 > -------------------------------------- > Type: Editorial > Reported by: ResponderIDs type is not defined anywhere. = >=20 > Section: 8 >=20 > Original Text > ------------- > In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP > responders that the client trusts.=20 >=20 > Corrected Text > -------------- > In the OCSPStatusRequest, the "ResponderID" provides a list of OCSP > responders that the client trusts. >=20 > or clearer=20 >=20 > In OCSPStatusRequest, the "responder_id_list" provides a list of > "ResponderID", OCSP responders that the client trusts. >=20 > Notes > ----- > ResponderIDs is not defined anywhere within the document. >=20 > Quote of this section in RFC6961 section 2.2 (p.4) seem to have fixed = this. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6066 (draft-ietf-tls-rfc4366-bis-12) > -------------------------------------- > Title : Transport Layer Security (TLS) Extensions: = Extension Definitions > Publication Date : January 2011 > Author(s) : D. Eastlake 3rd > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Wed Oct 5 10:35:36 2016 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 58A8E129717 for ; Wed, 5 Oct 2016 10:35:35 -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_H3=-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 UZtfsdTv5klO for ; Wed, 5 Oct 2016 10:35:33 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0119.outbound.protection.outlook.com [104.47.32.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FAB1293DC for ; Wed, 5 Oct 2016 10:35:33 -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=qdkHF1wuUZKDViBuNJp2KigfMDMgBVeLrU1AvOn8rgc=; b=kM3RgUAFneQ2i0Hp0s+5Nh8SNBQiBEkBuchRlG57ia9pUepXXoct1gez1taZ3i/6s5byGtXg1DINIvC2kwzdKnPIvnE4EuOVauoUl6zhzG6z7pIT+TPmcK8iThzqqhOpScGWOBrKANdDyoTUi1L0+PVLlmx9C2vtRgjnq1Il+5U= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 17:35:31 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0649.021; Wed, 5 Oct 2016 17:35:31 +0000 From: Andrei Popov To: Eric Rescorla , Martin Thomson Thread-Topic: [TLS] Exporter output size Thread-Index: AQHSHqhd5Z8e+0GkCUmnlUJ4uTWLHaCZOXwAgADlPrA= Date: Wed, 5 Oct 2016 17:35:31 +0000 Message-ID: References: In-Reply-To: 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=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:a::1d2] x-ms-office365-filtering-correlation-id: 9540558e-3447-4abd-455e-08d3ed460182 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:1sqZJHw4esX3GiO+mmjTWLUOGotHPJL1LfLyQ/xtNUscmz1P7NMYhsJXsTYIMlJBZ8tSWhTYw4nB4lQoFX/A70vJgvqN1p1aDWxukqZmmZIs06WOxEUKswOHuUsURkTxM8QPi/FehRDEHH/H4Ixn80dvmj5Kz/q8Swmlgd0QN3h4nudYXJHc0ll3kRxkrS6yUgeCx6m9ZMD98kGzP1Nw0rdRylIrdatW+owFzkPGL9AlV0dF6tgnURIskl0ZaK3pnwjBTmgkmcDp04g3OcVMyRQuz3RgAEOlifCApvHYMPtXP81QGrbffvt4LmLN7gUpjB3qM6Ks7Z0ui4Pexa5Z+g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(377454003)(199003)(189002)(24454002)(2900100001)(86362001)(7906003)(106356001)(99286002)(106116001)(7736002)(7846002)(86612001)(74316002)(4326007)(790700001)(105586002)(586003)(15975445007)(2906002)(8990500004)(6116002)(3660700001)(19580405001)(102836003)(87936001)(19609705001)(189998001)(19617315012)(122556002)(10290500002)(77096005)(19580395003)(8676002)(92566002)(5005710100001)(54356999)(68736007)(10400500002)(5002640100001)(2950100002)(11100500001)(3280700002)(101416001)(9686002)(5001770100001)(8936002)(97736004)(10090500001)(81156014)(76176999)(33656002)(19300405004)(16236675004)(76576001)(81166006)(19625215002)(50986999)(5660300001)(7696004)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.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_CY1PR0301MB08422FB26D2F18372A4451C68CC40CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 17:35:31.5678 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Exporter output size 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: Wed, 05 Oct 2016 17:35:35 -0000 --_000_CY1PR0301MB08422FB26D2F18372A4451C68CC40CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbywgaXQgd291bGQgYmUgZGlmZmljdWx0IHRvIHJlbW92ZSBleGlzdGluZyBmdW5jdGlvbmFs aXR5LCBhbmQgZ2V0IHRoZSBjYWxsZXJzIHRvIHVwZGF0ZS4gRS5nLiBkZXByZWNhdGlvbiBvZiBU TFNfVU5JUVVFIGlzIG5vdCBnb2luZyBlYXN5IGZvciBhcHBzL3Byb3RvY29scy4NCg0KQ2hlZXJz LA0KDQpBbmRyZWkNCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDQsIDIwMTYg ODo0OSBQTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpD YzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gRXhwb3J0ZXIgb3V0cHV0IHNpemUN Cg0KT24gVHVlLCBPY3QgNCwgMjAxNiBhdCA2OjMyIFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90 ZToNCkFmdGVyIGEgYnVuY2ggb2YgZGlzY3Vzc2lvbiBhYm91dCB0aGUgY29uc2VxdWVuY2VzIG9m IGhhdmluZw0KaW5zdWZmaWNpZW50IG91dHB1dCBmcm9tIHZhcmlvdXMgc3RhZ2VzIG9mIHRoZSBo YXNoIGZ1bmN0aW9ucy4uLiBDb3VsZA0Kd2UgbWFrZSBhbiBhbWVuZG1lbnQgdG8gVExTIDEuMyB0 byBmb3JjZSB0aGUgb3V0cHV0IHNpemUgb2YgdGhlDQpleHBvcnRlciB0byBiZSB0aGUgc2l6ZSBv ZiB0aGUgdW5kZXJseWluZyBoYXNoIG91dHB1dD8gIFRoYXQgaXMsDQpyZW1vdmUgdGhlIGxlbmd0 aCBwYXJhbWV0ZXIuICBPciBpcyBhIGNoYW5nZSB0byB0aGUgQVBJIHRvbw0KZGlzcnVwdGl2ZT8N Cg0KSSBkb24ndCB0aGluayB0aGlzIGlzIGEgZ29vZCBpZGVhLiBUaGVyZSBhcmUgcGxlbnR5IG9m IHJlYXNvbnMgd2h5IHlvdSB3b3VsZCB3YW50IHRvDQpleHBvcnQgdmFsdWVzICE9IGhhc2hfbGVu IChlLmcuLCBjcnlwdG9ncmFwaGljIGtleXMpLiBQdXR0aW5nIGEgcmVzdHJpY3Rpb24gaGVyZSBq dXN0DQpwdXNoZXMgdGhlIHByb2JsZW0gYXJvdW5kDQoNCi1Fa3INCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExT QGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0KDQo= --_000_CY1PR0301MB08422FB26D2F18372A4451C68CC40CY1PR0301MB0842_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFsc28sIGl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0byByZW1v dmUgZXhpc3RpbmcgZnVuY3Rpb25hbGl0eSwgYW5kIGdldCB0aGUgY2FsbGVycyB0byB1cGRhdGUu IEUuZy4gZGVwcmVjYXRpb24gb2YgVExTX1VOSVFVRSBpcyBub3QgZ29pbmcgZWFzeSBmb3IgYXBw cy9wcm90b2NvbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMg W21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBS ZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDQsIDIwMTYgODo0OSBQ TTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWls LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1RMU10gRXhwb3J0ZXIgb3V0cHV0IHNpemU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgT2N0IDQsIDIwMTYgYXQgNjozMiBQ TSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B ZnRlciBhIGJ1bmNoIG9mIGRpc2N1c3Npb24gYWJvdXQgdGhlIGNvbnNlcXVlbmNlcyBvZiBoYXZp bmc8YnI+DQppbnN1ZmZpY2llbnQgb3V0cHV0IGZyb20gdmFyaW91cyBzdGFnZXMgb2YgdGhlIGhh c2ggZnVuY3Rpb25zLi4uIENvdWxkPGJyPg0Kd2UgbWFrZSBhbiBhbWVuZG1lbnQgdG8gVExTIDEu MyB0byBmb3JjZSB0aGUgb3V0cHV0IHNpemUgb2YgdGhlPGJyPg0KZXhwb3J0ZXIgdG8gYmUgdGhl IHNpemUgb2YgdGhlIHVuZGVybHlpbmcgaGFzaCBvdXRwdXQ/Jm5ic3A7IFRoYXQgaXMsPGJyPg0K cmVtb3ZlIHRoZSBsZW5ndGggcGFyYW1ldGVyLiZuYnNwOyBPciBpcyBhIGNoYW5nZSB0byB0aGUg QVBJIHRvbzxicj4NCmRpc3J1cHRpdmU/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBnb29k IGlkZWEuIFRoZXJlIGFyZSBwbGVudHkgb2YgcmVhc29ucyB3aHkgeW91IHdvdWxkIHdhbnQgdG88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmV4cG9y dCB2YWx1ZXMgIT0gaGFzaF9sZW4gKGUuZy4sIGNyeXB0b2dyYXBoaWMga2V5cykuIFB1dHRpbmcg YSByZXN0cmljdGlvbiBoZXJlIGp1c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnB1c2hlcyB0aGUgcHJvYmxlbSBhcm91bmQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRMUyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90bHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB08422FB26D2F18372A4451C68CC40CY1PR0301MB0842_-- From nobody Wed Oct 5 11:16:35 2016 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 62D7B1293FC for ; Wed, 5 Oct 2016 11:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 1xPVmJIr_QZr for ; Wed, 5 Oct 2016 11:16:31 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20881293F8 for ; Wed, 5 Oct 2016 11:16:31 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1brqjz-0003jZ-D5; Wed, 05 Oct 2016 20:16:27 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.84_2) (envelope-from ) id 1brqjz-0004rv-9H; Wed, 05 Oct 2016 20:16:27 +0200 From: Florian Weimer To: Hubert Kario References: <1474627597.2773.14.camel@redhat.com> <1948820.OppVitlkjc@pintsize.usersys.redhat.com> Date: Wed, 05 Oct 2016 20:16:27 +0200 In-Reply-To: <1948820.OppVitlkjc@pintsize.usersys.redhat.com> (Hubert Kario's message of "Fri, 23 Sep 2016 15:41:14 +0200") Message-ID: <87h98q64qs.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] debugging tools [was: Industry Concerns about TLS 1.3] 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: Wed, 05 Oct 2016 18:16:33 -0000 * Hubert Kario: > those secret keys are on the client machines and they will stay on client > machines > > making it hard to extract master key from process memory is just security > through obscurity, not something that will stop a determined attacker I think extracting the master key is probably not what you want to do anyway, just adding Systemtap probes to get cleartext copies (preferably along with connection detail information) should be sufficient. From nobody Wed Oct 5 11:17:31 2016 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 6E1D01293F8 for ; Wed, 5 Oct 2016 11:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 CjOhFVruIXTD for ; Wed, 5 Oct 2016 11:17:29 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C041293E4 for ; Wed, 5 Oct 2016 11:17:29 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1brqkx-0003k9-JW; Wed, 05 Oct 2016 20:17:27 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.84_2) (envelope-from ) id 1brqkx-0004tQ-G6; Wed, 05 Oct 2016 20:17:27 +0200 From: Florian Weimer To: BITS Security References: Date: Wed, 05 Oct 2016 20:17:27 +0200 In-Reply-To: (BITS Security's message of "Thu, 22 Sep 2016 17:19:48 +0000") Message-ID: <87fuoa64p4.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Wed, 05 Oct 2016 18:17:30 -0000 * BITS Security: > Deprecation of the RSA key exchange in TLS 1.3 will cause significant > problems for financial institutions, almost all of whom are running > TLS internally and have significant, security-critical investments in > out-of-band TLS decryption. > > Like many enterprises, financial institutions depend upon the ability > to decrypt TLS traffic to implement data loss protection, intrusion > detection and prevention, malware detection, packet capture and > analysis, and DDoS mitigation. We should have already seen this with changing defaults in crypto libraries as part of security updates. That should have broken passive monitoring infrastructure, too. Maybe some of the vendors can shed some light on this problem and tell us if they ever have received pushback for rolling out ECDHE-by-default. (I know that some products have few capabilities for centralized policy management, which is why defaults matter a lot there.) From nobody Wed Oct 5 12:06:36 2016 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 0C63812982D for ; Wed, 5 Oct 2016 12:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 C_zJUPYshpda for ; Wed, 5 Oct 2016 12:06:33 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B475A129839 for ; Wed, 5 Oct 2016 12:06:29 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id j129so219515653qkd.1 for ; Wed, 05 Oct 2016 12:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=HapvXWE7t1LmMzkK+Alhmw1HJQLv+QCblyEMUIt0uwQ=; b=aYyV1GlqzhmZj6/o5T9qwGkj24nRsxY49E5WUznq0MtRT4/vxfmQCrm06/5wHvqy7z 7cuaBWWjbamnPeMVHuBmkqOIDQAx5E3G7YMm9eg6ILF1dI/uz2XgYuBUa8jry3OIq2rJ UkxJV4tqSzFvxSwU/aFStYUvUUG/vZzQvrcw0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=HapvXWE7t1LmMzkK+Alhmw1HJQLv+QCblyEMUIt0uwQ=; b=RlwlLi1QALhS3yax5CaTC6GN6DjfMFA39UPKnaWR8YyQi/1uPcv4eRo5JmUSVmxG0A pC01cn6ghaO7XQFPoIvE7E76Mxd8B0nxYjfg+QYjGSZ+pDFfKpOGFg2MU/IJCV9IrGvS I7DzZDtNTxRH+T0Io4qKdQGiZkPjKHAaxFKGfvk8iGkgO+1iJ4/4fsl/yMJPctgptcZY uuIORmgA23XD6AkVPGZBIjNCAsdR4iM1gs0fwekIVJ4dUnBEMIMmI8Ve3FajIi6lw7pH jPJ4rpWQ9Kq94+7aoDOPX2LeFoIPyjlqByeZxSvIdiw7SqiF96iNSTT8SbFKA48mWB3P 8LtQ== X-Gm-Message-State: AA6/9RlkVq8hTSEyEzjcr+AbeRGibR6tNv5e86PyfMyjuXygShxqbctpjuYRtrnmAHrFxw== X-Received: by 10.55.212.85 with SMTP id l82mr4263115qki.214.1475694388598; Wed, 05 Oct 2016 12:06:28 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id h22sm1984714qtb.32.2016.10.05.12.06.27 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Oct 2016 12:06:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 5 Oct 2016 15:06:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "tls@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Proposed Change to Certificate message (#654) 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: Wed, 05 Oct 2016 19:06:35 -0000 I=E2=80=99m not seeing objections to this PR so please let us know by = Friday (7 October) whether you see any issues with what=E2=80=99s been = proposed.=20 spt > On Sep 22, 2016, at 20:42, Nick Sullivan = wrote: >=20 > PR: https://github.com/tlswg/tls13-spec/pull/654 >=20 > Hello, >=20 > I'd like to propose a small to the Certificate message format to allow = for future extensibility of the protocol. >=20 > This change adds a set of extensions to the Certificate message. With = this change, the Certificate message can now hold all extension messages = that are certificate-specific (rather than connection-specific). This = change also resolves the anomaly of OCSP messages appearing before = certificates in the handshake. >=20 > Reasoning:=20 > I've come to the conclusion that the current mechanism in TLS 1.3 for = OCSP and SCT is lacking forsight. OCSP and SCT are per-certificate = metadata, not per-connection metadata. By putting these responses in the = EncryptedExtensions, you limit these extensions to being shown once per = connection. This restricts future protocol extensions from using = multiple Certificate messages to support multiple certificates on the = same connection. An example of this is the post-handshake authentication = proposal = (https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00), = which currently requires a modified post-handshake Certificate message. = This proposed change would simplify the post-handshake auth proposal = significantly and generally make more sense as more certificate-specific = extensions are created. >=20 > Nick > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Oct 5 12:37:53 2016 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 0033212986D for ; Wed, 5 Oct 2016 12:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fsroundtable.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 Dl7LuQ7eFrCB for ; Wed, 5 Oct 2016 12:37:48 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0059.outbound.protection.outlook.com [104.47.36.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739D0129434 for ; Wed, 5 Oct 2016 12:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsroundtable.onmicrosoft.com; s=selector1-fsroundtable-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iEdE8X0RWrJlI9Ce3bwROKMGrBwJpPZU6MLJdKSALtg=; b=aFqvoGeq7NkEhp3bgFQwHEhS8N3KunaZD+/bXvccLE6QOYTEF+CuuyZEEc/delkLy3uy01k6Wf2v4MstEvV9AMefGm7MRMW64YAFMWPetnKNYGPXRRk1jHLvJ392T+y0BdhIUc1XnbCQWJ2Q4SP2pwZB4vqtAXdkYkIcafcAbLk= Received: from DM5PR11MB1419.namprd11.prod.outlook.com (10.168.104.21) by DM5PR11MB1420.namprd11.prod.outlook.com (10.168.104.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 19:37:46 +0000 Received: from DM5PR11MB1419.namprd11.prod.outlook.com ([10.168.104.21]) by DM5PR11MB1419.namprd11.prod.outlook.com ([10.168.104.21]) with mapi id 15.01.0649.022; Wed, 5 Oct 2016 19:37:46 +0000 From: BITS Security To: Florian Weimer Thread-Topic: [TLS] Industry Concerns about TLS 1.3 Thread-Index: AdIU8WqWM9WBapZoQzyfqxiOaK25faCaPahg Date: Wed, 5 Oct 2016 19:37:46 +0000 Message-ID: References: <87fuoa64p4.fsf@mid.deneb.enyo.de> In-Reply-To: <87fuoa64p4.fsf@mid.deneb.enyo.de> 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=BITSSecurity@fsroundtable.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [165.117.248.226] x-ms-office365-filtering-correlation-id: 2bf0a1f3-496c-4ff0-5d60-08d3ed571550 x-microsoft-exchange-diagnostics: 1; DM5PR11MB1420; 7:CTtdcLitEMy/V9OX3WafLeWmrrBm6ryFIonSAIdIGPr8ySLQQKe6iNXv/Eh2UjW5vVDxzSyLAjek5GnhbIeCIXLHPE7t/PVKZCaXzhVWzcnfO93Fijzvk5AEBDlEQT5kYJT5zlE1onaxKtgtS9q1cOH1jFKMvWOmpPdqLyWyIK/ZTHZH3jBkthf2r6OtWltkke2nwacpf9Vn/rrDz4u+5lREWYLu6h8zqjd7GkmhXxpjh0g6Kn94pamRIVoxl863LJYkGEi89hFsfKaSSFnM4iQbQpH63k4h504G58HlAU1sMNQIWm5ERKDc3eJzSRxRYVITKLG/5vGmVbAiiMf/+w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR11MB1420; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6042046)(6043046); SRVR:DM5PR11MB1420; BCL:0; PCL:0; RULEID:; SRVR:DM5PR11MB1420; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(377454003)(189002)(199003)(76176999)(2906002)(66066001)(10400500002)(8676002)(54356999)(11100500001)(105586002)(6116002)(92566002)(106356001)(586003)(102836003)(81166006)(556974002)(81156014)(5660300001)(2900100001)(8936002)(3846002)(68736007)(50986999)(99286002)(33656002)(110136003)(19580405001)(86362001)(5002640100001)(97736004)(74316002)(7736002)(7696004)(76576001)(87936001)(80792005)(122556002)(3660700001)(6916009)(4326007)(19580395003)(7846002)(9686002)(77096005)(305945005)(3280700002)(2950100002)(189998001)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1420; H:DM5PR11MB1419.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fsroundtable.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fsroundtable.org X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 19:37:46.3526 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 841de5a0-73e8-4cbc-8142-f80b225ef22d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1420 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Wed, 05 Oct 2016 19:37:51 -0000 Florian--Anecdotally, I have heard Microsoft and F5 did code upgrades a few= years back that moved Diffie Hellman to the top cipher suite priorities wh= ich broke security and fraud monitoring, APM reporting, and sniffer trouble= shooting for a financial services client and at least one other organizatio= n in a different industry. =20 The solution, at the time, was to put the PFS options (choices we will no l= onger in 1.3) at the bottom of the priority list. I don't know how much of= this was communicated back to the vendors at the time. =20 In retrospect, this could have been seen as the canary in the coalmine... b= ut here we are now at least. =20 - Andrew=20 -----Original Message----- From: Florian Weimer [mailto:fw@deneb.enyo.de]=20 Sent: Wednesday, October 5, 2016 2:17 PM To: BITS Security Cc: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 * BITS Security: > Deprecation of the RSA key exchange in TLS 1.3 will cause significant=20 > problems for financial institutions, almost all of whom are running=20 > TLS internally and have significant, security-critical investments in=20 > out-of-band TLS decryption. > =20 > Like many enterprises, financial institutions depend upon the ability=20 > to decrypt TLS traffic to implement data loss protection, intrusion=20 > detection and prevention, malware detection, packet capture and=20 > analysis, and DDoS mitigation. We should have already seen this with changing defaults in crypto libraries= as part of security updates. That should have broken passive monitoring i= nfrastructure, too. Maybe some of the vendors can shed some light on this problem and tell us i= f they ever have received pushback for rolling out ECDHE-by-default. (I kn= ow that some products have few capabilities for centralized policy manageme= nt, which is why defaults matter a lot there.) From nobody Wed Oct 5 12:40:40 2016 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 5D39712985A for ; Wed, 5 Oct 2016 12:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 IMdHr1cIqkV3 for ; Wed, 5 Oct 2016 12:40:37 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2E6129811 for ; Wed, 5 Oct 2016 12:40:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5BEA013256; Wed, 5 Oct 2016 22:40:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id qg1K2O2NgUOG; Wed, 5 Oct 2016 22:40:34 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C5231C4; Wed, 5 Oct 2016 22:40:34 +0300 (EEST) Date: Wed, 5 Oct 2016 22:40:28 +0300 From: Ilari Liusvaara To: Sean Turner Message-ID: <20161005194028.GA26154@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed Change to Certificate message (#654) 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: Wed, 05 Oct 2016 19:40:39 -0000 On Wed, Oct 05, 2016 at 03:06:25PM -0400, Sean Turner wrote: > I’m not seeing objections to this PR so please let us know by Friday > (7 October) whether you see any issues with what’s been proposed. > > > On Sep 22, 2016, at 20:42, Nick Sullivan wrote: > > > > PR: https://github.com/tlswg/tls13-spec/pull/654 The only issue that comes to mind is where extensions that are specific to the certificate chain instead to the certificate go. E.g. if a new kind of certificate chain[1] is ever implemented using client_certificate_type/server_certificate_type (or anything similar for that matter). [1] E.g. for allowing multisigning EE certificates (currently one can multisign CA certificates, but not EE ones). -Ilari From nobody Wed Oct 5 13:33:24 2016 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 70F8F129474; Wed, 5 Oct 2016 13:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 kK99KckD2CXj; Wed, 5 Oct 2016 13:33:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CC2129466; Wed, 5 Oct 2016 13:33:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4A28DB81197; Wed, 5 Oct 2016 13:33:21 -0700 (PDT) To: vincentleest@gmail.com, d3e3e3@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161005203321.4A28DB81197@rfc-editor.org> Date: Wed, 5 Oct 2016 13:33:21 -0700 (PDT) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Verified] RFC6066 (4817) 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: Wed, 05 Oct 2016 20:33:22 -0000 The following errata report has been verified for RFC6066, "Transport Layer Security (TLS) Extensions: Extension Definitions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6066&eid=4817 -------------------------------------- Status: Verified Type: Editorial Reported by: ResponderIDs type is not defined anywhere. Date Reported: 2016-10-03 Verified by: Stephen Farrell (IESG) Section: 8 Original Text ------------- In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP responders that the client trusts. Corrected Text -------------- In the OCSPStatusRequest, the "ResponderID" provides a list of OCSP responders that the client trusts. or clearer In OCSPStatusRequest, the "responder_id_list" provides a list of "ResponderID", OCSP responders that the client trusts. Notes ----- ResponderIDs is not defined anywhere within the document. Quote of this section in RFC6961 section 2.2 (p.4) seem to have fixed this. -------------------------------------- RFC6066 (draft-ietf-tls-rfc4366-bis-12) -------------------------------------- Title : Transport Layer Security (TLS) Extensions: Extension Definitions Publication Date : January 2011 Author(s) : D. Eastlake 3rd Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Oct 5 19:59:37 2016 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 8149012945D for ; Wed, 5 Oct 2016 19:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fr81IWjT6BBs for ; Wed, 5 Oct 2016 19:59:35 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483B11293F5 for ; Wed, 5 Oct 2016 19:59:35 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id n189so5692067qke.0 for ; Wed, 05 Oct 2016 19:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sdzh1okFGvRqLrFpZ73mTFv+5PnEk4oliCQnaEMBq6w=; b=f8SF3lBTHodRIi4lbf5d+MW+jZ7WJGEw/mgEA0hQ7c+5W+oGkERfr9QY5ffkZzckd/ uS4uIhyBGMqIXkGZFvqbbP3viEVpi/OdvR9toC8bJDBFGS+fQDq52xliyOp5JizZ/GCZ COgCx6yteueJq0JKphafKG28l62zLpugjwHUGOsz0TmC3Y2hM46Ewbtt7RlItzLyTw6Q JyD7Uun8XA4WgpEY4fg0wC+V/SYSIE2IM6voH6TquZmwBXWoR3Mu0DTOVF26EisdHt7/ w/xUA/Mw+fIeDbzrzm3sc/v79Hhr7HHLdxr8T3d4u2soetJ8Ti15jqikRflwGqpFuZ7r 2o1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sdzh1okFGvRqLrFpZ73mTFv+5PnEk4oliCQnaEMBq6w=; b=TB1/Z6PKSeFj3nmRuS2EHHxSCN9NesKnCqLMZgc2jOGXIysy0n/DAD4fgX2Io7ckvL zNp02sPdpqbJ0KQzVBT5Si5h5U6bRGZgE4svBVquNeC02TZ4t3jbrTYXuWHzGjZaZg20 wpzMhSWSLkfw5dO1+NpWtFyqfPuvPu31pFRJh7v4rM7ZsDUPky9kVj4IGcF/P3wVejse gml0JKGQeGYUd0x+j9YGWaA/TueC/rX4XcpwxsIWy0zDVxLwZT7PqYaCEMHW10b+5K+J yL3I6MsakFmJoJjHEW+tzeS6TzHzD11INvm7oaj5XY/NTqVG9xgovMRx/DlbyFuJneEm d3Dw== X-Gm-Message-State: AA6/9Rlzwzk41xcAKjGT1Lyt/OAHOLc832ij6hgEIpEVtzOtzuSHC48dShtibedc5tlWb5I2eRnZ2UNcgA4nQw== X-Received: by 10.55.102.78 with SMTP id a75mr12436476qkc.193.1475722774422; Wed, 05 Oct 2016 19:59:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Wed, 5 Oct 2016 19:59:33 -0700 (PDT) In-Reply-To: <20161005194028.GA26154@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161005194028.GA26154@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Thu, 6 Oct 2016 13:59:33 +1100 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed Change to Certificate message (#654) 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, 06 Oct 2016 02:59:36 -0000 On 6 October 2016 at 06:40, Ilari Liusvaara wrote: > The only issue that comes to mind is where extensions that are specific > to the certificate chain instead to the certificate go. Let's keep it simple. I would put these on the EE cert. That is the entry that has the most chance of being looked at. From nobody Wed Oct 5 23:42:31 2016 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 0863C12946E for ; Wed, 5 Oct 2016 23:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 QxQL3_fzjhEA for ; Wed, 5 Oct 2016 23:42:28 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BFD63129454 for ; Wed, 5 Oct 2016 23:42:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 03EF2132D8; Thu, 6 Oct 2016 09:42:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id uyBR85W4oWFs; Thu, 6 Oct 2016 09:42:25 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id ABEA12310; Thu, 6 Oct 2016 09:42:25 +0300 (EEST) Date: Thu, 6 Oct 2016 09:42:20 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20161006064220.GA30076@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161005194028.GA26154@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed Change to Certificate message (#654) 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, 06 Oct 2016 06:42:30 -0000 On Thu, Oct 06, 2016 at 01:59:33PM +1100, Martin Thomson wrote: > On 6 October 2016 at 06:40, Ilari Liusvaara wrote: > > The only issue that comes to mind is where extensions that are specific > > to the certificate chain instead to the certificate go. > > Let's keep it simple. I would put these on the EE cert. That is the > entry that has the most chance of being looked at. Yeah, if there is no separate slot, then EE cert slot is the most logical. Perhaps also put server_certificate_type/client_certificate_type there? That would eliminate the anomaly that one must know the server certificate type before sending the certiifcate. However, with client_certificate_type, one has to be careful, since server support also matters. So presumably one would have server send a list of supported formats. -Ilari From nobody Thu Oct 6 02:25:53 2016 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 C5452129927 for ; Thu, 6 Oct 2016 02:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QODuL4wXHupV for ; Thu, 6 Oct 2016 02:25:50 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEBF129933 for ; Thu, 6 Oct 2016 02:25:40 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id f6so5437842qtd.2 for ; Thu, 06 Oct 2016 02:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V2G5s2SwQ9QItGVMgkCw3NwNx3VSbsGuSK32Odrfr7A=; b=jGPnfXfj+B6za5D/ERqtbV7klt4ajhRKlKDHxLApHLDZxis3rt6aTP7zPHfp4rAc7G Cy24k5FPX5W0fUYDDmX8G/rvbt8XJw0HDtXL5aspFAfjelh6Ifz/Ai9HelPad1A75NGo q20SxLUfmeSruHRg5aQZx1kDB7kYDPIa4yNgeK1sX5haGek0nqaI6Uk4A9L+6PbLyHfl mcbQszgXJOKtHcEIK+BUaihGBVJdeJ/rL10ZMqP+aAh8eG+ypOY7crC2QCRJmFIKaHKh w7a8NuUQGwt+MXA1IM2AYHoALjNqGDHdIjglb2p4oKCkLPFa8DhUPs9NdEAhc4gEOj/u GwOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V2G5s2SwQ9QItGVMgkCw3NwNx3VSbsGuSK32Odrfr7A=; b=EYQUmon4LmuNDQGy2E/Sg9V3s71vv+vkVZvlwIrquOnvYz0RbhyZrIPU75vjMhbJAZ kx7SWyIhOeSJzUq6gVK7yqU5iOJZLdNJOZBqrGI7nRzDbCc/C4aalPkFATR1f//dsT0E Da8DyWiVs/ckcqxqRR4rHT2ki4MvODpSIG84KAMHhtrIW4YcWxsHCl/s1k5eZWWG0olr sO7galgJT/oDP7XaUNqSrOknHyRwvQvnZFLuZ/0J6tdNCD8087im2KjdDg78ye7rit2G Orf9ZTONRJB9W8QGYo/8Q34ghYzshWZ8/1XNSQaZOEIbrnZr5YXRfqc3rD+/E9YnV5QH /5aQ== X-Gm-Message-State: AA6/9RlX1OeEB1f82Rk6738fNpKE0i9EmmdCn7BVvgSdchcAUBeIiWqUvP6DGGWiswVmYMJNJEndLYEIUnzA9Q== X-Received: by 10.200.53.54 with SMTP id y51mr13737521qtb.132.1475745938287; Thu, 06 Oct 2016 02:25:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Thu, 6 Oct 2016 02:25:37 -0700 (PDT) In-Reply-To: <20161006064220.GA30076@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161005194028.GA26154@LK-Perkele-V2.elisa-laajakaista.fi> <20161006064220.GA30076@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Thu, 6 Oct 2016 20:25:37 +1100 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed Change to Certificate message (#654) 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, 06 Oct 2016 09:25:52 -0000 On 6 October 2016 at 17:42, Ilari Liusvaara wrote: > Perhaps also put server_certificate_type/client_certificate_type > there? That would eliminate the anomaly that one must know the > server certificate type before sending the certiifcate. Sounds like a perfect use for the CertificateRequest extension field, for the client certificate anyway. From nobody Thu Oct 6 12:58:01 2016 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE04129773 for ; Thu, 6 Oct 2016 12:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147578387937.23942.11530316341990997802.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 12:57:59 -0700 From: IETF Secretariat Archived-At: Subject: [TLS] Milestones changed for tls WG X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 06 Oct 2016 19:57:59 -0000 Changed milestone "CBC Fixes to IESG", resolved as "Done - See RFC 7525 & MTI AEAD algs in TLS1.3". Changed milestone "RC4 replacement to IESG", resolved as "Done - See RFC 7465 & RFC 7905", added draft-ietf-tls-prohibiting-rc4, draft-ietf-tls-chacha20-poly1305 to milestone. Changed milestone "(D)TLS 1.3 to IESG", set due date to February 2017 from November 2014, added draft-ietf-tls-tls13 to milestone. URL: https://datatracker.ietf.org/wg/tls/charter/ From nobody Thu Oct 6 13:00:12 2016 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 C732F129436 for ; Thu, 6 Oct 2016 13:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 MzFi2D0q_Cnz for ; Thu, 6 Oct 2016 13:00:09 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C552129430 for ; Thu, 6 Oct 2016 13:00:09 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id n189so25836348qke.0 for ; Thu, 06 Oct 2016 13:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=4nkPSScvvpzLThprElXhkUVotKEpd8W8jKJgSDHg38U=; b=DJNY2VrIyEcT2QGaURQkLbpZgYF1BrYsoVHV7xyCVW5posWyaV8LJ8Wzbeb5vUusN9 6ExbXCcj8rFSIiLE3GeqsmfvzAJoTbPqq7klTeBYh/3/lk+pH8YVKpbZ5mdLIUwbSvwT igi3oThgT6aE4QBvdEMpseGDwIQDPIdQcX25s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=4nkPSScvvpzLThprElXhkUVotKEpd8W8jKJgSDHg38U=; b=NzhKnD+fwhARBWBtVSpv2thc8oCNBWv02eNdWs9KPEVgyay1hppUTdct3seyt7nAgA YT03m6g36vpi4kvcVel6qKaRh6Ql7HwPjNHu/2fsNwfe5I/XkfVAi0NcB9GVUkap23F7 LF8aLkZ+BwDsaRBFA61ljf/CDBEp1qO2O9HPlXrHBdcVOKwmVnmSKqXIgNCDFM5u+uIY a0EE727Vff119Bb9tntWksf8CEnhIBpf/MvuWCmARAT2YtZ7Mk7u5CX+4T5nQdD+WoH2 5MP1lB7hYoNYI3NqVZLDhHn7+lVfHWDfg1DWYbegcLKHxOe/09r52i4Z58hCgKjffRfV BI8g== X-Gm-Message-State: AA6/9Rm3dTlZ7NneUlhpJ9jJFmtJK8YSzLn1+ly71njCVoonerckFnFsF8UzE8I7OxSlAg== X-Received: by 10.55.203.213 with SMTP id u82mr15543627qkl.311.1475784008228; Thu, 06 Oct 2016 13:00:08 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id a20sm4251527qkj.39.2016.10.06.13.00.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Oct 2016 13:00:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <147578387937.23942.11530316341990997802.idtracker@ietfa.amsl.com> Date: Thu, 6 Oct 2016 16:00:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147578387937.23942.11530316341990997802.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Milestones changed for tls WG 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, 06 Oct 2016 20:00:11 -0000 It was suggested that I update the milestones. So I did. All dates are = ones I guessed at. spt > On Oct 06, 2016, at 15:57, IETF Secretariat = wrote: >=20 > Changed milestone "CBC Fixes to IESG", resolved as "Done - See RFC > 7525 & MTI AEAD algs in TLS1.3". >=20 > Changed milestone "RC4 replacement to IESG", resolved as "Done - See > RFC 7465 & RFC 7905", added draft-ietf-tls-prohibiting-rc4, > draft-ietf-tls-chacha20-poly1305 to milestone. >=20 > Changed milestone "(D)TLS 1.3 to IESG", set due date to February 2017 > from November 2014, added draft-ietf-tls-tls13 to milestone. >=20 > URL: https://datatracker.ietf.org/wg/tls/charter/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 6 13:08:10 2016 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 9B53A12977B for ; Thu, 6 Oct 2016 13:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 uqhGLPY3TacV for ; Thu, 6 Oct 2016 13:08:07 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2815012970A for ; Thu, 6 Oct 2016 13:08:07 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n189so26031237qke.0 for ; Thu, 06 Oct 2016 13:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Ms2Ok2srqxdrU1Oxp0p7rhormP8cDz/JB7Az1ADskpE=; b=XyD+vFGjIhYA3vxzrhulxKoc1fzbr4jTAMo2DakRumMpoEKO0Wwgaa5FRb3zQIUgCB GSaSdFRK7R0/c35icQYHsE0U5/eyl7f9fgGVQMAaz9pfDSNHN4NuD3KUxdN0HYBWAKKy pP4XASPXeo9QFnJJGzIMCkGByIFxLzfdhSTDI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Ms2Ok2srqxdrU1Oxp0p7rhormP8cDz/JB7Az1ADskpE=; b=Qt+n7OmLlOb82vdqcGVX6jf8PBjTeIMiqP/KM7kXXIC61VNFueBeOJHgOlqC7nAyKl 5zYMi9i6508IH1TFCo7ALpdLcpwVgd4kg+BNO61cXXUOr7Wv+DoUGgzlq3I1ELXVkrCM her+osOQBYHTAYS2RtE7LrXZ6GHR2ogk0GcHy2G7uQIXYuHVSvA5cOg4Zoub70B0DtnP GS8detiWv1F/hhyeKwNtt4dYV5MPgPQbRjA+Kul6bEn5tZqWRjlEbb9BNm+TZeIiFG9d FQgimV7bnblu9UWgUmdwssuJe//mkZay/DSfJxCy+W8wO7FHzsumTj5Zi3pSV/fcracU V9kA== X-Gm-Message-State: AA6/9RkWpCrBt5AfSpR/3RGxve9UkkoQ9AVGb5QeGQeA9kpMmjgM1WvF7KMx0/XTOmH8Wg== X-Received: by 10.55.9.149 with SMTP id 143mr14886489qkj.225.1475784485979; Thu, 06 Oct 2016 13:08:05 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id w72sm5693830qkb.33.2016.10.06.13.08.04 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Oct 2016 13:08:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <413E07D2-9B31-421B-A481-C720B163C56E@vigilsec.com> Date: Thu, 6 Oct 2016 16:08:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28214A3F-2F5F-4234-B7F3-147D44183FAD@sn3rd.com> References: <413E07D2-9B31-421B-A481-C720B163C56E@vigilsec.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3 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, 06 Oct 2016 20:08:09 -0000 All, It=E2=80=99s time to put this one to bed. ekr=E2=80=99s going to put = back user_mapping for Andrei/MS, but we=E2=80=99re going to ban/orphan = the client_authz and server_authz extensions. If it turns out that = there=E2=80=99s some need to later unban/unorphan them, then somebody = can write a draft that specifies how they=E2=80=99re used with TLS1.3. spt > On Sep 06, 2016, at 23:58, Russ Housley wrote: >=20 > I agree that client_authz and server_authz have not enjoyed much = implementation. >=20 > Russ >=20 >=20 > On Sep 3, 2016, at 3:54 PM, Eric Rescorla wrote: >=20 >> https://github.com/tlswg/tls13-spec/pull/624 >>=20 >> We currently have code points assigned for >>=20 >> user_mapping [RFC4681] =20 >> client_authz [RFC5878] =20 >> server_authz [RFC5878]=20 >>=20 >> These aren't well-specified for use in TLS 1.3 and my sense is that = they >> are barely used. Any objections to just banning them? If not, I'll = merge this >> PR end of next week. >>=20 >> -Ekr >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 6 14:10:39 2016 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 2931B129431 for ; Thu, 6 Oct 2016 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.446 X-Spam-Level: X-Spam-Status: No, score=-5.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 IKPNoHu0gGSf for ; Thu, 6 Oct 2016 14:10:33 -0700 (PDT) Received: from BLU004-OMC4S4.hotmail.com (blu004-omc4s4.hotmail.com [65.55.111.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA819129465 for ; Thu, 6 Oct 2016 14:10:33 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com ([65.55.111.135]) by BLU004-OMC4S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 6 Oct 2016 14:10:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4FxhJbscFrskLojTGb46XRZw9TzQb1T9HKw3QSzatQ0=; b=SSGlcG2kFxxQLLakRo3nICah6a30+VTt15JVcRf7P2x7LQfdj2KgrnqGezE6MBidFHpkF03jCdAljKGboUzbUcb30IWEL/e4x/0JQlxqZHdjHcUNpuQRyDZjpTgCMF+VvuTcet3tuJi+ptltZ6EbWHL0Ze/rRzne7Voh2aKv9R9RhfR9sUbpIcqcJKiVx+qpRNkrwACxDkje+OLjMNNXPMCJ25oOgkIwAWZn5ueB4Fp9DCSB0ET25Yd4U1iaWN4OCfteLofCAC551fypd+j4NvZXfbJxZpPJe7zzt1tft//Si7lAwHs/2QNzX6LumFiMwr+8e41jmtHrhc7pqvl0hg== Received: from CY1NAM02FT009.eop-nam02.prod.protection.outlook.com (10.152.74.59) by CY1NAM02HT205.eop-nam02.prod.protection.outlook.com (10.152.75.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Thu, 6 Oct 2016 21:10:31 +0000 Received: from CO1PR07MB283.namprd07.prod.outlook.com (10.152.74.55) by CY1NAM02FT009.mail.protection.outlook.com (10.152.75.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Thu, 6 Oct 2016 21:10:31 +0000 Received: from CO1PR07MB283.namprd07.prod.outlook.com ([169.254.11.14]) by CO1PR07MB283.namprd07.prod.outlook.com ([169.254.11.14]) with mapi id 15.01.0649.024; Thu, 6 Oct 2016 21:10:30 +0000 From: Yuhong Bao To: Sean Turner , "" Thread-Topic: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3 Thread-Index: AQHSBh0I/ZOBS3l64kyjGQoXY6cUOqBta+MAgC6ikoCAABFQ4g== Date: Thu, 6 Oct 2016 21:10:30 +0000 Message-ID: References: <413E07D2-9B31-421B-A481-C720B163C56E@vigilsec.com>, <28214A3F-2F5F-4234-B7F3-147D44183FAD@sn3rd.com> In-Reply-To: <28214A3F-2F5F-4234-B7F3-147D44183FAD@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sn3rd.com; dkim=none (message not signed) header.d=none;sn3rd.com; dmarc=none action=none header.from=hotmail.com; x-tmn: [0vo+wK+v3sMCoKWVgmfZmGLIDrJEeEP8] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; CY1NAM02HT205; 6:LMVyTLPr4B2598+FnRHfGzuoeH+4ikT+klxUkFrivVIBG5rdv/G6XynwIv7UG8ce3NNqbrmgOBFCqCya686yS5iJtnyFZIHjF5AtAOMtMviS/G6NMmOvEDtubTcYY8CrvtE7paqPdNdgL2/HpCQFK2uaXIlGidPGQ74F2VTt+X0UaH80UzlZLh1XJfg5VK32vOJo9WFQqHmf9RT/e5EpDL+sBS1NlczRzpzScQX/tcQf3YmqW91XItkC3off7irgyhQALWcx9E+rqcUadtmDRRTDerXfTs7pXl8luqkv/CU=; 5:6L79m0+1hRmXY0pKdYSL2ky7mp4Ur6OwbTTkAybUtdniPoV12TkZo/et5qb1YOlppCFLVzjHBriSMO+JUdZa5IYZzdKVzEx3BVl9hjMN4NFQU3ltVj7V+g9TWBFuNWKKQK0y5naktX2QGWtpG5BBWQ==; 24:xWzvwOx2An9ngJZ+7O9uSNfK4x1cFo1qyLqURXKXiNsefzzdk/tVB7WrGkf5Z4THEWTtj/DpsvdNllLKmmcid1hTQQ8qjfR4os52lJCuJYo=; 7:6zukh+M6iV098OMApMocbOxGG31RU0amynvyhYfzpj/8iKZA/JQ1xIkfWvJQaj5ptLW+TMo3XvO2gmE9NelgnGo5b1wdUq32iUTDdoKX0aec6w87Mh7rfLh+cZyVVy/D008wVSZOqNpZkO6lmejCk/eIZ3vBRP11L8FK8hfPk58NWW+FF/akz7OcwK1RhgQ/N0jDVZ2O5k7JCsFuE7dLwSs3hRZiHMsf0D0mQB7bm5H8tO+to7duYdTSu5nFnMR0Q7jE51RstWTkv+q4td0nyMsZ1K62ss2qkeJ0fQT6NFv1DxLMgKblCV4vFDx7rI2x x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1NAM02HT205; H:CO1PR07MB283.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 71b6bdd6-897a-41c3-6902-08d3ee2d3433 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:CY1NAM02HT205; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CY1NAM02HT205; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT205; x-forefront-prvs: 00872B689F spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO1PR07MB2837765F8C72641CD28058EC3C70CO1PR07MB283namprd_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2016 21:10:30.5265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT205 X-OriginalArrivalTime: 06 Oct 2016 21:10:32.0767 (UTC) FILETIME=[13059CF0:01D22016] Archived-At: Subject: Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3 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, 06 Oct 2016 21:10:37 -0000 --_000_CO1PR07MB2837765F8C72641CD28058EC3C70CO1PR07MB283namprd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yea, I think they were controversial due to a patent by RedPhone. ________________________________ From: TLS on behalf of Sean Turner Sent: Thursday, October 06, 2016 1:08:03 PM To: Subject: Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3 All, It=92s time to put this one to bed. ekr=92s going to put back user_mapping= for Andrei/MS, but we=92re going to ban/orphan the client_authz and server= _authz extensions. If it turns out that there=92s some need to later unban= /unorphan them, then somebody can write a draft that specifies how they=92r= e used with TLS1.3. spt > On Sep 06, 2016, at 23:58, Russ Housley wrote: > > I agree that client_authz and server_authz have not enjoyed much implemen= tation. > > Russ > > > On Sep 3, 2016, at 3:54 PM, Eric Rescorla wrote: > >> https://github.com/tlswg/tls13-spec/pull/624 >> >> We currently have code points assigned for >> >> user_mapping [RFC4681] >> client_authz [RFC5878] >> server_authz [RFC5878] >> >> These aren't well-specified for use in TLS 1.3 and my sense is that they >> are barely used. Any objections to just banning them? If not, I'll merge= this >> PR end of next week. >> >> -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CO1PR07MB2837765F8C72641CD28058EC3C70CO1PR07MB283namprd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Yea, I think they were controversial due to a patent by RedPhone.

From: TLS <tls-bounces= @ietf.org> on behalf of Sean Turner <sean@sn3rd.com>
Sent: Thursday, October 06, 2016 1:08:03 PM
To: <tls@ietf.org>
Subject: Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3
 
After the discussion on PR #615, I took another pass = at this with some
help from the research community. Please see:



Key changes in this PR:

1. I have merged the HMAC into the PreSharedKey message, where it is=
now called "PSK Binder" to make very clear what the pu= rpose of the
HMAC it is (this suggestion due to Karthik Bhargavan= ) This also makes
implementation somewhat easier and avoids creat= ing another extension.

2. It is now possible to ha= ve >1 PSK, each with its own binder.

3. The bin= der is now computed over the ClientHello prefix rather than
filli= ng the MAC with zeroes.

4. I've taken a sugges= tion from David Benjamin to move the negotiation
of the PSK key e= xchange parameters out of the PSK itself and into a
separate mess= age. This cleans things up and also lets us drop the
currently no= n-useful auth_mode parameter.

This text is still a= bit rough but I think shows the right direction.

= As usual, comments welcome, but I think the key question we need
= to resolve is whether we really need multiple PSKs. It's clearly
<= div>simpler not to support them but it seems like we need to worry about
the case where we are resuming a session created with a PSK. I'= ve come
to the conclusion that if we want to have multiple concur= rent PSKs at
all, then this is the right structure, rather than h= aving one PSK and
using HRR to fix it.

I= STM that the other major alternatives are to say:

= 1. You can't resume sessions created with a PSK.
2. Tickets c= reated in sessions created with a PSK have a hard lifetime
=C2=A0= =C2=A0value and it's a failure if the server forgets during the lifeti= me
=C2=A0 =C2=A0(this seems like it's going to interact badly= with clock skew).
=C2=A0 =C2=A0
Note that if we decide= that we only want one PSK, I'll just revise the
PreSharedKey= section to have one, not a list [0].

Thanks,
-Ekr

[0] In fairness, it's also worth no= ting that if we decide to only
have one, it's possible in the= future to replace the PreSharedKey
extension with a MultiplePreS= haredKey extension.


--f403045db83ea8d580053e47b211-- From nobody Fri Oct 7 08:11:43 2016 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 AECD112965A for ; Fri, 7 Oct 2016 08:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 RxNSUg2r_X9F for ; Fri, 7 Oct 2016 08:11:31 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EE9129635 for ; Fri, 7 Oct 2016 08:11:31 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id u124so33867089ywg.3 for ; Fri, 07 Oct 2016 08:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=D1LzwZCdJiNhD7b0b3hu8hmXI7p8Iko09aOlxKEOy3M=; b=zfC9hioZz9kDvd1tDjZxuxXhuVLGqA9vx59kVgisz0fyhgnHasy+z6Qg7MEmm3YIIY Y11bCh9kEPx1fT0rgD5+8+4wkIfXAlL+P4X3cEbaAal00jJzodzoCaOoBapAhi0AeunB e7A7VZ3QM9Ea5sKH1istsZDWK8p530O1mPd6WeX/Kw88DepOOOLUwVl7GnDf8zrcRAVV jjay/t+SQLY8bQU5UvDQp96z6uEJyABwUcB3nnDSJJZqAXwT4V1SuSYhHbhx+6iJfsNX 3Q/HRTluvYkB4u9tUjeqlpwXCFwzAfFFyqLfEZ7GK4ITt5HZ4d2Uj4km/j0vDBT3X1aq edBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=D1LzwZCdJiNhD7b0b3hu8hmXI7p8Iko09aOlxKEOy3M=; b=inMl+uKyPcpVoHQ7n6QcgADd/h6RTkUdrBPl4IIMbKmUo5ChlBhaNaWohhgycwaOoa Zi9d/FUUrt5V+Vh4Y5H2FKbodG9D5/0CNpiw2+avoLb1Fl7v4DjuyuFaFoKwNVPXog+7 hqL2iJ7XKaNTl5I1u7ZRrF9BPqXhoESNkR12WUhSQICbuMYbAJx8GJr43PWUkz71GmGc OX0+3EVSuGBgveSRGATN7dpnqTw8monYAr0aswHt35AyHVd/sKzXnQolRq3KwlbZdgcl K0oF0d74LlPXku+hu/lUOwm8E+yA093GpaWusJvDNETmXAh/YhJPnfDHVaGPS7C+4b48 FojA== X-Gm-Message-State: AA6/9RkLgleyaRfcn/hK9O3fb9FyfCzynHeOboge8HJxym0wLyThwEJn7UVLn74shFlZRg5UFpVL+n8iIICFeg== X-Received: by 10.129.83.193 with SMTP id h184mr16013630ywb.52.1475853089988; Fri, 07 Oct 2016 08:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 08:10:49 -0700 (PDT) From: Eric Rescorla Date: Fri, 7 Oct 2016 08:10:49 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114d6f1c2bd07a053e47d358 Archived-At: Subject: [TLS] Earlier exporters 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: Fri, 07 Oct 2016 15:11:33 -0000 --001a114d6f1c2bd07a053e47d358 Content-Type: text/plain; charset=UTF-8 Please see the following PR: https://github.com/tlswg/tls13-spec/pull/673 This includes various changes to make exporters/resumption work better. Basically: 1. Add a 0-RTT exporter and change the transcript for the regular exporter so it only includes the transcript up to ServerFinished. This gives it parity with the rest of the traffic keys. If we need an exporter with the full transcript we can always add it later 2. Point out that you can predict ClientFinished for NST when not doing Client auth. This lets you issue tickets on the server's first flight, while still ensuring that if you do client auth you still bind resumption to the client's full transcript. These are pretty straightforward changes, so absent objections I'll merge them early next week. -Ekr --001a114d6f1c2bd07a053e47d358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please see the following PR:

This includes various = changes to make exporters/resumption work better.

= Basically:
1. Add a 0-RTT exporter and change the transcript for = the regular exporter so it
=C2=A0 =C2=A0 only includes the transc= ript up to ServerFinished. This gives it parity with the
=C2=A0 = =C2=A0 rest of the traffic keys. If we need an exporter with the full trans= cript we can
=C2=A0 =C2=A0 always add it later

2. Point out that you can predict ClientFinished for NST when not do= ing
=C2=A0 =C2=A0 Client auth. This lets you issue tickets o= n the server's first flight, while still
=C2=A0 =C2=A0 = ensuring that if you do client auth you still bind resumption to the client= 's
=C2=A0 =C2=A0 full transcript.

Th= ese are pretty straightforward changes, so absent objections I'll merge=
them early next week.

-Ekr
--001a114d6f1c2bd07a053e47d358-- From nobody Fri Oct 7 08:26:43 2016 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 076CC12962F for ; Fri, 7 Oct 2016 08:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.396 X-Spam-Level: X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 LPy3BsH0AFJp for ; Fri, 7 Oct 2016 08:26:37 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDEC129426 for ; Fri, 7 Oct 2016 08:26:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E0D2816313; Fri, 7 Oct 2016 18:26:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id f_Ts1Kdf_ExC; Fri, 7 Oct 2016 18:26:34 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 920C52310; Fri, 7 Oct 2016 18:26:34 +0300 (EEST) Date: Fri, 7 Oct 2016 18:26:28 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Fri, 07 Oct 2016 15:26:40 -0000 On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > After the discussion on PR #615, I took another pass at this with some > help from the research community. Please see: > > https://github.com/tlswg/tls13-spec/pull/672 > > > Key changes in this PR: > > 1. I have merged the HMAC into the PreSharedKey message, where it is > now called "PSK Binder" to make very clear what the purpose of the > HMAC it is (this suggestion due to Karthik Bhargavan) This also makes > implementation somewhat easier and avoids creating another extension. > > 2. It is now possible to have >1 PSK, each with its own binder. > > 3. The binder is now computed over the ClientHello prefix rather than > filling the MAC with zeroes. > > 4. I've taken a suggestion from David Benjamin to move the negotiation > of the PSK key exchange parameters out of the PSK itself and into a > separate message. This cleans things up and also lets us drop the > currently non-useful auth_mode parameter. Eeh... From the text, it seems to currently require the kex modes extension if PSK extension is present. Which seems worse than useless if the meaning is to get rid of the kex mode parameter from PSK extension (since you will have the value anyway, but need to dig it from another extension... Blech). > This text is still a bit rough but I think shows the right direction. I would talk about PSKs established by NST, not resumption PSKs. Also, didn't notice what prevents pathology like this (I presume this is not allowed): (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] ---> [0-RTT data, encrypted using AES-128-GCM-SHA256] <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] <-- EncryptedExtensions[EarlyDataIndication] Note the record protection algorithm mismatch. Also, to straightforwardly prove that collision resistance of HKDF and HMAC (as used) follows from collision resistance of the underlying hash function, yon need to take the output to be at least the hash output size. As otherwise it is not guaranteed that any collision in HKDF or HMAC can be reduced into collision of the underlying hash. -Ilari From nobody Fri Oct 7 09:36:26 2016 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 407E912956C for ; Fri, 7 Oct 2016 09:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 PbCC4UYuMwXF for ; Fri, 7 Oct 2016 09:36:22 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BBD129529 for ; Fri, 7 Oct 2016 09:36:22 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id w3so8205755ywg.1 for ; Fri, 07 Oct 2016 09:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pgVHmP8IK+l3mSCt72rEdmfE16xlLHF90wm+p9pI5UA=; b=ZMrurDi7zcY4VQTrHWbk3/cSYYlQUPp6cAAmuUdYDOeNckYuNK6KmpyDtqLo9ZuSJc rqt8mVPmDzE8bJ5Bo+6C7oENGwRbt6kxgANiZ0P20sNY7kjLTz0Hb9gVHtLVKS74jw/V 1kGdXiM1VbkUYV5hbSybCpUgzZVjJj+pA8LLeFx9puSDTVMiwWo7qMuk8jzO084G2aQf WWZjUVcuYNyfYYr3nwyNdgxo/sK2OzSRfMWejG8Os2E45haojb1hQqSOsTV3je0URSWE zdUu2UnqG4em1Z2nMDyORiawf+6X/cCJPVGT4HyJezeOXz8TrIz3C+03Qo7fkgIsFwAB QlFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pgVHmP8IK+l3mSCt72rEdmfE16xlLHF90wm+p9pI5UA=; b=VGuI3+sLnANxe05tEZ+KJpABub/O1IqNZpEU9y064ftC04BIpfDqt7XY/APClz67+P VYqJZ28Yn/ekP5UuWpPIXFxHTdXMWhv+cKbaRY2ssTr5XIT399/LfroO6a/WtjxgZCYX srLrjOYjnJmS+I4INxrTclxMp7sxI2SRWrFTeHLGHUlnu4JJ92TYDLuxv3yDSemtElzM OIeELMueKAew37sR5gKVqkS1sPILC89dT7ZeNFuRPKYVmYucegcrdOVT0fGb2SJVzF9A ruB8hGFjdSzNfsk8sTlUSONFu4Aaa4PgAW2SR4aNBaY8e+12hVIw0d7YKOI+ffB95UTK b2lg== X-Gm-Message-State: AA6/9RnGg4XzeSUz0LWgFPgyNM0ZX7Ov8Dm8oe4hHvQ/3sLAbBSKJK3/Odi2cC1PiXM8Z7Ml9awCwHuKig8mhw== X-Received: by 10.129.125.198 with SMTP id y189mr15456708ywc.234.1475858181380; Fri, 07 Oct 2016 09:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 09:35:40 -0700 (PDT) In-Reply-To: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 7 Oct 2016 09:35:40 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114926a0a41bca053e4902a5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Fri, 07 Oct 2016 16:36:24 -0000 --001a114926a0a41bca053e4902a5 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara wrote: > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > After the discussion on PR #615, I took another pass at this with some > > help from the research community. Please see: > > > > https://github.com/tlswg/tls13-spec/pull/672 > > > > > > Key changes in this PR: > > > > 1. I have merged the HMAC into the PreSharedKey message, where it is > > now called "PSK Binder" to make very clear what the purpose of the > > HMAC it is (this suggestion due to Karthik Bhargavan) This also makes > > implementation somewhat easier and avoids creating another extension. > > > > 2. It is now possible to have >1 PSK, each with its own binder. > > > > 3. The binder is now computed over the ClientHello prefix rather than > > filling the MAC with zeroes. > > > > 4. I've taken a suggestion from David Benjamin to move the negotiation > > of the PSK key exchange parameters out of the PSK itself and into a > > separate message. This cleans things up and also lets us drop the > > currently non-useful auth_mode parameter. > > Eeh... From the text, it seems to currently require the kex modes > extension if PSK extension is present. Which seems worse than useless > if the meaning is to get rid of the kex mode parameter from PSK > extension (since you will have the value anyway, but need to dig it > from another extension... Blech). > I guess this is a matter of taste, but what convinced me was that: 1. It put all the logic on the server side. 2. It removed the auth mod parameter. Maybe david can say more. > This text is still a bit rough but I think shows the right direction. > > I would talk about PSKs established by NST, not resumption PSKs. > Willdo. > > Also, didn't notice what prevents pathology like this (I presume this > is not allowed): > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] ---> > [0-RTT data, encrypted using AES-128-GCM-SHA256] > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] > <-- EncryptedExtensions[EarlyDataIndication] > > Note the record protection algorithm mismatch. > Yes, this is forbidden by the combination of: "The parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) are the same as those which were negotiated in the connection which established the PSK. The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension." (though I think I just recently added cipher suite). and: "Any ticket MUST only be resumed with a cipher suite that is identical to that negotiated connection where the ticket was established." Also, to straightforwardly prove that collision resistance of HKDF and > HMAC (as used) follows from collision resistance of the underlying hash > function, yon need to take the output to be at least the hash output > size. As otherwise it is not guaranteed that any collision in HKDF or > HMAC can be reduced into collision of the underlying hash. > Right. I have some text here but please feel free to suggest more. -Ekr > > > > > -Ilari > --001a114926a0a41bca053e4902a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wr= ote:
> After the discussion on PR #615, I took another pass at this with some=
> help from the research community. Please see:
>
>=C2=A0 =C2=A0 https://github.com/tlswg/tls13-sp= ec/pull/672
>
>
> Key changes in this PR:
>
> 1. I have merged the HMAC into the PreSharedKey message, where it is > now called "PSK Binder" to make very clear what the purpose = of the
> HMAC it is (this suggestion due to Karthik Bhargavan) This also makes<= br> > implementation somewhat easier and avoids creating another extension.<= br> >
> 2. It is now possible to have >1 PSK, each with its own binder.
>
> 3. The binder is now computed over the ClientHello prefix rather than<= br> > filling the MAC with zeroes.
>
> 4. I've taken a suggestion from David Benjamin to move the negotia= tion
> of the PSK key exchange parameters out of the PSK itself and into a > separate message. This cleans things up and also lets us drop the
> currently non-useful auth_mode parameter.

Eeh... From the text, it seems to currently require the kex modes extension if PSK extension is present. Which seems worse than useless
if the meaning is to get rid of the kex mode parameter from PSK
extension (since you will have the value anyway, but need to dig it
from another extension... Blech).

I gue= ss this is a matter of taste, but what convinced me was that:
1. It put all the logic on the server side.
2. It rem= oved the auth mod parameter.

Maybe david can say m= ore.


> This text is still a bit rough but I think shows the right direction.<= br>
I would talk about PSKs established by NST, not resumption PSKs.
=

Willdo.

=C2=A0

Also, didn't notice what prevents pathology like this (I presume this is not allowed):

(Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)

ClientHello[Ciphers=3DCHACHA20-POLY1305-SHA256, EarlyDataIndication] -= -->
[0-RTT data, encrypted using AES-128-GCM-SHA256]
<-- ServerHello[Cipher=3DCHACHA20-POLY1305-SHA256]
<-- EncryptedExtensions[EarlyDataIndication]

Note the record protection algorithm mismatch.

Yes, this is forbidden by the combination of:

<= div>"The parameters for the 0-RTT data (symmetric cipher suite,
<= div>ALPN, etc.) are the same as those which were negotiated in the connecti= on
which established the PSK.=C2=A0 The PSK used to encrypt the e= arly data
MUST be the first PSK listed in the client's "= pre_shared_key" extension."
(though I think I just rece= ntly added cipher suite).

and:
"Any= ticket MUST only be resumed with a cipher suite that is identical
to that negotiated connection where the ticket was established."



Also, to straightforwardly prove that collision resistance of HKDF and
HMAC (as used) follows from collision resistance of the underlying hash
function, yon need to take the output to be at least the hash output
size. As otherwise it is not guaranteed that any collision in HKDF or
HMAC can be reduced into collision of the underlying hash.
=

Right. I have some text here but please feel free to su= ggest more.

-Ekr


=C2=A0




-Ilari

--001a114926a0a41bca053e4902a5-- From nobody Fri Oct 7 09:57:42 2016 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 5928F1295EF for ; Fri, 7 Oct 2016 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=filippo.io header.b=E5NXjMNf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=cXmt4n+J 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 FXbLUNeCa0ZY for ; Fri, 7 Oct 2016 09:57:38 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D635B1295F0 for ; Fri, 7 Oct 2016 09:57:38 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 340DC20866; Fri, 7 Oct 2016 12:57:38 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute3.internal (MEProxy); Fri, 07 Oct 2016 12:57:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=filippo.io; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Is8 83vNLqSF8uNEllOaCbr9NyMI=; b=E5NXjMNfbXGyBUawUM8MM8hmjydKOH+QYpQ PZ9d53fA75U/NM1YFMG4ecXCHrBW116e8apUGEoHEj6xqruk1hBUlcG922bu270X 8F093jpmoF2yyT6/01HqHUUVxq0oBm13pqhq29C0asi/57vZX/g9FN/MgdwIQLCP OlnRH2BA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Is883vNLqSF8uNEllOaCbr9NyMI=; b=cXmt4 n+J1newMl/UrgwN8tBf5yHf8lIcVxYtyUIt0S/JWpRyO0To1vDxUz7QmJ3rv1NQU XOp0XDb9eGAnpw2DVGIusuSAWyd6N3oNDOeFO04tomXngIbTx9X2eTbFsbcyS3li 4f0vzLW6yFB611GT8+0i10vdA3xgDsY2bngD9s= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 08CEC96E99; Fri, 7 Oct 2016 12:57:37 -0400 (EDT) Message-Id: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com> X-Sasl-Enc: ESAAJp2pVB1AaiR4u5lwzwgzZJCsDzL32N4H3uW4NysM 1475859457 From: Filippo Valsorda To: tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-43d69252 Date: Fri, 07 Oct 2016 12:57:37 -0400 Archived-At: Cc: filippo@cloudflare.com, aaspring@umich.edu Subject: [TLS] Add max_early_data_size to TicketEarlyDataInfo 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: Fri, 07 Oct 2016 16:57:40 -0000 Hello, Cloudflare's current (not definitive) plan for 0-RTT is essentially to decide whether or not to answer to requests in the 0.5 flight on a case-by-case basis. That obviously requires reading all of them and caching the ones we don't want to answer. To mitigate the obvious DoS concern we plan to use the ticket age and a per-machine replay cache. However, chatting with Drew (cc'd) we realized that clients could still send huge amounts of 0-RTT data that we would have to buffer. Once a client sent early data, there's no way to accept only a part of it or to verify that the client is not replaying before reading it all. But if we were to close the connection after a given amount of data we risk failing connections from legal clients. I propose to add a field max_early_data_size to TicketEarlyDataInfo, to inform clients about the maximum amount of 0-RTT data they are allowed to send, allowing servers to safely terminate connections that exceed it. https://github.com/tlswg/tls13-spec/pull/674 [Please keep me in the CC of replies] From nobody Fri Oct 7 10:03:35 2016 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 7A70F12965B for ; Fri, 7 Oct 2016 10:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 q5zwB-CSqGua for ; Fri, 7 Oct 2016 10:03:31 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC75A129663 for ; Fri, 7 Oct 2016 10:03:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 4D401117EE; Fri, 7 Oct 2016 20:03:29 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id pLgEBEWUJFx5; Fri, 7 Oct 2016 20:03:28 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D43C92313; Fri, 7 Oct 2016 20:03:28 +0300 (EEST) Date: Fri, 7 Oct 2016 20:03:23 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Fri, 07 Oct 2016 17:03:34 -0000 On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara > wrote: > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > 4. I've taken a suggestion from David Benjamin to move the negotiation > > > of the PSK key exchange parameters out of the PSK itself and into a > > > separate message. This cleans things up and also lets us drop the > > > currently non-useful auth_mode parameter. > > > > Eeh... From the text, it seems to currently require the kex modes > > extension if PSK extension is present. Which seems worse than useless > > if the meaning is to get rid of the kex mode parameter from PSK > > extension (since you will have the value anyway, but need to dig it > > from another extension... Blech). > > I guess this is a matter of taste, but what convinced me was that: > > 1. It put all the logic on the server side. > 2. It removed the auth mod parameter. > > Maybe david can say more. I mean if server is to accept PSK, it must now go fishing for another extension, check that it is present and pay attention to values there. As opposed to having the data in where it is needed. > > Also, didn't notice what prevents pathology like this (I presume this > > is not allowed): > > > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) > > > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] ---> > > [0-RTT data, encrypted using AES-128-GCM-SHA256] > > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] > > <-- EncryptedExtensions[EarlyDataIndication] > > > > Note the record protection algorithm mismatch. > > > > Yes, this is forbidden by the combination of: > > "The parameters for the 0-RTT data (symmetric cipher suite, > ALPN, etc.) are the same as those which were negotiated in the connection > which established the PSK. The PSK used to encrypt the early data > MUST be the first PSK listed in the client's "pre_shared_key" extension." > (though I think I just recently added cipher suite). > > and: > "Any ticket MUST only be resumed with a cipher suite that is identical > to that negotiated connection where the ticket was established." If 0-RTT is used with manually provisioned PSKs (might not be allowed currently, but might be allowed soon), does that still hold? Also, I think it is problematic that externally provisioned PSKs can be used with any protection with given prf-hash, while NST-provisioned PSKs can only be used with one protection and prf-hash. 0-RTT requirements are separate matter, since those would apply to all. The original purpose of resumption-as-PSK was AFAIK to unify the two mechanisms to simplify things. Therefore those two should be as similar as possible. > > Also, to straightforwardly prove that collision resistance of HKDF and > > HMAC (as used) follows from collision resistance of the underlying hash > > function, yon need to take the output to be at least the hash output > > size. As otherwise it is not guaranteed that any collision in HKDF or > > HMAC can be reduced into collision of the underlying hash. > > > > Right. I have some text here but please feel free to suggest more. Yes, but the text says 256 bit output is enough. One isn't guaranteed to be able to reduce such collision to collision of >256 bit hash. (In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely unlikely to reduce). -Ilari From nobody Fri Oct 7 10:08:46 2016 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 44D7312967D for ; Fri, 7 Oct 2016 10:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 n7CQT8eNlEQQ for ; Fri, 7 Oct 2016 10:08:43 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF2E129663 for ; Fri, 7 Oct 2016 10:08:43 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id u124so35870381ywg.3 for ; Fri, 07 Oct 2016 10:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5nQaLjenmIEupa5vi7pI4aviS5CY2mtITuPokz+RSvM=; b=CnVVI8j1Yj3LJv5pJotA8WI48L/xRJsB1dSZzWfeHeS9ZilsAdG4AF4uuAJAvmdOfz qbJeHdoYm95vws2O37ZVTvbC945Ef2O5LofAqhisYsln2DfXsgzYwQVUIJDKno885iU7 /vRJuTKckXK/FIMNBAdQs+Slfc9/aWNOim2NDh42ZfxQFVL2bGuJvwCreQL4UejA+QrW TenbquzYaPdNkwFUQ6oy3CiRjfltdv2U02z69Oyn0v3QfAeEvfkzPwQYTDDKnp/yHyEA GxrOjfVi9ZhCJpZradqVkuDp/WQ1Z5st+5mPD05myVlObi1e/Cz2f1q4wNysvIaUYAoq stHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5nQaLjenmIEupa5vi7pI4aviS5CY2mtITuPokz+RSvM=; b=ht7NAYNQ230XvLH1fr9gK+3cz05wPDrprfbg/tXWDDlBUUK411l4llTIpBhBTQsqhH MvuaWX3+B0cAF89TyURTW65jOfmNQJuvCCjA/PBpvjDb8Ke9TFOcFlwfJLyGZYx+33Hc hdbSTso7yBEOF/kQdHi/HIWExyjxA3GZ22csx53FHOYseA4hEbQvifh98Ar8pK3gEJzN DuT6mXkHFebVZQ0LdlraCMYo9CUotc+4MBeAmiTs072ouZgLAVccL6EgVXZDQfccQUNt TiPPJocREkcZTYoTMxdc/eNrW1++w1tBe4OiZVhT4FbMoSFn4i5CKmYJuT0fOPl5hw/G S7RA== X-Gm-Message-State: AA6/9RnJaqfa3+Vt66eA0Uy/3PiocawzYfnsL+amZZUCHuxS91XEfZ8sVqvuBVvmq2ruxgkhsQbTS6S7nkD/hg== X-Received: by 10.129.53.206 with SMTP id c197mr15896511ywa.205.1475860122732; Fri, 07 Oct 2016 10:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 10:08:02 -0700 (PDT) In-Reply-To: <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 7 Oct 2016 10:08:02 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11421a265acb57053e49761b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Fri, 07 Oct 2016 17:08:45 -0000 --001a11421a265acb57053e49761b Content-Type: text/plain; charset=UTF-8 On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara wrote: > On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > > 4. I've taken a suggestion from David Benjamin to move the > negotiation > > > > of the PSK key exchange parameters out of the PSK itself and into a > > > > separate message. This cleans things up and also lets us drop the > > > > currently non-useful auth_mode parameter. > > > > > > Eeh... From the text, it seems to currently require the kex modes > > > extension if PSK extension is present. Which seems worse than useless > > > if the meaning is to get rid of the kex mode parameter from PSK > > > extension (since you will have the value anyway, but need to dig it > > > from another extension... Blech). > > > > I guess this is a matter of taste, but what convinced me was that: > > > > 1. It put all the logic on the server side. > > 2. It removed the auth mod parameter. > > > > Maybe david can say more. > > I mean if server is to accept PSK, it must now go fishing for another > extension, check that it is present and pay attention to values there. > As opposed to having the data in where it is needed. > This is a reasonable argument (and the reason I stuffed the binder here). However, David's argument was that this applied to *all* PSKs even new ones. -Ekr > > Also, didn't notice what prevents pathology like this (I presume this > > > is not allowed): > > > > > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) > > > > > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] > ---> > > > [0-RTT data, encrypted using AES-128-GCM-SHA256] > > > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] > > > <-- EncryptedExtensions[EarlyDataIndication] > > > > > > Note the record protection algorithm mismatch. > > > > > > > Yes, this is forbidden by the combination of: > > > > "The parameters for the 0-RTT data (symmetric cipher suite, > > ALPN, etc.) are the same as those which were negotiated in the connection > > which established the PSK. The PSK used to encrypt the early data > > MUST be the first PSK listed in the client's "pre_shared_key" extension." > > (though I think I just recently added cipher suite). > > > > and: > > "Any ticket MUST only be resumed with a cipher suite that is identical > > to that negotiated connection where the ticket was established." > > If 0-RTT is used with manually provisioned PSKs (might not be allowed > currently, but might be allowed soon), does that still hold? > > Also, I think it is problematic that externally provisioned PSKs can > be used with any protection with given prf-hash, while NST-provisioned > PSKs can only be used with one protection and prf-hash. > > 0-RTT requirements are separate matter, since those would apply to all. > > The original purpose of resumption-as-PSK was AFAIK to unify the two > mechanisms to simplify things. Therefore those two should be as similar > as possible. > > > > > Also, to straightforwardly prove that collision resistance of HKDF and > > > HMAC (as used) follows from collision resistance of the underlying hash > > > function, yon need to take the output to be at least the hash output > > > size. As otherwise it is not guaranteed that any collision in HKDF or > > > HMAC can be reduced into collision of the underlying hash. > > > > > > > Right. I have some text here but please feel free to suggest more. > > Yes, but the text says 256 bit output is enough. One isn't guaranteed > to be able to reduce such collision to collision of >256 bit hash. > > (In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely > unlikely to reduce). > Right. I can update. -Ekr > > > > -Ilari > --001a11421a265acb57053e49761b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > 4. I've taken a suggestion from = David Benjamin to move the negotiation
> > > of the PSK key exchange parameters out of the PSK itself and= into a
> > > separate message. This cleans things up and also lets us dro= p the
> > > currently non-useful auth_mode parameter.
> >
> > Eeh... From the text, it seems to currently require the kex modes=
> > extension if PSK extension is present. Which seems worse than use= less
> > if the meaning is to get rid of the kex mode parameter from PSK > > extension (since you will have the value anyway, but need to dig = it
> > from another extension... Blech).
>
> I guess this is a matter of taste, but what convinced me was that:
>
> 1. It put all the logic on the server side.
> 2. It removed the auth mod parameter.
>
> Maybe david can say more.

I mean if server is to accept PSK, it must now go fishing for anothe= r
extension, check that it is present and pay attention to values there.
As opposed to having the data in where it is needed.
<= br>
This is a reasonable argument (and the reason I stuffed the b= inder here).
However, David's argument was that this applied = to *all* PSKs even new ones.


-Ekr

> > Also, didn't notice what prevents pathology like this (I pres= ume this
> > is not allowed):
> >
> > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)
> >
> > ClientHello[Ciphers=3DCHACHA20-POLY1305-SHA256, EarlyDataInd= ication] --->
> > [0-RTT data, encrypted using AES-128-GCM-SHA256]
> > <-- ServerHello[Cipher=3DCHACHA20-POLY1305-SHA256]
> > <-- EncryptedExtensions[EarlyDataIndication]
> >
> > Note the record protection algorithm mismatch.
> >
>
> Yes, this is forbidden by the combination of:
>
> "The parameters for the 0-RTT data (symmetric cipher suite,
> ALPN, etc.) are the same as those which were negotiated in the connect= ion
> which established the PSK.=C2=A0 The PSK used to encrypt the early dat= a
> MUST be the first PSK listed in the client's "pre_shared_key&= quot; extension."
> (though I think I just recently added cipher suite).
>
> and:
> "Any ticket MUST only be resumed with a cipher suite that is iden= tical
> to that negotiated connection where the ticket was established."<= br>
If 0-RTT is used with manually provisioned PSKs (might not be allowe= d
currently, but might be allowed soon), does that still hold?

Also, I think it is problematic that externally provisioned PSKs can
be used with any protection with given prf-hash, while NST-provisioned
PSKs can only be used with one protection and prf-hash.

0-RTT requirements are separate matter, since those would apply to all.

The original purpose of resumption-as-PSK was AFAIK to unify the two
mechanisms to simplify things. Therefore those two should be as similar
as possible.

>
> Also, to straightforwardly prove that collision resistance of HKDF and=
> > HMAC (as used) follows from collision resistance of the underlyin= g hash
> > function, yon need to take the output to be at least the hash out= put
> > size. As otherwise it is not guaranteed that any collision in HKD= F or
> > HMAC can be reduced into collision of the underlying hash.
> >
>
> Right. I have some text here but please feel free to suggest more.

Yes, but the text says 256 bit output is enough. One isn't guara= nteed
to be able to reduce such collision to collision of >256 bit hash.

(In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely
unlikely to reduce).

Right. I can updat= e.

-Ekr
=C2=A0



-Ilari

--001a11421a265acb57053e49761b-- From nobody Fri Oct 7 13:40:02 2016 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 0AC5F12940F for ; Fri, 7 Oct 2016 13:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 6HV_sHf3TzmI for ; Fri, 7 Oct 2016 13:39:58 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 79077129547 for ; Fri, 7 Oct 2016 13:39:58 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A64C64E1335; Fri, 7 Oct 2016 20:39:57 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 8FAE74E1313; Fri, 7 Oct 2016 20:39:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1475872797; bh=MJXUelNkFa+RidSN0ogkwPn8V6ZXQrWgNsjvN2IzTYY=; l=8031; h=To:References:Cc:From:Date:In-Reply-To:From; b=i8u3CZR2cTApgEOnHDhjuRk1tMz7XUESpDXN5Oystru0MDIQtQQLFBbQSbzO6QJd8 kNDwhF3CSx/z1yTeO6Z5EkGzkLWoRfvDqnYyyrXlhHWpXih8Aa28aDbZ2i3C13UGI/ Q5YlPu96LXOjabxHgo4BjBy10eJznyhRtyZ47tes= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 51FFE1FC88; Fri, 7 Oct 2016 20:39:57 +0000 (GMT) To: Eric Rescorla , Ilari Liusvaara References: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 7 Oct 2016 15:39:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ED62A6EB235372656596D553" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Fri, 07 Oct 2016 20:40:01 -0000 This is a multi-part message in MIME format. --------------ED62A6EB235372656596D553 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/07/2016 12:08 PM, Eric Rescorla wrote: > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > > wrote: > > On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara > > > > wrote: > > > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > > 4. I've taken a suggestion from David Benjamin to move the negotiation > > > > of the PSK key exchange parameters out of the PSK itself and > into a > > > > separate message. This cleans things up and also lets us > drop the > > > > currently non-useful auth_mode parameter. > > > > > > Eeh... From the text, it seems to currently require the kex modes > > > extension if PSK extension is present. Which seems worse than > useless > > > if the meaning is to get rid of the kex mode parameter from PSK > > > extension (since you will have the value anyway, but need to > dig it > > > from another extension... Blech). > > > > I guess this is a matter of taste, but what convinced me was that: > > > > 1. It put all the logic on the server side. > I was going to ask whether this also includes the decision on whether to send a Certificate to authenticate the server (even for PSK modes), but it looks like this change is intentionally removing the ability to do PSK keyex and auth with a certificate? > > 2. It removed the auth mod parameter. > > > > Maybe david can say more. > > I mean if server is to accept PSK, it must now go fishing for another > extension, check that it is present and pay attention to values there. > As opposed to having the data in where it is needed. > > > This is a reasonable argument (and the reason I stuffed the binder here). > However, David's argument was that this applied to *all* PSKs even new > ones. > Implementations already have to do some amount of "scan through all extensions to detect certain things, do some initial processing, and then finish process everything [else]", not least because SNI can change what cert types you have, configuration knobs, etc.. So, yes it's bad, but how bad is it in a relative sense? I think there is some value in the client indicating to the server whether it doesn't want to do psk_dhe (or doesn't want to do pure psk) for future NSTs, though it's perhaps not of the utmost importance. That property does support a separate psk_key_exchange_modes extension in preference to rolling it into pre_shared_keys (as a separate list next to identities and binders), but it seems to only be a weak argument for separation. I do think that keeping the psk kex mode orthogonal to the individual keys is helpful, though. Anyway, maybe it's time to bite the bullet and actually write up the description of the proper procedure for ClientHello processing (scan extensions for SNI, load up servername-specific config+cert/key, etc.). Which would make this stuff any prettier, but would at least help people not get it wrong. -Ben --------------ED62A6EB235372656596D553 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 10/07/2016 12:08 PM, Eric Rescorla wrote:


On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > 4. I've taken a suggestion from David Benjamin to move the negotiation
> > > of the PSK key exchange parameters out of the PSK itself and into a
> > > separate message. This cleans things up and also lets us drop the
> > > currently non-useful auth_mode parameter.
> >
> > Eeh... From the text, it seems to currently require the kex modes
> > extension if PSK extension is present. Which seems worse than useless
> > if the meaning is to get rid of the kex mode parameter from PSK
> > extension (since you will have the value anyway, but need to dig it
> > from another extension... Blech).
>
> I guess this is a matter of taste, but what convinced me was that:
>
> 1. It put all the logic on the server side.

I was going to ask whether this also includes the decision on whether to send a Certificate to authenticate the server (even for PSK modes), but it looks like this change is intentionally removing the ability to do PSK keyex and auth with a certificate?

> 2. It removed the auth mod parameter.
>
> Maybe david can say more.

I mean if server is to accept PSK, it must now go fishing for another
extension, check that it is present and pay attention to values there.
As opposed to having the data in where it is needed.

This is a reasonable argument (and the reason I stuffed the binder here).
However, David's argument was that this applied to *all* PSKs even new ones.


Implementations already have to do some amount of "scan through all extensions to detect certain things, do some initial processing, and then finish process everything [else]", not least because SNI can change what cert types you have, configuration knobs, etc..  So, yes it's bad, but how bad is it in a relative sense?

I think there is some value in the client indicating to the server whether it doesn't want to do psk_dhe (or doesn't want to do pure psk) for future NSTs, though it's perhaps not of the utmost importance.  That property does support a separate psk_key_exchange_modes extension in preference  to rolling it into pre_shared_keys (as a separate list next to identities and binders), but it seems to only be a weak argument for separation.  I do think that keeping the psk kex mode orthogonal to the individual keys is helpful, though.

Anyway, maybe it's time to bite the bullet and actually write up the description of the proper procedure for ClientHello processing (scan extensions for SNI, load up servername-specific config+cert/key, etc.).  Which would make this stuff any prettier, but would at least help people not get it wrong.

-Ben
--------------ED62A6EB235372656596D553-- From nobody Fri Oct 7 13:41:19 2016 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 A38C0129436 for ; Fri, 7 Oct 2016 13:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CLJj0IFa-vhI for ; Fri, 7 Oct 2016 13:41:15 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A3812940F for ; Fri, 7 Oct 2016 13:41:15 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id u68so54090799uau.2 for ; Fri, 07 Oct 2016 13:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0n/HjdBOQqdje+XGm2c48iHGpT6q8e1AbiD8WiXK6hc=; b=iFHV7jHztGU7DLfUFPbnJFlCPSg9PTHcMPjb/gIXHNE+HFTk83j03x8KRtce+m5xM0 SeyaocGdcl7ULMDilmsHlsKAZcLNYdYq6lnXHEhmbQjLnJMOVdlX3w1m3gU9OOP9XJsE CxBE/N9QxumDnxK+gTdLQVn95fYU7TgFMLYBKdVIg648H9cQyghdN7tbSTLW2zxbaUfy qjOJHTg90KHDb82RG9SDOqhyjM0mDmrqEDPiXfw0B8DWkR5DoXO2woCLPVysWc09CKII iwdDXqQxT4IFJ4mE8vNvSLrkOsOA+5kVTO3x+6WgLPT70uIf77qrOfm10l7vTjT/nVlJ CWtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0n/HjdBOQqdje+XGm2c48iHGpT6q8e1AbiD8WiXK6hc=; b=dd163n9ZRkncQ7Og/WqqL7TxYF3Of6i/lCTKyht+XFGxzLLcsKsYKIJhk7TE9effan JWbwgqYGlIHe5wHqniGvYR4fZtctyweNDA//czaeFAc1FY3NUgWCgITE8nuZ1kUBRnbF B/0Se2tma8V2r4KLV/hzyKQgcmjymNM/tVhs9VrU8nQS0uvW45NvOoC5kcPreYeXNtPD HJwDY++I9HvR8/IJUQjcH4A9AD82mJgz0B4loIGdEiKVyQJjmh347WlN9zKDhyvgIlW9 Y72zladv1+IcvAr7u/EB10HzplfxvhYF6GlNRaK/zN/J82RBt6/WkA8QJA4OB351Dtnr K6FQ== X-Gm-Message-State: AA6/9RlLeXM7vEW8Xob4OoTxQ5TND6w1eiqFiSzkzMrTdeljDrgNY1YEsxr2mSwqqjRNUTnEyupwx+Jhp9aZVg== X-Received: by 10.176.82.161 with SMTP id v30mr15843524uav.28.1475872874517; Fri, 07 Oct 2016 13:41:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.41 with HTTP; Fri, 7 Oct 2016 13:41:14 -0700 (PDT) In-Reply-To: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> From: Watson Ladd Date: Fri, 7 Oct 2016 13:41:14 -0700 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Fri, 07 Oct 2016 20:41:18 -0000 On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara wrote: > On Fri, Sep 23, 2016 at 04:08:38PM -0700, Watson Ladd wrote: >> Dear all, >> We've got API guidance and application layer interactions on the TODO >> list, and both of these are important and don't show up yet. I can't >> credibly commit to taking a big stab at them, but hopefully this email >> is detailed enough that it serves as a starting point. >> >> The problems with the application layer interaction center around >> 0-RTT and client post-authentication. 0-RTT data is replayable, and >> furthermore does not authenticate SNI or other extensions that might >> affect its interpretation at the server. I smell possible bugs where >> extension data isn't properly treated with 0-RTT vs. 1-RTT fallback: >> the current draft probably should include something like "any >> extensions which influence the interpretation of this data must be the >> same". > > In composing my list of extensions to pay attention when doing 0-RTT > (SNI and ALPN), I considered matters like: > > - Does this seem like it would affect 0-RTT interpretation. > - What are the TLS 1.2 rules on it? > - Is it even meaningful with PSK? > - Is it just low-level connection control? > > ALPN was included because it definitely affects 0-RTT interpretation > (even against TLS 1.2 rules) and SNI because of TLS 1.2 rules (SNI > was later removed from the list). Are we sure this is safe to remove? It probably depends on higher layer protocol semantics. I would suggest that we make 0-RTT per application layer support: each application needs to opt in to 0-RTT, and we should ensure each higher level protocol is aware of the interactions and writes a description of what to do for each extension. Yes, this is hideous and a ton of work. I'm not convinced there is a safe alternative. > > There might be future extensions that do have an effect on 0-RTT > (some proposed extensions to Token Binding perhaps?). And it is of > course theoretically possible that TLS stack implements some extension > in a very odd way. > >> The difference between received 0-RTT data and other data doesn't >> necessarily line up with connection state while processing, as the TLS >> stack could have transitioned to normal 1-RTT operation while 0-RTT >> data is still sitting around waiting to be processed. This is really >> an API problem, but can also be caused by application layer choices: >> if the 0-RTT data can't be cleanly parsed, and some leaks into 1-RTT, >> life gets a bit weird. > > Is "life gets a bit weird" an euphemism for "there will likely be > security issues here"? :-) > > Also, it is very likely that 0-RTT would need its own read API, because > it is pretty unlikely that existing API could be safely retrofitted > or even purpose-built unified API be designed that isn't just asking > for security problems via mixing 0-RTT and 1-RTT data. Yes. In particular I think the TLS state machine transitions need to be ordered with respect to the arrival and sending of data. The challenge for a multithreaded program (yes, some programs have multiple threads sending and receiving at once) is making this make sense, or even a single-threaded program where the TLS stack can change state at times not visible to the sending thread. Maybe there is some slop here, like 0-RTT can become 1-RTT on send, but this raises all sorts of problems for receiving. I think we need to require separation in the API. > > > It gets even more fun in DTLS, where 0-RTT packets can be reordered > after Client Finished, so more 0-RTT data arrives when the connection > has already transitioned to 1-RTT. > > Perhaps the last one could be solved by requiring the library to > discard any such packets and not pass them forward. This is the sanest solution I can think of. When DTLS 1.3 is produced it should be noted. > > >> Post-handshake auth is an ugly one for both. It can complete >> asynchronously with respect to data exchange, which is not what the >> desired semantics usually are. Generally we want each request to have >> a single authentication context. Designing APIs to handle this is >> hard, and applications will have to be aware of how TLS authentication >> works to have rules for it. Add in the ability to stream data in both >> directions, and life gets interesting. I'm really not sure what this >> should look like. > > At least you must have client and server agree on authentication > context of every given request. If they don't, vulernabilities WILL > result. > > And then there have been multiple CVEs due to applications using > wrong authentication context in some situation. > > (This is the reason one needs to be especially careful when combining > dynamic client certificates with HTTP/2... Basically, it can not be > done safely without coordination on application layer). > > One likely wants application protocol to be able to specify part of > or the entiere request context and to extract that part in the other > end when requesting a certificate selection. This is to allow putting > part of coordination data into the request itself. However, this is not > sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at > application layer. > > E.g. HTTP/2 would want to signal which stream triggered the client > certificate request, in order to enable the client to not be completely > dumb in certificate selection. > > And then upon completion of the authentication (either successful or > explicitly rejected), signal the application with the new certificate > chain and the context the request had. This is going to require major changes to APIs and to the HTTP/2 layer. It also interacts with token binding, whee! My question then becomes one of what we actually need: can we assume that leakage between authentication contexts over a single session is safe because all contexts represent the same principal, by restricting the usages, or is this overly restrictive? When we have multiple requests and replies in flight and the authentication state changes, things get nasty. If we think of TLS as sending a stream of events including authentication changes to the application, this fits the semantics of the TLS draft as I understand them to be, but does not necessarily fit what application protocols want. There might be a semantic mismatch here requiring reworking of one or another part. Sincerely, Watson > > > -Ilari -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Oct 7 13:42:47 2016 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 2301D12940F for ; Fri, 7 Oct 2016 13:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 0zJUlEj0-Brx for ; Fri, 7 Oct 2016 13:42:36 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF97129547 for ; Fri, 7 Oct 2016 13:42:29 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id w3so11959804ywg.1 for ; Fri, 07 Oct 2016 13:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g5fgoMpg5hKO0YQFCTArDLYeXCEMSvCD45Y7Yy85IEE=; b=1RC+s+0wBq6TFYJlLVAD7MG590Lecf+t7Oa8bNtxaKrKtGh4PSnkhFBVFRwa67eSrl Z96i4oudeWSpAlyGm1lLSPEdyqZZNRiX/EFU7ukljCD6l+XA/0Cf/8cxsPAaKEME0qNz YyPzmETDouSoA/nGStwmaWK4JfFhGp3WiNU3Xz0STNz6yd8zGCadJbM00FG9sluxcWEo nQHWiNgTVmyu6VVFPYsHS7wgOP6VwwcwJs9ZgYe36WvubyTpPtPFpdFOLtDX2+oA5BbP Kmi0Ddx4H2zEBgf5dY4IVzz457EJJto8mmBPDJ3dOMpwm4o0OjEOsra+4njggbmaZGl/ TFJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g5fgoMpg5hKO0YQFCTArDLYeXCEMSvCD45Y7Yy85IEE=; b=gXAiRivIgJyX9CdAOA5g44JgpxvGbemzRAZ/MKAadCFsIfQ8Xi8kC/FmtiiaxxlqN8 RMKMx0hkD/qg7FnPLoF+1QC0Mob4gWqPCktxIAHkRgXeCatzFMsFzeBh+NqBLzXkCsCy Iu5TqL8dhi/VmX3VNSz/JjaYT+CgmPDCsXavdagS9Fkr5wtjFa/CtVvEjiIiNftHxTQq Vfk9xzKCurI4gSkR0RHpmk+UCQGsfIAjcJ+ofS7eSxGrOMSigmdSLiQQg0XW7haHtbMY z1/EEtsXNL3dzMD9j8er0ttH0LDLGUQNnmU7IOWxE8NwLTezsE6Ny3Vm0P0JNbLsulim KEfQ== X-Gm-Message-State: AA6/9RleF8ZTgczcXZXfmDJTCj4392xTnZaP2qGx031I1M0+lh2ds3f0Gq+MPLI3Ct32bkkRT2k0dxtZEacTbw== X-Received: by 10.129.125.198 with SMTP id y189mr16249536ywc.234.1475872948992; Fri, 07 Oct 2016 13:42:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 13:41:48 -0700 (PDT) In-Reply-To: References: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 7 Oct 2016 13:41:48 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a114926a0dbf387053e4c72a6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Fri, 07 Oct 2016 20:42:41 -0000 --001a114926a0dbf387053e4c72a6 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk wrote: > On 10/07/2016 12:08 PM, Eric Rescorla wrote: > > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > wrote: > >> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: >> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara < >> ilariliusvaara@welho.com> >> > wrote: >> > >> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: >> > > > 4. I've taken a suggestion from David Benjamin to move the >> negotiation >> > > > of the PSK key exchange parameters out of the PSK itself and into a >> > > > separate message. This cleans things up and also lets us drop the >> > > > currently non-useful auth_mode parameter. >> > > >> > > Eeh... From the text, it seems to currently require the kex modes >> > > extension if PSK extension is present. Which seems worse than useless >> > > if the meaning is to get rid of the kex mode parameter from PSK >> > > extension (since you will have the value anyway, but need to dig it >> > > from another extension... Blech). >> > >> > I guess this is a matter of taste, but what convinced me was that: >> > >> > 1. It put all the logic on the server side. >> > > I was going to ask whether this also includes the decision on whether to > send a Certificate to authenticate the server (even for PSK modes), but it > looks like this change is intentionally removing the ability to do PSK > keyex and auth with a certificate? > Yes, while preserving the ability to add it later by adding a PskAuthMode extension parallel to this one. -Ekr > > 2. It removed the auth mod parameter. >> > >> > Maybe david can say more. >> >> I mean if server is to accept PSK, it must now go fishing for another >> extension, check that it is present and pay attention to values there. >> As opposed to having the data in where it is needed. >> > > This is a reasonable argument (and the reason I stuffed the binder here). > However, David's argument was that this applied to *all* PSKs even new > ones. > > > Implementations already have to do some amount of "scan through all > extensions to detect certain things, do some initial processing, and then > finish process everything [else]", not least because SNI can change what > cert types you have, configuration knobs, etc.. So, yes it's bad, but how > bad is it in a relative sense? > > I think there is some value in the client indicating to the server whether > it doesn't want to do psk_dhe (or doesn't want to do pure psk) for future > NSTs, though it's perhaps not of the utmost importance. That property does > support a separate psk_key_exchange_modes extension in preference to > rolling it into pre_shared_keys (as a separate list next to identities and > binders), but it seems to only be a weak argument for separation. I do > think that keeping the psk kex mode orthogonal to the individual keys is > helpful, though. > > Anyway, maybe it's time to bite the bullet and actually write up the > description of the proper procedure for ClientHello processing (scan > extensions for SNI, load up servername-specific config+cert/key, etc.). > Which would make this stuff any prettier, but would at least help people > not get it wrong. > > -Ben > --001a114926a0dbf387053e4c72a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk <bkaduk@akamai.com&= gt; wrote:
=20 =20 =20
On 10/07/2016 12:08 PM, Eric Rescorla wrote:
=20


On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Oct 07, 2016 at 09= :35:40AM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > 4. I've taken a suggestion from David Benjamin to move the negotiation
> > > of the PSK key exchange parameters out of the PSK itself and into a
> > > separate message. This cleans things up and also lets us drop the
> > > currently non-useful auth_mode parameter. > >
> > Eeh... From the text, it seems to currently require the kex modes
> > extension if PSK extension is present. Which seems worse than useless
> > if the meaning is to get rid of the kex mode parameter from PSK
> > extension (since you will have the value anyway, but need to dig it
> > from another extension... Blech).
>
> I guess this is a matter of taste, but what convinced me was that:
>
> 1. It put all the logic on the server side.

 I was going to ask whether this also includes the decision on whether to send a Certificate to authenticate the server (even for PSK modes), but it looks like this change is intentionally removing the ability to do PSK keyex and auth with a certificate?

Yes, while preserving the ability to add it later b= y adding a PskAuthMode extension parallel to this one.

=
-Ekr


> 2. It removed the auth mod parameter.
>
> Maybe david can say more.

I mean if server is to accept PSK, it must now go fishing for another
extension, check that it is present and pay attention to values there.
As opposed to having the data in where it is needed.

This is a reasonable argument (and the reason I stuffed the binder here).
However, David's argument was that this applied to *all* PSKs even new ones.


 Implementations already have to do some amount of "scan through al= l extensions to detect certain things, do some initial processing, and then finish process everything [else]", not least because SNI can change what cert types you have, configuration knobs, etc..=C2=A0 So, y= es it's bad, but how bad is it in a relative sense?

I think there is some value in the client indicating to the server whether it doesn't want to do psk_dhe (or doesn't want to do pu= re psk) for future NSTs, though it's perhaps not of the utmost importance.=C2=A0 That property does support a separate psk_key_exchange_modes extension in preference=C2=A0 to rolling it into pre_shared_keys (as a separate list next to identities and binders), but it seems to only be a weak argument for separation.=C2=A0 I do thin= k that keeping the psk kex mode orthogonal to the individual keys is helpful, though.

Anyway, maybe it's time to bite the bullet and actually write up th= e description of the proper procedure for ClientHello processing (scan extensions for SNI, load up servername-specific config+cert/key, etc.).=C2=A0 Which would make this stuff any prettier, but would at lea= st help people not get it wrong.

-Ben

--001a114926a0dbf387053e4c72a6-- From nobody Fri Oct 7 13:59:33 2016 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 5247E12945F for ; Fri, 7 Oct 2016 13:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QuA7U_BbuVMf for ; Fri, 7 Oct 2016 13:59:30 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AB1129445 for ; Fri, 7 Oct 2016 13:59:30 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id e20so20197476ybb.0 for ; Fri, 07 Oct 2016 13:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OhytrMYkC0NDTV/5fhxvLktam1DhSjFrJrU9xjBYbno=; b=kQ+ATY0Zo0KwmV8Os30+rqDzJVLEnC53g/KNEI4OctbM595rZCbNl4wsfg80bMS4Us VKhx3cKLDngjvvWZ/vZazxtFDHyjhCPexOc9QJM5tawwr4X2NQ+J2r/TDEO/gXwMIsYi 1UA77LcxG5lZCbVNH5QAwCyPoXdn05h5UePgPk/wIQwTEngNctr3xCzncS0V89XHcNAS 5RaJIGj5VvYNeP3ikuAhmPKN/zbpiZ97aV+9BaMa+I8Us6Fr7Nfe0hZ2FfENUhqQId22 MB4YJGL/8PwXGsvSiJgmQUiywq5WL+lSCj9wVuDP3ne0Br0YthJ5PvymWBjEm+rf1+Al UP9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OhytrMYkC0NDTV/5fhxvLktam1DhSjFrJrU9xjBYbno=; b=dDlHA+OVffR88cFjNj/hWJhoZLE9t9sH0jmB9NASFn6vciKoJLOj52iZIQKun5vD2e huaqLRv5X9MLyZbXNCGdzwOO1g8ftGof8QREaSUXjJKxw7/f/VXcr3hnxc0caFS6nODz /b0zVSC77fDPEZXi7rnxRKLWeN6lgIRz8JlQsMUhtgtSm4Llk9ZLCnLAugAnk4yAEhOs LJMy6m2fsAWhPDg8EVW5d3iky6S+x+EFy/c4TEAxZwHp1J5PzInVmAe7s49v+emvwsoW pHaMOE1O40Qjxh1wWhEziVpS/biuuM/ihq3zOH97tpJLshxFKbhYKciZPhf78Ch4Es+/ wisw== X-Gm-Message-State: AA6/9Rmr2hUIvI2f/fpE6/nTpAJ1Nbk6yckHtDF/+oGH4WRUxdLwl6QJfBka7Q8wSd82BhoY2BrsFXbAKBU151Qq X-Received: by 10.37.200.132 with SMTP id y126mr17105070ybf.5.1475873969199; Fri, 07 Oct 2016 13:59:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.7 with HTTP; Fri, 7 Oct 2016 13:59:08 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Fri, 7 Oct 2016 13:59:08 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c054e20ab57fc053e4caf5b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Earlier exporters 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: Fri, 07 Oct 2016 20:59:32 -0000 --94eb2c054e20ab57fc053e4caf5b Content-Type: text/plain; charset=UTF-8 Does the wording of this PR mean that the value from the exporter changes depending on whether it's run before or after exporter_secret can be computed? I think it would be better to keep an RFC 5705-style exporter that remains constant for the connection. The 0-RTT exporter from an API perspective can be a separate thing that a caller has to explicitly choose to use. On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla wrote: > Please see the following PR: > https://github.com/tlswg/tls13-spec/pull/673 > > This includes various changes to make exporters/resumption work better. > > Basically: > 1. Add a 0-RTT exporter and change the transcript for the regular exporter > so it > only includes the transcript up to ServerFinished. This gives it > parity with the > rest of the traffic keys. If we need an exporter with the full > transcript we can > always add it later > > 2. Point out that you can predict ClientFinished for NST when not doing > Client auth. This lets you issue tickets on the server's first flight, > while still > ensuring that if you do client auth you still bind resumption to the > client's > full transcript. > > These are pretty straightforward changes, so absent objections I'll merge > them early next week. > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c054e20ab57fc053e4caf5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Does the wording of this PR mean that the value from the e= xporter changes depending on whether it's run before or after exporter_= secret can be computed? I think it would be better to keep an RFC 5705-styl= e exporter that remains constant for the connection. The 0-RTT exporter fro= m an API perspective can be a separate thing that a caller has to explicitl= y choose to use.

On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
Please see = the following PR:

This includes various changes to= make exporters/resumption work better.

Basically:=
1. Add a 0-RTT exporter and change the transcript for the regula= r exporter so it
=C2=A0 =C2=A0 only includes the transcript up to= ServerFinished. This gives it parity with the
=C2=A0 =C2=A0 rest= of the traffic keys. If we need an exporter with the full transcript we ca= n
=C2=A0 =C2=A0 always add it later

2. P= oint out that you can predict ClientFinished for NST when not doing
=C2=A0 =C2=A0 Client auth. This lets you issue tickets on the serve= r's first flight, while still
=C2=A0 =C2=A0 ensuring th= at if you do client auth you still bind resumption to the client's
=C2=A0 =C2=A0 full transcript.

These are pre= tty straightforward changes, so absent objections I'll merge
= them early next week.

-Ekr


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


--94eb2c054e20ab57fc053e4caf5b-- From nobody Fri Oct 7 14:07:54 2016 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 635211296C8 for ; Fri, 7 Oct 2016 14:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 yDhvjfKEWMGJ for ; Fri, 7 Oct 2016 14:07:50 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AC3129540 for ; Fri, 7 Oct 2016 14:07:50 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t192so19652783ywf.0 for ; Fri, 07 Oct 2016 14:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=taI7KwepRbBRvms8jO8unQyLHdbnh0XbxTEKmMxliKM=; b=e/OnfSMfqxZ4WAxTB/q+hobg4FQ4AkmruwMuhLqBMbcp1kwkA7Egs/NW7EDHu6Ur1O Pt8TAVsP+UxQ/EmdyufIZ3Y7dYOBaRh7545JKfdZXrJb88BHQNez/k5Qxye50ZPYqzgG weLwHxgcUgCYBELBV2t82wNYh0YH9QTlB9nGFYcmK8wjC5wUegA3p4LgCd2jTjMNPXLb k/OhnwgQ4w0FzLp51kpUp8yZH+N2nxoXRd3BIzKiaMR6EMDp0AzkkGko5i/hLr26gar3 Njt+AyqOA58OUxQKvfTDJR+grAenuoye7+CJXjdilFWAOvo4qQmBKQoj+zYFMzt1fh2G 79qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=taI7KwepRbBRvms8jO8unQyLHdbnh0XbxTEKmMxliKM=; b=bgB3ipDr7MxwsJWCkQx7+PY5gHI3hfrhdiwskdHXOmWliNP+FTTVYdCii7+SXJZviI K80n4IftQiqhIsxpIoHvRb0/WNonmikhN6012F+clRTkze/63kuMvN8PUHU+4QJ/j/mF pP8JKG9okoJmniKOtlas1CxAuytBItkRWRwxVYiATUlRAy8zofuDQR5IEsh0bcuVxx30 jfgrKQ9zQP4LsEvWgh991cpmfpxcP2lh5sN8NkwQQ7GoNoThrWHvTSnWyvoNUk1HwnOc rpqZ3RyU+GYCmb3lijKEvHNFK1ulXHNl79NPVKjXjlZ18nU6o0XlrBPLyygm2XdABg+H rjHw== X-Gm-Message-State: AA6/9RlY28D59HDVPkAq1CeGTwqdabinzW3hGGg55g1Q6f6pQ/uWgcwnVD7o4vLvn9RsvDvr2G0dMDicIlEZ5w== X-Received: by 10.129.86.131 with SMTP id k125mr17174326ywb.21.1475874469865; Fri, 07 Oct 2016 14:07:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 14:07:09 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 7 Oct 2016 14:07:09 -0700 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a1143312c82b86f053e4ccdd5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Earlier exporters 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: Fri, 07 Oct 2016 21:07:52 -0000 --001a1143312c82b86f053e4ccdd5 Content-Type: text/plain; charset=UTF-8 I was assuming that there were two exporters: Export() --> the same API as in 1.2 and computed as described here Export0RTT -> A new API that computes the early_exporter. -Ekr On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper wrote: > Does the wording of this PR mean that the value from the exporter changes > depending on whether it's run before or after exporter_secret can be > computed? I think it would be better to keep an RFC 5705-style exporter > that remains constant for the connection. The 0-RTT exporter from an API > perspective can be a separate thing that a caller has to explicitly choose > to use. > > On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla wrote: > >> Please see the following PR: >> https://github.com/tlswg/tls13-spec/pull/673 >> >> This includes various changes to make exporters/resumption work better. >> >> Basically: >> 1. Add a 0-RTT exporter and change the transcript for the regular >> exporter so it >> only includes the transcript up to ServerFinished. This gives it >> parity with the >> rest of the traffic keys. If we need an exporter with the full >> transcript we can >> always add it later >> >> 2. Point out that you can predict ClientFinished for NST when not doing >> Client auth. This lets you issue tickets on the server's first >> flight, while still >> ensuring that if you do client auth you still bind resumption to the >> client's >> full transcript. >> >> These are pretty straightforward changes, so absent objections I'll merge >> them early next week. >> >> -Ekr >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --001a1143312c82b86f053e4ccdd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was assuming that there were two exporters:

Export() --> the same API as in 1.2 and computed as de= scribed here
Export0RTT -> A new API that computes the early_e= xporter.


-Ekr

On Fri, Oct 7, 2016 at 1:59= PM, Nick Harper <nharper@google.com> wrote:
Does the wording of this PR mean that = the value from the exporter changes depending on whether it's run befor= e or after exporter_secret can be computed? I think it would be better to k= eep an RFC 5705-style exporter that remains constant for the connection. Th= e 0-RTT exporter from an API perspective can be a separate thing that a cal= ler has to explicitly choose to use.

On Fri, Oct 7, 2016 at 8:10= AM, Eric Rescorla <ekr@rtfm.com> wrote:
Please s= ee the following PR:

This includes various changes= to make exporters/resumption work better.

Basical= ly:
1. Add a 0-RTT exporter and change the transcript for the reg= ular exporter so it
=C2=A0 =C2=A0 only includes the transcript up= to ServerFinished. This gives it parity with the
=C2=A0 =C2=A0 r= est of the traffic keys. If we need an exporter with the full transcript we= can
=C2=A0 =C2=A0 always add it later

2= . Point out that you can predict ClientFinished for NST when not doing
=C2=A0 =C2=A0 Client auth. This lets you issue tickets on the se= rver's first flight, while still
=C2=A0 =C2=A0 ensuring= that if you do client auth you still bind resumption to the client's
=C2=A0 =C2=A0 full transcript.

These are = pretty straightforward changes, so absent objections I'll merge
them early next week.

-Ekr

=

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



--001a1143312c82b86f053e4ccdd5-- From nobody Fri Oct 7 14:37:50 2016 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 38646129417 for ; Fri, 7 Oct 2016 14:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hMPbQEVz6B1g for ; Fri, 7 Oct 2016 14:37:46 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BED71293EB for ; Fri, 7 Oct 2016 14:37:46 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t192so19970463ywf.0 for ; Fri, 07 Oct 2016 14:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tPdo7CVC85dx0E7sLp5E9hgrgt+G0FLEM5JJ4ZqyPrI=; b=AN/2L1LlTgEzkjCZqPIyLIDQ+BeBT7emHhaJhVYf19DNuRGT8jw3w7LC60rGEYBsQb NeKdcb5NVxRbpaRKj7emMBaSWwI381ohKIFin7SnjpCPXJPNcLxUmGd4BJuxV/elyKJ6 KwAkV4L3XG+6GtQK77koYMhzA4KTkwjGZGQl6reXuqa04oyXfH83WZn1GSGyr/4L+7p6 pdgJtrSP/2FK5OBufIT0XZbWYufCV8pP89QKBiMhzyBhpm17kTLxQPYQ3aTVnXOKDx8F TG3diBfTs7UBYqNCcUGi5dNCt+wRR8J3OHM04CyaCw6p4SrGSQk/ttatVscXfTu8QCxO F+Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tPdo7CVC85dx0E7sLp5E9hgrgt+G0FLEM5JJ4ZqyPrI=; b=XFCQ7EAEUYQt0t1jWHwubXv2sRw8ldPZD1BJLsYyPOcAGaKgpaFchNi1bJuZmfr2mf xOiq4MUgnzV580e/ZUuPrIup8OzNBt1aMbkzBOZUfGIyocSnYQF1/mQr1uuzAaXW+hAl MfIwz8KN3wAx6k5p2mneygX4DtiE3XsCICFRH/yruiuwYZJvbF+dk7LmKMeDqFJZ0nKc M9jKkutRvL40x9y6X7+xUIMW53M0VBGDMZsx9wKoAWOjyBII1k5pTCgj3Ro7rQkXf4oY 8ZwoDNtZ2EnHbPIuML+Zbb1Kt1PXOz0EtTnMe0qevdNlHuN8d5sLCf6PGmPGQg/5ZhHQ vRZQ== X-Gm-Message-State: AA6/9RlJiRo2eMiPx9cBn+JCkKQNyepZLDCECS8y+liwPHwoy9a3Mariyi+GPweMUixCQiw/trpHKgYxD2z2TXU0 X-Received: by 10.129.53.206 with SMTP id c197mr16784625ywa.205.1475876265241; Fri, 07 Oct 2016 14:37:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.7 with HTTP; Fri, 7 Oct 2016 14:37:24 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Fri, 7 Oct 2016 14:37:24 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11421a268627ab053e4d38d9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Earlier exporters 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: Fri, 07 Oct 2016 21:37:48 -0000 --001a11421a268627ab053e4d38d9 Content-Type: text/plain; charset=UTF-8 That's my assumption as well. On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla wrote: > I was assuming that there were two exporters: > > Export() --> the same API as in 1.2 and computed as described here > Export0RTT -> A new API that computes the early_exporter. > > > -Ekr > > On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper wrote: > >> Does the wording of this PR mean that the value from the exporter changes >> depending on whether it's run before or after exporter_secret can be >> computed? I think it would be better to keep an RFC 5705-style exporter >> that remains constant for the connection. The 0-RTT exporter from an API >> perspective can be a separate thing that a caller has to explicitly choose >> to use. >> >> On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla wrote: >> >>> Please see the following PR: >>> https://github.com/tlswg/tls13-spec/pull/673 >>> >>> This includes various changes to make exporters/resumption work better. >>> >>> Basically: >>> 1. Add a 0-RTT exporter and change the transcript for the regular >>> exporter so it >>> only includes the transcript up to ServerFinished. This gives it >>> parity with the >>> rest of the traffic keys. If we need an exporter with the full >>> transcript we can >>> always add it later >>> >>> 2. Point out that you can predict ClientFinished for NST when not doing >>> Client auth. This lets you issue tickets on the server's first >>> flight, while still >>> ensuring that if you do client auth you still bind resumption to the >>> client's >>> full transcript. >>> >>> These are pretty straightforward changes, so absent objections I'll merge >>> them early next week. >>> >>> -Ekr >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > --001a11421a268627ab053e4d38d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's my assumption as well.

On Fri, Oct 7, 2016 at 2:07 PM, Eric= Rescorla <ekr@rtfm.com> wrote:
I was assuming that there were two exporters:
<= div>
Export() --> the same API as in 1.2 and computed as d= escribed here
Export0RTT -> A new API that computes the early_= exporter.


-Ekr

On F= ri, Oct 7, 2016 at 1:59 PM, Nick Harper <nharper@google.com> wrote:
Does the wordin= g of this PR mean that the value from the exporter changes depending on whe= ther it's run before or after exporter_secret can be computed? I think = it would be better to keep an RFC 5705-style exporter that remains constant= for the connection. The 0-RTT exporter from an API perspective can be a se= parate thing that a caller has to explicitly choose to use.

On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= div class=3D"m_-6907689978470548408h5">
Please see the= following PR:

This includes various changes to ma= ke exporters/resumption work better.

Basically:
1. Add a 0-RTT exporter and change the transcript for the regular e= xporter so it
=C2=A0 =C2=A0 only includes the transcript up to Se= rverFinished. This gives it parity with the
=C2=A0 =C2=A0 rest of= the traffic keys. If we need an exporter with the full transcript we can
=C2=A0 =C2=A0 always add it later

2. Poin= t out that you can predict ClientFinished for NST when not doing
=
=C2=A0 =C2=A0 Client auth. This lets you issue tickets on the server&#= 39;s first flight, while still
=C2=A0 =C2=A0 ensuring that = if you do client auth you still bind resumption to the client's
=C2=A0 =C2=A0 full transcript.

These are pretty= straightforward changes, so absent objections I'll merge
the= m early next week.

-Ekr


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




--001a11421a268627ab053e4d38d9-- From nobody Fri Oct 7 14:45:37 2016 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 815CE129459 for ; Fri, 7 Oct 2016 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 H9hcrzN5fYzx for ; Fri, 7 Oct 2016 14:45:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id BCDFB12943F for ; Fri, 7 Oct 2016 14:45:32 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D5E8E43347D; Fri, 7 Oct 2016 21:45:31 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4B404433455; Fri, 7 Oct 2016 21:45:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1475876731; bh=xKzRaw8X3up7SaC6cySEqKqXKsv5BMq45ZmUQTuZZ8Y=; l=4265; h=To:References:Cc:From:Date:In-Reply-To:From; b=PaW2WW7lVqYB+mCq5IXgCp556jEbAMLkDVV8Hy7XSYbW183GlpMjbBHTXcuPTiv+s 45jYGmQnI94jGozgdC7dowb+YKzzI9jNZIEvmC45CkmDHXVN77nyDlan7hteCLouE6 PJjevEKTo29pjp/s4DXmYg/yES+0kMI5kD4WHqm8= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 07FD81FC8E; Fri, 7 Oct 2016 21:45:30 +0000 (GMT) To: Filippo Valsorda , tls@ietf.org References: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com> From: Benjamin Kaduk Message-ID: <82f39c83-0040-cf87-94ae-16c321eecc95@akamai.com> Date: Fri, 7 Oct 2016 16:45:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------742B4CA1488D1CBB3358AEED" Archived-At: Cc: filippo@cloudflare.com, aaspring@umich.edu Subject: Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo 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: Fri, 07 Oct 2016 21:45:35 -0000 This is a multi-part message in MIME format. --------------742B4CA1488D1CBB3358AEED Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/07/2016 11:57 AM, Filippo Valsorda wrote: > Hello, > > Cloudflare's current (not definitive) plan for 0-RTT is essentially to > decide whether or not to answer to requests in the 0.5 flight on a > case-by-case basis. That obviously requires reading all of them and > caching the ones we don't want to answer. > > To mitigate the obvious DoS concern we plan to use the ticket age and a > per-machine replay cache. > > However, chatting with Drew (cc'd) we realized that clients could still > send huge amounts of 0-RTT data that we would have to buffer. Once a Well, "have to" is perhaps a bit of a stretch; the client should be prepared to cope reasonably if you abort the connection arbitrarily. > client sent early data, there's no way to accept only a part of it or to > verify that the client is not replaying before reading it all. But if we > were to close the connection after a given amount of data we risk > failing connections from legal clients. > > I propose to add a field max_early_data_size to TicketEarlyDataInfo, to > inform clients about the maximum amount of 0-RTT data they are allowed > to send, allowing servers to safely terminate connections that exceed > it. But this seems like a good idea; I left a couple of ~editorial notes on github. -Ben > https://github.com/tlswg/tls13-spec/pull/674 > > [Please keep me in the CC of replies] > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------742B4CA1488D1CBB3358AEED Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/07/2016 11:57 AM, Filippo Valsorda wrote:
Hello,

Cloudflare's current (not definitive) plan for 0-RTT is essentially to
decide whether or not to answer to requests in the 0.5 flight on a
case-by-case basis. That obviously requires reading all of them and
caching the ones we don't want to answer.

To mitigate the obvious DoS concern we plan to use the ticket age and a
per-machine replay cache.

However, chatting with Drew (cc'd) we realized that clients could still
send huge amounts of 0-RTT data that we would have to buffer. Once a

Well, "have to" is perhaps a bit of a stretch; the client should be prepared to cope reasonably if you abort the connection arbitrarily.

client sent early data, there's no way to accept only a part of it or to
verify that the client is not replaying before reading it all. But if we
were to close the connection after a given amount of data we risk
failing connections from legal clients.

I propose to add a field max_early_data_size to TicketEarlyDataInfo, to
inform clients about the maximum amount of 0-RTT data they are allowed
to send, allowing servers to safely terminate connections that exceed
it.

But this seems like a good idea; I left a couple of ~editorial notes on github.

-Ben

https://github.com/tlswg/tls13-spec/pull/674

[Please keep me in the CC of replies]

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

--------------742B4CA1488D1CBB3358AEED-- From nobody Fri Oct 7 14:45:52 2016 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 62A8D129473 for ; Fri, 7 Oct 2016 14:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 gihQ7iO6fYtx for ; Fri, 7 Oct 2016 14:45:39 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB328129434 for ; Fri, 7 Oct 2016 14:45:39 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id 184so20443419yby.2 for ; Fri, 07 Oct 2016 14:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nnik3ThQ7u6faPwbR0jbDLa+NKP33UlFJcIuJ9DBSsk=; b=U7SBlFBSOJH2z6gdpXqe+wZ1zocnZhe94v3/TeWz+lksKZX8K7sLEpStMHESTJHA8F CrPEfzUZRInvhBY4sau/sO6wWRbm5e1KP6G/lHKPx5tUE92y04PEh4nz6GT3ukqWMjFs B+eZ6+pwQ6q88C16hqMCnIqoYDRN5IkriNymLPX+dXUCxQNv1SGkO2TRJ2KChi6sS6w1 lq61frYXch+L+NOITugies3qysjXvtTBgkhdsew45GMh+XyTQoJ4iiqNBnZ4MJv1kkqc qkaM/qDDW8TaPpU4SNauvSgMEFof5QajBRwHH/5dQ/GNG39lfbDuJhDz7L40AXmzu8D6 eV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nnik3ThQ7u6faPwbR0jbDLa+NKP33UlFJcIuJ9DBSsk=; b=cJYAfEAXXgdZevqC2Phw7LcFLFd0JEmxgikasUaMiTof3S/mXeAEHBDFeJ7BVgXlmh +4d+evlf3VSF0TR+1bUqwbjNNsm7ni60wvGvANPtIBArvVMLYusKmELVzvzRVEdP7kFw pbBnUC7npGmaFM6Vv6sPkvj50/RvG6LGfzxiU0pMmXw7QTL2qyjdfQ+BjbvYoa5cCCpA rTwG1P1qWQUUQw/e0oWLBM+hZSvEUSczFQM+0F5cdnP+iUtPXMNJ2ERh4a8U9a3sqPZz j/gvIre3vOATJy98ZIr3x6TEfwj4jgCe11L97YLp+bpwTDgTmilDgnOscEF1UiEuwPTP d3Gw== X-Gm-Message-State: AA6/9RkY3zoB2sYLEWCZXYqgiiRK/MrbXS1QAWDTkuXbf2OQC+G1CqJiU64PVFbY3buKCyPLjo2cKi9NINPJ5Q== X-Received: by 10.37.65.142 with SMTP id o136mr16625199yba.65.1475876739018; Fri, 07 Oct 2016 14:45:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 14:44:58 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 7 Oct 2016 14:44:58 -0700 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a11c019aac34314053e4d5421 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Earlier exporters 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: Fri, 07 Oct 2016 21:45:51 -0000 --001a11c019aac34314053e4d5421 Content-Type: text/plain; charset=UTF-8 Good. I will try to clarify. PRs welcome On Fri, Oct 7, 2016 at 2:37 PM, Nick Harper wrote: > That's my assumption as well. > > On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla wrote: > >> I was assuming that there were two exporters: >> >> Export() --> the same API as in 1.2 and computed as described here >> Export0RTT -> A new API that computes the early_exporter. >> >> >> -Ekr >> >> On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper wrote: >> >>> Does the wording of this PR mean that the value from the exporter >>> changes depending on whether it's run before or after exporter_secret can >>> be computed? I think it would be better to keep an RFC 5705-style exporter >>> that remains constant for the connection. The 0-RTT exporter from an API >>> perspective can be a separate thing that a caller has to explicitly choose >>> to use. >>> >>> On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla wrote: >>> >>>> Please see the following PR: >>>> https://github.com/tlswg/tls13-spec/pull/673 >>>> >>>> This includes various changes to make exporters/resumption work better. >>>> >>>> Basically: >>>> 1. Add a 0-RTT exporter and change the transcript for the regular >>>> exporter so it >>>> only includes the transcript up to ServerFinished. This gives it >>>> parity with the >>>> rest of the traffic keys. If we need an exporter with the full >>>> transcript we can >>>> always add it later >>>> >>>> 2. Point out that you can predict ClientFinished for NST when not doing >>>> Client auth. This lets you issue tickets on the server's first >>>> flight, while still >>>> ensuring that if you do client auth you still bind resumption to >>>> the client's >>>> full transcript. >>>> >>>> These are pretty straightforward changes, so absent objections I'll >>>> merge >>>> them early next week. >>>> >>>> -Ekr >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>> >> > --001a11c019aac34314053e4d5421 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good. I will try to clarify. PRs welcome

On Fri, Oct 7, 2016 at 2:37= PM, Nick Harper <nharper@google.com> wrote:
That's my assumption as well.

On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla <ekr@rtfm= .com> wrote:
I was assuming that there were two exporters:

<= div>Export() --> the same API as in 1.2 and computed as described here
Export0RTT -> A new API that computes the early_exporter.
=


-Ekr

On Fri, Oct 7, 2016 at 1:59 PM, = Nick Harper <nharper@google.com> wrote:
Does the wording of this PR mean that the v= alue from the exporter changes depending on whether it's run before or = after exporter_secret can be computed? I think it would be better to keep a= n RFC 5705-style exporter that remains constant for the connection. The 0-R= TT exporter from an API perspective can be a separate thing that a caller h= as to explicitly choose to use.

On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla= <ek= r@rtfm.com> wrote:
Please see the following PR:
=
This includes various changes to make exporters/resumption w= ork better.

Basically:
1. Add a 0-RTT ex= porter and change the transcript for the regular exporter so it
= =C2=A0 =C2=A0 only includes the transcript up to ServerFinished. This gives= it parity with the
=C2=A0 =C2=A0 rest of the traffic keys. If we= need an exporter with the full transcript we can
=C2=A0 =C2=A0 a= lways add it later

2. Point out that you can predi= ct ClientFinished for NST when not doing
=C2=A0 =C2=A0 Clien= t auth. This lets you issue tickets on the server's first flight, while= still
=C2=A0 =C2=A0 ensuring that if you do client auth yo= u still bind resumption to the client's
=C2=A0 =C2=A0 full tr= anscript.

These are pretty straightforward changes= , so absent objections I'll merge
them early next week.
=

-Ekr


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





--001a11c019aac34314053e4d5421-- From nobody Fri Oct 7 15:00:41 2016 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 41AE3129418 for ; Fri, 7 Oct 2016 15:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 yw_yVwiflwNf for ; Fri, 7 Oct 2016 15:00:37 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id C149D129431 for ; Fri, 7 Oct 2016 15:00:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 17BE713229; Sat, 8 Oct 2016 01:00:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id J4Q8b-gmMF2D; Sat, 8 Oct 2016 01:00:34 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 84EF2C4; Sat, 8 Oct 2016 01:00:34 +0300 (EEST) Date: Sat, 8 Oct 2016 01:00:28 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Fri, 07 Oct 2016 22:00:40 -0000 On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > wrote: > > > > Also, it is very likely that 0-RTT would need its own read API, because > > it is pretty unlikely that existing API could be safely retrofitted > > or even purpose-built unified API be designed that isn't just asking > > for security problems via mixing 0-RTT and 1-RTT data. > > Yes. In particular I think the TLS state machine transitions need to > be ordered with respect to the arrival and sending of data. The > challenge for a multithreaded program (yes, some programs have > multiple threads sending and receiving at once) is making this make > sense, or even a single-threaded program where the TLS stack can > change state at times not visible to the sending thread. Maybe there > is some slop here, like 0-RTT can become 1-RTT on send, but this > raises all sorts of problems for receiving. I think we need to require > separation in the API. 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- retransmit, which needs to be disableable, as sometimes that just plain won't work). This impiles that the application always needs to explicitly signal the end of 0-RTT data, even just to abort sending it. > > (This is the reason one needs to be especially careful when combining > > dynamic client certificates with HTTP/2... Basically, it can not be > > done safely without coordination on application layer). > > > > One likely wants application protocol to be able to specify part of > > or the entiere request context and to extract that part in the other > > end when requesting a certificate selection. This is to allow putting > > part of coordination data into the request itself. However, this is not > > sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at > > application layer. > > > > And then upon completion of the authentication (either successful or > > explicitly rejected), signal the application with the new certificate > > chain and the context the request had. > > This is going to require major changes to APIs and to the HTTP/2 > layer. It also interacts with token binding, whee! My question then > becomes one of what we actually need: can we assume that leakage > between authentication contexts over a single session is safe because > all contexts represent the same principal, by restricting the usages, > or is this overly restrictive? Yes, it is going to reuqire such changes. And you absolutely can not assume that all contexts present the same principal. And as I said, in multiplexed protocol like HTTP/2, you need application- level coordination on top. TLS just can't do that. > When we have multiple requests and replies in flight and the > authentication state changes, things get nasty. If we think of TLS as > sending a stream of events including authentication changes to the > application, this fits the semantics of the TLS draft as I understand > them to be, but does not necessarily fit what application protocols > want. There might be a semantic mismatch here requiring reworking of > one or another part. Also, some applications presumably want the events done synchronously, so they don't move with data reads. Basically, post-handshake auth is heckuva nasty problem. -Ilari From nobody Fri Oct 7 15:05:00 2016 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 91A8412946A for ; Fri, 7 Oct 2016 15:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 BrhJjYp-5CCl for ; Fri, 7 Oct 2016 15:04:56 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04368129431 for ; Fri, 7 Oct 2016 15:04:56 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id 191so20537358ybv.3 for ; Fri, 07 Oct 2016 15:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=alhqZgBF9ulCAzVakJlMiIC7NKZeQsPLRob44WDIJJU=; b=wi9Uqt6xGBZ7YgEk22kHX015vOpWJlyIfl6IAR3GfdBMYHmWpo1RNEhyb3RREe4rVY tu5df1UsRm68WrSNN25pQLKV5CKX2Jn8j/ppmifDgeHqopg5a0cVdvMVJYBgMqIjHVqH AW6M6+j3sCaSY5OTtfi3OXK4ndwUWq5Wzmcy/2dZmFC0Eh3ZJ7vCgLQcXxqI9+x2D4yG FpCeTKM4zq63LAJmufU4c5sZbUGbaIrRrNgR6a+fSxK5UDKKlwWXy9VU6mejoxINEps7 c0ygGQhGdO4/UftYmGpkemVwCpkHLwmb/UiNXaoLE4SLKjkxzVL1A2D27QnoTBhTQTmT yKfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=alhqZgBF9ulCAzVakJlMiIC7NKZeQsPLRob44WDIJJU=; b=IQC9fdyQl30TKSL9FsjguCLelW4xF35PdZhn0SSIP7zVFeboxev0OQvIKaB4ZWpXgu L+h6/1+gGxYoPSY0J9lAu6OvCGsP24G9eEKk1Iyk7Uk+oTl+0p02UVWkrEFYIHiBGWRg 8VbRPJoU4ZpR4Uwt1WzdtAG2fhyz4Cxa/En4YB6hAqOnPYD8hgmSfIqns8CR5CAtMAcT VtNCb4fqxpNKniqlzZpF+FZ3bTQzfxp1PQtkwGj+XiVXrsBr9db0hMfKQc+co4c3R/s1 YsLBFpDrVQgH7HRWLD2ctjqBvwfjSUtkDEsdzrVHyecq+8mItcd6RGXJh8P6G/edU002 KXmw== X-Gm-Message-State: AA6/9Rl3yFVHRAxxyYE5jgxlZxJTnmLaaE5ZR5cgSwXob1aWLs1Jum/UfT+vaaBBXDKxlWhyqCgvGOZmTlEnzg== X-Received: by 10.37.103.139 with SMTP id b133mr18085654ybc.107.1475877895187; Fri, 07 Oct 2016 15:04:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 15:04:14 -0700 (PDT) In-Reply-To: <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 7 Oct 2016 15:04:14 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1142f87aad066b053e4d9990 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Fri, 07 Oct 2016 22:04:58 -0000 --001a1142f87aad066b053e4d9990 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara wrote: > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > > wrote: > > > > > > Also, it is very likely that 0-RTT would need its own read API, because > > > it is pretty unlikely that existing API could be safely retrofitted > > > or even purpose-built unified API be designed that isn't just asking > > > for security problems via mixing 0-RTT and 1-RTT data. > > > > Yes. In particular I think the TLS state machine transitions need to > > be ordered with respect to the arrival and sending of data. The > > challenge for a multithreaded program (yes, some programs have > > multiple threads sending and receiving at once) is making this make > > sense, or even a single-threaded program where the TLS stack can > > change state at times not visible to the sending thread. Maybe there > > is some slop here, like 0-RTT can become 1-RTT on send, but this > > raises all sorts of problems for receiving. I think we need to require > > separation in the API. > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- > retransmit, which needs to be disableable, as sometimes that just plain > won't work). > Can you explain why that is? -Ekr This impiles that the application always needs to explicitly signal > the end of 0-RTT data, even just to abort sending it. > > > > (This is the reason one needs to be especially careful when combining > > > dynamic client certificates with HTTP/2... Basically, it can not be > > > done safely without coordination on application layer). > > > > > > One likely wants application protocol to be able to specify part of > > > or the entiere request context and to extract that part in the other > > > end when requesting a certificate selection. This is to allow putting > > > part of coordination data into the request itself. However, this is not > > > sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at > > > application layer. > > > > > > And then upon completion of the authentication (either successful or > > > explicitly rejected), signal the application with the new certificate > > > chain and the context the request had. > > > > This is going to require major changes to APIs and to the HTTP/2 > > layer. It also interacts with token binding, whee! My question then > > becomes one of what we actually need: can we assume that leakage > > between authentication contexts over a single session is safe because > > all contexts represent the same principal, by restricting the usages, > > or is this overly restrictive? > > Yes, it is going to reuqire such changes. > > And you absolutely can not assume that all contexts present the same > principal. > > And as I said, in multiplexed protocol like HTTP/2, you need application- > level coordination on top. TLS just can't do that. > > > When we have multiple requests and replies in flight and the > > authentication state changes, things get nasty. If we think of TLS as > > sending a stream of events including authentication changes to the > > application, this fits the semantics of the TLS draft as I understand > > them to be, but does not necessarily fit what application protocols > > want. There might be a semantic mismatch here requiring reworking of > > one or another part. > > Also, some applications presumably want the events done synchronously, > so they don't move with data reads. > > > Basically, post-handshake auth is heckuva nasty problem. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1142f87aad066b053e4d9990 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
> <ilariliusvaara@welho.c= om> wrote:
> >
> > Also, it is very likely that 0-RTT would = need its own read API, because
> > it is pretty unlikely that existing API could be safely retrofitt= ed
> > or even purpose-built unified API be designed that isn't just= asking
> > for security problems via mixing 0-RTT and 1-RTT data.
>
> Yes. In particular I think the TLS state machine transitions need to > be ordered with respect to the arrival and sending of data. The
> challenge for a multithreaded program (yes, some programs have
> multiple threads sending and receiving at once) is making this make > sense, or even a single-threaded program where the TLS stack can
> change state at times not visible to the sending thread. Maybe there > is some slop here, like 0-RTT can become 1-RTT on send, but this
> raises all sorts of problems for receiving. I think we need to require=
> separation in the API.

0-RTT can't be allowed to become 1-RTT on send (unless it is aut= o-
retransmit, which needs to be disableable, as sometimes that just plain
won't work).

Can you explain why th= at is?

-Ekr



This impiles that the application always needs to explicitly signal
the end of 0-RTT data, even just to abort sending it.

> > (This is the reason one needs to be especially careful when combi= ning
> > dynamic client certificates with HTTP/2... Basically, it can not = be
> > done safely without coordination on application layer).
> >
> > One likely wants application protocol to be able to specify part = of
> > or the entiere request context and to extract that part in the ot= her
> > end when requesting a certificate selection. This is to allow put= ting
> > part of coordination data into the request itself. However, this = is not
> > sufficient for e.g. HTTP/2 signaling, so more needs to be exchang= ed at
> > application layer.
> >
> > And then upon completion of the authentic= ation (either successful or
> > explicitly rejected), signal the application with the new certifi= cate
> > chain and the context the request had.
>
> This is going to require major changes to APIs and to the HTTP/2
> layer. It also interacts with token binding, whee! My question then > becomes one of what we actually need: can we assume that leakage
> between authentication contexts over a single session is safe because<= br> > all contexts represent the same principal, by restricting the usages,<= br> > or is this overly restrictive?

Yes, it is going to reuqire such changes.

And you absolutely can not assume that all contexts present the same
principal.

And as I said, in multiplexed protocol like HTTP/2, you need application- level coordination on top. TLS just can't do that.

> When we have multiple requests and replies in flight and the
> authentication state changes, things get nasty. If we think of TLS as<= br> > sending a stream of events including authentication changes to the
> application, this fits the semantics of the TLS draft as I understand<= br> > them to be, but does not necessarily fit what application protocols > want. There might be a semantic mismatch here requiring reworking of > one or another part.

Also, some applications presumably want the events done synchronousl= y,
so they don't move with data reads.


Basically, post-handshake auth is heckuva nasty problem.


-Ilari

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

--001a1142f87aad066b053e4d9990-- From nobody Fri Oct 7 15:06:50 2016 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 C2893128E19 for ; Fri, 7 Oct 2016 15:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.995 X-Spam-Level: X-Spam-Status: No, score=-4.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 Rmak-knmBbZZ for ; Fri, 7 Oct 2016 15:06:46 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D31129431 for ; Fri, 7 Oct 2016 15:06:46 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id z65so20496282itc.0 for ; Fri, 07 Oct 2016 15:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=czwPt+bakc0o3rv2CTWt6C9vyA8eelgF6NWq1w9y4SI=; b=FN8gpu4oDm8hLDmSu4WH0UMsLEK7saK6c3Bh11SKCVXa3RPB1TjSbdf9ANCt6CgPLu uUdea8jp4+Jgu9nd110FeytGjp/LcL3NjCrmzdoPKT/N/6CdPjsItPV7AiC+yTG8GfOs P77HtOReyQKmoz5I5H9Qqo1yDMXjhCjR2+EEU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=czwPt+bakc0o3rv2CTWt6C9vyA8eelgF6NWq1w9y4SI=; b=YhhD2SRInbvNcooEYn5OdHtIZCUBwU6p08T/HdSwrPDOotTzjvPMNu0YyXMiR6YttO Jr1a7BbOS+LQTIS/8cHGFoDZpv9Oby1sv9onGLAldEubQWAGa5AWp//+7QSY8FsN1QAv 8nTGPS1MMCMHCuWGPUsqv/wZaw1bob1z7jOJN0UtJxKEPwTVSB+hI+oHJdblYCtF1o8a yX1p/fldfnUIEQPlyNEUF/H1do5EJ1dK0tOhC4A+0eo1kM3/mtm4o/xcXAS2MJdeHh/k NGWY6V2IThB2JN8NZVZb9fcW9mij0KGLFFMh69+v7Bmh87fnUxtAuhMpUyy/np9tgj2K 3qLw== X-Gm-Message-State: AA6/9Rl7nbLf2452qymzM+xjzieSrUVLMFMzzJQVqn1T57V5AeHlq5LQtBScPefIT4jmDji7Q/Q2JAnFKU/vQnL9 X-Received: by 10.36.20.9 with SMTP id 9mr931122itg.24.1475878005715; Fri, 07 Oct 2016 15:06:45 -0700 (PDT) MIME-Version: 1.0 References: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com> <82f39c83-0040-cf87-94ae-16c321eecc95@akamai.com> In-Reply-To: <82f39c83-0040-cf87-94ae-16c321eecc95@akamai.com> From: David Benjamin Date: Fri, 07 Oct 2016 22:06:35 +0000 Message-ID: To: Benjamin Kaduk , Filippo Valsorda , tls@ietf.org Content-Type: multipart/alternative; boundary=001a11446af84386fc053e4da058 Archived-At: Cc: filippo@cloudflare.com, aaspring@umich.edu Subject: Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo 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: Fri, 07 Oct 2016 22:06:49 -0000 --001a11446af84386fc053e4da058 Content-Type: text/plain; charset=UTF-8 We were also expecting to want to bound how much traffic a server could be compelled to skip over without making progress. It actually didn't occur to me we could let the client know the bounds, rather than just making up a conservative bound (there's only so much data you can get into an RTT) and hoping nothing breaks. That's a good idea. Units is a little interesting. For those purposes, this limit would kick in whether or not the early data could be decrypted, so the server-side limit would be measured in ciphertext, possibly even including record headers. (Although any inaccuracies in converting could be done by just advertising an underestimate and breaking peers that send pathologically silly things like all one-byte records. So it doesn't matter much.) On Fri, Oct 7, 2016 at 5:45 PM Benjamin Kaduk wrote: On 10/07/2016 11:57 AM, Filippo Valsorda wrote: Hello, Cloudflare's current (not definitive) plan for 0-RTT is essentially to decide whether or not to answer to requests in the 0.5 flight on a case-by-case basis. That obviously requires reading all of them and caching the ones we don't want to answer. To mitigate the obvious DoS concern we plan to use the ticket age and a per-machine replay cache. However, chatting with Drew (cc'd) we realized that clients could still send huge amounts of 0-RTT data that we would have to buffer. Once a Well, "have to" is perhaps a bit of a stretch; the client should be prepared to cope reasonably if you abort the connection arbitrarily. I think the concern is that a well-meaning client may not necessarily do a retry here and instead read this even as a network error. And if it did, the next attempt, if there is still a 0-RTT-able ticket available, may hit this again anyway... client sent early data, there's no way to accept only a part of it or to verify that the client is not replaying before reading it all. But if we were to close the connection after a given amount of data we risk failing connections from legal clients. I propose to add a field max_early_data_size to TicketEarlyDataInfo, to inform clients about the maximum amount of 0-RTT data they are allowed to send, allowing servers to safely terminate connections that exceed it. But this seems like a good idea; I left a couple of ~editorial notes on github. -Ben https://github.com/tlswg/tls13-spec/pull/674 [Please keep me in the CC of replies] _______________________________________________ TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a11446af84386fc053e4da058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We were also expectin= g to want to bound how much traffic a server could be compelled to skip ove= r without making progress. It actually didn't occur to me we could let = the client know the bounds, rather than just making up a conservative bound= (there's only so much data you can get into an RTT) and hoping nothing= breaks. That's a good idea.

Units is a little interesting. For tho= se purposes, this limit would kick in whether or not the early data could b= e decrypted, so the server-side limit would be measured in ciphertext, poss= ibly even including record headers. (Although any inaccuracies in convertin= g could be done by just advertising an underestimate and breaking peers tha= t send pathologically silly things like all one-byte records. So it doesn&#= 39;t matter much.)

On Fri, Oct 7, 2016 at 5:45 PM = Benjamin Kaduk <bkaduk@akamai.com> wrote:
=
On 10/07/2016 11:57 AM, Filippo Valsorda wrote:
Hello,

Cloudflare's current (not definitive) plan for 0-RTT is essentially to
decide whether or not to answer to requests in the 0.5 flight on a
case-by-case basis. That obviously requires reading all of them and
caching the ones we don't want to answer.

To mitigate the obvious DoS concern we plan to use the ticket age and a
per-machine replay cache.

However, chatting with Drew (cc'd) we realized that clients could still
send huge amounts of 0-RTT data that we would have to buffer. Once a

Well, "have to" is perhaps a bit of a stretch; the client sho= uld be prepared to cope reasonably if you abort the connection arbitrarily.

I think the concern is that a well-meaning client may no= t necessarily do a retry here and instead read this even as a network error= . And if it did, the next attempt, if there is still a 0-RTT-able ticket av= ailable, may hit this again anyway...

client sent early data, there's no way t=
o accept only a part of it or to
verify that the client is not replaying before reading it all. But if we
were to close the connection after a given amount of data we risk
failing connections from legal clients.

I propose to add a field max_early_data_size to TicketEarlyDataInfo, to
inform clients about the maximum amount of 0-RTT data they are allowed
to send, allowing servers to safely terminate connections that exceed
it.

But this seems like a good idea; I left a couple of ~editorial notes on github.

-Ben


https://github.com/tlswg/tls13-spec=
/pull/674

[Please keep me in the CC of replies]

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

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a11446af84386fc053e4da058-- From nobody Fri Oct 7 18:03:36 2016 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 640401294E5 for ; Fri, 7 Oct 2016 18:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ktcP1yI9SpXP for ; Fri, 7 Oct 2016 18:03:33 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A691294DC for ; Fri, 7 Oct 2016 18:03:33 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id z65so23182981itc.0 for ; Fri, 07 Oct 2016 18:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=vOSSX38rrQ6ayJCwS+tNXtrjkfSsTiEiB55r+bYeNQw=; b=TKedctue7c7xGBEbnOrbwxnu4p0goGEcoPzA+4dekWcOaJePbauRIm0sC5v+QiW0sq lphpcmfWJvfkQ5BmKMb2c33JKaYz3kfcp2Lr21oqVGoTOm6Ey8Gajbax0Z2aXUkoE6R/ VHy2qFnwBQllGfU4+CwtRhtaX6/7Kjcs8psciW/qSQT5lfWda7vB/Q+MlYhKySfPOUP1 S+s4ZSuWZ3VCHLE9uvAt/FPlNLu6cEvO+b0dfvKYKftdM7b5mEe7QGfCueHzw+sLDkys KtGrmeXUk2O5Nq60D5EzI9ddlBzM/JzwYpWVQNtLBDQ8o7UwDCww6eqQWGpZdv5ho/HG 5LAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vOSSX38rrQ6ayJCwS+tNXtrjkfSsTiEiB55r+bYeNQw=; b=OHb0FTkEV12tcD/lmtYwjsy+d3CRziAFg6eGpxMRRD1Yk/f6sOJFXWhobSMhqyAjPp J1JXznLaI/USCX4GUTGysD8HJCTM40cFSb63vpryKjiwjO0a9+eEKtjsaMp8eE9edoVS Yx/STICOY+vfbrEugz/gkv8JF77z0+65qIc39OWygrUMprMsM596NFHmhCJXuUUGiPye TgZ4IG3IT8G7sYILfbFpeP7oT3tnQzLUvDe41MM+7iOBMh0e82m/ocad+1V/ry6GmRUL IxTHWxujamD4mBt9vaVV9Mpb1uz/pEJ0N3Idqc1v2fQUeva1haQ3X4nRudRfunWJD0hT x+3w== X-Gm-Message-State: AA6/9RlYXdZsfIyoyFt8cGE31nr9V8479c/EOifOCyQ2p5D/QiZ6MTBY1SKgQoWYbn+vbWXlZbmbH7jmJtaVRA== X-Received: by 10.36.54.67 with SMTP id l64mr1321799itl.69.1475888612634; Fri, 07 Oct 2016 18:03:32 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Sat, 08 Oct 2016 01:03:21 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1143d2f07bf7de053e50189e Archived-At: Subject: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Sat, 08 Oct 2016 01:03:35 -0000 --001a1143d2f07bf7de053e50189e Content-Type: text/plain; charset=UTF-8 There has been a lot of discussion lately about post-handshake messages that do not contain application data and how to handle them. This PR is an attempt to make the story more explicit by adding a new post_handshake extension to TLS 1.3. Supporting all types of post-handshake messages can require extra complexity and logic, even when the features that these messages enable are not needed. Some types of connections/implementations don't need to support key updates (some unidirectional connections), session tickets (pure PSK implementations) and post-handshake client auth (most browsers). These are all currently SHOULDs in the spec and they don't need to be. In order to simplify the logic around dealing with post-handshake messages, this proposal makes support for each of these modes explicit via a new handshake extension. This change also makes the path to introducing other types of post-handshake messages in future drafts more explicit. PR: https://github.com/tlswg/tls13-spec/pull/676 Nick --001a1143d2f07bf7de053e50189e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There has been a lot of discussion lately about post-= handshake messages that do not contain application data and how to handle t= hem. This PR is an attempt to make the story more explicit by adding a new = post_handshake extension to TLS 1.3.

Supporting all types of post-ha= ndshake messages can require extra complexity and logic, even when the feat= ures that these messages enable are not needed. Some types of connections/i= mplementations don't need to support key updates (some unidirectional c= onnections), session tickets (pure PSK implementations) and post-handshake = client auth (most browsers). These are all currently SHOULDs in the spec an= d they don't need to be.

In order to simplify the logic around d= ealing with post-handshake messages, this proposal makes support for each o= f these modes explicit via a new handshake extension. This change also make= s the path to introducing other types of post-handshake messages in future = drafts more explicit.

PR:
https://github.com/tlswg/tls13-spec/pull/676

<= /div>Nick
--001a1143d2f07bf7de053e50189e-- From nobody Sat Oct 8 02:03:09 2016 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 BA75B1294A0 for ; Sat, 8 Oct 2016 02:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 ZqmDRjEn9ZbA for ; Sat, 8 Oct 2016 02:03:05 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 694F6129473 for ; Sat, 8 Oct 2016 02:03:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 9D45D137EE; Sat, 8 Oct 2016 12:03:03 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id ZJNQtm-xF4qj; Sat, 8 Oct 2016 12:03:03 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 576FA2313; Sat, 8 Oct 2016 12:03:03 +0300 (EEST) Date: Sat, 8 Oct 2016 12:02:57 +0300 From: Ilari Liusvaara To: Nick Sullivan Message-ID: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Sat, 08 Oct 2016 09:03:08 -0000 On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages > that do not contain application data and how to handle them. This PR is an > attempt to make the story more explicit by adding a new post_handshake > extension to TLS 1.3. > > Supporting all types of post-handshake messages can require extra > complexity and logic, even when the features that these messages enable are > not needed. Some types of connections/implementations don't need to support > key updates (some unidirectional connections), session tickets (pure PSK > implementations) and post-handshake client auth (most browsers). These are > all currently SHOULDs in the spec and they don't need to be. Post-handshake authentication is the only one of these that is genuinely annoying. This is because you can't even reject it without a MAC, that additionally continues the handshake hash. KeyUpdate is rather simple, and NST can just be ignored (leading to some waste in bandwidth). Furthermore, the post-handshake authentication mechanism doesn't look to be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants, And there are serious questions about how it should interact with applications. -Ilari From nobody Sat Oct 8 07:16:37 2016 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 944AA1295C8 for ; Sat, 8 Oct 2016 07:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 yGyI_lSihkFE for ; Sat, 8 Oct 2016 07:16:33 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7AF1295C5 for ; Sat, 8 Oct 2016 07:16:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 73B8E12F2D; Sat, 8 Oct 2016 17:16:31 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id gJ5f904MIyJu; Sat, 8 Oct 2016 17:16:30 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 0C3FB21C; Sat, 8 Oct 2016 17:16:30 +0300 (EEST) Date: Sat, 8 Oct 2016 17:16:23 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161008141623.GA11416@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Sat, 08 Oct 2016 14:16:35 -0000 On Fri, Oct 07, 2016 at 01:41:48PM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk wrote: > > > On 10/07/2016 12:08 PM, Eric Rescorla wrote: > > > > > > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > > wrote: > > > >> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: > >> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara < > >> ilariliusvaara@welho.com> > >> > wrote: > >> > > >> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > >> > > > 4. I've taken a suggestion from David Benjamin to move the > >> negotiation > >> > > > of the PSK key exchange parameters out of the PSK itself and into a > >> > > > separate message. This cleans things up and also lets us drop the > >> > > > currently non-useful auth_mode parameter. > >> > > > >> > > Eeh... From the text, it seems to currently require the kex modes > >> > > extension if PSK extension is present. Which seems worse than useless > >> > > if the meaning is to get rid of the kex mode parameter from PSK > >> > > extension (since you will have the value anyway, but need to dig it > >> > > from another extension... Blech). > >> > > >> > I guess this is a matter of taste, but what convinced me was that: > >> > > >> > 1. It put all the logic on the server side. > >> > > > > I was going to ask whether this also includes the decision on whether to > > send a Certificate to authenticate the server (even for PSK modes), but it > > looks like this change is intentionally removing the ability to do PSK > > keyex and auth with a certificate? > > > > Yes, while preserving the ability to add it later by adding a PskAuthMode > extension parallel to this one. But unlike the KexMode extension, the AuthMode one would not be mandatory if PSK extension is included (the KexMode extension has no sane defaults!). And the semantics of authentication with PSK are much more subtle than semantics of key exchange with PSK. -Ilari From nobody Sat Oct 8 07:22:56 2016 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 B365B1295CF for ; Sat, 8 Oct 2016 07:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 hmwCo6ygdRDH for ; Sat, 8 Oct 2016 07:22:54 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 473FD1295CA for ; Sat, 8 Oct 2016 07:22:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 988F612E19; Sat, 8 Oct 2016 17:22:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id sM0CkuGlosjf; Sat, 8 Oct 2016 17:22:53 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2C31121C; Sat, 8 Oct 2016 17:22:53 +0300 (EEST) Date: Sat, 8 Oct 2016 17:22:47 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Sat, 08 Oct 2016 14:22:56 -0000 On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara > wrote: > > > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > > > wrote: > > > > > > > > Also, it is very likely that 0-RTT would need its own read API, because > > > > it is pretty unlikely that existing API could be safely retrofitted > > > > or even purpose-built unified API be designed that isn't just asking > > > > for security problems via mixing 0-RTT and 1-RTT data. > > > > > > Yes. In particular I think the TLS state machine transitions need to > > > be ordered with respect to the arrival and sending of data. The > > > challenge for a multithreaded program (yes, some programs have > > > multiple threads sending and receiving at once) is making this make > > > sense, or even a single-threaded program where the TLS stack can > > > change state at times not visible to the sending thread. Maybe there > > > is some slop here, like 0-RTT can become 1-RTT on send, but this > > > raises all sorts of problems for receiving. I think we need to require > > > separation in the API. > > > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- > > retransmit, which needs to be disableable, as sometimes that just plain > > won't work). > > Can you explain why that is? E.g. what they are planning to do with 0-RTT Token Binding in HTTP. The client puts in a signature into 0-RTT data. If the server rejects the 0-RTT and the client retransmits, the signature will still be there but is different. Also, if 0-RTT data can silently shift to 1-RTT, it would mean the server-side model would be to concatenate 0-RTT and 1-RTT data, which I thought we already established is quite dangerous. -Ilari From nobody Sat Oct 8 07:25:55 2016 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 779D01295D2 for ; Sat, 8 Oct 2016 07:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CtpC1yG58NxV for ; Sat, 8 Oct 2016 07:25:49 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D76E1295CF for ; Sat, 8 Oct 2016 07:25:49 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id q7so32442355qtq.1 for ; Sat, 08 Oct 2016 07:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LxWEZ26/k64QZkxW7por/qOflZwg6eAbhSZRVhI4qxg=; b=jn9qhHRhEzXtwbc/vGgZzAw3XEnOoQODnG3xG6lS3pze2rispRe9R9MmApRUr8ju2u f4RevbFUcsRcKSRL6/2lztlH+JXzw0wqhb09aH8LtGPB40L325tMiscbOreH8H+d8Ip6 3t/l1+RyN+fMpAjSIbJPcrYnytKL+zrz7PV5DbTumquQ5DQGKJCg7k1l5AiKJGhgPPKa LMg7JtQjqac8LH+hJnoyzcqjM597C2H/fs6dS6gK5cIeXbO4EeiD5SiBWIbZpqmYbwEt EUSyNuGsLErr3qOa0FYn+bTgU/P9q6vTcP5XVWNtUn7KnVrlUwxBTH4od9gVpirYC0Ak dEkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LxWEZ26/k64QZkxW7por/qOflZwg6eAbhSZRVhI4qxg=; b=hXrNThQ4L6Dh5i+zeXsX7W23x6T091aNbuQD0/PcMImezKnefIE8saQZPweDS/0l5M /jA6FpqjPFeht6LgN28zIneEuR2VzBhHD0waJSybpD8oR5yOQVCpESMeUhjaKNVeCrGL rqsSBDOiyh0S56Uwt1iia1TxLErteEeF9w9duXZxC6L4EDeF9JvxCtJEXlRqFCY/dkDe QcnRoBUw13RKbvf6mKRABBmjZcaIR3cUITnS2cMuyoPU7Uaec8HjM8VwX42ylIndpYAm r64znu4GBh8MNKjxnVEr3y03kEHZg5acYHWnHPUDx5vio5pkfWjHe5HDWlN1wHxyLBaz P92w== X-Gm-Message-State: AA6/9RlR6DpiPJ/rjYi4eUqgVxfIEIhg2p1rCoYJ7vOXfFb8lBOPW8KDW+cqWCPfQs49KsjgEpbUmVcLf8YX5A== X-Received: by 10.237.44.193 with SMTP id g59mr7848436qtd.144.1475936748360; Sat, 08 Oct 2016 07:25:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.87 with HTTP; Sat, 8 Oct 2016 07:25:47 -0700 (PDT) Received: by 10.12.171.87 with HTTP; Sat, 8 Oct 2016 07:25:47 -0700 (PDT) In-Reply-To: References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> From: Watson Ladd Date: Sat, 8 Oct 2016 07:25:47 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c12569298dae0053e5b4d54 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Application layer interactions and API guidance 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: Sat, 08 Oct 2016 14:25:52 -0000 --94eb2c12569298dae0053e5b4d54 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla wrote: > > > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara > wrote: >> >> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: >> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara >> > wrote: >> > > >> > > Also, it is very likely that 0-RTT would need its own read API, >> > > because >> > > it is pretty unlikely that existing API could be safely retrofitted >> > > or even purpose-built unified API be designed that isn't just asking >> > > for security problems via mixing 0-RTT and 1-RTT data. >> > >> > Yes. In particular I think the TLS state machine transitions need to >> > be ordered with respect to the arrival and sending of data. The >> > challenge for a multithreaded program (yes, some programs have >> > multiple threads sending and receiving at once) is making this make >> > sense, or even a single-threaded program where the TLS stack can >> > change state at times not visible to the sending thread. Maybe there >> > is some slop here, like 0-RTT can become 1-RTT on send, but this >> > raises all sorts of problems for receiving. I think we need to require >> > separation in the API. >> >> 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- >> retransmit, which needs to be disableable, as sometimes that just plain >> won't work). > > > Can you explain why that is? Grammar problems. Let's say you have an context-free parseable protocol, and you want to insert the restriction that there is a 0-RTT set of allowed constructions and an 1-RTT allowed set that is bigger. The most obvious way to do this is to treat the transition as a token that comes between the top-level productions of each set of allowable things: so I send you a bunch of 0-RTT allowed bits, then switch, then a bunch of 1-RTT allowed bits. If the sending stack can insert that transition anywhere the grammar explodes. One could try to handle this by some nasty "did we switch before now" construction to delay the transition. But you still need to switch how you are reading. > > -Ekr > > > >> This impiles that the application always needs to explicitly signal >> the end of 0-RTT data, even just to abort sending it. >> >> > > (This is the reason one needs to be especially careful when combining >> > > dynamic client certificates with HTTP/2... Basically, it can not be >> > > done safely without coordination on application layer). >> > > >> > > One likely wants application protocol to be able to specify part of >> > > or the entiere request context and to extract that part in the other >> > > end when requesting a certificate selection. This is to allow putting >> > > part of coordination data into the request itself. However, this is >> > > not >> > > sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at >> > > application layer. >> > > >> > > And then upon completion of the authentication (either successful or >> > > explicitly rejected), signal the application with the new certificate >> > > chain and the context the request had. >> > >> > This is going to require major changes to APIs and to the HTTP/2 >> > layer. It also interacts with token binding, whee! My question then >> > becomes one of what we actually need: can we assume that leakage >> > between authentication contexts over a single session is safe because >> > all contexts represent the same principal, by restricting the usages, >> > or is this overly restrictive? >> >> Yes, it is going to reuqire such changes. >> >> And you absolutely can not assume that all contexts present the same >> principal. >> >> And as I said, in multiplexed protocol like HTTP/2, you need application- >> level coordination on top. TLS just can't do that. >> >> > When we have multiple requests and replies in flight and the >> > authentication state changes, things get nasty. If we think of TLS as >> > sending a stream of events including authentication changes to the >> > application, this fits the semantics of the TLS draft as I understand >> > them to be, but does not necessarily fit what application protocols >> > want. There might be a semantic mismatch here requiring reworking of >> > one or another part. >> >> Also, some applications presumably want the events done synchronously, >> so they don't move with data reads. >> >> >> Basically, post-handshake auth is heckuva nasty problem. >> >> >> -Ilari >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- "Man is born free, but everywhere he is in chains". --Rousseau. --94eb2c12569298dae0053e5b4d54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>>
>> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
>> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
>> > <ilariliusvaar= a@welho.com> wrote:
>> > >
>> > > Also, it is very likely that 0-RTT would need its own re= ad API,
>> > > because
>> > > it is pretty unlikely that existing API could be safely = retrofitted
>> > > or even purpose-built unified API be designed that isn&#= 39;t just asking
>> > > for security problems via mixing 0-RTT and 1-RTT data. >> >
>> > Yes. In particular I think the TLS state machine transitions = need to
>> > be ordered with respect to the arrival and sending of data. T= he
>> > challenge for a multithreaded program (yes, some programs hav= e
>> > multiple threads sending and receiving at once) is making thi= s make
>> > sense, or even a single-threaded program where the TLS stack = can
>> > change state at times not visible to the sending thread. Mayb= e there
>> > is some slop here, like 0-RTT can become 1-RTT on send, but t= his
>> > raises all sorts of problems for receiving. I think we need t= o require
>> > separation in the API.
>>
>> 0-RTT can't be allowed to become 1-RTT on send (unless it is a= uto-
>> retransmit, which needs to be disableable, as sometimes that just = plain
>> won't work).
>
>
> Can you explain why that is?

Grammar problems.

Let's say you have an context-free parseable protocol, a= nd you want to insert the restriction that there is a 0-RTT set of allowed = constructions and an 1-RTT allowed set that is bigger. The most obvious way= to do this is to treat the transition as a token that comes between the to= p-level productions of each set of allowable things: so I send you a bunch = of 0-RTT allowed bits, then switch, then a bunch of 1-RTT allowed bits.

If the sending stack can insert that transition anywhere the= grammar explodes.

One could try to handle this by some nasty "did we swit= ch before now" construction to delay the transition. But you still nee= d to switch how you are reading.

>
> -Ekr
>
>
>
>> This impiles that the application always needs to explicitly signa= l
>> the end of 0-RTT data, even just to abort sending it.
>>
>> > > (This is the reason one needs to be especially careful w= hen combining
>> > > dynamic client certificates with HTTP/2... Basically, it= can not be
>> > > done safely without coordination on application layer).<= br> >> > >
>> > > One likely wants application protocol to be able to spec= ify part of
>> > > or the entiere request context and to extract that part = in the other
>> > > end when requesting a certificate selection. This is to = allow putting
>> > > part of coordination data into the request itself. Howev= er, this is
>> > > not
>> > > sufficient for e.g. HTTP/2 signaling, so more needs to b= e exchanged at
>> > > application layer.
>> > >
>> > > And then upon completion of the authentication (either s= uccessful or
>> > > explicitly rejected), signal the application with the ne= w certificate
>> > > chain and the context the request had.
>> >
>> > This is going to require major changes to APIs and to the HTT= P/2
>> > layer. It also interacts with token binding, whee! My questio= n then
>> > becomes one of what we actually need: can we assume that leak= age
>> > between authentication contexts over a single session is safe= because
>> > all contexts represent the same principal, by restricting the= usages,
>> > or is this overly restrictive?
>>
>> Yes, it is going to reuqire such changes.
>>
>> And you absolutely can not assume that all contexts present the sa= me
>> principal.
>>
>> And as I said, in multiplexed protocol like HTTP/2, you need appli= cation-
>> level coordination on top. TLS just can't do that.
>>
>> > When we have multiple requests and replies in flight and the<= br> >> > authentication state changes, things get nasty. If we think o= f TLS as
>> > sending a stream of events including authentication changes t= o the
>> > application, this fits the semantics of the TLS draft as I un= derstand
>> > them to be, but does not necessarily fit what application pro= tocols
>> > want. There might be a semantic mismatch here requiring rewor= king of
>> > one or another part.
>>
>> Also, some applications presumably want the events done synchronou= sly,
>> so they don't move with data reads.
>>
>>
>> Basically, post-handshake auth is heckuva nasty problem.
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.= ietf.org/mailman/listinfo/tls
>
>

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--94eb2c12569298dae0053e5b4d54-- From nobody Sat Oct 8 08:06:44 2016 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 8630012952D for ; Sat, 8 Oct 2016 08:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 vdF7IVBkGiuz for ; Sat, 8 Oct 2016 08:06:40 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E60129427 for ; Sat, 8 Oct 2016 08:06:40 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id l13so38792804itl.1 for ; Sat, 08 Oct 2016 08:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aZgtMwUp2l3DdxqAnuMIdcmEUb3QMnF4hH9lPUdfs8E=; b=n1WJVQoynLi1PsDW/sLFSQ0NfeffIBMy8M4V2CIZa+dtv1xcSV5Fw2F/teXvf6WPxZ LYJ1i4tbMoSWKWgJmN9jPp+GDNnRcUdjWpfwh/kTyfyDkl0Rw2FZ0Q7S/Ur/7nVXXMPe PtdYdhHS8pPApUTxA0SzEnYkI3miNAs7Tee08= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aZgtMwUp2l3DdxqAnuMIdcmEUb3QMnF4hH9lPUdfs8E=; b=RlBO9/2m517C3HWIXxU0fo1qTXzQg5TzX2NEkRP8U3tBnGUC3lo1yGVCJuzg6W5csd L1HGCTqQ6aEW1NYMdh8une24qNSWt9sYMTYP4we93jrKHVqtu0/le+22W6BlbB2J83fW QXFFi9OXMUeVwFO7AlrI+90gKVVE1eSNsiRlAxG2MH+WQLoFiILFfdoqMBn0mlScYLOl ++zSgGt5MHHxUnFTO4Z0oB9xdyr/HYu3xqOpjiVQKELW6nnYW8aZc2Xh13XP8gI/e3bY x41pV3ANoJXWClG5lIKKVWbiCxcjXB0ornoBa/s8pVr+Ci8+1akM6nEdITagGA/e/6vA Fu8w== X-Gm-Message-State: AA6/9RlFFdn4X7q7IySj/qeoez5eAsCdmprbRJauQ3xTr78scG5BV8ljClFhKaVSD7wuKsdet5aYMjBxzmGo5TG3 X-Received: by 10.36.20.9 with SMTP id 9mr3432178itg.24.1475939199533; Sat, 08 Oct 2016 08:06:39 -0700 (PDT) MIME-Version: 1.0 References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Sat, 08 Oct 2016 15:06:28 +0000 Message-ID: To: Ilari Liusvaara , Nick Sullivan Content-Type: multipart/alternative; boundary=001a11446af8b3127b053e5bdf23 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Sat, 08 Oct 2016 15:06:42 -0000 --001a11446af8b3127b053e5bdf23 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara wrote: On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages > that do not contain application data and how to handle them. This PR is an > attempt to make the story more explicit by adding a new post_handshake > extension to TLS 1.3. > > Supporting all types of post-handshake messages can require extra > complexity and logic, even when the features that these messages enable are > not needed. Some types of connections/implementations don't need to support > key updates (some unidirectional connections), session tickets (pure PSK > implementations) and post-handshake client auth (most browsers). These are > all currently SHOULDs in the spec and they don't need to be. Post-handshake authentication is the only one of these that is genuinely annoying. This is because you can't even reject it without a MAC, that additionally continues the handshake hash. KeyUpdate is rather simple, and NST can just be ignored (leading to some waste in bandwidth). Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have problems with either of the way, while post-handshake auth is indeed horrific. Furthermore, the post-handshake authentication mechanism doesn't look to be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants, And there are serious questions about how it should interact with applications. An extension also doesn't really capture things if we intend for, say, this to be used for legacy protocols like HTTP/1.1 (where we don't have as rich a framing layer) but not HTTP/2 (where we do and can use it as a substrate for all this silliness). I was anticipating that, if this ends up being used in the HTTP world like renego is, it would be like our renego stuff: off by default, forbidden in HTTP/2, and with all interleave forbidden. Further, what useful thing could a server even do with this extension? Decline to do post-handshake auth doesn't work. Either the application protocol doesn't use post-handshake auth (please pick this one) or it does. One doesn't need to send a client_writes_first extension in HTTP/1.1. Post-handshake auth another knob on the TLS <-> application protocol boundary. This means each application protocol must specify for itself what post-handshake auth means: what to do with the context field, when it may be received, what it does to application flow, etc. Then the spec must be clear that if the application protocol does not opt in, CertificateRequest is forbidden. A CertificateRequest at an unexpected point (say, half-way through a HTTP/1.1 body) is also forbidden. Also make it clear this is for legacy protocols and new ones do not use it. This is analogous to how HTTP/2 forbids renego at the spec level. (TLS 1.2 got the "defaults" for renego wrong.) No one ever wrote down the exact rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does this for post-handshake auth should do the same for renego. It is a lot of spec work for such a tiny-seeming feature, but this is consistent with how messy the feature actually is. David --001a11446af8b3127b053e5bdf23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 8, 2016 at= 5:03 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:=
On S= at, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake message= s
> that do not contain application data and how to handle them. This PR i= s an
> attempt to make the story more explicit by adding a new post_handshake=
> extension to TLS 1.3.
>
> Supporting all types of post-handshake messages can require extra
> complexity and logic, even when the features that these messages enabl= e are
> not needed. Some types of connections/implementations don't need t= o support
> key updates (some unidirectional connections), session tickets (pure P= SK
> implementations) and post-handshake client auth (most browsers). These= are
> all currently SHOULDs in the spec and they don't need to be.

Post-handshake authentication is the only one of these that is genuinely annoying. This is because you can't even reject it without a MAC, that<= br class=3D"gmail_msg"> additionally continues the handshake hash.

KeyUpdate is rather simple, and NST can just be ignored (leading to some waste in bandwidth).

Ye= ah, after the fix to how KeyUpdate is acked, I don't think we'd hav= e problems with either of the way, while post-handshake auth is indeed horr= ific.
=C2=A0
Furthermore, the post-handshake authentication mechanism doesn't look t= o
be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants,
And there are serious questions about how it should interact with
applications.
=
An extens= ion also doesn't really capture things if we intend for, say, this to b= e used for legacy protocols like HTTP/1.1 (where we don't have as rich = a framing layer) but not HTTP/2 (where we do and can use it as a substrate = for all this silliness). I was anticipating that, if this ends up being use= d in the HTTP world like renego is, it would be like our renego stuff: off = by default, forbidden in HTTP/2, and with all interleave forbidden.

Further, what useful thing could a server even do with this extension? D= ecline to do post-handshake auth doesn't work. Either the application p= rotocol doesn't use post-handshake auth (please pick this one) or it do= es. One doesn't need to send a client_writes_first extension in HTTP/1.= 1.

Post-handshake auth another knob on th= e TLS <-> application protocol boundary. This means each application = protocol must specify for itself what post-handshake auth means: what to do= with the context field, when it may be received, what it does to applicati= on flow, etc. Then the spec must be clear that if the application protocol = does not opt in, CertificateRequest is forbidden. A CertificateRequest at a= n unexpected point (say, half-way through a HTTP/1.1 body) is also forbidde= n. Also make it clear this is for legacy protocols and new ones do not use = it.

This is analogous to how HTTP/2 forbids renego at the spec l= evel. (TLS 1.2 got the "defaults" for renego wrong.) No one ever = wrote down the exact rules for the client-auth/renego hack in HTTP/1.1, but= whatever spec does this for post-handshake auth should do the same for ren= ego.

It is a lot of spec work for such a tiny-seeming feature, bu= t this is consistent with how messy the feature actually is.

David
--001a11446af8b3127b053e5bdf23-- From nobody Sat Oct 8 09:23:27 2016 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 B9ADB1295CA for ; Sat, 8 Oct 2016 09:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 z9Tqg0Kaxuc0 for ; Sat, 8 Oct 2016 09:23:23 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC5112957E for ; Sat, 8 Oct 2016 09:23:22 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id e2so25472183ybi.1 for ; Sat, 08 Oct 2016 09:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u9X3KmNH4OgF1R/c8NxFmbXIa4Vd35+D6w483hzAvDE=; b=plUYYBfRniWlRJEIR3vc9U91ZLVMOykpTII73LcbSUGRA7pVk6+FO8zuOLMmHIVz76 B5o4cQ6liL1wRZPNS3uZ1WBE3/suoA7nvr/ysIrMtoBhelH3KGcv4f/u7jkkOVaXTLwc luPjzYYEeaT4/Btw6sacBC8vXHazV2QP0589NM7LkGcDPpuLoiFsgU6Ws19F3ipSILKx ZsVSXUFi2MTeLDGAIN3WkD2RuRj6yPMQumCiZYGBLX7XUlxZW8N7qVcp07yZpogzEkN4 1XQ4hZZ68vKsiGyLFqvxBWXnZ8VtC9Gtg5wKat8hlmQ5ckrB9nv9M4YmbNG5eesQ5gC9 chHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u9X3KmNH4OgF1R/c8NxFmbXIa4Vd35+D6w483hzAvDE=; b=jVkrGFdwfavbM/9+x7DRHzNpxkyC+M/UUXSZcc2lNltizGJkY6C9mLZpawy8G0R7d4 ivE/NF7l+pPg6ZPHrePU4wgpw7PfyWSEJPPVLC4lQOTMIsXSmabJ9AgI3sW8/ZZkQ90+ Djt+zZMInxnFRgv7yocwaJCpfZrKmQAkkgh7519TW8DiGBvJ03lfG2bBCmA27h4XLXGy ByO24MLlZbofI3cSygj5+kqFrkoSx9GjJj+Xbtg3t4wcmD5GUCIBAvYtEb3LZLH56yRR SExu1k39Mu4sHxS4kqnF2QdwOJJTJHIiRjVcEpLOKuLnevyZ8v5FupMOn0pi3lnOUvrp sKbA== X-Gm-Message-State: AA6/9RnDIQxqkRfVfWI4n+c3FJp+B8u6esQNCDQrzFxECd9Sm+PnoeoAdV5Ez4XS9y7nVG1aP8oo0wa2f8JxOw== X-Received: by 10.37.171.234 with SMTP id v97mr20244241ybi.161.1475943801392; Sat, 08 Oct 2016 09:23:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Sat, 8 Oct 2016 09:22:40 -0700 (PDT) In-Reply-To: References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sat, 8 Oct 2016 09:22:40 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=94eb2c0ce1f8fdcaca053e5cf118 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Sat, 08 Oct 2016 16:23:26 -0000 --94eb2c0ce1f8fdcaca053e5cf118 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 8, 2016 at 7:25 AM, Watson Ladd wrote: > On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla wrote: > > > > > > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > >> > >> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > >> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > >> > wrote: > >> > > > >> > > Also, it is very likely that 0-RTT would need its own read API, > >> > > because > >> > > it is pretty unlikely that existing API could be safely retrofitted > >> > > or even purpose-built unified API be designed that isn't just asking > >> > > for security problems via mixing 0-RTT and 1-RTT data. > >> > > >> > Yes. In particular I think the TLS state machine transitions need to > >> > be ordered with respect to the arrival and sending of data. The > >> > challenge for a multithreaded program (yes, some programs have > >> > multiple threads sending and receiving at once) is making this make > >> > sense, or even a single-threaded program where the TLS stack can > >> > change state at times not visible to the sending thread. Maybe there > >> > is some slop here, like 0-RTT can become 1-RTT on send, but this > >> > raises all sorts of problems for receiving. I think we need to require > >> > separation in the API. > >> > >> 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- > >> retransmit, which needs to be disableable, as sometimes that just plain > >> won't work). > > > > > > Can you explain why that is? > > Grammar problems. > > Let's say you have an context-free parseable protocol, and you want to > insert the restriction that there is a 0-RTT set of allowed constructions > and an 1-RTT allowed set that is bigger. The most obvious way to do this is > to treat the transition as a token that comes between the top-level > productions of each set of allowable things: so I send you a bunch of 0-RTT > allowed bits, then switch, then a bunch of 1-RTT allowed bits. > > If the sending stack can insert that transition anywhere the grammar > explodes. > In the APIs people have been designing, 0-RTT can become 1-RTT but not the other way around. Specifically: - There is an option to allow 0-RTT writing - With that option on, SSL_Write() succeeds in both 0-RTT and 1-RTT modes. - There is a callback that tells you when you have gone from 0-RTT to 1-RTT. -Ekr One could try to handle this by some nasty "did we switch before now" > construction to delay the transition. But you still need to switch how you > are reading. > -Ekr > > > > -Ekr > > > > > > > >> This impiles that the application always needs to explicitly signal > >> the end of 0-RTT data, even just to abort sending it. > >> > >> > > (This is the reason one needs to be especially careful when > combining > >> > > dynamic client certificates with HTTP/2... Basically, it can not be > >> > > done safely without coordination on application layer). > >> > > > >> > > One likely wants application protocol to be able to specify part of > >> > > or the entiere request context and to extract that part in the other > >> > > end when requesting a certificate selection. This is to allow > putting > >> > > part of coordination data into the request itself. However, this is > >> > > not > >> > > sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged > at > >> > > application layer. > >> > > > >> > > And then upon completion of the authentication (either successful or > >> > > explicitly rejected), signal the application with the new > certificate > >> > > chain and the context the request had. > >> > > >> > This is going to require major changes to APIs and to the HTTP/2 > >> > layer. It also interacts with token binding, whee! My question then > >> > becomes one of what we actually need: can we assume that leakage > >> > between authentication contexts over a single session is safe because > >> > all contexts represent the same principal, by restricting the usages, > >> > or is this overly restrictive? > >> > >> Yes, it is going to reuqire such changes. > >> > >> And you absolutely can not assume that all contexts present the same > >> principal. > >> > >> And as I said, in multiplexed protocol like HTTP/2, you need > application- > >> level coordination on top. TLS just can't do that. > >> > >> > When we have multiple requests and replies in flight and the > >> > authentication state changes, things get nasty. If we think of TLS as > >> > sending a stream of events including authentication changes to the > >> > application, this fits the semantics of the TLS draft as I understand > >> > them to be, but does not necessarily fit what application protocols > >> > want. There might be a semantic mismatch here requiring reworking of > >> > one or another part. > >> > >> Also, some applications presumably want the events done synchronously, > >> so they don't move with data reads. > >> > >> > >> Basically, post-handshake auth is heckuva nasty problem. > >> > >> > >> -Ilari > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > --94eb2c0ce1f8fdcaca053e5cf118 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 8, 2016 at 7:25 AM, Watson Ladd <watsonbladd@gmail.com= > wrote:
<= p dir=3D"ltr">

On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <ilariliusvaara@welho.com>= ;
> wrote:
>>
>> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
>> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
>> > <ilariliusvaara@welho.com> wrote:
>> > >
>> > > Also, it is very likely that 0-RTT would need its own re= ad API,
>> > > because
>> > > it is pretty unlikely that existing API could be safely = retrofitted
>> > > or even purpose-built unified API be designed that isn&#= 39;t just asking
>> > > for security problems via mixing 0-RTT and 1-RTT data. >> >
>> > Yes. In particular I think the TLS state machine transitions = need to
>> > be ordered with respect to the arrival and sending of data. T= he
>> > challenge for a multithreaded program (yes, some programs hav= e
>> > multiple threads sending and receiving at once) is making thi= s make
>> > sense, or even a single-threaded program where the TLS stack = can
>> > change state at times not visible to the sending thread. Mayb= e there
>> > is some slop here, like 0-RTT can become 1-RTT on send, but t= his
>> > raises all sorts of problems for receiving. I think we need t= o require
>> > separation in the API.
>>
>> 0-RTT can't be allowed to become 1-RTT on send (unless it is a= uto-
>> retransmit, which needs to be disableable, as sometimes that just = plain
>> won't work).
>
>
> Can you explain why that is?

Grammar problems.

Let's say you have an context-free parseable protocol, a= nd you want to insert the restriction that there is a 0-RTT set of allowed = constructions and an 1-RTT allowed set that is bigger. The most obvious way= to do this is to treat the transition as a token that comes between the to= p-level productions of each set of allowable things: so I send you a bunch = of 0-RTT allowed bits, then switch, then a bunch of 1-RTT allowed bits.

If the sending stack can insert that transition anywhere the= grammar explodes.

In the APIs people have been design= ing, 0-RTT can become 1-RTT but not the other way around.
Specifi= cally:

- There is an option to allow 0-RTT writing=
- With that option on, SSL_Write() succeeds in both 0-RTT and 1-= RTT modes.
- There is a callback that tells you when you have gon= e from 0-RTT to 1-RTT.

-Ekr


One could try to handle this by some nasty "did we swit= ch before now" construction to delay the transition. But you still nee= d to switch how you are reading.



-Ekr
=C2=A0

>
> -Ekr
>
>
>
>> This impiles that the application always needs to explicitly signa= l
>> the end of 0-RTT data, even just to abort sending it.
>>
>> > > (This is the reason one needs to be especially careful w= hen combining
>> > > dynamic client certificates with HTTP/2... Basically, it= can not be
>> > > done safely without coordination on application layer).<= br> >> > >
>> > > One likely wants application protocol to be able to spec= ify part of
>> > > or the entiere request context and to extract that part = in the other
>> > > end when requesting a certificate selection. This is to = allow putting
>> > > part of coordination data into the request itself. Howev= er, this is
>> > > not
>> > > sufficient for e.g. HTTP/2 signaling, so more needs to b= e exchanged at
>> > > application layer.
>> > >
>> > > And then upon completion of the authentication (either s= uccessful or
>> > > explicitly rejected), signal the application with the ne= w certificate
>> > > chain and the context the request had.
>> >
>> > This is going to require major changes to APIs and to the HTT= P/2
>> > layer. It also interacts with token binding, whee! My questio= n then
>> > becomes one of what we actually need: can we assume that leak= age
>> > between authentication contexts over a single session is safe= because
>> > all contexts represent the same principal, by restricting the= usages,
>> > or is this overly restrictive?
>>
>> Yes, it is going to reuqire such changes.
>>
>> And you absolutely can not assume that all contexts present the sa= me
>> principal.
>>
>> And as I said, in multiplexed protocol like HTTP/2, you need appli= cation-
>> level coordination on top. TLS just can't do that.
>>
>> > When we have multiple requests and replies in flight and the<= br> >> > authentication state changes, things get nasty. If we think o= f TLS as
>> > sending a stream of events including authentication changes t= o the
>> > application, this fits the semantics of the TLS draft as I un= derstand
>> > them to be, but does not necessarily fit what application pro= tocols
>> > want. There might be a semantic mismatch here requiring rewor= king of
>> > one or another part.
>>
>> Also, some applications presumably want the events done synchronou= sly,
>> so they don't move with data reads.
>>
>>
>> Basically, post-handshake auth is heckuva nasty problem.
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org=
>> https://www.ietf.org/mailman/listinfo/tls
>
>

--
"Man is born free, but everywhere he is in chains".
--Rousseau.


--94eb2c0ce1f8fdcaca053e5cf118-- From nobody Sat Oct 8 09:32:47 2016 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 D993F1294FD for ; Sat, 8 Oct 2016 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u2kptrQY4Ihy for ; Sat, 8 Oct 2016 09:32:43 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9885E1288B8 for ; Sat, 8 Oct 2016 09:32:43 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id k64so6984107itb.0 for ; Sat, 08 Oct 2016 09:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nEuC9+F6SrpQN3BYDJsqOAbxy7fs5xSnRKd9nDNVBcA=; b=SjYOlDmirw2m18YIPT7uszB2bupAqi53H1ixU0sCvClOU8BpB6YPtajnwsZGSiL/AX 3v8AK5liBims3EarMy6+zVCyqQ8MknDpvX6G/S+eJ6EH3zUCx+RzdOZn7vrxbSiVCPkJ l2D+xEfuwpxsgv4b7VywAt1RMHreE9lTP+B36820yAdnV20QweaOdMXSnCGSVfuKqQRZ TfJSY5jbrSRTcjBc5hyrn09a/wCVbgy2lMzttfuNaFw0FXPY+YFclQfX8sqv8DhatiEY M3JYWEE2p0pm+5y4B6NnU/AEAbSz0C/xzL6GTPYkkyYA1XPm4kku/Fblkpy/5daOzwin nXwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nEuC9+F6SrpQN3BYDJsqOAbxy7fs5xSnRKd9nDNVBcA=; b=a8yQKvHvatBCvVnQhP98WgFJ+bI468PR0Cv45EMg7OyQvPf9nP6prJCG4AadwefUW0 bvk6mnpDmlrP3IBsvIRg3SoOr9uaxeo5QfyrZqS6FDeSOQBpc4yI4kCvR88M31lRBu85 BN/rczivCSu6t+VFKYQyfUVNXd+yvopyw/EJmZD6YnH5HYzvB4ZsS8HGkCJ8YUbZa4UR H0+ad72HX/6vO9Q8zxujmNhZ9WpjqXiiHMhd0FVKfoyn07r0A2Wc66xjnb6o74Wp1a58 6tejuCPl3n0p/xjtnU5TiXBBTIfNK0kCfAcWHb666EGgg+OS8tOQzeThLI7JpGICgR7K Gf5g== X-Gm-Message-State: AA6/9RkGUKlp/RnEYAIYBHsC37JPIDV2tAmuz0D78N8g3ZhuNtu2562np27AB3XINVxpNtuYoL2O6FBBGR8hMw== X-Received: by 10.36.253.200 with SMTP id m191mr3355509ith.35.1475944362963; Sat, 08 Oct 2016 09:32:42 -0700 (PDT) MIME-Version: 1.0 References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: Nick Sullivan Date: Sat, 08 Oct 2016 16:32:32 +0000 Message-ID: To: David Benjamin , Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0361e2767ca3053e5d13ca Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Sat, 08 Oct 2016 16:32:46 -0000 --94eb2c0361e2767ca3053e5d13ca Content-Type: text/plain; charset=UTF-8 I'm not proposing any new post-handshake authentication mechanisms or anything relating to HTTP/2 renegotiation in this change. I'm simply making support for the existing post-handshake messages optional. With this change, if the client does not opt in, unexpected CertificateRequests are fatal to the connection. Same with unexpected KeyUpdates and SessionTickets. This will hopefully reduce the complexity of TLS 1.3 implementations that don't need these features. Nick On Sat, Oct 8, 2016 at 8:06 AM David Benjamin wrote: > On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara > wrote: > > On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote: > > > There has been a lot of discussion lately about post-handshake messages > > > that do not contain application data and how to handle them. This PR is > an > > > attempt to make the story more explicit by adding a new post_handshake > > > extension to TLS 1.3. > > > > > > Supporting all types of post-handshake messages can require extra > > > complexity and logic, even when the features that these messages enable > are > > > not needed. Some types of connections/implementations don't need to > support > > > key updates (some unidirectional connections), session tickets (pure PSK > > > implementations) and post-handshake client auth (most browsers). These > are > > > all currently SHOULDs in the spec and they don't need to be. > > > > Post-handshake authentication is the only one of these that is genuinely > > annoying. This is because you can't even reject it without a MAC, that > > additionally continues the handshake hash. > > > > KeyUpdate is rather simple, and NST can just be ignored (leading to some > > waste in bandwidth). > > > Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have > problems with either of the way, while post-handshake auth is indeed > horrific. > > > > Furthermore, the post-handshake authentication mechanism doesn't look to > > be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants, > > And there are serious questions about how it should interact with > > applications. > > > An extension also doesn't really capture things if we intend for, say, > this to be used for legacy protocols like HTTP/1.1 (where we don't have as > rich a framing layer) but not HTTP/2 (where we do and can use it as a > substrate for all this silliness). I was anticipating that, if this ends up > being used in the HTTP world like renego is, it would be like our renego > stuff: off by default, forbidden in HTTP/2, and with all interleave > forbidden. > > Further, what useful thing could a server even do with this extension? > Decline to do post-handshake auth doesn't work. Either the application > protocol doesn't use post-handshake auth (please pick this one) or it does. > One doesn't need to send a client_writes_first extension in HTTP/1.1. > > Post-handshake auth another knob on the TLS <-> application protocol > boundary. This means each application protocol must specify for itself what > post-handshake auth means: what to do with the context field, when it may > be received, what it does to application flow, etc. Then the spec must be > clear that if the application protocol does not opt in, CertificateRequest > is forbidden. A CertificateRequest at an unexpected point (say, half-way > through a HTTP/1.1 body) is also forbidden. Also make it clear this is for > legacy protocols and new ones do not use it. > > This is analogous to how HTTP/2 forbids renego at the spec level. (TLS 1.2 > got the "defaults" for renego wrong.) No one ever wrote down the exact > rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does > this for post-handshake auth should do the same for renego. > > It is a lot of spec work for such a tiny-seeming feature, but this is > consistent with how messy the feature actually is. > > David > --94eb2c0361e2767ca3053e5d13ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not proposing any new post-handshake authenticatio= n mechanisms or anything relating to HTTP/2 renegotiation in this change. I= 'm simply making support for the existing post-handshake messages optio= nal.

With this change, if the client does not opt in, un= expected CertificateRequests are fatal to the connection. Same with unexpec= ted KeyUpdates and SessionTickets. This will hopefully reduce the complexit= y of TLS 1.3 implementations that don't need these features.
=
Nick

On Sat, Oct 8, 2016 at 8:06 AM David Benjamin <davidben@chromium.org> wrote:
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaar= a <ilariliusvaara@welho.com> wrote:
On Sat, Oct 08, 2016 at 01:= 03:21AM +0000, Nick Sullivan wrote:

> There h= as been a lot of discussion lately about post-handshake messages

> that do not contain application data and how to han= dle them. This PR is an

> attempt to make the= story more explicit by adding a new post_handshake
=
> extension to TLS 1.3.

>

> Supporting all types of post-handshake messages can req= uire extra

> complexity and logic, even when = the features that these messages enable are

>= not needed. Some types of connections/implementations don't need to su= pport

> key updates (some unidirectional conn= ections), session tickets (pure PSK

> impleme= ntations) and post-handshake client auth (most browsers). These are

> all currently SHOULDs in the spec and they don'= ;t need to be.



Post-= handshake authentication is the only one of these that is genuinely

annoying. This is because you can't even reject it = without a MAC, that

additionally continues the h= andshake hash.



KeyUp= date is rather simple, and NST can just be ignored (leading to some

waste in bandwidth).

=
<= div class=3D"gmail_quote gmail_msg">
Yeah, after th= e fix to how KeyUpdate is acked, I don't think we'd have problems w= ith either of the way, while post-handshake auth is indeed horrific.
<= /div>
=C2=A0

Furthermore, th= e post-handshake authentication mechanism doesn't look to

be featureful enough for kind of post-handshake auth e.g. HTT= P/2 wants,

And there are serious questions about= how it should interact with

applications.

An extension also doesn't really capture things if we i= ntend for, say, this to be used for legacy protocols like HTTP/1.1 (where w= e don't have as rich a framing layer) but not HTTP/2 (where we do and c= an use it as a substrate for all this silliness). I was anticipating that, = if this ends up being used in the HTTP world like renego is, it would be li= ke our renego stuff: off by default, forbidden in HTTP/2, and with all inte= rleave forbidden.

Further, what useful thing could a server even = do with this extension? Decline to do post-handshake auth doesn't work.= Either the application protocol doesn't use post-handshake auth (pleas= e pick this one) or it does. One doesn't need to send a client_writes_f= irst extension in HTTP/1.1.

Post-handshak= e auth another knob on the TLS <-> application protocol boundary. Thi= s means each application protocol must specify for itself what post-handsha= ke auth means: what to do with the context field, when it may be received, = what it does to application flow, etc. Then the spec must be clear that if = the application protocol does not opt in, CertificateRequest is forbidden. = A CertificateRequest at an unexpected point (say, half-way through a HTTP/1= .1 body) is also forbidden. Also make it clear this is for legacy protocols= and new ones do not use it.

This is analogous to how HTTP/2 forb= ids renego at the spec level. (TLS 1.2 got the "defaults" for ren= ego wrong.) No one ever wrote down the exact rules for the client-auth/rene= go hack in HTTP/1.1, but whatever spec does this for post-handshake auth sh= ould do the same for renego.

It is a lot of spec work for such a = tiny-seeming feature, but this is consistent with how messy the feature act= ually is.

D= avid
--94eb2c0361e2767ca3053e5d13ca-- From nobody Sat Oct 8 09:51:33 2016 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 048C6129466 for ; Sat, 8 Oct 2016 09:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 ztU9Jzs2nyTv for ; Sat, 8 Oct 2016 09:51:30 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E75129426 for ; Sat, 8 Oct 2016 09:51:30 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id q192so74898045iod.0 for ; Sat, 08 Oct 2016 09:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mhdVlkfkrnffe7cdhlyML9Y2WQa7JEnUBvRv7ubiIkA=; b=nVIUYDEt5OoYatKcLD5R4oyo/AfqDy45tuN5nUzUa8lVk7NEkMdflZPWV5YNkMBdRf mQnlmVondZjMVkUhlFtr5I4dsg2Vvh09QgDGfGa8z23Uq4M5HQqewapKedHgAtR3UH4J 2Kx6xfBthixaJ/GQa81NoJ5/YhAiwt2Mg2Jz8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mhdVlkfkrnffe7cdhlyML9Y2WQa7JEnUBvRv7ubiIkA=; b=mEBll0E2LVZetQM2js9/uHpR3ZEr5y+RAmeDiwTn92AXk3GqkHBZkDKdSINY7jviUL MEp0tTrU4tIts3bncgsDcjhDQ8n0/tU6gLsiB/CtziuiqfbjLjXmMhewVsNZxAAq4Aon k35PormG8fgNF+39zsPHAvZJFP7eKJKdQlR57Vgf+kqGGoiP6hsBjT+lsgLOCKbKY31r qJNQVBMqDiLLp50GnU7AoJPoavRPYQWyma5USeUGRq+SOM6MDvms5eb5/VSYQb38ZnEg t29CcMILkfn6WRzIEHGJ/F5drN3gcyBn1q5sE9c8o2An8bKFd1I/iFvmRktOJ0f/S3YY JGmQ== X-Gm-Message-State: AA6/9Rk6FMbB9Ukz3rtfqEPJSQhcdPRSZbivVSHPiqYhzzeu0SksY3IwHbmuylNRSBJ00YXswLtmJYCnFcpO6/PS X-Received: by 10.107.14.65 with SMTP id 62mr24273698ioo.142.1475945489165; Sat, 08 Oct 2016 09:51:29 -0700 (PDT) MIME-Version: 1.0 References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Sat, 08 Oct 2016 16:51:17 +0000 Message-ID: To: Nick Sullivan , Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113fd05a97763a053e5d569b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Sat, 08 Oct 2016 16:51:33 -0000 --001a113fd05a97763a053e5d569b Content-Type: text/plain; charset=UTF-8 Right, but making it an extension does not really capture the complexities of post-handshake auth. What's needed is mostly spec text, not wire changes. The text should say something to the effect of unexpected CertificateRequests are always fatal to the connection. By default, all CertificateRequests are unexpected. An application protocol may define this otherwise in certain contexts with certain semantics. For instance, a spec for reactive client auth over HTTP/1.1 might say a CertificateRequest just before a response is legal (but not in the middle of one). HTTP/2 would not say such a thing, so it would forbid all CertificateRequests implicitly (just like it currently forbids renego, though that sadly had to be done explicitly). Unless the application protocol needs some help with the negotiation, there's no need to add a separate negotiable boolean at the TLS layer. We assume both sides know what application protocol they're using, just like we assume both sides know they're speaking TLS. David On Sat, Oct 8, 2016 at 12:32 PM Nick Sullivan wrote: I'm not proposing any new post-handshake authentication mechanisms or anything relating to HTTP/2 renegotiation in this change. I'm simply making support for the existing post-handshake messages optional. With this change, if the client does not opt in, unexpected CertificateRequests are fatal to the connection. Same with unexpected KeyUpdates and SessionTickets. This will hopefully reduce the complexity of TLS 1.3 implementations that don't need these features. Nick On Sat, Oct 8, 2016 at 8:06 AM David Benjamin wrote: On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara wrote: On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages > that do not contain application data and how to handle them. This PR is an > attempt to make the story more explicit by adding a new post_handshake > extension to TLS 1.3. > > Supporting all types of post-handshake messages can require extra > complexity and logic, even when the features that these messages enable are > not needed. Some types of connections/implementations don't need to support > key updates (some unidirectional connections), session tickets (pure PSK > implementations) and post-handshake client auth (most browsers). These are > all currently SHOULDs in the spec and they don't need to be. Post-handshake authentication is the only one of these that is genuinely annoying. This is because you can't even reject it without a MAC, that additionally continues the handshake hash. KeyUpdate is rather simple, and NST can just be ignored (leading to some waste in bandwidth). Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have problems with either of the way, while post-handshake auth is indeed horrific. Furthermore, the post-handshake authentication mechanism doesn't look to be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants, And there are serious questions about how it should interact with applications. An extension also doesn't really capture things if we intend for, say, this to be used for legacy protocols like HTTP/1.1 (where we don't have as rich a framing layer) but not HTTP/2 (where we do and can use it as a substrate for all this silliness). I was anticipating that, if this ends up being used in the HTTP world like renego is, it would be like our renego stuff: off by default, forbidden in HTTP/2, and with all interleave forbidden. Further, what useful thing could a server even do with this extension? Decline to do post-handshake auth doesn't work. Either the application protocol doesn't use post-handshake auth (please pick this one) or it does. One doesn't need to send a client_writes_first extension in HTTP/1.1. Post-handshake auth another knob on the TLS <-> application protocol boundary. This means each application protocol must specify for itself what post-handshake auth means: what to do with the context field, when it may be received, what it does to application flow, etc. Then the spec must be clear that if the application protocol does not opt in, CertificateRequest is forbidden. A CertificateRequest at an unexpected point (say, half-way through a HTTP/1.1 body) is also forbidden. Also make it clear this is for legacy protocols and new ones do not use it. This is analogous to how HTTP/2 forbids renego at the spec level. (TLS 1.2 got the "defaults" for renego wrong.) No one ever wrote down the exact rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does this for post-handshake auth should do the same for renego. It is a lot of spec work for such a tiny-seeming feature, but this is consistent with how messy the feature actually is. David --001a113fd05a97763a053e5d569b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, but making it = an extension does not really capture the complexities of post-handshake aut= h. What's needed is mostly spec text, not wire changes. The text should= say something to the effect of unexpected CertificateRequests are always f= atal to the connection. By default, all CertificateRequests are unexpected.= An application protocol may define this otherwise in certain contexts with= certain semantics. For instance, a spec for reactive client auth over HTTP= /1.1 might say a CertificateRequest just before a response is legal (but no= t in the middle of one). HTTP/2 would not say such a thing, so it would for= bid all CertificateRequests implicitly (just like it currently forbids rene= go, though that sadly had to be done explicitly).
<= br class=3D"gmail_msg">
Unless the application protocol needs some help with the negotiation, t= here's no need to add a separate negotiable boolean at the TLS layer. W= e assume both sides know what application protocol they're using, just = like we assume both sides know they're speaking TLS.
<= div dir=3D"ltr" class=3D"gmail_msg">

David

=
=
O= n Sat, Oct 8, 2016 at 12:32 PM Nick Sullivan <nicholas.sulliva= n@gmail.com> wrote:
I'm not pr= oposing any new post-handshake authentication mechanisms or anything relati= ng to HTTP/2 renegotiation in this change. I'm simply making support fo= r the existing post-handshake messages optional.
With this change, if t= he client does not opt in, unexpected CertificateRequests are fatal to the = connection. Same with unexpected KeyUpdates and SessionTickets. This will h= opefully reduce the complexity of TLS 1.3 implementations that don't ne= ed these features.

Nic= k

On Sat, Oct 8, 2016 at 8:06 AM Dav= id Benjamin <davidben@chromium.org> wrote:
On Sat, Oct 8, 2016 at 5= :03 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Sat= , Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote:

> There has been a lot of discussion lately= about post-handshake messages

> that do not contain application data and how to handle them. This P= R is an

> attempt to make= the story more explicit by adding a new post_handshake

> extension to TLS 1.3.

>

> Supporting all types of post-handshake messages can require extra<= br class=3D"gmail_msg">
> complexity and logic, e= ven when the features that these messages enable are

> not needed. Some types of connections/impleme= ntations don't need to support

> key updates (some unidirectional connections), session tickets = (pure PSK

> implementatio= ns) and post-handshake client auth (most browsers). These are

> all currently SHOULDs in the spec an= d they don't need to be.



Post-handshake authenticat= ion is the only one of these that is genuinely

annoying. This is because you can't even reject it w= ithout a MAC, that

additiona= lly continues the handshake hash.



KeyUpdate is rather s= imple, and NST can just be ignored (leading to some
=
waste in bandwidth).

Yeah, afte= r the fix to how KeyUpdate is acked, I don't think we'd have proble= ms with either of the way, while post-handshake auth is indeed horrific.
=C2=A0

Furthermore, the post-handshake authentication mechanism doesn'= ;t look to

be featureful eno= ugh for kind of post-handshake auth e.g. HTTP/2 wants,

And there are serious questions about how it sho= uld interact with

applicatio= ns.

=
An extension also doesn't really capture thing= s if we intend for, say, this to be used for legacy protocols like HTTP/1.1= (where we don't have as rich a framing layer) but not HTTP/2 (where we= do and can use it as a substrate for all this silliness). I was anticipati= ng that, if this ends up being used in the HTTP world like renego is, it wo= uld be like our renego stuff: off by default, forbidden in HTTP/2, and with= all interleave forbidden.

Further, what useful thing could a ser= ver even do with this extension? Decline to do post-handshake auth doesn= 9;t work. Either the application protocol doesn't use post-handshake au= th (please pick this one) or it does. One doesn't need to send a client= _writes_first extension in HTTP/1.1.

Post= -handshake auth another knob on the TLS <-> application protocol boun= dary. This means each application protocol must specify for itself what pos= t-handshake auth means: what to do with the context field, when it may be r= eceived, what it does to application flow, etc. Then the spec must be clear= that if the application protocol does not opt in, CertificateRequest is fo= rbidden. A CertificateRequest at an unexpected point (say, half-way through= a HTTP/1.1 body) is also forbidden. Also make it clear this is for legacy = protocols and new ones do not use it.

This is analogous to how HT= TP/2 forbids renego at the spec level. (TLS 1.2 got the "defaults"= ; for renego wrong.) No one ever wrote down the exact rules for the client-= auth/renego hack in HTTP/1.1, but whatever spec does this for post-handshak= e auth should do the same for renego.

It is a lot of spec work fo= r such a tiny-seeming feature, but this is consistent with how messy the fe= ature actually is.

David
--001a113fd05a97763a053e5d569b-- From nobody Sat Oct 8 09:53:11 2016 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 758DE1295A0 for ; Sat, 8 Oct 2016 09:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 SKNFg-WxC5It for ; Sat, 8 Oct 2016 09:53:08 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 097A512957E for ; Sat, 8 Oct 2016 09:53:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id AF56F131CA; Sat, 8 Oct 2016 19:53:06 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id UazkuRLQk64a; Sat, 8 Oct 2016 19:53:06 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 715FE2310; Sat, 8 Oct 2016 19:53:06 +0300 (EEST) Date: Sat, 8 Oct 2016 19:53:00 +0300 From: Ilari Liusvaara To: Nick Sullivan Message-ID: <20161008165300.GA12067@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Sat, 08 Oct 2016 16:53:10 -0000 On Sat, Oct 08, 2016 at 04:32:32PM +0000, Nick Sullivan wrote: > I'm not proposing any new post-handshake authentication mechanisms or > anything relating to HTTP/2 renegotiation in this change. I'm simply making > support for the existing post-handshake messages optional. > > With this change, if the client does not opt in, unexpected > CertificateRequests are fatal to the connection. Same with unexpected > KeyUpdates and SessionTickets. This will hopefully reduce the complexity of > TLS 1.3 implementations that don't need these features. I really don't think making KeyUpdate optional is a good idea. SessionTicket: Just don't send it / ignore it on reception. What makes CertificateRequest really annoying is that one can't just simply dismiss or NAK it. There are two messages involved, one involving a MAC. And furthermore, one must be quite careful in use of post-handshake auth to not get subtle security issues. -Ilari From nobody Sat Oct 8 09:55:32 2016 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 40B6E129426 for ; Sat, 8 Oct 2016 09:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 7oW7ZRMBSBFy for ; Sat, 8 Oct 2016 09:55:28 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD57B1295D2 for ; Sat, 8 Oct 2016 09:55:28 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id w3so21804083ywg.1 for ; Sat, 08 Oct 2016 09:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hMLn7zbLVjJzxrKYxe3EH7mXCNow2OHyRwjJXEzKln0=; b=Y1z79/mcfGxzPenMBYAGASeSJO/Vj++Noi5rCJ6Pu7ZaiP/eicsFDUghKovqSTv998 /e12kd9O7sW+Ny/rdFpUtMK3ueQAk0TstZlh8SeGRYysxnYD62GRLFGbEKCaLoM3z8/L 2MwKeMq2WZO0blEn4AxbwHRUuMZyKo3s6cmx18eiz3DpXHyJ7wWkgXxvvqHWPezYqsTz rTLA62XY/+CaGbJ+pfY4oMl02XQstqsk+Df+hQ+zsEpJMLEfa7+gIKhpOYyecs+Hd85c VYz5VPyDxAi1SNVF7RcbC7h1tNmVXmB775/tRN49bQTC1TGJjS6WPNI8PK2CF8v/zmkI n04A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hMLn7zbLVjJzxrKYxe3EH7mXCNow2OHyRwjJXEzKln0=; b=g3udVMKe4TRBRfru2v26px7pcAWVEPDM/1y7K3ysVZyburaOnqH9az5CnO7BP70wEE n3xa1ZfNJ2rrM7qFomelrM6GmE7K3APCnglUbPaxaZhI/ZT2qstqstqO4Ng9/hMoL4ni f7E2+7SX+3BNDEVEF59MQNXmssq563FpHGKyTcYtL3htnWNtXg7cpNzoFx/21dmj9qWK GN4+20Rc7CwyxCDET1mjwlMPluLxbG6L1vroRM2x+BLCXNBTImwEH7FCjadetkMjewuD 2E5RKZzfFu05f2XG7nM7+7kVanpRiqS9Kn5JHIwUb49Tdlm6uySHUoypw6dIB6XwPnJA zztA== X-Gm-Message-State: AA6/9RmR9NXs5+CmMczouzc0XhGlXWA/yWNmPRsoM5AyC/4totAsSXoiUVDWHCkMUcgzn13DFqxWoktZsLkNFQ== X-Received: by 10.129.121.206 with SMTP id u197mr19399600ywc.146.1475945727947; Sat, 08 Oct 2016 09:55:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Sat, 8 Oct 2016 09:54:47 -0700 (PDT) In-Reply-To: References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sat, 8 Oct 2016 09:54:47 -0700 Message-ID: To: Nick Sullivan Content-Type: multipart/alternative; boundary=94eb2c0b0f68d2a653053e5d64af Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Sat, 08 Oct 2016 16:55:31 -0000 --94eb2c0b0f68d2a653053e5d64af Content-Type: text/plain; charset=UTF-8 I could go either way on this. It seems like this pushes complexity from the client to the server. Consider the case of NST. Presently, a client which doesn't want resumption can just ignore NST, but in your proposed change, the server needs to read this extension and then conditionally send NST, and the client still needs the logic to detect unexpected handshake messages and abort on them. As I said, I could go either way, and I do think it's potentially useful to be able to say "I won't do post-handshake client auth" and even more useful to be able to say "I would do post handshake message X which will be invented in 2018" (but of course we can register an extension for that then), but less useful to say "I don't like NST or KU" -Ekr On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan wrote: > I'm not proposing any new post-handshake authentication mechanisms or > anything relating to HTTP/2 renegotiation in this change. I'm simply making > support for the existing post-handshake messages optional. > > With this change, if the client does not opt in, unexpected > CertificateRequests are fatal to the connection. Same with unexpected > KeyUpdates and SessionTickets. This will hopefully reduce the complexity of > TLS 1.3 implementations that don't need these features. > > Nick > > On Sat, Oct 8, 2016 at 8:06 AM David Benjamin > wrote: > >> On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara >> wrote: >> >>> On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote: >>> >>> > There has been a lot of discussion lately about post-handshake messages >>> >>> > that do not contain application data and how to handle them. This PR >>> is an >>> >>> > attempt to make the story more explicit by adding a new post_handshake >>> >>> > extension to TLS 1.3. >>> >>> > >>> >>> > Supporting all types of post-handshake messages can require extra >>> >>> > complexity and logic, even when the features that these messages >>> enable are >>> >>> > not needed. Some types of connections/implementations don't need to >>> support >>> >>> > key updates (some unidirectional connections), session tickets (pure >>> PSK >>> >>> > implementations) and post-handshake client auth (most browsers). These >>> are >>> >>> > all currently SHOULDs in the spec and they don't need to be. >>> >>> >>> >>> Post-handshake authentication is the only one of these that is genuinely >>> >>> annoying. This is because you can't even reject it without a MAC, that >>> >>> additionally continues the handshake hash. >>> >>> >>> >>> KeyUpdate is rather simple, and NST can just be ignored (leading to some >>> >>> waste in bandwidth). >>> >> >> Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have >> problems with either of the way, while post-handshake auth is indeed >> horrific. >> >> >>> >>> Furthermore, the post-handshake authentication mechanism doesn't look to >>> >>> be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants, >>> >>> And there are serious questions about how it should interact with >>> >>> applications. >>> >> >> An extension also doesn't really capture things if we intend for, say, >> this to be used for legacy protocols like HTTP/1.1 (where we don't have as >> rich a framing layer) but not HTTP/2 (where we do and can use it as a >> substrate for all this silliness). I was anticipating that, if this ends up >> being used in the HTTP world like renego is, it would be like our renego >> stuff: off by default, forbidden in HTTP/2, and with all interleave >> forbidden. >> >> Further, what useful thing could a server even do with this extension? >> Decline to do post-handshake auth doesn't work. Either the application >> protocol doesn't use post-handshake auth (please pick this one) or it does. >> One doesn't need to send a client_writes_first extension in HTTP/1.1. >> >> Post-handshake auth another knob on the TLS <-> application protocol >> boundary. This means each application protocol must specify for itself what >> post-handshake auth means: what to do with the context field, when it may >> be received, what it does to application flow, etc. Then the spec must be >> clear that if the application protocol does not opt in, CertificateRequest >> is forbidden. A CertificateRequest at an unexpected point (say, half-way >> through a HTTP/1.1 body) is also forbidden. Also make it clear this is for >> legacy protocols and new ones do not use it. >> >> This is analogous to how HTTP/2 forbids renego at the spec level. (TLS >> 1.2 got the "defaults" for renego wrong.) No one ever wrote down the exact >> rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does >> this for post-handshake auth should do the same for renego. >> >> It is a lot of spec work for such a tiny-seeming feature, but this is >> consistent with how messy the feature actually is. >> >> David >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0b0f68d2a653053e5d64af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I could go either way on this. It seems like this pushes c= omplexity from the client to the server.=C2=A0

Consider = the case of NST. Presently, a client which doesn't want resumption can = just ignore NST,
but in your proposed change, the server needs to= read this extension and then conditionally send
NST, and the cli= ent still needs the logic to detect unexpected handshake messages and abort=
on them.

As I said, I could go either w= ay, and I do think it's potentially useful to be able to say "I wo= n't do
post-handshake client auth" and even more useful = to be able to say "I would do post handshake
message X which= will be invented in 2018" (but of course we can register an extension= for
that then), but less useful to say "I don't like NS= T or KU"

-Ekr


On Sat, Oct 8, 2016 at 9:32= AM, Nick Sullivan <nicholas.sullivan@gmail.com> w= rote:
I'm not propos= ing any new post-handshake authentication mechanisms or anything relating t= o HTTP/2 renegotiation in this change. I'm simply making support for th= e existing post-handshake messages optional.

With this c= hange, if the client does not opt in, unexpected CertificateRequests are fa= tal to the connection. Same with unexpected KeyUpdates and SessionTickets. = This will hopefully reduce the complexity of TLS 1.3 implementations that d= on't need these features.

<= div>
Nick

On Sat, Oct 8, 2016 at 8:06 AM David Benj= amin <davidbe= n@chromium.org> wrote:
On= Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:=
On Sat, Oct 08, 2016 at 01:03:21AM= +0000, Nick Sullivan wrote:

> There has been a lot of discussion= lately about post-handshake messages

> that do not contain appli= cation data and how to handle them. This PR is an

> attempt to ma= ke the story more explicit by adding a new post_handshake

> exten= sion to TLS 1.3.

>

> Supporting all types of post-hands= hake messages can require extra

> complexity and logic, even when= the features that these messages enable are

> not needed. Some t= ypes of connections/implementations don't need to support

> k= ey updates (some unidirectional connections), session tickets (pure PSK
=
> implementations) and post-handshake client auth (most browsers). T= hese are

> all currently SHOULDs in the spec and they don't n= eed to be.



Post-handshake authentication is the only one of = these that is genuinely

annoying. This is because you can't even= reject it without a MAC, that

additionally continues the handshake = hash.



KeyUpdate is rather simple, and NST can just be ignore= d (leading to some

waste in bandwidth).

Yeah, after the fix to how KeyUpdate is acked, I don't thin= k we'd have problems with either of the way, while post-handshake auth = is indeed horrific.
=C2=A0
An e= xtension also doesn't really capture things if we intend for, say, this= to be used for legacy protocols like HTTP/1.1 (where we don't have as = rich a framing layer) but not HTTP/2 (where we do and can use it as a subst= rate for all this silliness). I was anticipating that, if this ends up bein= g used in the HTTP world like renego is, it would be like our renego stuff:= off by default, forbidden in HTTP/2, and with all interleave forbidden.

Further, what useful thing could a server even do wi= th this extension? Decline to do post-handshake auth doesn't work. Eith= er the application protocol doesn't use post-handshake auth (please pic= k this one) or it does. One doesn't need to send a client_writes_first = extension in HTTP/1.1.

Post-handshake auth ano= ther knob on the TLS <-> application protocol boundary. This means ea= ch application protocol must specify for itself what post-handshake auth me= ans: what to do with the context field, when it may be received, what it do= es to application flow, etc. Then the spec must be clear that if the applic= ation protocol does not opt in, CertificateRequest is forbidden. A Certific= ateRequest at an unexpected point (say, half-way through a HTTP/1.1 body) i= s also forbidden. Also make it clear this is for legacy protocols and new o= nes do not use it.

This is analogous to how HTTP/2= forbids renego at the spec level. (TLS 1.2 got the "defaults" fo= r renego wrong.) No one ever wrote down the exact rules for the client-auth= /renego hack in HTTP/1.1, but whatever spec does this for post-handshake au= th should do the same for renego.

It is a lot of s= pec work for such a tiny-seeming feature, but this is consistent with how m= essy the feature actually is.

David

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


--94eb2c0b0f68d2a653053e5d64af-- From nobody Sat Oct 8 10:06:17 2016 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 B7C7F129544 for ; Sat, 8 Oct 2016 10:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 8qZmMQd285Mv for ; Sat, 8 Oct 2016 10:06:13 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF39129503 for ; Sat, 8 Oct 2016 10:06:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7162816113; Sat, 8 Oct 2016 20:06:11 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id CULhU9BkWTBF; Sat, 8 Oct 2016 20:06:11 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 30E4221C; Sat, 8 Oct 2016 20:06:11 +0300 (EEST) Date: Sat, 8 Oct 2016 20:06:05 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161008170605.GB12067@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Sat, 08 Oct 2016 17:06:16 -0000 On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote: > > In the APIs people have been designing, 0-RTT can become 1-RTT but not the > other way around. > Specifically: > > - There is an option to allow 0-RTT writing > - With that option on, SSL_Write() succeeds in both 0-RTT and 1-RTT modes. > - There is a callback that tells you when you have gone from 0-RTT to 1-RTT. I really hope I misunderstood what you wrote... I understood it as: The TLS client library notifies the application that it has transitioned on its own, without instruction from client application from sending 0-RTT data to server to sending 1-RTT data to the server??? -Ilari From nobody Sat Oct 8 10:13:52 2016 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 AE82E12954F for ; Sat, 8 Oct 2016 10:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 JslhM3q8zdwR for ; Sat, 8 Oct 2016 10:13:49 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A8E1293FE for ; Sat, 8 Oct 2016 10:13:49 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id w3so21960941ywg.1 for ; Sat, 08 Oct 2016 10:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nSUA/oi5lpmodzeOVvrDJ+6BEjZi7O4eRS5YnOx5EQw=; b=KSxj4/ID4ot/qdb2IH3T0vnx9HPJ8vZQTnJvxYpIdrDPANNz1pgXfFJqlem9BT/LJC IM+k2h7Hri+Mqxyk9ddno7wHSLbClE1FF0aSENxqunb8TRE+QjFhdNHQrk/vnE4Vt5Dl jKhdnNzGLiIQH9wLHraFblP8q23K1wpb2JLc/97JngGJz2DUxZRZ+FSIQyna4fgEnA64 vMA4Duf3kCxOa8Lso2/wJyzWegCPIAT8NJ9zW85W+9zxpnf2Jm4enwWpnAqO3V4wTB3u yATc9eXB0fS9WdoligoFzkqca6qwVMIW4V3D057R/xdxYFNBgPASvP41Fm+LH3g35sQS hMbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nSUA/oi5lpmodzeOVvrDJ+6BEjZi7O4eRS5YnOx5EQw=; b=AunPNHkDvz8h1PcrQUoTBZoZtlUljzavI8HiRPserh3R5Uzkv9ymSPY6qI8UhSitxS zKI8Ds9d8BDaIpC/Rpu21uzWPl3HNBmMS6jCNQtm/Gcb0GHwPwV530C5Hq3IBn69lDYV QL62VfenEiI5pOw9xOJhHWAJhQt1UiXDQfbS9q01JzVrR4ojQweon/Gda9pKdWoBLpeo DLHXbYTz9ClXF5wLGwz+lZ9ZCUB7ilVLDzvuKODAdKsTagrRFlVSpocS7/Y/wGUk9d+l 7cDD/Oa9L/1DOm/U7mwf7G0YaGbZcjr2Vquidrdkl1ICGHsJKU4zmeG0ngXFqjgjvbCx OMzw== X-Gm-Message-State: AA6/9RntM4ABe8ZUUAdfJYhyvSlheKCtJxObW4mYGsy2V9MELvDc6sw1SKl8+LUnBsDc4AgiH6i1uWxuPMCQDg== X-Received: by 10.129.125.198 with SMTP id y189mr19249617ywc.234.1475946828431; Sat, 08 Oct 2016 10:13:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Sat, 8 Oct 2016 10:13:07 -0700 (PDT) In-Reply-To: <20161008170605.GB12067@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008170605.GB12067@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sat, 8 Oct 2016 10:13:07 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114926a06ab23d053e5da6e7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Sat, 08 Oct 2016 17:13:50 -0000 --001a114926a06ab23d053e5da6e7 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 8, 2016 at 10:06 AM, Ilari Liusvaara wrote: > On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote: > > > > In the APIs people have been designing, 0-RTT can become 1-RTT but not > the > > other way around. > > Specifically: > > > > - There is an option to allow 0-RTT writing > > - With that option on, SSL_Write() succeeds in both 0-RTT and 1-RTT > modes. > > - There is a callback that tells you when you have gone from 0-RTT to > 1-RTT. > > I really hope I misunderstood what you wrote... > > I understood it as: The TLS client library notifies the application > that it has transitioned on its own, without instruction from client > application from sending 0-RTT data to server to sending 1-RTT data > to the server??? > Approximately. It's a little more subtle than that b/c individual SSL_Write() calls don't cross boundaries, so at any given time you can interrogate what state you're in, but it's really not practical for the client app to tell the stack what state to be in, because the stack responds to receiving the server's Finished by sending end_of_early_data and then its own Finished, so it's not like you can keep it on sending 0-RTT at that point, though of course if you had two APIs, you could generate an error when the client tried to use the wrong one. Can you elaborate on your concern here? -Ekr > > > -Ilari > --001a114926a06ab23d053e5da6e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Oct 8, 2016 at 10:06 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote:
>
> In the APIs people have been designing, 0-RTT can become 1-RTT but not= the
> other way around.
> Specifically:
>
> - There is an option to allow 0-RTT writing
> - With that option on, SSL_Write() succeeds in both 0-RTT and 1-RTT mo= des.
> - There is a callback that tells you when you have gone from 0-RTT to = 1-RTT.

I really hope I misunderstood what you wrote...

I understood it as: The TLS client library notifies the application
that it has transitioned on its own, without instruction from client
application from sending 0-RTT data to server to sending 1-RTT data
to the server???

Approximately.

It's a little more subtle than that b/c individual SS= L_Write() calls don't cross boundaries, so at any
given time = you can interrogate what state you're in, but it's really not pract= ical for the client
app to tell the stack what state to be in= , because the stack responds to receiving the server's
Finish= ed by sending end_of_early_data and then its own Finished, so it's not = like you can
keep it on sending 0-RTT at that point, though of co= urse if you had two APIs, you could
generate an error when the cl= ient tried to use the wrong one.

Can you elaborate= on your concern here?

-Ekr

=C2=A0


-Ilari

--001a114926a06ab23d053e5da6e7-- From nobody Sat Oct 8 10:14:06 2016 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 329431295AD for ; Sat, 8 Oct 2016 10:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RqHeZGjl3oO6 for ; Sat, 8 Oct 2016 10:13:57 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBF41295D4 for ; Sat, 8 Oct 2016 10:13:57 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id w3so21962058ywg.1 for ; Sat, 08 Oct 2016 10:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3XfyMrydbidFjtOoO+Y2BD2C+Bl+Rw2qRYxLsrD0dT0=; b=ZOoGwlVVU0lTgI75pX8uGN5payCQ1Lgvgf+fIamRr4YrS7hmKOUBKDMjKHOhP2fDnB v9grfDIPHXvMifr8uPNCB1iDyBzJAA1Owh4WaWSTCFaRZ4PqD98rZvlUHlhYiLuA8bUP /auyl2Tg82RfWDJA9N0a9b9kRNd+UvMLY4tkOZoI2bIaxKyj1/UdNRR4V/AptVvL2k+g vWerqyEhHV4tdiOS3ZNwjPZJZA8HZZNdPm5myQ5irx1Jk2eIagXDKoGRj1N3PF35Y10o 8wdDSvXTr1PzeF5dU9XoZMw1XWeKoL1ieU14nYP2v8X7dAYRMjukQVixee5aPyInerlF ca8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3XfyMrydbidFjtOoO+Y2BD2C+Bl+Rw2qRYxLsrD0dT0=; b=fA/Dn/ImKHJdtLvqjXoTMzOyUWOO/mIJMpFKXtK2T8kuSqGsasD3QpgduMGK+9JXPI wo3pDkziXfU617i5g42KrMfSmfSZ5BOXDtLRzCJum+AxExN2bs0brudcIQlFeeqRo/q3 QLiScISbvbUL6Gk5XULcmzqgHMBduegY49IQgbHcvoZSefeN3MXu2HNFqs8visOBvF/B +D4n6ILTyLdj09q02ZQ5zzwWT60Qx27CymEWDb4La/O1oWJlT2iPIAj8kxHmlW498VtJ nzhvnmYBNsmWJDOu8t65cB4GEdDE3WJqaUDNM2uHh1KgmydctcthcNrkCatYa3u6+wJL bdCg== X-Gm-Message-State: AA6/9RniI63iwTLPjCfrPvByHxlvz54qE1Wem3XeQtK4ogYUGZw5XAfNYYkeRpTbgFoloiNIosKSuKYmxcBpFNww X-Received: by 10.13.253.134 with SMTP id n128mr22681763ywf.20.1475946836285; Sat, 08 Oct 2016 10:13:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.7 with HTTP; Sat, 8 Oct 2016 10:13:55 -0700 (PDT) In-Reply-To: <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> From: Nick Harper Date: Sat, 8 Oct 2016 10:13:55 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c06a37ae2c15c053e5da621 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Sat, 08 Oct 2016 17:14:03 -0000 --94eb2c06a37ae2c15c053e5da621 Content-Type: text/plain; charset=UTF-8 In my proposed 0-RTT Token Binding draft ( https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01), the signature is the same in 0-RTT data as in 1-RTT data, assuming the server didn't reject early data. The thought here is that a client's write API might look like "please send this data, and I'm fine with it being sent 0-RTT", so the Token Binding code doesn't have to know if its message was sent before or after handshake completion. If early data is rejected, then the application data has to change, but this isn't something limited to Token Binding. A server cold reject early data and also change ALPN from what the client expected, requiring the client to send different data. I think it's fine from an API perspective for data sent 0-RTT to also be sent 1-RTT so long as early data is accepted. On Saturday, October 8, 2016, Ilari Liusvaara wrote: > On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote: > > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara < > ilariliusvaara@welho.com > > > wrote: > > > > > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > > > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > > > > > wrote: > > > > > > > > > > Also, it is very likely that 0-RTT would need its own read API, > because > > > > > it is pretty unlikely that existing API could be safely retrofitted > > > > > or even purpose-built unified API be designed that isn't just > asking > > > > > for security problems via mixing 0-RTT and 1-RTT data. > > > > > > > > Yes. In particular I think the TLS state machine transitions need to > > > > be ordered with respect to the arrival and sending of data. The > > > > challenge for a multithreaded program (yes, some programs have > > > > multiple threads sending and receiving at once) is making this make > > > > sense, or even a single-threaded program where the TLS stack can > > > > change state at times not visible to the sending thread. Maybe there > > > > is some slop here, like 0-RTT can become 1-RTT on send, but this > > > > raises all sorts of problems for receiving. I think we need to > require > > > > separation in the API. > > > > > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- > > > retransmit, which needs to be disableable, as sometimes that just plain > > > won't work). > > > > Can you explain why that is? > > E.g. what they are planning to do with 0-RTT Token Binding in HTTP. > The client puts in a signature into 0-RTT data. If the server rejects > the 0-RTT and the client retransmits, the signature will still be > there but is different. > > Also, if 0-RTT data can silently shift to 1-RTT, it would mean the > server-side model would be to concatenate 0-RTT and 1-RTT data, which > I thought we already established is quite dangerous. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c06a37ae2c15c053e5da621 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In my proposed 0-RTT Token Binding draft (https://tools.ietf.org/html/dra= ft-nharper-0-rtt-token-binding-01), the signature is the same in 0-RTT = data as in 1-RTT data, assuming the server didn't reject early data. Th= e thought here is that a client's write API might look like "pleas= e send this data, and I'm fine with it being sent 0-RTT", so the T= oken Binding code doesn't have to know if its message was sent before o= r after handshake completion. If early data is rejected, then the applicati= on data has to change, but this isn't something limited to Token Bindin= g. A server cold reject early data and also change ALPN from what the clien= t expected, requiring the client to send different data.=C2=A0

I think it's fine from an API perspective for data sent 0-RTT to= also be sent 1-RTT so long as early data is accepted.

On Saturday, = October 8, 2016, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
> > > <ilariliusvaara@welho.com>= wrote:
> > > >
> > > > Also, it is very likely that 0-RTT would need its own r= ead API, because
> > > > it is pretty unlikely that existing API could be safely= retrofitted
> > > > or even purpose-built unified API be designed that isn&= #39;t just asking
> > > > for security problems via mixing 0-RTT and 1-RTT data.<= br> > > >
> > > Yes. In particular I think the TLS state machine transitions= need to
> > > be ordered with respect to the arrival and sending of data. = The
> > > challenge for a multithreaded program (yes, some programs ha= ve
> > > multiple threads sending and receiving at once) is making th= is make
> > > sense, or even a single-threaded program where the TLS stack= can
> > > change state at times not visible to the sending thread. May= be there
> > > is some slop here, like 0-RTT can become 1-RTT on send, but = this
> > > raises all sorts of problems for receiving. I think we need = to require
> > > separation in the API.
> >
> > 0-RTT can't be allowed to become 1-RTT on send (unless it is = auto-
> > retransmit, which needs to be disableable, as sometimes that just= plain
> > won't work).
>
> Can you explain why that is?

E.g. what they are planning to do with 0-RTT Token Binding in HTTP.
The client puts in a signature into 0-RTT data. If the server rejects
the 0-RTT and the client retransmits, the signature will still be
there but is different.

Also, if 0-RTT data can silently shift to 1-RTT, it would mean the
server-side model would be to concatenate 0-RTT and 1-RTT data, which
I thought we already established is quite dangerous.


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--94eb2c06a37ae2c15c053e5da621-- From nobody Sat Oct 8 10:32:25 2016 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 9AE4A129543 for ; Sat, 8 Oct 2016 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 0SWVm5H40UeP for ; Sat, 8 Oct 2016 10:32:21 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA821129466 for ; Sat, 8 Oct 2016 10:32:21 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id r30so75278431ioi.1 for ; Sat, 08 Oct 2016 10:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H4ZKlHT3NY1aHnTJvxySXTekaY+fn6d49yNDuHoQsrI=; b=KIjo8REtYYvvCyhcjyHhnBLcK9B8nM5SXtrWX8Bp3EdPeVoUi8tzvZPV6/l2XP04wQ DMM2NwzUWa26eH7iVDD/ZPzU+CscuDIFoOqCxg4neezX361uYRsJkvqOHzMt09WNSVH/ d3vSBFkFC0l04kF3URG9d70WNs1OvJalO7XTc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H4ZKlHT3NY1aHnTJvxySXTekaY+fn6d49yNDuHoQsrI=; b=PHn+IJ1i2yBgkfyvgsNdYk9YwKNDuwLEjvmTFI/b1FkVEOIKhXHnndhZ68971070r0 MGzZSKjCh4OwEpBIAr/igxG+FDP7kUMmzp0gNtOKX4wK8dGD2Z62Mh2NozILt1UKlhbI b4zP0d9MLc9XZ4fq141AFNUKFeyj3aZF82e/ZY6ld57lWS8N8PJQnO3lr3IELdPMEphX TzqYmF0165uV0iyBhoxr6fxxv3nvVNeRdagCNXIhpItjRMTI4xa643VQl5QzYTV1N+Ew eDfGr4bQJAoc1iNXhvulNVQzImmPa0GC8E97m6/NWVVb7KgNukIKTBLe/QO6H3QRZaz5 VIiw== X-Gm-Message-State: AA6/9RkEuqwmVaFlq7xzgcpVyCjUlulRsBhk+blXUInl3Jhz9kRDo8iaC+P7DRPzOnWYwtsYNypTPyLVdAewbqM1 X-Received: by 10.107.136.232 with SMTP id s101mr25265030ioi.171.1475947940887; Sat, 08 Oct 2016 10:32:20 -0700 (PDT) MIME-Version: 1.0 References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Sat, 08 Oct 2016 17:32:09 +0000 Message-ID: To: Nick Harper , Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113ec3b4b98aba053e5de8a8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Sat, 08 Oct 2016 17:32:24 -0000 --001a113ec3b4b98aba053e5de8a8 Content-Type: text/plain; charset=UTF-8 To add to that, in out-of-order transports, whether a message was sent over 0-RTT or not may not even be very well-defined. If QUIC originally sent data over 0-RTT but had to retransmit it after the full connection parameters are available, I believe it will use those. Even in an in-order transport, imagine if I have a very long replayable request in HTTP/2 (maybe it's a PUT and comes with a request body, or maybe it has too many headers). I start sending that one over 0-RTT. While I'm in the middle of sending that, I get back a ServerHello (w/ early_data) through Finished. I either need to complete the handshake and switch to 1-RTT mid-request or wait for the long request to complete before finishing the handshake or sending any non-replayable ones, though they may be higher priority. (They probably are if they don't come with as giant of response bodies...) The former is by far the more attractive option. Or perhaps I hit max_early_data_size ( https://github.com/tlswg/tls13-spec/pull/674) and thus can't send more 0-RTT data anyway. In HTTP/2 you have the additional amusement that, due to HPACK, your 0-RTT data probably has an effect on the 1-RTT data even if requests are all or nothing. I don't think we can make the receiver aware of the 0-RTT / 1-RTT boundary sanely. In my mind, the decision whether to send something 0-RTT or wait until 1-RTT is primarily the sender's business. If the sender wanted to, it could make the data replayable anyway by just replaying it. On the receiver's side, yeah, you concatenate the streams. That's why the server must decline 0-RTT if any negotiated parameter (ALPN, etc.) changes. David On Sat, Oct 8, 2016 at 1:14 PM Nick Harper wrote: In my proposed 0-RTT Token Binding draft ( https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01), the signature is the same in 0-RTT data as in 1-RTT data, assuming the server didn't reject early data. The thought here is that a client's write API might look like "please send this data, and I'm fine with it being sent 0-RTT", so the Token Binding code doesn't have to know if its message was sent before or after handshake completion. If early data is rejected, then the application data has to change, but this isn't something limited to Token Binding. A server cold reject early data and also change ALPN from what the client expected, requiring the client to send different data. I think it's fine from an API perspective for data sent 0-RTT to also be sent 1-RTT so long as early data is accepted. On Saturday, October 8, 2016, Ilari Liusvaara wrote: On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara > wrote: > > > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > > > wrote: > > > > > > > > Also, it is very likely that 0-RTT would need its own read API, because > > > > it is pretty unlikely that existing API could be safely retrofitted > > > > or even purpose-built unified API be designed that isn't just asking > > > > for security problems via mixing 0-RTT and 1-RTT data. > > > > > > Yes. In particular I think the TLS state machine transitions need to > > > be ordered with respect to the arrival and sending of data. The > > > challenge for a multithreaded program (yes, some programs have > > > multiple threads sending and receiving at once) is making this make > > > sense, or even a single-threaded program where the TLS stack can > > > change state at times not visible to the sending thread. Maybe there > > > is some slop here, like 0-RTT can become 1-RTT on send, but this > > > raises all sorts of problems for receiving. I think we need to require > > > separation in the API. > > > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- > > retransmit, which needs to be disableable, as sometimes that just plain > > won't work). > > Can you explain why that is? E.g. what they are planning to do with 0-RTT Token Binding in HTTP. The client puts in a signature into 0-RTT data. If the server rejects the 0-RTT and the client retransmits, the signature will still be there but is different. Also, if 0-RTT data can silently shift to 1-RTT, it would mean the server-side model would be to concatenate 0-RTT and 1-RTT data, which I thought we already established is quite dangerous. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a113ec3b4b98aba053e5de8a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To add to that, in ou= t-of-order transports, whether a message was sent over 0-RTT or not may not= even be very well-defined. If QUIC originally sent data over 0-RTT but had= to retransmit it after the full connection parameters are available, I bel= ieve it will use those.

Even in an in-order transport, imagine if I hav= e a very long replayable request in HTTP/2 (maybe it's a PUT and comes = with a request body, or maybe it has too many headers). I start sending tha= t one over 0-RTT. While I'm in the middle of sending that, I get back a= ServerHello (w/ early_data) through Finished. I either need to complete th= e handshake and switch to 1-RTT mid-request or wait for the long request to= complete before finishing the handshake or sending any non-replayable ones= , though they may be higher priority. (They probably are if they don't = come with as giant of response bodies...) The former is by far the more att= ractive option.

Or perhaps I hit max_early_data_size (https://github.com/tlswg/tls13-spec/pull/674) and thus can'= ;t send more 0-RTT data anyway.

In HTTP/= 2 you have the additional amusement that, due to HPACK, your 0-RTT data pro= bably has an effect on the 1-RTT data even if requests are all or nothing.<= /div>

I don't think we can make the receiver aware of the 0-RTT / 1= -RTT boundary sanely. In my mind, the decision whether to send something 0-= RTT or wait until 1-RTT is primarily the sender's business. If the send= er wanted to, it could make the data replayable anyway by just replaying it= . On the receiver's side, yeah, you concatenate the streams. That's= why the server must decline 0-RTT if any negotiated parameter (ALPN, etc.)= changes.

=
David


On Sat, Oct 8, 2016 at 1:14 PM Nick Harper <n= harper@google.com> wrote:
In my proposed 0-RTT Token Binding draft (https://tools.ietf.org/html/draft-nharpe= r-0-rtt-token-binding-01), the signature is the same in 0-RTT data as i= n 1-RTT data, assuming the server didn't reject early data. The thought= here is that a client's write API might look like "please send th= is data, and I'm fine with it being sent 0-RTT", so the Token Bind= ing code doesn't have to know if its message was sent before or after h= andshake completion. If early data is rejected, then the application data h= as to change, but this isn't something limited to Token Binding. A serv= er cold reject early data and also change ALPN from what the client expecte= d, requiring the client to send different data.=C2=A0

I think it's = fine from an API perspective for data sent 0-RTT to also be sent 1-RTT so l= ong as early data is accepted.


On Saturday, October 8, 2016, Ilari Liusv= aara <ilariliusvaara@welho.com> wrote:
On Fri, Oct 07, 2016 at 03:04:= 14PM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
> > > <ilariliusvaara@welho.com> = wrote:
> > > >
> > > > Also, it is very likely that 0-RTT would need its own r= ead API, because
> > > > it is pretty unlikely that existing API could be safely= retrofitted
> > > > or even purpose-built unified API be designed that isn&= #39;t just asking
> > > > for security problems via mixing 0-RTT and 1-RTT data.<= br class=3D"gmail_msg"> > > >
> > > Yes. In particular I think the TLS state machine transitions= need to
> > > be ordered with respect to the arrival and sending of data. = The
> > > challenge for a multithreaded program (yes, some programs ha= ve
> > > multiple threads sending and receiving at once) is making th= is make
> > > sense, or even a single-threaded program where the TLS stack= can
> > > change state at times not visible to the sending thread. May= be there
> > > is some slop here, like 0-RTT can become 1-RTT on send, but = this
> > > raises all sorts of problems for receiving. I think we need = to require
> > > separation in the API.
> >
> > 0-RTT can't be allowed to become 1-RTT on send (unless it is = auto-
> > retransmit, which needs to be disableable, as sometimes that just= plain
> > won't work).
>
> Can you explain why that is?

E.g. what they are planning to do with 0-RTT Token Binding in HTTP.
The client puts in a signature into 0-RTT data. If the server rejects
the 0-RTT and the client retransmits, the signature will still be
there but is different.

Also, if 0-RTT data can silently shift to 1-RTT, it would mean the
server-side model would be to concatenate 0-RTT and 1-RTT data, which
I thought we already established is quite dangerous.


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a113ec3b4b98aba053e5de8a8-- From nobody Sat Oct 8 13:03:08 2016 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 3107B1293E8 for ; Sat, 8 Oct 2016 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JQz_7sQLpZuO for ; Sat, 8 Oct 2016 13:03:04 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325C2120726 for ; Sat, 8 Oct 2016 13:03:04 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id j37so77321921ioo.3 for ; Sat, 08 Oct 2016 13:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vqNbUD/sHiQGa2r7eVqJ3i2dAkLmcvMAqtLL4/pPmmg=; b=DbjZfO6Ka03Z8DKE0PS/Ptd0Hl9B1g+DR+onmUSA6ONPoHnrOcpOieeXbChPsDZMX+ 8+VdYNYGWeS5J5LFrMn+9OU9It4Wv416fsOqqkCp5sYQ5H9wSkYH/HqsFD7X3EakfRBE IMW/DdG9DdwrbQranQFQBpBsjlSK+6xOuMaOGQt/EFfXVV05DOxKle1nQ3hG5h7E0dci oLR8rBGPnNjGl1oNPGUSSp1vdeeclJUX5uHihsCZUf/FbI6bxOAM+ZEB3X2qouIdpXNv 4gvf0I2AaKlF1u3W08/K9mB0KKxJde6gE+8pbu0zSZ6EFr4TKZYkt8UsHcQLzEp7pZkp VgTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vqNbUD/sHiQGa2r7eVqJ3i2dAkLmcvMAqtLL4/pPmmg=; b=dCZ/aoGyOHMxK/pZldH5pWGOHUaAaJtT4vCugy1CK64JKCD+ww4S31ZMgMg/tbDfm9 aAPrkeCmtMRzPVy2PyAq2W8xQ/GRAkbUxI3CNwzjCjEvuhLsJfGSZVwepJnj3I5ozArs auCXDn58RNeqPxN9ccr/Pmvw7g3DWvq+ebRO0x0h54pzUbxyMkdKincUBV7eMCIRSl5m IqkBEVj6ha7UZFyNCEYN+AKMJJi++ekBZsTIyMUOKl0ue1o/K7yPDpVriayR8pTbfvRX zpqti6ERqdaKFtklRafdIEv+pk1/MfsLwoMLWb2LiSClCD5DQi6Zp5raMOYaqFION9Mz xGDw== X-Gm-Message-State: AA6/9RnOoHvcfq6P2LtDntvSiV/o0C9lCiR0iKCnHQuwEoBf1ywpbvsWCpdRzrtd8zoY5FNtVhTNFUAohmA/eg== X-Received: by 10.107.188.133 with SMTP id m127mr24656159iof.50.1475956983467; Sat, 08 Oct 2016 13:03:03 -0700 (PDT) MIME-Version: 1.0 References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: Nick Sullivan Date: Sat, 08 Oct 2016 20:02:52 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c05d472b4171e053e6003a2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Sat, 08 Oct 2016 20:03:07 -0000 --94eb2c05d472b4171e053e6003a2 Content-Type: text/plain; charset=UTF-8 I agree that "I don't like NST or KU" is not a very useful thing to add to the spec. I added them as part of a general move towards clarity and conservatism about which types of post-handshake messages are permissible in TLS 1.3. Right now the spec is ambiguous about what each side of the connection is supposed to do when it receives an unexpected or unknown post-handshake message. This change hopefully makes it crystal clear: any post-handshake message that wasn't agreed upon by both parties should be fatal. David suggested that the behavior with respect to post-handshake messages should be negotiated at the application layer. This also seems reasonable, but I worry about how this policy would be communicated from the application layer to the TLS stack. Would the application layer be alerted of incoming CertificateRequests and either terminate the connection or reply with an empty certificate and finished message? If we want to support "2018" post-handshake messages, will we just end up re-inventing this post_handshake extension in a later draft to advertise support? Different post-handshake messages have different uses, so I see how this more case-by-case application-dependent policy could be more expressive than what I proposed, but I worry we may end up with something more complex than necessary. In any case, post-handshake authentication as currently described is problematic. I'd be open to seeing a text change along the lines of what David proposed instead of the wire change I'm proposing as long as it includes some guidance around how it should interact with policies from the application layer. On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla wrote: > I could go either way on this. It seems like this pushes complexity from > the client to the server. > > Consider the case of NST. Presently, a client which doesn't want > resumption can just ignore NST, > but in your proposed change, the server needs to read this extension and > then conditionally send > NST, and the client still needs the logic to detect unexpected handshake > messages and abort > on them. > > As I said, I could go either way, and I do think it's potentially useful > to be able to say "I won't do > post-handshake client auth" and even more useful to be able to say "I > would do post handshake > message X which will be invented in 2018" (but of course we can register > an extension for > that then), but less useful to say "I don't like NST or KU" > > -Ekr > > > On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan > wrote: > > I'm not proposing any new post-handshake authentication mechanisms or > anything relating to HTTP/2 renegotiation in this change. I'm simply making > support for the existing post-handshake messages optional. > > With this change, if the client does not opt in, unexpected > CertificateRequests are fatal to the connection. Same with unexpected > KeyUpdates and SessionTickets. This will hopefully reduce the complexity of > TLS 1.3 implementations that don't need these features. > > Nick > > On Sat, Oct 8, 2016 at 8:06 AM David Benjamin > wrote: > > On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara > wrote: > > On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote: > > > There has been a lot of discussion lately about post-handshake messages > > > that do not contain application data and how to handle them. This PR is > an > > > attempt to make the story more explicit by adding a new post_handshake > > > extension to TLS 1.3. > > > > > > Supporting all types of post-handshake messages can require extra > > > complexity and logic, even when the features that these messages enable > are > > > not needed. Some types of connections/implementations don't need to > support > > > key updates (some unidirectional connections), session tickets (pure PSK > > > implementations) and post-handshake client auth (most browsers). These > are > > > all currently SHOULDs in the spec and they don't need to be. > > > > Post-handshake authentication is the only one of these that is genuinely > > annoying. This is because you can't even reject it without a MAC, that > > additionally continues the handshake hash. > > > > KeyUpdate is rather simple, and NST can just be ignored (leading to some > > waste in bandwidth). > > > Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have > problems with either of the way, while post-handshake auth is indeed > horrific. > > > > Furthermore, the post-handshake authentication mechanism doesn't look to > > be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants, > > And there are serious questions about how it should interact with > > applications. > > > An extension also doesn't really capture things if we intend for, say, > this to be used for legacy protocols like HTTP/1.1 (where we don't have as > rich a framing layer) but not HTTP/2 (where we do and can use it as a > substrate for all this silliness). I was anticipating that, if this ends up > being used in the HTTP world like renego is, it would be like our renego > stuff: off by default, forbidden in HTTP/2, and with all interleave > forbidden. > > Further, what useful thing could a server even do with this extension? > Decline to do post-handshake auth doesn't work. Either the application > protocol doesn't use post-handshake auth (please pick this one) or it does. > One doesn't need to send a client_writes_first extension in HTTP/1.1. > > Post-handshake auth another knob on the TLS <-> application protocol > boundary. This means each application protocol must specify for itself what > post-handshake auth means: what to do with the context field, when it may > be received, what it does to application flow, etc. Then the spec must be > clear that if the application protocol does not opt in, CertificateRequest > is forbidden. A CertificateRequest at an unexpected point (say, half-way > through a HTTP/1.1 body) is also forbidden. Also make it clear this is for > legacy protocols and new ones do not use it. > > This is analogous to how HTTP/2 forbids renego at the spec level. (TLS 1.2 > got the "defaults" for renego wrong.) No one ever wrote down the exact > rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does > this for post-handshake auth should do the same for renego. > > It is a lot of spec work for such a tiny-seeming feature, but this is > consistent with how messy the feature actually is. > > David > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --94eb2c05d472b4171e053e6003a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that "I don't like NST or KU" is not= a very useful thing to add to the spec. I added them as part of a general = move towards clarity and conservatism about which types of post-handshake m= essages are permissible in TLS 1.3. Right now the spec is ambiguous about w= hat each side of the connection is supposed to do when it receives an unexp= ected or unknown post-handshake message. This change hopefully makes it cry= stal clear: any post-handshake message that wasn't agreed upon by both = parties should be fatal.

David suggested that the behavi= or with respect to post-handshake messages should be negotiated at the appl= ication layer. This also seems reasonable, but I worry about how this polic= y would be communicated from the application layer to the TLS stack. Would = the application layer be alerted of incoming CertificateRequests and either= terminate the connection or reply with an empty certificate and finished m= essage? If we want to support "2018" post-handshake messages, wil= l we just end up re-inventing this post_handshake extension in a later draf= t to advertise support? Different post-handshake messages have different us= es, so I see how this more case-by-case application-dependent policy could = be more expressive than what I proposed, but I worry we may end up with som= ething more complex than necessary.

In any case, p= ost-handshake authentication as currently described is problematic. I'd= be open to seeing a text change along the lines of what David proposed ins= tead of the wire change I'm proposing as long as it includes some guida= nce around how it should interact with policies from the application layer.=



On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla <= ekr@rtfm.com> wrote:
I could go ei= ther way on this. It seems like this pushes complexity from the client to t= he server.=C2=A0

Consider the case of NST. Presently, a client which do= esn't want resumption can just ignore NST,
but in your proposed change, the server needs to read this extension and = then conditionally send
NST, and the client s= till needs the logic to detect unexpected handshake messages and abort
on them.

As I said, I could go either = way, and I do think it's potentially useful to be able to say "I w= on't do
post-handshake client auth" = and even more useful to be able to say "I would do post handshake
message X which will be invented in 2018" (b= ut of course we can register an extension for
that then), but less useful to say "I don't like NST or KU"<= /div>

-Ekr

=

<nicholas.sullivan@gmail.com> wrote:<= br class=3D"gmail_msg">
I'm not proposing any new post-handshake authentication mechanisms= or anything relating to HTTP/2 renegotiation in this change. I'm simpl= y making support for the existing post-handshake messages optional.

Wit= h this change, if the client does not opt in, unexpected CertificateRequest= s are fatal to the connection. Same with unexpected KeyUpdates and SessionT= ickets. This will hopefully reduce the complexity of TLS 1.3 implementation= s that don't need these features.

Nick

On Sat, Oct 8, 2016 at 8:06 A= M David Benjamin <davidben@chromium.org> wrote:
On Sat, Oct 8, 2016 = at 5:03 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrot= e:
On= Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote:

> There has been a lot of discussion la= tely about post-handshake messages

> that do not contain application data and how to handle them. Th= is PR is an

> attempt to = make the story more explicit by adding a new post_handshake

> extension to TLS 1.3.

>

> Supporting all types of post-handshake messages can require ex= tra

> complexity and logi= c, even when the features that these messages enable are

> not needed. Some types of connections/imp= lementations don't need to support

> key updates (some unidirectional connections), session tick= ets (pure PSK

> implement= ations) and post-handshake client auth (most browsers). These are

> all currently SHOULDs in the sp= ec and they don't need to be.



Post-handshake authen= tication is the only one of these that is genuinely
=
annoying. This is because you can't even reject= it without a MAC, that

addi= tionally continues the handshake hash.



KeyUpdate is rat= her simple, and NST can just be ignored (leading to some

waste in bandwidth).

Yeah,= after the fix to how KeyUpdate is acked, I don't think we'd have p= roblems with either of the way, while post-handshake auth is indeed horrifi= c.
=C2=A0

Furthermore, the post-handshake authentication mechanism do= esn't look to

be feature= ful enough for kind of post-handshake auth e.g. HTTP/2 wants,

And there are serious questions about how= it should interact with

app= lications.
An extension also doesn't really capture= things if we intend for, say, this to be used for legacy protocols like HT= TP/1.1 (where we don't have as rich a framing layer) but not HTTP/2 (wh= ere we do and can use it as a substrate for all this silliness). I was anti= cipating that, if this ends up being used in the HTTP world like renego is,= it would be like our renego stuff: off by default, forbidden in HTTP/2, an= d with all interleave forbidden.

Further, what useful thing could= a server even do with this extension? Decline to do post-handshake auth do= esn't work. Either the application protocol doesn't use post-handsh= ake auth (please pick this one) or it does. One doesn't need to send a = client_writes_first extension in HTTP/1.1.

Post-handshake auth another knob on the TLS <-> application protoco= l boundary. This means each application protocol must specify for itself wh= at post-handshake auth means: what to do with the context field, when it ma= y be received, what it does to application flow, etc. Then the spec must be= clear that if the application protocol does not opt in, CertificateRequest= is forbidden. A CertificateRequest at an unexpected point (say, half-way t= hrough a HTTP/1.1 body) is also forbidden. Also make it clear this is for l= egacy protocols and new ones do not use it.
<= br class=3D"gmail_msg">
This is analogous to = how HTTP/2 forbids renego at the spec level. (TLS 1.2 got the "default= s" for renego wrong.) No one ever wrote down the exact rules for the c= lient-auth/renego hack in HTTP/1.1, but whatever spec does this for post-ha= ndshake auth should do the same for renego.
<= br class=3D"gmail_msg">
It is a lot of spec w= ork for such a tiny-seeming feature, but this is consistent with how messy = the feature actually is.

David
=

__________________= _____________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls


--94eb2c05d472b4171e053e6003a2-- From nobody Sat Oct 8 16:01:27 2016 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 C471C129400 for ; Sat, 8 Oct 2016 16:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 U5M08sa1jInd for ; Sat, 8 Oct 2016 16:01:21 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105BE129437 for ; Sat, 8 Oct 2016 16:01:21 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id t192so31942848ywf.0 for ; Sat, 08 Oct 2016 16:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8BmngXdHhmDXWq7Cpjef66jcyCsf0GZnyh3PASV6EPI=; b=tQ2PMb9XbIHiSeaodWCrttjFeDI+YgGw8C1QLekZSTBZKORrAtqIBF8Dl2eyw0AYEA /e9FuGRM3JF1WbdIGXH8YHbQWOCUFZAuZ3BfBQU8tyOCsbzN6MUTF/rtV9bU6/0E2vK2 YRmCPaznQvdOhPDYRoJsCT7im+W2MPRIG8PSfNoSSLmcLqICzzJPlzLFtguOKdaBLy79 i+KLN1nZ26MR4kyaUQwDO7y7l8KCraj6WDaDHFUpE1qcxxOeeCzbNJplW2LBcj21i6dQ NCG5y/yFlIi90fUmWypuLShkO/f+Mc5rjBQVWT+5SHVIuxOdrtIU+PYA4VH8qvq16xUx ZPYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8BmngXdHhmDXWq7Cpjef66jcyCsf0GZnyh3PASV6EPI=; b=dGCP2xenWxURGdg1j/POAmVmHByvyRD5SRRo4PekyNLrtfIKImrMan1GkBbqFD2X9o qryvjfAQovZyUuPbMlh79Pba4Kb9Pm4qwwfQpex/jnHu5guRn3aIfGnoIaUXTTiwYpZr 2Tbcyk99ezuPeF8D7VRQl8gg5UkktUmTCJfDqG9qnTuMi48RrJqXjdyFXVtNdno1j9Ru XTZD1ZPySiXk9nlV2Oiw/5DJOytMo4JxHwM9H6GMJMHNSvAieqo3XynKQcSEakHnh0VH Y3wPQU3+uY4JCWHOxZl5zzILzBRR+PQ8wI7WLODGqG8tyALObFdPpJwf1RY+NhsM9K4U DBHg== X-Gm-Message-State: AA6/9RnialA170IVv1fVgaUYxPMwvZrX/AHRBUHwh7wf1PbaEoWE8n4O6pcc2Ze5xJ76uzPGGG4YbBhgQ9tYrw== X-Received: by 10.129.60.10 with SMTP id j10mr22623835ywa.354.1475967680288; Sat, 08 Oct 2016 16:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Sat, 8 Oct 2016 16:00:39 -0700 (PDT) In-Reply-To: References: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com> <82f39c83-0040-cf87-94ae-16c321eecc95@akamai.com> From: Eric Rescorla Date: Sat, 8 Oct 2016 16:00:39 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a1142702648d502053e6281d0 Archived-At: Cc: Filippo Valsorda , aaspring@umich.edu, Filippo Valsorda , "tls@ietf.org" Subject: Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo 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: Sat, 08 Oct 2016 23:01:24 -0000 --001a1142702648d502053e6281d0 Content-Type: text/plain; charset=UTF-8 I agree that this is a good idea. Absent objection, i'm going to merge this PR on Monday On Fri, Oct 7, 2016 at 3:06 PM, David Benjamin wrote: > We were also expecting to want to bound how much traffic a server could be > compelled to skip over without making progress. It actually didn't occur to > me we could let the client know the bounds, rather than just making up a > conservative bound (there's only so much data you can get into an RTT) and > hoping nothing breaks. That's a good idea. > > Units is a little interesting. For those purposes, this limit would kick > in whether or not the early data could be decrypted, so the server-side > limit would be measured in ciphertext, possibly even including record > headers. (Although any inaccuracies in converting could be done by just > advertising an underestimate and breaking peers that send pathologically > silly things like all one-byte records. So it doesn't matter much.) > > On Fri, Oct 7, 2016 at 5:45 PM Benjamin Kaduk wrote: > >> On 10/07/2016 11:57 AM, Filippo Valsorda wrote: >> >> Hello, >> >> Cloudflare's current (not definitive) plan for 0-RTT is essentially to >> decide whether or not to answer to requests in the 0.5 flight on a >> case-by-case basis. That obviously requires reading all of them and >> caching the ones we don't want to answer. >> >> To mitigate the obvious DoS concern we plan to use the ticket age and a >> per-machine replay cache. >> >> However, chatting with Drew (cc'd) we realized that clients could still >> send huge amounts of 0-RTT data that we would have to buffer. Once a >> >> >> Well, "have to" is perhaps a bit of a stretch; the client should be >> prepared to cope reasonably if you abort the connection arbitrarily. >> > > I think the concern is that a well-meaning client may not necessarily do a > retry here and instead read this even as a network error. And if it did, > the next attempt, if there is still a 0-RTT-able ticket available, may hit > this again anyway... > > client sent early data, there's no way to accept only a part of it or to >> verify that the client is not replaying before reading it all. But if we >> were to close the connection after a given amount of data we risk >> failing connections from legal clients. >> >> I propose to add a field max_early_data_size to TicketEarlyDataInfo, to >> inform clients about the maximum amount of 0-RTT data they are allowed >> to send, allowing servers to safely terminate connections that exceed >> it. >> >> >> But this seems like a good idea; I left a couple of ~editorial notes on >> github. >> >> -Ben >> >> >> https://github.com/tlswg/tls13-spec/pull/674 >> >> [Please keep me in the CC of replies] >> >> _______________________________________________ >> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1142702648d502053e6281d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that this is a good idea. Absent objection, i'= m going to merge this PR on Monday

On Fri, Oct 7, 2016 at 3:06 PM, David Benjamin <davidben@chromium.org> wrote:
We were also expecting to want to bou= nd how much traffic a server could be compelled to skip over without making= progress. It actually didn't occur to me we could let the client know = the bounds, rather than just making up a conservative bound (there's on= ly so much data you can get into an RTT) and hoping nothing breaks. That= 9;s a good idea.

Units is a little interesting. For thos= e purposes, this limit would kick in whether or not the early data could be= decrypted, so the server-side limit would be measured in ciphertext, possi= bly even including record headers. (Although any inaccuracies in converting= could be done by just advertising an underestimate and breaking peers that= send pathologically silly things like all one-byte records. So it doesn= 9;t matter much.)

<= /div>
On Fri, Oct 7, 2016 at 5:45 PM Benjamin Kaduk= <bkaduk@akamai.c= om> wrote:
On 10/07/2016 11:57 AM, Filippo Valsorda wrote:
Hello,

Cloudflare's current (not definitive) plan for 0-RTT is essentially to
decide whether or not to answer to requests in the 0.5 flight on a
case-by-case basis. That obviously requires reading all of them and
caching the ones we don't want to answer.

To mitigate the obvious DoS concern we plan to use the ticket age and a
per-machine replay cache.

However, chatting with Drew (cc'd) we realized that clients could still
send huge amounts of 0-RTT data that we would have to buffer. Once a

Well, "have to" is perhaps a bit of a stretch; the client sho= uld be prepared to cope reasonably if you abort the connection arbitrarily.

I think the concern is that a= well-meaning client may not necessarily do a retry here and instead read t= his even as a network error. And if it did, the next attempt, if there is s= till a 0-RTT-able ticket available, may hit this again anyway...

client sent early data, there's no way to accept only a part=
 of it or to
verify that the client is not replaying before reading it all. But if we
were to close the connection after a given amount of data we risk
failing connections from legal clients.

I propose to add a field max_early_data_size to TicketEarlyDataInfo, to
inform clients about the maximum amount of 0-RTT data they are allowed
to send, allowing servers to safely terminate connections that exceed
it.

But this seems like a good idea; I left a couple of ~editorial notes on github.

-Ben


https://github.com/tlswg/tls13-spec/pull/674

[Please keep me in the CC of replies]

_______________________________________________
TLS mailing list
TLS@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/tls

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

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


--001a1142702648d502053e6281d0-- From nobody Sat Oct 8 22:32:39 2016 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 3DD251293F2 for ; Sat, 8 Oct 2016 22:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lMSuUU7BXW6j for ; Sat, 8 Oct 2016 22:32:35 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 13499128E18 for ; Sat, 8 Oct 2016 22:32:34 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-1c-57f9d670fb12 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id FE.1F.03250.F66D9F75; Sun, 9 Oct 2016 07:32:32 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.51]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Sun, 9 Oct 2016 07:32:31 +0200 From: John Mattsson To: Martin Thomson , Nikos Mavrogiannopoulos Thread-Topic: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead Thread-Index: AQHR8m4qJsMuKCEAAE6yNvJM3NZSr6BBziKAgALxGgCAWzlRgA== Date: Sun, 9 Oct 2016 05:32:30 +0000 Message-ID: References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7qG7BtZ/hBnu7DSyunfnHaPHj6FYW i0/nuxgdmD12zrrL7rFkyU8mj/f7rrIFMEdx2aSk5mSWpRbp2yVwZdzct5uxYI9UxYy/PewN jE8kuxg5OSQETCRmPF7C0sXIxSEksJ5RYlrjPTYIZxGjxI3vh1lAqtgEDCTm7mlgA7FFBKIk rr7awgRiMwsoSry/NA+sRlggXuLq7OOMEDUJEvObVzNB2E4St96fZAWxWQRUJM48mgc0h4OD V8Bc4sz6LIhdqxkl7jXOAJvDKRAo0do2A6yeUUBM4vupNVC7xCVuPZnPBHG1gMSSPeeZIWxR iZeP/4HViwroSTz7/JwdIq4ksWL7JUaQXcwCmhLrd+lDjLGW2DhtGjPM+VO6H4KV8woISpyc +YRlAqP4LCTbZiF0z0LSPQtJ9ywk3QsYWVcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbg wS2/DXYwvnzueIhRgINRiYc3IednuBBrYllxZe4hRgkOZiUR3oOXgUK8KYmVValF+fFFpTmp xYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwds8rFPJrf9OlLJHMskypfu3NY8+/ zJ6rcW12YkRu7ru9TZZX5xXwOh16WrfCo/OCru+he8n5d5I9d1aYP3H/NDFsim6AT/HO7TEi nVLHXqWa9f/K/bm6w97k4sU3yr4r7eYunvgs0pLxQtE+DksX4UeqBqoTHjTax6ssdBNZb+ge sX15dukuJZbijERDLeai4kQAZE7IC7wCAAA= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead 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: Sun, 09 Oct 2016 05:32:37 -0000 SGkgTWFydGluLA0KDQogDQpBRVNfMjU2X0NDTV84IHdhcyBub3QgaW4gdGhlIGZpcnN0IHZlcnNp b25zIG9mIHRoZSBkcmFmdCBidXQgYWRkZWQgbGF0ZXINCmFmdGVyIHJlcXVlc3QgZnJvbSBJb1Qg cGVvcGxlIChwcm9iYWJseSBhZnJhaWQgb2YgcXVhbnR1bSBjb21wdXRlcnMpLg0KDQogDQpXaGls ZSBJIHRoaW5rIGl0IG1ha2VzIHZlcnkgbXVjaCBzZW5zZSB0byBoYXZlIHNob3J0IHRhZ3MgaW4g d2lyZWxlc3MNCnJhZGlvLCBJIGRvIG5vdCBrbm93IGhvdyBsYXJnZSBuZWVkIHRoZXJlIGlzIGZv ciBBRVMtMjU2IGluIElvVCBmb3INCmNvbnN0cmFpbmVkIGRldmljZXMsIG9yIGhvdyBsYXJnZSB0 aGUgbmVlZCB3b3VsZCBiZSB0byB0cnVuY2F0ZSB0aGUgdGFnIGluDQp0aGVzZSBjYXNlcy4NCg0K IA0KTXkgY3VycmVudCB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgR3JvdmVy4oCZcyBhbGdvcml0aG0g bWF5IG5ldmVyIGJlIG1vcmUNCmNvc3QtZWZmZWN0aXZlIHRoYW4gYSBjbHVzdGVyIG9mIGNsYXNz aWNhbCBjb21wdXRlcnMsIGFuZCB0aGF0IHF1YW50dW0NCmNvbXB1dGVycyB0aGVyZWZvcmUgbGlr ZWx5IGRvIG5vdCBhZmZlY3QgdGhlIGxpZmV0aW1lIG9mIEFFUy0xMjguDQogDQoNCkkgZG8gbm90 IGhhdmUgYW55IHN0cm9uZyBvcGluaW9ucyByZWdhcmRpbmcga2VlcGluZyBBRVNfMjU2X0NDTV84 IG9yIG5vdC4NCldlIHNob3VsZCBub3QgZ2l2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IEFFUy0yNTYg aXMgbmVlZGVkIGZvciBwcmFjdGljYWwNCnJlc2lzdGFuY2UgdG8gcXVhbnR1bSBjb21wdXRlcnMg YW55dGltZSBzb29uLCBpdCBpcyBob3dldmVyIGEgcmVxdWlyZW1lbnQNCmZvciB1c2UgYnkgVVMg Z292ZXJubWVudC4gQWdyZWUgdGhhdCBBRVNfMTI4X0NDTV84IGFuZCBBRVNfMjU2X0NDTSBzZWVt cw0KbGlrZSB0aGUgYmVzdCBjaG9pY2VzIGluIG1vc3QgY2FzZXMuDQoNCiANCkNoZWVycywNCkpv aG4NCg0KDQoNCk9uIDEyLzA4LzE2IDA4OjI5LCAiVExTIG9uIGJlaGFsZiBvZiBNYXJ0aW4gVGhv bXNvbiIgPHRscy1ib3VuY2VzQGlldGYub3JnDQpvbiBiZWhhbGYgb2YgbWFydGluLnRob21zb25A Z21haWwuY29tPiB3cm90ZToNCg0KPkxvb2tpbmcgYXQgdGhvc2UgZW1haWxzLCBJIGFtIHByb21w dGVkIHRvIHdvbmRlciBpZiBhbnlvbmUgY2FuIGp1c3RpZnkNCj50aGUgZXhpc3RlbmNlIG9mIGEg Y2lwaGVyc3VpdGUgd2l0aCBhIGRvdWJsZS1zaXplZCBrZXkgYW5kIGhhbGYtc2l6ZWQNCj5hdXRo ZW50aWNhdGlvbiB0YWcuICBSRkMgNjY1NSBkb2Vzbid0IHJlYWxseSBleHBsYWluIGhvdyB0aGF0 IGlzIGENCj51c2VmdWwgdGhpbmcuDQo+DQo+T24gMTAgQXVndXN0IDIwMTYgYXQgMTk6MzMsIE5p a29zIE1hdnJvZ2lhbm5vcG91bG9zIDxubWF2QHJlZGhhdC5jb20+DQo+d3JvdGU6DQo+PiBPbiBU dWUsIDIwMTYtMDgtMDkgYXQgMTQ6NDUgLTA0MDAsIFNlYW4gVHVybmVyIHdyb3RlOg0KPj4+IEFs bCwNCj4+Pg0KPj4+IFdlJ3ZlIHJlY2VpdmVkIGEgcmVxdWVzdCBmb3IgZWFybHkgSUFOQSBhc3Np Z25tZW50cyBmb3IgdGhlIDYgY2lwaGVyDQo+Pj4gc3VpdGVzIGxpc3RlZCBpbiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRscy1lY2RoDQo+Pj4gZS1wc2stYWVh ZC8uICBQbGVhc2UgcmVzcG9uZCBiZWZvcmUgQXVndXN0IDIzcmQgaWYgeW91IGhhdmUgY29uY2Vy bnMNCj4+PiBhYm91dCBlYXJseSBjb2RlIHBvaW50IGFzc2lnbm1lbnQgZm9yIHRoZXNlIGNpcGhl ciBzdWl0ZXMuDQo+Pg0KPj4gSSBoYXZlIHByZXZpb3VzbHkgcmFpc2VkIGFuIGlzc3VlIFswXSBv biB0aGVzZSBjaXBoZXJzdWl0ZXMuIFRoZSBzYW1lDQo+PiByZXF1aXJlbWVudCB3YXMgbm90ZWQg YWxzbyBieSBQZXRlciBEZXR0bWFuIGFzIHNvbWV0aGluZyBzcGVjaWFsIGluDQo+PiBbMV0uIEhv d2V2ZXIsIHRoZXJlIGhhcyBiZWVuIG5vIHJlYWN0aW9uIGZyb20gdGhlIGF1dGhvcnMgKG5vdyBp biBDQykuDQo+Pg0KPj4gcmVnYXJkcywNCj4+IE5pa29zDQo+Pg0KPj4gWzBdLiANCj4+aHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90bHMvNFBac2NfRHktYVQyOTlCWXJsQkt2 WnMwQk9RDQo+PiBbMV0uIA0KPj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3Rscy9vbkVrZGdIMzBlWmdXczh2NVJwLUNVcUNIZHMNCj4+DQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gVExTIG1haWxpbmcgbGlzdA0KPj4g VExTQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs cw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ VExTIG1haWxpbmcgbGlzdA0KPlRMU0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzDQoNCg== From nobody Sat Oct 8 23:59:28 2016 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 057C61294B2 for ; Sat, 8 Oct 2016 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hBEvW7QMeeht for ; Sat, 8 Oct 2016 23:59:25 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 E94811294AD for ; Sat, 8 Oct 2016 23:59:24 -0700 (PDT) X-AuditID: c1b4fb30-b87ff70000000cb2-6c-57f9eaca608a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 1C.87.03250.ACAE9F75; Sun, 9 Oct 2016 08:59:23 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.51]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Sun, 9 Oct 2016 08:59:21 +0200 From: John Mattsson To: Dan Harkins , Sean Turner , "Nikos Mavrogiannopoulos" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt Thread-Index: AQHR2pj1k3z3BfHf+k6el32lv2/tSKATLaCAgABguQCAjLIjAA== Date: Sun, 9 Oct 2016 06:59:20 +0000 Message-ID: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> In-Reply-To: <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <940A3AB94A7B794FBEC72B8013998788@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7q+7pVz/DDe5OErdY+u8Li8WPo1tZ LK6samS2+HS+i9GBxWPJkp9MHs92v2TxeL/vKpvHwYOMASxRXDYpqTmZZalF+nYJXBlTXj1n KbiiWHFo+W72BsYnCl2MnBwSAiYStzbfYQWxhQTWM0q83+bfxcgFZC9ilLh67RAbSIJNwEBi 7p4GMFtEoEji+sYdLCA2s4CixPtL88BsYQFniRmnbrN3MbID1bhI3BWGqHaSmPP1Cth4FgEV id3bJ4NN4RUwl7jw4hUTxKr3jBKNNxczgyQ4Bbwllh3cyQhiMwqISXw/tYYJYpW4xK0n85kg bhaQWLLnPDOELSrx8vE/sAWiAnoSzz4/Z4eIK0msPbwd6DQOoF5NifW79CHGWEtsf3iPDeb6 Kd0P2SHuEZQ4OfMJywRG8VlIts1C6J6FpHsWku5ZSLoXMLKuYhQtTi1Oyk03MtJLLcpMLi7O z9PLSy3ZxAiMx4NbfhvsYHz53PEQowAHoxIPb0LOz3Ah1sSy4srcQ4wSHMxKIrwTnwGFeFMS K6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYIxMVfC98fZCelF9 aGtGkFqBZUHCT8tOLoZdNzJzd2x8Xu/4+f0E4WWadybdff/xNcfu6xJXq/+kXfPlfTbzPduP 6GeWBZM62+olDpZ9eb9VfWpNwpKm0onGqn6LX3s3rLqSHz3z3o0TiTf2sC739Z3y2aVTMyr2 rL7rzffrnjb8uqUcEnvj5W0lluKMREMt5qLiRAC9Sc7uwwIAAA== Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt 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: Sun, 09 Oct 2016 06:59:27 -0000 SGkgRGFuLCBTZWFuLCBOaWtvcywNCg0KRmlyc3QsIGxldCBtZSBzdGF0ZSB0aGF0IEkgdGhpbmsg cmVxdWlyaW5nIDEyOC1iaXQga2V5IG1hbmFnZW1lbnQgZm9yDQpBRVMtMTI4IGlzIHF1aXRlIHJl YXNvbmFibGUuDQoNCkhUVFAvMiBbUkZDNzU0MF0gYWxzbyBoYXMgc29tZSByZWxhdGVkIHRleHQg aW4gU2VjdGlvbiA5LjIuMSB0aGF0IGFwcGxpZXMNCndoZW4gVExTIGlzIHVzZWQgZm9yIEhUVFAv Mi4gIkVuZHBvaW50cyBNQVkgdHJlYXQgbmVnb3RpYXRpb24gb2Yga2V5IHNpemVzDQpzbWFsbGVy IHRoYW4gdGhlIGxvd2VyIGxpbWl0cyBhcyBhIGNvbm5lY3Rpb24gZXJyb3IgKFNlY3Rpb24gNS40 LjENCjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzU0MCNzZWN0aW9uLTUuNC4xPikg b2YgdHlwZQ0KSU5BREVRVUFURV9TRUNVUklUWS4iDQoNCg0KSSB0aGluayB0aGlzIGlzIGEgcXVl c3Rpb24gZm9yIFRMUyBpbiBnZW5lcmFsLA0KZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQg c2hvdWxkIGp1c3QgZm9sbG93IHdoYXQgdGhlIFRMUyBXRyBkZWNpZGVzDQphcyB0aGUgZ2VuZXJh bCB3YXkgZm9yd2FyZC4gV2V0aGVyIHRoYXQgaXMgTUFZL1NIT1VMRC9TSEFMTCB0cmVhdCBncm91 cHMNCndpdGggaW5zdWZmaWNpZW50IHNlY3VyaXR5IGFzIGFuIGVycm9yLg0KDQpJIHRoaW5rIHRo ZSByZWFsIHByb2JsZW0gaGVyZSBhcmUgVExTIGxpYnJhcmllcyBzdXBwb3J0aW5nIDEwMjQgTU9E UCBhbmQNCjE2MCBFQ0MgYXQgYWxsLCBzdXBwb3J0IGZvciB0aGVzZSBzaG91bGQgaGF2ZSBiZWVu IHJlbW92ZWQgYmVmb3JlIDIwMTAuDQpOaWtvcyBbMF0gcmVjb21tZW5kcyBhIFJDRiBmb3JiaWRk aW5nIHdlYWsgZWxsaXB0aWMgY3VydmVzIGZyb20gVExTIDEuMg0KKGkuZS4gV2Vha0RIIERpZURp ZURpZSEhISkuIEkgdGhpbmsgdGhpcyBpcyBhIGdyZWF0IGlkZWEgYW5kIG11Y2ggYmV0dGVyDQp0 aGFuIGJ1bmRsaW5nIGl0IGludG8gYSBjb2RlLXBvaW50IGFzc2lnbm1lbnQgUkZDLiAoTXkgY3Vy cmVudCBwbGFucyBmb3INCnRoZSBuZXh0IHVwZGF0ZSBvZiAzR1BQ4oCZcyBUTFMgYW5kIERUTFMg cHJvZmlsZXMgaXMgc2ltcGx5IHRvIGZvcmJpZA0Kc3VwcG9ydCBvZiBhbnl0aGluZyB3ZWFrZXIg dGhhbiAyMDQ4IE1PRFAgYW5kIDI1NS1iaXQgRUNDKS4NCg0KWzBdLiBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3Rscy80UFpzY19EeS1hVDI5OUJZcmxCS3ZaczBCT1ENCg0K DQoNCkNoZWVycywNCkpvaG4NCg0KDQpPbiAxMS8wNy8xNiAyMjoyNiwgIlRMUyBvbiBiZWhhbGYg b2YgRGFuIEhhcmtpbnMiIDx0bHMtYm91bmNlc0BpZXRmLm9yZyBvbg0KYmVoYWxmIG9mIGRoYXJr aW5zQGxvdW5nZS5vcmc+IHdyb3RlOg0KDQo+DQo+ICBJJ20gZ2xhZCBJIGhhdmUgdG8gb3Bwb3J0 dW5pdHkgdG8gbWFrZSB5b3UgaGFwcHkgU2VhbiA6LSkNCj4NCj5PbiBNb24sIEp1bHkgMTEsIDIw MTYgNzo0MCBhbSwgU2VhbiBUdXJuZXIgd3JvdGU6DQo+PiBJIHRoaW5rIEkgY2FuIHRha2UgdGhp cyBiaXQ6DQo+Pg0KPj4gT24gSnVsIDEwLCAyMDE2LCBhdCAwNjo1MSwgUGV0ZXIgRGV0dG1hbg0K Pj48cGV0ZXIuZGV0dG1hbkBib3VuY3ljYXN0bGUub3JnPg0KPj4gd3JvdGU6DQo+Pj4NCj4+PiBJ J20gYWxzbyBjdXJpb3VzIHdoZXRoZXIgdGhlcmUgaXMgYSBwcmVjZWRlbnQgaW4gb3RoZXIgUkZD cyBmb3IgYW4NCj4+PiBleHBsaWNpdCBtaW5pbXVtIGN1cnZlIGJpdHMsIG9yIHBlcmhhcHMgYSBk ZSBmYWN0byBpbXBsZW1lbnRlcidzIHJ1bGU/DQo+Pg0KPj4gSSdkIGJlIGhhcHB5IHRvIGJlIHdy b25nIGhlcmUuIGJ1dCB0byBteSBrbm93bGVkZ2Ugbm8gdGhlcmUncyBub3QgYmVlbg0KPj4gYW4g ZXhwbGljaXQgbWluaW11bSBmb3IgY3VydmUgYml0cy4gIFRoZXJlIGhhdmUgaG93ZXZlciBiZWVu IHNpbWlsYXIgKGF0DQo+PiBsZWFzdCBpbiBteSBub24tY3J5cHRvZ3JhcGhlciBtaW5kKSBmb3Ig UlNBIGtleSBzaXplcyBzbyBpZiB3ZSB3YW50ZWQgdG8NCj4+IGRlZmluZSBhbiBleHBsaWNpdCBt aW5pbXVtIGN1cnZlIGJpdHMgdGhlbiB3ZSBjb3VsZC4NCj4NCj4gIGRyYWZ0LWlldGYtdGxzLXB3 ZC0wNyBpbmNsdWRlcyBhIFJFQ09NTUVOREVEIHByYWN0aWNlIG9mIGVuc3VyaW5nDQo+dGhlIGN1 cnZlcyB1c2VkIHByb3ZpZGUgY29tbWVuc3VyYXRlIHN0cmVuZ3RoIHdpdGggdGhlIGNpcGhlcnN1 aXRlDQo+bmVnb3RpYXRlZC4gU2VjdGlvbiAxMCwgIkltcGxlbWVudGF0aW9uIENvbnNpZGVyYXRp b25zIiwgc2F5czoNCj4NCj4gICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGltcGxlbWVudGF0aW9u cyB0YWtlIG5vdGUgb2YgdGhlIHN0cmVuZ3RoDQo+ICAgZXN0aW1hdGVzIG9mIHBhcnRpY3VsYXIg Z3JvdXBzIGFuZCB0byBzZWxlY3QgYSBjaXBoZXJzdWl0ZSBwcm92aWRpbmcNCj4gICBjb21tZW5z dXJhdGUgc2VjdXJpdHkgd2l0aCBpdHMgaGFzaCBhbmQgZW5jcnlwdGlvbiBhbGdvcml0aG1zLiAg QQ0KPiAgIGNpcGhlcnN1aXRlIHdob3NlIGVuY3J5cHRpb24gYWxnb3JpdGhtIGhhcyBhIGtleWxl bmd0aCBsZXNzIHRoYW4gdGhlDQo+ICAgc3RyZW5ndGggZXN0aW1hdGUsIG9yIHdob3NlIGhhc2gg YWxnb3JpdGhtIGhhcyBhIGJsb2Nrc2l6ZSB0aGF0IGlzDQo+ICAgbGVzcyB0aGFuIHR3aWNlIHRo ZSBzdHJlbmd0aCBlc3RpbWF0ZSBTSE9VTEQgTk9UIGJlIHVzZWQuDQo+DQo+ICBBbmQgSSB3b3Vs ZCBsaWtlIHRvIHRha2UgdGhpcyBvcHBvcnR1bml0eSB0byByZW1pbmQgZXZlcnlvbmUgdGhhdA0K PnRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiBUTFNfRUNESEVfUFNLX1dJVEhfQUVTXzEyOF9H Q01fU0hBMjU2DQo+YW5kIFRMU19FQ0NQV0RfV0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYgaXMgdGhh dCB0aGUgbGF0dGVyIGlzIHJlc2lzdGFudA0KPnRvIGRpY3Rpb25hcnkgYXR0YWNrIGFuZCB0aGUg Zm9ybWVyIGlzIG5vdC4NCj4NCj4gIHJlZ2FyZHMsDQo+DQo+ICBEYW4uDQo+DQo+DQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5UTFMgbWFpbGlu ZyBsaXN0DQo+VExTQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHMNCg0K From nobody Sun Oct 9 00:04:20 2016 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 7CCAD1294AD for ; Sun, 9 Oct 2016 00:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 odaszYH29Wsd for ; Sun, 9 Oct 2016 00:04:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 68B4612948C for ; Sun, 9 Oct 2016 00:04:17 -0700 (PDT) X-AuditID: c1b4fb2d-1c7ff700000009f7-f4-57f9ebefa696 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id AA.9E.02551.FEBE9F75; Sun, 9 Oct 2016 09:04:15 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.51]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Sun, 9 Oct 2016 09:04:15 +0200 From: John Mattsson To: Peter Dettman , "tls@ietf.org" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt Thread-Index: AQHR2pj1k3z3BfHf+k6el32lv2/tSKCgQdoA Date: Sun, 9 Oct 2016 07:04:14 +0000 Message-ID: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> In-Reply-To: <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdQPf965/hBpdPaVg0fVnEZPHpfBej A5PHw1kaHkuW/GQKYIrisklJzcksSy3St0vgynh4bCJLwS/5incrFrA0ME6Q72Lk5JAQMJF4 OO8dSxcjF4eQwHpGiUWPtkM5ixglzi3/zgJSxSZgIDF3TwMbiC0iECxxp+kgmC0s4Cwx49Rt 9i5GdqC4i8RdYYgKI4nGA8fBKlgEVCR+/V7L1MXIwcErYC4xeV4oSFhIoFqi9fJ/ZhCbE6hx 4Ycv7CA2o4CYxPdTa5hAbGYBcYlbT+YzQZwpILFkz3lmCFtU4uXjf6wgtqiAnsSzz8/ZIeJK EmsPg1zPAdSrKbF+lz7EGGuJic3zWCFsRYkp3Q/BynkFBCVOznzCMoFRbBaSbbMQumch6Z6F pHsWku4FjKyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQKj6eCW37o7GFe/djzEKMDBqMTD m5DzM1yINbGsuDL3EKMEB7OSCO/EZ0Ah3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQn lqRmp6YWpBbBZJk4OKUaGOOUkgSFPyoudOdeEqezU9qifL2eCe/O4IkNE939k7d3/r1e/D5Y +s2DZWIf/N3MvjLE33l0T/Wc53bLWenc08oSD1j42K2Mq9zguvZb7FKjCzekuk9un/o97VHB jIj2gLUTohz8UqI8GfP9gtN93qvdZtyVIprmdkZZ32Erw6zD3dd4r7raK7EUZyQaajEXFScC AMhVDESiAgAA Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt 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: Sun, 09 Oct 2016 07:04:19 -0000 SGkgUGV0ZXIsDQoNClllcywgaXQgc2hvdWxkIGVuZCB3aXRoIC4uLlNIQTM4NC4gV2Ugd2lsbCBm aXggdGhpcyBpbiB0aGUgbmV4dCB1cGRhdGUuDQooUmVsYXRlZCBxdWVzdGlvbiBmcm9tIE1hcnRp biBUaG9tcHNvbiBjYW4gYmUgZm91bmQgaW4gWzBdKQ0KDQpDaGVlcnMsDQpKb2huDQoNClswXSBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzIxNTE3 Lmh0bWwNCg0KDQoNCk9uIDEwLzA3LzE2IDEyOjUxLCAiVExTIG9uIGJlaGFsZiBvZiBQZXRlciBE ZXR0bWFuIiA8dGxzLWJvdW5jZXNAaWV0Zi5vcmcNCm9uIGJlaGFsZiBvZiBwZXRlci5kZXR0bWFu QGJvdW5jeWNhc3RsZS5vcmc+IHdyb3RlOg0KDQo+SGksDQo+SSd2ZSBqdXN0IGltcGxlbWVudGVk IHRoZXNlIGNpcGhlcnN1aXRlcyBpbiBCb3VuY3lDYXN0bGUgVExTLCBhbmQgaGF2ZSBhDQo+Y291 cGxlIG9mIHF1ZXN0aW9uczoNCj4NCj5JbiBTZWN0aW9uIDMuLCBzaG91bGQNCj4NCj4gICBUTFNf RUNESEVfUFNLX1dJVEhfQUVTXzI1Nl9DQ01fOF9TSEEyNTYgPSB7MHhUQkQsMHhUQkR9Ow0KPg0K PmVuZCB3aXRoIC4uLlNIQTM4NCBpbnN0ZWFkPw0KPg0KPiAgIEZvciB0aGUgQUVTLTI1NiBjaXBo ZXIgc3VpdGVzLCB0aGUgVExTIFBSRiB3aXRoIFNIQS0zODQgYXMgdGhlIGhhc2gNCj4gICBmdW5j dGlvbiBTSEFMTCBiZSB1c2VkIGFuZCBDbGllbnRzIGFuZCBTZXJ2ZXJzIE1VU1QgTk9UIG5lZ290 aWF0ZQ0KPiAgIGN1cnZlcyBvZiBsZXNzIHRoYW4gMzg0IGJpdHMuDQo+DQo+cmVxdWlyZXMgU0hB Mzg0IGFzIHRoZSBQUkYsIGFuZCBJIGRvbid0IGtub3cgd2hhdCBlbHNlIFNIQTI1NiBjb3VsZA0K PnJlZmVyIHRvIGZvciBhbiBBRUFEIGNpcGhlcnN1aXRlLg0KPg0KPkknbSBhbHNvIGN1cmlvdXMg d2hldGhlciB0aGVyZSBpcyBhIHByZWNlZGVudCBpbiBvdGhlciBSRkNzIGZvciBhbg0KPmV4cGxp Y2l0IG1pbmltdW0gY3VydmUgYml0cywgb3IgcGVyaGFwcyBhIGRlIGZhY3RvIGltcGxlbWVudGVy J3MgcnVsZT8NCj4NCj5SZWdhcmRzLA0KPlBldGUgRGV0dG1hbg0KPg0KPk9uIDI4LzA1LzIwMTYg MTI6MTkgQU0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4+IA0KPj4gQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzDQo+PmRpcmVjdG9yaWVzLg0KPj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg VHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IG9mIHRoZSBJRVRGLg0KPj4gDQo+PiAgICAgICAgIFRp dGxlICAgICAgICAgICA6IEVDREhFX1BTSyB3aXRoIEFFUy1HQ00gYW5kIEFFUy1DQ00gQ2lwaGVy DQo+PlN1aXRlcyBmb3IgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpDQo+PiAgICAgICAg IEF1dGhvcnMgICAgICAgICA6IEpvaG4gTWF0dHNzb24NCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgRGFuaWVsIE1pZ2F1bHQNCj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRs cy1lY2RoZS1wc2stYWVhZC0wMC50eHQNCj4+IAlQYWdlcyAgICAgICAgICAgOiA3DQo+PiAJRGF0 ZSAgICAgICAgICAgIDogMjAxNi0wNS0yNw0KPj4gDQo+PiBBYnN0cmFjdDoNCj4+ICAgIFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBzZXZlcmFsIG5ldyBjaXBoZXIgc3VpdGVzIGZvciB0aGUgVHJhbnNw b3J0DQo+PiAgICBMYXllciBTZWN1cml0eSAoVExTKSBwcm90b2NvbC4gIFRoZSBjaXBoZXIgc3Vp dGVzIGFyZSBhbGwgYmFzZWQgb24NCj4+ICAgIHRoZSBFcGhlbWVyYWwgRWxsaXB0aWMgQ3VydmUg RGlmZmllLUhlbGxtYW4gd2l0aCBQcmUtU2hhcmVkIEtleQ0KPj4gICAgKEVDREhFX1BTSykga2V5 IGV4Y2hhbmdlIHRvZ2V0aGVyIHdpdGggdGhlIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbg0KPj4g ICAgd2l0aCBBc3NvY2lhdGVkIERhdGEgKEFFQUQpIGFsZ29yaXRobXMgQUVTLUdDTSBhbmQgQUVT LUNDTS4gIFBTSw0KPj4gICAgcHJvdmlkZXMgbGlnaHQgYW5kIGVmZmljaWVudCBhdXRoZW50aWNh dGlvbiwgRUNESEUgcHJvdmlkZXMgcGVyZmVjdA0KPj4gICAgZm9yd2FyZCBzZWNyZWN5LCBhbmQg QUVTLUdDTSBhbmQgQUVTLUNDTSBwcm92aWRlcyBlbmNyeXB0aW9uIGFuZA0KPj4gICAgaW50ZWdy aXR5IHByb3RlY3Rpb24uDQo+PiANCj4+IA0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC8NCj4+IA0KPj4gVGhlcmUncyBhbHNv IGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQtMDANCj4+IA0KPj4gDQo+PiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPj5zdWJtaXNzaW9uDQo+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4gDQo+PiBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gVExTIG1haWxpbmcgbGlzdA0KPj4gVExT QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K Pj4gDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5UTFMgbWFpbGluZyBsaXN0DQo+VExTQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90bHMNCg0K From nobody Sun Oct 9 06:58:31 2016 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 3018C12950A for ; Sun, 9 Oct 2016 06:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 UZVS-B63H7Hf for ; Sun, 9 Oct 2016 06:58:26 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8065E129479 for ; Sun, 9 Oct 2016 06:58:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 7295612F79; Sun, 9 Oct 2016 16:58:24 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id S8zzhp4pYBBk; Sun, 9 Oct 2016 16:58:23 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DD285287; Sun, 9 Oct 2016 16:58:23 +0300 (EEST) Date: Sun, 9 Oct 2016 16:58:17 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Sun, 09 Oct 2016 13:58:29 -0000 On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > After the discussion on PR #615, I took another pass at this with some > help from the research community. Please see: > > https://github.com/tlswg/tls13-spec/pull/672 > Also, an observation: This seems to interact in somewhat annoying way with stateless HRR. Basically, CH reconstruction no longer works properly, so one needs to have a freezeable PRF hash (and most implementations of hashes can not be frozen). And server not supporting PSK does not help here. (BTW: Simlar thing comes up if you try to freeze an established TLS session: Currently you need to freeze a hash due to post-handshake authentication, even if you don't support it. Nothing else in TLS 1.2 or 1.3 needs hash freezing for established session). -Ilari From nobody Sun Oct 9 07:11:43 2016 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 7B84C12952B for ; Sun, 9 Oct 2016 07:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 c7yICb-fi-Gp for ; Sun, 9 Oct 2016 07:11:41 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EB81294DD for ; Sun, 9 Oct 2016 07:11:40 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t192so37609569ywf.0 for ; Sun, 09 Oct 2016 07:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GhC0L3HtR2d9CKOChvZ3oxfegsvEhKIRMN1ZVXvhB+8=; b=RU365m6c+OqQ88bRaTmsJF3SDeS4vLqR25UIlnvOI/kayx8d7w447mQryQ+6lsrFhQ T6hsEGK7pGu+MhhdNb2cmOB45GZ2uO3Nniq8FqHyt57t+9q+mdUoL7N3bEiMrdfYDD3j JEeLgU9pgTQZBvyg7FPh2+EK7eeQSI03hE38QIuBxY9Tgy/bbgUhtjNPljK1u50vYZqM MkJfzBurGB/cw7w1Z50geybdikpNNYq8XjlRsY22dXnOJU6iivsHnxKDKlUbBJpPEXmN EzCuJoWMZPpZlZnMe8oS9vA64xL2/YUWq9FGD4VuQKwF2jVraKnxOBpbvLFvc8wJRd1l sWVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GhC0L3HtR2d9CKOChvZ3oxfegsvEhKIRMN1ZVXvhB+8=; b=eV8Bsg+SRnkVxoK5Ge4xgE9Fz/KZVtnIh6j7tmBaVixRNB0dB3DOpa5b/1ik8LB/Rd w5gFjB/UVKsgbM6yScmYn9exmVSRvCnzdrHlPHlS3x2jI7LXsemY3vFXLRU6aOihq+yn nUF/pVVDDX8cinqStb4vhy95levrIDSJSgarcYAJ0o0RWwLPesKq03winCSI0NWJWI0x rncfA847EXqIROjo6RJdfH6cCchExWjLgVK3ESKFfiDyOkL42r39iEidO6lDA7q5O2v2 OubIpUMbNviGJAdgpQo2G4719J24EZWAcQF2nrH7CQMS0otTiEcsHQQspi4reUY02Enm D0qg== X-Gm-Message-State: AA6/9RnsQsYXbcAkX47zbXHprHKgE4n+J+GnGUAp3WBTkUh9hBuTibc6u0obizVITzF0sXOCBGbqzCpH348G/A== X-Received: by 10.129.86.131 with SMTP id k125mr23614088ywb.21.1476022300226; Sun, 09 Oct 2016 07:11:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Sun, 9 Oct 2016 07:10:59 -0700 (PDT) In-Reply-To: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 9 Oct 2016 07:10:59 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1143312ce2e426053e6f38e9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Sun, 09 Oct 2016 14:11:42 -0000 --001a1143312ce2e426053e6f38e9 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara wrote: > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > After the discussion on PR #615, I took another pass at this with some > > help from the research community. Please see: > > > > https://github.com/tlswg/tls13-spec/pull/672 > > > > Also, an observation: This seems to interact in somewhat annoying way > with stateless HRR. > > Basically, CH reconstruction no longer works properly, so one needs to > have a freezeable PRF hash (and most implementations of hashes can not > be frozen). > I've been coming to the conclusion that CH reconstruction is a bad idea. It's tricky to get right and in the common case involves a lot of bloat in the CH (because of duplicating the Key Shares). I think we would be better off just removing it and replacing (rather than appending to ) KeyShares in HRR. This was primarily intended as an attempt to avoid the need to continue the hash in any case. Best, -Ekr And server not supporting PSK does not help here. > > > (BTW: Simlar thing comes up if you try to freeze an established TLS > session: Currently you need to freeze a hash due to post-handshake > authentication, even if you don't support it. Nothing else in TLS > 1.2 or 1.3 needs hash freezing for established session). > > > -Ilari > --001a1143312ce2e426053e6f38e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On= Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> After the discussion on PR #615, I took another pass at t= his with some
> help from the research community. Please see:
>
>=C2=A0 =C2=A0 https://github.com/tlswg/tls13-sp= ec/pull/672
>

Also, an observation: This seems to interact in somewhat annoying wa= y
with stateless HRR.

Basically, CH reconstruction no longer works properly, so one needs to
have a=C2=A0 freezeable PRF hash (and most implementations of hashes can no= t
be frozen).

I've been coming to the= conclusion that CH reconstruction is a bad idea. It's
tricky= to get right and in the common case involves a lot of bloat in the CH
(because of duplicating the Key Shares). I think we would be better o= ff just
removing it and replacing (rather than appending to ) Key= Shares in HRR.
This was primarily intended as an attempt to avoid= the need to continue
the hash in any case.

<= div>Best,
-Ekr


And server not supporting PSK does not help here.


(BTW: Simlar thing comes up if you try to freeze an established TLS
session: Currently you need to freeze a hash due to post-handshake
authentication, even if you don't support it. Nothing else in TLS
1.2 or 1.3 needs hash freezing for established session).


-Ilari

--001a1143312ce2e426053e6f38e9-- From nobody Sun Oct 9 08:45:17 2016 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 695C4129573 for ; Sun, 9 Oct 2016 08:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 xE14hdZOtr1l for ; Sun, 9 Oct 2016 08:45:04 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEBB129572 for ; Sun, 9 Oct 2016 08:45:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 620D811495; Sun, 9 Oct 2016 18:45:02 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id KCaUZ2ZW3iJJ; Sun, 9 Oct 2016 18:45:01 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id E40F121C; Sun, 9 Oct 2016 18:45:01 +0300 (EEST) Date: Sun, 9 Oct 2016 18:44:55 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161009154455.GA13453@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Sun, 09 Oct 2016 15:45:07 -0000 On Sun, Oct 09, 2016 at 07:10:59AM -0700, Eric Rescorla wrote: > On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara > wrote: > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > After the discussion on PR #615, I took another pass at this with some > > > help from the research community. Please see: > > > > > > https://github.com/tlswg/tls13-spec/pull/672 > > > > > > > Also, an observation: This seems to interact in somewhat annoying way > > with stateless HRR. > > > > Basically, CH reconstruction no longer works properly, so one needs to > > have a freezeable PRF hash (and most implementations of hashes can not > > be frozen). > > > > I've been coming to the conclusion that CH reconstruction is a bad idea. > It's > tricky to get right and in the common case involves a lot of bloat in the CH > (because of duplicating the Key Shares). I think we would be better off just > removing it and replacing (rather than appending to ) KeyShares in HRR. > This was primarily intended as an attempt to avoid the need to continue > the hash in any case. > That creates a bit of a edge case, where the server might need to pull client's share accross retry. (Since if group is OK, the group is not included in HRR, which presumably causes the client to blank its KeyShare). Also, doing some size calculations: ClientHello with "smallest group" rule is ~200 bytes with reasonable parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack, it is 265 bytes, but would be 196 with "smallest group" rule). The amount of space needed to freeze (octet) SHA-256 is 32+63+8=103 octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=207 bytes (for full SHA-256 and SHA-384, add one more byte). So if selecting ciphersuite using SHA-384, the state size might be comparable to ClientHello size. -Ilari From nobody Sun Oct 9 08:51:21 2016 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 6FA0212956E for ; Sun, 9 Oct 2016 08:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 O1IEAAYz2tmy for ; Sun, 9 Oct 2016 08:51:17 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13107129459 for ; Sun, 9 Oct 2016 08:51:17 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w3so30956846ywg.1 for ; Sun, 09 Oct 2016 08:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sc1eActxoAFVl/nkRTUIwhzLJ0k63RGA1zZO/QMwW4g=; b=sK0kxLPl8u0q2sPxNxoqmDHOLslYCT9aAlxHLCjMstOgQfcnXT8ZUVIVaof2i3cRP+ fNX7lJdLJg72ukSI+uU4Vszo6x2rImJAgixXKyDdOqP65Q/jZfGg3HUhb+ACVNzkUEmT +sFbbtsN7Ku+LkGVDd4bmT68LAB4IkQl3haOaJqmk8iUqKkrGyOFe5GyNlmP2y88KV9v cpf6VGRuUWLj2lM/LMfSofJ6H6QxvlTVM7iqsgxRJ/Jt+nnhf897TiKAUk8j5/DjZqMZ QhHJJZwmHIhYj11j25IHSulwepZPovmBfA7FeNAvQ7On1lYyh7sm4t8MuGUvgeRHvp2s yzUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sc1eActxoAFVl/nkRTUIwhzLJ0k63RGA1zZO/QMwW4g=; b=OJsK4NeL5wDmLeHRR06HNfZUI2MLK3lLObIxyma1B5l6ZihuYNesYa0cAHAuvJfatk bkBre0hnn0hNlrbA6aZt1il6o9/85kPStiQXWZJGmGYEr7S/hmaC/wS8dDZWri4RyK1f 0JIXrMxlPR8tUyCVQM7754Q62HbtSPASrQer+fElK/GqHE3Xe2SA2wvfQMTs746JCheG 9AyyQZqWEhiGZ78JaN4Y32f8zphltvJqxj7OArSB6kxXVS340ZMWb0N1F7A0+T9qSUWw W8gr3w76aGGc4UuKraa1D9qzJChsEQNwRk0HAJtaHdPc22DtfXel8ystr7wXKe1tzyDF +5FQ== X-Gm-Message-State: AA6/9RkOHeDMvhXI/I5cPOyQMkTZ4/lw2zuz1s7JwpE9WTjCJs1aotJlu0zVcp60mrN6Okcre3Tt3fjR238ctQ== X-Received: by 10.129.86.131 with SMTP id k125mr23993877ywb.21.1476028276350; Sun, 09 Oct 2016 08:51:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Sun, 9 Oct 2016 08:50:35 -0700 (PDT) In-Reply-To: <20161009154455.GA13453@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> <20161009154455.GA13453@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 9 Oct 2016 08:50:35 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1143312c175ca0053e709d74 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Sun, 09 Oct 2016 15:51:19 -0000 --001a1143312c175ca0053e709d74 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 9, 2016 at 8:44 AM, Ilari Liusvaara wrote: > On Sun, Oct 09, 2016 at 07:10:59AM -0700, Eric Rescorla wrote: > > On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > > After the discussion on PR #615, I took another pass at this with > some > > > > help from the research community. Please see: > > > > > > > > https://github.com/tlswg/tls13-spec/pull/672 > > > > > > > > > > Also, an observation: This seems to interact in somewhat annoying way > > > with stateless HRR. > > > > > > Basically, CH reconstruction no longer works properly, so one needs to > > > have a freezeable PRF hash (and most implementations of hashes can not > > > be frozen). > > > > > > > I've been coming to the conclusion that CH reconstruction is a bad idea. > > It's > > tricky to get right and in the common case involves a lot of bloat in > the CH > > (because of duplicating the Key Shares). I think we would be better off > just > > removing it and replacing (rather than appending to ) KeyShares in HRR. > > This was primarily intended as an attempt to avoid the need to continue > > the hash in any case. > > > > That creates a bit of a edge case, where the server might need to pull > client's share accross retry. > > (Since if group is OK, the group is not included in HRR, which presumably > causes the client to blank its KeyShare). > I think we would change that rule, probably. -Ekr > > > Also, doing some size calculations: > > ClientHello with "smallest group" rule is ~200 bytes with reasonable > parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack, > it is 265 bytes, but would be 196 with "smallest group" rule). > > The amount of space needed to freeze (octet) SHA-256 is 32+63+8=103 > octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=207 > bytes (for full SHA-256 and SHA-384, add one more byte). > > So if selecting ciphersuite using SHA-384, the state size might be > comparable to ClientHello size. > > > -Ilari > --001a1143312c175ca0053e709d74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 9, 2016 at 8:44 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Sun, Oct 09, 2016 at 07:10:59AM -0700, Eric Rescorla wrote:
> On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > After the discussion on PR #615, I took another pass at this= with some
> > > help from the research community. Please see:
> > >
> > >=C2=A0 =C2=A0 https://github.com/tlswg/tls13-spec/pull/672
> > >
> >
> > Also, an observation: This seems to interact in somewhat annoying= way
> > with stateless HRR.
> >
> > Basically, CH reconstruction no longer works properly, so one nee= ds to
> > have a=C2=A0 freezeable PRF hash (and most implementations of has= hes can not
> > be frozen).
> >
>
> I've been coming to the conclusion that CH reconstruction is a bad= idea.
> It's
> tricky to get right and in the common case involves a lot of bloat in = the CH
> (because of duplicating the Key Shares). I think we would be better of= f just
> removing it and replacing (rather than appending to ) KeyShares in HRR= .
> This was primarily intended as an attempt to avoid the need to continu= e
> the hash in any case.
>

That creates a bit of a edge case, where the server might need to pu= ll
client's share accross retry.

(Since if group is OK, the group is not included in HRR, which presumably causes the client to blank its KeyShare).

I think we would change that rule, probably.

-E= kr
=C2=A0


Also, doing some size calculations:

ClientHello with "smallest group" rule is ~200 bytes with reasona= ble
parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack,
it is 265 bytes, but would be 196 with "smallest group" rule).
The amount of space needed to freeze (octet) SHA-256 is 32+63+8=3D103
octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=3D207 bytes (for full SHA-256 and SHA-384, add one more byte).

So if selecting ciphersuite using SHA-384, the state size might be
comparable to ClientHello size.


-Ilari

--001a1143312c175ca0053e709d74-- From nobody Sun Oct 9 13:24:09 2016 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 B6A4F1295BD for ; Sun, 9 Oct 2016 13:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hOrqEAETYFVy for ; Sun, 9 Oct 2016 13:24:06 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104EF12944A for ; Sun, 9 Oct 2016 13:24:06 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id u124so60294903ywg.3 for ; Sun, 09 Oct 2016 13:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CmNI5mFDv8bnXQwUNk9ZLOiO4g44EnzCw48hoI8+rFI=; b=kR1+6/oOr+zv4pLgA3QUofOuOz167xPaLpY8xrNtgpMJxtpIAej42o4TQTHcs3PzDN DPwtmYiuicFQPkgfM+t1MnFv5zfCj0MFB/NyE6nF4t051Cw1FPqYTRSVMIxEjv+NW6Gj WWaTlpMmchKG5b4wifeKNFvJVI5fzIr0OaZ4W0gq6CPE2cgYgir4Sau8jjDopkcXXC1U 28EsBM55fEgBx+aezw+d0+hbcRGf776ljaV6L2f7zro61ltBsk5HJ248+nIIT+AOQnNq 8XYWxlBvtJMbNXnnfNc53X7OAPn4O1/v9QqcXgz3oT8ZsWWmivO9oNKIUwxgvu84TrM2 MnBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CmNI5mFDv8bnXQwUNk9ZLOiO4g44EnzCw48hoI8+rFI=; b=D/wtjvsno1EMqsGZmR+SWEG0/LczN4MivVJD9peHXmGFsMlsA48mKVN0+gWfqU89OY jSKIpRWXfD7MhkeejMa3R+O2L/uSbpirOxNHEIzXPhADoIQSc9xYCbpxGnITFLxqObcf cjSjNoNjHREaK/yAuqilZrv3o/QrCwe5/l7f9RFFioA5WNyQyPfKWRm8LMIn++xy/h2E EFpdlx64fNRQG1ERALopkuHjoSjSdtM2rnmMfO2sPo8D5xjj779q4QJl6GpZntUUdK4C xqiB4QPVQ9sd/ceUZhZixmxlF+6tGJLTN2zbOcxdWXZxLgU0RQfNKsrkcbn14SwcddRI Tu8g== X-Gm-Message-State: AA6/9RlSYb8OPAhBCs+ek/cfi8P+p5Z9hrowBP+dwJinnOArNBhKRhwzOR1PvkONm6ggALiZdC6rzI0Jmu8DKA== X-Received: by 10.13.249.135 with SMTP id j129mr26850055ywf.267.1476044645253; Sun, 09 Oct 2016 13:24:05 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.37.132 with HTTP; Sun, 9 Oct 2016 13:23:34 -0700 (PDT) In-Reply-To: References: <20161007152628.GA9408@LK-Perkele-V2.elisa-laajakaista.fi> <20161007170323.GA9856@LK-Perkele-V2.elisa-laajakaista.fi> From: Hugo Krawczyk Date: Sun, 9 Oct 2016 16:23:34 -0400 X-Google-Sender-Auth: v-e1oG-7Mr2Mhw8xG-LhxVABAzs Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c082696c0ca30053e746c27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Sun, 09 Oct 2016 20:24:08 -0000 --94eb2c082696c0ca30053e746c27 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2016 at 1:08 PM, Eric Rescorla wrote: > > > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > wrote: > >> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote: >> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara < >> ilariliusvaara@welho.com> >> > wrote: >> > >> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: >> > > > 4. I've taken a suggestion from David Benjamin to move the >> negotiation >> > > > of the PSK key exchange parameters out of the PSK itself and into = a >> > > > separate message. This cleans things up and also lets us drop the >> > > > currently non-useful auth_mode parameter. >> > > >> > > Eeh... From the text, it seems to currently require the kex modes >> > > extension if PSK extension is present. Which seems worse than useles= s >> > > if the meaning is to get rid of the kex mode parameter from PSK >> > > extension (since you will have the value anyway, but need to dig it >> > > from another extension... Blech). >> > >> > I guess this is a matter of taste, but what convinced me was that: >> > >> > 1. It put all the logic on the server side. >> > 2. It removed the auth mod parameter. >> > >> > Maybe david can say more. >> >> I mean if server is to accept PSK, it must now go fishing for another >> extension, check that it is present and pay attention to values there. >> As opposed to having the data in where it is needed. >> > > This is a reasonable argument (and the reason I stuffed the binder here). > However, David's argument was that this applied to *all* PSKs even new > ones. > > > -Ekr > > > > Also, didn't notice what prevents pathology like this (I presume this >> > > is not allowed): >> > > >> > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) >> > > >> > > ClientHello[Ciphers=3DCHACHA20-POLY1305-SHA256, EarlyDataIndication] >> ---> >> > > [0-RTT data, encrypted using AES-128-GCM-SHA256] >> > > <-- ServerHello[Cipher=3DCHACHA20-POLY1305-SHA256] >> > > <-- EncryptedExtensions[EarlyDataIndication] >> > > >> > > Note the record protection algorithm mismatch. >> > > >> > >> > Yes, this is forbidden by the combination of: >> > >> > "The parameters for the 0-RTT data (symmetric cipher suite, >> > ALPN, etc.) are the same as those which were negotiated in the >> connection >> > which established the PSK. The PSK used to encrypt the early data >> > MUST be the first PSK listed in the client's "pre_shared_key" >> extension." >> > (though I think I just recently added cipher suite). >> > >> > and: >> > "Any ticket MUST only be resumed with a cipher suite that is identical >> > to that negotiated connection where the ticket was established." >> >> If 0-RTT is used with manually provisioned PSKs (might not be allowed >> currently, but might be allowed soon), does that still hold? >> >> Also, I think it is problematic that externally provisioned PSKs can >> be used with any protection with given prf-hash, while NST-provisioned >> PSKs can only be used with one protection and prf-hash. >> >> 0-RTT requirements are separate matter, since those would apply to all. >> >> The original purpose of resumption-as-PSK was AFAIK to unify the two >> mechanisms to simplify things. Therefore those two should be as similar >> as possible. >> >> > >> > Also, to straightforwardly prove that collision resistance of HKDF and >> > > HMAC (as used) follows from collision resistance of the underlying >> hash >> > > function, yon need to take the output to be at least the hash output >> > > size. As otherwise it is not guaranteed that any collision in HKDF o= r >> > > HMAC can be reduced into collision of the underlying hash. >> > > >> > >> > Right. I have some text here but please feel free to suggest more. >> >> Yes, but the text says 256 bit output is enough. One isn't guaranteed >> to be able to reduce such collision to collision of >256 bit hash. >> >> (In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely >> unlikely to reduce). >> > > Right. I can update. > =E2=80=8B =E2=80=8BI think that allowing truncation (e.g. for SHA-512) with at least = 256-bit output should be fine too without forcing implementations to work with, say, 512-bit keys. While I agree that we don't have generic reductions from collision resistance of a hash function to its truncations, such (long enough) truncations are believed to inherit collision resistance. For example, SHA-512 is "officially" allowed to be truncated and it is the way SHA-384 is defined. Also, a collision on a 256-bit truncated output would be a MAJOR weakness for any hash function, in particular "breaking" the treatment of the function as a random oracle (such weakness must lead to abandoning that hash function). What do cryptanalysts think? Hugo =E2=80=8B =E2=80=8B > > -Ekr > > >> >> >> >> -Ilari >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c082696c0ca30053e746c27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 7, 2016 at 1:08 PM, Eric Rescorla <ekr@rtfm.co= m> wrote:


On Fri, Oct 7, 2016 at 10= :03 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wr= ote:
On Fri, Oct= 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <ilariliusvaara@welho.com>= ;
> wrote:
>
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > 4. I've taken a suggestion from David Benja= min to move the negotiation
> > > of the PSK key exchange parameters out of the PSK itself and= into a
> > > separate message. This cleans things up and also lets us dro= p the
> > > currently non-useful auth_mode parameter.
> >
> > Eeh... From the text, it seems to currently require the kex modes=
> > extension if PSK extension is present. Which seems worse than use= less
> > if the meaning is to get rid of the kex mode parameter from PSK > > extension (since you will have the value anyway, but need to dig = it
> > from another extension... Blech).
>
> I guess this is a matter of taste, but what convinced me was that:
>
> 1. It put all the logic on the server side.
> 2. It removed the auth mod parameter.
>
> Maybe david can say more.

I mean if server is to accept PSK, it must now go fishing for anothe= r
extension, check that it is present and pay attention to values there.
As opposed to having the data in where it is needed.
<= br>
This is a reasonable argument (and the reason I stuffe= d the binder here).
However, David's argument was that this a= pplied to *all* PSKs even new ones.


-Ekr

> > Also, didn't notice what prevents pathology like this (I pres= ume this
> > is not allowed):
> >
> > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)
> >
> > ClientHello[Ciphers=3DCHACHA20-POLY1305-SHA256, EarlyDataInd= ication] --->
> > [0-RTT data, encrypted using AES-128-GCM-SHA256]
> > <-- ServerHello[Cipher=3DCHACHA20-POLY1305-SHA256]
> > <-- EncryptedExtensions[EarlyDataIndication]
> >
> > Note the record protection algorithm mismatch.
> >
>
> Yes, this is forbidden by the combination of:
>
> "The parameters for the 0-RTT data (symmetric cipher suite,
> ALPN, etc.) are the same as those which were negotiated in the connect= ion
> which established the PSK.=C2=A0 The PSK used to encrypt the early dat= a
> MUST be the first PSK listed in the client's "pre_shared_key&= quot; extension."
> (though I think I just recently added cipher suite).
>
> and:
> "Any ticket MUST only be resumed with a cipher suite that is iden= tical
> to that negotiated connection where the ticket was established."<= br>
If 0-RTT is used with manually provisioned PSKs (might not be allowe= d
currently, but might be allowed soon), does that still hold?

Also, I think it is problematic that externally provisioned PSKs can
be used with any protection with given prf-hash, while NST-provisioned
PSKs can only be used with one protection and prf-hash.

0-RTT requirements are separate matter, since those would apply to all.

The original purpose of resumption-as-PSK was AFAIK to unify the two
mechanisms to simplify things. Therefore those two should be as similar
as possible.

>
> Also, to straightforwardly prove that collision resistance of HKDF and=
> > HMAC (as used) follows from collision resistance of the underlyin= g hash
> > function, yon need to take the output to be at least the hash out= put
> > size. As otherwise it is not guaranteed that any collision in HKD= F or
> > HMAC can be reduced into collision of the underlying hash.
> >
>
> Right. I have some text here but please feel free to suggest more.

Yes, but the text says 256 bit output is enough. One isn't guara= nteed
to be able to reduce such collision to collision of >256 bit hash.

(In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely
unlikely to reduce).

Right.= I can update.


=E2=80=8B
=E2=80=8BI think tha= t allowing truncation (e.g. for SHA-512) with at least 256-bit output shoul= d be fine too without forcing implementations to work with, say, 512-bit ke= ys.
While I agree that we don't have generic reductions from collisi= on resistance of a hash function to its truncations, such (long enough) tru= ncations are believed to inherit collision resistance. For example, SHA-512= is "officially" allowed to be truncated and it is the way SHA-38= 4 is defined. Also, a collision on a 256-bit truncated output would be a MA= JOR weakness for any hash function, in particular "breaking" the = treatment of the function as a random oracle (such weakness must lead to ab= andoning that hash function).

What d= o cryptanalysts think?

Hugo
=E2=80=8B
=C2=A0=E2=80=8B
=C2=A0
=

-Ekr
=C2=A0



-Ilari


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


--94eb2c082696c0ca30053e746c27-- From nobody Sun Oct 9 16:11:40 2016 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 3F07C129406 for ; Sun, 9 Oct 2016 16:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jecL6WwHsD05 for ; Sun, 9 Oct 2016 16:11:36 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0A9127ABE for ; Sun, 9 Oct 2016 16:11:36 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id f128so66260390qkb.1 for ; Sun, 09 Oct 2016 16:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MyHmGgn7wWQ4fmaYXfbooG8VbIIxfYpFbf1AjzwNncg=; b=sVtzDA4RI9j7HQ39scrgKqjiCqypAYvKsrcqovHfzIXX/LkAahuQa+DkIZi/G/ChJx ZzL9abT1nw0/ndX+LQtoPA5l9Z5fjZOgakMAO6b601f9HuAhYGccJuphrk2URAu/XhiQ SHecsra+HX5S/ppqNqOpBLroV6G3pTseMCZvrbBq9G0p0giuAUcLM34oUPvyez1Romxd jfG+nuOhRChcA1HUsCyc+xCqfyNtCA+Fl5RZ52PcI58BHofaOGJXWGC3SvI4UgteXxgw BgQ9qwmA/DNLKnnInYvuPWMTNAuurxaCMaNwDl8VxorN0+pIQrdurY27tRmZhzbV2PEU Gykg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MyHmGgn7wWQ4fmaYXfbooG8VbIIxfYpFbf1AjzwNncg=; b=LgC08ZnFO+XsrMgaf52EmEPaPLKp/8kL7En9rX4aIompeqJ5zsB+7/KPsTNYVL6kcj kBE66KzOuTE6ee3/KR4b32X3N6an6/mCVj0/xgjLen1buIWpgWPG+D8UzDRkyjOpo/zT LOs/rkjtwz6c9Wyky1OZWtJ1RE7kQH/onKdxnjg394xVSs+JvJOo3BvSAWJ26NcMHTij AxQGQgEDaq/FDcgpui33UUfHpURKE8T8BhUgKY7co5VCNLu0stmyOEaHF00rEvU5noUN I/8D7lg8cAj2cwWUDcxMj5qM9HYA+mUxU9RTEhcN1ojFN/F7p5eoBby64naIcMqMS6d4 TlDQ== X-Gm-Message-State: AA6/9RllWkenwuK6Y0yVEeXtISjNgCzhBWIDz2sg6VdOFllDy+4voXzn8+OtPNXrOSMaqEWoQpRJmrKsT1Bxew== X-Received: by 10.55.74.6 with SMTP id x6mr20963135qka.316.1476054695339; Sun, 09 Oct 2016 16:11:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 9 Oct 2016 16:11:34 -0700 (PDT) In-Reply-To: References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> From: Martin Thomson Date: Mon, 10 Oct 2016 10:11:34 +1100 Message-ID: To: John Mattsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead 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: Sun, 09 Oct 2016 23:11:38 -0000 I'm mainly just looking to economize on different configurations. On 9 October 2016 at 16:32, John Mattsson wrot= e: > Hi Martin, > > > AES_256_CCM_8 was not in the first versions of the draft but added later > after request from IoT people (probably afraid of quantum computers). > > > While I think it makes very much sense to have short tags in wireless > radio, I do not know how large need there is for AES-256 in IoT for > constrained devices, or how large the need would be to truncate the tag i= n > these cases. > > > My current understanding is that Grover=E2=80=99s algorithm may never be = more > cost-effective than a cluster of classical computers, and that quantum > computers therefore likely do not affect the lifetime of AES-128. > > > I do not have any strong opinions regarding keeping AES_256_CCM_8 or not. > We should not give the impression that AES-256 is needed for practical > resistance to quantum computers anytime soon, it is however a requirement > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seems > like the best choices in most cases. > > > Cheers, > John > > > > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" on behalf of martin.thomson@gmail.com> wrote: > >>Looking at those emails, I am prompted to wonder if anyone can justify >>the existence of a ciphersuite with a double-sized key and half-sized >>authentication tag. RFC 6655 doesn't really explain how that is a >>useful thing. >> >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos >>wrote: >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: >>>> All, >>>> >>>> We've received a request for early IANA assignments for the 6 cipher >>>> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh >>>> e-psk-aead/. Please respond before August 23rd if you have concerns >>>> about early code point assignment for these cipher suites. >>> >>> I have previously raised an issue [0] on these ciphersuites. The same >>> requirement was noted also by Peter Dettman as something special in >>> [1]. However, there has been no reaction from the authors (now in CC). >>> >>> regards, >>> Nikos >>> >>> [0]. >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ >>> [1]. >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >>_______________________________________________ >>TLS mailing list >>TLS@ietf.org >>https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Oct 10 06:44:36 2016 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 DD7961296D5 for ; Mon, 10 Oct 2016 06:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 sWaihzCXmPFG for ; Mon, 10 Oct 2016 06:44:32 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCF81296CC for ; Mon, 10 Oct 2016 06:44:32 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3st1ZQ57Mpz1HpS; Mon, 10 Oct 2016 15:44:30 +0200 (CEST) X-purgate-ID: 152705::1476107070-0000521C-049B5A1D/0/0 X-purgate-size: 854 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3st1ZP6w9QzkmnZ; Mon, 10 Oct 2016 15:44:29 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id E12881A559; Mon, 10 Oct 2016 15:44:29 +0200 (CEST) In-Reply-To: To: Geoffrey Keating Date: Mon, 10 Oct 2016 15:44:29 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161010134429.E12881A559@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] CertficateRequest extension encoding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Mon, 10 Oct 2016 13:44:35 -0000 Geoffrey Keating wrote: > > A typical macOS system will have many issued certs, typically with at > most one that will work for any particular web site or web API. So > the filter is somewhat important for client certs to work there in any > kind of user-friendly way. In particular if the server provides no > guidance, the UI will ask the user, presenting a dialog containing > many certificates the user is not aware they have, leading to complete > user confusion. In the past, Safari on MAC entirely ignored the server-asserted contents of certificate_authorities in the TLS CertificateRequest handshake message, and would offer *all* possible client certs to the user. Has this bug been fixed in Safari? I remember customer messages where clients were refused that were erroneously sending AppleID client certs... -Martin From nobody Mon Oct 10 12:22:34 2016 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 7A29B129471 for ; Mon, 10 Oct 2016 12:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=filippo.io header.b=eDv87F5Z; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=dH7pshKn 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 1AfuYLl7VWxF for ; Mon, 10 Oct 2016 12:22:32 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16918129451 for ; Mon, 10 Oct 2016 12:22:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7BA6520817; Mon, 10 Oct 2016 15:22:31 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute3.internal (MEProxy); Mon, 10 Oct 2016 15:22:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=filippo.io; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ZuIrQUSeT36J+Dp+7maWZsU8UZg=; b=eDv87F 5ZUaC08ppr0dHxv5r0pKvq14gY7MvblfBvo3p745SDRWzaaNtyL7Pe+fewl01i6t IDfIr87ONcTxCWqaLoWxuvYKbwcUdZzwDfM7sWX/8EGxyaQ4lER3Db9BbJUa5l1+ OfRTMB2LifjoMCGhgB6AKig1M60GJ71LgSpJI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ZuIrQUSeT36J+Dp +7maWZsU8UZg=; b=dH7pshKnoBwu3GSRhcFcVw0maZWpdHCV4pq4k1CI9dIxtRk xRSJQEyXuCHjtyWyhWbYBGFTx+q70UYTtSqSmjcdT4NURAN4OitHCFNsJCN1OfBI EjowmGX5OhU5xTEXH0PBsj7pF7PKX2k66AtJMecBupfVkPmaNRoPUSbm4jcw= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5673296EA2; Mon, 10 Oct 2016 15:22:31 -0400 (EDT) Message-Id: <1476127351.3937248.751550105.203AFB6D@webmail.messagingengine.com> X-Sasl-Enc: nroqix70MdJU+4IN1TRRXOGRkQte22G6P8fQLqeeIluN 1476127351 From: Filippo Valsorda To: David Benjamin , Benjamin Kaduk , tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_147612735139372480"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdbff290 Date: Mon, 10 Oct 2016 20:22:31 +0100 In-Reply-To: References: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com> <82f39c83-0040-cf87-94ae-16c321eecc95@akamai.com> Archived-At: Cc: filippo@cloudflare.com, aaspring@umich.edu Subject: Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo 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: Mon, 10 Oct 2016 19:22:33 -0000 This is a multi-part message in MIME format. --_----------=_147612735139372480 Content-Transfer-Encoding: 7bit Content-Type: text/plain 2016-10-07 22:06 GMT+0000 David Benjamin : > Units is a little interesting. For those purposes, this limit would > kick in whether or not the early data could be decrypted, so the server- > side limit would be measured in ciphertext, possibly even including > record headers. (Although any inaccuracies in converting could be done > by just advertising an underestimate and breaking peers that send > pathologically silly things like all one-byte records. So it doesn't > matter much.) Yeah, I've been thinking about that. I went for plaintext because it seemed to simplify the API on the client side, but maybe it's best to count the whole record size, and let the client worry about not doing some silly splitting or padding. I'll update the PR. --_----------=_147612735139372480 Content-Transfer-Encoding: 7bit Content-Type: text/html
2016-10-07 22:06 GMT+0000 David Benjamin <davidben@chromium.org>:
Units is a little interesting. For those purposes, this limit would kick in whether or not the early data could be decrypted, so the server-side limit would be measured in ciphertext, possibly even including record headers. (Although any inaccuracies in converting could be done by just advertising an underestimate and breaking peers that send pathologically silly things like all one-byte records. So it doesn't matter much.)

Yeah, I've been thinking about that. I went for plaintext because it seemed to simplify the API on the client side, but maybe it's best to count the whole record size, and let the client worry about not doing some silly splitting or padding.

I'll update the PR.
--_----------=_147612735139372480-- From nobody Mon Oct 10 13:49:17 2016 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 26EB812974E for ; Mon, 10 Oct 2016 13:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8sepjhXkmrv5 for ; Mon, 10 Oct 2016 13:49:13 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF79D1293FE for ; Mon, 10 Oct 2016 13:49:12 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id o68so2396345qkf.3 for ; Mon, 10 Oct 2016 13:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a0X3VVyXPuNXwfhFCHVWtax2H3B8ZvpuB9DIZHGiob4=; b=M8XeqlU+WITY3gFDJFDOIKN82JV1VaJ+jGqqRzkyNglsH8cijZ2Qg/Nw6ADeBHR++z llV4raH3ZsbqhbEai3i/rktD8MR6uZFjnB3i4k1ShHUT+nteLfzVvNYGNZCrEoPj/Dg/ H9qGQFT1n8lQMeGsJ/RSFK/OxB18je4ErDR9zQGNXP3ZYdj1VpLtmKTpzskMIZ2MfRxx V1Gtv+KdB3nEU/8WIvCRFAq1mZ94S8FfXOASwkKRHB4ZNfZHl+vCdCpoa1jPZgg3Sa/k SBqx1RklYHkhga4WkcPNfpDPJNRbYi+IYdTUFDAaCcQYWQc38+6CX0qDW7+c2Z98t9SB egew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a0X3VVyXPuNXwfhFCHVWtax2H3B8ZvpuB9DIZHGiob4=; b=HngSSWa5duDSXztEOzZg8yjZEmMbO1Jtky5VJSklaNkMkAVd3cQTRCGkefTr7noeT/ pLUR/FWJgzIoH11yk2vmsWd2F72ojgnrsNfbynga69y/reo67se11iVF8fytWSXrZiRr w4LxlOkt+QF7FS7fYWLVissuCDx7oPqathLuYL4K4iO4B1fTTtHX66I0yvxmzpeJ47gH mk2ygzd1T51QHVVJu+Hkx7MCWGvv8zc6RTbkGKyBnCG6OywpIGA1lk78fRnwndUALi03 5KLr5PnjPr7t4eEf3Louo2P4OKqciqbO+RvXJJB2BBj0pEbjvw96tvsyfz3hdsT/S0Ad g90w== X-Gm-Message-State: AA6/9RkKiJ3ZAC045w9M8N4M2h5qzHNKv4gU+L6S+lomwBPKknJ/tnQN/W8x0h/j7+CgP5edFndqYoheqNVsVA== X-Received: by 10.55.138.66 with SMTP id m63mr142814qkd.159.1476132551942; Mon, 10 Oct 2016 13:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.87 with HTTP; Mon, 10 Oct 2016 13:49:11 -0700 (PDT) In-Reply-To: References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> From: Watson Ladd Date: Mon, 10 Oct 2016 13:49:11 -0700 Message-ID: To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Mon, 10 Oct 2016 20:49:16 -0000 On Sat, Oct 8, 2016 at 10:32 AM, David Benjamin wrote: > To add to that, in out-of-order transports, whether a message was sent over > 0-RTT or not may not even be very well-defined. If QUIC originally sent data > over 0-RTT but had to retransmit it after the full connection parameters are > available, I believe it will use those. > > Even in an in-order transport, imagine if I have a very long replayable > request in HTTP/2 (maybe it's a PUT and comes with a request body, or maybe > it has too many headers). I start sending that one over 0-RTT. While I'm in > the middle of sending that, I get back a ServerHello (w/ early_data) through > Finished. I either need to complete the handshake and switch to 1-RTT > mid-request or wait for the long request to complete before finishing the > handshake or sending any non-replayable ones, though they may be higher > priority. (They probably are if they don't come with as giant of response > bodies...) The former is by far the more attractive option. > > Or perhaps I hit max_early_data_size > (https://github.com/tlswg/tls13-spec/pull/674) and thus can't send more > 0-RTT data anyway. > > In HTTP/2 you have the additional amusement that, due to HPACK, your 0-RTT > data probably has an effect on the 1-RTT data even if requests are all or > nothing. > > I don't think we can make the receiver aware of the 0-RTT / 1-RTT boundary > sanely. In my mind, the decision whether to send something 0-RTT or wait > until 1-RTT is primarily the sender's business. If the sender wanted to, it > could make the data replayable anyway by just replaying it. On the > receiver's side, yeah, you concatenate the streams. That's why the server > must decline 0-RTT if any negotiated parameter (ALPN, etc.) changes. The problem is with poorly-behaved senders and attackers resending 0-RTT data. Receivers should be able to ensure side-effectfull operations are not carried out by 0-RTT data. Making 0-RTT silent in APIs transforms an interoperability issue into a silent security issue. This is not a good idea. > > David > > > On Sat, Oct 8, 2016 at 1:14 PM Nick Harper wrote: >> >> In my proposed 0-RTT Token Binding draft >> (https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01), the >> signature is the same in 0-RTT data as in 1-RTT data, assuming the server >> didn't reject early data. The thought here is that a client's write API >> might look like "please send this data, and I'm fine with it being sent >> 0-RTT", so the Token Binding code doesn't have to know if its message was >> sent before or after handshake completion. If early data is rejected, then >> the application data has to change, but this isn't something limited to >> Token Binding. A server cold reject early data and also change ALPN from >> what the client expected, requiring the client to send different data. >> >> I think it's fine from an API perspective for data sent 0-RTT to also be >> sent 1-RTT so long as early data is accepted. >> >> >> On Saturday, October 8, 2016, Ilari Liusvaara >> wrote: >>> >>> On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote: >>> > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara >>> > >>> > wrote: >>> > >>> > > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: >>> > > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara >>> > > > wrote: >>> > > > > >>> > > > > Also, it is very likely that 0-RTT would need its own read API, >>> > > > > because >>> > > > > it is pretty unlikely that existing API could be safely >>> > > > > retrofitted >>> > > > > or even purpose-built unified API be designed that isn't just >>> > > > > asking >>> > > > > for security problems via mixing 0-RTT and 1-RTT data. >>> > > > >>> > > > Yes. In particular I think the TLS state machine transitions need >>> > > > to >>> > > > be ordered with respect to the arrival and sending of data. The >>> > > > challenge for a multithreaded program (yes, some programs have >>> > > > multiple threads sending and receiving at once) is making this make >>> > > > sense, or even a single-threaded program where the TLS stack can >>> > > > change state at times not visible to the sending thread. Maybe >>> > > > there >>> > > > is some slop here, like 0-RTT can become 1-RTT on send, but this >>> > > > raises all sorts of problems for receiving. I think we need to >>> > > > require >>> > > > separation in the API. >>> > > >>> > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- >>> > > retransmit, which needs to be disableable, as sometimes that just >>> > > plain >>> > > won't work). >>> > >>> > Can you explain why that is? >>> >>> E.g. what they are planning to do with 0-RTT Token Binding in HTTP. >>> The client puts in a signature into 0-RTT data. If the server rejects >>> the 0-RTT and the client retransmits, the signature will still be >>> there but is different. >>> >>> Also, if 0-RTT data can silently shift to 1-RTT, it would mean the >>> server-side model would be to concatenate 0-RTT and 1-RTT data, which >>> I thought we already established is quite dangerous. >>> >>> >>> -Ilari >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Oct 10 13:52:19 2016 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 9758C129756 for ; Mon, 10 Oct 2016 13:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 xmqiBGp0tKmy for ; Mon, 10 Oct 2016 13:52:15 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00583129758 for ; Mon, 10 Oct 2016 13:52:14 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id e2so490178ybi.1 for ; Mon, 10 Oct 2016 13:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6oO6SqD/wL7z6mA2nqE7Qztsbr6+A+U7AtCqk9+V9J4=; b=OKyjMHHXMk8HyxzgFqdp46zgKUSd+3/NsXYe/q0i1PSFjVb3+E9ZLTCRcitAhjsyBY 5fH+mEmts1KlKxwm5ZtOfKQIdB+4cf3NhizK8bry+A4XoL7SeBWGO8HqbpxuIl1w/t80 kj0D8YnjxbHop/OZCwnG+OD0NuhXbVFsdgsAgj5QrIoGufVSABSEowmkAeLpD6z6YMKj EYpxk5+Ta0sZdXup7iq6RlwX4zq6SnUXeM4ZhItmnpZwAg/Gyb5MLVZ0SwGxnpAYwJgw NEfOx9QU2AYQcN1UpoNJqFdHrj69edaLHlYmdDDNGMXDdnXRCWn+m2DgF32Y0jVR/Iu1 CUMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6oO6SqD/wL7z6mA2nqE7Qztsbr6+A+U7AtCqk9+V9J4=; b=NPERpqhQLo1xh2LtLwvSj+Xn/B9lyGdXBsxvbCme1QiGvoloZ825WgLiazd61yCO6x aLe5rsDWFbicDL6PXq5G2/iZLzd7zwZ784p1pWbhnEwbE9fCD3S3zxR+HaXrPY2GltIR HflQn28j/UrvoZqQ7crZSfYnOMqr9X80ejBP3enfKsJL8fGNgjn6+nASbQZUAOiQ7aYm /GhDz80hkCrDc87Uuf074ytubNyIUXYxe5sEqPoAgpvO6qjwf2ZR0rB9498jeo+0Y8A2 JmG8M7+nS1NDFF1aOvLFAxAvIzaQ9cb/ruAGWeiKRE/nn5WDUfDDwF3VfzYpk7//XCZ/ 9XcA== X-Gm-Message-State: AA6/9RnQpDxX3cv52BQpCn5NrrLYr+YoLp+MraSwALEiaBTHMOT/J9s99J5P4ONXWHVB5SOtqynlutazP2AmpQ== X-Received: by 10.37.171.234 with SMTP id v97mr96377ybi.161.1476132734260; Mon, 10 Oct 2016 13:52:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Mon, 10 Oct 2016 13:51:33 -0700 (PDT) In-Reply-To: References: <1475859457.3070375.749089329.59EED0F8@webmail.messagingengine.com> <82f39c83-0040-cf87-94ae-16c321eecc95@akamai.com> From: Eric Rescorla Date: Mon, 10 Oct 2016 13:51:33 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=94eb2c0ce1f8448690053e88ef91 Archived-At: Cc: Filippo Valsorda , Drew Springall , Filippo Valsorda , "tls@ietf.org" Subject: Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo 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: Mon, 10 Oct 2016 20:52:17 -0000 --94eb2c0ce1f8448690053e88ef91 Content-Type: text/plain; charset=UTF-8 Merged On Sat, Oct 8, 2016 at 4:00 PM, Eric Rescorla wrote: > I agree that this is a good idea. Absent objection, i'm going to merge > this PR on Monday > > On Fri, Oct 7, 2016 at 3:06 PM, David Benjamin > wrote: > >> We were also expecting to want to bound how much traffic a server could >> be compelled to skip over without making progress. It actually didn't occur >> to me we could let the client know the bounds, rather than just making up a >> conservative bound (there's only so much data you can get into an RTT) and >> hoping nothing breaks. That's a good idea. >> >> Units is a little interesting. For those purposes, this limit would kick >> in whether or not the early data could be decrypted, so the server-side >> limit would be measured in ciphertext, possibly even including record >> headers. (Although any inaccuracies in converting could be done by just >> advertising an underestimate and breaking peers that send pathologically >> silly things like all one-byte records. So it doesn't matter much.) >> >> On Fri, Oct 7, 2016 at 5:45 PM Benjamin Kaduk wrote: >> >>> On 10/07/2016 11:57 AM, Filippo Valsorda wrote: >>> >>> Hello, >>> >>> Cloudflare's current (not definitive) plan for 0-RTT is essentially to >>> decide whether or not to answer to requests in the 0.5 flight on a >>> case-by-case basis. That obviously requires reading all of them and >>> caching the ones we don't want to answer. >>> >>> To mitigate the obvious DoS concern we plan to use the ticket age and a >>> per-machine replay cache. >>> >>> However, chatting with Drew (cc'd) we realized that clients could still >>> send huge amounts of 0-RTT data that we would have to buffer. Once a >>> >>> >>> Well, "have to" is perhaps a bit of a stretch; the client should be >>> prepared to cope reasonably if you abort the connection arbitrarily. >>> >> >> I think the concern is that a well-meaning client may not necessarily do >> a retry here and instead read this even as a network error. And if it did, >> the next attempt, if there is still a 0-RTT-able ticket available, may hit >> this again anyway... >> >> client sent early data, there's no way to accept only a part of it or to >>> verify that the client is not replaying before reading it all. But if we >>> were to close the connection after a given amount of data we risk >>> failing connections from legal clients. >>> >>> I propose to add a field max_early_data_size to TicketEarlyDataInfo, to >>> inform clients about the maximum amount of 0-RTT data they are allowed >>> to send, allowing servers to safely terminate connections that exceed >>> it. >>> >>> >>> But this seems like a good idea; I left a couple of ~editorial notes on >>> github. >>> >>> -Ben >>> >>> >>> https://github.com/tlswg/tls13-spec/pull/674 >>> >>> [Please keep me in the CC of replies] >>> >>> _______________________________________________ >>> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --94eb2c0ce1f8448690053e88ef91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Merged

On Sat, Oct 8, 2016 at 4:00 PM, Eric Rescorla <ekr@rtfm.com>= wrote:
I agree t= hat this is a good idea. Absent objection, i'm going to merge this PR o= n Monday

On Fri, Oct 7, 2016 at 3:06 PM, David = Benjamin <davidben@chromium.org> wrote:
We were also expecting = to want to bound how much traffic a server could be compelled to skip over = without making progress. It actually didn't occur to me we could let th= e client know the bounds, rather than just making up a conservative bound (= there's only so much data you can get into an RTT) and hoping nothing b= reaks. That's a good idea.

Units is a little interes= ting. For those purposes, this limit would kick in whether or not the early= data could be decrypted, so the server-side limit would be measured in cip= hertext, possibly even including record headers. (Although any inaccuracies= in converting could be done by just advertising an underestimate and break= ing peers that send pathologically silly things like all one-byte records. = So it doesn't matter much.)

On Fri, Oct 7, 2016 at 5:45 PM Benjamin K= aduk <bkaduk@akam= ai.com> wrote:
On 10/07/2016 11:57 AM, Filippo Valsorda wrote:
Hello,

Cloudflare's current (not definitive) plan for 0-RTT is essentially to
decide whether or not to answer to requests in the 0.5 flight on a
case-by-case basis. That obviously requires reading all of them and
caching the ones we don't want to answer.

To mitigate the obvious DoS concern we plan to use the ticket age and a
per-machine replay cache.

However, chatting with Drew (cc'd) we realized that clients could still
send huge amounts of 0-RTT data that we would have to buffer. Once a

Well, "have to" is perhaps a bit of a stretch; the client sho= uld be prepared to cope reasonably if you abort the connection arbitrarily.

I think the concern is that a= well-meaning client may not necessarily do a retry here and instead read t= his even as a network error. And if it did, the next attempt, if there is s= till a 0-RTT-able ticket available, may hit this again anyway...

client sent early data, there's no way to accept only a part=
 of it or to
verify that the client is not replaying before reading it all. But if we
were to close the connection after a given amount of data we risk
failing connections from legal clients.

I propose to add a field max_early_data_size to TicketEarlyDataInfo, to
inform clients about the maximum amount of 0-RTT data they are allowed
to send, allowing servers to safely terminate connections that exceed
it.

But this seems like a good idea; I left a couple of ~editorial notes on github.

-Ben


https://github.com/tlswg/tls13-spec/pull/674

[Please keep me in the CC of replies]

_______________________________________________
TLS mailing list
TLS@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/tls

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

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



--94eb2c0ce1f8448690053e88ef91-- From nobody Mon Oct 10 13:57:34 2016 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 595EB129759 for ; Mon, 10 Oct 2016 13:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 HLXqKOgGspcm for ; Mon, 10 Oct 2016 13:57:29 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9251293FE for ; Mon, 10 Oct 2016 13:57:29 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id f128so2887522qkb.1 for ; Mon, 10 Oct 2016 13:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pR61lUv5utyj0zsXuBtDYASbFQQ5ekFVdh1d+MKj1YY=; b=YIVjWf3OMbG8aybXjdbxIWbp0/JqHkHLOzkGurVaFoITJ6ER65IrhgYZTDEw8Ms7ls qkFs23HgQRbnShnToiycJvHTxCHGqNMFoMDQolmOGEikwZq0NtsrRoMmps68s0gvjZaP Grmpo6FwXq+uR0DgfB/MqjrujySJLG/XhUpS0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pR61lUv5utyj0zsXuBtDYASbFQQ5ekFVdh1d+MKj1YY=; b=amYErllJHYpQ/R9QTYZgSSc2wPC0iZbMKg76ifmjgrlVDrqDPn/LipHjAFkdC/s0H8 gnII6xKou14gHRuK1m0jzcu897O85iO2AfcQVibxsUoDy02OlcnloUVZrUESa0VgE1YY JJj/VB985ZB6aYFpHq2K2rJ/Ti1016PlYLQ+3PicOysh2V9mRGepxrq1dMXzplymKhWa 6b8bPQlfSLivkNDVKS+Q7DFCrB/Iisv3viCJp+Sj8lZWRckFwlqkH8kcGDvjjNcBO9Zg UyGn/KW38jKsU5Oi+SRFDsrut/jfK9GC6d4mLg/pWgc4XjfSTQNTb/eYjGjp0Ela91xA WZPw== X-Gm-Message-State: AA6/9RngTtIWrCwulZJ3r2fj8JFd2M2AU7jO3m3+HJhbnw9QgiQLqesYMa0r9kBW3CPnyNRBm26jqbeEvY+HEw== X-Received: by 10.55.19.36 with SMTP id d36mr137685qkh.247.1476133048698; Mon, 10 Oct 2016 13:57:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Mon, 10 Oct 2016 13:57:27 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Mon, 10 Oct 2016 13:57:27 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a113ffee6027c54053e89022c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Mon, 10 Oct 2016 20:57:32 -0000 --001a113ffee6027c54053e89022c Content-Type: text/plain; charset=UTF-8 On Mon, Oct 10, 2016 at 1:49 PM, Watson Ladd wrote: > > The problem is with poorly-behaved senders and attackers resending > 0-RTT data. Receivers should be able to ensure side-effectfull > operations are not carried out by 0-RTT data. Making 0-RTT silent in > APIs transforms an interoperability issue into a silent security > issue. This is not a good idea. > +1. FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin that the web is substantially broken without retry logic in the browsers, that naturally make application-level replay mitigation a necessity. But I don't think (nor do I think he claimed) that the same is true of all protocols or systems that might use TLS. So while 0-RTT-obliviousness may be okay for browsers in particular given the other constraints under which they operate, it is probably not good to bake that into the API for the general case. Kyle --001a113ffee6027c54053e89022c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 10, 2016 at 1:49 PM, Watson Ladd <watsonb= ladd@gmail.com> wrote:

The problem is with poorly-behaved senders and attackers resend= ing
0-RTT data. Receivers should be able to ensure side-effectfull
operations are not carried out by 0-RTT data. Making 0-RTT silent in
APIs transforms an interoperability issue into a silent security
issue. This is not a good idea.

+1.

FWIW, P= atrick McManus made a pretty eloquent and convincing case in Berlin that th= e web is substantially broken without retry logic in the browsers, that nat= urally make application-level replay mitigation a necessity. But I don'= t think (nor do I think he claimed) that the same is true of all protocols = or systems that might use TLS. So while 0-RTT-obliviousness may be okay for= browsers in particular given the other constraints under which they operat= e, it is probably not good to bake that into the API for the general case.<= br>
Kyle
--001a113ffee6027c54053e89022c-- From nobody Mon Oct 10 15:00:02 2016 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 8CF9512979A for ; Mon, 10 Oct 2016 15:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Sc7mP6bPkOZZ for ; Mon, 10 Oct 2016 14:59:59 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179B2129786 for ; Mon, 10 Oct 2016 14:59:59 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id w3so1808333ywg.1 for ; Mon, 10 Oct 2016 14:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q3PASbBQzl9D0AzWm+j7KPlTzIR+LQPBt8bSEuW7XWk=; b=elRpRat4kkP9neFjulMwfxDNoa7vnC6lCSoqWGgzJznbQixN/ZKmcmMHhEAkShXaYu 6DfBfzcQUS2dhEvTGllFW6birGWWUeXwou4zRzLj/9cKFyrTOwUFsyZFSplQZNz3qfRI 0VUZEqKZFPSIhQ+fKaUfIOK28Ya2XCV/l4HgfoJghTNIZR/4Z7xa6JZyBsq6hHR/huXw LJyYCJ7Qo97vyJqjTu5Wl9XwlsSoeYZOQU1Bg1UORgF8NDb5vYrw7w3FclvAWeTmKNvU 2TwTUWkpWfVZYtS6HYV9RxAEAL7ChXJ7CAbUNzmSLC7JiLZZbzGxS5mDttNy7rzHzd20 AywQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q3PASbBQzl9D0AzWm+j7KPlTzIR+LQPBt8bSEuW7XWk=; b=FeG97b5TCG23Lgs/6xhbJ/fyzkLJW/j05f5q/SEfEhIKUBIh+BP6VXI1IYwI6NqzKA RsWuacKudGEgAHo1T9+tEs3JK74oqYQVcWiMQ9bGdLYvIdyFGVDtYADZS6RDgd4mykJd NkLtggrF8/q4XQVnkDNOsAvXnC6QQawGtXWeNDXyJPaW7JcrmLK+vU5Op0kpZY2PzWdW 5tKF407wZvPYup74RihLgXVbAGRv9RI6+16UmhiNnOLmRPWQrp0cK7mcawfUz4o8ljKv ZYPn0pOo70Ouq5TUfZ08c4g0X+xKfF+bvrEiPK2XVNSDtcTqdhiFvkewqunjxg05uquq ZKmw== X-Gm-Message-State: AA6/9RmG9WCIxb37kQ09f+wFN/lvrpn38Wm4ys+aEAWi+G4jj0RoOJPuaeIAqvuTzayy8QkXAAnnx+u4qkAXZQ== X-Received: by 10.129.83.134 with SMTP id h128mr426978ywb.52.1476136798315; Mon, 10 Oct 2016 14:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Mon, 10 Oct 2016 14:59:17 -0700 (PDT) In-Reply-To: References: <2b155eb4-3268-c687-031e-6ac9928940c3@gmx.net> From: Eric Rescorla Date: Mon, 10 Oct 2016 14:59:17 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e8108813ca9053e89e131 Archived-At: Cc: "" Subject: Re: [TLS] Zero-RTT Data & PSK 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: Mon, 10 Oct 2016 22:00:00 -0000 --001a114e8108813ca9053e89e131 Content-Type: text/plain; charset=UTF-8 I agree with MT. Hannes, if you want to clean up the text to take into account MT's comments, I will merge On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson wrote: > On 9 September 2016 at 23:37, Hannes Tschofenig > wrote: > > I am wondering why I cannot use Zero-RTT with just PSK-based > authentication > > (without a prior ticket change). > > I think that you would need to bind more things to the key in that > case, but I assume that it would be OK if you did so. You already > need to pair a PSK with a hash, but if you paired it with a whole > cipher suite instead and also the ALPN (which could be null), then I > see no reason not to permit 0-RTT for pure PSK. (I think that cipher > suite + ALPN is sufficient, but someone can correct me if I missed > anything.) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114e8108813ca9053e89e131 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with MT. Hannes, if you want to clean up the text = to take into account MT's comments, I will merge

On Sat, Sep 10, 2016 at 3:35 AM, M= artin Thomson <martin.thomson@gmail.com> wrote:
On 9 September 2016 at 23:37, Hannes Tschofeni= g
<hannes.ts= chofenig@gmx.net> wrote:
> I am wondering why I cannot use Zero-RTT with just PSK-based authentic= ation
> (without a prior ticket change).

I think that you would need to bind more things to the key in that case, but I assume that it would be OK if you did so.=C2=A0 You already
need to pair a PSK with a hash, but if you paired it with a whole
cipher suite instead and also the ALPN (which could be null), then I
see no reason not to permit 0-RTT for pure PSK.=C2=A0 (I think that cipher<= br> suite + ALPN is sufficient, but someone can correct me if I missed
anything.)

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

--001a114e8108813ca9053e89e131-- From nobody Mon Oct 10 20:30:16 2016 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 40061129440 for ; Mon, 10 Oct 2016 20:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.707 X-Spam-Level: X-Spam-Status: No, score=-3.707 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 oHbLaG1C6vkA for ; Mon, 10 Oct 2016 20:30:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4A65412944E for ; Mon, 10 Oct 2016 20:30:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7F588433411; Tue, 11 Oct 2016 03:30:08 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5E814433420; Tue, 11 Oct 2016 03:30:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1476156608; bh=39G7/sKMCHpjCs0cePWjG+hKV1eJ180DQeCgrrHUlgI=; l=23055; h=To:References:Cc:From:Date:In-Reply-To:From; b=GNKnJ5xJK/+JZI/B1XqxjJblO/67da6ELi+wgd+T11cUoQ5/G6YA5uMSaE9z5A7vZ 3KEACfqowfQ6SeA5b+TnGaXMG1eH130R2j1ppuxyCg0+nbPRV1y0vyY/uOelzLp+U+ /seMP6s1aQ3cHoLb1WbPfOS+iT9Sk5m+Qk5r7smk= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id EC1351FC88; Tue, 11 Oct 2016 03:30:07 +0000 (GMT) To: Nick Sullivan , Eric Rescorla References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk Message-ID: <00dc9f8c-768c-0bac-d776-ceb1f63c097b@akamai.com> Date: Mon, 10 Oct 2016 22:30:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------57C6900560335A8C646133A9" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Tue, 11 Oct 2016 03:30:14 -0000 This is a multi-part message in MIME format. --------------57C6900560335A8C646133A9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit With respect to communicating policy from the application layer to the TLS stack, what's wrong with David's "CertificateRequest is disallowed by default, and the application must make a library call to enable it for a given connection/context" proposal? It seems fairly straightforward in terms of API surface, to me. You mostly mentioned this already, but this list of known message types is another protocol surface that would need to be GREASEd. So, on the balance, I think I'm starting to lean against this specific proposal and more towards the text changes that David wants. -Ben On 10/08/2016 03:02 PM, Nick Sullivan wrote: > I agree that "I don't like NST or KU" is not a very useful thing to > add to the spec. I added them as part of a general move towards > clarity and conservatism about which types of post-handshake messages > are permissible in TLS 1.3. Right now the spec is ambiguous about what > each side of the connection is supposed to do when it receives an > unexpected or unknown post-handshake message. This change hopefully > makes it crystal clear: any post-handshake message that wasn't agreed > upon by both parties should be fatal. > > David suggested that the behavior with respect to post-handshake > messages should be negotiated at the application layer. This also > seems reasonable, but I worry about how this policy would be > communicated from the application layer to the TLS stack. Would the > application layer be alerted of incoming CertificateRequests and > either terminate the connection or reply with an empty certificate and > finished message? If we want to support "2018" post-handshake > messages, will we just end up re-inventing this post_handshake > extension in a later draft to advertise support? Different > post-handshake messages have different uses, so I see how this more > case-by-case application-dependent policy could be more expressive > than what I proposed, but I worry we may end up with something more > complex than necessary. > > In any case, post-handshake authentication as currently described is > problematic. I'd be open to seeing a text change along the lines of > what David proposed instead of the wire change I'm proposing as long > as it includes some guidance around how it should interact with > policies from the application layer. > > > > On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla > wrote: > > I could go either way on this. It seems like this pushes > complexity from the client to the server. > > Consider the case of NST. Presently, a client which doesn't want > resumption can just ignore NST, > but in your proposed change, the server needs to read this > extension and then conditionally send > NST, and the client still needs the logic to detect unexpected > handshake messages and abort > on them. > > As I said, I could go either way, and I do think it's potentially > useful to be able to say "I won't do > post-handshake client auth" and even more useful to be able to say > "I would do post handshake > message X which will be invented in 2018" (but of course we can > register an extension for > that then), but less useful to say "I don't like NST or KU" > > -Ekr > > > On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan > > > wrote: > > I'm not proposing any new post-handshake authentication > mechanisms or anything relating to HTTP/2 renegotiation in > this change. I'm simply making support for the existing > post-handshake messages optional. > > With this change, if the client does not opt in, unexpected > CertificateRequests are fatal to the connection. Same with > unexpected KeyUpdates and SessionTickets. This will hopefully > reduce the complexity of TLS 1.3 implementations that don't > need these features. > > Nick > > On Sat, Oct 8, 2016 at 8:06 AM David Benjamin > > wrote: > > On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara > > wrote: > > On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick > Sullivan wrote: > > > There has been a lot of discussion lately about > post-handshake messages > > > that do not contain application data and how to > handle them. This PR is an > > > attempt to make the story more explicit by adding a > new post_handshake > > > extension to TLS 1.3. > > > > > > Supporting all types of post-handshake messages can > require extra > > > complexity and logic, even when the features that > these messages enable are > > > not needed. Some types of > connections/implementations don't need to support > > > key updates (some unidirectional connections), > session tickets (pure PSK > > > implementations) and post-handshake client auth > (most browsers). These are > > > all currently SHOULDs in the spec and they don't > need to be. > > > > Post-handshake authentication is the only one of these > that is genuinely > > annoying. This is because you can't even reject it > without a MAC, that > > additionally continues the handshake hash. > > > > KeyUpdate is rather simple, and NST can just be > ignored (leading to some > > waste in bandwidth). > > > Yeah, after the fix to how KeyUpdate is acked, I don't > think we'd have problems with either of the way, while > post-handshake auth is indeed horrific. > > > > Furthermore, the post-handshake authentication > mechanism doesn't look to > > be featureful enough for kind of post-handshake auth > e.g. HTTP/2 wants, > > And there are serious questions about how it should > interact with > > applications. > > > An extension also doesn't really capture things if we > intend for, say, this to be used for legacy protocols like > HTTP/1.1 (where we don't have as rich a framing layer) but > not HTTP/2 (where we do and can use it as a substrate for > all this silliness). I was anticipating that, if this ends > up being used in the HTTP world like renego is, it would > be like our renego stuff: off by default, forbidden in > HTTP/2, and with all interleave forbidden. > > Further, what useful thing could a server even do with > this extension? Decline to do post-handshake auth doesn't > work. Either the application protocol doesn't use > post-handshake auth (please pick this one) or it does. One > doesn't need to send a client_writes_first extension in > HTTP/1.1. > > Post-handshake auth another knob on the TLS <-> > application protocol boundary. This means each application > protocol must specify for itself what post-handshake auth > means: what to do with the context field, when it may be > received, what it does to application flow, etc. Then the > spec must be clear that if the application protocol does > not opt in, CertificateRequest is forbidden. A > CertificateRequest at an unexpected point (say, half-way > through a HTTP/1.1 body) is also forbidden. Also make it > clear this is for legacy protocols and new ones do not use it. > > This is analogous to how HTTP/2 forbids renego at the spec > level. (TLS 1.2 got the "defaults" for renego wrong.) No > one ever wrote down the exact rules for the > client-auth/renego hack in HTTP/1.1, but whatever spec > does this for post-handshake auth should do the same for > renego. > > It is a lot of spec work for such a tiny-seeming feature, > but this is consistent with how messy the feature actually is. > > David > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------57C6900560335A8C646133A9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit With respect to communicating policy from the application layer to the TLS stack, what's wrong with David's "CertificateRequest is disallowed by default, and the application must make a library call to enable it for a given connection/context" proposal?  It seems fairly straightforward in terms of API surface, to me.

You mostly mentioned this already, but this list of known message types is another protocol surface that would need to be GREASEd.

So, on the balance, I think I'm starting to lean against this specific proposal and more towards the text changes that David wants.

-Ben

On 10/08/2016 03:02 PM, Nick Sullivan wrote:
I agree that "I don't like NST or KU" is not a very useful thing to add to the spec. I added them as part of a general move towards clarity and conservatism about which types of post-handshake messages are permissible in TLS 1.3. Right now the spec is ambiguous about what each side of the connection is supposed to do when it receives an unexpected or unknown post-handshake message. This change hopefully makes it crystal clear: any post-handshake message that wasn't agreed upon by both parties should be fatal.

David suggested that the behavior with respect to post-handshake messages should be negotiated at the application layer. This also seems reasonable, but I worry about how this policy would be communicated from the application layer to the TLS stack. Would the application layer be alerted of incoming CertificateRequests and either terminate the connection or reply with an empty certificate and finished message? If we want to support "2018" post-handshake messages, will we just end up re-inventing this post_handshake extension in a later draft to advertise support? Different post-handshake messages have different uses, so I see how this more case-by-case application-dependent policy could be more expressive than what I proposed, but I worry we may end up with something more complex than necessary.

In any case, post-handshake authentication as currently described is problematic. I'd be open to seeing a text change along the lines of what David proposed instead of the wire change I'm proposing as long as it includes some guidance around how it should interact with policies from the application layer.



On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla <ekr@rtfm.com> wrote:
I could go either way on this. It seems like this pushes complexity from the client to the server. 

Consider the case of NST. Presently, a client which doesn't want resumption can just ignore NST,
but in your proposed change, the server needs to read this extension and then conditionally send
NST, and the client still needs the logic to detect unexpected handshake messages and abort
on them.

As I said, I could go either way, and I do think it's potentially useful to be able to say "I won't do
post-handshake client auth" and even more useful to be able to say "I would do post handshake
message X which will be invented in 2018" (but of course we can register an extension for
that then), but less useful to say "I don't like NST or KU"

-Ekr


On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan <nicholas.sullivan@gmail.com> wrote:
I'm not proposing any new post-handshake authentication mechanisms or anything relating to HTTP/2 renegotiation in this change. I'm simply making support for the existing post-handshake messages optional.

With this change, if the client does not opt in, unexpected CertificateRequests are fatal to the connection. Same with unexpected KeyUpdates and SessionTickets. This will hopefully reduce the complexity of TLS 1.3 implementations that don't need these features.

Nick

On Sat, Oct 8, 2016 at 8:06 AM David Benjamin <davidben@chromium.org> wrote:
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote:

> There has been a lot of discussion lately about post-handshake messages

> that do not contain application data and how to handle them. This PR is an

> attempt to make the story more explicit by adding a new post_handshake

> extension to TLS 1.3.

>

> Supporting all types of post-handshake messages can require extra

> complexity and logic, even when the features that these messages enable are

> not needed. Some types of connections/implementations don't need to support

> key updates (some unidirectional connections), session tickets (pure PSK

> implementations) and post-handshake client auth (most browsers). These are

> all currently SHOULDs in the spec and they don't need to be.



Post-handshake authentication is the only one of these that is genuinely

annoying. This is because you can't even reject it without a MAC, that

additionally continues the handshake hash.



KeyUpdate is rather simple, and NST can just be ignored (leading to some

waste in bandwidth).

Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have problems with either of the way, while post-handshake auth is indeed horrific.
 

Furthermore, the post-handshake authentication mechanism doesn't look to

be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants,

And there are serious questions about how it should interact with

applications.

An extension also doesn't really capture things if we intend for, say, this to be used for legacy protocols like HTTP/1.1 (where we don't have as rich a framing layer) but not HTTP/2 (where we do and can use it as a substrate for all this silliness). I was anticipating that, if this ends up being used in the HTTP world like renego is, it would be like our renego stuff: off by default, forbidden in HTTP/2, and with all interleave forbidden.

Further, what useful thing could a server even do with this extension? Decline to do post-handshake auth doesn't work. Either the application protocol doesn't use post-handshake auth (please pick this one) or it does. One doesn't need to send a client_writes_first extension in HTTP/1.1.

Post-handshake auth another knob on the TLS <-> application protocol boundary. This means each application protocol must specify for itself what post-handshake auth means: what to do with the context field, when it may be received, what it does to application flow, etc. Then the spec must be clear that if the application protocol does not opt in, CertificateRequest is forbidden. A CertificateRequest at an unexpected point (say, half-way through a HTTP/1.1 body) is also forbidden. Also make it clear this is for legacy protocols and new ones do not use it.

This is analogous to how HTTP/2 forbids renego at the spec level. (TLS 1.2 got the "defaults" for renego wrong.) No one ever wrote down the exact rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does this for post-handshake auth should do the same for renego.

It is a lot of spec work for such a tiny-seeming feature, but this is consistent with how messy the feature actually is.

David

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




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

--------------57C6900560335A8C646133A9-- From nobody Mon Oct 10 23:27:28 2016 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 7E14B129456 for ; Mon, 10 Oct 2016 23:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3bbsWGZm05VG for ; Mon, 10 Oct 2016 23:27:25 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5E41293F2 for ; Mon, 10 Oct 2016 23:27:25 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id z190so14675713qkc.2 for ; Mon, 10 Oct 2016 23:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dj7LO0+CnlLgDF12NYYP0Vd1rcp+8jFOl35TnBaF6VY=; b=Avp5jEWK6mKptp7i1FUxTfl9pkAs9VQmY0HftuBnFGFaCdpLwXymfhOwyv18VzqrQ9 CSigx2h357ejuyrgiG4gsETmrgdYhDOEMofvAiGxO0K7cO9jmTtOEFA9B0zmJrS53QZg P7IP6zlfd+IMKLVfgZy2XJwzj7eIfbTzZ5FkOPr+NrTWRUwQLX0NLg2rg1QbpFPleneP +QM7mA/jqwb9GPrVR6HRmhvbfWQJiI4kmdRYozMo8gI2Wc2+bdTbqWUpGZ5ScOIiedNn sBtqlGNJmK6PhdLH8odKjvNCQmRew3B4qJGCpMaycrYLLsuGC54xoSE/HchV+FXOcbny Kydg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dj7LO0+CnlLgDF12NYYP0Vd1rcp+8jFOl35TnBaF6VY=; b=ZQMIu21ctc4b0dB6esucA6vGYzebyQ8tfbxFQckjFVzbWkjxOyRc2NNJyVPXh1wm8b O40Q4G6IRVbhiorYnRwcipTEJ0+GY+BA1sxWGdjQn3METnFo4/Urmart0VBgiJQeH2w3 fnjHiuJzeBKAMSLRe3RuxZPwWERkmB56pTJcZWor5Yb8iFvGTvG2E+xzWGDYXwVC1CWC Ib8AoahCSirUq3PeFd73IqC/yITfjAMcPB9Q0SJwGbc6YQTQpRMRGrOfLliA5ZCCQjTm fCfXkeC7eT15FFB6ODAeBeONB6LsqM1V9nVv+05Y7/3/E/IjPeMcO7OkBuPJx4eWZ7V4 70IQ== X-Gm-Message-State: AA6/9RldrXOa1cbsgSUTg8gmoTkyfW44jDsqnOK6ahZBE2LBf6JJhqasZsAQG0MWPBuiOtZDWCSkEizuaEU7Bw== X-Received: by 10.55.155.15 with SMTP id d15mr1656174qke.115.1476167244144; Mon, 10 Oct 2016 23:27:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 10 Oct 2016 23:27:23 -0700 (PDT) In-Reply-To: References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Tue, 11 Oct 2016 17:27:23 +1100 Message-ID: To: Kyle Rose Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Tue, 11 Oct 2016 06:27:27 -0000 On 11 October 2016 at 07:57, Kyle Rose wrote: > FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin > that the web is substantially broken without retry logic in the browsers, > that naturally make application-level replay mitigation a necessity. But I > don't think (nor do I think he claimed) that the same is true of all > protocols or systems that might use TLS. So while 0-RTT-obliviousness may be > okay for browsers in particular given the other constraints under which they > operate, it is probably not good to bake that into the API for the general > case. The 0-RTT API in NSS allows a server to detect this transition. The problem that I think David was referring to is that the specific instant of the transition is lost when the multiple layers of stack that sit on top of TLS get involved. If an HTTP client sends a request that relies on HPACK state that was established during 0-RTT, is it a 0-RTT request? I'm going to go with probably not. If an HTTP client sends the first octets of a message in 0-RTT but completes the request after the handshake completes, is it 0-RTT? I suspect that this again is not a concern. I agree that we should make it clear that 0-RTT data needs to be treated specially. I would like to see someone propose some text rather than read more vague emails on the subject. From nobody Mon Oct 10 23:29:19 2016 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 8CEAF129460 for ; Mon, 10 Oct 2016 23:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zTAYSmtq0Gdz for ; Mon, 10 Oct 2016 23:29:15 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF10129456 for ; Mon, 10 Oct 2016 23:29:15 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id q7so5728330qtq.1 for ; Mon, 10 Oct 2016 23:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fqCgMZJcwTzhmhc69OnHfkS7xReoUJ2JSL7p6wJWaLo=; b=w39fqeO/wRAbgAkbMei1xvMBYbqi1XQw6weiytI8+p7ySi9xnyUcZakN9m3OAEUn+k gf7dRQ/JEq8OZMZ3qASpUrxXsNmSHvcfi6Hj9p+KoacEKASlgh5t8L4Glq9IPvI/5Hea f2i2LC84ihsM/iTfLZgRITdgWZ8Bs8ZK2nrA6pnEUEbgx7RzwKPjI3Lq0JWblAUAoE42 hjiXHIuKh+es8d7MBVw3owAA3JFOtTzSHOKSpncn03szIT7UkglBPIKzaXlw3tVM8Nc0 78QPzZQ6bDZ8FsU393MW/QJnoCVI9p6gzG02aiUIGUkUPjLMYcknu3GyyecU2pT08BDU kmVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fqCgMZJcwTzhmhc69OnHfkS7xReoUJ2JSL7p6wJWaLo=; b=T2ooe+GwHL+Pz/asx7QMKtoXpnLFRGR5da1iMa74jUC4qew/kbTt5Pwk/nEcBXpG3r G/bA5UlhTbA0lvMve933o1/dUSPq8vyAdIRYOlwkvmTy3O4na+AEn0SloQFpVPoqx4Br 2GnDPpKzSJAtbF8MW/GJqbjEKIHf+xY5tp+1XYqeJTVh+gwIs7nPtIUpC53Nxz9sD/mQ ZKVZeH9T1HFcR0j7r4FjKFiIi79b2roq2mPxnZH2+VvsxAfQVSjZXmznqbRmieL6dgfU 1AcAyIj9wZKNRqGLh8QBBiYaiiZiMPgtV6RoMgZZ2U1q+ZbQt/4ZgjGfuYPrhONY1YFu ZR8Q== X-Gm-Message-State: AA6/9RnNgJPS8D44q0cfrlCnHQu9rf3bfRqqjgrRufbffMFBddkt60h0INzI7TunoWgrTjGDTb/Ltbmawn8q7Q== X-Received: by 10.200.34.66 with SMTP id p2mr1879963qtp.107.1476167354722; Mon, 10 Oct 2016 23:29:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 10 Oct 2016 23:29:14 -0700 (PDT) In-Reply-To: <00dc9f8c-768c-0bac-d776-ceb1f63c097b@akamai.com> References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> <00dc9f8c-768c-0bac-d776-ceb1f63c097b@akamai.com> From: Martin Thomson Date: Tue, 11 Oct 2016 17:29:14 +1100 Message-ID: To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Tue, 11 Oct 2016 06:29:17 -0000 On 11 October 2016 at 14:30, Benjamin Kaduk wrote: > So, on the balance, I think I'm starting to lean against this specific > proposal and more towards the text changes that David wants. Yes, I would rather not take NST or KU out of the mandatory set of 1.3 features. I'm happy to have post-handshake authentication require opt-in though. From nobody Tue Oct 11 06:29:02 2016 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 4D57B1294CB for ; Tue, 11 Oct 2016 06:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 VLRtoM1oRDLh for ; Tue, 11 Oct 2016 06:28:59 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5555A126B6D for ; Tue, 11 Oct 2016 06:28:59 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id j37so24306221ioo.3 for ; Tue, 11 Oct 2016 06:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=79AEfESZrwpwnwM7/xpMCiHHWJBCCJ7OjYoVYJcBprQ=; b=M4fbciwkNvbjUkH4D+MgbrmTVXmIa9aHzyucXdrThwCoML4kz5PhqxGEhk7O8EWIx7 sxK0RD1zOpbUmACYeJmEXRWxeCErE1BjeWkWGotpwsErV8CA32PoM5DnIUL73bgdWEcR 6Tzu031vXrpi24BoNzRIM+AHxY444w1vAic04= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=79AEfESZrwpwnwM7/xpMCiHHWJBCCJ7OjYoVYJcBprQ=; b=dsF5Vmd4nz6NkbkDuOM5gk6SWARDyC9JJeAm+9ubIbvoN/Yw6iLBVUtmBIFeMkf+cv yWKIr/yMomDL52tbOSNTN4niHFUEgnKhQzG5uak/pAbnamPA2WnX39WDe7RBdXetFEtS a5HxrlFpn8aqX6D9FkkAcXlc0yDOFU/x/pLOtPyiNer7bb57hn2MUTtS7d8knS0XUrtg qk8EFM3InIi8BksNfwY7VxBSrQ3PVPRU32d9MrQoSHLSG+W89YbPwIxg6asTYU9rmeOn EbNeQtyOB+8SODgTaiEIWuo0vo4ft1pFXdYgbggyVwjqgaifmZR8Z1IfM6AWUVY3EvK/ 4Lxw== X-Gm-Message-State: AA6/9RlyGHTw/5KhBTKXK0cV2Ps0fNkFiqkyzg+la23ZJh3+6SjMZotvPuQYJcWw0W8OnoWF1mQzrP5LlxNTybZ5 X-Received: by 10.107.63.215 with SMTP id m206mr6020268ioa.56.1476192538655; Tue, 11 Oct 2016 06:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.100 with HTTP; Tue, 11 Oct 2016 06:28:38 -0700 (PDT) In-Reply-To: References: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> From: Tom Ritter Date: Tue, 11 Oct 2016 08:28:38 -0500 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Tue, 11 Oct 2016 13:29:01 -0000 On 8 October 2016 at 11:54, Eric Rescorla wrote: > I could go either way on this. It seems like this pushes complexity from the > client to the server. > > Consider the case of NST. Presently, a client which doesn't want resumption > can just ignore NST, > but in your proposed change, the server needs to read this extension and > then conditionally send > NST, and the client still needs the logic to detect unexpected handshake > messages and abort > on them. > > As I said, I could go either way, and I do think it's potentially useful to > be able to say "I won't do > post-handshake client auth" and even more useful to be able to say "I would > do post handshake > message X which will be invented in 2018" (but of course we can register an > extension for > that then), but less useful to say "I don't like NST or KU" I'm concerned about the information this exposes on the wire. We've added Record Content Type protection, so things like post-handshake client auth can't be detected on the wire (modulo behavior/length attacks, for which we can attempt protection with padding.) But now we're going to say in the client's plaintext "Yea, I might want post-handsake client auth". And it seems like the percentage of clients who will say that will be few and far between... leading to more fingerprinting and a step back from where we were. -tom From nobody Tue Oct 11 06:52:10 2016 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 3FB52129429 for ; Tue, 11 Oct 2016 06:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 t0TnMKjy2E_l for ; Tue, 11 Oct 2016 06:52:07 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948C5126B6D for ; Tue, 11 Oct 2016 06:52:07 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t192so12933858ywf.0 for ; Tue, 11 Oct 2016 06:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ug12VJ7Lu1BhHrELYHMrWSjB6yBfaQBMfHLeJ2bs67k=; b=stBKWOKqS4ooxbWaJ+Fmb9KjZSrW9G1fzkSkRS93Wt2VmkqxFZRojvE3Zr+l/yUlER e7HmTUSaQhUdqIiOJodmLC06CNKvVg/pDe5XVMjE+GsYb9KlRkxSOkdsm59gblaBvm23 adT+MiApiiiCdqG44fBTbHtjG1LdV6p3RTVuJyNqWkODqdPHwWYEMWZihgeYnvS47/XD wO5oYBSzwB/1DHCsIITJHRb5Qgq2d63+baScH8blAz0CYZ+dhoNWjSK20KYR1tDquryI J+zwaOrHBrpNVuLBmhFzSPR7R6y6IK7BvRNa2LgOZIY0HvkNWjnxK7Wn1+a22LHdLPvT bCHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ug12VJ7Lu1BhHrELYHMrWSjB6yBfaQBMfHLeJ2bs67k=; b=Eii/wWN6J8BOj36JKJSiORnS4T01rzkySsBMZVLW1vRHLhrWGPj/Aqxr+OC4Fk3Pz9 DJYmIG/du8uA1KRhQ0YxJ/YmV01qvF8dnvMqKx1hQ9hEfGWeBWckFjdrrgZedusbUINE 1K9RUY9U2VTtUe0W5rtzTsK29SrfTWaX2CYW6JKdU7wajfmxENE0pdW0DYGve9dpApI6 f+6aJD75BffQAMoGOYSAjbHsEDtM8P7gn6Btlw2w/vlmr9f7L9nZB3vz76gwd8Acf83W IhKzRseYLGzIybvo80gvLFw1ojT2DqWC6JT7j5tToCzFQ3pKnsn6RDjdIcghhFcDrMpY x3Zw== X-Gm-Message-State: AA6/9RkSEvM4QvRPoaFUHGzP40mV5zyXY4cBGvvOgbIGhdVze+DVyyKyPFZ4GVuJwcD9X3JtO1YlFTNZL0u77w== X-Received: by 10.129.81.21 with SMTP id f21mr3280587ywb.149.1476193926716; Tue, 11 Oct 2016 06:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Tue, 11 Oct 2016 06:51:26 -0700 (PDT) In-Reply-To: References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 11 Oct 2016 06:51:26 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114611049f8c07053e972e64 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Tue, 11 Oct 2016 13:52:09 -0000 --001a114611049f8c07053e972e64 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 9, 2016 at 7:10 AM, Eric Rescorla wrote: > > > On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara > wrote: > >> On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: >> > After the discussion on PR #615, I took another pass at this with some >> > help from the research community. Please see: >> > >> > https://github.com/tlswg/tls13-spec/pull/672 >> > >> >> Also, an observation: This seems to interact in somewhat annoying way >> with stateless HRR. >> >> Basically, CH reconstruction no longer works properly, so one needs to >> have a freezeable PRF hash (and most implementations of hashes can not >> be frozen). >> > > I've been coming to the conclusion that CH reconstruction is a bad idea. > It's > tricky to get right and in the common case involves a lot of bloat in the > CH > (because of duplicating the Key Shares). I think we would be better off > just > removing it and replacing (rather than appending to ) KeyShares in HRR. > This was primarily intended as an attempt to avoid the need to continue > the hash in any case. > See: https://github.com/tlswg/tls13-spec/pull/678 -Ekr > Best, > -Ekr > > > And server not supporting PSK does not help here. >> >> >> (BTW: Simlar thing comes up if you try to freeze an established TLS >> session: Currently you need to freeze a hash due to post-handshake >> authentication, even if you don't support it. Nothing else in TLS >> 1.2 or 1.3 needs hash freezing for established session). >> >> >> -Ilari >> > > --001a114611049f8c07053e972e64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Oct 9, 2016 at 7:10 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:

On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara &= lt;ilariliusv= aara@welho.com> wrote:
On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorl= a wrote:
> After the discussion on PR #615, I took another pass at t= his with some
> help from the research community. Please see:
>
>=C2=A0 =C2=A0 https://github.com/tlswg/tls13-sp= ec/pull/672
>

Also, an observation: This seems to interact in somewhat annoying wa= y
with stateless HRR.

Basically, CH reconstruction no longer works properly, so one needs to
have a=C2=A0 freezeable PRF hash (and most implementations of hashes can no= t
be frozen).

I've been coming= to the conclusion that CH reconstruction is a bad idea. It's
tricky to get right and in the common case involves a lot of bloat in the = CH
(because of duplicating the Key Shares). I think we would be b= etter off just
removing it and replacing (rather than appending t= o ) KeyShares in HRR.
This was primarily intended as an attempt t= o avoid the need to continue
the hash in any case.

See:

-Ekr
=C2=A0
Best,
-Ekr


And server not supporting PSK does not help here.


(BTW: Simlar thing comes up if you try to freeze an established TLS
session: Currently you need to freeze a hash due to post-handshake
authentication, even if you don't support it. Nothing else in TLS
1.2 or 1.3 needs hash freezing for established session).


-Ilari


--001a114611049f8c07053e972e64-- From nobody Tue Oct 11 09:22:22 2016 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 3825E1293E0 for ; Tue, 11 Oct 2016 09:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XJ4knQ3LkjKS for ; Tue, 11 Oct 2016 09:22:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1897D129636 for ; Tue, 11 Oct 2016 09:22:15 -0700 (PDT) Received: from [192.168.91.134] ([80.92.121.244]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MCOdh-1bkxG91pYX-0095yN; Tue, 11 Oct 2016 18:22:12 +0200 To: Eric Rescorla , Martin Thomson References: <2b155eb4-3268-c687-031e-6ac9928940c3@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <43b8276e-a9ff-79f1-7eb9-645500d2582d@gmx.net> Date: Tue, 11 Oct 2016 18:22:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cVjCSrmSTX1HaxwKXpsPiwkq7pNKcL7VO" X-Provags-ID: V03:K0:TvzP4GfRH+QxpzN57EOThtZZ1UI+Ks274PItwiGu1mIVaMnQRwe v2Cw6zsgFgsDvUbqvjB0CFCcTHtndCQ5iYPQxWltqP/LSrVQJ3Btb+lQfrdQmlJFr3dW5Zp IyUOVBDcTgiyRhKL3C0nBI64y6Bg4oYGULLsnDDSsasglOfvOEYmQf5DsNKdsxACS4wvVIm TGPRtjS6LI+x0uK32Qi0w== X-UI-Out-Filterresults: notjunk:1;V01:K0:XBVD1wmXMXE=:YFRPtsNtnj7Y4VhaHyZs0x TURpAAJMZQcUnHW5ORYNIkoyCI0eDtvix4yC0fWKxAnOeQ8uIIQc08EiDfFralLrn1bU7yu7r 3eU02k4nm3OHQTnUeve29QaYsOuJ+XrSsxc7dZaIxwmer0edNi9nQgN9ieCs62mA3ov8+9oZ+ PKo8eGCj0h+dEdIWZGlAFqWxQrS863GiuPBakBWgNKakuDLdCgzyaUnT1/KWWg4hBvxp/CysT JNeSOjB788dYAPHiW4+WcDXxNVEVNMrdxyAXU7WrbvinANXfDcFtf9qotChpmuK4zqf5ouK7d /JP9qyZ9RKGecZUMK16ZpurtjKuMxxW/1P3C4+e3TQrq14KPMKIY+BosexyEPZTS0QNYtwwCf TAluO7Xr8bL1bE5QqsrYXUm/iD7aI9vMRVCibbh8Xmw+TSoGLYVfUi55VOVBv8rc+zgdBL/IU JHStO1DmAX32LoBtaCGOIl/+4rj7HHffNIp9xd88VxPKTj7FRP5RNEIFQtygCHSfL9xTKl28n Z/66iyj5McgMMF604uDho3aSEqlMtH8Ydtl7cJ8Qs8Vl5YNDpoX/SySlB1/SZJjYwl5zziise xJYKpIfXVIeX9dyE6L8ji9anvTmo56cf+Dq47okqPMBFB+GVn4+NE6rBCEoFFwQNJmAKDU9Ka T5n2+7J8v0dDsbMPvzbMKFHiha3YTMJhLzs33OOyoZUk7Pos2nhGN6JjqmqGDR3lg/+ic661q eozFyFVzhW6Anlw7ZauweFXLO95U4hNWuXo0I/b/uNdYKeN35EXFlY2V9hc= Archived-At: Cc: "" Subject: Re: [TLS] Zero-RTT Data & PSK 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: Tue, 11 Oct 2016 16:22:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cVjCSrmSTX1HaxwKXpsPiwkq7pNKcL7VO Content-Type: multipart/mixed; boundary="Mj316u10MTEqjkp9TSb7aGXUOg50icRwP"; protected-headers="v1" From: Hannes Tschofenig To: Eric Rescorla , Martin Thomson Cc: "" Message-ID: <43b8276e-a9ff-79f1-7eb9-645500d2582d@gmx.net> Subject: Re: [TLS] Zero-RTT Data & PSK References: <2b155eb4-3268-c687-031e-6ac9928940c3@gmx.net> In-Reply-To: --Mj316u10MTEqjkp9TSb7aGXUOg50icRwP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I gave it a try, see https://github.com/tlswg/tls13-spec/pull/668/commits/91e5b39e5f0ce62a90ef= fdbaf4e3c90ed0d81245 Ciao Hannes On 10/10/2016 11:59 PM, Eric Rescorla wrote: > I agree with MT. Hannes, if you want to clean up the text to take into > account MT's comments, I will merge >=20 > On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson > > wrote: >=20 > On 9 September 2016 at 23:37, Hannes Tschofenig > > wrot= e: > > I am wondering why I cannot use Zero-RTT with just PSK-based auth= entication > > (without a prior ticket change). >=20 > I think that you would need to bind more things to the key in that > case, but I assume that it would be OK if you did so. You already > need to pair a PSK with a hash, but if you paired it with a whole > cipher suite instead and also the ALPN (which could be null), then = I > see no reason not to permit 0-RTT for pure PSK. (I think that ciph= er > suite + ALPN is sufficient, but someone can correct me if I missed > anything.) >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >=20 >=20 --Mj316u10MTEqjkp9TSb7aGXUOg50icRwP-- --cVjCSrmSTX1HaxwKXpsPiwkq7pNKcL7VO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX/RGyAAoJEGhJURNOOiAtYMAH/jjx6EJZorN6+du4OgA2gUal 0bRJJ4ML8+8aDDWTROca2q6EyubL7WdZt08Z0W6b1ucIOlpUHSqGb1HeG1oAk9oy smyMLe4SmjF6vpKiDATA9esKWzOq2wopULJYlK/syywTpHdEs5EZ9Id5mODLudJh LYv76QjkDSenLKAHF9mMiKkH93hF17Xuw1MHig9CoRuBlAMBlAEb/nBPNaJIV+Ye WNNr51tNTEUYJLdZ+APp5GQuIMCUCsl418UqjPeq52nLJIRTYey8SWepVCGZnr9S sqlK3rS1c1Zi1zhtC0YRPahd9wJo286A7f2nsHk1fpWcNjAODLI4EWFToMFdQYU= =G43j -----END PGP SIGNATURE----- --cVjCSrmSTX1HaxwKXpsPiwkq7pNKcL7VO-- From nobody Tue Oct 11 09:24:26 2016 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 DCD4C129645 for ; Tue, 11 Oct 2016 09:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 uWAwBzTvMqIO for ; Tue, 11 Oct 2016 09:24:23 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6DF1293E0 for ; Tue, 11 Oct 2016 09:24:22 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t192so16334232ywf.0 for ; Tue, 11 Oct 2016 09:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1uEzYb0/luBi2JKTE3ru6PvulomWeqKHlnrHG0A5PRs=; b=LYicktah3xdR0vuNR3FJgwTX9CjvM8ZPQCvXS/+vNdTlVWVQDYwHMc98wJXdEgRHDC SNepcuNcjC1xE8q35B6irqsfbvivVvpEkGmjtf4LSg5UvkP+QaWLT2MmUgvDe9TpZtqd tsZ+SOvk4ToPMHbk1zQw7aNMYbegtZTnCYOkjgXmXYfVnOY0qmv6leyT3CyU38G9oCyj pg0sPT88RaUPsQq2ek+Y2DzltZRGSVpTtrj5iN54Df6Yrn4Bngpn6XZawWuN8nAf3R0p nYEV1vfbaDU94PjgMrRuB6ncCpmvwAyQPl2wbwFZRbaJUHsbPvIxdb0ggFhZ3k5BKVw4 hLEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1uEzYb0/luBi2JKTE3ru6PvulomWeqKHlnrHG0A5PRs=; b=IDXqkaqGHb2vM7FlK7IvyfJ+CGJ+N0lShMGem4g+M0xV6kOTzjaVN4uBi8L2PckM7o ebLCNdPL1d/+IKKEV7X/Bhn2KWNxYJznVvNeWVvJrqCYSSyKxcsWJe/m4j5kS5AM+s4+ ihULuFNZdIfXkVNma6eo9fueF52Emw9vhpHMZdppZm9vjQXobTtBg32Jg9OOV6wYpJlg MOJFdZZeS2IXY3IkhNZlIbFgjGvP8tJoZ4V7LR9Hn66FT5Mcz5JvNQdrHkPciqPYkPi2 8D+r+VK13H+fmxh2vCl1hSJT4VgjkHim2rbCFUdjdmIYjtLm32zFaghOb8WmJXv5pnoK jlWQ== X-Gm-Message-State: AA6/9RkPA4Gfdlg+J9EFuDCluIiRPATIrdvGCQUnetN8P94x2xPK8Kv4nUcjyh6dMxJgPrMXLFA7BmAvG5Z9vA== X-Received: by 10.129.83.134 with SMTP id h128mr4080906ywb.52.1476203061981; Tue, 11 Oct 2016 09:24:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Tue, 11 Oct 2016 09:23:41 -0700 (PDT) In-Reply-To: <43b8276e-a9ff-79f1-7eb9-645500d2582d@gmx.net> References: <2b155eb4-3268-c687-031e-6ac9928940c3@gmx.net> <43b8276e-a9ff-79f1-7eb9-645500d2582d@gmx.net> From: Eric Rescorla Date: Tue, 11 Oct 2016 09:23:41 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a114e8108205bce053e994fcf Archived-At: Cc: "" Subject: Re: [TLS] Zero-RTT Data & PSK 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: Tue, 11 Oct 2016 16:24:25 -0000 --001a114e8108205bce053e994fcf Content-Type: text/plain; charset=UTF-8 This LGTM. Absent objections I will merge tomorrow On Tue, Oct 11, 2016 at 9:22 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > I gave it a try, see > https://github.com/tlswg/tls13-spec/pull/668/commits/ > 91e5b39e5f0ce62a90effdbaf4e3c90ed0d81245 > > > Ciao > Hannes > > > On 10/10/2016 11:59 PM, Eric Rescorla wrote: > > I agree with MT. Hannes, if you want to clean up the text to take into > > account MT's comments, I will merge > > > > On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson > > > wrote: > > > > On 9 September 2016 at 23:37, Hannes Tschofenig > > > > wrote: > > > I am wondering why I cannot use Zero-RTT with just PSK-based > authentication > > > (without a prior ticket change). > > > > I think that you would need to bind more things to the key in that > > case, but I assume that it would be OK if you did so. You already > > need to pair a PSK with a hash, but if you paired it with a whole > > cipher suite instead and also the ALPN (which could be null), then I > > see no reason not to permit 0-RTT for pure PSK. (I think that cipher > > suite + ALPN is sufficient, but someone can correct me if I missed > > anything.) > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > --001a114e8108205bce053e994fcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This LGTM. Absent objections I will merge tomorrow

On Tue, Oct 11, 201= 6 at 9:22 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= wrote:
I gave it a try, see
https:/= /github.com/tlswg/tls13-spec/pull/668/commits/91e5b39e5f0ce62a90e= ffdbaf4e3c90ed0d81245


Ciao
Hannes


On 10/10/2016 11:59 PM, Eric Rescorla wrote:
> I agree with MT. Hannes, if you want to clean up the text to take into=
> account MT's comments, I will merge
>
> On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 9 September 2016 at 23:37, Hannes Tschofenig
>=C2=A0 =C2=A0 =C2=A0<hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>= wrote:
>=C2=A0 =C2=A0 =C2=A0> I am wondering why I cannot use Zero-RTT with = just PSK-based authentication
>=C2=A0 =C2=A0 =C2=A0> (without a prior ticket change).
>
>=C2=A0 =C2=A0 =C2=A0I think that you would need to bind more things to = the key in that
>=C2=A0 =C2=A0 =C2=A0case, but I assume that it would be OK if you did s= o.=C2=A0 You already
>=C2=A0 =C2=A0 =C2=A0need to pair a PSK with a hash, but if you paired i= t with a whole
>=C2=A0 =C2=A0 =C2=A0cipher suite instead and also the ALPN (which could= be null), then I
>=C2=A0 =C2=A0 =C2=A0see no reason not to permit 0-RTT for pure PSK.=C2= =A0 (I think that cipher
>=C2=A0 =C2=A0 =C2=A0suite + ALPN is sufficient, but someone can correct= me if I missed
>=C2=A0 =C2=A0 =C2=A0anything.)
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0TLS mailing list
>=C2=A0 =C2=A0 =C2=A0TLS@ietf.org= <mailto:TLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/l= istinfo/tls
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/tls>
>
>


--001a114e8108205bce053e994fcf-- From nobody Tue Oct 11 09:37:16 2016 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 6BDAE129468 for ; Tue, 11 Oct 2016 09:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3XD7pU4GVqRi for ; Tue, 11 Oct 2016 09:37:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295D81293E0 for ; Tue, 11 Oct 2016 09:37:13 -0700 (PDT) Received: from [192.168.91.134] ([80.92.121.244]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LtJAR-1asjJV1W1r-012miP; Tue, 11 Oct 2016 18:37:10 +0200 To: Nick Sullivan , "tls@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 11 Oct 2016 18:37:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EWPfpAKRV4JWGL3lUA3gt3ASjkXKoEFrC" X-Provags-ID: V03:K0:EfnBwgMP0kp3Qobi+7dVK0jMOsT/aPl2FVv8V/lPV7zFSoy0rZ2 KdJEcmjy84LHUrDk6utiDTN8ipoH5B9TKZVXDNYQIOBu1Ra31W6Q9kslXrL0Zmqo8d0wwD2 Db+0O5THuoT7tccti6RgaqiZIo3jaYSO/HsbOqqJnuZQxA3QhVFITj6Z4L4pBe4u6VWkKqa nm8V0LSyCj8St+Xm59pCw== X-UI-Out-Filterresults: notjunk:1;V01:K0:bQ4pLuXM5gM=:FsljIDs8nK4E5Ugg2MQR6C FWh1LkO8jupl2AQevP4gtuCJVYIbuTwg/O1cesRsrt6sByFVzohRP7wQ0muFVE7z+3X7r/mNU dwI5th8xqL8exiCJ3uX302xd0duIHo7QgnQCjKOW7GA+9Dno2a+OGLwzDvU5d9ZWWy7ePwlN7 cfcU8rQcEq1v443VlP6eiYTZwPkmhHXAOlk5Um5UZRu3gqsBKMZ5c26xrHDVsy7SXl6kmfur9 nTPadR+dzX6IcSsnwBkjiZDk9Z+iBTaGnhX6sij33j4aCumHvHEkZn4Se5HkhhB92PmLbKWTE 1xeQsjPCcm9wpeBv4LkiFwYmmk5ohGn3Nq5+O0HSEMg+A8kJW38l6TTur/QXrR3m60fAS1eHb w0irKLS376vlqPnwMM75zv7HHsZUQXWD+cv1gxKH7yEkIj//kqFYr5zpUr4Dfpsgji+2LEIT0 YL6FfgPdPLb1x/zL6f31H3K0RIyAQJui2XuxeFO8iEmx/lKuFjuvIN22BP7bwG/dquTRkZ1d/ XbLGCTX3bo8hiQ2Huy6LhN7a1VLTE6dSvdO7eTmYCjwW89Npve9lSwXX/kA07RFPKXPiscYvT uuY8oAgci0wcBPhl3Xfk7JZ4kulAf3wkfG6TGWMlK8EDG25QfviCcEiZTfrBaicgTPKhYdqBn DM3CNisIWKkhDIgy1J74hhgHkUkU/bJLyRqNn9l+XpD2zU3pZrTH21CGnO5P5YpPbhBio2bIm OginyggQxMH77tnyy02nDvMN1dPpf1wz5JT14z3sYCipSzRmAxFHdX3/xkY= Archived-At: Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Tue, 11 Oct 2016 16:37:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EWPfpAKRV4JWGL3lUA3gt3ASjkXKoEFrC Content-Type: multipart/mixed; boundary="4m2SqjDWnfCJqiEP3PeMTlDIlpbkxdo6q"; protected-headers="v1" From: Hannes Tschofenig To: Nick Sullivan , "tls@ietf.org" Message-ID: Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) References: In-Reply-To: --4m2SqjDWnfCJqiEP3PeMTlDIlpbkxdo6q Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Nick, given my discussion with Martin in this thread https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like your idea of making the post-handshake messages optional since it allows me to develop a TLS 1.3 client that is smaller in code size. Ciao Hannes On 10/08/2016 03:03 AM, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages= > that do not contain application data and how to handle them. This PR is= > an attempt to make the story more explicit by adding a new > post_handshake extension to TLS 1.3. >=20 > Supporting all types of post-handshake messages can require extra > complexity and logic, even when the features that these messages enable= > are not needed. Some types of connections/implementations don't need to= > support key updates (some unidirectional connections), session tickets > (pure PSK implementations) and post-handshake client auth (most > browsers). These are all currently SHOULDs in the spec and they don't > need to be. >=20 > In order to simplify the logic around dealing with post-handshake > messages, this proposal makes support for each of these modes explicit > via a new handshake extension. This change also makes the path to > introducing other types of post-handshake messages in future drafts mor= e > explicit. >=20 > PR: > https://github.com/tlswg/tls13-spec/pull/676 >=20 > Nick >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --4m2SqjDWnfCJqiEP3PeMTlDIlpbkxdo6q-- --EWPfpAKRV4JWGL3lUA3gt3ASjkXKoEFrC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX/RU1AAoJEGhJURNOOiAttBcH/0gLIyNiZzAi8HKNglztMSCi cWSDzbvoGXVYkE2FMORXc0OP/aTSQM/0Tm7r+Jo5vk7IyVdkWqSilLh3vwoVOm+R nLYtfoUR6mICqLOAH7s4sCP3bfycWT99jbu0s7fVzXBuJhRacolV7qlej7tTdZ1v w8fGIqNSwItwCgqGqvJjjAdvMRej7mPkfJVjYg7slwFjzRfywM5fXO50M7QNTeCq Icy1xS1385Jb8vAB5IzBSDAjx3+QALnueNehXOxq/moML3TQn5Z/s0W14T8M+WYT IgUbTutzNMJSqCqd+FCj2i94VvxTc0+MW66SlRgNV50aAjHrYuZbdb7BQK9rNeY= =xBte -----END PGP SIGNATURE----- --EWPfpAKRV4JWGL3lUA3gt3ASjkXKoEFrC-- From nobody Tue Oct 11 10:22:34 2016 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 CCEA8129566 for ; Tue, 11 Oct 2016 10:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 8-PEDWmm9y96 for ; Tue, 11 Oct 2016 10:22:31 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0238129563 for ; Tue, 11 Oct 2016 10:22:31 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id t193so17689526ywc.2 for ; Tue, 11 Oct 2016 10:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=71a6WM0FxQnjddScrVmV1mUiDnkHmhqBvboao9wwHMs=; b=fq9WAwEEgB8IwnOTGI9nORc2DuYdrRtzcvDRNAiglXf4SStqY7rbJXZVNUrG2TH6fu 0a6vvRUNoFmRrW/Qc6DQapHKuw1Lbc5zy3nQs4g+LFaEpWiNLunCA4tKXfdfZc884nc9 w7sCSX1AtOAj1UTUekeLdajjU4MDE+EomusIlKMsi3il3GPJPVjKnXUNu8ODbHcv8vCp mYR+CVXrKLjCguCQxzVYn/whU+f3tok3nIqNoUVgfF910E9Pd0j0Iy6AUL90dvlpk2q7 2UXI32leEbGCYu09H/MBCT6Lhg18Ssd22aVm5WbhG3DVa//j8f4voSNHIZMA4og/DrRI 6VRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=71a6WM0FxQnjddScrVmV1mUiDnkHmhqBvboao9wwHMs=; b=Ga7RRSmvt7BabYQzCGcboTuXOsEpeivBMUwnXo0zkm7bmlNcGvx6IftbPYF0YIMJet 30OBLyd3j1uU9IJ/wra09HSgmV9Wj8TiM+vNdYQQ3PCg6pI16tH4HZzXVqNUZ/8ZcLlD QCpGK/rmhbul3cP+n5lB01c4rAerVDf7MbfwvBQe7xoulw3KnFa3RMaFuMbdxHQTcpHn fM9bnBs/ENiRlgv4+BStt9Y1/o3J8joECfdZdvjrcojfblXPsgohmEI7J6gZlGNmyzDn ZDd1qdVe6jx+baPe/zvkEoAorgt4x0xI5/wwPbDsP42wyUHyw/+9yW6I6bi6KlWwHZV2 MwbA== X-Gm-Message-State: AA6/9RmBZws9wFLScVOe4dLxKsjC08oTZHNGsnUOop+qSrKVlEflY/FuNikbyv61l+v7HuCAzyJdST9h6T4/lQ== X-Received: by 10.129.60.10 with SMTP id j10mr4802789ywa.354.1476206550941; Tue, 11 Oct 2016 10:22:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Tue, 11 Oct 2016 10:21:50 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 11 Oct 2016 10:21:50 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a1142702615d1dd053e9a1fec Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Tue, 11 Oct 2016 17:22:34 -0000 --001a1142702615d1dd053e9a1fec Content-Type: text/plain; charset=UTF-8 I think it would be simpler (and deal with most cases) to only allow this for specific application profiles (we would then allow it in HTTP/H2, perhaps with some small -bis RFC). Here is a PR for this: https://github.com/tlswg/tls13-spec/pull/680 Andrei, would this cause you any problem? My impression was that this use case was only about HTTP/H2. Thanks, -Ekr On Tue, Oct 11, 2016 at 9:37 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Nick, > > given my discussion with Martin in this thread > https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like > your idea of making the post-handshake messages optional since it allows > me to develop a TLS 1.3 client that is smaller in code size. > > Ciao > Hannes > > > On 10/08/2016 03:03 AM, Nick Sullivan wrote: > > There has been a lot of discussion lately about post-handshake messages > > that do not contain application data and how to handle them. This PR is > > an attempt to make the story more explicit by adding a new > > post_handshake extension to TLS 1.3. > > > > Supporting all types of post-handshake messages can require extra > > complexity and logic, even when the features that these messages enable > > are not needed. Some types of connections/implementations don't need to > > support key updates (some unidirectional connections), session tickets > > (pure PSK implementations) and post-handshake client auth (most > > browsers). These are all currently SHOULDs in the spec and they don't > > need to be. > > > > In order to simplify the logic around dealing with post-handshake > > messages, this proposal makes support for each of these modes explicit > > via a new handshake extension. This change also makes the path to > > introducing other types of post-handshake messages in future drafts more > > explicit. > > > > PR: > > https://github.com/tlswg/tls13-spec/pull/676 > > > > Nick > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1142702615d1dd053e9a1fec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it would be simpler (and deal with most cases) to = only allow this for specific application
profiles (we would then allow = it in HTTP/H2, perhaps with some small -bis RFC).

= Here is a PR for this:

Andrei, would this cause you any problem? My impression w= as that this use case was only
about HTTP/H2.

Thanks,
-Ekr



On Tue, Oct 11, 2016 a= t 9:37 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Nick,

given my discussion with Martin in this thread
https://www.ietf.org/mail-archiv= e/web/tls/current/msg21481.html I like
your idea of making the post-handshake messages optional since it allows me to develop a TLS 1.3 client that is smaller in code size.

Ciao
Hannes


On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake message= s
> that do not contain application data and how to handle them. This PR i= s
> an attempt to make the story more explicit by adding a new
> post_handshake extension to TLS 1.3.
>
> Supporting all types of post-handshake messages can require extra
> complexity and logic, even when the features that these messages enabl= e
> are not needed. Some types of connections/implementations don't ne= ed to
> support key updates (some unidirectional connections), session tickets=
> (pure PSK implementations) and post-handshake client auth (most
> browsers). These are all currently SHOULDs in the spec and they don= 9;t
> need to be.
>
> In order to simplify the logic around dealing with post-handshake
> messages, this proposal makes support for each of these modes explicit=
> via a new handshake extension. This change also makes the path to
> introducing other types of post-handshake messages in future drafts mo= re
> explicit.
>
> PR:
> https://github.com/tlswg/tls13-spec/pull/676
>
> Nick
>
>
> __________________= _____________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


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


--001a1142702615d1dd053e9a1fec-- From nobody Tue Oct 11 10:26:17 2016 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 2B07F129557 for ; Tue, 11 Oct 2016 10:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 t4gDIhF0Z7dN for ; Tue, 11 Oct 2016 10:26:14 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D3E12952B for ; Tue, 11 Oct 2016 10:26:14 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id j37so32318741ioo.3 for ; Tue, 11 Oct 2016 10:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1A7D4AyPrXOzF4AlzfBzqekmd+yl8buFxJW0WdXQhww=; b=Sa2CKZKvGi2Lybt++sMQte//+VoSiuO96Zuw/t7JPMygL+Cluum8BsoSUnRMya5Un8 XZ8IEIeHgr7n3zs722EyG3U6nAQ5xKnq1KUK6drQJJ1h+AFKLHgEQOZhfH8x5rHAbTur 5VtEQfscpIHMIgIe5cL5/9GpB9JuxPnJj2LqG2r7pq7t8/SKiLruYuqoYincN3qXlVR0 aUHwI4+XtHinkGC5fmWgLo+cUyOUTU1cm+kqOrjaMx+Adn2VnrL6DzPYDrjrAF6DDYMC L5N36OLPzG4DYAPf6vqcL45JzBfkDS5ed4qqVEIixuRntBjC+l1JnBSpwMsIhhhmjxE/ SOXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1A7D4AyPrXOzF4AlzfBzqekmd+yl8buFxJW0WdXQhww=; b=I8mKPmss9c1SE4iiM/GzioUuT/78OYsKSQnEC7e9RwA4EBvRAY8TPSQ+j+ZAG6kZDq acpZgkUJ3+duQI9bPIwLaEKnYr+qmQTZzKWFbA3aAODxwd/GhiR/i+mmigbKaqBu+rcz SL0ImUk7sXDX0Bz8MuBtev2NVudup/oLW+a67rVLkP2HQxxPGXNVI0VnFxg65imPauIG 2X0tav9J4xeMwIDw66bkISEBey2oGlyRX4pg8AS+7bteezNnO2fodwLCqowwjtYuQiia aEO/GNvigKrdT0Jm9+UHmZOUc7qPnpSFL20dZeGZw0pc6spkNGa/Q+8HGqvro+FsniLX xplA== X-Gm-Message-State: AA6/9Rl/7fp+RBH+cnlmtIaV1dkhUU9YVC1bVO4opOZPPNyh6zsMUw2DewueJEp+GymSEr90dhvfdG2Tp22Tqg== X-Received: by 10.107.185.8 with SMTP id j8mr2622247iof.3.1476206773700; Tue, 11 Oct 2016 10:26:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Tue, 11 Oct 2016 17:26:02 +0000 Message-ID: To: Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c076a6a5cd83d053e9a2cf1 Archived-At: Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Tue, 11 Oct 2016 17:26:16 -0000 --94eb2c076a6a5cd83d053e9a2cf1 Content-Type: text/plain; charset=UTF-8 The major thing that this proposal achieves is that it makes post-handshake auth an optional part of the implementation. Instead of this, I would also be in favor of a simpler change that modifies the text to say that post-handshake CertificateRequest messages are fatal by default and only permitted if the application permits their use in a given context (say if the application is HTTP 1.1, only directly after requests). Embedded implementations may choose to simply fail on unexpected CertificateRequests, and that way not have to implement any code around post-handshake finished messages or updating the transcript when one arrives. This default wording should also apply to other types of post-handshake messages, though NST and KU could be exceptions that should always be supported and non-fatal. On Tue, Oct 11, 2016 at 9:37 AM Hannes Tschofenig wrote: > Hi Nick, > > given my discussion with Martin in this thread > https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like > your idea of making the post-handshake messages optional since it allows > me to develop a TLS 1.3 client that is smaller in code size. > > Ciao > Hannes > > > On 10/08/2016 03:03 AM, Nick Sullivan wrote: > > There has been a lot of discussion lately about post-handshake messages > > that do not contain application data and how to handle them. This PR is > > an attempt to make the story more explicit by adding a new > > post_handshake extension to TLS 1.3. > > > > Supporting all types of post-handshake messages can require extra > > complexity and logic, even when the features that these messages enable > > are not needed. Some types of connections/implementations don't need to > > support key updates (some unidirectional connections), session tickets > > (pure PSK implementations) and post-handshake client auth (most > > browsers). These are all currently SHOULDs in the spec and they don't > > need to be. > > > > In order to simplify the logic around dealing with post-handshake > > messages, this proposal makes support for each of these modes explicit > > via a new handshake extension. This change also makes the path to > > introducing other types of post-handshake messages in future drafts more > > explicit. > > > > PR: > > https://github.com/tlswg/tls13-spec/pull/676 > > > > Nick > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > --94eb2c076a6a5cd83d053e9a2cf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The major thing that this proposal achieves is that it mak= es post-handshake auth an optional part of the implementation. Instead of t= his, I would also be in favor of a simpler change that modifies the text to= say that post-handshake CertificateRequest messages are fatal by default a= nd only permitted if the application permits their use in a given context (= say if the application is HTTP 1.1, only directly after requests).

=
Embedded implementations may choose to simply fail on unexpected= CertificateRequests, and that way not have to implement any code around po= st-handshake finished messages or updating the transcript when one arrives.=

This default wording should also apply to other types o= f post-handshake messages, though NST and KU could be exceptions that shoul= d always be supported and non-fatal.

On Tue, Oct 11, 2016 at 9:37 = AM Hannes Tschofenig <hanne= s.tschofenig@gmx.net> wrote:
Hi Nick,

given my discussion with Martin in this thread
https://www.ietf.= org/mail-archive/web/tls/current/msg21481.html I like
your idea of making the post-handshake messages optional since it allows me to develop a TLS 1.3 client that is smaller in code size.

Ciao
Hannes


On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake message= s
> that do not contain application data and how to handle them. This PR i= s
> an attempt to make the story more explicit by adding a new
> post_handshake extension to TLS 1.3.
>
> Supporting all types of post-handshake messages can require extra
> complexity and logic, even when the features that these messages enabl= e
> are not needed. Some types of connections/implementations don't ne= ed to
> support key updates (some unidirectional connections), session tickets=
> (pure PSK implementations) and post-handshake client auth (most
> browsers). These are all currently SHOULDs in the spec and they don= 9;t
> need to be.
>
> In order to simplify the logic around dealing with post-handshake
> messages, this proposal makes support for each of these modes explicit=
> via a new handshake extension. This change also makes the path to
> introducing other types of post-handshake messages in future drafts mo= re
> explicit.
>
> PR:
> https://github.com/tlswg/tls13-= spec/pull/676
>
> Nick
>
>
> _______________________________________________
> TLS mailing list
> = TLS@ietf.org
> https://www.ietf.org/mailman/listi= nfo/tls
>

--94eb2c076a6a5cd83d053e9a2cf1-- From nobody Tue Oct 11 11:08:40 2016 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 E5382129652 for ; Tue, 11 Oct 2016 11:08:38 -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_H3=-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 Z3M0Boe6uh_L for ; Tue, 11 Oct 2016 11:08:36 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0104.outbound.protection.outlook.com [104.47.38.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4B612964C for ; Tue, 11 Oct 2016 11:08:35 -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=gha5jVbKyZBjRpWhAfBr1zWR8N0XS4ti90UUl/PsL/Y=; b=ND8RettIlv+rMDcZ4FU3RHFyRKlEE7FaffLNHvtiu5tP/3o6mscDB8ZT+NTxCeD1UD1Zolnahjfen0kbYXVGnktyu16HsX5eFknoHiXFfXNnK7KGtxoReWVMML5NGAV98dEVCCK993ECizAdddJ8kXqYG4Fl3dpvVj7526FXUOI= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Tue, 11 Oct 2016 18:08:33 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0649.027; Tue, 11 Oct 2016 18:08:33 +0000 From: Andrei Popov To: Eric Rescorla , Hannes Tschofenig , Mike Bishop Thread-Topic: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) Thread-Index: AQHSIP/SPFMLyEzrU065iUHGJctjPaCjeWoAgAAMfQCAAAzmoA== Date: Tue, 11 Oct 2016 18:08:33 +0000 Message-ID: References: In-Reply-To: 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=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: 1bb0d3be-e4bd-4ede-47cc-08d3f2019d29 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:uJqR+V6dlYOJ50xevg3G3ya+SR2/v6TfIMKlWHh/74ciTjwsub9QE4WInYtLcZrE43VoxTw+O3ULLM3qcExeWfhVe/w/6i++XejuvtlOAineAI/0L99T/N+SMH6X9BVy6soJs4WOAljtsRWhVM8MPb8h5sQayO/qftKuHKigwGHFcGzhLbFDhDLrmqqylVmyblPsdjQCXjV3h8c1T4RqaFaIKbkjddYOXGRxhA9q3Oj1Sm5d2mpIaYHs1q5pTT4W9ebrXIJyLnkwosHmI0Ie0R+vAnwgpK9NfRFP4BNUZWjj76Kp84pfmUaAiFbbM4se0wOR+MFcscqmm5AuADs63QAAL3UDB+EzAh68MhBXBmQcRgx8a/Sq45J4kdBX8qSX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2707; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(248736688235697)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(199003)(189002)(74316002)(10710500007)(790700001)(6116002)(102836003)(3660700001)(7906003)(7846002)(87936001)(9686002)(561944003)(2950100002)(4326007)(86612001)(76576001)(19625215002)(8990500004)(15650500001)(19580395003)(19609705001)(8936002)(77096005)(3280700002)(1511001)(19300405004)(5002640100001)(19580405001)(86362001)(6862003)(15975445007)(11100500001)(97736004)(7696004)(6636002)(2561002)(81166006)(105586002)(99286002)(81156014)(2906002)(50986999)(76176999)(122556002)(2420400007)(92566002)(10090500001)(101416001)(2900100001)(7736002)(33656002)(106356001)(7110500001)(54356999)(16236675004)(189998001)(2421001)(8676002)(586003)(68736007)(5001770100001)(5660300001)(106116001)(5005710100001)(19617315012)(10290500002)(10400500002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:CY1PR0301MB0842.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_CY1PR0301MB0842DBBF261CAF19F16896898CDA0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2016 18:08:33.3097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Tue, 11 Oct 2016 18:08:39 -0000 --_000_CY1PR0301MB0842DBBF261CAF19F16896898CDA0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KyBNaWtlIHdobyBoYXMgYWRkaXRpb25hbCBjb25jZXJucyB3aXRoIHRoaXMuDQoNCkNoZWVycywN Cg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMSwgMjAxNiAx MDoyMiBBTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0 Pg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIE1ha2luZyBwb3N0LWhhbmRz aGFrZSBtZXNzYWdlcyBvcHRpb25hbCBpbiBUTFMgMS4zICgjNjc2KQ0KDQpJIHRoaW5rIGl0IHdv dWxkIGJlIHNpbXBsZXIgKGFuZCBkZWFsIHdpdGggbW9zdCBjYXNlcykgdG8gb25seSBhbGxvdyB0 aGlzIGZvciBzcGVjaWZpYyBhcHBsaWNhdGlvbg0KcHJvZmlsZXMgKHdlIHdvdWxkIHRoZW4gYWxs b3cgaXQgaW4gSFRUUC9IMiwgcGVyaGFwcyB3aXRoIHNvbWUgc21hbGwgLWJpcyBSRkMpLg0KDQpI ZXJlIGlzIGEgUFIgZm9yIHRoaXM6DQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3Bl Yy9wdWxsLzY4MA0KDQpBbmRyZWksIHdvdWxkIHRoaXMgY2F1c2UgeW91IGFueSBwcm9ibGVtPyBN eSBpbXByZXNzaW9uIHdhcyB0aGF0IHRoaXMgdXNlIGNhc2Ugd2FzIG9ubHkNCmFib3V0IEhUVFAv SDIuDQoNClRoYW5rcywNCi1Fa3INCg0KDQoNCk9uIFR1ZSwgT2N0IDExLCAyMDE2IGF0IDk6Mzcg QU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpo YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQpIaSBOaWNrLA0KDQpnaXZlbiBteSBk aXNjdXNzaW9uIHdpdGggTWFydGluIGluIHRoaXMgdGhyZWFkDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzIxNDgxLmh0bWwgSSBsaWtlDQp5b3Vy IGlkZWEgb2YgbWFraW5nIHRoZSBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBvcHRpb25hbCBzaW5j ZSBpdCBhbGxvd3MNCm1lIHRvIGRldmVsb3AgYSBUTFMgMS4zIGNsaWVudCB0aGF0IGlzIHNtYWxs ZXIgaW4gY29kZSBzaXplLg0KDQpDaWFvDQpIYW5uZXMNCg0KDQpPbiAxMC8wOC8yMDE2IDAzOjAz IEFNLCBOaWNrIFN1bGxpdmFuIHdyb3RlOg0KPiBUaGVyZSBoYXMgYmVlbiBhIGxvdCBvZiBkaXNj dXNzaW9uIGxhdGVseSBhYm91dCBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcw0KPiB0aGF0IGRvIG5v dCBjb250YWluIGFwcGxpY2F0aW9uIGRhdGEgYW5kIGhvdyB0byBoYW5kbGUgdGhlbS4gVGhpcyBQ UiBpcw0KPiBhbiBhdHRlbXB0IHRvIG1ha2UgdGhlIHN0b3J5IG1vcmUgZXhwbGljaXQgYnkgYWRk aW5nIGEgbmV3DQo+IHBvc3RfaGFuZHNoYWtlIGV4dGVuc2lvbiB0byBUTFMgMS4zLg0KPg0KPiBT dXBwb3J0aW5nIGFsbCB0eXBlcyBvZiBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBjYW4gcmVxdWly ZSBleHRyYQ0KPiBjb21wbGV4aXR5IGFuZCBsb2dpYywgZXZlbiB3aGVuIHRoZSBmZWF0dXJlcyB0 aGF0IHRoZXNlIG1lc3NhZ2VzIGVuYWJsZQ0KPiBhcmUgbm90IG5lZWRlZC4gU29tZSB0eXBlcyBv ZiBjb25uZWN0aW9ucy9pbXBsZW1lbnRhdGlvbnMgZG9uJ3QgbmVlZCB0bw0KPiBzdXBwb3J0IGtl eSB1cGRhdGVzIChzb21lIHVuaWRpcmVjdGlvbmFsIGNvbm5lY3Rpb25zKSwgc2Vzc2lvbiB0aWNr ZXRzDQo+IChwdXJlIFBTSyBpbXBsZW1lbnRhdGlvbnMpIGFuZCBwb3N0LWhhbmRzaGFrZSBjbGll bnQgYXV0aCAobW9zdA0KPiBicm93c2VycykuIFRoZXNlIGFyZSBhbGwgY3VycmVudGx5IFNIT1VM RHMgaW4gdGhlIHNwZWMgYW5kIHRoZXkgZG9uJ3QNCj4gbmVlZCB0byBiZS4NCj4NCj4gSW4gb3Jk ZXIgdG8gc2ltcGxpZnkgdGhlIGxvZ2ljIGFyb3VuZCBkZWFsaW5nIHdpdGggcG9zdC1oYW5kc2hh a2UNCj4gbWVzc2FnZXMsIHRoaXMgcHJvcG9zYWwgbWFrZXMgc3VwcG9ydCBmb3IgZWFjaCBvZiB0 aGVzZSBtb2RlcyBleHBsaWNpdA0KPiB2aWEgYSBuZXcgaGFuZHNoYWtlIGV4dGVuc2lvbi4gVGhp cyBjaGFuZ2UgYWxzbyBtYWtlcyB0aGUgcGF0aCB0bw0KPiBpbnRyb2R1Y2luZyBvdGhlciB0eXBl cyBvZiBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBpbiBmdXR1cmUgZHJhZnRzIG1vcmUNCj4gZXhw bGljaXQuDQo+DQo+IFBSOg0KPiBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9w dWxsLzY3Ng0KPg0KPiBOaWNrDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4gVExTQGlldGYub3JnPG1h aWx0bzpUTFNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_CY1PR0301MB0842DBBF261CAF19F16896898CDA0CY1PR0301MB0842_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mIzQzOyBNaWtlIHdobyBoYXMgYWRkaXRpb25hbCBjb25jZXJucyB3aXRoIHRoaXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgW21haWx0bzp0bHMtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDExLCAyMDE2IDEwOjIyIEFNPGJyPg0KPGI+VG86 PC9iPiBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCZndDs8 YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RM U10gTWFraW5nIHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzIG9wdGlvbmFsIGluIFRMUyAxLjMgKCM2 NzYpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCB3b3Vs ZCBiZSBzaW1wbGVyIChhbmQgZGVhbCB3aXRoIG1vc3QgY2FzZXMpIHRvIG9ubHkgYWxsb3cgdGhp cyBmb3Igc3BlY2lmaWMgYXBwbGljYXRpb248bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5wcm9maWxlcyAod2Ugd291bGQgdGhlbiBhbGxvdyBpdCBpbiBIVFRQL0gy LCBwZXJoYXBzIHdpdGggc29tZSBzbWFsbCAtYmlzIFJGQykuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgYSBQUiBmb3IgdGhpczo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvNjgwIj5odHRwczov L2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzY4MDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmVpLCB3b3VsZCB0aGlz IGNhdXNlIHlvdSBhbnkgcHJvYmxlbT8gTXkgaW1wcmVzc2lvbiB3YXMgdGhhdCB0aGlzIHVzZSBj YXNlIHdhcyBvbmx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5hYm91dCBIVFRQL0gyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAxMSwgMjAxNiBhdCA5OjM3 IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2Zl bmlnQGdteC5uZXQiIHRhcmdldD0iX2JsYW5rIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgTmljayw8YnI+DQo8YnI+DQpnaXZlbiBteSBkaXNjdXNzaW9uIHdpdGggTWFydGlu IGluIHRoaXMgdGhyZWFkPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyMTQ4MS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyMTQ4MS5o dG1sPC9hPiBJIGxpa2U8YnI+DQp5b3VyIGlkZWEgb2YgbWFraW5nIHRoZSBwb3N0LWhhbmRzaGFr ZSBtZXNzYWdlcyBvcHRpb25hbCBzaW5jZSBpdCBhbGxvd3M8YnI+DQptZSB0byBkZXZlbG9wIGEg VExTIDEuMyBjbGllbnQgdGhhdCBpcyBzbWFsbGVyIGluIGNvZGUgc2l6ZS48YnI+DQo8YnI+DQpD aWFvPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi Pkhhbm5lczwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCk9uIDEwLzA4LzIwMTYgMDM6MDMgQU0sIE5pY2sg U3VsbGl2YW4gd3JvdGU6PGJyPg0KJmd0OyBUaGVyZSBoYXMgYmVlbiBhIGxvdCBvZiBkaXNjdXNz aW9uIGxhdGVseSBhYm91dCBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlczxicj4NCiZndDsgdGhhdCBk byBub3QgY29udGFpbiBhcHBsaWNhdGlvbiBkYXRhIGFuZCBob3cgdG8gaGFuZGxlIHRoZW0uIFRo aXMgUFIgaXM8YnI+DQomZ3Q7IGFuIGF0dGVtcHQgdG8gbWFrZSB0aGUgc3RvcnkgbW9yZSBleHBs aWNpdCBieSBhZGRpbmcgYSBuZXc8YnI+DQomZ3Q7IHBvc3RfaGFuZHNoYWtlIGV4dGVuc2lvbiB0 byBUTFMgMS4zLjxicj4NCiZndDs8YnI+DQomZ3Q7IFN1cHBvcnRpbmcgYWxsIHR5cGVzIG9mIHBv c3QtaGFuZHNoYWtlIG1lc3NhZ2VzIGNhbiByZXF1aXJlIGV4dHJhPGJyPg0KJmd0OyBjb21wbGV4 aXR5IGFuZCBsb2dpYywgZXZlbiB3aGVuIHRoZSBmZWF0dXJlcyB0aGF0IHRoZXNlIG1lc3NhZ2Vz IGVuYWJsZTxicj4NCiZndDsgYXJlIG5vdCBuZWVkZWQuIFNvbWUgdHlwZXMgb2YgY29ubmVjdGlv bnMvaW1wbGVtZW50YXRpb25zIGRvbid0IG5lZWQgdG88YnI+DQomZ3Q7IHN1cHBvcnQga2V5IHVw ZGF0ZXMgKHNvbWUgdW5pZGlyZWN0aW9uYWwgY29ubmVjdGlvbnMpLCBzZXNzaW9uIHRpY2tldHM8 YnI+DQomZ3Q7IChwdXJlIFBTSyBpbXBsZW1lbnRhdGlvbnMpIGFuZCBwb3N0LWhhbmRzaGFrZSBj bGllbnQgYXV0aCAobW9zdDxicj4NCiZndDsgYnJvd3NlcnMpLiBUaGVzZSBhcmUgYWxsIGN1cnJl bnRseSBTSE9VTERzIGluIHRoZSBzcGVjIGFuZCB0aGV5IGRvbid0PGJyPg0KJmd0OyBuZWVkIHRv IGJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEluIG9yZGVyIHRvIHNpbXBsaWZ5IHRoZSBsb2dpYyBh cm91bmQgZGVhbGluZyB3aXRoIHBvc3QtaGFuZHNoYWtlPGJyPg0KJmd0OyBtZXNzYWdlcywgdGhp cyBwcm9wb3NhbCBtYWtlcyBzdXBwb3J0IGZvciBlYWNoIG9mIHRoZXNlIG1vZGVzIGV4cGxpY2l0 PGJyPg0KJmd0OyB2aWEgYSBuZXcgaGFuZHNoYWtlIGV4dGVuc2lvbi4gVGhpcyBjaGFuZ2UgYWxz byBtYWtlcyB0aGUgcGF0aCB0bzxicj4NCiZndDsgaW50cm9kdWNpbmcgb3RoZXIgdHlwZXMgb2Yg cG9zdC1oYW5kc2hha2UgbWVzc2FnZXMgaW4gZnV0dXJlIGRyYWZ0cyBtb3JlPGJyPg0KJmd0OyBl eHBsaWNpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBQUjo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvNjc2IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC82NzY8L2E+PGJyPg0KJmd0 Ozxicj4NCiZndDsgTmljazxicj4NCiZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7IFRMUyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PGJyPg0K Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR0301MB0842DBBF261CAF19F16896898CDA0CY1PR0301MB0842_-- From nobody Tue Oct 11 11:21:17 2016 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 395DF12956E for ; Tue, 11 Oct 2016 11:21:15 -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_H3=-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 ON-IjgYwh_E5 for ; Tue, 11 Oct 2016 11:21:12 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0101.outbound.protection.outlook.com [104.47.32.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E006E12952D for ; Tue, 11 Oct 2016 11:21:11 -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=+memZ4IXjDWhmYyE8R+1RH2VItHo00uCQfA8szFk/0w=; b=NRa4AlYG+dNaxdDKYMVe4jMocduiPlsTfTEACmBtAnJelp/YTkwRLEIEmiPL+o5RIGgHRfuFXhnRrYiJIDM71+woBaZR8cCirlh5Fzze+E/qFIbyVTBbJuDZdmVKSmgvgJM0HQxNcfaLZsX2CqXWGqISWJE9AuTzry0eEXpLL3c= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by DM2PR0301MB0846.namprd03.prod.outlook.com (10.160.215.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Tue, 11 Oct 2016 18:21:08 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0659.020; Tue, 11 Oct 2016 18:21:08 +0000 From: Mike Bishop To: Andrei Popov , Eric Rescorla , Hannes Tschofenig Thread-Topic: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) Thread-Index: AQHSIP/SPFMLyEzrU065iUHGJctjPaCjeWoAgAAMfQCAAAzmoIAAAEzA Date: Tue, 11 Oct 2016 18:21:07 +0000 Message-ID: References: In-Reply-To: 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:4898:80e8:2::390] x-ms-office365-filtering-correlation-id: 8f784c90-40cf-4095-eddc-08d3f2035ef4 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0846; 7:8H+Ke3iO2f0V39NzPw6x+NvjgxWdRgPf3CQHatimbJyG3Wi/lBOXHsyi9hZfoIn2+1JEqgLJrRRNoxeawq6llhnlT6MOycvFO4HEMud8LQ5UGJeiU30/8/TFoT38X8bYuZqxAU7+ahbj/z0qVIaxgf9ai7xxhz1lX8j/8h0pcWI2lHAkgKf1qfNWFctk+YOdQCLpRtjY7+2HRS5l3x2Zx65j6LWys97eZ6cgTLYScRXjJxfHGnx6a3IHqstPyrhD0l0gNl9iG1FDd0bwWLF7f11Vzrh3ovNP5D+w3fxyaC10tceHzHDjonA4z2SgUc/FdjE9PBgfuzIQi+/+cHK43IP/M6TAgu+hhTE/HQR4WZQeFCF3p88KRblKIndYyQkH x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0846; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(248736688235697)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0846; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0846; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(24454002)(105586002)(101416001)(106356001)(99286002)(93886004)(33656002)(106116001)(19625215002)(19300405004)(76176999)(561944003)(54356999)(16236675004)(11100500001)(76576001)(2561002)(86612001)(2421001)(5001770100001)(19617315012)(97736004)(2906002)(19580395003)(8676002)(81166006)(19580405001)(81156014)(4326007)(7736002)(7906003)(50986999)(586003)(7846002)(6116002)(74316002)(10710500007)(102836003)(3660700001)(68736007)(3280700002)(8936002)(2420400007)(15650500001)(9686002)(7110500001)(189998001)(86362001)(10090500001)(87936001)(2950100002)(77096005)(2900100001)(5002640100001)(3900700001)(122556002)(7696004)(15975445007)(92566002)(5005710100001)(1511001)(10400500002)(10290500002)(8990500004)(5660300001)(19609705001)(790700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0846; H:BN6PR03MB2708.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_BN6PR03MB2708347484ED81B842ADE93487DA0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2016 18:21:07.9733 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0846 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Tue, 11 Oct 2016 18:21:15 -0000 --_000_BN6PR03MB2708347484ED81B842ADE93487DA0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIGEgY291cGxlIG9mIHNjZW5hcmlvcyB3ZSBuZWVkIHRvIGtlZXAgaW4gbWluZDoN Cg0KMS4gICAgICAgRXhpc3RpbmcgSFRUUC8xLjEgZXhjaGFuZ2VzIG92ZXIgdXBncmFkZWQgVExT IGNsaWVudHMuICBJZiB3ZSBuZWVkIGEgYnJpZWYgUkZDIHRoYXQgc2F5cyBwb3N0LWhhbmRzaGFr ZSBjbGllbnQgYXV0aCBpcyBhbGxvd2VkIGZvciBIVFRQLzEuMSBvdmVyIFRMUyAxLjMsIHRoYXTi gJlzIGZpbmUuDQoNCjIuICAgICAgIENsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBIVFRQLzIuICBT bGlnaHRseSBsb25nZXIgUkZDIGZvciB0aGlzIChidXQgcG9zc2libHkgdGhlIHNhbWUgb25lKSB0 aGF0IHNheXMgcG9zdC1oYW5kc2hha2UgY2xpZW50IGF1dGggaXMgYWxsb3dlZCBmb3IgSFRUUC8y LCB0aGVuIGRlc2NyaWJpbmcgaG93IHRvIHVzZSB0aGUgY29udGV4dCAoYW5kIG5ldyBIVFRQLzIg ZnJhbWVzLCBpZiBuZWVkZWQpIHRvIGJpbmQgdGhlIFBIQSBleGNoYW5nZSB0byBvbmUgb3IgbW9y ZSBzdHJlYW1zLg0KDQozLiAgICAgICBTZWNvbmRhcnkgc2VydmVyIGF1dGhlbnRpY2F0aW9uIGlu IEhUVFAvMi4gIFRoaXMgYXBwcm9hY2ggc3RpbGwgZG9lc27igJl0IGdpdmUgYSBjbGVhbiB3YXkg dG8gZG8gdGhpcywgdW5sZXNzIHdlIHVzZSBleHBvcnRlcnMgYW5kIHJvbGwgb3VyIG93bi4gIFRo YXQgaGFzIHByb3ZlbiB0byBiZSBhIGxpdHRsZSBoYXphcmRvdXMgdG8gZXZlcnlvbmXigJlzIHBl YWNlIG9mIG1pbmQsIGJ1dCByZW1haW5zIHNvbWV0aGluZyB3ZSBjYW4gcmVmaW5lIGluIHRoZSBm dXR1cmUuDQoNCldoYXQgY29uY2VybnMgbWUgbW9yZSwgdGhvdWdoLCBpcyB0aGUgcHJvc3BlY3Qg dGhhdCBhIGxvdCBvZiBUTFMgaW1wbGVtZW50YXRpb25zIHdvdWxkIHNpbXBseSBvbWl0IHN1cHBv cnQuICBPYnZpb3VzbHksIGl04oCZcyBub3QgdXNlZCBpbiBtb3N0IEhUVFAgc2Vzc2lvbnMsIGFu ZCB5b3UgbWF5IGJlIGFuIGltcGxlbWVudGF0aW9uIHdob3NlIG5pY2hlIGRvZXNu4oCZdCByZXF1 aXJlIHN1cHBvcnRpbmcgaXQg4oCTIGJ1dCBzaW5jZSB0aGUgYXBwbGljYXRpb24gcHJvZmlsZSBh bGxvd3MgaXQsIHlvdSBzdGlsbCBuZWVkIHRvIGtub3cgaG93IHRvIGRlY2xpbmUgaWYgYXNrZWQu ICBJZiBpdOKAmXMgYWxsb3dlZCBpbiBIVFRQLCB3aGljaCBJIGFzc3VtZSBpcyBhIHN1cHBvcnRl ZCB3b3JrbG9hZCBmb3IgbW9zdCBpbXBsZW1lbnRhdGlvbnMsIHRoZW4gaXTigJlzIGFsbG93ZWQg aW4geW91ciBhcHBsaWNhdGlvbiBwcm9maWxlIGFuZCB0aGVyZWZvcmUgcHJvaGliaXRpbmcgaXQg YnkgZGVmYXVsdCBkb2VzbuKAmXQgc2VlbSBsaWtlIGl0IGJ1eXMgeW91IG11Y2guICBIYXZpbmcg YSBzaW1wbGUgd2F5IHRvIGRpc2NsYWltIHN1cHBvcnQsIGVpdGhlciBhdCBjb25uZWN0aW9uIHRp bWUgb3IgdXBvbiByZWNlaXZpbmcgYSBjaGFsbGVuZ2UsIHNlZW1zIGxpa2UgaXQgcHJvdmlkZXMg bW9yZSBzaW1wbGljaXR5IGZvciB0aGUgaW1wbGVtZW50YXRpb25zIHRoYXQgd2FudCB0byBvbWl0 IGl0Lg0KDQpGcm9tOiBBbmRyZWkgUG9wb3YNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTEsIDIw MTYgMTE6MDkgQU0NClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBIYW5uZXMgVHNj aG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD47IE1pa2UgQmlzaG9wIDxNaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtU TFNdIE1ha2luZyBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBvcHRpb25hbCBpbiBUTFMgMS4zICgj Njc2KQ0KDQorIE1pa2Ugd2hvIGhhcyBhZGRpdGlvbmFsIGNvbmNlcm5zIHdpdGggdGhpcy4NCg0K Q2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDEx LCAyMDE2IDEwOjIyIEFNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2Zlbmln QGdteC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+Pg0KQ2M6IHRsc0BpZXRm Lm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIE1ha2luZyBwb3N0 LWhhbmRzaGFrZSBtZXNzYWdlcyBvcHRpb25hbCBpbiBUTFMgMS4zICgjNjc2KQ0KDQpJIHRoaW5r IGl0IHdvdWxkIGJlIHNpbXBsZXIgKGFuZCBkZWFsIHdpdGggbW9zdCBjYXNlcykgdG8gb25seSBh bGxvdyB0aGlzIGZvciBzcGVjaWZpYyBhcHBsaWNhdGlvbg0KcHJvZmlsZXMgKHdlIHdvdWxkIHRo ZW4gYWxsb3cgaXQgaW4gSFRUUC9IMiwgcGVyaGFwcyB3aXRoIHNvbWUgc21hbGwgLWJpcyBSRkMp Lg0KDQpIZXJlIGlzIGEgUFIgZm9yIHRoaXM6DQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxz MTMtc3BlYy9wdWxsLzY4MA0KDQpBbmRyZWksIHdvdWxkIHRoaXMgY2F1c2UgeW91IGFueSBwcm9i bGVtPyBNeSBpbXByZXNzaW9uIHdhcyB0aGF0IHRoaXMgdXNlIGNhc2Ugd2FzIG9ubHkNCmFib3V0 IEhUVFAvSDIuDQoNClRoYW5rcywNCi1Fa3INCg0KDQoNCk9uIFR1ZSwgT2N0IDExLCAyMDE2IGF0 IDk6MzcgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1h aWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQpIaSBOaWNrLA0KDQpnaXZl biBteSBkaXNjdXNzaW9uIHdpdGggTWFydGluIGluIHRoaXMgdGhyZWFkDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzIxNDgxLmh0bWwgSSBsaWtl DQp5b3VyIGlkZWEgb2YgbWFraW5nIHRoZSBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBvcHRpb25h bCBzaW5jZSBpdCBhbGxvd3MNCm1lIHRvIGRldmVsb3AgYSBUTFMgMS4zIGNsaWVudCB0aGF0IGlz IHNtYWxsZXIgaW4gY29kZSBzaXplLg0KDQpDaWFvDQpIYW5uZXMNCg0KDQpPbiAxMC8wOC8yMDE2 IDAzOjAzIEFNLCBOaWNrIFN1bGxpdmFuIHdyb3RlOg0KPiBUaGVyZSBoYXMgYmVlbiBhIGxvdCBv ZiBkaXNjdXNzaW9uIGxhdGVseSBhYm91dCBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcw0KPiB0aGF0 IGRvIG5vdCBjb250YWluIGFwcGxpY2F0aW9uIGRhdGEgYW5kIGhvdyB0byBoYW5kbGUgdGhlbS4g VGhpcyBQUiBpcw0KPiBhbiBhdHRlbXB0IHRvIG1ha2UgdGhlIHN0b3J5IG1vcmUgZXhwbGljaXQg YnkgYWRkaW5nIGEgbmV3DQo+IHBvc3RfaGFuZHNoYWtlIGV4dGVuc2lvbiB0byBUTFMgMS4zLg0K Pg0KPiBTdXBwb3J0aW5nIGFsbCB0eXBlcyBvZiBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBjYW4g cmVxdWlyZSBleHRyYQ0KPiBjb21wbGV4aXR5IGFuZCBsb2dpYywgZXZlbiB3aGVuIHRoZSBmZWF0 dXJlcyB0aGF0IHRoZXNlIG1lc3NhZ2VzIGVuYWJsZQ0KPiBhcmUgbm90IG5lZWRlZC4gU29tZSB0 eXBlcyBvZiBjb25uZWN0aW9ucy9pbXBsZW1lbnRhdGlvbnMgZG9uJ3QgbmVlZCB0bw0KPiBzdXBw b3J0IGtleSB1cGRhdGVzIChzb21lIHVuaWRpcmVjdGlvbmFsIGNvbm5lY3Rpb25zKSwgc2Vzc2lv biB0aWNrZXRzDQo+IChwdXJlIFBTSyBpbXBsZW1lbnRhdGlvbnMpIGFuZCBwb3N0LWhhbmRzaGFr ZSBjbGllbnQgYXV0aCAobW9zdA0KPiBicm93c2VycykuIFRoZXNlIGFyZSBhbGwgY3VycmVudGx5 IFNIT1VMRHMgaW4gdGhlIHNwZWMgYW5kIHRoZXkgZG9uJ3QNCj4gbmVlZCB0byBiZS4NCj4NCj4g SW4gb3JkZXIgdG8gc2ltcGxpZnkgdGhlIGxvZ2ljIGFyb3VuZCBkZWFsaW5nIHdpdGggcG9zdC1o YW5kc2hha2UNCj4gbWVzc2FnZXMsIHRoaXMgcHJvcG9zYWwgbWFrZXMgc3VwcG9ydCBmb3IgZWFj aCBvZiB0aGVzZSBtb2RlcyBleHBsaWNpdA0KPiB2aWEgYSBuZXcgaGFuZHNoYWtlIGV4dGVuc2lv bi4gVGhpcyBjaGFuZ2UgYWxzbyBtYWtlcyB0aGUgcGF0aCB0bw0KPiBpbnRyb2R1Y2luZyBvdGhl ciB0eXBlcyBvZiBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBpbiBmdXR1cmUgZHJhZnRzIG1vcmUN Cj4gZXhwbGljaXQuDQo+DQo+IFBSOg0KPiBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMt c3BlYy9wdWxsLzY3Ng0KPg0KPiBOaWNrDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4gVExTQGlldGYu b3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_BN6PR03MB2708347484ED81B842ADE93487DA0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56 Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEy ODE2MjQ4MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTMxNTg1NjQ4MiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMQ0KCXttc28tbGlzdC1pZDoxNTgzNzU3MDY4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczo3MzEwNTExODAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+VGhlcmUgYXJlIGEgY291cGxlIG9mIHNjZW5hcmlvcyB3ZSBuZWVkIHRvIGtlZXAgaW4gbWlu ZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48L2I+PCFbZW5kaWZdPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXhpc3RpbmcgSFRUUC8xLjEg ZXhjaGFuZ2VzIG92ZXIgdXBncmFkZWQgVExTIGNsaWVudHMuPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyBJZiB3ZSBuZWVkIGEgYnJpZWYgUkZDIHRoYXQNCiBzYXlzIHBvc3QtaGFu ZHNoYWtlIGNsaWVudCBhdXRoIGlzIGFsbG93ZWQgZm9yIEhUVFAvMS4xIG92ZXIgVExTIDEuMywg dGhhdOKAmXMgZmluZS48Yj48bzpwPjwvbzpwPjwvYj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9iPjwhW2VuZGlmXT48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBIVFRQLzIuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyBTbGlnaHRseSBsb25nZXIgUkZDIGZvciB0aGlzIChidXQgcG9zc2libHkgdGhl DQogc2FtZSBvbmUpIHRoYXQgc2F5cyBwb3N0LWhhbmRzaGFrZSBjbGllbnQgYXV0aCBpcyBhbGxv d2VkIGZvciBIVFRQLzIsIHRoZW4gZGVzY3JpYmluZyBob3cgdG8gdXNlIHRoZSBjb250ZXh0IChh bmQgbmV3IEhUVFAvMiBmcmFtZXMsIGlmIG5lZWRlZCkgdG8gYmluZCB0aGUgUEhBIGV4Y2hhbmdl IHRvIG9uZSBvciBtb3JlIHN0cmVhbXMuPGI+PG86cD48L286cD48L2I+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvYj48IVtlbmRpZl0+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5TZWNvbmRhcnkgc2VydmVyIGF1dGhlbnRpY2F0aW9uIGluIEhUVFAvMi48L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7IFRoaXMgYXBwcm9hY2ggc3RpbGwgZG9lc27i gJl0IGdpdmUgYSBjbGVhbg0KIHdheSB0byBkbyB0aGlzLCB1bmxlc3Mgd2UgdXNlIGV4cG9ydGVy cyBhbmQgcm9sbCBvdXIgb3duLiZuYnNwOyBUaGF0IGhhcyBwcm92ZW4gdG8gYmUgYSBsaXR0bGUg aGF6YXJkb3VzIHRvIGV2ZXJ5b25l4oCZcyBwZWFjZSBvZiBtaW5kLCBidXQgcmVtYWlucyBzb21l dGhpbmcgd2UgY2FuIHJlZmluZSBpbiB0aGUgZnV0dXJlLjxiPjxvOnA+PC9vOnA+PC9iPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPldoYXQgY29uY2VybnMgbWUgbW9yZSwgdGhvdWdoLCBpcyB0aGUgcHJvc3BlY3QgdGhh dCBhIGxvdCBvZiBUTFMgaW1wbGVtZW50YXRpb25zIHdvdWxkIHNpbXBseSBvbWl0IHN1cHBvcnQu Jm5ic3A7IE9idmlvdXNseSwgaXTigJlzIG5vdCB1c2VkIGluIG1vc3QgSFRUUCBzZXNzaW9ucywg YW5kIHlvdSBtYXkgYmUNCiBhbiBpbXBsZW1lbnRhdGlvbiB3aG9zZSBuaWNoZSBkb2VzbuKAmXQg cmVxdWlyZSBzdXBwb3J0aW5nIGl0IOKAkyBidXQgc2luY2UgdGhlIGFwcGxpY2F0aW9uIHByb2Zp bGUgYWxsb3dzIGl0LCB5b3Ugc3RpbGwgbmVlZCB0byBrbm93IGhvdyB0byBkZWNsaW5lIGlmIGFz a2VkLiZuYnNwOyBJZiBpdOKAmXMgYWxsb3dlZCBpbiBIVFRQLCB3aGljaCBJIGFzc3VtZSBpcyBh IHN1cHBvcnRlZCB3b3JrbG9hZCBmb3IgbW9zdCBpbXBsZW1lbnRhdGlvbnMsIHRoZW4gaXTigJlz DQogYWxsb3dlZCBpbiB5b3VyIGFwcGxpY2F0aW9uIHByb2ZpbGUgYW5kIHRoZXJlZm9yZSBwcm9o aWJpdGluZyBpdCBieSBkZWZhdWx0IGRvZXNu4oCZdCBzZWVtIGxpa2UgaXQgYnV5cyB5b3UgbXVj aC4mbmJzcDsgSGF2aW5nIGEgc2ltcGxlIHdheSB0byBkaXNjbGFpbSBzdXBwb3J0LCBlaXRoZXIg YXQgY29ubmVjdGlvbiB0aW1lIG9yIHVwb24gcmVjZWl2aW5nIGEgY2hhbGxlbmdlLCBzZWVtcyBs aWtlIGl0IHByb3ZpZGVzIG1vcmUgc2ltcGxpY2l0eSBmb3IgdGhlDQogaW1wbGVtZW50YXRpb25z IHRoYXQgd2FudCB0byBvbWl0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHJl aSBQb3Bvdg0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTEsIDIwMTYgMTE6 MDkgQU08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs7 IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0OzsgTWlr ZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtUTFNdIE1ha2luZyBw b3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBvcHRpb25hbCBpbiBUTFMgMS4zICgjNjc2KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ JiM0MzsgTWlrZSB3aG8gaGFzIGFkZGl0aW9uYWwgY29uY2VybnMgd2l0aCB0aGlzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFs8YSBocmVmPSJtYWlsdG86dGxz LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg T2N0b2JlciAxMSwgMjAxNiAxMDoyMiBBTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVu aWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Ij5oYW5uZXMu dHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0 bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtUTFNdIE1ha2luZyBwb3N0LWhhbmRzaGFrZSBtZXNzYWdlcyBvcHRpb25hbCBpbiBUTFMgMS4z ICgjNjc2KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQg d291bGQgYmUgc2ltcGxlciAoYW5kIGRlYWwgd2l0aCBtb3N0IGNhc2VzKSB0byBvbmx5IGFsbG93 IHRoaXMgZm9yIHNwZWNpZmljIGFwcGxpY2F0aW9uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+cHJvZmlsZXMgKHdlIHdvdWxkIHRoZW4gYWxsb3cgaXQgaW4gSFRU UC9IMiwgcGVyaGFwcyB3aXRoIHNvbWUgc21hbGwgLWJpcyBSRkMpLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIGEgUFIgZm9yIHRo aXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzY4MCI+aHR0 cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC82ODA8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHJlaSwgd291bGQg dGhpcyBjYXVzZSB5b3UgYW55IHByb2JsZW0/IE15IGltcHJlc3Npb24gd2FzIHRoYXQgdGhpcyB1 c2UgY2FzZSB3YXMgb25seTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YWJvdXQgSFRUUC9IMi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgMTEsIDIwMTYgYXQg OTozNyBBTSwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5l dDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBOaWNrLDxi cj4NCjxicj4NCmdpdmVuIG15IGRpc2N1c3Npb24gd2l0aCBNYXJ0aW4gaW4gdGhpcyB0aHJlYWQ8 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9j dXJyZW50L21zZzIxNDgxLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzIxNDgxLmh0bWw8L2E+IEkgbGlrZTxi cj4NCnlvdXIgaWRlYSBvZiBtYWtpbmcgdGhlIHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzIG9wdGlv bmFsIHNpbmNlIGl0IGFsbG93czxicj4NCm1lIHRvIGRldmVsb3AgYSBUTFMgMS4zIGNsaWVudCB0 aGF0IGlzIHNtYWxsZXIgaW4gY29kZSBzaXplLjxicj4NCjxicj4NCkNpYW88YnI+DQo8c3BhbiBj bGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+SGFubmVzPC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyPg0KT24gMTAvMDgvMjAxNiAwMzowMyBBTSwgTmljayBTdWxsaXZhbiB3cm90ZTo8 YnI+DQomZ3Q7IFRoZXJlIGhhcyBiZWVuIGEgbG90IG9mIGRpc2N1c3Npb24gbGF0ZWx5IGFib3V0 IHBvc3QtaGFuZHNoYWtlIG1lc3NhZ2VzPGJyPg0KJmd0OyB0aGF0IGRvIG5vdCBjb250YWluIGFw cGxpY2F0aW9uIGRhdGEgYW5kIGhvdyB0byBoYW5kbGUgdGhlbS4gVGhpcyBQUiBpczxicj4NCiZn dDsgYW4gYXR0ZW1wdCB0byBtYWtlIHRoZSBzdG9yeSBtb3JlIGV4cGxpY2l0IGJ5IGFkZGluZyBh IG5ldzxicj4NCiZndDsgcG9zdF9oYW5kc2hha2UgZXh0ZW5zaW9uIHRvIFRMUyAxLjMuPGJyPg0K Jmd0Ozxicj4NCiZndDsgU3VwcG9ydGluZyBhbGwgdHlwZXMgb2YgcG9zdC1oYW5kc2hha2UgbWVz c2FnZXMgY2FuIHJlcXVpcmUgZXh0cmE8YnI+DQomZ3Q7IGNvbXBsZXhpdHkgYW5kIGxvZ2ljLCBl dmVuIHdoZW4gdGhlIGZlYXR1cmVzIHRoYXQgdGhlc2UgbWVzc2FnZXMgZW5hYmxlPGJyPg0KJmd0 OyBhcmUgbm90IG5lZWRlZC4gU29tZSB0eXBlcyBvZiBjb25uZWN0aW9ucy9pbXBsZW1lbnRhdGlv bnMgZG9uJ3QgbmVlZCB0bzxicj4NCiZndDsgc3VwcG9ydCBrZXkgdXBkYXRlcyAoc29tZSB1bmlk aXJlY3Rpb25hbCBjb25uZWN0aW9ucyksIHNlc3Npb24gdGlja2V0czxicj4NCiZndDsgKHB1cmUg UFNLIGltcGxlbWVudGF0aW9ucykgYW5kIHBvc3QtaGFuZHNoYWtlIGNsaWVudCBhdXRoIChtb3N0 PGJyPg0KJmd0OyBicm93c2VycykuIFRoZXNlIGFyZSBhbGwgY3VycmVudGx5IFNIT1VMRHMgaW4g dGhlIHNwZWMgYW5kIHRoZXkgZG9uJ3Q8YnI+DQomZ3Q7IG5lZWQgdG8gYmUuPGJyPg0KJmd0Ozxi cj4NCiZndDsgSW4gb3JkZXIgdG8gc2ltcGxpZnkgdGhlIGxvZ2ljIGFyb3VuZCBkZWFsaW5nIHdp dGggcG9zdC1oYW5kc2hha2U8YnI+DQomZ3Q7IG1lc3NhZ2VzLCB0aGlzIHByb3Bvc2FsIG1ha2Vz IHN1cHBvcnQgZm9yIGVhY2ggb2YgdGhlc2UgbW9kZXMgZXhwbGljaXQ8YnI+DQomZ3Q7IHZpYSBh IG5ldyBoYW5kc2hha2UgZXh0ZW5zaW9uLiBUaGlzIGNoYW5nZSBhbHNvIG1ha2VzIHRoZSBwYXRo IHRvPGJyPg0KJmd0OyBpbnRyb2R1Y2luZyBvdGhlciB0eXBlcyBvZiBwb3N0LWhhbmRzaGFrZSBt ZXNzYWdlcyBpbiBmdXR1cmUgZHJhZnRzIG1vcmU8YnI+DQomZ3Q7IGV4cGxpY2l0Ljxicj4NCiZn dDs8YnI+DQomZ3Q7IFBSOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3Rs c3dnL3RsczEzLXNwZWMvcHVsbC82NzYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5j b20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzY3NjwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBOaWNr PGJyPg0KJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgVExTIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOlRMU0Bp ZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnI+DQomZ3Q7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExT QGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708347484ED81B842ADE93487DA0BN6PR03MB2708namp_-- From nobody Tue Oct 11 17:16:09 2016 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 C57281293E1 for ; Tue, 11 Oct 2016 17:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Set2YfhJxLyH for ; Tue, 11 Oct 2016 17:16:07 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC85127071 for ; Tue, 11 Oct 2016 17:16:07 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id n189so11866092qke.0 for ; Tue, 11 Oct 2016 17:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U+bmoVy7vQm1dFcBSEGYnQD5hAk/5jEkqDuiPjyi9gg=; b=bcBKngfDYFnh72EiqY25qeqSCOz/hXxRyei9H66WT4RfUL68zrlM+zYLSArY8ePQDO wFvzS/5TJhNhQ006II1AaOoYToyak6Ivaw23cy2GnsADr5CbHzZtZudTWx35iDupS64/ rCsGV/T9ddqS6rcBGosgBjNtG3+OafeY8KPzOMg08jIja3iyFoTV2PLqEc3CdXZe+a/3 bVCg0t4W01EMJ03lVaWBTbe7bgJi0buxyWP3hdeIK03U2pSnemBSbZnQBRYvyj5kdMsb HPi3rYed/a9xIqMbAsToInlz5CHW0RnJ6mJgUQRY9M2MK85Ta6A8w0oTwTVHs3jIUQ3X JS0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U+bmoVy7vQm1dFcBSEGYnQD5hAk/5jEkqDuiPjyi9gg=; b=ihwnzex1yjcKMbjWzPXJ/yvuerNDAF4+IJGqHWq+Gl9zaMVKwr5N6iwyS9Mh/VTYAE BlKs6uMVCzswGJnOX9NRtJvSdylqflnw1iibKk7yYatWdD64OsaUEyRGpaqp4x3TCCHe GlSCGFx0/kzOEcCE20HOWaJS0E3QndZTcuGEYgFk+1PYLXG4mC8ymqQVvLnpLiE6Hlxf J49YG5UWO6uivZRwv2QtL4hHYHwyL/mv+YSErzaNwbfGlJAObLrhj3GLHYV3a7lh/qmA tgCuoXbSSDt2yl2Gds3ysbmY3hG7ysUgy6LYgzkN5E82dxEE8Fx2s0DIo3CMgIrNpPEd PFQg== X-Gm-Message-State: AA6/9RmwLCa4ccFNuSxscrgk2XhupylKmHxVLagUPgsugoQKYbO7F3RQnr0cRbqsLNglqnoNHMctEKXIIjr7ow== X-Received: by 10.55.163.214 with SMTP id m205mr5698438qke.68.1476231366217; Tue, 11 Oct 2016 17:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 11 Oct 2016 17:16:05 -0700 (PDT) In-Reply-To: References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Wed, 12 Oct 2016 11:16:05 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Wed, 12 Oct 2016 00:16:08 -0000 On 12 October 2016 at 00:51, Eric Rescorla wrote: > See: > https://github.com/tlswg/tls13-spec/pull/678 I'm convinced that this is the right change. Reconstruction was always going to be brittle. I will note that I don't think that the change gets the error codes right though. I explained why on the PR. From nobody Tue Oct 11 17:24:05 2016 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 1F6EC129457 for ; Tue, 11 Oct 2016 17:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 c9nFHXEBTUkn for ; Tue, 11 Oct 2016 17:24:02 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66AE41293E1 for ; Tue, 11 Oct 2016 17:24:02 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id f128so11366243qkb.1 for ; Tue, 11 Oct 2016 17:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2WaddRp27u6aCHhbQsZG3wKpzNCXKwkB+jASB40a8PI=; b=EhgQinnfzzOhtPuvu27coy4NqH5ccsDvdCAXgpabHL3EIeafbmxoAtjrnVYqHzCDNu 8vGn6p3y6dPLALYv0GF2F7Xo6QaeXrEMPdKPf0r2andzFUPg0mPGKafSvFBKc8ZduXMt sOyBz08YNQbbj03Q0FHpblSF75rOuv99JuYy3PHo84fzjI7rh1UJ1OPqvr73QoMOVyD8 goTqpqlvssQBIbUEMx0Z0b7Ta2hYmdUR661ltRXpjJJ+5+9VQr4uwwk7e1BKpx+Sc1Np Q89gLX6MxVN/Cu1sE0YD5BJOpNiSC8bJkywFsbbSpu4YXHSyzT2G3oOkxymSTyo9tTmX oPKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2WaddRp27u6aCHhbQsZG3wKpzNCXKwkB+jASB40a8PI=; b=XjvNuViqmvw2OC/sN92hCGAfAaQ1CyCXb97qmlZ9hGAoI7zV3V8YjoYhnmGWiH777l 7l0zhGiuKQqm42VSeOjQVfOM7WtoOQHw3vsiZkvMeTPFEfpfo/9/7NdOLZzZFbjyq7Sj TZxYkiuQh5JdxfBWlPJuhdC4a0daVcrwR6jqTerrP3ynuOQHwvoM0fY2S4TywoV87utc r2mx4UQbF4krLAglNx5vTMMAM0G4ZLShoUpNFNi4FSoZRaCV9JxXy72TRPs9T+cFV9zK Skvhjz4dntm9bGoqgyPhXlAFDkIRitVToaMU1P8PLgkfIFfAPtyUbFdQmw5CAKmVVSKh La+w== X-Gm-Message-State: AA6/9RmZR4CBG9ZH+OQmCtdyAT9z9FyH6fXVSzJhCH9umEXTXchbFN2LHPJZPfJofRgaUhCk91xcNYjXJOWY8Q== X-Received: by 10.55.71.3 with SMTP id u3mr6657775qka.144.1476231841528; Tue, 11 Oct 2016 17:24:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 11 Oct 2016 17:24:01 -0700 (PDT) In-Reply-To: References: <2b155eb4-3268-c687-031e-6ac9928940c3@gmx.net> <43b8276e-a9ff-79f1-7eb9-645500d2582d@gmx.net> From: Martin Thomson Date: Wed, 12 Oct 2016 11:24:01 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Zero-RTT Data & PSK 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: Wed, 12 Oct 2016 00:24:04 -0000 I put a few minor comments on the commit. Nothing that affects the technical content though, it looks correct. (Good catch on SNI, I think that I missed that one.) On 12 October 2016 at 03:23, Eric Rescorla wrote: > This LGTM. Absent objections I will merge tomorrow > > On Tue, Oct 11, 2016 at 9:22 AM, Hannes Tschofenig > wrote: >> >> I gave it a try, see >> >> https://github.com/tlswg/tls13-spec/pull/668/commits/91e5b39e5f0ce62a90effdbaf4e3c90ed0d81245 >> >> >> Ciao >> Hannes >> >> >> On 10/10/2016 11:59 PM, Eric Rescorla wrote: >> > I agree with MT. Hannes, if you want to clean up the text to take into >> > account MT's comments, I will merge >> > >> > On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson >> > > wrote: >> > >> > On 9 September 2016 at 23:37, Hannes Tschofenig >> > > >> > wrote: >> > > I am wondering why I cannot use Zero-RTT with just PSK-based >> > authentication >> > > (without a prior ticket change). >> > >> > I think that you would need to bind more things to the key in that >> > case, but I assume that it would be OK if you did so. You already >> > need to pair a PSK with a hash, but if you paired it with a whole >> > cipher suite instead and also the ALPN (which could be null), then I >> > see no reason not to permit 0-RTT for pure PSK. (I think that >> > cipher >> > suite + ALPN is sufficient, but someone can correct me if I missed >> > anything.) >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> > >> > >> > From nobody Tue Oct 11 17:24:58 2016 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 8479C1295C6 for ; Tue, 11 Oct 2016 17:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 fF-I5X_5bTwP for ; Tue, 11 Oct 2016 17:24:54 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F8D1293E1 for ; Tue, 11 Oct 2016 17:24:53 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id n189so12019312qke.0 for ; Tue, 11 Oct 2016 17:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=3jP2rcUn2BWLuAD9cHFinLTjYATyzswRNVzblXRqOGg=; b=heAQI7cTNLRBPg+Yq17rOcuqIym+MmeTrkta+QwxOuyWIVs8LvEujkYtHueUZW/m1f WxtHv7vVJcd+37tV/Joo75575ti5JpApbPCyBKS4MF2yFfYjRLhvZgItn6ub5/+18+CX wHSW2EG7KxIa/tddBooPUDOMAx6AS5sr8NPTY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=3jP2rcUn2BWLuAD9cHFinLTjYATyzswRNVzblXRqOGg=; b=RcZsErKxjn27YAKm8mREL91yKLFBo33OsW0TlcG5uY4vGGkrEbMN9vEKViepKZ+bv0 mZflpElpig5ELrjpNVTx8ezwv1UxvnYMl0p7fz9gxQDNXGTm2m/IByeuHb1SRdtj2Vew 8+wcz4ev+a8XhnypXw6bEVnNjb97VOik56ssvrTMqhy7IPzypmrtbjgq53a3a7v6nheJ W2Fd6Splzr3G4JqezYL8Qn+AfOdP4btJ2ZYON8uDzq2F7mUhpVpKSYvewkBCLr567GoQ /tIXbB1EFjONfbM+5vHD+yAnEzd12Gxbe+uKtAbX3UKPRRjsSRJJmMdOPjFWsUWlPCIy YoVg== X-Gm-Message-State: AA6/9Rm1FWoe/KI3YWr+BrkdCdgfbQvhf2w5VREVKFIlRolYnlEAF2bn+wiHZ6BCPFgxPg== X-Received: by 10.55.65.22 with SMTP id o22mr5610866qka.136.1476231892775; Tue, 11 Oct 2016 17:24:52 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id l6sm1959842qkd.41.2016.10.11.17.24.50 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Oct 2016 17:24:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Tue, 11 Oct 2016 20:24:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87fuoa64p4.fsf@mid.deneb.enyo.de> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Wed, 12 Oct 2016 00:24:56 -0000 As one of the WG chairs, it looks like it=E2=80=99s time to bring to a = close whether or not we=E2=80=99ll be re-introducing static RSA key = exchange. One digression before that though: I think there is a realization in the = IAB, IESG, and many parts of the IETF that significant = operational/management issues exist with encryption; the MaRNEW workshop = [0][1][2], some related drafts [3][4], and the PLUS/ACCORD BOFs = proposals are just some examples that reflect this. On dropping static RSA key exchange: The DH-only key exchange proposal = had a very lengthy and robust discussion. PFS was definitely a driver = [5], but the simplifying effect of removing static RSA key exchange was = another one that should not be forgotten; less options, less code, = (hopefully) less coding errors. It is probably also worth pointing out = that the "remove RSA key exchange" shoe has been dropping since 2003: = =E2=80=9CRSAES-OAEP is recommended for new applications; = RSAES-PKCS1-v1_5 is included only for compatibility with existing = applications, and is not recommended for new applications=E2=80=9D [6]. On the one hand, I am sympathetic to concerns about impacts resulting = from protocol changes. On the other hand, the cycle of new protocol = version followed by product updates is not really that out of the = ordinary; this cycle is disliked by those with budgets but normal = nonetheless. Also, there appears to be a couple of different solutions = that would allow an enterprise to do what it wants. I=E2=80=99m not = seeing anything that would alter the consensus that we reached earlier = to drop static RSA key exchange from TLS 1.3. spt [0] https://www.iab.org/activities/workshops/marnew/ [1] https://datatracker.ietf.org/doc/draft-nrooney-marnew-report/ [2] https://www.ietf.org/proceedings/94/slides/slides-94-saag-1.pdf [3] https://www.ietf.org/archive/id/draft-mm-wg-effect-encrypt-03.txt [4] = https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-management/= [5] https://datatracker.ietf.org/doc/rfc7525/ [6] https://datatracker.ietf.org/doc/rfc3447/ > On Oct 05, 2016, at 15:37, BITS Security = wrote: >=20 > Florian--Anecdotally, I have heard Microsoft and F5 did code upgrades = a few years back that moved Diffie Hellman to the top cipher suite = priorities which broke security and fraud monitoring, APM reporting, and = sniffer troubleshooting for a financial services client and at least one = other organization in a different industry. =20 >=20 > The solution, at the time, was to put the PFS options (choices we will = no longer in 1.3) at the bottom of the priority list. I don't know how = much of this was communicated back to the vendors at the time. =20 >=20 > In retrospect, this could have been seen as the canary in the = coalmine... but here we are now at least. =20 >=20 > - Andrew=20 >=20 >=20 > -----Original Message----- > From: Florian Weimer [mailto:fw@deneb.enyo.de]=20 > Sent: Wednesday, October 5, 2016 2:17 PM > To: BITS Security > Cc: tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 >=20 > * BITS Security: >=20 >> Deprecation of the RSA key exchange in TLS 1.3 will cause significant=20= >> problems for financial institutions, almost all of whom are running=20= >> TLS internally and have significant, security-critical investments in=20= >> out-of-band TLS decryption. >>=20 >> Like many enterprises, financial institutions depend upon the ability=20= >> to decrypt TLS traffic to implement data loss protection, intrusion=20= >> detection and prevention, malware detection, packet capture and=20 >> analysis, and DDoS mitigation. >=20 > We should have already seen this with changing defaults in crypto = libraries as part of security updates. That should have broken passive = monitoring infrastructure, too. >=20 > Maybe some of the vendors can shed some light on this problem and tell = us if they ever have received pushback for rolling out ECDHE-by-default. = (I know that some products have few capabilities for centralized policy = management, which is why defaults matter a lot > there.) >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Oct 11 18:42:02 2016 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 9834D1293E1 for ; Tue, 11 Oct 2016 18:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 627EjMTdvIgB for ; Tue, 11 Oct 2016 18:41:58 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4743124281 for ; Tue, 11 Oct 2016 18:41:56 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o68so58717563qkf.3 for ; Tue, 11 Oct 2016 18:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=13nSEfZX+9Fa7HJoJOYjH7VicUGWUd6plA6e06sGrXk=; b=QPYSFOYEJyA/RbMTOIbyPzmznZGjUkfVa33DDetO+UZFLIuQQ0iWgl7dBmlseFlbd4 R+orcapnCVC9GshHq1Y1tQeWr+EMAjtu5ositlpiN2V7M6c0NW/UPO0npDl6u3hPs6uq A62bV75lX/xy3jUL+ZwxBPq5qbm1XiKoPUuZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=13nSEfZX+9Fa7HJoJOYjH7VicUGWUd6plA6e06sGrXk=; b=DVlsNyzDPf+WOBSogTdxih6uDyhLYZu2oePfUTY9yQ4zL34Axc3gxIrHXUCchSPvI7 sxwOhgaVKESU+kVhUPKR4PYfQppuNyMEuL+tv1BMWs6UCOKDb8Ie4dnAT+NJuVJbfGMr UpCfg/WujuRHB/7sAovgYZxydptVj73C0RmnUSBZfY9C+hvh3eclYo2ynQqYoUc3Oa+V Xy5ff3QWxfYpXspSB4Ui6Qn3MGYNqGBEKhs6ZWsVYvVo9CUt6e7QgFnOHYwWHLwh1fTd OOZam2K6DFOcxJKV6VCjg3Us6xestd78nZdrSE4c9XCR09oClFYb5EqT2N/atF8pfxd3 OMDA== X-Gm-Message-State: AA6/9RnLV5wyWk6LQ0CLtVLIdBxrZxxhSOHfUfYIanOJ7Lw4+XmtLodaE7NHN6nqA1nVaj/2GZxzlps9bCmBmw== X-Received: by 10.55.137.67 with SMTP id l64mr7117706qkd.21.1476236516132; Tue, 11 Oct 2016 18:41:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Tue, 11 Oct 2016 18:41:55 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:7cdd:60af:8a49:c126] In-Reply-To: References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Tue, 11 Oct 2016 21:41:55 -0400 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c072edc262482053ea1196c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 01:42:00 -0000 --94eb2c072edc262482053ea1196c Content-Type: text/plain; charset=UTF-8 > > The 0-RTT API in NSS allows a server to detect this transition. The > problem that I think David was referring to is that the specific > instant of the transition is lost when the multiple layers of stack > that sit on top of TLS get involved. > To David's second paragraph, if we eventually authenticate the early data as strongly as 1-RTT data, then there is no problem with long requests. I.e., if the client starts a long PUT request that doesn't finish until after the handshake is done, then the connection could be broken by the server stack mid-request if it is able to figure out that the early data was replayed. It appears this will be the case because the handshake context for 0-RTT includes the ClientHello, which includes the early data, so the client {Finished} will cover it. (Not clear on the value of 0-RTT to long PUT requests, but you provide a more likely example below.) If an HTTP client sends a request that relies on HPACK state that was > established during 0-RTT, is it a 0-RTT request? I'm going to go with > probably not. > For the above reason, the HPACK state should be strongly authenticated by this point, at which point it's no longer 0-RTT data. Since the authentication status of early data may vary over the course of the connection from "unknown/possibly replayed" to either "replayed" or "authentic", maybe we should classify it by its status at the time we go to use it. Which suggests the following terrible API for the server: read(max) will return either a string of fully-authenticated data up to max bytes, or EAGAIN if none is available (with possibly some side-band mechanism for indicating that data of unknown authenticity is available) read_sketchy(max) will return possibly-sketchy data up to max bytes, or 0 if there is no more such data (at which point the caller should switch to regular read), or EAGAIN if the entire ClientHello hasn't yet been received. If the server doesn't care about early data, or waits long enough for the handshake to complete, all data will have been elevated to authentic or the connection broken, depending on what happened with client {Finished}. On the client side, one option is for the early data to be specified prior to or alongside handshake initiation, with some indication by the stack of whether it was written or not. (I suggest all-or-none.) This precludes question on the part of the client as to which data might have been sent 0-RTT and which must have been sent 1-RTT. One of the nice things about the above API is that a simple server wanting to process early data ASAP can do the same thing every time: poll for read try: r = read_sketchy() if r: do_something_with_early_data(r) catch EAGAIN: noop try: r = read() if r: do_something(r) else: terminate_connection catch EAGAIN: noop Another nice thing is that at the moment you receive a single byte from read() you know a priori that every byte of early data you processed was authentic. Do we want to support the case in which 0-RTT failure means the client can send entirely different data? If so, then the above isn't general enough, but the client API could offer an option to say "don't resend this data if 0-RTT fails" with some flag set on this condition or (for event systems) a callback registered to do something more interesting. The above API also doesn't support the case in which the server wants to treat 0-RTT data entirely different from 1-RTT data, which would suggest a side-band/two channel API. Is this interesting to anyone? I'm not sure I can see any use for purposely ignoring post-hoc authentication of early data. Kyle --94eb2c072edc262482053ea1196c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The 0-RTT API in NSS allows a serve= r to detect this transition.=C2=A0 The
problem that I think David was referring to is that the specific
instant of the transition is lost when the multiple layers of stack
that sit on top of TLS get involved.

To= David's second paragraph, if we eventually authenticate the early data= as strongly as 1-RTT data, then there is no problem with long requests. I.= e., if the client starts a long PUT request that doesn't finish until a= fter the handshake is done, then the connection could be broken by the serv= er stack mid-request if it is able to figure out that the early data was re= played. It appears this will be the case because the handshake context for = 0-RTT includes the ClientHello, which includes the early data, so the clien= t {Finished} will cover it. (Not clear on the value of 0-RTT to long PUT re= quests, but you provide a more likely example below.)

If an HTTP client sends a request that relies on HPACK state that was
established during 0-RTT, is it a 0-RTT request?=C2=A0 I'm going to go = with
probably not.

For the above reason, the HPACK stat= e should be strongly authenticated by this point, at which point it's n= o longer 0-RTT data.

Since the authentication status of e= arly data may vary over the course of the connection from "unknown/pos= sibly replayed" to either "replayed" or "authentic"= ;, maybe we should classify it by its status at the time we go to use it. W= hich suggests the following terrible API for the server:

read(= max) will return either a string of fully-authenticated data up to max byte= s, or EAGAIN if none is available (with possibly some side-band mechanism f= or indicating that data of unknown authenticity is available)

<= /div>
read_sketchy(max) will return possibly-sketchy data up to max byt= es, or 0 if there is no more such data (at which point the caller should sw= itch to regular read), or EAGAIN if the entire ClientHello hasn't yet b= een received.

If the server doesn't care about early = data, or waits long enough for the handshake to complete, all data will hav= e been elevated to authentic or the connection broken, depending on what ha= ppened with client {Finished}.

On the client s= ide, one option is for the early data to be specified prior to or alongside= handshake initiation, with some indication by the stack of whether it was = written or not. (I suggest all-or-none.) This precludes question on the par= t of the client as to which data might have been sent 0-RTT and which must = have been sent 1-RTT.

One of the nice things about the ab= ove API is that a simple server wanting to process early data ASAP can do t= he same thing every time:

poll for read
try= :
=C2=A0 r =3D read_sketchy()
=C2=A0 if r: do_s= omething_with_early_data(r)
catch EAGAIN: noop
try:<= br>=C2=A0 r =3D read()
=C2=A0 if r: do_= something(r)
=C2=A0 else: terminate_con= nection
catch EAGAIN: noop

Another nice thing is that at the moment you re= ceive a single byte from read() you know a priori that every byte of early = data you processed was authentic.
=
Do we want to support the case in which 0-RTT failure means = the client can send entirely different data? If so, then the above isn'= t general enough, but the client API could offer an option to say "don= 't resend this data if 0-RTT fails" with some flag set on this con= dition or (for event systems) a callback registered to do something more in= teresting.

The above API also doesn't support the cas= e in which the server wants to treat 0-RTT data entirely different from 1-R= TT data, which would suggest a side-band/two channel API. Is this interesti= ng to anyone? I'm not sure I can see any use for purposely ignoring pos= t-hoc authentication of early data.

Kyle
=
--94eb2c072edc262482053ea1196c-- From nobody Tue Oct 11 19:23:27 2016 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 97F8C1296B1 for ; Tue, 11 Oct 2016 19:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 x0AtBhdHkWsB for ; Tue, 11 Oct 2016 19:23:22 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 14BAB12953E for ; Tue, 11 Oct 2016 19:23:21 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 11CE3423724 for ; Wed, 12 Oct 2016 02:23:21 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id E63DC423701 for ; Wed, 12 Oct 2016 02:23:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1476239000; bh=Z7RoFM5OWkSXIsf/+/j6YfDRjLYjc1oBbLnorefkD0w=; l=3292; h=From:To:Date:From; b=JWwgurC9CRSuh+nVOJ9w1OmfCLAcK2mnB2SRkJvG2xpOGs2a6ejjJOd748muh99Mt 2jYPJcHzuWopHVpE8FHdM46WrAlPEtChlXvz9suQsXiGBOYYsffU0E8794Z/85SKC8 pYuNn/WToOberpmsUV7N/PWwsTSDp8w+CitQNyJ0= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E2CC31FC86 for ; Wed, 12 Oct 2016 02:23:20 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 11 Oct 2016 22:23:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 11 Oct 2016 22:23:20 -0400 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: how close are we? Thread-Index: AdIkL02YcVjui0A+SGmVotYm/TlkOA== Date: Wed, 12 Oct 2016 02:23:19 +0000 Message-ID: <5c8856d676684aa189919fb1c59bfdb8@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.222] Content-Type: multipart/alternative; boundary="_000_5c8856d676684aa189919fb1c59bfdb8usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] how close are we? 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: Wed, 12 Oct 2016 02:23:24 -0000 --_000_5c8856d676684aa189919fb1c59bfdb8usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been away, and sick, for most of the post three weeks. How close is this ready to WGLC? Is it really just polishing the shiny bit= s? I mean I can kinda understand that, but also parts of this seems like l= sat-midnight late-night hacking. Looking for some input here. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_5c8856d676684aa189919fb1c59bfdb8usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been away, and sick, for most of the post= three weeks.

 

How close is this ready to WGLC?  Is it really = just polishing the shiny bits?  I mean I can kinda understand that, bu= t also parts of this seems like lsat-midnight late-night hacking.

 

Looking for some input here.

 

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_5c8856d676684aa189919fb1c59bfdb8usma1exdag1mb1msgcorpak_-- From nobody Tue Oct 11 19:37:50 2016 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 480CC12946D for ; Tue, 11 Oct 2016 19:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 78iwYI_jQa0e for ; Tue, 11 Oct 2016 19:37:46 -0700 (PDT) Received: from BLU004-OMC4S26.hotmail.com (blu004-omc4s26.hotmail.com [65.55.111.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B3A1293E9 for ; Tue, 11 Oct 2016 19:37:46 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com ([65.55.111.137]) by BLU004-OMC4S26.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 11 Oct 2016 19:37:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CatQaDTFDY465i11KJ47G0++T0MV5rYY7+BiCDb9u1U=; b=Z86ZqhXBwgDAtpErlgwUtWCjt8q5jwsRcrxbkDvtVfgy/5QlB1FZYi18J+sKKIoLqJw88fKa4droFs6o2+S9AZC/jaJZC+8qJZs27M+KjFQvUR13C3EP3rP8vlDR1V2xYFyZglv9yLTKQRU78LEH/y2ceckrYEGA58qZK/wGUEPDfthcPNl9pkZ4IyHOcJQnStZauQUqipQCm9+R5/daLtJZJk/oXWqujiqcglxaYVegE9XHsKXBF4Tt6dNgiucvXp/S+6BqpTzIhZ9+8aGhh8n0dkzhKgsUfKW3Z2nOPtOpzdslItTpiIzgUx1Pf8wjPeEOAW/4HDqTXELuTKNljw== Received: from SN1NAM01FT060.eop-nam01.prod.protection.outlook.com (10.152.64.53) by SN1NAM01HT245.eop-nam01.prod.protection.outlook.com (10.152.65.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Wed, 12 Oct 2016 02:37:44 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.64.58) by SN1NAM01FT060.mail.protection.outlook.com (10.152.64.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Wed, 12 Oct 2016 02:37:44 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0659.020; Wed, 12 Oct 2016 02:37:44 +0000 From: Xiaoyin Liu To: "Salz, Rich" , "tls@ietf.org" Thread-Topic: how close are we? Thread-Index: AdIkL02YcVjui0A+SGmVotYm/TlkOAAAMise Date: Wed, 12 Oct 2016 02:37:44 +0000 Message-ID: References: <5c8856d676684aa189919fb1c59bfdb8@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <5c8856d676684aa189919fb1c59bfdb8@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.64.58) smtp.mailfrom=outlook.com; akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.64.58 as permitted sender) x-tmn: [kWilzgE4SXxgUMljjjWffcgdpsq3Wse1] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM01HT245; 6:TkIAfX08qFaN4K1ERJBSuOUReb4XEFv73jjPJpiuYxg6ZE30SoBmFdvNDg+21hiRrOnWWvxx13Stvy6XIb9UemanQrVld9+xCMeh2DeKQxAtUD+uD7Yd/iEO8OjNxxcT5WJyF5HGXR1mjNrUldXMAZd8Nxb0KleKQ38OonU1dQ355/1GiwK2fGXR5hseod8CQdEkrFsnXQbI7VwK5z5FVXaC7C9/i0cfSswQbq9lyISC3hVFgKcDO2H1FrIpqTUCudUlr+AvW9VZxzl87MiZupnULFbvL1ma19KbXj3DY2E=; 5:2BzR0nSyAjWXrI6CiM0xg0uFQGx0THqzi7/tP5MWIQgdvMR7MIrogRgieEL9gvnBaIWalUUtaxekJWt9TG3Mk4wNaUuxlwJijR/dfpIGUx6Ab1sDb4WZuMT+jdDK6YVYnTvPxZVYdLp2xcLnjDllcA==; 24:k/71nWmDBXbtZ1y2xlDValAunpqGSuFq5VRgOX5Pxo67jsnviYLQKdCye1/V71b/9zX31yPO/HNm743k5yLB7lyLDDPNwGPcKtE/fR8rg/I=; 7:kULbEOnDoRdUGoIyU1M9baPepKohOSSsqhZYvAkxfyM5/0pfFsi6EQOaqpkD11UaoLHqZx97O2YZ+2h3kaJNursblc+O+Ulbey9eaJNmRgdS15wTi4hGvF2w/fkUTpEs/Y0NL5kdkJpwaqf3wuK+t2ePwp7LO1qiuMz51KYZTiYf1TgAijbe1aFkEAqdr/ZAD2q0GGuOV8H4l08vyzeIfgwdbgC/1aJ33lfrWzFLCqyissDZCoAGnTbqz4n/bKknipj112wS08AaluNJEvZ32vjOJUTNHQPa4N+aQqUjNWjrFJYwSoOnNbJJaLaZspUFqC7BnnggF4mwedUcWvMWvg== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM01HT245; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: c9c0519b-4c4f-49b3-465c-08d3f248beea x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:SN1NAM01HT245; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM01HT245; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT245; x-forefront-prvs: 0093C80C01 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB07781839CDE058F110E6F95DFFDD0CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 02:37:44.2392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT245 X-OriginalArrivalTime: 12 Oct 2016 02:37:45.0685 (UTC) FILETIME=[9D37E850:01D22431] Archived-At: Subject: Re: [TLS] how close are we? 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: Wed, 12 Oct 2016 02:37:49 -0000 --_000_CY1PR15MB07781839CDE058F110E6F95DFFDD0CY1PR15MB0778namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Not directly related to Rich's question, but will we settle the "TLS 1.3 ->= TLS 2.0" discussion (PR #612= ) before WGLC? Or has this already been closed as "keeping the current name= "? Best, Xiaoyin ________________________________ From: TLS on behalf of Salz, Rich Sent: Tuesday, October 11, 2016 10:23 PM To: tls@ietf.org Subject: [TLS] how close are we? I've been away, and sick, for most of the post three weeks. How close is this ready to WGLC? Is it really just polishing the shiny bit= s? I mean I can kinda understand that, but also parts of this seems like l= sat-midnight late-night hacking. Looking for some input here. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_CY1PR15MB07781839CDE058F110E6F95DFFDD0CY1PR15MB0778namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Not directly related to Rich's question, but will we settle the "TLS 1= .3 -> TLS 2.0" discussion (PR #612) before WGLC? Or has this alrea= dy been closed as "keeping the current name"?


Best,

Xiaoyin

From: TLS <tls-bounces= @ietf.org> on behalf of Salz, Rich <rsalz@akamai.com>
Sent: Tuesday, October 11, 2016 10:23 PM
To: tls@ietf.org
Subject: [TLS] how close are we?
 

I’ve been away, and sick, for most of the post three weeks.

 

How close is this ready to WGLC?  Is it really just polishing the shin= y bits?  I mean I can kinda understand that, but also parts of this se= ems like lsat-midnight late-night hacking.

 

Looking for some input here.

 

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

 

--_000_CY1PR15MB07781839CDE058F110E6F95DFFDD0CY1PR15MB0778namp_-- From nobody Tue Oct 11 19:39:12 2016 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 53DAC12946D for ; Tue, 11 Oct 2016 19:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 aFRJgf_qlwJQ for ; Tue, 11 Oct 2016 19:39:09 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7271293E9 for ; Tue, 11 Oct 2016 19:39:09 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id e20so15362847ybb.0 for ; Tue, 11 Oct 2016 19:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ef2rIgodjFutiC/Xj62Q4LfYqwmcYkDEOz1BY5EA7Dk=; b=wvioau82lEOxh49n9m3nB7lCDnkkJ3GY25lfTvU+Lpv1BFEy1sZxEdUR4tTu3iR5eF UasFhXCuS0NTBSI4nSu4lE0JpCTTpCOqWr79zJ4M/LuAzSXtl61NOitzmwFXpcDksCDk tunE4PNKCyOXDcEgam6jvJTcYjUtVavuh0JQp3RX/FGokXaF9uWLOh7NoJE9pfUTNfEd 7DQHLVafhvJbz2WQsDy8r8zowNmWUIuLPdY1ThoxtmbohEcpYgTK6WlM9SslWUxu8bdd IXNFRff9CkXVgacFClPwqXS+5Ry2aXtqWl6FsvFv4x1drqcprg1PKGACuI3BAz46lgMz AHFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ef2rIgodjFutiC/Xj62Q4LfYqwmcYkDEOz1BY5EA7Dk=; b=CePSubpcregeYOJFjc1jwQKj5azUiMNhOMN1BZy4kJsXaRisKmI6PhCAiefC+Ja54p Odu5iq5PmpY5ruDMUVnzIvIczuzE8BqjzTHLe4fQW2ysdYlOOJe5sK2EUAm/CVqEPsbP N84nPLvMRcHNBXvuC4IlWIXZr8ZPQ+un1rKi3e491T6fCcNO9M6H/J73GpJhFudKzmi7 kZFtffXd2K215cgA6Gmpk3da+9tkfjke/sbodpyG0A7D6lEGJ/M/+Tf679gukq67t+6p g4rq3qvsiTR3YVMl51b8xi9+DqP1IfZFSVyJVa56M4CxyrhTuSfHKSMjmpeVog62NiF0 sSQw== X-Gm-Message-State: AA6/9Rmoei+srfLcQPcbkaox01oxgv2RFrNU63oT1jJDYLpj3KHBCMf0C5cirQlN+mErDFupmCVgcT2vevxwNw== X-Received: by 10.37.65.142 with SMTP id o136mr6085277yba.65.1476239948553; Tue, 11 Oct 2016 19:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Tue, 11 Oct 2016 19:38:28 -0700 (PDT) In-Reply-To: <5c8856d676684aa189919fb1c59bfdb8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5c8856d676684aa189919fb1c59bfdb8@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Tue, 11 Oct 2016 19:38:28 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11c019aabcd821053ea1e5bf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] how close are we? 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: Wed, 12 Oct 2016 02:39:11 -0000 --001a11c019aabcd821053ea1e5bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've got a bunch of PRs in flight that I think we need to resolve one way or the other. I'm expecting the chairs to address those shortly and if all goes well with that I'll put out -17 next week and then we should revisit this question. Best, -Ekr On Tue, Oct 11, 2016 at 7:23 PM, Salz, Rich wrote: > I=E2=80=99ve been away, and sick, for most of the post three weeks. > > > > How close is this ready to WGLC? Is it really just polishing the shiny > bits? I mean I can kinda understand that, but also parts of this seems > like lsat-midnight late-night hacking. > > > > Looking for some input here. > > > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c019aabcd821053ea1e5bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've got a bunch of PRs in flight that I think we need= to resolve one way or the other.
I'm expecting the chairs to = address those shortly and if all goes well with that I'll put
out -17 next week and then we should revisit this question.

=
Best,
-Ekr


On Tue, Oct 1= 1, 2016 at 7:23 PM, Salz, Rich <rsalz@akamai.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

I=E2=80=99ve been away, and sick, for most of the po= st three weeks.

=C2=A0

How close is this ready to WGLC?=C2=A0 Is it really = just polishing the shiny bits?=C2=A0 I mean I can kinda understand that, bu= t also parts of this seems like lsat-midnight late-night hacking.=

=C2=A0

Looking for some input here.<= font color=3D"#888888">

=C2=A0

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies<= /p>

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0


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


--001a11c019aabcd821053ea1e5bf-- From nobody Tue Oct 11 19:48:49 2016 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 17A8E129436 for ; Tue, 11 Oct 2016 19:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 zNZAtb3fhUiG for ; Tue, 11 Oct 2016 19:48:46 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4F6129408 for ; Tue, 11 Oct 2016 19:48:46 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id 184so15405150yby.2 for ; Tue, 11 Oct 2016 19:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kpJN8AOdXSc2x1bfyvwF9NANnFT4EhpfgM72+gMoXVg=; b=1R/Wg2N7yMAoUsLe69vZKcnYj+19lUiQEREl3PwEW+hsgNgWz3PdT4iV6oNh7APkUn OgthlpN1CqVyODbcdAGY+ejc2Uh/onduCdp20dSJ0wo4ZqYAviYuR1usLeem6xanHutD pq2uhc8hdj6cRIItbkegec12Ie1lzzH7NITxG4iEv+f2mn/oSrmEaXsE9rKoEcxoSskt QCK6aGCLlQ5QrE6oh0BiQkoY01AH2EkOFGEcXKUDopLxcHdwvad3oQMKXAFEQT+emtJk usB9nq8wKhCB/egSQHgNdjsNN2XBBmtmpCe19gRTx7SGAiUAmmtwoCQ/zFSO103g09PB GvVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kpJN8AOdXSc2x1bfyvwF9NANnFT4EhpfgM72+gMoXVg=; b=kRvY0E3RvWpKHj2WFKp6fkm+FcPXusTzb01ibpYN9yNoBA28lchnhtT4xrZ3lpq2sE U1GdLxKGxM5lcsLRWbfxjIm1Yqw1KoxWillhSIY5//XcLb+bGhY+LHl8xx0lZ8XinK8Y YUPZ54oINwaL1lMcqFNsT63FCYb9ZPRVWr9Ik71OTXMQ97+zavmXKeWGpmf4pb6j/AzA 9F7nwvupYMSKci26pPdAL7+DhZ+ldZ4k/pZIQi2MF3VDcMV70MGGXttTZAHLI5lhNCsy 9JmGv/It+H3MrkLcCfCsqIPUyP3OoG81EmqCrMssqJcbonZH8Ftdm8b/BDVYwW9jslBy ar2g== X-Gm-Message-State: AA6/9Rk8ZWa04qgY2gG2k2hBp03vPf2ZZaVaL5JBKtVAnGj71V7Lon2FoinP3C3RMDikqg2iG3UeA7TGXzFBnA== X-Received: by 10.37.174.11 with SMTP id a11mr6129188ybj.180.1476240525543; Tue, 11 Oct 2016 19:48:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Tue, 11 Oct 2016 19:48:05 -0700 (PDT) In-Reply-To: References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 11 Oct 2016 19:48:05 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045db83e2109bc053ea20826 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Wed, 12 Oct 2016 02:48:48 -0000 --f403045db83e2109bc053ea20826 Content-Type: text/plain; charset=UTF-8 Thanks, I'll look at this. I'll be merging this change (modulo your comments) Friday unless there is significant objection. -Ekr On Tue, Oct 11, 2016 at 5:16 PM, Martin Thomson wrote: > On 12 October 2016 at 00:51, Eric Rescorla wrote: > > See: > > https://github.com/tlswg/tls13-spec/pull/678 > > I'm convinced that this is the right change. Reconstruction was > always going to be brittle. I will note that I don't think that the > change gets the error codes right though. I explained why on the PR. > --f403045db83e2109bc053ea20826 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, I'll look at this. I'll be merging this ch= ange (modulo your comments) Friday unless there is significant objection.
-Ekr


On Tue, Oct 11, 2016 at 5:16 PM, Martin Tho= mson <martin.thomson@gmail.com> wrote:
On 12 October 2016 at 00:51, Eric Rescorla <ekr@rtfm.com> wrote:
> See:
> https://github.com/tlswg/tls13-spec/pull/678

I'm convinced that this is the right change.=C2=A0 Reconstruction was always going to be brittle.=C2=A0 I will note that I don't think that t= he
change gets the error codes right though.=C2=A0 I explained why on the PR.<= br>

--f403045db83e2109bc053ea20826-- From nobody Tue Oct 11 20:21:34 2016 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 CFE671296C6 for ; Tue, 11 Oct 2016 20:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 BsTDCodZhDHo for ; Tue, 11 Oct 2016 20:21:29 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224DE1296C3 for ; Tue, 11 Oct 2016 20:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1476242488; x=1507778488; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nRoXPcJLKA+W+Qp66uyi66O/t2EjXWU3bb0TFBrBN/g=; b=l0+jhOz2polGK1XW/V3cNNqUNS8T8QJyoZjUfDOvfGQlrTsakSco42VW wRlnR+GVLfxKxe1UwAP+WY+AF4Jq3N6YGO7ZVqihgD0FSNTWcISJnxxvK CZEhCUwad2x2E1hWOhhdco6fA1NcVlTmW4+auxgH/fJPwzz+TwN9pT0PP 9BztNY6IK1v8pEA+qLxnx0f52O0fi/UwnBivK2wRz9INj+ddaUT04GNaQ ac5jVWT7dsAFrM1R/Phcc41bU3YkOhEbz2K4WU0z+iSY9LNfgKyvk9TcR CcxZHdlwnzMjVOMvHlXKUIhqNmGzwttAUCfTCwHsI47/9H0QUKZQIJ8h2 A==; X-IronPort-AV: E=Sophos;i="5.31,332,1473076800"; d="scan'208";a="109817061" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Oct 2016 16:21:22 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 12 Oct 2016 16:21:23 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Wed, 12 Oct 2016 16:21:23 +1300 From: Peter Gutmann To: Xiaoyin Liu , "Salz, Rich" , "tls@ietf.org" Thread-Topic: how close are we? Thread-Index: AdIkL02YcVjui0A+SGmVotYm/TlkOAAAMiseAAHY320= Date: Wed, 12 Oct 2016 03:21:23 +0000 Message-ID: <1476242482704.52897@cs.auckland.ac.nz> References: <5c8856d676684aa189919fb1c59bfdb8@usma1ex-dag1mb1.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] how close are we? 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: Wed, 12 Oct 2016 03:21:33 -0000 Xiaoyin Liu writes:=0A= =0A= >Not directly related to Rich's question, but will we settle the "TLS 1.3 -= > TLS 2.0" =0A= >discussion=A0(PR #612)=A0before WGLC? Or has this=A0already been closed as= "keeping =0A= >the current name"?=0A= =0A= The impression I got from the discussion was that most people, or at least = those who=0A= contributed, wanted 2.0, or at least something other than 1.3. I was kinda= surprised =0A= to see it still being referred to as 1.3.=0A= =0A= Peter.=0A= From nobody Tue Oct 11 20:31:17 2016 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 244451296BC for ; Tue, 11 Oct 2016 20:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 p50SB8oNOkED for ; Tue, 11 Oct 2016 20:31:14 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3650212949D for ; Tue, 11 Oct 2016 20:31:14 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id z190so14989459qkc.2 for ; Tue, 11 Oct 2016 20:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=hKZHR/Vf8EY2QsJVJhtz0OtERHAabJF7k1SHeyXRfSI=; b=GtID8Bh93oRfeope+gKXbR90i+oroBXUStkvKCurOliYjbf859IRHIKAiaDi534rXE XpEskn5AzbvkZm3BKjtcAxGa02r4qQtapDS7yeun41GXo5+6USr+w5eb33ZLcDDEt6l8 6EYdATSVnma+c4k6U/lYRTY7wUrib+1uEwqB8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=hKZHR/Vf8EY2QsJVJhtz0OtERHAabJF7k1SHeyXRfSI=; b=QV6+gWxMsBHjU/knyUsFKDwRtq1AnW8LYT/g7UPtXnUGCFAHkXLHPjcjtL6fsRp6NS 0gh/9sMj/hIKd0SkCJK2NTPnNonhA4C33btPXn6Vqc76AR9bktkjAaX8deaxzHb+trx+ 8lB7mvEoWmQgdocQkmwqdAp2Ec+t+AHIWxZRE0bP9FuSkI9zuIsw7y+oxdHz4rEtYt/Z rcy8ORFR8cXK5xvTsTwArAkdHhK4lnWV+B4x7Q7QiWsX0ULCryZxtz4p76NgohmFPi6j xuk0InUCI7h93mAOQU6g9J+FPM/X72dvP6bvOG65ra5n02OvEwip7MVqUvCdH7uhZW9N C+zQ== X-Gm-Message-State: AA6/9RkYnIMXXsDHHjanrSAUU3WCgRCxPPVoKcfPCYfziCvf86HHq3rR20BvkvRSriVc7Q== X-Received: by 10.55.209.207 with SMTP id o76mr5920826qkl.276.1476243072919; Tue, 11 Oct 2016 20:31:12 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id k74sm2181152qkl.14.2016.10.11.20.31.11 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Oct 2016 20:31:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <1476242482704.52897@cs.auckland.ac.nz> Date: Tue, 11 Oct 2016 23:31:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <153BDDAA-BB61-4756-8700-0DDFFEED4639@sn3rd.com> References: <5c8856d676684aa189919fb1c59bfdb8@usma1ex-dag1mb1.msg.corp.akamai.com> <1476242482704.52897@cs.auckland.ac.nz> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] how close are we? 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: Wed, 12 Oct 2016 03:31:16 -0000 > On Oct 11, 2016, at 23:21, Peter Gutmann = wrote: >=20 > Xiaoyin Liu writes: >=20 >> Not directly related to Rich's question, but will we settle the "TLS = 1.3 -> TLS 2.0"=20 >> discussion (PR #612) before WGLC? Or has this already been closed as = "keeping=20 >> the current name"? >=20 > The impression I got from the discussion was that most people, or at = least those who > contributed, wanted 2.0, or at least something other than 1.3. I was = kinda surprised=20 > to see it still being referred to as 1.3. >=20 > Peter. It=E2=80=99s still in the queue. The chairs felt it best to focus on = the open technical issues. spt=20= From nobody Wed Oct 12 00:11:10 2016 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 2F82C12946F for ; Wed, 12 Oct 2016 00:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 c_DgK9PEqed6 for ; Wed, 12 Oct 2016 00:11:07 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id A5194129421 for ; Wed, 12 Oct 2016 00:11:07 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 45550F98C; Wed, 12 Oct 2016 03:11:06 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 14B09200CC; Wed, 12 Oct 2016 00:10:58 -0700 (PDT) From: Daniel Kahn Gillmor To: Nick Sullivan , Hannes Tschofenig , "tls\@ietf.org" In-Reply-To: References: Date: Wed, 12 Oct 2016 03:10:54 -0400 Message-ID: <87fuo2vy81.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Wed, 12 Oct 2016 07:11:09 -0000 --=-=-= Content-Type: text/plain On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote: > The major thing that this proposal achieves is that it makes post-handshake > auth an optional part of the implementation. Instead of this, I would also > be in favor of a simpler change that modifies the text to say that > post-handshake CertificateRequest messages are fatal by default and only > permitted if the application permits their use in a given context (say if > the application is HTTP 1.1, only directly after requests). > > Embedded implementations may choose to simply fail on unexpected > CertificateRequests, and that way not have to implement any code around > post-handshake finished messages or updating the transcript when one > arrives. > > This default wording should also apply to other types of post-handshake > messages, though NST and KU could be exceptions that should always be > supported and non-fatal. I don't see the advantage of putting this on the wire during the intial handshake. In the HTTP case, either (a) the requested resource wants a new authentication or (b) it does not. If it does not want new authentication (b), no CertificateRequest message will be forthcoming. If it does want new authentication, then either (a.1) it requires it (meaning the HTTP request will fail if the client can't offer a good cert), or (a.2) it just hopes to send a different response based on some new authentication. in (a.1), the request will simply fail when the client can't send a client cert. So the the client needs to know how to at least reject it gracefully. This is the case even when the client fully implements client auth anyway, since it might not have a client cert available. I don't think it's too much to ask that implementations be able to reject a post-handshake CertificateRequest gracefully, even if they have no intention of ever implementing a proper Client Certificate response. Changes to the wire format here only seems to give a small advantage to the server in one corner case for HTTP (a.2, when the client has no implementation of post-handshake client certs): the server can confidently send the certRequest, knowing that the client will know how to deal with it. But now clients will also need to decide whether they should indicate "i do post-handshake client auth" even if they have no likely client certs available at the time of session establishment, and to keep track of how they signaled over the lifetime of the session (how does this interact with session resumption?). I don't think that's a complexity win overall. If we make it clear that TLS 1.3 clients MUST at least know how to gracefully reject a post-handshake Certificate Request, i think that leaves the ecosystem as a whole with less complexity, and reduces the fiddliness of the wire format. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJX/eH+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKZIcP/0MoBHC7y2vo2cPX19yXK1Sn 4F8tP5OFHbhB28awlMwln3OrRXBgRL5PW537IhYfwRk2c4+CHgxbKXQ2dZP30qpZ Zi9tMDpFTU81Wl+MzlW0y907PrzeyLAe+AUd7gHtfQWoLGIwptpAP6HR2RHq0MMo 17QWmO84mwyrLx0EX3ojWkoACJndSdNAZaxBMVwzWmqnc8hVUE4G7s8ltfO3EDWb Qkhv7QgaelIUn3GjoDq89sxwKZLTZWLx73y7VdsKkaiNXotX694AOtwRFJPcTdwa 6P5kyNSnZU0SLynfSRhi19n5bnZIxk5dxC4C8WT6K8p7r9sCeBJPdPf9kd2fGxqN Rr/VQLWsv3xcW7A+H0Iwgcx6q5FsUVoMpmLo0aGMaNTKldTGnIC7dGgHOb6hMkdN 8HBoKbG09feLuU3ndbfB7D7wkuXxMZLYBi3HH63cP3Gb903NSy3U2E/lGM6AfwgW uHxMbp9u3BNAMiFyA59+qouVMJ7rQFZMmv/K1Xytg+tJtMKYtuBSLmHSbeKpozoT sfXwVGk0f65tcf0K7HmN6huf+dzw36CSeUNp3n4X8uMC2xbwAvat9+Yafm2LzAN1 jmDZnf98JTKi6kWrx3LKAboE23G3SD8FXYt/2C4BKiGD1wZBnrdutivjTTTKfqyO vJuQxmLVa/feo6Jo5sm6 =Ryqb -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 12 01:11:59 2016 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 BF5CC12949E for ; Wed, 12 Oct 2016 01:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 huWG4kLHj7_Q for ; Wed, 12 Oct 2016 01:11:55 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id F3D2E1294A2 for ; Wed, 12 Oct 2016 01:11:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 01BC1136F6; Wed, 12 Oct 2016 11:11:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id BE6AIg_RrI1e; Wed, 12 Oct 2016 11:11:52 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 868BC28B; Wed, 12 Oct 2016 11:11:52 +0300 (EEST) Date: Wed, 12 Oct 2016 11:11:45 +0300 From: Ilari Liusvaara To: Kyle Rose Message-ID: <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 08:11:58 -0000 On Tue, Oct 11, 2016 at 09:41:55PM -0400, Kyle Rose wrote: > > > > The 0-RTT API in NSS allows a server to detect this transition. The > > problem that I think David was referring to is that the specific > > instant of the transition is lost when the multiple layers of stack > > that sit on top of TLS get involved. > > > > To David's second paragraph, if we eventually authenticate the early data > as strongly as 1-RTT data, then there is no problem with long requests. > I.e., if the client starts a long PUT request that doesn't finish until > after the handshake is done, then the connection could be broken by the > server stack mid-request if it is able to figure out that the early data > was replayed. It appears this will be the case because the handshake > context for 0-RTT includes the ClientHello, which includes the early data, > so the client {Finished} will cover it. (Not clear on the value of 0-RTT to > long PUT requests, but you provide a more likely example below.) I have actually seen one service where partially received PUT requests had "side effects". Fortunately, not a replay problem in that case, since application would reject replays anyway. > Since the authentication status of early data may vary over the course of > the connection from "unknown/possibly replayed" to either "replayed" or > "authentic", maybe we should classify it by its status at the time we go to > use it. Which suggests the following terrible API for the server: > > read(max) will return either a string of fully-authenticated data up to max > bytes, or EAGAIN if none is available (with possibly some side-band > mechanism for indicating that data of unknown authenticity is available) > > read_sketchy(max) will return possibly-sketchy data up to max bytes, or 0 > if there is no more such data (at which point the caller should switch to > regular read), or EAGAIN if the entire ClientHello hasn't yet been received. For when 0-RTT has become boring enough for me to implement, I would think the server-side interface I put in would be something like the following: - ServerSession::getReplayable0RttReader(alp_list) -> ZRttReader - ZRttReader::getAlpn() -> String - ZRttReader::dataAvailable() -> size - ZRttReader implements Read If there is no replayable 0RTT reader given when ClientHello is received, or if the ALP of the 0-RTT does not match any in alp_list, the 0-RTT is rejected. Otherwise it is accepted and the data stream is received via the ZRttReader. Then regular 1-RTT data will be returned by the usual Read interface of ServerSession. > If the server doesn't care about early data, or waits long enough for the > handshake to complete, all data will have been elevated to authentic or the > connection broken, depending on what happened with client {Finished}. In the interface above, not caring about 0-RTT gets 0-RTT rejected. And waiting just causes the connection to freeze up. > On the client side, one option is for the early data to be specified prior > to or alongside handshake initiation, with some indication by the stack of > whether it was written or not. (I suggest all-or-none.) This precludes > question on the part of the client as to which data might have been sent > 0-RTT and which must have been sent 1-RTT. The interface I envision has client write all the 0-RTT data and explicitly signal the end of data, with a callback if server rejects, so the application can abort the flight early (the stack just black- holes the data after error). And of course some critical thingy in which normally blocks 0-RTT sending has name suggestive of replayability. The reason for waiting for application to ACK the 0-RTT error is that the thing is MT-safe, so one has to prepare for races.. > Another nice thing is that at the moment you receive a single byte from > read() you know a priori that every byte of early data you processed was > authentic. Well, one always knows that for any received data, one who sent it possesses the PSK secret and it can't be tampered with without the PSK secret. However, receiving any 1-RTT data after 0-RTT data does not imply that the 0-RTT data was not replayed! > Do we want to support the case in which 0-RTT failure means the client can > send entirely different data? If so, then the above isn't general enough, > but the client API could offer an option to say "don't resend this data if > 0-RTT fails" with some flag set on this condition or (for event systems) a > callback registered to do something more interesting. There's the case where ALP mismatches (and unfortunately, due to how ALPN and 0-RTT interact, mismatches can happen in cases other than just that 0-RTT is fundamentially impossible). In that case, the data is obviously different. Then there are also things like the planned 0-RTT tokbind, where the data sent on 0-RTT failure is different from the original data. > The above API also doesn't support the case in which the server wants to > treat 0-RTT data entirely different from 1-RTT data, which would suggest a > side-band/two channel API. Is this interesting to anyone? I'm not sure I > can see any use for purposely ignoring post-hoc authentication of early > data. I regard post-hoc authentication as quite dangerous. At least in some applications it is a deadly security mistake. -Ilari From nobody Wed Oct 12 01:17:35 2016 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 33ADD1294B3 for ; Wed, 12 Oct 2016 01:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 7QZMWD2b3EAi for ; Wed, 12 Oct 2016 01:17:32 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id C068A12957A for ; Wed, 12 Oct 2016 01:17:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id BB9C616B0B; Wed, 12 Oct 2016 11:17:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id CZ344Xa51w5l; Wed, 12 Oct 2016 11:17:30 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 8648B2310; Wed, 12 Oct 2016 11:17:30 +0300 (EEST) Date: Wed, 12 Oct 2016 11:17:24 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20161012081724.GB16436@LK-Perkele-V2.elisa-laajakaista.fi> References: <87fuo2vy81.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87fuo2vy81.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Wed, 12 Oct 2016 08:17:34 -0000 On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote: > > I don't think it's too much to ask that implementations be able to > reject a post-handshake CertificateRequest gracefully, even if they have > no intention of ever implementing a proper Client Certificate response. Unfortunately, currently it is too much: One can't just send a message saying "NAK CertficiateRequest X", since that message is followed by Finished message, that is quite annoying to compute (even requires forkable hash, when nothing else requires that, and if one is to be able to freeze connection, requires very exotic features from hash implementation. -Ilari From nobody Wed Oct 12 01:36:16 2016 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 775CA129701 for ; Wed, 12 Oct 2016 01:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QoryxW1rnwVY for ; Wed, 12 Oct 2016 01:36:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3AA1296FC for ; Wed, 12 Oct 2016 01:36:12 -0700 (PDT) Received: from [192.168.91.134] ([80.92.121.244]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M4Gup-1b3VuJ2NhD-00rrck; Wed, 12 Oct 2016 10:36:04 +0200 To: Ilari Liusvaara , Daniel Kahn Gillmor References: <87fuo2vy81.fsf@alice.fifthhorseman.net> <20161012081724.GB16436@LK-Perkele-V2.elisa-laajakaista.fi> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <8d57d323-8ee2-0da0-40f0-e758bc0b55b3@gmx.net> Date: Wed, 12 Oct 2016 10:36:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161012081724.GB16436@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sdifEeKJFqP77jn9GXhibeBKQDdufM8Rq" X-Provags-ID: V03:K0:wD7YiLe/vYQZlPfCoa6A3tQp9SfdpuKb3kngka8PkYYy3kBMOfN u5NAa+D9ijFZKCT7DtPJlmq0x68YBwcM10D8im5qpgrFvYYyLF9qqOj0htT0VgAeNzuGp1Z 6mGSSpRQeWTcRy2AbFyDh8yAeacWFJa5VYYE2BgLbAO+kx2to3p7mgOVXqxUgCptuFZtvz6 hVBoVn83ZMKh4ToAoU6OA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Lzni+cKyyTg=:qkAncsymvBovLJvEnOJ9Zw jmqpztA7FmivAu+fRlo2GBI42xtnqyPUhSjnRpeliVQG+DE0mLDAqftqENsRoWtx+jxqxbb1+ Oi/67mCeLKMFSn0uB1z7e5p/sYENrCLM9WoEfdTLa9PRVnGTWrVTdtetPqnmfFJ4sXWDN1xl8 MqFoXD/9GqBaoeFKUcVXnBs8arCITF2MNwqAf1qXmZNu683Ie/Vj7deRxEa3rgXqNKX2JRGkQ VGjU09bDW88Kna788x8P4wvYyEU/CJGTbxJ5maExvsKmcbv+qM04Z5uYOp9npCo4WvsEMh5cm 1L8BNfyi45QkEN0ZWH+RDqLyWJw08oSPwpn+H2ry1ka+d/+ZUJP8GSc8VsbF8KZWf7QW40/7O OrpusYafI1h8VLy0tWexDtsn05JEhSkV6nNdujJUaBvG2yDTdvgPn4xBfP1R6vxdfG/Q+oMwN yxSAD3FrHznw9XEt816QNxZlfqK0KjP9AQWcUaHdJmBZgkF2olREhifS/SkzE2/MkEtoqp9I2 zcVInSBkOnmYHd8P7FZZ2OTIXq/tfqk/d72bZ9MqNF6Rqc72SAZYwjZ2ES50tghm+CBeH0ypO qf2cW44HU8JheGP/gb+Genzi62lZxaSGEpZ6/RLVGQWmeflVvgy8npxsSLcdq/jh2hdGaO4+C 1AGnIEdlHyijEJoqz56HvAFPiH+xubJO2voNiiJiNUfRBpQXMsuO9Uspsm8crCiWSyxbp4J6W hylqMIw6qNz+zWwrm+QcfMjI7q50QSYewDktX7aJ4SuDVu9kVemHRbT5sGU= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Wed, 12 Oct 2016 08:36:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sdifEeKJFqP77jn9GXhibeBKQDdufM8Rq Content-Type: multipart/mixed; boundary="04XH3IjrnQ2WnFuwiFaWrv35DkSqrUVSj"; protected-headers="v1" From: Hannes Tschofenig To: Ilari Liusvaara , Daniel Kahn Gillmor Cc: Nick Sullivan , "tls@ietf.org" Message-ID: <8d57d323-8ee2-0da0-40f0-e758bc0b55b3@gmx.net> Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) References: <87fuo2vy81.fsf@alice.fifthhorseman.net> <20161012081724.GB16436@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161012081724.GB16436@LK-Perkele-V2.elisa-laajakaista.fi> --04XH3IjrnQ2WnFuwiFaWrv35DkSqrUVSj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agre with Ilari. Currently, the way to reject a request is more than just saying "no, thanks.". On 10/12/2016 10:17 AM, Ilari Liusvaara wrote: > On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote: >> >> I don't think it's too much to ask that implementations be able to >> reject a post-handshake CertificateRequest gracefully, even if they ha= ve >> no intention of ever implementing a proper Client Certificate response= =2E >=20 > Unfortunately, currently it is too much: >=20 > One can't just send a message saying "NAK CertficiateRequest X", since > that message is followed by Finished message, that is quite annoying > to compute (even requires forkable hash, when nothing else requires > that, and if one is to be able to freeze connection, requires very > exotic features from hash implementation. >=20 >=20 > -Ilari >=20 --04XH3IjrnQ2WnFuwiFaWrv35DkSqrUVSj-- --sdifEeKJFqP77jn9GXhibeBKQDdufM8Rq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJX/fXxAAoJEGhJURNOOiAtoogH/R8DF+FH3hr2pQPXOMCKgL+8 7moc5Zap5jXtTZoa1MaClOJpxN03KvomSMfh7+czf8IqypM59V4a8MyM+Ss/HHOe UFW22iJ+ObS8ueBhplyXRfxZVczoENXzf9G/sxrmdU6d+Jqy6kXbXXauCnzQxiCb ytn5DgPbknTB8WYkUpC/DSa/SW+KEG5KOXS002thlCHcnaOP9rHzlqTNeEagKdIp 43D+t+z/gKb2QWUJuz9QEX7EroFOBmCwQsS0imeIiv65qn1hB1jEQqdQPBgzq+cf /zXOQRGBCKqBYC0IS/geKHi7TF2iSnzXFl1yzGowW49nx+/GyCOut09wB8Zh9t0= =Yy4M -----END PGP SIGNATURE----- --sdifEeKJFqP77jn9GXhibeBKQDdufM8Rq-- From nobody Wed Oct 12 01:50:59 2016 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 4C65D129445 for ; Wed, 12 Oct 2016 01:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 Pbw8OfEwjon6 for ; Wed, 12 Oct 2016 01:50:55 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id EF1EA127078 for ; Wed, 12 Oct 2016 01:50:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id EA33313B8D; Wed, 12 Oct 2016 11:50:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id oGkyFaK7C5Q0; Wed, 12 Oct 2016 11:50:53 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 824AA21C; Wed, 12 Oct 2016 11:50:53 +0300 (EEST) Date: Wed, 12 Oct 2016 11:50:47 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161012085047.GD16436@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Wed, 12 Oct 2016 08:50:57 -0000 On Tue, Oct 11, 2016 at 07:48:05PM -0700, Eric Rescorla wrote: > On Tue, Oct 11, 2016 at 5:16 PM, Martin Thomson > wrote: > > > On 12 October 2016 at 00:51, Eric Rescorla wrote: > > > See: > > > https://github.com/tlswg/tls13-spec/pull/678 > > > > I'm convinced that this is the right change. Reconstruction was > > always going to be brittle. I will note that I don't think that the > > change gets the error codes right though. I explained why on the PR. > > > Thanks, I'll look at this. I'll be merging this change (modulo your > comments) Friday unless there is significant objection. Well, if reject with in-list group is spurious or not depends on if there is some hello-altering extension other than key share group (it isn't if any other extension alters CH). I also noticed another edge case: What is to prevent server from omitting key share group (emitting a cookie, so the restart is not spurious), presumably causing the client to blank its key_share and then proceed to accept DH versus client's previously sent share? (That kind of thing really plays hell if client has explicit list of keypairs it considers active for connection). -Ilari From nobody Wed Oct 12 03:43:11 2016 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 1F0511294CA for ; Wed, 12 Oct 2016 03:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6Sjs7rnr8vsc for ; Wed, 12 Oct 2016 03:43:07 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9724C1296F1 for ; Wed, 12 Oct 2016 03:43:07 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id o68so68560221qkf.3 for ; Wed, 12 Oct 2016 03:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aSjyZ25KeXpdK1hJh2zLM2yg196eSQ1aZ5XDlkKFY/g=; b=Uy0LwBCAEtb6QbnUmI0zCV74MkqVptUC4F4oLhsiLE3Rtv9781t+Ep2ZRblPBEvqJW IjY7ypOy2swOtOn2M5kJvb5RyM0q1d6NC8R1isEeCO3im1X9mLH9dQqQkNSc+gDGbBsZ FvEwNMcaBe+b2+0fAlqQ6hgpTeUu+2jXy+E94hPEb23C1u2twa7TJydTxMU4itk/RMcz vfsYDOlM4UPNquvIWZT4zcRvQMSTlMY1s8jMQQ8U/23FEcZFL2XN9Pd1DMOzPgdqRq+C RXuq/efNrfh4Tw84ZEItddcXZWLaCmqPb3n+4GXkmesVETaXoLU7gb2s3fTlVgzx4VPs IBDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aSjyZ25KeXpdK1hJh2zLM2yg196eSQ1aZ5XDlkKFY/g=; b=aZTIPKq9RNVEr8blyFeoN/tWzDD7ENhbjTO0Py8vxVD4EOU/KLUXhrADDohIPt/yUR CykoeI7z8/Y7en1L43wvEdH/vWMnLYd3oMMqGE0+PsmmCRHERaLvnS+Z3E1OeTs5DLq5 VOBF32QT9NGj765HzTrUla4UhhFiMMXF5KB/74hySV4T7aTGD+Yc4pcqU4XLXtID5cKf kePYNqaDpfvMDFe9ztZiVOEC49KWe/e/Nr+CBiL7cEdG+RQIR9jmqj/huW755a00eVe+ TFfCoabR/ZlwzNHr4fLuwduWSmY97OC7/TgKW/fXH1WQiEUYJV4l9gcc44GZqEdRlb47 dmnA== X-Gm-Message-State: AA6/9RljWdwBWXvple+zQHPpeibpyXfRw5bCn8eUUf23jEOq4c7YHIlVHHJx4c9plQ0CsEcACYARLjtH84pTKQ== X-Received: by 10.55.158.139 with SMTP id h133mr417719qke.202.1476268986600; Wed, 12 Oct 2016 03:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 12 Oct 2016 03:43:05 -0700 (PDT) In-Reply-To: <20161012085047.GD16436@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> <20161012085047.GD16436@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Wed, 12 Oct 2016 21:43:05 +1100 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Wed, 12 Oct 2016 10:43:10 -0000 On 12 October 2016 at 19:50, Ilari Liusvaara wrote: > I also noticed another edge case: What is to prevent server from > omitting key share group (emitting a cookie, so the restart is > not spurious), presumably causing the client to blank its key_share > and then proceed to accept DH versus client's previously sent share? How about: If key_share isn't in the HRR, the client should replay it's old key_share verbatim. Though I agree that the text should say as much. Maybe we should require text for every extension that can appear in the HRR: what to do if the extension is in the HRR, and what to do if it isn't. From nobody Wed Oct 12 07:28:23 2016 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 759FD1295D8 for ; Wed, 12 Oct 2016 07:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 HwQ9HFnHRbwg for ; Wed, 12 Oct 2016 07:28:20 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id F1E111297A5 for ; Wed, 12 Oct 2016 07:27:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7239516BA5; Wed, 12 Oct 2016 17:27:55 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id RakTp6PXeVdh; Wed, 12 Oct 2016 17:27:55 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 1D8F8C4; Wed, 12 Oct 2016 17:27:55 +0300 (EEST) Date: Wed, 12 Oct 2016 17:27:48 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20161012142748.GA17137@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> <20161012085047.GD16436@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Wed, 12 Oct 2016 14:28:22 -0000 On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote: > On 12 October 2016 at 19:50, Ilari Liusvaara wrote: > > I also noticed another edge case: What is to prevent server from > > omitting key share group (emitting a cookie, so the restart is > > not spurious), presumably causing the client to blank its key_share > > and then proceed to accept DH versus client's previously sent share? > > How about: If key_share isn't in the HRR, the client should replay > it's old key_share verbatim. Though I agree that the text should say > as much. Yeah, would work. > Maybe we should require text for every extension that can appear in > the HRR: what to do if the extension is in the HRR, and what to do if > it isn't. Or have every extension be "no change" if not present, and do the specified thing to CH if prsent and known, abort if present and unknown. That would waste a bit of space with extensions signaling support for some rewrites if the server doesn't use those but retries the handshake. -Ilari From nobody Wed Oct 12 07:56:33 2016 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 9B207126B6D for ; Wed, 12 Oct 2016 07:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 ySQ9cPQ7oY-u for ; Wed, 12 Oct 2016 07:56:29 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C8D129478 for ; Wed, 12 Oct 2016 07:56:29 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q192so53437312iod.0 for ; Wed, 12 Oct 2016 07:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M54vmE4bg7rhUDmn1jOFT/rGjNgUkypdp3ZwwPeWIkw=; b=ZtI573TmCzGPAD7CNv9XOwEwb+gxshnVSb8cYJuUIeoSBIGlC8oqQGHOj2ldJGaq0n BSR77aakUk+3fwwdFvlQ61Rt2sceWuNoLvDJxRppaj4n+ZoA6PbUGjKO4oxAhaVWaWzf yEyXvoW0fLBtsXK/y+eLCA5iq+OyyhWe9imGg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M54vmE4bg7rhUDmn1jOFT/rGjNgUkypdp3ZwwPeWIkw=; b=GdKLDMQq9PZ7cs5pX90rQIEbh9IfOmoq5sYyerRjXrRkrozo6GkbExv85I3EfXUcQ+ dwmAWEMeeb+5gmC0lnm3t98zedXFAaleSsdLA/X8Em3DTAkYM2GxjaGodvJg1lS4vT6Q k+sefqJLFJDvu3DlcsxJj7/VuPys84E1TfMsdb2fms38aF6hyd0MPrDG3MBncgVbB2wJ CxU6wBi8xOIjWcrWJhQ0hwoHVOD0LskyqpY1Tf4I1FK8qETL/W4BXm2glPDstdioZNQn Lxeb2Ja3zrwgMMYqhe1+jv+KCtPSwS+LIsR08N+xqljfkfBXJdyX2nuUqToygspoTGCW xIBA== X-Gm-Message-State: AA6/9RnPqW2paBBWgH4mZkarb8lXZ/nzfRmPQcXGkGh2VeM4jtvQW+4/nMsRbU/2a+O3n4Z0O2Y15ZU1OAqLsvab X-Received: by 10.107.144.138 with SMTP id s132mr1798069iod.146.1476284188706; Wed, 12 Oct 2016 07:56:28 -0700 (PDT) MIME-Version: 1.0 References: <87fuo2vy81.fsf@alice.fifthhorseman.net> <20161012081724.GB16436@LK-Perkele-V2.elisa-laajakaista.fi> <8d57d323-8ee2-0da0-40f0-e758bc0b55b3@gmx.net> In-Reply-To: <8d57d323-8ee2-0da0-40f0-e758bc0b55b3@gmx.net> From: David Benjamin Date: Wed, 12 Oct 2016 14:56:16 +0000 Message-ID: To: Hannes Tschofenig , Ilari Liusvaara , Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=94eb2c0557d8a88a29053eac32b3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676) 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: Wed, 12 Oct 2016 14:56:31 -0000 --94eb2c0557d8a88a29053eac32b3 Content-Type: text/plain; charset=UTF-8 Even without the Finished computation, rejecting a CertificateRequest would hit the same unboundedness problem the previous generation of KeyUpdate had. Our implementation currently treats all post-handshake CertificateRequests as a fatal error. I think the only context where we'd conceivably change this is if we need to support HTTP/1.1 + TLS 1.3 + reactive client-auth, which means it would be under the same constraints the old renego hack was under. (Forbidden by default, forbidden in HTTP/2, all application interleave forbidden to prevent unboundedness, and only handled if exactly between HTTP/1.1 request and response.) This entire feature is a legacy hack to retain support for some legacy mechanisms by HTTP/1.1 and others. We need to have some story here, but it should not burden the protocol any more than is absolutely necessary. I think EKR's PR is the simplest option here. David On Wed, Oct 12, 2016 at 4:36 AM Hannes Tschofenig wrote: I agre with Ilari. Currently, the way to reject a request is more than just saying "no, thanks.". On 10/12/2016 10:17 AM, Ilari Liusvaara wrote: > On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote: >> >> I don't think it's too much to ask that implementations be able to >> reject a post-handshake CertificateRequest gracefully, even if they have >> no intention of ever implementing a proper Client Certificate response. > > Unfortunately, currently it is too much: > > One can't just send a message saying "NAK CertficiateRequest X", since > that message is followed by Finished message, that is quite annoying > to compute (even requires forkable hash, when nothing else requires > that, and if one is to be able to freeze connection, requires very > exotic features from hash implementation. > > > -Ilari > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --94eb2c0557d8a88a29053eac32b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Even without the Finished computation, rejecting a Certific= ateRequest would hit the same unboundedness problem the previous generation= of KeyUpdate had.

Our implementation currently treats all post-handsha= ke CertificateRequests as a fatal error. I think the only context where we&= #39;d conceivably change this is if we need to support HTTP/1.1 + TLS 1.3 += reactive client-auth, which means it would be under the same constraints t= he old renego hack was under. (Forbidden by default, forbidden in HTTP/2, a= ll application interleave forbidden to prevent unboundedness, and only hand= led if exactly between HTTP/1.1 request and response.)

This entire feat= ure is a legacy hack to retain support for some legacy mechanisms by HTTP/1= .1 and others. We need to have some story here, but it should not burden th= e protocol any more than is absolutely necessary. I think EKR's PR is t= he simplest option here.

David
=


On Wed, Oct 12, 2016 at 4:36 AM Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
I agre with Ilari. Currently, the way= to reject a request is more than

just saying "no, thanks.".



On 10/12/201= 6 10:17 AM, Ilari Liusvaara wrote:

> On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor w= rote:

>>

>> I don't think it's too m= uch to ask that implementations be able to

>> reject a post-handshake CertificateRequest graceful= ly, even if they have

>&g= t; no intention of ever implementing a proper Client Certificate response.<= br class=3D"gmail_msg">
>
=
> Unfortunately, currently it is too much:

>

> One can't just send a message saying "NAK = CertficiateRequest X", since

> that message is followed by Finished message, that is quite anno= ying

> to compute (even r= equires forkable hash, when nothing else requires
> that, and if one is to be able to freeze connect= ion, requires very

> exot= ic features from hash implementation.

>

>

> -Ilari
<= br class=3D"gmail_msg">>

=

___________________________= ____________________

TLS mai= ling list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

=
--94eb2c0557d8a88a29053eac32b3-- From nobody Wed Oct 12 08:14:12 2016 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 B2ECA12955D for ; Wed, 12 Oct 2016 08:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 Qr3BQe1Jf7Uc for ; Wed, 12 Oct 2016 08:14:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA63129508 for ; Wed, 12 Oct 2016 08:14:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D9C1D433419; Wed, 12 Oct 2016 15:13:57 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B9F3343340F; Wed, 12 Oct 2016 15:13:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1476285237; bh=rSgnT2TW/ndB56tQk4j65K40anPaRW10qiu/VhzRV/Y=; l=3070; h=To:References:Cc:From:Date:In-Reply-To:From; b=F9IFQGciudYYsDqdajj3IVIM9obkpsOXhdjYkw3tMdBMNQ2IzNn3UZAPrxdRVoX51 uhPUnTMO5xqVCcEZNCJ5LYW16xd8bLfJBmwV1iHE8Z72sO1w9YtIpwrdDC3DjkcOj/ W6b5E/vIho21PQ5wA3/8bOa/l+9a1Jm1F76gAjso= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 714D21FC86; Wed, 12 Oct 2016 15:13:57 +0000 (GMT) To: Ilari Liusvaara , Martin Thomson References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> <20161012085047.GD16436@LK-Perkele-V2.elisa-laajakaista.fi> <20161012142748.GA17137@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk Message-ID: Date: Wed, 12 Oct 2016 10:13:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161012142748.GA17137@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/alternative; boundary="------------6F6C7C0BC5772A4801DCE245" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Wed, 12 Oct 2016 15:14:11 -0000 This is a multi-part message in MIME format. --------------6F6C7C0BC5772A4801DCE245 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/12/2016 09:27 AM, Ilari Liusvaara wrote: > On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote: >> On 12 October 2016 at 19:50, Ilari Liusvaara wrote: >> >> Maybe we should require text for every extension that can appear in >> the HRR: what to do if the extension is in the HRR, and what to do if >> it isn't. > Or have every extension be "no change" if not present, and do the > specified thing to CH if prsent and known, abort if present and > unknown. This is an instance of the "require text for every extension" case, though I think either would work. > That would waste a bit of space with extensions signaling support > for some rewrites if the server doesn't use those but retries the > handshake. > I'm having trouble parsing this. The idea is that the client would waste some space in the new CH because the server doesn't have a way to indicate that the client only needs to send a subset of what it sent the first time around? -Ben --------------6F6C7C0BC5772A4801DCE245 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 10/12/2016 09:27 AM, Ilari Liusvaara wrote:
On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote:

On 12 October 2016 at 19:50, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:


Maybe we should require text for every extension that can appear in
the HRR: what to do if the extension is in the HRR, and what to do if
it isn't.

Or have every extension be "no change" if not present, and do the
specified thing to CH if prsent and known, abort if present and
unknown.

This is an instance of the "require text for every extension" case, though I think either would work.

That would waste a bit of space with extensions signaling support
for some rewrites if the server doesn't use those but retries the
handshake.

I'm having trouble parsing this.  The idea is that the client would waste some space in the new CH because the server doesn't have a way to indicate that the client only needs to send a subset of what it sent the first time around?

-Ben
--------------6F6C7C0BC5772A4801DCE245-- From nobody Wed Oct 12 08:45:35 2016 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 2F08D12943A for ; Wed, 12 Oct 2016 08:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 m4B6_ZbgvOc0 for ; Wed, 12 Oct 2016 08:45:31 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id B7276129428 for ; Wed, 12 Oct 2016 08:45:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 140FC12F22; Wed, 12 Oct 2016 18:45:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Az4N-6OUaC1V; Wed, 12 Oct 2016 18:45:29 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id BB2BA2313; Wed, 12 Oct 2016 18:45:29 +0300 (EEST) Date: Wed, 12 Oct 2016 18:45:23 +0300 From: Ilari Liusvaara To: Benjamin Kaduk Message-ID: <20161012154523.GA21085@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161009135817.GA13000@LK-Perkele-V2.elisa-laajakaista.fi> <20161012085047.GD16436@LK-Perkele-V2.elisa-laajakaista.fi> <20161012142748.GA17137@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing/PSK Binders 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: Wed, 12 Oct 2016 15:45:34 -0000 On Wed, Oct 12, 2016 at 10:13:57AM -0500, Benjamin Kaduk wrote: > On 10/12/2016 09:27 AM, Ilari Liusvaara wrote: > > On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote: > > > That would waste a bit of space with extensions signaling support > > for some rewrites if the server doesn't use those but retries the > > handshake. > > > > I'm having trouble parsing this. The idea is that the client would > waste some space in the new CH because the server doesn't have a way to > indicate that the client only needs to send a subset of what it sent the > first time around? Well, depends on the extension... Actually, not a major issue, given that there is usually a great amount of bloat in the second CH (just to make it look like CH, instead of just transporting what is needed). -Ilari From nobody Wed Oct 12 08:55:07 2016 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 280DC129472 for ; Wed, 12 Oct 2016 08:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 jeTlltXP0ET3 for ; Wed, 12 Oct 2016 08:55:01 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1B612943A for ; Wed, 12 Oct 2016 08:55:01 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id z190so39170633qkc.2 for ; Wed, 12 Oct 2016 08:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5CbpLOZkZIKOYrRLU9To0NKpeAkX7V7aRc+o475/KiU=; b=aIyaZarYuh9YRz+ruHb1iL5U3D4EzvgjFf6Zigo/qFeAeyB+fs3k+yo2CgRLdcxagD O5TGLI0IgdIK5j6WvLpPhOgWGrM5JydRqPinMqd5rqPZYHdUxTQ3bN9T81fr2nHK+7Li AghFtjKSt8Rh0+bfJ3wu+CAvvQjZ+7lwFERRk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5CbpLOZkZIKOYrRLU9To0NKpeAkX7V7aRc+o475/KiU=; b=Idqe6JlbsXnzWb+k9fKlQOsV3B0JaVdoTNuL6caux+gHHtUTHB7M8hZYG6eVGrVm+w Tcts51SbKSCNuGI8COgksLwvn02Eu/9/WvEHynDHnfqWlx3XmYPOjd1AFBLm2u7/0rqw fkD4QhnRI/c1gpHwh4E6u3+6Up0BeaPp2t3ZxCiwyE3hbb4iATjTjYZLXC2rD/9l6dFX q6cRYuy7I3ZvLCAr4QSz2VlygaTaPB1cXoxXsLNXTXMJqVpxN9ydYhQI7swQoxp5sKBr jV+n6Z8EFKW7K3DLi692yCd73LkcV3eBzNW9Xu9hxNMeJY59J99zCeu+YKm/Y1g1W65i M84A== X-Gm-Message-State: AA6/9RnRsKkvt7CCA/u/imPgYfAf/fC33ObENR+qeyFHj+I68m3xq5zoCRP4G15EgUqxoRi+aNCfUR1Cwam2/g== X-Received: by 10.233.235.3 with SMTP id b3mr1812237qkg.77.1476287700621; Wed, 12 Oct 2016 08:55:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Wed, 12 Oct 2016 08:54:59 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Wed, 12 Oct 2016 11:54:59 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c09743efb7631053ead03eb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 15:55:05 -0000 --94eb2c09743efb7631053ead03eb Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara wrote: > For when 0-RTT has become boring enough for me to implement, I would > think the server-side interface I put in would be something like the > following: > > - ServerSession::getReplayable0RttReader(alp_list) -> ZRttReader > - ZRttReader::getAlpn() -> String > - ZRttReader::dataAvailable() -> size > - ZRttReader implements Read > > If there is no replayable 0RTT reader given when ClientHello is > received, or if the ALP of the 0-RTT does not match any in alp_list, > the 0-RTT is rejected. Otherwise it is accepted and the data stream is > received via the ZRttReader. Then regular 1-RTT data will be returned by > the usual Read interface of ServerSession. > Ok, I see where you're going with this. I'm not sure whether I would put the ALP filtering logic in the API or do something more like: early_data = get_early_data() is_early_data_good = start_server_handshake(reject_early_data = !is_early_data_good) This allows the server to decide whether or not to reject early data on any basis, not just ALP. But maybe a shortcut is good for the common case. > On the client side, one option is for the early data to be specified prior > > to or alongside handshake initiation, with some indication by the stack > of > > whether it was written or not. (I suggest all-or-none.) This precludes > > question on the part of the client as to which data might have been sent > > 0-RTT and which must have been sent 1-RTT. > > The interface I envision has client write all the 0-RTT data and > explicitly signal the end of data, with a callback if server rejects, > so the application can abort the flight early (the stack just black- > holes the data after error). > Agreed on that, with s/a callback/some client application signaling appropriate to the language or development model involved/. The reason for waiting for application to ACK the 0-RTT error is that > the thing is MT-safe, so one has to prepare for races.. > I'm frankly skeptical of the utility of (most) thread safety at the socket level. (Safety against crashes, yes; safety against arbitrary interleaving of stream data, no.) IMO, semantic guarantees around multiplexing belong in a higher layer. Otherwise, the API must impose additional constraints (e.g., max write size) that apply across the board, even to applications that will never write from multiple threads, and must require the stack provide additional guarantees (e.g., all-or-none writes) that the developer has to know about. Given how much TLS libraries try to look like Berkeley sockets to applications, you'll probably see fewer usage errors if that multiplexing logic is implemented at the application layer with an upward-facing interface that either looks nothing like sockets or that presents distinct logical sockets for distinct streams, intended for use by one thread at a time, multiplexed over the same connection. > Another nice thing is that at the moment you receive a single byte from > > read() you know a priori that every byte of early data you processed was > > authentic. > > Well, one always knows that for any received data, one who sent it > possesses the PSK secret and it can't be tampered with without the > PSK secret. > Absolutely. But is it an authentic part of *this* connection? That's what the client {Finished} tells you, later. > However, receiving any 1-RTT data after 0-RTT data does not imply that > the 0-RTT data was not replayed! > I think I may have been imprecise. By "received" I mean "received by the application", i.e., "delivered by the stack". By the time the stack delivers one byte of 1-RTT data to the application, we know: (1) Client {Finished} has been received by the server (2) which authenticates ClientHello (3) which incorporates early_data (4) Client {Finished} is protected by client_handshake_traffic_secret (5) which incorporates ServerHello (6) which incorporates the server random (7) which means that secret is fresh (i.e., not subject to replay) By this point in the connection, there is proof that early_data has not been replayed. The application doesn't necessarily know this when the early data is first delivered, but it can find out later, which may be all that some applications want. Clearly not all, as you point out: > Do we want to support the case in which 0-RTT failure means the client can > > send entirely different data? If so, then the above isn't general enough, > > but the client API could offer an option to say "don't resend this data > if > > 0-RTT fails" with some flag set on this condition or (for event systems) > a > > callback registered to do something more interesting. > > There's the case where ALP mismatches (and unfortunately, due to how > ALPN and 0-RTT interact, mismatches can happen in cases other than > just that 0-RTT is fundamentially impossible). > > In that case, the data is obviously different. Then there are also > things like the planned 0-RTT tokbind, where the data sent on 0-RTT > failure is different from the original data. > Agreed that this is a perfect example. Since the early_data has to be received by the stack and be authenticated as a single chunk as part of the ClientHello, an API that returns it as a monolithic blob (like get_early_data, as above) solves the problem of associating requests/tokens to channel bindings. If some middleware wants to offer a stream interface to this buffer because that's the idiom for the particular language, that probably makes sense, but I suspect the low-level interface for a C implementation will be something more like "Here's a pointer and a length; go nuts." > The above API also doesn't support the case in which the server wants to > > treat 0-RTT data entirely different from 1-RTT data, which would suggest > a > > side-band/two channel API. Is this interesting to anyone? I'm not sure I > > can see any use for purposely ignoring post-hoc authentication of early > > data. > > I regard post-hoc authentication as quite dangerous. At least in > some applications it is a deadly security mistake. > How so? There's certainly some danger in mixing the two data streams for applications that really care about the state of forward secrecy for each byte. But I'm having a tough time understanding why finding out later that "No, that early_data was in fact not replayed" is a bad thing. IANAC: genuinely curious here. Kyle --94eb2c09743efb7631053ead03eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 12, 2016 at 4:= 11 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wro= te:
For when 0-RTT has become boring enough for me to implement, I would=
think the server-side interface I put in would be something like the
following:

- ServerSession::getReplayable0RttReader(alp_list) -> ZRttReader - ZRttReader::getAlpn() -> String
- ZRttReader::dataAvailable() -> size
- ZRttReader implements Read

If there is no replayable 0RTT reader given when ClientHello is
received, or if the ALP of the 0-RTT does not match any in alp_list,
the 0-RTT is rejected. Otherwise it is accepted and the data stream is
received via the ZRttReader. Then regular 1-RTT data will be returned by the usual Read interface of ServerSession.

<= div>Ok, I see where you're going with this. I'm not sure whether I = would put the ALP filtering logic in the API or do something more like:
=
early_data =3D get_early_data()
is_early_data_= good =3D <application inspects the early data>
start_server_= handshake(reject_early_data =3D !is_early_data_good)
This allows the server to decide whether or not to reject early= data on any basis, not just ALP. But maybe a shortcut is good for the comm= on case.

>= On the client side, one option is for the early data to be specified prior=
> to or alongside handshake initiation, with some indication by the stac= k of
> whether it was written or not. (I suggest all-or-none.) This precludes=
> question on the part of the client as to which data might have been se= nt
> 0-RTT and which must have been sent 1-RTT.

The interface I envision has client write all the 0-RTT data and
explicitly signal the end of data, with a callback if server rejects,
so the application can abort the flight early (the stack just black-
holes the data after error).

Agreed on = that, with s/a callback/some client application signaling appropriate to th= e language or development model involved/.

The reason for waiting for application to = ACK the 0-RTT error is that
the thing is MT-safe, so one has to prepare for races..

I'm frankly skeptical of the utility of (most) thread = safety at the socket level. (Safety against crashes, yes; safety against ar= bitrary interleaving of stream data, no.) IMO, semantic guarantees around = multiplexing belong in a higher layer. Otherwise, the API must impose addit= ional constraints (e.g., max write size) that apply across the board, even = to applications that will never write from multiple threads, and must requi= re the stack provide additional guarantees (e.g., all-or-none writes) that = the developer has to know about.

Given how much TLS libraries try to= look like Berkeley sockets to applications, you'll probably see fewer = usage errors if that multiplexing logic is implemented at the application l= ayer with an upward-facing interface that either looks nothing like sockets= or that presents distinct logical sockets for distinct streams, intended f= or use by one thread at a time, multiplexed over the same connection.

> Another nice thing is that at the moment you receive a = single byte from
> read() you know a priori that every byte of early data you processed w= as
> authentic.

Well, one always knows that for any received data, one who sent it possesses the PSK secret and it can't be tampered with without the
PSK secret.

Absolutely. But is it an au= thentic part of *this* connection? That's what the client {Finished} te= lls you, later.
=C2=A0
However, receiving any 1-RTT data after 0-RTT data does not imply that
the 0-RTT data was not replayed!

I thin= k I may have been imprecise. By "received" I mean "received = by the application", i.e., "delivered by the stack". By the = time the stack delivers one byte of 1-RTT data to the application, we know:=

(1) Client {Finished} has been received by the server
(2) which authenticates ClientHello
(3) which inc= orporates early_data
(4) Client {Finished} is protected by cl= ient_handshake_traffic_secret
(5) which incorporates Ser= verHello
(6) which incorporates the server random
(7) which means that secret is fresh (i.e., not subject to replay)
By this point in the connection, there is proof that early_dat= a has not been replayed. The application doesn't necessarily know this = when the early data is first delivered, but it can find out later, which ma= y be all that some applications want. Clearly not all, as you point out:

> Do we want to support the case in which 0-RTT failure means the client= can
> send entirely different data? If so, then the above isn't general = enough,
> but the client API could offer an option to say "don't resend= this data if
> 0-RTT fails" with some flag set on this condition or (for event s= ystems) a
> callback registered to do something more interesting.

There's the case where ALP mismatches (and unfortunately, due to= how
ALPN and 0-RTT interact, mismatches can happen in cases other than
just that 0-RTT is fundamentially impossible).

In that case, the data is obviously different. Then there are also
things like the planned 0-RTT tokbind, where the data sent on 0-RTT
failure is different from the original data.

Agreed that this is a perfect example.

Since the early_data ha= s to be received by the stack and be authenticated as a single chunk as par= t of the ClientHello, an API that returns it as a monolithic blob (like get= _early_data, as above) solves the problem of associating requests/tokens to= channel bindings. If some middleware wants to offer a stream interface to = this buffer because that's the idiom for the particular language, that = probably makes sense, but I suspect the low-level interface for a C impleme= ntation will be something more like "Here's a pointer and a length= ; go nuts."

> The above API also doesn't support the case in which the server wa= nts to
> treat 0-RTT data entirely different from 1-RTT data, which would sugge= st a
> side-band/two channel API. Is this interesting to anyone? I'm not = sure I
> can see any use for purposely ignoring post-hoc authentication of earl= y
> data.

I regard post-hoc authentication as quite dangerous. At least in
some applications it is a deadly security mistake.
How so? There's certainly some danger in mixing the two dat= a streams for applications that really care about the state of forward secr= ecy for each byte. But I'm having a tough time understanding why findin= g out later that "No, that early_data was in fact not replayed" i= s a bad thing. IANAC: genuinely curious here.

Kyle
--94eb2c09743efb7631053ead03eb-- From nobody Wed Oct 12 10:02:50 2016 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 15AFF129619 for ; Wed, 12 Oct 2016 10:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 9T9AxROyxywH for ; Wed, 12 Oct 2016 10:02:46 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 61EDE129462 for ; Wed, 12 Oct 2016 10:02:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 4D54511D3C; Wed, 12 Oct 2016 20:02:44 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 2jgeFd0ba5HE; Wed, 12 Oct 2016 20:02:43 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B40F527F; Wed, 12 Oct 2016 20:02:43 +0300 (EEST) Date: Wed, 12 Oct 2016 20:02:37 +0300 From: Ilari Liusvaara To: Kyle Rose Message-ID: <20161012170237.GB21085@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 17:02:49 -0000 On Wed, Oct 12, 2016 at 11:54:59AM -0400, Kyle Rose wrote: > On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara > wrote: > > Ok, I see where you're going with this. I'm not sure whether I would put > the ALP filtering logic in the API or do something more like: > > early_data = get_early_data() > is_early_data_good = > start_server_handshake(reject_early_data = !is_early_data_good) > > This allows the server to decide whether or not to reject early data on any > basis, not just ALP. But maybe a shortcut is good for the common case. You need ALP if multiple are supported, since some applications might support 0-RTT and some not. Also, TLS 1.3 0-RTT assumes that 0-RTT transport is all-or-none. > The reason for waiting for application to ACK the 0-RTT error is that > > the thing is MT-safe, so one has to prepare for races.. > > > > I'm frankly skeptical of the utility of (most) thread safety at the socket > level. (Safety against crashes, yes; safety against arbitrary interleaving > of stream data, no.) IMO, semantic guarantees around multiplexing belong in > a higher layer. Otherwise, the API must impose additional constraints > (e.g., max write size) that apply across the board, even to applications > that will never write from multiple threads, and must require the stack > provide additional guarantees (e.g., all-or-none writes) that the developer > has to know about. That was actually mostly artifact of the programming language (easiest to make things that aren't thread-locked fully thread-safe, even if there is an intermediate step). > Given how much TLS libraries try to look like Berkeley sockets to > applications, you'll probably see fewer usage errors if that multiplexing > logic is implemented at the application layer with an upward-facing > interface that either looks nothing like sockets or that presents distinct > logical sockets for distinct streams, intended for use by one thread at a > time, multiplexed over the same connection. Well, this lib looks nothing like Berkeley sockets. :-) > > However, receiving any 1-RTT data after 0-RTT data does not imply that > > the 0-RTT data was not replayed! > > > > I think I may have been imprecise. By "received" I mean "received by the > application", i.e., "delivered by the stack". By the time the stack > delivers one byte of 1-RTT data to the application, we know: > > (1) Client {Finished} has been received by the server > (2) which authenticates ClientHello > (3) which incorporates early_data > (4) Client {Finished} is protected by client_handshake_traffic_secret > (5) which incorporates ServerHello > (6) which incorporates the server random > (7) which means that secret is fresh (i.e., not subject to replay) > > By this point in the connection, there is proof that early_data has not > been replayed. The application doesn't necessarily know this when the early > data is first delivered, but it can find out later, which may be all that > some applications want. Clearly not all, as you point out: This is actually only useful if the application can cancel out effects of 0-RTT if handshake fails... Which tends to be fraught with peril to implement. Because the transport delay from client starting sending CH to server first receiving first byte past some point is the same if the data before the point is sent as 0-RTT or 1-RTT! And the dominant component in transport delay tends to be round-trip delay. > > Do we want to support the case in which 0-RTT failure means the client can > > > send entirely different data? If so, then the above isn't general enough, > > > but the client API could offer an option to say "don't resend this data > > if > > > 0-RTT fails" with some flag set on this condition or (for event systems) > > a > > > callback registered to do something more interesting. > > > > There's the case where ALP mismatches (and unfortunately, due to how > > ALPN and 0-RTT interact, mismatches can happen in cases other than > > just that 0-RTT is fundamentially impossible). > > > > In that case, the data is obviously different. Then there are also > > things like the planned 0-RTT tokbind, where the data sent on 0-RTT > > failure is different from the original data. > > > > Agreed that this is a perfect example. > > Since the early_data has to be received by the stack and be authenticated > as a single chunk as part of the ClientHello, an API that returns it as a > monolithic blob (like get_early_data, as above) solves the problem of > associating requests/tokens to channel bindings. If some middleware wants > to offer a stream interface to this buffer because that's the idiom for the > particular language, that probably makes sense, but I suspect the low-level > interface for a C implementation will be something more like "Here's a > pointer and a length; go nuts." The 0-RTT data is not part of ClientHello. It is sent in streaming manner (with handshake blocking if it hans't been completely sent by the time ServerFinished is received. ClientFinished does _not_ MAC 0-RTT data, even in case of successful transport. Also, the tokbind case would require interface that lets the application get to the connection in state where ClientHello has been sent but no 0-RTT data yet, since some of the parameters in 0-RTT data do actually depend on the exact ClientHello sent. > > The above API also doesn't support the case in which the server wants to > > > treat 0-RTT data entirely different from 1-RTT data, which would suggest > > a > > > side-band/two channel API. Is this interesting to anyone? I'm not sure I > > > can see any use for purposely ignoring post-hoc authentication of early > > > data. > > > > I regard post-hoc authentication as quite dangerous. At least in > > some applications it is a deadly security mistake. > > > > How so? There's certainly some danger in mixing the two data streams for > applications that really care about the state of forward secrecy for each > byte. But I'm having a tough time understanding why finding out later that > "No, that early_data was in fact not replayed" is a bad thing. IANAC: > genuinely curious here. Well, I was referring to the general problem that finding out that 'the peer is X' and applying it to the data sent in the same TLS connection before that point can result in very nasty surprises. And also, receiving 1-RTT data does not imply that the 0-RTT data itself was not replayed (just that any replay it is of didn't complete, assuming PSK keys are secret). -Ilari From nobody Wed Oct 12 10:51:31 2016 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 8A695129466 for ; Wed, 12 Oct 2016 10:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 KLaU4uhTtDLo for ; Wed, 12 Oct 2016 10:51:27 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2254F1279EB for ; Wed, 12 Oct 2016 10:51:27 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id f128so43004175qkb.1 for ; Wed, 12 Oct 2016 10:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lZbsAVRFNBpCApUEnkLNFRkWoTSIWfnoqlB/ESd2lA4=; b=kEZj6inOp3M1mwxsueGg5eDg8i5PozJ3GnrkR9JzSpzJZ1kekDCTIkGydqeQW9pR18 7WCF6Og1q1gC8By3ZX+fCtXCRRN4/rSQcihnxtC6lPMzE36y587Wlk00IqsJXVeLFgVy ot12f1NoXM5A0sHVMkhWZaXE30MxH8EqsAPNw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lZbsAVRFNBpCApUEnkLNFRkWoTSIWfnoqlB/ESd2lA4=; b=QRnKXovG9yzTkst7hSPjU6JWU2ocrsTmL7aHf+NzyZ2G8PXcEpD0M3PuQxXCXGgX43 WKGpNvcdEpvLhNsw2EWn46RwkJqvc6iCtXoXSlQ4dx1Z8Qi9Fhds+RA0BJLmTtiAfF8D APZMrzHaRt+ovw3AJ5rI4/S2NLrorNwX7jiyffSyCfHEwsA4gZMcGuy2YTxf716l4sKs Zs0zSWi6aNg9iFyxteOrixYxnZoCQTUdzHgi5qbsxBRrlg6JsdyotJdvpLRVMYD7vxbu nNr6jJQnapxbYch5kkgK4NOHLB+4msCZYsiVR0bqsSQGHVl8kE1AvACznJLydtU2UTtD bVHw== X-Gm-Message-State: AA6/9RkYFc+IufRzoIUjhroBamOGK/uO78GSRXhMQw/XoLjZRG+LuqImTEJ91qTBeqwiz5urU7XDjqyar1XtFA== X-Received: by 10.233.235.3 with SMTP id b3mr2373257qkg.77.1476294686245; Wed, 12 Oct 2016 10:51:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Wed, 12 Oct 2016 10:51:25 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <20161012170237.GB21085@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> <20161012170237.GB21085@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Wed, 12 Oct 2016 13:51:25 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c09743e5ba03f053eaea472 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 17:51:30 -0000 --94eb2c09743e5ba03f053eaea472 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara wrote: > > By this point in the connection, there is proof that early_data has not > > been replayed. The application doesn't necessarily know this when the > early > > data is first delivered, but it can find out later, which may be all that > > some applications want. Clearly not all, as you point out: > > This is actually only useful if the application can cancel out effects > of 0-RTT if handshake fails... Which tends to be fraught with peril to > implement. > Absolutely, but it doesn't seem like it would be any more perilous than the danger of accepting 0-RTT data in the first place: at worst you process the same replayed data, and at best you process less replayed data. (Unless there's a perverse incentive problem created by providing a half-measure.) > The 0-RTT data is not part of ClientHello. It is sent in streaming > manner (with handshake blocking if it hans't been completely sent by > the time ServerFinished is received. > > ClientFinished does _not_ MAC 0-RTT data, even in case of successful > transport. > There's my confusion. I misinterpreted both the Zero-RTT diagram and the table of handshake contexts under "Authentication Messages", specifically "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is accepted, is the second Finished message from the client ("{Finished}") the same message encrypted differently (using the handshake traffic secret)? Is there a succinct explanation for the design choices around what is and is not included in the handshake context? Being spread out over a year and a half of mailing list messages makes it hard to track. :-) I'm concerned that an on-path adversary that can slice-and-dice connections along MAC context lines will be able to create mischief, so I'd like to be able to convince myself that this isn't the case. And also, receiving 1-RTT data does not imply that the 0-RTT data > itself was not replayed (just that any replay it is of didn't > complete, assuming PSK keys are secret). > Yeah, I get that now. It seems like a missed opportunity to detect mischief after the fact, and could make for some interesting vulnerabilities for stateful protocols. E.g., if your early data is "cd /tmp" and your 1-RTT data is "rm -rf *", but the adversary is able to swap out the early data for a replayed "cd ~". That one is probably too obvious of an example to happen in real life, but imagine some developer who maintains his or her own tlstunnel hearing about 0-RTT and implementing early data for arbitrary applications using that tunnel wrapper because "reduced latency!": if early data were later authenticated, it would limit the scope of vulnerability to only those things that could fit in that first flight. But because it can't catch every possible replay-based attack, maybe such a measure would provide only a false sense of security. Sigh. I have no desire to re-ignite arguments from a year ago. Kyle --94eb2c09743e5ba03f053eaea472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
> By this point in the connection, there is = proof that early_data has not
> been replayed. The application doesn't necessarily know this when = the early
> data is first delivered, but it can find out later, which may be all t= hat
> some applications want. Clearly not all, as you point out:

This is actually only useful if the application can cancel out effec= ts
of 0-RTT if handshake fails... Which tends to be fraught with peril to
implement.

Absolutely, but it doesn'= ;t seem like it would be any more perilous than the danger of accepting 0-R= TT data in the first place: at worst you process the same replayed data, an= d at best you process less replayed data. (Unless there's a perverse in= centive problem created by providing a half-measure.)
=C2=A0<= br>
The 0-RTT data is not part of ClientHello. It is sent in streaming
manner (with handshake blocking if it hans't been completely sent by the time ServerFinished is received.

ClientFinished does _not_ MAC 0-RTT data, even in case of successful
transport.

There's my confusion. I = misinterpreted both the Zero-RTT diagram and the table of handshake context= s under "Authentication Messages", specifically "ClientHello= ... later of EncryptedExtensions/CertificateRequest". I'm guessin= g I should be looking at the 0-RTT row only? I.e., if 0-RTT is accepted, is= the second Finished message from the client ("{Finished}") the s= ame message encrypted differently (using the handshake traffic secret)?
=
Is there a succinct explanation for the design choices aroun= d what is and is not included in the handshake context? Being spread out ov= er a year and a half of mailing list messages makes it hard to track. :-) I= 'm concerned that an on-path adversary that can slice-and-dice connecti= ons along MAC context lines will be able to create mischief, so I'd lik= e to be able to convince myself that this isn't the case.

And also, receiving 1-RTT data does not imply that the 0-RTT data
itself was not replayed (just that any replay it is of didn't
complete, assuming PSK keys are secret).

Yeah, I get that now. It seems like a missed opportunity to detect mischi= ef after the fact, and could make for some interesting vulnerabilities for = stateful protocols. E.g., if your early data is "cd /tmp" and you= r 1-RTT data is "rm -rf *", but the adversary is able to swap out= the early data for a replayed "cd ~". That one is probably too o= bvious of an example to happen in real life, but imagine some developer who= maintains his or her own tlstunnel hearing about 0-RTT and implementing ea= rly data for arbitrary applications using that tunnel wrapper because "= ;reduced latency!": if early data were later authenticated, it would l= imit the scope of vulnerability to only those things that could fit in that= first flight. But because it can't catch every possible replay-based a= ttack, maybe such a measure would provide only a false sense of security. = Sigh. I have no desire to re-ignite arguments from a year ago.

Kyle
--94eb2c09743e5ba03f053eaea472-- From nobody Wed Oct 12 11:03:50 2016 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 BB9E4129521 for ; Wed, 12 Oct 2016 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 ys2WoChpua8Y for ; Wed, 12 Oct 2016 11:03:46 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id DE96D12950C for ; Wed, 12 Oct 2016 11:03:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 6ED3413D33; Wed, 12 Oct 2016 21:03:44 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id OjMhzapkYr1r; Wed, 12 Oct 2016 21:03:44 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EF1C02310; Wed, 12 Oct 2016 21:03:43 +0300 (EEST) Date: Wed, 12 Oct 2016 21:03:37 +0300 From: Ilari Liusvaara To: Kyle Rose Message-ID: <20161012180337.GA21390@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> <20161012170237.GB21085@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 18:03:50 -0000 On Wed, Oct 12, 2016 at 01:51:25PM -0400, Kyle Rose wrote: > On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara > wrote: > > > > By this point in the connection, there is proof that early_data has not > > > been replayed. The application doesn't necessarily know this when the > > early > > > data is first delivered, but it can find out later, which may be all that > > > some applications want. Clearly not all, as you point out: > > > > This is actually only useful if the application can cancel out effects > > of 0-RTT if handshake fails... Which tends to be fraught with peril to > > implement. > > > > Absolutely, but it doesn't seem like it would be any more perilous than the > danger of accepting 0-RTT data in the first place: at worst you process the > same replayed data, and at best you process less replayed data. (Unless > there's a perverse incentive problem created by providing a half-measure.) If all 0-RTT data is idempotent (including after replay delay!), sure. However, if it isn't idempotent, you could get issues... > > The 0-RTT data is not part of ClientHello. It is sent in streaming > > manner (with handshake blocking if it hans't been completely sent by > > the time ServerFinished is received. > > > > ClientFinished does _not_ MAC 0-RTT data, even in case of successful > > transport. > > > > There's my confusion. I misinterpreted both the Zero-RTT diagram and the > table of handshake contexts under "Authentication Messages", specifically > "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm > guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is > accepted, is the second Finished message from the client ("{Finished}") the > same message encrypted differently (using the handshake traffic secret)? No, there is no difference in ClientFinished in case of 0-RTT accept or reject (other than the contents of the CH and EE hashed in). > Is there a succinct explanation for the design choices around what is and > is not included in the handshake context? Being spread out over a year and > a half of mailing list messages makes it hard to track. :-) I'm concerned > that an on-path adversary that can slice-and-dice connections along MAC > context lines will be able to create mischief, so I'd like to be able to > convince myself that this isn't the case. The thing that protects the 0-RTT data from substitution is the record protection MACs that are made using key derived from the PSK secret. So if the PSK secret is unknown, the key for 0-RTT can't be derived, and as consequence, 0-RTT data can't be altered (there's end-of-data marker too, preventing truncation). And basically, ServerFinished MAC covers everything up to that point, and ClientFinished MAC covers the entiere handshake (0-RTT data not included). > And also, receiving 1-RTT data does not imply that the 0-RTT data > > itself was not replayed (just that any replay it is of didn't > > complete, assuming PSK keys are secret). > > > > Yeah, I get that now. It seems like a missed opportunity to detect mischief > after the fact, and could make for some interesting vulnerabilities for > stateful protocols. E.g., if your early data is "cd /tmp" and your 1-RTT > data is "rm -rf *", but the adversary is able to swap out the early data > for a replayed "cd ~". That one is probably too obvious of an example to > happen in real life, but imagine some developer who maintains his or her > own tlstunnel hearing about 0-RTT and implementing early data for arbitrary > applications using that tunnel wrapper because "reduced latency!": if early > data were later authenticated, it would limit the scope of vulnerability to > only those things that could fit in that first flight. But because it can't > catch every possible replay-based attack, maybe such a measure would > provide only a false sense of security. Sigh. I have no desire to re-ignite > arguments from a year ago. You can't swap out 0-RTT data (without PSK keys). One can only create new connection attempts (that fail!) with the same 0-RTT data (and the same ClientHello) before or after the real connection (if any, it could be supressed, in which case you would get only failed handshakes with 0-RTT data). -Ilari From nobody Wed Oct 12 12:49:43 2016 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 1DD2F127A90 for ; Wed, 12 Oct 2016 12:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=O6KjUkhd; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=N2HL2Ncl 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 1Cr3SL7slh3k for ; Wed, 12 Oct 2016 12:49:40 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 70FB6129518 for ; Wed, 12 Oct 2016 12:49:40 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9CJnatE014628 for ; Wed, 12 Oct 2016 12:49:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=facebook; bh=J0vdtt74Mh0xKVwaQo0X9r5yjNmJZfZoX4g19ENtUJc=; b=O6KjUkhdSnas6Ru8qDcakxXwwkgzfcACECxWIB3jtjucbMAbL1fNpidHwhgQFzXWXNZx LQuBgBudn2yYnK6JoLXYEDLkuAkw/k3dWYxDLBqAG9vNt5enS0fIgzniIOQH16OTTmwx 3/9trV+td4I7FtCKtJfWlX+pz+IS4gJwcXw= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 261raxs998-5 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Oct 2016 12:49:40 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 12 Oct 2016 15:49:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J0vdtt74Mh0xKVwaQo0X9r5yjNmJZfZoX4g19ENtUJc=; b=N2HL2NclS0WkTsKOaU4AVAe4PuObFQLVBgL+V7JPVqN/K+o1+rp+y3azhN8aQy8uw6Hwx/vhBVX8U6mxSlZi48XrqliY6Ji/qoulcgy+jT8PXXTxHij0nKz/aVJFduZzBXOP/2p+ZY9R8kxG1j4Tclwpt5JaiCUKkn7E63o4xwU= Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Wed, 12 Oct 2016 19:49:35 +0000 Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0659.020; Wed, 12 Oct 2016 19:49:35 +0000 From: Kyle Nekritz To: "tls@ietf.org" Thread-Topic: ALPN with 0-RTT Data Thread-Index: AdIkwNG9QrjHsFtFQbqjMnydw22iRw== Date: Wed, 12 Oct 2016 19:49:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c091:200::5:ba78] x-ms-office365-filtering-correlation-id: f84f9e62-63f8-4194-db6d-08d3f2d8e4f1 x-microsoft-exchange-diagnostics: 1; MWHPR15MB1182; 20:lDCZML6sgzZ2X/U8xerB2IsBScx10daEr3N4uHBCkKMGfCkcsLSaual4zHWdiuTDd4d188D/KXUNAtU/dC46iR12+2qkva86oBnUj+Xc7q9/ULmsRy3DXOZGH1vOP22kzy47wXMBjbW9TXN9HT6nw3UzsYdWHZTTSYjSHJB/+cc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1182; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:MWHPR15MB1182; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1182; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(9686002)(87936001)(1730700003)(3280700002)(33656002)(8936002)(101416001)(6916009)(5660300001)(54356999)(76576001)(81166006)(5002640100001)(50986999)(5640700001)(3660700001)(99286002)(110136003)(122556002)(86362001)(81156014)(7696004)(8676002)(105586002)(586003)(6116002)(102836003)(107886002)(2906002)(189998001)(2501003)(7736002)(106356001)(305945005)(2900100001)(10400500002)(11100500001)(68736007)(15975445007)(2351001)(97736004)(77096005)(229853001)(92566002)(74316002)(450100001)(7846002)(19580395003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1182; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 19:49:35.4462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1182 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-12_10:, , signatures=0 Archived-At: Subject: [TLS] ALPN with 0-RTT Data 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: Wed, 12 Oct 2016 19:49:42 -0000 Currently the draft specifies that the ALPN must be "the same" as in the co= nnection that established the PSK used with 0-RTT, and that the server must= check that the selected ALPN matches what was previously used. I find this= unclear if 1) the client should select and offer one (and only one) application protoc= ol 2) the client can offer multiple protocols, but use the most preferred one = offered for 0-RTT data 3) the client must send the exact same ALPN extension as in the previous co= nnection, but must use the ALPN previously selected by the server (even if = it was not the client's first offer). To clarify this we can instead * allow the client to offer whatever ALPN extension it wants * define that the 0-RTT data uses the client's most preferred application p= rotocol offer (and the server must pick this ALPN if it accepts 0-RTT), sim= ilar to using the first PSK offer if multiple are offered * recommend that the client uses the same application protocol that was use= d on the previous connection. PR: https://github.com/tlswg/tls13-spec/pull/681 Kyle From nobody Wed Oct 12 12:55:55 2016 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 315581294F4 for ; Wed, 12 Oct 2016 12:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 3jTCvt42idLa for ; Wed, 12 Oct 2016 12:55:51 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A115B1294D0 for ; Wed, 12 Oct 2016 12:55:51 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id f6so27467683qtd.2 for ; Wed, 12 Oct 2016 12:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ouTBcGJ/snLKu3W5DIiQDUIME2gVKh5a34mFyytToJk=; b=V9aO2O+hTKLeveUoRyIRCtXvJE/lDX35LiznuBbHkPw9P+TnsUeb0Pgxa2z5gXcWpX rTzaknvJehBPd+cRxogx/b1UCGbkX2TYHj1RMmQjmIYrZZhgMPyN5QSLMQAqoAOZJAJJ EPDMe0muz/CTrfQoGIJLRyCsyrrzYKYT2kmvQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ouTBcGJ/snLKu3W5DIiQDUIME2gVKh5a34mFyytToJk=; b=KYmBR7FROiM49fsmYbkhKfVQnmOFdOXjuJ+5fCIemx1tZ3KqQKhnyvqd03qPntdtpz VjeK+NXwy6gKrKcTAEfYQf8jIScx9H49EPSMmIXUXUOkYVfTO4HySTguDFQCMLKQ0h91 zMFYqed8yglZ9iHvhSb0TEgYv78dO+Gy1HwuQMmK+HCL2kseEEM5dpw+IAF3+sXwel33 i+MbOCxwqLEmSgIbZSDS8eWc8DwW8J7FZywxqz9+i4xPsEFdAyG7CqjNbfZSBjDSB908 PXzIbW4Cm9PL4TPoPpVtBS/NKjadRjjQdG0NGYdFgF2VJfzMoeT9QDv48JZxG6MW0f3F 9AjA== X-Gm-Message-State: AA6/9RlxhiyEfejr/3+3K98fUq9aKffhLzepgvSlgvl0YUk+oyey/MK/zoWz/jxhIxaVX2TWM604qbo9m+eJoA== X-Received: by 10.200.35.33 with SMTP id a30mr3097651qta.25.1476302150717; Wed, 12 Oct 2016 12:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Wed, 12 Oct 2016 12:55:49 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <20161012180337.GA21390@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> <20161012170237.GB21085@LK-Perkele-V2.elisa-laajakaista.fi> <20161012180337.GA21390@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Wed, 12 Oct 2016 15:55:49 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113a8008466a7f053eb06191 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 19:55:54 -0000 --001a113a8008466a7f053eb06191 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara wrote: > > There's my confusion. I misinterpreted both the Zero-RTT diagram and the > > table of handshake contexts under "Authentication Messages", specifically > > "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm > > guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is > > accepted, is the second Finished message from the client ("{Finished}") > the > > same message encrypted differently (using the handshake traffic secret)? > > No, there is no difference in ClientFinished in case of 0-RTT accept or > reject (other than the contents of the CH and EE hashed in). > Still confused. :-) In the message flow for 0-RTT, there are two Finished messages sent from client to server. One is sent right after CH, and is protected by the client_early_traffic_secret: (Finished). The other is sent after the server sends its Finished, and this is protected by the handshake_traffic_secret: {Finished}. In the table under "Authentication Messages", there are four rows, one for each Mode: 0-RTT, 1-RTT (Server), 1-RTT (Client), and Post-Handshake. Which handshake context is used for the (Finished) message and which is used for the {Finished} message? The thing that protects the 0-RTT data from substitution is the record > protection MACs that are made using key derived from the PSK secret. So > if the PSK secret is unknown, the key for 0-RTT can't be derived, and > as consequence, 0-RTT data can't be altered (there's end-of-data marker > too, preventing truncation). > Altered is one thing, and I agree that is prevented; I'm talking about substitution. > And basically, ServerFinished MAC covers everything up to that point, > and ClientFinished MAC covers the entiere handshake (0-RTT data not > included). > So client Finished doesn't protect 0-RTT data, but... > You can't swap out 0-RTT data (without PSK keys). One can only create > new connection attempts (that fail!) with the same 0-RTT data (and the > same ClientHello) before or after the real connection (if any, it > could be supressed, in which case you would get only failed handshakes > with 0-RTT data). > This is exactly what I'm trying to understand. What specifically prevents this swapping? I.e., what ties the 0-RTT data sent on a particular connection to the rest of that connection, such that replacing that 0-RTT data with 0-RTT data from a previous successful connection will cause a failure? Kyle --001a113a8008466a7f053eb06191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara <= ilariliusvaara@welho.com> wrote:
> There's my confusion. I misinterpreted both the Zero-RTT diagram= and the
> table of handshake contexts under "Authentication Messages",= specifically
> "ClientHello ... later of EncryptedExtensions/CertificateReq= uest". I'm
> guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is<= br> > accepted, is the second Finished message from the client ("{Finis= hed}") the
> same message encrypted differently (using the handshake traffic secret= )?

No, there is no difference in ClientFinished in case of 0-RTT accept= or
reject (other than the contents of the CH and EE hashed in).

Still confused. :-)

In the message flow for 0-= RTT, there are two Finished messages sent from client to server. One is sen= t right after CH, and is protected by the client_early_traffic_secret: (Fin= ished). The other is sent after the server sends its Finished, and this is = protected by the handshake_traffic_secret: {Finished}.

In= the table under "Authentication Messages", there are four rows, = one for each Mode: 0-RTT, 1-RTT (Server), 1-RTT (Client), and Post-Handshak= e.

Which handshake context is used for the (Finished) mes= sage and which is used for the {Finished} message?

The thing that protects the 0-RTT data from sub= stitution is the record
protection MACs that are made using key derived from the PSK secret. So
if the PSK secret is unknown, the key for 0-RTT can't be derived, and as consequence, 0-RTT data can't be altered (there's end-of-data ma= rker
too, preventing truncation).

Altered is= one thing, and I agree that is prevented; I'm talking about substituti= on.
=C2=A0
And basically, ServerFinished MAC covers everything up to that point,
and ClientFinished MAC covers the entiere handshake (0-RTT data not
included).

So client Finished doesn'= ;t protect 0-RTT data, but...
=C2=A0
You can't swap out 0-RTT data (without PSK keys). One can only create new connection attempts (that fail!) with the same 0-RTT data (and the
same ClientHello) before or after the real connection (if any, it
could be supressed, in which case you would get only failed handshakes
with 0-RTT data).

This is exactly what = I'm trying to understand. What specifically prevents this swapping? I.e= ., what ties the 0-RTT data sent on a particular connection to the rest of = that connection, such that replacing that 0-RTT data with 0-RTT data from a= previous successful connection will cause a failure?

Kyle
--001a113a8008466a7f053eb06191-- From nobody Wed Oct 12 12:57:46 2016 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 8621112958D for ; Wed, 12 Oct 2016 12:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 FvLIMBt4e3Uj for ; Wed, 12 Oct 2016 12:57:43 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30CA1294D0 for ; Wed, 12 Oct 2016 12:57:43 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id 191so23314422ybv.3 for ; Wed, 12 Oct 2016 12:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dhq0HJK41Ap9WKgZLdWtUI1GfZyTA/tR4aa7ejqzrKQ=; b=pY+Y91bMLzbZOwY7CgUGBA5nyfAWDF8NkjckJJTp7vHQZSWlDJIP2tZPZbCbylrcDq +GDoJJjeOe+AynIgqinBH1u6LAni+eWxp9R3TzDcMT7Tl/X2ZXJuDZK7PY9UCleIN+v+ JRo4WrSCFvB9scGhzNcKVjlCmUQQ04C13YekUhQIPZWO2AcILTfS/QcMFIxyzBAlNmvN jOYayncipCLMkuFKeLt8K1jwyc3yAVOX8O7JgUK43Oo2129bb0caiboNzVTR4UZRQM/G evoNnekIGHyInrpsIrJmBbZkyMSLX3d0qNnk45wtlr8c2YX+i23PRXaT5QF2i9oIvo33 UiNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dhq0HJK41Ap9WKgZLdWtUI1GfZyTA/tR4aa7ejqzrKQ=; b=cDtZR6XNXog70mYgOScmdSi217eNICO68LptXjb7zAMIg5ewmlPgatO7VzQda/y+xD cwOjIi9GXXMIjYkOBu7BA+5s45HI8S/dmz9XRdSsGIpBIprcnWF1CNvimYJdSPT/qwCY ajRQ3BQcLbEvSb/wL8KzcCZf1LQD4qvX2IZeWR+REn5ioT5i0ELI4g6sy4fpH8lktCrg 0yoY7tI5+J8yEDHB4F4whPC+sxYGvK83+nmNXl61Uji24drLe1NDTXa6/mUhAZLWsslw iOM1CmpXcf9ZrIsL+Ur/Lla6LujYLtJYCp2dpHcZbmE2pieMjGgt6PIHs1pFv/k/0c7l KpPw== X-Gm-Message-State: AA6/9Rm6nt56rnSaPD6Pz0XF9UYrj6/1tftjh9a+29xy09UAfMJqMBWfAMn9nfWzeRiRwILCwDMG6r+Q21Wehg== X-Received: by 10.37.65.142 with SMTP id o136mr2481365yba.65.1476302262906; Wed, 12 Oct 2016 12:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Wed, 12 Oct 2016 12:57:02 -0700 (PDT) In-Reply-To: References: <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> <20161012170237.GB21085@LK-Perkele-V2.elisa-laajakaista.fi> <20161012180337.GA21390@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Wed, 12 Oct 2016 12:57:02 -0700 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=001a11c019aaf67d0a053eb06736 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 19:57:45 -0000 --001a11c019aaf67d0a053eb06736 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 12:55 PM, Kyle Rose wrote: > On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara > wrote: > >> > There's my confusion. I misinterpreted both the Zero-RTT diagram and the >> > table of handshake contexts under "Authentication Messages", >> specifically >> > "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm >> > guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is >> > accepted, is the second Finished message from the client ("{Finished}") >> the >> > same message encrypted differently (using the handshake traffic secret)? >> >> No, there is no difference in ClientFinished in case of 0-RTT accept or >> reject (other than the contents of the CH and EE hashed in). >> > > Still confused. :-) > > In the message flow for 0-RTT, there are two Finished messages sent from > client to server. One is sent right after CH, and is protected by the > client_early_traffic_secret: (Finished). The other is sent after the server > sends its Finished, and this is protected by the handshake_traffic_secret: > {Finished}. > > In the table under "Authentication Messages", there are four rows, one for > each Mode: 0-RTT, 1-RTT (Server), 1-RTT (Client), and Post-Handshake. > > Which handshake context is used for the (Finished) message and which is > used for the {Finished} message? > > The thing that protects the 0-RTT data from substitution is the record >> protection MACs that are made using key derived from the PSK secret. So >> if the PSK secret is unknown, the key for 0-RTT can't be derived, and >> as consequence, 0-RTT data can't be altered (there's end-of-data marker >> too, preventing truncation). >> > > Altered is one thing, and I agree that is prevented; I'm talking about > substitution. > > >> And basically, ServerFinished MAC covers everything up to that point, >> and ClientFinished MAC covers the entiere handshake (0-RTT data not >> included). >> > > So client Finished doesn't protect 0-RTT data, but... > > >> You can't swap out 0-RTT data (without PSK keys). One can only create >> new connection attempts (that fail!) with the same 0-RTT data (and the >> same ClientHello) before or after the real connection (if any, it >> could be supressed, in which case you would get only failed handshakes >> with 0-RTT data). >> > > This is exactly what I'm trying to understand. What specifically prevents > this swapping? I.e., what ties the 0-RTT data sent on a particular > connection to the rest of that connection, such that replacing that 0-RTT > data with 0-RTT data from a previous successful connection will cause a > failure? > The 0-RTT traffic key incorporates the ClientHello.Random which is tied into the full handshake. -Ekr > > Kyle > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c019aaf67d0a053eb06736 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 12, 2016 at 12:55 PM, Kyle Rose <krose@krose.org> wrote:
On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara &l= t;ilariliusva= ara@welho.com> wrote:
> There's my confusion. I misinterpreted both the Zero-RTT diagr= am and the
> table of handshake contexts under "Authentication Messages",= specifically
> "ClientHello ... later of EncryptedExtensions/CertificateReq= uest". I'm
> guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is<= br> > accepted, is the second Finished message from the client ("{Finis= hed}") the
> same message encrypted differently (using the handshake traffic secret= )?

No, there is no difference in ClientFinished in case of 0-RTT accept= or
reject (other than the contents of the CH and EE hashed in).

Still confused. :-)

In the message flow= for 0-RTT, there are two Finished messages sent from client to server. One= is sent right after CH, and is protected by the client_early_traffic_secre= t: (Finished). The other is sent after the server sends its Finished, and t= his is protected by the handshake_traffic_secret: {Finished}.

=
In the table under "Authentication Messages", there are four= rows, one for each Mode: 0-RTT, 1-RTT (Server), 1-RTT (Client), and Post-H= andshake.

Which handshake context is used for the (Finish= ed) message and which is used for the {Finished} message?

The thing that protects the 0-RTT data from substitution= is the record
protection MACs that are made using key derived from the PSK secret. So
if the PSK secret is unknown, the key for 0-RTT can't be derived, and as consequence, 0-RTT data can't be altered (there's end-of-data ma= rker
too, preventing truncation).

Alt= ered is one thing, and I agree that is prevented; I'm talking about sub= stitution.
=C2=A0
And basically, ServerFinished MAC covers everything up to that point,
and ClientFinished MAC covers the entiere handshake (0-RTT data not
included).

So client Finished do= esn't protect 0-RTT data, but...
=C2=A0<= br>
You can't swap out 0-RTT data (without PSK keys). One can only create new connection attempts (that fail!) with the same 0-RTT data (and the
same ClientHello) before or after the real connection (if any, it
could be supressed, in which case you would get only failed handshakes
with 0-RTT data).

This is exactl= y what I'm trying to understand. What specifically prevents this swappi= ng? I.e., what ties the 0-RTT data sent on a particular connection to the r= est of that connection, such that replacing that 0-RTT data with 0-RTT data= from a previous successful connection will cause a failure?

The 0-RTT traffic key incorporate= s the ClientHello.Random which is tied into the full handshake.
<= br>
-Ekr



Kyle

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


--001a11c019aaf67d0a053eb06736-- From nobody Wed Oct 12 13:02:07 2016 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 CA4011295A1 for ; Wed, 12 Oct 2016 13:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 RsgL8TTX-e9y for ; Wed, 12 Oct 2016 13:02:04 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10820129573 for ; Wed, 12 Oct 2016 13:02:04 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id o19so64786470ito.1 for ; Wed, 12 Oct 2016 13:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WBRtmaFzSMH4zpi+RTt8zAf1YSxnVDiqMimR40KeUfM=; b=HaUOGbeqqOKxkHWn9Fz3YpGT7ildak3EudJTU8wvZJdC4spUG5bkTB/S0h+MkY0Ogd CZEvKWqnngfMK1gzR7uvWGK/c6xo9zPiid9oAhS8uyOXaaW8y/x3e2Xmp2lrj04gChrr OaxWqwNH9ZGSfLP26jwhkIqofv9PilUpE2hPo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WBRtmaFzSMH4zpi+RTt8zAf1YSxnVDiqMimR40KeUfM=; b=SfH4SMCEQ/lMMYa7YF22iz2y+TmaiJpiGIR9aTuZYJC4TXONKYNlhKqw2WpFzuv/FA b+S832pTMC44a6zqRclWzbOXZwI41zaom4MzWbatClDo2Ji/Vv2YA14OcBSTSpXD7X6l J4jovhCMKrldiAQF/zyzq5cMmPN86dq2AC26IobaMXBz72QFDT6EJIK+03yidRUX57mJ SYpqmjJIk+vmCtRv3Bzd41eECp4NLhc8J01O3HUwUFG/7BBcdn+EZU23y0db/7401f2M yqBQsXFFICW+TUXK6xK4MWfaEIKl5NzPPyUc+02etKSRzxA3ZhEFhg7sxUg3MRY7pkxx TBXQ== X-Gm-Message-State: AA6/9Rm5Bv+DCehbGcU3D/Vhuhn4gkzpjUJhFUBG035WkSkpEIzKo3/ADN3p/liHWjgrnsWR3UZJ+JnL9arkm52y X-Received: by 10.36.210.70 with SMTP id z67mr4253502itf.67.1476302523177; Wed, 12 Oct 2016 13:02:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 12 Oct 2016 20:01:52 +0000 Message-ID: To: Kyle Nekritz , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05d07e79f1b5053eb077fa Archived-At: Subject: Re: [TLS] ALPN with 0-RTT Data 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: Wed, 12 Oct 2016 20:02:06 -0000 --94eb2c05d07e79f1b5053eb077fa Content-Type: text/plain; charset=UTF-8 My interpretation was: 1. Client and server remember the previous selected ALPN protocol in the session. 2. The client may offer whatever ALPN protocols it likes. It does not need to match the previous offer list, though it presumably will unless you've got a persistent session cache or so. 3. The client assumes that session's ALPN protocol was selected for purposes of minting 0-RTT data. 4. The server must decline 0-RTT if it choses a different ALPN protocol. This can be implemented by just doing ALPN negotiation as normal and declining 0-RTT if the result does not match. (If client and server prefs have not changed, 0-RTT will work. If prefs have changed, 0-RTT will miss but future sessions will start being 0-RTT-able. I think this is probably the sanest behavior.) 5. The client performs the usual checks on the selected ALPN protocol (must be one of the advertised ones). In addition, it enforces that, if 0-RTT was accepted, the protocol must match the session one. Pinning on the most preferred one causes awkward transitions when the most preferred ALPN protocol is not the same as the most commonly deployed one. If we ever define, say, h3, we want that one in front of h2 presumably, but we wouldn't want to lose 0-RTT against all the h2 servers out there. I don't think we should be reorder preferences based on the sessions we are offering. That makes it much harder to reason about the behavior of preference lists. David On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz wrote: Currently the draft specifies that the ALPN must be "the same" as in the connection that established the PSK used with 0-RTT, and that the server must check that the selected ALPN matches what was previously used. I find this unclear if 1) the client should select and offer one (and only one) application protocol 2) the client can offer multiple protocols, but use the most preferred one offered for 0-RTT data 3) the client must send the exact same ALPN extension as in the previous connection, but must use the ALPN previously selected by the server (even if it was not the client's first offer). To clarify this we can instead * allow the client to offer whatever ALPN extension it wants * define that the 0-RTT data uses the client's most preferred application protocol offer (and the server must pick this ALPN if it accepts 0-RTT), similar to using the first PSK offer if multiple are offered * recommend that the client uses the same application protocol that was used on the previous connection. PR: https://github.com/tlswg/tls13-spec/pull/681 Kyle _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --94eb2c05d07e79f1b5053eb077fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My interpretation was:

1. Clie= nt and server remember the previous selected ALPN protocol in the session.<= /div>

2. The client may offer whatever ALPN protocols it likes. It does= not need to match the previous offer list, though it presumably will unles= s you've got a persistent session cache or so.

3. The client = assumes that session's ALPN protocol was selected for purposes of minti= ng 0-RTT data.

=
4. The server must decline 0-RTT if it choses a di= fferent ALPN protocol. This can be implemented by just doing ALPN negotiati= on as normal and declining 0-RTT if the result does not match. (If client a= nd server prefs have not changed, 0-RTT will work. If prefs have changed, 0= -RTT will miss but future sessions will start being 0-RTT-able. I think thi= s is probably the sanest behavior.)

5. The client performs the us= ual checks on the selected ALPN protocol (must be one of the advertised one= s). In addition, it enforces that, if 0-RTT was accepted, the protocol must= match the session one.

Pinning on the most preferred one causes = awkward transitions when the most preferred ALPN protocol is not the same a= s the most commonly deployed one. If we ever define, say, h3, we want that = one in front of h2 presumably, but we wouldn't want to lose 0-RTT again= st all the h2 servers out there.

I don't think we should be reorder preferences b= ased on the sessions we are offering. That makes it much harder to reason a= bout the behavior of preference lists.

David
=

<= br class=3D"gmail_msg">
On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz <knekri= tz@fb.com> wrote:
Currently the draft specifies that the ALPN must be &qu= ot;the same" as in the connection that established the PSK used with 0= -RTT, and that the server must check that the selected ALPN matches what wa= s previously used. I find this unclear if

1) the client should select and offer one (and only one) app= lication protocol

2) the cli= ent can offer multiple protocols, but use the most preferred one offered fo= r 0-RTT data

3) the client m= ust send the exact same ALPN extension as in the previous connection, but m= ust use the ALPN previously selected by the server (even if it was not the = client's first offer).

<= br class=3D"gmail_msg">
To clarify this we can inste= ad

* allow the client to off= er whatever ALPN extension it wants

* define that the 0-RTT data uses the client's most preferred a= pplication protocol offer (and the server must pick this ALPN if it accepts= 0-RTT), similar to using the first PSK offer if multiple are offered

* recommend that the client uses = the same application protocol that was used on the previous connection.



PR: https://github.= com/tlswg/tls13-spec/pull/681



Kyle



_______________________________________________
=
TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/= tls

<= /div>
--94eb2c05d07e79f1b5053eb077fa-- From nobody Wed Oct 12 13:04:02 2016 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 2CE1D129674 for ; Wed, 12 Oct 2016 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 qqntAddiYSj9 for ; Wed, 12 Oct 2016 13:03:59 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE85129573 for ; Wed, 12 Oct 2016 13:03:58 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id 191so23373503ybv.3 for ; Wed, 12 Oct 2016 13:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E5rZxBxvvzGzGtkpw35dPIAL4Fm+vflRy9cIbrTLO5g=; b=pWHH1eDpTBfzjApc5tlG4888ny+P+ZpKalXn6H/IBEZyYGykkfC341Uv+ESHqd376b WmcZh0n2I0koPrQiSKA4VKez+zZVgePTC1iUR8GZr4GdkUpc1kMj6UxYEDXRWQfMN1mZ OXrtQs1rCftqMaYiPPAIYNWFIKbjQbPjMyF00xCH9VlirqliZ5e9S+8o9HRdday8R0Es iYt4oVGL7N8rdEprF+7t0K6pBwW9X6PZKfczDBI0UOCiVWRyZc2Ij1dJ2+grzdMUuDfD wqTOb5CsHlCPIEvjEOAy8qKpAiKaJh3FQGevIM7qJgDUUhJT9wBgqt0s+R27kPA8bWnS 138w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E5rZxBxvvzGzGtkpw35dPIAL4Fm+vflRy9cIbrTLO5g=; b=NWoa1LhSFAx0vGc9NHLxAo3iGJsDfZFAe/+CZkoHN0ZfKxQXArKPVvY5u5rmFaky6j qSHsUH8r8MSlHTVE10xg7sDJ/Ro69Rx/ICqXS2cf1Vpp9EE0x+7hEDfQ49/lI3VqJgtW SnkzfYYZJFtHw9oyTsneb8pbxxBs4i2UAGiOUHS89bi8P6lCWQLWd0JJLB/USQJ/b1FI 3F2Kgbx9qk6sMT3ztn9vr2UGvdoanO9WlRwVAesULuOHZly7d0SDh3uPlDA4pb4cv4Dw WSuQKDJnCJR0kYxxDiiJk0JFP5MRgnmT+cUrXumUM/NTBLLvrdu2n1L9jCI60cdOyXVc JflQ== X-Gm-Message-State: AA6/9Rmn1oq3yQuLGyyUtbjIsyPRtcAaOkkih4WziLV+FWeQFH2QSy0cl6f6296llinij4VtT5E4ZOv7nC+8cw== X-Received: by 10.37.85.136 with SMTP id j130mr2449608ybb.80.1476302638090; Wed, 12 Oct 2016 13:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Wed, 12 Oct 2016 13:03:17 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 12 Oct 2016 13:03:17 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a113e8a4c533a04053eb07e42 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN with 0-RTT Data 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: Wed, 12 Oct 2016 20:04:01 -0000 --001a113e8a4c533a04053eb07e42 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin wrote: > My interpretation was: > > 1. Client and server remember the previous selected ALPN protocol in the > session. > > 2. The client may offer whatever ALPN protocols it likes. It does not need > to match the previous offer list, though it presumably will unless you've > got a persistent session cache or so. > > 3. The client assumes that session's ALPN protocol was selected for > purposes of minting 0-RTT data. > > 4. The server must decline 0-RTT if it choses a different ALPN protocol. > This can be implemented by just doing ALPN negotiation as normal and > declining 0-RTT if the result does not match. (If client and server prefs > have not changed, 0-RTT will work. If prefs have changed, 0-RTT will miss > but future sessions will start being 0-RTT-able. I think this is probably > the sanest behavior.) > > 5. The client performs the usual checks on the selected ALPN protocol > (must be one of the advertised ones). In addition, it enforces that, if > 0-RTT was accepted, the protocol must match the session one. > This matches the behavior I intended in the spec (and the one NSS implements). -Ekr Pinning on the most preferred one causes awkward transitions when the most > preferred ALPN protocol is not the same as the most commonly deployed one. > If we ever define, say, h3, we want that one in front of h2 presumably, but > we wouldn't want to lose 0-RTT against all the h2 servers out there. > > I don't think we should be reorder preferences based on the sessions we > are offering. That makes it much harder to reason about the behavior of > preference lists. > > David > > > On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz wrote: > > Currently the draft specifies that the ALPN must be "the same" as in the > connection that established the PSK used with 0-RTT, and that the server > must check that the selected ALPN matches what was previously used. I find > this unclear if > > 1) the client should select and offer one (and only one) application > protocol > > 2) the client can offer multiple protocols, but use the most preferred one > offered for 0-RTT data > > 3) the client must send the exact same ALPN extension as in the previous > connection, but must use the ALPN previously selected by the server (even > if it was not the client's first offer). > > > > To clarify this we can instead > > * allow the client to offer whatever ALPN extension it wants > > * define that the 0-RTT data uses the client's most preferred application > protocol offer (and the server must pick this ALPN if it accepts 0-RTT), > similar to using the first PSK offer if multiple are offered > > * recommend that the client uses the same application protocol that was > used on the previous connection. > > > > PR: https://github.com/tlswg/tls13-spec/pull/681 > > > > Kyle > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113e8a4c533a04053eb07e42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
My interpretation was:

1. Client and server remember the previous se= lected ALPN protocol in the session.

2. The client may offer whatever ALPN p= rotocols it likes. It does not need to match the previous offer list, thoug= h it presumably will unless you've got a persistent session cache or so= .

= 3. The client assumes that session's ALPN protocol was selected for pur= poses of minting 0-RTT data.

4. The server must decline 0-RTT if it choses a = different ALPN protocol. This can be implemented by just doing ALPN negotia= tion as normal and declining 0-RTT if the result does not match. (If client= and server prefs have not changed, 0-RTT will work. If prefs have changed,= 0-RTT will miss but future sessions will start being 0-RTT-able. I think t= his is probably the sanest behavior.)

5. The client performs the usual checks= on the selected ALPN protocol (must be one of the advertised ones). In add= ition, it enforces that, if 0-RTT was accepted, the protocol must match the= session one.

This matches the behavior I intended in the spec (and the one NSS implemen= ts).

-Ekr


Pinning on the most preferred one causes awkward = transitions when the most preferred ALPN protocol is not the same as the mo= st commonly deployed one. If we ever define, say, h3, we want that one in f= ront of h2 presumably, but we wouldn't want to lose 0-RTT against all t= he h2 servers out there.

I don't think = we should be reorder preferences based on the sessions we are offering. Tha= t makes it much harder to reason about the behavior of preference lists.

=
David


On Wed, O= ct 12, 2016 at 3:49 PM Kyle Nekritz <knekritz@fb.com<= /a>> wrote:
Currently the draft spe= cifies that the ALPN must be "the same" as in the connection that= established the PSK used with 0-RTT, and that the server must check that t= he selected ALPN matches what was previously used. I find this unclear if
1) the client should select and offer one (and only one) appli= cation protocol

2) the client can offer multiple protocols, b= ut use the most preferred one offered for 0-RTT data

3) the c= lient must send the exact same ALPN extension as in the previous connection= , but must use the ALPN previously selected by the server (even if it was n= ot the client's first offer).



To clarify t= his we can instead

* allow the client to offer whatever ALPN = extension it wants

* define that the 0-RTT data uses the clie= nt's most preferred application protocol offer (and the server must pic= k this ALPN if it accepts 0-RTT), similar to using the first PSK offer if m= ultiple are offered

* recommend that the client uses the sa= me application protocol that was used on the previous connection.



PR: https://github.com/tlswg/tls13-spec/pull/681



Kyle



____________________= ___________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/= tls


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


--001a113e8a4c533a04053eb07e42-- From nobody Wed Oct 12 13:12:39 2016 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 23442129573 for ; Wed, 12 Oct 2016 13:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 QYF5G3bj7tFG for ; Wed, 12 Oct 2016 13:12:36 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D001288B8 for ; Wed, 12 Oct 2016 13:12:36 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id m5so25626572qtb.3 for ; Wed, 12 Oct 2016 13:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T5XnwzUWZ962IjeAnMBIHwEwW36VmuHo8WqGmcGfwLM=; b=jhigNEOxZBFKllwJjvmtg2XtoJ7sv91F995wT7qWih/HHg0oIpum+kw5w7QsMKTa/5 qhbyzJJwR/gY5vf7NJk2rFKcWHVVdl/KQrsQvKtqfmKATVcGujsUNBL2q+fbLi9IS92F No3pY+SBwnoI4l0ECCgsXkzIK1gicrIq8gAGA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T5XnwzUWZ962IjeAnMBIHwEwW36VmuHo8WqGmcGfwLM=; b=nKDofVB6xz/ez4czvBHM8QMhGn4URWXDvhQaPcFs1rJcNgdUiKBQapztuznnod7ZHZ O8xvm9xoioZfE0dG/X0bDVMdiIW8/FaZLQ3TFfyqxOFYROQAVKhkv7joIYr3Jyvu7Rpn DT+Z/TG5PBAn3v3CUgnFIwqOpKhFzhaJm7g33qBU07xyZHQglP40sK3YXmcN+kVzTtcr 4qNMBzGdsRaIMvJZEXl0Z7EPZoFTv5bB2Lj6FBHM4GG/fgZP1OA16wAJLVaIPK4vePPd zjbeMZZAbJc8Ii/JC1wdDc7n7/79zQYmzTE3Ez+mmQ0cfQ6+3ehgfKa8WvzPLJpkTMXt zCIw== X-Gm-Message-State: AA6/9RnXiAPRm5xkZMECT6e8q73QWy51Od5OAHdeuMvONCcdrjlekfpOFx5zczBML1jKqXIlXorzUB3yJ4Ifow== X-Received: by 10.237.36.93 with SMTP id s29mr3206486qtc.134.1476303155703; Wed, 12 Oct 2016 13:12:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Wed, 12 Oct 2016 13:12:34 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <20161012081145.GA16436@LK-Perkele-V2.elisa-laajakaista.fi> <20161012170237.GB21085@LK-Perkele-V2.elisa-laajakaista.fi> <20161012180337.GA21390@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Wed, 12 Oct 2016 16:12:34 -0400 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1141281e2dafa5053eb09d00 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Wed, 12 Oct 2016 20:12:38 -0000 --001a1141281e2dafa5053eb09d00 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 3:57 PM, Eric Rescorla wrote: > The 0-RTT traffic key incorporates the ClientHello.Random which is tied > into the full handshake. > Ok, so for the replayed early data to be accepted, an adversary would also have to swap out CH.Random and the (Finished) message, which would alter the server Finished message, resulting in a handshake failure. I think that resolves my concern. Thanks. Kyle --001a1141281e2dafa5053eb09d00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 12, 2016 at 3:57 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
The 0-RTT traffic key incorporates the Client= Hello.Random which is tied into the full handshake.

Ok, so for the replayed e= arly data to be accepted, an adversary would also have to swap out CH.Rando= m and the (Finished) message, which would alter the server Finished message= , resulting in a handshake failure. I think that resolves my concern. Thank= s.

Kyle
--001a1141281e2dafa5053eb09d00-- From nobody Wed Oct 12 14:07:18 2016 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 62DF3129684 for ; Wed, 12 Oct 2016 14:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=FhYTp2X2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=kxZjUNGn 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 UZ13d5EC-L3E for ; Wed, 12 Oct 2016 14:07:13 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 13444129656 for ; Wed, 12 Oct 2016 14:07:13 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.17/8.16.0.17) with SMTP id u9CL6Qak017272; Wed, 12 Oct 2016 14:07:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=if3YYR/S2gbJGbZXx29aDxW7Hbnjs6n8leS4bINk+Jk=; b=FhYTp2X2CdlcjXKhPFqHyKqBfpawpmxvMrT9BgTX+RHvK8Oale9MMb2wvVVCIVPQOImW thFjXCDok9EUh7qAUEANMdVoSrlKZOJRU0TVApFvt8l7PV/l9tKYRgkWktFHl8Wiy3a9 m9+SKNugAs5vvkgJjnibrR1F3cgn8OjASkU= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 2615d3fa3u-13 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Oct 2016 14:07:10 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 12 Oct 2016 14:06:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=if3YYR/S2gbJGbZXx29aDxW7Hbnjs6n8leS4bINk+Jk=; b=kxZjUNGnfircXmbNGJ2aP3Gj+C5fUk6QGe3QBZ5mwpGs3DFrca5mISn0KVjjm4zElFXkicKuPSBIGjEcnF2x0YchWVEy+XZ7tKBDLE1ywpuXHznPMX1yOxSuB+RQRAiMn/a3Eq+A6udD8OJlUERtVkkZ3d7dJ1cU7ONHfKn1zAI= Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1181.namprd15.prod.outlook.com (10.175.2.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Wed, 12 Oct 2016 21:06:00 +0000 Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0659.020; Wed, 12 Oct 2016 21:06:00 +0000 From: Kyle Nekritz To: Eric Rescorla , David Benjamin Thread-Topic: [TLS] ALPN with 0-RTT Data Thread-Index: AdIkwNG9QrjHsFtFQbqjMnydw22iRwAAqeUAAAAMq4AAAGmTkA== Date: Wed, 12 Oct 2016 21:05:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c091:200::5:ba78] x-ms-office365-filtering-correlation-id: cd436ed0-1589-42bb-b9eb-08d3f2e39169 x-microsoft-exchange-diagnostics: 1; MWHPR15MB1181; 20:5RGjTFGn2svQZGplJ7YbfWFx3ntJyx+XzzUXSEXseeiryjkQfpV6HFbPd9/xCLfRI293jrFzdhYYw0euS+Yx2uSCfAuxbHQ5wT1l5x0WqzCc/IoLiN7eiyIt7XpNtFvf0SWCpSowIWLQblRz4ZKnTFu8X0nJU6Ul7PGOcc24NZw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1181; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(166708455590820)(67672495146484)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:MWHPR15MB1181; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1181; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(189002)(377454003)(11100500001)(106356001)(7696004)(5660300001)(2900100001)(76576001)(101416001)(7736002)(10400500002)(19609705001)(87936001)(105586002)(2906002)(81166006)(81156014)(189998001)(77096005)(33656002)(122556002)(7846002)(99286002)(7906003)(74316002)(4326007)(68736007)(15975445007)(19617315012)(3280700002)(76176999)(2950100002)(3660700001)(19580395003)(5001770100001)(16236675004)(54356999)(19300405004)(5002640100001)(50986999)(92566002)(586003)(790700001)(6116002)(19625215002)(97736004)(19580405001)(86362001)(9686002)(8676002)(102836003)(8936002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1181; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182EB64501B697B7B4E3D4FAFDD0MWHPR15MB1182namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 21:05:59.8783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1181 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-12_11:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN with 0-RTT Data 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: Wed, 12 Oct 2016 21:07:15 -0000 --_000_MWHPR15MB1182EB64501B697B7B4E3D4FAFDD0MWHPR15MB1182namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVvcmRlcmluZyB0aGUgQUxQTiBvZmZlciBoYXMgYSBjb3VwbGUgYWR2YW50YWdlczoNCiogSXQg ZXhwbGljaXRseSBkZWZpbmVzIHRoZSBwcm90b2NvbCB0aGF0IHRoZSAwLVJUVCBkYXRhIGlzIHVz aW5nIG9uIHRoYXQgY29ubmVjdGlvbi4gV2l0aG91dCB0aGlzLCBib3RoIHRoZSBjbGllbnQgYW5k IHRoZSBzZXJ2ZXIgbXVzdCBpbmRlcGVuZGVudGx5IHN0b3JlIHRoZSBBTFBOIGluIHVzZSAob2Yg Y291cnNlIHRoZSBzZXJ2ZXIgY2FuIHB1dCBpdCBpbiB0aGUgdGlja2V0KS4gV2hpbGUgdGhpcyBz aG91bGQgd29yayBpZiBpbXBsZW1lbnRlZCBwcm9wZXJseSwgdGhlcmUgaXMgbm90aGluZyBpbiB0 aGUgcHJvdG9jb2wgdGhhdCBlbmZvcmNlcyB0aGV5IG1hdGNoIGJlZm9yZSB0aGUgc2VydmVyIGFj Y2VwdHMgdGhlIGRhdGEuIElmIHRoZSBjbGllbnQgQUxQTiBvZmZlciBkb2VzIGhhcHBlbiB0byBj aGFuZ2UsIGl04oCZcyBldmVuIHBvc3NpYmxlIGZvciB0aGUgc2VsZWN0ZWQgQUxQTiB0byBiZSBv bmUgdGhhdCB0aGUgY2xpZW50IGRpZG7igJl0IGV2ZW4gb2ZmZXIuDQoqIElmIHRoZSBjbGllbnQg a25vd3Mgb3V0LW9mLWJhbmQgKG9yIGxlYXJucyBvdmVyIHRoZSBhcHBsaWNhdGlvbiBwcm90b2Nv bCkgdGhhdCB0aGUgc2VydmVyIHN1cHBvcnRzIG11bHRpcGxlIHByb3RvY29scywgaXQgd2lsbCBu b3QgYmUgYWJsZSB0byB1c2UgaXRzIGN1cnJlbnQgY29ubmVjdGlvbiB0byBzdGFydCB1cCBhIDAt UlRUIGNvbm5lY3Rpb24gb3ZlciB0aGUgbmV3IHByb3RvY29sLg0KKiBJIHRoaW5rIHJlYWxpc3Rp Y2FsbHkgZm9yIG1hbnkgY2xpZW50cyB0aGUgcHJvdG9jb2wgdXNlZCB0byBzZW5kIDAtUlRUIGRh dGEgd2lsbCBlbmQgdXAgYmVpbmcgdGhlIG9ubHkgcHJvdG9jb2wgdGhhdCBjYW4gYmUgdXNlZCBv biB0aGF0IGNvbm5lY3Rpb24sIGV2ZW4gaWYgMC1SVFQgaXMgcmVqZWN0ZWQuIFJlamVjdGVkIDAt UlRUIGRhdGEgY2Fu4oCZdCBiZSByZXNlbnQgMS1SVFQgaWYgYSBkaWZmZXJlbnQgYXBwbGljYXRp b24gcHJvdG9jb2wgaXMgdXNlZCwgYW5kIGl04oCZcyBkaWZmaWN1bHQgQVBJLXdpc2UgdG8gdGVs bCB0aGUgaGlnaGVyIGxheWVyIOKAnFlvdXIgaHR0cC8yIGVhcmx5IGRhdGEgZmFpbGVkLCBidXQg eW91IGNhbiBzZW5kIGh0dHAvMS4xIHJlcXVlc3RzIGlmIHlvdSB3YW504oCdLiBUaHVzIGl0IG1h a2VzIHNlbnNlIGZvciB0aGVzZSBjbGllbnRzIHRvIGFkdmVydGlzZSB0aGUgMC1SVFQgZGF0YeKA mXMgYXBwbGljYXRpb24gcHJvdG9jb2wgYXMgdGhlIG1vc3QgcHJlZmVycmVkLg0KDQpJ4oCZbSBu b3Qgc3VyZSBob3cgdGhpcyBtYWtlcyBwcm90b2NvbCB0cmFuc2l0aW9ucyBhd2t3YXJkLiBJ4oCZ ZCBzdGlsbCBleHBlY3QgY2xpZW50cyB0byBjaG9vc2UgdGhlIGFwcGxpY2F0aW9uIHByb3RvY29s IHRoYXQgd2FzIHByZXZpb3VzbHkgbmVnb3RpYXRlZCwgc28gcHJlZmVycmluZyBoMyB3b3VsZG7i gJl0IGNhdXNlIGFsbCBoMiAwLVJUVCB0byBnbyBhd2F5Lg0KDQpLeWxlDQoNCkZyb206IEVyaWMg UmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIg MTIsIDIwMTYgNDowMyBQTQ0KVG86IERhdmlkIEJlbmphbWluIDxkYXZpZGJlbkBjaHJvbWl1bS5v cmc+DQpDYzogS3lsZSBOZWtyaXR6IDxrbmVrcml0ekBmYi5jb20+OyB0bHNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbVExTXSBBTFBOIHdpdGggMC1SVFQgRGF0YQ0KDQoNCg0KT24gV2VkLCBPY3Qg MTIsIDIwMTYgYXQgMTowMSBQTSwgRGF2aWQgQmVuamFtaW4gPGRhdmlkYmVuQGNocm9taXVtLm9y ZzxtYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0ub3JnPj4gd3JvdGU6DQpNeSBpbnRlcnByZXRhdGlv biB3YXM6DQoNCjEuIENsaWVudCBhbmQgc2VydmVyIHJlbWVtYmVyIHRoZSBwcmV2aW91cyBzZWxl Y3RlZCBBTFBOIHByb3RvY29sIGluIHRoZSBzZXNzaW9uLg0KDQoyLiBUaGUgY2xpZW50IG1heSBv ZmZlciB3aGF0ZXZlciBBTFBOIHByb3RvY29scyBpdCBsaWtlcy4gSXQgZG9lcyBub3QgbmVlZCB0 byBtYXRjaCB0aGUgcHJldmlvdXMgb2ZmZXIgbGlzdCwgdGhvdWdoIGl0IHByZXN1bWFibHkgd2ls bCB1bmxlc3MgeW91J3ZlIGdvdCBhIHBlcnNpc3RlbnQgc2Vzc2lvbiBjYWNoZSBvciBzby4NCg0K My4gVGhlIGNsaWVudCBhc3N1bWVzIHRoYXQgc2Vzc2lvbidzIEFMUE4gcHJvdG9jb2wgd2FzIHNl bGVjdGVkIGZvciBwdXJwb3NlcyBvZiBtaW50aW5nIDAtUlRUIGRhdGEuDQoNCjQuIFRoZSBzZXJ2 ZXIgbXVzdCBkZWNsaW5lIDAtUlRUIGlmIGl0IGNob3NlcyBhIGRpZmZlcmVudCBBTFBOIHByb3Rv Y29sLiBUaGlzIGNhbiBiZSBpbXBsZW1lbnRlZCBieSBqdXN0IGRvaW5nIEFMUE4gbmVnb3RpYXRp b24gYXMgbm9ybWFsIGFuZCBkZWNsaW5pbmcgMC1SVFQgaWYgdGhlIHJlc3VsdCBkb2VzIG5vdCBt YXRjaC4gKElmIGNsaWVudCBhbmQgc2VydmVyIHByZWZzIGhhdmUgbm90IGNoYW5nZWQsIDAtUlRU IHdpbGwgd29yay4gSWYgcHJlZnMgaGF2ZSBjaGFuZ2VkLCAwLVJUVCB3aWxsIG1pc3MgYnV0IGZ1 dHVyZSBzZXNzaW9ucyB3aWxsIHN0YXJ0IGJlaW5nIDAtUlRULWFibGUuIEkgdGhpbmsgdGhpcyBp cyBwcm9iYWJseSB0aGUgc2FuZXN0IGJlaGF2aW9yLikNCg0KNS4gVGhlIGNsaWVudCBwZXJmb3Jt cyB0aGUgdXN1YWwgY2hlY2tzIG9uIHRoZSBzZWxlY3RlZCBBTFBOIHByb3RvY29sIChtdXN0IGJl IG9uZSBvZiB0aGUgYWR2ZXJ0aXNlZCBvbmVzKS4gSW4gYWRkaXRpb24sIGl0IGVuZm9yY2VzIHRo YXQsIGlmIDAtUlRUIHdhcyBhY2NlcHRlZCwgdGhlIHByb3RvY29sIG11c3QgbWF0Y2ggdGhlIHNl c3Npb24gb25lLg0KDQpUaGlzIG1hdGNoZXMgdGhlIGJlaGF2aW9yIEkgaW50ZW5kZWQgaW4gdGhl IHNwZWMgKGFuZCB0aGUgb25lIE5TUyBpbXBsZW1lbnRzKS4NCg0KLUVrcg0KDQoNClBpbm5pbmcg b24gdGhlIG1vc3QgcHJlZmVycmVkIG9uZSBjYXVzZXMgYXdrd2FyZCB0cmFuc2l0aW9ucyB3aGVu IHRoZSBtb3N0IHByZWZlcnJlZCBBTFBOIHByb3RvY29sIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUg bW9zdCBjb21tb25seSBkZXBsb3llZCBvbmUuIElmIHdlIGV2ZXIgZGVmaW5lLCBzYXksIGgzLCB3 ZSB3YW50IHRoYXQgb25lIGluIGZyb250IG9mIGgyIHByZXN1bWFibHksIGJ1dCB3ZSB3b3VsZG4n dCB3YW50IHRvIGxvc2UgMC1SVFQgYWdhaW5zdCBhbGwgdGhlIGgyIHNlcnZlcnMgb3V0IHRoZXJl Lg0KDQpJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBiZSByZW9yZGVyIHByZWZlcmVuY2VzIGJhc2Vk IG9uIHRoZSBzZXNzaW9ucyB3ZSBhcmUgb2ZmZXJpbmcuIFRoYXQgbWFrZXMgaXQgbXVjaCBoYXJk ZXIgdG8gcmVhc29uIGFib3V0IHRoZSBiZWhhdmlvciBvZiBwcmVmZXJlbmNlIGxpc3RzLg0KDQpE YXZpZA0KDQpPbiBXZWQsIE9jdCAxMiwgMjAxNiBhdCAzOjQ5IFBNIEt5bGUgTmVrcml0eiA8a25l a3JpdHpAZmIuY29tPG1haWx0bzprbmVrcml0ekBmYi5jb20+PiB3cm90ZToNCkN1cnJlbnRseSB0 aGUgZHJhZnQgc3BlY2lmaWVzIHRoYXQgdGhlIEFMUE4gbXVzdCBiZSAidGhlIHNhbWUiIGFzIGlu IHRoZSBjb25uZWN0aW9uIHRoYXQgZXN0YWJsaXNoZWQgdGhlIFBTSyB1c2VkIHdpdGggMC1SVFQs IGFuZCB0aGF0IHRoZSBzZXJ2ZXIgbXVzdCBjaGVjayB0aGF0IHRoZSBzZWxlY3RlZCBBTFBOIG1h dGNoZXMgd2hhdCB3YXMgcHJldmlvdXNseSB1c2VkLiBJIGZpbmQgdGhpcyB1bmNsZWFyIGlmDQoN CjEpIHRoZSBjbGllbnQgc2hvdWxkIHNlbGVjdCBhbmQgb2ZmZXIgb25lIChhbmQgb25seSBvbmUp IGFwcGxpY2F0aW9uIHByb3RvY29sDQoNCjIpIHRoZSBjbGllbnQgY2FuIG9mZmVyIG11bHRpcGxl IHByb3RvY29scywgYnV0IHVzZSB0aGUgbW9zdCBwcmVmZXJyZWQgb25lIG9mZmVyZWQgZm9yIDAt UlRUIGRhdGENCg0KMykgdGhlIGNsaWVudCBtdXN0IHNlbmQgdGhlIGV4YWN0IHNhbWUgQUxQTiBl eHRlbnNpb24gYXMgaW4gdGhlIHByZXZpb3VzIGNvbm5lY3Rpb24sIGJ1dCBtdXN0IHVzZSB0aGUg QUxQTiBwcmV2aW91c2x5IHNlbGVjdGVkIGJ5IHRoZSBzZXJ2ZXIgKGV2ZW4gaWYgaXQgd2FzIG5v dCB0aGUgY2xpZW50J3MgZmlyc3Qgb2ZmZXIpLg0KDQoNCg0KVG8gY2xhcmlmeSB0aGlzIHdlIGNh biBpbnN0ZWFkDQoNCiogYWxsb3cgdGhlIGNsaWVudCB0byBvZmZlciB3aGF0ZXZlciBBTFBOIGV4 dGVuc2lvbiBpdCB3YW50cw0KDQoqIGRlZmluZSB0aGF0IHRoZSAwLVJUVCBkYXRhIHVzZXMgdGhl IGNsaWVudCdzIG1vc3QgcHJlZmVycmVkIGFwcGxpY2F0aW9uIHByb3RvY29sIG9mZmVyIChhbmQg dGhlIHNlcnZlciBtdXN0IHBpY2sgdGhpcyBBTFBOIGlmIGl0IGFjY2VwdHMgMC1SVFQpLCBzaW1p bGFyIHRvIHVzaW5nIHRoZSBmaXJzdCBQU0sgb2ZmZXIgaWYgbXVsdGlwbGUgYXJlIG9mZmVyZWQN Cg0KKiByZWNvbW1lbmQgdGhhdCB0aGUgY2xpZW50IHVzZXMgdGhlIHNhbWUgYXBwbGljYXRpb24g cHJvdG9jb2wgdGhhdCB3YXMgdXNlZCBvbiB0aGUgcHJldmlvdXMgY29ubmVjdGlvbi4NCg0KDQoN ClBSOiBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzY4MQ0KDQoNCg0K S3lsZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KVExTIG1haWxpbmcgbGlzdA0KDQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9y Zz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb190bHMmZD1EUU1GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9 bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZtPWRpQlZLTUJtX0dKQnJxQnNpbFpXUDBhTjVLRDl4d3ZY U0NJRE9FNS1MQUEmcz1GdVNxZFkxUzk2VnRyeTYzb1VZN1ZHNGItNUpSSmdaWXYzM0lvQlBrQWhN JmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX3RscyZkPURRTUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1sMmo0QmprTzBM YzN1NENIMno3alB3Jm09ZGlCVktNQm1fR0pCcnFCc2lsWldQMGFONUtEOXh3dlhTQ0lET0U1LUxB QSZzPUZ1U3FkWTFTOTZWdHJ5NjNvVVk3Vkc0Yi01SlJKZ1pZdjMzSW9CUGtBaE0mZT0+DQoNCg== --_000_MWHPR15MB1182EB64501B697B7B4E3D4FAFDD0MWHPR15MB1182namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVvcmRlcmluZyB0 aGUgQUxQTiBvZmZlciBoYXMgYSBjb3VwbGUgYWR2YW50YWdlczo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiogSXQgZXhwbGljaXRs eSBkZWZpbmVzIHRoZSBwcm90b2NvbCB0aGF0IHRoZSAwLVJUVCBkYXRhIGlzIHVzaW5nIG9uIHRo YXQgY29ubmVjdGlvbi4gV2l0aG91dCB0aGlzLCBib3RoIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2 ZXIgbXVzdCBpbmRlcGVuZGVudGx5IHN0b3JlIHRoZSBBTFBOIGluIHVzZQ0KIChvZiBjb3Vyc2Ug dGhlIHNlcnZlciBjYW4gcHV0IGl0IGluIHRoZSB0aWNrZXQpLiBXaGlsZSB0aGlzIHNob3VsZCB3 b3JrIGlmIGltcGxlbWVudGVkIHByb3Blcmx5LCB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBwcm90 b2NvbCB0aGF0IGVuZm9yY2VzIHRoZXkgbWF0Y2ggYmVmb3JlIHRoZSBzZXJ2ZXIgYWNjZXB0cyB0 aGUgZGF0YS4gSWYgdGhlIGNsaWVudCBBTFBOIG9mZmVyIGRvZXMgaGFwcGVuIHRvIGNoYW5nZSwg aXTigJlzIGV2ZW4gcG9zc2libGUNCiBmb3IgdGhlIHNlbGVjdGVkIEFMUE4gdG8gYmUgb25lIHRo YXQgdGhlIGNsaWVudCBkaWRu4oCZdCBldmVuIG9mZmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KiBJZiB0aGUgY2xpZW50IGtu b3dzIG91dC1vZi1iYW5kIChvciBsZWFybnMgb3ZlciB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wp IHRoYXQgdGhlIHNlcnZlciBzdXBwb3J0cyBtdWx0aXBsZSBwcm90b2NvbHMsIGl0IHdpbGwgbm90 IGJlIGFibGUgdG8gdXNlIGl0cyBjdXJyZW50IGNvbm5lY3Rpb24gdG8NCiBzdGFydCB1cCBhIDAt UlRUIGNvbm5lY3Rpb24gb3ZlciB0aGUgbmV3IHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KiBJIHRoaW5rIHJlYWxp c3RpY2FsbHkgZm9yIG1hbnkgY2xpZW50cyB0aGUgcHJvdG9jb2wgdXNlZCB0byBzZW5kIDAtUlRU IGRhdGEgd2lsbCBlbmQgdXAgYmVpbmcgdGhlIG9ubHkgcHJvdG9jb2wgdGhhdCBjYW4gYmUgdXNl ZCBvbiB0aGF0IGNvbm5lY3Rpb24sIGV2ZW4gaWYgMC1SVFQgaXMgcmVqZWN0ZWQuDQogUmVqZWN0 ZWQgMC1SVFQgZGF0YSBjYW7igJl0IGJlIHJlc2VudCAxLVJUVCBpZiBhIGRpZmZlcmVudCBhcHBs aWNhdGlvbiBwcm90b2NvbCBpcyB1c2VkLCBhbmQgaXTigJlzIGRpZmZpY3VsdCBBUEktd2lzZSB0 byB0ZWxsIHRoZSBoaWdoZXIgbGF5ZXIg4oCcWW91ciBodHRwLzIgZWFybHkgZGF0YSBmYWlsZWQs IGJ1dCB5b3UgY2FuIHNlbmQgaHR0cC8xLjEgcmVxdWVzdHMgaWYgeW91IHdhbnTigJ0uIFRodXMg aXQgbWFrZXMgc2Vuc2UgZm9yIHRoZXNlIGNsaWVudHMNCiB0byBhZHZlcnRpc2UgdGhlIDAtUlRU IGRhdGHigJlzIGFwcGxpY2F0aW9uIHByb3RvY29sIGFzIHRoZSBtb3N0IHByZWZlcnJlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SeKAmW0gbm90IHN1cmUgaG93IHRoaXMgbWFrZXMgcHJvdG9jb2wgdHJhbnNp dGlvbnMgYXdrd2FyZC4gSeKAmWQgc3RpbGwgZXhwZWN0IGNsaWVudHMgdG8gY2hvb3NlIHRoZSBh cHBsaWNhdGlvbiBwcm90b2NvbCB0aGF0IHdhcyBwcmV2aW91c2x5IG5lZ290aWF0ZWQsIHNvIHBy ZWZlcnJpbmcgaDMgd291bGRu4oCZdA0KIGNhdXNlIGFsbCBoMiAwLVJUVCB0byBnbyBhd2F5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5LeWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBPY3RvYmVyIDEyLCAyMDE2IDQ6MDMgUE08YnI+DQo8Yj5Ubzo8L2I+IERhdmlk IEJlbmphbWluICZsdDtkYXZpZGJlbkBjaHJvbWl1bS5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBL eWxlIE5la3JpdHogJmx0O2tuZWtyaXR6QGZiLmNvbSZndDs7IHRsc0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW1RMU10gQUxQTiB3aXRoIDAtUlRUIERhdGE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIE9jdCAxMiwgMjAxNiBhdCAxOjAxIFBNLCBEYXZpZCBCZW5q YW1pbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkYmVuQGNocm9taXVtLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmRhdmlkYmVuQGNocm9taXVtLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBpbnRlcnByZXRhdGlvbiB3 YXM6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MS4gQ2xpZW50IGFuZCBzZXJ2ZXIgcmVtZW1iZXIgdGhlIHByZXZpb3VzIHNlbGVjdGVkIEFMUE4g cHJvdG9jb2wgaW4gdGhlIHNlc3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFRoZSBjbGllbnQgbWF5IG9mZmVyIHdoYXRldmVyIEFM UE4gcHJvdG9jb2xzIGl0IGxpa2VzLiBJdCBkb2VzIG5vdCBuZWVkIHRvIG1hdGNoIHRoZSBwcmV2 aW91cyBvZmZlciBsaXN0LCB0aG91Z2ggaXQgcHJlc3VtYWJseSB3aWxsIHVubGVzcyB5b3UndmUg Z290IGEgcGVyc2lzdGVudCBzZXNzaW9uIGNhY2hlIG9yIHNvLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBUaGUgY2xpZW50IGFzc3VtZXMg dGhhdCBzZXNzaW9uJ3MgQUxQTiBwcm90b2NvbCB3YXMgc2VsZWN0ZWQgZm9yIHB1cnBvc2VzIG9m IG1pbnRpbmcgMC1SVFQgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+NC4gVGhlIHNlcnZlciBtdXN0IGRlY2xpbmUgMC1SVFQgaWYgaXQg Y2hvc2VzIGEgZGlmZmVyZW50IEFMUE4gcHJvdG9jb2wuIFRoaXMgY2FuIGJlIGltcGxlbWVudGVk IGJ5IGp1c3QgZG9pbmcgQUxQTiBuZWdvdGlhdGlvbiBhcyBub3JtYWwgYW5kIGRlY2xpbmluZyAw LVJUVCBpZiB0aGUgcmVzdWx0IGRvZXMgbm90IG1hdGNoLiAoSWYgY2xpZW50IGFuZCBzZXJ2ZXIg cHJlZnMgaGF2ZSBub3QgY2hhbmdlZCwgMC1SVFQNCiB3aWxsIHdvcmsuIElmIHByZWZzIGhhdmUg Y2hhbmdlZCwgMC1SVFQgd2lsbCBtaXNzIGJ1dCBmdXR1cmUgc2Vzc2lvbnMgd2lsbCBzdGFydCBi ZWluZyAwLVJUVC1hYmxlLiBJIHRoaW5rIHRoaXMgaXMgcHJvYmFibHkgdGhlIHNhbmVzdCBiZWhh dmlvci4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjUuIFRoZSBjbGllbnQgcGVyZm9ybXMgdGhlIHVzdWFsIGNoZWNrcyBvbiB0aGUgc2VsZWN0 ZWQgQUxQTiBwcm90b2NvbCAobXVzdCBiZSBvbmUgb2YgdGhlIGFkdmVydGlzZWQgb25lcykuIElu IGFkZGl0aW9uLCBpdCBlbmZvcmNlcyB0aGF0LCBpZiAwLVJUVCB3YXMgYWNjZXB0ZWQsIHRoZSBw cm90b2NvbCBtdXN0IG1hdGNoIHRoZSBzZXNzaW9uIG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG1hdGNoZXMgdGhlIGJlaGF2aW9yIEkgaW50ZW5k ZWQgaW4gdGhlIHNwZWMgKGFuZCB0aGUgb25lIE5TUyBpbXBsZW1lbnRzKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlBpbm5pbmcgb24gdGhlIG1vc3QgcHJlZmVycmVkIG9uZSBjYXVzZXMgYXdrd2Fy ZCB0cmFuc2l0aW9ucyB3aGVuIHRoZSBtb3N0IHByZWZlcnJlZCBBTFBOIHByb3RvY29sIGlzIG5v dCB0aGUgc2FtZSBhcyB0aGUgbW9zdCBjb21tb25seSBkZXBsb3llZCBvbmUuIElmIHdlIGV2ZXIg ZGVmaW5lLCBzYXksIGgzLCB3ZSB3YW50IHRoYXQgb25lIGluIGZyb250IG9mIGgyIHByZXN1bWFi bHksIGJ1dCB3ZSB3b3VsZG4ndA0KIHdhbnQgdG8gbG9zZSAwLVJUVCBhZ2FpbnN0IGFsbCB0aGUg aDIgc2VydmVycyBvdXQgdGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGJlIHJlb3JkZXIgcHJl ZmVyZW5jZXMgYmFzZWQgb24gdGhlIHNlc3Npb25zIHdlIGFyZSBvZmZlcmluZy4gVGhhdCBtYWtl cyBpdCBtdWNoIGhhcmRlciB0byByZWFzb24gYWJvdXQgdGhlIGJlaGF2aW9yIG9mIHByZWZlcmVu Y2UgbGlzdHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi PkRhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE9jdCAxMiwg MjAxNiBhdCAzOjQ5IFBNIEt5bGUgTmVrcml0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtuZWtyaXR6 QGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtuZWtyaXR6QGZiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+Q3VycmVudGx5IHRoZSBkcmFmdCBzcGVjaWZpZXMgdGhhdCB0aGUgQUxQTiBtdXN0 IGJlICZxdW90O3RoZSBzYW1lJnF1b3Q7IGFzIGluIHRoZSBjb25uZWN0aW9uIHRoYXQgZXN0YWJs aXNoZWQgdGhlIFBTSyB1c2VkIHdpdGggMC1SVFQsIGFuZCB0aGF0IHRoZSBzZXJ2ZXIgbXVzdCBj aGVjayB0aGF0IHRoZSBzZWxlY3RlZCBBTFBOIG1hdGNoZXMgd2hhdCB3YXMgcHJldmlvdXNseQ0K IHVzZWQuIEkgZmluZCB0aGlzIHVuY2xlYXIgaWY8YnI+DQo8YnI+DQoxKSB0aGUgY2xpZW50IHNo b3VsZCBzZWxlY3QgYW5kIG9mZmVyIG9uZSAoYW5kIG9ubHkgb25lKSBhcHBsaWNhdGlvbiBwcm90 b2NvbDxicj4NCjxicj4NCjIpIHRoZSBjbGllbnQgY2FuIG9mZmVyIG11bHRpcGxlIHByb3RvY29s cywgYnV0IHVzZSB0aGUgbW9zdCBwcmVmZXJyZWQgb25lIG9mZmVyZWQgZm9yIDAtUlRUIGRhdGE8 YnI+DQo8YnI+DQozKSB0aGUgY2xpZW50IG11c3Qgc2VuZCB0aGUgZXhhY3Qgc2FtZSBBTFBOIGV4 dGVuc2lvbiBhcyBpbiB0aGUgcHJldmlvdXMgY29ubmVjdGlvbiwgYnV0IG11c3QgdXNlIHRoZSBB TFBOIHByZXZpb3VzbHkgc2VsZWN0ZWQgYnkgdGhlIHNlcnZlciAoZXZlbiBpZiBpdCB3YXMgbm90 IHRoZSBjbGllbnQncyBmaXJzdCBvZmZlcikuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVG8gY2xh cmlmeSB0aGlzIHdlIGNhbiBpbnN0ZWFkPGJyPg0KPGJyPg0KKiBhbGxvdyB0aGUgY2xpZW50IHRv IG9mZmVyIHdoYXRldmVyIEFMUE4gZXh0ZW5zaW9uIGl0IHdhbnRzPGJyPg0KPGJyPg0KKiBkZWZp bmUgdGhhdCB0aGUgMC1SVFQgZGF0YSB1c2VzIHRoZSBjbGllbnQncyBtb3N0IHByZWZlcnJlZCBh cHBsaWNhdGlvbiBwcm90b2NvbCBvZmZlciAoYW5kIHRoZSBzZXJ2ZXIgbXVzdCBwaWNrIHRoaXMg QUxQTiBpZiBpdCBhY2NlcHRzIDAtUlRUKSwgc2ltaWxhciB0byB1c2luZyB0aGUgZmlyc3QgUFNL IG9mZmVyIGlmIG11bHRpcGxlIGFyZSBvZmZlcmVkPGJyPg0KPGJyPg0KKiByZWNvbW1lbmQgdGhh dCB0aGUgY2xpZW50IHVzZXMgdGhlIHNhbWUgYXBwbGljYXRpb24gcHJvdG9jb2wgdGhhdCB3YXMg dXNlZCBvbiB0aGUgcHJldmlvdXMgY29ubmVjdGlvbi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQ UjogPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC82ODEi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxs LzY4MTwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpLeWxlPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8 YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQo8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3RscyZhbXA7ZD1EUU1GYVEmYW1wO2M9NVZEMFJU dE5sVGgzeWNkNDFiM01VdyZhbXA7cj1sMmo0QmprTzBMYzN1NENIMno3alB3JmFtcDttPWRpQlZL TUJtX0dKQnJxQnNpbFpXUDBhTjVLRDl4d3ZYU0NJRE9FNS1MQUEmYW1wO3M9RnVTcWRZMVM5NlZ0 cnk2M29VWTdWRzRiLTVKUkpnWll2MzNJb0JQa0FoTSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX3RscyZhbXA7ZD1EUU1GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFi M01VdyZhbXA7cj1sMmo0QmprTzBMYzN1NENIMno3alB3JmFtcDttPWRpQlZLTUJtX0dKQnJxQnNp bFpXUDBhTjVLRDl4d3ZYU0NJRE9FNS1MQUEmYW1wO3M9RnVTcWRZMVM5NlZ0cnk2M29VWTdWRzRi LTVKUkpnWll2MzNJb0JQa0FoTSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR15MB1182EB64501B697B7B4E3D4FAFDD0MWHPR15MB1182namp_-- From nobody Wed Oct 12 14:29:24 2016 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 7AA6812970E for ; Wed, 12 Oct 2016 14:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.006 X-Spam-Level: X-Spam-Status: No, score=-3.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 h3xds8qgVpzS for ; Wed, 12 Oct 2016 14:29:20 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3971296B8 for ; Wed, 12 Oct 2016 14:29:20 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id i202so64392931ioi.2 for ; Wed, 12 Oct 2016 14:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xBNuKZi2pEa+GrbtwM8QajHZK2jHRj2SPFKou3k9v7k=; b=KdS8yI3uUlJCZ/7gQpqlUM2W0YyGkLH/zwcf1njjNnPX7BQ56O0ObGI7hfrLvLjLJF Te7RUUrqPg0Q90vHjrTzKR2Xzo4IXZXVL0ag1pCmmvgdBfMhm9uk3FmQUWpaNAvCnsQG QimTQ/gurdGmYmWYU5igXdz9fYj519eGlaHiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xBNuKZi2pEa+GrbtwM8QajHZK2jHRj2SPFKou3k9v7k=; b=aMMfwzdeT7r5iX0PCnL2wVudBkLRrPlowC5TsQVHTcvtq9122ZyBa3RrRoNIvaJ7Is boizNpIJaYMutQFdNzTsLJDvW0bktD/64dJstjHZrkldX+dSI4rhFQbsk3p7UY4nS4dS rOndmUGVFlKuJpWEoiKFa/lIY/VDoMBV50yny/udD9ZXhkm0jHDQ3NoTv53aqkNszUnS 6tUU4IpSzceLD+m9DISgmpkDQFZVqWZFoqvgU2DoUqrYS6D6JS+e54mfXhQI6oBLbbXR 3s0wuZeqhVS8TsBs2+D5JGzpIEYVfO1tA8H1zAD2wTDx//qTjFXYIL1fFM3Dmq9i/ryk C39w== X-Gm-Message-State: AA6/9RnifC2uA6oCmRDmS5rzC+FbaR3cY7SwTvGirLTwJ0/HtsQklFd39V/U6xV8P4n3Kuih+1xskLwe7HK8nZ7o X-Received: by 10.107.144.138 with SMTP id s132mr3499005iod.146.1476307759442; Wed, 12 Oct 2016 14:29:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 12 Oct 2016 21:29:07 +0000 Message-ID: To: Kyle Nekritz , Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c0557d895478c053eb1af0b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ALPN with 0-RTT Data 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: Wed, 12 Oct 2016 21:29:23 -0000 --94eb2c0557d895478c053eb1af0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2016 at 5:07 PM Kyle Nekritz wrote: > > Reordering the ALPN offer has a couple advantages: > > * It explicitly defines the protocol that the 0-RTT data is using on that > connection. Without this, both the client and the server must independent= ly > store the ALPN in use > (of course the server can put it in the ticket). While this should work i= f > implemented properly, there is nothing in the protocol that enforces they > match before the server accepts the data. If the client ALPN offer does > happen to change, it=E2=80=99s even possible > for the selected ALPN to be one that the client didn=E2=80=99t even offer= . > The client shouldn't offer 0-RTT on a session which predicts an ALPN that it doesn't accept. This is consistent with the client not wanting to offer session that uses a cipher it doesn't support. That is illegal already. (Note clients already must have code for checking if an ALPN is acceptable because that's what happens when a server responds. The nice thing about the session-remembering algorithm is it involves no new codepaths apart from a simple equality check. Clients offer parameters and confirm acceptability of a single one, servers select given an offer.) > * If the client knows out-of-band (or learns over the application > protocol) that the server supports multiple protocols, it will not be abl= e > to use its current connection to > start up a 0-RTT connection over the new protocol. > Why wouldn't it have negotiated that protocol over ALPN originally? One should not need 0-RTT to unlock ALPN protocols. > * I think realistically for many clients the protocol used to send 0-RTT > data will end up being the only protocol that can be used on that > connection, even if 0-RTT is rejected. > Rejected 0-RTT data can=E2=80=99t be resent 1-RTT if a different applicat= ion > protocol is used, and it=E2=80=99s difficult API-wise to tell the higher = layer > =E2=80=9CYour http/2 early data failed, but you can send http/1.1 request= s if you > want=E2=80=9D. Thus it makes sense for these clients > to advertise the 0-RTT data=E2=80=99s application protocol as the most pr= eferred. > ALPN protocol switching (or any other connection property) on 0-RTT rejects is always something a client must account for. I think your proposal has the same problem. Perhaps the server had to turn h2 off for some reason. You cannot assume the server's configuration remains unchanged. It is an excellent prediction, but it is only a prediction. A 0-RTT reject for a client ultimately must look like a retry. Everything you ever wrote on the socket was discarded. It also must be bubbled up sufficiently high that all connection properties are allowed to change. This is pretty much fundamental to the whole idea of predicting server-selected parameters. (If TLS were server-offer/client-select like QUIC it would be a bit more obvious what's going on, but it's still the same deal.) For instance, here's an implementation strategy for socket-pooling clients (i.e. browsers): you tell the HTTP layer to try again completely from the top, meanwhile taking the socket and returning it to the socket pool as a 1-RTT-capable socket. The retry will grab that socket and use it. (Or maybe some other request else will. That sounds weird, but it's no different from what socket pools already do. A 0-RTT reject means the socket is reset.) > I=E2=80=99m not sure how this makes protocol transitions awkward. I=E2=80= =99d still expect > clients to choose the application protocol that was previously negotiated= , > so preferring h3 wouldn=E2=80=99t > cause all h2 0-RTT to go away. > They either go away or you pin on h2 when you should have gone to h3. Suppose I prefer h3 > h2 and I talk to an h2 server. Per your proposal, if I attempt to 0-RTT with that session, my choices are: 1. Keep my order h3 > h2. That means 0-RTT is conditioned on the server picking h3 and I cannot 0-RTT. 2. Swap the order h2 > h3. That means 0-RTT works, but if the server then gets upgraded to support h3, my order is false and the server continues to pick h2. Since the server is going to continually issue me new tickets, I'll never get the order switched back unless I go long periods without talking to it. With the session-remembering interpretation, once the server's preferences change, you 0-RTT miss once. (Because your prediction is wrong... that's unavoidable. The server's configuration changed.) But after that, all your new tickets are at h3 and the steady state is 0-RTT-capable again. David > > > Kyle > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > > > *Sent:* Wednesday, October 12, 2016 4:03 PM > > *To:* David Benjamin > > *Cc:* Kyle Nekritz ; tls@ietf.org > > *Subject:* Re: [TLS] ALPN with 0-RTT Data > > > > > > > > > > > On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin > wrote: > > > > > > My interpretation was: > > > > > > > > 1. Client and server remember the previous selected ALPN protocol in the > session. > > > > > > > > 2. The client may offer whatever ALPN protocols it likes. It does not nee= d > to match the previous offer list, though it presumably will unless you've > got a persistent session cache or so. > > > > > > > > 3. The client assumes that session's ALPN protocol was selected for > purposes of minting 0-RTT data. > > > > > > > > 4. The server must decline 0-RTT if it choses a different ALPN protocol. > This can be implemented by just doing ALPN negotiation as normal and > declining 0-RTT if the result does not match. (If client and server prefs > have not changed, 0-RTT > will work. If prefs have changed, 0-RTT will miss but future sessions wil= l > start being 0-RTT-able. I think this is probably the sanest behavior.) > > > > > > > > 5. The client performs the usual checks on the selected ALPN protocol > (must be one of the advertised ones). In addition, it enforces that, if > 0-RTT was accepted, the protocol must match the session one. > > > > > > > > > > > > > This matches the behavior I intended in the spec (and the one NSS > implements). > > > > > > > > -Ekr > > > > > > > > > > > > > > > > > Pinning on the most preferred one causes awkward transitions when the mos= t > preferred ALPN protocol is not the same as the most commonly deployed one= . > If we ever define, say, h3, we want that one in front of h2 presumably, b= ut > we wouldn't > want to lose 0-RTT against all the h2 servers out there. > > > > > > > > I don't think we should be reorder preferences based on the sessions we > are offering. That makes it much harder to reason about the behavior of > preference lists. > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz wrote: > > > > Currently the draft specifies that the ALPN must be "the same" as in the > connection that established the PSK used with 0-RTT, and that the server > must check that the selected ALPN matches what was previously > used. I find this unclear if > > > > 1) the client should select and offer one (and only one) application > protocol > > > > 2) the client can offer multiple protocols, but use the most preferred on= e > offered for 0-RTT data > > > > 3) the client must send the exact same ALPN extension as in the previous > connection, but must use the ALPN previously selected by the server (even > if it was not the client's first offer). > > > > > > > > To clarify this we can instead > > > > * allow the client to offer whatever ALPN extension it wants > > > > * define that the 0-RTT data uses the client's most preferred application > protocol offer (and the server must pick this ALPN if it accepts 0-RTT), > similar to using the first PSK offer if multiple are offered > > > > * recommend that the client uses the same application protocol that was > used on the previous connection. > > > > > > > > PR: https://github.com/tlswg/tls13-spec/pull/681 > > > > > > > > Kyle > > > > > > > > _______________________________________________ > > > > TLS mailing list > > > > TLS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > > --94eb2c0557d895478c053eb1af0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 12= , 2016 at 5:07 PM Kyle Nekritz <knekr= itz@fb.com> wrote:

Reordering the ALPN offer has a couple adv= antages:

* It explicitly def= ines the protocol that the 0-RTT data is using on that connection. Without = this, both the client and the server must independently store the ALPN in u= se
(of course the server can put it in the ticket). While this should w= ork if implemented properly, there is nothing in the protocol that enforces= they match before the server accepts the data. If the client ALPN offer do= es happen to change, it=E2=80=99s even possible
for the selected ALPN t= o be one that the client didn=E2=80=99t even offer.

<= /blockquote>

The client shouldn't offer 0-RTT on a s= ession which predicts an ALPN that it doesn't accept. This is consisten= t with the client not wanting to offer session that uses a cipher it doesn&= #39;t support. That is illegal already.

(Note clie= nts already must have code for checking if an ALPN is acceptable because th= at's what happens when a server responds. The nice thing about the sess= ion-remembering algorithm is it involves no new codepaths apart from a simp= le equality check. Clients offer parameters and confirm acceptability of a = single one, servers select given an offer.)
=C2=A0

* If the client kn= ows out-of-band (or learns over the application protocol) that the server s= upports multiple protocols, it will not be able to use its current connecti= on to
start up a 0-RTT connection over the new protocol.


Why wouldn't it have negotiate= d that protocol over ALPN originally? One should not need 0-RTT to unlock A= LPN protocols.
=C2=A0

* I think realistically for many clients the p= rotocol used to send 0-RTT data will end up being the only protocol that ca= n be used on that connection, even if 0-RTT is rejected.
Rejected 0-RTT= data can=E2=80=99t be resent 1-RTT if a different application protocol is = used, and it=E2=80=99s difficult API-wise to tell the higher layer =E2=80= =9CYour http/2 early data failed, but you can send http/1.1 requests if you= want=E2=80=9D. Thus it makes sense for these clients
to advertise the = 0-RTT data=E2=80=99s application protocol as the most preferred.

=

ALPN protocol switching (or an= y other connection property) on 0-RTT rejects is always something a client = must account for. I think your proposal has the same problem. Perhaps the s= erver had to turn h2 off for some reason. You cannot assume the server'= s configuration remains unchanged. It is an excellent prediction, but it is= only a prediction.

A 0-RTT reject for a client ul= timately must look like a retry. Everything you ever wrote on the socket wa= s discarded. It also must be bubbled up sufficiently high that all connecti= on properties are allowed to change. This is pretty much fundamental to the= whole idea of predicting server-selected parameters. (If TLS were server-o= ffer/client-select like QUIC it would be a bit more obvious what's goin= g on, but it's still the same deal.)

For insta= nce, here's an implementation strategy for socket-pooling clients (i.e.= browsers): you tell the HTTP layer to try again completely from the top, m= eanwhile taking the socket and returning it to the socket pool as a 1-RTT-c= apable socket. The retry will grab that socket and use it. (Or maybe some o= ther request else will. That sounds weird, but it's no different from w= hat socket pools already do. A 0-RTT reject means the socket is reset.)
=C2=A0

I=E2=80=99m not sure how this makes protocol transitions awkward= . I=E2=80=99d still expect clients to choose the application protocol that = was previously negotiated, so preferring h3 wouldn=E2=80=99t
cause all = h2 0-RTT to go away.


They either go away or you pin on h2 when you should have gone to h3. Supp= ose I prefer h3 > h2 and I talk to an h2 server. Per your proposal, if I= attempt to 0-RTT with that session, my choices are:

1. Keep my order h3 > h2. That means 0-RTT is conditioned on the serv= er picking h3 and I cannot 0-RTT.
2. Swap the order h2 > h3. T= hat means 0-RTT works, but if the server then gets upgraded to support h3, = my order is false and the server continues to pick h2. Since the server is = going to continually issue me new tickets, I'll never get the order swi= tched back unless I go long periods without talking to it.
With the session-remembering interpretation, once the server&#= 39;s preferences change, you 0-RTT miss once. (Because your prediction is w= rong... that's unavoidable. The server's configuration changed.) Bu= t after that, all your new tickets are at h3 and the steady state is 0-RTT-= capable again.

David
=C2=A0

=C2=A0


Kyle


=C2=A0


From: Eric Rescorla [mail= to:ek= r@rtfm.com]


Sent:= Wednesday, October 12, 2016 4:03 PM

To: David Benjamin <davidben@chromium.org>= ;

Cc: Kyle Nekritz &l= t;= knekritz@fb.com>; tls@ietf.org

Subject: Re: [TLS] ALPN with 0-RTT Data


= =C2=A0



=C2=A0


=C2=A0



On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin <dav= idben@chromium.org> wrote:






My interpretation was:



=C2=A0





1. Client and server remember t= he previous selected ALPN protocol in the session.



=C2=A0




2. The client may offer whatever ALPN protocols it= likes. It does not need to match the previous offer list, though it presum= ably will unless you've got a persistent session cache or so.




= =C2=A0




3. The client assumes that sessio= n's ALPN protocol was selected for purposes of minting 0-RTT data.




=C2=A0




4. The server must decline 0-RT= T if it choses a different ALPN protocol. This can be implemented by just d= oing ALPN negotiation as normal and declining 0-RTT if the result does not = match. (If client and server prefs have not changed, 0-RTT
will work. I= f prefs have changed, 0-RTT will miss but future sessions will start being = 0-RTT-able. I think this is probably the sanest behavior.)




=C2=A0=




<= p class=3D"MsoNormal gmail_msg">5. The client performs the usual checks on = the selected ALPN protocol (must be one of the advertised ones). In additio= n, it enforces that, if 0-RTT was accepted, the protocol must match the ses= sion one.









= =C2=A0




This matches the behavior I inten= ded in the spec (and the one NSS implements).




=C2=A0




-Ekr




=C2=A0


=


=C2=A0



=




=

Pinning o= n the most preferred one causes awkward transitions when the most preferred= ALPN protocol is not the same as the most commonly deployed one. If we eve= r define, say, h3, we want that one in front of h2 presumably, but we would= n't
want to lose 0-RTT against all the h2 servers out there.




= =C2=A0




I don't think we should be re= order preferences based on the sessions we are offering. That makes it much= harder to reason about the behavior of preference lists.




=C2=A0










David












=C2=A0



On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz <knekritz@= fb.com> wrote:=




Currently the draft specifies = that the ALPN must be "the same" as in the connection that establ= ished the PSK used with 0-RTT, and that the server must check that the sele= cted ALPN matches what was previously
used. I find this unclear if



1) the client should sel= ect and offer one (and only one) application protocol



2) the client can offer multiple protocol= s, but use the most preferred one offered for 0-RTT data



3) the client must send the exact same= ALPN extension as in the previous connection, but must use the ALPN previo= usly selected by the server (even if it was not the client's first offe= r).







To clarify this we can instead



* allow the client to of= fer whatever ALPN extension it wants



* define that the 0-RTT data uses the client's most = preferred application protocol offer (and the server must pick this ALPN if= it accepts 0-RTT), similar to using the first PSK offer if multiple are of= fered



* recommend th= at the client uses the same application protocol that was used on the previ= ous connection.







PR: https://github.com/tlswg/tls13-spec/pull/681






Kyle







_______________________= ________________________



TLS mailing list


TLS= @ietf.org



https://www.ietf.org/mailman/listinfo/tls












_______________________________________________

TLS mailing list

TLS@ietf.org<= br class=3D"gmail_msg">
https://www.ietf.or= g/mailman/listinfo/tls




=C2=A0



--94eb2c0557d895478c053eb1af0b-- From nobody Wed Oct 12 15:26:14 2016 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 20CBE129490 for ; Wed, 12 Oct 2016 15:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 m2Dtphj57nmO for ; Wed, 12 Oct 2016 15:26:11 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3480C128B44 for ; Wed, 12 Oct 2016 15:26:11 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id o68so104149416qkf.3 for ; Wed, 12 Oct 2016 15:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=dl7WRX6uhuGpPHFOc+NXCYPygEaVWbv2NrQoJaKNAh4=; b=UyCRvdNIE3/rdSkTpskYk3ZM0iLfSQDJIX40TcCk8ld/+n/a79XBMumNjFjpJg1aoT 6eQIrVdv4z1Grm5m1Z41l7q8PXYdyPOA0BxavbHbsvrXJ2k8LB6iSletKxnE7awdnT8n p9lpSR7E+W/S9eGG2suuSYqnqpc1bXegOn9Z8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=dl7WRX6uhuGpPHFOc+NXCYPygEaVWbv2NrQoJaKNAh4=; b=dhJbQuFWgAY/oebDmuB4jxxTqNRq78UUuiVbpogcUlgeVWHuy0s4KjDElx5ZI2NXrb iDSyGEzWR95jXdCB+VdR05Wn/YguG1gijySZA1ZDocyK/m6kO4uz46jw/DESI5G+qEhW L3Sqtt3erosl71pS/d5WrajzcOwXr0psQzdQRMg6J1X2WwQRQ908YXzzzsKKOeDZLkJR AQjSya14AAu6oB7ZKT7qQWC4qAEbtGsXq06x+778uqEkmPiZPwnhw/yN44yxAJFqgHEX cyZXOX9FV1jl3AP8u/TNELmejeUm6hKQhwcY8YIVHsjhp6wa2AMhUxRJRH9xjhQU6zW3 S1GA== X-Gm-Message-State: AA6/9RkxWR5MQsJ6i/RVNVaTKON2CiK7tCIGWFr43+TiQVBM1Yu5AoGVCTiHUpiene+PMQ== X-Received: by 10.55.3.140 with SMTP id 134mr4145606qkd.65.1476311170123; Wed, 12 Oct 2016 15:26:10 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id 16sm597395qtf.36.2016.10.12.15.26.07 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Oct 2016 15:26:08 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 12 Oct 2016 18:26:06 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] PR#634: Registry for TLS protocol version ID 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: Wed, 12 Oct 2016 22:26:13 -0000 Al, David Garrett has generated PR#634 = (https://github.com/tlswg/tls13-spec/pull/634) to "explicitly [rename] = the protocol version fields as IDs and defines a registry for all = values, as they're really just arbitrary codepoints at this point.=E2=80=9D= Note that there are no bits on the wire changes as result of this PR, = but it does establish more process; if we=E2=80=99re publishing a new = TLS version there=E2=80=99s already be lots of process this won=E2=80=99t = be the straw that breaks the camel=E2=80=99s back. We=E2=80=99d like to = get a sense as to whether this PR should be merged - please provide any = comments on merging this PR by Friday (10/14). J&S= From nobody Wed Oct 12 15:30:10 2016 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 B57FF12956D for ; Wed, 12 Oct 2016 15:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 OrjS5f90LlVt for ; Wed, 12 Oct 2016 15:30:07 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35B412954F for ; Wed, 12 Oct 2016 15:30:06 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id z190so58662688qkc.2 for ; Wed, 12 Oct 2016 15:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=oq+4UT9GGJqsfa5fSW9m1uvRyzO8Ekn2hhACqzWWdDM=; b=cqPqW7L1R35AvhzRxJlv33g3PCNxQM6FEtBLFdRlcmuCbE5hayn1IhQ0VEUBMcJtce oO7NEZrbhSaLZZZ3RfApjCDdizYZCceXlpXjRwkfYrJ0hvXahTKeA5YWuM0GoGgXA/v7 OOecI1HK1g/17iHipqaBJncPbdlBDcqwScW5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=oq+4UT9GGJqsfa5fSW9m1uvRyzO8Ekn2hhACqzWWdDM=; b=ekMaVUwusdQayQXlZNrr/tUGKHZHX8cm2SwvxrCMTln2Oqj9nEVyVEyzByxL2vK759 iSVKkcNrbZUTWZ8Vz5yR9J9tfAgYink/IC+3Om3hUBf6mNgzqzfiKd4hMgbSNLfLXaRz iQDMFRVWNQs50u7v4ogTipbDQJfjMULwX4RKE2Suy6OCS9MAlgtewsIRyZ8dPabUrgUM D0w8RK0cSFuDX/JifPsNz93R2DgaNjBoDdCM3+n54PxDhQJzvTFP/DeCL/KHgKwAjVn6 4Tb1jMqg6SSvUQPR8yWS/7GHP/syctxKDQlvW3jmsqgfmLIVo17jbbHUK4S8FIgNizj1 nrfA== X-Gm-Message-State: AA6/9Rn/X9HQ1J6SBcUYmj5y9c60TSXxWK1gulun78sHK9Oj0TQOA9XtyCskikum8idqRA== X-Received: by 10.55.56.12 with SMTP id f12mr3403274qka.106.1476311405918; Wed, 12 Oct 2016 15:30:05 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id a94sm3568003qkh.11.2016.10.12.15.30.04 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Oct 2016 15:30:05 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 12 Oct 2016 18:30:03 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] PR #672: Finished Stuffing/PSK Binder 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: Wed, 12 Oct 2016 22:30:08 -0000 All, We=E2=80=99re looking to land PR#672 (aka Finished Stuffing/PSK Binder): https://github.com/tlswg/tls13-spec/pull/672 It looks there=E2=80=99s been some discussion, but that the issues have = been largely resolved. Please send any comments you have by Friday = (10/14) so that we can address them. Barring that we=E2=80=99ll = instruct ekr to land the PR then. J&S= From nobody Wed Oct 12 15:49:27 2016 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 8A0D712946C for ; Wed, 12 Oct 2016 15:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 TfYDbeca-lwN for ; Wed, 12 Oct 2016 15:49:24 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id CD18C129440 for ; Wed, 12 Oct 2016 15:49:24 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EA2A74E1327; Wed, 12 Oct 2016 22:49:23 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id D23634E131F; Wed, 12 Oct 2016 22:49:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1476312563; bh=qpuXO9OStXpWqLgdDPqLC3H2RytxBZ9/YCNhoBCtZ0U=; l=140; h=From:To:Date:References:In-Reply-To:From; b=RJssm/oKn7kcBHnqJb3LnjPHuuyNYh77eAUSXFOfVa8qKLtupK1KcQs3x4FZLQAgu QxmT1OWorNbZhxwu6H+Kl1qgCFHCd/BA+urOv22jx7ft69+Nv0uxn8DlOo1B84AVbF XvCqTsez+h6zKUXEgaHAhn0KKRfIY7RoUH9uFdf4= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id CE0F31FC8C; Wed, 12 Oct 2016 22:49:23 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 12 Oct 2016 18:49:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 12 Oct 2016 18:49:23 -0400 From: "Salz, Rich" To: Sean Turner , "" Thread-Topic: [TLS] PR#634: Registry for TLS protocol version ID Thread-Index: AQHSJNepModTvDnpB0aP8Iglgs72DqCla/qA Date: Wed, 12 Oct 2016 22:49:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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: Wed, 12 Oct 2016 22:49:26 -0000 DQo+IERhdmlkIEdhcnJldHQgaGFzIGdlbmVyYXRlZCBQUiM2MzQgKGh0dHBzOi8vZ2l0aHViLmNv bS90bHN3Zy90bHMxMy0NCj4gc3BlYy9wdWxsLzYzNCkNCg0KKzENCg0KDQo= From nobody Wed Oct 12 16:01:20 2016 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 933DF129592 for ; Wed, 12 Oct 2016 16:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 LPZBiwqY7IMo for ; Wed, 12 Oct 2016 16:01:16 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722B312958B for ; Wed, 12 Oct 2016 16:01:15 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id w3so42258504ywg.1 for ; Wed, 12 Oct 2016 16:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QEiGF3F/OLqM8escitZGc+wuOvmffC63vgeYphaReEI=; b=DkydpRFXKgrp4bktnYgkdwNW4FkUM+tbOOpmb0uHUStc//4RTu9VtffHkGTr+HB9Fg +8SbeEThaiOfvZ/IMtoJxqZORiVWx4nMauQJ8MzCNAJGqgyd9PPGIbwu6jrGHQQ6YyVH uaItOWvwJjW+O0YsfTGzlXjNPUfq/949rud3pFw1RURoL/8d5dvTjZzKhrtY4vNeJiNv 816TAw/jGP6UuEUJT78RIEvhH2J5ikzM//MBOjTccDob+2ic5lx/mRz/x1ujxMxceKcF mIQNwIA4TiuGFc9J+r0NPKBHCIiEgIH6elVXUjk46CMOFCthl5PGmDcBIuEu8pc/pAXV B4dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QEiGF3F/OLqM8escitZGc+wuOvmffC63vgeYphaReEI=; b=SfHy0fxE2V5tOvVAiZmr9N7d/qjQ3M+74nMEr3vS2vH7eSQH2Q0d5i9EpwigUYw1/E B2tJAAwCInoB3G9woATtwv006kmWi8/Eca1apBGuelGvskIgc28AGWZGhFvieV0IKMez abY7F9EVh6WBp/datdx13///0W2MOEnW1a0WWuTmqCRT3pR0t1JKRsHbT2VmUz4ckNEf WimpzVC2r3Uk6cTzj9ANesKDF2CC5KR/o+dW3fgjvHtrf22Ypgb0QkBSNfxajzK/46K0 1nwiac2kUKBNl0SW2KMaijU1FtzKcWqo8juSbmZOGdCwoK7me7jC1obMkLpXg1b8CRLN Y9zA== X-Gm-Message-State: AA6/9RkVWHBp0NYZPcIji2Cxdj2zBINOCkrZoRThjhSnCvtuv77XuiZacTkZg/sjgV3AAlDZWROytrz0hXjr2A== X-Received: by 10.129.125.198 with SMTP id y189mr3010195ywc.234.1476313274677; Wed, 12 Oct 2016 16:01:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Wed, 12 Oct 2016 16:00:34 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 12 Oct 2016 16:00:34 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a114926a050c7ec053eb2f897 Archived-At: Cc: "" Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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: Wed, 12 Oct 2016 23:01:18 -0000 --001a114926a050c7ec053eb2f897 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2016 at 3:26 PM, Sean Turner wrote: > Al, > > David Garrett has generated PR#634 (https://github.com/tlswg/ > tls13-spec/pull/634) to "explicitly [rename] the protocol version fields > as IDs and defines a registry for all values, as they're really just > arbitrary codepoints at this point.=E2=80=9D Note that there are no bits= on the > wire changes as result of this PR, but it does establish more process; if > we=E2=80=99re publishing a new TLS version there=E2=80=99s already be lot= s of process this > won=E2=80=99t be the straw that breaks the camel=E2=80=99s back. We=E2= =80=99d like to get a sense > as to whether this PR should be merged - please provide any comments on > merging this PR by Friday (10/14). > > This PR involves two changes: 1. Attaching the term "ID" to version and defining new enum code points. 2. Creating a registry The first of these seems obfuscatory and unhelpful. The second just seems unnecessary. Other specifications other than new versions of TLS won't be adding new code points, so I don't see how a registry helps. I would prefer we not merge this PR. -Ekr J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114926a050c7ec053eb2f897 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Oct 12, 2016 at 3:26 PM, Sean Turner <sean@sn3rd.com> = wrote:
Al,

David Garrett has generated PR#634 (https://github.com/t= lswg/tls13-spec/pull/634) to "explicitly [rename] the protoco= l version fields as IDs and defines a registry for all values, as they'= re really just arbitrary codepoints at this point.=E2=80=9D=C2=A0 Note that= there are no bits on the wire changes as result of this PR, but it does es= tablish more process; if we=E2=80=99re publishing a new TLS version there= =E2=80=99s already be lots of process this won=E2=80=99t be the straw that = breaks the camel=E2=80=99s back.=C2=A0 We=E2=80=99d like to get a sense as = to whether this PR should be merged - please provide any comments on mergin= g this PR by Friday (10/14).


This PR involves two changes:

1. Attaching the term "ID" to version and defini= ng new enum code points.
2. Creating a registry=C2=A0
<= br>
The first of these seems obfuscatory and unhelpful. The secon= d just seems unnecessary. Other specifications other than new versions of T= LS won't be adding new code points, so I don't see how a registry h= elps.

I would prefer we not merge this PR.

-Ekr

J&S
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114926a050c7ec053eb2f897-- From nobody Wed Oct 12 16:34:45 2016 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 D6265129632 for ; Wed, 12 Oct 2016 16:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 35coD2gZQapQ for ; Wed, 12 Oct 2016 16:34:43 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31304129631 for ; Wed, 12 Oct 2016 16:34:43 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id q7so28710946qtq.1 for ; Wed, 12 Oct 2016 16:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=OQXIhW1qNVfGtl3qc9qBksCzKeYIdqegVC2XWJ3fwrA=; b=pniyT/dMO1BkJEQAlH3Sh4WYJC8KzDusEihYTQkFTeNHNlEFXl0jq2CZgQoxV95eeQ sEpaEwFl+KuqZ2oCdvO/IJopPjk5qICStnqH36/Kpj6yHqwkqBlBQb1iErDwv9lI3N0M 92P8qFJW3E0Njyl5hBuyGn9YxRQqUsQCyntmzSXIhoyHaG6a7z19vfCoAmnoBGgoa6eU 4cI+JMHlEYkpKc17bNbfoEWQr4vHP9LR2Ta/2wUsbzjeanZ9MjZy00EPHHnpGcgZnZib D8ojSIkjdlxpAJJ88oYRHTnmk7TX2xHMbBvnMNZAmxjr640c7665Cm3ywMBRcDjNwn5L 0DhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OQXIhW1qNVfGtl3qc9qBksCzKeYIdqegVC2XWJ3fwrA=; b=L7WFDkEsITC1b6WOOt4jOOUYI/CsGHaQxP65MtIsytgWUG0TG0CcZKZ8hlhFzTYPUk 4U5pbQtRBgNRVT5EDjTi/DHP5zV8V0CHwzJ0M5qWP6kFuwU649emVt5Rbaf+ihe0l/6k RHfSBOQqTbCn+OwuHuO9Lf866e5Kp9Ktydf9uAwxNOu/RGiwqf9Xs84En2Wp/+2Q/aRQ FsOeJP/rEDBiGeJyoGHb4Xv05plxab8VxmFy6OMK/E9XrLgSA1YQhl1Nyxa2Rm3I6zJb 8FdvDN+KRhegfWaraFf91ryRwi4eXzMTIG/d3msGulB3fJcvvRE11QKM1E4MtMzIUNxq 6t5A== X-Gm-Message-State: AA6/9Rku6gWL71eQ81YKtXQ2Gsmtv9mSBzlGkBjRhZc+ahDGv/eMVnapFd5ivhi2T+UUmBKyNhWEAg1ih0aKTA== X-Received: by 10.200.45.124 with SMTP id o57mr3912529qta.90.1476315282216; Wed, 12 Oct 2016 16:34:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.22.1 with HTTP; Wed, 12 Oct 2016 16:34:21 -0700 (PDT) From: Joseph Salowey Date: Wed, 12 Oct 2016 16:34:21 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1143a410f97308053eb36fe3 Archived-At: Subject: [TLS] Early code-point assignment request for draft-davidben-tls-grease-01 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: Wed, 12 Oct 2016 23:34:45 -0000 --001a1143a410f97308053eb36fe3 Content-Type: text/plain; charset=UTF-8 We have received a request for early code-point assignment of values for draft-davidben-tls-grease-01. Please respond to this list of you have concerns about these assignments by October 28, 2016. Thanks, J&S --001a1143a410f97308053eb36fe3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have received a reques= t for early code-point assignment of values for draft-davidben-tls-grease-0= 1.=C2=A0 Please respond to this list of you have concerns about these assig= nments by October 28, 2016.

Thanks,
J&S
--001a1143a410f97308053eb36fe3-- From nobody Wed Oct 12 16:43:45 2016 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 F2D9412958D for ; Wed, 12 Oct 2016 16:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 6FVmqtLWBirq for ; Wed, 12 Oct 2016 16:43:42 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9320120726 for ; Wed, 12 Oct 2016 16:43:41 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id t192so43099970ywf.0 for ; Wed, 12 Oct 2016 16:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kj3FrPh+8awmyR9d4LC5ByqiHDvRJOAF44Arx4s9vr8=; b=cyGOZJ0Nw4IN7E7tRROb4+ortzcsmXwJEQjoBrV0SRqMzZQ+naLFAQDKSY6jvcDyWk sxeYHuL20svdaSB5l1Yq3UhLPryl4xNHxhYBU4MgH3dC7nVLaXAS5zyqnZD1E4g0LllJ nCooHjLgyHIHJm0QLpW9Hc61My2npGMJCW+e9cRR9AnNCzhrZ4phYVWmrrn/t3+sRRhe H7XBlGe/VfJigpnBOfZ2jGYLguYAZI8NT9WdfKFT7m510ZuyVUEuqWjFD+B5w2cgL9Kv fuwqGf14Ny/2Y4+gpNhlXNawNOCju6SHq8iInonA8FHgqiRSLnyPGuuO8pnDL+fC38yj Rvnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kj3FrPh+8awmyR9d4LC5ByqiHDvRJOAF44Arx4s9vr8=; b=BdM6I9BYtMC18AqzL5pUxLH8YMgWuDo9SGutXEMyCgmIwNDgYHCohdulP2EukuwAYV V2w/gOBz9kMnO8M5pe0U+uyvRoLg+pnbQRSPgWEjsOb3FPgEg+SoHYztvCncQeShLIpJ Awtj6XbnlpnqZK5O1SF2QBTmoXbL/klz4LV7W+6YOe3Qgh6ob52DN2SN0z3u6LFzvvF4 E0JeN4ZUekv7nJ3XC11h1t5MQJHXCa9rQbO9+F43W5m8IXmgiez5JHYlIyaJ9t3Xtuox uiqfrTb2PZJ/exKzaZz5VBAnwH2NranAougKuTVkxDX2eh7YShhZN5Ak7Gmu6F1NFMEf Wgrg== X-Gm-Message-State: AA6/9Rlxzp5jtfJuLPpWMKBaLSZ6y0b2R6gPeN6Spbf5SS3mgKG8TWrfisl9ND4A/DLltAzh+Oyl1+PCIu6nPQ== X-Received: by 10.129.53.206 with SMTP id c197mr3255605ywa.205.1476315821265; Wed, 12 Oct 2016 16:43:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Wed, 12 Oct 2016 16:43:00 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 12 Oct 2016 16:43:00 -0700 Message-ID: To: Joseph Salowey Content-Type: multipart/alternative; boundary=001a11421a261a8671053eb3904b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code-point assignment request for draft-davidben-tls-grease-01 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: Wed, 12 Oct 2016 23:43:44 -0000 --001a11421a261a8671053eb3904b Content-Type: text/plain; charset=UTF-8 I am fine with this. -Ekr On Wed, Oct 12, 2016 at 4:34 PM, Joseph Salowey wrote: > We have received a request for early code-point assignment of values for > draft-davidben-tls-grease-01. Please respond to this list of you have > concerns about these assignments by October 28, 2016. > > Thanks, > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11421a261a8671053eb3904b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am fine with this.

-Ekr

On W= ed, Oct 12, 2016 at 4:34 PM, Joseph Salowey <joe@salowey.net> wrote:
We have received a request for early code-point assignmen= t of values for draft-davidben-tls-grease-01.=C2=A0 Please respond to this = list of you have concerns about these assignments by October 28, 2016.

=
Thanks,
J&S

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


--001a11421a261a8671053eb3904b-- From nobody Wed Oct 12 17:55:15 2016 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 1546A129664 for ; Wed, 12 Oct 2016 17:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qnietpY1uTNl for ; Wed, 12 Oct 2016 17:55:12 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BF7129659 for ; Wed, 12 Oct 2016 17:55:12 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z190so61788128qkc.2 for ; Wed, 12 Oct 2016 17:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=suXnwlOZgW4Cor0WSxbW+WeLuoodWxx4LOHh6CYDEww=; b=H/0voaouEWmX8DEWW2hqpTIJpiH/GP5fD/alG+1SkS5wIHZGVBvaYH+xg0/X+V54Fs 2e2m1yU2TJ78pQ7DOzgaHfQZ26U4+ALlq55fXj8AjvrtFDzVdyuA9a04gCMcKE+WO7av wm4uQEarkDHQhZKccRqBga6FSoBopbYotY/PpD5DEvIRl7yi64NfErewGg8GT+Af5Ttq FhQUp3lBtU23Z8kK5SCPiQnIHKfgtzz8fOfQxGJUzwodDLdjnwSbXuZ4GeFkJmDEFu9Q u+K7ydkGHPt7126NlrndoADvQEy4/DwgbDxSQnfykRswxw1Zrg2cSNmXJDph7PEJ3tJ1 AO2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=suXnwlOZgW4Cor0WSxbW+WeLuoodWxx4LOHh6CYDEww=; b=kkStBhfJaqkTjLU8dKf64nau91B4YEy2zkrxfGHAq2B+G8WqiXPJdOuw0OlHRMLFHU SyLGIfB9tYX4v5+zAc1fzN2Qpj9YIcvbimSRZzp+1KD6p/crzhzKbVmbYBNqtWnJ6nGD JTfLOeD0ZGQaseBmfmE9sTl1kn5WKGbiO90eFM2xs/TWyR4a3KGJg5oJovM8hhu254LS oBYq0mHUBTViYZTxAU2Rc9R/JtdJgHb8hsYyv0WBFj1HgY9kTilXhXc5Y6TLeKXnhZIt qWUM5OrlV1+++3VKUy2hke9YNaVQ12cDKXxB3z7RmLM7Qi8UT2WplDdEjh0yTlnlJLvs Ar/w== X-Gm-Message-State: AA6/9Rn8cdRE3yvC1W3vBplqr29wrKMtRaCum2OjUN557gtJImf4KJpHeuYs7DDkHA3yrziHUrsbh4qehx7BAQ== X-Received: by 10.55.155.15 with SMTP id d15mr3830220qke.115.1476320111376; Wed, 12 Oct 2016 17:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 12 Oct 2016 17:55:10 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 13 Oct 2016 11:55:10 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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, 13 Oct 2016 00:55:14 -0000 On 13 October 2016 at 10:00, Eric Rescorla wrote: > I would prefer we not merge this PR. I concur, though I would prefer if we stopped using the strange { 3, 3 } notation for versions, it's not useful and it implies a significance to the separation that just doesn't exist*. [*] One caveat: you will likely be very sad if you try to change that first octet in a ClientHello. From nobody Wed Oct 12 17:59:22 2016 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 949B012965A for ; Wed, 12 Oct 2016 17:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OyY5uxHKws0k for ; Wed, 12 Oct 2016 17:59:18 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06611295F0 for ; Wed, 12 Oct 2016 17:59:18 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id o68so107453012qkf.3 for ; Wed, 12 Oct 2016 17:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=48328y1Azn5+TumKd2WiV/Z889ceqvqoPlhZ8lb6rnI=; b=AS3jEdS/ipDOlrxaC14oKC9f8DcJm2X1YWMplFXPbsSAOzH3bRGwufDuFOoAM7M/NN kfpty3YJDD+Gu54eDgaqJU4mv+NTnuRVA2jKLt7yI6GUu6RVLU74IHv+oua3H9XD1wK/ e6UszsP8E91gVmWr78REfqXJBX7LHDHPgPAgoA8l4RNUY+7GlJpNZbzMMw7ZWkyWSKyB dqUwrs+ciuc72lmp4051mxE6piHOjQLfDhAeKx594iAc2ZGnag0WfzPpTQFKb3xPJ5pf L1jtH2vLUF3eMwi9945+QvC8V5dwpMvad7xddmjQQhsnyVM7NuFbb+If9AyMM/H+8v4j tSQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=48328y1Azn5+TumKd2WiV/Z889ceqvqoPlhZ8lb6rnI=; b=hDQKNwCSYbNfJVPJsKRr5kQ+SGrmtftVO2ss0gS03zDeHUk+1OfHoDhEd+kzvWC/OF BoSoHrJeuY7AOAKQCEq8P4iSvm/tqFjqW5BwQvyiGq6I5in9MQBFWYY8zz6/5aasw5vi y5WrJx/URW3l8CxiRtDRWoWBDIC8QUqYFD+76c7e2h+KYIYcYyB8ct/GDczJnGvUx+tY NT5yKs/Ijex8k8l6vkX6ac9XwuLQs1oHyWMZlWtFLfNe2U1EgPoTbhPSe1/VcQD1e7nz PwHhxiv2hij3nHGjpNwdPDhCqBT+WHYgPX01hyzEe+z3nmSQLehTyE2dEyqpj20Ynn1G 1R6g== X-Gm-Message-State: AA6/9Rln3Dmbs0k0Y5CiRZ6IIx+HaTi2fxvdI5HIafSxmUREEuoM/7RXD4UXjU7MoyjqGQ== X-Received: by 10.55.70.84 with SMTP id t81mr3716896qka.309.1476320357966; Wed, 12 Oct 2016 17:59:17 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id k73sm3191663qke.36.2016.10.12.17.59.17 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 12 Oct 2016 17:59:17 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 12 Oct 2016 20:59:15 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201610122059.15432.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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, 13 Oct 2016 00:59:20 -0000 On Wednesday, October 12, 2016 07:00:34 pm Eric Rescorla wrote: > This PR involves two changes: > > 1. Attaching the term "ID" to version and defining new enum code points. > 2. Creating a registry > > The first of these seems obfuscatory and unhelpful. The second just seems > unnecessary. Other specifications other than new versions of TLS won't be > adding new code points, so I don't see how a registry helps. > > I would prefer we not merge this PR. One added feature we get with this registry definition is a range of codepoints for private experimental use. Formal definition might not be strictly needed here, though it shouldn't hurt. My reasoning for the explicit use of "ID" is that it would be more clear to use the term "version ID" to refer to the arbitrary codepoints (e.g. 0x0304) and simply "version number" to refer to the more descriptive "TLS 1.3". Both do end up on-the-wire; the former in the version fields and the later in context strings, which is one of the reasons why I think being more explicit here may be a good idea. The registry was first suggested by Daniel Kahn Gillmor in prior mailing list discussion around rebranding to TLS 2.0 (which we're treating as a separate issue, at the moment). I think it makes sense and I would prefer it be merged, but I don't ascribe very high importance here. Dave From nobody Wed Oct 12 18:05:24 2016 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 A53DD129659 for ; Wed, 12 Oct 2016 18:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QUFkvvl9Eq-t for ; Wed, 12 Oct 2016 18:05:21 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4900129656 for ; Wed, 12 Oct 2016 18:05:20 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id f128so59098646qkb.1 for ; Wed, 12 Oct 2016 18:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mPix22/nnGxDEUz6TfMuFfMoAasKX9M/gApZhy91IEw=; b=vxqldM4ViYctuh6Ntw+/q0VPIDuS5d9oJFljwMjcz3CxEP9tH+8DuVoNPbG9hpPbO8 3/yf3eIFGr9s4S20uLbUi5qzopqIKzgVWKqTtBRBmGXQI5feL3L1+pP5DW/+OCzKsOmC cHhvGlqLzoe204y7GYfikLkCC5p4mN8lkhHyp7g849fpi9dVL1yedpvtL3fenKJNNhOn 70SNCWe9618iNo7B1HOAv45bzWkK7MalxqS4j/+iUeBgMYUdBve0vt60SYdhLFLq6KyW yCLH2ZWH9mVoGpIAjeYygiOGVPWoTOci4WsDaB6w38eYuy9mlwJHMzEyyu/HNDtsRM+C 3AmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mPix22/nnGxDEUz6TfMuFfMoAasKX9M/gApZhy91IEw=; b=KZcYOyw6m+5x2uOpNQ/jwRV2E9V7bRl0RfjrqOUyTNYKEuzDRsnwlsdwhjDazXjVMe f1F+LrQeKtNt8eDVsE61Wm+6NLMy1rEHS624KDWanHRyGZhAMqmeimZaRMgWTeTig97j R6yVPx+s19ywCA5P2mjEiA4LgpOZwjo5rDFq5CfHBXwfJqWSTROVtjHFlrF/tVhZUp38 nXnNI30hKjlT3ETugrRLBjKYfs38MRbtqhVZIVZO/YMjwyB2JwqONigpndKaiMnOgiu7 bX/HIAFlyDfDm1c3kIy2HzJm3oYNT6QETcgvMWWAgxlFJrzvek31s7J38H0Sx8UPt9ik 9DDw== X-Gm-Message-State: AA6/9Rmj1VjFFgYtJNoN7KGAKOWTZUVGtCmZ43vLuC6UEKntlKuTL0m3NdovbLctHCstzlN468QiO0OC94suBg== X-Received: by 10.55.155.15 with SMTP id d15mr3858191qke.115.1476320720006; Wed, 12 Oct 2016 18:05:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 12 Oct 2016 18:05:19 -0700 (PDT) In-Reply-To: <201610122059.15432.davemgarrett@gmail.com> References: <201610122059.15432.davemgarrett@gmail.com> From: Martin Thomson Date: Thu, 13 Oct 2016 12:05:19 +1100 Message-ID: To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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, 13 Oct 2016 01:05:23 -0000 On 13 October 2016 at 11:59, Dave Garrett wrote: > One added feature we get with this registry definition is a range of codepoints for private experimental use. Formal definition might not be strictly needed here, though it shouldn't hurt. The same can be achieved by saying "future versions of TLS will not use version numbers higher than 0x3fff; values with the top bit set are reserved for legacy versions of DTLS; values with the two bits set to 01 are reserved for experimentation". We don't need IANA to look after that. From nobody Wed Oct 12 18:07:47 2016 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 598451295C8 for ; Wed, 12 Oct 2016 18:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Z2tRMPeDS092 for ; Wed, 12 Oct 2016 18:07:41 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FB4129566 for ; Wed, 12 Oct 2016 18:07:41 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id 191so25530679ybv.3 for ; Wed, 12 Oct 2016 18:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qpmEW8nJBQhBJ2fO4fQl3bNuxOMu55VfSX9hjn4adBE=; b=b32x+ISc95A0Fm/i6WR8NJZuLXvHFwG1XpWJ3YF9/gSFTx1iSp1bx869EhNeYDYgmg ZQLLdk/pYx5e510Sj/jvP05PUZ+kDliNX3vqvCgxOMpqSWRsk98PxRIRWDE/XoGjKNOZ 5Pb1oSJhnuGtKAw599afRq+jNBhCqQPaANFMuHuwCwk5tsIq7grvuXZEreVvJ+RBdtdk n/j6rZTt3CiUBAxrgyfdS2NFadmJbKigMNR3w3L2ItUEZH42W2qTzpGH3xuVWInCSTE/ CuHP1TeIX23O1jWTvUKGC258kqYLDKLTQEaGGkXRUvCCUrj1rpD2ffV6ypfZEd2MjEF0 7vvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qpmEW8nJBQhBJ2fO4fQl3bNuxOMu55VfSX9hjn4adBE=; b=LHNVbZRoaPIGYamAauszn1qL1y9qrGw3y8VioDCNyH+YJ4Cb7gsceQ1HPtfcxM1Jjr oqsDE4ALs7GoyOIeoa2V6PPWpA9Xx19qgUrpWp8sUHtPIj9t8TidtC2+pyJHixbfo1dG 8jq6lOIZBF5pvzZrY1O9rXp6ZuNqWPO7/6d8EgHrdoH99CRo9gknxhYFV2abIyXl8eo0 IktTLPNdXsy6AlZkMbJctXtkC6V1Kq/fBs/XjyF7vYZiHP48bpFtpLAcdX2MCkvLFoVD UAxvcjb37Up9lrkaXf6T62w0meWoKSxU014tptYEnn07NGn3rKRZ6PFLLn/dVUkkT1w+ Db1w== X-Gm-Message-State: AA6/9Rk9G3/SEATB+XTxpHnzGgpR5H0khYOXhv+/t/nzQulK89s9wGfE4e4wUK70YHpl1dvJ04rS3xpJNh0GGw== X-Received: by 10.37.174.11 with SMTP id a11mr3421536ybj.180.1476320860660; Wed, 12 Oct 2016 18:07:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Wed, 12 Oct 2016 18:07:00 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 12 Oct 2016 18:07:00 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045db83e799990053eb4bc43 Archived-At: Cc: "" Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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, 13 Oct 2016 01:07:45 -0000 --f403045db83e799990053eb4bc43 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 12, 2016 at 5:55 PM, Martin Thomson wrote: > On 13 October 2016 at 10:00, Eric Rescorla wrote: > > I would prefer we not merge this PR. > > I concur, though I would prefer if we stopped using the strange { 3, 3 > } notation for versions, it's not useful and it implies a significance > to the separation that just doesn't exist*. > I assume you would prefer hex, i.e., 0x0303? [*] One caveat: you will likely be very sad if you try to change that > first octet in a ClientHello. > Indeed. -Ekr --f403045db83e799990053eb4bc43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 12, 2016 at 5:55 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 13 October 2016 at 10:00, Eric Rescorla <ekr@rtfm.com> wrote:
> I would prefer we not merge this PR.

I concur, though I would prefer if we stopped using the strange { 3,= 3
} notation for versions, it's not useful and it implies a significance<= br> to the separation that just doesn't exist*.

I assume you would prefer hex, i.e., 0x0303?

<= div>
[*] One caveat: you will likely be very sad if you try to change that
first octet in a ClientHello.

Indeed.

-Ekr


=C2=A0=

--f403045db83e799990053eb4bc43-- From nobody Wed Oct 12 18:10:26 2016 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 F3D50129446 for ; Wed, 12 Oct 2016 18:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CxhTgXxoda_i for ; Wed, 12 Oct 2016 18:10:23 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7707E1295C6 for ; Wed, 12 Oct 2016 18:10:23 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id o68so107672970qkf.3 for ; Wed, 12 Oct 2016 18:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QyuBnMRxv3b9Htm9LOi4+1KNONpBDOD5hiGndeKqL+w=; b=XFH8NwRsctD/v4/awAuCV/Lpp6bgltus5NiU7bcAXXtyTiu0EB9O+LyR5OG8E0Nr17 Px+9MTh6ofqZ1+RuIaamx8iDEmcI2V9+MPaI/cfyVtkveCEllfdQNsgeXWpa5/YymSPR EzgtUtilh8zbp587J46nf2dznNYX42KnmOzjcddj0K+SMbEg15Ks4MQnXY0SiSZs0nm1 +c9n3ugYrUvbKDRjvE5+RNOm+UN3+uO59lWDzus76P2rszxCi3I9tk5Nh10Wu0yMcCVG r5VBhvt4uEl6UiZ+JxFTUZWl0HEOFJZN2ieCEtQ33j11pRlR23/nU5bNSxPaiq2p++R7 rO2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QyuBnMRxv3b9Htm9LOi4+1KNONpBDOD5hiGndeKqL+w=; b=ZSp1zpNzBGDbHNp8nii8d5PRFGi0JlXtK7SYhAbmy+p4DIBjt2Ma25uJ78PvzrLYkG PPHfRwGmBfM2B13YuC88EhWMCX3P5C7VTsIjTj5E5nPuezsp+pYQGjM4GBWOznLBfoL6 L0jt+4CC1Jm5P2VAzw5SAVZLS9g0cxkGt5X3PtW5yPG0P/+tXod453xXYPk0tQaWdHsh +WcT0GM6ldFIoFeo3kjoYtOM+yycF8WuFxSbBI3s2cFhGoUZT/AElP3KbuEXPo2ewCPm /GvIj8G7fohbRbH5m/hf4HFkNGhnrsic+aWsXxwmiyi37RE9eCgzHIce08l8shlH4Ua/ HP0Q== X-Gm-Message-State: AA6/9RkYr9Ix0eo0dh3elFMI0fCXGxGjrA3JYHyaMKYoG10Kimh8IO8DC+kVfN7PGjQCH/W0k8EFuHncvm+PDQ== X-Received: by 10.55.71.3 with SMTP id u3mr4487975qka.144.1476321022601; Wed, 12 Oct 2016 18:10:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 12 Oct 2016 18:10:21 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 13 Oct 2016 12:10:21 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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, 13 Oct 2016 01:10:25 -0000 On 13 October 2016 at 12:07, Eric Rescorla wrote: > I assume you would prefer hex, i.e., 0x0303? Yeah, that would be nice: it's recognizably the same as the old one that way. From nobody Wed Oct 12 23:17:40 2016 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 E27C61295CF for ; Wed, 12 Oct 2016 23:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oOrPZEUL5btK for ; Wed, 12 Oct 2016 23:17:35 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522F1128B37 for ; Wed, 12 Oct 2016 23:17:35 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id b81so117315354lfe.1 for ; Wed, 12 Oct 2016 23:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=re4uKyqwwrqdKTpFNBXhhK4EpeZnyJ3JD6nNXMrnBIA=; b=tuHO/OIqdlKRO2h5U9WPmfsx0yvKOiHvXcKFQLOumHC3Mi5dTOaxDsyepiUXp08xOP dw34+FyqgCELPQ4AaI8UDm0TlBkhJBjA4CWntcDxxifwunIAoazmRs7MWi4z3lsLUrLS 3/dwW8vooFWbWgJhUpKpl5bijwrydbfkNj+mHzSMic4yNBdMILXGUbfgfdxpeEaRiHYI Yd+K9ezC4pMn2rfF6DPI6cEI6+LWtgAV4pl0vWZXnohTncTUMhKS4wu5GvnJMLqEhDX7 Z+6LwF7gkC5zIKxjMUPN5LyMpBcbtvr+3Y/rB/5XQurKhlxxXjEnGuUmda1DnbCDKavi 7iww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=re4uKyqwwrqdKTpFNBXhhK4EpeZnyJ3JD6nNXMrnBIA=; b=c/gQ9BUkPl8n6YoJEWUAt6TUU9zr2qW0ddNNpbq+vMiOpdmxknWPX1td84Fn6l5i7s URQB+Wv4+Hu2r96buIDBARPN7IrI1uf8nnh4wE0Jc3jw4vbIu4SR192adoxDSNDUUwok bwjpFuDcHfQm9V80dCPFVguaZt4YSOgRnIcRzJgjupl5swTYjgbN/n/w4OlxWqcwSTWv uNMPdH0tbbGDcd3K3/cvrPWvqSm8L3VsuVe5gmstm8mE32FBMUZxWGXutkLvSEeiQOFu eOxZkmkGYS4kRgtmyE3/Efpg9CEZ6Jx6QgJXzXR/6RPoAGydZnCBJ8mZ7Sple5YmXJr8 rZHw== X-Gm-Message-State: AA6/9Rl3gT0wP6ddfc9fDuLgfkZOe4lgJqy4l2BXjIZN5pRvWw/Sj9iZ7/h8A7EH6IkjG5OulNDdCL0CzC/vZA== X-Received: by 10.28.174.209 with SMTP id x200mr842364wme.55.1476339453211; Wed, 12 Oct 2016 23:17:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.69 with HTTP; Wed, 12 Oct 2016 23:17:32 -0700 (PDT) From: Kazuho Oku Date: Thu, 13 Oct 2016 15:17:32 +0900 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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, 13 Oct 2016 06:17:38 -0000 TLDR: the spec. was clear and easy to implement, but some test vectors and clarification on what constitutes a Handshake Context would have helped. FWIW, please let me share my experience of implementing TLS 1.3. This month, I have written a TLS 1.3 implementation (named picotls, available at https://github.com/h2o/picotls) based on draft 16 from scratch. This has been my first time to implement TLS. I wrote my implementation by going through the draft. While writing my code, I did not refer to other implementations except for looking into OpenSSL to see if there was an optimized path for implementing AES-GCM for TLS 1.3 (which turned out to not exist in 1.0.2; it has been introduced in OpenSSL 1.1.0). After my own implementation of server and client started talking to each other, I started to test interoperability by using Firefox Nightly. I had to fix five issues before picotls started talking with Firefox, which took about half a day of work (some errors are not strictly related to TLS). Commit 479f25f, ddd50b7 fixed errors in AEAD construction. Commit 5cb99c5 fixed an error in RSA signing. Commit 2d20c86 fixed a mis-optimization in my implementation of Derive-Secr= et. Commit 5780bfc fixed a silly mistake in generating a CertificateVerify. Details of each commit can be found at https://github.com/h2o/picotls/commits/master It was possible to fix the errors by observing the fatal alert sent by Firefox and going back to the Internet Draft. But it would have been even more easier if the draft included test vectors especially for the cryptographic operations. Aside from the bugs I fixed, it seemed to me that the draft was vague on whether if msg_type and length of Handshake should be considered as part of the Handshake Context (please forgive me if I missed somewhere that mentions it). In section 4.4, the draft states that, quote: a Handshake Context based on the hash of the handshake messages. This text seems to imply that msg_type and length should be considered part of the Context, but I could not find a formal definition of what a =E2=80=9Chandshake message= =E2=80=9D is. OTOH, other parts of the Draft seem to refer to Handshake Context as a list of Handshake bodies. For example, the table in section 4.4 states that the Handshake Context for 0-RTT mode is ClientHello. I think this could be interpreted that the Context is not expected to include msg_type and length, since ClientHello is a structure that is used as a message body. So even though my interpretation (the former of the two) was correct in sense that it matched that of Firefox, I needed to check if the browser was interpreting the draft in the latter way, while I tried to fix the AEAD error. The other two issues I had are my confusion on why a Handshake Context may contain Certificate and CertificateVerify after ServerFinished (answered by Illari at https://www.ietf.org/mail-archive/web/tls/current/msg21476.html), and a mistake in encoding draft 16 as 0x16 (https://github.com/tlswg/tls13-spec/issues/682). To summarize, the draft was clear enough for a newcomer to implement the specification, but I think some test vectors and clarification on what consists a Handshake Context might help others trying to implement the protocol. Thank you very much for the great draft, and providing answers to my issues. I am looking forward to seeing it formalized. --=20 Kazuho Oku From nobody Thu Oct 13 00:08:02 2016 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 97C471298AB for ; Thu, 13 Oct 2016 00:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 C9iGQ9edZZKq for ; Thu, 13 Oct 2016 00:07:59 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75BA1298AA for ; Thu, 13 Oct 2016 00:07:58 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id m5so32199547qtb.3 for ; Thu, 13 Oct 2016 00:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lrX0rQ+PuU0vL6ZLQyI8aH49pILzyOr/QjuNtqMcB1I=; b=l+41vf9lu4nUSssmip7XiZRBSakRLlxZwRsUxpI0ak/7h1EdlIjl7/GtXRE6Ox17Eq qh9825/U2J+k+zUv+kS3AaQyUDr7PtKaWmJoARFTaOPIKsUGLMXBb5YZaEsQlPU3rY6M 8IUAI2uW89TXpgtED/zXcLvo+HY/douBGFZqOPCxkwTykHEaH+e3Hb6GGHonAoi9YrHj i1GFl8kLH6zIbGhVzhwrS+hvyMIY2aypRT1WQphjR1QCYRi6MeD5X4goeHZl0SSlOvaV Xrs4VaSa6rUKlGurn/ABHf4RoyNVvwYJYQQFCMPajqzMWGG/tBZoDAZE4/xQJxdPNYcR c10g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lrX0rQ+PuU0vL6ZLQyI8aH49pILzyOr/QjuNtqMcB1I=; b=FN+E/RSDkRqs/m2MoN71kYXmFWF6MflVvBjSkCnaUx3JgCsunDD7yI8QWZsbfWIY4U czE3bPJ37tQPhOwksIPA34ONRsR4CoVDzH8raDAP9UBrXYjQF3te2gYrlzlZnGBgPaD2 Zfl7vCMe1jwnaOt2WatOugOr5xkMDSc7Pan0bHtZatmxKrPYs33WSherdhRikBBGNF8V GIn2ktBYCfgTlHTKacHPVrz3S6buA6sWY3RMjQw+nk3HixqZuVyp4MgVhjiojUUthsUO izajs5wV9/d9z2fvbJ1pkGQL0+uj7KwY1WCvo7P70VgAsBgsppdL6DYDJIdv2xTqf7bl SmZw== X-Gm-Message-State: AA6/9RlfEzhi4VvFNU690GYWBEP6ONYqq8SNPzOU562XN/7AVcqaDgOeHQNYzhYNX07demMTtseqqXQD8rjL1w== X-Received: by 10.200.49.85 with SMTP id h21mr5162246qtb.34.1476342477743; Thu, 13 Oct 2016 00:07:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 13 Oct 2016 00:07:57 -0700 (PDT) Received: by 10.140.85.7 with HTTP; Thu, 13 Oct 2016 00:07:57 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 13 Oct 2016 18:07:57 +1100 Message-ID: To: Kazuho Oku Content-Type: multipart/alternative; boundary=001a1136e79ef3ecda053eb9c497 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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, 13 Oct 2016 07:08:01 -0000 --001a1136e79ef3ecda053eb9c497 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Kazuho! Experiences like your own are critical at this stage. It is encouraging to see that there were so few problems. As for the key schedule, EKR and I have discussed taking a dump from one of our many test cases and putting that in a draft, including private keys and all the intermediate values. It might get a bit long, so we were thinking of doing a separate companion document. Would that help you? We haven't done anything yet because the draft has been changing quite a bit, but I believe that the changes are now mostly done. I am happy to take ideas on what configurations to trace. The only thing NSS doesn't support right now is KeyUpdate (coming soon after -17 I hope). Did you want to add your implementation to the wiki? https://github.com/tlswg/tls13-spec/wiki/Implementations and you would be most welcome to n join the next hackathon in Seoul. On 13 Oct 2016 5:17 PM, "Kazuho Oku" wrote: > TLDR: the spec. was clear and easy to implement, but some test vectors > and clarification on what constitutes a Handshake Context would have > helped. > > FWIW, please let me share my experience of implementing TLS 1.3. > > This month, I have written a TLS 1.3 implementation (named picotls, > available at https://github.com/h2o/picotls) based on draft 16 from > scratch. > > This has been my first time to implement TLS. > > I wrote my implementation by going through the draft. While writing my > code, I did not refer to other implementations except for looking into > OpenSSL to see if there was an optimized path for implementing AES-GCM > for TLS 1.3 (which turned out to not exist in 1.0.2; it has been > introduced in OpenSSL 1.1.0). > > After my own implementation of server and client started talking to > each other, I started to test interoperability by using Firefox > Nightly. > > I had to fix five issues before picotls started talking with Firefox, > which took about half a day of work (some errors are not strictly > related to TLS). > > Commit 479f25f, ddd50b7 fixed errors in AEAD construction. > Commit 5cb99c5 fixed an error in RSA signing. > Commit 2d20c86 fixed a mis-optimization in my implementation of > Derive-Secret. > Commit 5780bfc fixed a silly mistake in generating a CertificateVerify. > > Details of each commit can be found at > https://github.com/h2o/picotls/commits/master > > It was possible to fix the errors by observing the fatal alert sent by > Firefox and going back to the Internet Draft. But it would have been > even more easier if the draft included test vectors especially for the > cryptographic operations. > > Aside from the bugs I fixed, it seemed to me that the draft was vague > on whether if msg_type and length of Handshake should be considered as > part of the Handshake Context (please forgive me if I missed somewhere > that mentions it). > > In section 4.4, the draft states that, quote: a Handshake Context > based on the hash of the handshake messages. This text seems to imply > that msg_type and length should be considered part of the Context, but > I could not find a formal definition of what a =E2=80=9Chandshake message= =E2=80=9D is. > > OTOH, other parts of the Draft seem to refer to Handshake Context as a > list of Handshake bodies. For example, the table in section 4.4 states > that the Handshake Context for 0-RTT mode is ClientHello. I think this > could be interpreted that the Context is not expected to include > msg_type and length, since ClientHello is a structure that is used as > a message body. > > So even though my interpretation (the former of the two) was correct > in sense that it matched that of Firefox, I needed to check if the > browser was interpreting the draft in the latter way, while I tried to > fix the AEAD error. > > The other two issues I had are my confusion on why a Handshake Context > may contain Certificate and CertificateVerify after ServerFinished > (answered by Illari at > https://www.ietf.org/mail-archive/web/tls/current/msg21476.html), and > a mistake in encoding draft 16 as 0x16 > (https://github.com/tlswg/tls13-spec/issues/682). > > To summarize, the draft was clear enough for a newcomer to implement > the specification, but I think some test vectors and clarification on > what consists a Handshake Context might help others trying to > implement the protocol. > > Thank you very much for the great draft, and providing answers to my > issues. I am looking forward to seeing it formalized. > > -- > Kazuho Oku > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1136e79ef3ecda053eb9c497 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks Kazuho!

Experiences like your own are critical at this stage. It is = encouraging to see that there were so few problems.

As for the key schedule, EKR and I have discussed taking a d= ump from one of our many test cases and putting that in a draft, including = private keys and all the intermediate values. It might get a bit long, so w= e were thinking of doing a separate companion document. Would that help you= ?

We haven't done anything yet because the draft has been = changing quite a bit, but I believe that the changes are now mostly done. <= /p>

I am happy to take ideas on what configurations to trace. Th= e only thing NSS doesn't support right now is KeyUpdate (coming soon af= ter -17 I hope).

Did you want to add your implementation to the wiki?=C2=A0 <= a href=3D"https://github.com/tlswg/tls13-spec/wiki/Implementations">https:/= /github.com/tlswg/tls13-spec/wiki/Implementations=C2=A0 and you would b= e most welcome to n join the next hackathon in Seoul.


On 13 Oct 2016 5:= 17 PM, "Kazuho Oku" <ka= zuhooku@gmail.com> wrote:
TLDR: the spec. was clear and easy to implement, but some tes= t vectors
and clarification on what constitutes a Handshake Context would have
helped.

FWIW, please let me share my experience of implementing TLS 1.3.

This month, I have written a TLS 1.3 implementation (named picotls,
available at https://github.com/h2o/picotls) based on draft 1= 6 from
scratch.

This has been my first time to implement TLS.

I wrote my implementation by going through the draft. While writing my
code, I did not refer to other implementations except for looking into
OpenSSL to see if there was an optimized path for implementing AES-GCM
for TLS 1.3 (which turned out to not exist in 1.0.2; it has been
introduced in OpenSSL 1.1.0).

After my own implementation of server and client started talking to
each other, I started to test interoperability by using Firefox
Nightly.

I had to fix five issues before picotls started talking with Firefox,
which took about half a day of work (some errors are not strictly
related to TLS).

Commit 479f25f, ddd50b7 fixed errors in AEAD construction.
Commit 5cb99c5 fixed an error in RSA signing.
Commit 2d20c86 fixed a mis-optimization in my implementation of Derive-Secr= et.
Commit 5780bfc fixed a silly mistake in generating a CertificateVerify.

Details of each commit can be found at
https://github.com/h2o/picotls/commits/master<= br>
It was possible to fix the errors by observing the fatal alert sent by
Firefox and going back to the Internet Draft. But it would have been
even more easier if the draft included test vectors especially for the
cryptographic operations.

Aside from the bugs I fixed, it seemed to me that the draft was vague
on whether if msg_type and length of Handshake should be considered as
part of the Handshake Context (please forgive me if I missed somewhere
that mentions it).

In section 4.4, the draft states that, quote: a Handshake Context
based on the hash of the handshake messages. This text seems to imply
that msg_type and length should be considered part of the Context, but
I could not find a formal definition of what a =E2=80=9Chandshake message= =E2=80=9D is.

OTOH, other parts of the Draft seem to refer to Handshake Context as a
list of Handshake bodies. For example, the table in section 4.4 states
that the Handshake Context for 0-RTT mode is ClientHello. I think this
could be interpreted that the Context is not expected to include
msg_type and length, since ClientHello is a structure that is used as
a message body.

So even though my interpretation (the former of the two) was correct
in sense that it matched that of Firefox, I needed to check if the
browser was interpreting the draft in the latter way, while I tried to
fix the AEAD error.

The other two issues I had are my confusion on why a Handshake Context
may contain Certificate and CertificateVerify after ServerFinished
(answered by Illari at
https://www.ietf.org/mail-archiv= e/web/tls/current/msg21476.html), and
a mistake in encoding draft 16 as 0x16
(https://github.com/tlswg/tls13-spec/issues/682).

To summarize, the draft was clear enough for a newcomer to implement
the specification, but I think some test vectors and clarification on
what consists a Handshake Context might help others trying to
implement the protocol.

Thank you very much for the great draft, and providing answers to my
issues. I am looking forward to seeing it formalized.

--
Kazuho Oku

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1136e79ef3ecda053eb9c497-- From nobody Thu Oct 13 02:18:15 2016 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 598141296E0 for ; Thu, 13 Oct 2016 02:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 ymBvNf1SbGQ1 for ; Thu, 13 Oct 2016 02:18:12 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id E998F12957A for ; Thu, 13 Oct 2016 02:18:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 2D9B816816; Thu, 13 Oct 2016 12:18:10 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id H_vJ6N9ujT5D; Thu, 13 Oct 2016 12:18:09 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id BF23E21C; Thu, 13 Oct 2016 12:18:09 +0300 (EEST) Date: Thu, 13 Oct 2016 12:18:03 +0300 From: Ilari Liusvaara To: Kazuho Oku Message-ID: <20161013091803.GA22882@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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, 13 Oct 2016 09:18:14 -0000 On Thu, Oct 13, 2016 at 03:17:32PM +0900, Kazuho Oku wrote: > TLDR: the spec. was clear and easy to implement, but some test vectors > and clarification on what constitutes a Handshake Context would have > helped. > > FWIW, please let me share my experience of implementing TLS 1.3. > > This month, I have written a TLS 1.3 implementation (named picotls, > available at https://github.com/h2o/picotls) based on draft 16 from > scratch. Tried interop versus my own implementation (with my implementation as client). Didn't work... I traced the blowup to client_hello_decode_server_name(): The sent contents of the SNI extension is: 00 0B 00 00 08 "h2o.test" Which AFAICT is a server name list of 11 bytes, containing entry of type 0 (host_name), with length 8 and name "h2o.test". picotls seems to interpret the first byte as the type (happens to be 0, which is host_name), and then interprets 0B 00 as the length of the hostname. Which of course blows up as the length is way too big (over 2kB). Also, my implementation does not show any alert being received from the peer (as result of this failure), just connection being closed (internally, picotls returns -50, which I think is decode_error)? -Ilari From nobody Thu Oct 13 05:22:59 2016 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 939D61294C4 for ; Thu, 13 Oct 2016 05:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 1wPBu0non3vr for ; Thu, 13 Oct 2016 05:22:56 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB23D1294BE for ; Thu, 13 Oct 2016 05:22:55 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id 191so29986831ybv.3 for ; Thu, 13 Oct 2016 05:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/iUvz37Fa3iMhkH8cMmD89ulnAEKw5Vrwsno5+iniD0=; b=zfcX9NUfaJyuoOdIv8I44Uke+IAxKmqoBXddRnQaIHRJGSjmC90hg6ZIpAFh9bq+cz Jhg4R3loZVPzyLOdxsSq1Xga14zvVx6+/JklVTUrzSOwubDpKE2f+iE2zjjrR9Pg4ldD h+5Yr0sSLEilGHLXTyQjw6SFScL539WONUuk19+71TMHq9G4cG5/uiKVOxI3KHLTwtqY D93xxt9ctojbxsSmgmUKfeFxA7k+gYn3cKRIIgkfLEyV15ZMsHi4m2Jpypp8BihWf/KR KVEaJneR+9Lerpiw7CsLdYfJMOcW+PYyPFbP9bK01LLCr5qigeBFDtGJ47mbhcL42i1P bdUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/iUvz37Fa3iMhkH8cMmD89ulnAEKw5Vrwsno5+iniD0=; b=X7VBOnREOl10VMysInn0qFXVc3CkyiaRfEO9F1KML+OlRHIRuWBX9GAqoPkPupm8H+ +uI7rl0hDPrtlYTJH2XyxKV5dWIa9WYI5fBq2w3t5GPd1oS+JiM6jvHbWUFLJT1zQdDX 2zX6qCi2yO4JONenir5+n8KEdgPiloWkB4MAVTLdZESe23X9/xui6D/XR5v09eEW2MOT SUsNVkxNiGuBMpdBRIJD9Wv+BteRfmeGAa3rr6RMM4msl53wXsgkFTveB1fQTUHM6cHx 0Aghe0BKiZ8uhwT0/ikOprdvj9MpDXeeRZF3HPGfCcUnELlAQozbUbzh3ZK7hEudQbfp QeLg== X-Gm-Message-State: AA6/9RmYwhpTfChaG7ZjBrWbgBDpIa22cMr7estIwe19qQRVdGjy3hu2Uv/BZmA0qgAqQKdrk003fUzWxlZgUw== X-Received: by 10.37.80.12 with SMTP id e12mr5286592ybb.105.1476361375167; Thu, 13 Oct 2016 05:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Thu, 13 Oct 2016 05:22:14 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 13 Oct 2016 05:22:14 -0700 Message-ID: To: Kazuho Oku Content-Type: multipart/alternative; boundary=001a113e86cc53df24053ebe2b65 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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, 13 Oct 2016 12:22:58 -0000 --001a113e86cc53df24053ebe2b65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kazuho, Thanks for the feedback. This is very helpful. On Wed, Oct 12, 2016 at 11:17 PM, Kazuho Oku wrote: > > I wrote my implementation by going through the draft. While writing my > code, I did not refer to other implementations except for looking into > OpenSSL to see if there was an optimized path for implementing AES-GCM > for TLS 1.3 (which turned out to not exist in 1.0.2; it has been > introduced in OpenSSL 1.1.0). > > After my own implementation of server and client started talking to > each other, I started to test interoperability by using Firefox > Nightly. > > I had to fix five issues before picotls started talking with Firefox, > which took about half a day of work (some errors are not strictly > related to TLS). > > Commit 479f25f, ddd50b7 fixed errors in AEAD construction. > Commit 5cb99c5 fixed an error in RSA signing. > Commit 2d20c86 fixed a mis-optimization in my implementation of > Derive-Secret. > Commit 5780bfc fixed a silly mistake in generating a CertificateVerify. > > Details of each commit can be found at > https://github.com/h2o/picotls/commits/master > > It was possible to fix the errors by observing the fatal alert sent by > Firefox and going back to the Internet Draft. But it would have been > even more easier if the draft included test vectors especially for the > cryptographic operations. > We have heard this a number of times. We'll see what we can do about producing some vectors from a working implementation. Aside from the bugs I fixed, it seemed to me that the draft was vague > on whether if msg_type and length of Handshake should be considered as > part of the Handshake Context (please forgive me if I missed somewhere > that mentions it). > > In section 4.4, the draft states that, quote: a Handshake Context > based on the hash of the handshake messages. This text seems to imply > that msg_type and length should be considered part of the Context, but > I could not find a formal definition of what a =E2=80=9Chandshake message= =E2=80=9D is. > Ouch. Yes, I see what you mean here. There used to be some text that made this clear, but I think it got lost in an edit. I have filed an issue to fix this (https://github.com/tlswg/tls13-spec/issues/688) and will try to get it in by -17. The other two issues I had are my confusion on why a Handshake Context > may contain Certificate and CertificateVerify after ServerFinished > (answered by Illari at > https://www.ietf.org/mail-archive/web/tls/current/msg21476.html), and > It sounds like test vectors would help here. > a mistake in encoding draft 16 as 0x16 > (https://github.com/tlswg/tls13-spec/issues/682). > I have clarified this in in: https://github.com/tlswg/tls13-spec/commit/0353994e038cfbf15becc68c41264478= 9d2e3009 Thanks for the bug report! Thank you very much for the great draft, and providing answers to my > issues. I am looking forward to seeing it formalized. Thank you very much for your input. It's great to see people doing implementations from the specification and having success! Best, -Ekr > > -- > Kazuho Oku > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113e86cc53df24053ebe2b65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kazuho,

Thanks for the feedback. This i= s very helpful.

On Wed, Oct 12, 2016 at 11:17 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
I wrote my implementation by going through the draft. While writing my
code, I did not refer to other implementations except for looking into
OpenSSL to see if there was an optimized path for implementing AES-GCM
for TLS 1.3 (which turned out to not exist in 1.0.2; it has been
introduced in OpenSSL 1.1.0).

After my own implementation of server and client started talking to
each other, I started to test interoperability by using Firefox
Nightly.

I had to fix five issues before picotls started talking with Firefox,
which took about half a day of work (some errors are not strictly
related to TLS).

Commit 479f25f, ddd50b7 fixed errors in AEAD construction.
Commit 5cb99c5 fixed an error in RSA signing.
Commit 2d20c86 fixed a mis-optimization in my implementation of Derive-Secr= et.
Commit 5780bfc fixed a silly mistake in generating a CertificateVerify.

Details of each commit can be found at
https://github.com/h2o/picotls/commits/master<= br>
It was possible to fix the errors by observing the fatal alert sent by
Firefox and going back to the Internet Draft. But it would have been
even more easier if the draft included test vectors especially for the
cryptographic operations.

We have heard= this a number of times. We'll see what we can do about producing some<= /div>
vectors from a working implementation.=C2=A0

=

Aside from the bugs I fixed, it seemed to me that the draft was vague
on whether if msg_type and length of Handshake should be considered as
part of the Handshake Context (please forgive me if I missed somewhere
that mentions it).

In section 4.4, the draft states that, quote: a Handshake Context
based on the hash of the handshake messages. This text seems to imply
that msg_type and length should be considered part of the Context, but
I could not find a formal definition of what a =E2=80=9Chandshake message= =E2=80=9D is.

Ouch. Yes, I see what you= mean here. There used to be some text that made
this clear, but = I think it got lost in an edit. I have filed an issue to fix this
(https://github= .com/tlswg/tls13-spec/issues/688) and will try to get it in by -17.


The other two issues I had are my confusion on why a Handshake Context
may contain Certificate and CertificateVerify after ServerFinished
(answered by Illari at
https://www.ietf.org/mail-archiv= e/web/tls/current/msg21476.html), and

It sounds like test vectors would help here.

=C2=A0
a mistake in encoding draft 16 as 0x16
(https://github.com/tlswg/tls13-spec/issues/682).

=

Thanks = for the bug report!
=C2=A0

Thank you very much for the great draft, and providing answers to my
issues. I am looking forward to seeing it formalized.

=
Thank you very much for your input. It's great to see people= doing implementations from
the specification and having success!=

Best,
-Ekr
=C2=A0

--
Kazuho Oku

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

--001a113e86cc53df24053ebe2b65-- From nobody Thu Oct 13 13:33:33 2016 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 41845129643 for ; Thu, 13 Oct 2016 13:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 kmVgmLRmgXqS for ; Thu, 13 Oct 2016 13:33:28 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9736D12946B for ; Thu, 13 Oct 2016 13:33:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 15A1616972; Thu, 13 Oct 2016 23:33:27 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 4fuNeOroE_aM; Thu, 13 Oct 2016 23:33:26 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 59E7E286; Thu, 13 Oct 2016 23:33:26 +0300 (EEST) Date: Thu, 13 Oct 2016 23:33:19 +0300 From: Ilari Liusvaara To: Kazuho Oku Message-ID: <20161013203319.GA24052@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161013091803.GA22882@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161013091803.GA22882@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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, 13 Oct 2016 20:33:32 -0000 On Thu, Oct 13, 2016 at 12:18:03PM +0300, Ilari Liusvaara wrote: > On Thu, Oct 13, 2016 at 03:17:32PM +0900, Kazuho Oku wrote: > > TLDR: the spec. was clear and easy to implement, but some test vectors > > and clarification on what constitutes a Handshake Context would have > > helped. > > > > FWIW, please let me share my experience of implementing TLS 1.3. > > > > This month, I have written a TLS 1.3 implementation (named picotls, > > available at https://github.com/h2o/picotls) based on draft 16 from > > scratch. > > Tried interop versus my own implementation (with my implementation > as client). > > Didn't work... I traced the blowup to client_hello_decode_server_name(): > > The sent contents of the SNI extension is: > > 00 0B 00 00 08 "h2o.test" > > Which AFAICT is a server name list of 11 bytes, containing entry of > type 0 (host_name), with length 8 and name "h2o.test". Further testing: My implementation vs. picotls: ------------------------------ Ok, dumped the handshake using wireshark. Wireshark seems to think the SNI with two lengths is perfectly sane. I modified the picotls code to read the extra length. Then I hit another issue: eckey_is_on_group seems to be busted: It presumably should use == instead of !=, since it is presumably supposed to return 1 if groups match, since it is used to check if the key is P-256. Couple of bugs in my code later, I could get successful handshake with my code as client and picotls as server. Yay. picotls vs my implementation: ----------------------------- Trying picotls as client and my code as server first hit the issue that picotls doesn't send RSA-PKCS-V1.5 as supported, causing my implementation to fail with no suitable certificate (it requires algorithms for the chain too, not just the end key). After defeating that check, the handshake got further, but something in server's messages (ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished) made picotls crash (heap corruption as evidenced by the malloc() error). Haven't debugged that error yet. -Ilari From nobody Thu Oct 13 17:43:20 2016 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 1421F1294A0 for ; Thu, 13 Oct 2016 17:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HpspiXagOc7d for ; Thu, 13 Oct 2016 17:43:16 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BB5127A90 for ; Thu, 13 Oct 2016 17:43:15 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id b81so162238243lfe.1 for ; Thu, 13 Oct 2016 17:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jTmXXt0cH+5sN9g0dPapf2V7MGMYgK/Im2B7naYrldc=; b=eLzzZDDLO0WFeftMRV51V3Y4pCvIvj6VO9hnHFctQCYVq/0si6NqOHhpfK7jyI0PX9 10hcTI661G9F/L/sP/PajKx0ELQmz1pwZYPuPebMyUU5If4dH0ExXkv5nbP5fX7L669h l06yj/fMWwma1hqHp6LTUwXaZq/IONtDmx072JcJNiVA0be6IlhpEN/LVxuvsRNxWCWu 9bacTSy+c7/6J/7hKXm4a0CdxhVdLDYiHJcEKCZSVi65sjkpg4viyt3NV43L+As9Du5D JhY7hIUWMRackQWbIIF7gfehO7FBTgF68BhaQof0ZIJlkXbW16AldNwhtCD9Xgpv1pn2 gknw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jTmXXt0cH+5sN9g0dPapf2V7MGMYgK/Im2B7naYrldc=; b=gaW8bSXEp8/9q4xz+EVODeSBhbGUccn/zdBSXXgcESYqmwP/hrTaTFC85ubTdGw39p CHMqB2Bxu7ti6ttDNPRj9779NX9OmOevGtPGGbk6X150FlC36JS87jg3eVI44A97fFNg DpF24cDFs3fCLQiSveteK7FEvfvl6k6oUrZoMR4bsN1acBoo44B3/6wQI18nI/SAwHxO aruog1Ktwb4kew/gUkTdQ21OJcmC6Ec4tExQM+VkW30GIcjUbcJ3LgOJKGGDTf9QkF3P IqiVDpnkz31b4ZXFvscJN9jae79TxAVrjCci9kZsFWxJ7jgVxCU7neRDasg8r3iPmDBG Bnbw== X-Gm-Message-State: AA6/9Rl4nUc58ukgE3oc6V7Oq4xmixd+DhIfh+noKVGPU/ilzjPd8keVUD5fZ/BOIkzsHsdGwpyvdiBo8CTv8g== X-Received: by 10.194.242.1 with SMTP id wm1mr233266wjc.145.1476405793045; Thu, 13 Oct 2016 17:43:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.69 with HTTP; Thu, 13 Oct 2016 17:43:12 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 14 Oct 2016 09:43:12 +0900 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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: Fri, 14 Oct 2016 00:43:19 -0000 Hi Martin, 2016-10-13 16:07 GMT+09:00 Martin Thomson : > Thanks Kazuho! > > Experiences like your own are critical at this stage. It is encouraging t= o > see that there were so few problems. > > As for the key schedule, EKR and I have discussed taking a dump from one = of > our many test cases and putting that in a draft, including private keys a= nd > all the intermediate values. It might get a bit long, so we were thinking= of > doing a separate companion document. Would that help you? Yes. That would have helped. Especially it would be great if there was an example of generating AEAD key and IV from the handshake messages. The logic (e.g. HKDF-Expand-Label and Derive-Secret defined in section 7.1) and the parameters that the logic takes as input are defined in different sections of the draft. For example, you have to look at section 2 and 7.3 to find out the correct parameters. So I had to concentrate on getting all them together to form an interoperable code. I won't say it was hard, but having a test vector that goes though the process step by step would have helped a lot. > We haven't done anything yet because the draft has been changing quite a > bit, but I believe that the changes are now mostly done. > > I am happy to take ideas on what configurations to trace. The only thing = NSS > doesn't support right now is KeyUpdate (coming soon after -17 I hope). > > Did you want to add your implementation to the wiki? > https://github.com/tlswg/tls13-spec/wiki/Implementations and you would b= e > most welcome to n join the next hackathon in Seoul. Thank you for the offer. I added my implementation to the wiki. > > > On 13 Oct 2016 5:17 PM, "Kazuho Oku" wrote: >> >> TLDR: the spec. was clear and easy to implement, but some test vectors >> and clarification on what constitutes a Handshake Context would have >> helped. >> >> FWIW, please let me share my experience of implementing TLS 1.3. >> >> This month, I have written a TLS 1.3 implementation (named picotls, >> available at https://github.com/h2o/picotls) based on draft 16 from >> scratch. >> >> This has been my first time to implement TLS. >> >> I wrote my implementation by going through the draft. While writing my >> code, I did not refer to other implementations except for looking into >> OpenSSL to see if there was an optimized path for implementing AES-GCM >> for TLS 1.3 (which turned out to not exist in 1.0.2; it has been >> introduced in OpenSSL 1.1.0). >> >> After my own implementation of server and client started talking to >> each other, I started to test interoperability by using Firefox >> Nightly. >> >> I had to fix five issues before picotls started talking with Firefox, >> which took about half a day of work (some errors are not strictly >> related to TLS). >> >> Commit 479f25f, ddd50b7 fixed errors in AEAD construction. >> Commit 5cb99c5 fixed an error in RSA signing. >> Commit 2d20c86 fixed a mis-optimization in my implementation of >> Derive-Secret. >> Commit 5780bfc fixed a silly mistake in generating a CertificateVerify. >> >> Details of each commit can be found at >> https://github.com/h2o/picotls/commits/master >> >> It was possible to fix the errors by observing the fatal alert sent by >> Firefox and going back to the Internet Draft. But it would have been >> even more easier if the draft included test vectors especially for the >> cryptographic operations. >> >> Aside from the bugs I fixed, it seemed to me that the draft was vague >> on whether if msg_type and length of Handshake should be considered as >> part of the Handshake Context (please forgive me if I missed somewhere >> that mentions it). >> >> In section 4.4, the draft states that, quote: a Handshake Context >> based on the hash of the handshake messages. This text seems to imply >> that msg_type and length should be considered part of the Context, but >> I could not find a formal definition of what a =E2=80=9Chandshake messag= e=E2=80=9D is. >> >> OTOH, other parts of the Draft seem to refer to Handshake Context as a >> list of Handshake bodies. For example, the table in section 4.4 states >> that the Handshake Context for 0-RTT mode is ClientHello. I think this >> could be interpreted that the Context is not expected to include >> msg_type and length, since ClientHello is a structure that is used as >> a message body. >> >> So even though my interpretation (the former of the two) was correct >> in sense that it matched that of Firefox, I needed to check if the >> browser was interpreting the draft in the latter way, while I tried to >> fix the AEAD error. >> >> The other two issues I had are my confusion on why a Handshake Context >> may contain Certificate and CertificateVerify after ServerFinished >> (answered by Illari at >> https://www.ietf.org/mail-archive/web/tls/current/msg21476.html), and >> a mistake in encoding draft 16 as 0x16 >> (https://github.com/tlswg/tls13-spec/issues/682). >> >> To summarize, the draft was clear enough for a newcomer to implement >> the specification, but I think some test vectors and clarification on >> what consists a Handshake Context might help others trying to >> implement the protocol. >> >> Thank you very much for the great draft, and providing answers to my >> issues. I am looking forward to seeing it formalized. >> >> -- >> Kazuho Oku >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls --=20 Kazuho Oku From nobody Thu Oct 13 21:38:42 2016 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 84479129664 for ; Thu, 13 Oct 2016 21:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ie1JIAwrsclf for ; Thu, 13 Oct 2016 21:38:40 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C610312965A for ; Thu, 13 Oct 2016 21:38:39 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id x79so179176403lff.0 for ; Thu, 13 Oct 2016 21:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Msifkk9gaQtfFM8EXxYPHjD37v0gDltd7cPrIMGI6yc=; b=XCYNtEa8eRY14EuXEa6viQS2D5sZ0ZL/cTC7Ar3oK22EtR1Mh0L1igYZ5aGLzqWs85 wX2/S/O+1APAu+x6/0glcqxVq5jUeU+GiZyFeWpWT04OeP0aTLeSd0gTmLjJimQYdhhU rKHqVgu66aTHzQTe6RpFx5DW+rtodgl6gLEmfIPKc0icJlmEbl0szWEte8OQCXiCi3r6 QvZJIZ3E2Cx96lYv+vf+XuYBM+dwDyXGBi9q5tWZG7MHRer/cQRLhIgxNZvi0XErdu+W M4STwajaknC1T1q3YP220zs2WlJafsziNYhQkkH8K6SRdU09tOeXvnChMlE4ocAiAyJz zyJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Msifkk9gaQtfFM8EXxYPHjD37v0gDltd7cPrIMGI6yc=; b=atnGrNVeYwB0/tM79AMzMGjMFjNuIOlf5e+iVAuWckUGDw2DESZfo6e8L4ZncKLlEa NGxUVtFuPcHKPbQuelaV8jtm37YjgTqIIeRM8l9mZHeG/yM+HCEXY8Bi3ESglVdHyX90 VNOsudNRdGrfAjsb7ORTMGwJYxti+5Uv7XxTXyph+7TrJYzv9II8d5OmZnMlWoVwbfv5 hOdkof7F3XN/3SxwVaueI4kn2m9pzaaiKeDp3+eARi2xVGVwcifgB27EO9n60Ow6+tw9 Lg081AogaIUlXtwuIiFMO0DXKlaHzo5iMqDjMyvZi8NvADL147CKMHehgC7bzd5EbhkR b3uA== X-Gm-Message-State: AA6/9RlpzunSwEzD5943Cd/FP7OqhhQY+lNCwZh62Y9BLH4oPdXQpGhekPKoAipBXDOTLeZx5htczdvEJuWeIw== X-Received: by 10.194.97.69 with SMTP id dy5mr615569wjb.53.1476419917760; Thu, 13 Oct 2016 21:38:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.69 with HTTP; Thu, 13 Oct 2016 21:38:37 -0700 (PDT) From: Kazuho Oku Date: Fri, 14 Oct 2016 13:38:37 +0900 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate? 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: Fri, 14 Oct 2016 04:38:41 -0000 Hi, In TLS 1.3, my understanding is that the digest function negotiated using the Signature Algorithm should be used for generating CertificateVerify, since the draft states that: | Each SignatureScheme value lists a single signature algorithm that the client is willing to verify. | (section 4.2.3) | The Hash function and the HKDF hash are the cipher suite hash algorithm. Hash.length is its output length. | (section 7.1) The draft permits fullbacking back to using SHA1 certificates: | TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it. | (section 4.2.3) However, the draft also states: | SHA-1 MUST NOT be used in any signatures in CertificateVerify. All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures. | (section 4.4.2) So my question is, which signature algorithm am I supposed to use for a rsa_pkcs1_sha1 certificate? I'd assume that the answer is rsa_pss_sha256, but I could not find any such indication within the draft. -- Kazuho Oku From nobody Thu Oct 13 22:34:57 2016 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 501A1129694 for ; Thu, 13 Oct 2016 22:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EpSu950TNHUM for ; Thu, 13 Oct 2016 22:34:53 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1AF129698 for ; Thu, 13 Oct 2016 22:34:52 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id x79so181585703lff.0 for ; Thu, 13 Oct 2016 22:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=UY546M2sz00hZHuPvOpCnprhr6sl16P8jCubrxvDUOc=; b=MeKZ1AxsSnBBbp9cfYl0E+6towlDHz6RDssyEuJm6LjMiIcySlPGNC2qJUBGclSA+c zMOVAIXA5631SQYj88gw/LJKkH5g56f9w60TIcRdY33sbgaE/wMjxwC+nMjwcMpEZfM/ U7zJbt273F3Hdusegq+yI3m2txQZ0XNRqf1EZZvq9id8HlMXvZo1wbinIh9vNqZw5ioJ 3+NZ7Tl8fcfzw8uT8k7JYalAlBQ3mJujWWBSYtwoGe0wBOWOXJhqh34mGYQiF1UklRF6 iQ4oupdX6/Da20zDq6WqAtmgBI5763iVVQZxdGiNBfDD4kajLKQDFJXB3/lBQSwAMucD Py2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=UY546M2sz00hZHuPvOpCnprhr6sl16P8jCubrxvDUOc=; b=QcaxdI1vKbh1kKLMNI5nk5LHm7jhFhxlVLYM/+YEgrTVv6aAVNQSXFKDSxc8s7sV6k 2Z5uwgfKkJgoFg0TG8NOx3SCYpCIH4ecja2Al2xMhcNZwdZAvIzszIIDV0blBNNsDPOK nTv21MU82AxDKNjIg+tvXSUo5iAck9BFNUDeEUrbDd5Ajv31127sYc7nqExlEOgfhQC8 NroIpuDxrM4mT2vP2TTuCdj6ar8m8TyRnyRSaMdQ0NtOZEjgBqGdUzmdyduOeldjgo4X tY74SnQaY3C7AEZ6QzhlaVCCkGrlcffLvKtNHC7el+yyoj9KTXiPrMsKVuzAGvEft88z K5gg== X-Gm-Message-State: AA6/9RkYG0YIqp5/1bnWPyhVwvdcJQjpzzoax2I1gev/9souJMAI+6zkNs0Z/makHFPxUZEpQg2Jq6RWRYM9bQ== X-Received: by 10.28.10.202 with SMTP id 193mr351635wmk.123.1476423290071; Thu, 13 Oct 2016 22:34:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.69 with HTTP; Thu, 13 Oct 2016 22:34:49 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 14 Oct 2016 14:34:49 +0900 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate? 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: Fri, 14 Oct 2016 05:34:55 -0000 Sorry for the fuss, I think I was confused. Now my interpretation of the draft is as follows. A server is expected to send a Certificate message that contains certificates using the signature algorithms specified by the client, with preference and exception rules defined in section 4.2.3 (Signature Algorithms) and 4.4.1.2 (Server Certificate Selection). A server is expected to generate a Certificate Verify message using a method that is in the intersection of the algorithms specified by the client using the Signature Algorithms extension that is _not_ blacklisted to be used for signing CertificateVerify. The blacklisted ones are: rsa_pkcs1_XXX and those use SHA-1 (rsa_pkcs_sha1, dsa_sha1 ecdsa_sha1). note: It seems that dsa_sha1 and ecdsa_sha1 have _RESERVED suffixes in A.3.1.3 even though they are referred to without the suffixes in the document. Is this an editorial issue? I think I got confused by the way section 4.4.2 (Certificate Verify) blacklists the algorithm. To me the following sentences seemed to indicate that PKCS1 and SHA1 needed different treatments. RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms". SHA-1 MUST NOT be used in any signatures in CertificateVerify. All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures. But now to me it seems that both PKCS1 and SHA1 are allowed to be used in Certificate message only (to provide support for legacy certificates). Considering that, to me it seems preferable if the draft stated that both PKCS1 and SHA1 are obsoleted, and are allowed to be only used in certificates. Or is there any need to handle PKCS1 and SHA1 differently in protocol implementations? Thank you in advance. 2016-10-14 13:38 GMT+09:00 Kazuho Oku : > Hi, > > In TLS 1.3, my understanding is that the digest function negotiated > using the Signature Algorithm should be used for generating > CertificateVerify, since the draft states that: > > | Each SignatureScheme value lists a single signature algorithm that > the client is willing to verify. > | (section 4.2.3) > > | The Hash function and the HKDF hash are the cipher suite hash > algorithm. Hash.length is its output length. > | (section 7.1) > > The draft permits fullbacking back to using SHA1 certificates: > > | TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no > valid certificate chain can be produced without it. > | (section 4.2.3) > > However, the draft also states: > > | SHA-1 MUST NOT be used in any signatures in CertificateVerify. All > SHA-1 signature algorithms in this specification are defined solely > for use in legacy certificates, and are not valid for > CertificateVerify signatures. > | (section 4.4.2) > > So my question is, which signature algorithm am I supposed to use for > a rsa_pkcs1_sha1 certificate? I'd assume that the answer is > rsa_pss_sha256, but I could not find any such indication within the > draft. > > -- > Kazuho Oku -- Kazuho Oku From nobody Thu Oct 13 22:52:01 2016 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 86CE4129465 for ; Thu, 13 Oct 2016 22:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 W4dLYOneaNuO for ; Thu, 13 Oct 2016 22:51:57 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29F7129470 for ; Thu, 13 Oct 2016 22:51:56 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id l131so137429889lfl.2 for ; Thu, 13 Oct 2016 22:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qpSGQp2Cc/oS6158xVADl7b+OfoZ8ubteto9xRTBhAI=; b=JLB7BblqCMw6RdgHXO4JmEKoJnM2V7rGlOhDC0mWUz0dRetxaHUvmUVTXNMPG4bRFR ovfb2634P3PhQGGEBE8ClSJCVBm4Qb8Qed+LjL01BXjy90t/EtE/I5irkTxXFTXRhdwQ IHkx7xzRRM6BJ95KV8jjZ/AfNTqAdStUjHqLnkbU+yZ35mLvb9zJUkGfXIVbVgKgC5d/ l/LynSGF7EWay95yvNDB7qjknYMKIHsRV/fuqnT1AaoKCS/rOtt/PL33c/1FaDA0ztk5 ZjrkYFytrFBD8viFs5sBa39RlRLLPFqDeJo3A0KeRIluvsE9Ka5EKyZWOqp2G4RXohhw +7pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qpSGQp2Cc/oS6158xVADl7b+OfoZ8ubteto9xRTBhAI=; b=Eyp0LIiZaWKNbXTzK1o0zIGEBnyepJ/pYsQXti5xLRYX5cBDwH5FKDlV26rV1twMQz TFhcHFMXqVr5DV3JGCdjj9jdUSF6Oojt52hT4LtblZArGziowXVPUXST+veAhTBgHTjw g2geDMF2/uT+OGM0t+SeAy1hbuY6qFOUG84Ltiw0u2AygGtMVVVxsNkAMZahd7dpy0Ur Vz3NBkCm2OgfZ7Erjp/uwmTt8bPAbTIMZKi6TODRaj0O4a89JjSfXoMW6Zd8W6Ff4Gm6 3IQERi2H8c3oe8hmhQa3VJBOS/g/eJQ0GOIB4RUQbpNKUNvj7jDeGbXd0xpP2g9mg2/E RFYA== X-Gm-Message-State: AA6/9Rl9NeSm5cUW7JPv7zZ/vcT2xML4q8+2snKLPEWXISb+Y882nLjeSR00ByFywE1xf7xcJY/oQ/gtFVZyJw== X-Received: by 10.28.206.3 with SMTP id e3mr4388226wmg.30.1476424314788; Thu, 13 Oct 2016 22:51:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.69 with HTTP; Thu, 13 Oct 2016 22:51:54 -0700 (PDT) In-Reply-To: <20161013203319.GA24052@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161013091803.GA22882@LK-Perkele-V2.elisa-laajakaista.fi> <20161013203319.GA24052@LK-Perkele-V2.elisa-laajakaista.fi> From: Kazuho Oku Date: Fri, 14 Oct 2016 14:51:54 +0900 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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: Fri, 14 Oct 2016 05:51:59 -0000 Hi Ilari, Thank you for trying picotls, and thank you very much for notifying me of the issues you found. I have fixed three issues you reported (i.e. SNI decode error, EC group check error, PKCS not included in Signature Algorithms). Regarding the crash, is your implementation available to public so that I could use it for debugging? Thank you in advance. 2016-10-14 5:33 GMT+09:00 Ilari Liusvaara : > On Thu, Oct 13, 2016 at 12:18:03PM +0300, Ilari Liusvaara wrote: >> On Thu, Oct 13, 2016 at 03:17:32PM +0900, Kazuho Oku wrote: >> > TLDR: the spec. was clear and easy to implement, but some test vectors >> > and clarification on what constitutes a Handshake Context would have >> > helped. >> > >> > FWIW, please let me share my experience of implementing TLS 1.3. >> > >> > This month, I have written a TLS 1.3 implementation (named picotls, >> > available at https://github.com/h2o/picotls) based on draft 16 from >> > scratch. >> >> Tried interop versus my own implementation (with my implementation >> as client). >> >> Didn't work... I traced the blowup to client_hello_decode_server_name(): >> >> The sent contents of the SNI extension is: >> >> 00 0B 00 00 08 "h2o.test" >> >> Which AFAICT is a server name list of 11 bytes, containing entry of >> type 0 (host_name), with length 8 and name "h2o.test". > > Further testing: > > My implementation vs. picotls: > ------------------------------ > > Ok, dumped the handshake using wireshark. Wireshark seems to think > the SNI with two lengths is perfectly sane. > > I modified the picotls code to read the extra length. > > Then I hit another issue: eckey_is_on_group seems to be busted: It > presumably should use == instead of !=, since it is presumably > supposed to return 1 if groups match, since it is used to check > if the key is P-256. > > > Couple of bugs in my code later, I could get successful handshake > with my code as client and picotls as server. Yay. > > > picotls vs my implementation: > ----------------------------- > > Trying picotls as client and my code as server first hit the issue that > picotls doesn't send RSA-PKCS-V1.5 as supported, causing my > implementation to fail with no suitable certificate (it requires > algorithms for the chain too, not just the end key). > > After defeating that check, the handshake got further, but something > in server's messages (ServerHello, EncryptedExtensions, Certificate, > CertificateVerify, Finished) made picotls crash (heap corruption as > evidenced by the malloc() error). Haven't debugged that error yet. > > > > -Ilari -- Kazuho Oku From nobody Fri Oct 14 08:10:13 2016 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 DA00312944F for ; Fri, 14 Oct 2016 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.898 X-Spam-Level: X-Spam-Status: No, score=-9.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 HLkcAEQ9R8yY for ; Fri, 14 Oct 2016 08:10:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314CF129447 for ; Fri, 14 Oct 2016 08:10:10 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE9B23D95D; Fri, 14 Oct 2016 15:10:09 +0000 (UTC) Received: from pintsize.usersys.redhat.com (vpn1-7-10.ams2.redhat.com [10.36.7.10]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EFA7pe028194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2016 11:10:09 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 14 Oct 2016 17:10:01 +0200 Message-ID: <3337583.uaYQkpt7di@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.6-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) In-Reply-To: <20161013203319.GA24052@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161013091803.GA22882@LK-Perkele-V2.elisa-laajakaista.fi> <20161013203319.GA24052@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1595732.70UYj9tv1Z"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 14 Oct 2016 15:10:09 +0000 (UTC) Archived-At: Subject: Re: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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: Fri, 14 Oct 2016 15:10:12 -0000 --nextPart1595732.70UYj9tv1Z Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 13 October 2016 23:33:19 CEST Ilari Liusvaara wrote: > Ok, dumped the handshake using wireshark. Wireshark seems to think > the SNI with two lengths is perfectly sane. that's because wireshark doesn't perform length checks on many fields of TLS There are both valid messages rejected by wireshark (fragmented over multip= le=20 records) and invalid messages accepted by wireshark. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1595732.70UYj9tv1Z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYAPVJAAoJEJKo0bgB0vX1Mn4QAISoOgI9bu04QWOlnsHVqNvC i97RIGrFC/ayPOOfmciM6yM4N9aWh9QXzOlEQwHzG4PnHWZaU3gAeyrLWBuwvAMe jm3zEm7sMhz5qsQU8JmyArZPXuQei7GbFVbO+8SUh0jBcJo2s5wdrvijdOwvfqfG 98jUdmBovwd/12WlDRI4sgXW42IRunLWydMLrC8QC5chbUwsmw3dAHL1VdQWVJCz o7HdWDZQguLPgsO41Tjshd1h/OEy07h3lBEkcBTdR3da+EMDICD+9NzVdEW+jCCS /CUK8NWIVdxzvzltpsvAjZJ9/vY1lufUM3eEoTRgzl2YtcBxVHYwzCu2zgyQfuoq C2kb5Q3hDQezN/asDJTR94Gc4iPwEnbCCLm7XjlzHvuNE1+hN00STJWEagruBzc8 hSRa2eRS377/ExFEoxI22aXmC6Y02KMkiY3V7S+xufUt/hx51Udq5SNhAsYzrs42 iPQK8GlFdnqD4ToR9ADeobnpnke95sHKsC/RP1A/L7nNUe3ddGG7O4bSGhONSgsm wnfPdTjjsz9W6ij8HA6DawhZxrgw++xIUH5Kct/9DDX7otMZOVkx3Byf4dPoTnD9 zu74Z1hIUMpIRShNGkj4OPPy21AB5HvHYCtrUTIqg5i34pwh4o4K0SHFdJlYUVtJ 97txU9JmNDH1ocLLJfIZ =3MYn -----END PGP SIGNATURE----- --nextPart1595732.70UYj9tv1Z-- From nobody Fri Oct 14 08:15:53 2016 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 AAE4B12944F for ; Fri, 14 Oct 2016 08:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.898 X-Spam-Level: X-Spam-Status: No, score=-9.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 OA66etChg-Vl for ; Fri, 14 Oct 2016 08:15:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEF6129506 for ; Fri, 14 Oct 2016 08:15:51 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 053FA90E5C; Fri, 14 Oct 2016 15:15:51 +0000 (UTC) Received: from pintsize.usersys.redhat.com (vpn1-7-10.ams2.redhat.com [10.36.7.10]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EFFnkF015282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2016 11:15:50 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 14 Oct 2016 17:15:48 +0200 Message-ID: <3256832.cYMDsURMPZ@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.6-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1900046.KX5UqCWqXN"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 14 Oct 2016 15:15:51 +0000 (UTC) Archived-At: Subject: Re: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate? 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: Fri, 14 Oct 2016 15:15:53 -0000 --nextPart1900046.KX5UqCWqXN Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 14 October 2016 14:34:49 CEST Kazuho Oku wrote: > Considering that, to me it seems preferable if the draft stated that > both PKCS1 and SHA1 are obsoleted, and are allowed to be only used in > certificates. Or is there any need to handle PKCS1 and SHA1 > differently in protocol implementations? there isn't, the only case is when you also implement TLSv1.2 Pure TLSv1.3 implementation shouldn't ever generate messages or try to veri= fy=20 messages signed with SHA-1 (or MD5 for that matter) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1900046.KX5UqCWqXN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYAPakAAoJEJKo0bgB0vX1cQ4P/2U7gGfYo812fukA8Sfjrj2U WIMWg4/7svcbng3MGJzVHL1emnnFqimH7Z+9YaqHsJ4r2wX5TCOvPprAtibsd1Bm Ud7guu9LMGKNE4mS6gNK+vMr3FAj3ghtUhb/QYkNupi4fnbqcIKrW/ZrCc53Zfpq 3Wq1gZTssS9lbVrCS1ssQfizS+fR6QzN1i2FjkuNZ/lyGuRicZ0d1efqymmtkPHw p21dN9S59EPjmhp6qnCgPT+mbIUnTUUCv9xk65J+imvrjigO5oR9j8BUclgED2tF RernwbU61p6wZ+HugWs0R2l9udpOdQ2V8EbNzLJqSJNpl5aT+6Nl1ZjqmzDKkXcN /t+jmkdDp5D6TBl/NsUXMG1IBHk3I2tuGmmvUUVszU4pMYjvNisnyVdRP/ePvX1r aMerAzI0zus//mKiAT2HVUtSBfOOYTAPhHqw+jwRVNrxLA4AwpbwRfU8zt9+5Ze/ Vh50bXCWwgaceLIeqSI1T8P3kdGGluhxD0AA1FAPtmDWtQAphRmpmu/2K13Y0Zxl nOPIiIXr/JiXgvY8Q+wjuHfgYNZ3tiehscc7oekQNKoSjjMtGPEavtW8HHLaY3YY YRH4shN1qBcug80hx3Sbd9BC2mFPZ9EnSYhbrk3h06BcPDKqzaDoV7plQeUAetWl cO9fe6AtnxrHlswb7ryP =bam2 -----END PGP SIGNATURE----- --nextPart1900046.KX5UqCWqXN-- From nobody Fri Oct 14 08:42:24 2016 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 4D55C1294A1 for ; Fri, 14 Oct 2016 08:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 0PlPvzw8YRJP for ; Fri, 14 Oct 2016 08:42:07 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id EE09B12944D for ; Fri, 14 Oct 2016 08:42:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id DEA1E16C54; Fri, 14 Oct 2016 18:42:05 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id yYM1BucLpILA; Fri, 14 Oct 2016 18:42:05 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 9B3CF28A; Fri, 14 Oct 2016 18:42:05 +0300 (EEST) Date: Fri, 14 Oct 2016 18:41:58 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20161014154158.GA26004@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161013091803.GA22882@LK-Perkele-V2.elisa-laajakaista.fi> <20161013203319.GA24052@LK-Perkele-V2.elisa-laajakaista.fi> <3337583.uaYQkpt7di@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3337583.uaYQkpt7di@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?Newcomer=E2=80=99s_Implementation_Experience_of_T?= =?utf-8?q?LS_1=2E3_Draft_16?= 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: Fri, 14 Oct 2016 15:42:23 -0000 On Fri, Oct 14, 2016 at 05:10:01PM +0200, Hubert Kario wrote: > On Thursday, 13 October 2016 23:33:19 CEST Ilari Liusvaara wrote: > > Ok, dumped the handshake using wireshark. Wireshark seems to think > > the SNI with two lengths is perfectly sane. > > that's because wireshark doesn't perform length checks on many fields of TLS > > There are both valid messages rejected by wireshark (fragmented over multiple > records) and invalid messages accepted by wireshark. Actually, AFAICT, the message was encoded like it should (one length from the outer list length and one from the name length, as specified by the TLS standard). -Ilari From nobody Fri Oct 14 08:43:38 2016 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 9DAC3129845 for ; Fri, 14 Oct 2016 08:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 5THyIORpYauT for ; Fri, 14 Oct 2016 08:43:35 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5B12944D for ; Fri, 14 Oct 2016 08:43:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8DEDF16C42; Fri, 14 Oct 2016 18:43:34 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id DoFHUwM_KvzT; Fri, 14 Oct 2016 18:43:34 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 48AB2C4; Fri, 14 Oct 2016 18:43:34 +0300 (EEST) Date: Fri, 14 Oct 2016 18:43:27 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20161014154327.GB26004@LK-Perkele-V2.elisa-laajakaista.fi> References: <3256832.cYMDsURMPZ@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3256832.cYMDsURMPZ@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate? 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: Fri, 14 Oct 2016 15:43:36 -0000 On Fri, Oct 14, 2016 at 05:15:48PM +0200, Hubert Kario wrote: > On Friday, 14 October 2016 14:34:49 CEST Kazuho Oku wrote: > > Considering that, to me it seems preferable if the draft stated that > > both PKCS1 and SHA1 are obsoleted, and are allowed to be only used in > > certificates. Or is there any need to handle PKCS1 and SHA1 > > differently in protocol implementations? > > there isn't, the only case is when you also implement TLSv1.2 > > Pure TLSv1.3 implementation shouldn't ever generate messages or try to verify > messages signed with SHA-1 (or MD5 for that matter) Unfortunately while one sees less and less use of SHA-1 as certificates expire, there still is use of SHA-1 in OCSP. The only place where my TLS library uses SHA-1 is with OCSP. -Ilari From nobody Fri Oct 14 14:07:40 2016 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 7AF50129428 for ; Fri, 14 Oct 2016 14:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=mKw23ssb; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=H6YNWNvf 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 eG6Upsc7IMPX for ; Fri, 14 Oct 2016 14:07:36 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 C3963129640 for ; Fri, 14 Oct 2016 14:07:36 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.17/8.16.0.17) with SMTP id u9EL3phD027546 for ; Fri, 14 Oct 2016 14:07:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=yjVOFw8ST1xw6a3ysTVY2PcwOjEJNFKoR/pspOV2s8E=; b=mKw23ssbmWT3r187hOkYaXyYtyUwTfCMKpJ9qFj44y46pvZWP/msVb7NJydDbfisenSE YxQb04sOisJjQI+3g17Uh77UxZe3HgPYvgsLNqQ57oF4NtXVbh/FOTQx+GiGoCu/ldnr KUP3ZQIAcJsuqIN3gEAuM9Qld61KX2GlDj0= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 261sv7mnx7-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 Oct 2016 14:07:33 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.22) with Microsoft SMTP Server (TLS) id 14.3.294.0; Fri, 14 Oct 2016 14:07:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XIJAnPu/5mhWvSeOEuHVS6DtESZnteySnoRyhoybMgc=; b=H6YNWNvfp/Wh+sc0rkWuYbhx4T11T1Eb+N2TljoJ4F6XYtH0Na/CCW0vHdnHrXS8gCI8SSMGtYkGSBZPzerOR15IY+dbusWCDYWRhWB+DQ+mZQCyzIk/NehMoLPuXfp1LHceJrBx/l6RGmLiLdAuA4ATHgrBQDQMGfD30FbOLXc= Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1183.namprd15.prod.outlook.com (10.175.2.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Fri, 14 Oct 2016 21:07:31 +0000 Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0659.020; Fri, 14 Oct 2016 21:07:30 +0000 From: Kyle Nekritz To: "tls@ietf.org" Thread-Topic: Deprecating alert levels Thread-Index: AdImXnNSskDkr/RBRyKiMCb2wmhMDw== Date: Fri, 14 Oct 2016 21:07:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c091:200::6:5622] x-ms-office365-filtering-correlation-id: d5bfeaf0-3353-4b00-499c-08d3f4761c6f x-microsoft-exchange-diagnostics: 1; MWHPR15MB1183; 20:zlOhM5q7utXvk+QhLUXLSciHt7VaRKs3Bu5XiRvj8/byVMBvfUpFsL3vRHFGBg1e+NSixCKN19+HfQwJ+EsCgXjG55JP0syAwp1/X6EuBUIav48po0Mqu3WA4Oywmgomx4NYTpKk3/+8vMVMGoNmv38/0tH/EHzef6wrj6QO+Fk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1183; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:MWHPR15MB1183; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1183; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(189998001)(15975445007)(15650500001)(33656002)(50986999)(19300405004)(450100001)(110136003)(54356999)(7110500001)(7696004)(19580395003)(105586002)(2501003)(8676002)(86362001)(1730700003)(5640700001)(81156014)(76576001)(10400500002)(99286002)(122556002)(101416001)(107886002)(81166006)(2420400007)(5002640100001)(97736004)(3280700002)(92566002)(7736002)(2906002)(8936002)(9686002)(74316002)(68736007)(10710500007)(6116002)(106356001)(19625215002)(7846002)(3480700004)(77096005)(5660300001)(229853001)(87936001)(2351001)(2900100001)(7116003)(5630700001)(6916009)(16236675004)(586003)(102836003)(790700001)(3660700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1183; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182C9D7ED8BA11F0EAEFCE8AFDF0MWHPR15MB1182namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2016 21:07:30.6232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1183 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-14_10:, , signatures=0 Archived-At: Subject: [TLS] Deprecating alert levels 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: Fri, 14 Oct 2016 21:07:38 -0000 --_000_MWHPR15MB1182C9D7ED8BA11F0EAEFCE8AFDF0MWHPR15MB1182namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After PR #625 all alerts are required to be sent with fatal AlertLevel exce= pt for close_notify, end_of_early_data, and user_canceled. Since those thre= e alerts all have separate specified behavior, the AlertLevel field is not = serving much purpose, other than providing potential for misuse. We (Facebo= ok) currently receive a number of alerts at incorrect levels from clients (= internal_error warning alerts, etc.). I propose deprecating this field to s= implify implementations and require that any misuse be ignored. PR: https://github.com/tlswg/tls13-spec/pull/693 Kyle --_000_MWHPR15MB1182C9D7ED8BA11F0EAEFCE8AFDF0MWHPR15MB1182namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After PR #625 all alerts are required to be sent wit= h fatal AlertLevel except for close_notify, end_of_early_data, and user_can= celed. Since those three alerts all have separate specified behavior, the A= lertLevel field is not serving much purpose, other than providing potential for misuse. We (Facebook) currentl= y receive a number of alerts at incorrect levels from clients (internal_err= or warning alerts, etc.). I propose deprecating this field to simplify impl= ementations and require that any misuse be ignored.

 

PR: https://github.com/tlswg/tls13-spec/pull/693

 

Kyle

--_000_MWHPR15MB1182C9D7ED8BA11F0EAEFCE8AFDF0MWHPR15MB1182namp_-- From nobody Fri Oct 14 17:50:05 2016 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 0E201129537 for ; Fri, 14 Oct 2016 17:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wYPRHtFWEs3M for ; Fri, 14 Oct 2016 17:50:02 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F301293EC for ; Fri, 14 Oct 2016 17:50:02 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id f128so161699922qkb.1 for ; Fri, 14 Oct 2016 17:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y74UHMrURRzfkRiHBe+T07XBJ4Xp0A+yUi96SEkeVPU=; b=dpCderFQWzFlNbzbpWAqp1jJuNOMGTi3fRWAF58R4zKgI10nbetw+NsRi8lQZGMgt4 S0+jVafXfx5lvKlj+kpsFFMbZT0szuRk/iAxjbl1qvkgB1+/Lw76/9C9d+msTNJPyPRf daDTuw2TuqyT6TgP1qR6z0pfqya0jggC3aAQ9VW/+61fi5Hb0i5hjQseIrrJibHA+TND U6Sm2ooAzBTeDAjCASZjAEfwnzke4L3B7UavK/SsntydV2LLjw6qVEEYbp4UH183Doqh QVgE+sxTHslcLDXaohfRofHS+GNH5i5iFQNcTtOU0vDWSlZdRvDRajoEkw9V5DGg+RpP FJqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y74UHMrURRzfkRiHBe+T07XBJ4Xp0A+yUi96SEkeVPU=; b=So9C/bNETqzZLHJ81U5hBu2S5IBZ7icf2ukWdD+eMHEtOBPG52jkCv7X1evM7AQmKN befaZsLkZ+OrPho/E0efcr69VGRocch73+mWiVaEvuYHJqwdaXUFX3GV0Kx8q59s1IFD u530u0KgTkx+AT5WD/mrTkMpER/ayUyLDzPYacxttwzaE7DqNqsknAjLAOckc9xb/RaP 9x1EujbeJ2pqVhjtCvtDn8DDuye/3DMaXZdtR3zc/y6xTNGdn1eWE/Of7GNQwrrBGDKg 7W5oxoNTHxLR0u5V++Dd9eUdf+vXG22rGp+wQ/mqHhP37BZgK+XCX2n6QWicNAghQGoJ aMhg== X-Gm-Message-State: AA6/9Rmq3XELwAENn5adT0bw+OkRztJGBol+uXmjrpptln7CO/i8KkG+dpXTK/n6c9/2qst/QAmkxxWi4vtcLg== X-Received: by 10.55.136.5 with SMTP id k5mr13811611qkd.67.1476492601260; Fri, 14 Oct 2016 17:50:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.87 with HTTP; Fri, 14 Oct 2016 17:50:00 -0700 (PDT) In-Reply-To: References: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> From: Watson Ladd Date: Fri, 14 Oct 2016 17:50:00 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application layer interactions and API guidance 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: Sat, 15 Oct 2016 00:50:04 -0000 On Mon, Oct 10, 2016 at 11:27 PM, Martin Thomson wrote: > On 11 October 2016 at 07:57, Kyle Rose wrote: >> FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin >> that the web is substantially broken without retry logic in the browsers, >> that naturally make application-level replay mitigation a necessity. But I >> don't think (nor do I think he claimed) that the same is true of all >> protocols or systems that might use TLS. So while 0-RTT-obliviousness may be >> okay for browsers in particular given the other constraints under which they >> operate, it is probably not good to bake that into the API for the general >> case. > > The 0-RTT API in NSS allows a server to detect this transition. The > problem that I think David was referring to is that the specific > instant of the transition is lost when the multiple layers of stack > that sit on top of TLS get involved. > > If an HTTP client sends a request that relies on HPACK state that was > established during 0-RTT, is it a 0-RTT request? I'm going to go with > probably not. > > If an HTTP client sends the first octets of a message in 0-RTT but > completes the request after the handshake completes, is it 0-RTT? I > suspect that this again is not a concern. > > I agree that we should make it clear that 0-RTT data needs to be > treated specially. I would like to see someone propose some text > rather than read more vague emails on the subject. See https://github.com/tlswg/tls13-spec/pull/694. This is for API guidance rather than applications, and definitely needs expansion. I don't think we can say anything about HTTP without more details. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Oct 16 02:54:23 2016 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 492D412969C for ; Sun, 16 Oct 2016 02:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cwY1EnAFQCQV for ; Sun, 16 Oct 2016 02:54:19 -0700 (PDT) Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C50812969B for ; Sun, 16 Oct 2016 02:54:19 -0700 (PDT) Received: by mail-qt0-f175.google.com with SMTP id q7so99449223qtq.1 for ; Sun, 16 Oct 2016 02:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eP0wprWUAZ8bsTpQ9rRqB7+m2+NoFWWNxSevChczzTw=; b=ar9dDnk9bF+15lCIlrqNWBZO9kKT2qyqDw6iIa2W8BXwHydej+kn+4LLWuxMHpy4jq dR4PwFvvy3EcrEviAcRr2F9oY8DVKCKVH0eH7GNbV0FjqJmEtC1Fwovq9XGYbRN3EMgO UzqjPtuFy9XhOJ8ax4Cq3hUo5Tmawp20TVOg0X3OmFa6Lp/FCaM5aWRjTga0XafPRYVo Am0uHjDqUMSjg+vw0r7kv9RUGPST46aD6jUmlwUrSwocdGR3YZ18sSH0q064RYyRiarN OqEZmnD/VvT3o6TID1wSE28qFMKJpc742eSDFa9hnjfpXNB6gloePmn0s6u2N71i9MhQ BMcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eP0wprWUAZ8bsTpQ9rRqB7+m2+NoFWWNxSevChczzTw=; b=DkG8BXZ3i5l0PX3it8Z3BPruneAdoG5czftteyZdD5JSrZKjc+kc1BCZygajA/iMAK uY5DPaQ93Ky23Wp8/XoSiwMjNnric5kuW8bn5+o8y1BwSfv8gUMTjGewsdtS27bpjxxu 9oeeojT9BsHQ3xlgLeE3/xVaIEz8rZVgPS0ccrQWDcpqjMtU3jAZlxsq+zcHsltN2Gmn wT2d9XlTzsVPEnZbOvfakaABDz25cm4g78nCYWD9WdbRzFvmHMXP7N0RWLXJw/aOd06Z p6tNiGlfN4qkpsWWdtCy6DhPY81RchfXAHNtHKsE0quiBveK3v+6n9iqH8LsLuIx20TU Gv7w== X-Gm-Message-State: AA6/9RmaLHs3duOomg/b6mUPj5attXf8KJ+t5H2h9DTxtt67JqhIjPW7h9DFpHXaoog1XNjoHlcETMoPDCepqw== X-Received: by 10.237.59.123 with SMTP id q56mr20993655qte.116.1476611598693; Sun, 16 Oct 2016 02:53:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 16 Oct 2016 02:53:18 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sun, 16 Oct 2016 20:53:18 +1100 Message-ID: To: Kyle Nekritz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating alert levels 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: Sun, 16 Oct 2016 09:54:21 -0000 I'm sympathetic to this, but just to be clear... You are suggesting that end_of_early_data and close_notify will be marked "fatal". WFM. On 15 October 2016 at 08:07, Kyle Nekritz wrote: > After PR #625 all alerts are required to be sent with fatal AlertLevel > except for close_notify, end_of_early_data, and user_canceled. Since those > three alerts all have separate specified behavior, the AlertLevel field is > not serving much purpose, other than providing potential for misuse. We > (Facebook) currently receive a number of alerts at incorrect levels from > clients (internal_error warning alerts, etc.). I propose deprecating this > field to simplify implementations and require that any misuse be ignored. > > > > PR: https://github.com/tlswg/tls13-spec/pull/693 > > > > Kyle > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun Oct 16 13:41:27 2016 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 06B9F1294AA for ; Sun, 16 Oct 2016 13:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 CFa7HzrVGojc for ; Sun, 16 Oct 2016 13:41:21 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F77512947C for ; Sun, 16 Oct 2016 13:41:21 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t192so104548884ywf.0 for ; Sun, 16 Oct 2016 13:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1pBIBvw2ZwBADUq+B18fZ4Utz5N8QyzmRmy8clsBDK8=; b=Rp5AmXAgr3zj/Qn5F43wRClnOo3n2r+09qtbV9FqNp3gupx3T1AdtaVOa7Umeoibvd 6HdM1HBuAZ1yaxg8Sy0LdzKa5ePHMlkBs1oRe0y6+aK4ilfXoSMEu9P2ALsmD+igeX5E TAhEiNUc4E4j97zastGMDsU2wzh+3l9Ey8hym6036HOES9TP7TWo77PiOQ7HWR1JR3HA evBomKx4PhBUEjPla62EEmWLkIhcSO93SLMkiQmSDH9Gax1daWfRuuoS1usqUHIpa4B4 Nal0E//4rqWOd+bX4EuKoOdvtjVpz8I48ICQAEUfXjY1ocX7ZN7LI5BKxGCtEVVeb8Ql M7vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1pBIBvw2ZwBADUq+B18fZ4Utz5N8QyzmRmy8clsBDK8=; b=ENJIZnnpUk5D3pU0sMTkLiZyrqfgE64PeFB3jFx3oCj928DReeVdmaatqNKonXpB5Y M13RMuH6JDn8UTA8jPQQ6WvKNwfwzyTjoEaxW6bqcbpl0iMNvFq5SptsxWgDR8z2q5PT 1BWRhBE1LqHZN2lUDnYcU5cok3brdNeL8Psn27/1wVm/FjBNU0uw6q63P6bEySiuBFB6 o82dZqT3BQHuhAIAQQtp/Npsj/481+mDMLKDQOSX3HRkMxaS21d+qoKT/Z3tyBpYzgk6 0O1CPG1L0hO9Bz5TawWALvqIzgQUvrOlmhqs1iBH5Ch0iGOL86/9DvkvP3ycunT+USDH bVRQ== X-Gm-Message-State: AA6/9Rks99IFqLEgleh2+U/cWEWPD75guMz+/hH05D8+aQASnyGi02P6f9RIsgqF3RkjV/359DEXu7rt2n3aWA== X-Received: by 10.129.81.21 with SMTP id f21mr20439896ywb.149.1476650480902; Sun, 16 Oct 2016 13:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Sun, 16 Oct 2016 13:40:40 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 16 Oct 2016 13:40:40 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114611045fac77053f017b80 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating alert levels 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: Sun, 16 Oct 2016 20:41:27 -0000 --001a114611045fac77053f017b80 Content-Type: text/plain; charset=UTF-8 This seems like a good change. I'll merge this on Monday (pre draft-17) unless I hear objections On Sun, Oct 16, 2016 at 2:53 AM, Martin Thomson wrote: > I'm sympathetic to this, but just to be clear... > > You are suggesting that end_of_early_data and close_notify will be > marked "fatal". > > WFM. > > On 15 October 2016 at 08:07, Kyle Nekritz wrote: > > After PR #625 all alerts are required to be sent with fatal AlertLevel > > except for close_notify, end_of_early_data, and user_canceled. Since > those > > three alerts all have separate specified behavior, the AlertLevel field > is > > not serving much purpose, other than providing potential for misuse. We > > (Facebook) currently receive a number of alerts at incorrect levels from > > clients (internal_error warning alerts, etc.). I propose deprecating this > > field to simplify implementations and require that any misuse be ignored. > > > > > > > > PR: https://github.com/tlswg/tls13-spec/pull/693 > > > > > > > > Kyle > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114611045fac77053f017b80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems like a good change. I'll merge this on Mond= ay (pre draft-17) unless I hear objections
=
On Sun, Oct 16, 2016 at 2:53 AM, Martin Thom= son <martin.thomson@gmail.com> wrote:
I'm sympathetic to this, but just to be clear...

You are suggesting that end_of_early_data and close_notify will be
marked "fatal".

WFM.

On 15 October 2016 at 08:07, Kyle Nekritz <knekritz@fb.com> wrote:
> After PR #625 all alerts are required to be sent with fatal AlertLevel=
> except for close_notify, end_of_early_data, and user_canceled. Since t= hose
> three alerts all have separate specified behavior, the AlertLevel fiel= d is
> not serving much purpose, other than providing potential for misuse. W= e
> (Facebook) currently receive a number of alerts at incorrect levels fr= om
> clients (internal_error warning alerts, etc.). I propose deprecating t= his
> field to simplify implementations and require that any misuse be ignor= ed.
>
>
>
> PR: https://github.com/tlswg/tls13-spec/pull/6= 93
>
>
>
> Kyle
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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

--001a114611045fac77053f017b80-- From nobody Sun Oct 16 18:03:44 2016 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 2571A12953A for ; Sun, 16 Oct 2016 18:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Nvr18WVWV1CU for ; Sun, 16 Oct 2016 18:03:42 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893D0126B6D for ; Sun, 16 Oct 2016 18:03:41 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w3so105826215ywg.1 for ; Sun, 16 Oct 2016 18:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OBKVInK/jCaCX+boxwzIfy6FncY2WE+o3SMCmR0iQbQ=; b=Rf5XIxxQ6tIjEuRVARkuFRhrT3KI8wpCZLitGBWNLoZhwa+JdTP95OA3uaszpCZ6zf 5pejzZZRsXn72jNBav6lEZ47LKqywlzcJcvmI0gkdAwprWINs7XXaiy3G+VVcdDkemiT R0zm3xalOkYtj9BzZPFy9vUNyzTPf53BBqG4uUIkgx6zT0+F8ZRqKEwqjfSLDGVrNmPn f1SYmErlsBkezArYjDI4yvflqn92uOeL36Joxkepa16LIj5OvXfS7dOkyIUgTIOXDFCy /iP6vKinuqmRCuYvcWcnSfS+wP4nrH9ex8x2ot4ON0kKultP4S0aYaiCjSkp4UjJdK04 AmQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OBKVInK/jCaCX+boxwzIfy6FncY2WE+o3SMCmR0iQbQ=; b=AFuzRmM8FZ3DOyEa5/04qtP3O4V8QPsREXH+yLj4GcXopCIt6sLcgWsEpIFfLHX+oL 9Dx1HyQXQE+/W3yuZRImOLlr26BpNmCpOmr4OgM+CJL3lpJ+JRIHXkMI9uqRXb41HUVg JRXPuVKo4PVS6ddej7TwO4yX1NhHzpWscH65D4S60tQsJajf9NOxZQG7TB5kMHMf58Jd b19w83exHJ8sgXzWjlDDrvSGORF6xhHq8FVgF6zt5AA9k4+LTAyhDxfhJSgh4hC8vv1S MpCkZxpnTTXxvUe4IBb4DFyOK0Ub5XKqcR7K/AtDjOKnN+C4vn+pboCbGMabxOt4GEP1 tg/Q== X-Gm-Message-State: AA6/9RmeLI4nSID3WZTIguRreyjH9BtZ3zoC5Lf3yQ2azaDs+NdM9epzsDT14yqq7MENPSCGasNGqpi5vlFFjw== X-Received: by 10.129.121.206 with SMTP id u197mr21040552ywc.146.1476666220884; Sun, 16 Oct 2016 18:03:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Sun, 16 Oct 2016 18:03:00 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 16 Oct 2016 18:03:00 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0b0f688c6e67053f0525fd Archived-At: Cc: "" Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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: Mon, 17 Oct 2016 01:03:43 -0000 --94eb2c0b0f688c6e67053f0525fd Content-Type: text/plain; charset=UTF-8 Chairs: Can you advise on the disposition of this? -Ekr On Wed, Oct 12, 2016 at 6:10 PM, Martin Thomson wrote: > On 13 October 2016 at 12:07, Eric Rescorla wrote: > > I assume you would prefer hex, i.e., 0x0303? > > Yeah, that would be nice: it's recognizably the same as the old one that > way. > --94eb2c0b0f688c6e67053f0525fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chairs: Can you advise on the disposition of this?
-Ekr


<= div class=3D"gmail_quote">On Wed, Oct 12, 2016 at 6:10 PM, Martin Thomson <= span dir=3D"ltr"><martin.thomson@gmail.com> wrote:
On 13 October 2016 at 12:07, Eric Rescorla &= lt;ekr@rtfm.com> wrote:
> I assume you would prefer hex, i.e., 0x0303?

Yeah, that would be nice: it's recognizably the same as the old = one that way.

--94eb2c0b0f688c6e67053f0525fd-- From nobody Mon Oct 17 04:20:05 2016 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 323C312953E for ; Mon, 17 Oct 2016 04:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.333 X-Spam-Level: X-Spam-Status: No, score=-7.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mY7I95P1z4Iu for ; Mon, 17 Oct 2016 04:20:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB84129407 for ; Mon, 17 Oct 2016 04:20:02 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 52E7931B308; Mon, 17 Oct 2016 11:20:02 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HBK02u009061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2016 07:20:02 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 17 Oct 2016 13:20:00 +0200 Message-ID: <7351210.yvrLMuiDzx@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.6-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2348401.yz1MI19P2Q"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 17 Oct 2016 11:20:02 +0000 (UTC) Archived-At: Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 11:20:04 -0000 --nextPart2348401.yz1MI19P2Q Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz wrote: > After PR #625 all alerts are required to be sent with fatal AlertLevel > except for close_notify, end_of_early_data, and user_canceled. Since those > three alerts all have separate specified behavior, the AlertLevel field is > not serving much purpose, other than providing potential for misuse. We > (Facebook) currently receive a number of alerts at incorrect levels from > clients (internal_error warning alerts, etc.). could you expand on why it's a problem? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2348401.yz1MI19P2Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYBLPgAAoJEJKo0bgB0vX1Qw4P/jZs188gERx3eqek+iU9HrRM ho6oPfBJza52KI7tHlCq2CQUcnMsFDx5TTrXVUwoL/M8DFLfsEEM/ksSGd4vT4DU szzOi9LhagkWyaMKRbcOeiLoYBldI/Cd8EX3BD1l+/ZgyrYj0PXAwgtHc0shIIy5 YL5SCJbrHF1dx0u4RAJHLf5C3hbKEa6Kbj3IZcvMMojwMZF48SNrlpGrfrWOhm6J Z8aHTInUMCPnL5T+LdmWGFxNFzmaCeo3WSr9JKvRUJTCH9qBaPZsRouG2FC2OZTg 5Tfuwt4UFKwldKiDKVM6owNfnhO7FYXTl5Tx1RrayF4bGA2YRIbsTkbD2X+2It5I 3BXlZCgWJGZFfu0xTIPlH97VLaQMnHDate7PEihy0uz+6n9y7nY9WqKmAtZdBXFa yPdQtqOK8m+UzrVANOut6Bk4id4q06b0X0Fn+5KzJroxMzjuLZTOQBmGpMxMJuyq JtXkE+DzIo9GpKJsjdr81A5PruxSE+6rCAv6XfWZFz1Hn7dDQ8rL1gf2Nwo88I+a mQ7dXtjlWigEhh5iInNdOp9JD6NuNT+0UtBamnobfqE353ULdjLWltSRsuHs6Rf+ OS7TbUyu8lXO40xKZuQ75EKRJMPjdz5ubFyZ8kKhUkjviZDrAs1Xxbw+wm1R1dVg ECF27hFJy2pP9kEEBpWp =+NMV -----END PGP SIGNATURE----- --nextPart2348401.yz1MI19P2Q-- From nobody Mon Oct 17 09:04:03 2016 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 1E90A1294E6 for ; Mon, 17 Oct 2016 09:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 A_LQttYvkfjc for ; Mon, 17 Oct 2016 09:03:59 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0D512945A for ; Mon, 17 Oct 2016 09:03:59 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id q192so193221026iod.0 for ; Mon, 17 Oct 2016 09:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UgRtAid4yVQWL9Hihndx0Ky9N7h9nFwG/NCFnslciCI=; b=PaUkcp516rhnw1B4RsNeSN9hchHIxADTZ+AJsoZJfv2XoxlDnrCeM8aW3vO0whlpUc RiRPs5f/TDcl7/Jr/tzdrYkFhVUjkj9lG/1pSNLgmn0m65XGLbWPN9fkbeenrMSm7Bpw +qmsL9Ned79zeSGDOEpFRQ4csWLTzmb25S/ogwwKetTJWeMq0uzKrrK42JiddbNNP9qA F4zarP2KjDaDkhYVIpKafXtEutEGAKIQmlLHtqEg28jtN9RMdxS16PBLQK/57WqyI9/U B/sgnwgyWFjC5r0xsPhh0u5Bz4CgTXTGiSpJhFc82jAxIKnSRJxexqF01HvzXZSlyMW0 RXnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UgRtAid4yVQWL9Hihndx0Ky9N7h9nFwG/NCFnslciCI=; b=BRRsMQMk8smS9rgHuFHbf7YAMMHjrV454Uy2oJUs2/HctWj/LxQWupy6bIu6QAilsU u3iOT0rzpUrpbv+FFQdN0gBBVRggx/J2WKpWh+X+7F+W/QH7EklyvIFVQcKS6lvMdweR WbroDDLQmwL9fnNqG1iNQAHscJAYvUaP1EtWCB6KgdqrdaS5r62LkB+pBoEPP5VkZHRL MtJYu6ybVtqpUe6GrSdEkQegP8iTQU2Nx4+2lNnqrM2jmrmoLbAY57pUPURDfenuf5ve rcBaKXevjnB97900zPJ08c5eDWBgI2py9dyZmsVq/bBpQGSPCiHWUYg2GG1u/mZPY7VL G91w== X-Gm-Message-State: AA6/9RkBxwZtE2w33iaGOVYkCTuPIojDTpDDQFeQ2gt/ykqn93LyQQvP9Apjcmg6c2RT47oSqjqjqWE6uugRSQ== X-Received: by 10.107.28.148 with SMTP id c142mr22588163ioc.45.1476720239089; Mon, 17 Oct 2016 09:03:59 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 17 Oct 2016 09:03:58 -0700 (PDT) In-Reply-To: References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> From: Daniel Migault Date: Mon, 17 Oct 2016 12:03:58 -0400 X-Google-Sender-Auth: OK1UrfZHl7Yvn_9a0Qnzz7pqC2M Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113fd4b8489c16053f11b94a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead 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: Mon, 17 Oct 2016 16:04:02 -0000 --001a113fd4b8489c16053f11b94a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am not clear what the consensus is for the following points. Is there any consensus for requesting the following ones? BR, Daniel TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x01}; TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x02}; TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}; TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}; TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x05}; TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x06}; On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson wrote: > I'm mainly just looking to economize on different configurations. > > On 9 October 2016 at 16:32, John Mattsson > wrote: > > Hi Martin, > > > > > > AES_256_CCM_8 was not in the first versions of the draft but added late= r > > after request from IoT people (probably afraid of quantum computers). > > > > > > While I think it makes very much sense to have short tags in wireless > > radio, I do not know how large need there is for AES-256 in IoT for > > constrained devices, or how large the need would be to truncate the tag > in > > these cases. > > > > > > My current understanding is that Grover=E2=80=99s algorithm may never b= e more > > cost-effective than a cluster of classical computers, and that quantum > > computers therefore likely do not affect the lifetime of AES-128. > > > > > > I do not have any strong opinions regarding keeping AES_256_CCM_8 or no= t. > > We should not give the impression that AES-256 is needed for practical > > resistance to quantum computers anytime soon, it is however a requireme= nt > > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seem= s > > like the best choices in most cases. > > > > > > Cheers, > > John > > > > > > > > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" < > tls-bounces@ietf.org > > on behalf of martin.thomson@gmail.com> wrote: > > > >>Looking at those emails, I am prompted to wonder if anyone can justify > >>the existence of a ciphersuite with a double-sized key and half-sized > >>authentication tag. RFC 6655 doesn't really explain how that is a > >>useful thing. > >> > >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos > >>wrote: > >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: > >>>> All, > >>>> > >>>> We've received a request for early IANA assignments for the 6 cipher > >>>> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecd= h > >>>> e-psk-aead/. Please respond before August 23rd if you have concerns > >>>> about early code point assignment for these cipher suites. > >>> > >>> I have previously raised an issue [0] on these ciphersuites. The same > >>> requirement was noted also by Peter Dettman as something special in > >>> [1]. However, there has been no reaction from the authors (now in CC)= . > >>> > >>> regards, > >>> Nikos > >>> > >>> [0]. > >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ > >>> [1]. > >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >>_______________________________________________ > >>TLS mailing list > >>TLS@ietf.org > >>https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113fd4b8489c16053f11b94a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am not clear what the consensus i= s for the following points. Is there any consensus for requesting the follo= wing ones?

BR,
Daniel

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA2= 56=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0,0x01};
TLS_ECDHE_PSK_WITH_AES_25= 6_GCM_SHA384=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0,0x02};
TLS_ECDHE_PSK_W= ITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03};
TLS_ECDHE_PSK_W= ITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04};
TLS_ECDHE_PSK_W= ITH_AES_128_CCM_SHA256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0,0x05};
TLS_E= CDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0,0x06}= ;



On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
I'm mai= nly just looking to economize on different configurations.

On 9 October 2016 at 16:32, John Mattsson <john.mattsson@ericsson.com> wrote:
> Hi Martin,
>
>
> AES_256_CCM_8 was not in the first versions of the draft but added lat= er
> after request from IoT people (probably afraid of quantum computers).<= br> >
>
> While I think it makes very much sense to have short tags in wireless<= br> > radio, I do not know how large need there is for AES-256 in IoT for > constrained devices, or how large the need would be to truncate the ta= g in
> these cases.
>
>
> My current understanding is that Grover=E2=80=99s algorithm may never = be more
> cost-effective than a cluster of classical computers, and that quantum=
> computers therefore likely do not affect the lifetime of AES-128.
>
>
> I do not have any strong opinions regarding keeping AES_256_CCM_8 or n= ot.
> We should not give the impression that AES-256 is needed for practical=
> resistance to quantum computers anytime soon, it is however a requirem= ent
> for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM see= ms
> like the best choices in most cases.
>
>
> Cheers,
> John
>
>
>
> On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <tls-bounces@ietf.org
> on behalf of martin.thomso= n@gmail.com> wrote:
>
>>Looking at those emails, I am prompted to wonder if anyone can just= ify
>>the existence of a ciphersuite with a double-sized key and half-siz= ed
>>authentication tag.=C2=A0 RFC 6655 doesn't really explain how t= hat is a
>>useful thing.
>>
>>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos <nmav@redhat.com>
>>wrote:
>>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
>>>> All,
>>>>
>>>> We've received a request for early IANA assignments fo= r the 6 cipher
>>>> suites listed in https://datatr= acker.ietf.org/doc/draft-ietf-tls-ecdh
>>>> e-psk-aead/.=C2=A0 Please respond before August 23rd if yo= u have concerns
>>>> about early code point assignment for these cipher suites.=
>>>
>>> I have previously raised an issue [0] on these ciphersuites. T= he same
>>> requirement was noted also by Peter Dettman as something speci= al in
>>> [1]. However, there has been no reaction from the authors (now= in CC).
>>>
>>> regards,
>>> Nikos
>>>
>>> [0].
>>>https://mailarchive= .ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
>>> [1].
>>>https://mailarchive= .ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls=
>>
>>_______________________________________________
>>TLS mailing list
>>TLS@ietf.org
>>https://www.ietf.org/mailman/listinfo/tls<= br> >

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

--001a113fd4b8489c16053f11b94a-- From nobody Mon Oct 17 09:08:52 2016 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 8331F129892 for ; Mon, 17 Oct 2016 09:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 rkhWaWk345RM for ; Mon, 17 Oct 2016 09:08:49 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2415712989C for ; Mon, 17 Oct 2016 09:08:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 68522300A9E for ; Mon, 17 Oct 2016 12:08:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ea7yhKkCjLhD for ; Mon, 17 Oct 2016 12:08:46 -0400 (EDT) Received: from [10.59.2.154] (unknown [195.77.81.228]) by mail.smeinc.net (Postfix) with ESMTPSA id 4DB8A30050E; Mon, 17 Oct 2016 12:08:45 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A0EC47A5-5A24-4D2F-9E02-137B4814C70A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 17 Oct 2016 12:08:42 -0400 Message-Id: <560A7514-572F-4391-9348-40E42DE7DFCC@vigilsec.com> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> To: Daniel Migault X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF TLS Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead 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: Mon, 17 Oct 2016 16:08:51 -0000 --Apple-Mail=_A0EC47A5-5A24-4D2F-9E02-137B4814C70A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would like to see these included: > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x01}; > TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x02}; I am fine with including these as well if someone wants to use them: > TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x05}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x06}; I do not really see a reason to include the ones with the shorter MAC: > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x04}; Russ On Oct 17, 2016, at 12:03 PM, Daniel Migault = wrote: > Hi,=20 >=20 > I am not clear what the consensus is for the following points. Is = there any consensus for requesting the following ones? >=20 > BR,=20 > Daniel >=20 > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x01}; > TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x02}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x04}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x05}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x06}; >=20 >=20 >=20 > On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson = wrote: > I'm mainly just looking to economize on different configurations. >=20 > On 9 October 2016 at 16:32, John Mattsson = wrote: > > Hi Martin, > > > > > > AES_256_CCM_8 was not in the first versions of the draft but added = later > > after request from IoT people (probably afraid of quantum = computers). > > > > > > While I think it makes very much sense to have short tags in = wireless > > radio, I do not know how large need there is for AES-256 in IoT for > > constrained devices, or how large the need would be to truncate the = tag in > > these cases. > > > > > > My current understanding is that Grover=92s algorithm may never be = more > > cost-effective than a cluster of classical computers, and that = quantum > > computers therefore likely do not affect the lifetime of AES-128. > > > > > > I do not have any strong opinions regarding keeping AES_256_CCM_8 or = not. > > We should not give the impression that AES-256 is needed for = practical > > resistance to quantum computers anytime soon, it is however a = requirement > > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM = seems > > like the best choices in most cases. > > > > > > Cheers, > > John > > > > > > > > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" = > on behalf of martin.thomson@gmail.com> wrote: > > > >>Looking at those emails, I am prompted to wonder if anyone can = justify > >>the existence of a ciphersuite with a double-sized key and = half-sized > >>authentication tag. RFC 6655 doesn't really explain how that is a > >>useful thing. > >> > >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos = > >>wrote: > >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: > >>>> All, > >>>> > >>>> We've received a request for early IANA assignments for the 6 = cipher > >>>> suites listed in = https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh > >>>> e-psk-aead/. Please respond before August 23rd if you have = concerns > >>>> about early code point assignment for these cipher suites. > >>> > >>> I have previously raised an issue [0] on these ciphersuites. The = same > >>> requirement was noted also by Peter Dettman as something special = in > >>> [1]. However, there has been no reaction from the authors (now in = CC). > >>> > >>> regards, > >>> Nikos > >>> > >>> [0]. > = >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ > >>> [1]. > = >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >>_______________________________________________ > >>TLS mailing list > >>TLS@ietf.org > >>https://www.ietf.org/mailman/listinfo/tls > > >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_A0EC47A5-5A24-4D2F-9E02-137B4814C70A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = would like to see these included:

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   =3D = {0xTBD; 0xTBD} = {0xD0,0x01};
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   =3D = {0xTBD; 0xTBD} {0xD0,0x02};

I am fine = with including these as well if someone wants to use = them:

TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   =3D = {0xTBD; 0xTBD} = {0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   =3D = {0xTBD; 0xTBD} {0xD0,0x06};

I do not = really see a reason to include the ones with the shorter = MAC:

TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x03};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; = 0xTBD} = {0xD0,0x04};

Russ


On Oct 17, 2016, at 12:03 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

I am not clear = what the consensus is for the following points. Is there any consensus = for requesting the following ones?

BR, =
Daniel

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   =3D = {0xTBD; 0xTBD} = {0xD0,0x01};
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   =3D = {0xTBD; 0xTBD} {0xD0,0x02};
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D= {0xTBD; 0xTBD} {0xD0,0x03};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = =3D {0xTBD; 0xTBD} = {0xD0,0x04};
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   =3D = {0xTBD; 0xTBD} = {0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   =3D = {0xTBD; 0xTBD} {0xD0,0x06};



On Sun, Oct 9, 2016 = at 7:11 PM, Martin Thomson <martin.thomson@gmail.com> = wrote:
I'm mainly just = looking to economize on different configurations.

On 9 October 2016 at 16:32, John Mattsson <john.mattsson@ericsson.com&= gt; wrote:
> Hi Martin,
>
>
> AES_256_CCM_8 was not in the first versions of the draft but added = later
> after request from IoT people (probably afraid of quantum = computers).
>
>
> While I think it makes very much sense to have short tags in = wireless
> radio, I do not know how large need there is for AES-256 in IoT = for
> constrained devices, or how large the need would be to truncate the = tag in
> these cases.
>
>
> My current understanding is that Grover=92s algorithm may never be = more
> cost-effective than a cluster of classical computers, and that = quantum
> computers therefore likely do not affect the lifetime of = AES-128.
>
>
> I do not have any strong opinions regarding keeping AES_256_CCM_8 = or not.
> We should not give the impression that AES-256 is needed for = practical
> resistance to quantum computers anytime soon, it is however a = requirement
> for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM = seems
> like the best choices in most cases.
>
>
> Cheers,
> John
>
>
>
> On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <tls-bounces@ietf.org
> on behalf of martin.thomson@gmail.com> = wrote:
>
>>Looking at those emails, I am prompted to wonder if anyone can = justify
>>the existence of a ciphersuite with a double-sized key and = half-sized
>>authentication tag.  RFC 6655 doesn't really explain how = that is a
>>useful thing.
>>
>>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos <nmav@redhat.com>
>>wrote:
>>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
>>>> All,
>>>>
>>>> We've received a request for early IANA assignments for = the 6 cipher
>>>> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecd= h
>>>> e-psk-aead/.  Please respond before August 23rd if = you have concerns
>>>> about early code point assignment for these cipher = suites.
>>>
>>> I have previously raised an issue [0] on these = ciphersuites. The same
>>> requirement was noted also by Peter Dettman as something = special in
>>> [1]. However, there has been no reaction from the authors = (now in CC).
>>>
>>> regards,
>>> Nikos
>>>
>>> [0].
>>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-= aT299BYrlBKvZs0BOQ
>>> [1].
>>>https://mailarchive.ietf.org/arch/msg/tls/onEk= dgH30eZgWs8v5Rp-CUqCHds
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>>_______________________________________________
>>TLS mailing list
>>TLS@ietf.org
>>https://www.ietf.org/mailman/listinfo/tls
>

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

_______________________________________________
TLS mailing = list
TLS@ietf.org
https://www.ietf.org/mail= man/listinfo/tls

= --Apple-Mail=_A0EC47A5-5A24-4D2F-9E02-137B4814C70A-- From nobody Mon Oct 17 09:11:48 2016 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 AB2571295EA for ; Mon, 17 Oct 2016 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 AkrHfBbiUi5t for ; Mon, 17 Oct 2016 09:11:45 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 98BB8129538 for ; Mon, 17 Oct 2016 09:11:45 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8032E423706; Mon, 17 Oct 2016 16:11:44 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 53602423705; Mon, 17 Oct 2016 16:11:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1476720704; bh=/8WPuEAPeR1NcKSLLpl3DssWK4eX/cBn4QSuBN254Vs=; l=2402; h=To:References:From:Date:In-Reply-To:From; b=tY9pfs7Ati8/crGPCEddyOHOWYZuvD6kRs5mLfnrUj43+oG1WQnT88e5iywtbfBjO VoyWtU9ZNZ5U6+BZuTsIKlABesEXExWBOsvPh+Lnz9/g2OG1nxWJRfsSQbbrTsKGU+ eL7TqMKi8xVGwOmb3+8646qQA5rCOYyvq2XwbEbY= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1C8A61FC88; Mon, 17 Oct 2016 16:11:44 +0000 (GMT) To: Hubert Kario , tls@ietf.org References: <7351210.yvrLMuiDzx@pintsize.usersys.redhat.com> From: Benjamin Kaduk Message-ID: <2848f9dd-0bf9-609d-38d6-77484d504159@akamai.com> Date: Mon, 17 Oct 2016 11:11:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <7351210.yvrLMuiDzx@pintsize.usersys.redhat.com> Content-Type: multipart/alternative; boundary="------------593E7E0532312EDA3BA768B8" Archived-At: Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 16:11:46 -0000 This is a multi-part message in MIME format. --------------593E7E0532312EDA3BA768B8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/17/2016 06:20 AM, Hubert Kario wrote: > On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz wrote: >> After PR #625 all alerts are required to be sent with fatal AlertLevel >> except for close_notify, end_of_early_data, and user_canceled. Since those >> three alerts all have separate specified behavior, the AlertLevel field is >> not serving much purpose, other than providing potential for misuse. We >> (Facebook) currently receive a number of alerts at incorrect levels from >> clients (internal_error warning alerts, etc.). > could you expand on why it's a problem? > Why what is a problem? My understanding is that at present, the AlertLevel is not reliable (that is, some noticeable fraction of clients send nonsense) and so the change in PR 693 is merely documenting existing best practice. -Ben --------------593E7E0532312EDA3BA768B8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/17/2016 06:20 AM, Hubert Kario wrote:
On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz wrote:

After PR #625 all alerts are required to be sent with fatal AlertLevel
except for close_notify, end_of_early_data, and user_canceled. Since those
three alerts all have separate specified behavior, the AlertLevel field is
not serving much purpose, other than providing potential for misuse. We
(Facebook) currently receive a number of alerts at incorrect levels from
clients (internal_error warning alerts, etc.).

could you expand on why it's a problem?

Why what is a problem?

My understanding is that at present, the AlertLevel is not reliable (that is, some noticeable fraction of clients send nonsense) and so the change in PR 693 is merely documenting existing best practice.

-Ben
--------------593E7E0532312EDA3BA768B8-- From nobody Mon Oct 17 09:19:30 2016 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 86ABE1298AF for ; Mon, 17 Oct 2016 09:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.353 X-Spam-Level: X-Spam-Status: No, score=-7.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 CatNVV3HIbs2 for ; Mon, 17 Oct 2016 09:19:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752801298A9 for ; Mon, 17 Oct 2016 09:19:27 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2AD737F3F5; Mon, 17 Oct 2016 16:19:27 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HGJPbM015473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2016 12:19:26 -0400 From: Hubert Kario To: Benjamin Kaduk Date: Mon, 17 Oct 2016 18:19:25 +0200 Message-ID: <2433245.jcFcMeBmYW@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.6-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) In-Reply-To: <2848f9dd-0bf9-609d-38d6-77484d504159@akamai.com> References: <7351210.yvrLMuiDzx@pintsize.usersys.redhat.com> <2848f9dd-0bf9-609d-38d6-77484d504159@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6937391.kOs8xvOqXM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 17 Oct 2016 16:19:27 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 16:19:29 -0000 --nextPart6937391.kOs8xvOqXM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 17 October 2016 11:11:43 CEST Benjamin Kaduk wrote: > On 10/17/2016 06:20 AM, Hubert Kario wrote: > > On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz wrote: > >> After PR #625 all alerts are required to be sent with fatal AlertLevel > >> except for close_notify, end_of_early_data, and user_canceled. Since > >> those > >> three alerts all have separate specified behavior, the AlertLevel field > >> is > >> not serving much purpose, other than providing potential for misuse. We > >> (Facebook) currently receive a number of alerts at incorrect levels fr= om > >> clients (internal_error warning alerts, etc.). > >=20 > > could you expand on why it's a problem? >=20 > Why what is a problem? clients sending incorrect levels for the description they send =20 > My understanding is that at present, the AlertLevel is not reliable > (that is, some noticeable fraction of clients send nonsense) and so the > change in PR 693 is merely documenting existing best practice. the current draft says that any alert except the three defined as warning=20 level must be considered fatal and cause connection closure I don't see how deprecating the field changes anything - the implementation= s=20 won't need to behave differently and data on the wire won't be different =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart6937391.kOs8xvOqXM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYBPoNAAoJEJKo0bgB0vX1vtkP/ikIGyD9Z7g4XuErEume8Hmd K3qFbssGppR3tDDgRyUBoaj9CUocuBO/9cgwcSYCLNyBpkMPOscEzYUYx2xPUBaG L/O9YiD2ksi/+gP/PVUmK9iTnKPvp4ky+AHwZNvEP7yv8Vuy/kQLjKzpIqPUuUvM gWPIWK2RnqA4DKOzFlYdiGX4qHXVRflyG48GedVubpQWDa8kdAJas8QGORTWc804 2eEc+5mvBDY06QMFsuFo0v9f0CH4kScqxiANhEaO/imm9iLGGDTLarQzR4zVAUd7 t90gHBYOLY9gmtmOAc9s5brsQSMGjWXs64hbIh6CrZIzaiCseX69l236EHfDf++t EbCClAhOSHwt2rsq4N4o/Oh6lIUM6vbmiOK+fyKf8YBK7X3MUw9Vh+wq+Mc8Vx29 BkmxF8MjqG9g+RIMEXUutw+jA0XMsmUTlo8NIlSYR3tgRjoCkRCDHshFyuX75S+M mFVP6cM1uL6psqIOM2Wldo+oKJI4IXaNNX8EmqURBSnFe2rX9/KlKgpf2ofJsavP w9ETZm4dL5ta5rmlGMLYUSlgj6hvfDCwNBvt4NkKesm9MaivhrykdUsrx2G9k5dk KVyFQvKEKMlRINYci2G3rVoMkyb0DElMG6vQCjCAym01YoZpKhCx0WOYnY10R/gn vffg3+F5b3TF92caoDLn =LVzG -----END PGP SIGNATURE----- --nextPart6937391.kOs8xvOqXM-- From nobody Mon Oct 17 09:30:35 2016 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 6DDA61298C1 for ; Mon, 17 Oct 2016 09:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 dW3cfxsDRkD1 for ; Mon, 17 Oct 2016 09:30:30 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0EF1298CF for ; Mon, 17 Oct 2016 09:30:30 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id 191so67127480ybv.3 for ; Mon, 17 Oct 2016 09:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D1B+rQt9SMjfhoeWRqOLmL0oPn8a0YJuMnFZgiirFQE=; b=gMvbd+LyBWrP2MNUFeD3OwE7A9XRZzgewtq3/dulljlh4oGxa0laEZDBpbQ8lpn57E tVApH+J/O0/X1fblH2jAUi0Sds6k6QElRGrsl9AJEyCVcyjdzSa8FebMHnfNExX2vJG3 IWmKlEdjjis7rSBwxBFpZytcFOwSM1yAeSoJGaV/PEE+B+OpMltBOGPU+z1wnG8so/iG QhzAJksjfpfn3nWXa/ssVQONvNGNbs1K4w+eGKNi5HVIsnarGPgLh9qzn8DMsu16vewf vWacyjHsVHErUz44YatEhetWlKYyH3I1z2+x2kngMJ1Epz7Cbrf3xk/nvXS0BT84PE4W Mx0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D1B+rQt9SMjfhoeWRqOLmL0oPn8a0YJuMnFZgiirFQE=; b=f1zdgnXaDivPHnAdLAa8e3DEkk5R6znltF9OSM87xIljD5EKrSw62oGJQ/oD8T0Avc n3sPFjAItmzgSFs2Xm5bz26ODJOKvQ1+fyzN4a21PrFrxfey7vKuOeF+9EysJXBxW+ly yNxzUuy9j5z9tWXhPCMKUHcwC4hUYu1+13hhOBbYPEBbsMV7koo3d9ZqZvItBVIXFtCi 4kyG3neqzA5eXLRCcmTOAdUMSqUxsKZJQXxwri/8FRJnRhSgDP9qRa+Bib2s9hmtfTA8 7pflTAvUCFMkEzsByVjyGhQaxZ99Mcl2eHGWKNYdL0ofa9Is5sYoet4jC5bXb91BN86T ifMQ== X-Gm-Message-State: AA6/9Rn4dKZMwpTdrk/xpT4wrg6MtXo8s9K0Jp1kxpv7bidzum23MV61Dx5eF2rPTRzHkbYSmpRUVoQbrDBRPQ== X-Received: by 10.37.174.11 with SMTP id a11mr24074380ybj.180.1476721829966; Mon, 17 Oct 2016 09:30:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Mon, 17 Oct 2016 09:29:49 -0700 (PDT) In-Reply-To: <2433245.jcFcMeBmYW@pintsize.usersys.redhat.com> References: <7351210.yvrLMuiDzx@pintsize.usersys.redhat.com> <2848f9dd-0bf9-609d-38d6-77484d504159@akamai.com> <2433245.jcFcMeBmYW@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Mon, 17 Oct 2016 12:29:49 -0400 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=f403045db83e1bb344053f1218ae Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 16:30:32 -0000 --f403045db83e1bb344053f1218ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This would actually simplify our implementation slightly because then we would simply not look at the field at all, even for the closure alerts. -Ekr On Mon, Oct 17, 2016 at 12:19 PM, Hubert Kario wrote: > On Monday, 17 October 2016 11:11:43 CEST Benjamin Kaduk wrote: > > On 10/17/2016 06:20 AM, Hubert Kario wrote: > > > On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz wrote: > > >> After PR #625 all alerts are required to be sent with fatal AlertLev= el > > >> except for close_notify, end_of_early_data, and user_canceled. Since > > >> those > > >> three alerts all have separate specified behavior, the AlertLevel > field > > >> is > > >> not serving much purpose, other than providing potential for misuse. > We > > >> (Facebook) currently receive a number of alerts at incorrect levels > from > > >> clients (internal_error warning alerts, etc.). > > > > > > could you expand on why it's a problem? > > > > Why what is a problem? > > clients sending incorrect levels for the description they send > > > My understanding is that at present, the AlertLevel is not reliable > > (that is, some noticeable fraction of clients send nonsense) and so the > > change in PR 693 is merely documenting existing best practice. > > the current draft says that any alert except the three defined as warning > level must be considered fatal and cause connection closure > > I don't see how deprecating the field changes anything - the > implementations > won't need to behave differently and data on the wire won't be different > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f403045db83e1bb344053f1218ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This would actually simplify our implementation slightly b= ecause then we would simply not look at the field at all, even for the clos= ure alerts.

-Ekr


On Mon, Oct 17, 2016 at 12:19 = PM, Hubert Kario <hkario@redhat.com> wrote:
On Monday, 17 October 2016 11:11:43 CEST= Benjamin Kaduk wrote:
> On 10/17/2016 06:20 AM, Hubert Kario wrote:
> > On Friday, 14 October 2016 21:07:30 CEST Kyle Nekritz wrote:
> >> After PR #625 all alerts are required to be sent with fatal A= lertLevel
> >> except for close_notify, end_of_early_data, and user_canceled= . Since
> >> those
> >> three alerts all have separate specified behavior, the AlertL= evel field
> >> is
> >> not serving much purpose, other than providing potential for = misuse. We
> >> (Facebook) currently receive a number of alerts at incorrect = levels from
> >> clients (internal_error warning alerts, etc.).
> >
> > could you expand on why it's a problem?
>
> Why what is a problem?

clients sending incorrect levels for the description they send

> My understanding is that at present, the AlertLevel is not reliable > (that is, some noticeable fraction of clients send nonsense) and so th= e
> change in PR 693 is merely documenting existing best practice.

the current draft says that any alert except the three defined as wa= rning
level must be considered fatal and cause connection closure

I don't see how deprecating the field changes anything - the implementa= tions
won't need to behave differently and data on the wire won't be diff= erent

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic

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


--f403045db83e1bb344053f1218ae-- From nobody Mon Oct 17 09:37:11 2016 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 AD05D12948F for ; Mon, 17 Oct 2016 09:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.353 X-Spam-Level: X-Spam-Status: No, score=-7.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 t3dVcQkUh_yU for ; Mon, 17 Oct 2016 09:37:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D47129559 for ; Mon, 17 Oct 2016 09:37:09 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A6BFA80F6C for ; Mon, 17 Oct 2016 16:37:08 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HGb79L019152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Oct 2016 12:37:08 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 17 Oct 2016 18:37:02 +0200 Message-ID: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.6-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1792227.uYXD4gntMM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 17 Oct 2016 16:37:08 +0000 (UTC) Archived-At: Subject: [TLS] Supported Versions extension 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: Mon, 17 Oct 2016 16:37:11 -0000 --nextPart1792227.uYXD4gntMM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Currently the description of the extension states that only TLS versions ca= n=20 be listed in the extension and all unknown versions must be ignored. I wonder if making it explicit that {3, 0} and any lower values MUST NOT be= =20 advertised wouldn't be a good idea, if only to hammer it that SSL3 must not= be=20 used. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1792227.uYXD4gntMM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYBP4uAAoJEJKo0bgB0vX1l3QP/31pEbko+hti646IGKDFdmzw SkitWxkG/DjHlscg6zjzAhgf2nmdnh/AJaDFZjTRqxvX6lVYSE9zLYRevXrLzLKo yLOyj8v9v8twqiGc5ItYAEgcArzMwZlsteJHujzJUDBK1r2Z/n0P2C8jmFRk9bwp xulWAx+hfYHHuzy8fcR8DmsqRwBuwySoT7wzFSdVErQua5c5yOgWYpp5o6/9f64O 3LHto8pZdQ3XaqHmREKQEb8Op9x1I4qll7cTk9S4s9kmLHi1ZodMAiEj7+naOYwY tUOfDrn0VAnG3HVQUP/3msty6HX3ShO0E2bBXb5ova1QvxKWMZOc86zc80nzaemP lJFawZZAmb4YEn9VMz1hm+ApjYk/wVd3tcE6dVNBxoiInqK5t2ZWq6bzyN8McO68 X6+iEbm7jp3OOAyr3ajytvdClBNtJkxglcgXfT4PZdX21feZ1pb5pUaLhglQl4r8 z+wX3uExjXR/QQbhgSr/rAXg0Z/3FngOj2QkmVXcMV/OID1qcIIHf1bTh1E2H096 bNNqxrkMOrhv6U0McShoIpDNWkU0aMaZU+G+qTeqef0CwV/ov47Rn1RREB88lWR2 sI5a+++R9dm79Yh6kgy0D1EDQgK9ogEc4asSdpNfvvgMCu/ZWgv/XnahwQkn9ioT qw3t8b3M59dutJSo6tWJ =rBUV -----END PGP SIGNATURE----- --nextPart1792227.uYXD4gntMM-- From nobody Mon Oct 17 10:04:27 2016 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 A079A1298C3 for ; Mon, 17 Oct 2016 10:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1hINDINBBd0C for ; Mon, 17 Oct 2016 10:04:21 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC291295C3 for ; Mon, 17 Oct 2016 10:04:20 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3syPgk6Gz4z25St; Mon, 17 Oct 2016 19:04:18 +0200 (CEST) X-purgate-ID: 152705::1476723858-00002B31-09856E5B/0/0 X-purgate-size: 451 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3syPgk2VQKzksCH; Mon, 17 Oct 2016 19:04:18 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 49DD41A564; Mon, 17 Oct 2016 19:04:18 +0200 (CEST) In-Reply-To: To: Kyle Nekritz Date: Mon, 17 Oct 2016 19:04:18 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161017170418.49DD41A564@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating alert levels X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Mon, 17 Oct 2016 17:04:22 -0000 Kyle Nekritz wrote: > > After PR #625 all alerts are required to be sent with fatal AlertLevel > except for close_notify, end_of_early_data, and user_canceled. This list is already missing the warning-level "unrecognized_name" alert, and such a change would imply that all new/unrecognized alerts are going to be treated as fatal forever (i.e. that no new warning-level alerts can ever be defined). I don't like that proposal. -Martin From nobody Mon Oct 17 10:16:31 2016 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 97103129437 for ; Mon, 17 Oct 2016 10:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 M464-96bkvkU for ; Mon, 17 Oct 2016 10:16:28 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3549F129524 for ; Mon, 17 Oct 2016 10:16:28 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 139so49489394itm.1 for ; Mon, 17 Oct 2016 10:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rN+5y5ggt+DBVNg/0jtaksF7FlAAe7p2ahkwMgyJGqE=; b=GsJV7QneMPcat9HC2ywINmBp0dLX9/zVvdGy/is/jc27/ki32iZdZfWGSO4YnOo4s5 10STPp6/b3yt/5nNvOe72MqLrkuEPDCddc4DiaCojPjhfOc+TX6rYNiz22vPzWmwWzJO BsRzWR1RBu0nFqSklRzTfdAPN/toSRivWzA5rV8VYHlj3SmXnJuDENrqIY/eh+eWUGa7 4huPePZLFqFrsk2dSqmetyF7m2K0DdYAw1UldZ/omV6oEWz/Y5NV3he4myQUr5otI1EC zuPEEg3EycHSdTPGbFZ6xqONF43RyPcjqR1LAhBYMys8A3pt0tPcnZaniQxzNShiw8wF YDFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rN+5y5ggt+DBVNg/0jtaksF7FlAAe7p2ahkwMgyJGqE=; b=GO7Plsv/x233jwRJMILTaL9VSzjqD6fnHPnE6XXzxhOT9z0h6bgtAXOlecdFDnnups LKhQuL0ZLUZEt9HXSen1V6cNqQ1cu8KG6GOHbSidltsHb4iiPvIKYFUF5K0iYizCSUF8 c/xI2zLGmKDX8YrKnJzuYZ3odRs8JbrplRIB3/1ziO4BOH4xrp203IGCwE/5py2eowc+ geBlmcn+Uvo37GtUHG9aJwPxn/yzyrNB/8bEFXUT+OOZSK5fEJd20DFsOfNi1AdbAxsN z0BZ7b2GmraBvEI6ptvEhfPA5brYRXoCWNmEx2JVwEwUAHu4+WCd4O2Zeqz2KQf+ksoe BzkQ== X-Gm-Message-State: AA6/9RkF68dy8Quf7NT3xSS7g9aUftUmi7F33tBll6OtPurDOf5q/vrOlMB7OvqGBZsd0kqqBGf6eGp/T/0Epg== X-Received: by 10.36.90.202 with SMTP id v193mr9630565ita.120.1476724587543; Mon, 17 Oct 2016 10:16:27 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 17 Oct 2016 10:16:27 -0700 (PDT) In-Reply-To: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> From: Daniel Migault Date: Mon, 17 Oct 2016 13:16:27 -0400 X-Google-Sender-Auth: LX2RTcVBuCvLvqFGISi0qI3Hhk4 Message-ID: To: John Mattsson Content-Type: multipart/alternative; boundary=001a1145c51c78c2ad053f12bc72 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt 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: Mon, 17 Oct 2016 17:16:30 -0000 --001a1145c51c78c2ad053f12bc72 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am not very clear on how to update the text of the draft. The problem seems to me that code point restriction are hard to implement. As a result, the session is aborted with - insufficient_security(71) or equivalent - when the code point does not match the security strength. I am encline to think that we should also provide some profiles that achieve 128/256 bit security. These profiles may be described in this document or in another document more related to cryptographic recommendation. What would be the most appropriated way to move forward ? BR, Daniel On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson wrote: > Hi Dan, Sean, Nikos, > > First, let me state that I think requiring 128-bit key management for > AES-128 is quite reasonable. > > HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies > when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key size= s > smaller than the lower limits as a connection error (Section 5.4.1 > ) of type > INADEQUATE_SECURITY." > > > I think this is a question for TLS in general, > draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides > as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups > with insufficient security as an error. > > I think the real problem here are TLS libraries supporting 1024 MODP and > 160 ECC at all, support for these should have been removed before 2010. > Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2 > (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better > than bundling it into a code-point assignment RFC. (My current plans for > the next update of 3GPP=E2=80=99s TLS and DTLS profiles is simply to forb= id > support of anything weaker than 2048 MODP and 255-bit ECC). > > [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BO= Q > > > > Cheers, > John > > > On 11/07/16 22:26, "TLS on behalf of Dan Harkins" behalf of dharkins@lounge.org> wrote: > > > > > I'm glad I have to opportunity to make you happy Sean :-) > > > >On Mon, July 11, 2016 7:40 am, Sean Turner wrote: > >> I think I can take this bit: > >> > >> On Jul 10, 2016, at 06:51, Peter Dettman > >> > >> wrote: > >>> > >>> I'm also curious whether there is a precedent in other RFCs for an > >>> explicit minimum curve bits, or perhaps a de facto implementer's rule= ? > >> > >> I'd be happy to be wrong here. but to my knowledge no there's not been > >> an explicit minimum for curve bits. There have however been similar (= at > >> least in my non-cryptographer mind) for RSA key sizes so if we wanted = to > >> define an explicit minimum curve bits then we could. > > > > draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring > >the curves used provide commensurate strength with the ciphersuite > >negotiated. Section 10, "Implementation Considerations", says: > > > > It is RECOMMENDED that implementations take note of the strength > > estimates of particular groups and to select a ciphersuite providing > > commensurate security with its hash and encryption algorithms. A > > ciphersuite whose encryption algorithm has a keylength less than the > > strength estimate, or whose hash algorithm has a blocksize that is > > less than twice the strength estimate SHOULD NOT be used. > > > > And I would like to take this opportunity to remind everyone that > >the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 > >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant > >to dictionary attack and the former is not. > > > > regards, > > > > Dan. > > > > > > > >_______________________________________________ > >TLS mailing list > >TLS@ietf.org > >https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1145c51c78c2ad053f12bc72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am not very clear on ho= w to update the text of the draft. The problem seems to me that code point = restriction are hard to implement. As a result, the session is aborted with= - insufficient_security(71) or equivalent - when the code point does not m= atch the security strength. I am encline to think that we should also provi= de some profiles that achieve 128/256 bit security. These profiles may be d= escribed in this document or in another document more related to cryptograp= hic recommendation. What would be the most appropriated way to move forward= ?

BR,
Daniel



On Sun, Oct 9, 2= 016 at 2:59 AM, John Mattsson <john.mattsson@ericsson.com>= wrote:
Hi Dan, Sean, Nikos,

First, let me state that I think requiring 128-bit key management for
AES-128 is quite reasonable.

HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key s= izes
smaller than the lower limits as a connection error (Section 5.4.1
<https://tools.ietf.org/html/rfc7540#sectio= n-5.4.1>) of type
INADEQUATE_SECURITY."


I think this is a question for TLS in general,
draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups with insufficient security as an error.

I think the real problem here are TLS libraries supporting 1024 MODP and 160 ECC at all, support for these should have been removed before 2010.
Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
(i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better than bundling it into a code-point assignment RFC. (My current plans for the next update of 3GPP=E2=80=99s TLS and DTLS profiles is simply to forbid=
support of anything weaker than 2048 MODP and 255-bit ECC).

[0]. https://mailarchive.ietf.o= rg/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ



Cheers,
John


On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <tls-bounces@ietf.org on
behalf of dharkins@lounge.org> wrote:

>
>=C2=A0 I'm glad I have to opportunity to make you happy Sean :-) >
>On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
>> I think I can take this bit:
>>
>> On Jul 10, 2016, at 06:51, Peter Dettman
>><peter.dettman= @bouncycastle.org>
>> wrote:
>>>
>>> I'm also curious whether there is a precedent in other RFC= s for an
>>> explicit minimum curve bits, or perhaps a de facto implementer= 's rule?
>>
>> I'd be happy to be wrong here. but to my knowledge no there= 9;s not been
>> an explicit minimum for curve bits.=C2=A0 There have however been = similar (at
>> least in my non-cryptographer mind) for RSA key sizes so if we wan= ted to
>> define an explicit minimum curve bits then we could.
>
>=C2=A0 draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensurin= g
>the curves used provide commensurate strength with the ciphersuite
>negotiated. Section 10, "Implementation Considerations", says= :
>
>=C2=A0 =C2=A0It is RECOMMENDED that implementations take note of the st= rength
>=C2=A0 =C2=A0estimates of particular groups and to select a ciphersuite= providing
>=C2=A0 =C2=A0commensurate security with its hash and encryption algorit= hms.=C2=A0 A
>=C2=A0 =C2=A0ciphersuite whose encryption algorithm has a keylength les= s than the
>=C2=A0 =C2=A0strength estimate, or whose hash algorithm has a blocksize= that is
>=C2=A0 =C2=A0less than twice the strength estimate SHOULD NOT be used.<= br> >
>=C2=A0 And I would like to take this opportunity to remind everyone tha= t
>the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256<= br> >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resis= tant
>to dictionary attack and the former is not.
>
>=C2=A0 regards,
>
>=C2=A0 Dan.
>
>
>
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

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

--001a1145c51c78c2ad053f12bc72-- From nobody Mon Oct 17 10:27:16 2016 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 DF5FA129973 for ; Mon, 17 Oct 2016 10:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 c4BUS6y1CdDU for ; Mon, 17 Oct 2016 10:27:13 -0700 (PDT) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413A0129680 for ; Mon, 17 Oct 2016 10:27:13 -0700 (PDT) Received: by mail-qt0-f179.google.com with SMTP id q7so130923704qtq.1 for ; Mon, 17 Oct 2016 10:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=OeMGkaxqYVe1n6pyhlggz93eGSY79d1h7rW8tl0dtcE=; b=IEhHFkrzZnfhbbTWdEkJuICJdYFpgRMpf6Zs12x5Nz2DHEk5nOgGNAn/VoljbImCI2 6qWhh8qzWuD9AoZ8PUCK40tAgwDF3R55GaOha2oEqmw6tpgyNgLLms5d9unPLq2W5q9O cS4c9ABIuqTjCL7oxSyTy4Z5oXQiREPKEPCgt4r//c67dZb9rNNcyC4I8mKK07kQ2kA9 DPIBbvPVxuNzinbN2YDsTb/c9jd/egI88UkEYCeQtezTEUGUqztmlJHFC94xpGyb/vh6 jr5oXbD1aClc/LXpgoVdkcgfBF+NAF2gHa2Zu+eYPXqJ8WD0TSMVhstv494iE2TdD/vh n/lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=OeMGkaxqYVe1n6pyhlggz93eGSY79d1h7rW8tl0dtcE=; b=O8sZOzTUfVXMw7PtKWoJLBFtkqLI9TKqY1PrQEsNMf52YN950hhXgAeTDSjyxlfgOD NE8Zk0qirCLG5VRY2n8bedBBnkaRxgnWYmR7DpA/5fkdOSN2q9wJ/twaRhW1RVXAr+vk SRbF/ZskgEt3urwxT+/k84B+5nZVfPo/vy7wyVZr033tWry0HrpwJFLhlUA7eZLXCRwv IWOV4MugNrpmklineqtHtm36lM/LT9OtAtA6FiddhlOtWGpyOhmdWNyMAVjfmzlLueJZ fLRvU1oBnYjz5RJZ3zzLvS3ay6z7roDEgUTBbp+vnXqKAY+h0NmSIgdX6dx7mgZ8pcQH qZnw== X-Gm-Message-State: AA6/9RkCGwZayndepzvGrJO/Fuh80IG8lPNU2pf3Dzj7tY6WcasnnYSlqHjV+bY6My0ltA== X-Received: by 10.200.38.78 with SMTP id v14mr26474412qtv.81.1476725172268; Mon, 17 Oct 2016 10:26:12 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id f79sm15560972qke.6.2016.10.17.10.26.11 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 17 Oct 2016 10:26:11 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, mrex@sap.com Date: Mon, 17 Oct 2016 13:26:09 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20161017170418.49DD41A564@ld9781.wdf.sap.corp> In-Reply-To: <20161017170418.49DD41A564@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201610171326.10236.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 17:27:15 -0000 On Monday, October 17, 2016 01:04:18 pm Martin Rex wrote: > This list is already missing the warning-level "unrecognized_name" alert, > and such a change would imply that all new/unrecognized alerts are going > to be treated as fatal forever (i.e. that no new warning-level alerts > can ever be defined). That's already true: https://tools.ietf.org/html/draft-ietf-tls-tls13-16#section-6 https://tlswg.github.io/tls13-spec/#alert-protocol "Unknown alert types MUST be treated as fatal." Changelog says this change was made for draft 14. Dave From nobody Mon Oct 17 10:34:14 2016 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 83273129976 for ; Mon, 17 Oct 2016 10:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=YiD29ykv; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=R5tcdLn2 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 UtvHNOpCkDeI for ; Mon, 17 Oct 2016 10:34:11 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 01E3A129975 for ; Mon, 17 Oct 2016 10:34:10 -0700 (PDT) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9HHUOMl001367; Mon, 17 Oct 2016 10:34:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=JXFh1diKTY3uBhW3ndkooCIY8uPciwJDVvnJdHj1oug=; b=YiD29ykv+mMJa7p42yB/uT0oP0x5TtbMygTAKnJ6Tklvn78wWDVMH+pDHAeG4x3Y+9w4 a1KzL3p6rlOkx0UnixrJ9gEiqSQOfawci7OJ+vWqOm6PXQpbIQlvdh8ByR1/VjmMYROC jf6YpSSnRv72Wj8CwrtiarfkCwG2F9FrqtI= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2650pxu0sj-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Oct 2016 10:34:10 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 17 Oct 2016 13:34:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JXFh1diKTY3uBhW3ndkooCIY8uPciwJDVvnJdHj1oug=; b=R5tcdLn2DIf5GBnYuFbz7XEIdPReKjJR+BvCvMBlYZy+y/0xdkCTUXwm5KvrWTANBbbxGOI8zQbg2n3+oG5I5RstZdMm3+sBUj8eg6iWspq3qj7tn1yGyMUvH3up2eZCu12p+o5OXYZGhkVwOmW5BdQXB3DsqiBXTv92kwDMkkY= Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1183.namprd15.prod.outlook.com (10.175.2.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 17 Oct 2016 17:34:06 +0000 Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0659.025; Mon, 17 Oct 2016 17:34:05 +0000 From: Kyle Nekritz To: Martin Thomson Thread-Topic: [TLS] Deprecating alert levels Thread-Index: AdImXnNSskDkr/RBRyKiMCb2wmhMDwBNKucAADz34cA= Date: Mon, 17 Oct 2016 17:34:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c091:200::7:61b1] x-ms-office365-filtering-correlation-id: 1f4af97a-4cec-4bf5-acf0-08d3f6b3cb47 x-microsoft-exchange-diagnostics: 1; MWHPR15MB1183; 20:T4zo+sk/Muj+iOA6XXEznGtP4KIjxCqfzqSvqYL/mX6tQZgkf+fswaCwYxat+Gsp+8K6jmzw/inJEXAhIS2uvKvmzYL7rGKEyjhF2x+rnacJ0ZPKHY+XtGlpkFY++tQrsMwwS8KfEoxksIvB1MEz9thX8thEtL6Z3vmFVb2AR/c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1183; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(166708455590820)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:MWHPR15MB1183; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1183; x-forefront-prvs: 0098BA6C6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(13464003)(24454002)(2900100001)(77096005)(15975445007)(3660700001)(76576001)(15650500001)(10400500002)(5002640100001)(122556002)(92566002)(305945005)(6916009)(110136003)(7696004)(74316002)(5660300001)(87936001)(68736007)(8936002)(105586002)(99286002)(19580395003)(19580405001)(106356001)(7846002)(2950100002)(2906002)(4326007)(50986999)(76176999)(7736002)(3280700002)(54356999)(9686002)(81156014)(81166006)(8676002)(6116002)(86362001)(575784001)(97736004)(189998001)(101416001)(586003)(102836003)(33656002)(3826002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1183; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2016 17:34:05.7000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1183 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-17_08:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 17:34:12 -0000 PiBZb3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCBlbmRfb2ZfZWFybHlfZGF0YSBhbmQgY2xvc2Vfbm90 aWZ5IHdpbGwgYmUgbWFya2VkICJmYXRhbCIuDQoNClllcywgdGVjaG5pY2FsbHkgdGhleSB3b3Vs ZCBoYXZlIG5vIGFsZXJ0IGxldmVsIChzaW5jZSBhbGVydCBsZXZlbCBpcyBkZXByZWNhdGVkKSwg YnV0IGFzIGZhciBhcyBieXRlcyBvbiB0aGUgd2lyZSBjaGFuZ2VzIHdpdGggdGhpcyBQUiwgdGhh dCdzIGNvcnJlY3QuDQoNCj4gY291bGQgeW91IGV4cGFuZCBvbiB3aHkgaXQncyBhIHByb2JsZW0/ DQoNCkFsZXJ0IGxldmVsIGlzIG5vdCBjb252ZXlpbmcgYW55IGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gc2luY2UgdGhlcmUgaXMgb25lIChhbmQgb25seSBvbmUpIGFsZXJ0IGxldmVsIGVhY2ggYWxl cnQgdHlwZSBtdXN0IGJlIHNlbnQgYXMuIEhhdmluZyBhIHNlcGFyYXRlIGZpZWxkIHRoYXQgZG9l cyBub3QgY29udmV5IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaXMgb25seSBwcm92aWRpbmcgYW4g b3Bwb3J0dW5pdHkgZm9yIGltcGxlbWVudGF0aW9ucyB0byBtaXN1c2UgaXQgYW5kIGNyZWF0ZSBz dWJ0bGUgYnVncyAoZm9yIGV4YW1wbGUgaWYgb25lIGltcGxlbWVudGF0aW9uIGlnbm9yZXMgd2Fy bmluZyBsZXZlbCBhbGVydHMsIHdoaWxlIGFub3RoZXIgaW5jb3JyZWN0bHkgc2VuZHMgYWxlcnRz IGRlZmluZWQgYXMgZmF0YWwgYXQgd2FybmluZyBsZXZlbCkuDQoNCj4gVGhpcyBsaXN0IGlzIGFs cmVhZHkgbWlzc2luZyB0aGUgd2FybmluZy1sZXZlbCAidW5yZWNvZ25pemVkX25hbWUiIGFsZXJ0 LCBhbmQgc3VjaCBhIGNoYW5nZSB3b3VsZCBpbXBseSB0aGF0IGFsbCBuZXcvdW5yZWNvZ25pemVk IGFsZXJ0cyBhcmUgZ29pbmcgdG8gYmUgdHJlYXRlZCBhcyBmYXRhbCBmb3JldmVyIChpLmUuIHRo YXQgbm8gbmV3IHdhcm5pbmctbGV2ZWwgYWxlcnRzIGNhbiBldmVyIGJlIGRlZmluZWQpLg0KDQpU aGF0IGFsZXJ0IGlzIGN1cnJlbnRseSBkZWZpbmVkIGFzIGEgZmF0YWwgYWxlcnQgKHNlZSBzZWN0 aW9uIDYuMiBpbiB0aGUgY3VycmVudCBkcmFmdCkuIFJGQyA2MDY2IGFsc28gc3RhdGVzICJJdCBp cyBOT1QgUkVDT01NRU5ERUQgdG8gc2VuZCBhIHdhcm5pbmctbGV2ZWwgdW5yZWNvZ25pemVkX25h bWUoMTEyKSBhbGVydCwgYmVjYXVzZSB0aGUgY2xpZW50J3MgYmVoYXZpb3IgaW4gcmVzcG9uc2Ug dG8gd2FybmluZy1sZXZlbCBhbGVydHMgaXMgdW5wcmVkaWN0YWJsZS4iLCB3aGljaCBJIHRoaW5r IGlsbHVzdHJhdGVzIHRoZSBwcm9ibGVtLiBBbGxvd2luZyBuZXcgbm9uLWZhdGFsIGFsZXJ0cyB0 byBiZSBhZGRlZCBsYXRlciB3b3VsZCByZXF1aXJlIHRoYXQgZXhpc3RpbmcgY2xpZW50cyBpZ25v cmUgdW5rbm93biB3YXJuaW5nIGFsZXJ0cywgd2hpY2ggSSB0aGluayBpcyBzb21ld2hhdCBkYW5n ZXJvdXMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNv biBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBTdW5kYXksIE9jdG9i ZXIgMTYsIDIwMTYgNTo1MyBBTQ0KVG86IEt5bGUgTmVrcml0eiA8a25la3JpdHpAZmIuY29tPg0K Q2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIERlcHJlY2F0aW5nIGFsZXJ0IGxl dmVscw0KDQpJJ20gc3ltcGF0aGV0aWMgdG8gdGhpcywgYnV0IGp1c3QgdG8gYmUgY2xlYXIuLi4N Cg0KWW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgZW5kX29mX2Vhcmx5X2RhdGEgYW5kIGNsb3NlX25v dGlmeSB3aWxsIGJlIG1hcmtlZCAiZmF0YWwiLg0KDQpXRk0uDQoNCk9uIDE1IE9jdG9iZXIgMjAx NiBhdCAwODowNywgS3lsZSBOZWtyaXR6IDxrbmVrcml0ekBmYi5jb20+IHdyb3RlOg0KPiBBZnRl ciBQUiAjNjI1IGFsbCBhbGVydHMgYXJlIHJlcXVpcmVkIHRvIGJlIHNlbnQgd2l0aCBmYXRhbCBB bGVydExldmVsIA0KPiBleGNlcHQgZm9yIGNsb3NlX25vdGlmeSwgZW5kX29mX2Vhcmx5X2RhdGEs IGFuZCB1c2VyX2NhbmNlbGVkLiBTaW5jZSANCj4gdGhvc2UgdGhyZWUgYWxlcnRzIGFsbCBoYXZl IHNlcGFyYXRlIHNwZWNpZmllZCBiZWhhdmlvciwgdGhlIA0KPiBBbGVydExldmVsIGZpZWxkIGlz IG5vdCBzZXJ2aW5nIG11Y2ggcHVycG9zZSwgb3RoZXIgdGhhbiBwcm92aWRpbmcgDQo+IHBvdGVu dGlhbCBmb3IgbWlzdXNlLiBXZQ0KPiAoRmFjZWJvb2spIGN1cnJlbnRseSByZWNlaXZlIGEgbnVt YmVyIG9mIGFsZXJ0cyBhdCBpbmNvcnJlY3QgbGV2ZWxzIA0KPiBmcm9tIGNsaWVudHMgKGludGVy bmFsX2Vycm9yIHdhcm5pbmcgYWxlcnRzLCBldGMuKS4gSSBwcm9wb3NlIA0KPiBkZXByZWNhdGlu ZyB0aGlzIGZpZWxkIHRvIHNpbXBsaWZ5IGltcGxlbWVudGF0aW9ucyBhbmQgcmVxdWlyZSB0aGF0 IGFueSBtaXN1c2UgYmUgaWdub3JlZC4NCj4NCj4NCj4NCj4gUFI6IGh0dHBzOi8vZ2l0aHViLmNv bS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvNjkzDQo+DQo+DQo+DQo+IEt5bGUNCj4NCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVExTIG1haWxp bmcgbGlzdA0KPiBUTFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbA0KPiBtYW5fbGlzdGluZm9f dGxzJmQ9RFFJQmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPWwyajRCamtPMExjM3U0Q0gy DQo+IHo3alB3Jm09RDZ2Z2Vqd2F2TXhvV1NlZDJBTld3a2VjV0lsYzFNbkhmZ1hmaWVqRlM4WSZz PS1mRndveGFTNFRaWE5rb1oNCj4gTTA0b0VVQ0t6MjgzZHk2UVlSdWhsT0swbVFvJmU9DQo+DQo= From nobody Mon Oct 17 10:47:14 2016 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 59BB312988A for ; Mon, 17 Oct 2016 10:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 nwGK9XCMN9I4 for ; Mon, 17 Oct 2016 10:47:10 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2798A1295C6 for ; Mon, 17 Oct 2016 10:47:10 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id j37so196262311ioo.3 for ; Mon, 17 Oct 2016 10:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pHnSqFIZYnzzvhvV8nJAYp8k8MY8eMdhsXmBbnEXbrc=; b=jbiY6Ld+n+m0dGx2KRshdfb7jBaqaxBQIH3b+LLQSd5cfEnOmwRyDx6PXM8YMdTjgt HLjahuD5aNE7nzgD2oJGR3LF/7K1t0QjgmUuf6PvgOXgVevEw3rNQ7XDzY7gGXagAFp7 Vcvqq6dlqvdve6pneq9UqhyIT8ZwhTuIUuHrgSlkV562MrSXXIf0D7kmxFaulHe2QnL7 DNYTj5XxFVxgl/MjX9m27mJ5JvA1YPS84fAn1in1zwm21tJ+JLY9qkDK+jM4dCWTJxqw ziCiy9cf5XnkndkpV4XcQNBNayEPlLJ+jNAUI0+cFOduYdaVvL/lIApjEn8HAfJHSpBQ lc9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pHnSqFIZYnzzvhvV8nJAYp8k8MY8eMdhsXmBbnEXbrc=; b=jhDXc6g9N1E+5CFWaBLn4atA3lXZmfWe1iP1lDvkAj2I0smo+J9kgwRITvxAsKn/ZC kBxiaw4PHgWJ0nLF9EZ6DBt43oUJ1S7BF0bUG0ewL9GWLG55YTqi9oFmgaVi3RcKt8nL YxtLyov9R3OZrJdIb4h7WWvttUnCV1phvBIGMdHcnaQdb7h9FvVSYmiQN9TdrFL78zA8 k942w4qy4cnW0WXZUqoNaW4uQRQI+GlOoMsqj1JxZ0ybG6JCvOYJSwg1AijPlZ1ldkU0 UEiWZ+Qvfl46KClFBROop60FcZGw62lDLuLAOVvUiL/J83XK8lIeD5OYGSVTwg3AhQlZ njZA== X-Gm-Message-State: AA6/9Rm/CAKBMy7sWQHJnEl+eTVAMLhqhMNfviDtv5BYCRdLRhjYUmDpSxRA+L9lrK3PnCP90Fm6jBZxQZhe3WJp X-Received: by 10.107.136.232 with SMTP id s101mr23534728ioi.171.1476726429266; Mon, 17 Oct 2016 10:47:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Mon, 17 Oct 2016 17:46:57 +0000 Message-ID: To: Kyle Nekritz , Martin Thomson Content-Type: multipart/alternative; boundary=001a113ec3b43fb34d053f132a8f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 17:47:12 -0000 --001a113ec3b43fb34d053f132a8f Content-Type: text/plain; charset=UTF-8 On Mon, Oct 17, 2016 at 1:34 PM Kyle Nekritz wrote: > > You are suggesting that end_of_early_data and close_notify will be > marked "fatal". > > Yes, technically they would have no alert level (since alert level is > deprecated), but as far as bytes on the wire changes with this PR, that's > correct. > > > could you expand on why it's a problem? > > Alert level is not conveying any additional information since there is one > (and only one) alert level each alert type must be sent as. Having a > separate field that does not convey additional information is only > providing an opportunity for implementations to misuse it and create subtle > bugs (for example if one implementation ignores warning level alerts, while > another incorrectly sends alerts defined as fatal at warning level). > > > This list is already missing the warning-level "unrecognized_name" > alert, and such a change would imply that all new/unrecognized alerts are > going to be treated as fatal forever (i.e. that no new warning-level alerts > can ever be defined). > > That alert is currently defined as a fatal alert (see section 6.2 in the > current draft). RFC 6066 also states "It is NOT RECOMMENDED to send a > warning-level unrecognized_name(112) alert, because the client's behavior > in response to warning-level alerts is unpredictable.", which I think > illustrates the problem. Allowing new non-fatal alerts to be added later > would require that existing clients ignore unknown warning alerts, which I > think is somewhat dangerous. > Unfortunately, while NOT RECOMMENDED, some servers do this. I do not think we'll be able to retroactively declare warning alerts nonexistent in TLS 1.2 and earlier. https://bugzilla.mozilla.org/show_bug.cgi?id=1296862 David > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Sunday, October 16, 2016 5:53 AM > To: Kyle Nekritz > Cc: tls@ietf.org > Subject: Re: [TLS] Deprecating alert levels > > I'm sympathetic to this, but just to be clear... > > You are suggesting that end_of_early_data and close_notify will be marked > "fatal". > > WFM. > > On 15 October 2016 at 08:07, Kyle Nekritz wrote: > > After PR #625 all alerts are required to be sent with fatal AlertLevel > > except for close_notify, end_of_early_data, and user_canceled. Since > > those three alerts all have separate specified behavior, the > > AlertLevel field is not serving much purpose, other than providing > > potential for misuse. We > > (Facebook) currently receive a number of alerts at incorrect levels > > from clients (internal_error warning alerts, etc.). I propose > > deprecating this field to simplify implementations and require that any > misuse be ignored. > > > > > > > > PR: https://github.com/tlswg/tls13-spec/pull/693 > > > > > > > > Kyle > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > man_listinfo_tls&d=DQIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2 > > z7jPw&m=D6vgejwavMxoWSed2ANWwkecWIlc1MnHfgXfiejFS8Y&s=-fFwoxaS4TZXNkoZ > > M04oEUCKz283dy6QYRuhlOK0mQo&e= > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113ec3b43fb34d053f132a8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 17= , 2016 at 1:34 PM Kyle Nekritz <knekr= itz@fb.com> wrote:
> You= are suggesting that end_of_early_data and close_notify will be marked &quo= t;fatal".

Yes, technically they would have no alert level (since alert level is depre= cated), but as far as bytes on the wire changes with this PR, that's co= rrect.

> could you expand on why it's a problem?

Alert level is not conveying any additional information since there is one = (and only one) alert level each alert type must be sent as. Having a separa= te field that does not convey additional information is only providing an o= pportunity for implementations to misuse it and create subtle bugs (for exa= mple if one implementation ignores warning level alerts, while another inco= rrectly sends alerts defined as fatal at warning level).

> This list is already missing the warning-level "unrecognized_name= " alert, and such a change would imply that all new/unrecognized alert= s are going to be treated as fatal forever (i.e. that no new warning-level = alerts can ever be defined).

That alert is currently defined as a fatal alert (see section 6.2 in the cu= rrent draft). RFC 6066 also states "It is NOT RECOMMENDED to send a wa= rning-level unrecognized_name(112) alert, because the client's behavior= in response to warning-level alerts is unpredictable.", which I think= illustrates the problem. Allowing new non-fatal alerts to be added later w= ould require that existing clients ignore unknown warning alerts, which I t= hink is somewhat dangerous.

Unfortunately, while NOT RECOMMENDED, some servers do this. I do n= ot think we'll be able to retroactively declare warning alerts nonexist= ent in TLS 1.2 and earlier.

David
=C2=A0
-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Sunday, October 16, 2016 5:53 AM
To: Kyle Nekritz <knekritz@fb.com>
Cc: t= ls@ietf.org
Subject: Re: [TLS] Deprecating alert levels

I'm sympathetic to this, but just to be clear...

You are suggesting that end_of_early_data and close_notify will be marked &= quot;fatal".

WFM.

On 15 October 2016 at 08:07, Kyle Nekritz <knekritz@fb.com> wrote:<= br class=3D"gmail_msg"> > After PR #625 all alerts are required to be sent with fatal AlertLevel=
> except for close_notify, end_of_early_data, and user_canceled. Since > those three alerts all have separate specified behavior, the
> AlertLevel field is not serving much purpose, other than providing
> potential for misuse. We
> (Facebook) currently receive a number of alerts at incorrect levels > from clients (internal_error warning alerts, etc.). I propose
> deprecating this field to simplify implementations and require that an= y misuse be ignored.
>
>
>
> PR: https://github.com/tlswg/tl= s13-spec/pull/693
>
>
>
> Kyle
>
>
> _______________________________________________
> TLS mailing list
> = TLS@ietf.org
> htt= ps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail > man_listinfo_tls&d=3DDQIBaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r= =3Dl2j4BjkO0Lc3u4CH2
> z7jPw&m=3DD6vgejwavMxoWSed2ANWwkecWIlc1MnHfgXfiejFS8Y&s=3D-fFw= oxaS4TZXNkoZ
> M04oEUCKz283dy6QYRuhlOK0mQo&e=3D
>
_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a113ec3b43fb34d053f132a8f-- From nobody Mon Oct 17 11:06:46 2016 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 9DA4112711D for ; Mon, 17 Oct 2016 11:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.353 X-Spam-Level: X-Spam-Status: No, score=-7.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0PQNOFhI6OGq for ; Mon, 17 Oct 2016 11:06:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A05E126D73 for ; Mon, 17 Oct 2016 11:06:42 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BFE2FC057FAD; Mon, 17 Oct 2016 18:01:02 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HI11c1023962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2016 14:01:02 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 17 Oct 2016 20:00:49 +0200 Message-ID: <3870206.scrKBWvm1A@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.6-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) In-Reply-To: <201610171326.10236.davemgarrett@gmail.com> References: <20161017170418.49DD41A564@ld9781.wdf.sap.corp> <201610171326.10236.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1864286.iiPKSO8LT2"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 17 Oct 2016 18:01:02 +0000 (UTC) Archived-At: Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 18:06:43 -0000 --nextPart1864286.iiPKSO8LT2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 17 October 2016 13:26:09 CEST Dave Garrett wrote: > On Monday, October 17, 2016 01:04:18 pm Martin Rex wrote: > > This list is already missing the warning-level "unrecognized_name" aler= t, > > and such a change would imply that all new/unrecognized alerts are going > > to be treated as fatal forever (i.e. that no new warning-level alerts > > can ever be defined). >=20 > That's already true: >=20 > https://tools.ietf.org/html/draft-ietf-tls-tls13-16#section-6 > https://tlswg.github.io/tls13-spec/#alert-protocol > "Unknown alert types MUST be treated as fatal." >=20 > Changelog says this change was made for draft 14. but unrecognized_name is defined (it's a part of MTI extension in fact), an= d=20 any value defined by a new RFC automatically becomes a known alert Not to mention that implementations are not supposed to send unknown alerts= =20 unless negotiated by extension. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1864286.iiPKSO8LT2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYBRHRAAoJEJKo0bgB0vX1K14P/3sBQmSLftvrlYGpTixpua/B kKI5Xqo8TQJ9skuTNXtr9UYAJ7ARt4wHLyHG6REs9GOusYtferfRXVXtrGqoax0s qNUr2o13eB1x25TdwkS0naXYR9uJrzHQy/FAsSugDKMP7pjkkvyYLvyw9hF0DEQv X3n6dp4QlfXHaGHMA8H3yoh9fsV1dEsXkGHlPNdMS91yGyGdDzO9bb+eh1V730AM ZKCUsypK3+t9Y58OsBLwWcTKjzRHmo25gC2ViJPSso18zJWclevhxe40AhPz+Tik dEYs98zU6OYUle10ubmD4ErSl5IvS2nsK9n6mo97crlJPKuDGbwqRo+Oqx0QbnSt H7nT07i/OdJyawrkUuckKyS+3A9nh9aSuA8cyM0VFjxyVxr5TtccwJ4+JecDOqZL N56OKbLB3M72hnXQr9EUIf1vrVEX4nXpm9ENuKQLOk3qHGQP20jYH7YtewAGlqMf B+G/gKQVXUlFZHhl2gS4m3tM4oW76NNVk2PAyM8gck/QnOoMV285n/Jep5kb0oHs caCOCRC/tm5/LwPrkBROoAMFYLPhF0zeLqRtWx5q63g9iXqdybXPkYIgq8FPgo/R 7Bwzagy24CKngErLI8i/+xphfRYajqXnEobgnGZUKWfnFReDezUubUuo2bo02i0p wHwTN6v+LmcUYy/E/hMI =pJvk -----END PGP SIGNATURE----- --nextPart1864286.iiPKSO8LT2-- From nobody Mon Oct 17 11:10:46 2016 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 CE4A2129463 for ; Mon, 17 Oct 2016 11:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no 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 7WVkpjH_Y-SK for ; Mon, 17 Oct 2016 11:10:41 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 878AD126D73 for ; Mon, 17 Oct 2016 11:10:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 094C8171AD for ; Mon, 17 Oct 2016 21:10:39 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id P889spd3NNe7 for ; Mon, 17 Oct 2016 21:10:38 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 30D262315 for ; Mon, 17 Oct 2016 21:10:38 +0300 (EEST) Date: Mon, 17 Oct 2016 21:10:30 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] New review through the TLS 1.3 Editor's Copy 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: Mon, 17 Oct 2016 18:10:44 -0000 Did a new review of the document, given that stuff from the older review got addressed. Consulted the older review when making this, but not the issue lists: > EncryptedExtensions. > : responses to any extensions that are not required to > determine the cryptographic parameters. [{{encrypted-extensions}}] Also, with Certificate extensions, the extensions here need to not be specific to a certificate or certificate chain. > Finally, the client and server exchange Authentication messages. TLS > uses the same set of messages every time that authentication is needed. > Specifically: > > Certificate. > : the certificate of the endpoint. This message is omitted if the > server is not authenticating with a certificate. Note that if raw > public keys {{RFC7250}} or the cached information extension > {{?RFC7924}} are in use, then this message will not > contain a certificate but rather some other value corresponding to > the server's long-term key. [{{certificate}}] This is also omitted for client if CertificateRequest was not sent, right? > CertificateVerify. > : a signature over the entire handshake using the public key > in the Certificate message. This message is omitted if the > server is not authenticating via a certificate. [{{certificate-verify}}] Same as above. And additionally, for client, doesn't sending an empty certificate omit this? > ## Zero-RTT Data > > With the Zero-RTT mode, clients can send data on their first flight > ("early data") whereby the client uses a PSK either obtained > out-of-band or as a ticket (i.e., one with the "early_data_info" > extension) from an earlier exchange to authenticate to the server. > > When clients use a PSK obtained out-of-band then the following > information MUST be provisioned to both parties: > > * The PSK identity > * The cipher suite for use with this PSK > * The key exchange and authentication modes this PSK is allowed to be used with > * The Application-Layer Protocol Negotiation (ALPN) label(s) > * The Server Name Indication (SNI), if any is to be used The ALPN labels can't be plural. There must (nothing else will work) be a single ALP (possibly being the implicit default ALP) for any 0-RTT- capable PSK. Also, AFAIK, the reason why ticket_age exists in PSK is to support 0-RTT anti-replay. Without 0-RTT data, there is no point in using anything that doesn't involve server-side contribution anyway (and thus would get superrior security properties). > 2. There are no guarantees of non-replay between connections. > Unless the server takes special measures outside those provided by TLS, > the server has no guarantee that the same > 0-RTT data was not transmitted on multiple 0-RTT connections > (See {{replay-time}} for more details). > This is especially relevant if the data is authenticated either > with TLS client authentication or inside the application layer > protocol. However, 0-RTT data cannot be duplicated within a connection (i.e., the server > will not process the same data twice for the same connection) and > an attacker will not be able to make 0-RTT data appear to be > 1-RTT data (because it is protected with different keys.) Of course, if the server TLS library provodes the difference between 0-RTT and 1-RTT data is a different matter... > ## Decoding Errors > > TLS defines two generic alerts (see {{alert-protocol}}) to use upon failure to parse > a message. Peers which receive a message which cannot be parsed according to the syntax > (e.g., have a length extending beyond the message boundary or contain an out-of-range > length) MUST terminate the connection with a "decoding_error" alert. Peers which receive > a message which is syntactically correct but semantically invalid (e.g., a DHE share of p - 1) > MUST terminate the connection with an "illegal_parameter" alert. What alert is used if some field is an non-extensible enumeration and the value transmitted is outside the legal values? E.g. An unknown max_fragment_length value. I have used illegal_parameter for errors like this. Also, isn't the alert name decode_error, not decoding_error? > ### Client Hello > > In the event that a client requests additional functionality using > extensions, and this functionality is not supplied by the server, the > client MAY abort the handshake. Note that TLS 1.3 ClientHello messages > MUST always contain extensions, and a TLS 1.3 server MUST respond to > any TLS 1.3 ClientHello without extensions or with data following > the extensions block with a "decode_error" > alert. TLS 1.3 servers may receive TLS 1.2 ClientHello messages > without extensions. If negotiating TLS 1.2, a server MUST check that > the message either contains no data after legacy_compression_methods > or that it contains a valid extensions block with no data following. > If not, then it MUST abort the handshake with a "decode_error" alert. Note that it is now impossible to receive a TLS 1.3 ClientHello without extensions (any such would be interpretted as TLS 1.2 ClientHello without extensions). > ### Server Hello > > version > : This field contains the version of TLS negotiated for this session. Servers > MUST select the lower of the highest supported server version and the version > offered by the client in the ClientHello. In particular, servers MUST accept > ClientHello messages with versions higher than those supported and negotiate > the highest mutually supported version. For this version of the > specification, the version is { 3, 4 }. (See {{backward-compatibility}} for > details about backward compatibility.) Err, don't they have to select highest client indicated version that they support (now that version negotiation is with extensions)? > ## Hello Extensions > > An extension type MUST NOT appear in the ServerHello or HelloRetryRequest > unless the same extension type appeared in the corresponding ClientHello. > If a client receives an extension type in ServerHello or HelloRetryRequest > that it did not request in the associated ClientHello, it MUST abort the > handshake with an "unsupported_extension" fatal alert. Add note that Cookie is an exception to this? > When multiple extensions of different types are present in the ClientHello or > ServerHello messages, the extensions MAY appear in any order. There MUST NOT be > more than one extension of the same type. pre_shared_key is an exception to this in ClientHello, right? > In general, the specification of each extension type needs to describe the > effect of the extension both during full handshake and session resumption. Most > current TLS extensions are relevant only when a session is initiated: when an > older session is resumed, the server does not process these extensions in > ClientHello, and does not include them in ServerHello. However, some > extensions may specify different behavior during session resumption. > [[TODO: update this and the previous paragraph to cover PSK-based resumption.]] Basically, treating any extension specially with regards to full handshake versus "resumption" is very likely to be a Bad Idea and there should be good justifications on doing so. (Such difference would likely be a major source of implementation bugs.) > ### Signature Algorithms > > The client uses the "signature_algorithms" extension to indicate to the server > which signature algorithms may be used in digital signatures. Clients which > desire the server to authenticate via a certificate MUST send this extension. > If a server > is authenticating via a certificate and the client has not sent a > "signature_algorithms" extension then the server MUST > abort the handshake with a "missing_extension" alert > (see {{mti-extensions}}). > > Servers which are authenticating via a certificate MUST indicate so > by sending the client an empty "signature_algorithms" extension. This looks to be a Bad Idea. It was to support that poorly tought-out server certificate authentication in PSK mode, right? Basically, offering any means (even if there is "MUST" to "prevent" the use) of disabling server authentication in non-PSK mode is a footgun. > ### Negotiated Groups > > As of TLS 1.3, servers are permitted to send the "supported_groups" > extension to the client. If the server has a group it prefers to the > ones in the "key_share" extension but is still willing to accept the > ClientHello, it SHOULD send "supported_groups" to update the client's > view of its preferences; this extension SHOULD contain all groups > the server supports, regardless of whether they are currently > supported by the client. Clients MUST NOT act upon any information > found in "supported_groups" prior to successful completion of the > handshake, but MAY use the information learned from a successfully > completed handshake to change what groups they offer to a server in > subsequent connections. This means altering the set of key shares they offer to the server, right? Not the set of groups they indicate as supported? > ### Key Share > > Upon receipt of this extension in a HelloRetryRequest, the client MUST first > verify that the selected_group field corresponds to a group which was provided > in the "supported_groups" extension in the original ClientHello. It MUST then > verify that the selected_group field does not correspond to a group which was > provided in the "key_share" extension in the original ClientHello. If either of > these checks fails, then the client MUST abort the handshake with an > "illegal_parameter" alert. Otherwise, when sending the new ClientHello, the > client MUST append a new KeyShareEntry for the group indicated in the > selected_group field to the groups in its original KeyShare. The remaining > KeyShareEntry values MUST be preserved. Err... Hasn't the KeyShare behaviour been changed from "append" to "replace"? > ### Pre-Shared Key Extension > > obfuscated_ticket_age > : For each ticket, the time since the client learned about the server > configuration that it is using, in milliseconds. This value is > added modulo 2^32 to with the "ticket_age_add" value that was > included with the ticket, see {{NewSessionTicket}}. This addition > prevents passive observers from correlating sessions unless tickets > are reused. Note: because ticket lifetimes are restricted to a > week, 32 bits is enough to represent any plausible age, even in > milliseconds. External tickets SHOULD use an obfuscated_ticket_age of > 0; servers MUST ignore this value for external tickets. The comment above about purpose of ticket_age also applies here. > ### Pre-Shared Key Exchange Modes > > In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" > extension. The semantics of this extension are that the client only > supports the use of PSKs with these modes, which restricts both the > use of PSKs offered in this ClientHello and those which the server > might supply via NewSessionTicket. Why is this a separate extension and not part of pre_shared_key, given that if the latter is present, this must be too? Seems like more complexity for absolutely no reason. I would understand if this extension was optional if PSK is present, but it is not. > ### Early Data Indication > > When PSK resumption is used, the client can send application data > in its first flight of messages. If the client opts to do so, it MUST > supply an "early_data" extension as well as the "pre_shared_key" > extension. Can't early data now be used with any type of PSK, not just ones provisioned by NewSessionTicket? > A server MUST validate that the ticket age for the selected PSK > identity (computed by un-masking PskIdentity.obfuscated_ticket_age) > is within a small tolerance of the time since the ticket was > issued (see {{replay-time}}). If it is not, the server SHOULD proceed > with the handshake but reject 0-RTT, and SHOULD NOT take any other action > that assumes that this ClientHello is fresh. PSKs that are externally provisioned don't have any valid ticket age... > In order to accept early data, the server server MUST have accepted a > PSK cipher suite and selected the the first key offered in the > client's "pre_shared_key" extension. In addition, it MUST verify that > the following values are consistent with those negotiated in the > connection during which the ticket was established. > > - The TLS version number, AEAD algorithm, and the hash for HKDF. > - The selected ALPN {{!RFC7443}} value, if any. Actually, it must verify that the record protection matches, not just the HKDF. > ## Server Parameters > > The same extension types MUST NOT appear in both the ServerHello and > EncryptedExtensions. All server-sent extensions other than those explicitly > listed in {{server-hello}} or designated in the IANA registry MUST only > appear in EncryptedExtensions. Extensions which are designated to > appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients > MUST check EncryptedExtensions for the presence of any forbidden > extensions and if any are found MUST abort the handshake with an > "illegal_parameter" alert. Also there are extensions in Certificates as well... > #### Receiving a Certificate Message > > Any endpoint receiving any certificate signed using any signature algorithm > using an MD5 hash MUST abort the handshake with a "bad_certificate" alert. > SHA-1 is deprecated and it is RECOMMENDED that > any endpoint receiving any certificate signed using any signature algorithm > using a SHA-1 hash abort the handshake with a "bad_certificate" alert. > All endpoints are RECOMMENDED to transition to SHA-256 or better as soon > as possible to maintain interoperability with implementations > currently in the process of phasing out SHA-1 support. These requirements are problematic, and I have absolutely no intention of ever implementing this in my TLS libs. They treat signatures involving MD5 or SHA1 the same as unknown signature algorithm (which is not a fatal error). To be clear, MD5 (and SHOULD for SHA-1) signatures are absolutely not to be trusted. But those should be treated as unknown with no special handling. Also, if there are self-signed certs, the self-signature is just to be ignored. There are still CA root certs out there with MD5 signatures. > %%% Authentication Messages > If sent by a server, the signature algorithm MUST be one offered in the > client's "signature_algorithms" extension unless no valid certificate chain can be > produced without unsupported algorithms (see {{signature-algorithms}}). This is seemingly about server signatures. In that context, an unknown algorithm has absolutely no chance of working. > ### New Session Ticket Message {#NewSessionTicket} > > Any ticket MUST only be resumed with a cipher suite that is identical > to that negotiated connection where the ticket was established. This kind of requirement is problematic when "external" PSKs have requirement that just the hash matches. (Implementation bugs). -Ilari From nobody Mon Oct 17 11:16:51 2016 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 2EE5C12988A for ; Mon, 17 Oct 2016 11:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.353 X-Spam-Level: X-Spam-Status: No, score=-7.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KnC9pNloo-xZ for ; Mon, 17 Oct 2016 11:16:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A35129457 for ; Mon, 17 Oct 2016 11:16:49 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4B5C4693F2; Mon, 17 Oct 2016 18:07:05 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HI73ik007458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2016 14:07:05 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 17 Oct 2016 20:07:03 +0200 Message-ID: <3984825.SvkiBS79En@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.6-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3221699.ZAhIOHdloz"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 17 Oct 2016 18:07:05 +0000 (UTC) Archived-At: Subject: Re: [TLS] Deprecating alert levels 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: Mon, 17 Oct 2016 18:16:50 -0000 --nextPart3221699.ZAhIOHdloz Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 17 October 2016 17:34:05 CEST Kyle Nekritz wrote: > Allowing new non-fatal alerts to be added later > would require that existing clients ignore unknown warning alerts, which I > think is somewhat dangerous. but the standard doesn't say that you need to ignore unknown warning level= =20 alerts it says that any unknown alerts, irrespective of their level MUST be=20 considered fatal =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart3221699.ZAhIOHdloz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYBRNHAAoJEJKo0bgB0vX1ndcP/3BTKbQ18TRZ+rUvURGYOJ0C yU7lPrLYXrXeVp8eLEf6MN3qLa+fxkrOJnJsPTFxndGl/Yn9rd6PrNBV5P8Ooviq n0EFi4vJsU3b8hZ0V2m4OU00VVY/+Wpli/t8rg8Gm1fhwd40dUUwPyxgXK8ioT6P Usm4+tRxoK9EdYhUJ1WUAzpsK0TT7hLoYHTVbEFUuY9FQ0CNYlvJe80GOF4aCU+R 7HT6dBjoPM1AHL0fpUKaN+DpStKVeXKdoV/T/fHdYRMIH3Dh4h8ujP31hQ2pmv7k JbYNUnS042cbJtmeJz+zVO7NuuzJy0YbUmbgiuLRDK96nR9TLuOnfktEAIIg5w7J 4i4ptVeQlrIn8/8zoNtDjq3IjChcZsTQFT0mcx1dwzz2IZzy3XaymbagEBIztSYD WlcI/1+CI4s4R3hpNl1gtCp6D+J32KcvCVkp8MKmvdBUuQmTO93sS4jNRBCilvI4 wYDWOj5eJWHyYRUT+HgbzNFiXTsjXbG2JdPXKKrHu60JAXWC7LKtxuLFfNjSX0RS kinxsrep99ZfNqT/ueDQRJJHg30dIQ7u6P+nTsEO0Lc8gZ454jbjq+pr3q1Vkc35 kEABe+FDPr3HL0lq3r9gbQDQRT8iUwvKmfwjeLtXqTTq0MDNpCY+LqilVlL0u53D OahX0JVTaZ3IOQAl7Nr1 =Pp1q -----END PGP SIGNATURE----- --nextPart3221699.ZAhIOHdloz-- From nobody Mon Oct 17 12:04:35 2016 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 B95FA129856; Mon, 17 Oct 2016 12:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nN3ulF_dhZuw; Mon, 17 Oct 2016 12:04:27 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4551297CB; Mon, 17 Oct 2016 12:04:27 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m138so59524682itm.0; Mon, 17 Oct 2016 12:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wOnPgxvjYk57wLKis8y/ajAIFeMzqJ5PjDGtGFsRq7o=; b=uNcx4MBVUr26+72sg2plVGwNFVuv3zwmvPzhju/hZFV5Epdl0M1RB2b43ctMpxLpDH U6FD1XBo1KhW3424CGbD2KeWu6VgcQcRYDRInItDgV3S5yJL534ip+gMSBWdHdDsfsrw HVUrirh6O+HR29VMUqyuoJQbidiQg53LbYa97gKUFA8NAA+ESapPSI2QGXcQtYAdBpVW YalHvEvMT1PoECVwFAmbdQXkiY7ZrgjqOwa2xlPiEgUBOt3EJXRARswAUNJ6CaOUzHI7 i0Cl9tsSyPU9UYZ/cXIC+GXSVB/KhDQQh8BuqB6DoaIYgTIIX4AmcwtJp4tqI/i/gDu2 i0ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wOnPgxvjYk57wLKis8y/ajAIFeMzqJ5PjDGtGFsRq7o=; b=Ak2F/3U0KgwYrJthoWHNge4YW66XLFBl4Qw4XQjUCSnslya8aCIy4L1GWQh1NWArjo 2E/PgRn0teHwkdatwYpzLOw9Wc8Ut8qp4loU2KBY7mpjBMoNJAzOstlOdMqEzt26gaxt qU6vd+geWEUgqFPHE5FUsLebI3Nl/M3+wDIJUmr+Rn8rEo9M8DRkPx0//QibxtXVdAX9 P65Y/papzL+SnXkREaItjaN5xbNSnNSxiZgpXk2T6bphQhgIqG4noSXkQKebpQbGgWnN L70NB2EbNCQi6w9phXEqMBHtnkV+KUwJl+Lzp9XYthnmlFEBW5P8Y+D0kMQ3tLzPQEUq Vnew== X-Gm-Message-State: AA6/9Rk49bQC2z1YewpeFiRcYgzQ74G0N+uetvlQpl960i4ZN7VTom8lBKuhWaijLcqH+httNcUkJ+0dZtEu/g== X-Received: by 10.36.90.202 with SMTP id v193mr10047820ita.120.1476731066107; Mon, 17 Oct 2016 12:04:26 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 17 Oct 2016 12:04:25 -0700 (PDT) In-Reply-To: <560A7514-572F-4391-9348-40E42DE7DFCC@vigilsec.com> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> <560A7514-572F-4391-9348-40E42DE7DFCC@vigilsec.com> From: Daniel Migault Date: Mon, 17 Oct 2016 15:04:25 -0400 X-Google-Sender-Auth: nemMv8cefk4u0ovMQy3HsO7MqSE Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, "dtls-iot@ietf.org" Content-Type: multipart/alternative; boundary=001a1145c51c9fcd5c053f143e67 Archived-At: Cc: IETF TLS Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead 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: Mon, 17 Oct 2016 19:04:30 -0000 --001a1145c51c9fcd5c053f143e67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We are discussing in the TLS wg assignment points for TLS PSK authentication. We would like to understand if there is a specific interest of the IoT community for the following suites. TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}; TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}; Additional question might be whether AES_256_CCM_8_SHA384 is of interest for an IoT use case. Any feed back is appreciated. please provide them by the end of the week! BR, Daniel On Mon, Oct 17, 2016 at 12:08 PM, Russ Housley wrote= : > I would like to see these included: > > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x01}; > TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x02}; > > > I am fine with including these as well if someone wants to use them: > > TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x05}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x06}; > > > I do not really see a reason to include the ones with the shorter MAC: > > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}; > > > Russ > > > On Oct 17, 2016, at 12:03 PM, Daniel Migault > wrote: > > Hi, > > I am not clear what the consensus is for the following points. Is there > any consensus for requesting the following ones? > > BR, > Daniel > > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x01}; > TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x02}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x05}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x06}; > > > > On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson > wrote: > >> I'm mainly just looking to economize on different configurations. >> >> On 9 October 2016 at 16:32, John Mattsson >> wrote: >> > Hi Martin, >> > >> > >> > AES_256_CCM_8 was not in the first versions of the draft but added lat= er >> > after request from IoT people (probably afraid of quantum computers). >> > >> > >> > While I think it makes very much sense to have short tags in wireless >> > radio, I do not know how large need there is for AES-256 in IoT for >> > constrained devices, or how large the need would be to truncate the ta= g >> in >> > these cases. >> > >> > >> > My current understanding is that Grover=E2=80=99s algorithm may never = be more >> > cost-effective than a cluster of classical computers, and that quantum >> > computers therefore likely do not affect the lifetime of AES-128. >> > >> > >> > I do not have any strong opinions regarding keeping AES_256_CCM_8 or >> not. >> > We should not give the impression that AES-256 is needed for practical >> > resistance to quantum computers anytime soon, it is however a >> requirement >> > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM see= ms >> > like the best choices in most cases. >> > >> > >> > Cheers, >> > John >> > >> > >> > >> > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" < >> tls-bounces@ietf.org >> > on behalf of martin.thomson@gmail.com> wrote: >> > >> >>Looking at those emails, I am prompted to wonder if anyone can justify >> >>the existence of a ciphersuite with a double-sized key and half-sized >> >>authentication tag. RFC 6655 doesn't really explain how that is a >> >>useful thing. >> >> >> >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos >> >>wrote: >> >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: >> >>>> All, >> >>>> >> >>>> We've received a request for early IANA assignments for the 6 ciphe= r >> >>>> suites listed in https://datatracker.ietf.org/d >> oc/draft-ietf-tls-ecdh >> >>>> e-psk-aead/. Please respond before August 23rd if you have concern= s >> >>>> about early code point assignment for these cipher suites. >> >>> >> >>> I have previously raised an issue [0] on these ciphersuites. The sam= e >> >>> requirement was noted also by Peter Dettman as something special in >> >>> [1]. However, there has been no reaction from the authors (now in CC= ). >> >>> >> >>> regards, >> >>> Nikos >> >>> >> >>> [0]. >> >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ >> >>> [1]. >> >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds >> >>> >> >>> _______________________________________________ >> >>> TLS mailing list >> >>> TLS@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/tls >> >> >> >>_______________________________________________ >> >>TLS mailing list >> >>TLS@ietf.org >> >>https://www.ietf.org/mailman/listinfo/tls >> > >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1145c51c9fcd5c053f143e67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We are discussing in the = TLS wg assignment points for TLS PSK authentication. We would like to under= stand if there is a specific interest of the IoT community for the followin= g suites.

TLS_ECDHE_PSK_WITH_AES_128_= CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03};
TLS_ECDHE_PSK_WITH_AES_256_= CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04};

= Additional question might be whether AES_256_CCM_8_SHA384 is of interest for an IoT use = case.

Any feed back is appreciated. please provide= them by the end of the week!

BR,
Daniel



On Mon, Oct 17,= 2016 at 12:08 PM, Russ Housley <housley@vigilsec.com> wr= ote:
I would like to see these included:

=
TLS_= ECDHE_PSK_WITH_AES_128_GCM_SHA256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0= ,0x01};
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384=C2=A0=C2=A0 =3D {0xTB= D; 0xTBD} {0xD0,0x02};

I am fine wi= th including these as well if someone wants to use them:

= TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {= 0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0=C2=A0 =3D {= 0xTBD; 0xTBD} {0xD0,0x06};

I do not= really see a reason to include the ones with the shorter MAC:

TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0= x03};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0= xD0,0x04};

=
Russ


On Oct 17, 2016, at 12:03 PM, Dani= el Migault <daniel.migault@ericsson.com> wrote:

Hi,

I am not clear what the consensus is fo= r the following points. Is there any consensus for requesting the following= ones?

BR,
Daniel

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA= 256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0,0x01};
TLS_ECDHE_PSK_WITH_AES_2= 56_GCM_SHA384=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0,0x02};
TLS_ECDHE= _PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03};
TLS_= ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04};TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} = {0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0=C2=A0 =3D = {0xTBD; 0xTBD} {0xD0,0x06};


On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson = <martin.thomson@gmail.com> wrote:
I'm mainly just looking to economize = on different configurations.

On 9 October 2016 at 16:32, John Mattsson <john.mattsson@ericsson.com> wrote= :
> Hi Martin,
>
>
> AES_256_CCM_8 was not in the first versions of the draft but added lat= er
> after request from IoT people (probably afraid of quantum computers).<= br> >
>
> While I think it makes very much sense to have short tags in wireless<= br> > radio, I do not know how large need there is for AES-256 in IoT for > constrained devices, or how large the need would be to truncate the ta= g in
> these cases.
>
>
> My current understanding is that Grover=E2=80=99s algorithm may never = be more
> cost-effective than a cluster of classical computers, and that quantum=
> computers therefore likely do not affect the lifetime of AES-128.
>
>
> I do not have any strong opinions regarding keeping AES_256_CCM_8 or n= ot.
> We should not give the impression that AES-256 is needed for practical=
> resistance to quantum computers anytime soon, it is however a requirem= ent
> for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM see= ms
> like the best choices in most cases.
>
>
> Cheers,
> John
>
>
>
> On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <tls-bounces@ietf.org=
> on behalf of martin.thomson@gmail.com> wrote:
>
>>Looking at those emails, I am prompted to wonder if anyone can just= ify
>>the existence of a ciphersuite with a double-sized key and half-siz= ed
>>authentication tag.=C2=A0 RFC 6655 doesn't really explain how t= hat is a
>>useful thing.
>>
>>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos <nmav@redhat.com>
>>wrote:
>>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
>>>> All,
>>>>
>>>> We've received a request for early IANA assignments fo= r the 6 cipher
>>>> suites listed in https://datatr= acker.ietf.org/doc/draft-ietf-tls-ecdh
>>>> e-psk-aead/.=C2=A0 Please respond before August 23rd if yo= u have concerns
>>>> about early code point assignment for these cipher suites.=
>>>
>>> I have previously raised an issue [0] on these ciphersuites. T= he same
>>> requirement was noted also by Peter Dettman as something speci= al in
>>> [1]. However, there has been no reaction from the authors (now= in CC).
>>>
>>> regards,
>>> Nikos
>>>
>>> [0].
>>>https://mailarchive= .ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
>>> [1].
>>>https://mailarchive= .ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/tls=
>>
>>_______________________________________________
>>TLS mailing list
>>TLS@ietf.org<= br> >>https://www.ietf.org/mailman/listinfo/tls<= br> >

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

_______________________________________________
TLS mailing listTLS@ietf.org
https:/= /www.ietf.org/mailman/listinfo/tls


_______________________________________________=
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a1145c51c9fcd5c053f143e67-- From nobody Mon Oct 17 12:18:51 2016 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 48D571294DB for ; Mon, 17 Oct 2016 12:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nFZaEo4hp7G8 for ; Mon, 17 Oct 2016 12:18:49 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E552C129412 for ; Mon, 17 Oct 2016 12:18:48 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id n189so253226327qke.0 for ; Mon, 17 Oct 2016 12:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=ARvkgkLd+vJiYIBAuAk040AlChi/NSRJqcacvBeHcIY=; b=iHCjNN5qQlTNvz9GO4cP0+EP6DFIhCYwRn8qi+KgXcp0IXF8j6oVn0XA0J4QKPDwvH h60fii1A84T1umLypVUEJ97AiuiLkEDsOWXm+NCrnPytGv4f+13lBPp7E8t5BYwQaHH+ z3RZd/Tz5tvBsNSOSJGneNF6nt/QKroVYl8rqFOG8LprJ0Lk03+VEaHqgdjh6kh8bOqU sarL4W9wQTZ3Bjj+0+8oBtqmFBvYgT2a4Rn8iMjzC1XAMfMgL/KstNJMZiv1PCxgNBKB t5HQsvT+rRVVaCIkvrAeOX/8rB7XkQZ+jknvnkhe5eF1QcqiC9EGcs6Zz58OuqPkUZ7V jObA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=ARvkgkLd+vJiYIBAuAk040AlChi/NSRJqcacvBeHcIY=; b=lQTEHtkEQ8oU+SI9JQrGBj8e4D9geLflKFnX6k60t5SpIqhodflDqox3w36H/ytSuy HRxIhqmoMS6g8Tr1pPxsyqeIz1bXCySt5b+L41g+8lTgnD9rm1Pjb07ie3hxgx+q9jte XSYdoAZ/hGT3TLCPF9+z/FXyV0ITa/eDokGE+aH2mg5tIrZEky3EvE4Jkn6vY7Ef5CJd S3IeftyAUBKQA1s1DtOwtZOVdqgWvs6fXfNs53Pdvroa5c+QxNfF11LlmsieLcb3FKTt i6mvITIxt91N8IMf/7l+3tPlLPxgCZ8z/aCcBSPhEMuG4dKufrTW605fXu1ipYF/vI7r jkIQ== X-Gm-Message-State: AA6/9RkIqpBABsjNqC4GOnuoUV4kIdRh3KFTw7JgOk0kqADcvN/iroZzWO2TSwUpigUfgQ== X-Received: by 10.55.183.2 with SMTP id h2mr14149409qkf.134.1476731916554; Mon, 17 Oct 2016 12:18:36 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id p13sm5285195qtp.20.2016.10.17.12.18.36 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 17 Oct 2016 12:18:36 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Ilari Liusvaara Date: Mon, 17 Oct 2016 15:18:34 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201610171518.35092.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] New review through the TLS 1.3 Editor's Copy 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: Mon, 17 Oct 2016 19:18:50 -0000 On Monday, October 17, 2016 02:10:30 pm Ilari Liusvaara wrote: > > %%% Authentication Messages > > > If sent by a server, the signature algorithm MUST be one offered in the > > client's "signature_algorithms" extension unless no valid certificate chain can be > > produced without unsupported algorithms (see {{signature-algorithms}}). > > This is seemingly about server signatures. In that context, an > unknown algorithm has absolutely no chance of working. This came up in a discussion a while back and we decided to allow unsupported algorithms as a last-ditch fall-back. Opportunistic encryption might not care and there are systems that may trust certs as a whole, not caring about the signatures. The end result is that the client should be tasked with making the decision to accept or reject, not the server. Also can be helpful for debugging. Dave From nobody Mon Oct 17 12:42:10 2016 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 C126C12989C for ; Mon, 17 Oct 2016 12:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no 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 aHaxn76tMKHM for ; Mon, 17 Oct 2016 12:42:08 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC91297C9 for ; Mon, 17 Oct 2016 12:42:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 5BC86170AB; Mon, 17 Oct 2016 22:42:06 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id rkRbV9bUD6Ko; Mon, 17 Oct 2016 22:42:06 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 0E3EF2310; Mon, 17 Oct 2016 22:42:06 +0300 (EEST) Date: Mon, 17 Oct 2016 22:41:58 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20161017194158.GA26690@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> <201610171518.35092.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201610171518.35092.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New review through the TLS 1.3 Editor's Copy 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: Mon, 17 Oct 2016 19:42:10 -0000 On Mon, Oct 17, 2016 at 03:18:34PM -0400, Dave Garrett wrote: > On Monday, October 17, 2016 02:10:30 pm Ilari Liusvaara wrote: > > > %%% Authentication Messages > > > > > If sent by a server, the signature algorithm MUST be one offered in the > > > client's "signature_algorithms" extension unless no valid certificate chain can be > > > produced without unsupported algorithms (see {{signature-algorithms}}). > > > > This is seemingly about server signatures. In that context, an > > unknown algorithm has absolutely no chance of working. > > This came up in a discussion a while back and we decided to allow > unsupported algorithms as a last-ditch fall-back. Opportunistic > encryption might not care and there are systems that may trust > certs as a whole, not caring about the signatures. The end result > is that the client should be tasked with making the decision to > accept or reject, not the server. Also can be helpful for debugging. The only possible way stuff like this is going to work is for the client either ignores Certificate/CertificateVerify entierely (can't trust the certificate via any method) or if the client has serious security bug. While e.g. trusting the server by SPKI does bypass any and all signatures in certificates, it does not bypass this server signature. -Ilari From nobody Mon Oct 17 13:09:17 2016 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 EE8901298AB for ; Mon, 17 Oct 2016 13:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 7bpf5HNGHATP for ; Mon, 17 Oct 2016 13:09:14 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798C91298A4 for ; Mon, 17 Oct 2016 13:09:14 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id t192so125276450ywf.0 for ; Mon, 17 Oct 2016 13:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=dEUJyDvDlrmCoxorPftnNbnM3zG9yR1PkqShY0z2nqQ=; b=yJYFmiO7w0+v2y2cxY/U5xlelfmC8Skc5QMHDqB9qrQpCeG7Z+wbfL6umqVMRy5H5F Vqm7LlUQn91eUzssuBoXlK2PokEOhWeg1ax+8OZJJ8+c04SP4WyjdzyTpVrTtljqpn+t J3uo5/pFUtQVv9CjAh4gQ0D5IFGEh+VgnxZyjsJoXNQpLbHgtVhsq+4ps2auZEz5qqCb AQ33r2axKk61jc2fWotABu9pWLwnhvi6DCErDXbMx/+iB8DJ1sXRcxf5+IEH97ZVo1qJ Qhg0tySI7hz9v70OVzBrb5bLzlxXwluuqoZU5+WKwLrt5j/VWqyvtTosfvWhxLQnij11 3I+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dEUJyDvDlrmCoxorPftnNbnM3zG9yR1PkqShY0z2nqQ=; b=bVphhOp9iW4+e5BQJazuKzYPXBpPXMyi606cPtSY3PjcvhbQkjCrBEjc3rNDGJ7LiW fZicSCRl5dEhtIIS+uZTXHXE0HRoa9o6pnhNo3DD10N9e0ICbmrQQ1QBNXSCwaNQiEUq +KOHOZMlsKe3yrxu53/UASpUuR/iCuYCEoHWCUU1l9bAJIVSQPC1RJgpHzkQnmkwh4Kd QRomf1v/YjUELIpMH7ZEYWCpvq+ScIDGDDlRdo6isojk9C/RpAoE0UjMBUAeGuZMK6+y xOmAJGYZCz5ODOUl3hFKpHsWy7uAZrHHVzEChjUz5fWLNB1alc8KZPdH0w3bOz4Ff3Fu SPlQ== X-Gm-Message-State: AA6/9RmDx1cgULafCw54yndAK3XM4a575VhTKUKXdA8PZ2f5ZVtWBAet1PVCtTYeve79GaTVKCkJ8+qkyM5u1w== X-Received: by 10.129.53.206 with SMTP id c197mr25218866ywa.205.1476734953548; Mon, 17 Oct 2016 13:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Mon, 17 Oct 2016 13:08:33 -0700 (PDT) From: Eric Rescorla Date: Mon, 17 Oct 2016 16:08:33 -0400 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11421a26559fcb053f1526aa Archived-At: Subject: [TLS] PR #699: Simplify traffic key expansion 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: Mon, 17 Oct 2016 20:09:16 -0000 --001a11421a26559fcb053f1526aa Content-Type: text/plain; charset=UTF-8 Hi folks, https://github.com/tlswg/tls13-spec/pull/699/files A while back Steven Valdez pointed out that now that we have the PSK binder change and dual key ladders, each set of traffic keys is generated from a different base secret which has a label folded in [0], so we don't need to have the "phase" parameter in the traffic key calculation in Section 7.3, which simplifies things a bit. Due to an oversight, this didn't make it into the PR, but it seems straightforward. Please let me know ASAP if I have missed something here or you otherwise object. -Ekr [0] client_early_traffic_secret, [sender]_handshake_traffic_secret, [sender]_traffic_secret_N respectively --001a11421a26559fcb053f1526aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,


A while b= ack Steven Valdez pointed out that now that we have the PSK binder
change and dual key ladders, each set of traffic keys is generated from a= different
base secret which has a label folded in [0], so we don= 't need to have the "phase" parameter in the traffic key calc= ulation in Section 7.3, which simplifies things
a bit. Due to an = oversight, this didn't make it into the PR, but it seems
stra= ightforward.

Please let me know ASAP if I have mis= sed something here or you otherwise
object.

<= div>-Ekr


[0] client_early_traffic_s= ecret, [sender]_handshake_traffic_secret, [sender]_traffic_secret_N re= spectively
--001a11421a26559fcb053f1526aa-- From nobody Mon Oct 17 13:25:12 2016 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 583DA129492 for ; Mon, 17 Oct 2016 13:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 dsfFVRE_c22b for ; Mon, 17 Oct 2016 13:25:08 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B942012948D for ; Mon, 17 Oct 2016 13:25:08 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id e187so15500081itc.1 for ; Mon, 17 Oct 2016 13:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UzDUIXq82W0JuY9VB5jXEk6wCaL+ZmnkZJjcVNbl3g4=; b=XRPosAvajiNFBJe6mbGR2SmyVWuhPbZvIS/9SUlCQ9ltuEDh0l/4b9bdhgVUEAfQ25 tE0O3hVKFxx+5/b7U4IT6Minb+6wloUfcJwd0XUp+kbU5Q7kyg6QNMtRnjJK9PDQgFzi EELZIMHewdBLbGxskUvyJoo7xTKvmcPgBjxEqUsYxNsxFKigxn44KpWplYfUWa5Ozq5s D2OETDerhcK+naZqdN53KrcN9kQfh3Alzc3kzCD5IwKpqZB0EYIiGvy+3C59NyVECHSs ojah/yeBpYT7GRqe3k4+fC+vHcdhCselYperynxmCWAHF/qOklYr3PqMfxDHmzB/sO92 xxHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UzDUIXq82W0JuY9VB5jXEk6wCaL+ZmnkZJjcVNbl3g4=; b=miGFTiFL31yGddlvR7AbCINEGsHiJSmnUpT5HBghMakiaAy0v6ml6sklNSCtWzg/dX mr6WqeYxKhA6uMR0c5Gl4VUfoFQRhypIFya3Un2lp00zDZoN/81on0Ypg91qE+HvrP5k uf6ZFCfu2H00cS1kdmmyFaxPvxWmkaQ4dJAjnTGPvYXQuIZiyZNXWf6ChszuriWuEuzc 9BCOAf4ilMGhEELA6/Yhv1UNJaB+p3W+z3anzKJ2rOZlgaWIBNOjMVfqwv7tIOTZbTqf wnTwPlWnQ5ZZwAo8dWhvo0jVppYpRJ+vgDY0smLih5DiXbbw+drF0PgHwrwTrxckw5My 4wLQ== X-Gm-Message-State: AA6/9RmDD7s3NSDEvLZbqEq+4lfXu5EWjTvcKi64am0LDX+FzxpLgjv7mWeY1EohWdaol9QbFJQuqD3eprPn4A== X-Received: by 10.36.29.14 with SMTP id 14mr10223441itj.117.1476735908086; Mon, 17 Oct 2016 13:25:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Mon, 17 Oct 2016 13:25:07 -0700 (PDT) In-Reply-To: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> References: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> From: Brian Smith Date: Mon, 17 Oct 2016 10:25:07 -1000 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a1143ed623aa29d053f155f12 Archived-At: Cc: "" Subject: Re: [TLS] Supported Versions extension 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: Mon, 17 Oct 2016 20:25:10 -0000 --001a1143ed623aa29d053f155f12 Content-Type: text/plain; charset=UTF-8 Hubert Kario wrote: > Currently the description of the extension states that only TLS versions > can > be listed in the extension and all unknown versions must be ignored. > > I wonder if making it explicit that {3, 0} and any lower values MUST NOT be > advertised wouldn't be a good idea, if only to hammer it that SSL3 must > not be > used. > AFAICT, there's no need to list any version in that extension lower than TLS 1.2, and maybe not even TLS 1.2. If the server understand the extension then it is (almost?) definitely a TLS 1.3+ implementation, so it should choose TLS 1.3 or later. If the server doesn't understand the extension then it will use the ClientHello.legacy_version field for version negotiation. Therefore, I suggest the following change: OLD: "Implementations of this specification MUST send this extension containing all versions of TLS which they are prepared to negotiate. For this specification, that means minimally {3, 4}, but if previous versions of TLS are supported, they MUST be present as well." NEW: "Implementations of this specification MUST send this extension containing all versions of TLS from TLS 1.3 onwards (only) which they are prepared to negotiate. For this specification, that means minimally {3, 4}. If previous versions of TLS are supported, they MUST NOT be present." Cheers, Brian --001a1143ed623aa29d053f155f12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hube= rt Kario <hkario@redhat.com> wrote:
Currently the description of the extension st= ates that only TLS versions can
be listed in the extension and all unknown versions must be ignored.

I wonder if making it explicit that {3, 0} and any lower values MUST NOT be=
advertised wouldn't be a good idea, if only to hammer it that SSL3 must= not be
used.

AFAICT, there's no need to list any vers= ion in that extension lower than TLS 1.2, and maybe not even TLS 1.2. If th= e server understand the extension then it is (almost?) definitely a TLS 1.3= + implementation, so it should choose TLS 1.3 or later. If the server doesn= 't understand the extension then it will use the ClientHello.legacy_version=C2=A0field= for version negotiation.

Therefore, I suggest= the following change:

OLD: "Implementations = of this specification MUST send this extension containing all versions of T= LS which they are prepared to negotiate.=C2=A0For this specification, that means minimally {3, 4}= , but=C2=A0if p= revious versions of TLS are supported, they MUST be present as=C2=A0= well."

NEW:=C2=A0"Implementations of this specification MUST send this extension cont= aining all versions of TLS from TLS 1.3 onwards (only) which they are prepa= red to negotiate.=C2=A0For this specification, that means minimally {3, 4}. If previous versions of TLS are su= pported, they MUST NOT be present."

Cheers,
Brian

--001a1143ed623aa29d053f155f12-- From nobody Mon Oct 17 13:37:53 2016 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 92277129998 for ; Mon, 17 Oct 2016 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no 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 5CV1XgD1pMnm for ; Mon, 17 Oct 2016 13:37:50 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id A91AB12940F for ; Mon, 17 Oct 2016 13:37:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4B08D13EB4 for ; Mon, 17 Oct 2016 23:37:49 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 006_e3as1c3x for ; Mon, 17 Oct 2016 23:37:49 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id E5E212315 for ; Mon, 17 Oct 2016 23:37:48 +0300 (EEST) Date: Mon, 17 Oct 2016 23:37:41 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20161017203741.GA26847@LK-Perkele-V2.elisa-laajakaista.fi> References: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Supported Versions extension 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: Mon, 17 Oct 2016 20:37:52 -0000 On Mon, Oct 17, 2016 at 10:25:07AM -1000, Brian Smith wrote: > Hubert Kario wrote: > > > Currently the description of the extension states that only TLS versions > > can > > be listed in the extension and all unknown versions must be ignored. > > > > I wonder if making it explicit that {3, 0} and any lower values MUST NOT be > > advertised wouldn't be a good idea, if only to hammer it that SSL3 must > > not be > > used. > > > > AFAICT, there's no need to list any version in that extension lower than > TLS 1.2, and maybe not even TLS 1.2. If the server understand the extension > then it is (almost?) definitely a TLS 1.3+ implementation, so it should > choose TLS 1.3 or later. If the server doesn't understand the extension > then it will use the ClientHello.legacy_version field for version > negotiation. > > Therefore, I suggest the following change: > > OLD: "Implementations of this specification MUST send this extension > containing all versions of TLS which they are prepared to negotiate. For > this specification, that means minimally {3, 4}, but if previous versions > of TLS are supported, they MUST be present as well." > > NEW: "Implementations of this specification MUST send this extension > containing all versions of TLS from TLS 1.3 onwards (only) which they are > prepared to negotiate. For this specification, that means minimally {3, 4}. > If previous versions of TLS are supported, they MUST NOT be present." Omitting TLS 1.2 causes failures in some downnegotiation cases (when there are higher versions supported, but not overlapping). OTOH, negotiating 1.0 or 1.1 with this extension supported at both sides is very unlikely. -Ilari From nobody Mon Oct 17 13:40:37 2016 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 BF0EF1297C6 for ; Mon, 17 Oct 2016 13:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 ubMfqsFU0LsW for ; Mon, 17 Oct 2016 13:40:33 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F6012940F for ; Mon, 17 Oct 2016 13:40:33 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id q192so201512001iod.0 for ; Mon, 17 Oct 2016 13:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G+NL7zsjyXBbsKWIbH7SVg6v6uxosEDp9GXtJZ6TszU=; b=g5y2cs50bG4gKwjd8FrfkAhN6SV1yiL85uB/fImCbCA8ydseZ7q7cIuuGWtzsJBdDh NqLe9bCaukMxhdfjXCjRDv9Kp/2H96Wv1cfx2YNaYTPzu3In14RfEosuMhAo6nEw3tCZ uuzbinFhilV6qr9tLukfZyt0AK+iCOW3+DuHb9daEFqHL9Qmatvz+gJvhE2mL0hW/p8V MTuQBFaS6k8bm+0G1dynxg9MSccFpGWxyvDCV4hXjNsEpn3p2oEX2YCPbu22t7cWNQub l7cdPDwuClgn/a5oDuR7NhdKcL5oXSfpmzYtvJMr4XB3LOnyOnyqI3DJlPqFC2/rdMRF hrpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G+NL7zsjyXBbsKWIbH7SVg6v6uxosEDp9GXtJZ6TszU=; b=d5hFm97+hg1y8hvMxYxnmQyto8ZrReji7FWPjrl3LtdlTo7LKsQEE/kCpi0Rm4ijUw jSA4I3VmzE1EnBZtv7caA/6ZQsfU63JCwgLtkIT+zhKPEe5RW1fhhR/Y2Qqly6S4vYGZ 5Z+/MdfInSnAF5ZJB6f7G9LVUwCu4eN5KnOAL0A1CO3QsyqUXkSXz4O3dlLy07T3m0E7 IEOYkBpiafein0OPgE72PvphVkV+qpPwQoR0huVmhaR6zNCro1wAdXJRdK7VNF2z2wBp ORF6yt3XRqQokaUG9ihblsknw8bxRIYRXTmFy0zmoxK0DzAThDpa2TLZ6oFC4pm01xj5 aQtQ== X-Gm-Message-State: AA6/9RmxCCmeEb5IUa7w4E2A+nksphHIipC9s0BghRpx/Sd7vKrjm2bgvcuvuHxEqZUlZr0KNePYLgeUGpcQ0w== X-Received: by 10.107.154.134 with SMTP id c128mr28956775ioe.184.1476736832362; Mon, 17 Oct 2016 13:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Mon, 17 Oct 2016 13:40:31 -0700 (PDT) In-Reply-To: <20161017203741.GA26847@LK-Perkele-V2.elisa-laajakaista.fi> References: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> <20161017203741.GA26847@LK-Perkele-V2.elisa-laajakaista.fi> From: Brian Smith Date: Mon, 17 Oct 2016 10:40:31 -1000 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1140b9a451f0b1053f1596aa Archived-At: Cc: "" Subject: Re: [TLS] Supported Versions extension 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: Mon, 17 Oct 2016 20:40:35 -0000 --001a1140b9a451f0b1053f1596aa Content-Type: text/plain; charset=UTF-8 Ilari Liusvaara wrote: > Omitting TLS 1.2 causes failures in some downnegotiation cases (when there > are higher versions supported, but not overlapping). > Could you provide a concrete example, please? Thanks, Brian -- https://briansmith.org/ --001a1140b9a451f0b1053f1596aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ilar= i Liusvaara <ilariliusvaara@welho.com> wrote:
Omitting TLS 1.2 causes failures in some downneg= otiation cases (when there
are higher versions supported, but not overlapping).
<= br>
Could you provide a concrete example, please?

<= /div>
Thanks,
Brian
--
--001a1140b9a451f0b1053f1596aa-- From nobody Mon Oct 17 13:43:23 2016 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 B48E812999C for ; Mon, 17 Oct 2016 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 5qVq6P1cpk4f for ; Mon, 17 Oct 2016 13:43:20 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA661299A5 for ; Mon, 17 Oct 2016 13:43:20 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id x128so14664673ybg.1 for ; Mon, 17 Oct 2016 13:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LNShrPtMqS7RqmgfPRMlXjyVs4fqIjugLcVNGYKVjMY=; b=b0BmNcoVAgPqN9tzYlxLz+zcdY0gR2J8TJ499QPeaNaLP1aI7eWOws90rSbWcuGTjj 7nbXfp7qpmIMkfy9J758N6LQ0gDqWanBUVddTYO77W4Ix5E9HYjNjK7Ex8h0L15b16HV ZCFqEa/TZeIn3GcBWAuNrDy1LssGa2RlyK1sPcAwAi23VeRUIGH0yHWb1BuGM1SF839V a9f8OimTpddavQLdgXOMRnd00Pi2+cPEP9GFn3O+UYFs3a2aCf4Mqz11Zk/61gKf2aWk R/ukRzPLZBBu0Wqt/rmbq5oXDp/RvViLNC7ts3R/f8KAVMQoS1IEgyWf1+0BiXEhcBqF LZuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LNShrPtMqS7RqmgfPRMlXjyVs4fqIjugLcVNGYKVjMY=; b=U6L5TBvhvrLCuEbp69jyI8nPP+FU81/sA0etlQ/brvHIrbZyrtQ4LCS2l32q9w8XeC Az9Onwp0/cDcezYxddHtFsmKgC+ce5wWXHaGYRha3OAYyenM4vt7A/bImSxbJjJNpg7U 6IV9GVKzsQwSqp8mn99NCd2sC8UPlsuBaHo+l5MN1MSjt6hq5PJjuD8osm86Zwn9hqUj uMKfVl8+25UWSYLbZQaSztS7N00Lc47AF5vgR7GjR85W9dVtyIaz7oGtuCMRL3W3/lK9 MiAwY8VcJ8Njb+6SWEvWcIPi8YTnlfDaHbFaCvhl+a1lrXvc+gEviv4OQvX+4g5AeRtA eVWA== X-Gm-Message-State: AA6/9Rl85hlaEduEhDZhfYLgNWpYun7Mkx43Eli1rkO5FNumPlm/no6TkPXHkO6IgpKZiSp+K71AEmVcHrsjYw== X-Received: by 10.37.117.87 with SMTP id q84mr18316430ybc.80.1476736999564; Mon, 17 Oct 2016 13:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Mon, 17 Oct 2016 13:42:39 -0700 (PDT) In-Reply-To: References: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> <20161017203741.GA26847@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 17 Oct 2016 16:42:39 -0400 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a114bbb3c498743053f15a07a Archived-At: Cc: "" Subject: Re: [TLS] Supported Versions extension 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: Mon, 17 Oct 2016 20:43:23 -0000 --001a114bbb3c498743053f15a07a Content-Type: text/plain; charset=UTF-8 On Mon, Oct 17, 2016 at 4:40 PM, Brian Smith wrote: > Ilari Liusvaara wrote: > >> Omitting TLS 1.2 causes failures in some downnegotiation cases (when there >> are higher versions supported, but not overlapping). >> > > Could you provide a concrete example, please? > When I support TLS 1.2 and TLS 1.3 draft-16 and you support TLS 1.2 and TLS 1.3 draft-17. I would prefer to stick with the current design where if supported_versions exists it is the sole mechanism for negotiation. -Ekr Thanks, > Brian > -- > https://briansmith.org/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114bbb3c498743053f15a07a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 17, 2016 at 4:40 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Ilari = Liusvaara <ilariliusvaara@welho.com> wrote:
Omitting TLS 1.2 causes failures in some downnegot= iation cases (when there
are higher versions supported, but not overlapping).
<= br>
Could you provide a concrete example, please?

When I support TLS 1.2 and = TLS 1.3 draft-16 and you support TLS 1.2 and TLS 1.3 draft-17.
I would prefer to stick with the current design where if suppo= rted_versions exists it is the sole
mechanism for negotiation.

-Ekr


Thanks,
Brian
--

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


--001a114bbb3c498743053f15a07a-- From nobody Mon Oct 17 15:49:34 2016 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 0B8FA12957C for ; Mon, 17 Oct 2016 15:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 F4lUa5J5fmtY for ; Mon, 17 Oct 2016 15:49:31 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820DE1297C6 for ; Mon, 17 Oct 2016 15:49:31 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id e187so16214193itc.1 for ; Mon, 17 Oct 2016 15:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NVa8D/7zQuZdn3MxHRsUw11m6lnJWQ0135QTeqssND8=; b=IEu9YsTWl2Bajw8yjLbQzgXOa6A7Q4eq/ir8zTsTm33dv6vgn1BQJu+gyRvF8m7N88 Q1MMQ5im2N60CuODJBT0H9MiJPTh1qrH5szzL8clODOM52+08Lt40CMeqBuL9zdj5+6s Zbc1dV6RhcMeoM7LmByIbQI04Y7E1RWsmCpH6xO5uKYwQkQ9e7bKnKYyQ/Lq8pzW5L45 QZFmjJYuENxARhsKNlNWL7LPqANGnwEUnW0BgKbvGx40p45VwnkSdspexr49RFgxO37X gDRXGpgptbW+BiQXAOuYV7vIdpAs4uf2oK9oKRvAjxtOmduD+WQM23DSY4hSr2lfZEwX 3JIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NVa8D/7zQuZdn3MxHRsUw11m6lnJWQ0135QTeqssND8=; b=FgsNYnuR67pN6j+Co1hKVilaQo/S3QBVOOmhcw+tJc9Dp4eDVgEYpbYVb5Ckx9oxZU 7+CC0Pf4+GxSm55NAj80skEBAYu95DTzdfFf2djVaruoEYVST0gM6HuDs6H0cz0W6d6R XIYPrJLkr5Zi7i2qfzvQ8IwLdTf2Y7LSCvyIXGWRz6pStrqH6OgqKSbVk/mE6S8Aedwm BUoMOCYymqULzz4YCjJgiq9KB5or1FgdKg2ZLpgSrjErAhrfUcalKJQ1DN4sHCxwLpKz jcLrdUXwmzP1K6r0jL0uyThId8Es6Mj7FaMFFigEnO5TvkPBgf3uz76slAcv6rKvuHtU LlYA== X-Gm-Message-State: AA6/9RmO/GZFFRnCEONQiScU1meqrVJshvE4trsw7hsWOCL2OJaVyBmLQbmGKA3tqqhgyvvGGe+nSJlDkf0ToA== X-Received: by 10.36.29.14 with SMTP id 14mr10714833itj.117.1476744570843; Mon, 17 Oct 2016 15:49:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Mon, 17 Oct 2016 15:49:30 -0700 (PDT) In-Reply-To: References: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> <20161017203741.GA26847@LK-Perkele-V2.elisa-laajakaista.fi> From: Brian Smith Date: Mon, 17 Oct 2016 12:49:30 -1000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1143ed6291f5a8053f176326 Archived-At: Cc: "" Subject: Re: [TLS] Supported Versions extension 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: Mon, 17 Oct 2016 22:49:33 -0000 --001a1143ed6291f5a8053f176326 Content-Type: text/plain; charset=UTF-8 Eric Rescorla wrote: > Brian Smith wrote: > >> Ilari Liusvaara wrote: >> >>> Omitting TLS 1.2 causes failures in some downnegotiation cases (when >>> there >>> are higher versions supported, but not overlapping). >>> >> >> Could you provide a concrete example, please? >> > > When I support TLS 1.2 and TLS 1.3 draft-16 and you support TLS 1.2 and > TLS 1.3 draft-17. > > I would prefer to stick with the current design where if supported_versions > exists it is the sole mechanism for negotiation. > Note that in my suggestion, supported_versions is the sole mechanism for negotiation as well. With my suggestion, in your example where two different TLS 1.3 drafts are supported, by each end, the server will see that no supported draft of TLS 1.3 is supported and then negotiate TLS 1.2 if it supports TLS 1.2; otherwise it would give up. It can make this decision purely based on the contents of the supported_versions extension. Then if the client supports TLS 1.2 it will continue; otherwise it will abort. So there doesn't seem to be a significant benefit to advertising TLS 1.2 support in the extension. Especially since TLS 1.2 is a superset of TLS 1.1 and TLS 1.0, I don't think there's any need for TLS 1.0 or TLS 1.1 to be mentioned in the extension at all, even if the client supports them, because a server that supports this extension shouldn't ever negotiate TLS 1.0 or TLS 1.1. Imagine that we wanted to support clients that support TLS 1.0 and/or TLS 1.1, not TLS 1.2, but TLS 1.3, for some reason. Then we'd need to allow the legacy_version field to be TLS 1.1 or TLS 1.0. But, I don't think it's useful to support this. Cheers, Brian --001a1143ed6291f5a8053f176326 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eric= Rescorla <ekr@rtfm.com> wrote:
Brian Smith <<= a href=3D"mailto:brian@briansmith.org" target=3D"_blank">brian@briansmith.o= rg> wrote:
<= span>Ilari Liusvaara <ilariliusvaara@welho.com> wrote= :
Omitting TLS 1.2 cau= ses failures in some downnegotiation cases (when there
are higher versions supported, but not overlapping).
<= br>
Could you provide a concrete example, please?

When I support TLS 1= .2 and TLS 1.3 draft-16 and you support TLS 1.2 and TLS 1.3 draft-17.=C2=A0=
=C2=A0
I would prefer to stick with the current = design where if supported_versions exists it is the sole mechanism for nego= tiation.

Note t= hat in my suggestion, supported_versions is the sole mechanism for negotiat= ion as well. With my suggestion, in your example where two different TLS 1.= 3 drafts are supported, by each end, the server will see that no supported = draft of TLS 1.3 is supported and then negotiate TLS 1.2 if it supports TLS= 1.2; otherwise it would give up. It can make this decision purely based on= the contents of the supported_versions extension. Then if the client suppo= rts TLS 1.2 it will continue; otherwise it will abort. So there doesn't= seem to be a significant benefit to advertising TLS 1.2 support in the ext= ension.

Especially since TLS 1.2 is a superset of = TLS 1.1 and TLS 1.0, I don't think there's any need for =C2=A0TLS 1= .0 or TLS 1.1 to be mentioned in the extension at all, even if the client s= upports them, because a server that supports this extension shouldn't e= ver negotiate TLS 1.0 or TLS 1.1. Imagine that we wanted to support clients= that support TLS 1.0 and/or TLS 1.1, not TLS 1.2, but TLS 1.3, for some re= ason. Then we'd need to allow the legacy_version field to be TLS 1.1 or= TLS 1.0. But, I don't think it's useful to support this.

Cheers,
Brian
--001a1143ed6291f5a8053f176326-- From nobody Tue Oct 18 03:28:56 2016 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 410AB1295DD for ; Tue, 18 Oct 2016 03:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.353 X-Spam-Level: X-Spam-Status: No, score=-7.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4ngRFdsnX5h3 for ; Tue, 18 Oct 2016 03:28:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB0E1295DA for ; Tue, 18 Oct 2016 03:28:54 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 202B3C057FAD for ; Tue, 18 Oct 2016 10:28:54 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9IASqmK027370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2016 06:28:53 -0400 From: Hubert Kario To: "tls@ietf.org" Date: Tue, 18 Oct 2016 12:28:46 +0200 Message-ID: <2491854.n0oRtYzp7Y@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.7-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart123087856.MGi1IgC8WB"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 18 Oct 2016 10:28:54 +0000 (UTC) Archived-At: Subject: [TLS] Zero length fragments and fragmented Alert messages 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: Tue, 18 Oct 2016 10:28:56 -0000 --nextPart123087856.MGi1IgC8WB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Current draft states: Alert messages ({{alert-protocol}}) MUST NOT be fragmented across records. and Implementations MUST NOT send zero-length fragments of Handshake or Alert types, even if those fragments contain padding. But I don't see what is the expected behaviour of the side receiving such=20 malformed messages. Especially the fragmented alerts are unique in that any other message type = can=20 be fragmented, so no rules define how to handle incorrectly fragmented=20 messages. Or at least I don't see them. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart123087856.MGi1IgC8WB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYBfleAAoJEJKo0bgB0vX1qCsQAJpBvNRe+H3+UAyQJVg42M8C yX4bkKeh2DGrekNyz7SrwjhAo/LgTXs4BG2aOsFniRJKvrom3JBWO32XQ7M0qy9L Md7o8aWwhgVx8vWPYcEN8GIkrEpWz3ieMQseNHfKOZalkIHiDOHbH6uFhXNtfp3x O4bklQHjBWN5aYBsJQqn0n1bD9yb8e/iKmq3CW/GBLSKWG151nzTNolnrd0SkqMl jzQMaRRz8v004/EXykF9zYQfsJcTY6y96IG2GD7xXYjYmPTiapL3Ew8aAgJrKrWn +02WCAwneHq0D2XCB/CrEGe5jMaDRakeh4RZgUjug87iZoy2fUvzlsjGFB/YHVwp fezUeKDs0uHohS7qqbIZAwa3hrXs00/i1Ql3l/GNu1zLuh4hteG5rLlSq+FSFcpz kTx08YGTTYkF/dovcbam0MomPw2IQduOwsDA5pe2ScwaFt+vt5DoTJJB7OODgYwr yQ+7TPJhCIEZNzS7+U9dwrJnLD5c3pvboazGl7o8kHJeZBmZxRuSOpupLWymuPSE AZpFfzjvfc0LpYo4oKjje7ntinyrg+T4SWnwV2vdIaLo4VCCAjkAb1QnzS5mCmSG tg/rQpytY9Iu0rXDlL+M0n7OTiDDlKU/7ufmW3Te1oK0dFXyyKi7/q/dKNipGfKA xPeMP8NC6CVhZk5h6UzD =ddmV -----END PGP SIGNATURE----- --nextPart123087856.MGi1IgC8WB-- From nobody Tue Oct 18 03:40:41 2016 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 EF679129503 for ; Tue, 18 Oct 2016 03:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.353 X-Spam-Level: X-Spam-Status: No, score=-7.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 scxy-CPVOBzs for ; Tue, 18 Oct 2016 03:40:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D62129421 for ; Tue, 18 Oct 2016 03:40:38 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 80FF880084; Tue, 18 Oct 2016 10:40:38 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9IAeaeS026814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2016 06:40:37 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 18 Oct 2016 12:40:35 +0200 Message-ID: <4552334.3TtHzmCgkW@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.1 (Linux/4.7.7-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) In-Reply-To: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15732814.AlyK1GfpxJ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 18 Oct 2016 10:40:38 +0000 (UTC) Archived-At: Subject: Re: [TLS] New review through the TLS 1.3 Editor's Copy 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: Tue, 18 Oct 2016 10:40:40 -0000 --nextPart15732814.AlyK1GfpxJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 17 October 2016 21:10:30 CEST Ilari Liusvaara wrote: > > ## Decoding Errors > >=20 > > TLS defines two generic alerts (see {{alert-protocol}}) to use upon > > failure to parse a message. Peers which receive a message which cannot = be > > parsed according to the syntax (e.g., have a length extending beyond the > > message boundary or contain an out-of-range length) MUST terminate the > > connection with a "decoding_error" alert. Peers which receive a message > > which is syntactically correct but semantically invalid (e.g., a DHE > > share of p - 1) MUST terminate the connection with an "illegal_paramete= r" > > alert. >=20 > What alert is used if some field is an non-extensible enumeration and > the value transmitted is outside the legal values? >=20 > E.g. An unknown max_fragment_length value. >=20 > I have used illegal_parameter for errors like this. That would be my reading of the text too. Anything that can be parsed given the requirements on structs should not=20 generate decode_error, if it needs to be rejected because of other=20 limitations, it should result in an illegal_parameter. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart15732814.AlyK1GfpxJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYBfwjAAoJEJKo0bgB0vX1UjoP+wcMA46FlXYqfZvJwXp01xE7 /FGguIOJIUTOmfimR/BL1f8tUaGCqmXpthTMgr7uJNl4HTzsXOa7ZAr8kB0jzkNj hJobyr8ejlznhrI6iKohaQ/uIftd6V1V7q4Zibzn12i1QoBPB7BDUpk2dqblnMJ6 +UwuqxjxJQ8fkImIHuhU/VMCQ2IaESR8EO/Z3PnUxey2jUgN1hN2ydleNgxM7Y6Q KojX7qIlpKwiDq5UBe0pNtPlGbp9quCPa0MDSsW39r8UHdzuV+7Woqx82ebegsxe ZCpKUsrCH/U1WePcWb4JepQB4WyTg4C3jtRBpetApXPIx6RLDgZzwa5Io0DGzopj zQIi7VD4ynQws/73MwNyhlBKKTbvv69mzYxi6NVuZDno545Nu48St6dZx8/ISehS mmWGKULqlxNmoluz1G48KXDaASO+jOPJImsjn7mC1+tPWnGqjZWD0yXY2RPtCmto 5SIb8aFTEg3rtN6BX8b4z/6ZDQ7m6u/MzOOssybJdD2pb74Y76NvPRXVD7/Okzpz 5VJJxw3KZ+ArUyrSrpZPuK6N7hKcttAnTcCr+JqFv2CH5GCmWTuoBKuQyPQWmcud rW/umRwPkbf1xVLt8e+IPHE6US243acgq4uPIGXKmUFO0iGV+6TjMKmelsDCrwzL sYMuraAaUUAlj2p9wCYI =UL8R -----END PGP SIGNATURE----- --nextPart15732814.AlyK1GfpxJ-- From nobody Tue Oct 18 03:56:44 2016 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 B747612998D for ; Tue, 18 Oct 2016 03:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 DlR4Cd-J0kku for ; Tue, 18 Oct 2016 03:56:42 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265FF129426 for ; Tue, 18 Oct 2016 03:56:42 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id 184so75345034yby.2 for ; Tue, 18 Oct 2016 03:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x85XxCLUnK7miUxI1QvkJ3JLx6HCnIEMiGDA3lklaUA=; b=DI+RD4rnCXCvNuyOj5cGT8aFBr9/9tLETdQ3IYXKMLeF9tiRDcnjGcl1VrIIcn1AS4 tZ6Ju7Wj9jXEcwSkYX9gYN/ZAZzEK1w4uvnbMCKhsFqOFM3PD51xsnCuikamg98c0ffh VXJMgXyL+x0+22mRVdxfNM+XtjFq8jhzliouyf4t3VNV4c6vhuzhh15aSU7j7y1WROxT casCQJC8D5KpFFAP6ZQUJKoQQMFGTisIp/lUJSCo2Z/yrNPzz9yq6jVbqwwTUwyN8/1c +sxeRnXwanjdqpBo5ljrSI3+5ZfX1PB2pohBpTSKqHud1u7w6S7r9Nc9LBeA7Z41Lz9n fZeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x85XxCLUnK7miUxI1QvkJ3JLx6HCnIEMiGDA3lklaUA=; b=QKoh0HfsJiiEpZoQBciofyQKAQpvx33CR6vZQkjTd6qmYbFCx0VI+vAvXOBh9nwPid /s2uaepBOeltwdsjxuWaO9BXt0gi/71ks+tzYk8WlFuxepruA2WeFEceN2UFJLCarDeB fcq3MsOHSiTASHmWsmHMGO5uXoehJN6y0Q/vf+mUS/eYOueoItVdZq6Py0o+IJX3IxFM J1ZqUqkP44ksrexKCp63UdFrqtY29uINlwVoYP9e6frHg8IyO5lU9BcaMzzbcUeDHimy ClVcZQRoVKQHNc0whqvRJoepn+8DraWjqHG2FVoC6b0Lz1tkTHzgJcybbj0h3f1aTV6A g5Cg== X-Gm-Message-State: AA6/9Rn51/NMrss59VaaIJR72ZBXomulKhKzS5BiwCYImfDFMeFI4mLaamQiJ/B5KySS/5fo3WVt89OW0XY6qQ== X-Received: by 10.37.171.234 with SMTP id v97mr2132829ybi.161.1476788201383; Tue, 18 Oct 2016 03:56:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.212 with HTTP; Tue, 18 Oct 2016 03:56:01 -0700 (PDT) In-Reply-To: <2491854.n0oRtYzp7Y@pintsize.usersys.redhat.com> References: <2491854.n0oRtYzp7Y@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Tue, 18 Oct 2016 06:56:01 -0400 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=94eb2c0ce1f8271abd053f218c3b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Zero length fragments and fragmented Alert messages 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: Tue, 18 Oct 2016 10:56:43 -0000 --94eb2c0ce1f8271abd053f218c3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable " decode_error A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. " I suppose you could argue that: " This alert is used for errors where the message does not conform to the formal protocol syntax. " Rules that out, but I think I'm willing to stretch it here. -Ekr On Tue, Oct 18, 2016 at 6:28 AM, Hubert Kario wrote: > Current draft states: > > Alert messages ({{alert-protocol}}) MUST NOT be fragmented across > records. > > and > > Implementations MUST NOT send zero-length fragments of Handshake or > Alert types, even if those fragments contain padding. > > But I don't see what is the expected behaviour of the side receiving such > malformed messages. > > Especially the fragmented alerts are unique in that any other message typ= e > can > be fragmented, so no rules define how to handle incorrectly fragmented > messages. Or at least I don't see them. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0ce1f8271abd053f218c3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
" =C2=A0 decode_error =C2=A0A message could not be de= coded because some field was
=C2=A0 =C2=A0 =C2=A0 out of the specified = range or the length of the message was
=C2=A0 =C2=A0 =C2=A0 incor= rect. "

I suppose you could argue that:
=

" =C2=A0This alert is used for errors where the me= ssage does
=C2=A0 =C2=A0 =C2=A0 not conform to the formal protoco= l syntax. =C2=A0"

Rules that out, but I think= I'm willing to stretch it here.

-Ekr


On Tu= e, Oct 18, 2016 at 6:28 AM, Hubert Kario <hkario@redhat.com>= wrote:
Current draft = states:

=C2=A0 Alert messages ({{alert-protocol}}) MUST NOT be fragmented across re= cords.

and

=C2=A0 Implementations MUST NOT send zero-length fragments of Handshake or<= br> =C2=A0 Alert types, even if those fragments contain padding.

But I don't see what is the expected behaviour of the side receiving su= ch
malformed messages.

Especially the fragmented alerts are unique in that any other message type = can
be fragmented, so no rules define how to handle incorrectly fragmented
messages. Or at least I don't see them.
-= -
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c0ce1f8271abd053f218c3b-- From nobody Tue Oct 18 06:19:25 2016 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 5C868129A5E for ; Tue, 18 Oct 2016 06:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 g8vpXFSv9dwD for ; Tue, 18 Oct 2016 06:19:20 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766EE129A52 for ; Tue, 18 Oct 2016 06:19:20 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id f128so279260566qkb.1 for ; Tue, 18 Oct 2016 06:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M4Ed4GvpQ0QLVskIHUUQL9MxDr85DT4ZwXntNSHUMWI=; b=QWMBhIx/ySA/oO2GhV9MLlyA1rSQOzfyVDOXpNc8HsDLBkQd80yYKGIO+tOVpcInnY TICJptfrbXQtF/3xXSYcAKBtzjKZ+E09HsJqmLFbVIVL2R35+qO7mSfmRkRKnmWdSVBw fJbV0NNO/SyT+3hVD3ZUSCpoFlf22s2riuJ4s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M4Ed4GvpQ0QLVskIHUUQL9MxDr85DT4ZwXntNSHUMWI=; b=SJD4HvMCVkvj2L3QC6rhIMbh0xy7bNCwP17oZS821UVAIKif+Gr+g1QD+gz/kqTfOk nvgccDf+UeYGIfcbC4D3nqaDn4Nqr3bYdWkp7UBGDjv2JcEwOoID81BgF7gS3OycGqNp 3Hv93howRLfed4wteNxrlnuIpCSwym/fX96E0P/27BS9+Tfe9LepFZdGf4lsK8cXmca4 ZQkaBMEn1qnOsm2ZzgJlQmFv4MBNrZh1RFxvSJfKcG3pJiQ6CxTHu/79D2Sw5sq7Dip9 QN+icU6am0HXn2Ia08foLZTcVfM/kQCmP68ivU8GBxf4dYGPvyjJg/S7zRISMPoKin6n 4DCg== X-Gm-Message-State: ABUngvcGOz+tnmAWd5S3gi2tx53SiGvVTW5WdGdIo3oYmcp/WIqrwi0gdstorIewwBxOYQ== X-Received: by 10.55.80.135 with SMTP id e129mr520727qkb.74.1476796758308; Tue, 18 Oct 2016 06:19:18 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id m201sm7241582qke.1.2016.10.18.06.19.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Oct 2016 06:19:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Tue, 18 Oct 2016 09:19:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> To: Daniel Migault X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead 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: Tue, 18 Oct 2016 13:19:22 -0000 I think there might be consensus to ask for code points but not early. = This draft can=E2=80=99t really proceed any faster than the TLS1.3 and = 4492bis drafts. spt > On Oct 17, 2016, at 12:03, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > I am not clear what the consensus is for the following points. Is = there any consensus for requesting the following ones? >=20 > BR,=20 > Daniel >=20 > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x01}; > TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x02}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x04}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} = {0xD0,0x05}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} = {0xD0,0x06}; >=20 >=20 >=20 > On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson = wrote: > I'm mainly just looking to economize on different configurations. >=20 > On 9 October 2016 at 16:32, John Mattsson = wrote: > > Hi Martin, > > > > > > AES_256_CCM_8 was not in the first versions of the draft but added = later > > after request from IoT people (probably afraid of quantum = computers). > > > > > > While I think it makes very much sense to have short tags in = wireless > > radio, I do not know how large need there is for AES-256 in IoT for > > constrained devices, or how large the need would be to truncate the = tag in > > these cases. > > > > > > My current understanding is that Grover=E2=80=99s algorithm may = never be more > > cost-effective than a cluster of classical computers, and that = quantum > > computers therefore likely do not affect the lifetime of AES-128. > > > > > > I do not have any strong opinions regarding keeping AES_256_CCM_8 or = not. > > We should not give the impression that AES-256 is needed for = practical > > resistance to quantum computers anytime soon, it is however a = requirement > > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM = seems > > like the best choices in most cases. > > > > > > Cheers, > > John > > > > > > > > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" = > on behalf of martin.thomson@gmail.com> wrote: > > > >>Looking at those emails, I am prompted to wonder if anyone can = justify > >>the existence of a ciphersuite with a double-sized key and = half-sized > >>authentication tag. RFC 6655 doesn't really explain how that is a > >>useful thing. > >> > >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos = > >>wrote: > >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: > >>>> All, > >>>> > >>>> We've received a request for early IANA assignments for the 6 = cipher > >>>> suites listed in = https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh > >>>> e-psk-aead/. Please respond before August 23rd if you have = concerns > >>>> about early code point assignment for these cipher suites. > >>> > >>> I have previously raised an issue [0] on these ciphersuites. The = same > >>> requirement was noted also by Peter Dettman as something special = in > >>> [1]. However, there has been no reaction from the authors (now in = CC). > >>> > >>> regards, > >>> Nikos > >>> > >>> [0]. > = >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ > >>> [1]. > = >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >>_______________________________________________ > >>TLS mailing list > >>TLS@ietf.org > >>https://www.ietf.org/mailman/listinfo/tls > > >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Oct 18 09:23:07 2016 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 B5ED01296D4 for ; Tue, 18 Oct 2016 09:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 x8c8rJ7rQBZt for ; Tue, 18 Oct 2016 09:23:03 -0700 (PDT) Received: from BLU004-OMC1S7.hotmail.com (blu004-omc1s7.hotmail.com [65.55.116.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753CA1296BC for ; Tue, 18 Oct 2016 09:23:02 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com ([65.55.116.8]) by BLU004-OMC1S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 18 Oct 2016 09:23:01 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BDP221E86x20LCGNLFYNGbxsfu8a+l+RdpBvXFI64qc=; b=QxOUWMPExfZMLAgDOQ8g0IjhVcKYBcI8m3KxTr9LXvvM6A3NVHRQPbope5MOARgJnVIwe9MucBs8UjHDwutoy/7x6hZKzQlHJ1fn9FkEnf4oAj0kDXsy4glhAX3Z4yEjkjTdral3vNwn3usOoLOOxdOvfYebdCqby6GsmysP9gWQwcXwA7v0TBLlg/4P02PKFD0lxFusoyzuHG1GKoxCqcshAGIONaxXiF/Uxjc9ZkEkm7l6foweJbDr7iSSvGIWGp3FzefaAPFCFCCkEhz+Oov4qyxGN/9hcS3gVF/dZhoRkQrvdoJlphK1VpVZc2NBAC/tPT6EEfHVB9K9MbqqQQ== Received: from BN3NAM04FT039.eop-NAM04.prod.protection.outlook.com (10.152.92.56) by BN3NAM04HT164.eop-NAM04.prod.protection.outlook.com (10.152.93.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Tue, 18 Oct 2016 16:23:00 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.92.59) by BN3NAM04FT039.mail.protection.outlook.com (10.152.93.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Tue, 18 Oct 2016 16:23:00 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0659.025; Tue, 18 Oct 2016 16:22:59 +0000 From: Xiaoyin Liu To: Sean Turner , Daniel Migault Thread-Topic: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead Thread-Index: AQHR8m4rVzjbzGrDOEyISvKtPYtp7qBB76mAgALxGgCAWxduAIABJ+cAgAwbLgCAAWRPgIAAM1bz Date: Tue, 18 Oct 2016 16:22:59 +0000 Message-ID: References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sn3rd.com; dkim=none (message not signed) header.d=none;sn3rd.com; dmarc=none action=none header.from=outlook.com; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [oj/IzEeUXb+sdf9qrxZ6Fd47BbN59W5f] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BN3NAM04HT164; 6:LFrvVFw+qdF0BW8u2Ymv/qmH+bR2XoXZXfKjuDxM465RRxKHxJTHwvFzoV7Zcq6+b0KjGFf8SQFmnsJzUs3aGdxmYIS3UTVhk6cLG/sZyp1ZLY8xzitJnHePvIhUbZ9zwyL01HygOfr08fY2gxxvxY9oedzyl8jOI0Ug/PZuDFnv+x/7Mdgtqj5NCPc8qQUG8GfwrVEpElTVSprJOWnFFfaR6NwSSVz8MQ/y281QJh5U9VgPKaUGGi5QXQgI6NLnY6Nxydw+t1kn+c0/sF+YoEPlg0Sf7J8aBDB7Ojah2uc=; 5:K09fJQTJHGKj1cTej9xBrgvEudCliAeOaGQ9KUvbO2+g8lnzBtvTfo9dpKqv6/9AXh6DGHpBJ84Gs2DdhGKas8MITc9kY9O242JpBtpk2Vh1cSq2jrG0A/hXpyz44aUVxmcG/KyNxRyc9GP9CoYCtg==; 24:X4izNRqL6ZXB1tgOwzuh7tsSrqH23hJqaP3j5wIpr2FDwnDVLOwyZNGheOA6jz9h6fPuj2K3/bTnuVhd50nwwRLBioZYrTw/IrzgSWBb89o=; 7:/heGTiaxCZl7W6AoKKDxoEAIryqYasB3VoWShkKq2o4VDDG+8UJnVHr+Fia+E7tTHCk7wYIQ3WQQZifw9uGk9byp/NO3n1lrCmmLzyaWNId4OzPSAKrvWDm2Omf6OcKH2rgqXyzvfCyifUlyI3dNw6zuaB2hjYJDHjR9/r/Fi9TfC7Xg/YmpHfI1bvDJ/8ksBxJUCISy/Ca/K7m9Y+GDxOVMzi+bwxFjspT0kopVE1gjVD+mtejb7J0oD49aN8vieL2OpX5mWJw0Elc+3+DWQuzP00o1KB2TR3VxFwSu0qYw32QBwk7soOX4XmvZacnNkyELSkPTre7K4ly1M+Ozmw== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM04HT164; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: f2a9f3a3-073f-4517-05d8-08d3f77306fe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:BN3NAM04HT164; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BN3NAM04HT164; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM04HT164; x-forefront-prvs: 00997889E7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778A186FE5D6D2D7FA19BBFFFD30CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2016 16:22:59.8511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT164 X-OriginalArrivalTime: 18 Oct 2016 16:23:01.0759 (UTC) FILETIME=[E593B0F0:01D2295B] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead 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: Tue, 18 Oct 2016 16:23:05 -0000 --_000_CY1PR15MB0778A186FE5D6D2D7FA19BBFFFD30CY1PR15MB0778namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Why does this draft normatively depend on TLS 1.3, even if the cipher suite= s defined in this draft use the old syntax, which TLS 1.3 no longer uses? Best, Xiaoyin From: Sean Turner Sent: Tuesday, October 18, 2016 9:19 AM To: Daniel Migault Cc: tls@ietf.org Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-= tls-ecdhe-psk-aead I think there might be consensus to ask for code points but not early. Thi= s draft can=92t really proceed any faster than the TLS1.3 and 4492bis draft= s. spt > On Oct 17, 2016, at 12:03, Daniel Migault w= rote: > > Hi, > > I am not clear what the consensus is for the following points. Is there a= ny consensus for requesting the following ones? > > BR, > Daniel > > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x01}; > TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x02}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x05}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x06}; > > > > On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson = wrote: > I'm mainly just looking to economize on different configurations. > > On 9 October 2016 at 16:32, John Mattsson wr= ote: > > Hi Martin, > > > > > > AES_256_CCM_8 was not in the first versions of the draft but added late= r > > after request from IoT people (probably afraid of quantum computers). > > > > > > While I think it makes very much sense to have short tags in wireless > > radio, I do not know how large need there is for AES-256 in IoT for > > constrained devices, or how large the need would be to truncate the tag= in > > these cases. > > > > > > My current understanding is that Grover=92s algorithm may never be more > > cost-effective than a cluster of classical computers, and that quantum > > computers therefore likely do not affect the lifetime of AES-128. > > > > > > I do not have any strong opinions regarding keeping AES_256_CCM_8 or no= t. > > We should not give the impression that AES-256 is needed for practical > > resistance to quantum computers anytime soon, it is however a requireme= nt > > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seem= s > > like the best choices in most cases. > > > > > > Cheers, > > John > > > > > > > > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" > on behalf of martin.thomson@gmail.com> wrote: > > > >>Looking at those emails, I am prompted to wonder if anyone can justify > >>the existence of a ciphersuite with a double-sized key and half-sized > >>authentication tag. RFC 6655 doesn't really explain how that is a > >>useful thing. > >> > >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos > >>wrote: > >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: > >>>> All, > >>>> > >>>> We've received a request for early IANA assignments for the 6 cipher > >>>> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecd= h > >>>> e-psk-aead/. Please respond before August 23rd if you have concerns > >>>> about early code point assignment for these cipher suites. > >>> > >>> I have previously raised an issue [0] on these ciphersuites. The same > >>> requirement was noted also by Peter Dettman as something special in > >>> [1]. However, there has been no reaction from the authors (now in CC)= . > >>> > >>> regards, > >>> Nikos > >>> > >>> [0]. > >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ > >>> [1]. > >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >>_______________________________________________ > >>TLS mailing list > >>TLS@ietf.org > >>https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CY1PR15MB0778A186FE5D6D2D7FA19BBFFFD30CY1PR15MB0778namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Why does this draft normatively depend on TLS 1.3,= even if the cipher suites defined in this draft use the old syntax, which = TLS 1.3 no longer uses?

 

Best,

Xiaoyin

From: Sean Turner
Sent: Tuesday, October 18, 2016 9:19 AM
To: Daniel Migault
Cc: tls@ietf.org
Subject: Re: [TLS] early IANA code point assignment request for draf= t-ietf-tls-ecdhe-psk-aead

 

I think there might be consensus to ask for code p= oints but not early.  This draft can=92t really proceed any faster tha= n the TLS1.3 and 4492bis drafts.

spt

> On Oct 17, 2016, at 12:03, Daniel Migault <daniel.migault@ericsson.= com> wrote:
>
> Hi,
>
> I am not clear what the consensus is for the following points. Is ther= e any consensus for requesting the following ones?
>
> BR,
> Daniel
>
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   =3D {0xTBD; 0xTBD} {= 0xD0,0x01};
> TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   =3D {0xTBD; 0xTBD} {= 0xD0,0x02};
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}= ;
> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}= ;
> TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   =3D {0xTBD; 0xTBD} {= 0xD0,0x05};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   =3D {0xTBD; 0xTBD} {= 0xD0,0x06};
>
>
>
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
> I'm mainly just looking to economize on different configurations.
>
> On 9 October 2016 at 16:32, John Mattsson <john.mattsson@ericsson.c= om> wrote:
> > Hi Martin,
> >
> >
> > AES_256_CCM_8 was not in the first versions of the draft but adde= d later
> > after request from IoT people (probably afraid of quantum compute= rs).
> >
> >
> > While I think it makes very much sense to have short tags in wire= less
> > radio, I do not know how large need there is for AES-256 in IoT f= or
> > constrained devices, or how large the need would be to truncate t= he tag in
> > these cases.
> >
> >
> > My current understanding is that Grover=92s algorithm may never b= e more
> > cost-effective than a cluster of classical computers, and that qu= antum
> > computers therefore likely do not affect the lifetime of AES-128.=
> >
> >
> > I do not have any strong opinions regarding keeping AES_256_CCM_8= or not.
> > We should not give the impression that AES-256 is needed for prac= tical
> > resistance to quantum computers anytime soon, it is however a req= uirement
> > for use by US government. Agree that AES_128_CCM_8 and AES_256_CC= M seems
> > like the best choices in most cases.
> >
> >
> > Cheers,
> > John
> >
> >
> >
> > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" &l= t;tls-bounces@ietf.org
> > on behalf of martin.thomson@gmail.com> wrote:
> >
> >>Looking at those emails, I am prompted to wonder if anyone can= justify
> >>the existence of a ciphersuite with a double-sized key and hal= f-sized
> >>authentication tag.  RFC 6655 doesn't really explain how = that is a
> >>useful thing.
> >>
> >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos <nmav@r= edhat.com>
> >>wrote:
> >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
> >>>> All,
> >>>>
> >>>> We've received a request for early IANA assignments f= or the 6 cipher
> >>>> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh
> >>>> e-psk-aead/.  Please respond before August 23rd = if you have concerns
> >>>> about early code point assignment for these cipher su= ites.
> >>>
> >>> I have previously raised an issue [0] on these ciphersuit= es. The same
> >>> requirement was noted also by Peter Dettman as something = special in
> >>> [1]. However, there has been no reaction from the authors= (now in CC).
> >>>
> >>> regards,
> >>> Nikos
> >>>
> >>> [0].
> >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-= aT299BYrlBKvZs0BOQ
> >>> [1].
> >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30= eZgWs8v5Rp-CUqCHds
> >>>
> >>> _______________________________________________
> >>> TLS mailing list
> >>> TLS@ietf.org
> >>> htt= ps://www.ietf.org/mailman/listinfo/tls
> >>
> >>_______________________________________________
> >>TLS mailing list
> >>TLS@ietf.org
> >>https://= www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
 --_000_CY1PR15MB0778A186FE5D6D2D7FA19BBFFFD30CY1PR15MB0778namp_-- From nobody Tue Oct 18 09:31:19 2016 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 395E2129595 for ; Tue, 18 Oct 2016 09:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no 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 0TauZOeDJ1cq for ; Tue, 18 Oct 2016 09:31:14 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9021C12945E for ; Tue, 18 Oct 2016 09:31:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 0E64613FBE; Tue, 18 Oct 2016 19:31:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id wSgyW2IBf_Gv; Tue, 18 Oct 2016 19:31:12 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C08D0C4; Tue, 18 Oct 2016 19:31:12 +0300 (EEST) Date: Tue, 18 Oct 2016 19:31:05 +0300 From: Ilari Liusvaara To: Xiaoyin Liu Message-ID: <20161018163104.GA2405@LK-Perkele-V2.elisa-laajakaista.fi> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead 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: Tue, 18 Oct 2016 16:31:17 -0000 On Tue, Oct 18, 2016 at 04:22:59PM +0000, Xiaoyin Liu wrote: > Why does this draft normatively depend on TLS 1.3, even if the > cipher suites defined in this draft use the old syntax, which > TLS 1.3 no longer uses? I don't see any reason why it would normatively depend. If it claims to be so, IMO that is a mistake and such reference should be dropped (TLS 1.3 won't be able to use these anyway), or made in- formative, in case the text wants to make a passing reference to TLS 1.3. -Ilari From nobody Tue Oct 18 11:08:00 2016 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 21E0D129762 for ; Tue, 18 Oct 2016 11:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 WU3Sb9HAHEK2 for ; Tue, 18 Oct 2016 11:07:58 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2288129699 for ; Tue, 18 Oct 2016 11:07:58 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id n189so2306061qke.0 for ; Tue, 18 Oct 2016 11:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=26U77o67q0xMklHefxy5EeW1mLX7/LfMwpnUm4RhC1I=; b=eGjds1mBigrZIRLscjSJRmNw1K5phiLSRvgCj4kfmlTIM7j91mA7iBzFl1nR0fSZN5 zcVAaErja1iAvvyVqUryE+X80bv5wJR4wu/NoNVDrtjsTxgcN1wTsvhkoRRx54x0rEqJ w5ux3A4smEkolGA5GensSQuIPKoOC1ACOC9Pg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=26U77o67q0xMklHefxy5EeW1mLX7/LfMwpnUm4RhC1I=; b=J7dpAfbuI5nUYT4mbKUearwwwFRlskq9A2+ZKr9tyJxhR35SAlEKveHzr3vHPcnmqs p3k+0ZAgCd41GaFu5mATu9HFOlWR48/u+yY4bjMVLqpr39tRUG5PceJsOCJj79mrjvaa nbqOZvPCLK6MnhvxpKP0pq0ladAfuPcsMSWTc0/w5JMUBTEIOi83YgMIyPYGHWJ5urEV khBTN4aMECBKEEcMoj3WMrIUmBOPMt/1WZnskGqaxj0YPPJsxVhpfpL+3bhNJv1DWA6H Wonyw5Bejdehz33ed12gZxHnNLRcHGTz5ONutbNrHISWYdkf/yRECI78g4giPMvWteNq rE8g== X-Gm-Message-State: AA6/9RlBmnzScnQqTuzILnmXSUxskyacsMLSsRRHKYBgI44KIybUJe6FZlV422w03Ouwrg== X-Received: by 10.55.158.139 with SMTP id h133mr2103976qke.202.1476814077560; Tue, 18 Oct 2016 11:07:57 -0700 (PDT) Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id s23sm18659424qka.10.2016.10.18.11.07.56 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Oct 2016 11:07:56 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 18 Oct 2016 14:07:55 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Call for agenda items @ IETF 97 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: Tue, 18 Oct 2016 18:08:00 -0000 The preliminary IETF 97 agenda is out: = https://datatracker.ietf.org/meeting/97/agenda.html. We=E2=80=99re = currently scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1. Please send in agenda requests. But, please note that TLS 1.3-related = issues and WG drafts will be given a priority during the sessions. = We=E2=80=99re also going to give preferential treatment to drafts that = generated discussion on the list. Cheers, J&S From nobody Tue Oct 18 11:08:16 2016 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 768CF129423 for ; Tue, 18 Oct 2016 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 g0CBwVjAYTD2 for ; Tue, 18 Oct 2016 11:08:13 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D10129697 for ; Tue, 18 Oct 2016 11:08:13 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id f193so9572882wmg.1 for ; Tue, 18 Oct 2016 11:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZZC3s57HIefIlKIB7jshCASM0vpLi3MqWPiovcubq6c=; b=upOFQWB1hIOqsWomHBAk1XZPNOM9ahw/EpTkZir61f8PiBkDd9PMGq+C7aHt2/P8L1 SHnYXlobQs6E6oBxSvTQtS+ng9rwJhN+b0JIJgqrU1wedgVP+b0Ysab0+PvThiFSpQGC reYUJfXmMKDWSO5ckqDPKA2x6NQ1iMqs4FPP+oaBHLhdpZZH2uiQGPlFtSc7r2VnHAnt eOBO05Xnu69GCg1RX2ctj4ae/uvTlIz3xiyzkwtQsVLUBbteQg2eq9X24HAE2dMqo09S NCoGiCii92u7y4nGJqN3HuL+ioTGjUz79Q6QkPMyq9xxG+GCTIRrUleOvWPttLv4KBWr Gvdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZZC3s57HIefIlKIB7jshCASM0vpLi3MqWPiovcubq6c=; b=gtHaohqx5MtnkKWo4yliuvJGSU+qn4thc/8rvloCoFVmrYzW8TcI0qAojaU20KyGFc bAwSlDI2HHUntllWgTPz6ZQC0kHx74FLMwUR4GAfWv0qmBB9dEDdOmZdQiYv6bVMPoGk eQNRBSgtUrdbxQlv3A/9OSQCzBjci+8r3ubus3hk028ZAIii+zdB9iALC2UdWF46H21d paMTN+UlZ0pfU/ujnc6d74BkAEn1LPx0GTP4SZXPxHX8maHEUjH1eC/biUTlpWuYxixa YFrMF9jAVAnDjeHAckC1k7jabvUB1xDiZBzML8pVhldiSE9svvjaUY0DK2YGPqdh4w9B Am8w== X-Gm-Message-State: AA6/9RnHQC4l18lpgDh8hdv60r6FdjKsTL4BmyyFNI7hcDbCLY0s7UYuhhI0xIBpf8hUcC4IHzGGm+qVHJ1TnA== X-Received: by 10.28.148.22 with SMTP id w22mr13222259wmd.42.1476814092145; Tue, 18 Oct 2016 11:08:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.238.199 with HTTP; Tue, 18 Oct 2016 11:07:31 -0700 (PDT) In-Reply-To: <1475320974979.29940@cs.auckland.ac.nz> References: <1475320974979.29940@cs.auckland.ac.nz> From: Ryan Carboni Date: Tue, 18 Oct 2016 11:07:31 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a114b79bc5c9c7c053f27936b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Industry Concerns about TLS 1.3 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: Tue, 18 Oct 2016 18:08:15 -0000 --001a114b79bc5c9c7c053f27936b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Oct 1, 2016 at 4:23 AM, Peter Gutmann wrote: > Ryan Carboni writes: > > >I've never quite understood what TLS was supposed to be protecting > against, > >and whether or not it has done so successfully, or has the potential to > do so > >successfully. > > It's the Inside-Out Thread Model (also shared by a number of other securi= ty > protocols, it's not just TLS), "our defence is SSL/TLS/IPsec/PKI/=E2=80= =A6 and our > threat model is whatever that happens to defend against". DNSSEC is a > classic > example of this, the DNSSEC requirements doc was published *a decade* aft= er > DNSSEC itself. Mind you, other protocols are still waiting for their > requirements doc to be published. PKIX specifically actively declined to > consider use cases because heck, this is a standards committee dammit, we > can't be expected to take into account what people want to do with it. > > Mind you, in the absence of any success criteria, no-one can say you've > failed... > > Peter. It is worth reading this paper apparently from 2010 on reusing ephemeral keys: https://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf Regardless, I can hope the Snowden disclosures will force people into action. But please. Continue to make the internet secure. --001a114b79bc5c9c7c053f27936b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 1, 2016 at 4:23 AM, Peter Gutmann <pgut001@cs.auck= land.ac.nz> wrote:
Ryan Carboni <ryacko@gmail.com> writes:

>I've never quite understood what TLS was supposed to be protecting = against,
>and whether or not it has done so successfully, or has the potential to= do so
>successfully.

It's the Inside-Out Thread Model (also shared by a number of oth= er security
protocols, it's not just TLS), "our defence is SSL/TLS/IPsec/PKI/= =E2=80=A6=C2=A0 and our
threat model is whatever that happens to defend against".=C2=A0 DNSSEC= is a classic
example of this, the DNSSEC requirements doc was published *a decade* after=
DNSSEC itself.=C2=A0 Mind you, other protocols are still waiting for their<= br> requirements doc to be published.=C2=A0 PKIX specifically actively declined= to
consider use cases because heck, this is a standards committee dammit, we can't be expected to take into account what people want to do with it.<= br>
Mind you, in the absence of any success criteria, no-one can say you've=
failed...

Peter.


It is w= orth reading this paper apparently from 2010 on reusing ephemeral keys:


Regardless, I can hope= the Snowden disclosures will force people into action.

But please.

Continue to make the internet se= cure.
--001a114b79bc5c9c7c053f27936b-- From nobody Tue Oct 18 13:00:31 2016 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 61C2812947E for ; Tue, 18 Oct 2016 13:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 pqsMxUJZSdpa for ; Tue, 18 Oct 2016 13:00:27 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085191296E0 for ; Tue, 18 Oct 2016 13:00:27 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id z190so6119748qkc.2 for ; Tue, 18 Oct 2016 13:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u240zbaxemQfSjTlTJ/BVSLG0x4zb00SBMN62duFr3U=; b=NdEdhyzQhlhaV4z/0Mkyq+GQFBXl+pSwRBg3gwH/rWsOb660p2AAC5XfTLFLYyFdk/ /CST/1Jh9kMlwhuyGCofS/MfPygh52NMZ7rqr0EM/8baEP/nHmDdjP//xv+6PoEV8Yk0 g+mC/tEUY305TC0unITbXLMaYNDwhyadIWQNWDoB8hUfdoahRcepUM/3pp+LE+GC5rwN YUsLnpa3wbO+eYEY2i6dIk3umMPX1DdeIaq4lOuy8SkwTLaddfCawyziHBeGv0g9Gm2A aGHVIJGBzd4Gi/htQhlCbOCDrVsjdqaSRhhfvUcQevgJ+OTpsxPJepZC1tlUt5AL9fRh WG/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u240zbaxemQfSjTlTJ/BVSLG0x4zb00SBMN62duFr3U=; b=dPI1KoG3PEMMDrAjDJZzGfulOlhMARPFsSg094bntHskabwvqEnqlFcXeQNse3NhTq ZBVJL4v/VyxfSrZBFXXXuOBQMOYiK/TZ0kxW5cxPAFhwPnZ9ijaKXFM9uE9VT9vepsnV Z9gqBCQwpDj1NGLXX7rfkzq7Sr54ykV66+S+VEwkD1K89HeE3dzcvKdVpkjemH1evEYf hTaMiHPeKHzx4v27EwgFfyBtrc0MaYTDdMJ9zugLozB3GRELKdIYNxJnLPAbIuMj9Xjv R6t3WK+51Rfk0SLp7V/T6RgPpqZ9qbfQJN3CPwXV4SDkwp+L9fGCclxqSJEVUJjeZyMJ bOuw== X-Gm-Message-State: AA6/9RlBcxI9pAuoH14RAb8la5JBODyad9J/50FgbxylGB18Ud1W//i3MPHsn69/voNUgPNg5ij4J+fNs4q5fg== X-Received: by 10.55.47.198 with SMTP id v189mr10949qkh.250.1476820820493; Tue, 18 Oct 2016 13:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.22.1 with HTTP; Tue, 18 Oct 2016 12:59:59 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Tue, 18 Oct 2016 12:59:59 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114f471a67203d053f2924ad Archived-At: Cc: "" Subject: Re: [TLS] PR#634: Registry for TLS protocol version ID 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: Tue, 18 Oct 2016 20:00:29 -0000 --001a114f471a67203d053f2924ad Content-Type: text/plain; charset=UTF-8 It doesn't look like we have enough consensus to adopt this proposal. Thanks, J&S On Sun, Oct 16, 2016 at 6:03 PM, Eric Rescorla wrote: > Chairs: Can you advise on the disposition of this? > > -Ekr > > > On Wed, Oct 12, 2016 at 6:10 PM, Martin Thomson > wrote: > >> On 13 October 2016 at 12:07, Eric Rescorla wrote: >> > I assume you would prefer hex, i.e., 0x0303? >> >> Yeah, that would be nice: it's recognizably the same as the old one that >> way. >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114f471a67203d053f2924ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It doesn't look like we have enough consensus to adopt= this proposal. =C2=A0

Thanks,

= J&S

On Sun, Oct 16, 2016 at 6:03 PM, Eric Rescorla <ekr@rtfm.com> w= rote:
Chairs: Can you ad= vise on the disposition of this?

-Ekr

=
On Wed, Oct 12, 2016 at 6:10 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
On 13 October 2016 at 12:07, Eric Rescorla <ekr@rtfm.com> wrote:<= br> > I assume you would prefer hex, i.e., 0x0303?

Yeah, that would be nice: it's recognizably the same as the old = one that way.


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


--001a114f471a67203d053f2924ad-- From nobody Tue Oct 18 16:43:32 2016 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 94A68129479 for ; Tue, 18 Oct 2016 16:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 k1FnX6f3ZCLB for ; Tue, 18 Oct 2016 16:43:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id B0927127A91 for ; Tue, 18 Oct 2016 16:43:27 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7DD2D43345C; Tue, 18 Oct 2016 23:43:26 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5CFCC43340F; Tue, 18 Oct 2016 23:43:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1476834206; bh=yBkDUqgJdEfLSPDU5oXZatAFPicibe2trDfSpXTEVFQ=; l=34475; h=To:References:From:Date:In-Reply-To:From; b=ih3iMKHAhNsKKAiy0z4R84HKkXFCQc0HgjYJihTx2KmVfAidGEhVbOOY0rGb/Au5Q Jv+k/StEs4Fz6gpfCAB2LmhWNkfFzcnCQWVkmVTNmZoJOi7Yohv3IxhlG9Wlx5OODg tt/GT3pEI47Mid1RBj6r7MHIVD9TxHedCxHp0NRE= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 021CC1FC88; Tue, 18 Oct 2016 23:43:25 +0000 (GMT) To: Ilari Liusvaara , tls@ietf.org References: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 18 Oct 2016 18:43:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/alternative; boundary="------------296BA98AC4A465C585DC1E2D" Archived-At: Subject: Re: [TLS] New review through the TLS 1.3 Editor's Copy 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: Tue, 18 Oct 2016 23:43:31 -0000 This is a multi-part message in MIME format. --------------296BA98AC4A465C585DC1E2D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit [I trimmed a couple things that already had sub-threads spun off; leaving in others even where I don't have a comment right now] On 10/17/2016 01:10 PM, Ilari Liusvaara wrote: > >> Finally, the client and server exchange Authentication messages. TLS >> uses the same set of messages every time that authentication is needed. >> Specifically: >> >> Certificate. >> : the certificate of the endpoint. This message is omitted if the >> server is not authenticating with a certificate. Note that if raw >> public keys {{RFC7250}} or the cached information extension >> {{?RFC7924}} are in use, then this message will not >> contain a certificate but rather some other value corresponding to >> the server's long-term key. [{{certificate}}] > This is also omitted for client if CertificateRequest was not sent, > right? That as my understanding. >> CertificateVerify. >> : a signature over the entire handshake using the public key >> in the Certificate message. This message is omitted if the >> server is not authenticating via a certificate. [{{certificate-verify}}] > Same as above. And additionally, for client, doesn't sending an > empty certificate omit this? For post-handshake, that is explicitly stated. It is also implicitly stated for in-handshake ("Clients MUST send this message [CertificateVerify] whenever authenticating via a Certificate (i.e., when the Certificate message is non-empty)." >> ## Zero-RTT Data >> >> With the Zero-RTT mode, clients can send data on their first flight >> ("early data") whereby the client uses a PSK either obtained >> out-of-band or as a ticket (i.e., one with the "early_data_info" >> extension) from an earlier exchange to authenticate to the server. >> >> When clients use a PSK obtained out-of-band then the following >> information MUST be provisioned to both parties: >> >> * The PSK identity >> * The cipher suite for use with this PSK >> * The key exchange and authentication modes this PSK is allowed to be used with >> * The Application-Layer Protocol Negotiation (ALPN) label(s) >> * The Server Name Indication (SNI), if any is to be used > The ALPN labels can't be plural. There must (nothing else will work) be > a single ALP (possibly being the implicit default ALP) for any 0-RTT- > capable PSK. I pointed this out on Kyle's declined pull request and he fixed it in a later one that has already been merged. > Also, AFAIK, the reason why ticket_age exists in PSK is to support > 0-RTT anti-replay. Without 0-RTT data, there is no point in using > anything that doesn't involve server-side contribution anyway (and > thus would get superrior security properties). > I basically agree, and see only minimal reason why the ticket_age_add needs to be mandatory. Sure, it can give the server some insight into rejecting stale tickets, but there are other ways to do so. >> 2. There are no guarantees of non-replay between connections. >> Unless the server takes special measures outside those provided by TLS, >> the server has no guarantee that the same >> 0-RTT data was not transmitted on multiple 0-RTT connections >> (See {{replay-time}} for more details). >> This is especially relevant if the data is authenticated either >> with TLS client authentication or inside the application layer >> protocol. However, 0-RTT data cannot be duplicated within a connection (i.e., the server >> will not process the same data twice for the same connection) and >> an attacker will not be able to make 0-RTT data appear to be >> 1-RTT data (because it is protected with different keys.) > Of course, if the server TLS library provodes the difference between > 0-RTT and 1-RTT data is a different matter... Yes, the library has to tell the application that 0-RTT data and 1-RTT data are different, or bad things happen. Watson had some text to that effect in PR 694, which was not accepted (some text in a counter-proposal by Martin Thomson was accepted). >> ### Server Hello >> >> version >> : This field contains the version of TLS negotiated for this session. Servers >> MUST select the lower of the highest supported server version and the version >> offered by the client in the ClientHello. In particular, servers MUST accept >> ClientHello messages with versions higher than those supported and negotiate >> the highest mutually supported version. For this version of the >> specification, the version is { 3, 4 }. (See {{backward-compatibility}} for >> details about backward compatibility.) > Err, don't they have to select highest client indicated version that they > support (now that version negotiation is with extensions)? > Basically. It is not clear to me whether there is consensus to say "highest version" or just "server picks". >> ## Hello Extensions >> >> An extension type MUST NOT appear in the ServerHello or HelloRetryRequest >> unless the same extension type appeared in the corresponding ClientHello. >> If a client receives an extension type in ServerHello or HelloRetryRequest >> that it did not request in the associated ClientHello, it MUST abort the >> handshake with an "unsupported_extension" fatal alert. > Add note that Cookie is an exception to this? I thought there was already an exception for cookie: [...] As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see Section 4.2.2 ) extension. Though perhaps it is still worth duplicating that guidance so it's easier to find. >> When multiple extensions of different types are present in the ClientHello or >> ServerHello messages, the extensions MAY appear in any order. There MUST NOT be >> more than one extension of the same type. > pre_shared_key is an exception to this in ClientHello, right? Yes. >> In general, the specification of each extension type needs to describe the >> effect of the extension both during full handshake and session resumption. Most >> current TLS extensions are relevant only when a session is initiated: when an >> older session is resumed, the server does not process these extensions in >> ClientHello, and does not include them in ServerHello. However, some >> extensions may specify different behavior during session resumption. >> [[TODO: update this and the previous paragraph to cover PSK-based resumption.]] > Basically, treating any extension specially with regards to full > handshake versus "resumption" is very likely to be a Bad Idea and > there should be good justifications on doing so. > > (Such difference would likely be a major source of implementation bugs.) > >> ### Signature Algorithms >> >> The client uses the "signature_algorithms" extension to indicate to the server >> which signature algorithms may be used in digital signatures. Clients which >> desire the server to authenticate via a certificate MUST send this extension. >> If a server >> is authenticating via a certificate and the client has not sent a >> "signature_algorithms" extension then the server MUST >> abort the handshake with a "missing_extension" alert >> (see {{mti-extensions}}). >> >> Servers which are authenticating via a certificate MUST indicate so >> by sending the client an empty "signature_algorithms" extension. > This looks to be a Bad Idea. It was to support that poorly tought-out > server certificate authentication in PSK mode, right? > > Basically, offering any means (even if there is "MUST" to "prevent" the > use) of disabling server authentication in non-PSK mode is a footgun. > >> ### Negotiated Groups >> >> As of TLS 1.3, servers are permitted to send the "supported_groups" >> extension to the client. If the server has a group it prefers to the >> ones in the "key_share" extension but is still willing to accept the >> ClientHello, it SHOULD send "supported_groups" to update the client's >> view of its preferences; this extension SHOULD contain all groups >> the server supports, regardless of whether they are currently >> supported by the client. Clients MUST NOT act upon any information >> found in "supported_groups" prior to successful completion of the >> handshake, but MAY use the information learned from a successfully >> completed handshake to change what groups they offer to a server in >> subsequent connections. > This means altering the set of key shares they offer to the server, > right? Not the set of groups they indicate as supported? > >> ### Key Share >> >> Upon receipt of this extension in a HelloRetryRequest, the client MUST first >> verify that the selected_group field corresponds to a group which was provided >> in the "supported_groups" extension in the original ClientHello. It MUST then >> verify that the selected_group field does not correspond to a group which was >> provided in the "key_share" extension in the original ClientHello. If either of >> these checks fails, then the client MUST abort the handshake with an >> "illegal_parameter" alert. Otherwise, when sending the new ClientHello, the >> client MUST append a new KeyShareEntry for the group indicated in the >> selected_group field to the groups in its original KeyShare. The remaining >> KeyShareEntry values MUST be preserved. > Err... Hasn't the KeyShare behaviour been changed from "append" to > "replace"? I thought so, yes. >> ### Pre-Shared Key Extension >> >> obfuscated_ticket_age >> : For each ticket, the time since the client learned about the server >> configuration that it is using, in milliseconds. This value is >> added modulo 2^32 to with the "ticket_age_add" value that was >> included with the ticket, see {{NewSessionTicket}}. This addition >> prevents passive observers from correlating sessions unless tickets >> are reused. Note: because ticket lifetimes are restricted to a >> week, 32 bits is enough to represent any plausible age, even in >> milliseconds. External tickets SHOULD use an obfuscated_ticket_age of >> 0; servers MUST ignore this value for external tickets. > The comment above about purpose of ticket_age also applies here. > >> ### Pre-Shared Key Exchange Modes >> >> In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" >> extension. The semantics of this extension are that the client only >> supports the use of PSKs with these modes, which restricts both the >> use of PSKs offered in this ClientHello and those which the server >> might supply via NewSessionTicket. > Why is this a separate extension and not part of pre_shared_key, given > that if the latter is present, this must be too? > > Seems like more complexity for absolutely no reason. I would understand > if this extension was optional if PSK is present, but it is not. The justification for making it separate is that the psk_key_exchange_modes also applies to what the server will send back in NST, so in theory one could send psk_key_exchange_modes but not pre_shared_key. I'm still a little dubious, but accepted the justification. > >> ### Early Data Indication >> >> When PSK resumption is used, the client can send application data >> in its first flight of messages. If the client opts to do so, it MUST >> supply an "early_data" extension as well as the "pre_shared_key" >> extension. > Can't early data now be used with any type of PSK, not just ones > provisioned by NewSessionTicket? Yes. -Ben >> A server MUST validate that the ticket age for the selected PSK >> identity (computed by un-masking PskIdentity.obfuscated_ticket_age) >> is within a small tolerance of the time since the ticket was >> issued (see {{replay-time}}). If it is not, the server SHOULD proceed >> with the handshake but reject 0-RTT, and SHOULD NOT take any other action >> that assumes that this ClientHello is fresh. > PSKs that are externally provisioned don't have any valid ticket age... > >> In order to accept early data, the server server MUST have accepted a >> PSK cipher suite and selected the the first key offered in the >> client's "pre_shared_key" extension. In addition, it MUST verify that >> the following values are consistent with those negotiated in the >> connection during which the ticket was established. >> >> - The TLS version number, AEAD algorithm, and the hash for HKDF. >> - The selected ALPN {{!RFC7443}} value, if any. > Actually, it must verify that the record protection matches, not > just the HKDF. > >> ## Server Parameters >> >> The same extension types MUST NOT appear in both the ServerHello and >> EncryptedExtensions. All server-sent extensions other than those explicitly >> listed in {{server-hello}} or designated in the IANA registry MUST only >> appear in EncryptedExtensions. Extensions which are designated to >> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients >> MUST check EncryptedExtensions for the presence of any forbidden >> extensions and if any are found MUST abort the handshake with an >> "illegal_parameter" alert. > Also there are extensions in Certificates as well... > >> #### Receiving a Certificate Message >> >> Any endpoint receiving any certificate signed using any signature algorithm >> using an MD5 hash MUST abort the handshake with a "bad_certificate" alert. >> SHA-1 is deprecated and it is RECOMMENDED that >> any endpoint receiving any certificate signed using any signature algorithm >> using a SHA-1 hash abort the handshake with a "bad_certificate" alert. >> All endpoints are RECOMMENDED to transition to SHA-256 or better as soon >> as possible to maintain interoperability with implementations >> currently in the process of phasing out SHA-1 support. > These requirements are problematic, and I have absolutely no intention > of ever implementing this in my TLS libs. They treat signatures involving > MD5 or SHA1 the same as unknown signature algorithm (which is not a fatal > error). > > To be clear, MD5 (and SHOULD for SHA-1) signatures are absolutely not > to be trusted. But those should be treated as unknown with no special > handling. > > Also, if there are self-signed certs, the self-signature is just to be > ignored. There are still CA root certs out there with MD5 signatures. > >> %%% Authentication Messages >> If sent by a server, the signature algorithm MUST be one offered in the >> client's "signature_algorithms" extension unless no valid certificate chain can be >> produced without unsupported algorithms (see {{signature-algorithms}}). > This is seemingly about server signatures. In that context, an > unknown algorithm has absolutely no chance of working. > >> ### New Session Ticket Message {#NewSessionTicket} >> >> Any ticket MUST only be resumed with a cipher suite that is identical >> to that negotiated connection where the ticket was established. > This kind of requirement is problematic when "external" PSKs have > requirement that just the hash matches. (Implementation bugs). > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------296BA98AC4A465C585DC1E2D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit [I trimmed a couple things that already had sub-threads spun off; leaving in others even where I don't have a comment right now]

On 10/17/2016 01:10 PM, Ilari Liusvaara wrote:

Finally, the client and server exchange Authentication messages. TLS
uses the same set of messages every time that authentication is needed.
Specifically:

Certificate.
: the certificate of the endpoint. This message is omitted if the
  server is not authenticating with a certificate. Note that if raw
  public keys {{RFC7250}} or the cached information extension
  {{?RFC7924}} are in use, then this message will not
  contain a certificate but rather some other value corresponding to
  the server's long-term key.  [{{certificate}}]

This is also omitted for client if CertificateRequest was not sent,
right?

That as my understanding.


      

        
CertificateVerify.
: a signature over the entire handshake using the public key
  in the Certificate message. This message is omitted if the
  server is not authenticating via a certificate. [{{certificate-verify}}]


      

      
Same as above. And additionally, for client, doesn't sending an
empty certificate omit this?


    

    

    For post-handshake, that is explicitly stated.  It is also
    implicitly stated for in-handshake ("Clients MUST send this message
    [CertificateVerify] whenever authenticating via a Certificate (i.e.,
    when the Certificate message is non-empty)."

    

    

      

      

        
## Zero-RTT Data

With the Zero-RTT mode, clients can send data on their first flight
("early data") whereby the client uses a PSK either obtained 
out-of-band or as a ticket (i.e., one with the "early_data_info" 
extension) from an earlier exchange to authenticate to the server. 

When clients use a PSK obtained out-of-band then the following 
information MUST be provisioned to both parties:

  * The PSK identity
  * The cipher suite for use with this PSK
  * The key exchange and authentication modes this PSK is allowed to be used with
  * The Application-Layer Protocol Negotiation (ALPN) label(s)
  * The Server Name Indication (SNI), if any is to be used


      

      
The ALPN labels can't be plural. There must (nothing else will work) be
a single ALP (possibly being the implicit default ALP) for any 0-RTT-
capable PSK.


    

    

    I pointed this out on Kyle's declined pull request and he fixed it
    in a later one that has already been merged.

    

    

      
Also, AFAIK, the reason why ticket_age exists in PSK is to support
0-RTT anti-replay. Without 0-RTT data, there is no point in using
anything that doesn't involve server-side contribution anyway (and
thus would get superrior security properties).



    

    

    I basically agree, and see only minimal reason why the
    ticket_age_add needs to be mandatory.  Sure, it can give the server
    some insight into rejecting stale tickets, but there are other ways
    to do so.

    

    

      

        
2. There are no guarantees of non-replay between connections.
Unless the server takes special measures outside those provided by TLS,
the server has no guarantee that the same
0-RTT data was not transmitted on multiple 0-RTT connections
(See {{replay-time}} for more details).
This is especially relevant if the data is authenticated either
with TLS client authentication or inside the application layer
protocol. However, 0-RTT data cannot be duplicated within a connection (i.e., the server
will not process the same data twice for the same connection) and
an attacker will not be able to make 0-RTT data appear to be
1-RTT data (because it is protected with different keys.)


      

      
Of course, if the server TLS library provodes the difference between
0-RTT and 1-RTT data is a different matter...


    

    

    Yes, the library has to tell the application that 0-RTT data and
    1-RTT data are different, or bad things happen.  Watson had some
    text to that effect in PR 694, which was not accepted (some text in
    a counter-proposal by Martin Thomson was accepted).

    

    

    

      

      

        
###  Server Hello

version
: This field contains the version of TLS negotiated for this session.  Servers
  MUST select the lower of the highest supported server version and the version
  offered by the client in the ClientHello.  In particular, servers MUST accept
  ClientHello messages with versions higher than those supported and negotiate
  the highest mutually supported version.  For this version of the
  specification, the version is { 3, 4 }.  (See {{backward-compatibility}} for
  details about backward compatibility.)


      

      
Err, don't they have to select highest client indicated version that they
support (now that version negotiation is with extensions)?



    

    

    Basically.  It is not clear to me whether there is consensus to say
    "highest version" or just "server picks".

    

    

      

      

        
##  Hello Extensions

An extension type MUST NOT appear in the ServerHello or HelloRetryRequest
unless the same extension type appeared in the corresponding ClientHello.
If a client receives an extension type in ServerHello or HelloRetryRequest
that it did not request in the associated ClientHello, it MUST abort the
handshake with an "unsupported_extension" fatal alert.


      

      
Add note that Cookie is an exception to this?


    

    

    I thought there was already an exception for cookie:

    

    
   [...]  As with
   ServerHello, a HelloRetryRequest MUST NOT contain any extensions that
   were not first offered by the client in its ClientHello, with the
   exception of optionally the "cookie" (see Section 4.2.2) extension.


    Though perhaps it is still worth duplicating that guidance so it's
    easier to find.

    

    

      

      

        
When multiple extensions of different types are present in the ClientHello or
ServerHello messages, the extensions MAY appear in any order. There MUST NOT be
more than one extension of the same type.


      

      
pre_shared_key is an exception to this in ClientHello, right?


    

    

    Yes.

    

    

      

      

        
In general, the specification of each extension type needs to describe the
effect of the extension both during full handshake and session resumption. Most
current TLS extensions are relevant only when a session is initiated: when an
older session is resumed, the server does not process these extensions in
ClientHello, and does not include them in ServerHello. However, some
extensions may specify different behavior during session resumption.
[[TODO: update this and the previous paragraph to cover PSK-based resumption.]]


      

      
Basically, treating any extension specially with regards to full
handshake versus "resumption" is very likely to be a Bad Idea and
there should be good justifications on doing so.

(Such difference would likely be a major source of implementation bugs.)



      

        
###  Signature Algorithms

The client uses the "signature_algorithms" extension to indicate to the server
which signature algorithms may be used in digital signatures. Clients which
desire the server to authenticate via a certificate MUST send this extension.
If a server
is authenticating via a certificate and the client has not sent a
"signature_algorithms" extension then the server MUST
abort the handshake with a "missing_extension" alert
(see {{mti-extensions}}).

Servers which are authenticating via a certificate MUST indicate so
by sending the client an empty "signature_algorithms" extension.


      

      
This looks to be a Bad Idea. It was to support that poorly tought-out
server certificate authentication in PSK mode, right?

Basically, offering any means (even if there is "MUST" to "prevent" the
use) of disabling server authentication in non-PSK mode is a footgun.



      

        
### Negotiated Groups

As of TLS 1.3, servers are permitted to send the "supported_groups"
extension to the client. If the server has a group it prefers to the
ones in the "key_share" extension but is still willing to accept the
ClientHello, it SHOULD send "supported_groups" to update the client's
view of its preferences; this extension SHOULD contain all groups
the server supports, regardless of whether they are currently
supported by the client. Clients MUST NOT act upon any information
found in "supported_groups" prior to successful completion of the
handshake, but MAY use the information learned from a successfully
completed handshake to change what groups they offer to a server in
subsequent connections.


      

      
This means altering the set of key shares they offer to the server,
right? Not the set of groups they indicate as supported?



      

        
### Key Share

Upon receipt of this extension in a HelloRetryRequest, the client MUST first
verify that the selected_group field corresponds to a group which was provided
in the "supported_groups" extension in the original ClientHello. It MUST then
verify that the selected_group field does not correspond to a group which was
provided in the "key_share" extension in the original ClientHello. If either of
these checks fails, then the client MUST abort the handshake with an
"illegal_parameter" alert.  Otherwise, when sending the new ClientHello, the
client MUST append a new KeyShareEntry for the group indicated in the
selected_group field to the groups in its original KeyShare. The remaining
KeyShareEntry values MUST be preserved.


      

      
Err... Hasn't the KeyShare behaviour been changed from "append" to
"replace"?


    

    

    I thought so, yes.

    

    

      

      

        
### Pre-Shared Key Extension

obfuscated_ticket_age
: For each ticket, the time since the client learned about the server
  configuration that it is using, in milliseconds.  This value is
  added modulo 2^32 to with the "ticket_age_add" value that was
  included with the ticket, see {{NewSessionTicket}}.  This addition
  prevents passive observers from correlating sessions unless tickets
  are reused.  Note: because ticket lifetimes are restricted to a
  week, 32 bits is enough to represent any plausible age, even in
  milliseconds. External tickets SHOULD use an obfuscated_ticket_age of
  0; servers MUST ignore this value for external tickets.


      

      
The comment above about purpose of ticket_age also applies here.



      

        
### Pre-Shared Key Exchange Modes

In order to use PSKs, clients MUST also send a "psk_key_exchange_modes"
extension. The semantics of this extension are that the client only
supports the use of PSKs with these modes, which restricts both the
use of PSKs offered in this ClientHello and those which the server
might supply via NewSessionTicket.


      

      
Why is this a separate extension and not part of pre_shared_key, given
that if the latter is present, this must be too?

Seems like more complexity for absolutely no reason. I would understand
if this extension was optional if PSK is present, but it is not.


    

    

    The justification for making it separate is that the
    psk_key_exchange_modes also applies to what the server will send
    back in NST, so in theory one could send psk_key_exchange_modes but
    not pre_shared_key.  I'm still a little dubious, but accepted the
    justification.

    

    

      



      

        
### Early Data Indication

When PSK resumption is used, the client can send application data
in its first flight of messages. If the client opts to do so, it MUST
supply an "early_data" extension as well as the "pre_shared_key"
extension.


      

      
Can't early data now be used with any type of PSK, not just ones
provisioned by NewSessionTicket?


    

    

    Yes.

    

    -Ben

    

    

      

      

        
A server MUST validate that the ticket age for the selected PSK
identity (computed by un-masking PskIdentity.obfuscated_ticket_age)
is within a small tolerance of the time since the ticket was
issued (see {{replay-time}}).  If it is not, the server SHOULD proceed
with the handshake but reject 0-RTT, and SHOULD NOT take any other action
that assumes that this ClientHello is fresh.


      

      
PSKs that are externally provisioned don't have any valid ticket age...



      

        
In order to accept early data, the server server MUST have accepted a
PSK cipher suite and selected the the first key offered in the
client's "pre_shared_key" extension. In addition, it MUST verify that
the following values are consistent with those negotiated in the
connection during which the ticket was established.

- The TLS version number, AEAD algorithm, and the hash for HKDF.
- The selected ALPN {{!RFC7443}} value, if any.


      

      
Actually, it must verify that the record protection matches, not
just the HKDF.



      

        
## Server Parameters

The same extension types MUST NOT appear in both the ServerHello and
EncryptedExtensions. All server-sent extensions other than those explicitly
listed in {{server-hello}} or designated in the IANA registry MUST only
appear in EncryptedExtensions. Extensions which are designated to
appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients
MUST check EncryptedExtensions for the presence of any forbidden
extensions and if any are found MUST abort the handshake with an
"illegal_parameter" alert.


      

      
Also there are extensions in Certificates as well...



      

        
#### Receiving a Certificate Message

Any endpoint receiving any certificate signed using any signature algorithm
using an MD5 hash MUST abort the handshake with a "bad_certificate" alert.
SHA-1 is deprecated and it is RECOMMENDED that
any endpoint receiving any certificate signed using any signature algorithm
using a SHA-1 hash abort the handshake with a "bad_certificate" alert.
All endpoints are RECOMMENDED to transition to SHA-256 or better as soon
as possible to maintain interoperability with implementations
currently in the process of phasing out SHA-1 support.


      

      
These requirements are problematic, and I have absolutely no intention
of ever implementing this in my TLS libs. They treat signatures involving
MD5 or SHA1 the same as unknown signature algorithm (which is not a fatal
error).

To be clear, MD5 (and SHOULD for SHA-1) signatures are absolutely not
to be trusted. But those should be treated as unknown with no special
handling.

Also, if there are self-signed certs, the self-signature is just to be
ignored. There are still CA root certs out there with MD5 signatures.



      

        
%%% Authentication Messages


      

      

      

        
If sent by a server, the signature algorithm MUST be one offered in the
client's "signature_algorithms" extension unless no valid certificate chain can be
produced without unsupported algorithms (see {{signature-algorithms}}).


      

      
This is seemingly about server signatures. In that context, an
unknown algorithm has absolutely no chance of working.



      

        
### New Session Ticket Message {#NewSessionTicket}

Any ticket MUST only be resumed with a cipher suite that is identical
to that negotiated connection where the ticket was established.


      

      
This kind of requirement is problematic when "external" PSKs have
requirement that just the hash matches. (Implementation bugs).



-Ilari

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


    

    

  


--------------296BA98AC4A465C585DC1E2D--


From nobody Tue Oct 18 17:35:43 2016
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 CB15A1288B8 for ; Tue, 18 Oct 2016 17:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Ppol5xATAmX1 for ; Tue, 18 Oct 2016 17:35:36 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131831293EC for ; Tue, 18 Oct 2016 17:35:36 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id u124so6487142ywg.3 for ; Tue, 18 Oct 2016 17:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KYFfjVL/30lh6l1MsjW3kzbTJFSqRmbBdfRcUugPrkw=; b=XEg6rXLk1vXWri4ZJPyaNE0WoB9cRe9V9ksD5pjd1yGbfmfctvF6irhiC69Eped3+p G+4H5J5sPENgbYX7xgl+De4+/uKM9gqYveMz5OzDLBfCNGBBvITjXZAPkn3TRduyduRj OfDGYWg0duTg+E3wB7i3SA0qt/Qc/DQ0gTEomdCwtS7RqCvcFodEn5q4DzPOA5HLlFa6 DYzUFVISXyUEC+UUm9x9C8smBC8/0uVsZEqJirCfnYwGS5H4nQrz9cecccl5DeNv+a1t n/lAalD2uz+hiDFFr7o8Vv2IKq56GLbkS/y1XqFSTTwzN1Fma/8Ix+uGLMtzWwYamtRo VZ3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KYFfjVL/30lh6l1MsjW3kzbTJFSqRmbBdfRcUugPrkw=; b=mOJ/6Zr7P8OvXhyM4e4djkX76p9y3ByneOiRHGcH+rCdeO+i2ZP88mQ8oiJ/FnWOpI uff4g+6qG8+L4TTUUqz+kHWBVXUMjZzF3nRA5tIbm9yAlrB0kDY8lUoU5SLWA1MNJL34 fatiK2WUo/VgHkJLHNoO5f5aUkuEt+DZrJf9tNOIvdCdttqgdQpA6PDaeTuUnioOLNX7 5reITXVcdpd2rEh+iiFkc+FirXGFoxqI6psOXlm2GyOUrrUUCAam9zooUAzmmoqYL0Ie 8r3XKaEuir2ww2BpLAOuLOZ01ARSL8WBike2XDGTKIOqWjIN4BZcaQZA9BVDSMkD8aec DMcA==
X-Gm-Message-State: AA6/9RmPg/dpGqrj34JKfaDnDAN+P+RejaAcHb9wwGwclZvtTEo/EU1K7+IKmUDnsmpVBQmWcYS7BGjxQ9wJSQ==
X-Received: by 10.13.195.1 with SMTP id f1mr3642755ywd.354.1476837335118; Tue, 18 Oct 2016 17:35:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.212 with HTTP; Tue, 18 Oct 2016 17:34:54 -0700 (PDT)
In-Reply-To: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Tue, 18 Oct 2016 20:34:54 -0400
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a114e4e5cc08570053f2cfcf6
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] New review through the TLS 1.3 Editor's Copy
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: Wed, 19 Oct 2016 00:35:42 -0000

--001a114e4e5cc08570053f2cfcf6
Content-Type: text/plain; charset=UTF-8

I've updated the draft in response to a bunch of these comments and
scheduled some for update when I enter my own review comments which
are still in the "marked up document stage"

> > EncryptedExtensions.
> > : responses to any extensions that are not required to
> >   determine the cryptographic parameters. [{{encrypted-extensions}}]
>
> Also, with Certificate extensions, the extensions here need to not
> be specific to a certificate or certificate chain.

Updated.


> > Finally, the client and server exchange Authentication messages. TLS
> > uses the same set of messages every time that authentication is needed.
> > Specifically:
> >
> > Certificate.
> > : the certificate of the endpoint. This message is omitted if the
> >   server is not authenticating with a certificate. Note that if raw
> >   public keys {{RFC7250}} or the cached information extension
> >   {{?RFC7924}} are in use, then this message will not
> >   contain a certificate but rather some other value corresponding to
> >   the server's long-term key.  [{{certificate}}]
>
> This is also omitted for client if CertificateRequest was not sent,
> right?
>
> > CertificateVerify.
> > : a signature over the entire handshake using the public key
> >   in the Certificate message. This message is omitted if the
> >   server is not authenticating via a certificate.
[{{certificate-verify}}]
>
> Same as above. And additionally, for client, doesn't sending an
> empty certificate omit this?

Updated both of these.


> > ## Zero-RTT Data
> >
> > With the Zero-RTT mode, clients can send data on their first flight
> > ("early data") whereby the client uses a PSK either obtained
> > out-of-band or as a ticket (i.e., one with the "early_data_info"
> > extension) from an earlier exchange to authenticate to the server.
> >
> > When clients use a PSK obtained out-of-band then the following
> > information MUST be provisioned to both parties:
> >
> >   * The PSK identity
> >   * The cipher suite for use with this PSK
> >   * The key exchange and authentication modes this PSK is allowed to be
used with
> >   * The Application-Layer Protocol Negotiation (ALPN) label(s)
> >   * The Server Name Indication (SNI), if any is to be used
>
> The ALPN labels can't be plural. There must (nothing else will work) be
> a single ALP (possibly being the implicit default ALP) for any 0-RTT-
> capable PSK.

This was updated in PR#706.


> Also, AFAIK, the reason why ticket_age exists in PSK is to support
> 0-RTT anti-replay. Without 0-RTT data, there is no point in using
> anything that doesn't involve server-side contribution anyway (and
> thus would get superrior security properties).

I don't quite agree with this. I moved it from the 0-RTT messages to the
PSK messages so that the server had an opportunity to detect replay
of the ClientHello in case it was going to send 0.5 RTT data or other
side effects. This is an observation due to someone on the miTLS team
(can't remember who) that 0.5RTT (even without 0-RTT client data)
is like a client 0-RTT "I am here" message.


> > ## Decoding Errors
> >
> > TLS defines two generic alerts (see {{alert-protocol}}) to use upon
failure to parse
> > a message. Peers which receive a message which cannot be parsed
according to the syntax
> > (e.g., have a length extending beyond the message boundary or contain
an out-of-range
> > length) MUST terminate the connection with a "decoding_error" alert.
Peers which receive
> > a message which is syntactically correct but semantically invalid
(e.g., a DHE share of p - 1)
> > MUST terminate the connection with an "illegal_parameter" alert.
>
> What alert is used if some field is an non-extensible enumeration and
> the value transmitted is outside the legal values?
>
> E.g. An unknown max_fragment_length value.
>
> I have used illegal_parameter for errors like this.

Yeah, this seems like illegal_parameter.

I updated to make this clear.


> Also, isn't the alert name decode_error, not decoding_error?

Fixed.


> > ###  Client Hello
> >
> > In the event that a client requests additional functionality using
> > extensions, and this functionality is not supplied by the server, the
> > client MAY abort the handshake. Note that TLS 1.3 ClientHello messages
> > MUST always contain extensions, and a TLS 1.3 server MUST respond to
> > any TLS 1.3 ClientHello without extensions or with data following
> > the extensions block with a "decode_error"
> > alert. TLS 1.3 servers may receive TLS 1.2 ClientHello messages
> > without extensions. If negotiating TLS 1.2, a server MUST check that
> > the message either contains no data after legacy_compression_methods
> > or that it contains a valid extensions block with no data following.
> > If not, then it MUST abort the handshake with a "decode_error" alert.
>
> Note that it is now impossible to receive a TLS 1.3 ClientHello without
> extensions (any such would be interpretted as TLS 1.2 ClientHello
> without extensions).

True. Updated.

> > ###  Server Hello
> >
> > version
> > : This field contains the version of TLS negotiated for this session.
Servers
> >   MUST select the lower of the highest supported server version and the
version
> >   offered by the client in the ClientHello.  In particular, servers
MUST accept
> >   ClientHello messages with versions higher than those supported and
negotiate
> >   the highest mutually supported version.  For this version of the
> >   specification, the version is { 3, 4 }.  (See
{{backward-compatibility}} for
> >   details about backward compatibility.)
>
> Err, don't they have to select highest client indicated version that they
> support (now that version negotiation is with extensions)?

This was recently updated to just require that the pick from the list.


> > ##  Hello Extensions
> >
> > An extension type MUST NOT appear in the ServerHello or
HelloRetryRequest
> > unless the same extension type appeared in the corresponding
ClientHello.
> > If a client receives an extension type in ServerHello or
HelloRetryRequest
> > that it did not request in the associated ClientHello, it MUST abort the
> > handshake with an "unsupported_extension" fatal alert.
>
> Add note that Cookie is an exception to this?

Noted.


> > When multiple extensions of different types are present in the
ClientHello or
> > ServerHello messages, the extensions MAY appear in any order. There
MUST NOT be
> > more than one extension of the same type.
>
> pre_shared_key is an exception to this in ClientHello, right?

Thanks. Good catch.


> > In general, the specification of each extension type needs to describe
the
> > effect of the extension both during full handshake and session
resumption. Most
> > current TLS extensions are relevant only when a session is initiated:
when an
> > older session is resumed, the server does not process these extensions
in
> > ClientHello, and does not include them in ServerHello. However, some
> > extensions may specify different behavior during session resumption.
> > [[TODO: update this and the previous paragraph to cover PSK-based
resumption.]]
>
> Basically, treating any extension specially with regards to full
> handshake versus "resumption" is very likely to be a Bad Idea and
> there should be good justifications on doing so.
>
> (Such difference would likely be a major source of implementation bugs.)

Yes. I have in my notes to fix this.


> > ###  Signature Algorithms
> >
> > The client uses the "signature_algorithms" extension to indicate to the
server
> > which signature algorithms may be used in digital signatures. Clients
which
> > desire the server to authenticate via a certificate MUST send this
extension.
> > If a server
> > is authenticating via a certificate and the client has not sent a
> > "signature_algorithms" extension then the server MUST
> > abort the handshake with a "missing_extension" alert
> > (see {{mti-extensions}}).
> >
> > Servers which are authenticating via a certificate MUST indicate so
> > by sending the client an empty "signature_algorithms" extension.
>
> This looks to be a Bad Idea. It was to support that poorly tought-out
> server certificate authentication in PSK mode, right?

This is just cruft from before. Thanks for catching it.


> Basically, offering any means (even if there is "MUST" to "prevent" the
> use) of disabling server authentication in non-PSK mode is a footgun.
>
> > ### Negotiated Groups
> >
> > As of TLS 1.3, servers are permitted to send the "supported_groups"
> > extension to the client. If the server has a group it prefers to the
> > ones in the "key_share" extension but is still willing to accept the
> > ClientHello, it SHOULD send "supported_groups" to update the client's
> > view of its preferences; this extension SHOULD contain all groups
> > the server supports, regardless of whether they are currently
> > supported by the client. Clients MUST NOT act upon any information
> > found in "supported_groups" prior to successful completion of the
> > handshake, but MAY use the information learned from a successfully
> > completed handshake to change what groups they offer to a server in
> > subsequent connections.
>
> This means altering the set of key shares they offer to the server,
> right? Not the set of groups they indicate as supported?

Clarified.


> > ### Key Share
> >
> > Upon receipt of this extension in a HelloRetryRequest, the client MUST
first
> > verify that the selected_group field corresponds to a group which was
provided
> > in the "supported_groups" extension in the original ClientHello. It
MUST then
> > verify that the selected_group field does not correspond to a group
which was
> > provided in the "key_share" extension in the original ClientHello. If
either of
> > these checks fails, then the client MUST abort the handshake with an
> > "illegal_parameter" alert.  Otherwise, when sending the new
ClientHello, the
> > client MUST append a new KeyShareEntry for the group indicated in the
> > selected_group field to the groups in its original KeyShare. The
remaining
> > KeyShareEntry values MUST be preserved.
>
> Err... Hasn't the KeyShare behaviour been changed from "append" to
> "replace"?
>
> > ### Pre-Shared Key Extension
> >
> > obfuscated_ticket_age
> > : For each ticket, the time since the client learned about the server
> >   configuration that it is using, in milliseconds.  This value is
> >   added modulo 2^32 to with the "ticket_age_add" value that was
> >   included with the ticket, see {{NewSessionTicket}}.  This addition
> >   prevents passive observers from correlating sessions unless tickets
> >   are reused.  Note: because ticket lifetimes are restricted to a
> >   week, 32 bits is enough to represent any plausible age, even in
> >   milliseconds. External tickets SHOULD use an obfuscated_ticket_age of
> >   0; servers MUST ignore this value for external tickets.
>
> The comment above about purpose of ticket_age also applies here.

See above.


> > ### Pre-Shared Key Exchange Modes
> >
> > In order to use PSKs, clients MUST also send a "psk_key_exchange_modes"
> > extension. The semantics of this extension are that the client only
> > supports the use of PSKs with these modes, which restricts both the
> > use of PSKs offered in this ClientHello and those which the server
> > might supply via NewSessionTicket.
>
> Why is this a separate extension and not part of pre_shared_key, given
> that if the latter is present, this must be too?
>
> Seems like more complexity for absolutely no reason. I would understand
> if this extension was optional if PSK is present, but it is not.

As noted elsewhere, this allows the server to know whether it will be
able to send a ticket that will be acceptable to the client in
advance.


> > ### Early Data Indication
> >
> > When PSK resumption is used, the client can send application data
> > in its first flight of messages. If the client opts to do so, it MUST
> > supply an "early_data" extension as well as the "pre_shared_key"
> > extension.
>
> Can't early data now be used with any type of PSK, not just ones
> provisioned by NewSessionTicket?

Yes, thanks.


> > A server MUST validate that the ticket age for the selected PSK
> > identity (computed by un-masking PskIdentity.obfuscated_ticket_age)
> > is within a small tolerance of the time since the ticket was
> > issued (see {{replay-time}}).  If it is not, the server SHOULD proceed
> > with the handshake but reject 0-RTT, and SHOULD NOT take any other
action
> > that assumes that this ClientHello is fresh.
>
> PSKs that are externally provisioned don't have any valid ticket age...

Yes, thanks.


> > In order to accept early data, the server server MUST have accepted a
> > PSK cipher suite and selected the the first key offered in the
> > client's "pre_shared_key" extension. In addition, it MUST verify that
> > the following values are consistent with those negotiated in the
> > connection during which the ticket was established.
> >
> > - The TLS version number, AEAD algorithm, and the hash for HKDF.
> > - The selected ALPN {{!RFC7443}} value, if any.
>
> Actually, it must verify that the record protection matches, not
> just the HKDF.

Note that it says "AEAD algorithm", but this was before we broke the
cipher suites apart, so I have changed this to "cipher suite"


> > ## Server Parameters
> >
> > The same extension types MUST NOT appear in both the ServerHello and
> > EncryptedExtensions. All server-sent extensions other than those
explicitly
> > listed in {{server-hello}} or designated in the IANA registry MUST only
> > appear in EncryptedExtensions. Extensions which are designated to
> > appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients
> > MUST check EncryptedExtensions for the presence of any forbidden
> > extensions and if any are found MUST abort the handshake with an
> > "illegal_parameter" alert.
>
> Also there are extensions in Certificates as well...

Yes. I have scheduled a more general cleanup here.


> > #### Receiving a Certificate Message
> >
> > Any endpoint receiving any certificate signed using any signature
algorithm
> > using an MD5 hash MUST abort the handshake with a "bad_certificate"
alert.
> > SHA-1 is deprecated and it is RECOMMENDED that
> > any endpoint receiving any certificate signed using any signature
algorithm
> > using a SHA-1 hash abort the handshake with a "bad_certificate" alert.
> > All endpoints are RECOMMENDED to transition to SHA-256 or better as soon
> > as possible to maintain interoperability with implementations
> > currently in the process of phasing out SHA-1 support.
>
> These requirements are problematic, and I have absolutely no intention
> of ever implementing this in my TLS libs. They treat signatures involving
> MD5 or SHA1 the same as unknown signature algorithm (which is not a fatal
> error).
>
> To be clear, MD5 (and SHOULD for SHA-1) signatures are absolutely not
> to be trusted. But those should be treated as unknown with no special
> handling.
>
> Also, if there are self-signed certs, the self-signature is just to be
> ignored. There are still CA root certs out there with MD5 signatures.
>
> > %%% Authentication Messages
>
> > If sent by a server, the signature algorithm MUST be one offered in the
> > client's "signature_algorithms" extension unless no valid certificate
chain can be
> > produced without unsupported algorithms (see {{signature-algorithms}}).
>
> This is seemingly about server signatures. In that context, an
> unknown algorithm has absolutely no chance of working.

I generally share your view of these requirements, but they were the
result of a lot of list discussion, so I think we'll need a new
PR to change it. If you want to produce one, that would be useful
for discussion.


> > ### New Session Ticket Message {#NewSessionTicket}
> >
> > Any ticket MUST only be resumed with a cipher suite that is identical
> > to that negotiated connection where the ticket was established.
>
> This kind of requirement is problematic when "external" PSKs have
> requirement that just the hash matches. (Implementation bugs).

Agreed. I will harmonize these.

-Ekr


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


On Mon, Oct 17, 2016 at 2:10 PM, Ilari Liusvaara 
wrote:

> Did a new review of the document, given that stuff from the older
> review got addressed.
>
> Consulted the older review when making this, but not the issue lists:
>
>
> > EncryptedExtensions.
> > : responses to any extensions that are not required to
> >   determine the cryptographic parameters. [{{encrypted-extensions}}]
>
> Also, with Certificate extensions, the extensions here need to not
> be specific to a certificate or certificate chain.
>
> > Finally, the client and server exchange Authentication messages. TLS
> > uses the same set of messages every time that authentication is needed.
> > Specifically:
> >
> > Certificate.
> > : the certificate of the endpoint. This message is omitted if the
> >   server is not authenticating with a certificate. Note that if raw
> >   public keys {{RFC7250}} or the cached information extension
> >   {{?RFC7924}} are in use, then this message will not
> >   contain a certificate but rather some other value corresponding to
> >   the server's long-term key.  [{{certificate}}]
>
> This is also omitted for client if CertificateRequest was not sent,
> right?
>
> > CertificateVerify.
> > : a signature over the entire handshake using the public key
> >   in the Certificate message. This message is omitted if the
> >   server is not authenticating via a certificate.
> [{{certificate-verify}}]
>
> Same as above. And additionally, for client, doesn't sending an
> empty certificate omit this?
>
> > ## Zero-RTT Data
> >
> > With the Zero-RTT mode, clients can send data on their first flight
> > ("early data") whereby the client uses a PSK either obtained
> > out-of-band or as a ticket (i.e., one with the "early_data_info"
> > extension) from an earlier exchange to authenticate to the server.
> >
> > When clients use a PSK obtained out-of-band then the following
> > information MUST be provisioned to both parties:
> >
> >   * The PSK identity
> >   * The cipher suite for use with this PSK
> >   * The key exchange and authentication modes this PSK is allowed to be
> used with
> >   * The Application-Layer Protocol Negotiation (ALPN) label(s)
> >   * The Server Name Indication (SNI), if any is to be used
>
> The ALPN labels can't be plural. There must (nothing else will work) be
> a single ALP (possibly being the implicit default ALP) for any 0-RTT-
> capable PSK.
>
> Also, AFAIK, the reason why ticket_age exists in PSK is to support
> 0-RTT anti-replay. Without 0-RTT data, there is no point in using
> anything that doesn't involve server-side contribution anyway (and
> thus would get superrior security properties).
>
> > 2. There are no guarantees of non-replay between connections.
> > Unless the server takes special measures outside those provided by TLS,
> > the server has no guarantee that the same
> > 0-RTT data was not transmitted on multiple 0-RTT connections
> > (See {{replay-time}} for more details).
> > This is especially relevant if the data is authenticated either
> > with TLS client authentication or inside the application layer
> > protocol. However, 0-RTT data cannot be duplicated within a connection
> (i.e., the server
> > will not process the same data twice for the same connection) and
> > an attacker will not be able to make 0-RTT data appear to be
> > 1-RTT data (because it is protected with different keys.)
>
> Of course, if the server TLS library provodes the difference between
> 0-RTT and 1-RTT data is a different matter...
>
> > ## Decoding Errors
> >
> > TLS defines two generic alerts (see {{alert-protocol}}) to use upon
> failure to parse
> > a message. Peers which receive a message which cannot be parsed
> according to the syntax
> > (e.g., have a length extending beyond the message boundary or contain an
> out-of-range
> > length) MUST terminate the connection with a "decoding_error" alert.
> Peers which receive
> > a message which is syntactically correct but semantically invalid (e.g.,
> a DHE share of p - 1)
> > MUST terminate the connection with an "illegal_parameter" alert.
>
> What alert is used if some field is an non-extensible enumeration and
> the value transmitted is outside the legal values?
>
> E.g. An unknown max_fragment_length value.
>
> I have used illegal_parameter for errors like this.
>
> Also, isn't the alert name decode_error, not decoding_error?
>
> > ###  Client Hello
> >
> > In the event that a client requests additional functionality using
> > extensions, and this functionality is not supplied by the server, the
> > client MAY abort the handshake. Note that TLS 1.3 ClientHello messages
> > MUST always contain extensions, and a TLS 1.3 server MUST respond to
> > any TLS 1.3 ClientHello without extensions or with data following
> > the extensions block with a "decode_error"
> > alert. TLS 1.3 servers may receive TLS 1.2 ClientHello messages
> > without extensions. If negotiating TLS 1.2, a server MUST check that
> > the message either contains no data after legacy_compression_methods
> > or that it contains a valid extensions block with no data following.
> > If not, then it MUST abort the handshake with a "decode_error" alert.
>
> Note that it is now impossible to receive a TLS 1.3 ClientHello without
> extensions (any such would be interpretted as TLS 1.2 ClientHello
> without extensions).
>
> > ###  Server Hello
> >
> > version
> > : This field contains the version of TLS negotiated for this session.
> Servers
> >   MUST select the lower of the highest supported server version and the
> version
> >   offered by the client in the ClientHello.  In particular, servers MUST
> accept
> >   ClientHello messages with versions higher than those supported and
> negotiate
> >   the highest mutually supported version.  For this version of the
> >   specification, the version is { 3, 4 }.  (See
> {{backward-compatibility}} for
> >   details about backward compatibility.)
>
> Err, don't they have to select highest client indicated version that they
> support (now that version negotiation is with extensions)?
>
>
> > ##  Hello Extensions
> >
> > An extension type MUST NOT appear in the ServerHello or HelloRetryRequest
> > unless the same extension type appeared in the corresponding ClientHello.
> > If a client receives an extension type in ServerHello or
> HelloRetryRequest
> > that it did not request in the associated ClientHello, it MUST abort the
> > handshake with an "unsupported_extension" fatal alert.
>
> Add note that Cookie is an exception to this?
>
> > When multiple extensions of different types are present in the
> ClientHello or
> > ServerHello messages, the extensions MAY appear in any order. There MUST
> NOT be
> > more than one extension of the same type.
>
> pre_shared_key is an exception to this in ClientHello, right?
>
> > In general, the specification of each extension type needs to describe
> the
> > effect of the extension both during full handshake and session
> resumption. Most
> > current TLS extensions are relevant only when a session is initiated:
> when an
> > older session is resumed, the server does not process these extensions in
> > ClientHello, and does not include them in ServerHello. However, some
> > extensions may specify different behavior during session resumption.
> > [[TODO: update this and the previous paragraph to cover PSK-based
> resumption.]]
>
> Basically, treating any extension specially with regards to full
> handshake versus "resumption" is very likely to be a Bad Idea and
> there should be good justifications on doing so.
>
> (Such difference would likely be a major source of implementation bugs.)
>
> > ###  Signature Algorithms
> >
> > The client uses the "signature_algorithms" extension to indicate to the
> server
> > which signature algorithms may be used in digital signatures. Clients
> which
> > desire the server to authenticate via a certificate MUST send this
> extension.
> > If a server
> > is authenticating via a certificate and the client has not sent a
> > "signature_algorithms" extension then the server MUST
> > abort the handshake with a "missing_extension" alert
> > (see {{mti-extensions}}).
> >
> > Servers which are authenticating via a certificate MUST indicate so
> > by sending the client an empty "signature_algorithms" extension.
>
> This looks to be a Bad Idea. It was to support that poorly tought-out
> server certificate authentication in PSK mode, right?
>
> Basically, offering any means (even if there is "MUST" to "prevent" the
> use) of disabling server authentication in non-PSK mode is a footgun.
>
> > ### Negotiated Groups
> >
> > As of TLS 1.3, servers are permitted to send the "supported_groups"
> > extension to the client. If the server has a group it prefers to the
> > ones in the "key_share" extension but is still willing to accept the
> > ClientHello, it SHOULD send "supported_groups" to update the client's
> > view of its preferences; this extension SHOULD contain all groups
> > the server supports, regardless of whether they are currently
> > supported by the client. Clients MUST NOT act upon any information
> > found in "supported_groups" prior to successful completion of the
> > handshake, but MAY use the information learned from a successfully
> > completed handshake to change what groups they offer to a server in
> > subsequent connections.
>
> This means altering the set of key shares they offer to the server,
> right? Not the set of groups they indicate as supported?
>
> > ### Key Share
> >
> > Upon receipt of this extension in a HelloRetryRequest, the client MUST
> first
> > verify that the selected_group field corresponds to a group which was
> provided
> > in the "supported_groups" extension in the original ClientHello. It MUST
> then
> > verify that the selected_group field does not correspond to a group
> which was
> > provided in the "key_share" extension in the original ClientHello. If
> either of
> > these checks fails, then the client MUST abort the handshake with an
> > "illegal_parameter" alert.  Otherwise, when sending the new ClientHello,
> the
> > client MUST append a new KeyShareEntry for the group indicated in the
> > selected_group field to the groups in its original KeyShare. The
> remaining
> > KeyShareEntry values MUST be preserved.
>
> Err... Hasn't the KeyShare behaviour been changed from "append" to
> "replace"?
>
> > ### Pre-Shared Key Extension
> >
> > obfuscated_ticket_age
> > : For each ticket, the time since the client learned about the server
> >   configuration that it is using, in milliseconds.  This value is
> >   added modulo 2^32 to with the "ticket_age_add" value that was
> >   included with the ticket, see {{NewSessionTicket}}.  This addition
> >   prevents passive observers from correlating sessions unless tickets
> >   are reused.  Note: because ticket lifetimes are restricted to a
> >   week, 32 bits is enough to represent any plausible age, even in
> >   milliseconds. External tickets SHOULD use an obfuscated_ticket_age of
> >   0; servers MUST ignore this value for external tickets.
>
> The comment above about purpose of ticket_age also applies here.
>
> > ### Pre-Shared Key Exchange Modes
> >
> > In order to use PSKs, clients MUST also send a "psk_key_exchange_modes"
> > extension. The semantics of this extension are that the client only
> > supports the use of PSKs with these modes, which restricts both the
> > use of PSKs offered in this ClientHello and those which the server
> > might supply via NewSessionTicket.
>
> Why is this a separate extension and not part of pre_shared_key, given
> that if the latter is present, this must be too?
>
> Seems like more complexity for absolutely no reason. I would understand
> if this extension was optional if PSK is present, but it is not.
>
>
> > ### Early Data Indication
> >
> > When PSK resumption is used, the client can send application data
> > in its first flight of messages. If the client opts to do so, it MUST
> > supply an "early_data" extension as well as the "pre_shared_key"
> > extension.
>
> Can't early data now be used with any type of PSK, not just ones
> provisioned by NewSessionTicket?
>
> > A server MUST validate that the ticket age for the selected PSK
> > identity (computed by un-masking PskIdentity.obfuscated_ticket_age)
> > is within a small tolerance of the time since the ticket was
> > issued (see {{replay-time}}).  If it is not, the server SHOULD proceed
> > with the handshake but reject 0-RTT, and SHOULD NOT take any other action
> > that assumes that this ClientHello is fresh.
>
> PSKs that are externally provisioned don't have any valid ticket age...
>
> > In order to accept early data, the server server MUST have accepted a
> > PSK cipher suite and selected the the first key offered in the
> > client's "pre_shared_key" extension. In addition, it MUST verify that
> > the following values are consistent with those negotiated in the
> > connection during which the ticket was established.
> >
> > - The TLS version number, AEAD algorithm, and the hash for HKDF.
> > - The selected ALPN {{!RFC7443}} value, if any.
>
> Actually, it must verify that the record protection matches, not
> just the HKDF.
>
> > ## Server Parameters
> >
> > The same extension types MUST NOT appear in both the ServerHello and
> > EncryptedExtensions. All server-sent extensions other than those
> explicitly
> > listed in {{server-hello}} or designated in the IANA registry MUST only
> > appear in EncryptedExtensions. Extensions which are designated to
> > appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients
> > MUST check EncryptedExtensions for the presence of any forbidden
> > extensions and if any are found MUST abort the handshake with an
> > "illegal_parameter" alert.
>
> Also there are extensions in Certificates as well...
>
> > #### Receiving a Certificate Message
> >
> > Any endpoint receiving any certificate signed using any signature
> algorithm
> > using an MD5 hash MUST abort the handshake with a "bad_certificate"
> alert.
> > SHA-1 is deprecated and it is RECOMMENDED that
> > any endpoint receiving any certificate signed using any signature
> algorithm
> > using a SHA-1 hash abort the handshake with a "bad_certificate" alert.
> > All endpoints are RECOMMENDED to transition to SHA-256 or better as soon
> > as possible to maintain interoperability with implementations
> > currently in the process of phasing out SHA-1 support.
>
> These requirements are problematic, and I have absolutely no intention
> of ever implementing this in my TLS libs. They treat signatures involving
> MD5 or SHA1 the same as unknown signature algorithm (which is not a fatal
> error).
>
> To be clear, MD5 (and SHOULD for SHA-1) signatures are absolutely not
> to be trusted. But those should be treated as unknown with no special
> handling.
>
> Also, if there are self-signed certs, the self-signature is just to be
> ignored. There are still CA root certs out there with MD5 signatures.
>
> > %%% Authentication Messages
>
> > If sent by a server, the signature algorithm MUST be one offered in the
> > client's "signature_algorithms" extension unless no valid certificate
> chain can be
> > produced without unsupported algorithms (see {{signature-algorithms}}).
>
> This is seemingly about server signatures. In that context, an
> unknown algorithm has absolutely no chance of working.
>
> > ### New Session Ticket Message {#NewSessionTicket}
> >
> > Any ticket MUST only be resumed with a cipher suite that is identical
> > to that negotiated connection where the ticket was established.
>
> This kind of requirement is problematic when "external" PSKs have
> requirement that just the hash matches. (Implementation bugs).
>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a114e4e5cc08570053f2cfcf6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I've updated the draft in response to a bunch of =
these comments and
scheduled some for update when I enter my own =
review comments which
are still in the "marked up document s=
tage"

> > EncryptedExtensions.
> > : responses to any extensions that are not required to
> > =C2=A0 determine the cryptographic parameters. [{{encrypted-ext=
ensions}}]
>=C2=A0
> Also, with Certificate exten=
sions, the extensions here need to not
> be specific to a cert=
ificate or certificate chain.

Updated.
<=
br>

> > Finally, the client and server excha=
nge Authentication messages. TLS
> > uses the same set of m=
essages every time that authentication is needed.
> > Speci=
fically:
> >=C2=A0
> > Certificate.
> > : the certificate of the endpoint. This message is omitted if =
the
> > =C2=A0 server is not authenticating with a certific=
ate. Note that if raw
> > =C2=A0 public keys {{RFC7250}} or=
 the cached information extension
> > =C2=A0 {{?RFC7924}} a=
re in use, then this message will not
> > =C2=A0 contain a =
certificate but rather some other value corresponding to
> >=
; =C2=A0 the server's long-term key. =C2=A0[{{certificate}}]
=
>=C2=A0
> This is also omitted for client if CertificateReq=
uest was not sent,
> right?
>=C2=A0
>=
; > CertificateVerify.
> > : a signature over the entire=
 handshake using the public key
> > =C2=A0 in the Certifica=
te message. This message is omitted if the
> > =C2=A0 serve=
r is not authenticating via a certificate. [{{certificate-verify}}]
>=C2=A0
> Same as above. And additionally, for client, d=
oesn't sending an
> empty certificate omit this?

Updated both of these.


<=
div>> > ## Zero-RTT Data
> >=C2=A0
> >=
; With the Zero-RTT mode, clients can send data on their first flight
=

> > ("early data") whereby the client uses a PSK eithe=
r obtained=C2=A0
> > out-of-band or as a ticket (i.e., one =
with the "early_data_info"=C2=A0
> > extension) f=
rom an earlier exchange to authenticate to the server.=C2=A0
>=
 >=C2=A0
> > When clients use a PSK obtained out-of-band=
 then the following=C2=A0
> > information MUST be provision=
ed to both parties:
> >=C2=A0
> > =C2=A0 * =
The PSK identity
> > =C2=A0 * The cipher suite for use with=
 this PSK
> > =C2=A0 * The key exchange and authentication =
modes this PSK is allowed to be used with
> > =C2=A0 * The =
Application-Layer Protocol Negotiation (ALPN) label(s)
> > =
=C2=A0 * The Server Name Indication (SNI), if any is to be used
&=
gt;=C2=A0
> The ALPN labels can't be plural. There must (n=
othing else will work) be
> a single ALP (possibly being the i=
mplicit default ALP) for any 0-RTT-
> capable PSK.
<=
br>
This was updated in PR#706.


> Also, AFAIK, the reason why ticket_age exists in PSK is to supp=
ort
> 0-RTT anti-replay. Without 0-RTT data, there is no point=
 in using
> anything that doesn't involve server-side cont=
ribution anyway (and
> thus would get superrior security prope=
rties).

I don't quite agree with this. I moved=
 it from the 0-RTT messages to the
PSK messages so that the serve=
r had an opportunity to detect replay
of the ClientHello in case =
it was going to send 0.5 RTT data or other
side effects. This is =
an observation due to someone on the miTLS team
(can't rememb=
er who) that 0.5RTT (even without 0-RTT client data)
is like a cl=
ient 0-RTT "I am here" message.


> > ## Decoding Errors
> >=C2=A0
>=
; > TLS defines two generic alerts (see {{alert-protocol}}) to use upon =
failure to parse
> > a message. Peers which receive a messa=
ge which cannot be parsed according to the syntax
> > (e.g.=
, have a length extending beyond the message boundary or contain an out-of-=
range
> > length) MUST terminate the connection with a &quo=
t;decoding_error" alert. Peers which receive
> > a mes=
sage which is syntactically correct but semantically invalid (e.g., a DHE s=
hare of p - 1)
> > MUST terminate the connection with an &q=
uot;illegal_parameter" alert.
>=C2=A0
> What=
 alert is used if some field is an non-extensible enumeration and
> the value transmitted is outside the legal values?
>=C2=
=A0
> E.g. An unknown max_fragment_length value.
>=
;=C2=A0
> I have used illegal_parameter for errors like this.<=
/div>

Yeah, this seems like illegal_parameter.

I updated to make this clear.


=

> Also, isn't the alert name decode_error, not decoding_e=
rror?

Fixed.


> > ### =C2=A0Client Hello
> >
> >=
 In the event that a client requests additional functionality using
> > extensions, and this functionality is not supplied by the serv=
er, the
> > client MAY abort the handshake. Note that TLS 1=
.3 ClientHello messages
> > MUST always contain extensions,=
 and a TLS 1.3 server MUST respond to
> > any TLS 1.3 Clien=
tHello without extensions or with data following
> > the ex=
tensions block with a "decode_error"
> > alert. T=
LS 1.3 servers may receive TLS 1.2 ClientHello messages
> >=
 without extensions. If negotiating TLS 1.2, a server MUST check that
=

> > the message either contains no data after legacy_compression=
_methods
> > or that it contains a valid extensions block w=
ith no data following.
> > If not, then it MUST abort the h=
andshake with a "decode_error" alert.
>=C2=A0
<=
div>> Note that it is now impossible to receive a TLS 1.3 ClientHello wi=
thout
> extensions (any such would be interpretted as TLS 1.2 =
ClientHello
> without extensions).

Tr=
ue. Updated.

> > ### =C2=A0Server Hello
> >=C2=A0
> > version
> > : Thi=
s field contains the version of TLS negotiated for this session.=C2=A0 Serv=
ers
> > =C2=A0 MUST select the lower of the highest support=
ed server version and the version
> > =C2=A0 offered by the=
 client in the ClientHello.=C2=A0 In particular, servers MUST accept
<=
div>> > =C2=A0 ClientHello messages with versions higher than those s=
upported and negotiate
> > =C2=A0 the highest mutually supp=
orted version.=C2=A0 For this version of the
> > =C2=A0 spe=
cification, the version is { 3, 4 }. =C2=A0(See {{backward-compatibility}} =
for
> > =C2=A0 details about backward compatibility.)
=

>=C2=A0
> Err, don't they have to select highest c=
lient indicated version that they
> support (now that version =
negotiation is with extensions)?

This was recently=
 updated to just require that the pick from the list.

<=
div>
> > ## =C2=A0Hello Extensions
> >=
=C2=A0
> > An extension type MUST NOT appear in the ServerH=
ello or HelloRetryRequest
> > unless the same extension typ=
e appeared in the corresponding ClientHello.
> > If a clien=
t receives an extension type in ServerHello or HelloRetryRequest
=
> > that it did not request in the associated ClientHello, it MUST ab=
ort the
> > handshake with an "unsupported_extension&q=
uot; fatal alert.
>=C2=A0
> Add note that Cookie =
is an exception to this?

Noted.


> > When multiple extensions of different types=
 are present in the ClientHello or
> > ServerHello messages=
, the extensions MAY appear in any order. There MUST NOT be
> =
> more than one extension of the same type.
>=C2=A0
> pre_shared_key is an exception to this in ClientHello, right?
=


Thanks. Good catch.


=

> > In general, the specification of each extension type needs t=
o describe the
> > effect of the extension both during full=
 handshake and session resumption. Most
> > current TLS ext=
ensions are relevant only when a session is initiated: when an
&g=
t; > older session is resumed, the server does not process these extensi=
ons in
> > ClientHello, and does not include them in Server=
Hello. However, some
> > extensions may specify different b=
ehavior during session resumption.
> > [[TODO: update this =
and the previous paragraph to cover PSK-based resumption.]]
>=
=C2=A0
> Basically, treating any extension specially with rega=
rds to full
> handshake versus "resumption" is very =
likely to be a Bad Idea and
> there should be good justificati=
ons on doing so.
>=C2=A0
> (Such difference would=
 likely be a major source of implementation bugs.)

Yes. I have in my notes to fix this.


> > ### =C2=A0Signature Algorithms
> >=C2=A0
=

> > The client uses the "signature_algorithms" extensi=
on to indicate to the server
> > which signature algorithms=
 may be used in digital signatures. Clients which
> > desir=
e the server to authenticate via a certificate MUST send this extension.
> > If a server
> > is authenticating via a c=
ertificate and the client has not sent a
> > "signatur=
e_algorithms" extension then the server MUST
> > abort=
 the handshake with a "missing_extension" alert
> &g=
t; (see {{mti-extensions}}).
> >=C2=A0
> > =
Servers which are authenticating via a certificate MUST indicate so
> > by sending the client an empty "signature_algorithms"=
; extension.
>=C2=A0
> This looks to be a Bad Ide=
a. It was to support that poorly tought-out
> server certifica=
te authentication in PSK mode, right?

This is just=
 cruft from before. Thanks for catching it.


> Basically, offering any means (even if there is "MUST&qu=
ot; to "prevent" the
> use) of disabling server auth=
entication in non-PSK mode is a footgun.
>=C2=A0
>=
; > ### Negotiated Groups
> >=C2=A0
> > =
As of TLS 1.3, servers are permitted to send the "supported_groups&quo=
t;
> > extension to the client. If the server has a group i=
t prefers to the
> > ones in the "key_share" exte=
nsion but is still willing to accept the
> > ClientHello, i=
t SHOULD send "supported_groups" to update the client's
=

> > view of its preferences; this extension SHOULD contain all g=
roups
> > the server supports, regardless of whether they a=
re currently
> > supported by the client. Clients MUST NOT =
act upon any information
> > found in "supported_group=
s" prior to successful completion of the
> > handshake=
, but MAY use the information learned from a successfully
> &g=
t; completed handshake to change what groups they offer to a server in
> > subsequent connections.
>=C2=A0
>=
 This means altering the set of key shares they offer to the server,
<=
div>> right? Not the set of groups they indicate as supported?

Clarified.


> >=
; ### Key Share
> >=C2=A0
> > Upon receipt =
of this extension in a HelloRetryRequest, the client MUST first
&=
gt; > verify that the selected_group field corresponds to a group which =
was provided
> > in the "supported_groups" extens=
ion in the original ClientHello. It MUST then
> > verify th=
at the selected_group field does not correspond to a group which was
<=
div>> > provided in the "key_share" extension in the origin=
al ClientHello. If either of
> > these checks fails, then t=
he client MUST abort the handshake with an
> > "illega=
l_parameter" alert.=C2=A0 Otherwise, when sending the new ClientHello,=
 the
> > client MUST append a new KeyShareEntry for the gro=
up indicated in the
> > selected_group field to the groups =
in its original KeyShare. The remaining
> > KeyShareEntry v=
alues MUST be preserved.
>=C2=A0
> Err... Hasn=
9;t the KeyShare behaviour been changed from "append" to
> "replace"?
>=C2=A0
> > ### Pr=
e-Shared Key Extension
> >=C2=A0
> > obfusc=
ated_ticket_age
> > : For each ticket, the time since the c=
lient learned about the server
> > =C2=A0 configuration tha=
t it is using, in milliseconds.=C2=A0 This value is
> > =C2=
=A0 added modulo 2^32 to with the "ticket_age_add" value that was=

> > =C2=A0 included with the ticket, see {{NewSessionTicke=
t}}.=C2=A0 This addition
> > =C2=A0 prevents passive observ=
ers from correlating sessions unless tickets
> > =C2=A0 are=
 reused.=C2=A0 Note: because ticket lifetimes are restricted to a
> > =C2=A0 week, 32 bits is enough to represent any plausible age, e=
ven in
> > =C2=A0 milliseconds. External tickets SHOULD use=
 an obfuscated_ticket_age of
> > =C2=A0 0; servers MUST ign=
ore this value for external tickets.
>=C2=A0
> Th=
e comment above about purpose of ticket_age also applies here.
See above.


> > #=
## Pre-Shared Key Exchange Modes
> >=C2=A0
> &=
gt; In order to use PSKs, clients MUST also send a "psk_key_exchange_m=
odes"
> > extension. The semantics of this extension a=
re that the client only
> > supports the use of PSKs with t=
hese modes, which restricts both the
> > use of PSKs offere=
d in this ClientHello and those which the server
> > might =
supply via NewSessionTicket.
>=C2=A0
> Why is thi=
s a separate extension and not part of pre_shared_key, given
>=
 that if the latter is present, this must be too?
>=C2=A0
> Seems like more complexity for absolutely no reason. I would und=
erstand
> if this extension was optional if PSK is present, bu=
t it is not.

As noted elsewhere, this allows the s=
erver to know whether it will be
able to send a ticket that will =
be acceptable to the client in
advance.

=

> > ### Early Data Indication
> >=C2=
=A0
> > When PSK resumption is used, the client can send ap=
plication data
> > in its first flight of messages. If the =
client opts to do so, it MUST
> > supply an "early_dat=
a" extension as well as the "pre_shared_key"
> =
> extension.
>=C2=A0
> Can't early data no=
w be used with any type of PSK, not just ones
> provisioned by=
 NewSessionTicket?

Yes, thanks.


> > A server MUST validate that the ticket age =
for the selected PSK
> > identity (computed by un-masking P=
skIdentity.obfuscated_ticket_age)
> > is within a small tol=
erance of the time since the ticket was
> > issued (see {{r=
eplay-time}}).=C2=A0 If it is not, the server SHOULD proceed
>=
 > with the handshake but reject 0-RTT, and SHOULD NOT take any other ac=
tion
> > that assumes that this ClientHello is fresh.
=

>=C2=A0
> PSKs that are externally provisioned don'=
;t have any valid ticket age...

Yes, thanks.
=



> > In order to accept early data,=
 the server server MUST have accepted a
> > PSK cipher suit=
e and selected the the first key offered in the
> > client&=
#39;s "pre_shared_key" extension. In addition, it MUST verify tha=
t
> > the following values are consistent with those negoti=
ated in the
> > connection during which the ticket was esta=
blished.
> >=C2=A0
> > - The TLS version nu=
mber, AEAD algorithm, and the hash for HKDF.
> > - The sele=
cted ALPN {{!RFC7443}} value, if any.
>=C2=A0
> A=
ctually, it must verify that the record protection matches, not
&=
gt; just the HKDF.

Note that it says "AEAD al=
gorithm", but this was before we broke the
cipher suites apa=
rt, so I have changed this to "cipher suite"

=


> > ## Server Parameters
> >=C2=
=A0
> > The same extension types MUST NOT appear in both th=
e ServerHello and
> > EncryptedExtensions. All server-sent =
extensions other than those explicitly
> > listed in {{serv=
er-hello}} or designated in the IANA registry MUST only
> >=
 appear in EncryptedExtensions. Extensions which are designated to
> > appear in ServerHello MUST NOT appear in EncryptedExtensions. C=
lients
> > MUST check EncryptedExtensions for the presence =
of any forbidden
> > extensions and if any are found MUST a=
bort the handshake with an
> > "illegal_parameter"=
; alert.
>=C2=A0
> Also there are extensions in C=
ertificates as well...

Yes. I have scheduled a mor=
e general cleanup here.


> > #=
### Receiving a Certificate Message
> >
> >=
 Any endpoint receiving any certificate signed using any signature algorith=
m
> > using an MD5 hash MUST abort the handshake with a &qu=
ot;bad_certificate" alert.
> > SHA-1 is deprecated and=
 it is RECOMMENDED that
> > any endpoint receiving any cert=
ificate signed using any signature algorithm
> > using a SH=
A-1 hash abort the handshake with a "bad_certificate" alert.
> > All endpoints are RECOMMENDED to transition to SHA-256 or b=
etter as soon
> > as possible to maintain interoperability =
with implementations
> > currently in the process of phasin=
g out SHA-1 support.
>=C2=A0
> These requirements=
 are problematic, and I have absolutely no intention
> of ever=
 implementing this in my TLS libs. They treat signatures involving
> MD5 or SHA1 the same as unknown signature algorithm (which is not a =
fatal
> error).
>=C2=A0
> To be clea=
r, MD5 (and SHOULD for SHA-1) signatures are absolutely not
> =
to be trusted. But those should be treated as unknown with no special
=

> handling.
>=C2=A0
> Also, if there are =
self-signed certs, the self-signature is just to be
> ignored.=
 There are still CA root certs out there with MD5 signatures.
>=
;=C2=A0
> > %%% Authentication Messages
>=C2=
=A0
> > If sent by a server, the signature algorithm MUST b=
e one offered in the
> > client's "signature_algor=
ithms" extension unless no valid certificate chain can be
&g=
t; > produced without unsupported algorithms (see {{signature-algorithms=
}}).
>=C2=A0
> This is seemingly about server sig=
natures. In that context, an
> unknown algorithm has absolutel=
y no chance of working.

I generally share your vie=
w of these requirements, but they were the
result of a lot of lis=
t discussion, so I think we'll need a new
PR to change it. If=
 you want to produce one, that would be useful
for discussion.


> > ### New Session Ticket Mess=
age {#NewSessionTicket}
> >=C2=A0
> > Any t=
icket MUST only be resumed with a cipher suite that is identical
=
> > to that negotiated connection where the ticket was established.
>=C2=A0
> This kind of requirement is problematic =
when "external" PSKs have
> requirement that just th=
e hash matches. (Implementation bugs).

Agreed. I w=
ill harmonize these.

-Ekr


>=C2=A0
>=C2=A0
> -Ilari
=

>=C2=A0
> ____________________________________________=
___
> TLS mailing list
=


O=
n Mon, Oct 17, 2016 at 2:10 PM, Ilari Liusvaara <ilariliusvaara@wel=
ho.com> wrote:
Did a new re=
view of the document, given that stuff from the older

review got addressed.



Consulted the older review when making this, but not the issue lists:





> EncryptedExtensions.

> : responses to any extensions that are not required to

>=C2=A0 =C2=A0determine the cryptographic parameters. [{{encrypted-exten=
sions}}]



Also, with Certificate extensions, the extensions here need to not

be specific to a certificate or certificate chain.



> Finally, the client and server exchange Authentication messages. TLS
> uses the same set of messages every time that authentication is needed=
.

> Specifically:

>

> Certificate.

> : the certificate of the endpoint. This message is omitted if the

>=C2=A0 =C2=A0server is not authenticating with a certificate. Note that=
 if raw

>=C2=A0 =C2=A0public keys {{RFC7250}} or the cached information extensio=
n

>=C2=A0 =C2=A0{{?RFC7924}} are in use, then this message will not

>=C2=A0 =C2=A0contain a certificate but rather some other value correspo=
nding to

>=C2=A0 =C2=A0the server's long-term key.=C2=A0 [{{certificate}}]


This is also omitted for client if CertificateRequest was not sent,

right?



> CertificateVerify.

> : a signature over the entire handshake using the public key

>=C2=A0 =C2=A0in the Certificate message. This message is omitted if the=


>=C2=A0 =C2=A0server is not authenticating via a certificate. [{{certifi=
cate-verify}}]



Same as above. And additionally, for client, doesn't sending an

empty certificate omit this?



> ## Zero-RTT Data

>

> With the Zero-RTT mode, clients can send data on their first flight
> ("early data") whereby the client uses a PSK either obtained=


> out-of-band or as a ticket (i.e., one with the "early_data_info&q=
uot;

> extension) from an earlier exchange to authenticate to the server.

>

> When clients use a PSK obtained out-of-band then the following

> information MUST be provisioned to both parties:

>

>=C2=A0 =C2=A0* The PSK identity

>=C2=A0 =C2=A0* The cipher suite for use with this PSK

>=C2=A0 =C2=A0* The key exchange and authentication modes this PSK is al=
lowed to be used with

>=C2=A0 =C2=A0* The Application-Layer Protocol Negotiation (ALPN) label(=
s)

>=C2=A0 =C2=A0* The Server Name Indication (SNI), if any is to be used


The ALPN labels can't be plural. There must (nothing else will work) be=


a single ALP (possibly being the implicit default ALP) for any 0-RTT-

capable PSK.



Also, AFAIK, the reason why ticket_age exists in PSK is to support

0-RTT anti-replay. Without 0-RTT data, there is no point in using

anything that doesn't involve server-side contribution anyway (and

thus would get superrior security properties).



> 2. There are no guarantees of non-replay between connections.

> Unless the server takes special measures outside those provided by TLS=
,

> the server has no guarantee that the same

> 0-RTT data was not transmitted on multiple 0-RTT connections

> (See {{replay-time}} for more details).

> This is especially relevant if the data is authenticated either

> with TLS client authentication or inside the application layer

> protocol. However, 0-RTT data cannot be duplicated within a connection=
 (i.e., the server

> will not process the same data twice for the same connection) and

> an attacker will not be able to make 0-RTT data appear to be

> 1-RTT data (because it is protected with different keys.)



Of course, if the server TLS library provodes the difference between

0-RTT and 1-RTT data is a different matter...



> ## Decoding Errors

>

> TLS defines two generic alerts (see {{alert-protocol}}) to use upon fa=
ilure to parse

> a message. Peers which receive a message which cannot be parsed accord=
ing to the syntax

> (e.g., have a length extending beyond the message boundary or contain =
an out-of-range

> length) MUST terminate the connection with a "decoding_error"=
; alert. Peers which receive

> a message which is syntactically correct but semantically invalid (e.g=
., a DHE share of p - 1)

> MUST terminate the connection with an "illegal_parameter" al=
ert.



What alert is used if some field is an non-extensible enumeration and

the value transmitted is outside the legal values?



E.g. An unknown max_fragment_length value.



I have used illegal_parameter for errors like this.



Also, isn't the alert name decode_error, not decoding_error?



> ###=C2=A0 Client Hello

>

> In the event that a client requests additional functionality using

> extensions, and this functionality is not supplied by the server, the<=
br>
> client MAY abort the handshake. Note that TLS 1.3 ClientHello messages=


> MUST always contain extensions, and a TLS 1.3 server MUST respond to
> any TLS 1.3 ClientHello without extensions or with data following

> the extensions block with a "decode_error"

> alert. TLS 1.3 servers may receive TLS 1.2 ClientHello messages

> without extensions. If negotiating TLS 1.2, a server MUST check that
> the message either contains no data after legacy_compression_methods
> or that it contains a valid extensions block with no data following.
> If not, then it MUST abort the handshake with a "decode_error&quo=
t; alert.



Note that it is now impossible to receive a TLS 1.3 ClientHello without

extensions (any such would be interpretted as TLS 1.2 ClientHello

without extensions).



> ###=C2=A0 Server Hello

>

> version

> : This field contains the version of TLS negotiated for this session.=
=C2=A0 Servers

>=C2=A0 =C2=A0MUST select the lower of the highest supported server vers=
ion and the version

>=C2=A0 =C2=A0offered by the client in the ClientHello.=C2=A0 In particu=
lar, servers MUST accept

>=C2=A0 =C2=A0ClientHello messages with versions higher than those suppo=
rted and negotiate

>=C2=A0 =C2=A0the highest mutually supported version.=C2=A0 For this ver=
sion of the

>=C2=A0 =C2=A0specification, the version is { 3, 4 }.=C2=A0 (See {{backw=
ard-compatibility}} for

>=C2=A0 =C2=A0details about backward compatibility.)



Err, don't they have to select highest client indicated version that th=
ey

support (now that version negotiation is with extensions)?





> ##=C2=A0 Hello Extensions

>

> An extension type MUST NOT appear in the ServerHello or HelloRetryRequ=
est

> unless the same extension type appeared in the corresponding ClientHel=
lo.

> If a client receives an extension type in ServerHello or HelloRetryReq=
uest

> that it did not request in the associated ClientHello, it MUST abort t=
he

> handshake with an "unsupported_extension" fatal alert.



Add note that Cookie is an exception to this?



> When multiple extensions of different types are present in the ClientH=
ello or

> ServerHello messages, the extensions MAY appear in any order. There MU=
ST NOT be

> more than one extension of the same type.



pre_shared_key is an exception to this in ClientHello, right?



> In general, the specification of each extension type needs to describe=
 the

> effect of the extension both during full handshake and session resumpt=
ion. Most

> current TLS extensions are relevant only when a session is initiated: =
when an

> older session is resumed, the server does not process these extensions=
 in

> ClientHello, and does not include them in ServerHello. However, some
> extensions may specify different behavior during session resumption.
> [[TODO: update this and the previous paragraph to cover PSK-based resu=
mption.]]



Basically, treating any extension specially with regards to full

handshake versus "resumption" is very likely to be a Bad Idea and=


there should be good justifications on doing so.



(Such difference would likely be a major source of implementation bugs.)


> ###=C2=A0 Signature Algorithms

>

> The client uses the "signature_algorithms" extension to indi=
cate to the server

> which signature algorithms may be used in digital signatures. Clients =
which

> desire the server to authenticate via a certificate MUST send this ext=
ension.

> If a server

> is authenticating via a certificate and the client has not sent a

> "signature_algorithms" extension then the server MUST

> abort the handshake with a "missing_extension" alert

> (see {{mti-extensions}}).

>

> Servers which are authenticating via a certificate MUST indicate so
> by sending the client an empty "signature_algorithms" extens=
ion.



This looks to be a Bad Idea. It was to support that poorly tought-out

server certificate authentication in PSK mode, right?



Basically, offering any means (even if there is "MUST" to "p=
revent" the

use) of disabling server authentication in non-PSK mode is a footgun.



> ### Negotiated Groups

>

> As of TLS 1.3, servers are permitted to send the "supported_group=
s"

> extension to the client. If the server has a group it prefers to the
> ones in the "key_share" extension but is still willing to ac=
cept the

> ClientHello, it SHOULD send "supported_groups" to update the=
 client's

> view of its preferences; this extension SHOULD contain all groups

> the server supports, regardless of whether they are currently

> supported by the client. Clients MUST NOT act upon any information

> found in "supported_groups" prior to successful completion o=
f the

> handshake, but MAY use the information learned from a successfully

> completed handshake to change what groups they offer to a server in
> subsequent connections.



This means altering the set of key shares they offer to the server,

right? Not the set of groups they indicate as supported?



> ### Key Share

>

> Upon receipt of this extension in a HelloRetryRequest, the client MUST=
 first

> verify that the selected_group field corresponds to a group which was =
provided

> in the "supported_groups" extension in the original ClientHe=
llo. It MUST then

> verify that the selected_group field does not correspond to a group wh=
ich was

> provided in the "key_share" extension in the original Client=
Hello. If either of

> these checks fails, then the client MUST abort the handshake with an
> "illegal_parameter" alert.=C2=A0 Otherwise, when sending the=
 new ClientHello, the

> client MUST append a new KeyShareEntry for the group indicated in the<=
br>
> selected_group field to the groups in its original KeyShare. The remai=
ning

> KeyShareEntry values MUST be preserved.



Err... Hasn't the KeyShare behaviour been changed from "append&quo=
t; to

"replace"?



> ### Pre-Shared Key Extension

>

> obfuscated_ticket_age

> : For each ticket, the time since the client learned about the server<=
br>
>=C2=A0 =C2=A0configuration that it is using, in milliseconds.=C2=A0 Thi=
s value is

>=C2=A0 =C2=A0added modulo 2^32 to with the "ticket_age_add" v=
alue that was

>=C2=A0 =C2=A0included with the ticket, see {{NewSessionTicket}}.=C2=A0 =
This addition

>=C2=A0 =C2=A0prevents passive observers from correlating sessions unles=
s tickets

>=C2=A0 =C2=A0are reused.=C2=A0 Note: because ticket lifetimes are restr=
icted to a

>=C2=A0 =C2=A0week, 32 bits is enough to represent any plausible age, ev=
en in

>=C2=A0 =C2=A0milliseconds. External tickets SHOULD use an obfuscated_ti=
cket_age of

>=C2=A0 =C2=A00; servers MUST ignore this value for external tickets.


The comment above about purpose of ticket_age also applies here.



> ### Pre-Shared Key Exchange Modes

>

> In order to use PSKs, clients MUST also send a "psk_key_exchange_=
modes"

> extension. The semantics of this extension are that the client only
> supports the use of PSKs with these modes, which restricts both the
> use of PSKs offered in this ClientHello and those which the server

> might supply via NewSessionTicket.



Why is this a separate extension and not part of pre_shared_key, given

that if the latter is present, this must be too?



Seems like more complexity for absolutely no reason. I would understand

if this extension was optional if PSK is present, but it is not.





> ### Early Data Indication

>

> When PSK resumption is used, the client can send application data

> in its first flight of messages. If the client opts to do so, it MUST<=
br>
> supply an "early_data" extension as well as the "pre_sh=
ared_key"

> extension.



Can't early data now be used with any type of PSK, not just ones

provisioned by NewSessionTicket?



> A server MUST validate that the ticket age for the selected PSK

> identity (computed by un-masking PskIdentity.obfuscated_ticket_ag=
e)

> is within a small tolerance of the time since the ticket was

> issued (see {{replay-time}}).=C2=A0 If it is not, the server SHOULD pr=
oceed

> with the handshake but reject 0-RTT, and SHOULD NOT take any other act=
ion

> that assumes that this ClientHello is fresh.



PSKs that are externally provisioned don't have any valid ticket age...=




> In order to accept early data, the server server MUST have accepted a<=
br>
> PSK cipher suite and selected the the first key offered in the

> client's "pre_shared_key" extension. In addition, it MUS=
T verify that

> the following values are consistent with those negotiated in the

> connection during which the ticket was established.

>

> - The TLS version number, AEAD algorithm, and the hash for HKDF.

> - The selected ALPN {{!RFC7443}} value, if any.



Actually, it must verify that the record protection matches, not

just the HKDF.



> ## Server Parameters

>

> The same extension types MUST NOT appear in both the ServerHello and
> EncryptedExtensions. All server-sent extensions other than those expli=
citly

> listed in {{server-hello}} or designated in the IANA registry MUST onl=
y

> appear in EncryptedExtensions. Extensions which are designated to

> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients<=
br>
> MUST check EncryptedExtensions for the presence of any forbidden

> extensions and if any are found MUST abort the handshake with an

> "illegal_parameter" alert.



Also there are extensions in Certificates as well...



> #### Receiving a Certificate Message

>

> Any endpoint receiving any certificate signed using any signature algo=
rithm

> using an MD5 hash MUST abort the handshake with a "bad_certificat=
e" alert.

> SHA-1 is deprecated and it is RECOMMENDED that

> any endpoint receiving any certificate signed using any signature algo=
rithm

> using a SHA-1 hash abort the handshake with a "bad_certificate&qu=
ot; alert.

> All endpoints are RECOMMENDED to transition to SHA-256 or better as so=
on

> as possible to maintain interoperability with implementations

> currently in the process of phasing out SHA-1 support.



These requirements are problematic, and I have absolutely no intention

of ever implementing this in my TLS libs. They treat signatures involving
MD5 or SHA1 the same as unknown signature algorithm (which is not a fatal
error).



To be clear, MD5 (and SHOULD for SHA-1) signatures are absolutely not

to be trusted. But those should be treated as unknown with no special

handling.



Also, if there are self-signed certs, the self-signature is just to be

ignored. There are still CA root certs out there with MD5 signatures.



> %%% Authentication Messages



> If sent by a server, the signature algorithm MUST be one offered in th=
e

> client's "signature_algorithms" extension unless no vali=
d certificate chain can be

> produced without unsupported algorithms (see {{signature-algorithms}})=
.



This is seemingly about server signatures. In that context, an

unknown algorithm has absolutely no chance of working.



> ### New Session Ticket Message {#NewSessionTicket}

>

> Any ticket MUST only be resumed with a cipher suite that is identical<=
br>
> to that negotiated connection where the ticket was established.



This kind of requirement is problematic when "external" PSKs have=


requirement that just the hash matches. (Implementation bugs).







-Ilari



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114e4e5cc08570053f2cfcf6--


From nobody Wed Oct 19 08:58:52 2016
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 D06F41294A7 for ; Wed, 19 Oct 2016 08:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sqi1lCjK6DbT for ; Wed, 19 Oct 2016 08:58:48 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B51129413 for ; Wed, 19 Oct 2016 08:58:48 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3szc7B2Thgz1HWq; Wed, 19 Oct 2016 17:58:46 +0200 (CEST)
X-purgate-ID: 152705::1476892726-00003836-ABBC7F33/0/0
X-purgate-size: 1347
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3szc796SBwzkq48; Wed, 19 Oct 2016 17:58:45 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id D13E21A564; Wed, 19 Oct 2016 17:58:45 +0200 (CEST)
In-Reply-To: 
To: Kyle Nekritz 
Date: Wed, 19 Oct 2016 17:58:45 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161019155845.D13E21A564@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Deprecating alert levels
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 19 Oct 2016 15:58:52 -0000

Kyle Nekritz wrote:
> 
>> This list is already missing the warning-level "unrecognized_name" alert,
>> and such a change would imply that all new/unrecognized alerts are going
>> to be treated as fatal forever (i.e. that no new warning-level alerts
>> can ever be defined).
> 
> That alert is currently defined as a fatal alert (see section 6.2 in the
> current draft).  RFC 6066 also states "It is NOT RECOMMENDED to send a
> warning-level unrecognized_name(112) alert, because the client's behavior
> in response to warning-level alerts is unpredictable.", which I think
> illustrates the problem. Allowing new non-fatal alerts to be added later
> would require that existing clients ignore unknown warning alerts,
> which I think is somewhat dangerous.

It seems that rfc6066 is not clear enough in explaining the issue
about the situation with the two WELL-DEFINED (but poorly implemented)
variants of the TLS alerts

  (1)  unrecognized_name(112)  level WARNING
  (2)  unrecognized_name(112)  level FATAL

See the *ORIGINAL* specification which created *BOTH* of these alert variants:

https://tools.ietf.org/html/rfc3546#page-10


   If the server understood the client hello extension but does not
   recognize the server name, it SHOULD send an "unrecognized_name"
   alert (which MAY be fatal).


-Martin


From nobody Wed Oct 19 11:24:26 2016
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 F05991296EF for ; Wed, 19 Oct 2016 11:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 HyFygFkS2yhO for ; Wed, 19 Oct 2016 11:24:22 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB27D1296D6 for ; Wed, 19 Oct 2016 11:24:22 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id o68so51291650qkf.3 for ; Wed, 19 Oct 2016 11:24:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7nj1dsv10vhfcx4NoXv1KQDxcc+gtbSyQu1j6ntnNyU=; b=t9CNXoYMxg8ynqsA+FofApGKH/TDCRDCRzYdam2jymS00nIeqvXieSB2z6v+2pmmOq eCHR4HZzhby/Lg4CcbAo1PAgL6i8FBXtB/2Cprjm3h7UkHAnDbU3qe6FF3IGh3K4tKGx ErGXDMEUyfQXT63GqMhbYGpKff+pYj9Gz4q5IXBfZe/NqNtiIPT4efGIJhmmWtwotp4A sks1smXKIr70bloe8EaXQ0v+5YSeEo7RWh7hyapQ8as1dpLFNLZ+8weJV5nHX08UqJki 5BU/fo+E30PS4uXOXUGzyA5C9Pqi0bP0YAN1XCMI8wxK1am59EMZAnIAuh82wGvoRS4S QbpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7nj1dsv10vhfcx4NoXv1KQDxcc+gtbSyQu1j6ntnNyU=; b=SXOUa9vEChw3ZXLix/gXJ7GL4bp2jB9TS908OWspXNA4gHpUXPQ0/XpZIZ6iqA6fbH dJQhNk/5PqrUMqVfyZWVuVglpoy5CcmSqJmdvlHDdg5uf+mKl3QwGSJq6/k3UE68jwO5 JWXZr0EUU/hGDw+ANNJCGZcvUb4QopPYk6ac9LajfQpzjJDHFZwj+HvNg/4v4Of1XvpC yCBgXooEG1uIQlHo+UgnXFmguT3qG75tJJek56TAyNmberdx6Ra8/sO/ui8CTrsHhF15 bosySk3HkCAUwcFStYEXvQAcDSizsFPshnmeuwgw44rsoe4AE3ut3z3lqfNYed2LidCh ObJA==
X-Gm-Message-State: AA6/9Rl45aBzegoREgT+FdaZV3bkMJUCUfv5iGkTEw/QldVObKUrDlCO4WS1jR8Iel5nD6soCGFFAbTH5rMkjg==
X-Received: by 10.55.94.5 with SMTP id s5mr8802348qkb.102.1476901461735; Wed, 19 Oct 2016 11:24:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.22.1 with HTTP; Wed, 19 Oct 2016 11:24:01 -0700 (PDT)
In-Reply-To: <20161019155845.D13E21A564@ld9781.wdf.sap.corp>
References:  <20161019155845.D13E21A564@ld9781.wdf.sap.corp>
From: Joseph Salowey 
Date: Wed, 19 Oct 2016 11:24:01 -0700
Message-ID: 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a114e7152fed68a053f3bea21
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Deprecating alert levels
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: Wed, 19 Oct 2016 18:24:25 -0000

--001a114e7152fed68a053f3bea21
Content-Type: text/plain; charset=UTF-8

It does not look like we have sufficient consensus to adopt this PR.  While
there is some support for simplifying alerts by removing the alert level,
the current discussion raises some issues about the general approach.

1.  Is it appropriate for all unknown alerts to be treated as fatal? (the
current draft already states this)
2.  Are there cases, such as unrecognized name. where it is useful to
indicate that an alert is not fatal?  If so how should this case be handled?

Cheers,

J&S

On Wed, Oct 19, 2016 at 8:58 AM, Martin Rex  wrote:

> Kyle Nekritz wrote:
> >
> >> This list is already missing the warning-level "unrecognized_name"
> alert,
> >> and such a change would imply that all new/unrecognized alerts are going
> >> to be treated as fatal forever (i.e. that no new warning-level alerts
> >> can ever be defined).
> >
> > That alert is currently defined as a fatal alert (see section 6.2 in the
> > current draft).  RFC 6066 also states "It is NOT RECOMMENDED to send a
> > warning-level unrecognized_name(112) alert, because the client's behavior
> > in response to warning-level alerts is unpredictable.", which I think
> > illustrates the problem. Allowing new non-fatal alerts to be added later
> > would require that existing clients ignore unknown warning alerts,
> > which I think is somewhat dangerous.
>
> It seems that rfc6066 is not clear enough in explaining the issue
> about the situation with the two WELL-DEFINED (but poorly implemented)
> variants of the TLS alerts
>
>   (1)  unrecognized_name(112)  level WARNING
>   (2)  unrecognized_name(112)  level FATAL
>
> See the *ORIGINAL* specification which created *BOTH* of these alert
> variants:
>
> https://tools.ietf.org/html/rfc3546#page-10
>
>
>    If the server understood the client hello extension but does not
>    recognize the server name, it SHOULD send an "unrecognized_name"
>    alert (which MAY be fatal).
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a114e7152fed68a053f3bea21
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


It d=
oes not look like we have sufficient consensus to adopt this PR.=C2=A0 Whil=
e there is some support for simplifying alerts by removing the alert level,=
 the current discussion raises some issues about the general approach. =C2=
=A0

1.=C2=A0 Is it appropri=
ate for all unknown alerts to be treated as fatal? (the current draft alrea=
dy states this)
=
2.=C2=A0 Are there cases, such as unrecognized name. where it is useful to =
indicate that an alert is not fatal?=C2=A0 If so how should this case be ha=
ndled?

Cheers,

J&S

On Wed, Oct 19, 2016 at 8:58 AM, Martin Re=
x <m=
rex@sap.com> wrote:
Kyle Nekritz wrote:

>

>> This list is already missing the warning-level "unrecognized_=
name" alert,

>> and such a change would imply that all new/unrecognized alerts are=
 going

>> to be treated as fatal forever (i.e. that no new warning-level ale=
rts

>> can ever be defined).

>

> That alert is currently defined as a fatal alert (see section 6.2 in t=
he

> current draft).=C2=A0 RFC 6066 also states "It is NOT RECOMMENDED=
 to send a

> warning-level unrecognized_name(112) alert, because the client's b=
ehavior

> in response to warning-level alerts is unpredictable.", which I t=
hink

> illustrates the problem. Allowing new non-fatal alerts to be added lat=
er

> would require that existing clients ignore unknown warning alerts,

> which I think is somewhat dangerous.



It seems that rfc6066 is not clear enough in explaining the issue
about the situation with the two WELL-DEFINED (but poorly implemented)

variants of the TLS alerts



=C2=A0 (1)=C2=A0 unrecognized_name(112)=C2=A0 level WARNING

=C2=A0 (2)=C2=A0 unrecognized_name(112)=C2=A0 level FATAL



See the *ORIGINAL* specification which created *BOTH* of these alert varian=
ts:



https://tools.ietf.org/html/rfc3546#page-10





=C2=A0 =C2=A0If the server understood the client hello extension but does n=
ot

=C2=A0 =C2=A0recognize the server name, it SHOULD send an "unrecognize=
d_name"

=C2=A0 =C2=A0alert (which MAY be fatal).





-Martin




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114e7152fed68a053f3bea21--


From nobody Wed Oct 19 11:28:49 2016
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 8DFD0129721 for ; Wed, 19 Oct 2016 11:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 p2_PWZFXuP8D for ; Wed, 19 Oct 2016 11:28:45 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E52912975C for ; Wed, 19 Oct 2016 11:28:45 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id f97so7142698ybi.1 for ; Wed, 19 Oct 2016 11:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HI3qw6ap38ePs3Qywxww1OKqlkx2zycvBhRXmq25xTM=; b=EoxV4coBvv3JJJ7VbV9TaCD3d5EVt/NFlArfRp03il5hltUaxAW2YCAlHsB7av2fPw 6drMoPfXoLO5usPpduwJlhI0Aui3Hmn4kPdZ3s7Ux/jHpvLPo4i6YZ3D0i5Xt2wUDFKR XRnRY72dP34PHVIb2fUmuhYyu+63Nxt2c3hBwgvlrLBH2+iaEcipc4GxBMrmekZpbRpB 4np/y+QejVya2sRdxcnuCuQN67IpE3XExVBxe5qUP6bm7EsfWGKPXz7TpYkp0/9nXtod ONsKOFLgFXodK2TGQnO691J/x8F4sP8/lk0EGsSYvcWll9XVfIswd2oSLmGL9Z1Rcsk+ YHiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HI3qw6ap38ePs3Qywxww1OKqlkx2zycvBhRXmq25xTM=; b=gRDgL088d16NFW1TqyaiboRP33Idf2IynZ2Xget/KCxLSzwMDgp4mjv7mSgARXg7nk L5XnmAyJHiXnJVVXZ/rZHdmUMlhj/lNaX2X/LJCXkb36ncgMhWP6vEx2EsvOMQWt5L0z yR4HCb6p/Bexlo6wWWfNoxJdcDDIdzDjQJN+Op8eU+LNCYYnoxzRw1uEdQWC0TJOsCLO TfVqS0R5m4SQGYCDZjJXOqMtLBsl39lF0+cmasDqfWHsePn+o5l3U3Lf55q+jzrjuwOq v68bAhOVvpjY/4LmsVd5lsMJ0V25bdQzSW7z1jIKK+7ougBCINeVZPW0HduU/2q17Buq Fg+Q==
X-Gm-Message-State: AA6/9Rl/gsT9sUmC/Rz3B2sj3PbN/kFbW6kKyfO83OcCCpSHCy8MECEzu3ED+loE0cqxuhNlSDRT7byk8PZf+w==
X-Received: by 10.37.28.8 with SMTP id c8mr7713506ybc.64.1476901724648; Wed, 19 Oct 2016 11:28:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.212 with HTTP; Wed, 19 Oct 2016 11:28:04 -0700 (PDT)
In-Reply-To: 
References:  <20161019155845.D13E21A564@ld9781.wdf.sap.corp> 
From: Eric Rescorla 
Date: Wed, 19 Oct 2016 11:28:04 -0700
Message-ID: 
To: Joseph Salowey 
Content-Type: multipart/alternative; boundary=001a11426116aad39c053f3bfa62
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Deprecating alert levels
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: Wed, 19 Oct 2016 18:28:47 -0000

--001a11426116aad39c053f3bfa62
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 19, 2016 at 11:24 AM, Joseph Salowey  wrote:

> It does not look like we have sufficient consensus to adopt this PR.
> While there is some support for simplifying alerts by removing the alert
> level, the current discussion raises some issues about the general
> approach.
>
> 1.  Is it appropriate for all unknown alerts to be treated as fatal? (the
> current draft already states this)
>

I thought we had pretty strong consensus on this. I'd be sad to take it
back.


2.  Are there cases, such as unrecognized name. where it is useful to
> indicate that an alert is not fatal?  If so how should this case be handled?
>

I think this alert was a mistake :)

-Ekr


>
> Cheers,
>
> J&S
>
> On Wed, Oct 19, 2016 at 8:58 AM, Martin Rex  wrote:
>
>> Kyle Nekritz wrote:
>> >
>> >> This list is already missing the warning-level "unrecognized_name"
>> alert,
>> >> and such a change would imply that all new/unrecognized alerts are
>> going
>> >> to be treated as fatal forever (i.e. that no new warning-level alerts
>> >> can ever be defined).
>> >
>> > That alert is currently defined as a fatal alert (see section 6.2 in the
>> > current draft).  RFC 6066 also states "It is NOT RECOMMENDED to send a
>> > warning-level unrecognized_name(112) alert, because the client's
>> behavior
>> > in response to warning-level alerts is unpredictable.", which I think
>> > illustrates the problem. Allowing new non-fatal alerts to be added later
>> > would require that existing clients ignore unknown warning alerts,
>> > which I think is somewhat dangerous.
>>
>> It seems that rfc6066 is not clear enough in explaining the issue
>> about the situation with the two WELL-DEFINED (but poorly implemented)
>> variants of the TLS alerts
>>
>>   (1)  unrecognized_name(112)  level WARNING
>>   (2)  unrecognized_name(112)  level FATAL
>>
>> See the *ORIGINAL* specification which created *BOTH* of these alert
>> variants:
>>
>> https://tools.ietf.org/html/rfc3546#page-10
>>
>>
>>    If the server understood the client hello extension but does not
>>    recognize the server name, it SHOULD send an "unrecognized_name"
>>    alert (which MAY be fatal).
>>
>>
>> -Martin
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a11426116aad39c053f3bfa62
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 19, 2016 at 11:24 AM, Joseph Salowey <=
joe@salowey.net>=
; wrote:
It does not look like we have=
 sufficient consensus to adopt this PR.=C2=A0 While there is some support f=
or simplifying alerts by removing the alert level, the current discussion r=
aises some issues about the general approach. =C2=A0

1.=C2=A0 Is it appropriate for all unknown alerts=
 to be treated as fatal? (the current draft already states this)

I thought we had pretty strong consensus =
on this. I'd be sad to take it back.


2.=C2=A0 Are there cases, such as unrecognized =
name. where it is useful to indicate that an alert is not fatal?=C2=A0 If s=
o how should this case be handled?

<=
div>I think this alert was a mistake :)

-Ekr
=

=C2=A0

Cheers,

J&S

On Wed, Oct 19, 2016 at 8:58 AM, Martin Rex <mrex@sap.com=
> wrote:
Kyle Nekritz wro=
te:

>

>> This list is already missing the warning-level "unrecognized_=
name" alert,

>> and such a change would imply that all new/unrecognized alerts are=
 going

>> to be treated as fatal forever (i.e. that no new warning-level ale=
rts

>> can ever be defined).

>

> That alert is currently defined as a fatal alert (see section 6.2 in t=
he

> current draft).=C2=A0 RFC 6066 also states "It is NOT RECOMMENDED=
 to send a

> warning-level unrecognized_name(112) alert, because the client's b=
ehavior

> in response to warning-level alerts is unpredictable.", which I t=
hink

> illustrates the problem. Allowing new non-fatal alerts to be added lat=
er

> would require that existing clients ignore unknown warning alerts,

> which I think is somewhat dangerous.



It seems that rfc6066 is not clear enough in explaining the issue
about the situation with the two WELL-DEFINED (but poorly implemented)

variants of the TLS alerts



=C2=A0 (1)=C2=A0 unrecognized_name(112)=C2=A0 level WARNING

=C2=A0 (2)=C2=A0 unrecognized_name(112)=C2=A0 level FATAL



See the *ORIGINAL* specification which created *BOTH* of these alert varian=
ts:



https://tools.ietf.org/html/rfc3546#page-10





=C2=A0 =C2=A0If the server understood the client hello extension but does n=
ot

=C2=A0 =C2=A0recognize the server name, it SHOULD send an "unrecognize=
d_name"

=C2=A0 =C2=A0alert (which MAY be fatal).





-Martin




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls






_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a11426116aad39c053f3bfa62--


From nobody Wed Oct 19 19:18:30 2016
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 7078E1294A1 for ; Wed, 19 Oct 2016 19:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 imtr4vPZcL4k for ; Wed, 19 Oct 2016 19:18:27 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45347129481 for ; Wed, 19 Oct 2016 19:18:27 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id f128so65536577qkb.1 for ; Wed, 19 Oct 2016 19:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EJqX6dwtDCVbeP2wBmvdzcYwe1qqvR8AmMdnOlJ7tac=; b=JLZlzUObY87/jMnSoO0ElsSgY2SQFrBPeXURr2odArfd4UP1ES+uYxFw+uYT6fzudz Ha8U4WYdFnL4df7s8cW7TBDu+kNzBLDhDZ/nBlXrPC9Mj4GCySKe2yn3SZd1ZN/Eg+xT /pQXUfndKRtCi3vJ2RIgkWfB2KBMv0xZu/JkJIbBwWnczTeoqRwY32aeYPekaWDogu7r ygmgl/OEU1JXLJtnAjrTcNMaoCB9ktOsWaiVAMGuKpFw0zrtJd7hWE7rPBD198jK5Sc0 RT7k+d+cb8AzeELGc/Z8GCbpydl0hpDfUtmBnvwNloD6uslLURGHlck0lL25iUfPIzc4 jSOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EJqX6dwtDCVbeP2wBmvdzcYwe1qqvR8AmMdnOlJ7tac=; b=i7Da8lAB1mpH7C0wIxLZqKX6o/czTu/LpC8lRFlmQPPSTGq9Df0y5CtXQIzKjW9Hwh x8UN8DZSXnzAKnyleN+LfVNuipenAwGN/m1X3ynVWXeGjaQekFjMFLcezCZ9vuBw/Par qgfSt5dwWMy2J3iogVLIfz0grehsLnMtvvwpoHyoHU0ILIGdpXtyspkpCbeMP06AGkXU 6Fa69IRBt8lpyG0Cdg+A/bPbT/cFzUxDsfzxL2ve9rYjkXhmKq+oKAcz65v0GuEdHLzp 0MHOf8lmbc3To9A/rQ24Bp02q6Q2EiELlK7gTcxvbB2XAvZkWyUr0mPBn2OKpUjhVaJs pDNQ==
X-Gm-Message-State: ABUngveIAzLT+eAsCXwqfXtpfYDceVzlX1p8f1gwbgKPJtc8kvQm+OXV9H5CgmY16z54IhPk2UlnFOlVtsJuyQ==
X-Received: by 10.55.163.214 with SMTP id m205mr8808297qke.68.1476929906455; Wed, 19 Oct 2016 19:18:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Wed, 19 Oct 2016 19:18:25 -0700 (PDT)
In-Reply-To: 
References:  <20161019155845.D13E21A564@ld9781.wdf.sap.corp>  
From: Martin Thomson 
Date: Thu, 20 Oct 2016 13:18:25 +1100
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Deprecating alert levels
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, 20 Oct 2016 02:18:28 -0000

On 20 October 2016 at 05:28, Eric Rescorla  wrote:
>> 2.  Are there cases, such as unrecognized name. where it is useful to
>> indicate that an alert is not fatal?  If so how should this case be handled?
>
>
> I think this alert was a mistake :)

In NSS is to tolerate it, but it's an exception.  I'm happier with a
lone exception than with atrophied and redundant alert levels
continuing as they are.  I'd prefer to take the PR, with a minor
amendment noting the hazard caused by unrecognized_name(112).  Clients
that intend to accept TLS 1.2 and lower probably have to ignore
warning alerts until they see that the server is doing TLS 1.3 or
higher.


From nobody Wed Oct 19 19:20:11 2016
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 D4300129401 for ; Wed, 19 Oct 2016 19:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dgciB6_a3Tsp for ; Wed, 19 Oct 2016 19:20:08 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50EA1200DF for ; Wed, 19 Oct 2016 19:20:07 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id f128so65570429qkb.1 for ; Wed, 19 Oct 2016 19:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IklGJmNGu4Bdp0J0SSfZPo2RrhUcWPBj/sxyhT4GSNo=; b=DGXwRvuIxk3zosNL6GSQEH+6xZrKkueC/831qKbfCqBFuQVzIFweC2K8nmmaLFSK9J 7rdcj+80a/0aujpqfDDMQSqdyG4qwb9b/4OpMLVcOn4kTxzfQSFfSaZUmcLcio+re/ey ZdLLemUOIYacd8hqqg6U0s3p/fC5AY517jrLAJZPPtmyPbSb9HOF3AA2kl68hmQ3Ugiz rpTCmlu4kVOEPo5hcKs0b768b+dkAv6PYEfXDwG5zgOMVfzww7iJTsso88Cp4K0G3joK 1m9lQ/4ccOzaQmW0/WsstYUgwzlb8MlzwtcWSeQTojwpScHvssi82JZMYtpacubVxMgE EuBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IklGJmNGu4Bdp0J0SSfZPo2RrhUcWPBj/sxyhT4GSNo=; b=Ms56iRhi4czEjqGXp9o9pIaHtSulxWfQZZ6g7p53wsGU7LQ8IkHtPn//mTWqjuWBDu tq657bRXpbXx1+KC5nCMKlSQHniC3hbmQ/iv/Ra4HA7/zGLFwVzmizn8w+YRCmLBaDcL 4KK3RIf8/j7J6fWyQeYTcN98xAVulIFL2Lq+wmJ2ff/p6ZEj8NMDYCwclC2evYOiDKDS G1fsPQi+DvYqxZ3GmwtbyXlW7z2j9dBpD6671mxbDBRo6UwdGgSQh7DSNHrP0VL2G9DL dyOTBE3mcOQ08JYo5mCL92mpqcLrPPTcJvethwwAhiFMBu2mfe75ByfDGkAz4gZ0m87s yXUg==
X-Gm-Message-State: AA6/9RkULPzJrCCxy6TzIpB477z/22LRKhwqYsr9fSjGy7zl3AQD757ZFwcmvghRNSSSofLrB93oKzO1sl0HAA==
X-Received: by 10.55.71.3 with SMTP id u3mr10030298qka.144.1476930006995; Wed, 19 Oct 2016 19:20:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Wed, 19 Oct 2016 19:20:06 -0700 (PDT)
In-Reply-To: 
References:  <20161019155845.D13E21A564@ld9781.wdf.sap.corp>   
From: Martin Thomson 
Date: Thu, 20 Oct 2016 13:20:06 +1100
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Deprecating alert levels
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, 20 Oct 2016 02:20:10 -0000

On 20 October 2016 at 13:18, Martin Thomson  wrote:
> In NSS is to tolerate it

*(Learn to write fool) In NSS we tolerate warning alerts


From nobody Thu Oct 20 09:32:15 2016
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 759AA1293FB; Thu, 20 Oct 2016 09:32:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.35.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147698113447.18048.2372932494449428334.idtracker@ietfa.amsl.com>
Date: Thu, 20 Oct 2016 09:32:14 -0700
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-tls13-17.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Oct 2016 16:32:14 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

        Title           : The Transport Layer Security (TLS) Protocol Version 1.3
        Author          : Eric Rescorla
	Filename        : draft-ietf-tls-tls13-17.txt
	Pages           : 118
	Date            : 2016-10-20

Abstract:
   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Oct 20 09:33:21 2016
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 CF4AA129554 for ; Thu, 20 Oct 2016 09:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 SiMEpSs87CdK for ; Thu, 20 Oct 2016 09:33:18 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E73D1294BD for ; Thu, 20 Oct 2016 09:33:18 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id u124so60483458ywg.3 for ; Thu, 20 Oct 2016 09:33:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=zedh1tfMkXp8Ax1wUgix87Xajaw11IbEy9+Z2vy2IYA=; b=filqB5056Bn0heshopaSusXIjS7sdAmEh3xLuUAn06vL8wl0ChjTfRPk9z3iTq/bW1 lxF57FwUmcdCsFr+n7NyRwEOtauIH1m8p8a3wB/XH3Qy/rNKTYcPcHmgoJd5NM1Zcq5n gWRwhqAwPor0xH6oypMYtNHtGqdHAEisuzH6NpcYif4P7VtXAbE5xJgvPMg2El/uRdq7 0Ey9LeQNgo4GSdUksU4kpfv75Nl2KBKo3ZoJ9cWe9+cbP8tZ3NHkNbIZLnSToVATrW15 GeytJUfOXvwG5cr0TPTlZM/StNz/f/exIDBUBMbjjReLZYBI8jJfic6TkzYmvbWE+RjP vSyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zedh1tfMkXp8Ax1wUgix87Xajaw11IbEy9+Z2vy2IYA=; b=bfUzVQzKwVL5TNucGq/x1JcrSscOSxuLoz3rDkVhX0HLfPAs9NkVZa+3ct+vapCUvH 9VCRaY2woWqbKYoY/FQgwnYvegV4MsUNJl+aA7xrxztgixgHGH99buKguLgtmFy2JP7t 0YeykG6bkIiDPT1C7HGhh+TwEDUs4T9B0sxfGMWYLYjBBl2ltaNarjxkEd+IbFG9vYmp eCbBPOf4a3/3AjjaW6LQjP+4jPk8supx+/bRvRGgYtB7+jk6f6OQNkq0DPmipkUCXiWc YSNUhYHHfDPINw1qp6xU5+YkRb3EyZDAy/jncIS1r8Nu71BtN1t1Ti9p+DOqZDRKpFJM sReg==
X-Gm-Message-State: AA6/9Rk5vj4709+U5VIlZ7z1XzRjx5/H+7zROTN9J4St0kBcXflZTzn4MzNmy7JA6zkStjZ9FkhqEvH0mcQysQ==
X-Received: by 10.129.121.206 with SMTP id u197mr2262756ywc.146.1476981197116;  Thu, 20 Oct 2016 09:33:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Thu, 20 Oct 2016 09:32:36 -0700 (PDT)
From: Eric Rescorla 
Date: Thu, 20 Oct 2016 09:32:36 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c0b0f68984b34053f4e7b67
Archived-At: 
Subject: [TLS] draft-ietf-tls-tls-13-17 posted
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, 20 Oct 2016 16:33:20 -0000

--94eb2c0b0f68984b34053f4e7b67
Content-Type: text/plain; charset=UTF-8

Folks,

I have just uploaded draft-ietf-tls-tls13-17.

The major change in this draft is the removal of the 0-RTT Finished
and resumption_context constructs and their replacement with the
psk_binder. This has a number of side effects:

- Binds in the original transcript into the resumed handshake
  whenever resumption-PSK is used.

- Provides proof of possession of the RMS by the client (subject
  to replay issues). I've moved the obfuscated_ticket_age field
  out of the early_data_indication so that it now provides the
  same limited anti-replay for non-0-RTT PSK.

- Removes the need for any early handshake encryption. This change,
  along with the dual key ladders we introduced in -16, also allowed
  us to simplify the traffic key expansion so we don't need explicit
  labels for each key (they are already used in Derive-Secret).


Other changes included:
- Tweaking the PSK key exchange modes a bit (and removing the
  inoperative ability to specify PSK auth modes, while leaving
  a hook to do it later).

- Cleaned up the cipher suite requirements for resumption and 0-RTT.
  You can resume/do PSK as long as the PSK KDF matches, but to do 0-RTT
  you need the whole cipher suite must match.


This revision resolves all the outstanding technical PRs [0] and all but
one of the non-parked technical issues (#144, whether we should remove the
redundant TLSCipherText.opaque_type and TLSCipherText.record_version
fields). We are pursuing measurements to resolve whether this will
be a compat problem but we don't have them yet.

As usual, comments welcome. We are already working on implementing
-17 in NSS/Firefox and should have it before Seoul.

-Ekr

Full Changelog
- Remove the 0-RTT Finished, resumption_context, and replace with a
  psk_binder field in the PSK itself (*)

- Restructure PSK key exchange negotiation modes (*)

- Add max_early_data_size field to TicketEarlyDataInfo (*)

- Add a 0-RTT exporter and change the transcript for the regular exporter
(*)

- Merge TicketExtensions and Extensions registry. Changes
  ticket_early_data_info code point (*)

- Replace Client.key_shares in response to HRR (*)

- Remove redundant labels for traffic key derivation (*)

- Harmonize requirements about cipher suite matching: for resumption you
  need to match KDF but for 0-RTT you need whole cipher suite. This
  allows PSKs to actually negotiate cipher suites. (*)

- Explicitly allow non-offered extensions in NewSessionTicket

- Explicitly allow predicting ClientFinished for NST

- Clarify conditions for allowing 0-RTT with PSK


[0] The two remaining outstanding PRs are:
#680: Forbid post-handshake authentication except when permitted by
      application profile. This is almost entirely a requirements-level
      change, though it would allow clients to send "unexpected_message"
      when receiving an unexpected CertificateRequest.

#612: TLS 1.3 -> TLS 2.0
      This has no change on the wire format.

--94eb2c0b0f68984b34053f4e7b67
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Folks,

I have just uploaded =
draft-ietf-tls-tls13-17.

The major change in this =
draft is the removal of the 0-RTT Finished
and resumption_context=
 constructs and their replacement with the
psk_binder. This has a=
 number of side effects:

- Binds in the original t=
ranscript into the resumed handshake
=C2=A0 whenever resumption-P=
SK is used.

- Provides proof of possession of the =
RMS by the client (subject
=C2=A0 to replay issues). I've mov=
ed the obfuscated_ticket_age field
=C2=A0 out of the early_data_i=
ndication so that it now provides the
=C2=A0 same limited anti-re=
play for non-0-RTT PSK.

- Removes the need for any=
 early handshake encryption. This change,
=C2=A0 along with the d=
ual key ladders we introduced in -16, also allowed
=C2=A0 us to s=
implify the traffic key expansion so we don't need explicit
=
=C2=A0 labels for each key (they are already used in Derive-Secret).
<=
div>

Other changes included:
- Tweak=
ing the PSK key exchange modes a bit (and removing the
=C2=A0 ino=
perative ability to specify PSK auth modes, while leaving
=C2=A0 =
a hook to do it later).

- Cleaned up the cipher su=
ite requirements for resumption and 0-RTT.
=C2=A0 You can resume/=
do PSK as long as the PSK KDF matches, but to do 0-RTT
=C2=A0 you=
 need the whole cipher suite must match.


This revision resolves all the outstanding technical PRs [0] and all =
but
one of the non-parked technical issues (#144, whether we shou=
ld remove the
redundant TLSCipherText.opaque_type and TLSCipherTe=
xt.record_version
fields). We are pursuing measurements to resolv=
e whether this will
be a compat problem but we don't have the=
m yet.

As usual, comments welcome. We are already =
working on implementing
-17 in NSS/Firefox and should have it bef=
ore Seoul.

-Ekr

Full Chan=
gelog
- Remove the 0-RTT Finished, resumption_context, and replac=
e with a
=C2=A0 psk_binder field in the PSK itself (*)
=

- Restructure PSK key exchange negotiation modes (*)

- Add max_early_data_size field to TicketEarlyDataInfo (*=
)

- Add a 0-RTT exporter and change the transcript=
 for the regular exporter (*)

- Merge TicketExtens=
ions and Extensions registry. Changes
=C2=A0 ticket_early_data_in=
fo code point (*)

- Replace Client.key_shares in r=
esponse to HRR (*)

- Remove redundant labels for t=
raffic key derivation (*)

- Harmonize requirements=
 about cipher suite matching: for resumption you
=C2=A0 need to m=
atch KDF but for 0-RTT you need whole cipher suite. This
=C2=A0 a=
llows PSKs to actually negotiate cipher suites. (*)

- Explicitly allow non-offered extensions in NewSessionTicket
<=
br>
- Explicitly allow predicting ClientFinished for NST

- Clarify conditions for allowing 0-RTT with PSK


[0] The two remaining outstanding PRs are:
#680: Forbid post-handshake authentication except when permitted b=
y
=C2=A0 =C2=A0 =C2=A0 application profile. This is almost entire=
ly a requirements-level
=C2=A0 =C2=A0 =C2=A0 change, though it wo=
uld allow clients to send "unexpected_message"
=C2=A0 =
=C2=A0 =C2=A0 when receiving an unexpected CertificateRequest.
#612: TLS 1.3 -> TLS 2.0
=C2=A0 =C2=A0 =C2=A0 Thi=
s has no change on the wire format.



--94eb2c0b0f68984b34053f4e7b67--


From nobody Thu Oct 20 10:28:29 2016
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 90A8312968C for ; Thu, 20 Oct 2016 10:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 SxlPFp5vHXDn for ; Thu, 20 Oct 2016 10:28:25 -0700 (PDT)
Received: from BAY004-OMC4S6.hotmail.com (bay004-omc4s6.hotmail.com [65.54.190.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690001295B9 for ; Thu, 20 Oct 2016 10:28:25 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com ([65.54.190.201]) by BAY004-OMC4S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 20 Oct 2016 10:28:25 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LrzEGFbqno8Dp0VfxprTUQSxifs9skXhNo8oXJ+an9Y=; b=quZRA3UmB0QE41pJ8RcU/C/XbK2b24bo4ajfzpchyMDbCZ0DZ4bHT08RK76ECc02+dQEyCVOZkC6MNUqTWlgax6f7NPDe1RLgknyQCW+ErGd57Jq0/dzQz6xVqbhT/aPbTkG03LHn3gwWmsBx2dJdeKKVrUWf5yOZREAnxSs0XR3UK6/NEQCw6UGR7MrDeWG+P+NTA30ACAjkiCIwrcBWLv23S7rsK4/jCn+55+/gJLEjCe4qV0fvELCP++XtFU9/lohsEyChUb1kD7C3lgrkSgZ/34HrnI9uC9f7/A8rU0g55l1BySr9W9PDtbHE6TGGqua1eNopg9Y/MvHqX+UjA==
Received: from SN1NAM01FT057.eop-nam01.prod.protection.outlook.com (10.152.64.54) by SN1NAM01HT150.eop-nam01.prod.protection.outlook.com (10.152.64.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.7; Thu, 20 Oct 2016 17:28:24 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.64.59) by SN1NAM01FT057.mail.protection.outlook.com (10.152.65.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.7 via Frontend Transport; Thu, 20 Oct 2016 17:28:23 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0659.025; Thu, 20 Oct 2016 17:28:23 +0000
From: Xiaoyin Liu 
To: Sean Turner , "tls@ietf.org" 
Thread-Topic: [TLS] how close are we?
Thread-Index: AdIkL02YcVjui0A+SGmVotYm/TlkOAAAMiseAAHY320AAGZYAAGvkYjM
Date: Thu, 20 Oct 2016 17:28:23 +0000
Message-ID: 
References: <5c8856d676684aa189919fb1c59bfdb8@usma1ex-dag1mb1.msg.corp.akamai.com>  <1476242482704.52897@cs.auckland.ac.nz>, <153BDDAA-BB61-4756-8700-0DDFFEED4639@sn3rd.com>
In-Reply-To: <153BDDAA-BB61-4756-8700-0DDFFEED4639@sn3rd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: sn3rd.com; dkim=none (message not signed) header.d=none;sn3rd.com; dmarc=none action=none header.from=outlook.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [V8oLpypmEBHvk9rRjl6BeC01yCYHyCrB]
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; SN1NAM01HT150; 6:RlsymoJGs43Iwq0QiWKmYxNySw7WFlUaWZ890R64iqPm50ZAlc57UjPqrIA8oyPTG2VqqqFizN211w3it+OeiFH2kw3jPXMnWPXyKJhDtWmI+L+XCcL6MRj4M1JfpYLiZ+Q6icpwiL22fKW7vEO39VDlUZjTelpE2kqLl8cnhVlbfnp0/b4guBnuTmX0fGn/DfCFY6Y1ur3SLHmPQJA67qMQQWBp0lxKhtanq/MCQ8VMrYbq6Z8LH9HqMMa2bJQP3vz7rkj23jIfQqL9AKl2VunIqWCRnSh/zDfDDDrGQ/EHru3G4mb3HMWh+UO+Ovkp; 5:5Nxejuu5WvnqeRaknJ6xPNNIEEEmqauunKzf2UyE2/RKKgDv/SbuTFQeJeEZ4vkdHHaaaNxb6OJegVVfogIZ4w6yMgsyzK59UjzfCJ4AJJMCwFL9cvmWSExrzhn0hVikCuI45OAB9w6vK9BgBm/hEw==; 24:uZaqgHT07Xrdg62WXFmGE4VUnED+gsjfQVkbba5CWk/cmDsEwYom4P3KXvlwgPyPz/92APqrXEE9enRpP73OLzt0IlyQUnsF4CP6z2YMpQA=; 7:59PWduEkNwqrdWYk0WSYLOqEwNan+x+MLBii30QraxC8umNAIGLYmoyF5pxWKnPKAa45ko9Bh3c+3o7d9/Q7nuX35GMIvnuO3Ajtsi6YK0eVwgmDegWbiqUcnuGJVgZj5Wvw7CcRsT49LCIV3nLxLI5fhN8/K6d6JyJJnlnRKN1xCDZtrDXDT+x/zV6xWT2v0jjLvvVO0Ogq+YIG9olrIEeomPsd95WSiRMNc4bxCve+xHTOqRIa1uFTUXVE0kARwQoNwcUWz7KEMWnXadn2VYCyCrny4xOdRqMLQzKwqpoJ2cwYxOkx+ql3nIECUKhF5lCsB02A0f9YViVvFH9LN/8ahIGr1sa5fmIAqDtoWhg=
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM01HT150; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; 
x-ms-office365-filtering-correlation-id: e0d5dfc9-cdd3-4dc6-11ff-08d3f90e7e7f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047)(1603101333); SRVR:SN1NAM01HT150; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM01HT150; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT150; 
x-forefront-prvs: 01018CB5B3
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR15MB07783E028B351F4E35232147FFD50CY1PR15MB0778namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2016 17:28:23.4985 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT150
X-OriginalArrivalTime: 20 Oct 2016 17:28:25.0436 (UTC) FILETIME=[5D18C9C0:01D22AF7]
Archived-At: 
Subject: Re: [TLS] how close are we?
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, 20 Oct 2016 17:28:27 -0000

--_000_CY1PR15MB07783E028B351F4E35232147FFD50CY1PR15MB0778namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Since draft 17 has been posted, could we now resume this TLS 1.3 -> TLS 2.0=
 discussion?



Xiaoyin



From: Sean Turner
Sent: Tuesday, October 11, 2016 11:31 PM
To: tls@ietf.org
Subject: Re: [TLS] how close are we?



> On Oct 11, 2016, at 23:21, Peter Gutmann  wrot=
e:
>
> Xiaoyin Liu  writes:
>
>> Not directly related to Rich's question, but will we settle the "TLS 1.3=
 -> TLS 2.0"
>> discussion (PR #612) before WGLC? Or has this already been closed as "ke=
eping
>> the current name"?
>
> The impression I got from the discussion was that most people, or at leas=
t those who
> contributed, wanted 2.0, or at least something other than 1.3.  I was kin=
da surprised
> to see it still being referred to as 1.3.
>
> Peter.

It=92s still in the queue.  The chairs felt it best to focus on the open te=
chnical issues.

spt
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--_000_CY1PR15MB07783E028B351F4E35232147FFD50CY1PR15MB0778namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable















Since draft 17 has been posted, could we now resum=
e this TLS 1.3 -> TLS 2.0 discussion?


 


Xiaoyin


 




From: Sean Turner

Sent: Tuesday, October 11, 2016 11:31 PM

To: tls@ietf.org

Subject: Re: [TLS] how close are we?




 









> On Oct 11, 2016, at 23:21, Peter Gutmann <pgut001@cs.auckland.ac.nz=
> wrote:

> 

> Xiaoyin Liu <xiaoyin.l@outlook.com> writes:

> 

>> Not directly related to Rich's question, but will we settle the &q=
uot;TLS 1.3 -> TLS 2.0"


>> discussion (PR #612) before WGLC? Or has this already been closed =
as "keeping 

>> the current name"?

> 

> The impression I got from the discussion was that most people, or at l=
east those who

> contributed, wanted 2.0, or at least something other than 1.3.  I=
 was kinda surprised


> to see it still being referred to as 1.3.

> 

> Peter.



It=92s still in the queue.  The chairs felt it best to focus on the op=
en technical issues.



spt 

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/=
mailman/listinfo/tls







--_000_CY1PR15MB07783E028B351F4E35232147FFD50CY1PR15MB0778namp_--


From nobody Thu Oct 20 11:15:34 2016
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 60E121295D2 for ; Thu, 20 Oct 2016 11:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 RWMqy4tS7t26 for ; Thu, 20 Oct 2016 11:15:31 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6284D1294D0 for ; Thu, 20 Oct 2016 11:15:31 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id n189so109957718qke.0 for ; Thu, 20 Oct 2016 11:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=/16AdBlhAaUAW2j/vRCIKJ+qxLuOCYHrNbh/b4qvFvk=; b=gSgleDIeqpG4herjeRrrcv0hxbVwesRwzC0JKOFjsu7Gj3gdt6oBeU2D8iY+No8M/t Z8DX3zplAS7yMEFHbQ4QEWqw+MrPWLrUgkORge1fN9jOA6FfMnsjHNzn3Kyn30ZSdh8n CtmbewLmIULjoY/+swIhWHr+Rqjtjr1tUi35E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=/16AdBlhAaUAW2j/vRCIKJ+qxLuOCYHrNbh/b4qvFvk=; b=Uv06DmGZCG7MhG38/1CzfTRpoGCObOw07ZlNCGU8jxS5WJ7Ig5i7hJJfFJ3Q+nHG1h YW5Obx4Mx4+frm/SvIllzYjS46YZwRwHf1HNXavVMA8xQxVTHNfiCMARSmDzuTfGTK2q eOL93y61DhBwTehvKiUk1+H0TUvcxNfSC9xxVY60e3qSdEpEB9bYQL9xC1Eg0ueUBaHL 6SyqKZAoYnjp3i+snhFM0KAhZOqPxl5osOcqEE9HbBszfL5wB4PICNjk9aPuMuUtXZFu yI16elvJdL11ZWU5nvvmkFSelEGCXOJfGFsSqHf8LtfDZM6qK8puyJoyoaeTc7gp5cjH y5Dg==
X-Gm-Message-State: ABUngvfp0B4Qa+zd0cPr5GyBY7LJ4KEwVjK7+0kyipW+pjNI+jN98hcyfJ83VjMfVLyblQ==
X-Received: by 10.55.197.72 with SMTP id p69mr1506524qki.241.1476987330115; Thu, 20 Oct 2016 11:15:30 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id n128sm11773523qka.49.2016.10.20.11.15.28 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Oct 2016 11:15:29 -0700 (PDT)
From: Sean Turner 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 20 Oct 2016 14:15:27 -0400
References: <147698308536.18060.6507822848649177768.idtracker@ietfa.amsl.com>
To: "" 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [TLS] Fwd: I-D Action: draft-sandj-tls-iana-registry-updates-01.txt
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, 20 Oct 2016 18:15:33 -0000

All,

Joe and I submitted a revised version that merged a PR from DKG and =
incorporated the recommended cipher suite list that was in a.4 of =
draft-ietf-tls-tls13-14 (and a couple of other tweaks).

A repo for the draft can be found at:
https://github.com/seanturner/draft-sandj-tls-iana-registry-updates
PRs welcome.

A couple of things I am hoping for some input on:

1) I=E2=80=99d like to add something along the line of the following as =
a warning at the top of the cider suite registry for those that simply =
go to the cipher list and don=E2=80=99t read the RFCs:

    WARNING: Cryptographic algorithms will be broken
    or weakened over time.  Blindly implementing cipher
    suites listed here is not advised.  Implementers and
    users need to check that the cryptographic algorithms
    listed continue to provide the expected level of security.

2) draft-ietf-tls-tls13 will indicate cipher suites that are recommended =
for TLS1.3; remember the negotiation mechanism is different now so =
we=E2=80=99re using the same registry but the values are in the new =
range.  It seems like we still need to populate the recommended column =
for pre-1.3 from -14 A.4?

spt

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: I-D Action: draft-sandj-tls-iana-registry-updates-01.txt
> Date: October 20, 2016 at 13:04:45 EDT
> To: 
> Reply-To: internet-drafts@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
>        Title           : D/TLS IANA Registry Updates
>        Authors         : Joe Salowey
>                          Sean Turner
> 	Filename        : draft-sandj-tls-iana-registry-updates-01.txt
> 	Pages           : 10
> 	Date            : 2016-10-20
>=20
> Abstract:
>   This document changes the IANA registry policy for a number of
>   registries related to DTLS and TLS, renames some of the registries
>   for consistency, and adds notes to many of the registries.  As a
>   result, this document updates many RFCs (see updates header).
>=20
>=20
> The IETF datatracker status page for this draft is:
> =
https://datatracker.ietf.org/doc/draft-sandj-tls-iana-registry-updates/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01
>=20
> A diff from the previous version is available at:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-sandj-tls-iana-registry-updates-=
01
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nobody Thu Oct 20 12:43:39 2016
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 096101296DC for ; Thu, 20 Oct 2016 12:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PopMFRGjutB6 for ; Thu, 20 Oct 2016 12:43:36 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AA81296B6 for ; Thu, 20 Oct 2016 12:43:35 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id x79so106187024lff.0 for ; Thu, 20 Oct 2016 12:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iNh8REcsHhnOXF2W9O65o2MYN6LuCiARtCk7WfzFylY=; b=HImnwI05V8fzYTAzAUPvlff3l7gS+GmwUzB3Xihf8mFSG7WNybLow/qg05c/H3wN8S kLb2jirfo1wqADYFOstlG66SA0t9weDrxu03dlFq2Bx1hYtz5Vhc2KH0aboaq2FMzsgy kshnxUuHt7h9TvtDQrK8paMDWvyrP+CCBDfb6vMqk+XqplKkeaORtrLq0EWgATMBf8ss SO6mTXH6Iwo0HYUNwHsF5JwEoeUANUuZf67+eqtlHLbrcAO/WLouxML+ceyPglvVI/jf Md9hlwMwAacsJNcdULeKyDCj5NR31sRbEKz4QJKkf7OFfnCnDNjTnphZ27Mfh8vbQvco Ofyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iNh8REcsHhnOXF2W9O65o2MYN6LuCiARtCk7WfzFylY=; b=m5uyMI3/c8uSwffgKuNsYoBiXTV/uzCjGxicn1LPAyMEj/1HXMT9tZ989ZpYMHA0g1 FZz+Q93R28oxayLvN1T+KpQB5E+SUUza2uPc3hHb9Qq2dw6+Vj4rn2x+92UcOCAlnpul QD85b7dlW9OtN8IsMbBVuqffUNNTGI0QCJ5RTz/NbDQ61TrzkCAgFc+xEOmJMq2bbj9k SUKcfZ3mhOJHt+NK97Uv0wxgAb8w9ULLZh3dooV9HN4KVISDt84zx7Hr5YXofTGWBbet JqBVHI2To37D7K6391n0NSKamKhhCMuyL/iFj9Avsxp1zxWup0GLA9yOYH4+7Q5Xdjqm Euvw==
X-Gm-Message-State: AA6/9Rl/NkW/HNgfJlf5Bo2qwG3jxBckKtjSkV2i4Gy3eyaBPRGlkOJBNJiUnJFuZUTuTVU2jb9K8kWr/eAOXQ==
X-Received: by 10.28.64.133 with SMTP id n127mr7061124wma.31.1476992613879; Thu, 20 Oct 2016 12:43:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Thu, 20 Oct 2016 12:43:33 -0700 (PDT)
In-Reply-To: 
References: 
From: Kazuho Oku 
Date: Fri, 21 Oct 2016 04:43:33 +0900
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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, 20 Oct 2016 19:43:38 -0000

Hello,

It's great to see draft-17 being published. Thank you all for the effort.

Maybe the addition of extensions field to the Certificate message got
lost in the changelog?
https://github.com/tlswg/tls13-spec/pull/654

My understanding has been that it was a post-16 change and it changes
the wire protocol.


2016-10-21 1:32 GMT+09:00 Eric Rescorla :
> Folks,
>
> I have just uploaded draft-ietf-tls-tls13-17.
>
> The major change in this draft is the removal of the 0-RTT Finished
> and resumption_context constructs and their replacement with the
> psk_binder. This has a number of side effects:
>
> - Binds in the original transcript into the resumed handshake
>   whenever resumption-PSK is used.
>
> - Provides proof of possession of the RMS by the client (subject
>   to replay issues). I've moved the obfuscated_ticket_age field
>   out of the early_data_indication so that it now provides the
>   same limited anti-replay for non-0-RTT PSK.
>
> - Removes the need for any early handshake encryption. This change,
>   along with the dual key ladders we introduced in -16, also allowed
>   us to simplify the traffic key expansion so we don't need explicit
>   labels for each key (they are already used in Derive-Secret).
>
>
> Other changes included:
> - Tweaking the PSK key exchange modes a bit (and removing the
>   inoperative ability to specify PSK auth modes, while leaving
>   a hook to do it later).
>
> - Cleaned up the cipher suite requirements for resumption and 0-RTT.
>   You can resume/do PSK as long as the PSK KDF matches, but to do 0-RTT
>   you need the whole cipher suite must match.
>
>
> This revision resolves all the outstanding technical PRs [0] and all but
> one of the non-parked technical issues (#144, whether we should remove the
> redundant TLSCipherText.opaque_type and TLSCipherText.record_version
> fields). We are pursuing measurements to resolve whether this will
> be a compat problem but we don't have them yet.
>
> As usual, comments welcome. We are already working on implementing
> -17 in NSS/Firefox and should have it before Seoul.
>
> -Ekr
>
> Full Changelog
> - Remove the 0-RTT Finished, resumption_context, and replace with a
>   psk_binder field in the PSK itself (*)
>
> - Restructure PSK key exchange negotiation modes (*)
>
> - Add max_early_data_size field to TicketEarlyDataInfo (*)
>
> - Add a 0-RTT exporter and change the transcript for the regular exporter
> (*)
>
> - Merge TicketExtensions and Extensions registry. Changes
>   ticket_early_data_info code point (*)
>
> - Replace Client.key_shares in response to HRR (*)
>
> - Remove redundant labels for traffic key derivation (*)
>
> - Harmonize requirements about cipher suite matching: for resumption you
>   need to match KDF but for 0-RTT you need whole cipher suite. This
>   allows PSKs to actually negotiate cipher suites. (*)
>
> - Explicitly allow non-offered extensions in NewSessionTicket
>
> - Explicitly allow predicting ClientFinished for NST
>
> - Clarify conditions for allowing 0-RTT with PSK
>
>
> [0] The two remaining outstanding PRs are:
> #680: Forbid post-handshake authentication except when permitted by
>       application profile. This is almost entirely a requirements-level
>       change, though it would allow clients to send "unexpected_message"
>       when receiving an unexpected CertificateRequest.
>
> #612: TLS 1.3 -> TLS 2.0
>       This has no change on the wire format.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Kazuho Oku


From nobody Thu Oct 20 12:52:19 2016
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 CB87F1293EE for ; Thu, 20 Oct 2016 12:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Sppt_tskcEer for ; Thu, 20 Oct 2016 12:52:16 -0700 (PDT)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B899129423 for ; Thu, 20 Oct 2016 12:52:16 -0700 (PDT)
Received: by mail-yb0-x22a.google.com with SMTP id g68so32881480ybi.0 for ; Thu, 20 Oct 2016 12:52:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SXCtKa1V6bEVvnauoJ1EzY3reP6BPQtR0TRJq+AgO8U=; b=2Rk7q//Iux/EYZ4djYFPyZ1Y9JzvTEiTFcQN3sXVoQxvN30bNjfCqEsqK7NpvFZlgF FEOHlbWHeLVXeaoYfUojpfG0JNaDr830MVh7irRGDLHhGHme1Wza862oLz3DDoLUnAOB OLBwr8Bsoix+Ypk5KGx9rFKCWz9FDEenCMs7jhU2EEpr+57BVuZvV5dT2VQ1+K1npRhP 3WTn9FtRqiJg7Q+9Y68tjrmuvTShp2gYqRDlw3RQwtrZCH/WI/hRPTWYiTzLV87mHQnL L8WmSMSut+FNBbVPZ22akaQzsuAE+y6MZhJsBytAhks9ii8U22TuI9B2MUPxYFshDxf3 me/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SXCtKa1V6bEVvnauoJ1EzY3reP6BPQtR0TRJq+AgO8U=; b=Pbj/TG9nR9H1QClAEYESsHIZMsh7mR1md8vm+5pKqgq73OUmBsizjq+3rq9PC+OZoM rJIiu52xotF0K25oxLXHd+nJ1dicIKg2R+CewZl5n5H7ZBCjBNizq/6WwzzINXQJ6TCn 1tPOWjRMIZVG9eUqF0HtNqf2TYMkfKi7WcGGXUB+lznUr9QlrfaoGWvLBkSz1FEFn5Wg 2gTg5+s4T1IQhN1pC5IobOZL8Hst8M0k/jT8sMqccIRDNZ3TIl2WkE6/ogLGLrJZBW8x F98eYyECOZYWuiqGkn6bRwbzrJJ56Ek2BYlcPVa//AMmqcIqZz6McBopjNzW46NTFF0A o/hg==
X-Gm-Message-State: AA6/9Rm6ktog6nR0iuQeC6Ax/w9T4cE9+Wsc0UJPAl4t7GLKYjCACtUEjmp4DrqDoaJDus3ku9MSfwLz6b4IbQ==
X-Received: by 10.37.246.15 with SMTP id t15mr3510061ybd.107.1476993135832; Thu, 20 Oct 2016 12:52:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Thu, 20 Oct 2016 12:51:35 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Thu, 20 Oct 2016 12:51:35 -0700
Message-ID: 
To: Kazuho Oku 
Content-Type: multipart/alternative; boundary=f403045da0a632a21b053f5143bc
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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, 20 Oct 2016 19:52:19 -0000

--f403045da0a632a21b053f5143bc
Content-Type: text/plain; charset=UTF-8

You're right. I just missed it. Added to the editor's copy.

Thanks,
-Ekr


On Thu, Oct 20, 2016 at 12:43 PM, Kazuho Oku  wrote:

> Hello,
>
> It's great to see draft-17 being published. Thank you all for the effort.
>
> Maybe the addition of extensions field to the Certificate message got
> lost in the changelog?
> https://github.com/tlswg/tls13-spec/pull/654
>
> My understanding has been that it was a post-16 change and it changes
> the wire protocol.
>
>
> 2016-10-21 1:32 GMT+09:00 Eric Rescorla :
> > Folks,
> >
> > I have just uploaded draft-ietf-tls-tls13-17.
> >
> > The major change in this draft is the removal of the 0-RTT Finished
> > and resumption_context constructs and their replacement with the
> > psk_binder. This has a number of side effects:
> >
> > - Binds in the original transcript into the resumed handshake
> >   whenever resumption-PSK is used.
> >
> > - Provides proof of possession of the RMS by the client (subject
> >   to replay issues). I've moved the obfuscated_ticket_age field
> >   out of the early_data_indication so that it now provides the
> >   same limited anti-replay for non-0-RTT PSK.
> >
> > - Removes the need for any early handshake encryption. This change,
> >   along with the dual key ladders we introduced in -16, also allowed
> >   us to simplify the traffic key expansion so we don't need explicit
> >   labels for each key (they are already used in Derive-Secret).
> >
> >
> > Other changes included:
> > - Tweaking the PSK key exchange modes a bit (and removing the
> >   inoperative ability to specify PSK auth modes, while leaving
> >   a hook to do it later).
> >
> > - Cleaned up the cipher suite requirements for resumption and 0-RTT.
> >   You can resume/do PSK as long as the PSK KDF matches, but to do 0-RTT
> >   you need the whole cipher suite must match.
> >
> >
> > This revision resolves all the outstanding technical PRs [0] and all but
> > one of the non-parked technical issues (#144, whether we should remove
> the
> > redundant TLSCipherText.opaque_type and TLSCipherText.record_version
> > fields). We are pursuing measurements to resolve whether this will
> > be a compat problem but we don't have them yet.
> >
> > As usual, comments welcome. We are already working on implementing
> > -17 in NSS/Firefox and should have it before Seoul.
> >
> > -Ekr
> >
> > Full Changelog
> > - Remove the 0-RTT Finished, resumption_context, and replace with a
> >   psk_binder field in the PSK itself (*)
> >
> > - Restructure PSK key exchange negotiation modes (*)
> >
> > - Add max_early_data_size field to TicketEarlyDataInfo (*)
> >
> > - Add a 0-RTT exporter and change the transcript for the regular exporter
> > (*)
> >
> > - Merge TicketExtensions and Extensions registry. Changes
> >   ticket_early_data_info code point (*)
> >
> > - Replace Client.key_shares in response to HRR (*)
> >
> > - Remove redundant labels for traffic key derivation (*)
> >
> > - Harmonize requirements about cipher suite matching: for resumption you
> >   need to match KDF but for 0-RTT you need whole cipher suite. This
> >   allows PSKs to actually negotiate cipher suites. (*)
> >
> > - Explicitly allow non-offered extensions in NewSessionTicket
> >
> > - Explicitly allow predicting ClientFinished for NST
> >
> > - Clarify conditions for allowing 0-RTT with PSK
> >
> >
> > [0] The two remaining outstanding PRs are:
> > #680: Forbid post-handshake authentication except when permitted by
> >       application profile. This is almost entirely a requirements-level
> >       change, though it would allow clients to send "unexpected_message"
> >       when receiving an unexpected CertificateRequest.
> >
> > #612: TLS 1.3 -> TLS 2.0
> >       This has no change on the wire format.
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
>
>
> --
> Kazuho Oku
>

--f403045da0a632a21b053f5143bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


You're right. I just missed it. Added to the editor=
9;s copy.

Thanks,
-Ekr


On Thu, Oct 20=
, 2016 at 12:43 PM, Kazuho Oku <kazuhooku@gmail.com> wrote=
:
Hello,



It's great to see draft-17 being published. Thank you all for the effor=
t.



Maybe the addition of extensions field to the Certificate message got

lost in the changelog?

https://github.com/tlswg/tls13-spec/pull/654


My understanding has been that it was a post-16 change and it changes

the wire protocol.






2016-10-21 1:32 GMT+09:00 Eric Rescorla <ekr@rtfm.com>:

> Folks,

>

> I have just uploaded draft-ietf-tls-tls13-17.

>

> The major change in this draft is the removal of the 0-RTT Finished
> and resumption_context constructs and their replacement with the

> psk_binder. This has a number of side effects:

>

> - Binds in the original transcript into the resumed handshake

>=C2=A0 =C2=A0whenever resumption-PSK is used.

>

> - Provides proof of possession of the RMS by the client (subject

>=C2=A0 =C2=A0to replay issues). I've moved the obfuscated_ticket_ag=
e field

>=C2=A0 =C2=A0out of the early_data_indication so that it now provides t=
he

>=C2=A0 =C2=A0same limited anti-replay for non-0-RTT PSK.

>

> - Removes the need for any early handshake encryption. This change,
>=C2=A0 =C2=A0along with the dual key ladders we introduced in -16, also=
 allowed

>=C2=A0 =C2=A0us to simplify the traffic key expansion so we don't n=
eed explicit

>=C2=A0 =C2=A0labels for each key (they are already used in Derive-Secre=
t).

>

>

> Other changes included:

> - Tweaking the PSK key exchange modes a bit (and removing the

>=C2=A0 =C2=A0inoperative ability to specify PSK auth modes, while leavi=
ng

>=C2=A0 =C2=A0a hook to do it later).

>

> - Cleaned up the cipher suite requirements for resumption and 0-RTT.
>=C2=A0 =C2=A0You can resume/do PSK as long as the PSK KDF matches, but =
to do 0-RTT

>=C2=A0 =C2=A0you need the whole cipher suite must match.

>

>

> This revision resolves all the outstanding technical PRs [0] and all b=
ut

> one of the non-parked technical issues (#144, whether we should remove=
 the

> redundant TLSCipherText.opaque_type and TLSCipherText.record_version
> fields). We are pursuing measurements to resolve whether this will

> be a compat problem but we don't have them yet.

>

> As usual, comments welcome. We are already working on implementing

> -17 in NSS/Firefox and should have it before Seoul.

>

> -Ekr

>

> Full Changelog

> - Remove the 0-RTT Finished, resumption_context, and replace with a
>=C2=A0 =C2=A0psk_binder field in the PSK itself (*)

>

> - Restructure PSK key exchange negotiation modes (*)

>

> - Add max_early_data_size field to TicketEarlyDataInfo (*)

>

> - Add a 0-RTT exporter and change the transcript for the regular expor=
ter

> (*)

>

> - Merge TicketExtensions and Extensions registry. Changes

>=C2=A0 =C2=A0ticket_early_data_info code point (*)

>

> - Replace Client.key_shares in response to HRR (*)

>

> - Remove redundant labels for traffic key derivation (*)

>

> - Harmonize requirements about cipher suite matching: for resumption y=
ou

>=C2=A0 =C2=A0need to match KDF but for 0-RTT you need whole cipher suit=
e. This

>=C2=A0 =C2=A0allows PSKs to actually negotiate cipher suites. (*)

>

> - Explicitly allow non-offered extensions in NewSessionTicket

>

> - Explicitly allow predicting ClientFinished for NST

>

> - Clarify conditions for allowing 0-RTT with PSK

>

>

> [0] The two remaining outstanding PRs are:

> #680: Forbid post-handshake authentication except when permitted by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0application profile. This is almost entirely=
 a requirements-level

>=C2=A0 =C2=A0 =C2=A0 =C2=A0change, though it would allow clients to sen=
d "unexpected_message"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0when receiving an unexpected CertificateRequ=
est.

>

> #612: TLS 1.3 -> TLS 2.0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0This has no change on the wire format.

>

>


> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls

>







--

Kazuho Oku





--f403045da0a632a21b053f5143bc--


From nobody Thu Oct 20 12:52:43 2016
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 B86D5129562 for ; Thu, 20 Oct 2016 12:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0i9G7kG6ND88 for ; Thu, 20 Oct 2016 12:52:40 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4441296BC for ; Thu, 20 Oct 2016 12:52:39 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id o68so115356991qkf.3 for ; Thu, 20 Oct 2016 12:52:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JCreNdjGBqu3H/+bHPNWFqfLWbU4b+4cQOHHRk0Y8/8=; b=G006aug4yvgvzAz4jpxokm+6JnjRiAId341llvBaaNorNvZpThWAmaPgiPrWuen8hG 89U4XCb6kC2RVAoVJC/oCmZV5qH8g740TopAIJXmNn7/BnsvJZ4qRDFtq2z7xG5QeHhI WmDGAbtSuVbVXKeSpWplCVXf/DSDN4qHe9m9Rn7PJLqNhQkdgasCHJPxs8LqOB8HX/aw +R8SgXLmDmzyg5+m1sIjvuG4HvP61+4Q1epNeEzFYHX3Ey5jUpTRdvp467+CS9EEDnBW V4dFB5gNoW7ZEpy9+aM/fRDSRA4sJyBPcWA4DNCVh7dxV6dW+FBdsBh3DKRjYDfBNclz OdIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JCreNdjGBqu3H/+bHPNWFqfLWbU4b+4cQOHHRk0Y8/8=; b=NtXehBfMqXyzDB+6RDRnU9cJKm/+HJHLza1pCg0gEuyMDSnR/6H6edDBd0gahddpF7 OMEJK6H0Gnej0Lv8LQmIufGO3eGVoJtBJWHUlyFDzYouyopiBvqTf5drOynYnG0ly74V moDVxCYxWn/rgC2Hn9TpPq1Zimo17dcnnqShw4SgF5fBbqG56MCrKXmv4NSRNZXDJvtD woRAuMRiU6jgTGxhsMT9aATNrlRHc/SP48lZFT37099JQPmNRBG2j6clqPpRddtvFcyy aNCg20dE8TITj+2H97HRQNUJAvKlT9JkLvwnBUD6109yejLmZ0mqXVPZXUBNYM4Zfged Latw==
X-Gm-Message-State: AA6/9RngXhzX/Rhwo53Q4vwfjNz3GC2djPFfqEMZt6xhpKnJ7t7alRc3xElX9VBz0bsxxqdT4M7B8Wh4VjLsBA==
X-Received: by 10.194.97.69 with SMTP id dy5mr1276233wjb.53.1476993158322; Thu, 20 Oct 2016 12:52:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Thu, 20 Oct 2016 12:52:37 -0700 (PDT)
In-Reply-To: 
References: 
From: Kazuho Oku 
Date: Fri, 21 Oct 2016 04:52:37 +0900
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PR #699: Simplify traffic key expansion
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, 20 Oct 2016 19:52:42 -0000

Hi,

While trying to implement NewSessionTicket, I have noticed that
resumption_psk is derived from resumption_secret.

Is there any need to expand resumption_psk from resumption_secret?

To me, it is unclear why resumption_secret cannot be used directly as
a psk, since the two values have the same lengths and since the secret
is only used for deriving the psk.

Maybe is this something we could also simplify?


2016-10-18 5:08 GMT+09:00 Eric Rescorla :
> Hi folks,
>
> https://github.com/tlswg/tls13-spec/pull/699/files
>
> A while back Steven Valdez pointed out that now that we have the PSK binder
> change and dual key ladders, each set of traffic keys is generated from a
> different
> base secret which has a label folded in [0], so we don't need to have the
> "phase" parameter in the traffic key calculation in Section 7.3, which
> simplifies things
> a bit. Due to an oversight, this didn't make it into the PR, but it seems
> straightforward.
>
> Please let me know ASAP if I have missed something here or you otherwise
> object.
>
> -Ekr
>
>
> [0] client_early_traffic_secret, [sender]_handshake_traffic_secret,
> [sender]_traffic_secret_N respectively
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Kazuho Oku


From nobody Thu Oct 20 16:04:16 2016
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 87B7A129469 for ; Thu, 20 Oct 2016 16:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xsJ85ntDFF5P for ; Thu, 20 Oct 2016 16:04:14 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A211294E7 for ; Thu, 20 Oct 2016 16:04:14 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id f6so73509375qtd.2 for ; Thu, 20 Oct 2016 16:04:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YjcvJNDiYbwbsu0dVutkCdVggXWsiaorVJGPiuQPk98=; b=zjr5YZlxex/JX7CE6GMz/MLHug0yvBZfA9ZWHmgrOd1HIAaxiERGIdpDA5E9w/JLVJ 9SddpoOMUAoVjGc1Buc6yTtWfETnJ0TVbPCXkOEOuwv84WH7bqKSbhEPu7sznk0q1Zoi zh5ndUfdl92iNc3BhR9MK1jpuun41twrp7i/lKpQxZTU/92p/ftDWsksxTmrqERpi7re s7Ty50jGUiCaTjtCxU0HG7wWpBWLGtIHUJJVUqKNiGv7W0hBNy6nSHeG5j/SiXZRvxAK 0kFjDXZa/aU48DU3E65wYT36vklhWrvGadj5R+W45aP1ZMORDSavznDZnRnNYOgzP6vW IfZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YjcvJNDiYbwbsu0dVutkCdVggXWsiaorVJGPiuQPk98=; b=MlTIDgmApnNkrz7OiD2DYXC4LVsuHuLoR1F9gipPwlwaqFHxwblM/6iUcpTQkbi45K BuAF8KQZQX20nA0BUEAeNdPTdifwxLWadhepnwnvHiFvhzIgipBLMSXch3kGKi21YooJ 9W08ZNhZxT0WqqfzPjLa6amnetAx8+7Wjrpac3n7AYReuh9LXJlVmGJRLTXV9jQmfsST 5sNC2BLpTA1Wr3NgfRXlwp6TGBi1BXDJPM4lIcCLBl2AfwNrQRb9bdGS2jr5DRpEZCsn LsRJBVIq3VLaRJ6EkTEb7MMjl86m7ffxxruBqFjqb8Cxp+5xHb8j0A5xVIDMcPreGDy7 mb0Q==
X-Gm-Message-State: ABUngvfvPjiQyErjRQgequ5wycJk99AX7kvlILEoBWXbsHu4HRcYZXeyqmG1QpF3wy82AjZOhWtDtv3GWt8rxQ==
X-Received: by 10.200.34.66 with SMTP id p2mr3023478qtp.107.1477004653203; Thu, 20 Oct 2016 16:04:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Thu, 20 Oct 2016 16:04:12 -0700 (PDT)
In-Reply-To: 
References: <147698308536.18060.6507822848649177768.idtracker@ietfa.amsl.com> 
From: Martin Thomson 
Date: Fri, 21 Oct 2016 10:04:12 +1100
Message-ID: 
To: Sean Turner 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Fwd: I-D Action: draft-sandj-tls-iana-registry-updates-01.txt
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, 20 Oct 2016 23:04:15 -0000

On 21 October 2016 at 05:15, Sean Turner  wrote:
> 1) I=E2=80=99d like to add something along the line of the following as a=
 warning at the top of the cider suite registry for those that simply go to=
 the cipher list and don=E2=80=99t read the RFCs:
>
>     WARNING: Cryptographic algorithms will be broken
>     or weakened over time.  Blindly implementing cipher
>     suites listed here is not advised.  Implementers and
>     users need to check that the cryptographic algorithms
>     listed continue to provide the expected level of security.

SGTM.  Doesn't say how to check, but I'm not sure that there is any
simple advice you could give there.

> 2) draft-ietf-tls-tls13 will indicate cipher suites that are recommended =
for TLS1.3; remember the negotiation mechanism is different now so we=E2=80=
=99re using the same registry but the values are in the new range.  It seem=
s like we still need to populate the recommended column for pre-1.3 from -1=
4 A.4?

I think that TLS 1.3 should just register the small set of cipher
suites that it does and this doc can take on the other things.  What
was in -14 seems about right.


From nobody Thu Oct 20 16:05:25 2016
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 BFC0E129492 for ; Thu, 20 Oct 2016 16:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xi7Pfx9NhmYb for ; Thu, 20 Oct 2016 16:05:21 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E2F12940F for ; Thu, 20 Oct 2016 16:05:21 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id f128so118221062qkb.1 for ; Thu, 20 Oct 2016 16:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fBKW5jCQ3G+pnggCkxncICDZlC5uFxIBJXyERv2ZscE=; b=pe0EmWJxCS2VIJBLZI9RubzEBRw57KCoZ/rik9DBP+e+Qdrp33H+3VtePYIDthxEgK ezGvfSBrgo0p6j2fJ2iDlgWAXkMRb8qBYmXO6WV8lBEwxYhJu0GROkn6WULQ3Ml8URD0 c0AKeCKrIeXnp9cl3CRsrBPLeqdGq2WWylvhA4p4Vm9Cg61uMVIEWf6LO0GqSZHLNBVE wtVRQr+JJDqZpIUCN7bzItomwjvdlgOi8NVt/UtYWYXTgVZdW8dYJkXMYTPHZFNbEnJm q7cYtNiA+3InNr9nDG8s2oMTYRFSqm0lpc+xbbuCmUHXJAbwlHx1lywVTJ3LntifDTVb Z0EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fBKW5jCQ3G+pnggCkxncICDZlC5uFxIBJXyERv2ZscE=; b=Mg10ijzqbwwHoBqrg4gTivkcd1KiSIm58FJVfOFDXfED9wM6cLeQKdNAhnaxqIZxo3 FoCPMUqYaQ3NRZ2P/tFlWsWDJQ+BlxyoSf/uIIHXYh0bBwkUCxs3aiq5rBR7uwx2AhuB 9Y/5sBzN5+kZ6epHluOJR2LOvHOYLvnnCMhCnj9RVUWphTwubWUExSwEKCzH96/zjdhm Urm7cBWF8mIudMV3dE1I4EOWJ6sETM5h/LzweSBhVBLhCPT4PZ7C3Rhk9Ir6BxrDim8C No5fT3HxkcLeehKWB97ElehWSbv91DZloZJP0Gipv/YrVW5m5oaxLdfxa16r3kGBvuz3 HsgA==
X-Gm-Message-State: ABUngvdImwN3zMUwMTdAyALex18Vy4mSf8DOzayWsxVM7UJ/h85taYbDdNtc3CSY0jSA90Br0GGhdfp7k84RLQ==
X-Received: by 10.55.158.139 with SMTP id h133mr3258382qke.202.1477004720162;  Thu, 20 Oct 2016 16:05:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Thu, 20 Oct 2016 16:05:19 -0700 (PDT)
In-Reply-To: 
References:  
From: Martin Thomson 
Date: Fri, 21 Oct 2016 10:05:19 +1100
Message-ID: 
To: Kazuho Oku 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PR #699: Simplify traffic key expansion
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, 20 Oct 2016 23:05:24 -0000

On 21 October 2016 at 06:52, Kazuho Oku  wrote:
> Is there any need to expand resumption_psk from resumption_secret?
>
> To me, it is unclear why resumption_secret cannot be used directly as
> a psk, since the two values have the same lengths and since the secret
> is only used for deriving the psk.
>
> Maybe is this something we could also simplify?

draft-17 makes a simplification along the lines you suggested.  Note
that this wasn't as easy to get right as you might have imagined for a
bunch of reasons.


From nobody Thu Oct 20 17:07:49 2016
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 61C70129471 for ; Thu, 20 Oct 2016 17:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 EqbiH0xirj2X for ; Thu, 20 Oct 2016 17:07:46 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE09127735 for ; Thu, 20 Oct 2016 17:07:46 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id f128so119584478qkb.1 for ; Thu, 20 Oct 2016 17:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fKtG5fD3YsNMRJAJ9DLmZ4N6mnTqBpTnRZlmuhQErDY=; b=e1K9qdTAHjfmd/ASh+qd+z6PPz74COGpFPQUn5SHHGngF1bIry6JTlWwPh1ehXym06 RhMNWQ+nbHsKQ1j8wg0i/y8qVD7P/wRoUCrH7KbyYTq24KREBUopPL9tfgwvaI5JNz1+ Irs2hUSS1E61c1Z8G83fTgHgMa2rLSfZO3pfM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fKtG5fD3YsNMRJAJ9DLmZ4N6mnTqBpTnRZlmuhQErDY=; b=Xa4kk8cPKPOnRgoO5iQjRlWNG2x24J+PtImR5iD5775h/OhC8adsO78IUp0/C0aLYP l5NSt1ajNitVFUrDjbLY3Xrhivbj5W8WdtbM1gg6OZU8xMsv3xMbuQLlimsXVOSR0fu5 UlRyniYlHdZvPCjBFHufS3WdTx4aQEJAy1y0prBm4Af7YFG5KQYfoYdSqbEKTtq68nl1 8XcFsK/rVL/Or6TeigdkwCfNwR5PVx8D7U/AFmBCmWMoAGFaYZ30v9P5Ws0RicGBetHq lO0+zQahLN16coiMlA3Z67Dlq2FMCaN306BpLK+XQqsKCCDpLm3J7SKuq7eYcX9KaknU eQYA==
X-Gm-Message-State: ABUngve6zRAabZZtxBfz6nx16ZQqc+AnF7Xjrm/62U8vgorgNgBljYhHCo+Gl2YshV5NQw==
X-Received: by 10.55.107.198 with SMTP id g189mr2832142qkc.287.1477008465537;  Thu, 20 Oct 2016 17:07:45 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id u4sm24861657qka.9.2016.10.20.17.07.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Oct 2016 17:07:44 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Thu, 20 Oct 2016 20:07:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <17734869-D257-4B17-8C7A-9CF6E13788EB@sn3rd.com>
References: <147698308536.18060.6507822848649177768.idtracker@ietfa.amsl.com>  
To: Martin Thomson 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] I-D Action: draft-sandj-tls-iana-registry-updates-01.txt
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: Fri, 21 Oct 2016 00:07:48 -0000

> On Oct 20, 2016, at 19:04, Martin Thomson  =
wrote:
>=20
> On 21 October 2016 at 05:15, Sean Turner  wrote:
>> 1) I=E2=80=99d like to add something along the line of the following =
as a warning at the top of the cider suite registry for those that =
simply go to the cipher list and don=E2=80=99t read the RFCs:
>>=20
>>    WARNING: Cryptographic algorithms will be broken
>>    or weakened over time.  Blindly implementing cipher
>>    suites listed here is not advised.  Implementers and
>>    users need to check that the cryptographic algorithms
>>    listed continue to provide the expected level of security.
>=20
> SGTM.  Doesn't say how to check, but I'm not sure that there is any
> simple advice you could give there.

PR for this can be found here:
=
https://github.com/seanturner/draft-sandj-tls-iana-registry-updates/pull/1=
9

spt=


From nobody Thu Oct 20 17:34:25 2016
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 B25E21294BB for ; Thu, 20 Oct 2016 17:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 DIbFyEs5Mj45 for ; Thu, 20 Oct 2016 17:34:23 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109F712947D for ; Thu, 20 Oct 2016 17:34:23 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id g68so34921962ybi.0 for ; Thu, 20 Oct 2016 17:34:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Mm+Z2YXC+q6Uh75ynZtKKBvf3608fkhpOvPbmKDx/90=; b=Z74OZNrVie1QWoZPC/IOcVrwL2ohApE9Q/D+nSiDxdgigb6y51ARr+2V8Ju2MQ1ujg adP6yFVG56mMWRyJ+rrDODaFZpC72KBmbbuPO/rznpJDQrTnPgPbQz48lef5/dDpN+Kw YgE1wofuMEZF1s5zeQHMozGC3JBhnDr+znDzQkkK2/U1ESHat8+r/Hu2dRxwG2UcMPtB cgoMtt34/6xKnrdBWBxmY/65l3RaXPuClk3DujKzGgrMXExiMJmb13tW8ft0AHqzSTiM IxQ6ZRw4g3VwC2GYkircvsCMI9xNJIVrtwL//LCN/wM/p14ATiCUYo6U3Yu9z3rzMK8+ GfzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Mm+Z2YXC+q6Uh75ynZtKKBvf3608fkhpOvPbmKDx/90=; b=KnYjCLuDGPC5u74j1n1cHlKE7fszIMfTeZFVcCCkVsjJMAu/vGNKiVdCjB4E2mtOFs imPHHHCJ5qGBfhdtWwgfIhxm45dPGRNPtUhCJAfrBnHv5kqVqpSsKCgwEXFFh7lBQqJj wucIJ4qegWNt2NLfh/ujOJtz4bqP5TaGjsuFjGGuzhmDzHZxtHGmTQjErC3NnQszg4ox 3eRsQHjLDj3tp6OOm+BIn2CC2EO4cZ0ylv5df8pZb1sJ+MsbRbonfs0JSLpWNvfgLbnA uC28fcb5pIKzhViZ84TPlL02xgtnIZWAEcr8gaKN/ijOJOVU9btBZe8tur5gkDmEb5/0 9c2A==
X-Gm-Message-State: AA6/9RmUon8W1niF6i9d/hqsuRuWDhvJ3CCUiuS2WaQQHxaO5dTOYPPDp8RwqKpm7fB5DJRNzjklAl/5oa96WA==
X-Received: by 10.37.246.15 with SMTP id t15mr4703824ybd.107.1477010061899; Thu, 20 Oct 2016 17:34:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Thu, 20 Oct 2016 17:33:41 -0700 (PDT)
From: Eric Rescorla 
Date: Thu, 20 Oct 2016 17:33:41 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f403045da0a611f418053f5534d2
Archived-At: 
Subject: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 00:34:25 -0000

--f403045da0a611f418053f5534d2
Content-Type: text/plain; charset=UTF-8

We used to explicitly say that you had to check SNI for 0-RTT (but
didn't say anything about resumption). On the principle that 0-RTT and
resumption should be the same I removed that, but it turns out that
the document doesn't actually have any rule at all other than the one
we've inherited from RFC 6066, which clearly says that you can't
resume with a different SNI [0].

Following the discussion in
https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
to the draft clarifying that the RFC 6066 rule still applies [1]

With that said, it does seem like there might be situations where it
would be useful to allow resumption/0-RTT with different SNIs. My
intuition (partly informed by [2]) is that this is something we should
be pretty careful about and have the server opt-in explicitly (if at
all) but I'm willing to be wrong about that.

Comments?
-Ekr


[0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
[1]
https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121
[2] http://antoine.delignat-lavaud.fr/doc/www15.pdf

--f403045da0a611f418053f5534d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


We used to explicitly say that you had to check SNI f=
or 0-RTT (but
didn't say anything about resumption). On t=
he principle that 0-RTT and
resumption should be the same I remov=
ed that, but it turns out that
the document doesn't actually =
have any rule at all other than the one
we've inherited from =
RFC 6066, which clearly says that you can't
resume with a dif=
ferent SNI [0].

Following the discussion in
<=
div>https://gith=
ub.com/tlswg/tls13-spec/issues/720 I've added a statement
to the draft clarifying that the RFC 6066 rule still applies [1]

With that said, it does seem like there might be situations=
 where it
would be useful to allow resumption/0-RTT with differen=
t SNIs. My
intuition (partly informed by [2]) is that this is som=
ething we should
be pretty careful about and have the server opt-=
in explicitly (if at
all) but I'm willing to be wrong about t=
hat.

Comments?
-Ekr

=




--f403045da0a611f418053f5534d2--


From nobody Thu Oct 20 17:43:58 2016
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 17338127735 for ; Thu, 20 Oct 2016 17:43:56 -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_H3=-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 y-d5EGpnjanF for ; Thu, 20 Oct 2016 17:43:53 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0123.outbound.protection.outlook.com [104.47.34.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3FD124281 for ; Thu, 20 Oct 2016 17:43:53 -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=Vn34V4Y76kYl93NG/g85vUKeceVlzraCL1c6RoglrXo=; b=XJ7xzWdqZjaN5yoer8jP6FGCQOv46hdaXF/TxL8QpuelpmElR41n+ivo5lOMEOYpIXWSVEAFC23AXZmOoleXwmZUMN4GTNb4BsM7wJkV4DYIThBG+1UAFh2Y/UIaRHOq54iR2oe6jZS2h/944mB/oUbqfp4FnY/O04amFy3nwVE=
Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0840.namprd03.prod.outlook.com (10.160.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Fri, 21 Oct 2016 00:43:50 +0000
Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Fri, 21 Oct 2016 00:43:50 +0000
From: Andrei Popov 
To: Eric Rescorla , "tls@ietf.org" 
Thread-Topic: [TLS] SNI and Resumption/0-RTT
Thread-Index: AQHSKzLpp1if3oZyr0eklNKSlm6JUqCyEPyw
Date: Fri, 21 Oct 2016 00:43:50 +0000
Message-ID: 
References: 
In-Reply-To: 
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=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8::1d2]
x-ms-office365-filtering-correlation-id: ac8ab9a3-ddee-454f-2baa-08d3f94b5372
x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0840; 7:s4c4iqwv+z7xAXg+Hh6Zi0Cd0nhyo532BHL2mDuViXf2tVFlyDhgYCVP+MNHD4p2yTgWOO8MB9v9yj8lBkbiBYvvrtDhjkTLW6TAtlkkCH3MbgMiHq7N9nBY4ML4bAo7C3gL5WRbJTDSfnHmTrKbo/BOcUbUddCS0GysffXcxionBk6i6uQSEKRg8eQ2UhPtGaVDrf2E+k/HLQPZ4OVg3dp5G+9HdY70Cfc0KyYDe5w14ZnY7ae8t4+UHIJVVLNyHKpNSF97RAOLuxAFFKckn8tZOsOvjcsRcOcJgcxFcJtF28oFfFqE30sKsKHhBi0wR0DgL0P0gEwe6WHP3mnMzXxyqLjeIhp9IaQK7DrnulE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0840;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0840; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0840; 
x-forefront-prvs: 01026E1310
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(2906002)(7696004)(7736002)(2501003)(87936001)(15975445007)(790700001)(5001770100001)(74316002)(7906003)(68736007)(76576001)(7846002)(92566002)(107886002)(11100500001)(19625215002)(97736004)(2950100002)(2900100001)(189998001)(86362001)(77096005)(86612001)(10090500001)(101416001)(19300405004)(9686002)(16236675004)(5002640100001)(76176999)(54356999)(19580405001)(8676002)(50986999)(8936002)(33656002)(81156014)(8990500004)(5660300001)(10400500002)(10290500002)(5005710100001)(586003)(105586002)(122556002)(106356001)(102836003)(99286002)(6116002)(3660700001)(106116001)(19580395003)(81166006)(3280700002)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0840; H:BY1PR0301MB0838.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_BY1PR0301MB08382DA7C63232F9DD074D548CD40BY1PR0301MB0838_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2016 00:43:50.5820 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0840
Archived-At: 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 00:43:56 -0000

--_000_BY1PR0301MB08382DA7C63232F9DD074D548CD40BY1PR0301MB0838_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

w5ggIFdpdGggdGhhdCBzYWlkLCBpdCBkb2VzIHNlZW0gbGlrZSB0aGVyZSBtaWdodCBiZSBzaXR1
YXRpb25zIHdoZXJlIGl0DQoNCsOYICB3b3VsZCBiZSB1c2VmdWwgdG8gYWxsb3cgcmVzdW1wdGlv
bi8wLVJUVCB3aXRoIGRpZmZlcmVudCBTTklzLg0KV2hhdCBhcmUgc29tZSBleGFtcGxlIHNpdHVh
dGlvbnMgd2hlcmUgcmVzdW1wdGlvbiB3aXRoIGEgZGlmZmVyZW50IFNOSSBpcyB1c2VmdWw/DQoN
ClRoYW5rcywNCg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIg
MjAsIDIwMTYgNTozNCBQTQ0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gU05JIGFu
ZCBSZXN1bXB0aW9uLzAtUlRUDQoNCldlIHVzZWQgdG8gZXhwbGljaXRseSBzYXkgdGhhdCB5b3Ug
aGFkIHRvIGNoZWNrIFNOSSBmb3IgMC1SVFQgKGJ1dA0KZGlkbid0IHNheSBhbnl0aGluZyBhYm91
dCByZXN1bXB0aW9uKS4gT24gdGhlIHByaW5jaXBsZSB0aGF0IDAtUlRUIGFuZA0KcmVzdW1wdGlv
biBzaG91bGQgYmUgdGhlIHNhbWUgSSByZW1vdmVkIHRoYXQsIGJ1dCBpdCB0dXJucyBvdXQgdGhh
dA0KdGhlIGRvY3VtZW50IGRvZXNuJ3QgYWN0dWFsbHkgaGF2ZSBhbnkgcnVsZSBhdCBhbGwgb3Ro
ZXIgdGhhbiB0aGUgb25lDQp3ZSd2ZSBpbmhlcml0ZWQgZnJvbSBSRkMgNjA2Niwgd2hpY2ggY2xl
YXJseSBzYXlzIHRoYXQgeW91IGNhbid0DQpyZXN1bWUgd2l0aCBhIGRpZmZlcmVudCBTTkkgWzBd
Lg0KDQpGb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gaW4NCmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3
Zy90bHMxMy1zcGVjL2lzc3Vlcy83MjAgSSd2ZSBhZGRlZCBhIHN0YXRlbWVudA0KdG8gdGhlIGRy
YWZ0IGNsYXJpZnlpbmcgdGhhdCB0aGUgUkZDIDYwNjYgcnVsZSBzdGlsbCBhcHBsaWVzIFsxXQ0K
DQpXaXRoIHRoYXQgc2FpZCwgaXQgZG9lcyBzZWVtIGxpa2UgdGhlcmUgbWlnaHQgYmUgc2l0dWF0
aW9ucyB3aGVyZSBpdA0Kd291bGQgYmUgdXNlZnVsIHRvIGFsbG93IHJlc3VtcHRpb24vMC1SVFQg
d2l0aCBkaWZmZXJlbnQgU05Jcy4gTXkNCmludHVpdGlvbiAocGFydGx5IGluZm9ybWVkIGJ5IFsy
XSkgaXMgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB3ZSBzaG91bGQNCmJlIHByZXR0eSBjYXJlZnVs
IGFib3V0IGFuZCBoYXZlIHRoZSBzZXJ2ZXIgb3B0LWluIGV4cGxpY2l0bHkgKGlmIGF0DQphbGwp
IGJ1dCBJJ20gd2lsbGluZyB0byBiZSB3cm9uZyBhYm91dCB0aGF0Lg0KDQpDb21tZW50cz8NCi1F
a3INCg0KDQpbMF0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNtYXJrdXA/ZG9jPTYwNjYjc2Vj
dGlvbi0zDQpbMV0gaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvY29tbWl0L2Iy
NjA5M2I1ZTkxNDNmYjYxZjViNjE5ZDFkYTc4YzRiYTU0YjIxMjENClsyXSBodHRwOi8vYW50b2lu
ZS5kZWxpZ25hdC1sYXZhdWQuZnIvZG9jL3d3dzE1LnBkZg0KDQo=

--_000_BY1PR0301MB08382DA7C63232F9DD074D548CD40BY1PR0301MB0838_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv
TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo
dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg
TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u
b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K
CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv
bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx
LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg
RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY5NzQ2Mzg5NzsNCgltc28t
bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMTkwNDM2MzAgMTMw
MjUwOTM2NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5
ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZh
bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N
CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs
MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm
b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1s
aXN0LWlkOjg4NjQ1NTM1MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w
bGF0ZS1pZHM6ODUxNjI2MDg4IDUwMTAyMTQzMCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2
NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTps
ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsN
Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6
bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwx
OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw
aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFb
aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNw
YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv
dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb
ZW5kaWZdPldpdGggdGhhdCBzYWlkLCBpdCBkb2VzIHNlZW0gbGlrZSB0aGVyZSBtaWdodCBiZSBz
aXR1YXRpb25zIHdoZXJlIGl0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn
cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+
PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0
eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3Nw
YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+d291bGQgYmUgdXNlZnVsIHRvIGFsbG93IHJlc3Vt
cHRpb24vMC1SVFQgd2l0aCBkaWZmZXJlbnQgU05Jcy48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2hh
dCBhcmUgc29tZSBleGFtcGxlIHNpdHVhdGlvbnMgd2hlcmUgcmVzdW1wdGlvbiB3aXRoIGEgZGlm
ZmVyZW50IFNOSSBpcyB1c2VmdWw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAyMCwg
MjAxNiA1OjM0IFBNPGJyPg0KPGI+VG86PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gW1RMU10gU05JIGFuZCBSZXN1bXB0aW9uLzAtUlRUPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHVzZWQgdG8gZXhwbGljaXRseSBzYXkgdGhhdCB5
b3UgaGFkIHRvIGNoZWNrIFNOSSBmb3IgMC1SVFQgKGJ1dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlkbid0IHNheSBhbnl0aGluZyBhYm91dCBy
ZXN1bXB0aW9uKS4gT24gdGhlIHByaW5jaXBsZSB0aGF0IDAtUlRUIGFuZDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVzdW1wdGlvbiBzaG91bGQg
YmUgdGhlIHNhbWUgSSByZW1vdmVkIHRoYXQsIGJ1dCBpdCB0dXJucyBvdXQgdGhhdDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGRvY3VtZW50
IGRvZXNuJ3QgYWN0dWFsbHkgaGF2ZSBhbnkgcnVsZSBhdCBhbGwgb3RoZXIgdGhhbiB0aGUgb25l
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53ZSd2
ZSBpbmhlcml0ZWQgZnJvbSBSRkMgNjA2Niwgd2hpY2ggY2xlYXJseSBzYXlzIHRoYXQgeW91IGNh
bid0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5y
ZXN1bWUgd2l0aCBhIGRpZmZlcmVudCBTTkkgWzBdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gaW48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy
ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL2lzc3Vlcy83MjAiPmh0dHBz
Oi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL2lzc3Vlcy83MjA8L2E+IEkndmUgYWRkZWQg
YSBzdGF0ZW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPnRvIHRoZSBkcmFmdCBjbGFyaWZ5aW5nIHRoYXQgdGhlIFJGQyA2MDY2IHJ1bGUgc3Rp
bGwgYXBwbGllcyBbMV08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+V2l0aCB0aGF0IHNhaWQsIGl0IGRvZXMgc2VlbSBsaWtlIHRoZXJlIG1pZ2h0
IGJlIHNpdHVhdGlvbnMgd2hlcmUgaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPndvdWxkIGJlIHVzZWZ1bCB0byBhbGxvdyByZXN1bXB0aW9uLzAt
UlRUIHdpdGggZGlmZmVyZW50IFNOSXMuIE15PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnR1aXRpb24gKHBhcnRseSBpbmZvcm1lZCBieSBbMl0p
IGlzIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcgd2Ugc2hvdWxkPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iZSBwcmV0dHkgY2FyZWZ1bCBhYm91dCBh
bmQgaGF2ZSB0aGUgc2VydmVyIG9wdC1pbiBleHBsaWNpdGx5IChpZiBhdDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWxsKSBidXQgSSdtIHdpbGxp
bmcgdG8gYmUgd3JvbmcgYWJvdXQgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzBdIDxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvcmZjbWFya3VwP2RvYz02MDY2I3NlY3Rpb24tMyI+DQpodHRwczovL3Rvb2xz
LmlldGYub3JnL3JmY21hcmt1cD9kb2M9NjA2NiNzZWN0aW9uLTM8L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0mbmJzcDs8YSBocmVmPSJo
dHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9jb21taXQvYjI2MDkzYjVlOTE0M2Zi
NjFmNWI2MTlkMWRhNzhjNGJhNTRiMjEyMSI+aHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEz
LXNwZWMvY29tbWl0L2IyNjA5M2I1ZTkxNDNmYjYxZjViNjE5ZDFkYTc4YzRiYTU0YjIxMjE8L2E+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMl0g
PGEgaHJlZj0iaHR0cDovL2FudG9pbmUuZGVsaWduYXQtbGF2YXVkLmZyL2RvYy93d3cxNS5wZGYi
Pg0KaHR0cDovL2FudG9pbmUuZGVsaWduYXQtbGF2YXVkLmZyL2RvYy93d3cxNS5wZGY8L2E+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_BY1PR0301MB08382DA7C63232F9DD074D548CD40BY1PR0301MB0838_--


From nobody Thu Oct 20 17:47:48 2016
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 AD5091294BB for ; Thu, 20 Oct 2016 17:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 cb_xkbWLEE1h for ; Thu, 20 Oct 2016 17:47:45 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90D91294C8 for ; Thu, 20 Oct 2016 17:47:45 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id t193so77622144ywc.2 for ; Thu, 20 Oct 2016 17:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zQeQyk82aVTLBnon+vdFgEOjdS0SlrSmBepvhRgH54E=; b=XTn2ZqjzygCNqNJxwsWdVQf1EZWaBLqlM/mnYleXELpHFvR/XwfcIR9crcPbIwhpHx lYq0erNQ7rAW5eg9r9s1aJARK9Cty6zgbFd0Jh2dimMutXRoZg7OAxRXUhuORe5rAjxk fpCrVs/f731UtUnXw2MzP0+nCWFbLhd0lCSF7Viu6vSw/04Fs2aj/MNmZi0prRfPZLIE YINjobud3D05AfCVxvloq0n48K/u8yjrAVwFrrYbZMmYUOg7JTNX3UNQXgluFu0xC6gx ECkSKgUjO55DuPEtaWpcPE09r4UzgpDy4WV1H1jYIu7JRXCW//JexGoZ1E615DwBbmvs QLEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zQeQyk82aVTLBnon+vdFgEOjdS0SlrSmBepvhRgH54E=; b=KR40M2EqVEwl8vB3LDoRzEVF5mNiMbM6QCSckLRfNoGNREQuXlmYe4/uVKTZVnfzWW PlsJDQz6Owx3ZROkCw4TmE/HBGhRRH4BH4GorR1G/DmWQG47DgqEAxUH9WTtNVK6+HvK zMEhp5yCRVFVJEWuiCDzNWuq2h8dsKjNhPuTbMZ4jIaycZ0VsiNnjUZyI260yoY8a5Q5 uA3q9NQ/cf0ZGz0dEXNMGzYRHiri/43zWn75qj4BzATuVoesIBzmSiniobe0zNkjUCGd dJpO31fzybiRflHuay4bgStKn6Eu+BZyx3iDSDFZcru1H3lP0DmwjLgkGHAoLlpgr7y6 cJww==
X-Gm-Message-State: AA6/9RlbmqMNSC47LTciiYGNW9mlaMVYjaknORvsl56wLZl5Stn9yzi+7pIoYzpieCmxXC7MG25DyD6udW4Kaw==
X-Received: by 10.129.81.21 with SMTP id f21mr4494276ywb.149.1477010864931; Thu, 20 Oct 2016 17:47:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Thu, 20 Oct 2016 17:47:04 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Thu, 20 Oct 2016 17:47:04 -0700
Message-ID: 
To: Andrei Popov 
Content-Type: multipart/alternative; boundary=001a11461104ef5bdf053f556316
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 00:47:48 -0000

--001a11461104ef5bdf053f556316
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov 
wrote:

> =C3=98  With that said, it does seem like there might be situations where=
 it
>
> =C3=98  would be useful to allow resumption/0-RTT with different SNIs.
>
> What are some example situations where resumption with a different SNI is
> useful
>

A system where you have a bunch of co-tenanted names and you'd like to get
0-RTT on
SNI A after negotiating with SNI B. Basically the same conceptual situation
as Mike Bishops
add-a-server-cert draft.

With that said, I'm more than happy to stuff this in the "TODO-for-later"
list.

-Ekr


Thanks,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, October 20, 2016 5:34 PM
> *To:* tls@ietf.org
> *Subject:* [TLS] SNI and Resumption/0-RTT
>
>
>
> We used to explicitly say that you had to check SNI for 0-RTT (but
>
> didn't say anything about resumption). On the principle that 0-RTT and
>
> resumption should be the same I removed that, but it turns out that
>
> the document doesn't actually have any rule at all other than the one
>
> we've inherited from RFC 6066, which clearly says that you can't
>
> resume with a different SNI [0].
>
>
>
> Following the discussion in
>
> https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
>
> to the draft clarifying that the RFC 6066 rule still applies [1]
>
>
>
> With that said, it does seem like there might be situations where it
>
> would be useful to allow resumption/0-RTT with different SNIs. My
>
> intuition (partly informed by [2]) is that this is something we should
>
> be pretty careful about and have the server opt-in explicitly (if at
>
> all) but I'm willing to be wrong about that.
>
>
>
> Comments?
>
> -Ekr
>
>
>
>
>
> [0] https://tools.ietf.org/rfcmarkup?doc=3D6066#section-3
>
> [1] https://github.com/tlswg/tls13-spec/commit/
> b26093b5e9143fb61f5b619d1da78c4ba54b2121
>
> [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>
>
>

--001a11461104ef5bdf053f556316
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov <Andrei.Popov@m=
icrosoft.com> wrote:











=C3=98=C2=A0
With that said, it does seem like there might b=
e situations where it


=C3=98=C2=A0
would be useful to allow resumption/0-RTT with =
different SNIs.


What are some example situations where resumption w=
ith a different SNI is useful

<=
/div>
A system where you have a bunch of co-tenanted names and you'=
d like to get 0-RTT on
SNI A after negotiating with SNI B. Basica=
lly the same conceptual situation as Mike Bishops
add-a-server-ce=
rt draft.

With that said, I'm more than happy =
to stuff this in the "TODO-for-later" list.

<=
div>-Ekr


=



Thanks,


=C2=A0


Andrei


=C2=A0


From: TLS [mailto:tls-bounces@ietf.org]
On Behalf Of Eric Rescorla

Sent: Thursday, October 20, 2016 5:34 PM

To: tls@ietf.org

Subject: [TLS] SNI and Resumption/0-RTT


=C2=A0






We used to explicitly say that you had to check SNI =
for 0-RTT (but






didn't say anything about resumption). On the pr=
inciple that 0-RTT and






resumption should be the same I removed that, but it=
 turns out that






the document doesn't actually have any rule at a=
ll other than the one






we've inherited from RFC 6066, which clearly say=
s that you can't






resume with a different SNI [0].






=C2=A0






Following the discussion in







to the draft clarifying that the RFC 6066 rule still=
 applies [1]






=C2=A0






With that said, it does seem like there might be sit=
uations where it






would be useful to allow resumption/0-RTT with diffe=
rent SNIs. My






intuition (partly informed by [2]) is that this is s=
omething we should






be pretty careful about and have the server opt-in e=
xplicitly (if at






all) but I'm willing to be wrong about that.<=
/u>






=C2=A0






Comments?






-Ekr






=C2=A0






=C2=A0









=C2=A0














--001a11461104ef5bdf053f556316--


From nobody Thu Oct 20 18:00:27 2016
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 C6236129418 for ; Thu, 20 Oct 2016 18:00:25 -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_H3=-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 AUE98tBjmdGc for ; Thu, 20 Oct 2016 18:00:23 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0091.outbound.protection.outlook.com [104.47.32.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F311293F2 for ; Thu, 20 Oct 2016 18:00:23 -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=WYSDthed3PaD1KFO8nk6qbjZFgrGrni8LQlo3FsY9Lg=; b=MrNasPjpo3FmkzI7mKrEI0gHQQCUhKKMYzfVDcd5osNolOeQ/rhxOHxJBUXxKZ47MdqRpbzQGsES5fBwLhYUBaZIzqncNm50gwv9ib6M5cHFuSR4QyqTjWBHYon/slNM9jhI5yaGCp0ni7qpNs4/1BvChUYWxeHk0uTesR+UHa8=
Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Fri, 21 Oct 2016 01:00:18 +0000
Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Fri, 21 Oct 2016 01:00:18 +0000
From: Andrei Popov 
To: Eric Rescorla 
Thread-Topic: [TLS] SNI and Resumption/0-RTT
Thread-Index: AQHSKzLpp1if3oZyr0eklNKSlm6JUqCyEPywgAAB5gCAAACNkA==
Date: Fri, 21 Oct 2016 01:00:18 +0000
Message-ID: 
References:   
In-Reply-To: 
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=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8::1d2]
x-ms-office365-filtering-correlation-id: ede7d1c6-3ba2-4b2f-ffff-08d3f94da055
x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0838; 7:70wrPdg3+cdCEFlOQ2KLwyIskJFBowtBt9K3Yc9mobWH/LQOPmj1AUAzmxYo7+66uHVDNapL6xchrWWM1KQ7XF5r3ZJlQNbAFyWRciJ3hcsyUhSueFcpv59huESXc1lGX64j4neFGfa5E30haQcxI3Cf18O0YQTydyvdBHs0TpD39E2595AYzwb8dyhkJP5IXIqPK+BATrKp9yak4K0yS4TvfIy6lciIFLmSoaZb3V3qJn+nSzhaHOvVuiLc6xsWIGg654qNmO/Iw8SG5ym1FBYqNEZSR6YnFWdfw+3KrXccjw7CnQ2e4NcxKz8gP0IxiJEVaYxjeLiKF3fEJPwwE17Jup9OAqpUGy2TF7B63/4=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0838;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0838; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0838; 
x-forefront-prvs: 01026E1310
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(377454003)(199003)(86612001)(54356999)(19300405004)(77096005)(6916009)(105586002)(87936001)(8676002)(2950100002)(92566002)(102836003)(110136003)(189998001)(76576001)(10090500001)(11100500001)(19580395003)(19580405001)(9686002)(7696004)(2900100001)(19617315012)(19609705001)(3280700002)(15975445007)(33656002)(106116001)(7906003)(122556002)(50986999)(106356001)(81156014)(4326007)(10400500002)(81166006)(5005710100001)(68736007)(7736002)(586003)(8990500004)(3660700001)(74316002)(76176999)(5002640100001)(790700001)(86362001)(19625215002)(7846002)(6116002)(101416001)(8936002)(2906002)(5660300001)(10290500002)(16236675004)(99286002)(97736004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0838; H:BY1PR0301MB0838.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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_BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40BY1PR0301MB0838_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2016 01:00:18.4191 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0838
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 01:00:26 -0000

--_000_BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40BY1PR0301MB0838_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UGVyaGFwcyBpdOKAmXMgT0sgdG8gcmVzdW1lIGEgc2Vzc2lvbiB3aXRoIGEgZGlmZmVyZW50IFNO
SSBpZiBpbiB0aGlzIHNlc3Npb24gdGhlIHNlcnZlciBoYXMgcHJvdmVkIGFuIGlkZW50aXR5IHRo
YXQgbWF0Y2hlcyB0aGUgbmV3IFNOSS4NCkluIG9yZGVyIHRvIGVuZm9yY2UgdGhpcywgdGhlIHNl
cnZlciB3b3VsZCBoYXZlIHRvIGNhY2hlIChvciBzYXZlIGluIHRoZSB0aWNrZXQpIGEgbGlzdCBv
ZiBpZGVudGl0aWVzIGl0IHByZXNlbnRlZCBpbiBlYWNoIHJlc3VtYWJsZSBzZXNzaW9u4oCmDQoN
CkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiBUaHVyc2Rh
eSwgT2N0b2JlciAyMCwgMjAxNiA1OjQ3IFBNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9w
b3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBT
TkkgYW5kIFJlc3VtcHRpb24vMC1SVFQNCg0KDQoNCk9uIFRodSwgT2N0IDIwLCAyMDE2IGF0IDU6
NDMgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFu
ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCj4gIFdpdGggdGhhdCBzYWlkLCBp
dCBkb2VzIHNlZW0gbGlrZSB0aGVyZSBtaWdodCBiZSBzaXR1YXRpb25zIHdoZXJlIGl0DQoNCj4g
IHdvdWxkIGJlIHVzZWZ1bCB0byBhbGxvdyByZXN1bXB0aW9uLzAtUlRUIHdpdGggZGlmZmVyZW50
IFNOSXMuDQpXaGF0IGFyZSBzb21lIGV4YW1wbGUgc2l0dWF0aW9ucyB3aGVyZSByZXN1bXB0aW9u
IHdpdGggYSBkaWZmZXJlbnQgU05JIGlzIHVzZWZ1bA0KDQpBIHN5c3RlbSB3aGVyZSB5b3UgaGF2
ZSBhIGJ1bmNoIG9mIGNvLXRlbmFudGVkIG5hbWVzIGFuZCB5b3UnZCBsaWtlIHRvIGdldCAwLVJU
VCBvbg0KU05JIEEgYWZ0ZXIgbmVnb3RpYXRpbmcgd2l0aCBTTkkgQi4gQmFzaWNhbGx5IHRoZSBz
YW1lIGNvbmNlcHR1YWwgc2l0dWF0aW9uIGFzIE1pa2UgQmlzaG9wcw0KYWRkLWEtc2VydmVyLWNl
cnQgZHJhZnQuDQoNCldpdGggdGhhdCBzYWlkLCBJJ20gbW9yZSB0aGFuIGhhcHB5IHRvIHN0dWZm
IHRoaXMgaW4gdGhlICJUT0RPLWZvci1sYXRlciIgbGlzdC4NCg0KLUVrcg0KDQoNClRoYW5rcywN
Cg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPG1haWx0
bzp0bHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50
OiBUaHVyc2RheSwgT2N0b2JlciAyMCwgMjAxNiA1OjM0IFBNDQpUbzogdGxzQGlldGYub3JnPG1h
aWx0bzp0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVExTXSBTTkkgYW5kIFJlc3VtcHRpb24vMC1S
VFQNCg0KV2UgdXNlZCB0byBleHBsaWNpdGx5IHNheSB0aGF0IHlvdSBoYWQgdG8gY2hlY2sgU05J
IGZvciAwLVJUVCAoYnV0DQpkaWRuJ3Qgc2F5IGFueXRoaW5nIGFib3V0IHJlc3VtcHRpb24pLiBP
biB0aGUgcHJpbmNpcGxlIHRoYXQgMC1SVFQgYW5kDQpyZXN1bXB0aW9uIHNob3VsZCBiZSB0aGUg
c2FtZSBJIHJlbW92ZWQgdGhhdCwgYnV0IGl0IHR1cm5zIG91dCB0aGF0DQp0aGUgZG9jdW1lbnQg
ZG9lc24ndCBhY3R1YWxseSBoYXZlIGFueSBydWxlIGF0IGFsbCBvdGhlciB0aGFuIHRoZSBvbmUN
CndlJ3ZlIGluaGVyaXRlZCBmcm9tIFJGQyA2MDY2LCB3aGljaCBjbGVhcmx5IHNheXMgdGhhdCB5
b3UgY2FuJ3QNCnJlc3VtZSB3aXRoIGEgZGlmZmVyZW50IFNOSSBbMF0uDQoNCkZvbGxvd2luZyB0
aGUgZGlzY3Vzc2lvbiBpbg0KaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvaXNz
dWVzLzcyMCBJJ3ZlIGFkZGVkIGEgc3RhdGVtZW50DQp0byB0aGUgZHJhZnQgY2xhcmlmeWluZyB0
aGF0IHRoZSBSRkMgNjA2NiBydWxlIHN0aWxsIGFwcGxpZXMgWzFdDQoNCldpdGggdGhhdCBzYWlk
LCBpdCBkb2VzIHNlZW0gbGlrZSB0aGVyZSBtaWdodCBiZSBzaXR1YXRpb25zIHdoZXJlIGl0DQp3
b3VsZCBiZSB1c2VmdWwgdG8gYWxsb3cgcmVzdW1wdGlvbi8wLVJUVCB3aXRoIGRpZmZlcmVudCBT
TklzLiBNeQ0KaW50dWl0aW9uIChwYXJ0bHkgaW5mb3JtZWQgYnkgWzJdKSBpcyB0aGF0IHRoaXMg
aXMgc29tZXRoaW5nIHdlIHNob3VsZA0KYmUgcHJldHR5IGNhcmVmdWwgYWJvdXQgYW5kIGhhdmUg
dGhlIHNlcnZlciBvcHQtaW4gZXhwbGljaXRseSAoaWYgYXQNCmFsbCkgYnV0IEknbSB3aWxsaW5n
IHRvIGJlIHdyb25nIGFib3V0IHRoYXQuDQoNCkNvbW1lbnRzPw0KLUVrcg0KDQoNClswXSBodHRw
czovL3Rvb2xzLmlldGYub3JnL3JmY21hcmt1cD9kb2M9NjA2NiNzZWN0aW9uLTMNClsxXSBodHRw
czovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9jb21taXQvYjI2MDkzYjVlOTE0M2ZiNjFm
NWI2MTlkMWRhNzhjNGJhNTRiMjEyMQ0KWzJdIGh0dHA6Ly9hbnRvaW5lLmRlbGlnbmF0LWxhdmF1
ZC5mci9kb2Mvd3d3MTUucGRmDQoNCg0K

--_000_BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40BY1PR0301MB0838_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv
bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6
bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5t
ODczMzIwODU5MzQyMDEzMTY4MG1zb2xpc3RwYXJhZ3JhcGgsIGxpLm04NzMzMjA4NTkzNDIwMTMx
NjgwbXNvbGlzdHBhcmFncmFwaCwgZGl2Lm04NzMzMjA4NTkzNDIwMTMxNjgwbXNvbGlzdHBhcmFn
cmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzg3MzMyMDg1OTM0MjAxMzE2ODBtc29saXN0cGFyYWdy
YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UGVyaGFwcyBpdOKAmXMgT0sgdG8gcmVzdW1l
IGEgc2Vzc2lvbiB3aXRoIGEgZGlmZmVyZW50IFNOSSBpZiBpbiB0aGlzIHNlc3Npb24gdGhlIHNl
cnZlciBoYXMgcHJvdmVkIGFuIGlkZW50aXR5IHRoYXQgbWF0Y2hlcyB0aGUgbmV3IFNOSS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PkluIG9yZGVyIHRvIGVuZm9yY2UgdGhpcywgdGhlIHNlcnZlciB3b3VsZCBoYXZlIHRvIGNhY2hl
IChvciBzYXZlIGluIHRoZSB0aWNrZXQpIGEgbGlzdCBvZiBpZGVudGl0aWVzIGl0IHByZXNlbnRl
ZCBpbiBlYWNoIHJlc3VtYWJsZSBzZXNzaW9u4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0u
Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDIwLCAyMDE2IDU6NDcg
UE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29m
dC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFtUTFNdIFNOSSBhbmQgUmVzdW1wdGlvbi8wLVJUVDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk9uIFRodSwgT2N0IDIwLCAyMDE2IGF0IDU6NDMgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7
PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtODczMzIwODU5MzQyMDEz
MTY4MG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3Mi
PsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOw0KPC9zcGFuPldp
dGggdGhhdCBzYWlkLCBpdCBkb2VzIHNlZW0gbGlrZSB0aGVyZSBtaWdodCBiZSBzaXR1YXRpb25z
IHdoZXJlIGl0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTg3MzMyMDg1OTM0MjAxMzE2ODBt
c29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNw
Ow0KPC9zcGFuPndvdWxkIGJlIHVzZWZ1bCB0byBhbGxvdyByZXN1bXB0aW9uLzAtUlRUIHdpdGgg
ZGlmZmVyZW50IFNOSXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+V2hhdCBhcmUgc29tZSBleGFtcGxlIHNpdHVhdGlvbnMgd2hlcmUgcmVz
dW1wdGlvbiB3aXRoIGEgZGlmZmVyZW50IFNOSSBpcyB1c2VmdWw8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+QSBzeXN0ZW0gd2hlcmUgeW91IGhhdmUgYSBidW5jaCBvZiBjby10ZW5hbnRlZCBu
YW1lcyBhbmQgeW91J2QgbGlrZSB0byBnZXQgMC1SVFQgb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNOSSBBIGFmdGVyIG5lZ290aWF0aW5nIHdp
dGggU05JIEIuIEJhc2ljYWxseSB0aGUgc2FtZSBjb25jZXB0dWFsIHNpdHVhdGlvbiBhcyBNaWtl
IEJpc2hvcHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPmFkZC1hLXNlcnZlci1jZXJ0IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoYXQgc2FpZCwgSSdtIG1vcmUgdGhhbiBo
YXBweSB0byBzdHVmZiB0aGlzIGluIHRoZSAmcXVvdDtUT0RPLWZvci1sYXRlciZxdW90OyBsaXN0
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t
RWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+QW5kcmVpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2Vz
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+
T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5
LCBPY3RvYmVyIDIwLCAyMDE2IDU6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0
bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFtUTFNdIFNOSSBhbmQgUmVzdW1wdGlvbi8wLVJUVDwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSB1c2Vk
IHRvIGV4cGxpY2l0bHkgc2F5IHRoYXQgeW91IGhhZCB0byBjaGVjayBTTkkgZm9yIDAtUlRUIChi
dXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
ZGlkbid0IHNheSBhbnl0aGluZyBhYm91dCByZXN1bXB0aW9uKS4gT24gdGhlIHByaW5jaXBsZSB0
aGF0IDAtUlRUIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5yZXN1bXB0aW9uIHNob3VsZCBiZSB0aGUgc2FtZSBJIHJlbW92ZWQgdGhhdCwg
YnV0IGl0IHR1cm5zIG91dCB0aGF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPnRoZSBkb2N1bWVudCBkb2Vzbid0IGFjdHVhbGx5IGhhdmUgYW55
IHJ1bGUgYXQgYWxsIG90aGVyIHRoYW4gdGhlIG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj53ZSd2ZSBpbmhlcml0ZWQgZnJvbSBSRkMgNjA2
Niwgd2hpY2ggY2xlYXJseSBzYXlzIHRoYXQgeW91IGNhbid0PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJlc3VtZSB3aXRoIGEgZGlmZmVyZW50
IFNOSSBbMF0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5Gb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gaW48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9naXRo
dWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvaXNzdWVzLzcyMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL2lzc3Vlcy83MjA8L2E+IEkndmUgYWRkZWQg
YSBzdGF0ZW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+dG8gdGhlIGRyYWZ0IGNsYXJpZnlpbmcgdGhhdCB0aGUgUkZDIDYwNjYgcnVsZSBz
dGlsbCBhcHBsaWVzIFsxXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+V2l0aCB0aGF0IHNhaWQsIGl0IGRvZXMgc2VlbSBsaWtlIHRoZXJl
IG1pZ2h0IGJlIHNpdHVhdGlvbnMgd2hlcmUgaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+d291bGQgYmUgdXNlZnVsIHRvIGFsbG93IHJlc3Vt
cHRpb24vMC1SVFQgd2l0aCBkaWZmZXJlbnQgU05Jcy4gTXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW50dWl0aW9uIChwYXJ0bHkgaW5mb3Jt
ZWQgYnkgWzJdKSBpcyB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHdlIHNob3VsZDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5iZSBwcmV0dHkgY2Fy
ZWZ1bCBhYm91dCBhbmQgaGF2ZSB0aGUgc2VydmVyIG9wdC1pbiBleHBsaWNpdGx5IChpZiBhdDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hbGwp
IGJ1dCBJJ20gd2lsbGluZyB0byBiZSB3cm9uZyBhYm91dCB0aGF0LjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29tbWVudHM/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1Fa3I8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5bMF0NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjbWFya3VwP2RvYz02MDY2
I3NlY3Rpb24tMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjbWFy
a3VwP2RvYz02MDY2I3NlY3Rpb24tMzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu
Y29tL3Rsc3dnL3RsczEzLXNwZWMvY29tbWl0L2IyNjA5M2I1ZTkxNDNmYjYxZjViNjE5ZDFkYTc4
YzRiYTU0YjIxMjEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxz
MTMtc3BlYy9jb21taXQvYjI2MDkzYjVlOTE0M2ZiNjFmNWI2MTlkMWRhNzhjNGJhNTRiMjEyMTwv
YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
WzJdDQo8YSBocmVmPSJodHRwOi8vYW50b2luZS5kZWxpZ25hdC1sYXZhdWQuZnIvZG9jL3d3dzE1
LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9hbnRvaW5lLmRlbGlnbmF0LWxhdmF1ZC5mci9k
b2Mvd3d3MTUucGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40BY1PR0301MB0838_--


From nobody Thu Oct 20 18:07:29 2016
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 B6DA0127735 for ; Thu, 20 Oct 2016 18:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 7JjGlaBt7Q8u for ; Thu, 20 Oct 2016 18:07:26 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89DDD124281 for ; Thu, 20 Oct 2016 18:07:26 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id w3so77301012ywg.1 for ; Thu, 20 Oct 2016 18:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/mOSof61XMfu5yOnWNGXwRqbkv9NvN/F5v0UE3t+gJs=; b=Yc7sa/VXDVCtYCS2KSkHWa0SGfLp3E4lsdLoWGBpyrP8ZUCgo/J7QNGdeGh3m4SMn4 tSdH7yIryAjwHKcT/S7KmamSrKZ+EuYlG1Kp4TIOfM8tcmCl+SL0hplreXsCPqrLObJA KlKenBnGYefOk1SUd41Bpd+RCGTbwojI0F4pFyCHPXqsxy6XS0TOjONy1DvgPW//41gw tDrrdbb1gC7eMxvALFzvFvj7tNFkgBGvslX6kFocZaANDS6+AKHDQsH1EgU/+Nw5Taqs Md9T4I/82MRyMRGrEJP+Y3cYHsakkx4sCb4Br0758wO9hajNvx7EurkYiX7db6lS+MHx oEbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/mOSof61XMfu5yOnWNGXwRqbkv9NvN/F5v0UE3t+gJs=; b=EHrKrorOJvJrwUsG7AUoCwA58BBmm6iEbO1K3Gehd9mArkUY3jLC5Nuov6LCyKCaiU 8Q9qPMoeG+Sku846nXfeyzE2sseVBwrykvjTwJPyVBKq37g1TVTdvF5Ez1z93oAUd2yo kmk0dsxnr/h/Ta74phGUzG1beXE7l34pr/539h6gx7tdfmud1EPqtKFicgIDtjxwZGeK BavAPiXkXK/rEEAu6vJvF6iJy89TmkUjgltWW3CYgTc1qDIq/k1DwgkrEuw1NH3q8vxe hfhfBvwryzaFb01AwZ5hhjQBifDV3ceiMmPYSxYeZfAkQ4L4Pt9AqhinES9tz4jP6KfZ 0LLQ==
X-Gm-Message-State: AA6/9Rl2e9X5bcstG57a/ltzLm9AadxBV33lOqj7wHvdI52c1hOGHaeIgi2Yeh/6qomTsPZvWwKFjqsasEAeFQ==
X-Received: by 10.129.53.206 with SMTP id c197mr4488693ywa.205.1477012045556;  Thu, 20 Oct 2016 18:07:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Thu, 20 Oct 2016 18:06:45 -0700 (PDT)
In-Reply-To: 
References:    
From: Eric Rescorla 
Date: Thu, 20 Oct 2016 18:06:45 -0700
Message-ID: 
To: Andrei Popov 
Content-Type: multipart/alternative; boundary=001a11421a264e204b053f55aac8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 01:07:29 -0000

--001a11421a264e204b053f55aac8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yeah, it does seem a bit complicated.... :)

-Ekr


On Thu, Oct 20, 2016 at 6:00 PM, Andrei Popov 
wrote:

> Perhaps it=E2=80=99s OK to resume a session with a different SNI if in th=
is
> session the server has proved an identity that matches the new SNI.
>
> In order to enforce this, the server would have to cache (or save in the
> ticket) a list of identities it presented in each resumable session=E2=80=
=A6
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Thursday, October 20, 2016 5:47 PM
> *To:* Andrei Popov 
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] SNI and Resumption/0-RTT
>
>
>
>
>
>
>
> On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov 
> wrote:
>
> =C3=98  With that said, it does seem like there might be situations where=
 it
>
> =C3=98  would be useful to allow resumption/0-RTT with different SNIs.
>
> What are some example situations where resumption with a different SNI is
> useful
>
>
>
> A system where you have a bunch of co-tenanted names and you'd like to ge=
t
> 0-RTT on
>
> SNI A after negotiating with SNI B. Basically the same conceptual
> situation as Mike Bishops
>
> add-a-server-cert draft.
>
>
>
> With that said, I'm more than happy to stuff this in the "TODO-for-later"
> list.
>
>
>
> -Ekr
>
>
>
>
>
> Thanks,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, October 20, 2016 5:34 PM
> *To:* tls@ietf.org
> *Subject:* [TLS] SNI and Resumption/0-RTT
>
>
>
> We used to explicitly say that you had to check SNI for 0-RTT (but
>
> didn't say anything about resumption). On the principle that 0-RTT and
>
> resumption should be the same I removed that, but it turns out that
>
> the document doesn't actually have any rule at all other than the one
>
> we've inherited from RFC 6066, which clearly says that you can't
>
> resume with a different SNI [0].
>
>
>
> Following the discussion in
>
> https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
>
> to the draft clarifying that the RFC 6066 rule still applies [1]
>
>
>
> With that said, it does seem like there might be situations where it
>
> would be useful to allow resumption/0-RTT with different SNIs. My
>
> intuition (partly informed by [2]) is that this is something we should
>
> be pretty careful about and have the server opt-in explicitly (if at
>
> all) but I'm willing to be wrong about that.
>
>
>
> Comments?
>
> -Ekr
>
>
>
>
>
> [0] https://tools.ietf.org/rfcmarkup?doc=3D6066#section-3
>
> [1] https://github.com/tlswg/tls13-spec/commit/
> b26093b5e9143fb61f5b619d1da78c4ba54b2121
>
> [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>
>
>
>
>

--001a11421a264e204b053f55aac8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yeah, it does seem a bit complicated.... :)

=

-Ekr


On Thu, Oct 20, 2016 at 6:00 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:











Perhaps it=E2=80=99s OK to resume a session with a =
different SNI if in this session the server has proved an identity that mat=
ches the new SNI.


In order to enforce this, the server would have to =
cache (or save in the ticket) a list of identities it presented in each res=
umable session=E2=80=A6


=C2=A0


From: Eric Rescorla [mailto:ekr@rtfm.com]


Sent: Thursday, October 20, 2016 5:47 PM

To: Andrei Popov <Andrei.Popov@microsoft.com>

Cc: tls@ietf.org

Subject: Re: [TLS] SNI and Resumption/0-RTT
=



=C2=A0




=C2=A0




=C2=A0




On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov <Andrei.Popov@=
microsoft.com> wrote:








=C3=98=C2=A0
With that said, it does seem like there might be situations where it=



=C3=98=C2=A0
would be useful to allow resumption/0-RTT with different SNIs.


What are some example situations where resumption w=
ith a different SNI is useful










=C2=A0






A system where you have a bunch of co-tenanted names=
 and you'd like to get 0-RTT on






SNI A after negotiating with SNI B. Basically the sa=
me conceptual situation as Mike Bishops






add-a-server-cert draft.






=C2=A0






With that said, I'm more than happy to stuff thi=
s in the "TODO-for-later" list.






=C2=A0






-Ekr






=C2=A0






=C2=A0










Thanks,


=C2=A0


Andrei


=C2=A0


From: TLS [mailto:tls-bounces@ietf.org]
On Behalf Of Eric Rescorla

Sent: Thursday, October 20, 2016 5:34 PM

To: tls@ietf.org

Subject: [TLS] SNI and Resumption/0-RTT






=C2=A0






We used to explicitly say that you had to check SNI =
for 0-RTT (but






didn't say anything about resumption). On the pr=
inciple that 0-RTT and






resumption should be the same I removed that, but it=
 turns out that






the document doesn't actually have any rule at a=
ll other than the one






we've inherited from RFC 6066, which clearly say=
s that you can't






resume with a different SNI [0].






=C2=A0






Following the discussion in







to the draft clarifying that the RFC 6066 rule still=
 applies [1]






=C2=A0






With that said, it does seem like there might be sit=
uations where it






would be useful to allow resumption/0-RTT with diffe=
rent SNIs. My






intuition (partly informed by [2]) is that this is s=
omething we should






be pretty careful about and have the server opt-in e=
xplicitly (if at






all) but I'm willing to be wrong about that.<=
/u>






=C2=A0






Comments?






-Ekr






=C2=A0






=C2=A0









=C2=A0


















=C2=A0














--001a11421a264e204b053f55aac8--


From nobody Thu Oct 20 18:24:09 2016
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 1C6F61293F2 for ; Thu, 20 Oct 2016 18:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sXtxz_pVnadM for ; Thu, 20 Oct 2016 18:24:06 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1A9127735 for ; Thu, 20 Oct 2016 18:24:06 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id x79so121215956lff.0 for ; Thu, 20 Oct 2016 18:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/tLE8aUSJ54E4A/ju6JnMeB8XdyWz43sIG25U5gA33s=; b=p1/bhQyOp4+ZpIbm9RL7G9WlGzEgWgg27jYXj1ulhbKREwiBwXliwqgwnRtcymm7sl VcStZUjTEhVstTuB6iwGpcTtHcz2l3wf78Tr9p8SIrvwd65dD+cuMIRwUeM1EB0OTOe7 03BrChF8bKOfz0vmvAh5xn54WmFxBFUFLRw6s11yp7KIbL591MyUQc5eAj7XiIzIUGlX kRnPdwotNcRIrpCx7b83s9HE1uBOCyjyWBCZvf/qntvSoolOpL47OB8waQs8TFclhM0K 0svqTQ68T5DPkmPv+sIJIFgAijmCuplFfNnWy64/BjvPHyBcO1a77jTpuBV2EUv3cKKx eFFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/tLE8aUSJ54E4A/ju6JnMeB8XdyWz43sIG25U5gA33s=; b=PeFAhLhCaT/NCyYbsxCLlR0rgS/K6LJ4vqfbiH86uj7okfqBCzJvi+8acEVo7esvl0 eyaQLuRoMtBv3rP6mi2TnXDjkah8/OxGwdALMHS2ExWXpPJjutaWBLuPFYA6X5pfrCvC XohQqvdas11Yr6CBqIwVp2cRkueopUhFBxkkInntBxAqXdkzHLm/V7kXfdWMKjwGHyjh Hhv7KqKcNVKe1AS3FAadUzXY76i62T6ayBJcd+LcsPHaF5AdO/wIoGx8rfxdzO8Hu91F B3cEGlqxph9PTUuYKMJ+40Ev8XT6Da3bl53IA2iYV630iYZYU4YSfgpOQCUAq0VkT4u9 eOiQ==
X-Gm-Message-State: ABUngvdVj+z6N8uJtfqfNXFs/95bQcy30q0OvwsT2TwAS5lHVhZoM8OxZ9ckLhcPLcX78vhEZhpBC1QxqGG2xA==
X-Received: by 10.194.177.230 with SMTP id ct6mr1944442wjc.145.1477013044343;  Thu, 20 Oct 2016 18:24:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.80.233 with HTTP; Thu, 20 Oct 2016 18:24:02 -0700 (PDT)
In-Reply-To: 
References:   
From: Kazuho Oku 
Date: Fri, 21 Oct 2016 10:24:02 +0900
Message-ID: 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PR #699: Simplify traffic key expansion
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: Fri, 21 Oct 2016 01:24:08 -0000

Hi Martin,

Thank you for your response.

2016-10-21 8:05 GMT+09:00 Martin Thomson :
> On 21 October 2016 at 06:52, Kazuho Oku  wrote:
>> Is there any need to expand resumption_psk from resumption_secret?
>>
>> To me, it is unclear why resumption_secret cannot be used directly as
>> a psk, since the two values have the same lengths and since the secret
>> is only used for deriving the psk.
>>
>> Maybe is this something we could also simplify?
>
> draft-17 makes a simplification along the lines you suggested.  Note
> that this wasn't as easy to get right as you might have imagined for a
> bunch of reasons.

Observing the differences between draft-16 and 17, I understand that
it has become much simpler. In fact, I have decided to skip
implementing the draft-16 style NewSessionTicket and go directly to
implementing draft-17, since the newer draft seems easier to
implement. Thank you for making those adjustments to the draft.

That said, the point I am trying to raise is not something that was
fixed in draft-17. It's something that has become apparent in draft-17
thanks to the simplifications being introduced.

In draft-16, resumption_secret was used for two purposes: generate
resumption_psk and resumption_context. So it made sense to derive
resumption_psk from resumption_secret.

But in draft-17, my understanding is that resumption_context has been
abolished. As the result, generation of resumption_psk has been the
only use of resumption_secret.

That is the reason I thought it might be worthwhile to remove the
following formula in section 4.5.1:

   resumption_psk = HKDF-Expand-Label(resumption_secret,
                                      "resumption psk", "", Hash.Length)

and use resumption_secret as the psk.

Thank you in advance. Please forgive me if I am missing something.

-- 
Kazuho Oku


From nobody Thu Oct 20 18:25:57 2016
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 856CA12940D for ; Thu, 20 Oct 2016 18:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5ggLSO_ubdk1 for ; Thu, 20 Oct 2016 18:25:55 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64EC51293F2 for ; Thu, 20 Oct 2016 18:25:55 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id z190so126018798qkc.2 for ; Thu, 20 Oct 2016 18:25:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=95kwu5d6yC3J9yirIKYfyBUsLGqy7ZEwb5pPYF+Z1rE=; b=raXqWDhgC3eCnRP9K4Bb3VCv1cNjBWzJl3mnt1/wIs2vWcuSdzpQ9183TpJ/rgMDK7 nkuUdgK2zFe2mPt/GfXbFPKwUNoOtWF4nBNJnY9BuqEqOziaF+dXaLfJS0Gu7W3qW8uY 8azS0sDzE4i095S8TfKVprjlLqf8jtrh95CV0ZWWuoyn4g+JbyRhx2EmgIF94fUupAo1 X8cATy93gslDmW1MUlhxt3UxMEXt7pirqBaVffGpk7QPGIRok6ggKm+RcF3U+eTAwHZN htA2+Q7/DPA1R+dnKaywboZgH/k2Eew6SG8ooezBZ9XgaYB5KcRq2ouNqLKpf6/Ait/G UylA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=95kwu5d6yC3J9yirIKYfyBUsLGqy7ZEwb5pPYF+Z1rE=; b=bmXAlcXvsIrhghOkU3LnbYSfnhfU/5PS57oSRmHgCWkrLo2jElYbzYBsmhFHvOA458 v/kcz/klbad4Fdbz/TtAcCm2QvqYrWZ9c3OVFAPIfJjkuzp1DgCvvsB1iwLLULEDfN3K tO/hydM8kd6L6LN/+9SKntlxWs81khQiKaVqWUvTArru1IxygJm6MxuYSydSum4xpL4s hNVwmxyXoD+8H63ZNLoicFuW3RfvUkF14TSKXhXKVvxeiuCE35R0q5etNBHmAq0OAU95 Mnilf8p+6J9aeOMbamNN01nR9WkT3mm7pr/M0KVNixZbl/5pOWMKa/bqr31wL4ruj9/M pKDw==
X-Gm-Message-State: ABUngvcxrrS1SeGC2OMV96KGlxdAXAYrntzPbdbpHLmcVOcbmrLtBYNBlym/00FfbTfmQKLH1DTVPSk+o/Gi5g==
X-Received: by 10.55.155.15 with SMTP id d15mr3192741qke.115.1477013154536; Thu, 20 Oct 2016 18:25:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Thu, 20 Oct 2016 18:25:54 -0700 (PDT)
In-Reply-To: 
References:    
From: Martin Thomson 
Date: Fri, 21 Oct 2016 12:25:54 +1100
Message-ID: 
To: Kazuho Oku 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PR #699: Simplify traffic key expansion
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: Fri, 21 Oct 2016 01:25:56 -0000

On 21 October 2016 at 12:24, Kazuho Oku  wrote:
> That is the reason I thought it might be worthwhile to remove the
> following formula in section 4.5.1:
>
>    resumption_psk = HKDF-Expand-Label(resumption_secret,
>                                       "resumption psk", "", Hash.Length)
>
> and use resumption_secret as the psk.

That step does seem redundant, yes.


From nobody Thu Oct 20 18:38:35 2016
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 075AA12948D for ; Thu, 20 Oct 2016 18:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YBrR6r_3sbkp for ; Thu, 20 Oct 2016 18:38:31 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06AC129488 for ; Thu, 20 Oct 2016 18:38:30 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id n189so126726456qke.0 for ; Thu, 20 Oct 2016 18:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jv94MB5NYyBYdgkwWo91wtQhspoTS10C7497UxD9N/s=; b=QaS88+oBTO2j0YFkrOSI4CkxXTc83QpkKnQYyYdn0Cuqv3W4TUBjqm4lUWR4gcpWA6 OO1+8YPcJ03xjSeKxRX+2kzO95VP7ADr5IRhtp5I7XVE4gzkoqK+gp/4q4nBCCV7/GF6 0Q2N8xknZfQux/e/SW4k1TXZ4Tw/BjJq6gtTMtDN2sYnF0zZjO4o5hNmyr0DQlIY8HRf rZIqcemH9k0QYqovZ5TZkERcpADcO2LY8Z698Xjup1aIWfbyUY+1OuVbIyrKYxj53FJG W4OngyyiZ5fyqgXblOcCc9vYXcKQqB0057bPCPRqm3DU5T4D3rv/zlfrWHreUCyIEe1B 7ibg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jv94MB5NYyBYdgkwWo91wtQhspoTS10C7497UxD9N/s=; b=RvIBR8Elpl0zCzr/URCY6PQrs6EwasSIpWFZ/2ZmMB5FnxBRxTmxUORdZScLmaHXo6 JANs35qeHc/c/EPiK88dtYPg4BttdZPwhIr4FYW0a8Pkec9QA8LI2QITOJKLDBefolBh rRdo0oq5LR1UVGVpXFGuijup3SomDNpI6Cz6Zph/ZWPIe4CNaJ/m0JbUQ7TX+XxmeJZ8 pAS3Nc/B4625l931FNO1zEqEYXA5pIbCSwDTZMqyb71zTlqW0pLM3lNra2twxPxxuvw2 npDwsYOKZMo7eDB+g3y/+LYDCsVKd54ZC49LYy30Hk8gVRWVJ9Vxbmhqm7EeQiiToGJ1 xQQA==
X-Gm-Message-State: ABUngveTBHnOWsXp7Mj0nbx2O4ZWY6HAa0BDhB+GWo/l52Hb6IH2ZmPVkQrLrg5nCUPBrK4IwSZPI8tV4INOsg==
X-Received: by 10.55.165.16 with SMTP id o16mr3690737qke.5.1477013909849; Thu, 20 Oct 2016 18:38:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Thu, 20 Oct 2016 18:38:29 -0700 (PDT)
In-Reply-To: 
References:     
From: Martin Thomson 
Date: Fri, 21 Oct 2016 12:38:29 +1100
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 01:38:33 -0000

So I think that the problem could be reduced in complexity.  A little
at least.  The obvious consequence of changing SNI is that you end up
somewhere different than last time.  But we can still ensure that the
connection is to the same peer.

If the server remembered which certificate it used, and insisted that
THAT remain constant, then you could take a different SNI from - for
example - a subjectAltName.  Provided that the routing works out, you
might still get the same certificate.

I mean, the point of SNI is to route to the right configuration.
Changing name messes with resumption in that you want to make sure
that you end up in a place that has the resumption secret.  But if you
end up at the wrong server, you either fail to resume, or fail to
connect on the normal terms of the protocol.

The only thing that could screw this all up is if we end up in a
situation where one or other peer is confused about either its own
identity, the identity of its peer, or the identity (-ies) that it
believes it peer has for itself.  However, with certificate stability
rather than name stability I don't think we are worse off than with -
say - a wildcard cert.

I agree that the add-a-name stuff makes this harder.  A co-tenanted
server with resumption keys across a bunch of names risks confusing
itself if it allows resumption across certificates, depending on how
much state it carries from the old session.  In doing add-a-name, then
we need to be careful about that, but that's a problem for those of us
who want to do add-a-name.

On 21 October 2016 at 12:06, Eric Rescorla  wrote:
> Yeah, it does seem a bit complicated.... :)
>
> -Ekr
>
>
> On Thu, Oct 20, 2016 at 6:00 PM, Andrei Popov 
> wrote:
>>
>> Perhaps it=E2=80=99s OK to resume a session with a different SNI if in t=
his
>> session the server has proved an identity that matches the new SNI.
>>
>> In order to enforce this, the server would have to cache (or save in the
>> ticket) a list of identities it presented in each resumable session=E2=
=80=A6
>>
>>
>>
>> From: Eric Rescorla [mailto:ekr@rtfm.com]
>> Sent: Thursday, October 20, 2016 5:47 PM
>> To: Andrei Popov 
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] SNI and Resumption/0-RTT
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov 
>> wrote:
>>
>> =C3=98  With that said, it does seem like there might be situations wher=
e it
>>
>> =C3=98  would be useful to allow resumption/0-RTT with different SNIs.
>>
>> What are some example situations where resumption with a different SNI i=
s
>> useful
>>
>>
>>
>> A system where you have a bunch of co-tenanted names and you'd like to g=
et
>> 0-RTT on
>>
>> SNI A after negotiating with SNI B. Basically the same conceptual
>> situation as Mike Bishops
>>
>> add-a-server-cert draft.
>>
>>
>>
>> With that said, I'm more than happy to stuff this in the "TODO-for-later=
"
>> list.
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
>> Sent: Thursday, October 20, 2016 5:34 PM
>> To: tls@ietf.org
>> Subject: [TLS] SNI and Resumption/0-RTT
>>
>>
>>
>> We used to explicitly say that you had to check SNI for 0-RTT (but
>>
>> didn't say anything about resumption). On the principle that 0-RTT and
>>
>> resumption should be the same I removed that, but it turns out that
>>
>> the document doesn't actually have any rule at all other than the one
>>
>> we've inherited from RFC 6066, which clearly says that you can't
>>
>> resume with a different SNI [0].
>>
>>
>>
>> Following the discussion in
>>
>> https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
>>
>> to the draft clarifying that the RFC 6066 rule still applies [1]
>>
>>
>>
>> With that said, it does seem like there might be situations where it
>>
>> would be useful to allow resumption/0-RTT with different SNIs. My
>>
>> intuition (partly informed by [2]) is that this is something we should
>>
>> be pretty careful about and have the server opt-in explicitly (if at
>>
>> all) but I'm willing to be wrong about that.
>>
>>
>>
>> Comments?
>>
>> -Ekr
>>
>>
>>
>>
>>
>> [0] https://tools.ietf.org/rfcmarkup?doc=3D6066#section-3
>>
>> [1]
>> https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78=
c4ba54b2121
>>
>> [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>>
>>
>>
>>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Fri Oct 21 01:55:19 2016
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 C567E129511 for ; Fri, 21 Oct 2016 01:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 32o3hhvAt1zy for ; Fri, 21 Oct 2016 01:55:13 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9774A129543 for ; Fri, 21 Oct 2016 01:55:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5105F13844; Fri, 21 Oct 2016 11:55:11 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id s0Vti52SvvQQ; Fri, 21 Oct 2016 11:55:11 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EDB502310; Fri, 21 Oct 2016 11:55:10 +0300 (EEST)
Date: Fri, 21 Oct 2016 11:55:02 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20161021085502.GA7878@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 08:55:18 -0000

On Thu, Oct 20, 2016 at 05:33:41PM -0700, Eric Rescorla wrote:
> We used to explicitly say that you had to check SNI for 0-RTT (but
> didn't say anything about resumption). On the principle that 0-RTT and
> resumption should be the same I removed that, but it turns out that
> the document doesn't actually have any rule at all other than the one
> we've inherited from RFC 6066, which clearly says that you can't
> resume with a different SNI [0].

If you define "resumption" as "using PSK provisioned by NST", there is
a pretty major difference between "resumption" and "0-RTT".

The symmetry arguments are between "PSKs provisioned by NST" and
"PSKs provisioned externally", not between PSKs of any kind and 0-RTT.

> With that said, it does seem like there might be situations where it
> would be useful to allow resumption/0-RTT with different SNIs. My
> intuition (partly informed by [2]) is that this is something we should
> be pretty careful about and have the server opt-in explicitly (if at
> all) but I'm willing to be wrong about that.

IIRC, Martin Rex used to argue that the rule should be "would result in
the same certificate". Of course, defining the "same certificate" is
way trickier than it initially seems (runs into the same type of
philosophical problems as "Trigger's broom")...

Maybe one interpretation would be that the server can choose a
certificate that is valid for both old and new SNI... That is at least
a consistent rule (no idea about any sort of usefulness).

Or another: The certificate that would be chosen for new SNI is
also valid for old SNI (or vice versa). These rules are subtly
different.

Or saving the list of domains for the selected certificate in
the original connection and then allowing PSK with any of those.


One thing to be very careful of: What careless server that omits the
checks can cause (the checks are relatively complex and subtle, so
getting that wrong is to be expected).


-Ilari


From nobody Fri Oct 21 02:34:03 2016
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 998E1129514 for ; Fri, 21 Oct 2016 02:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 QS9ojjv1G-Se for ; Fri, 21 Oct 2016 02:33:59 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 95AF4128B44 for ; Fri, 21 Oct 2016 02:33:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3E8A616CF9; Fri, 21 Oct 2016 12:33:58 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id AHriKKa2TQFd; Fri, 21 Oct 2016 12:33:58 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id F1B63C4; Fri, 21 Oct 2016 12:33:57 +0300 (EEST)
Date: Fri, 21 Oct 2016 12:33:50 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 09:34:01 -0000

On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
> Folks,
> 
> I have just uploaded draft-ietf-tls-tls13-17.

Updated my own implementation from -16 to -17 (TODO: Add to
implementations page, it isn't any of the ones listed).

And since that implementation supports RFC7250 (for the server
certificate), here is my interpretation of it:

The certificate type is sent in extensions of EE certificate,
via the usual server_certificate_type extension (using the server-side
syntax from RFC7250).


Okay, the extension is after the certificate it attaches to (which is
just weird), but turns out this wasn't that bad to implement, due to
how the code happened to be laid out (it first sliced the certificate
message to extract the certificates and only afterwards processed
those).



... Interop tests with picotls failed:

- Picotls sends extension 13 (signature_algorithms) in ServerHello,
  which my implementation does not like[1].
- Picotls still seems to have the resumption_context mixed into
  hashes. I tought that got nuked when switching to "finished
  stuffing"? This causes wrong encryption keys to be derived,
  causing the handshake to blow up.



[1] Wasn't this ripped out in -17? The -17 draft seems to list that
extension as "clear", shouldn't it be "client" as the AFAIK the
server won't send it?


-Ilari


From nobody Fri Oct 21 04:40:43 2016
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 6592D129430 for ; Fri, 21 Oct 2016 04:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 4O3TfpEyf78T for ; Fri, 21 Oct 2016 04:40:41 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1216D129422 for ; Fri, 21 Oct 2016 04:40:41 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id t192so90533694ywf.0 for ; Fri, 21 Oct 2016 04:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L7Biqnoqh/YKbIA4kKY0vIJ9B2UKCHvG+DFXQQWufqo=; b=pNoZ82LOoYuQFNmjo8lO1xEHCMEDjRJ1KNGGdbngN+S1+8iqVNLt5Ywd2uZOYskkUN ujXCjgkgcTEVH+2oEZTRlx+1hDZaAWKK5V+D7o++GPP8Csmv4yefOsiuz8ENCNSGcxl8 nY9kG21N0HLs0MYG32Hxa1Q7TnQ50BWMS9FToR65yhDDSs+zm2LoYncb22m0cVVtleaq fZpbxDe9VBlFM4wykPf9E7+7YJ6Qn6vFxYLLE0lxOpTe5Vdivh1uEsHh8R5HAFfa+50v ZeW5VZEwunr65glMAiuDPWo+wrqja5mGUtGKQQNkadmEbnf3/LIjx5LTClA2D4gc0ok+ H6Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L7Biqnoqh/YKbIA4kKY0vIJ9B2UKCHvG+DFXQQWufqo=; b=jE/goA+apwMHKenn6AsrIdOnoLWkwxgP15xMNc87SfuWPv2uqwyy9r/yPoGxWh0fu8 R42NTcdVz7uuUEmguP5R9Fu8Vd69T4k4UdfcbSMTD6UiCm+OZdhPuzl5RNL2oM4zHuTl 0hhQVzqLtmNxtXqu8X4W2bVJ5qWDaUk/8kE+XMqd9NAI0VhIIUWsumSURiKP46Gad6Yl iN3nTyVf/+dHQjZt8vq1UyHfzeaWN9rqNJrBcet0PtRSsHLdUNxWazXBUNVlhe564N+9 pn4EXkeq89ZVQCJ0YX9dRJGhy9y6sKT7hfRl3XtPbL+w+ZOe/3J2re3vxpBLfSSIdjUy rebg==
X-Gm-Message-State: ABUngvfu+xZB51x4YnoVv7IDI24pevW7hYCQzyVJKG5BQUBdtSZorZJumvQEmGInXxm2kQ9yaKpJEfWfjf71Qg==
X-Received: by 10.129.81.21 with SMTP id f21mr434467ywb.149.1477050040350; Fri, 21 Oct 2016 04:40:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Fri, 21 Oct 2016 04:39:59 -0700 (PDT)
In-Reply-To: <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Fri, 21 Oct 2016 04:39:59 -0700
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a11461104f8a845053f5e8248
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 11:40:42 -0000

--001a11461104f8a845053f5e8248
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara 
wrote:

> On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
> > Folks,
> >
> > I have just uploaded draft-ietf-tls-tls13-17.
>
> Updated my own implementation from -16 to -17 (TODO: Add to
> implementations page, it isn't any of the ones listed).
>

Please do.

We're working on ours so interop testing would be great.


And since that implementation supports RFC7250 (for the server
> certificate), here is my interpretation of it:
>
> The certificate type is sent in extensions of EE certificate,
> via the usual server_certificate_type extension (using the server-side
> syntax from RFC7250).
>

I think this probably should go in Encrypted Extensions.


> ... Interop tests with picotls failed:
>
> - Picotls sends extension 13 (signature_algorithms) in ServerHello,
>   which my implementation does not like[1].
>

You are correct.



> - Picotls still seems to have the resumption_context mixed into
>   hashes. I tought that got nuked when switching to "finished
>   stuffing"? This causes wrong encryption keys to be derived,
>   causing the handshake to blow up.
>

It did.



> [1] Wasn't this ripped out in -17? The -17 draft seems to list that
> extension as "clear", shouldn't it be "client" as the AFAIK the
> server won't send it?
>

Thanks. That got missed in the update.

-Ekr


>
>
> -Ilari
>

--001a11461104f8a845053f5e8248
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:
On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
> Folks,

>

> I have just uploaded draft-ietf-tls-tls13-17.



Updated my own implementation from -16 to -17 (TODO: Add to

implementations page, it isn't any of the ones listed).

Please do.

We're working =
on ours so interop testing would be great.



And since that implementation supports RFC7250 (for the server

certificate), here is my interpretation of it:



The certificate type is sent in extensions of EE certificate,

via the usual server_certificate_type extension (using the server-side

syntax from RFC7250).

I think this prob=
ably should go in Encrypted Extensions.



... Interop tests with picotls failed:



- Picotls sends extension 13 (signature_algorithms) in ServerHello,

=C2=A0 which my implementation does not like[1].

<=
/div>
You are correct.

=C2=A0

- Picotls still seems to have the resumption_context mixed into

=C2=A0 hashes. I tought that got nuked when switching to "finished

=C2=A0 stuffing"? This causes wrong encryption keys to be derived,

=C2=A0 causing the handshake to blow up.

It did.

=C2=A0
[1] Wasn't this ripped out in -17? The -17 draft seems to list that<=
br>
extension as "clear", shouldn't it be "client" as t=
he AFAIK the

server won't send it?

Thanks. That =
got missed in the update.

-Ekr
=C2=A0





-Ilari





--001a11461104f8a845053f5e8248--


From nobody Fri Oct 21 05:42:05 2016
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 AF44212959D for ; Fri, 21 Oct 2016 05:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 D26-I5Yv4_SF for ; Fri, 21 Oct 2016 05:42:02 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58516129420 for ; Fri, 21 Oct 2016 05:42:01 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id s49so83977746qta.0 for ; Fri, 21 Oct 2016 05:42:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mmvkG5Xd39ivjIgHweYbCptIrccBlRoJTzCA+VT/hRQ=; b=bDrQ45LY+MEv+YpJMVk71sDKj6nUSN6G1jlN0xetsM8or4MgMN2DInX5YrA86tOAeC f+HqTfo+C51c0Mhca3uwG0jh55/7NlHBnWb/XBpmRDkAQRWFcvu5idIUxpsx9b+VCcWL vF7xGZWTWdXWFUHupSObWFFRGEG5pZA+eosVp9drJUdxStGIYdUsq0tXpzegwWIlk3u5 FrqLke4aP/vN1UtJvHUuKO5MZTf2BegN3zHoeYLfw2i4ol0McUnRWBi8ypqG4oumVoNT JdTjoDq9kH+44HRhbsbr5g6rI4fp7edY9xmFs+LVpG3bWhlseQCIj8Q5Hgd0ZhDKfvrg fjrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mmvkG5Xd39ivjIgHweYbCptIrccBlRoJTzCA+VT/hRQ=; b=Hcm4XCUue9dES23JGFSSbYlVh5PpLusntsmKDx79egWcWAbZ+dDv+OrBFguFwWJa54 kr/sG1nZSFxzNujnWPR2P9F/QP8QyAxKuLCkp+tP6ZQHzzQrrP/CPxJP9WZQ8VF/j0ha H4uTgUNnI7KejJr/tjQeeW27gQlBLZbrCeWgK3yvnFff4srFUtzaJGk3NLv6kUAvR8I8 UgHNEZo8q1Pz/OqEx2ulUanvIoL7BaEiCJCur11cQ3DTaxxBP9JeP3m2QfQt3TKm6DyC mbdWdaJrLtt1+27VCqZqIw0sbsj1CL0Tl8V8UQAbiGnEZJjh6RdT8NZ3WqB2PPqIvO43 C7SQ==
X-Gm-Message-State: ABUngveWzmiKxgl4HOni61l2Ck8N6O4fQlPs1SwtQQ833cup7jDkyexFxJXSpZy9rm6lYQTa3emdP5i+BZB59w==
X-Received: by 10.200.45.170 with SMTP id p39mr832004qta.32.1477053720501; Fri, 21 Oct 2016 05:42:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Fri, 21 Oct 2016 05:41:59 -0700 (PDT)
In-Reply-To: <20161021085502.GA7878@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021085502.GA7878@LK-Perkele-V2.elisa-laajakaista.fi>
From: Martin Thomson 
Date: Fri, 21 Oct 2016 23:41:59 +1100
Message-ID: 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 12:42:04 -0000

On 21 October 2016 at 19:55, Ilari Liusvaara  wrote:
> Of course, defining the "same certificate" is
> way trickier than it initially seems

Not if you think simplistically: same octets in EE ASN1Cert in both handshakes.


From nobody Fri Oct 21 06:24:47 2016
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 4A5AE129560 for ; Fri, 21 Oct 2016 06:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.454
X-Spam-Level: 
X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 xIf-aOc73Dgf for ; Fri, 21 Oct 2016 06:24:43 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B2812943D for ; Fri, 21 Oct 2016 06:24:43 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5DB2FC057FA5 for ; Fri, 21 Oct 2016 13:24:43 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9LDOgGm022706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Oct 2016 09:24:43 -0400
From: Hubert Kario 
To: "tls@ietf.org" 
Date: Fri, 21 Oct 2016 15:24:35 +0200
Message-ID: <2807298.nMSlSttlYL@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.1 (Linux/4.7.7-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart41033876.HFTSU0vPTT"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 21 Oct 2016 13:24:43 +0000 (UTC)
Archived-At: 
Subject: [TLS] Server abort because of unrecognised vs rejected client provided parameters
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: Fri, 21 Oct 2016 13:24:45 -0000

--nextPart41033876.HFTSU0vPTT
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Currently TLS has two alert descriptions for when there is no intersection=
=20
between ciphers/sigalgs/groups advertises by client and ones that are enabl=
ed=20
in server. It's the handshake_failure and insufficient_security alerts.

While it is a step in good direction in providing users with better message=
s=20
in case of connection failure, I think there is one edge case which may rui=
n=20
the effort.

Let's say we have a client that advertises following signature methods:
rsa-ssa-sha256
rsa-ssa-sha384

and this client is connecting to server which requires use of rsa-ssa-sha51=
2=20
signatures only, but does implement weaker hashes and the requirement is ju=
st=20
result of administrator requiring high security.

I think that such connection attempt should end with insufficient_security.

Problem is, what if the server does not implement some even never RSA=20
signature format, but client does advertise support for them?

I think then the connection should end with handshake_failure.

So I think we should add to the insufficient_security description the=20
following sentence:

   In case the connection peer advertised security parameters not recognize=
d=20
   or unsupported by the implementation, the implementation MUST send
   "handshake_failure" alert instead.
=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart41033876.HFTSU0vPTT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJYChcTAAoJEJKo0bgB0vX1XLYP/2YstLYOV2DTKbw8Vwy9gA8s
7UaAjdvD+PfPwKGzM+CMucom+MFoZrXFZmG95Wj0l5XvXEMFdmUUPTMiZSjTk/Xy
TVeC9j7Zt+Lcy2EP4C5G90DI7Z9/dCC/0jBxnYq3kWzKzucr32Ct7emfJ9l2qChf
z+bgfCZb1wZwBRgXd3cvsiCic2Mu/e2IwBW2/F+aGIa+itD+ImVFq8C72x/91IlL
0H7b6jsF3P4Sz432hxL9Oir4o+MPvqzeJPp08UdgetajILbfD/0a3oncr19jvyKi
VwMJ479ktQSafs2HMUPXfNjw0b1zhx0OMWrXT+eQ3Iq+Tmo9jd5Ad6J/bsF9hOzd
Fs/cApKwS/AUxFJLnQxVdxwqFIgQV2EP4eGD9YXtdnboDFyVgl/XcZ56ox3Bqfoz
iahmkYYrR39uzRklMe129QW4J3LoG4CBD0PqeIezEr6KvUMdXdIVyXJiAv362LbH
wLevG/kQKDYdipgkkUNir1K9sZMbB4D/sb3vXZqXH4XeDiiOzh6D3mwLJ36MWY1z
jqFI4//0zRP7aaO2Pms4aupPqVKAtNTg9wZR3GQC4VPDQywdlLeGUHWFW4jw8I27
mcD9EvwnEroqOZT+LNO1+vGxNalm5h7+3ssS15lRdy/VnWolqYso7wJNK7GzuLjC
DQnQcL9N3BoSwGUKjPYa
=EqKU
-----END PGP SIGNATURE-----

--nextPart41033876.HFTSU0vPTT--


From nobody Fri Oct 21 06:52:13 2016
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 A7299129793 for ; Fri, 21 Oct 2016 06:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 5Eptj98vKIkK for ; Fri, 21 Oct 2016 06:52:10 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E985129789 for ; Fri, 21 Oct 2016 06:52:09 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3t0nD72SW6z1J7X; Fri, 21 Oct 2016 15:52:07 +0200 (CEST)
X-purgate-ID: 152705::1477057927-00003836-97A9A340/0/0
X-purgate-size: 1289
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t0nD65W09zkqT4; Fri, 21 Oct 2016 15:52:06 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B74981A565; Fri, 21 Oct 2016 15:52:06 +0200 (CEST)
In-Reply-To: 
To: Andrei Popov 
Date: Fri, 21 Oct 2016 15:52:06 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161021135206.B74981A565@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 21 Oct 2016 13:52:11 -0000

Andrei Popov wrote:
>
> Perhaps it's OK to resume a session with a different SNI if in this
> session the server has proved an identity that matches the new SNI.
> In order to enforce this, the server would have to cache (or save in
> the ticket) a list of identities it presented in each resumable session?

The current wording in rfc6066 may be slightly confusing about what is
acutally important and why.

The server ought to perform a full handshake whenever the full handshake
will result in selection & use of a _different_ TLS server certificate
than what was used for the original full handshake on a session resumption.
This is a direct consequence of the principle of least surprise.

This is also the most backwards-compatible behaviour when upgrading the
server from a does-not-support-SNI to a supports-SNI state/implementation.

You do *NOT* want to have session caching interfere with the
server certificate that a client gets to see, because that would
essentially result in not-quite-deterministic server behaviour.

Sometimes there may be bugs in client-side session caching,
and clients proposing the wrong session for resumption, and the server
doing a full handshake results in interoperable, deterministic and
secure behaviour.


-Martin


From nobody Fri Oct 21 07:01:15 2016
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 6B33812984B for ; Fri, 21 Oct 2016 07:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 v5kl_A4BoE8G for ; Fri, 21 Oct 2016 07:01:12 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1050C12984A for ; Fri, 21 Oct 2016 07:01:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id ECB03139AB; Fri, 21 Oct 2016 17:01:05 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id XqajgewBXV6N; Fri, 21 Oct 2016 17:01:05 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B58492317; Fri, 21 Oct 2016 17:01:05 +0300 (EEST)
Date: Fri, 21 Oct 2016 17:00:57 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20161021140057.GA8197@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 14:01:14 -0000

On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara 
> wrote:
> 
> And since that implementation supports RFC7250 (for the server
> > certificate), here is my interpretation of it:
> >
> > The certificate type is sent in extensions of EE certificate,
> > via the usual server_certificate_type extension (using the server-side
> > syntax from RFC7250).
> >
> 
> I think this probably should go in Encrypted Extensions.

It is definitely related to the certificate chain, and the spec
says such things should go to the first certificate slot (and indeed
the table about extensions says it goes to certificate extensions
block (but not which one).

The client_certificate_type (which I am not using) is listed to go to
EncryptedExtensions, which definitely looks wrong to me, being another
extension related to the certificate chain.


-Ilari


From nobody Fri Oct 21 07:03:26 2016
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 B24E312984B for ; Fri, 21 Oct 2016 07:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 D_x20ZXbspTJ for ; Fri, 21 Oct 2016 07:03:20 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 65A481294F7 for ; Fri, 21 Oct 2016 07:03:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 0056214147; Fri, 21 Oct 2016 17:03:19 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id uVEp5R9sd15k; Fri, 21 Oct 2016 17:03:18 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id C71DE2317; Fri, 21 Oct 2016 17:03:18 +0300 (EEST)
Date: Fri, 21 Oct 2016 17:03:11 +0300
From: Ilari Liusvaara 
To: Martin Thomson 
Message-ID: <20161021140310.GB8197@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021085502.GA7878@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 14:03:25 -0000

On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote:
> On 21 October 2016 at 19:55, Ilari Liusvaara  wrote:
> > Of course, defining the "same certificate" is
> > way trickier than it initially seems
> 
> Not if you think simplistically: same octets in EE ASN1Cert in both handshakes.

Such behaviour would run into problems with certificate renewal.


-Ilari


From nobody Fri Oct 21 07:35:17 2016
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 23599129507 for ; Fri, 21 Oct 2016 07:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 CXCEqQtFEOyg for ; Fri, 21 Oct 2016 07:35:15 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD46E129438 for ; Fri, 21 Oct 2016 07:35:14 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3t0p9r6y42z1J9s; Fri, 21 Oct 2016 16:35:12 +0200 (CEST)
X-purgate-ID: 152705::1477060512-00003836-EDD9BF77/0/0
X-purgate-size: 964
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t0p9r47zmzkq5P; Fri, 21 Oct 2016 16:35:12 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 84D5D1A565; Fri, 21 Oct 2016 16:35:12 +0200 (CEST)
In-Reply-To: <20161021140310.GB8197@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara 
Date: Fri, 21 Oct 2016 16:35:12 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161021143512.84D5D1A565@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 21 Oct 2016 14:35:16 -0000

Ilari Liusvaara wrote:
> On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote:
>> On 21 October 2016 at 19:55, Ilari Liusvaara  wrote:
>>> Of course, defining the "same certificate" is
>>> way trickier than it initially seems
>> 
>> Not if you think simplistically: same octets in EE ASN1Cert
>> in both handshakes.
> 
> Such behaviour would run into problems with certificate renewal.

Just the opposite.  You definitely want full handshake on
certificate renewal.

I don't know how common it is in TLS servers (and TLS clients) to
allow replacing of TLS certificates in "full flight".  I implemented
this in ours about 10 years ago, and I'm flushing the session cache
after loading of the new/updated cert, so that every new handshake
will result in a full handshake rather than session resume (ongoing
connections continue to use the old/previous certificate until
closed by the application).

-Martin


From nobody Fri Oct 21 07:42:51 2016
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 1CCBA1295E6 for ; Fri, 21 Oct 2016 07:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 rhMB1Lqni5Rz for ; Fri, 21 Oct 2016 07:42:48 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id D46F41295CF for ; Fri, 21 Oct 2016 07:42:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 739CF1415C; Fri, 21 Oct 2016 17:42:46 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id Otdw_0eGS8K6; Fri, 21 Oct 2016 17:42:46 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1783F283; Fri, 21 Oct 2016 17:42:46 +0300 (EEST)
Date: Fri, 21 Oct 2016 17:42:38 +0300
From: Ilari Liusvaara 
To: Martin Thomson 
Message-ID: <20161021144238.GA8516@LK-Perkele-V2.elisa-laajakaista.fi>
References:      
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 14:42:50 -0000

On Fri, Oct 21, 2016 at 12:38:29PM +1100, Martin Thomson wrote:
> So I think that the problem could be reduced in complexity.  A little
> at least.  The obvious consequence of changing SNI is that you end up
> somewhere different than last time.  But we can still ensure that the
> connection is to the same peer.

You _might_ end up somewhere different. And even with the same SNI, you
can still end up to different server in the same "group". And different
SNI names can still get you to the same actual place.

> If the server remembered which certificate it used, and insisted that
> THAT remain constant, then you could take a different SNI from - for
> example - a subjectAltName.  Provided that the routing works out, you
> might still get the same certificate.
> 
> I mean, the point of SNI is to route to the right configuration.
> Changing name messes with resumption in that you want to make sure
> that you end up in a place that has the resumption secret.  But if you
> end up at the wrong server, you either fail to resume, or fail to
> connect on the normal terms of the protocol.

There are three tasks of SNI:

- Routing to the correct server. Sometimes this routing is performed by
  middleboxes (yay, middleboxes!).
- The certificate selection within the server.
- Set application instance, if the protocol can't do this in-band (but
  if it does, applications generally override this with in-band value).

And I would expect the servers to actually look at the PSKs offered and
not blindly trying to use one, so if connection is routed wrong, I would
expect fallback to the usual DH-CERT handshake.

> The only thing that could screw this all up is if we end up in a
> situation where one or other peer is confused about either its own
> identity, the identity of its peer, or the identity (-ies) that it
> believes it peer has for itself.  However, with certificate stability
> rather than name stability I don't think we are worse off than with -
> say - a wildcard cert.

I would expect such confusion about own identity to be pretty much the
norm for HTTP servers. And those are frequently used in ways that tend
to amplify even a small errors to serious attacks.

For other types of servers, I would expect any confusion resulting in
security problems to be pretty rare.

But since HTTP is very important usecase, this impiles that the client
shouldn't attempt to use PSKs when such confusion could create security
issues.

> I agree that the add-a-name stuff makes this harder.  A co-tenanted
> server with resumption keys across a bunch of names risks confusing
> itself if it allows resumption across certificates, depending on how
> much state it carries from the old session.  In doing add-a-name, then
> we need to be careful about that, but that's a problem for those of us
> who want to do add-a-name.

You can already get such confusion with wildcard certificates, no
changes needed.. 


-Ilari


From nobody Fri Oct 21 07:57:19 2016
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 975F71295E1 for ; Fri, 21 Oct 2016 07:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 O_Bqim1RbW9q for ; Fri, 21 Oct 2016 07:57:15 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id A7D9C12952C for ; Fri, 21 Oct 2016 07:56:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 48BDA1396B; Fri, 21 Oct 2016 17:56:40 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id dw-5MQrfes21; Fri, 21 Oct 2016 17:56:40 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 021BA21C; Fri, 21 Oct 2016 17:56:39 +0300 (EEST)
Date: Fri, 21 Oct 2016 17:56:32 +0300
From: Ilari Liusvaara 
To: Martin Rex 
Message-ID: <20161021145632.GA8760@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20161021140310.GB8197@LK-Perkele-V2.elisa-laajakaista.fi> <20161021143512.84D5D1A565@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20161021143512.84D5D1A565@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 14:57:17 -0000

On Fri, Oct 21, 2016 at 04:35:12PM +0200, Martin Rex wrote:
> Ilari Liusvaara wrote:
> > On Fri, Oct 21, 2016 at 11:41:59PM +1100, Martin Thomson wrote:
> >> On 21 October 2016 at 19:55, Ilari Liusvaara  wrote:
> >>> Of course, defining the "same certificate" is
> >>> way trickier than it initially seems
> >> 
> >> Not if you think simplistically: same octets in EE ASN1Cert
> >> in both handshakes.
> > 
> > Such behaviour would run into problems with certificate renewal.
> 
> Just the opposite.  You definitely want full handshake on
> certificate renewal.
> 
> I don't know how common it is in TLS servers (and TLS clients) to
> allow replacing of TLS certificates in "full flight". 

Oh, the library I have written definitely does allowing replacing the
server certificate in the flight. All the way to one thread replacing
the certificate while another is handshaking with the old one in the
meantime. And these replaces can happen behind application's and even
the TLS library's back. So no cache flushing.



-Ilari


From nobody Fri Oct 21 07:59:10 2016
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 CA62E12952C for ; Fri, 21 Oct 2016 07:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 fCB10Ah8ppBl for ; Fri, 21 Oct 2016 07:59:08 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 F1258129529 for ; Fri, 21 Oct 2016 07:59:07 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bxbHl-0002QM-VF for tls@ietf.org; Fri, 21 Oct 2016 16:59:07 +0200
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bxbHh-0004Su-E9 for tls@ietf.org; Fri, 21 Oct 2016 10:59:05 -0400
Received: (qmail 9310 invoked from network); 21 Oct 2016 14:59:00 -0000
Received: from unknown (HELO [100.192.24.228]) (Authenticated-user:_huitema@huitema.net@[172.56.42.110]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Oct 2016 14:59:00 -0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Christian Huitema 
X-Mailer: iPhone Mail (14A456)
In-Reply-To: <20161021144238.GA8516@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Fri, 21 Oct 2016 07:58:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <24D2F095-CC7C-4C0F-8501-3467CA5703CD@huitema.net>
References:       <20161021144238.GA8516@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara 
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dP6iToxOOfkkkKBkEi+o3RqBn9PDoOhj/xzb7kHn/aQhIMekNi8AbP1K8LEdFLG4hpdN 8TDNo/7DaoPreqWbH4yb9oylgW8YJxpG8H8ivjVgGlugeeYNRP+TKatltgBEa09tg6wnJ2lrZSUC ZrKFYsHubplnbiDyBMUiEvUZuPnV+6xPoqikFlxGE5ethSvjIJZI+lxcZnIhduMqXEDVCZfDqcig OvSxdRnthmhn8Zn6/mJzKVdFu79dud0anUTz61PsH1QqniimNy9qh2Eko/GUK0vciBekfU6mwXfa SylR/WRbdco3pKNX9x7s84ASzhMKuUeqX+EE9ftsEQ35CMRUE7Q9WvntXa9VPL9K4cA+8t3Xj/Lz Z5s/OJg1L2asZxEp4Bv7TWEUoKzFQfrYUezLRF4P3cD+yYsyYy0PbXJivfXYa4zafYJGo76gRHJN CirkfYeKydSIUY0HOcUIkoQwERtQftX4sSMByQEeoQjUACMyE+XhWF028w059hjlWNOITDa6LxNU +V0EKPyMEBMfFwR5hdoSHsinycGYjNdnlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk
X-Report-Abuse-To: spam@mx99.antispamcloud.com
X-Originating-IP: 168.144.250.245
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.18)
X-Recommended-Action: accept
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 14:59:10 -0000

I am a bit worried about privacy implications of the SNI. Suppose that we in=
vent an obfuscation mechanism that prevents third parties to track which ser=
vice corresponds to an SNI string. The SNI would then be different for any c=
onnection, including resumptions. Do we want to prevent that with a hard rul=
e in the spec?

-- Christian Huitema=20

> On Oct 21, 2016, at 7:42 AM, Ilari Liusvaara  wr=
ote:
>=20
>> On Fri, Oct 21, 2016 at 12:38:29PM +1100, Martin Thomson wrote:
>> So I think that the problem could be reduced in complexity.  A little
>> at least.  The obvious consequence of changing SNI is that you end up
>> somewhere different than last time.  But we can still ensure that the
>> connection is to the same peer.
>=20
> You _might_ end up somewhere different. And even with the same SNI, you
> can still end up to different server in the same "group". And different
> SNI names can still get you to the same actual place.
>=20
>> If the server remembered which certificate it used, and insisted that
>> THAT remain constant, then you could take a different SNI from - for
>> example - a subjectAltName.  Provided that the routing works out, you
>> might still get the same certificate.
>>=20
>> I mean, the point of SNI is to route to the right configuration.
>> Changing name messes with resumption in that you want to make sure
>> that you end up in a place that has the resumption secret.  But if you
>> end up at the wrong server, you either fail to resume, or fail to
>> connect on the normal terms of the protocol.
>=20
> There are three tasks of SNI:
>=20
> - Routing to the correct server. Sometimes this routing is performed by
>  middleboxes (yay, middleboxes!).
> - The certificate selection within the server.
> - Set application instance, if the protocol can't do this in-band (but
>  if it does, applications generally override this with in-band value).
>=20
> And I would expect the servers to actually look at the PSKs offered and
> not blindly trying to use one, so if connection is routed wrong, I would
> expect fallback to the usual DH-CERT handshake.
>=20
>> The only thing that could screw this all up is if we end up in a
>> situation where one or other peer is confused about either its own
>> identity, the identity of its peer, or the identity (-ies) that it
>> believes it peer has for itself.  However, with certificate stability
>> rather than name stability I don't think we are worse off than with -
>> say - a wildcard cert.
>=20
> I would expect such confusion about own identity to be pretty much the
> norm for HTTP servers. And those are frequently used in ways that tend
> to amplify even a small errors to serious attacks.
>=20
> For other types of servers, I would expect any confusion resulting in
> security problems to be pretty rare.
>=20
> But since HTTP is very important usecase, this impiles that the client
> shouldn't attempt to use PSKs when such confusion could create security
> issues.
>=20
>> I agree that the add-a-name stuff makes this harder.  A co-tenanted
>> server with resumption keys across a bunch of names risks confusing
>> itself if it allows resumption across certificates, depending on how
>> much state it carries from the old session.  In doing add-a-name, then
>> we need to be careful about that, but that's a problem for those of us
>> who want to do add-a-name.
>=20
> You can already get such confusion with wildcard certificates, no
> changes needed..=20
>=20
>=20
> -Ilari
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Fri Oct 21 08:01:17 2016
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 39324128DF6 for ; Fri, 21 Oct 2016 08:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Uy_upsaBkaE1 for ; Fri, 21 Oct 2016 08:01:14 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1E8129567 for ; Fri, 21 Oct 2016 08:01:14 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id u124so98370508ywg.3 for ; Fri, 21 Oct 2016 08:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z0X1gDhrQ0XrCdK+v92z50WgaK6JMD6SkCvKvNXnmNQ=; b=D32vvzbResHsDVcoSU64HRmE1HanawyFbCrZ1qb4i2bNT8KagMi9TyZW27FNjIzIEt Gn+lDH9HdWISBlCIrKL03kZsqJEAx0Q/i7WVmdqMk2CI4BwnWHqfURyGYm+xZSZbE11f 9jjehVwZR0VWztL+108J4BEqr5CU6Q4vwhICUUcpmwxXFwkDgJ4bErAE2VabmAVOuxWp PnqrESPLRF4DiUGxxg9xJTgBYcmXyXAoF5L5hFqYDEcXLyNH+aehjdHBoJdPVQ3SCEu+ AllKQmV7+AYtn/c1ldst/uDJRCsAxUm3kO0cdvLgyZGryq4UVU8jT8L5AjxuZqAxBhUX rsxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z0X1gDhrQ0XrCdK+v92z50WgaK6JMD6SkCvKvNXnmNQ=; b=lVtDGZq4g0p7QdpyWcN+zJ3CnPvkzfTqHBmDqE3ai75gASWhZRCUQmyKelCj1aSkAo 0jGb1aJFuP7/FixqmR0YPgtNasSjjzUzdF9SvPUn/oWgquzjGAuOo7ymaA5CF/RjFWjr EjjRl4fb4Kt94mudCyKZ3jPYo57cIwxaOBNVAXuH6c/Vrg+ltrnDFHBG+E5VWBCMn0Tm bgH1Mlkons+N2UCVmWVw+wFjq4miZIFYaZzgztaIaZiNJx5mY6MWpxuY4FQxkcWL1OVp NevlTlgigTgGesbkpOFh6T7NJEZQ/4XlnLVr5AUvVMOj99MrOCCnX1J4npP0xjJhgK+1 UiLg==
X-Gm-Message-State: ABUngvfs9LhxLo/ISRmiGrZIc1hEBnoG+jGwSUvNIInOAqnow5n6C0hTHbCswOyz5lcg+amOlFh7fLqBHhRGsA==
X-Received: by 10.129.78.197 with SMTP id c188mr1514203ywb.21.1477062073627; Fri, 21 Oct 2016 08:01:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Fri, 21 Oct 2016 08:00:33 -0700 (PDT)
In-Reply-To: <20161021140057.GA8197@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>  <20161021140057.GA8197@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Fri, 21 Oct 2016 08:00:33 -0700
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a114ddac635ec41053f615082
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 15:01:16 -0000

--001a114ddac635ec41053f615082
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara 
wrote:

> On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> >
> > And since that implementation supports RFC7250 (for the server
> > > certificate), here is my interpretation of it:
> > >
> > > The certificate type is sent in extensions of EE certificate,
> > > via the usual server_certificate_type extension (using the server-side
> > > syntax from RFC7250).
> > >
> >
> > I think this probably should go in Encrypted Extensions.
>
> It is definitely related to the certificate chain,


My argument would be that it doesn't belong in "individual certificates"
because it applies to certificates as a whole. It's not like it would be
legal to have a 7250 cert followed by an X.509 cert, one hopes

-Ekr


-Ekr



and the spec
> says such things should go to the first certificate slot (and indeed
> the table about extensions says it goes to certificate extensions
> block (but not which one).
>


> The client_certificate_type (which I am not using) is listed to go to
> EncryptedExtensions, which definitely looks wrong to me, being another
> extension related to the certificate chain.
>
>
> -Ilari
>

--001a114ddac635ec41053f615082
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:
On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <ilariliusvaara@welho.com>

> wrote:

>

> And since that implementation supports RFC7250=
 (for the server

> > certificate), here is my interpretation of it:

> >

> > The certificate type is sent in extensions of EE certificate,

> > via the usual server_certificate_type extension (using the server=
-side

> > syntax from RFC7250).

> >

>

> I think this probably should go in Encrypted Extensions.



It is definitely related to the certificate chain, 

My argument would be that it doesn't belong in "in=
dividual certificates"
because it applies to certificates as=
 a whole. It's not like it would be
legal to have a 7250 cert=
 followed by an X.509 cert, one hopes

-Ekr


-Ekr



and the spec

says such things should go to the first certificate slot (and indeed

the table about extensions says it goes to certificate extensions

block (but not which one).



The client_certificate_type (which I am not using) is listed to go to

EncryptedExtensions, which definitely looks wrong to me, being another

extension related to the certificate chain.





-Ilari





--001a114ddac635ec41053f615082--


From nobody Fri Oct 21 08:06:20 2016
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 37EE2129411 for ; Fri, 21 Oct 2016 08:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 dpHi-YCWPxde for ; Fri, 21 Oct 2016 08:06:18 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id BD64F120726 for ; Fri, 21 Oct 2016 08:06:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D997D16DA1; Fri, 21 Oct 2016 18:06:17 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id WErBAp-YH5jX; Fri, 21 Oct 2016 18:06:17 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 8EAE727B; Fri, 21 Oct 2016 18:06:17 +0300 (EEST)
Date: Fri, 21 Oct 2016 18:06:09 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20161021150609.GA8844@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>  <20161021140057.GA8197@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 15:06:20 -0000

On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara 
> wrote:
> 
> > On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <
> > ilariliusvaara@welho.com>
> > > wrote:
> > >
> > > And since that implementation supports RFC7250 (for the server
> > > > certificate), here is my interpretation of it:
> > > >
> > > > The certificate type is sent in extensions of EE certificate,
> > > > via the usual server_certificate_type extension (using the server-side
> > > > syntax from RFC7250).
> > > >
> > >
> > > I think this probably should go in Encrypted Extensions.
> >
> > It is definitely related to the certificate chain,
> 
> 
> My argument would be that it doesn't belong in "individual certificates"
> because it applies to certificates as a whole. It's not like it would be
> legal to have a 7250 cert followed by an X.509 cert, one hopes

Well, there can't be two server certificate "chains". But if there
could, I would expect the type to per-chain.



-Ilari


From nobody Fri Oct 21 08:15:03 2016
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 6320412955B for ; Fri, 21 Oct 2016 08:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 b_OsK4nUGbXj for ; Fri, 21 Oct 2016 08:14:59 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8201294B2 for ; Fri, 21 Oct 2016 08:14:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 33E7B13966; Fri, 21 Oct 2016 18:14:50 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id qRho6HVAKgU5; Fri, 21 Oct 2016 18:14:50 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id EC62227F; Fri, 21 Oct 2016 18:14:49 +0300 (EEST)
Date: Fri, 21 Oct 2016 18:14:42 +0300
From: Ilari Liusvaara 
To: Christian Huitema 
Message-ID: <20161021151442.GA9003@LK-Perkele-V2.elisa-laajakaista.fi>
References:       <20161021144238.GA8516@LK-Perkele-V2.elisa-laajakaista.fi> <24D2F095-CC7C-4C0F-8501-3467CA5703CD@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <24D2F095-CC7C-4C0F-8501-3467CA5703CD@huitema.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 15:15:02 -0000

On Fri, Oct 21, 2016 at 07:58:57AM -0700, Christian Huitema wrote:
> I am a bit worried about privacy implications of the SNI. Suppose
> that we invent an obfuscation mechanism that prevents third parties
> to track which service corresponds to an SNI string. The SNI would
> then be different for any connection, including resumptions. Do we
> want to prevent that with a hard rule in the spec?

Such mechanism on TLS level would be pretty hard to do. You can't do
any sort of static encryption or obfustication for instance (because
that would be trivially attackable).


Much more feasible to have application layer (with possibly TLS protocol
support) way of sending new server certificates in the fly (post-
handshake auth, but with servers).

(It seems to me that due to the roles of HTTP clients and servers, post-
handshake server auth is a lot less scary than post-handshake client
auth).


-Ilari


From nobody Fri Oct 21 08:15:46 2016
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 B6EA61294B2 for ; Fri, 21 Oct 2016 08:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 J_XyuV4Z8dok for ; Fri, 21 Oct 2016 08:15:35 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532F51295FC for ; Fri, 21 Oct 2016 08:15:31 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id f97so38099901ybi.1 for ; Fri, 21 Oct 2016 08:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=63g010ZrZWbWmwezR7yrZm9N5LLiZfG0WF/jefgNkV4=; b=xRaqd4EexeavrlMObXB3iwGZlmtQ94mXZHvYBR/olsDPDXAUhEC3IiD+XbDhF4A/qI WC4kriGBUuMMhIrEjrwaKMe5r+IvMGa4k1uu1ujJGOFskacCJUILBgUehKar2Magz1o5 mavlQzJ6BMcLBCpXD66GX8X9RTFiTHvyqkwIiyJzAxnaFr0hfOx/T+d3UOmJLUNx4XGi 63AklG+t4IrtCPCOuahTIgrnXu8zfkcAn6APRibh9I2xkn00eS6sNeCmU39B6IipbI2X rfwJ6+V9bQutDj1nsXvihz09knwN38foy/yPM+dlizrBJDfyaXuds7sNgvlgp/TbTDwZ eyFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=63g010ZrZWbWmwezR7yrZm9N5LLiZfG0WF/jefgNkV4=; b=S9F2G75wAtd8KWPbrGxkbFcFQ/UyBV1ObRxR5vrAKcwY7ip/YmYP94ozwT5OFNsRhs d8JxuTU+ofXIP8COlyMCcA53aJdFD8knW3HhCUB7mldIcoUJbAWfpqzWUWsk+OxNvEwS B34dH0ckYJH/Z7iT36Tl4a9hempimqHyJDzKn0YgIZXLMY1+guW3+3w1U7ZlfSoCgjJg 2P4iEBaXSHeht+rfULGxSM6GelhMbdIhPnSts7b4nu7BcHcd9mQAJV+iPqi7OnrwMIkV IPw4Nhdhfleu0IOVlM8C+3Sbo/E36sjmtrU3RcGyUfVH3APojqtf/Okk+CmE1zsp1KBV ncSA==
X-Gm-Message-State: ABUngvfxnUCcd2CJSpaM7Z/j9bZ8e6qH7QP/s8nuyQBFpchs7QcotGpgYO3hHg0jAIM0q5BtFJZken/P1741OQ==
X-Received: by 10.37.174.11 with SMTP id a11mr1552615ybj.180.1477062930586; Fri, 21 Oct 2016 08:15:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Fri, 21 Oct 2016 08:14:50 -0700 (PDT)
In-Reply-To: <20161021150609.GA8844@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>  <20161021140057.GA8197@LK-Perkele-V2.elisa-laajakaista.fi>  <20161021150609.GA8844@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Fri, 21 Oct 2016 08:14:50 -0700
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=f403045db83e4a31e2053f6183d2
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 15:15:37 -0000

--f403045db83e4a31e2053f6183d2
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 21, 2016 at 8:06 AM, Ilari Liusvaara 
wrote:

> On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote:
> > On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> >
> > > On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > > > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <
> > > ilariliusvaara@welho.com>
> > > > wrote:
> > > >
> > > > And since that implementation supports RFC7250 (for the server
> > > > > certificate), here is my interpretation of it:
> > > > >
> > > > > The certificate type is sent in extensions of EE certificate,
> > > > > via the usual server_certificate_type extension (using the
> server-side
> > > > > syntax from RFC7250).
> > > > >
> > > >
> > > > I think this probably should go in Encrypted Extensions.
> > >
> > > It is definitely related to the certificate chain,
> >
> >
> > My argument would be that it doesn't belong in "individual certificates"
> > because it applies to certificates as a whole. It's not like it would be
> > legal to have a 7250 cert followed by an X.509 cert, one hopes
>
> Well, there can't be two server certificate "chains". But if there
> could, I would expect the type to per-chain.
>

Sorry, I'm not sure I am following.

What I am concerned about is the case where ServerCertificate =

[
   {
      Extensions : [ server_certificate_type = RawPublicKey],
      Certificate  : 
   } ,
   {
      Extensions : [],
      Certificate : 
   }
]

What is the other side supposed to do with that?


-Ekr


>
>
>
> -Ilari
>

--f403045db83e4a31e2053f6183d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Oct 21, 2016 at 8:06 AM, Ilari Liusvaara <=
ilariliusvaar=
a@welho.com> wrote:
On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara <ilariliusvaara@welho.com>

> wrote:

>

> > On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <

> > ilariliusvaara@welho.=
com>

> > > wrote:

> > >

> > > And since that implementation supports RFC7250 (for the serv=
er

> > > > certificate), here is my interpretation of it:

> > > >

> > > > The certificate type is sent in extensions of EE certif=
icate,

> > > > via the usual server_certificate_type extension (using =
the server-side

> > > > syntax from RFC7250).

> > > >

> > >

> > > I think this probably should go in Encrypted Extensions.

> >

> > It is definitely related to the certificate chain,

>

>

> My argument would be that it doesn't belong in "individual ce=
rtificates"

> because it applies to certificates as a whole. It's not like it wo=
uld be

> legal to have a 7250 cert followed by an X.509 cert, one hopes



Well, there can't be two server certificate "chains". =
But if there

could, I would expect the type to per-chain.

Sorry, I'm not sure I am following.

What=
 I am concerned about is the case where ServerCertificate =3D
[
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 Exten=
sions : [ server_certificate_type =3D RawPublicKey],
=C2=A0 =C2=
=A0 =C2=A0 Certificate =C2=A0: <some SPKI>
=C2=A0 =C2=A0} ,=

=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 Extensions : [],
=C2=A0 =C2=A0 =C2=A0 Certificate : <some X.509 cert>
=C2=A0 =C2=A0}
]

What is the othe=
r side supposed to do with that?
=C2=A0=C2=A0

-Ekr
=C2=A0







-Ilari





--f403045db83e4a31e2053f6183d2--


From nobody Fri Oct 21 08:22:15 2016
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 58906129614 for ; Fri, 21 Oct 2016 08:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 w-A-ZzvI7sWI for ; Fri, 21 Oct 2016 08:22:06 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id EB769129608 for ; Fri, 21 Oct 2016 08:22:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4C759139B0; Fri, 21 Oct 2016 18:22:05 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id XtUmSu_WEXTb; Fri, 21 Oct 2016 18:22:05 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id E211C2310; Fri, 21 Oct 2016 18:22:04 +0300 (EEST)
Date: Fri, 21 Oct 2016 18:21:57 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20161021152157.GB9003@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>  <20161021140057.GA8197@LK-Perkele-V2.elisa-laajakaista.fi>  <20161021150609.GA8844@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 15:22:14 -0000

On Fri, Oct 21, 2016 at 08:14:50AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 8:06 AM, Ilari Liusvaara 
> wrote:
> 
> > On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote:
> > > On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara <
> > ilariliusvaara@welho.com>
> > > wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > > > > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <
> > > > ilariliusvaara@welho.com>
> > > > > wrote:
> > > > >
> > > > > And since that implementation supports RFC7250 (for the server
> > > > > > certificate), here is my interpretation of it:
> > > > > >
> > > > > > The certificate type is sent in extensions of EE certificate,
> > > > > > via the usual server_certificate_type extension (using the
> > server-side
> > > > > > syntax from RFC7250).
> > > > > >
> > > > >
> > > > > I think this probably should go in Encrypted Extensions.
> > > >
> > > > It is definitely related to the certificate chain,
> > >
> > >
> > > My argument would be that it doesn't belong in "individual certificates"
> > > because it applies to certificates as a whole. It's not like it would be
> > > legal to have a 7250 cert followed by an X.509 cert, one hopes
> >
> > Well, there can't be two server certificate "chains". But if there
> > could, I would expect the type to per-chain.
> >
> 
> Sorry, I'm not sure I am following.
> 
> What I am concerned about is the case where ServerCertificate =
> 
> [
>    {
>       Extensions : [ server_certificate_type = RawPublicKey],
>       Certificate  : 
>    } ,
>    {
>       Extensions : [],
>       Certificate : 
>    }
> ]
> 
> What is the other side supposed to do with that?

Well, my implementation treats it the same as TLS 1.2 handshake with
server_certificate_type=RPK and a two certificates in the chain). Which
apparently means just ignoring the second certificate.

But if it had certificate type that could use multiple slots, there
could only be one chain type (server_certificate_type can only appear
once per chain, in the first slot).



-Ilari


From nobody Fri Oct 21 08:38:22 2016
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 0CEBB129631 for ; Fri, 21 Oct 2016 08:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 b-JT3TbB6NiO for ; Fri, 21 Oct 2016 08:38:19 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C19B129608 for ; Fri, 21 Oct 2016 08:38:19 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id q7so91515599qtq.1 for ; Fri, 21 Oct 2016 08:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=zWwXwhWN6mU7cB13lnm8ZaZjmlGA+mSR2kP/oCT8Zhk=; b=bv0YN+cNzeqJouvl4uqFr6kg+KLsl5sfLMYLGl1LmMGWrUI3VHjfwRpyUmCiEzt20M dz3KVtS7xJDmYVV4Ne2A9p7DbZ4KlblyLjis6nVZzgYypQN8vZ/APPx+WfoSgbD0rlhr fmWcK2OoiOEtOBmXym4OUut6MuDHpljFXWme8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=zWwXwhWN6mU7cB13lnm8ZaZjmlGA+mSR2kP/oCT8Zhk=; b=mfDMh3Dj+ZWbb3egyv3mSYHtik3Jn4j7sPS59NbbxKTmX1j6tEYCRYO6+kma7LEKwL cFbL2rYLx6qwaMtKt3iP23YoJY1UfUclWxFyjn9t6ADryWLzcC11yv4wgkgqeXVbxhmK zlkxY0XT3eZ/8b+AjQ/vsLD7EWv4dKr4ML0WL/9FrXaVAUYx3d4IXtJOsyK556/yfwO6 OCq//kjuuKXET8EjdJ8qVjGD1AI5pfIjRLazfNIaY+OB7NLOmGacf6Ajo/TE1p/lMSOi INf3Vm44X6mig9rRnnhGN3M0mzI6hvr0ZNbunIbnXBgIAvQMwcr1QOyHFDtz3zjENboY BK4Q==
X-Gm-Message-State: ABUngvdelNwPHp1w1ZFc3FFmMX8XmtJXt/f4vKgYEIipM5cz4xYsLZ2Rh6vstCdogtqKlw==
X-Received: by 10.200.34.6 with SMTP id o6mr1863142qto.88.1477064298184; Fri, 21 Oct 2016 08:38:18 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.229.241]) by smtp.gmail.com with ESMTPSA id n128sm1589744qka.49.2016.10.21.08.38.17 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 21 Oct 2016 08:38:17 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Fri, 21 Oct 2016 11:38:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi> 
To: "tls@ietf.org" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 15:38:21 -0000

> On Oct 21, 2016, at 07:39, Eric Rescorla  wrote:
>=20
> On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara =
 wrote:
> On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
> > Folks,
> >
> > I have just uploaded draft-ietf-tls-tls13-17.
>=20
> Updated my own implementation from -16 to -17 (TODO: Add to
> implementations page, it isn't any of the ones listed).
>=20
> Please do.
>=20
> We're working on ours so interop testing would be great.

Not sure how up to date this is but here=E2=80=99s a list of some =
implementations:

https://github.com/tlswg/tls13-spec/wiki/Implementations

spt=


From nobody Fri Oct 21 08:43:13 2016
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 15F231293E9 for ; Fri, 21 Oct 2016 08:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Xq_M8JsCn5tQ for ; Fri, 21 Oct 2016 08:43:11 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 0B4D11295C9 for ; Fri, 21 Oct 2016 08:43:11 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bxbyP-00028x-B7 for tls@ietf.org; Fri, 21 Oct 2016 17:43:10 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bxbyK-0007YE-UK for tls@ietf.org; Fri, 21 Oct 2016 11:43:08 -0400
Received: (qmail 24165 invoked from network); 21 Oct 2016 15:43:03 -0000
Received: from unknown (HELO [10.10.6.107]) (Authenticated-user:_huitema@huitema.net@[207.170.229.107]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Oct 2016 15:43:03 -0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Christian Huitema 
X-Mailer: iPhone Mail (14A456)
In-Reply-To: <20161021151442.GA9003@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Fri, 21 Oct 2016 08:42:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E570F74-46B8-4B1D-A3FF-951238A3824F@huitema.net>
References:       <20161021144238.GA8516@LK-Perkele-V2.elisa-laajakaista.fi> <24D2F095-CC7C-4C0F-8501-3467CA5703CD@huitema.net> <20161021151442.GA9003@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara 
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dP6iToxOOfkkkKBkEi+o3RqBn9PDoOhj/xzb7kHn/aQhIMekNi8AbP1K8LEdFLG4hjMN uobEWnyCepw9YP8m35ak2VYwN59oO6WH87YCmRSlGlugeeYNRP+TKatltgBEa09tg6wnJ2lrZSUC ZrKFYsHubplnbiDyBMUiEvUZuPnV+6xPoqikFlxGE5ethSvjIJZI+lxcZnIhduMqXEDVCZfDqcig OvSxdRnthmhn8Zn6/mJzKVdFu79dud0anUTz61PsH1QqniimNy9qh2Eko/GUK0vciBekfU6mwXfa SylR/WRbdco3pKNX9x7s84ASzhMKuUeqX+EE9ftsEQ35CMRUE7Q9WvntXa9VPL9K4cA+8t3Xj/Lz Z5s/OJg1L2asZxEp4Bv7TWEUoKzFQfrYUezLRF4P3cD+yYsyYy0PbXJivfXYa4zafYJGo76gRHJN CirkfYeKydSIUY0HOcUIkoQwERtQftX4sSMByQEeoQjUACMyE+XhWF028w059hjlWNOITDa6LxNU +V0EKPyMEBMfFwR5hdoSHsinycGYjNdnlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk
X-Report-Abuse-To: spam@mx99.antispamcloud.com
X-Originating-IP: 168.144.250.245
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.21)
X-Recommended-Action: accept
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 15:43:12 -0000

I mentioned obfuscation as one possible solution. I know that I can make it w=
ork for small scale servers, e.g., up to a few hundreds registered clients. B=
ut if we can achieve the same privacy results with some mechanisms using dyn=
amic certificates, that's fine too. My only point is, please don't forbid fu=
ture privacy enhancement with a hard rule on SNI. Maybe something like "shou=
ld use the same SNI, but may use different ones if client and server agree o=
n an SNI privacy scheme."

-- Christian Huitema=20

> On Oct 21, 2016, at 8:14 AM, Ilari Liusvaara  wr=
ote:
>=20
>> On Fri, Oct 21, 2016 at 07:58:57AM -0700, Christian Huitema wrote:
>> I am a bit worried about privacy implications of the SNI. Suppose
>> that we invent an obfuscation mechanism that prevents third parties
>> to track which service corresponds to an SNI string. The SNI would
>> then be different for any connection, including resumptions. Do we
>> want to prevent that with a hard rule in the spec?
>=20
> Such mechanism on TLS level would be pretty hard to do. You can't do
> any sort of static encryption or obfustication for instance (because
> that would be trivially attackable).
>=20
>=20
> Much more feasible to have application layer (with possibly TLS protocol
> support) way of sending new server certificates in the fly (post-
> handshake auth, but with servers).
>=20
> (It seems to me that due to the roles of HTTP clients and servers, post-
> handshake server auth is a lot less scary than post-handshake client
> auth).
>=20
>=20
> -Ilari


From nobody Fri Oct 21 10:32:53 2016
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF4C129634; Fri, 21 Oct 2016 10:32:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147707117213.28125.1202195457305261205.idtracker@ietfa.amsl.com>
Date: Fri, 21 Oct 2016 10:32:52 -0700
Archived-At: 
Cc: tls@ietf.org, tls-chairs@ietf.org, smccammon@amsl.com
Subject: [TLS] tls - Update to a Meeting Session Request for IETF 97
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 21 Oct 2016 17:32:52 -0000

An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the tls working group.


---------------------------------------------------------
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Stephanie McCammon

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 2 Hours
Number of Attendees: 120
Conflicts to Avoid: 
 First Priority: curdle uta acme cose cfrg dane httpbis httpauth rtcweb saag stir tcpinc tokbind perc quic
 Second Priority: sacm oauth



Special Requests:
  
---------------------------------------------------------


From nobody Fri Oct 21 11:11:42 2016
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 0AED61297C4 for ; Fri, 21 Oct 2016 11:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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 DA8yoRMIfAFc for ; Fri, 21 Oct 2016 11:11:39 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0120.outbound.protection.outlook.com [104.47.40.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0081295B9 for ; Fri, 21 Oct 2016 11:11:39 -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=y1JQnQzLpPL1RIGVI02YZIQO2B4yonAeoWmQZFq6KCM=; b=fSLPY1e2aW2NOdvVjIrCM6UmgB7rxhtZEdZC/6tSWoqiBOIaWOrO7hIbimuH2G2GMQBhUNtKeUkb6fujqY/1ctIm72+9y4Z6QpUNEolYvwXPa5GLCK3Hjrb4wHYERTIIc+crzCgMbZeCg9gXvY8YLHcpyYuomYLMDWrQQ5W21Gs=
Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Fri, 21 Oct 2016 18:11:37 +0000
Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Fri, 21 Oct 2016 18:11:37 +0000
From: Andrei Popov 
To: "mrex@sap.com" 
Thread-Topic: [TLS] SNI and Resumption/0-RTT
Thread-Index: AQHSKzLpp1if3oZyr0eklNKSlm6JUqCyEPywgAAB5gCAAACNkIAA2skAgABEipA=
Date: Fri, 21 Oct 2016 18:11:36 +0000
Message-ID: 
References:  <20161021135206.B74981A565@ld9781.wdf.sap.corp>
In-Reply-To: <20161021135206.B74981A565@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=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8::1d2]
x-ms-office365-filtering-correlation-id: ab02fc22-7611-4e74-4ada-08d3f9ddb2b1
x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0838; 7:8CMdCatfIHhiL6VCk17i6gtVsEVXmx+8nzUlegLMC7rmefrwHbHrvje5eWmlMjlTpYt0F9/Z1kWFruJO4i/SJMxwZwmXa/1cUUaFib/Bx3IDHkG3a6LbvBBE1oYhvQUb3NonHmVwsDNBRJcXgszjOVCpt1jhZORUOikByKMtU65nAoea8Z4knkHLJxBhHhRK0WXdYIEFXH5yb8HMB7egznbwwjv5c/wELIMjYBagKXiySiQyJfuRYm1KG5nJGih1yin58GaeV/eDLdZM4tOAiQNG9TFV5cdLplfBrJQ767CxSKbdhYJdUOL7G4xlZpn5y14Y4rGC/T1Kdtl29Wz6iZGMMmlRRvjD7oe120LBIgI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0838;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(55761251573089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0838; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0838; 
x-forefront-prvs: 01026E1310
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(13464003)(199003)(189002)(586003)(7736002)(5005710100001)(68736007)(106356001)(8990500004)(305945005)(74316002)(106116001)(5002640100001)(3660700001)(50986999)(122556002)(10400500002)(81166006)(81156014)(1730700003)(4326007)(8666005)(5660300001)(2351001)(10290500002)(76176999)(8936002)(2906002)(101416001)(5640700001)(86362001)(7846002)(6116002)(97736004)(99286002)(8676002)(110136003)(102836003)(2950100002)(92566002)(105586002)(87936001)(76576001)(189998001)(54356999)(86612001)(77096005)(6916009)(2900100001)(33656002)(3280700002)(2501003)(7696004)(19580405001)(10090500001)(11100500001)(19580395003)(9686002)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0838; H:BY1PR0301MB0838.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2016 18:11:36.8392 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0838
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 18:11:41 -0000

> The server ought to perform a full handshake whenever the full handshake =
will result in selection & use of a _different_ TLS server certificate than=
 what was used for the original full handshake on a session resumption.
I think this is correct, assuming a server is only able to present one cert=
 in a TLS session (which is currently the case).

However, this does not mean that the SNI at resumption time has to match th=
e SNI at session establishment time, because the same server cert can match=
 multiple SNIs.

Also, there appears to be interest in allowing the client to request server=
 auth post-handshake. If this gets supported, a server may prove multiple i=
dentities to a client within the same TLS session. And then perhaps the cli=
ent should be able to resume the session with an SNI that matches any of th=
e identities the server has proved in this session.

Cheers,

Andrei

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com]=20
Sent: Friday, October 21, 2016 6:52 AM
To: Andrei Popov 
Cc: Eric Rescorla ; tls@ietf.org
Subject: Re: [TLS] SNI and Resumption/0-RTT

Andrei Popov wrote:
>
> Perhaps it's OK to resume a session with a different SNI if in this=20
> session the server has proved an identity that matches the new SNI.
> In order to enforce this, the server would have to cache (or save in=20
> the ticket) a list of identities it presented in each resumable session?

The current wording in rfc6066 may be slightly confusing about what is acut=
ally important and why.

The server ought to perform a full handshake whenever the full handshake wi=
ll result in selection & use of a _different_ TLS server certificate than w=
hat was used for the original full handshake on a session resumption.
This is a direct consequence of the principle of least surprise.

This is also the most backwards-compatible behaviour when upgrading the ser=
ver from a does-not-support-SNI to a supports-SNI state/implementation.

You do *NOT* want to have session caching interfere with the server certifi=
cate that a client gets to see, because that would essentially result in no=
t-quite-deterministic server behaviour.

Sometimes there may be bugs in client-side session caching, and clients pro=
posing the wrong session for resumption, and the server doing a full handsh=
ake results in interoperable, deterministic and secure behaviour.


-Martin


From nobody Fri Oct 21 14:59:02 2016
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 DD134129683 for ; Fri, 21 Oct 2016 14:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EPKcraSim5TT for ; Fri, 21 Oct 2016 14:59:00 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AAC129669 for ; Fri, 21 Oct 2016 14:59:00 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id c78so9048408wme.1 for ; Fri, 21 Oct 2016 14:59:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GFx/IPcbmDXY1otfPy8XDqQ5+qZhJAPzw28YLlIudRc=; b=m+qAHBf2jWmkHEyA3mYrsEq7n4G5DY6SZ2ogZQj0IoSNaYFM1xoHJ1xQOV5GXhXFk4 qzKekJxBexQ+cm9yni2GHw7GMocu9iN0QPkVzfhBn1E2OAEADXkw/vWRGCzJRUb9SmsU IAG7mwDTrUfqfcDuVpBrONBYFUP3lePTAu7EzlGk3zviogjCdN+cqhr1xAYPz+cIluyf 4XQxsgCYcY3tUP1NYmG8lw7RAhCcuw+V1tH44COYv7YQmuVWfVNF6GJvhYL7SSNdHQAj UNN4gH+UEx9oTQupOD8eC0uRhUK5toS+NzzHF5NWAnAozrtkWbzr/Cxm4S32zSc7OJJl UmEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GFx/IPcbmDXY1otfPy8XDqQ5+qZhJAPzw28YLlIudRc=; b=UJSFSHBZkO7Lol+M08A36wrRFRtTzOpT1qkus3ZywEWNSEMTGfcfd+r8PTU8a+esDp huUNLZXhrWhTivdTn52mpAvwmCLOi7IZ18/jvsoYTr1T9PDcg7caDBq35P42SgEI5VKl jvQncD2mEdKyxPlbAX2XswPLMywt5QsPPDtHgJLOBSVz9XywfaqoBVq13c6fzTAs+nxn 9mSPioPc/scLqSzLjkRAOdSzacWuLlGSzZMT5yuEbfyfpXgdN7aSVj7LqrOCDg0Dz3Ml 9vAFrb9tVDFTYrscoUAq3wqhNQXE23aiTBV4t3Q9eSoU/VWfnkIFxDn+PEU9/HkiuNWB ivpA==
X-Gm-Message-State: ABUngveIIF8OphwnRDF51zjiDvZ0zIvdGk1D+I8aaS/1JoUG68MmSWVZVopQcQXA5XwLtzOclTgSEDvI0qRzpQ==
X-Received: by 10.194.97.69 with SMTP id dy5mr2251277wjb.53.1477087138581; Fri, 21 Oct 2016 14:58:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Fri, 21 Oct 2016 14:58:57 -0700 (PDT)
In-Reply-To: <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>
From: Kazuho Oku 
Date: Sat, 22 Oct 2016 06:58:57 +0900
Message-ID: 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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: Fri, 21 Oct 2016 21:59:02 -0000

2016-10-21 18:33 GMT+09:00 Ilari Liusvaara :
> On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
>> Folks,
>>
>> I have just uploaded draft-ietf-tls-tls13-17.
>
> Updated my own implementation from -16 to -17 (TODO: Add to
> implementations page, it isn't any of the ones listed).
>
> And since that implementation supports RFC7250 (for the server
> certificate), here is my interpretation of it:
>
> The certificate type is sent in extensions of EE certificate,
> via the usual server_certificate_type extension (using the server-side
> syntax from RFC7250).
>
>
> Okay, the extension is after the certificate it attaches to (which is
> just weird), but turns out this wasn't that bad to implement, due to
> how the code happened to be laid out (it first sliced the certificate
> message to extract the certificates and only afterwards processed
> those).
>
>
>
> ... Interop tests with picotls failed:
>
> - Picotls sends extension 13 (signature_algorithms) in ServerHello,
>   which my implementation does not like[1].
> - Picotls still seems to have the resumption_context mixed into
>   hashes. I tought that got nuked when switching to "finished
>   stuffing"? This causes wrong encryption keys to be derived,
>   causing the handshake to blow up.
>

Thank you very much for testing, and for reporting the issues you
found. Apparently I missed the changes when I made the adjustments for
draft-17.

I've pushed the fixes on to my git repository
(https://github.com/h2o/picotls) fixing the two issues. Hopefully with
them, picotls would be able to communicate with your implementation (I
think it might be better to go through my code with draft-17 in hand
to see if any other discordances exist, but that'll be in the next
week).

I am also looking forward to seeing your implementation on the Wiki.

>
>
> [1] Wasn't this ripped out in -17? The -17 draft seems to list that
> extension as "clear", shouldn't it be "client" as the AFAIK the
> server won't send it?
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Kazuho Oku


From nobody Fri Oct 21 16:26:11 2016
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DD8129871; Fri, 21 Oct 2016 16:21:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147709207800.28214.12313304502480836525.idtracker@ietfa.amsl.com>
Date: Fri, 21 Oct 2016 16:21:18 -0700
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] tls - Requested sessions have been scheduled for IETF 97
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 21 Oct 2016 23:21:18 -0000

Dear Sean Turner,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

tls Session 1 (2:30:00)
    Tuesday, Afternoon Session II 1550-1820
    Room Name: Park Ballroom 1 size: 125
    ---------------------------------------------
    tls Session 2 (2:00:00)
    Friday, Morning Session I 0930-1130
    Room Name: Grand Ballroom 2 size: 200
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Sean Turner

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 2 Hours
Number of Attendees: 120
Conflicts to Avoid: 
 First Priority: curdle uta acme cose cfrg dane httpbis httpauth rtcweb saag stir tcpinc tokbind perc quic
 Second Priority: sacm oauth



Special Requests:
  
---------------------------------------------------------


From nobody Sat Oct 22 07:30:14 2016
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 705131295DA for ; Sat, 22 Oct 2016 07:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.732
X-Spam-Level: 
X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 bi_9McKDFSva for ; Sat, 22 Oct 2016 07:30:12 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7961294EE for ; Sat, 22 Oct 2016 07:30:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8CB29BE4C for ; Sat, 22 Oct 2016 15:30:10 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWOY2zibT8fX for ; Sat, 22 Oct 2016 15:30:09 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9BABEBE49 for ; Sat, 22 Oct 2016 15:30:08 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477146609; bh=ozXHEB9CkFdz7gUyCtdQ8tIgjjs4O5n4PI5FLmiqgaU=; h=To:From:Subject:Date:From; b=4LvfZK8/1G4DnsXZFZ1uWPJdijRzSwmeK/ZK0pQwlXDAqJeM0BSf6mS6pW1c8LqRr 6S7vJ2KsQ8QuO87uBHM+e4eB7LEUOTXcN16fOrH0Agm9+qFX3xSEDGP2pMKlflwOxr mTVZu06W/sfBgxLfTM2x48BScMFuq/3f82mdodXA=
To: "tls@ietf.org" 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie>
Date: Sat, 22 Oct 2016 15:30:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020602070608080304090200"
Archived-At: 
Subject: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01
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: Sat, 22 Oct 2016 14:30:13 -0000

This is a cryptographically signed message in MIME format.

--------------ms020602070608080304090200
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi all,

Sean and Joe wrote up this IANA registry draft as per
discussions at WG meetings and on the list. As they've
done the initial work, but are WG chairs, they wanted
me (as responsible AD) to call consensus for it. (They
wrote this up as finding authors for such fairly boring
stuff was hard - thank them for taking one for us all
when you see 'em:-)

Based on the earlier discussions and limited mails on
this draft, I do think there's consensus to adopt this
approach and that the text in the I-D [1] is a good
enough starting point for the WG.

If you think otherwise, please comment to the list in
the next week.

If you've questions about all this from a process-crap
POV, feel free to ask those on or off the list as you
think appropriate;-)

Note that if this is adopted as a WG item, the chairs
might decide to continue as editors or recruit someone
else. In the former case, I'm fine with doing the WGLC
stuff when this is ready (which it nearly is IMO, so
there may or may not be a need for new authors, depends
on what the WG think of the text I'd guess).

Cheers,
S.



[1] https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01


--------------ms020602070608080304090200
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMjIx
NDMwMDhaMC8GCSqGSIb3DQEJBDEiBCB/dBjC7VO4dgHfBOi1pV+07ZtsQi+Y0LePMqO0SZj2
tjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBGOx9YsVIQGXc8bzk030YhBSGmBOFmm6hh5wPGDnchXCgeLBytiFox
QJedknXzO+TR2at5r6Fi+HBuicHKuXzdr2Up4smQBF2qIxAZuN7KeqvmJ+x/gJAxO5Pe+JMk
NXrN4iqRLfhV1T4q9uqJTWOXcN9rCeGHj29ttJDOD/Ji7Hlx6KFa3506irmTrsMdefVX2jgR
KNxEGnVne9Ldxg64vL0aYo12Njb+vF4yGzIHgdkXS3eRXGzCfM4iYuzVTO6leqwaSjLqAdqh
FwqjS51Ros/ZJEcYMDUYZXJrPO3OgotVrrrzQ4v2c5xI7p/hpvpID3id4QNOPPVCF24r0jdn
AAAAAAAA
--------------ms020602070608080304090200--


From nobody Sat Oct 22 08:26:43 2016
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 A401E12948E for ; Sat, 22 Oct 2016 08:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 vPiFEbS3Qk5s for ; Sat, 22 Oct 2016 08:26:39 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF95F12954F for ; Sat, 22 Oct 2016 08:26:39 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id 191so52808656ybv.3 for ; Sat, 22 Oct 2016 08:26:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eOnE1jZe9mFLDR1mtbfpy38UAl83ylJHcGuz0/4INm8=; b=C7XfD6eN262A4iSXTTV/2RQupDpV4DR4O1QaqJh/VIxe5mbkpAdg1KxaoNI20YQeVT vmjRXJlRrm55pblEQDfl4ATwOmM3nLtlCBJcnXo8we4pDOvk2O2qu6Bp8E3xWWaJwX4W d2JC5IHjuLtXkJZaVqwC8pwcFKA19sYadpIBTUidiLY3f/e5yjtzLi//Wt0BA9cJ2Oet 3FF0409D8vlkzTfiyE2eXyRNRuek9Pu43FK1atwwnq6aBxZtCnsosNhDQXu8AgPTbIQb st1mEUOUADIOkin/mFG6buKeU42ngmhltT5Qnq5Bm8ej+cW1JO/A+f51yDdHkQ9HD9Cm rR0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eOnE1jZe9mFLDR1mtbfpy38UAl83ylJHcGuz0/4INm8=; b=bE7ay/x4rthTLPZI+/lPhEG7DVNpTUoa3zoao1RuO24N4E2223mJjDglCZyMGshNZj LDNnv26x2OD1hOi+93XfFhPZsmmZwiIP8IJLroNz/iI3GVGHLV4d2gYKG5fcjx49OoyK rxhKw+LFtVGQ6AlppCvJ9TSOXvt6g/0EHlmWZifF5lG+TWh3fKMcGjv7aJUOtpCPnTt/ beZsZAGR332XiW6+31l7XW8VdncjvM8WV7/vZLfpdQFYojjr9O7+65guzjGGU7sjfAs1 eP2yvPbaWSYGpl+vmQ5kySjJAbfIv/Yl/0w8YkrsC7ILaeXdH66EkjRabNOfcCMf80rD RM+Q==
X-Gm-Message-State: ABUngveRQroHwAWafRsPTGKi41jl3w085vQTPnTjGDbYGusj7ZnS1YwzzczYFJkL9c3+yeoyC3wIBz/BZexmsQ==
X-Received: by 10.37.246.15 with SMTP id t15mr7146334ybd.107.1477149998901; Sat, 22 Oct 2016 08:26:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Sat, 22 Oct 2016 08:25:58 -0700 (PDT)
In-Reply-To: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie>
References: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie>
From: Eric Rescorla 
Date: Sat, 22 Oct 2016 08:25:58 -0700
Message-ID: 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=f403045da0a6f731a7053f75c85b
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01
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: Sat, 22 Oct 2016 15:26:41 -0000

--f403045da0a6f731a7053f75c85b
Content-Type: text/plain; charset=UTF-8

+1

This draft just codifies stuff that we had already agreed on but had been
awkwardly stuffed in TLS 1.3. Having it separate is an improvement.

-Ekr




On Sat, Oct 22, 2016 at 7:30 AM, Stephen Farrell 
wrote:

>
> Hi all,
>
> Sean and Joe wrote up this IANA registry draft as per
> discussions at WG meetings and on the list. As they've
> done the initial work, but are WG chairs, they wanted
> me (as responsible AD) to call consensus for it. (They
> wrote this up as finding authors for such fairly boring
> stuff was hard - thank them for taking one for us all
> when you see 'em:-)
>
> Based on the earlier discussions and limited mails on
> this draft, I do think there's consensus to adopt this
> approach and that the text in the I-D [1] is a good
> enough starting point for the WG.
>
> If you think otherwise, please comment to the list in
> the next week.
>
> If you've questions about all this from a process-crap
> POV, feel free to ask those on or off the list as you
> think appropriate;-)
>
> Note that if this is adopted as a WG item, the chairs
> might decide to continue as editors or recruit someone
> else. In the former case, I'm fine with doing the WGLC
> stuff when this is ready (which it nearly is IMO, so
> there may or may not be a need for new authors, depends
> on what the WG think of the text I'd guess).
>
> Cheers,
> S.
>
>
>
> [1] https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--f403045da0a6f731a7053f75c85b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1

This draft just codifies stuff that =
we had already agreed on but had been awkwardly stuffed in TLS 1.3. Having =
it separate is an improvement.

-Ekr

=




On Sat, Oct 22, 2016 at 7:30 AM, Stephen Farrell <=
span dir=3D"ltr"><stephen.farrell@cs.tcd.ie> wrote:


Hi all,



Sean and Joe wrote up this IANA registry draft as per

discussions at WG meetings and on the list. As they've

done the initial work, but are WG chairs, they wanted

me (as responsible AD) to call consensus for it. (They

wrote this up as finding authors for such fairly boring

stuff was hard - thank them for taking one for us all

when you see 'em:-)



Based on the earlier discussions and limited mails on

this draft, I do think there's consensus to adopt this

approach and that the text in the I-D [1] is a good

enough starting point for the WG.



If you think otherwise, please comment to the list in

the next week.



If you've questions about all this from a process-crap

POV, feel free to ask those on or off the list as you

think appropriate;-)



Note that if this is adopted as a WG item, the chairs

might decide to continue as editors or recruit someone

else. In the former case, I'm fine with doing the WGLC

stuff when this is ready (which it nearly is IMO, so

there may or may not be a need for new authors, depends

on what the WG think of the text I'd guess).



Cheers,

S.







[1] https://tools.ietf.org/html/=
draft-sandj-tls-iana-registry-updates-01




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--f403045da0a6f731a7053f75c85b--


From nobody Sat Oct 22 10:02:01 2016
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 17CD9129592 for ; Sat, 22 Oct 2016 10:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 6jP6zxanw61R for ; Sat, 22 Oct 2016 10:01:58 -0700 (PDT)
Received: from COL004-OMC1S13.hotmail.com (col004-omc1s13.hotmail.com [65.55.34.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C969129629 for ; Sat, 22 Oct 2016 10:01:58 -0700 (PDT)
Received: from NAM04-BN3-obe.outbound.protection.outlook.com ([65.55.34.9]) by COL004-OMC1S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 22 Oct 2016 10:01:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jTJ7gyrBekHZc7kRIHN8DobJi1gMaHbt4TBfl9XBX1w=; b=rJwr8fobf7aRwqccoelazGjNAfq4BqQ4ZFKBa96k0gZDMl7fJ1GOtWgGnyi9iLPqkxRFkyWCF+Gkeq2brlzvK6cTA0uLd/ABTiJ6fD2PDhFvWs8Eo6TKZj1lNVxFVVBuq/+FDPTEJPcR729djcHaYq8pRIr8AMjkQYKpzQfbQR87MGLKHMBgZlIr52wT0ZcSmMEPC4ttYiguLdkDg2jZphxeE7Dzmty3cNDjyzJqtV6TbChjuu0SNGucKw5QmEN3oMccX956UAbuadbQIslEdAhNBkIzjj01auN8nHC6/BngDasxEiM2G9q4fjYuq+XiS2EEkvZGNqPaMpMwNkHAig==
Received: from CO1NAM04FT013.eop-NAM04.prod.protection.outlook.com (10.152.90.55) by CO1NAM04HT031.eop-NAM04.prod.protection.outlook.com (10.152.91.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.7; Sat, 22 Oct 2016 17:01:56 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.90.58) by CO1NAM04FT013.mail.protection.outlook.com (10.152.91.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.7 via Frontend Transport; Sat, 22 Oct 2016 17:01:56 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0659.028; Sat, 22 Oct 2016 17:01:55 +0000
From: Xiaoyin Liu 
To: Eric Rescorla , Stephen Farrell 
Thread-Topic: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01
Thread-Index: AQHSLHDTM8hO4pLxCEKXX0VMdeg4faC0mEsAgAAazUU=
Date: Sat, 22 Oct 2016 17:01:55 +0000
Message-ID: 
References: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=outlook.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [yOqOqDG+x/Vw6mjzVqgb+1qZ5x0+w7lD]
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; CO1NAM04HT031; 6:I4t3aQVlkchMEO2f00dPeWm1O/CA6uteT4xwJA1N3Qv4kGIBqmoP89mEkGhPyNU8t2xiYgmfAz721+YADWoqx5zkwnDiXXZfGfCDBaMgtvjtJKuh2RYsR4kp9deyzMu9Qjr+5bfoVELS3XrG62gq5f0HInvZlaGPaJKB2EZ2rkUn6FUX2GQSHMdOGskbWpIWdO0lcdgLy/wS0XC8NXakmgdO5H6Ri9g9/ii1ClaV087414txx0dm5NKbnYaiJ0RoUWIHxc9fvNxTSWrE2uUeZBTeOMoFnzhMDFKxRFuHDbzraCAK22G5O0ycH9Vhgqen; 5:Oy0Q64KcaDPW/5XO9Q5PuqqcRVRWfUm5T8ddAWyX8Cg61k4z0lhpok4CFwADpSUFGM0BBOMxsrfc+JzefEu2oV+AJzlwSCtBJH04Ayz9cAb8nTAdnyv2Bog5GBdpPQW3UNWtPQ7RwjwR7Q4FcjEYtw==; 24:1tqlz042j5YYunT/tt+CrEhpHziqqljtMguBQm2hFCxTgvRwSE/xKldjzDV49xpUY45NUykfefzzuv/dkDkX8iU1ESFLzJDoT+0ZQ/9DP8o=; 7:wYIk1ENAxSzpVF4rBnO3deN23GWt+XAe7Cdzx3NCOrpxOhSKnNhcxGDo34+YrjwFEudo/WE0R4sdddyjZ01WuqBU+KHMjnkrVbJQkHfUBOmE5odkN6/qBDsTljzGKBMrHSbOxIW+nbUz1nui6TSwJSUD4vf4H7KpwERXb2gQGcV7oMcDX1evOD6yHLjiFYf5tIAAfdszSr4CfqSSHpB8ffZUUTTYE+MWf23fc3DA0pdA9L0wm7130bflztJYa+Vf3BxUDwEpm2kTbWZ47w7kbAZEsxJlS8O34ZXgTOqSNrIxAJwbz09DlbEM74TaJaoodrh2gGDWivBupdj2lNdw8EekfJHtc93Q7TXhe/SJPqs=
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM04HT031; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; 
x-ms-office365-filtering-correlation-id: b7c9e13a-57b3-40fa-7e54-08d3fa9d20db
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1603101337)(1601125047); SRVR:CO1NAM04HT031; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CO1NAM04HT031; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT031; 
x-forefront-prvs: 01039C93E4
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778458060E6DE7CDC085127FFD70CY1PR15MB0778namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2016 17:01:55.6295 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT031
X-OriginalArrivalTime: 22 Oct 2016 17:01:57.0920 (UTC) FILETIME=[FFB09200:01D22C85]
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01
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: Sat, 22 Oct 2016 17:02:00 -0000

--_000_CY1PR15MB0778458060E6DE7CDC085127FFD70CY1PR15MB0778namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1

Xiaoyin

From: Eric Rescorla
Sent: Saturday, October 22, 2016 11:26 AM
To: Stephen Farrell
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

+1

This draft just codifies stuff that we had already agreed on but had been a=
wkwardly stuffed in TLS 1.3. Having it separate is an improvement.

-Ekr




On Sat, Oct 22, 2016 at 7:30 AM, Stephen Farrell > wrote:

Hi all,

Sean and Joe wrote up this IANA registry draft as per
discussions at WG meetings and on the list. As they've
done the initial work, but are WG chairs, they wanted
me (as responsible AD) to call consensus for it. (They
wrote this up as finding authors for such fairly boring
stuff was hard - thank them for taking one for us all
when you see 'em:-)

Based on the earlier discussions and limited mails on
this draft, I do think there's consensus to adopt this
approach and that the text in the I-D [1] is a good
enough starting point for the WG.

If you think otherwise, please comment to the list in
the next week.

If you've questions about all this from a process-crap
POV, feel free to ask those on or off the list as you
think appropriate;-)

Note that if this is adopted as a WG item, the chairs
might decide to continue as editors or recruit someone
else. In the former case, I'm fine with doing the WGLC
stuff when this is ready (which it nearly is IMO, so
there may or may not be a need for new authors, depends
on what the WG think of the text I'd guess).

Cheers,
S.



[1] https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01


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



--_000_CY1PR15MB0778458060E6DE7CDC085127FFD70CY1PR15MB0778namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable












+1


 


Xiaoyin


 




From: Eric Rescorla

Sent: Saturday, October 22, 2016 11:26 AM

To: Stephen Farrell=


Cc: tls@ietf.org

Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-upda=
tes-01




 






+1






This draft just codifies stuff that we had already agreed on but had b=
een awkwardly stuffed in TLS 1.3. Having it separate is an improvement.






-Ekr






















On Sat, Oct 22, 2016 at 7:30 AM, Stephen Farrell=
 
<stephen.=
farrell@cs.tcd.ie> wrote:





Hi all,



Sean and Joe wrote up this IANA registry draft as per

discussions at WG meetings and on the list. As they've

done the initial work, but are WG chairs, they wanted

me (as responsible AD) to call consensus for it. (They

wrote this up as finding authors for such fairly boring

stuff was hard - thank them for taking one for us all

when you see 'em:-)



Based on the earlier discussions and limited mails on

this draft, I do think there's consensus to adopt this

approach and that the text in the I-D [1] is a good

enough starting point for the WG.



If you think otherwise, please comment to the list in

the next week.



If you've questions about all this from a process-crap

POV, feel free to ask those on or off the list as you

think appropriate;-)



Note that if this is adopted as a WG item, the chairs

might decide to continue as editors or recruit someone

else. In the former case, I'm fine with doing the WGLC

stuff when this is ready (which it nearly is IMO, so

there may or may not be a need for new authors, depends

on what the WG think of the text I'd guess).



Cheers,

S.







[1] 
https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates=
-01





_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls
















--_000_CY1PR15MB0778458060E6DE7CDC085127FFD70CY1PR15MB0778namp_--


From nobody Sun Oct 23 08:14:05 2016
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 B947C129659 for ; Sun, 23 Oct 2016 08:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 3LcnE7ZfRm3b for ; Sun, 23 Oct 2016 08:14:02 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B58312956D for ; Sun, 23 Oct 2016 08:14:02 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id s49so114569685qta.0 for ; Sun, 23 Oct 2016 08:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=WPSYee37YOPaDku/gj1HjNxio0sRAkmqM49ckFy9yq4=; b=VpCVzokJ8d3HBVcgmIG5srVVmm2kon86h4XOkYk3G8e7RQpghb2hdujqvW5zQ3Zi1B rRsOrjW7cf2753RvT/K4hY+prcWxsLGy0t8CBO3K9mnn93UDcrvY8MVI3C7q1Y4ntQZm Upv59ngktwDd5JF4n3oE2t+44k1SoZ/txPeHY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=WPSYee37YOPaDku/gj1HjNxio0sRAkmqM49ckFy9yq4=; b=FxtcDYRe0WnjONjp4jqEytCtBL55Z3ywpkg04BYc4xyVgGHyGm3lmjRZObImmlfQLg H0SAy00YkGWrjy/D6N+QNhcoet00ujR7hlpxbx1aMwWtHhtzozzSYMtpo3aGyAUIfaMY P03AFBZzx94qr/ZmZpCVO07tbqMTcZ67ossobwJknEmmizCIxzTnna189mgFzVQVhYb5 hwwxIjnzqjd4q7kZtrV8oH3f5f5p/m3qtnaH7WsVWThzUe9EKVkWoayWdf7ow6htRmlj Le0dDSdHppnviXgLte6kLDQoht9+FGmCH7qQ7jqQZuxd6cTHvzK7XKbkT3obPArYQiIl x9FA==
X-Gm-Message-State: ABUngvf6sFDlkKvSAqrfe3+F+0rYtJpdmjD5LRObj4N727UOHZocguiKYcJj1ZZOHvTs/g==
X-Received: by 10.200.33.184 with SMTP id 53mr11303768qty.17.1477235641010; Sun, 23 Oct 2016 08:14:01 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id d20sm6282257qtb.41.2016.10.23.08.13.59 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 23 Oct 2016 08:14:00 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Sun, 23 Oct 2016 11:13:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [TLS] Call for agenda items @ IETF 97
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: Sun, 23 Oct 2016 15:14:04 -0000

The final IETF 97 agenda is out:
https://datatracker.ietf.org/meeting/97/agenda.html

Please note that there are TWO tls sessions:
1. Tuesday @ 15:50-18:20 in Park Ballroom 1
2. Friday @ 09:30-1130 in Grand Ballroom 2

spt

> On Oct 18, 2016, at 14:07, Sean Turner  wrote:
>=20
> The preliminary IETF 97 agenda is out: =
https://datatracker.ietf.org/meeting/97/agenda.html.  We=E2=80=99re =
currently scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1.
>=20
> Please send in agenda requests.  But, please note that TLS 1.3-related =
issues and WG drafts will be given a priority during the sessions.  =
We=E2=80=99re also going to give preferential treatment to drafts that =
generated discussion on the list.
>=20
> Cheers,
>=20
> J&S


From nobody Sun Oct 23 09:34:17 2016
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 CF2B012944C for ; Sun, 23 Oct 2016 09:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 WYoFOBWw8cWq for ; Sun, 23 Oct 2016 09:34:14 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C8C129411 for ; Sun, 23 Oct 2016 09:34:13 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id z190so208301462qkc.2 for ; Sun, 23 Oct 2016 09:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=CyLqlbISrrph3E/bGKFqktqikxSwgJ7T8jv1BBCAnJU=; b=QyCIjHy9NzxlYdOHOicQ2Iq5tNYA964kjA9xEwSI7lP6Ug9AXzTWI+LrbHlexcJV0a ppywxGAozhuspesxy7tkRSGX9LGChby9eUZL4s8xRYZ0FWFHqNFkSeD+WlQsOMunXaEu xJxngsuvb+g3b84l2sMc/tpcbBvtdrh8zYdXQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=CyLqlbISrrph3E/bGKFqktqikxSwgJ7T8jv1BBCAnJU=; b=emf+/lvV+bl89SlFdFTfB80cNwLeOP/Qid2ct9dfvDN7wdILqypkDxwWpHhay6KeN4 oaKmVGvGhihphz3LIp+FF2GI6g6ephAEYCGTzdwtckd32Sm55JqxJK4Wgm0PzzskhGv+ daiDCl8fK29zO+8F7ND2VdIi97mLuxtf7fA1A1qMuGWi5V7usIuelQ09o7rwmXZjLqb8 bnfRajhN6Q3vCjOuG0h3aekFWjdl5It3Z2VasEmiHzZLBOhQuGrdsOIhgiDMxb5Fjo0I jCp2duxAqq7KfGzIO0iU91pJiVr8vjqkNBmFZSX2YaFxpX9PgFj480zKymH62hDsDTOm p9RA==
X-Gm-Message-State: ABUngvfLe5z5NZJhWuyJ/Pc1o1HyBLfAVcbVw3YtMPUT8WORp8+2mKRU2Jvmt/titqijwA==
X-Received: by 10.55.154.11 with SMTP id c11mr10517871qke.25.1477240452638; Sun, 23 Oct 2016 09:34:12 -0700 (PDT)
Received: from [172.16.0.112] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id f79sm6445989qke.6.2016.10.23.09.34.11 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 23 Oct 2016 09:34:11 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie>
Date: Sun, 23 Oct 2016 12:34:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <41681B91-595E-4824-B2D4-F2942DD65733@sn3rd.com>
References: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie>
To: "tls@ietf.org" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01
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: Sun, 23 Oct 2016 16:34:16 -0000

Note that I hope that we don=E2=80=99t need to present in Korea.  My =
opinion is that this process mumbo jumbo is important (to some), but I =
don=E2=80=99t think it should occupy the group=E2=80=99s f2f time.  But, =
it still needs review so please do and provide comments either here or =
via a PR.

spt

> On Oct 22, 2016, at 10:30, Stephen Farrell  =
wrote:
>=20
>=20
> Hi all,
>=20
> Sean and Joe wrote up this IANA registry draft as per
> discussions at WG meetings and on the list. As they've
> done the initial work, but are WG chairs, they wanted
> me (as responsible AD) to call consensus for it. (They
> wrote this up as finding authors for such fairly boring
> stuff was hard - thank them for taking one for us all
> when you see 'em:-)
>=20
> Based on the earlier discussions and limited mails on
> this draft, I do think there's consensus to adopt this
> approach and that the text in the I-D [1] is a good
> enough starting point for the WG.
>=20
> If you think otherwise, please comment to the list in
> the next week.
>=20
> If you've questions about all this from a process-crap
> POV, feel free to ask those on or off the list as you
> think appropriate;-)
>=20
> Note that if this is adopted as a WG item, the chairs
> might decide to continue as editors or recruit someone
> else. In the former case, I'm fine with doing the WGLC
> stuff when this is ready (which it nearly is IMO, so
> there may or may not be a need for new authors, depends
> on what the WG think of the text I'd guess).
>=20
> Cheers,
> S.
>=20
>=20
>=20
> [1] =
https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Sun Oct 23 18:50:44 2016
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 648711293DF for ; Sun, 23 Oct 2016 18:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 A_b5SAPCuyMy for ; Sun, 23 Oct 2016 18:50:25 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2037512948B for ; Sun, 23 Oct 2016 18:50:25 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id q7so120234347qtq.1 for ; Sun, 23 Oct 2016 18:50:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8Pikb9KGlaMrwPO8z0VLK5avfFP0semyvBmd8jo0poo=; b=IiFHo/SuQb1Z8tqnOmFHTW+6Wqew8/S9AvCPS9y526SMA7R4IG+k1MnvhDWOvDELcm Z/wfm7vK0DIEsuQCmfCh3KNnPhQjKy05H+OeBtyf83symXKZWQWQBtfoxJ7s2UQ6HXd6 YaqB6ykOlo1bNqpuwmgmVzQHUNvnt291Pd/wYCAbIRSdcDSlVajIzgar78muLbO3WALY 2a/Ss+kEBAk5qLYFPIBOtkHys39iFDPuguIrRsTAgnVRUY0+Q/zBLda9Or1wLu4QXTwz PQK0+fXIdP4iWHz9urRbonuanRqAwd6S8+CykdLF/FvEVXnvpv+Oskze4xSj+kRU6wrf zB2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8Pikb9KGlaMrwPO8z0VLK5avfFP0semyvBmd8jo0poo=; b=cmIXeTZD3ORICAkRRfMc+Ivf4nZmGsRpR9Ng4DI1oq/uhbz9BpELLW73CxKmwBPy/o hr8DTL5CfQQwzgZSzjWTZQ5EXxJ4Q9eTl0gM77VINgt5gsg+137qRcOms69i5uwKmr/L LvNstWkRenHebSsjcl5KjWyjNN6gt1Tv/RZ7W1i02JPGXH8dHbzCXIFXzHTIkb5HWAbr QMs0YhSX14ziPbvRH64Six+llgC0fjKC+wl06o797IpgSWP1CYtTSiTaoAMNZ2eTMV3u hShRPofVHzfHQG1QDaqHuGW6FKBXZVJGG7kqPgHvKdlytRdDlozgGtBFS8+qvZsFIlbX +XEQ==
X-Gm-Message-State: ABUngvf/qoJSG/Dhd/03vmNdD5U5CXO+2BHUSYS4JDOERmY4yK65s020YcUoroHpOFcUscskU8wK3XdQb23QkA==
X-Received: by 10.200.45.170 with SMTP id p39mr13119151qta.32.1477273824265; Sun, 23 Oct 2016 18:50:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Sun, 23 Oct 2016 18:50:23 -0700 (PDT)
Received: by 10.140.85.7 with HTTP; Sun, 23 Oct 2016 18:50:23 -0700 (PDT)
In-Reply-To: <41681B91-595E-4824-B2D4-F2942DD65733@sn3rd.com>
References: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie> <41681B91-595E-4824-B2D4-F2942DD65733@sn3rd.com>
From: Martin Thomson 
Date: Mon, 24 Oct 2016 12:50:23 +1100
Message-ID: 
To: Sean Turner 
Content-Type: multipart/alternative; boundary=001a11c02c56880d68053f929de4
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01
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: Mon, 24 Oct 2016 01:50:42 -0000

--001a11c02c56880d68053f929de4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good plan. I support publishing this doc.

(I haven't reviewed this recently, but will commit to do so.)

On 24 Oct 2016 3:34 AM, "Sean Turner"  wrote:

> Note that I hope that we don=E2=80=99t need to present in Korea.  My opin=
ion is
> that this process mumbo jumbo is important (to some), but I don=E2=80=99t=
 think it
> should occupy the group=E2=80=99s f2f time.  But, it still needs review s=
o please
> do and provide comments either here or via a PR.
>
> spt
>
> > On Oct 22, 2016, at 10:30, Stephen Farrell 
> wrote:
> >
> >
> > Hi all,
> >
> > Sean and Joe wrote up this IANA registry draft as per
> > discussions at WG meetings and on the list. As they've
> > done the initial work, but are WG chairs, they wanted
> > me (as responsible AD) to call consensus for it. (They
> > wrote this up as finding authors for such fairly boring
> > stuff was hard - thank them for taking one for us all
> > when you see 'em:-)
> >
> > Based on the earlier discussions and limited mails on
> > this draft, I do think there's consensus to adopt this
> > approach and that the text in the I-D [1] is a good
> > enough starting point for the WG.
> >
> > If you think otherwise, please comment to the list in
> > the next week.
> >
> > If you've questions about all this from a process-crap
> > POV, feel free to ask those on or off the list as you
> > think appropriate;-)
> >
> > Note that if this is adopted as a WG item, the chairs
> > might decide to continue as editors or recruit someone
> > else. In the former case, I'm fine with doing the WGLC
> > stuff when this is ready (which it nearly is IMO, so
> > there may or may not be a need for new authors, depends
> > on what the WG think of the text I'd guess).
> >
> > Cheers,
> > S.
> >
> >
> >
> > [1] https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-0=
1
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a11c02c56880d68053f929de4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Good plan. I support publishing this doc.


(I haven't reviewed this recently, but will commit to do=
 so.) 



On 24 Oct 2016 3:=
34 AM, "Sean Turner" <sean@s=
n3rd.com> wrote:
Note that I hope that we don=E2=80=99t need to present in Korea.=C2=A0 =
My opinion is that this process mumbo jumbo is important (to some), but I d=
on=E2=80=99t think it should occupy the group=E2=80=99s f2f time.=C2=A0 But=
, it still needs review so please do and provide comments either here or vi=
a a PR.



spt



> On Oct 22, 2016, at 10:30, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

>

>

> Hi all,

>

> Sean and Joe wrote up this IANA registry draft as per

> discussions at WG meetings and on the list. As they've

> done the initial work, but are WG chairs, they wanted

> me (as responsible AD) to call consensus for it. (They

> wrote this up as finding authors for such fairly boring

> stuff was hard - thank them for taking one for us all

> when you see 'em:-)

>

> Based on the earlier discussions and limited mails on

> this draft, I do think there's consensus to adopt this

> approach and that the text in the I-D [1] is a good

> enough starting point for the WG.

>

> If you think otherwise, please comment to the list in

> the next week.

>

> If you've questions about all this from a process-crap

> POV, feel free to ask those on or off the list as you

> think appropriate;-)

>

> Note that if this is adopted as a WG item, the chairs

> might decide to continue as editors or recruit someone

> else. In the former case, I'm fine with doing the WGLC

> stuff when this is ready (which it nearly is IMO, so

> there may or may not be a need for new authors, depends

> on what the WG think of the text I'd guess).

>

> Cheers,

> S.

>

>

>

> [1] https://tools.ietf.org/=
html/draft-sandj-tls-iana-registry-updates-01

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--001a11c02c56880d68053f929de4--


From nobody Mon Oct 24 08:22:13 2016
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 793A4129879 for ; Mon, 24 Oct 2016 08:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 42bnKP6pjGhv for ; Mon, 24 Oct 2016 08:22:08 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDBB129876 for ; Mon, 24 Oct 2016 08:22:08 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id t193so192695519ywc.2 for ; Mon, 24 Oct 2016 08:22:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jFQCtGUMCa8pRgx9/texZf5o+z3ZtrVdpkFLIkR/l2k=; b=pLSO0f/XkHHlcJCfzJzJ/jiBdhdiytQc9EdxVpeXizOa7VYr9U/Z8GyADBm31ZaMv/ Rdmm49jlBTXi9vEOpCLmVHY+QvuEUWQafUlHCOasqW4ZYa0p/wQ6gvDaO1Exwt5fjXLf kg+/RYkKbzZF74cNjEGxOSjezp64FIbRkpAndUPO78k/5XYGDA7+plawKxFn4nKfEbpQ 8IbCdCy4SAuSPMmSOSQct1yvBhiDllmaxK208vqxOM9NUAeD+lKwhImHzHxh8+NUuofN uO8Rjd79mSpU5jrVVvQ36yHz+xEiMurgxHwV50LNQ3EzTNkOeUuKx6VHjeGnJGCQjGs3 0/Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jFQCtGUMCa8pRgx9/texZf5o+z3ZtrVdpkFLIkR/l2k=; b=KczATIuocHR6YgCdUQoOj0xnPP1hlWekg4kqqfEvY7sQeHNwOCrvgzS85usJ3hK0ss paHfxjeEJu6q6mXvVjcXN7rO10K72InLAW2I/NxfEz2MNYnGELFl3RWgvcJMhTK7ddUg tN/JdDUD6ru7ND71uvrujU354e1qP3zDdPgt/Cp7yLAF4IPlm2E0YCQ1kef53Ffaur4B 4A9j9/gkxjz0fuToB3l9E/7zn46PDUr0QvZ28Hrnn5sspggCtPcK1BBw5ABxy7NQpHs4 6eySu1RqtoSz4Rjku6/Sh2nsxKI8n6JSkzwavFQM78orrO6fiNed/xOJk6prrteHsAE3 F4Nw==
X-Gm-Message-State: ABUngvfjdnI9t8a17ph70EC6kmbfkla8ONZGy7M3MVoYSNrWmqGGy4gfrTnaoaUWGtjsaYuDZHd6Xk1vcJxodw==
X-Received: by 10.107.164.103 with SMTP id n100mr12873717ioe.35.1477322527335;  Mon, 24 Oct 2016 08:22:07 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.188.4 with HTTP; Mon, 24 Oct 2016 08:22:06 -0700 (PDT)
In-Reply-To: 
References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net>  
From: Daniel Migault 
Date: Mon, 24 Oct 2016 11:22:06 -0400
X-Google-Sender-Auth: XRqXwGt9PD180LuOwCuNdvj9t1M
Message-ID: 
To: John Mattsson 
Content-Type: multipart/alternative; boundary=001a1141c95675efdd053f9df42a
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt
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: Mon, 24 Oct 2016 15:22:12 -0000

--001a1141c95675efdd053f9df42a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

My understanding is that the updated version should not introduce any
profile. Am I correct ?

BR,
Daniel

On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault  wrote:

> Hi,
>
> I am not very clear on how to update the text of the draft. The problem
> seems to me that code point restriction are hard to implement. As a resul=
t,
> the session is aborted with - insufficient_security(71) or equivalent -
> when the code point does not match the security strength. I am encline to
> think that we should also provide some profiles that achieve 128/256 bit
> security. These profiles may be described in this document or in another
> document more related to cryptographic recommendation. What would be the
> most appropriated way to move forward ?
>
> BR,
> Daniel
>
>
>
> On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson 
> wrote:
>
>> Hi Dan, Sean, Nikos,
>>
>> First, let me state that I think requiring 128-bit key management for
>> AES-128 is quite reasonable.
>>
>> HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applie=
s
>> when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key siz=
es
>> smaller than the lower limits as a connection error (Section 5.4.1
>> ) of type
>> INADEQUATE_SECURITY."
>>
>>
>> I think this is a question for TLS in general,
>> draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides
>> as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups
>> with insufficient security as an error.
>>
>> I think the real problem here are TLS libraries supporting 1024 MODP and
>> 160 ECC at all, support for these should have been removed before 2010.
>> Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
>> (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better
>> than bundling it into a code-point assignment RFC. (My current plans for
>> the next update of 3GPP=E2=80=99s TLS and DTLS profiles is simply to for=
bid
>> support of anything weaker than 2048 MODP and 255-bit ECC).
>>
>> [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrl
>> BKvZs0BOQ
>>
>>
>>
>> Cheers,
>> John
>>
>>
>> On 11/07/16 22:26, "TLS on behalf of Dan Harkins" > on
>> behalf of dharkins@lounge.org> wrote:
>>
>> >
>> >  I'm glad I have to opportunity to make you happy Sean :-)
>> >
>> >On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
>> >> I think I can take this bit:
>> >>
>> >> On Jul 10, 2016, at 06:51, Peter Dettman
>> >>
>> >> wrote:
>> >>>
>> >>> I'm also curious whether there is a precedent in other RFCs for an
>> >>> explicit minimum curve bits, or perhaps a de facto implementer's rul=
e?
>> >>
>> >> I'd be happy to be wrong here. but to my knowledge no there's not bee=
n
>> >> an explicit minimum for curve bits.  There have however been similar
>> (at
>> >> least in my non-cryptographer mind) for RSA key sizes so if we wanted
>> to
>> >> define an explicit minimum curve bits then we could.
>> >
>> >  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
>> >the curves used provide commensurate strength with the ciphersuite
>> >negotiated. Section 10, "Implementation Considerations", says:
>> >
>> >   It is RECOMMENDED that implementations take note of the strength
>> >   estimates of particular groups and to select a ciphersuite providing
>> >   commensurate security with its hash and encryption algorithms.  A
>> >   ciphersuite whose encryption algorithm has a keylength less than the
>> >   strength estimate, or whose hash algorithm has a blocksize that is
>> >   less than twice the strength estimate SHOULD NOT be used.
>> >
>> >  And I would like to take this opportunity to remind everyone that
>> >the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
>> >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
>> >to dictionary attack and the former is not.
>> >
>> >  regards,
>> >
>> >  Dan.
>> >
>> >
>> >
>> >_______________________________________________
>> >TLS mailing list
>> >TLS@ietf.org
>> >https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>

--001a1141c95675efdd053f9df42a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi, 

My understandi=
ng is that the updated version should not introduce any profile. Am I corre=
ct ?

BR, 
Daniel 

On Mon, Oct 17, 2016 at 1:16 PM, Daniel Mig=
ault <daniel.migault@ericsson.com> wrote:
Hi, 

I am not very clear on how to update the text of the draft. The problem se=
ems to me that code point restriction are hard to implement. As a result, t=
he session is aborted with - insufficient_security(71) or equivalent - when=
 the code point does not match the security strength. I am encline to think=
 that we should also provide some profiles that achieve 128/256 bit securit=
y. These profiles may be described in this document or in another document =
more related to cryptographic recommendation. What would be the most approp=
riated way to move forward ?

BR, 
Daniel



On Sun, Oct 9, 2016 at 2:=
59 AM, John Mattsson <john.mattsson@ericsson.com> w=
rote:
Hi Dan, Sean, Nikos,



First, let me state that I think requiring 128-bit key management for

AES-128 is quite reasonable.



HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies
when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key s=
izes

smaller than the lower limits as a connection error (Section 5.4.1

<https://tools.ietf.org/html/rfc7540#sectio=
n-5.4.1>) of type

INADEQUATE_SECURITY."





I think this is a question for TLS in general,

draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides
as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups
with insufficient security as an error.



I think the real problem here are TLS libraries supporting 1024 MODP and
160 ECC at all, support for these should have been removed before 2010.

Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2

(i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better
than bundling it into a code-point assignment RFC. (My current plans for
the next update of 3GPP=E2=80=99s TLS and DTLS profiles is simply to forbid=


support of anything weaker than 2048 MODP and 255-bit ECC).



[0]. https://mailarchive.ietf.o=
rg/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ







Cheers,

John





On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <tls-bounces@ietf.org on<=
br>

behalf of dha=
rkins@lounge.org> wrote:



>

>=C2=A0 I'm glad I have to opportunity to make you happy Sean :-)
>

>On Mon, July 11, 2016 7:40 am, Sean Turner wrote:

>> I think I can take this bit:

>>

>> On Jul 10, 2016, at 06:51, Peter Dettman

>><peter.dettman@bouncycastle.org>

>> wrote:

>>>

>>> I'm also curious whether there is a precedent in other RFC=
s for an

>>> explicit minimum curve bits, or perhaps a de facto implementer=
's rule?

>>

>> I'd be happy to be wrong here. but to my knowledge no there=
9;s not been

>> an explicit minimum for curve bits.=C2=A0 There have however been =
similar (at

>> least in my non-cryptographer mind) for RSA key sizes so if we wan=
ted to

>> define an explicit minimum curve bits then we could.

>

>=C2=A0 draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensurin=
g

>the curves used provide commensurate strength with the ciphersuite

>negotiated. Section 10, "Implementation Considerations", says=
:

>

>=C2=A0 =C2=A0It is RECOMMENDED that implementations take note of the st=
rength

>=C2=A0 =C2=A0estimates of particular groups and to select a ciphersuite=
 providing

>=C2=A0 =C2=A0commensurate security with its hash and encryption algorit=
hms.=C2=A0 A

>=C2=A0 =C2=A0ciphersuite whose encryption algorithm has a keylength les=
s than the

>=C2=A0 =C2=A0strength estimate, or whose hash algorithm has a blocksize=
 that is

>=C2=A0 =C2=A0less than twice the strength estimate SHOULD NOT be used.<=
br>
>

>=C2=A0 And I would like to take this opportunity to remind everyone tha=
t

>the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256<=
br>
>and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resis=
tant

>to dictionary attack and the former is not.

>

>=C2=A0 regards,

>

>=C2=A0 Dan.

>

>

>

>_______________________________________________

>TLS mailing list

>TLS@ietf.org

>https://www.ietf.org/mailman/listinfo/tls



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls








--001a1141c95675efdd053f9df42a--


From nobody Mon Oct 24 08:54:04 2016
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DA9129957; Mon, 24 Oct 2016 08:53:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147732443920.15435.14765937222814029251.idtracker@ietfa.amsl.com>
Date: Mon, 24 Oct 2016 08:53:59 -0700
Archived-At: 
Cc: tls@ietf.org, ipr-announce@ietf.org
Subject: [TLS] IPR Disclosure Eric Rescorla's Statement about IPR related to draft-ietf-tls-tls13 belonging to Groupe Des Ecoles Des Telecommunications - Ecole Nationale Superieure Des Telecommunications
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 24 Oct 2016 15:53:59 -0000

Dear Eric Rescorla:


An IPR disclosure that pertains to your Internet-Draft entitled "The
Transport Layer Security (TLS) Protocol Version 1.3" (draft-ietf-tls-tls13)
was submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/2900/). The title of the IPR disclosure is
"Eric Rescorla's Statement about IPR related to draft-ietf-tls-tls13
belonging to Groupe Des Ecoles Des Telecommunications - Ecole Nationale
Superieure Des Telecommunications"


Thank you

IETF Secretariat


From nobody Mon Oct 24 08:59:14 2016
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 E78C212996A; Mon, 24 Oct 2016 08:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qHygLhunMrm7; Mon, 24 Oct 2016 08:59:11 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0978B129964; Mon, 24 Oct 2016 08:59:11 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id 14so159961vke.5; Mon, 24 Oct 2016 08:59:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8UiLeke0Oqp/8SNkVRCCiGaugZUuF6wHc4HH0RAITxo=; b=fN09hC5cSSRXr+eqV6VwZhI3AwKQkcUd6TcwHP3DBUenvGQNyBCan2k1o83AfJX/7E EECniM6Xr5N6cM7Pprn75Ghzy9adPrlQ6sYCFa7VUdlGkmIdR0+z34NWXlLmmRkAb9nU j9Ob5C9sNm0JaihFnWh2fR65YIaDZfcGE97SjJKoAOoCcSq3qSnISP+3kiLlvPGKBOkW GS6CgnqZai2RUo4faSWamN7FIZ3rTTYY38u3cEZa0u46eW952OI0b2fSjqlZCnShpd5T +v14T1PU7/0JlPPu0bjgCUQTtvAgbSjE7xPh7x+nW0D46SS+6rcKxWE0JeG8IBgWuteA JUsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8UiLeke0Oqp/8SNkVRCCiGaugZUuF6wHc4HH0RAITxo=; b=AabZzLGgV7kGbkb3D1OE+UkaHpjJWF8MLB8YLEosrhYUMDhf0LRYIdYKcdtAYy6w4X wsWZ7HZ5AAKcQI61+Q1S3e2uOAEZDE0Rv8VMhhQPswpiALPvzGtfz+tIxdYD2DuLbs5j 1V8QT82BnNYJ7E3br5+8ZlEI3DTthCHK05xt40NX2WsgU7eivVzN+HQFbf67ZlwI2rEF ep3kW52SCqmbZ0n8W1Eqtc0tly/TaBGbrQ580oEvYIxoUd4chgtSTNZL6IoVU+wnyQG5 8ajHDOBuWKmZVgkRXuhzhBWrPH/r6fGbu0xcnQk8b3cDpc7iTsarXJ98/6WbsL2smFD6 mvqQ==
X-Gm-Message-State: ABUngvdFbYfbNrUqy0c1a7KfRXXSP7BQK9IJqeTox7JEi6RN8Cf/p78pe+JIHBXcSWWuh7qcTPjh5pDxdY6mXA==
X-Received: by 10.31.67.203 with SMTP id q194mr10234896vka.38.1477324749835; Mon, 24 Oct 2016 08:59:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.85.30 with HTTP; Mon, 24 Oct 2016 08:59:09 -0700 (PDT)
In-Reply-To: <147732443920.15435.14765937222814029251.idtracker@ietfa.amsl.com>
References: <147732443920.15435.14765937222814029251.idtracker@ietfa.amsl.com>
From: Watson Ladd 
Date: Mon, 24 Oct 2016 17:59:09 +0200
Message-ID: 
To: IETF Secretariat 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: draft-ietf-tls-tls13@ietf.org, "tls@ietf.org" , ipr-announce@ietf.org
Subject: Re: [TLS] IPR Disclosure Eric Rescorla's Statement about IPR related to draft-ietf-tls-tls13 belonging to Groupe Des Ecoles Des Telecommunications - Ecole Nationale Superieure Des Telecommunications
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: Mon, 24 Oct 2016 15:59:13 -0000

See also https://tools.ietf.org/html/rfc4306#page-7, published a year
before the priority date of the patent.

On Mon, Oct 24, 2016 at 5:53 PM, IETF Secretariat  wrote:
> Dear Eric Rescorla:
>
>
> An IPR disclosure that pertains to your Internet-Draft entitled "The
> Transport Layer Security (TLS) Protocol Version 1.3" (draft-ietf-tls-tls13)
> was submitted to the IETF Secretariat on  and has been posted on the "IETF Page
> of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/2900/). The title of the IPR disclosure is
> "Eric Rescorla's Statement about IPR related to draft-ietf-tls-tls13
> belonging to Groupe Des Ecoles Des Telecommunications - Ecole Nationale
> Superieure Des Telecommunications"
>
>
> Thank you
>
> IETF Secretariat
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.


From nobody Mon Oct 24 10:13:41 2016
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 411301297BD for ; Mon, 24 Oct 2016 10:13:40 -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, 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_H2=-0.001, 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 zKzcC_Ss_8i1 for ; Mon, 24 Oct 2016 10:13:38 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0121.outbound.protection.outlook.com [104.47.36.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0DCD12944B for ; Mon, 24 Oct 2016 10:13:37 -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=XXBWYqPJKZo+gBKc4wvF0is/H0zKK8yPj9veNJ//J3Y=; b=EtO9inmMyAW2UQEazaHpZJ4Zhl+/4H5yTFdoCYVxxWkktpWGMkUAR9V3HHxq2c0neigIUu9EptKW+SnpGoTMUhrB9m3TDLDax/GS+s8mWUkDpKWdfqpbC63tZ5MbObe05lWmb9k10MsrVQevB+6pt3SKIOeu4ez2Gb4+PaYoGwg=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Mon, 24 Oct 2016 17:13:35 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0649.027; Mon, 24 Oct 2016 17:13:35 +0000
From: Andrei Popov 
To: Xiaoyin Liu , Eric Rescorla , "Stephen Farrell" 
Thread-Topic: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01
Thread-Index: AQHSLHDaWBwLpJvS+kKEBgtLVtl0yKC0mEsAgAAaz4CAAyezAA==
Date: Mon, 24 Oct 2016 17:13:35 +0000
Message-ID: 
References: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie>,  
In-Reply-To: 
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=Andrei.Popov@microsoft.com; 
x-originating-ip: [2001:4898:80e8::1d2]
x-ms-office365-filtering-correlation-id: f09e9dc6-0a15-4eca-4577-08d3fc3116a7
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:PinKcfFy19FCIUdIkTSEjvLtPFWsHI/nSMF8SzqHM/m4nIKGNvgykCVrmvUVTYctkElEeH5yJ5ryLEIJs8VyJkHU72UeNa181hXeCbUD7KdAl1wRAR1gFPLp1d437gZjYrlAJhLGPDnOLmaUkipomB8YoflRAXWxuVuDPON8ZKJSBMFwal57xeEU7SS8Ai4ALYAPHq38xo+/P+oNEgQnDLQF5pQarI8dXLa10DnrbTSR3iqhIovew0Op9PDes7dKtWNCmFtsuE7S7iVbrN53/icszck/mkeL+uZBgLznKiDXhwFY7MNE1gdg/6y9PAMFIZdEtRbm0PbADmfHd1SfT5IcoJ7VCjDEG0fgnE5gyszFCPW6qxgBJ6mhYfJBIpB1
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(32856632585715)(100405760836317)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:(304825118); SRVR:CY1PR0301MB0841; 
x-forefront-prvs: 0105DAA385
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(53754006)(24454002)(199003)(10090500001)(106116001)(7846002)(102836003)(5005710100001)(77096005)(19580395003)(50986999)(15975445007)(3280700002)(33656002)(7736002)(2900100001)(9686002)(7110500001)(19580405001)(230783001)(586003)(76176999)(74316002)(68736007)(105586002)(2906002)(10710500007)(106356001)(54356999)(7906003)(87936001)(97736004)(5001770100001)(6116002)(19300405004)(4326007)(81166006)(8936002)(189998001)(19617315012)(81156014)(7696004)(790700001)(5002640100001)(92566002)(16236675004)(86362001)(3660700001)(10290500002)(86612001)(76576001)(3900700001)(2950100002)(11100500001)(10400500002)(19625215002)(5660300001)(15650500001)(8990500004)(2420400007)(101416001)(8676002)(122556002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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_CY1PR0301MB0842CC0E796B33854E68C9B98CA90CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2016 17:13:35.0842 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01
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: Mon, 24 Oct 2016 17:13:40 -0000

--_000_CY1PR0301MB0842CC0E796B33854E68C9B98CA90CY1PR0301MB0842_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1

Definitely good enough starting point.

Cheers,

Andrei

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Xiaoyin Liu
Sent: Saturday, October 22, 2016 10:02 AM
To: Eric Rescorla ; Stephen Farrell 
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

+1

Xiaoyin

From: Eric Rescorla
Sent: Saturday, October 22, 2016 11:26 AM
To: Stephen Farrell
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

+1

This draft just codifies stuff that we had already agreed on but had been a=
wkwardly stuffed in TLS 1.3. Having it separate is an improvement.

-Ekr




On Sat, Oct 22, 2016 at 7:30 AM, Stephen Farrell > wrote:

Hi all,

Sean and Joe wrote up this IANA registry draft as per
discussions at WG meetings and on the list. As they've
done the initial work, but are WG chairs, they wanted
me (as responsible AD) to call consensus for it. (They
wrote this up as finding authors for such fairly boring
stuff was hard - thank them for taking one for us all
when you see 'em:-)

Based on the earlier discussions and limited mails on
this draft, I do think there's consensus to adopt this
approach and that the text in the I-D [1] is a good
enough starting point for the WG.

If you think otherwise, please comment to the list in
the next week.

If you've questions about all this from a process-crap
POV, feel free to ask those on or off the list as you
think appropriate;-)

Note that if this is adopted as a WG item, the chairs
might decide to continue as editors or recruit someone
else. In the former case, I'm fine with doing the WGLC
stuff when this is ready (which it nearly is IMO, so
there may or may not be a need for new authors, depends
on what the WG think of the text I'd guess).

Cheers,
S.



[1] https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01


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


--_000_CY1PR0301MB0842CC0E796B33854E68C9B98CA90CY1PR0301MB0842_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











+1


 


Definitely good enough starting point.

 


Cheers,


 


Andrei


 






From: TLS [mailto:tls-bounces@ietf.org] On=
 Behalf Of
Xiaoyin Liu

Sent: Saturday, October 22, 2016 10:02 AM

To: Eric Rescorla <ekr@rtfm.com>; Stephen Farrell <stephen.=
farrell@cs.tcd.ie>

Cc: tls@ietf.org

Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-upda=
tes-01






 




+1


 


Xiaoyin


 




From: Eric Re=
scorla

Sent: Saturday, October 22, 2016 11:26 AM

To: Stephen Farrell=


Cc: tls@ietf.org

Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-upda=
tes-01




 








+1





 






This draft just codifies stuff that we had alrea=
dy agreed on but had been awkwardly stuffed in TLS 1.3. Having it separate =
is an improvement.






 






-Ekr






 




 






 










 




On Sat, Oct 22, 2016 at 7:30 AM, Stephen Farrell=
 <stephen=
.farrell@cs.tcd.ie> wrote:






Hi all,



Sean and Joe wrote up this IANA registry draft as per

discussions at WG meetings and on the list. As they've

done the initial work, but are WG chairs, they wanted

me (as responsible AD) to call consensus for it. (They

wrote this up as finding authors for such fairly boring

stuff was hard - thank them for taking one for us all

when you see 'em:-)



Based on the earlier discussions and limited mails on

this draft, I do think there's consensus to adopt this

approach and that the text in the I-D [1] is a good

enough starting point for the WG.



If you think otherwise, please comment to the list in

the next week.



If you've questions about all this from a process-crap

POV, feel free to ask those on or off the list as you

think appropriate;-)



Note that if this is adopted as a WG item, the chairs

might decide to continue as editors or recruit someone

else. In the former case, I'm fine with doing the WGLC

stuff when this is ready (which it nearly is IMO, so

there may or may not be a need for new authors, depends

on what the WG think of the text I'd guess).



Cheers,

S.







[1] 
https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls






 










--_000_CY1PR0301MB0842CC0E796B33854E68C9B98CA90CY1PR0301MB0842_--


From nobody Mon Oct 24 11:11:05 2016
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 5F92E12941A for ; Mon, 24 Oct 2016 11:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 P_9lvxm4lM4P for ; Mon, 24 Oct 2016 11:11:02 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235371293DA for ; Mon, 24 Oct 2016 11:11:02 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id d199so774533wmd.0 for ; Mon, 24 Oct 2016 11:11:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=P7VzkGCaftHtVpDQdhEO0OE0qJLrcYCNaVCtAcnG04o=; b=uC2ov/N/j3Ay2/Tfatybfa6mYB7EPBu6UV2+wH+VDN9oX6w8qsTj9PGLwrI2XN5C+8 yTQv45W++0xvx+jtKbZWjvCrGqeeECPLFZMA5+fpf8N5DbkzsFGAkmw+XfN/yb0HuzaP IzdvpTKHSBzgTpNWqOyR1hA1YKPsF7wHyweUzOk+wtUhsjm6eZvTfGr6Q7hsi5QyztEK jGxZwX5YT4JmuKEoRe23tEZ2yG/y1NLC9OI1lhbHbcWyvhCklXt59n7R8G13KoYm6YBC bUL2XZ52caRCaFtUCndC43/J2mZTsUoyEqxxesqws6Q5vWCDF8q5/jE/Cty2FBF9AFGc 7JBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=P7VzkGCaftHtVpDQdhEO0OE0qJLrcYCNaVCtAcnG04o=; b=W4D+JhVqOYiZfxe0crUg5NWI0jZiL6xDed5oBzY3OMoui5Qsw6Oj9+4VFDgIRBONLr tlO2n1O2vsTiNyTev64XiC+X7OobYVQ409X8fk87JlQnio4UnivjjYU/j6vWspefsrkF xXo96piLs3q2I51TLT1cdcxgxr9oleyjpMsULFmNzxMi2/leAFXWZSxcSYAnurzVTEpc 1IwfFAMhXddE26hC4qhU3Dzc5IJHGlpx8aBEMq0xUH1hr8qeXfXTr0zOtTjgXF9I1Ml+ 4Ms/qmjawFKlVUWW0q1L+iecyK3Sh/aWkgLlR8Wzu0MF5toYjn8wl74hDOCLQQIwrG4t EJvA==
X-Gm-Message-State: ABUngvehJmoMYD0pc/8glws8K69UbGWA+cTjHsfNJKSmzMNL3GCUvzi/ayQZMjIABywMFGy6RyEBI6aNyRsocw==
X-Received: by 10.194.192.197 with SMTP id hi5mr12775937wjc.71.1477332660468;  Mon, 24 Oct 2016 11:11:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.238.199 with HTTP; Mon, 24 Oct 2016 11:10:19 -0700 (PDT)
From: Ryan Carboni 
Date: Mon, 24 Oct 2016 11:10:19 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bb0427671429c053fa05072
Archived-At: 
Subject: [TLS] How should inability to access key revocation lists impact the TLS handshake?
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: Mon, 24 Oct 2016 18:11:03 -0000

--047d7bb0427671429c053fa05072
Content-Type: text/plain; charset=UTF-8

How should inability to access key revocation lists impact the TLS
handshake, if previous public keys and/or certificate hashes are not cached?

I cannot see this in the standard. Considering that all one has to do is
DDOS a certificate authority nowadays...

--047d7bb0427671429c053fa05072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


How should inability to access key revocation lists impact=
 the TLS handshake, if previous public keys and/or certificate hashes are n=
ot cached?

I cannot see this in the standard. Consid=
ering that all one has to do is DDOS a certificate authority nowadays...


--047d7bb0427671429c053fa05072--


From nobody Mon Oct 24 11:15:48 2016
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 94DDC12989D for ; Mon, 24 Oct 2016 11:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.132
X-Spam-Level: 
X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 dRJSPj7IM9zm for ; Mon, 24 Oct 2016 11:15:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 59CE11296EF for ; Mon, 24 Oct 2016 11:15:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 33AC7433463; Mon, 24 Oct 2016 18:15:44 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 0A913433460; Mon, 24 Oct 2016 18:15:44 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1477332944; bh=t5N2+gE9MW0+X62Bn6ep7HHusz+QOLm32PTUpctbeCE=; l=666; h=From:To:Date:References:In-Reply-To:From; b=fJV+cXqDeWX/TMdPfRYqb4AMZTQsMArpLSWaOFdw45zAAhiyHXU6U1jJkNCnkxjKV yxICIz1P7BbQC7gZUPtP9yQImClGC18g/L1VZMOmCluJ93em2/qQxTyz2YP58ouZkM 2/1CW9GEjgf0oAyAQd7YD8i3zgCFuQanwUqbGb40=
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 0798D1FC94; Mon, 24 Oct 2016 18:15:44 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 24 Oct 2016 14:15:43 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 24 Oct 2016 14:15:43 -0400
From: "Salz, Rich" 
To: Ryan Carboni , "tls@ietf.org" 
Thread-Topic: [TLS] How should inability to access key revocation lists impact the TLS handshake?
Thread-Index: AQHSLiH/7WABWV6xekGfUuTjdg73b6C36J/Q
Date: Mon, 24 Oct 2016 18:15:42 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.42.79]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] How should inability to access key revocation lists impact the TLS handshake?
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: Mon, 24 Oct 2016 18:15:46 -0000

PiBIb3cgc2hvdWxkIGluYWJpbGl0eSB0byBhY2Nlc3Mga2V5IHJldm9jYXRpb24gbGlzdHMgaW1w
YWN0IHRoZSBUTFMgaGFuZHNoYWtlLCBpZiBwcmV2aW91cyBwdWJsaWMga2V5cyBhbmQvb3IgY2Vy
dGlmaWNhdGUgaGFzaGVzIGFyZSBub3QgY2FjaGVkPw0KDQpOb2JvZHkgZG9lcyByZXZvY2F0aW9u
IG9uIHRoZSB3ZWIsIGZvciBzb21lIGFsbW9zdCBhbGwgZW5jb21wYXNzaW5nIGRlZmluaXRpb24g
b2Ygbm9ib2R5Lg0KDQpJbnN0ZWFkLCBPQ1NQIGFuZCBPQ1NQIHN0YXBsaW5nLg0KDQo+IEkgY2Fu
bm90IHNlZSB0aGlzIGluIHRoZSBzdGFuZGFyZC4gQ29uc2lkZXJpbmcgdGhhdCBhbGwgb25lIGhh
cyB0byBkbyBpcyBERE9TIGEgY2VydGlmaWNhdGUgYXV0aG9yaXR5IG5vd2FkYXlzLi4uDQoNCkdl
bmVyYWwgUEtJIGFuZCBrZXkgbGlmZWN5Y2xlIGlzc3VlcyBhcmUsIHByb3Blcmx5LCBub3QgcGFy
dCBvZiB0aGUgVExTIHNwZWMuDQoNCgkvciQNCg==


From nobody Mon Oct 24 12:12:33 2016
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 BA1231299C0 for ; Mon, 24 Oct 2016 12:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.018
X-Spam-Level: 
X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 y9_Z6XVuPUFv for ; Mon, 24 Oct 2016 12:12:30 -0700 (PDT)
Received: from BAY004-OMC4S14.hotmail.com (bay004-omc4s14.hotmail.com [65.54.190.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1E21299B4 for ; Mon, 24 Oct 2016 12:12:30 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com ([65.54.190.200]) by BAY004-OMC4S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 24 Oct 2016 12:12:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TaMHLCLg88OOC9lRifj6iOjUA+FGzVXRIf25Jvn5Cck=; b=CdIXu/asGvjHjoYXTmp7sFIrWps4UsiPTntg6h+BrsuUvyhryzmnL+06sSgzsypmUA/qMSv4Ls98HqjjwuylFgWK3UTz3bvITmEglcrRaW7GylfY4KUkmg6KUIxV0feBb+56cuA7KFDp0aav79Kt4gHRqnNmrbM8DPPft4T1a8m8zBBySdC4j+Jg0rEv2tySeNEZKRAIp9fW8lmX9kdSqCcCH3Q10S/muL4hvlZbGSwhqOO+gBdw3rMnFOZQ0onmkYXbnkQ4mXKTXwYV4XcIPNcCgeWyrQr5mItQM5giiqpEdpYh8RxcLmJaykj06N3cuzOK6lvPfdo31/uaakE4mg==
Received: from CO1NAM04FT032.eop-NAM04.prod.protection.outlook.com (10.152.90.58) by CO1NAM04HT204.eop-NAM04.prod.protection.outlook.com (10.152.91.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Mon, 24 Oct 2016 19:12:28 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.90.55) by CO1NAM04FT032.mail.protection.outlook.com (10.152.90.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5 via Frontend Transport; Mon, 24 Oct 2016 19:12:28 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0659.028; Mon, 24 Oct 2016 19:12:28 +0000
From: Xiaoyin Liu 
To: "Salz, Rich" , Ryan Carboni , "tls@ietf.org" 
Thread-Topic: [TLS] How should inability to access key revocation lists impact the TLS handshake?
Thread-Index: AQHSLiIDJviNz/aqz06k2cfULs8chaC36P4AgAAP2pc=
Date: Mon, 24 Oct 2016 19:12:28 +0000
Message-ID: 
References: ,  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=outlook.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [xrZTU4DUMvOUM40g0miIztCXGv0s9z/Q]
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; CO1NAM04HT204; 6:HBB2RQaMIypRbYmHL0n0JzyCCzA/DGR73ybe4cd3PIjKBvZxmJrkFYCyXz7RAQARV4aTSocTlJUJeUfUdWukyz6pB+wxHIJ/AdswnC9i0LIDCkEh8W1PBEaFfTNLnMy/iOv77dPAoeW13/9q0Q8Cu7dZ11EolX9SFVRJjkIgeJEjIs1TrL/SvzrvYQJDupK9K7yH1o/i5kybD6Rxi3ilDoALROdWqKAyLBYDqLlidUDaJMjHSQdzwoGMZUDwajb70PROfR8ry6IXYRR6+HW4Q8odPNcX8tlxwffL/dv+jADzVFjiMqgcwtmraN9/vwyO; 5:fvMNOETEEtUtvLzEZ8OpRotPpu2FJ1g7a7ureNy5lm0lPJcjaYfLPAQR/M8e1j4IMN8o3ZjbQbkO0lV2Mc5jE7JLHJrF47Mi0ufNBir/VtUrxbGdorVXrL0sSFy2r+ps7OV+H+lJRCEoJum6bHIzig==; 24:G0av2HZyXJMoEkw1kpb3LFN/X+jIOoE455YCyO120N0VhdH1mcmvTcGGiPrtYEuwbNp99qrqGAKs2BlOYZUMWvn0IJrW1KhYGQ6gTArFfVg=; 7:YJ940hDV5UC/akXG8l9EaXZxMqfNMf2jbnFW+nxvQpnoIU4ubvOZqY6r3muhjmVjp76g8w/l7vZ47sngJIs7TN8Hjf/+GV2UvZRPvJZdgbpb8onGGH9hwZHywtfYyEfpMm4Uu5D3LcRD8pU9Ti9QMf5K2ymD7W/u/S2vTgvhVlVUJ+qY1OFbhyPjOjLH059Wr0zrk7dEcZo5sbqORrR+EnTP21XJt8DiNaxFEmWP3jaOpl3OH/c+VU/LUxTBDIXeJGaoZgLyrgpj4hggqGAM8WKj0jtZU7u8LlCUQPgZvBmXqhVGaYiYpo5Wt5LPx01jPPE/RcTTuyCg4k4QvW51AnaLzujFK5XLAWUNLkKLFuo=
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM04HT204; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; 
x-ms-office365-filtering-correlation-id: b56959cf-17d7-4951-0ba9-08d3fc41b259
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1603101340)(1601125047); SRVR:CO1NAM04HT204; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CO1NAM04HT204; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT204; 
x-forefront-prvs: 0105DAA385
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778C07EB8011F19A780023BFFA90CY1PR15MB0778namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2016 19:12:28.2914 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT204
X-OriginalArrivalTime: 24 Oct 2016 19:12:30.0065 (UTC) FILETIME=[90D68E10:01D22E2A]
Archived-At: 
Subject: Re: [TLS] How should inability to access key revocation lists impact the TLS handshake?
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: Mon, 24 Oct 2016 19:12:32 -0000

--_000_CY1PR15MB0778C07EB8011F19A780023BFFA90CY1PR15MB0778namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

But I think the problem is that there is no TLS alert for =93revocation sta=
tus inaccessible=94.



Best,

Xiaoyin

From: Salz, Rich
Sent: Monday, October 24, 2016 2:15 PM
To: Ryan Carboni; tls@ietf.org
Subject: Re: [TLS] How should inability to access key revocation lists impa=
ct the TLS handshake?



> How should inability to access key revocation lists impact the TLS handsh=
ake, if previous public keys and/or certificate hashes are not cached?

Nobody does revocation on the web, for some almost all encompassing definit=
ion of nobody.

Instead, OCSP and OCSP stapling.

> I cannot see this in the standard. Considering that all one has to do is =
DDOS a certificate authority nowadays...

General PKI and key lifecycle issues are, properly, not part of the TLS spe=
c.

        /r$
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--_000_CY1PR15MB0778C07EB8011F19A780023BFFA90CY1PR15MB0778namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable















But I think the problem is that there is no TLS al=
ert for =93revocation status inaccessible=94.


 


Best,


Xiaoyin




From: Salz, Rich

Sent: Monday, October 24, 2016 2:15 PM

To: Ryan Carboni; 
tls@ietf.org

Subject: Re: [TLS] How should inability to access key revocation lis=
ts impact the TLS handshake?




 







> How should inability to access key revocation=
 lists impact the TLS handshake, if previous public keys and/or certificate=
 hashes are not cached?



Nobody does revocation on the web, for some almost all encompassing definit=
ion of nobody.



Instead, OCSP and OCSP stapling.



> I cannot see this in the standard. Considering that all one has to do =
is DDOS a certificate authority nowadays...



General PKI and key lifecycle issues are, properly, not part of the TLS spe=
c.



        /r$

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/=
mailman/listinfo/tls







--_000_CY1PR15MB0778C07EB8011F19A780023BFFA90CY1PR15MB0778namp_--


From nobody Mon Oct 24 12:18:27 2016
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 A3A5B12989D for ; Mon, 24 Oct 2016 12:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 c7U27jP-2ckG for ; Mon, 24 Oct 2016 12:18:24 -0700 (PDT)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3781299BB for ; Mon, 24 Oct 2016 12:18:24 -0700 (PDT)
Received: by mail-yb0-x22d.google.com with SMTP id g68so88217206ybi.0 for ; Mon, 24 Oct 2016 12:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EmRenR3BHwYTw4cheF5g//2biRwU1wVO9mbIjvrqXX8=; b=z4VarbEW1LBtAlsUs1lBVfTmilzfhRrDAfgpAdl3gSK4qUyrk/FMOozh+c8w30TcAm wSmMn2g1xfZFQKB6M+5rBgHKFyfP9P1MWpdiyaVHAdy71tDcDFP/P6Ik2fGvu+i4XH36 /9/B6uLnltcT7LgAsqZlocrXdmY82sD1MPnrRgMJuGkxftsVjyCchqkjSuFt0JXmPikp jQCh+kAiE68w51wSLju1wGaSnA++8/W2Mf6EqmXmt6rIChg479kax04jnzu2sCpXCyvX wXKeF4Jivom4E5ItQ1PL1GtFjb4Ff5l9m3DdyeJhGLCxYy8nGtY+tXiEjI5BJYdih3s/ l4eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EmRenR3BHwYTw4cheF5g//2biRwU1wVO9mbIjvrqXX8=; b=j3cYF2HMU3VroiD9Gk4Vy5QSHNxKogx8yORkmWsUtJ4gu5liBVXYx2Aw3f7A7O8K4x JrlAWWPGGQXPynTOrovG4QSG50bzDL6oT08a8adFKRWuNTz+MjnaA7jVieogmLNFNoCg SWF/EcxNDTpeB0m3/JmgKQRVbfbJChAWWS3df88hOqbD+1NWKYPKV4WfcWAw8v65g8PL q14ievBUVmVHelrKrYlWGTUsNMOUT4KqoSn+r+PsaSFTxG60puiooYTF+4oihlp2tljH zEOw9kJbU4OJ222MZk9ily6obAwJdwGQRVUJJBfCN4/N4hWUxqZEDipSh9nYNeCYEktB FX3w==
X-Gm-Message-State: ABUngvf35WbjlRakxWgTeHCwL7PSGS25ZhH5uq/VYcq+hYeQQP5tcnEqh82gnf4Vtyq1oSe/CIrZD0+y2qIN2g==
X-Received: by 10.37.246.15 with SMTP id t15mr18475761ybd.107.1477336704034; Mon, 24 Oct 2016 12:18:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Mon, 24 Oct 2016 12:17:43 -0700 (PDT)
In-Reply-To: 
References:   
From: Eric Rescorla 
Date: Mon, 24 Oct 2016 12:17:43 -0700
Message-ID: 
To: Xiaoyin Liu 
Content-Type: multipart/alternative; boundary=f403045da0a6755a09053fa141c3
Archived-At: 
Cc: "tls@ietf.org" , Ryan Carboni 
Subject: Re: [TLS] How should inability to access key revocation lists impact the TLS handshake?
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: Mon, 24 Oct 2016 19:18:27 -0000

--f403045da0a6755a09053fa141c3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

"certificate_unknown" seems like it should be fine for this

On Mon, Oct 24, 2016 at 12:12 PM, Xiaoyin Liu  wrote=
:

> But I think the problem is that there is no TLS alert for =E2=80=9Crevoca=
tion
> status inaccessible=E2=80=9D.
>
>
>
> Best,
>
> Xiaoyin
>
> *From: *Salz, Rich 
> *Sent: *Monday, October 24, 2016 2:15 PM
> *To: *Ryan Carboni ; tls@ietf.org
> *Subject: *Re: [TLS] How should inability to access key revocation lists
> impact the TLS handshake?
>
>
> > How should inability to access key revocation lists impact the TLS
> handshake, if previous public keys and/or certificate hashes are not cach=
ed?
>
> Nobody does revocation on the web, for some almost all encompassing
> definition of nobody.
>
> Instead, OCSP and OCSP stapling.
>
> > I cannot see this in the standard. Considering that all one has to do i=
s
> DDOS a certificate authority nowadays...
>
> General PKI and key lifecycle issues are, properly, not part of the TLS
> spec.
>
>         /r$
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--f403045da0a6755a09053fa141c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


"certificate_unknown" seems like it should be fi=
ne for this

=
On Mon, Oct 24, 2016 at 12:12 PM, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:















But I think the problem is th=
at there is no TLS alert for =E2=80=9Crevocation status inaccessible=E2=80=
=9D.


=C2=A0


Best,


Xiaoyin




From: Sal=
z, Rich

Sent: Monday, October 24, 2016 2:15 PM

To: Ryan Carbo=
ni; 
tls@ietf.org

Subject: Re: [TLS] How should inability to access key revocation lis=
ts impact the TLS handshake?




=C2=A0







> How should inability to =
access key revocation lists impact the TLS handshake, if previous public ke=
ys and/or certificate hashes are not cached?



Nobody does revocation on the web, for some almost all encompassing definit=
ion of nobody.



Instead, OCSP and OCSP stapling.



> I cannot see this in the standard. Considering that all one has to do =
is DDOS a certificate authority nowadays...



General PKI and key lifecycle issues are, properly, not part of the TLS spe=
c.



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /r$

_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls








_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--f403045da0a6755a09053fa141c3--


From nobody Mon Oct 24 15:48:43 2016
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 9848D129AAF for ; Mon, 24 Oct 2016 15:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.131
X-Spam-Level: 
X-Spam-Status: No, score=-3.131 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_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 AYZk7gEJuR1n for ; Mon, 24 Oct 2016 15:48:39 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0241129500 for ; Mon, 24 Oct 2016 15:48:39 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id 12so2219960qtm.3 for ; Mon, 24 Oct 2016 15:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9I2CpS3BkUw8FOei0lnyjYTSqoKJvZ+3ejzqgEGJhJg=; b=pITyCbJNBjd2ShbDLGMwbaKU1Bh9+uIpCUwm+YpDqrZZjYeMFDIQcqhmfqgFNwPfSe DjBmo7QuwQ+ofaEUvZy9udC1b3gSxp+ct7J43MqSQp823teEaBE27CBRdzIWsVy0ovx3 SXZCufsyRGaMLttuAb48z4XKMRojvLIIRBODTGBmvSWqqc2xkaI3SagK0Np3N3sDPVKC QKcVotFgGKvOGA23MQ8IMrzIKZXJzyE1P0wfi0SPYnJ0L51GgrKuydrEyeJNGB3UgVMK 5k0zItg8T0S02JgV1O9D4RMDjhDg0YEs6qJF1HYE7gFCcL4USgJT8j5LvsVkqq0HNQxG Wf/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9I2CpS3BkUw8FOei0lnyjYTSqoKJvZ+3ejzqgEGJhJg=; b=OpJ4sm+YraD2liArZmNyht+/ptT+7O1HlNezFt5XAfFXMIMEC4FlIYWfpa0ezJxtX+ BJmUEDgYJJkNK06QOLg8v69dhwwiEzdJ34wq7II15KoCR0qnZs6yhSYDcJhT8IeOxUGc FLNRW7sdEuhsf39R8IlrMTQiG/6n18EZ6hTQ8zGXUNEZYKqGBrLOrmmXDa1ZORJ+FL9m tbVWxUQYJ8qMX/na7BrOKCyp/bkO1zC8GgEpWIvPXqjJxMWsmenE3gxGkDhewEaA4FDj lYR4IrtMNmibgdth0QxMxrto6VE0itT+kE97VEhWpK0Rfq0OpnhTpQWYZUUEjjjo1Xn/ OjEA==
X-Gm-Message-State: ABUngvf5ZD10VtufmN0Vhvjt88Cyc2eTdewtLZcgRloBLs9ZFSGoT47KvHdAu7cuMfx0HzqjvYxICfz4vVfzZKFy
X-Received: by 10.200.41.135 with SMTP id 7mr17581123qts.71.1477349318518; Mon, 24 Oct 2016 15:48:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.98.134 with HTTP; Mon, 24 Oct 2016 15:48:37 -0700 (PDT)
In-Reply-To: 
References: 
From: Victor Vasiliev 
Date: Mon, 24 Oct 2016 18:48:37 -0400
Message-ID: 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=001a1140458a57488e053fa4313f
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Mon, 24 Oct 2016 22:48:41 -0000

--001a1140458a57488e053fa4313f
Content-Type: text/plain; charset=UTF-8

I believe that an ability to resume across different server_name values
specified in the subjectAltName of a certificate will have a positive
performance impact on the websites which due to various reasons have to
fetch
resources from different servers.  A particular use case I have in mind is
when
a website maintains a pool of servers, say, *.cdn.example.com, and supplies
a
specific server directly in a resource URL.  In that case, all the servers
already share a wildcard certificate with a secret, so they can share a
ticket
key too, meaning it makes sense for them to accept the ticket issued by
another
server in the pool.

There are potential confusion issues associated with using a ticket for a
different server name, both with the server becoming confused and the client
becoming confused.  On the server side, this requires implementations to
know
how to handle SNI value change.  I suggest that the servers should
explicitly
indicate to the client that a newly issued ticket may be used for all the
subjectAltName values present in the server's certificate.

Clients must also account for any per-host differences before offering a
ticket.  For instance, web browsers typically require users to pick a
certificate for each domain they authenticate to, so resumption across
different SNI values should obviously not happen here.  One can also
imagine,
say, a client which uses different cipher configuration or a different set
of
trust anchors for each host.  In all of those cases, it is on the client to
not
cross-resume, but a lot of those concerns are application-specific in
nature,
so I am not sure how much guidance can the TLS specification provide on this
matter.


On Thu, Oct 20, 2016 at 8:33 PM, Eric Rescorla  wrote:

> We used to explicitly say that you had to check SNI for 0-RTT (but
> didn't say anything about resumption). On the principle that 0-RTT and
> resumption should be the same I removed that, but it turns out that
> the document doesn't actually have any rule at all other than the one
> we've inherited from RFC 6066, which clearly says that you can't
> resume with a different SNI [0].
>
> Following the discussion in
> https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
> to the draft clarifying that the RFC 6066 rule still applies [1]
>
> With that said, it does seem like there might be situations where it
> would be useful to allow resumption/0-RTT with different SNIs. My
> intuition (partly informed by [2]) is that this is something we should
> be pretty careful about and have the server opt-in explicitly (if at
> all) but I'm willing to be wrong about that.
>
> Comments?
> -Ekr
>
>
> [0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
> [1] https://github.com/tlswg/tls13-spec/commit/
> b26093b5e9143fb61f5b619d1da78c4ba54b2121
> [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a1140458a57488e053fa4313f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I believe that an ability to resume across different =
server_name values
specified in the subjectAltName of a certifica=
te will have a positive
performance impact on the websites which =
due to various reasons have to fetch
resources from different ser=
vers.=C2=A0 A particular use case I have in mind is when
a websit=
e maintains a pool of servers, say, *.cd=
n.example.com, and supplies a
specific server directly in a r=
esource URL.=C2=A0 In that case, all the servers
already share a =
wildcard certificate with a secret, so they can share a ticket
ke=
y too, meaning it makes sense for them to accept the ticket issued by anoth=
er
server in the pool.

There are po=
tential confusion issues associated with using a ticket for a
dif=
ferent server name, both with the server becoming confused and the client
becoming confused.=C2=A0 On the server side, this requires impleme=
ntations to know
how to handle SNI value change.=C2=A0 I suggest =
that the servers should explicitly
indicate to the client that a =
newly issued ticket may be used for all the
subjectAltName values=
 present in the server's certificate.

Clients must also account for any per-host differences before offering a=

ticket.=C2=A0 For instance, web browsers typically require users=
 to pick a
certificate for each domain they authenticate to, so r=
esumption across
different SNI values should obviously not happen=
 here.=C2=A0 One can also imagine,
say, a client which uses diffe=
rent cipher configuration or a different set of
trust anchors for=
 each host.=C2=A0 In all of those cases, it is on the client to not
cross-resume, but a lot of those concerns are application-specific in na=
ture,
so I am not sure how much guidance can the TLS specificatio=
n provide on this
matter.


On Thu, Oct 20, 2016 at 8:33 P=
M, Eric Rescorla <ekr@rtfm.com> wrote:
We used to explicitly say =
that you had to check SNI for 0-RTT (but
didn't say anyth=
ing about resumption). On the principle that 0-RTT and
resumption=
 should be the same I removed that, but it turns out that
the doc=
ument doesn't actually have any rule at all other than the one
we've inherited from RFC 6066, which clearly says that you can't<=
/div>
resume with a different SNI [0].

Followi=
ng the discussion in
to the draft clarifying =
that the RFC 6066 rule still applies [1]

With that=
 said, it does seem like there might be situations where it
would=
 be useful to allow resumption/0-RTT with different SNIs. My
intu=
ition (partly informed by [2]) is that this is something we should
be pretty careful about and have the server opt-in explicitly (if at
all) but I'm willing to be wrong about that.

=

Comments?
-Ekr


[0] <=
a href=3D"https://tools.ietf.org/rfcmarkup?doc=3D6066#section-3" target=3D"=
_blank">https://tools.ietf.org/rfcmarkup?doc=3D6066#section-3



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a1140458a57488e053fa4313f--


From nobody Mon Oct 24 18:09:58 2016
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 C2F6C129A08 for ; Mon, 24 Oct 2016 18:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level: 
X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=IIaaWWsA; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=KNAvemHH
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 LM-toO6F_N5D for ; Mon, 24 Oct 2016 18:09:55 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 269FA126CD8 for ; Mon, 24 Oct 2016 18:09:55 -0700 (PDT)
Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9P14UsE010708; Mon, 24 Oct 2016 18:09:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=dqjmT/l8fNZo1RSAONwk60B4xO6993/NfGKq1so1oEk=; b=IIaaWWsAc8tYK7HxyX3XdMdRPjO8AVWFqgz/En230hqKJkzQjo428CO8GUTomprNUTqr ko/vGseFMXg21W6JK8Rd39ydfHu7G5PphbcrX8WGIMXLt6SeWyhCYeXyMS36vdOPVssK BZkupmcGhYXSGxH5L7HgRWu39N9TsAEZHSE= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 269s4d9w40-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2016 18:09:54 -0700
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.21) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 24 Oct 2016 21:09:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=dqjmT/l8fNZo1RSAONwk60B4xO6993/NfGKq1so1oEk=; b=KNAvemHHZygd9cgKeOzuUpRgUe/CYvddcN1P+jXfK9gfGFkVc7bE6JPkBHQ+YZeFoc27zl1kVihY6NVx01Xs6AvvmUoCX9Nfqm/p2zFCkqklCRPsjN7H/vviU3y2s3RGcftZpwElOziPNn21fLebpSMqA+or8uK17c835pWljoM=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Tue, 25 Oct 2016 01:09:45 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0679.012; Tue, 25 Oct 2016 01:09:45 +0000
From: Kyle Nekritz 
To: Eric Rescorla , "tls@ietf.org" 
Thread-Topic: [TLS] SNI and Resumption/0-RTT
Thread-Index: AQHSKzL1pALf5VOBjEej9Ya71kljcaC4Wb+w
Date: Tue, 25 Oct 2016 01:09:45 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2620:10d:c091:180::1:b71d]
x-ms-office365-filtering-correlation-id: f9e7bb3d-3855-4d8d-d2f5-08d3fc739c07
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1182; 20:T8OPhM8jRy48uXWxmEFYMdFRCI7qVTIBJpoUIy4Qv+cLSNAJ6ZQxy5J4Jj1aJQXF3TNRyvurKk7+UTY/ys2kYKWHf2o0AgReBUx8v/mcJ3OepqeWcT3A4Y7f7K+jhkEti7b1fcWKcfdOKtZMyjGu31t8vaomEpBfuqgaFB48fCI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1182;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(166708455590820)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);  SRVR:MWHPR15MB1182; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1182; 
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(189998001)(97736004)(19580395003)(9686002)(5001770100001)(19617315012)(2501003)(8676002)(2900100001)(19609705001)(15975445007)(7846002)(3280700002)(5002640100001)(122556002)(87936001)(107886002)(5660300001)(54356999)(76576001)(2950100002)(76176999)(77096005)(7696004)(8936002)(50986999)(105586002)(92566002)(86362001)(99286002)(101416001)(19625215002)(68736007)(106356001)(106116001)(7736002)(11100500001)(7906003)(586003)(19300405004)(10400500002)(2906002)(102836003)(6116002)(790700001)(33656002)(81156014)(81166006)(74316002)(3660700001)(16236675004)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1182; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182E0D0F4FE9DFB7D772CF9AFA80MWHPR15MB1182namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2016 01:09:45.4915 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1182
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-24_19:, , signatures=0
Archived-At: 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Tue, 25 Oct 2016 01:09:57 -0000

--_000_MWHPR15MB1182E0D0F4FE9DFB7D772CF9AFA80MWHPR15MB1182namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBkbyB0aGluayB0aGlzIHNob3VsZCBiZSBhbGxvd2VkIGlmIHRoZSBjbGllbnQgaXMgc2F0aXNm
aWVkIHdpdGggdGhlIHByZXZpb3VzIGlkZW50aXRpZXMgcHJlc2VudGVkLiBXZSBjdXJyZW50bHkg
YWxsb3cgcmVzdW1wdGlvbiBhY3Jvc3MgZG9tYWlucyBzdXBwb3J0ZWQgYnkgb3VyIHdpbGRjYXJk
IGNlcnRpZmljYXRlIChJIGJlbGlldmUgdGhpcyBpcyBmYWlybHkgY29tbW9uIHByYWN0aWNlKSwg
YW5kIG91ciBjbGllbnRzIHRha2UgYWR2YW50YWdlIG9mIHRoaXMgdG8gaW1wcm92ZSB0aGVpciBy
ZXN1bXB0aW9uIHJhdGUuIEluIHJlZ2FyZHMgdG8gdGhlIHJlZmVyZW5jZWQgcGFwZXIsIEkgZG9u
4oCZdCB0aGluayB0aGlzIGlzIGFueSBtb3JlIGRhbmdlcm91cyB0aGFuIHRoZSB3aWxkY2FyZCBj
ZXJ0aWZpY2F0ZSBpdHNlbGYgYXMgYSBmdWxsIGhhbmRzaGFrZSB3b3VsZCBzdWNjZWVkIGFueXdh
eS4gSSBkb27igJl0IHRoaW5rIGl04oCZcyBlbnRpcmVseSBuZWNlc3NhcnkgZm9yIHRoZSBzZXJ2
ZXIgdG8gb3B0LWluIHRvIHRoaXMgZWl0aGVyLCBpZiB0aGUgc2VydmVyIHdhbnRzIGl0IGNhbiBz
aW1wbHkgcmVqZWN0IHRoZSByZXN1bXB0aW9uIGF0dGVtcHQuDQoNCkZyb206IFRMUyBbbWFpbHRv
OnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDog
VGh1cnNkYXksIE9jdG9iZXIgMjAsIDIwMTYgODozNCBQTQ0KVG86IHRsc0BpZXRmLm9yZw0KU3Vi
amVjdDogW1RMU10gU05JIGFuZCBSZXN1bXB0aW9uLzAtUlRUDQoNCldlIHVzZWQgdG8gZXhwbGlj
aXRseSBzYXkgdGhhdCB5b3UgaGFkIHRvIGNoZWNrIFNOSSBmb3IgMC1SVFQgKGJ1dA0KZGlkbid0
IHNheSBhbnl0aGluZyBhYm91dCByZXN1bXB0aW9uKS4gT24gdGhlIHByaW5jaXBsZSB0aGF0IDAt
UlRUIGFuZA0KcmVzdW1wdGlvbiBzaG91bGQgYmUgdGhlIHNhbWUgSSByZW1vdmVkIHRoYXQsIGJ1
dCBpdCB0dXJucyBvdXQgdGhhdA0KdGhlIGRvY3VtZW50IGRvZXNuJ3QgYWN0dWFsbHkgaGF2ZSBh
bnkgcnVsZSBhdCBhbGwgb3RoZXIgdGhhbiB0aGUgb25lDQp3ZSd2ZSBpbmhlcml0ZWQgZnJvbSBS
RkMgNjA2Niwgd2hpY2ggY2xlYXJseSBzYXlzIHRoYXQgeW91IGNhbid0DQpyZXN1bWUgd2l0aCBh
IGRpZmZlcmVudCBTTkkgWzBdLg0KDQpGb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gaW4NCmh0dHBz
Oi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL2lzc3Vlcy83MjAgSSd2ZSBhZGRlZCBhIHN0
YXRlbWVudA0KdG8gdGhlIGRyYWZ0IGNsYXJpZnlpbmcgdGhhdCB0aGUgUkZDIDYwNjYgcnVsZSBz
dGlsbCBhcHBsaWVzIFsxXQ0KDQpXaXRoIHRoYXQgc2FpZCwgaXQgZG9lcyBzZWVtIGxpa2UgdGhl
cmUgbWlnaHQgYmUgc2l0dWF0aW9ucyB3aGVyZSBpdA0Kd291bGQgYmUgdXNlZnVsIHRvIGFsbG93
IHJlc3VtcHRpb24vMC1SVFQgd2l0aCBkaWZmZXJlbnQgU05Jcy4gTXkNCmludHVpdGlvbiAocGFy
dGx5IGluZm9ybWVkIGJ5IFsyXSkgaXMgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB3ZSBzaG91bGQN
CmJlIHByZXR0eSBjYXJlZnVsIGFib3V0IGFuZCBoYXZlIHRoZSBzZXJ2ZXIgb3B0LWluIGV4cGxp
Y2l0bHkgKGlmIGF0DQphbGwpIGJ1dCBJJ20gd2lsbGluZyB0byBiZSB3cm9uZyBhYm91dCB0aGF0
Lg0KDQpDb21tZW50cz8NCi1Fa3INCg0KDQpbMF0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNt
YXJrdXA/ZG9jPTYwNjYjc2VjdGlvbi0zPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfcmZjbWFya3VwLTNGZG9jLTNENjA2
Ni0yM3NlY3Rpb24tMkQzJmQ9RFFNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPWwyajRC
amtPMExjM3U0Q0gyejdqUHcmbT03bEpzZ0M2c0hSTW91dUZPcTZ3RGg0Tjcycm00eVdtMlZXNmdk
MnpDdmRRJnM9Uk1vek5wV0xwYVM3azNFNlNyZ21HeC1Cclgtb2xYX0I1b0dhTkRJQ25fTSZlPT4N
ClsxXSBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9jb21taXQvYjI2MDkzYjVl
OTE0M2ZiNjFmNWI2MTlkMWRhNzhjNGJhNTRiMjEyMQ0KWzJdIGh0dHA6Ly9hbnRvaW5lLmRlbGln
bmF0LWxhdmF1ZC5mci9kb2Mvd3d3MTUucGRmPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50
LmNvbS92Mi91cmw/dT1odHRwLTNBX19hbnRvaW5lLmRlbGlnbmF0LTJEbGF2YXVkLmZyX2RvY193
d3cxNS5wZGYmZD1EUU1GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9bDJqNEJqa08wTGMz
dTRDSDJ6N2pQdyZtPTdsSnNnQzZzSFJNb3V1Rk9xNndEaDRONzJybTR5V20yVlc2Z2QyekN2ZFEm
cz1IQmZjbDFzdldjaERzaFpxUUtPX05DVlBxMlRjeHZhR2FEYUZkTVhTRzc4JmU9Pg0KDQo=

--_000_MWHPR15MB1182E0D0F4FE9DFB7D772CF9AFA80MWHPR15MB1182namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu
MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94
bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw
ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs
aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG8gdGhpbmsgdGhpcyBzaG91
bGQgYmUgYWxsb3dlZCBpZiB0aGUgY2xpZW50IGlzIHNhdGlzZmllZCB3aXRoIHRoZSBwcmV2aW91
cyBpZGVudGl0aWVzIHByZXNlbnRlZC4gV2UgY3VycmVudGx5IGFsbG93IHJlc3VtcHRpb24gYWNy
b3NzIGRvbWFpbnMgc3VwcG9ydGVkIGJ5IG91ciB3aWxkY2FyZA0KIGNlcnRpZmljYXRlIChJIGJl
bGlldmUgdGhpcyBpcyBmYWlybHkgY29tbW9uIHByYWN0aWNlKSwgYW5kIG91ciBjbGllbnRzIHRh
a2UgYWR2YW50YWdlIG9mIHRoaXMgdG8gaW1wcm92ZSB0aGVpciByZXN1bXB0aW9uIHJhdGUuIElu
IHJlZ2FyZHMgdG8gdGhlIHJlZmVyZW5jZWQgcGFwZXIsIEkgZG9u4oCZdCB0aGluayB0aGlzIGlz
IGFueSBtb3JlIGRhbmdlcm91cyB0aGFuIHRoZSB3aWxkY2FyZCBjZXJ0aWZpY2F0ZSBpdHNlbGYg
YXMgYSBmdWxsIGhhbmRzaGFrZQ0KIHdvdWxkIHN1Y2NlZWQgYW55d2F5LiBJIGRvbuKAmXQgdGhp
bmsgaXTigJlzIGVudGlyZWx5IG5lY2Vzc2FyeSBmb3IgdGhlIHNlcnZlciB0byBvcHQtaW4gdG8g
dGhpcyBlaXRoZXIsIGlmIHRoZSBzZXJ2ZXIgd2FudHMgaXQgY2FuIHNpbXBseSByZWplY3QgdGhl
IHJlc3VtcHRpb24gYXR0ZW1wdC48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxvOnA+PC9vOnA+
PC9hPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i
PkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9iZXIgMjAsIDIw
MTYgODozNCBQTTxicj4NCjxiPlRvOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8
L2I+IFtUTFNdIFNOSSBhbmQgUmVzdW1wdGlvbi8wLVJUVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB1c2VkIHRvIGV4cGxpY2l0bHkgc2F5IHRoYXQgeW91
IGhhZCB0byBjaGVjayBTTkkgZm9yIDAtUlRUIChidXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRpZG4ndCBzYXkgYW55dGhpbmcgYWJvdXQgcmVz
dW1wdGlvbikuIE9uIHRoZSBwcmluY2lwbGUgdGhhdCAwLVJUVCBhbmQ8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlc3VtcHRpb24gc2hvdWxkIGJl
IHRoZSBzYW1lIEkgcmVtb3ZlZCB0aGF0LCBidXQgaXQgdHVybnMgb3V0IHRoYXQ8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBkb2N1bWVudCBk
b2Vzbid0IGFjdHVhbGx5IGhhdmUgYW55IHJ1bGUgYXQgYWxsIG90aGVyIHRoYW4gdGhlIG9uZTxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2UndmUg
aW5oZXJpdGVkIGZyb20gUkZDIDYwNjYsIHdoaWNoIGNsZWFybHkgc2F5cyB0aGF0IHlvdSBjYW4n
dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVz
dW1lIHdpdGggYSBkaWZmZXJlbnQgU05JIFswXS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9sbG93aW5nIHRoZSBkaXNjdXNzaW9uIGluPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm
PSJodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9pc3N1ZXMvNzIwIj5odHRwczov
L2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9pc3N1ZXMvNzIwPC9hPiBJJ3ZlIGFkZGVkIGEg
c3RhdGVtZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj50byB0aGUgZHJhZnQgY2xhcmlmeWluZyB0aGF0IHRoZSBSRkMgNjA2NiBydWxlIHN0aWxs
IGFwcGxpZXMgWzFdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPldpdGggdGhhdCBzYWlkLCBpdCBkb2VzIHNlZW0gbGlrZSB0aGVyZSBtaWdodCBi
ZSBzaXR1YXRpb25zIHdoZXJlIGl0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj53b3VsZCBiZSB1c2VmdWwgdG8gYWxsb3cgcmVzdW1wdGlvbi8wLVJU
VCB3aXRoIGRpZmZlcmVudCBTTklzLiBNeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50dWl0aW9uIChwYXJ0bHkgaW5mb3JtZWQgYnkgWzJdKSBp
cyB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHdlIHNob3VsZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YmUgcHJldHR5IGNhcmVmdWwgYWJvdXQgYW5k
IGhhdmUgdGhlIHNlcnZlciBvcHQtaW4gZXhwbGljaXRseSAoaWYgYXQ8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFsbCkgYnV0IEknbSB3aWxsaW5n
IHRvIGJlIHdyb25nIGFib3V0IHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlswXSA8YSBocmVmPSJodHRwczovL3VybGRl
ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX3Jm
Y21hcmt1cC0zRmRvYy0zRDYwNjYtMjNzZWN0aW9uLTJEMyZhbXA7ZD1EUU1GYVEmYW1wO2M9NVZE
MFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1sMmo0QmprTzBMYzN1NENIMno3alB3JmFtcDttPTds
SnNnQzZzSFJNb3V1Rk9xNndEaDRONzJybTR5V20yVlc2Z2QyekN2ZFEmYW1wO3M9Uk1vek5wV0xw
YVM3azNFNlNyZ21HeC1Cclgtb2xYX0I1b0dhTkRJQ25fTSZhbXA7ZT0iPg0KaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9yZmNtYXJrdXA/ZG9jPTYwNjYjc2VjdGlvbi0zPC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0i
aHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvY29tbWl0L2IyNjA5M2I1ZTkxNDNm
YjYxZjViNjE5ZDFkYTc4YzRiYTU0YjIxMjEiPmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMx
My1zcGVjL2NvbW1pdC9iMjYwOTNiNWU5MTQzZmI2MWY1YjYxOWQxZGE3OGM0YmE1NGIyMTIxPC9h
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzJd
IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw
LTNBX19hbnRvaW5lLmRlbGlnbmF0LTJEbGF2YXVkLmZyX2RvY193d3cxNS5wZGYmYW1wO2Q9RFFN
RmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9bDJqNEJqa08wTGMzdTRDSDJ6
N2pQdyZhbXA7bT03bEpzZ0M2c0hSTW91dUZPcTZ3RGg0Tjcycm00eVdtMlZXNmdkMnpDdmRRJmFt
cDtzPUhCZmNsMXN2V2NoRHNoWnFRS09fTkNWUHEyVGN4dmFHYURhRmRNWFNHNzgmYW1wO2U9Ij4N
Cmh0dHA6Ly9hbnRvaW5lLmRlbGlnbmF0LWxhdmF1ZC5mci9kb2Mvd3d3MTUucGRmPC9hPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_MWHPR15MB1182E0D0F4FE9DFB7D772CF9AFA80MWHPR15MB1182namp_--


From nobody Mon Oct 24 18:14:29 2016
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 1D86A129A3B for ; Mon, 24 Oct 2016 18:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Cjck0D6g; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=XTT39lxH
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 Naz85kmlL7xV for ; Mon, 24 Oct 2016 18:14:26 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 9934C129A32 for ; Mon, 24 Oct 2016 18:14:26 -0700 (PDT)
Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9P1EQoC025664; Mon, 24 Oct 2016 18:14:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=h7XOfSCN4m0jkE328uiEcWC0JL7HtEEpGUCGxDyfDPY=; b=Cjck0D6gyJCn2w5m1w/yyrCuENj+2CODDeNyZ3icOFog8aMzeq97gK0AbtQXziKE3laz onsMog5c5Ls/9Hh4ywlKhdrLOIPsbf8IZyxJibBi2xemmtbjDV11iIEFOPuIFvkL7UT9 MrHA+neLOeJES3THH7tRqev0yDrQ/LFTVFg= 
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 269r962bkw-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2016 18:14:26 -0700
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.23) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 24 Oct 2016 18:14:25 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;  bh=AWrDSG4ju//fUZCRrk9kOlGkzq2fZmaMiRBrOeUy4W0=; b=XTT39lxHgj8YlHDQAvaDdrxVQf4W73lsIxs9fX4A7B7Fvnx+Oj36c68kIUe2tTkJqmD2lcTU1s6CUWT95nF9ZRUpahpJzGDJmQ6ZZwKtrbe1P8ngrUMSg+ICJMQQO5NxBMx3Mfw2S6Oig7GhZFn+K+4XIbuVJPqNm0VWAUeA1P8=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Tue, 25 Oct 2016 01:14:23 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0679.012; Tue, 25 Oct 2016 01:14:23 +0000
From: Kyle Nekritz 
To: Martin Thomson , Eric Rescorla 
Thread-Topic: [TLS] Deprecating alert levels
Thread-Index: AdImXnNSskDkr/RBRyKiMCb2wmhMDwBNKucAADz34cAAZqtPgAAFEsmAAAAkNgAAEG1CgAD5HzAQ
Date: Tue, 25 Oct 2016 01:14:23 +0000
Message-ID: 
References:  <20161019155845.D13E21A564@ld9781.wdf.sap.corp>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2620:10d:c091:180::1:b71d]
x-ms-office365-filtering-correlation-id: 9d164ebb-9021-4bab-21d1-08d3fc7441b3
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1182; 20:QdseVc78tR2Ig0ubsBvgP0hkL2dBYxkbQcH041QvbPBcxf/AG7/X/ro9rR+tVHdvlBYJhWmtVU7/3gd4dW9RpJ1KqTwH15DtjbthgOAWxETsvSqWYwBL1mqxxy8oenGIWy2tOvaXg/lqjFAyTR+G3oJXJTzzM/DZ8K7sn9iTY1Q=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1182;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);  SRVR:MWHPR15MB1182; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1182; 
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(13464003)(189002)(199003)(377454003)(189998001)(97736004)(19580395003)(9686002)(5001770100001)(15650500001)(8676002)(2900100001)(4326007)(15975445007)(7846002)(3280700002)(5002640100001)(122556002)(87936001)(5660300001)(54356999)(76576001)(2950100002)(76176999)(77096005)(7696004)(8936002)(50986999)(105586002)(92566002)(86362001)(99286002)(101416001)(68736007)(93886004)(106356001)(7736002)(305945005)(11100500001)(586003)(10400500002)(2906002)(102836003)(6116002)(575784001)(33656002)(81156014)(81166006)(74316002)(3660700001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1182; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2016 01:14:23.5154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1182
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-24_19:, , signatures=0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Deprecating alert levels
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: Tue, 25 Oct 2016 01:14:28 -0000

+1 to both Martin and ekr, I think simplifying these alerts with clearly de=
fined behavior for each alert description is the best way forward.

Kyle=20

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Wednesday, October 19, 2016 10:18 PM
To: Eric Rescorla 
Cc: tls@ietf.org
Subject: Re: [TLS] Deprecating alert levels

On 20 October 2016 at 05:28, Eric Rescorla  wrote:
>> 2.  Are there cases, such as unrecognized name. where it is useful to=20
>> indicate that an alert is not fatal?  If so how should this case be hand=
led?
>
>
> I think this alert was a mistake :)

In NSS is to tolerate it, but it's an exception.  I'm happier with a lone e=
xception than with atrophied and redundant alert levels continuing as they =
are.  I'd prefer to take the PR, with a minor amendment noting the hazard c=
aused by unrecognized_name(112).  Clients that intend to accept TLS 1.2 and=
 lower probably have to ignore warning alerts until they see that the serve=
r is doing TLS 1.3 or higher.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_tls&d=3DDQICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dl2j4BjkO0Lc3u4CH2z7=
jPw&m=3D1svSdxAuionbHyrUN4ThSCRLZ1pCQuLaO0qtgQ8Dk7A&s=3DjWxxDB9uWwT6kP_7TcZ=
4isUa_Z5LNWOhgMX_O1s3oaw&e=3D=20


From nobody Tue Oct 25 03:07:50 2016
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 4CB8212943C for ; Tue, 25 Oct 2016 03:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hi2OUHoCavJk for ; Tue, 25 Oct 2016 03:07:45 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2506112943D for ; Tue, 25 Oct 2016 03:07:45 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3t383M0rf6z25YK; Tue, 25 Oct 2016 12:07:43 +0200 (CEST)
X-purgate-ID: 152705::1477390063-00002B31-10066411/0/0
X-purgate-size: 3999
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t383L4pRCzkqL5; Tue, 25 Oct 2016 12:07:42 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 993131A564; Tue, 25 Oct 2016 12:07:42 +0200 (CEST)
In-Reply-To: 
To: Kyle Nekritz 
Date: Tue, 25 Oct 2016 12:07:42 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161025100742.993131A564@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 25 Oct 2016 10:07:47 -0000

Kyle Nekritz wrote:
>
> I do think this should be allowed if the client is satisfied with the
> previous identities presented. We currently allow resumption across
> domains supported by our wildcard certificate (I believe this is fairly
> common practice), and our clients take advantage of this to improve their
> resumption rate. In regards to the referenced paper, I don't think this
> is any more dangerous than the wildcard certificate itself as a full
> handshake would succeed anyway. I don't think it's entirely necessary
> for the server to opt-in to this either, if the server wants it can
> simply reject the resumption attempt.

I think it is a bad idea to look at this purely from the perspective
of whether this represents an obvious attack vector.

And there are two entirely *independent* decisions involved.

  (1) whether the TLS client proposes resumption for a session
      (i.e. client-side cache management)

  (2) whether the TLS server agrees to a proposed resumption
      or whether it performs a full handshake instead

And there are _different_ security trade-offs in these two distinct
decisions.

As I previously described my position, I'm perfectly OK with a server
performing a resumption if the full handshake would cause the server
to send/present the very same TLS server certificate as in the full
handshake that created the session that is proposed for resumption
... and that is actually the behaviour which I implemented, and
what comes out naturally if you implement TLS extension SNI support
_outside_ of the TLS stack on the server side.

However, I believe that the server agreeing to resumption with a
different SNI hostname is a use case, that with a sensible
generic TLS client, should never actually occur in practice.
Except for bugs or design flaws in the client-side session cache management
maybe.

The client does _not_ know which TLS server certificates the server has
available, and what criteria it will apply for selecting one or the other.
The existence of a wildcard certificate does not unconditionally preclude
existence of host-specific certificates for specific services that are
technically covered by the wildcard.  I really dislike seemingly
non-deterministic behaviour, and therefore try to avoid it as much
as possible in whatever I implement.

The decision to accept a particular server certificate for one specific
hostname/target does not (should not) necessarily apply to *each* other
possible servername covered/conveyed by that server certificate.

Special-casing stuff makes the behaviour also difficult to comprehend
for end-users / consumers (and implementers get it wrong more easily).
What if the server certificate is "manually" confirmed by the end-user
(for whatever reason:  it's self-signed/untrusted or from DANE rather
that PKIX) should that "acceptance" still/also transcend to all other
hostnames (why or why not)?

My client-side TLS session cache management (which I implemented above
the TLS stack), uses the target hostname as one of the session cache
lookup parameters, and I don't think it would be sensible to propose
arbitrary sessions for resumption.

The performance overhead for a full handshake per hostname is completely
negligible (and if the server operator cares, he could simply avoid
spreading content over distinct server hostnames).

What I found painful instead, is the server-side behaviour implemented
by Microsoft IIS / SChannel in the past, because when configured for
optional client certificates, the server exhibits Alzheimer towards
certificate-less clients (or at least it did so in the past),
because it would force each client without client cert through
a full renegotiation handshake after resumption for each new connection,
failing to memorize that the resumed session was created by renegotiation
where the server did ask for a client cert and the client did turn down
that request.


-Martin


From nobody Tue Oct 25 22:44:18 2016
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 264C312951A; Tue, 25 Oct 2016 22:44:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147746065415.29301.5576320765738473701.idtracker@ietfa.amsl.com>
Date: Tue, 25 Oct 2016 22:44:14 -0700
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-tls13-18.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 26 Oct 2016 05:44:14 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

        Title           : The Transport Layer Security (TLS) Protocol Version 1.3
        Author          : Eric Rescorla
	Filename        : draft-ietf-tls-tls13-18.txt
	Pages           : 118
	Date            : 2016-10-25

Abstract:
   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Oct 25 22:44:46 2016
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 E9D20129A10 for ; Tue, 25 Oct 2016 22:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Ud4seqz6MuU4 for ; Tue, 25 Oct 2016 22:44:43 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DB0129A18 for ; Tue, 25 Oct 2016 22:44:39 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id w3so960242ywg.1 for ; Tue, 25 Oct 2016 22:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=NNm4eT1ifwyGdyFF4yZLSm2gGfnH6JOgbth3z4vvmRU=; b=YTMtEWdSZmM0WfsPalr6tNl7UU8cPkNATUUGWlbAURxe1IO+UMqbcFekFig/+RQwBI cYDnGBkT/x0J9I7o38ilHR2SQpyhgj1s23vPzmY3r0fJ5yNwZGD5YDqDgPeQzzrbOLAP VHjBn1jwwQ0cZiylqA7qUs9MJxOMHWZbmW9H1/SUsXzxckbwWAAdDlYNQeWYTWt+w5fP 0Pg/pTU7oA2It0kPeHaFt9+OZ4AT19KlKfjPio4f8nBtmn7tKdJio/cPTh4vwfUXRIP0 fmgrUiAOuszJnpwio9b9gnEfGgDW9r59OUiR1TK96XivFyiwUJMEtuOePMSxVQK5Pe5o bUBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NNm4eT1ifwyGdyFF4yZLSm2gGfnH6JOgbth3z4vvmRU=; b=m+KHXpAME3tuTBbwUb5IC+FTj+18OJKkrkMHTrOmxgmiwIv7HxKteWtUH88x6Sw/S2 VJTH2zv8WU4UA5l4C/jtK7sz/ugQB+F49iIjHdV1TfmcnoPPSD3qYiDZhvjxNWFReJgj N+IR1DefBjg/BVoNjczAsdJlyky8JR+G3Qgr/7Pfm3pZy6hPHhva5SNADypu86MHeQ6g KEL9VmmuTo8zrjz2DaX6H0gjjOrQ+4CgB60jWwlIxgZW6hf+LEwP4KI6NW73rvebeGz6 7qubvopj77SYITJYEI7Lv35nwR9AtHvPs830M2UzkmDShjgd9BbNrhmCGbod+LwkxblP hWOQ==
X-Gm-Message-State: ABUngve6g7YPXCRDbg3uFinIJmfpXYbc6iJbwrrYrIgV4kGHNA8vOXgsse5/naoCcncm75UNmmkqgutRgwRuNA==
X-Received: by 10.129.78.197 with SMTP id c188mr293108ywb.21.1477460678654; Tue, 25 Oct 2016 22:44:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Tue, 25 Oct 2016 22:43:58 -0700 (PDT)
From: Eric Rescorla 
Date: Wed, 26 Oct 2016 16:43:58 +1100
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114ddac6ebe9c5053fbe1eef
Archived-At: 
Subject: [TLS] draft-ietf-tls-tls13 posted
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: Wed, 26 Oct 2016 05:44:45 -0000

--001a114ddac6ebe9c5053fbe1eef
Content-Type: text/plain; charset=UTF-8

Folks,

I have just posted draft-ietf-tls-tls13-18.

The only wire format change from -17 is that I removed the extra key
derivation stage computing resumption_psk from RMS. This was a
holdover from when we also had a resumption context. Now PSK for
connection N+1 = RMS from connection N. Thanks to Kazuho for
suggesting this simplification.

This draft also makes a number of minor editorial changes that
should make for easier reading.

The two remaining open technical issues I am aware of are both
requirements issues:

1. Can you resume with a different SNI than the one that the
   connection was initiated with [current answer is "no"]?

2. Do you need an application profile to do post-handshake
   client auth [current answer is "no"]?

There has been a bunch of discussion of these on the list but no
consensus declarations from the chairs. These are easy to change
in the draft once the chairs make the call.

As always, comments welcome.

-Ekr

P.S. NSS will be skipping draft-17 and going right to -18. This
should happen before Seoul.

--001a114ddac6ebe9c5053fbe1eef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Folks,

I have just posted dr=
aft-ietf-tls-tls13-18.

The only wire format change=
 from -17 is that I removed the extra key
derivation stage comput=
ing resumption_psk from RMS. This was a
holdover from when we als=
o had a resumption context. Now PSK for
connection N+1 =3D RMS fr=
om connection N. Thanks to Kazuho for
suggesting this simplificat=
ion.

This draft also makes a number of minor edito=
rial changes that
should make for easier reading.

<=
/div>
The two remaining open technical issues I am aware of are both
requirements issues:

1. Can you resume wit=
h a different SNI than the one that the
=C2=A0 =C2=A0connection w=
as initiated with [current answer is "no"]?

<=
div>2. Do you need an application profile to do post-handshake
=
=C2=A0 =C2=A0client auth [current answer is "no"]?

=

There has been a bunch of discussion of these on the list but no=

consensus declarations from the chairs. These are easy to change=

in the draft once the chairs make the call.

=

As always, comments welcome.

-Ekr
<=
br>
P.S. NSS will be skipping draft-17 and going right to -18. Th=
is
should happen before Seoul.



--001a114ddac6ebe9c5053fbe1eef--


From nobody Wed Oct 26 05:15:29 2016
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 92544129406 for ; Wed, 26 Oct 2016 04:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no
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 ci_1OtlcNSjP for ; Wed, 26 Oct 2016 04:36:11 -0700 (PDT)
Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D626C12950C for ; Wed, 26 Oct 2016 04:36:10 -0700 (PDT)
Received: from [127.0.0.1] (unknown [90.63.246.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id B7168541DF for ; Wed, 26 Oct 2016 11:36:07 +0000 (UTC)
To: tls@ietf.org
References:  <20161019155845.D13E21A564@ld9781.wdf.sap.corp>    
From: Olivier Levillain 
Message-ID: <58109527.3000903@ssi.gouv.fr>
Date: Wed, 26 Oct 2016 13:36:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Wed, 26 Oct 2016 05:15:28 -0700
Subject: Re: [TLS] Deprecating alert levels
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: Wed, 26 Oct 2016 11:36:13 -0000

Hi list,

I recently saw a related CVE regarding OpenSSL on oss-security mailing
list: CVE-2016-8610. The original mail is
http://seclists.org/oss-sec/2016/q4/224. As I understand it, the idea is
to send a continuous flow of unauthenticated, warning-level alerts in
the middle of the initial handshake. This leads OpenSSL to keep the
connection open (and apparently to consume some CPU).

Even if this might not be the attack of the century, it may also be
another reason to reconsider how a TLS stack should handle
[multiple|warning|unauthenticated] alerts.

olivier


Le 25/10/2016 03:14, Kyle Nekritz a écrit :
> +1 to both Martin and ekr, I think simplifying these alerts with clearly defined behavior for each alert description is the best way forward.
>
> Kyle 
>
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: Wednesday, October 19, 2016 10:18 PM
> To: Eric Rescorla 
> Cc: tls@ietf.org
> Subject: Re: [TLS] Deprecating alert levels
>
> On 20 October 2016 at 05:28, Eric Rescorla  wrote:
>>> 2.  Are there cases, such as unrecognized name. where it is useful to 
>>> indicate that an alert is not fatal?  If so how should this case be handled?
>>
>> I think this alert was a mistake :)
> In NSS is to tolerate it, but it's an exception.  I'm happier with a lone exception than with atrophied and redundant alert levels continuing as they are.  I'd prefer to take the PR, with a minor amendment noting the hazard caused by unrecognized_name(112).  Clients that intend to accept TLS 1.2 and lower probably have to ignore warning alerts until they see that the server is doing TLS 1.3 or higher.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=1svSdxAuionbHyrUN4ThSCRLZ1pCQuLaO0qtgQ8Dk7A&s=jWxxDB9uWwT6kP_7TcZ4isUa_Z5LNWOhgMX_O1s3oaw&e= 
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Wed Oct 26 10:41:32 2016
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 474351293D8 for ; Wed, 26 Oct 2016 10:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.142
X-Spam-Level: 
X-Spam-Status: No, score=-1.142 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 1PqmMhY7EMBF for ; Wed, 26 Oct 2016 10:41:27 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 81D681293FE for ; Wed, 26 Oct 2016 10:41:27 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0486B433424; Wed, 26 Oct 2016 17:41:27 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E0017433408; Wed, 26 Oct 2016 17:41:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1477503686; bh=Q80M9cEaypEMDrCFnOmPTx1jzTOpZVSFUe4escz2VU0=; l=15882; h=To:References:Cc:From:Date:In-Reply-To:From; b=HmDo28UGAbegjWudOp6nPSQjtzvzABjEPFA4TnNrUNKkglMySW3IR6pobN+gpvXL/ oQ8NAL5E0TZwWqWTGe4gmZZY+wnrd1CHM2bEQLw407A3mHSndeaxfm8P2ybdjLlFkV Z0VTmxg+FzAjk2mXtH8iG30KkNPVR48neHFAeT18=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 89E961FC8B;  Wed, 26 Oct 2016 17:41:26 +0000 (GMT)
To: Victor Vasiliev , Eric Rescorla 
References:  
From: Benjamin Kaduk 
X-Enigmail-Draft-Status: N1110
Message-ID: <4e2b054a-c391-d4f9-c106-d62eb90e2034@akamai.com>
Date: Wed, 26 Oct 2016 12:41:26 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B67C4FAB41CB01B6E43DAF69"
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Wed, 26 Oct 2016 17:41:30 -0000

This is a multi-part message in MIME format.
--------------B67C4FAB41CB01B6E43DAF69
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Picking a message somewhat at random to reply to with some more-general
observations...

On 10/24/2016 05:48 PM, Victor Vasiliev wrote:
> I believe that an ability to resume across different server_name values
> specified in the subjectAltName of a certificate will have a positive
> performance impact on the websites which due to various reasons have
> to fetch
> resources from different servers.  A particular use case I have in
> mind is when
> a website maintains a pool of servers, say, *.cdn.example.com
> ,
> and supplies a
> specific server directly in a resource URL.  In that case, all the servers
> already share a wildcard certificate with a secret, so they can share
> a ticket
> key too, meaning it makes sense for them to accept the ticket issued
> by another
> server in the pool.
>

I think it is useful to distinguish between this case, where
[cdn.]example.com is the owner of all the content involved, from other
co-tenanted names that have different content owners, such as from a
shared hosting service.  The wildcard cert is pretty clearly in the
"same content owner" case, but even subjectAltNames in a single cert do
not necessarily provide the same indication -- I understand that some
CDNs offer a lower-cost TLS option by means of being a SAN on a cert
that shares names with many different CDN customers.

So, even the server's configuration settings may change as a result of
SNI (e.g., a hosting provider may let customers configure settings
differently even when served from the same TLS server).

> There are potential confusion issues associated with using a ticket for a
> different server name, both with the server becoming confused and the
> client
> becoming confused.  On the server side, this requires implementations
> to know
> how to handle SNI value change.  I suggest that the servers should
> explicitly
> indicate to the client that a newly issued ticket may be used for all the
> subjectAltName values present in the server's certificate.
>

I would argue that changing SNI value on resumption or 0RTT only has a
hope of making sense in the "same content owner" case ... but the client
may not have an easy way of knowing, in the absence of an explicit
server signal as you propose.

> Clients must also account for any per-host differences before offering a
> ticket.  For instance, web browsers typically require users to pick a
> certificate for each domain they authenticate to, so resumption across
> different SNI values should obviously not happen here.  One can also
> imagine,
> say, a client which uses different cipher configuration or a different
> set of
> trust anchors for each host.  In all of those cases, it is on the
> client to not
> cross-resume, but a lot of those concerns are application-specific in
> nature,
> so I am not sure how much guidance can the TLS specification provide
> on this
> matter.
>
>

Things are getting messy enough that I'm starting to lean towards just
not doing it at all (perhaps with the carve-out for future behavior that
Chrstian wants, if we can satisfy ourselves that it won't ossify).

-Ben

> On Thu, Oct 20, 2016 at 8:33 PM, Eric Rescorla  > wrote:
>
>     We used to explicitly say that you had to check SNI for 0-RTT (but
>     didn't say anything about resumption). On the principle that 0-RTT and
>     resumption should be the same I removed that, but it turns out that
>     the document doesn't actually have any rule at all other than the one
>     we've inherited from RFC 6066, which clearly says that you can't
>     resume with a different SNI [0].
>
>     Following the discussion in
>     https://github.com/tlswg/tls13-spec/issues/720
>     
>     I've added a statement
>     to the draft clarifying that the RFC 6066 rule still applies [1]
>
>     With that said, it does seem like there might be situations where it
>     would be useful to allow resumption/0-RTT with different SNIs. My
>     intuition (partly informed by [2]) is that this is something we should
>     be pretty careful about and have the server opt-in explicitly (if at
>     all) but I'm willing to be wrong about that.
>
>     Comments?
>     -Ekr
>
>
>     [0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
>     
>     [1] https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121
>     
>     [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>     
>
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org 
>     https://www.ietf.org/mailman/listinfo/tls
>     
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------B67C4FAB41CB01B6E43DAF69
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Picking a message somewhat at random to reply to with some more-general
      observations...

    

    
On 10/24/2016 05:48 PM, Victor Vasiliev
      wrote:

    

    

      
      

        
I believe that an ability to resume across different
          server_name values

        
specified in the subjectAltName of a certificate will have
          a positive

        
performance impact on the websites which due to various
          reasons have to fetch

        
resources from different servers.  A particular use case I
          have in mind is when

        
a website maintains a pool of servers, say, *.cdn.example.com,
          and supplies a

        
specific server directly in a resource URL.  In that case,
          all the servers

        
already share a wildcard certificate with a secret, so they
          can share a ticket

        
key too, meaning it makes sense for them to accept the
          ticket issued by another

        
server in the pool.

        


        

      

    

    

    I think it is useful to distinguish between this case, where
    [cdn.]example.com is the owner of all the content involved, from
    other co-tenanted names that have different content owners, such as
    from a shared hosting service.  The wildcard cert is pretty clearly
    in the "same content owner" case, but even subjectAltNames in a
    single cert do not necessarily provide the same indication -- I
    understand that some CDNs offer a lower-cost TLS option by means of
    being a SAN on a cert that shares names with many different CDN
    customers.

    

    So, even the server's configuration settings may change as a result
    of SNI (e.g., a hosting provider may let customers configure
    settings differently even when served from the same TLS server).

    

    

      

        

          
There are potential confusion issues associated with
            using a ticket for a

          
different server name, both with the server becoming
            confused and the client

          
becoming confused.  On the server side, this requires
            implementations to know

          
how to handle SNI value change.  I suggest that the
            servers should explicitly

          
indicate to the client that a newly issued ticket may be
            used for all the

          
subjectAltName values present in the server's
            certificate.

        

        


        

      

    

    

    I would argue that changing SNI value on resumption or 0RTT only has
    a hope of making sense in the "same content owner" case ... but the
    client may not have an easy way of knowing, in the absence of an
    explicit server signal as you propose.

    

    

      

        

          
Clients must also account for any per-host differences
            before offering a

          
ticket.  For instance, web browsers typically require
            users to pick a

          
certificate for each domain they authenticate to, so
            resumption across

          
different SNI values should obviously not happen here. 
            One can also imagine,

          
say, a client which uses different cipher configuration
            or a different set of

          
trust anchors for each host.  In all of those cases, it
            is on the client to not

          
cross-resume, but a lot of those concerns are
            application-specific in nature,

          
so I am not sure how much guidance can the TLS
            specification provide on this

          
matter.

        

        


        

        


        

      

    

    

    Things are getting messy enough that I'm starting to lean towards
    just not doing it at all (perhaps with the carve-out for future
    behavior that Chrstian wants, if we can satisfy ourselves that it
    won't ossify).

    

    -Ben

    

    

      

        

          
On Thu, Oct 20, 2016 at 8:33 PM, Eric
            Rescorla <ekr@rtfm.com>
            wrote:

            

              

                
We used to explicitly say that you had to check SNI
                  for 0-RTT (but

                

                
didn't say anything about resumption). On the
                  principle that 0-RTT and

                
resumption should be the same I removed that, but
                  it turns out that

                
the document doesn't actually have any rule at all
                  other than the one

                
we've inherited from RFC 6066, which clearly says
                  that you can't

                
resume with a different SNI [0].

                


                

                
Following the discussion in

                
                
to the draft clarifying that the RFC 6066 rule
                  still applies [1]

                


                

                
With that said, it does seem like there might be
                  situations where it

                
would be useful to allow resumption/0-RTT with
                  different SNIs. My

                
intuition (partly informed by [2]) is that this is
                  something we should

                
be pretty careful about and have the server opt-in
                  explicitly (if at

                
all) but I'm willing to be wrong about that.

                


                

                
Comments?

                
-Ekr

                


                

                


                

                
                
                
                


                

              

              

              _______________________________________________

              TLS mailing list

              TLS@ietf.org

              https://www.ietf.org/mailman/listinfo/tls

              

            

          

          

        

      

      

      

      

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


    

    

  


--------------B67C4FAB41CB01B6E43DAF69--


From nobody Wed Oct 26 11:11:12 2016
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 4F6B01295B5 for ; Wed, 26 Oct 2016 11:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.131
X-Spam-Level: 
X-Spam-Status: No, score=-3.131 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_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MhgWtTHJqM3L for ; Wed, 26 Oct 2016 11:11:08 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A328D129426 for ; Wed, 26 Oct 2016 11:11:08 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id n189so13641809qke.0 for ; Wed, 26 Oct 2016 11:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T20ihYTMIHv+GIXvkeKe3kA/TR92lXh6E8iKcnMQXuk=; b=YAbq6JSJPpeDH8O4zS2PoNV1wc+iHSeAmDeb5Fsx3z1jDU3ACe/6VMZ8z081bUvyRW 9XELUs/rfNezJPwlcEw1XjRoGX2W5LGjNwnm7vw0mUM0lN/g6Tj2V+Pq1bglJKl3o1Va /Yn0Zac8qQaqn0RxCl2jgy2tHKEhonbotQxCkW9q0MAvlh4nnxC/SOzyOjyZeH4Rr5dw 0516Hp6k7AhlBlbpkj5N5AbanHXduB2/Mn/F7LAQtfDWttyzEGE7VXE2j16TeDWM3DF4 Gkch3sPzUFZeAIJiI20kTCRVdrJ4BMdzt5PNCt75/04Gmbsg3tcDX6Hh/g69qa9nAG4u hQpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T20ihYTMIHv+GIXvkeKe3kA/TR92lXh6E8iKcnMQXuk=; b=lRoqwlaMNSY0hnYeTBLgqu1pm5WsAkRyOy2bBaby2lY3p14Q0UHG90jDy8qwt5q8/+ mya6QSxqp1kJMUF6RfqmGgXpTlhYbzLsviwK0lgepQtlm1h1rKWf218VxgPkwIz3RM0T e28Kynb64Zm+a1WxrebB1vvFejrFN0HnQs8n2F4DRMCGBD/08lcVrWlZCZ81xljGVAzj J/8tnhYXPWSHhUBsmohQcHIocgdskQ1amanGm93Ifm8O6r/LJfgp7BWdVm62zAmrOXP9 6L3DuRTnEsZio6nGaj58o26kYgR373+WbQZ4DnINzA/LfyLiyq0fnGiUTzfrwTUw8lnI 3shg==
X-Gm-Message-State: ABUngveBQpGmOtAZNb97SZtvYzcjkk+BlxhWznG/gWRwo8btt+ki26kcBD0suLxzNz0gBEAZyB2jtpIimiPEGu3Z
X-Received: by 10.55.23.65 with SMTP id i62mr2545897qkh.238.1477505467588; Wed, 26 Oct 2016 11:11:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.98.79 with HTTP; Wed, 26 Oct 2016 11:11:06 -0700 (PDT)
In-Reply-To: <4e2b054a-c391-d4f9-c106-d62eb90e2034@akamai.com>
References:   <4e2b054a-c391-d4f9-c106-d62eb90e2034@akamai.com>
From: Victor Vasiliev 
Date: Wed, 26 Oct 2016 14:11:06 -0400
Message-ID: 
To: Benjamin Kaduk 
Content-Type: multipart/alternative; boundary=001a1147a0528d20df053fc88ced
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Wed, 26 Oct 2016 18:11:11 -0000

--001a1147a0528d20df053fc88ced
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 26, 2016 at 1:41 PM, Benjamin Kaduk  wrote:

> Picking a message somewhat at random to reply to with some more-general
> observations...
>
> On 10/24/2016 05:48 PM, Victor Vasiliev wrote:
>
> I believe that an ability to resume across different server_name values
> specified in the subjectAltName of a certificate will have a positive
> performance impact on the websites which due to various reasons have to
> fetch
> resources from different servers.  A particular use case I have in mind is
> when
> a website maintains a pool of servers, say, *.cdn.example.com
> ,
> and supplies a
> specific server directly in a resource URL.  In that case, all the servers
> already share a wildcard certificate with a secret, so they can share a
> ticket
> key too, meaning it makes sense for them to accept the ticket issued by
> another
> server in the pool.
>
>
> I think it is useful to distinguish between this case, where [cdn.]
> example.com is the owner of all the content involved, from other
> co-tenanted names that have different content owners, such as from a shared
> hosting service.  The wildcard cert is pretty clearly in the "same content
> owner" case, but even subjectAltNames in a single cert do not necessarily
> provide the same indication -- I understand that some CDNs offer a
> lower-cost TLS option by means of being a SAN on a cert that shares names
> with many different CDN customers.
>
> So, even the server's configuration settings may change as a result of SNI
> (e.g., a hosting provider may let customers configure settings differently
> even when served from the same TLS server).
>
> There are potential confusion issues associated with using a ticket for a
> different server name, both with the server becoming confused and the
> client
> becoming confused.  On the server side, this requires implementations to
> know
> how to handle SNI value change.  I suggest that the servers should
> explicitly
> indicate to the client that a newly issued ticket may be used for all the
> subjectAltName values present in the server's certificate.
>
>
> I would argue that changing SNI value on resumption or 0RTT only has a
> hope of making sense in the "same content owner" case ... but the client
> may not have an easy way of knowing, in the absence of an explicit server
> signal as you propose.
>
>
I agree with your points, hence I have suggested explicit signal.  This is
more of a performance issue than a security issue, since resumption by
nature
requires the server to have access to the resumption key.


> Clients must also account for any per-host differences before offering a
> ticket.  For instance, web browsers typically require users to pick a
> certificate for each domain they authenticate to, so resumption across
> different SNI values should obviously not happen here.  One can also
> imagine,
> say, a client which uses different cipher configuration or a different set
> of
> trust anchors for each host.  In all of those cases, it is on the client
> to not
> cross-resume, but a lot of those concerns are application-specific in
> nature,
> so I am not sure how much guidance can the TLS specification provide on
> this
> matter.
>
>
>
> Things are getting messy enough that I'm starting to lean towards just not
> doing it at all (perhaps with the carve-out for future behavior that
> Chrstian wants, if we can satisfy ourselves that it won't ossify).
>
>
Web browsers already have to implement all of those policy filters for
HTTP/2
connection pooling, so I do not expect this to be that much of a burden to
implement.  Since the client can always choose to not send a ticket, it can
always decide to not resume across multiple domains in order to simplify the
implementation.

  -- Victor.

--001a1147a0528d20df053fc88ced
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Oct 26, 2016 at 1:41 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:

 =20
   =20
 =20
  

    Picking a message somewhat at random to reply to with some more-gen=
eral
      observations...

    

    
On 10/24/2016=
 05:48 PM, Victor Vasiliev
      wrote:

    

    

     =20
      

        
I believe that an ability to resume across different
          server_name values

        
specified in the subjectAltName of a certificate will have
          a positive

        
performance impact on the websites which due to various
          reasons have to fetch

        
resources from different servers.=C2=A0 A particular use case =
I
          have in mind is when

        
a website maintains a pool of servers, say, *.cdn.e=
xample.com,
          and supplies a

        
specific server directly in a resource URL.=C2=A0 In that case=
,
          all the servers

        
already share a wildcard certificate with a secret, so they
          can share a ticket

        
key too, meaning it makes sense for them to accept the
          ticket issued by another

        
server in the pool.

        


        

      

    

    

    I think it is useful to distinguish between this case, where
    [cdn.]example.com =
is the owner of all the content involved, from
    other co-tenanted names that have different content owners, such as
    from a shared hosting service.=C2=A0 The wildcard cert is pretty clearl=
y
    in the "same content owner" case, but even subjectAltNames in=
 a
    single cert do not necessarily provide the same indication -- I
    understand that some CDNs offer a lower-cost TLS option by means of
    being a SAN on a cert that shares names with many different CDN
    customers.

    

    So, even the server's configuration settings may change as a result
    of SNI (e.g., a hosting provider may let customers configure
    settings differently even when served from the same TLS server).

    

    

      

        

          
There are potential confusion issues associated with
            using a ticket for a

          
different server name, both with the server becoming
            confused and the client

          
becoming confused.=C2=A0 On the server side, this requires
            implementations to know

          
how to handle SNI value change.=C2=A0 I suggest that the
            servers should explicitly

          
indicate to the client that a newly issued ticket may be
            used for all the

          
subjectAltName values present in the server's
            certificate.

        

        


        

      

    

    

    I would argue that changing SNI value on resumption or 0RTT only has
    a hope of making sense in the "same content owner" case ... b=
ut the
    client may not have an easy way of knowing, in the absence of an
    explicit server signal as you propose.

    

I agree with you=
r points, hence I have suggested explicit signal.=C2=A0 This is
m=
ore of a performance issue than a security issue, since resumption by natur=
e
requires the server to have access to the resumption key.
=

=C2=A0

    

      

        

          
Clients must also account for any per-host differences
            before offering a

          
ticket.=C2=A0 For instance, web browsers typically require
            users to pick a

          
certificate for each domain they authenticate to, so
            resumption across

          
different SNI values should obviously not happen here.=C2=A0
            One can also imagine,

          
say, a client which uses different cipher configuration
            or a different set of

          
trust anchors for each host.=C2=A0 In all of those cases, it
            is on the client to not

          
cross-resume, but a lot of those concerns are
            application-specific in nature,

          
so I am not sure how much guidance can the TLS
            specification provide on this

          
matter.

        

        


        

        


        

      

    

    

    Things are getting messy enough that I'm starting to lean towards
    just not doing it at all (perhaps with the carve-out for future
    behavior that Chrstian wants, if we can satisfy ourselves that it
    won't ossify).

    

Web browsers already ha=
ve to implement all of those policy filters for HTTP/2
connection=
 pooling, so I do not expect this to be that much of a burden to
=
implement.=C2=A0 Since the client can always choose to not send a ticket, i=
t can
always decide to not resume across multiple domains in orde=
r to simplify the
implementation.

=
=C2=A0 -- Victor.


--001a1147a0528d20df053fc88ced--


From nobody Wed Oct 26 19:56:36 2016
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 3656E1299B8 for ; Wed, 26 Oct 2016 19:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 Gp5rMh7ooLtL for ; Wed, 26 Oct 2016 19:56:34 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92631299B7 for ; Wed, 26 Oct 2016 19:56:33 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id w3so28354380ywg.1 for ; Wed, 26 Oct 2016 19:56:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YSX338bPV8+ob/mwLYPZCOfglSgakryeB2CnVEzbABI=; b=HoIaeEvt7ueq7B/Sg/GD/IuYYARxANqfrNpisyb/Xejnb1J7gAYb/6A/CDUa7prDu/ sNpVuOJkV8XkxtaHr7p4ngB+grTkKZmQXJRo6I6zuVyYlrO8lH9dmxqyIyFWDl0cImpp nGJSjVBu72tQxtwFr2WNSsqG9Inhns65zWQz1ST5+8xP5tQ5woJSA6m+DLiFuSWkvEIJ tjCZ+PkNuUb7uOFj8C5rEioIuLn3YcjRWWfXoQ071AX4qcy6upSL+yBcNPCBuA/mcEo+ 5SzkGNxm9eiCxq2VBS8s2ZopRcfqacrGQPFFARZGYmCOndnJWQTi+xTdJ7KOYtfqjjty bzfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YSX338bPV8+ob/mwLYPZCOfglSgakryeB2CnVEzbABI=; b=mPBlrcGnH2LPoncO+qwnJqkMgzl2wh9Zk9SEyU/zTdAQeYMqEDib/iiP3MPstvxNqB vZiEoAxNd1nhEB2p7fYJPtidu3xdlVivzjdgHj1ExOQI2bWRQoGmNmfCH9dAeKZr0VRB 1/WSX6/go2lWob/JHTL2tjYTBv19/9UEpJFxIg3eLKZDe2XF8Ym3o1BFqqlaO9GRreEx OMn/8XBIeizQx4mZQ2Qu1AFTz5zFvI5bYbAy3hOsjm3F0FzbMmmmrNa2qTYZp4s/mYBT vfBs0msFxtulj+/W34bFndFYf8uvDmQE/nGOmu23HuFv4YCshdN8k5hUwOnQXo6iMlQM 8oAw==
X-Gm-Message-State: ABUngvf4HUDsCHbR/H/lpYM2y1B1Cq1UAXcmcz03VqiTJ/qJAijZX0BJ3zSRloAJRUqIQOVh4i/otseX/6yYCA==
X-Received: by 10.36.239.65 with SMTP id i62mr5131510ith.57.1477536992854; Wed, 26 Oct 2016 19:56:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.118.216 with HTTP; Wed, 26 Oct 2016 19:56:12 -0700 (PDT)
From: Joseph Salowey 
Date: Wed, 26 Oct 2016 19:56:12 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c1170969a169f053fcfe34d
Archived-At: 
Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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, 27 Oct 2016 02:56:35 -0000

--94eb2c1170969a169f053fcfe34d
Content-Type: text/plain; charset=UTF-8

This is a working group last call announcement for draft-ietf-tls-tls13-18,
to run through November 20. If possible, we would like to receive comments
on the list by November 13 so they can be discussed at the meeting in
Seoul. We hope to address any substantive issues raised during that process
shortly thereafter.

In order to allow for cryptographic review, we will delay submission of the
draft to the IESG until the end of January 2017; there will be an
opportunity to address any issues discovered by the cryptographic community
prior to submission to the IESG.

Cheers,

Joe

--94eb2c1170969a169f053fcfe34d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This i=
s a working group last call announcement for=C2=A0draft-ietf-tls-tls13-18, to run through=C2=A0November 20. If possible=
, we=C2=A0would like to receive comments on the list by=C2=A0November 13=C2=A0=
so they can=C2=A0be discussed at th=
e meeting in Seoul. We hope to address any=C2=A0substantive issues raised during that process shortly thereaft=
er.

In order to allow for cryptographic review, we will delay submissi=
on=C2=A0of the draft to the IESG until the=
 end of January 2017; there=C2=A0wi=
ll be an opportunity to address any issues discovered by the=C2=A0cryptographic community prior to submission =
to the IESG.

Cheers,

Joe



--94eb2c1170969a169f053fcfe34d--


From nobody Wed Oct 26 22:27:15 2016
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 D7114129B96 for ; Wed, 26 Oct 2016 22:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Z8gu3ApFsJYK for ; Wed, 26 Oct 2016 22:27:12 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22341293F0 for ; Wed, 26 Oct 2016 22:27:11 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id 140so9407676wmv.0 for ; Wed, 26 Oct 2016 22:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hWas8up3caf4fjEjU2YJyKcRqe6vNQFvgaXnokCGgp8=; b=OymF/DI6hfQdhMkOyJ5uwcEzREXwySTdm6L09HSZTh9jtFn2I48Db6I+QETDYaPQ92 qswbtdn/I1Dgc9BjMUxPTOfiWdAT/ZXGHBJMKJm5saqBOmrxGRsSMfAjfmqQ7wh072FO hFExUDagVFz7CUiO8ZxHAeh5Q+nBS81+EmM9KLynZvBdALfDROnwXUdcTbpEfV0O8VcW JAC5AYJDym5lIoqmCO9DAPQlkA7ffDe+cKXzuZc05ggqGdaF4q1RRD3RhIzn4mc8fEsY 8QqpPNuvQ/TW4d0nuGlZ6ykz2thlN3dBqyZdZzWD3USJZDGWpsbd6DxgjvXVucCd34dy lPXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hWas8up3caf4fjEjU2YJyKcRqe6vNQFvgaXnokCGgp8=; b=VoJ0uuCKVo5LD+3z7iiWrE8DeSwdB2ZG1ViQxv+tUr098LQ/1NXMvVyLZV1Zcd/Tgo 52dMIFJLHYOrTopVrr56bkBXubhoehT6RLA/7Dp/7IciktZU9VneexLohuc39Q9uc3CW J/JfryUQSrpUajVm8ylnwfjT9VyNHmnMCwwsxd37/+ykXgbqDnckHF9SQMSgyqRf1Vdf 1Otz3A45GAp2uKPbnyVw0ph+My67P0vXO4xQJ0h0X8tSKIWos9n/kBOJBhWKXC3o02ix 5oyO/RGokIMiMsDPc7MlCwtz1VBMuGIcc2VQbRAPzejYIbWjcPLEi7rOywJYH9v0O+dw eUQQ==
X-Gm-Message-State: ABUngvdn+mP9rPVzPrC8/tky9JbAMQXk2AYhxU5uTOwG63hOWxFNnOAl2ViWmZJmK/FGYH4XQnWL3yldNOmpqA==
X-Received: by 10.28.74.15 with SMTP id x15mr1775703wma.31.1477546030385; Wed, 26 Oct 2016 22:27:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Wed, 26 Oct 2016 22:27:09 -0700 (PDT)
In-Reply-To: 
References: 
From: Kazuho Oku 
Date: Thu, 27 Oct 2016 14:27:09 +0900
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls13 posted
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, 27 Oct 2016 05:27:14 -0000

Hi,

Thank you for posting draft-18, and thank you for the simplification of RMS.

I have finished implementing resumption and early-data in picotls. The
effort started just before draft-17 was published, so it would be fair
to say that my effort is solely based on the up-to-date specification.

I am happy to report that all I have found is one minor issue.

The issue I saw is discordance between PSKIdentity.identity and
NewSessionTicket.ticket.

In draft-18, PSKIdentity.identity is defined as <0..2^16-1>. OTOH
NewSessionTicket.ticket is <1..2^16-1>.

Is there any reason to only allow a zero-length identity for the former?

My understanding is that when resuming a session, the value of
NewSessionTicket.ticket is sent as PSKIdentity.identity. So to me, it
seems more natural if the permitted range of the two arrays were
equal.

Please forgive me for the fuss if the difference is intentional.

2016-10-26 14:43 GMT+09:00 Eric Rescorla :
> Folks,
>
> I have just posted draft-ietf-tls-tls13-18.
>
> The only wire format change from -17 is that I removed the extra key
> derivation stage computing resumption_psk from RMS. This was a
> holdover from when we also had a resumption context. Now PSK for
> connection N+1 = RMS from connection N. Thanks to Kazuho for
> suggesting this simplification.
>
> This draft also makes a number of minor editorial changes that
> should make for easier reading.
>
> The two remaining open technical issues I am aware of are both
> requirements issues:
>
> 1. Can you resume with a different SNI than the one that the
>    connection was initiated with [current answer is "no"]?
>
> 2. Do you need an application profile to do post-handshake
>    client auth [current answer is "no"]?
>
> There has been a bunch of discussion of these on the list but no
> consensus declarations from the chairs. These are easy to change
> in the draft once the chairs make the call.
>
> As always, comments welcome.
>
> -Ekr
>
> P.S. NSS will be skipping draft-17 and going right to -18. This
> should happen before Seoul.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Kazuho Oku


From nobody Wed Oct 26 22:30:56 2016
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 B579C129BBD for ; Wed, 26 Oct 2016 22:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 x40PrR8UIGnP for ; Wed, 26 Oct 2016 22:30:50 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C72B129BA9 for ; Wed, 26 Oct 2016 22:30:50 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id p22so15581826ywe.0 for ; Wed, 26 Oct 2016 22:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GutMKewEr4rTCqpZWZmJ9ve77NXDohRbqw0kt9Zg86Y=; b=NAsmeIza6EQzLcUfFpGq5LR/HKhUp1+j57zqtNyM2UHvB3JlIIgvI6IykypSlHKLBF Gs8xsdjea70Y7P6L96wkrUR/AwfDo1rASa1QTjyH1CrdxRsTv7Q8pjpTpwGSaFnto3xk wuEO9kd1OVCwvUO5bFjgY4Xn1WWrf/JgHRnP3tb/4HMDkM0p0vgoLD02E77T5GYTdOoT nIY7F2Sq/M3vtpsiI7JzWraGPLHVAc3b69k0UIUBsR+egyFYsiPAnxbEWYNRccb6xEjP MrrOCYMPCkGyIQgh8ay5FL0ccsTPSMhMhsbSLUPtdJ1hO1OoFYrPizCT1TMF00Cf31il /AoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GutMKewEr4rTCqpZWZmJ9ve77NXDohRbqw0kt9Zg86Y=; b=CyXfs5sZUtp9llzpapqRecLt07hchZ0sX/f9jiFrnGvb6E8RKA7bcqAulVJ+aAfxSJ BGf8FFRU1GMkIMjn9xA05b97+KnW36bgmQkH03oOa4nRBLmF6HvZi88BKZiFzwu+GGQ8 fFkGVzujhdU01QzvBbWesNip+a7ma4Fd3bk/wFZNxCb+lcLG4ZvUNAK74AOgtD4Ve9eM ePzGYx2kY6wq5SsM3ETOQ0bmUjSkRg86tv8hkZ2NFoO7Hbu120QAofv6c0EW6bnHfwb5 OWxYSegGx4UivLUtK8l/HYahKCrqLFDYUpYHRMKXIK8Q1Hv6Vi8zbNraHOtkpV4Sb8E2 NGdw==
X-Gm-Message-State: ABUngvcNhtTleFdLeuFgX1Zj/jHARbRPoyw7JpFhSaRrEevA2FJWnnalOR5yc3TrvBM3Q37kmcufp1JQ4coEXg==
X-Received: by 10.129.53.206 with SMTP id c197mr5020546ywa.205.1477546249850;  Wed, 26 Oct 2016 22:30:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Wed, 26 Oct 2016 22:30:09 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Thu, 27 Oct 2016 16:30:09 +1100
Message-ID: 
To: Kazuho Oku 
Content-Type: multipart/alternative; boundary=001a11421a265cc384053fd20bd2
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls13 posted
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, 27 Oct 2016 05:30:54 -0000

--001a11421a265cc384053fd20bd2
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 27, 2016 at 4:27 PM, Kazuho Oku  wrote:

> Hi,
>
> Thank you for posting draft-18, and thank you for the simplification of
> RMS.
>
> I have finished implementing resumption and early-data in picotls. The
> effort started just before draft-17 was published, so it would be fair
> to say that my effort is solely based on the up-to-date specification.
>
> I am happy to report that all I have found is one minor issue.
>
> The issue I saw is discordance between PSKIdentity.identity and
> NewSessionTicket.ticket.
>
> In draft-18, PSKIdentity.identity is defined as <0..2^16-1>. OTOH
> NewSessionTicket.ticket is <1..2^16-1>.
>
> Is there any reason to only allow a zero-length identity for the former?
>
> My understanding is that when resuming a session, the value of
> NewSessionTicket.ticket is sent as PSKIdentity.identity. So to me, it
> seems more natural if the permitted range of the two arrays were
> equal.
>
> Please forgive me for the fuss if the difference is intentional.
>

Well, you could have an external PSK which I suppose might be zero length.

But I also wouldn't argue if we required this to be nonzero length.

-Ekr


> 2016-10-26 14:43 GMT+09:00 Eric Rescorla :
> > Folks,
> >
> > I have just posted draft-ietf-tls-tls13-18.
> >
> > The only wire format change from -17 is that I removed the extra key
> > derivation stage computing resumption_psk from RMS. This was a
> > holdover from when we also had a resumption context. Now PSK for
> > connection N+1 = RMS from connection N. Thanks to Kazuho for
> > suggesting this simplification.
> >
> > This draft also makes a number of minor editorial changes that
> > should make for easier reading.
> >
> > The two remaining open technical issues I am aware of are both
> > requirements issues:
> >
> > 1. Can you resume with a different SNI than the one that the
> >    connection was initiated with [current answer is "no"]?
> >
> > 2. Do you need an application profile to do post-handshake
> >    client auth [current answer is "no"]?
> >
> > There has been a bunch of discussion of these on the list but no
> > consensus declarations from the chairs. These are easy to change
> > in the draft once the chairs make the call.
> >
> > As always, comments welcome.
> >
> > -Ekr
> >
> > P.S. NSS will be skipping draft-17 and going right to -18. This
> > should happen before Seoul.
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
>
>
> --
> Kazuho Oku
>

--001a11421a265cc384053fd20bd2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 27, 2016 at 4:27 PM, Kazuho Oku <kazuhooku@gmail.com=
> wrote:
Hi,



Thank you for posting draft-18, and thank you for the simplification of RMS=
.



I have finished implementing resumption and early-data in picotls. The

effort started just before draft-17 was published, so it would be fair

to say that my effort is solely based on the up-to-date specification.



I am happy to report that all I have found is one minor issue.



The issue I saw is discordance between PSKIdentity.identity and

NewSessionTicket.ticket.



In draft-18, PSKIdentity.identity is defined as <0..2^16-1>. OTOH

NewSessionTicket.ticket is <1..2^16-1>.



Is there any reason to only allow a zero-length identity for the former?


My understanding is that when resuming a session, the value of

NewSessionTicket.ticket is sent as PSKIdentity.identity. So to me, it

seems more natural if the permitted range of the two arrays were

equal.



Please forgive me for the fuss if the difference is intentional.

Well, you could have an external PSK which I supp=
ose might be zero length.

But I also wouldn't =
argue if we required this to be nonzero length.

-E=
kr





2016-10-26 14:43 GMT+09:00 Eric Rescorla <ekr@rtfm.com>:

> Folks,

>

> I have just posted draft-ietf-tls-tls13-18.

>

> The only wire format change from -17 is that I removed the extra key
> derivation stage computing resumption_psk from RMS. This was a

> holdover from when we also had a resumption context. Now PSK for

> connection N+1 =3D RMS from connection N. Thanks to Kazuho for

> suggesting this simplification.

>

> This draft also makes a number of minor editorial changes that

> should make for easier reading.

>

> The two remaining open technical issues I am aware of are both

> requirements issues:

>

> 1. Can you resume with a different SNI than the one that the

>=C2=A0 =C2=A0 connection was initiated with [current answer is "no=
"]?

>

> 2. Do you need an application profile to do post-handshake

>=C2=A0 =C2=A0 client auth [current answer is "no"]?

>

> There has been a bunch of discussion of these on the list but no

> consensus declarations from the chairs. These are easy to change

> in the draft once the chairs make the call.

>

> As always, comments welcome.

>

> -Ekr

>

> P.S. NSS will be skipping draft-17 and going right to -18. This

> should happen before Seoul.

>

>


> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls

>







--

Kazuho Oku





--001a11421a265cc384053fd20bd2--


From nobody Wed Oct 26 22:42:00 2016
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 93BA6129BF1 for ; Wed, 26 Oct 2016 22:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BrGPAmVmzgrY for ; Wed, 26 Oct 2016 22:41:57 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB390129BE4 for ; Wed, 26 Oct 2016 22:41:56 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id 140so9890367wmv.0 for ; Wed, 26 Oct 2016 22:41:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nIjFGYaDbeI/wi3YTg4bM9B+0l9pKLy4NWjqJ+jYunk=; b=lWRIVgS7ZTQJaBcTM3d6UOHg7ICtQmeRFn6dFgoalKMzgAaq3wLRNYr96rMLhIH3PI WGEynIiuQ8Ob5vJQVRrzSet/QDEeB02ZjHTlDUfnCK0Q5FadQAM94jxnIlgjHpfEbd6n GzVIqr2GV4AoFIlSDlsYDuoRAxSkAEjiZw+AMwAlZKe+SQInkAXP5X0OXa5cxS3rRyVM iUUrVssTNS3xPsrUXZOWfON/f/M2pneI3wBxW89HgaN2iV4z9ju/H7/zx/xsvvF+KFMQ h1PkHh6yJz51VPOqPXcj7OMqD9k3DXwc5hUh1AV8rfZ4auu2vJ3OHBN/pTNVb5s24jxm JW5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nIjFGYaDbeI/wi3YTg4bM9B+0l9pKLy4NWjqJ+jYunk=; b=l8eqbHWhacGlFcyiAYkQw9hTb0CMwkXSg5v8dORBRDbwHlGmbibMF58CN0qpxQ9LjO yj1lnWE/PQ3InrNMtNp03kcUiPkC2cZzsWVATwrrpcsRC+KPUrtb606Bm9JcsPVdNi2J M05idJLDKz4qH5QV7fVo15q2SvpJC9KHTPJFvDO8QMqpgHua8wMGv5J75Tng6bzjcb0V rFVYBT9/mlDfblM2NayTv4suXfYJGaZNH40fy6WQE0Kx/XbkN83Mp8dFG2Fwx3QalWUZ rqIunTjkmubx0RDRefzuY/UC7oq2Ds/Fcesuhq4MCxYbNcCxgGHkP1iM97dtw9ss1ydo dXdA==
X-Gm-Message-State: ABUngvcqQMP32rNu/v0SfaOYrSj+qNrrZr+DzrIhZ64E3dPkPyN8WVMdSvOKnS+x/VUm4fdds2ojkyL7YHo25w==
X-Received: by 10.194.177.230 with SMTP id ct6mr5021424wjc.145.1477546915198;  Wed, 26 Oct 2016 22:41:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Wed, 26 Oct 2016 22:41:54 -0700 (PDT)
In-Reply-To: 
References:   
From: Kazuho Oku 
Date: Thu, 27 Oct 2016 14:41:54 +0900
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls13 posted
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, 27 Oct 2016 05:41:58 -0000

2016-10-27 14:30 GMT+09:00 Eric Rescorla :
>
>
> On Thu, Oct 27, 2016 at 4:27 PM, Kazuho Oku  wrote:
>>
>> Hi,
>>
>> Thank you for posting draft-18, and thank you for the simplification of
>> RMS.
>>
>> I have finished implementing resumption and early-data in picotls. The
>> effort started just before draft-17 was published, so it would be fair
>> to say that my effort is solely based on the up-to-date specification.
>>
>> I am happy to report that all I have found is one minor issue.
>>
>> The issue I saw is discordance between PSKIdentity.identity and
>> NewSessionTicket.ticket.
>>
>> In draft-18, PSKIdentity.identity is defined as <0..2^16-1>. OTOH
>> NewSessionTicket.ticket is <1..2^16-1>.
>>
>> Is there any reason to only allow a zero-length identity for the former?
>>
>> My understanding is that when resuming a session, the value of
>> NewSessionTicket.ticket is sent as PSKIdentity.identity. So to me, it
>> seems more natural if the permitted range of the two arrays were
>> equal.
>>
>> Please forgive me for the fuss if the difference is intentional.
>
>
> Well, you could have an external PSK which I suppose might be zero length.
>
> But I also wouldn't argue if we required this to be nonzero length.

Thank you for the clarification.

Yes, having a zero-length external PSK makes sense.

And for the same reason, I would argue that having a zero-length
session identifier makes sense as well. For a client-server pair that
only talk to the other, a zero-length session identifier would work
well.

So if we are going to align the ranges of the two arrays, it might
make more sense to allow zero-length for both of them, instead of
disallowing it.

Please forgive me for the nit-pick.

> -Ekr
>
>>
>> 2016-10-26 14:43 GMT+09:00 Eric Rescorla :
>> > Folks,
>> >
>> > I have just posted draft-ietf-tls-tls13-18.
>> >
>> > The only wire format change from -17 is that I removed the extra key
>> > derivation stage computing resumption_psk from RMS. This was a
>> > holdover from when we also had a resumption context. Now PSK for
>> > connection N+1 = RMS from connection N. Thanks to Kazuho for
>> > suggesting this simplification.
>> >
>> > This draft also makes a number of minor editorial changes that
>> > should make for easier reading.
>> >
>> > The two remaining open technical issues I am aware of are both
>> > requirements issues:
>> >
>> > 1. Can you resume with a different SNI than the one that the
>> >    connection was initiated with [current answer is "no"]?
>> >
>> > 2. Do you need an application profile to do post-handshake
>> >    client auth [current answer is "no"]?
>> >
>> > There has been a bunch of discussion of these on the list but no
>> > consensus declarations from the chairs. These are easy to change
>> > in the draft once the chairs make the call.
>> >
>> > As always, comments welcome.
>> >
>> > -Ekr
>> >
>> > P.S. NSS will be skipping draft-17 and going right to -18. This
>> > should happen before Seoul.
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>>
>>
>>
>> --
>> Kazuho Oku
>
>



-- 
Kazuho Oku


From nobody Thu Oct 27 04:07:35 2016
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 34A34129A6B for ; Thu, 27 Oct 2016 04:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.152
X-Spam-Level: 
X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 xvQoiUeydHDB for ; Thu, 27 Oct 2016 04:07:27 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8590E129A6E for ; Thu, 27 Oct 2016 04:07:27 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 637D242392E; Thu, 27 Oct 2016 11:07:26 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 4C434423914; Thu, 27 Oct 2016 11:07:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1477566446; bh=XnNCpiAH5gMhuIr/XUO2pfF4eAWjLfaJRplVNnZUo1c=; l=252; h=From:To:Date:References:In-Reply-To:From; b=tzDN/iN5DGNVep5xKMJKYAe0TEu26nDCRBOFZMaNMdxKWpnlj5wN9cIzTaoW+vuir g+VHcDAR5S0wg7MZNa5pTVhylpj4NMztWquwU48hzKHhDoiOLplVqNvrNSbimz/WsO Su/2Lor84FJy4MRUNJOwCMCNN82xBV7JcMBNs4eg=
Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 40A381FC95; Thu, 27 Oct 2016 11:07:26 +0000 (GMT)
Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 27 Oct 2016 07:07:25 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 27 Oct 2016 07:07:25 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 27 Oct 2016 07:07:25 -0400
From: "Salz, Rich" 
To: Joseph Salowey , "tls@ietf.org" 
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
Thread-Index: AQHSL/2+7HM9ClSQ40Wwf3PQxwdBMaC8JGnQ
Date: Thu, 27 Oct 2016 11:07:24 +0000
Message-ID: <74dbd140dc9046d4b1f99269a674bbee@usma1ex-dag1mb1.msg.corp.akamai.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.40.153]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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, 27 Oct 2016 11:07:32 -0000

U28gaXNuJ3QgaXQgcmVhbGx5IGEgV0dMQyB0aGF0IHJ1bnMgdW50aWwgZW5kIG9mIEphbnVhcnkg
MjAxNz8NCg0KLS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVt
YmVyLCBPcGVuU1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJp
Y2hTYWx6DQoNCg0K


From nobody Thu Oct 27 10:46:47 2016
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 6A17E12956A for ; Thu, 27 Oct 2016 10:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 8D3DUq7hnPLH for ; Thu, 27 Oct 2016 10:46:43 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 9E3DB129568 for ; Thu, 27 Oct 2016 10:46:43 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 96428A8A034B; Thu, 27 Oct 2016 17:46:41 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 5916E1FE023E; Thu, 27 Oct 2016 19:46:41 +0200 (CEST)
Date: Thu, 27 Oct 2016 19:46:40 +0200
From: Kurt Roeckx 
To: Hubert Kario 
Message-ID: <20161027174640.akocwtmqcfhkzbvx@roeckx.be>
References: <2807298.nMSlSttlYL@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2807298.nMSlSttlYL@pintsize.usersys.redhat.com>
User-Agent: NeoMutt/20161014 (1.7.1)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Server abort because of unrecognised vs rejected client provided parameters
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, 27 Oct 2016 17:46:45 -0000

On Fri, Oct 21, 2016 at 03:24:35PM +0200, Hubert Kario wrote:
> Currently TLS has two alert descriptions for when there is no intersection 
> between ciphers/sigalgs/groups advertises by client and ones that are enabled 
> in server. It's the handshake_failure and insufficient_security alerts.
> 
> While it is a step in good direction in providing users with better messages 
> in case of connection failure, I think there is one edge case which may ruin 
> the effort.
> 
> Let's say we have a client that advertises following signature methods:
> rsa-ssa-sha256
> rsa-ssa-sha384
> 
> and this client is connecting to server which requires use of rsa-ssa-sha512 
> signatures only, but does implement weaker hashes and the requirement is just 
> result of administrator requiring high security.
> 
> I think that such connection attempt should end with insufficient_security.
> 
> Problem is, what if the server does not implement some even never RSA 
> signature format, but client does advertise support for them?
> 
> I think then the connection should end with handshake_failure.

So what about the case where the server does implement it, but
it's been disabled? For instance because he wanted to disable MD5
he only enabled SHA-1 years ago, but then SHA-2 got implemented
and only SHA-1 is enabled.


Kurt


From nobody Thu Oct 27 11:30:01 2016
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 173231295C4 for ; Thu, 27 Oct 2016 11:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.333
X-Spam-Level: 
X-Spam-Status: No, score=-7.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 dpOpFu6pJ8B0 for ; Thu, 27 Oct 2016 11:29:58 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A3C1293FE for ; Thu, 27 Oct 2016 11:29:58 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 55A2D8F253; Thu, 27 Oct 2016 18:23:05 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9RIN4LA016759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2016 14:23:05 -0400
From: Hubert Kario 
To: Kurt Roeckx 
Date: Thu, 27 Oct 2016 20:22:55 +0200
Message-ID: <77772374.d9I1LrzaI5@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.1 (Linux/4.7.9-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <20161027174640.akocwtmqcfhkzbvx@roeckx.be>
References: <2807298.nMSlSttlYL@pintsize.usersys.redhat.com> <20161027174640.akocwtmqcfhkzbvx@roeckx.be>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart7740430.XLk2MSyslZ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 27 Oct 2016 18:23:05 +0000 (UTC)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Server abort because of unrecognised vs rejected client provided parameters
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, 27 Oct 2016 18:30:00 -0000

--nextPart7740430.XLk2MSyslZ
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Thursday, 27 October 2016 19:46:40 CEST Kurt Roeckx wrote:
> On Fri, Oct 21, 2016 at 03:24:35PM +0200, Hubert Kario wrote:
> > Currently TLS has two alert descriptions for when there is no intersect=
ion
> > between ciphers/sigalgs/groups advertises by client and ones that are
> > enabled in server. It's the handshake_failure and insufficient_security
> > alerts.
> >=20
> > While it is a step in good direction in providing users with better
> > messages in case of connection failure, I think there is one edge case
> > which may ruin the effort.
> >=20
> > Let's say we have a client that advertises following signature methods:
> > rsa-ssa-sha256
> > rsa-ssa-sha384
> >=20
> > and this client is connecting to server which requires use of
> > rsa-ssa-sha512 signatures only, but does implement weaker hashes and the
> > requirement is just result of administrator requiring high security.
> >=20
> > I think that such connection attempt should end with
> > insufficient_security.
> >=20
> > Problem is, what if the server does not implement some even never RSA
> > signature format, but client does advertise support for them?
> >=20
> > I think then the connection should end with handshake_failure.
>=20
> So what about the case where the server does implement it, but
> it's been disabled? For instance because he wanted to disable MD5
> he only enabled SHA-1 years ago, but then SHA-2 got implemented
> and only SHA-1 is enabled.

handshake_failure

ideally because server recognizes that client hello includes values
it implements that are stronger than what it has enabled

the main point is to differentiate failures caused by too weak/old clients=
=20
from=20regular lack of overlap between server and client implemented paramete=
r=20
set

in short, server should never send insufficient_security if all parameters=
=20
included in client hello are ones that have been defined at the time when=20
server was implemented

=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart7740430.XLk2MSyslZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJYEkX/AAoJEJKo0bgB0vX13igP/j57BNgr2wVizVsXBwEB3FTq
2yxL4yE6gbTfqgs9nIK/RF+BmtF/CrfObpc55t0kzkJlmpagcnISvZj5epNsOyA7
BpAeRtpHO4odSfwoDxX2D49z1mDM3rE6IpETmVE3hUytxFzTs0V2dSxuDRunKuZN
h+bwc10rcgs0TrINQlnxdXSMtGbE5IVvMyE4K92eGTOTUEQvvLGExTsazNcC0YfI
+OOMFJyAcxW/gqJ0PusDZCfglimawetbw0kIwYVdch7+TDnV7CHcSyMTxmBDjbFG
RO7E1xHnucqDmxcQBeX9UfyK0yiifnHuDOcp07cssEW4z7Cot34ENIadD/abhg7s
/uMQp0QWf9sU3KVkNART1N5syOc2s8cVrXf8i2CVFFNn3oQ2zvNEyL4Gi3y6i9k4
a/jriyqmjFa4pHee9GdLI7lv1j3iCADHDzqXmVuocLrA4LF4vQhyQvIesRsD7xIk
ZycDhbeIWgqaJ7jWFX5cbSWJ1hIe+EhpGhW6CQbnF5qw6ZbBS8/BWIGgEKOkxQbJ
NyerrwgZsaSt4G3l8bp2BT3gJkdACjZ40ermE2shsT9grRDmL7KBiVFQl1WS+5Kt
/AowIrVhU2Id1MJzdlr31js1yOjtPhgXBqgigNX4+Yt7y+mcOk1sUknmmutbr8Mh
VLR6/Orlkx3AefH+pI8W
=8gR2
-----END PGP SIGNATURE-----

--nextPart7740430.XLk2MSyslZ--


From nobody Thu Oct 27 23:04:44 2016
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 D44AF129654 for ; Thu, 27 Oct 2016 23:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 owwbeMTHBz6d for ; Thu, 27 Oct 2016 23:04:41 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289E712944E for ; Thu, 27 Oct 2016 23:04:41 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id o68so74944304qkf.3 for ; Thu, 27 Oct 2016 23:04:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8OAMqtcMTz1vv7yTpYhnZdIqHiObYeiXuDvRitiJ9pI=; b=kaDDgcxCav9f4jbF8MqFHrtsX0FDqXmPSRpcHnIcLanC+5Nb37q0FxbnWfiCl8lEZ4 8VY0/BULSUE9hOAjkbOa9S/54p2o1E3PeXAIy5igzqw+OrNsPGMcP3ynqJXjLF3hCrdQ eXoC1E5ri3U/WZW/4ePitKOdtau4H4GzuyzrUI1FmQoZVdOxRcd4x2MTwNx9f1ZVd/tD 2OFzu/AdLEIKZYpAAS2cyNuQD9JtcrSWrKq8JNeUQZKTGAE1hNBOtHjVHC+5QXyAepLn hAoeFZWfmYM2mFKpYEBAsaGnTt4wZA76rLqZXjNvkmCQoFB549julRvzV83icqBYrX6G PLoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8OAMqtcMTz1vv7yTpYhnZdIqHiObYeiXuDvRitiJ9pI=; b=fCH4m5Yz8qXgisukG44S1+ADvjFax50DkhqjrdwtGNrovbr3SFRy2sPqIQwQKDDKsz RpcCU18nzkLxqXVHqMlh8lFV9Ka5e9TcJvNLLUY4RPpyXo4bU1IONElfN4oM/9elKI9L nztWiL8bN9amIBFq1ruDytR5zH1DnkLQT/mRWJeNmu4eWNGC6JSguuBam2VLJ7z7DTGV mmsUCQWeMKV++uiTst9Wrt9RPE4fdGHCXWtdZ2hFXLz7hshIkdZZR5E8xQ42Uja+mZ58 Cnti5I8s+i+nMLwsXXr5ISHo3NNfEQi+MFiw3nTVXvMzgjr9DaI3CK8N7rf+LfAdP7zh J61Q==
X-Gm-Message-State: ABUngvcGTF3tyou0T3kissF+AGutA2r2dcJpZ423OdMnSLLDl/quGfcqUxHNsV0B4ZE02gjN9TcZUTtwDSu0TQ==
X-Received: by 10.55.165.16 with SMTP id o16mr9992764qke.5.1477634680338; Thu, 27 Oct 2016 23:04:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Thu, 27 Oct 2016 23:04:39 -0700 (PDT)
In-Reply-To: 
References:    
From: Martin Thomson 
Date: Fri, 28 Oct 2016 17:04:39 +1100
Message-ID: 
To: Kazuho Oku 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-ietf-tls-tls13 posted
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: Fri, 28 Oct 2016 06:04:43 -0000

On 27 October 2016 at 16:41, Kazuho Oku  wrote:
> So if we are going to align the ranges of the two arrays, it might
> make more sense to allow zero-length for both of them, instead of
> disallowing it.

I think that it would be better to have a minimum size here.  Those
applications that don't want to store a value for the ticket identity
can agree to send a one octet value or something like that.  I don't
think that we need a zero length value.

https://github.com/tlswg/tls13-spec/pull/744


From nobody Fri Oct 28 09:00:10 2016
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 E390B129AB6 for ; Fri, 28 Oct 2016 09:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jPf1hNmylM5N for ; Fri, 28 Oct 2016 09:00:06 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1962129A6D for ; Fri, 28 Oct 2016 09:00:06 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3t57kX4H6Yz1JF1; Fri, 28 Oct 2016 18:00:04 +0200 (CEST)
X-purgate-ID: 152705::1477670404-0000521C-4101AA68/0/0
X-purgate-size: 1778
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t57kW5f1yzks98; Fri, 28 Oct 2016 18:00:03 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B5CA61A56C; Fri, 28 Oct 2016 18:00:03 +0200 (CEST)
In-Reply-To: 
To: Joseph Salowey 
Date: Fri, 28 Oct 2016 18:00:03 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161028160003.B5CA61A56C@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 28 Oct 2016 16:00:09 -0000

Joseph Salowey wrote:
>
> This is a working group last call announcement for draft-ietf-tls-tls13-18,
> to run through November 20. If possible, we would like to receive comments
> on the list by November 13 so they can be discussed at the meeting in
> Seoul. We hope to address any substantive issues raised during that process
> shortly thereafter.
> 
> In order to allow for cryptographic review, we will delay submission of the
> draft to the IESG until the end of January 2017; there will be an
> opportunity to address any issues discovered by the cryptographic community
> prior to submission to the IESG.


There are two seriously backwards-incompatible changes in the
current proposal that provide zero value, but completely break
backwards-compatibility with existing middleware infrastructure.


(1) hiding of the TLS record content types.
    Please leave the TLS record types (handshake/AppData/Alert/CCS)
    clearly visible on the outside of the TLS records, so that
    middleware protocol parsers (which interface to transport-free
    TLS protocol stacks) can continue to work, and continue to
    work efficiently.

(2) hiding of the TLS extension SNI.
    Right now it is perferctly fine to implement TLS extensions SNI
    on the server completely outside the TLS protocol stack to route
    to single-cert SNI-unaware backends.  The current proposal
    suggest to move TLS extension SNI into the encrypted part, if
    my superficial reading of the draft is correct, so TLSv1.3
    will not fly with existing architectures where spreading of
    TLS requests on the server-side based on TLS extension SNI
    is done outside of the TLS protocol stack (i.e. bottleneck-less
    without having to open TLS).


-Martin


From nobody Fri Oct 28 09:24:33 2016
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 ED17B12961A for ; Fri, 28 Oct 2016 09:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 trDzyxfRnH7J for ; Fri, 28 Oct 2016 09:24:30 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id DD291129496 for ; Fri, 28 Oct 2016 09:24:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 750A116226; Fri, 28 Oct 2016 19:24:28 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id tr3JAlqQSeiZ; Fri, 28 Oct 2016 19:24:28 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 236092310; Fri, 28 Oct 2016 19:24:28 +0300 (EEST)
Date: Fri, 28 Oct 2016 19:24:26 +0300
From: Ilari Liusvaara 
To: Martin Rex 
Message-ID: <20161028162426.GA25186@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161028160003.B5CA61A56C@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20161028160003.B5CA61A56C@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Fri, 28 Oct 2016 16:24:32 -0000

On Fri, Oct 28, 2016 at 06:00:03PM +0200, Martin Rex wrote:
> Joseph Salowey wrote:
> 
> There are two seriously backwards-incompatible changes in the
> current proposal that provide zero value, but completely break
> backwards-compatibility with existing middleware infrastructure.
> 
> 
> (1) hiding of the TLS record content types.
>     Please leave the TLS record types (handshake/AppData/Alert/CCS)
>     clearly visible on the outside of the TLS records, so that
>     middleware protocol parsers (which interface to transport-free
>     TLS protocol stacks) can continue to work, and continue to
>     work efficiently.

Hiding the types does have its benefits (and it is also used for
zero-overhead padding scheme).

And also, TLS 1.3 handshake is so darn different from TLS 1.2, that
you couldn't do anything sane even if you had record types.
 
> (2) hiding of the TLS extension SNI.
>     Right now it is perferctly fine to implement TLS extensions SNI
>     on the server completely outside the TLS protocol stack to route
>     to single-cert SNI-unaware backends.  The current proposal
>     suggest to move TLS extension SNI into the encrypted part, if
>     my superficial reading of the draft is correct, so TLSv1.3
>     will not fly with existing architectures where spreading of
>     TLS requests on the server-side based on TLS extension SNI
>     is done outside of the TLS protocol stack (i.e. bottleneck-less
>     without having to open TLS).

Who actually cares about server-side SNI? And it wasn't like you
could do anything useful with server-side SNI in TLS 1.2 either.

You can still route connections on SNI, and it even works the
same way it did in TLS 1.2 (so existing code works).


-Ilari


From nobody Fri Oct 28 11:04:41 2016
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 207AA129675 for ; Fri, 28 Oct 2016 11:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 1anSy_3sAyXO for ; Fri, 28 Oct 2016 11:04:38 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486C4129444 for ; Fri, 28 Oct 2016 11:04:38 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id w3so95556296ywg.1 for ; Fri, 28 Oct 2016 11:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q9ZCkrfd9hAC0zQoH/jMHo5bCdJP5iEWQE19qy0zyiw=; b=032EEL+6UIpZZg75BcB9fFzLPiK/+sqjvIlIBOo5idTU4HrBL+QfhxJz1XKjdbgECo XVjD05qzqXaGom+Hy6FhgC7T/spQdbggIpLCZMf8KxgO45e2no7mv1cTHKg4Uy9klJpZ hVgZS4j9qxCfGJmuYN+nHB4e4dotF1U2E0gxSVlcWFi9z++rVamwWqtDg2XRyozZz2D6 L4GMe8dxOeisD6NkKQp3J84ArdzB0o0AUCi/DtXNV8MnwZtDjh/IOKIGcm0zhsGZFpD6 J/eArxaF7Wc6MCWAfVtt79QioKuNCDYSkBWcbG+E0XA1xn7FOYPYVPFYPEvCgyu3sJMp E8Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q9ZCkrfd9hAC0zQoH/jMHo5bCdJP5iEWQE19qy0zyiw=; b=IMITZ5vvjyUHtfd7XlKPEbzsdVkTdrIuxzAb12dbfGbC8lCK1YEYRDcwlKZmGY3Oag axJu7V/UwMqpATZdQx0NKydP2IuKB3QgS6xnKjppAc2ku9H16hMl6cJ5gt+kjfoCXMAG SFs9X1tfZcTWb0zZiqHm8P1ZkpX5zSE+/4TQZsvJMhqZWfVmmFh5gXhoFN2oydik86YE 71CDErNOMSI+Vnyob+aT5CpNQAN5GZ9tvlmKJqYg7jC2iJ9oAwN2ItNqoIJ1EAvERun2 5cifbmdAaFvI+Mk5UJQ5m8plgFg4ykd4hqN9LGjmCqtzkd1xvwI5TrFguVP+QXx4DSFS 7tow==
X-Gm-Message-State: ABUngvekxxyFzgDuAsVNkNtw39aL4bbRn6uhMlJ1qLr5PpCKvIVCcufU3qvhvdsmPQPlm7R5+qXPliB5zo93VQ==
X-Received: by 10.129.125.215 with SMTP id y206mr4789353ywc.234.1477677876803;  Fri, 28 Oct 2016 11:04:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Fri, 28 Oct 2016 11:03:56 -0700 (PDT)
In-Reply-To: <20161028160003.B5CA61A56C@ld9781.wdf.sap.corp>
References:  <20161028160003.B5CA61A56C@ld9781.wdf.sap.corp>
From: Eric Rescorla 
Date: Sat, 29 Oct 2016 05:03:56 +1100
Message-ID: 
To: "mrex@sap.com" 
Content-Type: multipart/alternative; boundary=001a11492dfaf0c409053ff0b04d
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Fri, 28 Oct 2016 18:04:40 -0000

--001a11492dfaf0c409053ff0b04d
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 29, 2016 at 3:00 AM, Martin Rex  wrote:

> Joseph Salowey wrote:
> >
> > This is a working group last call announcement for
> draft-ietf-tls-tls13-18,
> > to run through November 20. If possible, we would like to receive
> comments
> > on the list by November 13 so they can be discussed at the meeting in
> > Seoul. We hope to address any substantive issues raised during that
> process
> > shortly thereafter.
> >
> > In order to allow for cryptographic review, we will delay submission of
> the
> > draft to the IESG until the end of January 2017; there will be an
> > opportunity to address any issues discovered by the cryptographic
> community
> > prior to submission to the IESG.
>
>
> There are two seriously backwards-incompatible changes in the
> current proposal that provide zero value, but completely break
> backwards-compatibility with existing middleware infrastructure.
>
>
> (1) hiding of the TLS record content types.
>     Please leave the TLS record types (handshake/AppData/Alert/CCS)
>     clearly visible on the outside of the TLS records, so that
>     middleware protocol parsers (which interface to transport-free
>     TLS protocol stacks) can continue to work, and continue to
>     work efficiently.


I'll let the chairs determine how to handle this.



> (2) hiding of the TLS extension SNI.
>     Right now it is perferctly fine to implement TLS extensions SNI
>     on the server completely outside the TLS protocol stack to route
>     to single-cert SNI-unaware backends.  The current proposal
>     suggest to move TLS extension SNI into the encrypted part, if
>     my superficial reading of the draft is correct, so TLSv1.3
>     will not fly with existing architectures where spreading of
>     TLS requests on the server-side based on TLS extension SNI
>     is done outside of the TLS protocol stack (i.e. bottleneck-less
>     without having to open TLS).


This isn't quite right. In RFC 6066, the client sends its server_name
extension in ClientHello and the server responds with an empty
server_name in its ServerHello to indicate that it accepted SNI.

   A server that receives a client hello containing the "server_name"
   extension MAY use the information contained in the extension to guide
   its selection of an appropriate certificate to return to the client,
   and/or other aspects of security policy.  In this event, the server
   SHALL include an extension of type "server_name" in the (extended)
   server hello.  The "extension_data" field of this extension SHALL be
   empty.

In TLS 1.3, the client's extension remains where it is, but the server's
extension is in EncryptedExtensions. This shouldn't interfere with
configurations such as the one you describe, as the server already
needed to insert the SNI field itself and hash it into Finished.

-Ekr


>

--001a11492dfaf0c409053ff0b04d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, Oct 29, 2016 at 3:00 AM, Martin Rex <mrex@sap.com> wr=
ote:
Joseph Salowey wrote:

>

> This is a working group last call announcement for draft-ietf-tls-tls1=
3-18,

> to run through November 20. If possible, we would like to receive comm=
ents

> on the list by November 13 so they can be discussed at the meeting in<=
br>
> Seoul. We hope to address any substantive issues raised during that pr=
ocess

> shortly thereafter.

>

> In order to allow for cryptographic review, we will delay submission o=
f the

> draft to the IESG until the end of January 2017; there will be an

> opportunity to address any issues discovered by the cryptographic comm=
unity

> prior to submission to the IESG.





There are two seriously backwards-incompatible changes in the

current proposal that provide zero value, but completely break

backwards-compatibility with existing middleware infrastructure.





(1) hiding of the TLS record content types.

=C2=A0 =C2=A0 Please leave the TLS record types (handshake/AppData/Alert/CC=
S)

=C2=A0 =C2=A0 clearly visible on the outside of the TLS records, so that
=C2=A0 =C2=A0 middleware protocol parsers (which interface to transport-fre=
e

=C2=A0 =C2=A0 TLS protocol stacks) can continue to work, and continue to
=C2=A0 =C2=A0 work efficiently.

I'll le=
t the chairs determine how to handle this.

=C2=A0<=
/div>

(2) hiding of the TLS extension SNI.

=C2=A0 =C2=A0 Right now it is perferctly fine to implement TLS extensions S=
NI

=C2=A0 =C2=A0 on the server completely outside the TLS protocol stack to ro=
ute

=C2=A0 =C2=A0 to single-cert SNI-unaware backends.=C2=A0 The current propos=
al

=C2=A0 =C2=A0 suggest to move TLS extension SNI into the encrypted part, if=


=C2=A0 =C2=A0 my superficial reading of the draft is correct, so TLSv1.3
=C2=A0 =C2=A0 will not fly with existing architectures where spreading of
=C2=A0 =C2=A0 TLS requests on the server-side based on TLS extension SNI
=C2=A0 =C2=A0 is done outside of the TLS protocol stack (i.e. bottleneck-le=
ss

=C2=A0 =C2=A0 without having to open TLS).

=
This isn't quite right. In RFC 6066, the client sends its server_name
extension in ClientHello and the server responds with an empty
server_name in its ServerHello to indicate that it accepted SNI.

=C2=A0 =C2=A0A server that receives a client hel=
lo containing the "server_name"
=C2=A0 =C2=A0extension =
MAY use the information contained in the extension to guide
=C2=
=A0 =C2=A0its selection of an appropriate certificate to return to the clie=
nt,
=C2=A0 =C2=A0and/or other aspects of security policy.=C2=A0 I=
n this event, the server
=C2=A0 =C2=A0SHALL include an extension =
of type "server_name" in the (extended)
=C2=A0 =C2=A0se=
rver hello.=C2=A0 The "extension_data" field of this extension SH=
ALL be
=C2=A0 =C2=A0empty.

In TLS =
1.3, the client's extension remains where it is, but the server's
extension is in EncryptedExtensions. This shouldn't interfere =
with
configurations such as the one you describe, as the server a=
lready
needed to insert the SNI field itself and hash it into Fin=
ished.

-Ekr
=C2=A0
=C2=A0


--001a11492dfaf0c409053ff0b04d--


From nobody Fri Oct 28 11:23:48 2016
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 75DA4129593 for ; Fri, 28 Oct 2016 11:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 w9LAZ5jED7GP for ; Fri, 28 Oct 2016 11:23:45 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFD61294A8 for ; Fri, 28 Oct 2016 11:23:45 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3t5BwH2HyVz26CG; Fri, 28 Oct 2016 20:23:43 +0200 (CEST)
X-purgate-ID: 152705::1477679023-0000521C-35536832/0/0
X-purgate-size: 2574
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t5BwG48nKzkp5T; Fri, 28 Oct 2016 20:23:42 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 842351A56E; Fri, 28 Oct 2016 20:23:42 +0200 (CEST)
In-Reply-To: 
To: Eric Rescorla 
Date: Fri, 28 Oct 2016 20:23:42 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161028182342.842351A56E@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 28 Oct 2016 18:23:46 -0000

If the server_name remains in plaintext and full sight in ClientHello
(where it needs to be for TLSv1.2 backwards compatibility anyway),
then I don't have an issue.  (I'm sorry for not reading the draft in full).


Eric Rescorla wrote:
> 
>> (2) hiding of the TLS extension SNI.
>>     Right now it is perferctly fine to implement TLS extensions SNI
>>     on the server completely outside the TLS protocol stack to route
>>     to single-cert SNI-unaware backends.  The current proposal
>>     suggest to move TLS extension SNI into the encrypted part, if
>>     my superficial reading of the draft is correct, so TLSv1.3
>>     will not fly with existing architectures where spreading of
>>     TLS requests on the server-side based on TLS extension SNI
>>     is done outside of the TLS protocol stack (i.e. bottleneck-less
>>     without having to open TLS).
> 
> 
> This isn't quite right. In RFC 6066, the client sends its server_name
> extension in ClientHello and the server responds with an empty
> server_name in its ServerHello to indicate that it accepted SNI.

Yes, I know that rfc6066 suggests the server responds with an empty SNI
extension.  This kind of server response is is a complete waste,
and server-side SNI works just fine with the server not returning
an empty SNI extension.


> 
>    A server that receives a client hello containing the "server_name"
>    extension MAY use the information contained in the extension to guide
>    its selection of an appropriate certificate to return to the client,
>    and/or other aspects of security policy.  In this event, the server
>    SHALL include an extension of type "server_name" in the (extended)
>    server hello.  The "extension_data" field of this extension SHALL be
>    empty.
> 
> In TLS 1.3, the client's extension remains where it is, but the server's
> extension is in EncryptedExtensions. This shouldn't interfere with
> configurations such as the one you describe, as the server already
> needed to insert the SNI field itself and hash it into Finished.

Nope, the server doesn't need to insert anything at all.  The empty
TLS extensions SNI in ServerHello is completely superflouous.

If this is really about "hinding the empty TLS extension SNI response",
while leaving the actualy server_name in full sight in the cleartext
ClientHello, why not just dropping the ServerHello TLS extension SNI
response and be done with it?  It really has no functional value other
than information discovery for scanners (the bad guys).


-Martin


From nobody Fri Oct 28 11:30:53 2016
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 838FD12953B for ; Fri, 28 Oct 2016 11:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 LUw-VT3aY4ix for ; Fri, 28 Oct 2016 11:30:49 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C28A128B37 for ; Fri, 28 Oct 2016 11:30:49 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id h14so99192740ywa.2 for ; Fri, 28 Oct 2016 11:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DD+V1Sggag1UklTsykPSq3wnGpCcQDvUL2a0MZjVIl8=; b=QlqqVTQw/OL6NvISxr+F9n4OXufyJS1clautPO85AsLzhe4trfMAQutzYuNa7b7fNW 93f8LYlIg11AYNKmv7ZHaURT016giRXXfa5JzjSF2o7uCVoUO3ZsjyRoii6zf3CO26C1 fXJExKAyHMPGF/zn94XtC6xsA1xw0wvUTzbXNhV0h+pOwkju2TJqDnfoAvhTGWsH4qBP kFcHa+eeihvKjWaIV0l/Piki787pLxAlSJ49atoL+XKx92tSnAcdLMwyITwDPDt3+FMQ Mynma81IvkRLcVkXIxxkCTukolABBbGR83A3tV5tXHxOwOvyPCHw81oq4mQaUx/kulzg UmPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DD+V1Sggag1UklTsykPSq3wnGpCcQDvUL2a0MZjVIl8=; b=W80WUmSXVaeDl8BiDwsFNzkl4wwPNZFqsTDk4DhPZc+gpXY8GEdRGxgUbLcNlm90w4 nIciwhFTYTYP+uUVgZc6BqkPz+Xh/4k2VlkPQc0tTu7+5HiHCfcD4INBexJRHagA+/JC uQBn0fAt/1WlQjo5Af43MiCra44Jf7aDNJZ0Z87LOnOwqFxqejFpscCnqB7wbmkz6hNw bt21kYG94UN2KfF0L1C/Kj/nYEUy5spTgYgF66HkYJOJpJf+WjD8uIA/MCoAEkavIytt 5BQVTvT/WlZuqDoeqds28FHOS1Op+wXf6KB9z3gaqj8QnIve8c+cyk+nFYa6vw7ryAb3 83+Q==
X-Gm-Message-State: ABUngveOAcJjl4XZwJutczv2tzLDnxtuWS2ZOBKyxJBpIk3z9ulsVKDMSpIGLvYUZQkIi5dakK71Oqfvgntk5A==
X-Received: by 10.13.195.1 with SMTP id f1mr15618292ywd.354.1477679448845; Fri, 28 Oct 2016 11:30:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Fri, 28 Oct 2016 11:30:08 -0700 (PDT)
In-Reply-To: <20161028182342.842351A56E@ld9781.wdf.sap.corp>
References:  <20161028182342.842351A56E@ld9781.wdf.sap.corp>
From: Eric Rescorla 
Date: Sat, 29 Oct 2016 05:30:08 +1100
Message-ID: 
To: "mrex@sap.com" 
Content-Type: multipart/alternative; boundary=001a114e4e5ca42357053ff10e83
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Fri, 28 Oct 2016 18:30:51 -0000

--001a114e4e5ca42357053ff10e83
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 29, 2016 at 5:23 AM, Martin Rex  wrote:

> If the server_name remains in plaintext and full sight in ClientHello
> (where it needs to be for TLSv1.2 backwards compatibility anyway),
> then I don't have an issue.  (I'm sorry for not reading the draft in full)


Good to hear.


> Eric Rescorla wrote:
> >
> >> (2) hiding of the TLS extension SNI.
> >>     Right now it is perferctly fine to implement TLS extensions SNI
> >>     on the server completely outside the TLS protocol stack to route
> >>     to single-cert SNI-unaware backends.  The current proposal
> >>     suggest to move TLS extension SNI into the encrypted part, if
> >>     my superficial reading of the draft is correct, so TLSv1.3
> >>     will not fly with existing architectures where spreading of
> >>     TLS requests on the server-side based on TLS extension SNI
> >>     is done outside of the TLS protocol stack (i.e. bottleneck-less
> >>     without having to open TLS).
> >
> >
> > This isn't quite right. In RFC 6066, the client sends its server_name
> > extension in ClientHello and the server responds with an empty
> > server_name in its ServerHello to indicate that it accepted SNI.
>
> Yes, I know that rfc6066 suggests the server responds with an empty SNI
> extension.  This kind of server response is is a complete waste,
> and server-side SNI works just fine with the server not returning
> an empty SNI extension.
>
>
> >
> >    A server that receives a client hello containing the "server_name"
> >    extension MAY use the information contained in the extension to guide
> >    its selection of an appropriate certificate to return to the client,
> >    and/or other aspects of security policy.  In this event, the server
> >    SHALL include an extension of type "server_name" in the (extended)
> >    server hello.  The "extension_data" field of this extension SHALL be
> >    empty.
> >
> > In TLS 1.3, the client's extension remains where it is, but the server's
> > extension is in EncryptedExtensions. This shouldn't interfere with
> > configurations such as the one you describe, as the server already
> > needed to insert the SNI field itself and hash it into Finished.
>
> Nope, the server doesn't need to insert anything at all.  The empty
> TLS extensions SNI in ServerHello is completely superflouous.
>
> If this is really about "hinding the empty TLS extension SNI response",
> while leaving the actualy server_name in full sight in the cleartext
> ClientHello, why not just dropping the ServerHello TLS extension SNI
> response and be done with it?  It really has no functional value other
> than information discovery for scanners (the bad guys).
>

I would be fine with that if others are. Here's how we got here:

- RFC 6066 requires it (it's a SHALL level requirement).
- We didn't see a need to update the semantics of 6066
- Everything that doesn't have to be in ServerHello goes into EE.

If point #2 is wrong, then that's easy to change, though it would be a
change to
implementations. NSS, for instance, sends it:
http://searchfox.org/nss/source/lib/ssl/ssl3ext.c#436
-Ekr


>
> -Martin
>

--001a114e4e5ca42357053ff10e83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, Oct 29, 2016 at 5:23 AM, Martin Rex <mrex@sap.com> wr=
ote:
If the server_nam=
e remains in plaintext and full sight in ClientHello

(where it needs to be for TLSv1.2 backwards compatibility anyway),

then I don't have an issue.=C2=A0 (I'm sorry for not reading the dr=
aft in full)
=C2=A0
Good to hear.

=




Eric Rescorla wrote:

>

>> (2) hiding of the TLS extension SNI.

>>=C2=A0 =C2=A0 =C2=A0Right now it is perferctly fine to implement TL=
S extensions SNI

>>=C2=A0 =C2=A0 =C2=A0on the server completely outside the TLS protoc=
ol stack to route

>>=C2=A0 =C2=A0 =C2=A0to single-cert SNI-unaware backends.=C2=A0 The =
current proposal

>>=C2=A0 =C2=A0 =C2=A0suggest to move TLS extension SNI into the encr=
ypted part, if

>>=C2=A0 =C2=A0 =C2=A0my superficial reading of the draft is correct,=
 so TLSv1.3

>>=C2=A0 =C2=A0 =C2=A0will not fly with existing architectures where =
spreading of

>>=C2=A0 =C2=A0 =C2=A0TLS requests on the server-side based on TLS ex=
tension SNI

>>=C2=A0 =C2=A0 =C2=A0is done outside of the TLS protocol stack (i.e.=
 bottleneck-less

>>=C2=A0 =C2=A0 =C2=A0without having to open TLS).

>

>

> This isn't quite right. In RFC 6066, the client sends its server_n=
ame

> extension in ClientHello and the server responds with an empty

> server_name in its ServerHello to indicate that it accepted SNI.



Yes, I know that rfc6066 suggests the server responds with an empty =
SNI

extension.=C2=A0 This kind of server response is is a complete waste,

and server-side SNI works just fine with the server not returning

an empty SNI extension.





>

>=C2=A0 =C2=A0 A server that receives a client hello containing the &quo=
t;server_name"

>=C2=A0 =C2=A0 extension MAY use the information contained in the extens=
ion to guide

>=C2=A0 =C2=A0 its selection of an appropriate certificate to return to =
the client,

>=C2=A0 =C2=A0 and/or other aspects of security policy.=C2=A0 In this ev=
ent, the server

>=C2=A0 =C2=A0 SHALL include an extension of type "server_name"=
; in the (extended)

>=C2=A0 =C2=A0 server hello.=C2=A0 The "extension_data" field =
of this extension SHALL be

>=C2=A0 =C2=A0 empty.

>

> In TLS 1.3, the client's extension remains where it is, but the se=
rver's

> extension is in EncryptedExtensions. This shouldn't interfere with=


> configurations such as the one you describe, as the server already

> needed to insert the SNI field itself and hash it into Finished.



Nope, the server doesn't need to insert anything at all.=C2=A0 T=
he empty

TLS extensions SNI in ServerHello is completely superflouous.



If this is really about "hinding the empty TLS extension SNI response&=
quot;,

while leaving the actualy server_name in full sight in the cleartext

ClientHello, why not just dropping the ServerHello TLS extension SNI

response and be done with it?=C2=A0 It really has no functional value other=


than information discovery for scanners (the bad guys).

I would be fine with that if others are. Here's how we=
 got here:

- RFC 6066 requires it (it's a SHAL=
L level requirement).
- We didn't see a need to update the se=
mantics of 6066
- Everything that doesn't have to be in Serve=
rHello goes into EE.

If point #2 is wrong, then th=
at's easy to change, though it would be a change to
implement=
ations. NSS, for instance, sends it:
-Ekr






-Martin





--001a114e4e5ca42357053ff10e83--


From nobody Fri Oct 28 11:35:51 2016
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 C9671129568 for ; Fri, 28 Oct 2016 11:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level: 
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 TKIT0p4IGYDS for ; Fri, 28 Oct 2016 11:35:47 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C91712953B for ; Fri, 28 Oct 2016 11:35:47 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3t5CBB0XWbz26Kf; Fri, 28 Oct 2016 20:35:46 +0200 (CEST)
X-purgate-ID: 152705::1477679746-00003836-9C09BD07/0/0
X-purgate-size: 2248
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t5CB94dMPzksH6; Fri, 28 Oct 2016 20:35:45 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 942CC1A56E; Fri, 28 Oct 2016 20:35:45 +0200 (CEST)
In-Reply-To: <20161028162426.GA25186@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara 
Date: Fri, 28 Oct 2016 20:35:45 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20161028183545.942CC1A56E@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 28 Oct 2016 18:35:49 -0000

Ilari Liusvaara wrote:
> Martin Rex wrote:
>> Joseph Salowey wrote:
>> 
>> There are two seriously backwards-incompatible changes in the
>> current proposal that provide zero value, but completely break
>> backwards-compatibility with existing middleware infrastructure.
>> 
>> 
>> (1) hiding of the TLS record content types.
>>     Please leave the TLS record types (handshake/AppData/Alert/CCS)
>>     clearly visible on the outside of the TLS records, so that
>>     middleware protocol parsers (which interface to transport-free
>>     TLS protocol stacks) can continue to work, and continue to
>>     work efficiently.
> 
> Hiding the types does have its benefits (and it is also used for
> zero-overhead padding scheme).

Nope, ZERO benefits.  But it totally breaks the middleware
_at_the_endpoints_!


> 
> And also, TLS 1.3 handshake is so darn different from TLS 1.2, that
> you couldn't do anything sane even if you had record types.

Wrong.

If one is using an architecture where the TLS protocol stack is
transportless, so that the network communication can be performed
efficiently (coalescing TLS records that are trickling in), then
the *REAL* content type is quite important for knowing whether
the TLS handshake is still ongoing, or whether it is already
complete.

The way I've built this is that the middleware has a timeout for
the TLS handshake in its entirety (independent of the number of
roundtrips), and at the same time promises the application a
network readable event for every incoming TLS record with
application data.  This only works if I can leave TLS appdata
records partially in the incoming network buffer, and for this
I must be able to recognize them.

For processing TLS records with Handshake messages, pre-reading and
passing multiple of them is preferable and much more efficient
(if TLS handshake messages come in seperate TLS records each, which
some implementations do).  Pre-reading TLS records with handshake messages,
but not prereading TLS records with AppData (so that network readable
events will remain visible for app data) is only possible if I see the
contents on the outside of the record by just reading the TLS record header.


-Martin


From nobody Fri Oct 28 21:09:19 2016
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 C3B951295E8 for ; Fri, 28 Oct 2016 21:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bBtc6TNtgq7h for ; Fri, 28 Oct 2016 21:09:16 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93BC1295C7 for ; Fri, 28 Oct 2016 21:09:15 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id n6so12333367qtd.1 for ; Fri, 28 Oct 2016 21:09:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=sLNqbzQ9pAEjfzpnRGV5NkHQR6xKm4V1VULKEwgJyoI=; b=GWf473ubBWKgtAtYoQobifgy3fTCe4qCkhgbmcFSpYd8pO1vVKHe0ROQMalYOVZM5j KKEtgbol8m0ZedrXcpivJS2S6HyCdPzBCxH4DLnREjL6xBNuIj1LeEGXK417q16rq+uZ GRYvA+2CjXZC+ElertxYV6bXfKhDnf/V8kxJ4ZVZGPIEUB/R+/+Ihf2UBdn9VL+9xr1W cHCg+RBy6WDnEdiQUfnfeGIXYDbbhH8Ar54AAd5NAU7WVO+TzED6xqpUUmuEm0+Y/Hqp fzRCtCOI30cxWDcBIXE1Ayp9v5szk3KKEvMdJfxMYOXgf/ECAuvraidiF4J9XlwiG/eT JWcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=sLNqbzQ9pAEjfzpnRGV5NkHQR6xKm4V1VULKEwgJyoI=; b=bpzZjeOu75o+pVKEJl4ppEH6xMun5vgfBtAF4u9qs1WqvMKGk420SEgHsbl1qVu+Td hq+mskhMROJQgCVCwpekjyULh4dXjJ7CimCiWukUB/gx1WOsXDziWIRr3lgMPofTx/wC rT0ZJ83qbCiAX+JxrWeWGbrJrzIUeXuyB3RENfDgKoV7DyE7GaECMDMnWbiBxA7FYJIX JGyY+KMR2wcoGrUFnE7zg3eO1Dh4Q9SvWm1oru1l4x4H1dMBKadHfPua/riYhSRBLFfs p6hU8haO8FnmjWRp7E7rTeLdZB0GYADJBVYagbjBhWuItxsh1FXobS6FDDxHqBy2/1kc GMDw==
X-Gm-Message-State: ABUngvcJrHNyn4fRB+ZUdO+b1qxLwF6Aj5l13GNG4r0TL/oJ63qHItDVqaMyg+/Xc7jO7UpLkq46iYmSimEC3g==
X-Received: by 10.237.59.120 with SMTP id q53mr12112573qte.116.1477714151377;  Fri, 28 Oct 2016 21:09:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Fri, 28 Oct 2016 21:09:10 -0700 (PDT)
In-Reply-To: <147771337150.24947.13319458137662655584.idtracker@ietfa.amsl.com>
References: <147771337150.24947.13319458137662655584.idtracker@ietfa.amsl.com>
From: Martin Thomson 
Date: Sat, 29 Oct 2016 15:09:10 +1100
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-00.txt
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: Sat, 29 Oct 2016 04:09:18 -0000

A lot of people have asked for test vectors for TLS 1.3.  This draft
includes two very simple handshakes: a 1-RTT handshake and a 0-RTT
handshake resumed from the first.

The baling-wire and string holding this together are here:
  https://github.com/martinthomson/tls13-vectors

Requests for scenarios to trace are welcome.  The vectors are
automatically generated using the NSS test suite, so I'm very happy to
write new tests and include the traces from those tests.

Since NSS only supports draft -16, these aren't up to date with the
latest draft.  We're working on an update and I hope to be able to
provide an version that is updated to -18 before we meet.

I would like to talk about whether this is worthwhile publishing.  In
Seoul if we can't decide before then.

---------- Forwarded message ----------
From:  
Date: 29 October 2016 at 14:56
Subject: New Version Notification for draft-thomson-tls-tls13-vectors-00.txt
To: Martin Thomson 

A new version of I-D, draft-thomson-tls-tls13-vectors-00.txt
has been successfully submitted by Martin Thomson and posted to the
IETF repository.

Name:           draft-thomson-tls-tls13-vectors
Revision:       00
Title:          Example Handshake Traces for TLS 1.3
Document date:  2016-10-28
Group:          Individual Submission
Pages:          26
URL:
https://www.ietf.org/internet-drafts/draft-thomson-tls-tls13-vectors-00.txt
Status:
https://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/
Htmlized:       https://tools.ietf.org/html/draft-thomson-tls-tls13-vectors-00


Abstract:
   Examples of TLS 1.3 handshakes are shown.  Private keys and inputs
   are provided so that these handshakes might be reproduced.
   Intermediate values, including secrets, traffic keys and ivs are
   shown so that implementations might be checked incrementally against
   these values.


From nobody Sat Oct 29 07:22:36 2016
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 88D2112711D for ; Sat, 29 Oct 2016 07:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 tW2vCx8K9KIg for ; Sat, 29 Oct 2016 07:22:33 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 63643127077 for ; Sat, 29 Oct 2016 07:22:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id BFBC312CE3; Sat, 29 Oct 2016 17:22:30 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id d8jAf3-S1VPK; Sat, 29 Oct 2016 17:22:30 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 6A7A2C4; Sat, 29 Oct 2016 17:22:30 +0300 (EEST)
Date: Sat, 29 Oct 2016 17:22:28 +0300
From: Ilari Liusvaara 
To: Martin Rex 
Message-ID: <20161029142228.GA27171@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20161028162426.GA25186@LK-Perkele-V2.elisa-laajakaista.fi> <20161028183545.942CC1A56E@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20161028183545.942CC1A56E@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Sat, 29 Oct 2016 14:22:35 -0000

On Fri, Oct 28, 2016 at 08:35:45PM +0200, Martin Rex wrote:
> Ilari Liusvaara wrote:
> > Martin Rex wrote:
> >> Joseph Salowey wrote:
> >> 
> >> There are two seriously backwards-incompatible changes in the
> >> current proposal that provide zero value, but completely break
> >> backwards-compatibility with existing middleware infrastructure.
> >> 
> >> 
> >> (1) hiding of the TLS record content types.
> >>     Please leave the TLS record types (handshake/AppData/Alert/CCS)
> >>     clearly visible on the outside of the TLS records, so that
> >>     middleware protocol parsers (which interface to transport-free
> >>     TLS protocol stacks) can continue to work, and continue to
> >>     work efficiently.
> > 
> > Hiding the types does have its benefits (and it is also used for
> > zero-overhead padding scheme).
> 
> Nope, ZERO benefits.  But it totally breaks the middleware
> _at_the_endpoints_!

Allowing padding is already a large benefit. TLS 1.2 AEAD modes don't
allow padding, causing rather large unavoidable information leaks.
Especially with HTTP/1.1, which doesn't have application-level padding
mechanism nor multiplexing.


Also, things like this should have been discussed like year or two
ago. Right now it is too late for major changes like this without good
cryptographic justifications (which AFAICT don't exist).

> > And also, TLS 1.3 handshake is so darn different from TLS 1.2, that
> > you couldn't do anything sane even if you had record types.
> 
> If one is using an architecture where the TLS protocol stack is
> transportless, so that the network communication can be performed
> efficiently (coalescing TLS records that are trickling in), then
> the *REAL* content type is quite important for knowing whether
> the TLS handshake is still ongoing, or whether it is already
> complete.

I implemented zero-copy (for TLS decoding) packet receving in TLS
lib I am writing. Works in both TLS 1.2 and 1.3.

Rather big efficiency boost too... I suspect doing the same for
encoding would be another big efficiency boost.

> The way I've built this is that the middleware has a timeout for
> the TLS handshake in its entirety (independent of the number of
> roundtrips), and at the same time promises the application a
> network readable event for every incoming TLS record with
> application data.  This only works if I can leave TLS appdata
> records partially in the incoming network buffer, and for this
> I must be able to recognize them.

Note that even if the record is truly appdata, it may not contain
any data, and one can't tell this from just the type.

> For processing TLS records with Handshake messages, pre-reading and
> passing multiple of them is preferable and much more efficient
> (if TLS handshake messages come in seperate TLS records each, which
> some implementations do).  Pre-reading TLS records with handshake messages,
> but not prereading TLS records with AppData (so that network readable
> events will remain visible for app data) is only possible if I see the
> contents on the outside of the record by just reading the TLS record header.

Also, TLS 1.3, it isn't safe to reorder appdata records across
handshake records, which can be sent after primary handshake
has completed.


-Ilari


From nobody Sat Oct 29 13:02:49 2016
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D441295AA; Sat, 29 Oct 2016 13:02:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147777136515.30613.3065462234077424025.idtracker@ietfa.amsl.com>
Date: Sat, 29 Oct 2016 13:02:45 -0700
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-09.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 29 Oct 2016 20:02:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

        Title           : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
        Authors         : Yoav Nir
                          Simon Josefsson
                          Manuel Pegourie-Gonnard
	Filename        : draft-ietf-tls-rfc4492bis-09.txt
	Pages           : 32
	Date            : 2016-10-29

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
   Digital Signature Algorithm (EdDSA) as new authentication mechanisms.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat Oct 29 13:04:56 2016
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 20FD91294F4 for ; Sat, 29 Oct 2016 13:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2LVZZisryVeS for ; Sat, 29 Oct 2016 13:04:53 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518EE1294A6 for ; Sat, 29 Oct 2016 13:04:53 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id e69so167934765wmg.0 for ; Sat, 29 Oct 2016 13:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Rdt7Vd3d1DirGvAhSfWGPWkcHcJDUg29XowXg4q57gI=; b=fueE8urEBS6YIAXcuYj92/HVo+89924cpcSjRL9UDloPrXXsIIZGHjTAUXFuMhb86B vJGbp5S/2Qq2zjwbbMFGOjUw72PtN+PLFsJw/rqYF0nx7WyjHpJZ0CbttImzFtfMqXvk pwKDF+3aMgULqdiP7fjDGubaVaTImGCnaSuUcf5vH5a0Do0oyea6p8YwENSigzFAeB61 cbJKPuwW7slawrxw0agmcjTYcAEiH+P+E6PUZl8y0h/rr69PrfBEnohoYRrqVWINPzhq cvdUK4vlHIJMyaVQBRj8E3+Og04ZKkrrpZ0Y7Sos/0M/ah+pnGblX51HCe3iDplTk3Yc 5RPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Rdt7Vd3d1DirGvAhSfWGPWkcHcJDUg29XowXg4q57gI=; b=GPFAs75G1vSHbxAT+c78x60Jkt0ROZYadpRE/rvQUGI0tmnQKXTe+f9GpVY28cXbMG g4uzwko0hNCqgFAfHmxVyeYKcZrpm3GntvLSmwPwWerXW13W+ngtWk3l7k0t8ghVnsTK AVZWT+JFtQ4TyjriIiXNuKWV1tPgt8WVVOXhXGfFU/NQm9j9DQzsrXZlSucyd6VIL7kP RWcPkpmeU18iV2zgCcjf5wbaP2fxNaLT0Q8MS8aF6A6JVn6v6EU4SGvGdg8U35qYeEUm /WF5Gh8vqLimu36Id5isYYN432/CErf4/wGlH+I9DrIENvFpDIX1Dpedq2OMVJIMC2Nh hjlQ==
X-Gm-Message-State: ABUngveYNjVaUb5yCd+jnhcZczzPWaX7gMDpnLcBuvXoqph116hl/6r48p46XvHz8elkfw==
X-Received: by 10.28.21.68 with SMTP id 65mr4338102wmv.132.1477771491567; Sat, 29 Oct 2016 13:04:51 -0700 (PDT)
Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n3sm17507699wjq.34.2016.10.29.13.04.50 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 13:04:51 -0700 (PDT)
From: Yoav Nir 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Sat, 29 Oct 2016 23:04:49 +0300
References: <147777136515.30613.3065462234077424025.idtracker@ietfa.amsl.com>
To: "" 
In-Reply-To: <147777136515.30613.3065462234077424025.idtracker@ietfa.amsl.com>
Message-Id: <0AFB8C31-317E-403B-AB7B-BCF21C090C77@gmail.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-09.txt
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: Sat, 29 Oct 2016 20:04:55 -0000

Hi.

This is mostly a maintenance version. I=E2=80=99ve updated references =
and removed some TBDs for ideas that were never pursued.

IMO this is ready.

Yoav

> On 29 Oct 2016, at 23:02, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Transport Layer Security of the IETF.
>=20
>        Title           : Elliptic Curve Cryptography (ECC) Cipher =
Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
>        Authors         : Yoav Nir
>                          Simon Josefsson
>                          Manuel Pegourie-Gonnard
> 	Filename        : draft-ietf-tls-rfc4492bis-09.txt
> 	Pages           : 32
> 	Date            : 2016-10-29
>=20
> Abstract:
>   This document describes key exchange algorithms based on Elliptic
>   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
>   protocol.  In particular, it specifies the use of Ephemeral Elliptic
>   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and =
the
>   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and =
Edwards
>   Digital Signature Algorithm (EdDSA) as new authentication =
mechanisms.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-09
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-09
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Sat Oct 29 14:28:43 2016
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 ACF52129439 for ; Sat, 29 Oct 2016 14:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xLrAb_EstDiO for ; Sat, 29 Oct 2016 14:28:40 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2935C1293D8 for ; Sat, 29 Oct 2016 14:28:40 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id i127so166475481oia.2 for ; Sat, 29 Oct 2016 14:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=r6vceuRHb7iEYuDNWMC1JkrXsd172rx1uwVBGwJqfGI=; b=W0hB80UVBBS9yRToKbR38i9yUNql2HdjocVAlLNBS2uZnXSekZsUs35hGSfhCNK6cU oFRbVnSrjPKtYKgrSnOdz6+UtNcZJqmRDhAtW1eZsAnzFwHFVE1trWLzMtNljw+8mnqS 98kfbr4e76KvOe0y6bM92+D43uO1rDCeibB42aL4F9kVJ+XQRishgXb0T+uQblg5Na+j If/shFhNUpV36g763v7StSQemQikW3ygotZCLF1F2kS5Em8TFTYFVDG8T20liinuJXu8 dm+XPkxWP3Lu2gzt6lIFB2aCvs7kpnhfyGzk+3m3ieKQxCxeTpNfzdjkl3jVEY4AdJ9Y zvGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r6vceuRHb7iEYuDNWMC1JkrXsd172rx1uwVBGwJqfGI=; b=ARh4hht+216c1lMdPVglAAHe6NqZs2oH7sySgiDzzlTMcKYkgvXpHAAQaGkALpwG6J yRAk1xYG7qTgDRoC3MwSIeYVWwTndtkcrK9zy61wV3Rz5Q5of5s84BZGO8C0T8SD88dT 6vthviTxDidBfDL9Nh5wMSjZXfOjHrIkOiLYGQ7uPPyaadGWPsxK8wLxiiqL9K2AfbZF Dpmil3JtooVdT6C1lHnNvyZg+CmpuK6NBss6h49HFkGPr7UTy0+RXjNB/AlXUGxd3AKm Zzn7ZVU7w43z/bc4RLTRMoSFdcfgPpdzLF8538Mc6AVjA60ZvFMd7MEjVnFRQD6i7jNH +Rbw==
X-Gm-Message-State: ABUngvexmprs8gSqcdO0Lorl3+UnA71TZFDyu1qBGQR0NZbltv8zOTVXkq5iUqGm93+ck/BvGz5VRGI/NlehJw==
X-Received: by 10.157.48.70 with SMTP id w6mr15339062otd.174.1477776519257; Sat, 29 Oct 2016 14:28:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.181.9 with HTTP; Sat, 29 Oct 2016 14:27:58 -0700 (PDT)
From: Joseph Birr-Pixton 
Date: Sat, 29 Oct 2016 22:27:58 +0100
Message-ID: 
To: tls@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] PSS SignatureScheme ordinal choice
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: Sat, 29 Oct 2016 21:28:42 -0000

Just a quick question. In TLS1.3 we have:

     enum {
          rsa_pkcs1_sha1 (0x0201),
          rsa_pkcs1_sha256 (0x0401),
          rsa_pkcs1_sha384 (0x0501),
          rsa_pkcs1_sha512 (0x0601),
          ecdsa_secp256r1_sha256 (0x0403),
          ecdsa_secp384r1_sha384 (0x0503),
          ecdsa_secp521r1_sha512 (0x0603),
(then)
          rsa_pss_sha256 (0x0804),
          rsa_pss_sha384 (0x0805),
          rsa_pss_sha512 (0x0806),
      } SignatureScheme;

This kind of looks like someone was trying to make the
rsa_pss_shasomething ordinals be decodable by a TLS1.2 implementation
given a SignatureAlgorithm reservation for PSS of 8, but got the bytes
the wrong way around.

Is this an error, or am I missing something subtle?

Cheers,
Joe


From nobody Sat Oct 29 14:59:56 2016
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 42AEE129407 for ; Sat, 29 Oct 2016 14:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 DOZVPHr1HxVn for ; Sat, 29 Oct 2016 14:59:53 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 336DE120726 for ; Sat, 29 Oct 2016 14:59:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AF28B165DD; Sun, 30 Oct 2016 00:59:51 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id wMZL4KFLOqB9; Sun, 30 Oct 2016 00:59:51 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 6904921C; Sun, 30 Oct 2016 00:59:51 +0300 (EEST)
Date: Sun, 30 Oct 2016 00:59:49 +0300
From: Ilari Liusvaara 
To: Joseph Birr-Pixton 
Message-ID: <20161029215949.GA27953@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] PSS SignatureScheme ordinal choice
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: Sat, 29 Oct 2016 21:59:55 -0000

On Sat, Oct 29, 2016 at 10:27:58PM +0100, Joseph Birr-Pixton wrote:
> Just a quick question. In TLS1.3 we have:
> 
>      enum {
>           rsa_pkcs1_sha1 (0x0201),
>           rsa_pkcs1_sha256 (0x0401),
>           rsa_pkcs1_sha384 (0x0501),
>           rsa_pkcs1_sha512 (0x0601),
>           ecdsa_secp256r1_sha256 (0x0403),
>           ecdsa_secp384r1_sha384 (0x0503),
>           ecdsa_secp521r1_sha512 (0x0603),
> (then)
>           rsa_pss_sha256 (0x0804),
>           rsa_pss_sha384 (0x0805),
>           rsa_pss_sha512 (0x0806),
>       } SignatureScheme;
> 
> This kind of looks like someone was trying to make the
> rsa_pss_shasomething ordinals be decodable by a TLS1.2 implementation
> given a SignatureAlgorithm reservation for PSS of 8, but got the bytes
> the wrong way around.
> 
> Is this an error, or am I missing something subtle?

Actually, those PSS schemes intentionally have a new hash (for some
reasons). Never noticed the second bytes would be hash algorithm bytes
for SHA-256/384/512).


-Ilari


From nobody Sat Oct 29 16:15:49 2016
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 34E7C12940F for ; Sat, 29 Oct 2016 16:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 5xLVvfXMJGum for ; Sat, 29 Oct 2016 16:15:46 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BA1129409 for ; Sat, 29 Oct 2016 16:15:46 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id u124so117056046ywg.3 for ; Sat, 29 Oct 2016 16:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xH3aiVnSjpdXcPDdkjtxsszsNCy1ct0RnAbVnM094oY=; b=GH0mag93DMX7iJCan7n0twXkZ+fYyUr/tCUYQaKSBGdOlnpu0mr6Qrvl6z+HvcUjqM h6BpdzFR8SzefkWsnZ7g/cYkvFrXrUvUcP6Ba3WdJT0oOyR0uFpE6wv8DZSksiznQ8db PAUqPNd2l5DrIerTyjX3YYwkrFCFcjOssAtROUYn52wW1HjSVTum2TD8GWR/K0hm+i8g xOEqIzudnzCCcb8JU0T3ze7xeUDv9SFzhTkstb4esS7SjdQiQko2bj5XhTV8IYG+CODx ier+xgasH0JXAqfEBxl0LYrbtdj+tiK2u8m6wKHWOz95Bf7ucKCyTl57XbOHWWBAurGK AYZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xH3aiVnSjpdXcPDdkjtxsszsNCy1ct0RnAbVnM094oY=; b=CqwK5afWVJkEDyRbi1sPimiNMQeKjZXsuZ9zqghQFgJ7anC1mrhVnepIugTqbljeJc w+xTcmuQwMVZTm0DH/KxIgAlpYlRvBXKdT/pzthabjrPl7sZE/QEL+XRb+I+5e//z3SV Rst1ro/FgDnqQKbJTdIvpwAK9Pum+qkdhpY867SjHG8KpVQPEC00m69Aj4CZWFASe0AY w6OJXcYwjRqB1myLYqdC5vOETbR5jgGgJK7xTDhvB8xljaJ9if0hCxySOuOcJrLtyGap OKKTsjaOp2eLUBaEdqRbx8CCNTwrX1pgPfQ3NdQYu6adt+4Yf/eD91ISrUxIbkLpkpJH /oTg==
X-Gm-Message-State: ABUngvfSyaYsgxgnbOO0Y8CT0U+I15g6a3S6+qTMMjNDiY8FAew6ArZ50RoEnDzejlozSGFN8xv9y81astSFMw==
X-Received: by 10.129.121.206 with SMTP id u197mr17433224ywc.146.1477782945955;  Sat, 29 Oct 2016 16:15:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Sat, 29 Oct 2016 16:15:05 -0700 (PDT)
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Sat, 29 Oct 2016 16:15:05 -0700
Message-ID: 
To: Joseph Birr-Pixton 
Content-Type: multipart/alternative; boundary=94eb2c0b0f688cc18b05400927b0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] PSS SignatureScheme ordinal choice
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: Sat, 29 Oct 2016 23:15:48 -0000

--94eb2c0b0f688cc18b05400927b0
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 29, 2016 at 2:27 PM, Joseph Birr-Pixton 
wrote:

> Just a quick question. In TLS1.3 we have:
>
>      enum {
>           rsa_pkcs1_sha1 (0x0201),
>           rsa_pkcs1_sha256 (0x0401),
>           rsa_pkcs1_sha384 (0x0501),
>           rsa_pkcs1_sha512 (0x0601),
>           ecdsa_secp256r1_sha256 (0x0403),
>           ecdsa_secp384r1_sha384 (0x0503),
>           ecdsa_secp521r1_sha512 (0x0603),
> (then)
>           rsa_pss_sha256 (0x0804),
>           rsa_pss_sha384 (0x0805),
>           rsa_pss_sha512 (0x0806),
>       } SignatureScheme;
>
> This kind of looks like someone was trying to make the
> rsa_pss_shasomething ordinals be decodable by a TLS1.2 implementation
> given a SignatureAlgorithm reservation for PSS of 8, but got the bytes
> the wrong way around.
>
> Is this an error, or am I missing something subtle?
>

No, it's not an error. We deliberately allocated code points with (what
would be in TLS 1.2)
an unknown hash and an unknown signature algorithm. AFAIK it's just
coincidence that the second
byte matches up with the 1.5 digest algorithms, by virtue of us counting
upward.

-Ekr


> Cheers,
> Joe
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c0b0f688cc18b05400927b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, Oct 29, 2016 at 2:27 PM, Joseph Birr-Pixton &=
lt;jpixton@gmail.com=
> wrote:
Just a quick quest=
ion. In TLS1.3 we have:



=C2=A0 =C2=A0 =C2=A0enum {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pkcs1_sha1 (0x0201),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pkcs1_sha256 (0x0401),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pkcs1_sha384 (0x0501),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pkcs1_sha512 (0x0601),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ecdsa_secp256r1_sha256 (0x0403),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ecdsa_secp384r1_sha384 (0x0503),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ecdsa_secp521r1_sha512 (0x0603),

(then)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_sha256 (0x0804),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_sha384 (0x0805),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_sha512 (0x0806),

=C2=A0 =C2=A0 =C2=A0 } SignatureScheme;



This kind of looks like someone was trying to make the

rsa_pss_shasomething ordinals be decodable by a TLS1.2 implementation

given a SignatureAlgorithm reservation for PSS of 8, but got the bytes

the wrong way around.



Is this an error, or am I missing something subtle?
No, it's not an error. We deliberately allocated code poin=
ts with (what would be in TLS 1.2)
an unknown hash and an unknown=
 signature algorithm. AFAIK it's just coincidence that the second
=

byte matches up with the 1.5 digest algorithms, by virtue of us counti=
ng upward.

-Ekr
=C2=A0

Cheers,

Joe



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c0b0f688cc18b05400927b0--


From nobody Sun Oct 30 03:03:45 2016
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 397B012949E for ; Sun, 30 Oct 2016 03:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 M9i9zeqq5HMS for ; Sun, 30 Oct 2016 03:03:43 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A89F126B6D for ; Sun, 30 Oct 2016 03:03:43 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id q130so13415354qke.1 for ; Sun, 30 Oct 2016 03:03:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=Idr+gYiVfDT/2/9R0RX2ooczsc7pxXgpEhUj3mTT0dI=; b=Is61ep99JTgCtCHOPTQ8LBXtlqmqsIjMXnERmIaoObWomlH+pR72gw0E+b9w36MjX9 xP03y3rx6qBhjTiFqrcDlRClqW2vNaWXHsh8HgLMBckmOOtEk1lIY0R6FCzoOuLjT7KC k7upqLRv4bnktl+sIoB4Kp5VVDV8wf/MhwErUvvE/JVDE40EigAADxCOpaCX4zH/Sbkl SHQ1Am6MT5NMD7+G8U3Ojs0qbZxX/TTbKujYsa/kmikWpl58l8TWhfAk+25s12rAcwaM BqRNpcb9VoZZnDamxMPXUQo0VMYZrEVETqpxgUreDDWP5mP5MyyS+WFtplkOrxnOsew8 0e9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Idr+gYiVfDT/2/9R0RX2ooczsc7pxXgpEhUj3mTT0dI=; b=i/z00df6DBT1YKc0D+7bg2hLWxMu1E0vo8lRQ5Z/ry4tvOyTA/TTy7m3BedRBJCOXz Q7guCNMCmCMKqusbv4tXGG+ZTRVYpvOKhg5hZSfNT+eEXql0xGulqTf5x2M9ihoA7joM msTNyR1SmpfW5p+KbLlc3IZjyskBkbUa00WYap++3ON9nWqmaJjc6YXH24FcHBSkHS15 IwHRvQLLy6NOLEIvZHOZixN+q2tFaseT03/Rbpy4sxNrjvv9TDbeA1kL64VAd+lDaHJg /bFAy1ycvAbMXW1teTixU/ehmShIRm/EbL54V5ma5kTpRzhTwKGmj2oYNc3Bo0HwqDwi +tWg==
X-Gm-Message-State: ABUngvfurVC1ex1QPfbaNv7RQ0Eq/vx94tdDTKp6Re1tTyVLQD6lyY9e4o9Ex4TM0DVw61Jr6KCApW7p/opdAQ==
X-Received: by 10.55.12.2 with SMTP id 2mr14509361qkm.68.1477821822269; Sun, 30 Oct 2016 03:03:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Sun, 30 Oct 2016 03:03:41 -0700 (PDT)
From: Martin Thomson 
Date: Sun, 30 Oct 2016 21:03:41 +1100
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] Padding extension and 0-RTT
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: Sun, 30 Oct 2016 10:03:44 -0000

(Trivial optimization warning)

Just perusing my draft and noticed that NSS pads a 0-RTT handshake,
which is not that surprising given that it's fairly beefy (it will get
even larger in -18).  Since a 0-RTT handshake will break servers that
don't at least superficially understand TLS 1.3, maybe we could avoid
pading in this case.  Is there any reason we shouldn't include that
advice in the draft?


From nobody Sun Oct 30 12:52:36 2016
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 34FA1129473 for ; Sun, 30 Oct 2016 12:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level: 
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 UPMmkz-GMo_b for ; Sun, 30 Oct 2016 12:52:32 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B2F129408 for ; Sun, 30 Oct 2016 12:52:32 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id 62so64614751oif.1 for ; Sun, 30 Oct 2016 12:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=k9lgKDELG4AmlvzCztOyBC4GMCrqKFTxSJQNNUAH1Z0=; b=dJMASYBq3jI/VLUhXuH7plB+z6MZbEWwRk7CebHrfk+EnxhbVKPCc81PvJ99dupbwl yLNuL/sWn2vUEgqDSyChCy+JiEvg2Uja+ywYONG2KXC3ZePWh0iqikkG++quyo4ojXEh aouqD2p01YmR0dusPD+wuvSO9W+OeWeTfvTUM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=k9lgKDELG4AmlvzCztOyBC4GMCrqKFTxSJQNNUAH1Z0=; b=F9V4h26M9l66zi+xxSNXSU7Ff+4s492uC1edh6l+1dYGc8OEYKIzGaD4o7GtC0HSCG aaBE9w2i8FkiUK2OSY2R1frPDB5l/F0PaTHwAl1o6RG1Hc0Q2mQwb30eDPWcglYV/BR3 QBdqft8/xLB8hqyCfo2NtjCybTwIrmxQYdQmBC1biDdZR7EV42yCb2QNMLz/z27h9wk/ QhqqO3tBkYLXPApEwgVOekmM/wZUfBbheanBFHNnRmKP+pXl0UPQ5oTNguBCzn7lrJD9 XNtLj+GJdCrGrCJ7eSM5uFYaMo3i7irNRsmFjdDsnLcWSmZ397WPOWG9/+xVfHDC+gqv Cqdg==
X-Gm-Message-State: ABUngvcijwY7MwTyHnShI7NFmAseXUd8ag7sqfuDtLNIs5IfX4Xr5B7jJ93ZAmBGaajkZ2nYIs3fMJGTAn4q/USM
X-Received: by 10.107.15.146 with SMTP id 18mr20561884iop.22.1477857152022; Sun, 30 Oct 2016 12:52:32 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: David Benjamin 
Date: Sun, 30 Oct 2016 19:52:20 +0000
Message-ID: 
To: Martin Thomson , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ed64a938c4905401a6e6e
Archived-At: 
Subject: Re: [TLS] Padding extension and 0-RTT
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: Sun, 30 Oct 2016 19:52:35 -0000

--001a113ed64a938c4905401a6e6e
Content-Type: text/plain; charset=UTF-8

Sounds reasonable.

One concern is the F5 bug's failure mode was a timeout rather than an
error, so, if you take away padding, the allowance in C.3 will not save
heterogenous deployments where some servers do 1.3 and some are old F5
servers. But given we're talking about a straight-up server bug now, it
seems reasonable for a client to say, okay, I will try to account for
heterogenous 1.2 and 1.3 deployments because that's kinda operationally
tricky, but if you've got that F5 bug, please fix it already.

David


On Sun, Oct 30, 2016 at 6:03 AM Martin Thomson 
wrote:

(Trivial optimization warning)

Just perusing my draft and noticed that NSS pads a 0-RTT handshake,
which is not that surprising given that it's fairly beefy (it will get
even larger in -18).  Since a 0-RTT handshake will break servers that
don't at least superficially understand TLS 1.3, maybe we could avoid
pading in this case.  Is there any reason we shouldn't include that
advice in the draft?

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

--001a113ed64a938c4905401a6e6e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Sounds reasonable.
One concern is the F5 bug's failure mode was a timeout rather than an=
 error, so, if you take away padding, the allowance in C.3 will not save he=
terogenous deployments where some servers do 1.3 and some are old F5 server=
s. But given we're talking about a straight-up server bug now, it seems=
 reasonable for a client to say, okay, I will try to account for heterogeno=
us 1.2 and 1.3 deployments because that's kinda operationally tricky, b=
ut if you've got that F5 bug, please fix it already.

David

=


On Sun, Oct 30, 2016 at 6:0=
3 AM Martin Thomson <martin.thomson@gmail.com> wrote:
(Trivia=
l optimization warning)



Just perusing my draft and noticed that NSS pads a 0-RTT handshake,

which is not that surprising given that it's fairly beefy (it will get<=
br class=3D"gmail_msg">
even larger in -18).=C2=A0 Since a 0-RTT handshake will break servers that<=
br class=3D"gmail_msg">
don't at least superficially understand TLS 1.3, maybe we could avoid
pading in this case.=C2=A0 Is there any reason we shouldn't include tha=
t

advice in the draft?



_______________________________________________

TLS mailing list

TLS@i=
etf.org

https://www.ietf.org/mailman/listinfo/t=
ls




--001a113ed64a938c4905401a6e6e--


From nobody Sun Oct 30 12:59:12 2016
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 63166128B37 for ; Sun, 30 Oct 2016 12:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 8LumGRKVcVIE for ; Sun, 30 Oct 2016 12:59:09 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036E412711D for ; Sun, 30 Oct 2016 12:59:09 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id r204so15766096ywb.0 for ; Sun, 30 Oct 2016 12:59:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oNjGwlbYIaxdO5ci/HDa6TIYck+w/U8tIbYNUYTRE34=; b=ltpBuabq/DVXTHQaHsHnub+WN7zLgNIv08hTreVYq/rmodGpkQ5rbTbkMS7uidsjB9 +z4Y4BvBUk7uUZs4ph4FmFoOpf4DHIiKMV3tbRPz336iUviKzSe2dSStVlIG9zth4kPa d5Tuy9hWfElbw0ERrxHgnkBW1tVtb9MJGMC1E+/SwM3VzTNwUFkDEz46/HnZlxrpN8Zl oxGUsMKY2wDJMpf2mDKdD0S8pSvYZ58SORm6V7JN2kyZriRnxP7jNn0W1vXV05zvrKdC tn7QWt/Jgn693PsrNRdIJ/fvlnk7FZp+3/5AyTTcgYoi9B2cQkE3G8Iazp+CCiKBbpwt KkSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oNjGwlbYIaxdO5ci/HDa6TIYck+w/U8tIbYNUYTRE34=; b=Rh3zLAb/kYY5op/j8Qv8Ycv0vxOPqQMEp3CyOUFrKJH76hcS1L8qWjUrBMWX8PCA11 RYNuWvKoAi2wNp9jzwLq7WyPCT8hP6X6aU8rP0RP+j+DCQAXv3kTS/w3+xE5cYFRkuoo JdP/YmPg3Qetxd2zows441oe2PuEaLkbqVSKLBPuBD+glLDir0KL/enruAJGvwLJWc/1 Hfzahu8qX5blMyDCEWHT9aWO8HieULMsKL8zN1pYPApKkVKEtix+PMtwl47V4IB0jhmj 85Ql9yM2CUEixaA2M3WFlKjP0dPNGRJNoSaJB9IkK/RnpJvHcU4O5Wyux+va3wkRdslq FY7w==
X-Gm-Message-State: ABUngvcS58gFIwCwk8wvvaX9/1y6mph9NEu5L4zR29D/EMpvLIySeSJkT5feaYwRKg7w0/gY6HUwt43fjrd18Q==
X-Received: by 10.129.121.1 with SMTP id u1mr2345647ywc.146.1477857548177; Sun, 30 Oct 2016 12:59:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Sun, 30 Oct 2016 12:58:27 -0700 (PDT)
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Sun, 30 Oct 2016 12:58:27 -0700
Message-ID: 
To: David Benjamin 
Content-Type: multipart/alternative; boundary=94eb2c0a8f82304d4b05401a86cd
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Padding extension and 0-RTT
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: Sun, 30 Oct 2016 19:59:10 -0000

--94eb2c0a8f82304d4b05401a86cd
Content-Type: text/plain; charset=UTF-8

I'm ambivalent on this. OTOH, you're technically right, but OTOH it's just
one more conditional to save a few bytes (you need padding to exist
anyway), and if you're doing 0-RTT, you're about to send a lot more bytes
anyway.

-Ekr




On Sun, Oct 30, 2016 at 12:52 PM, David Benjamin 
wrote:

> Sounds reasonable.
>
> One concern is the F5 bug's failure mode was a timeout rather than an
> error, so, if you take away padding, the allowance in C.3 will not save
> heterogenous deployments where some servers do 1.3 and some are old F5
> servers. But given we're talking about a straight-up server bug now, it
> seems reasonable for a client to say, okay, I will try to account for
> heterogenous 1.2 and 1.3 deployments because that's kinda operationally
> tricky, but if you've got that F5 bug, please fix it already.
>
> David
>
>
> On Sun, Oct 30, 2016 at 6:03 AM Martin Thomson 
> wrote:
>
> (Trivial optimization warning)
>
> Just perusing my draft and noticed that NSS pads a 0-RTT handshake,
> which is not that surprising given that it's fairly beefy (it will get
> even larger in -18).  Since a 0-RTT handshake will break servers that
> don't at least superficially understand TLS 1.3, maybe we could avoid
> pading in this case.  Is there any reason we shouldn't include that
> advice in the draft?
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c0a8f82304d4b05401a86cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm ambivalent on this. OTOH, you're technically r=
ight, but OTOH it's just one more conditional to save a few bytes (you =
need padding to exist anyway), and if you're doing 0-RTT, you're ab=
out to send a lot more bytes anyway.

-Ekr

=




On Sun, Oct 30, 2016 at 12:52 PM, David Benjamin <d=
avidben@chromium.org> wrote:
Sounds reasonable.

One concern is the F5 bug's failure mode was =
a timeout rather than an error, so, if you take away padding, the allowance=
 in C.3 will not save heterogenous deployments where some servers do 1.3 an=
d some are old F5 servers. But given we're talking about a straight-up =
server bug now, it seems reasonable for a client to say, okay, I will try t=
o account for heterogenous 1.2 and 1.3 deployments because that's kinda=
 operationally tricky, but if you've got that F5 bug, please fix it alr=
eady.
D=
avid


On Sun, Oct 30,=
 2016 at 6:03 AM Martin Thomson <martin.thomson@gmail.com> wrote:
(Trivial optimiza=
tion warning)



Just perusing my draft and noticed that NSS pads a 0-RTT handshake,

which is not that surprising given that it's fairly beefy (it will get<=
br class=3D"m_2396851799138713256m_-3021758033615196580gmail_msg">
even larger in -18).=C2=A0 Since a 0-RTT handshake will break servers that<=
br class=3D"m_2396851799138713256m_-3021758033615196580gmail_msg">
don't at least superficially understand TLS 1.3, maybe we could avoid
pading in this case.=C2=A0 Is there any reason we shouldn't include tha=
t

advice in the draft?



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c0a8f82304d4b05401a86cd--


From nobody Sun Oct 30 14:13:29 2016
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 B755B129428 for ; Sun, 30 Oct 2016 14:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WOQbN90U7VR1 for ; Sun, 30 Oct 2016 14:13:25 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8C012941D for ; Sun, 30 Oct 2016 14:13:25 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id p16so64220783qta.0 for ; Sun, 30 Oct 2016 14:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tLspoGsv5Z3P7uDzgJUX4dgGMpSq32VZwfbHT48N8Gg=; b=aI1avukB6gkTOpJPKE+7v/DQaUcQmQtKZz7xZI+lnRb7+Auo+6VCKtdMGgUsKuVOqZ C32QYR/Snxjace2EIArjwmXmewae5O7HMCZyHLJ96bQG6+oGURMlJXcLFW2HgE/tTG3w isrM4D6xPAWtWWYRCCtD5Tnqw9pwD4ce2BrkuGmZEo9FdHklTQsPsE96GKVmdboqTevp DeqXXXrCQd2qnOjOnnOgtzLYgLUd8hfrIMHyCneP/6IuKU7vgoWKhNgpjOQTejPr6XBR Wy6lpalTKWtH1BEm0mLAiF13JUA+kqBNeimZQSenzFVrBtrSqIuqSTBo2gqioBI27bti 4qzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tLspoGsv5Z3P7uDzgJUX4dgGMpSq32VZwfbHT48N8Gg=; b=AfjYnMxlbVzWmDYYpodDbgW8ebgCfIuiggtELeBR/tZlN4q7MmlGU4BsCQ/i4mo9Gc LAejB2IK4EOer6LUM8bTQ4DcoHLUmrsL7E93wWXUUl+YbtB8KoTRZNZ+SAm+evoRWVFF p77MjOAMLt8HMbUMf3dJ6Iw/wmTHAQcHP1VQ5sbW1LbRXFgik2hqlmDM9gJTUhreYOlk NK/+/00Rg/SVMb+dn9Jo+GZilcTkD2ZSbCABobOYYd0NDaXXQFPjtlMIVMfdOEZp4yF7 ej+tjCxyBP3xJq595oCsx3mSexh0K8DsImwV0W3vP3LsSyxDY/d4JbPGsYNl26DIxVCB CFHQ==
X-Gm-Message-State: ABUngvcNgO0E3LwMCRkqDde2VC58oUXuwvFAeebo2gTCTVFM+bbFdh4jWA7AsYmgFlT81V2+Si/nJvKGakdreg==
X-Received: by 10.237.53.132 with SMTP id c4mr7315264qte.85.1477862004245; Sun, 30 Oct 2016 14:13:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Sun, 30 Oct 2016 14:13:23 -0700 (PDT)
In-Reply-To: 
References:   
From: Martin Thomson 
Date: Mon, 31 Oct 2016 08:13:23 +1100
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Padding extension and 0-RTT
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: Sun, 30 Oct 2016 21:13:27 -0000

On 31 October 2016 at 06:58, Eric Rescorla  wrote:
> I'm ambivalent on this. OTOH, you're technically right, but OTOH it's just
> one more conditional to save a few bytes (you need padding to exist anyway),
> and if you're doing 0-RTT, you're about to send a lot more bytes anyway.

0-RTT happens when you have a small CWND.  I thought that it was maybe
worth it.  The space I'm seeing padded is enough for an extra request,
maybe two.


From nobody Sun Oct 30 14:30:27 2016
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 0DF691294AB for ; Sun, 30 Oct 2016 14:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 sK6c4B6TD1RR for ; Sun, 30 Oct 2016 14:30:24 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BFA12940A for ; Sun, 30 Oct 2016 14:30:24 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id w3so123091573ywg.1 for ; Sun, 30 Oct 2016 14:30:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8YaX75i1d7Nmi+oHLTQmpOoMa9eaTDYr1nJN4LMgZgs=; b=W5xFbk09zmvIXo4nn9YGQIeoOfONL2pWagL3muw5TYuIFjHReNcmuz7WSHyyqekPkf mLSR68kQaYi+os24BAnsO524lWhYXoQxiDypH2RFV2kxe0iaXeLRjCsdS1uL/I0zYrXW t8uNBrwRpBaGELgKOHuTrSFEXz4zE6hwozSgt3QdXnGCLcYod6sCXY1aJsQfvJCfeoND zh70o6ft39MpdE9Y6gEE00f2f92MO2CT+oMa7O88rIt62K7JvlpyksENnZ8Jqa0c4My7 7hovIcFb6H08sE1SC5oapi3W7I5TKiRpXl4CBvwtlgquTSOHXbwc3hsogEnGdzBkwVGF DXfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8YaX75i1d7Nmi+oHLTQmpOoMa9eaTDYr1nJN4LMgZgs=; b=D/CtZzV4Q8VC9PCqB1kOKxseGhvAzWDDgnnAjPiPOGKNQygHRW+T6kaqrE+9JKZp1x iz6xTM9zlOwBNbvUVI6FSEm4jREQ6as6yHPuggcqYoCdAN173MxCfmY4mEYZpoK5Jn0a g+dSN51RWtHDmn8piCtlVsfPxVPTG0NjCY6JGn+wjv4AIj1MKB3HSOQdV+L0cv2t4AW4 xJljPP1bmRxFGTouEg6oNulLrMJIKgDFtWKCMuEXWq8vKXRMZuCK9YPohcGqNrHVVa2E hbZjC/q4gdJTRvRK4+UZb4dRXjW87eK+nnuNvnY39OimcoMECFa0fpDYysn4yPF/8Bjg X+iQ==
X-Gm-Message-State: ABUngvez5Dhn4Pg+i+MJBk1YT/+UgdbAuhj6CA76XEKz+dQA6PCpeWM9KhNi88Jwv6Ms24932EqXO/Kivo2Twg==
X-Received: by 10.129.108.216 with SMTP id h207mr5089193ywc.52.1477863023515;  Sun, 30 Oct 2016 14:30:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Sun, 30 Oct 2016 14:29:43 -0700 (PDT)
In-Reply-To: 
References:    
From: Eric Rescorla 
Date: Sun, 30 Oct 2016 14:29:43 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a114dd36e8b473005401bcc3c
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Padding extension and 0-RTT
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: Sun, 30 Oct 2016 21:30:26 -0000

--001a114dd36e8b473005401bcc3c
Content-Type: text/plain; charset=UTF-8

On Sun, Oct 30, 2016 at 2:13 PM, Martin Thomson 
wrote:

> On 31 October 2016 at 06:58, Eric Rescorla  wrote:
> > I'm ambivalent on this. OTOH, you're technically right, but OTOH it's
> just
> > one more conditional to save a few bytes (you need padding to exist
> anyway),
> > and if you're doing 0-RTT, you're about to send a lot more bytes anyway.
>
> 0-RTT happens when you have a small CWND.


Fair enough.



> I thought that it was maybe
> worth it.  The space I'm seeing padded is enough for an extra request,
> maybe two.
>

Note: this will change somewhat with draft-18, because ClientHello is going
to expand
by ~32 octets.

-Ekr

--001a114dd36e8b473005401bcc3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sun, Oct 30, 2016 at 2:13 PM, Martin Thomson <<=
a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson=
@gmail.com> wrote:
On 31 October 2016 at 06:58, Eric Rescorla <ekr@rtfm.com> wrote:

> I'm ambivalent on this. OTOH, you're technically right, but OT=
OH it's just

> one more conditional to save a few bytes (you need padding to exist an=
yway),

> and if you're doing 0-RTT, you're about to send a lot more byt=
es anyway.



0-RTT happens when you have a small CWND.=C2=A0 
Fair enough.

=C2=A0
I thought that it was maybe

worth it.=C2=A0 The space I'm seeing padded is enough for an extra requ=
est,

maybe two.

Note: this will change somew=
hat with draft-18, because ClientHello is going to expand
by ~32 =
octets.

-Ekr


<=
/div>

--001a114dd36e8b473005401bcc3c--


From nobody Mon Oct 31 06:34:14 2016
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 8A6BC1297C3 for ; Mon, 31 Oct 2016 06:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 nqD0J6X6PZaM for ; Mon, 31 Oct 2016 06:34:10 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAF81296D0 for ; Mon, 31 Oct 2016 06:34:00 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id q130so41430968qke.1 for ; Mon, 31 Oct 2016 06:34:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7ngvZlUg7+RwKQk33lqDAhR8TG8um8oSabkyeXzZ5lo=; b=KuNDCWwDKJFI866mcF2ul6rDlgK9Jqr7cxoP8SiGk9hHZ2JpRPJkltxEdDNMagPrja sg24iYYFaBezWlPCmiJM0wt+5zcg/SO+CQ+/DqefcztdqxmxBeAMcCMUSYhE3hYxtCIW u88fEoqqIOelLApDvWlSTGbS/iqOmpJ/PslRw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7ngvZlUg7+RwKQk33lqDAhR8TG8um8oSabkyeXzZ5lo=; b=e0r5gSKrTT7ge2WYmleLpwzmViJeZYPtcU7YSB5y1RZijM3SygPsb/t9fZYRd97p/8 jyTZrWRYnzkBId1L5LwyPKQrs7KQjfH1fg+Xqkwcb9xNC4gqYvBIbF18Vrpt0suuD6In X+PeiGkvwxS9QmVkKRklEoqz+yON/H1fZO+23LbWUptJZ0akTX4pXtqS05t0UegZhj9A ph88MVxbP4aOnvJRupHYzWU6PNSkbfOv9WFRJE4IHK4oeJy7w++CiDSkByO7yBoisfhb zCt80HWas1yx5SJtSP/ADz/85kVdcWxNCkwBXb8ya7xbSqkk8oQuoXYkz9R/TcziI+Hr sNyg==
X-Gm-Message-State: ABUngvfEMX+Wlq0YlvI+GpfNz7qBJlrdYtsOoNeZkCSK1dT3aDJOnBLA2qj7Q+wszAnD8w==
X-Received: by 10.55.33.2 with SMTP id h2mr23937544qkh.230.1477920839935; Mon, 31 Oct 2016 06:33:59 -0700 (PDT)
Received: from [172.16.0.92] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id z41sm13184005qtb.13.2016.10.31.06.33.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Oct 2016 06:33:59 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: <0AFB8C31-317E-403B-AB7B-BCF21C090C77@gmail.com>
Date: Mon, 31 Oct 2016 09:33:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <00DD77B9-E50D-4B40-AABF-D4D142930BF9@sn3rd.com>
References: <147777136515.30613.3065462234077424025.idtracker@ietfa.amsl.com> <0AFB8C31-317E-403B-AB7B-BCF21C090C77@gmail.com>
To: Yoav Nir 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-09.txt
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: Mon, 31 Oct 2016 13:34:12 -0000

Yoav thanks for continuing to push this. We=E2=80=99ll update the status =
slides once we kick off the next steps.

spt

> On Oct 29, 2016, at 16:04, Yoav Nir  wrote:
>=20
> Hi.
>=20
> This is mostly a maintenance version. I=E2=80=99ve updated references =
and removed some TBDs for ideas that were never pursued.
>=20
> IMO this is ready.
>=20
> Yoav
>=20
>> On 29 Oct 2016, at 23:02, internet-drafts@ietf.org wrote:
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the Transport Layer Security of the =
IETF.
>>=20
>>       Title           : Elliptic Curve Cryptography (ECC) Cipher =
Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
>>       Authors         : Yoav Nir
>>                         Simon Josefsson
>>                         Manuel Pegourie-Gonnard
>> 	Filename        : draft-ietf-tls-rfc4492bis-09.txt
>> 	Pages           : 32
>> 	Date            : 2016-10-29
>>=20
>> Abstract:
>>  This document describes key exchange algorithms based on Elliptic
>>  Curve Cryptography (ECC) for the Transport Layer Security (TLS)
>>  protocol.  In particular, it specifies the use of Ephemeral Elliptic
>>  Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and =
the
>>  use of Elliptic Curve Digital Signature Algorithm (ECDSA) and =
Edwards
>>  Digital Signature Algorithm (EdDSA) as new authentication =
mechanisms.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/
>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-09
>>=20
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-09
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Mon Oct 31 06:46:35 2016
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 7323C1296B2 for ; Mon, 31 Oct 2016 06:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 FDhOrnyxqlIQ for ; Mon, 31 Oct 2016 06:46:31 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A541294B1 for ; Mon, 31 Oct 2016 06:46:31 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id o68so162343772qkf.3 for ; Mon, 31 Oct 2016 06:46:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zP0p7ikYDT9Vq72fVOP/MsM3SF5CCLuqzKHJ535MHjA=; b=DZhqJ5v8u0FfVBXN7U8ulIOmoKsXzGYpawpezQNB42OYGE02PgppmD62azmdj9BpmQ i9bxg76t86YzKozBgxkofd+EKVrsVeNBomogdma82+M4P9FObQhnrmv5hpjlbU0WFo13 6vYUaNW1x+Br1MeT+Dw+5XmijNb+3SBHxJoEQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zP0p7ikYDT9Vq72fVOP/MsM3SF5CCLuqzKHJ535MHjA=; b=afA3Z6+qHhcQiI90TZJ8e1s4lUgmIo4M+t0zuEgIMsnq6hFtPUI4E6hqYdzT/xl8kc b29QFtfzEx2Nl19Re1O1+LF4oPu8VzqxkScciiy8YfLCyQBtT1q5er4ioh2crxPWsd+g al/ZwTnSj9tIXJQEzllrau4/7L7LL3qvjF8ohrF+d0LVMjM9bBAvkb42ZIDfepCMnvDd tJ+b9aUD2ajvqGMrXn1GpDkF/FdX8rUFTDeKVkz9ZuqfkdHYyXrls8xLgiEwVvUK21bd wNmxd+EyHpoA+/0xfVumUi05daA7GJty1BW6nE6GWnT61fft/4OcPffoa7GGfEiukPDO +auw==
X-Gm-Message-State: ABUngvdx/Ce/CdTrLG67Dvh4V2xHRYFHBeiC/tBnBckrkMD8/KgPsuydTQLwC4YcVdgtPQ==
X-Received: by 10.55.148.131 with SMTP id w125mr23150876qkd.57.1477921590807;  Mon, 31 Oct 2016 06:46:30 -0700 (PDT)
Received: from [172.16.0.92] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id n77sm13284121qkn.28.2016.10.31.06.46.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Oct 2016 06:46:29 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: <74dbd140dc9046d4b1f99269a674bbee@usma1ex-dag1mb1.msg.corp.akamai.com>
Date: Mon, 31 Oct 2016 09:46:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <74dbd140dc9046d4b1f99269a674bbee@usma1ex-dag1mb1.msg.corp.akamai.com>
To: Rich Salz 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
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: Mon, 31 Oct 2016 13:46:33 -0000

The concern here is that people won=E2=80=99t review it until the end =
and that is definitely not what we want.  I=E2=80=99d really like get =
the most out of our f2f meeting in Seoul so pretty please people review =
it before Seoul.

spt

> On Oct 27, 2016, at 07:07, Salz, Rich  wrote:
>=20
> So isn't it really a WGLC that runs until end of January 2017?
>=20
> -- =20
> Senior Architect, Akamai Technologies
> Member, OpenSSL Dev Team
> IM: richsalz@jabber.at Twitter: RichSalz
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Mon Oct 31 07:00:14 2016
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 B50411295A8 for ; Mon, 31 Oct 2016 07:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 dkQhPTt_P8uz for ; Mon, 31 Oct 2016 07:00:10 -0700 (PDT)
Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (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 4E50712957D for ; Mon, 31 Oct 2016 07:00:10 -0700 (PDT)
Received: from vsmta11.fe.internet.bosch.com (unknown [10.4.98.51]) by imta23.fe.bosch.de (Postfix) with ESMTP id 2DA671580214 for ; Mon, 31 Oct 2016 15:00:08 +0100 (CET)
Received: from IMBVW2EXC00.bosch-si.com (vsgw22.fe.internet.bosch.com [10.4.98.11]) by vsmta11.fe.internet.bosch.com (Postfix) with ESMTP id AA4C52380B3C for ; Mon, 31 Oct 2016 15:00:07 +0100 (CET)
Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by IMBVW2EXC00 ([10.55.1.51]) with mapi id 14.03.0319.002; Mon, 31 Oct 2016 15:00:36 +0100
From: "Kraus Achim (INST/ESY1)" 
To: "tls@ietf.org" 
Thread-Topic: draft-fossati-tls-iot-optimizations-00, 4.2, hash chain
Thread-Index: AdIzfyQac8NCX80aRqKr1I0Ot73Xdg==
Date: Mon, 31 Oct 2016 14:00:34 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.144.45]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22670.006
X-TMASE-MatchedRID: rRVXzim0CnrC/uSBpQr0lrThj82FPFSC6XgeomAFiRwcQXgzaVXEcnLA QqCJeWM9tIiQ8jiM3T3IFr6H5/HEpiYw947zyArgsyNb+yeIRAqfll4kkeCNba+WgCcaviqGyl3 4Qjxod9W7vD2NKQ+RHMUqW9NkGq/HePs/Cx1DJd1mVHNo7XGknS4tncCojEfcsoddizCZ8tWzMh qIZZH9F6qifjszwIdDqNhuFB/lXK9XKXIMqa7kQtD3C6F7IetUQZXZg2I8JabZxX/W2g+Ev67xW EOiLago/nE2I3N9Ii0vN0bLeC1Afpja5QCEBu6/ngIgpj8eDcCEYGTT/umyEsRB0bsfrpPIcSqb xBgG0w6+8wA2LMF0OZK8pp4Oq944R7FXjYA1rXJS0txVuPtQXQtjCsSsG3vOyMbDtjYtkzL5Luk vluyPAb/TcyWTBwHSM5I5S2mEFBjeloC7shIVXg6WpWKKS2rRYyaijWogO/1SB/rCybjKWQ==
Archived-At: 
Subject: [TLS] draft-fossati-tls-iot-optimizations-00, 4.2, hash chain
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: Mon, 31 Oct 2016 14:00:12 -0000

Dear Authors,

draft-fossati-tls-iot-optimizations-00 mentions in 4.2, page 5, a hash chai=
n (Lampert, "Password Authentication with Insecure Communication").=20

Would it be possible, to get more details about that approach?

In my opinion, DTLS needs a connection id, the record is usually secured by=
 the MAC.=20
So the hash chain providing a "password" seems for me to rely on a "identit=
y", for which the "password" should be verified.=20
But that identity is missing and the verification is done with the MAC.

Use this in reverse, I could think of something as:

connection hash :=3D H ^ record.sequence_number (connection id)
   =20
So with an incoming record {sequence_number, connection hash} you may look =
up, if "connection ids" hashed
"sequence_number" times results in the provided "connection hash" and then =
you may verify, if one of the
candidates will verify with the MAC.  Even with defining a "sequence number=
 window" to exclude "faraway"
sessions, I'm not sure,  how such an approach would scale for a large numbe=
r of session.

So could you please provide your ideas about that hash chain?

Mit freundlichen Gr=FC=DFen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Stra=DFe 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com=20

Tel. +49 711 811-58139
achim.kraus@bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB =
148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn



From nobody Mon Oct 31 07:34:46 2016
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 8995B1295F6 for ; Mon, 31 Oct 2016 07:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ia78pPL--xSa for ; Mon, 31 Oct 2016 07:34:44 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0A0129501 for ; Mon, 31 Oct 2016 07:34:42 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id f134so99550003lfg.2 for ; Mon, 31 Oct 2016 07:34:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xloZWARrIEZ7jckERV85hbXlyDOUZ5EAPD+5vHg+bdA=; b=d3sFbYOinzdSQV7R0NLK2zB8LJsVV7Jsyz8EdVdn3AYvfI5Wj7SPQWgqHI0UnVji2W RsfJngs88BIsnL1xSPLfaOjM+CghZgpaaQTG8IuCGy0hU1TvTRlHzvWWPCYKN3xH7kp7 Aal0ZCvBTqxXV7E34JzB+soEvjO5NTfzPdF7UOMjj/hGIx/elL1fCjeV6ptzDCdknIlC YSU21nFVLgdaCTTJ5ENGf3hW61DtEbzxdltJdQ1fT0fiyl7HuoJAH5u/lwEExZ2ErZG8 HZRZGme1A/Byt2rQ1plj9HkZ9aZSRMhEVUI7GprSwAzv/mfGOjcE/W6ll4dxVOiL6uj1 gBfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xloZWARrIEZ7jckERV85hbXlyDOUZ5EAPD+5vHg+bdA=; b=Cg2Jodz82er4yQDpKG2mWUVWvzKpKEJ0sqwqxY8TXLYVqE4LkHsgAJtNwHEmMEni8t M7Wdm/XD89xB+/bRCfsVgz50TdFvi5riF+aMXGl1b0Ti64i1AMpFO5qpJh7+kQ7upr03 dyTdbV9ttir/HzPPSNdzoa37+jKuClEhOuN68+qDBos7BC8BoigpL5U2944sKu+FGB0T mzcL+K008u5e1Q/eqp1y+nU8x2nG6OtbWCfBaAbmgFLXd7Z8iHBkh4nXpVA69ogDRd3+ 1iX8ow36DwM/CghuKGXikLT80QyBIuWXajbFOcFYGwWHg8NcUP4BKf4+mpjwPRiFXOD0 no7Q==
X-Gm-Message-State: ABUngvcigHxE9vdXfVGRbSBSJZ4t21dwr7LqrlcvomIULWan5NIVCkSk4EEMhpjrtW2KfZ4x/oY27XmMNoOeXA==
X-Received: by 10.194.172.100 with SMTP id bb4mr5391759wjc.53.1477924480587; Mon, 31 Oct 2016 07:34:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Mon, 31 Oct 2016 07:34:39 -0700 (PDT)
In-Reply-To: 
References: <147771337150.24947.13319458137662655584.idtracker@ietfa.amsl.com> 
From: Kazuho Oku 
Date: Mon, 31 Oct 2016 23:34:39 +0900
Message-ID: 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-00.txt
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: Mon, 31 Oct 2016 14:34:45 -0000

Hi,

Thank you for the draft.

As said, I would love to have this kind of document.

In TLS 1.3, multiples steps are required to derive the AEAD secrets.
Without a step-by-step example, implementors need to (i.e. I had to)
struggle to figure out what went wrong.

I also believe that the document should be put up at some location
where people trying to implement TLS 1.3 can find easily. And as a
novice myself, RFCs would be where I would search first.

2016-10-29 13:09 GMT+09:00 Martin Thomson :
> A lot of people have asked for test vectors for TLS 1.3.  This draft
> includes two very simple handshakes: a 1-RTT handshake and a 0-RTT
> handshake resumed from the first.
>
> The baling-wire and string holding this together are here:
>   https://github.com/martinthomson/tls13-vectors
>
> Requests for scenarios to trace are welcome.  The vectors are
> automatically generated using the NSS test suite, so I'm very happy to
> write new tests and include the traces from those tests.
>
> Since NSS only supports draft -16, these aren't up to date with the
> latest draft.  We're working on an update and I hope to be able to
> provide an version that is updated to -18 before we meet.
>
> I would like to talk about whether this is worthwhile publishing.  In
> Seoul if we can't decide before then.
>
> ---------- Forwarded message ----------
> From:  
> Date: 29 October 2016 at 14:56
> Subject: New Version Notification for draft-thomson-tls-tls13-vectors-00.txt
> To: Martin Thomson 
>
> A new version of I-D, draft-thomson-tls-tls13-vectors-00.txt
> has been successfully submitted by Martin Thomson and posted to the
> IETF repository.
>
> Name:           draft-thomson-tls-tls13-vectors
> Revision:       00
> Title:          Example Handshake Traces for TLS 1.3
> Document date:  2016-10-28
> Group:          Individual Submission
> Pages:          26
> URL:
> https://www.ietf.org/internet-drafts/draft-thomson-tls-tls13-vectors-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/
> Htmlized:       https://tools.ietf.org/html/draft-thomson-tls-tls13-vectors-00
>
>
> Abstract:
>    Examples of TLS 1.3 handshakes are shown.  Private keys and inputs
>    are provided so that these handshakes might be reproduced.
>    Intermediate values, including secrets, traffic keys and ivs are
>    shown so that implementations might be checked incrementally against
>    these values.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Kazuho Oku


From nobody Mon Oct 31 11:42:00 2016
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 F27F31299E3 for ; Mon, 31 Oct 2016 11:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZUHmbVSi4bL5 for ; Mon, 31 Oct 2016 11:41:57 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1811299FD for ; Mon, 31 Oct 2016 11:41:48 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id x186so53252056vkd.1 for ; Mon, 31 Oct 2016 11:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=P4VIfyhXnSNWmW3ioTDEnQ82TQvBjqZERDQ5VhrNDFs=; b=OQof5MAqMn8imDOGWbRAkY/ehhTY6dNN9H697sS17ZCFcHQGB1q78JCaWT0CfqcV6Y zuxc1HqIMBqDia5008yAqNHg3KyFVCywSOdCSIV50oibXwvfaEQUYTq6uHjXbvNzmebU iY+XrPW/7FvWSZy1LktWUzc2IoofWsS3pNvvYtIetdFScOqMy6uzcQ6BVk05hWoAUqiC rjHHWg0JhxLdYGVxmxw5waadVmi+/v3MyFEbJKN25HtDv3Efxq5nAcKnBadoxzj5h3yh pBqhTh7tPvRdfigHzFs6rKlLwWq8a86uhKo0amocYm7RaUCZQi72sITGWmK9OlGSh6hQ Epcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=P4VIfyhXnSNWmW3ioTDEnQ82TQvBjqZERDQ5VhrNDFs=; b=aagShxEtfIukWw0r/sgBjfxx4tYQe1YHZ8dPtMbFSrIO3JUOIG6cJLRjaMJxsA57Cx OM4P6rtOtlXFLg/nGjpWtRTfwnetmSuJF7ChVsFRzOf3s7DX2rlmRZH7Tk3dVv+Uyqtu 0KaVOE6ctH6pEvjpcDQDQieYpBs9vQ6cNOu9GQOWx6jljIyUKCCeFBppTTLeuwIxKlwo /AoVmcEVvrqdUbRIQUVyNI6eA5ujkiuOn9zvKY69y86vfxfY6tLAGIZObMOR1fAEhwvs EPeNEDGgfqPo9lhhrPJ4drUWtmDD1FzkrHF7raPQPPbNpkF/4C9yJC6PwJN4k/6nGpuE U28A==
X-Gm-Message-State: ABUngveJUFlsEfUIgmzDRestFMMZ6YeiJJfaLL1nrCW9L33nGRtIm59LkGsRPhi1d5TWeCt9kz+vbxiP5XJO0Q==
X-Received: by 10.31.151.13 with SMTP id z13mr6381999vkd.41.1477939307382; Mon, 31 Oct 2016 11:41:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.68.135 with HTTP; Mon, 31 Oct 2016 11:41:46 -0700 (PDT)
From: Watson Ladd 
Date: Mon, 31 Oct 2016 11:41:46 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] Comments on draft-ietf-tls-tls13-18
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: Mon, 31 Oct 2016 18:41:59 -0000

Hello,

Looking at the history of TLS implementation attacks we see that many
result from the standard not strictly enough prescribing behavior,
particularly of the state machine. This draft does not actually fix
this problem, but continues to present example flows without
explicitly requiring them to be the only possible flows.

For example, consider HelloRetryRequest. Do servers only send one of
these per connection, or can it be resent multiple times? Obviously
there is a DoS possibility here, but I do not see where this behavior
is explicitly defined. I think we should require that the server only
ever sends one HelloRetryRequest, and then terminates the connection
if the ClientHello is unacceptable. At no point is it stated that only
the example flows should be supported. I would prefer more clarity
about what messages are to be expected when, especially with alerts.

ECDSA cannot be used with x25519 or x448, but the draft seems to
require support in TLS 1.2 for this as a consequence of its
description of the fallback mode. The mandated use of uncompressed
points invites easy wrong-curve attacks: mandating support and use for
compressed points would solve this problem. I think at minimum we
should fix the text to make clear what we mean about TLS 1.2.

ALPN, resumption, and 0-RTT remain problematic. For instance we see
that 0-RTT data is sent with the same ALPN state when the PSK was
derived, but this could be different from the ALPN transmitted and
negotiated during the handshake, which is explicitly allowed later in
the document. I do not understand what is supposed to happen in this
scenario.

Appendix B removes the text about upper-layer protocol interactions
with 0-RTT I provided, merely discussing the API. I think this is a
mistake: how 0-RTT should be used safely depends on the upper-layer
protocol, and can be complex. API guidance is not enough.

There is still a note about needing a channel binding mechanism in the
text. I think this should be resolved soon so it can be analyzed,
probably built on top of the exporter mechanism. Either that, or we
consciously punt and remove the note and replace with something else.

As for process, I support the idea of having a last call on November
20th, and then completing the security analysis by January 20th (or
whatever date was decided). This will prevent a flurry of changes
potentially breaking things.

Sincerely,
Watson Ladd


From nobody Mon Oct 31 11:44:00 2016
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 92F41129A0E for ; Mon, 31 Oct 2016 11:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 ZT7CUOSrlvVT for ; Mon, 31 Oct 2016 11:43:57 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEA9129A0B for ; Mon, 31 Oct 2016 11:43:56 -0700 (PDT)
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 59804CCA for ; Mon, 31 Oct 2016 18:43:54 +0000 (GMT)
Received: by mail-qk0-f179.google.com with SMTP id z190so172388984qkc.2 for ; Mon, 31 Oct 2016 11:43:54 -0700 (PDT)
X-Gm-Message-State: ABUngvdfuLHlWmlcGpOSsBcCC7GHKMIqaZpE8fe3h/vE31YQV3yeoT2nRXKnFPCny6PQa0Ottp63ZYV8KYpihw==
X-Received: by 10.55.102.130 with SMTP id a124mr22338845qkc.292.1477939432787;  Mon, 31 Oct 2016 11:43:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.34.61 with HTTP; Mon, 31 Oct 2016 11:43:52 -0700 (PDT)
From: Matt Caswell 
Date: Mon, 31 Oct 2016 18:43:52 +0000
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [TLS] supported_versions question
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: Mon, 31 Oct 2016 18:43:58 -0000

A few supported_versions questions:

1) What should a server do if supported_versions is received but
ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
ignore legacy_version?

2) What should a server do if supported_versions is received,
ClientHello.legacy_version == TLS1.2, but supported_versions does not
contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
handshake, use the legacy_version, or use use the versions in
supported_versions?

3) If the answer to (2) above is ignore the legacy_version, and just
use the versions in supported_versions, which client_version should be
used in the RSA pre-master secret calculation? The one in
legacy_version, or the highest one in supported_versions? Presumably
it has to be the one in legacy_version, otherwise thing will fail when
the client talks to a server that doesn't understand
supported_versions?

Matt


From nobody Mon Oct 31 11:57:31 2016
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 BEDBD129A11 for ; Mon, 31 Oct 2016 11:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
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 IeeQgNYHlXP4 for ; Mon, 31 Oct 2016 11:57:28 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8675B129A0B for ; Mon, 31 Oct 2016 11:57:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 51B9B1308B; Mon, 31 Oct 2016 20:57:26 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id jNQjXwnk94wV; Mon, 31 Oct 2016 20:57:26 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id F123127F; Mon, 31 Oct 2016 20:57:25 +0200 (EET)
Date: Mon, 31 Oct 2016 20:57:24 +0200
From: Ilari Liusvaara 
To: Matt Caswell 
Message-ID: <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 18:57:31 -0000

On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
> A few supported_versions questions:
> 
> 1) What should a server do if supported_versions is received but
> ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> ignore legacy_version?

If legacy_version > TLS1.2, the spec requires server to ignore
legacy_version.

The case where legacy_version < TLS1.2 IIRC isn't specified, but
ignoring legacy_version is reasonable in this case too.

> 2) What should a server do if supported_versions is received,
> ClientHello.legacy_version == TLS1.2, but supported_versions does not
> contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> handshake, use the legacy_version, or use use the versions in
> supported_versions?

There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
the latter the server has never heard about...

> 3) If the answer to (2) above is ignore the legacy_version, and just
> use the versions in supported_versions, which client_version should be
> used in the RSA pre-master secret calculation? The one in
> legacy_version, or the highest one in supported_versions? Presumably
> it has to be the one in legacy_version, otherwise thing will fail when
> the client talks to a server that doesn't understand
> supported_versions?

Yeah, I presume putting the version in legacy_version is the only sane
thing to do. But causes other problems with downgrade protection.

OTOH, RSA key exchange is known to be very broken and is affected by
all kinds of downgrade (and other) attacks. So if one wants actual
security, it needs to be removed.



-Ilari


From nobody Mon Oct 31 12:11:31 2016
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 65D69129A3D for ; Mon, 31 Oct 2016 12:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 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_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Y-QIsV6b5mMc for ; Mon, 31 Oct 2016 12:11:27 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628C1129A4E for ; Mon, 31 Oct 2016 12:11:22 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id h14so153199051ywa.2 for ; Mon, 31 Oct 2016 12:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CKLX6T/NpbyoFFIyphKH1Gt8Jzc5IkoriuFDB7jF+w8=; b=S1/yeJ5LhvxgIHZ4Ye9accWQ5TijIGeKNqwJ9ciF+fgWJ4uUNHZQCfNnbOcTll/Z6e ikO69zooKdyjyYc2lTjlJdtRgacoz0W+m5J6pGJmNsQBB5DRuTqAGR4/jpFg44STFhKu 1+ai9Hwr7ogLgIrsZDkRxTHKC3gjwb0yjDJi6hSUxhH8llmSAJsRFXfIXVlZd2v+KGDS h/r9gOrgm4XD3PYbHGBkhFyqqdgZAw/kGuAHHAsWdMbC2ed3DuAOGG+Mf+tzpZ6l4IPO 8mNvGQnJFnRUmsUfty4urWzrG2bXKMDYO8IFpe+c6Q0In0lL4q1j2+D5PTVTe8/IkaWv yiJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKLX6T/NpbyoFFIyphKH1Gt8Jzc5IkoriuFDB7jF+w8=; b=C2FjHd09l2mUandmM8Xfle95QoSA/ym6i0IYcpSHlmak341PuFKTIoY5KZ6LQfp0Mq aC6QZo5RrCKnPFzo74bsGsXsBHMJO2EEHPaspI0XE2/4SkULxuO3FS2rUba44FdRDE3a zNdX9FuqO7uoDrtJ9tjXYTY7xEcPQ9uXpiBVkttLY2sP0oJ97Dd9/Py0R6tkqCcmvxwr 2mWCtKjgzXzmnCn7jPCEWzM5cEaExpxjIK7o5xl+GGkQTIC7DKEoZbndRdkRqbc/WXkA Tk1r2KnWQSlmeMsHyBQX8me8gQS5J3jIQna4bZee8Owt0+KFdB1Oso7i+wB1ZXrtuLxp G9yA==
X-Gm-Message-State: ABUngveqffOregm6OCUjMBqnaMmftalofXc7IWo9lkyD0B1HBVif6xL4/6uBp0Bg07WIhN9HPZ6U+Ce+d1zeBmJV
X-Received: by 10.36.105.5 with SMTP id e5mr9895399itc.75.1477941081490; Mon, 31 Oct 2016 12:11:21 -0700 (PDT)
MIME-Version: 1.0
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>
From: David Benjamin 
Date: Mon, 31 Oct 2016 19:11:10 +0000
Message-ID: 
To: Ilari Liusvaara , Matt Caswell 
Content-Type: multipart/alternative; boundary=001a11445d5e298b6805402df9e4
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 19:11:29 -0000

--001a11445d5e298b6805402df9e4
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara 
wrote:

> On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
> > A few supported_versions questions:
> >
> > 1) What should a server do if supported_versions is received but
> > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> > ignore legacy_version?
>
> If legacy_version > TLS1.2, the spec requires server to ignore
> legacy_version.
>
> The case where legacy_version < TLS1.2 IIRC isn't specified, but
> ignoring legacy_version is reasonable in this case too.
>
> > 2) What should a server do if supported_versions is received,
> > ClientHello.legacy_version == TLS1.2, but supported_versions does not
> > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> > handshake, use the legacy_version, or use use the versions in
> > supported_versions?
>
> There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
> the latter the server has never heard about...
>
> > 3) If the answer to (2) above is ignore the legacy_version, and just
> > use the versions in supported_versions, which client_version should be
> > used in the RSA pre-master secret calculation? The one in
> > legacy_version, or the highest one in supported_versions? Presumably
> > it has to be the one in legacy_version, otherwise thing will fail when
> > the client talks to a server that doesn't understand
> > supported_versions?
>
> Yeah, I presume putting the version in legacy_version is the only sane
> thing to do. But causes other problems with downgrade protection.
>
> OTOH, RSA key exchange is known to be very broken and is affected by
> all kinds of downgrade (and other) attacks. So if one wants actual
> security, it needs to be removed.
>

We could say the versions extension only applies to 1.2 and up. I.e. don't
bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
when they see them in the version list. That keeps the protocol deployable
on the Internet as it exists, avoids having to evaluate too versioning
schemes (if you see the extension, you don't bother reading legacy_version
at all), while avoiding the weird behavior where, given this ClientHello:

   legacy_version: TLS 1.2
   supported_versions: {TLS 1.1}

TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

David

--001a11445d5e298b6805402df9e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Mon, Oct 31=
, 2016 at 2:57 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:=


> A few supported_versions questions:

>

> 1) What should a server do if supported_versions is received but

> ClientHello.legacy_version !=3D TLS1.2? Fail the handshake, or just
> ignore legacy_version?



If legacy_version > TLS1.2, the spec requires server to ignore

legacy_version.



The case where legacy_version < TLS1.2 IIRC isn't specified, but

ignoring legacy_version is reasonable in this case too.



> 2) What should a server do if supported_versions is received,

> ClientHello.legacy_version =3D=3D TLS1.2, but supported_versions does =
not

> contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the<=
br class=3D"gmail_msg">
> handshake, use the legacy_version, or use use the versions in

> supported_versions?



There's also the case where supported_versions has TLS 1.1 and TLS 1.4,=


the latter the server has never heard about...



> 3) If the answer to (2) above is ignore the legacy_version, and just
> use the versions in supported_versions, which client_version should be=


> used in the RSA pre-master secret calculation? The one in

> legacy_version, or the highest one in supported_versions? Presumably
> it has to be the one in legacy_version, otherwise thing will fail when=


> the client talks to a server that doesn't understand

> supported_versions?



Yeah, I presume putting the version in legacy_version is the only sane

thing to do. But causes other problems with downgrade protection.



OTOH, RSA key exchange is known to be very broken and is affected by

all kinds of downgrade (and other) attacks. So if one wants actual

security, it needs to be removed.
=

We could say the versions extension only applies to 1.2 and =
up. I.e. don't bother advertising 1.1 and 1.0 as a client and servers i=
gnore 1.1 and 1.0 when they see them in the version list. That keeps the pr=
otocol deployable on the Internet as it exists, avoids having to evaluate t=
oo versioning schemes (if you see the extension, you don't bother readi=
ng legacy_version at all), while avoiding the weird behavior where, given t=
his ClientHello:

=C2=A0 =C2=A0legacy_version: TLS =
1.2
=C2=A0 =C2=A0supported_versions: {TLS 1.1}

TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS =
1.2.

David


--001a11445d5e298b6805402df9e4--


From nobody Mon Oct 31 12:28:21 2016
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 D11DA1299D2 for ; Mon, 31 Oct 2016 12:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
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 ekuTQ4-P2vL8 for ; Mon, 31 Oct 2016 12:28:16 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id A5CC5129421 for ; Mon, 31 Oct 2016 12:28:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id AC82BF3D2; Mon, 31 Oct 2016 21:28:15 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id j8ymt4GHtt8t; Mon, 31 Oct 2016 21:28:15 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 3F2562310; Mon, 31 Oct 2016 21:28:15 +0200 (EET)
Date: Mon, 31 Oct 2016 21:28:13 +0200
From: Ilari Liusvaara 
To: Watson Ladd 
Message-ID: <20161031192813.GB23357@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Comments on draft-ietf-tls-tls13-18
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: Mon, 31 Oct 2016 19:28:19 -0000

On Mon, Oct 31, 2016 at 11:41:46AM -0700, Watson Ladd wrote:

> ECDSA cannot be used with x25519 or x448, but the draft seems to
> require support in TLS 1.2 for this as a consequence of its
> description of the fallback mode. The mandated use of uncompressed
> points invites easy wrong-curve attacks: mandating support and use for
> compressed points would solve this problem. I think at minimum we
> should fix the text to make clear what we mean about TLS 1.2.

Just as note: Point compression does not completely fix wrong-curve
attacks.

The reason is that for Weierstrass curves and the usual square square
root algorithm, the "square roots" for QNRs, if the code does not check,
don't result points on the twist, but all sorts of strange points, on
variety of different curves.

(With one-coordinate Montgomery ladder on montgomery curves, the invalid
points all map to the twist, which is a single curve and can be arranged
to have a large prime factor in its order).

Oh, and thanks to different message order in TLS 1.3 compared to TLS
1.2, wrong-curve attacks look more exploitable.

 
> ALPN, resumption, and 0-RTT remain problematic. For instance we see
> that 0-RTT data is sent with the same ALPN state when the PSK was
> derived, but this could be different from the ALPN transmitted and
> negotiated during the handshake, which is explicitly allowed later in
> the document. I do not understand what is supposed to happen in this
> scenario.

Well, the spec prohibits accepting 0-RTT data if ALPN does not match,
but this looks bit error prone to me.

I proposed forcing the ALP to the previous value, and not allowing it
to be negotiated via any method. This would eliminate this sort of
edge case check.

> There is still a note about needing a channel binding mechanism in the
> text. I think this should be resolved soon so it can be analyzed,
> probably built on top of the exporter mechanism. Either that, or we
> consciously punt and remove the note and replace with something else.

I think this is a replacement for the tls-unique channel binding. While
the definition of tls-unique does still make sense for TLS 1.3, the
definition has security problems with TLS 1.2.

Thus, need for replacment.


-Ilari


From nobody Mon Oct 31 12:30:16 2016
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 C2ED5129A6D for ; Mon, 31 Oct 2016 12:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
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 ZG_AjzoTeCVN for ; Mon, 31 Oct 2016 12:30:13 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 599AE129421 for ; Mon, 31 Oct 2016 12:30:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 4D6911649B; Mon, 31 Oct 2016 21:30:12 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id vo0SK7B_uB8G; Mon, 31 Oct 2016 21:30:12 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 13A7B2310; Mon, 31 Oct 2016 21:30:12 +0200 (EET)
Date: Mon, 31 Oct 2016 21:30:10 +0200
From: Ilari Liusvaara 
To: David Benjamin 
Message-ID: <20161031193010.GC23357@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 19:30:15 -0000

On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
> 
> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate too versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
> 
>    legacy_version: TLS 1.2
>    supported_versions: {TLS 1.1}
> 
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

Yeah, I don't think it ever makes sense to stick TLS 1.0 or 1.1 into
supported_versions. There are good reasons to stick TLS 1.2 there tho.


-Ilari


From nobody Mon Oct 31 12:33:41 2016
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 CEF56129A72 for ; Mon, 31 Oct 2016 12:33:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.018
X-Spam-Level: 
X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 6NcepTEI2nUi for ; Mon, 31 Oct 2016 12:33:38 -0700 (PDT)
Received: from SNT004-OMC1S7.hotmail.com (snt004-omc1s7.hotmail.com [65.55.90.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70602129A6E for ; Mon, 31 Oct 2016 12:33:38 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com ([65.55.90.8]) by SNT004-OMC1S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 31 Oct 2016 12:33:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cc8feL2VvMfKdeweUjOYS5m9YgpIswFkX8RXz2deqf0=; b=gwLk9CgRIvKcay+OMwFCRg9JrgOJN7bjw/GvLty1+kanP3WUyFK2/o3c7vZMBm7eG8fTfgDUNJ9FMA3xYgoEPZ1o6VBHssN4+xaIuRJEQcPWL8wawJNXc2ibYu4XyfvTXW8UIf9gIWhucX1jybhu2L5sstjZAyvDHtB33MTwAhymP8pS2FHmkHNcC8tijfEIWTCfVJhNQzx2ZFp8JdXBKhAJyPzyHNtFVXNqJHxvJXp4S0K6NCFIYPLzrY4BclO2d1zE/QGGzLfaxrO+33UCVkM9hFgzjyjvGqQ65ug2vGcHpazaeQak6PS9xQ2FG2fRpOm5mIsKSYuLTL2mGOgW9w==
Received: from CO1NAM03FT039.eop-NAM03.prod.protection.outlook.com (10.152.80.54) by CO1NAM03HT039.eop-NAM03.prod.protection.outlook.com (10.152.81.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3; Mon, 31 Oct 2016 19:33:36 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.80.55) by CO1NAM03FT039.mail.protection.outlook.com (10.152.81.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3 via Frontend Transport; Mon, 31 Oct 2016 19:33:36 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0693.009; Mon, 31 Oct 2016 19:33:36 +0000
From: Xiaoyin Liu 
To: Matt Caswell , "tls@ietf.org" 
Thread-Topic: [TLS] supported_versions question
Thread-Index: AQHSM6bDgOZgYO0RjEy7XUtk3r8FIqDC9Amf
Date: Mon, 31 Oct 2016 19:33:36 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: baggins.org; dkim=none (message not signed) header.d=none;baggins.org; dmarc=none action=none header.from=outlook.com;
x-incomingtopheadermarker: OriginalChecksum:642C35EBD4B6C9945BD1DFC0CA204C1BED7A47D29AE174EF75BE33AA2803B09E; UpperCasedChecksum:ADC5B00839F510370A4F5EA44AB3C0E4EDD6A6AA3F0353FB61D71B7A99FF6D0F; SizeAsReceived:7238; Count:38
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [os6fgqHX5hm8WAu4yJXYtPbhwAwdhRq9]
x-incomingheadercount: 38
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; CO1NAM03HT039; 5:v/j1hSdgp+7grOZJsWkisM1A7M2CRIdrTucd4W3A7iUlXyNNkVgNJOOABJWAKBwYNxtbhxSEvRLgnrrXH1oVQu0pKzjlOzcbnuCsfvT94pkBVXhHL8WM4TByqkqLP5f/T4rob7VqdM/f7j+/c+XvGsH7e+A2tSJJXVoz+b6KJzE=; 24:VzrODfOeHg3Xnh3N0VSU/SaZqEBe91PAnAVN96Mxbg8X075bGE70SFj0s4b4b4/xZdwzcCQm6F6q3hfYDRbdzRtekjD/klGOpE2k+i5ZGEQ=; 7:3Ycpoa9Z4V5+A7tFJputLc6mdG3an1mgJKXnKO5gTa2wySxBjLPRHFEe7dKp9M3AizIXK51Rfu9BNXgeJBBFQQG9E9NPpPaczvMhgxdwKAzcGhbxH6JDuD24OTECE58/6wmAGsQ2tdD38f0mNeXXnFtVci0XCiyhBItAf/JJwrbR/TkfLfOvrJEZ7MnsrQx9fSAmpWHlL1L+OGd6/AH7jCA5JKYbptOe1Znk4GnLyDVxzTBiItc+W7WxlwicZFB41s3LAuzPgsM3DsCxJoERXlHJiJA6yq6uVIpCwgMvENkFX8W0bLwyH6sozWOlRQgriRS5/G4HX+3pakWamW+slgXIpE7yqStLZ8fV+4HKnyI=
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM03HT039; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; 
x-ms-office365-filtering-correlation-id: e35263df-0db3-47ce-f47a-08d401c4cefb
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1603101340)(1601125047); SRVR:CO1NAM03HT039; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CO1NAM03HT039; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM03HT039; 
x-forefront-prvs: 01128BA907
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR15MB07782F602D8E69B7191004FAFFAE0CY1PR15MB0778namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2016 19:33:36.2807 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT039
X-OriginalArrivalTime: 31 Oct 2016 19:33:37.0858 (UTC) FILETIME=[AD64AA20:01D233AD]
Archived-At: 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 19:33:40 -0000

--_000_CY1PR15MB07782F602D8E69B7191004FAFFAE0CY1PR15MB0778namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think for question 1, it should ignore legacy_version, and select a versi=
on from supported_versions, because if a client only supports TLS 1.1 and T=
LS 1.3, in order to connect to pre-TLS1.3 server, it has to set legacy_vers=
ion to TLS 1.1.



I have no idea about questions 2 or 3.



Best,

Xiaoyin



From: Matt Caswell
Sent: Monday, October 31, 2016 2:44 PM
To: tls@ietf.org
Subject: [TLS] supported_versions question



A few supported_versions questions:

1) What should a server do if supported_versions is received but
ClientHello.legacy_version !=3D TLS1.2? Fail the handshake, or just
ignore legacy_version?

2) What should a server do if supported_versions is received,
ClientHello.legacy_version =3D=3D TLS1.2, but supported_versions does not
contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
handshake, use the legacy_version, or use use the versions in
supported_versions?

3) If the answer to (2) above is ignore the legacy_version, and just
use the versions in supported_versions, which client_version should be
used in the RSA pre-master secret calculation? The one in
legacy_version, or the highest one in supported_versions? Presumably
it has to be the one in legacy_version, otherwise thing will fail when
the client talks to a server that doesn't understand
supported_versions?

Matt

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

--_000_CY1PR15MB07782F602D8E69B7191004FAFFAE0CY1PR15MB0778namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable















I think for question 1, it should ignore legacy_ve=
rsion, and select a version from supported_versions, because if a client on=
ly supports TLS 1.1 and TLS 1.3, in order to connect to pre-TLS1.3 server, =
it has to set legacy_version to TLS
 1.1.


 


I have no idea about questions 2 or 3.


 


Best,


Xiaoyin


 




From: Matt Caswell

Sent: Monday, October 31, 2016 2:44 PM

To: tls@ietf.org

Subject: [TLS] supported_versions question




 







A few supported_versions questions:



1) What should a server do if supported_versions is received but

ClientHello.legacy_version !=3D TLS1.2? Fail the handshake, or just

ignore legacy_version?



2) What should a server do if supported_versions is received,

ClientHello.legacy_version =3D=3D TLS1.2, but supported_versions does not
contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the

handshake, use the legacy_version, or use use the versions in

supported_versions?



3) If the answer to (2) above is ignore the legacy_version, and just

use the versions in supported_versions, which client_version should be

used in the RSA pre-master secret calculation? The one in

legacy_version, or the highest one in supported_versions? Presumably

it has to be the one in legacy_version, otherwise thing will fail when

the client talks to a server that doesn't understand

supported_versions?



Matt



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/=
mailman/listinfo/tls







--_000_CY1PR15MB07782F602D8E69B7191004FAFFAE0CY1PR15MB0778namp_--


From nobody Mon Oct 31 13:16:35 2016
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 8A91B129AEF for ; Mon, 31 Oct 2016 13:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 2raFy9uAiy6p for ; Mon, 31 Oct 2016 13:16:33 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EC5129AF4 for ; Mon, 31 Oct 2016 13:16:32 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id l124so15450307ywb.3 for ; Mon, 31 Oct 2016 13:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RGaLkhYrVCuiqkADPOVQKZPKfxH1VXO2/DpJlcFVEog=; b=QVpgliW5fFuLhRUylPe1EOUTHKyoKu6cVdkLvuGdVLjOUU5WkctM0VK5jCY3ToQRzk qyff02LCmxubbnWE9hPtTCLMzE1gWeRnJ1QbXy9mX1ETNUczat2dtSs6rUiNhf3kuj1C VGrakZgcBr4mq6dg7qFJe0qfSP1nD+H5AQjHZNHE0TaLx7a4MK1jW5NQ8/Ud2yP3WCw6 aQn3NY5cxSeBQw41AFyJEz6txyXm4doaHsVMT2YWpKw61VAesue4bohN6RrV+9ywixlu XqZzhhxSgrfgX2yS1xFbUHarsGcHPgrvhZ9Ik1pDv3gtYyTZ/Uc5mLsue1fAew2fut19 jATQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RGaLkhYrVCuiqkADPOVQKZPKfxH1VXO2/DpJlcFVEog=; b=GSEEs0JGRDqTFQVZkoyvlgR1WKaaaAjEJQsdoeFzPu/3ZsJSRzH+7llq7eBVxjVhi0 XgXc0O0r1QSylrWrY8zp9PXoFinjjjp/aG9Utq02tuhQ+WfWD9yNTHU7Jm1gqlG+BMSB XR9RD9VQrqTcvI+jdWGh+uD+So6Afm5w3IcT9tx5edWnDoci3TfKVaGNGJx9W4kh5gHD iPLPMmHHmCXq8VQSTPKjD4Ui2W5RkU1wk1kr8hE9JcUXOg9fACgWjje5ukRyXSyPJUHq yhR++AAQ7ia6nAaF/Q8uZuxTITma8WL/NLwuKSGaP1OyIaXBPGkCG8JuEBRirVL5LtWK I1TQ==
X-Gm-Message-State: ABUngvfE/X2VpqH0vambUtg0meyMiGZkILDclnsr1DHGRuurUDNAqMlA2E9ll8Fl80eqD986gpykrd+ErkWOpw==
X-Received: by 10.36.118.203 with SMTP id z194mr9440036itb.87.1477944991906; Mon, 31 Oct 2016 13:16:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.85.83 with HTTP; Mon, 31 Oct 2016 13:16:31 -0700 (PDT)
In-Reply-To: 
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi> 
From: Brian Smith 
Date: Mon, 31 Oct 2016 10:16:31 -1000
Message-ID: 
To: David Benjamin 
Content-Type: multipart/alternative; boundary=001a114410f63d99b805402ee252
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 20:16:34 -0000

--001a114410f63d99b805402ee252
Content-Type: text/plain; charset=UTF-8

David Benjamin  wrote:

> Ilari Liusvaara  wrote:
>
>> The case where legacy_version < TLS1.2 IIRC isn't specified, but
>> ignoring legacy_version is reasonable in this case too.
>>
>
I imagine that there will be three common implementations for the case
where legacy_version < 1.2 and supported_versions is present:

1. The server ignores supported_versions. (Note that all TLS 1.0 and TLS
1.1 implementations will do this.)
2. The server ignores legacy_version and only looks at supported_versions.
3. The server drops the connection (maybe with an alert) because clients
shouldn't be doing that in the first place.


> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate [two] versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
>
>    legacy_version: TLS 1.2
>    supported_versions: {TLS 1.1}
>
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
>

David's suggestion here is reasonable and good. It definitely would be
surprising and unwanted to allow supported_versions to negotiate anything
less than TLS 1.2, especially when legacy_version is TLS 1.2.

Cheers,
Brian
-- 
https://briansmith.org/

--001a114410f63d99b805402ee252
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Davi=
d Benjamin <davidben@google.com> wrote:
Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
=

The case where legacy_version < TLS=
1.2 IIRC isn't specified, but

ignoring legacy_version is reasonable in this case too.
=


I imagine that there will be three common implementatio=
ns for the case where legacy_version < 1.2 and supported_versions is pre=
sent:

1. The server ignores supported_versions. (N=
ote that all TLS 1.0 and TLS 1.1 implementations will do this.)
2=
. The server ignores legacy_version and only looks at supported_versions.
3. The server drops the connection (maybe with an alert) because c=
lients shouldn't be doing that in the first place.
=C2=A0
We could say the versions extension only applies to 1.2 and up. I.e.=
 don't bother advertising 1.1 and 1.0 as a client and servers ignore 1.=
1 and 1.0 when they see them in the version list. That keeps the protocol d=
eployable on the Internet as it exists, avoids having to evaluate [two] ver=
sioning schemes (if you see the extension, you don't bother reading leg=
acy_version at all), while avoiding the weird behavior where, given this Cl=
ientHello:

=C2=A0 =C2=A0legacy_version: TLS 1.2
=C2=A0 =C2=A0supported_versions: {TLS 1.1}

TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

David's suggestion her=
e is reasonable and good. It definitely would be surprising and unwanted to=
 allow supported_versions to negotiate anything less than TLS 1.2, especial=
ly when legacy_version is TLS 1.2.

Cheers,
Brian
-- 




--001a114410f63d99b805402ee252--


From nobody Mon Oct 31 14:29:01 2016
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 1CD54129B12 for ; Mon, 31 Oct 2016 14:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 ou0zsXqxlAV9 for ; Mon, 31 Oct 2016 14:28:56 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4CD129B3B for ; Mon, 31 Oct 2016 14:28:42 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id d128so67372267ybh.2 for ; Mon, 31 Oct 2016 14:28:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wWlkJdcaessA94k/aX49d2xGpB4auDEm76pES4FJqf4=; b=M+JWvet4EV2hyOkAVghYeu4hEIzmc1ojRJatUO8gnJdTGHwMIJQx2qcC/69rrKpnu/ LkNCWTbIApp/QXHxasaihYY80zs+p/vWHbiOhXG7gvOS6I1kp9p6T6v2dBxdPoSh65dB sSFwDsuoaQlTEZwmweV5V9suuu1DcYn8ThJNa0dUpiia4XF2YsXwFKSLoQAz+aUWidUW Lx4B1qRqlXt9LlFkZCTsg2bfl0cdrcEIGDN+wQ/8GuyUI1v/U/3XN4aXDpBYfAHJ2/6q pm5zBWF3eQTbnej/imdBqvdkpZP4pX/uVx7fyZVCDHC9dmGIYEzyGAirAemnQ0tXKIcS JFvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wWlkJdcaessA94k/aX49d2xGpB4auDEm76pES4FJqf4=; b=nBLtNFlKVCmN+5h44crrZNt+3gOIhYVYJPFTECLjhqmptbG4fpnX6I0M2UKSrvJEdM otSroGE37tv9c+U5FaEmgNzjLhLBeqos0rSLp5p43oOjKywRkjIiQCBkSDRsfo7jwe9o T65xLwQiOaua0otoVnAxWzGao7k0kGXXcxtCS532qDQEfpVH/eBEw/TstIP1sHWyS2P4 GxZC4OgmJaMx7J4hTLB+kOGG+JKcXk7Kt444zIDv/MOWZkK3N91JtODl07Jyu4VmcCqI YAkti7FUNn5petuw2V96geR+a1DbRaKa+rl031X35CDPPzvX0Y/NvWuh6sExUlyss0Wi bKtA==
X-Gm-Message-State: ABUngvdArgKYRUWnhx+5N3jFYT/XiYjODmLYNupp+7mMQb6W/pZVgvWFLyYKZu6WA6TcE6UTgViRPBe1cAyPDQ==
X-Received: by 10.37.204.73 with SMTP id l70mr27482405ybf.161.1477949321496; Mon, 31 Oct 2016 14:28:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.159.141 with HTTP; Mon, 31 Oct 2016 14:28:00 -0700 (PDT)
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Mon, 31 Oct 2016 14:28:00 -0700
Message-ID: 
To: Watson Ladd 
Content-Type: multipart/alternative; boundary=94eb2c07f3024dfd6105402fe437
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Comments on draft-ietf-tls-tls13-18
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: Mon, 31 Oct 2016 21:28:59 -0000

--94eb2c07f3024dfd6105402fe437
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Watson,

Thanks for your comments!

On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd  wrote=
:

> Hello,
>
> Looking at the history of TLS implementation attacks we see that many
> result from the standard not strictly enough prescribing behavior,
> particularly of the state machine. This draft does not actually fix
> this problem, but continues to present example flows without
> explicitly requiring them to be the only possible flows.
>


For example, consider HelloRetryRequest. Do servers only send one of
> these per connection, or can it be resent multiple times? Obviously
> there is a DoS possibility here, but I do not see where this behavior
> is explicitly defined. I think we should require that the server only
> ever sends one HelloRetryRequest, and then terminates the connection
> if the ClientHello is unacceptable.



The server is forbidden to send multiple HRRs and the client is required
to enforce it. See:

  https://tlswg.github.io/tls13-spec/#hello-retry-request

I agree that we don't require the server to behave this way. I can fix the
draft to say this.


At no point is it stated that only
> the example flows should be supported. I would prefer more clarity
> about what messages are to be expected when, especially with alerts.
>

Actually the text does say something here:
https://tlswg.github.io/tls13-spec/#handshake-protocol

"Protocol messages MUST be sent in the order defined below (and shown in
the diagrams in Section 2
). A peer which
receives a handshake message in an unexpected order MUST abort the
handshake with an =E2=80=9Cunexpected_message=E2=80=9D alert. Unneeded hand=
shake messages
are omitted, however."

However, this text was also in 5246, so I think there's a fair argument
that it's not strong enough. I'm not quite sure how to make it better.
Suggestions?


ECDSA cannot be used with x25519 or x448, but the draft seems to
> require support in TLS 1.2 for this as a consequence of its
> description of the fallback mode.


I don't *think* that that's true: can you point to the specific text that
you are concerned with?


ALPN, resumption, and 0-RTT remain problematic. For instance we see
> that 0-RTT data is sent with the same ALPN state when the PSK was
> derived, but this could be different from the ALPN transmitted and
> negotiated during the handshake, which is explicitly allowed later in
> the document. I do not understand what is supposed to happen in this
> scenario.
>

Here's the relevant text:
https://tlswg.github.io/tls13-spec/#early-data-indication

"If any of these checks fail [ALPN is in the list above] the server MUST
NOT respond with the extension and must discard all the remaining first
flight data (thus falling back to 1-RTT). If the client attempts a 0-RTT
handshake but the server rejects it, it will generally not have the 0-RTT
record protection keys and must instead trial decrypt each record with the
1-RTT handshake keys until it finds one that decrypts properly, and then
pick up the handshake from that point."

Is there anything else you'd like to see here?

Appendix B removes the text about upper-layer protocol interactions
> with 0-RTT I provided, merely discussing the API. I think this is a
> mistake: how 0-RTT should be used safely depends on the upper-layer
> protocol, and can be complex. API guidance is not enough.
>

This ended up in the main text:
https://tlswg.github.io/tls13-spec/#zero-rtt-data

"Protocols MUST NOT use 0-RTT data without a profile that defines its use.
That profile needs to identify which messages or interactions are safe to
use with 0-RTT. In addition, to avoid accidental misuse, implementations
SHOULD NOT enable 0-RTT unless specifically requested. Special functions
for 0-RTT data are RECOMMENDED to ensure that an application is always
aware that it is sending or receiving data that might be replayed."

Is this missing pieces you think we need?


There is still a note about needing a channel binding mechanism in the
> text. I think this should be resolved soon so it can be analyzed,
> probably built on top of the exporter mechanism. Either that, or we
> consciously punt and remove the note and replace with something else.
>

The idea here is that we need a separate draft that just says "use
exporters with
label X". I think we remove the note and see if we can get someone to write
that draft.


As for process, I support the idea of having a last call on November
> 20th, and then completing the security analysis by January 20th (or
> whatever date was decided). This will prevent a flurry of changes
> potentially breaking things.
>

That's the idea.

-Ekr


> Sincerely,
> Watson Ladd
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c07f3024dfd6105402fe437
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Watson,

Thanks for your comments!

On Mon, Oct 31, 201=
6 at 11:41 AM, Watson Ladd <watsonbladd@gmail.com> wrote=
:
Hello,



Looking at the history of TLS implementation attacks we see that many

result from the standard not strictly enough prescribing behavior,

particularly of the state machine. This draft does not actually fix

this problem, but continues to present example flows without

explicitly requiring them to be the only possible flows.



For example, consider HelloRetryRequest. Do servers only send one of

these per connection, or can it be resent multiple times? Obviously

there is a DoS possibility here, but I do not see where this behavior

is explicitly defined. I think we should require that the server only

ever sends one HelloRetryRequest, and then terminates the connection

if the ClientHello is unacceptable. 


The server is=
 forbidden to send multiple HRRs and the client is required
to en=
force it. See:


I agree that we don't require the server to behave this way. I=
 can fix the
draft to say this.


At no point is it state=
d that only

the example flows should be supported. I would prefer more clarity

about what messages are to be expected when, especially with alerts.

Actually the text does say something here:

"Protocol m=
essages MUST be sent in the order defined below (and shown in the diagrams =
in=C2=A0Section=
 2). A peer which receives a handshake messa=
ge in an unexpected order MUST abort the handshake with an =E2=80=9Cunexpec=
ted_message=E2=80=9D alert. Unneeded handshake messages are omitted, howeve=
r."

However, this text was also in 524=
6, so I think there's a fair argument
that it's not stron=
g enough. I'm not quite sure how to make it better.
Suggestio=
ns?



ECDSA cannot be used with x25519 or x448, but the draft seems to

require support in TLS 1.2 for this as a consequence of its

description of the fallback mode.

I don'=
;t *think* that that's true: can you point to the specific text that
you are concerned with?



ALPN, resumption, and 0-RTT remain problematic. For instance we see

that 0-RTT data is sent with the same ALPN state when the PSK was

derived, but this could be different from the ALPN transmitted and

negotiated during the handshake, which is explicitly allowed later in

the document. I do not understand what is supposed to happen in this

scenario.

Here's the relevant text:=


"If any of these checks fail [ALPN is in the list above] the server MUST =
NOT respond with the extension and must discard all the remaining first fli=
ght data (thus falling back to 1-RTT). If the client attempts a 0-RTT hands=
hake but the server rejects it, it will generally not have the 0-RTT record=
 protection keys and must instead trial decrypt each record with the 1-RTT =
handshake keys until it finds one that decrypts properly, and then pick up =
the handshake from that point."

Is there anything else you'd=
 like to see here?

=


Appendix B removes the text about upper-layer protocol interactions

with 0-RTT I provided, merely discussing the API. I think this is a

mistake: how 0-RTT should be used safely depends on the upper-layer

protocol, and can be complex. API guidance is not enough.
<=
div>=C2=A0
This ended up in the main text:

=

"Protocols MUST NOT use 0-RTT da=
ta without a profile that defines its use. That profile needs to identify w=
hich messages or interactions are safe to use with 0-RTT. In addition, to a=
void accidental misuse, implementations SHOULD NOT enable 0-RTT unless spec=
ifically requested. Special functions for 0-RTT data are RECOMMENDED to ens=
ure that an application is always aware that it is sending or receiving dat=
a that might be replayed."

Is this mi=
ssing pieces you think we need?


The=
re is still a note about needing a channel binding mechanism in the

text. I think this should be resolved soon so it can be analyzed,

probably built on top of the exporter mechanism. Either that, or we

consciously punt and remove the note and replace with something else.

The idea here is that we need a separate dra=
ft that just says "use exporters with
label X". I think=
 we remove the note and see if we can get someone to write
that d=
raft.



As for process, I support the idea of having a last call on November

20th, and then completing the security analysis by January 20th (or

whatever date was decided). This will prevent a flurry of changes

potentially breaking things.

That's=
 the idea.

-Ekr
=C2=A0

Sincerely,

Watson Ladd



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c07f3024dfd6105402fe437--


From nobody Mon Oct 31 14:29:56 2016
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 288AF129B34 for ; Mon, 31 Oct 2016 14:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lS3A-0bJxMq8 for ; Mon, 31 Oct 2016 14:29:53 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E81129B16 for ; Mon, 31 Oct 2016 14:29:30 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id t125so17314481ywc.1 for ; Mon, 31 Oct 2016 14:29:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=kAxYnvQKnQBaVpAkZolPy4HZjxkZdlAVagX264jSW7Y=; b=eFSjtJ83tBtEPLDozbCSrBYCx7JUoTH/vf1EWoRzYzbV4pFwMWSSnG0Sej5+gKoRLh 2ojjymZcmQQvUJZFaZ5O+nuc7uk2X+U7D7B5ceRB99tpALYhciFXLVk6GPEn4G8PDqya 7FOTGM0TuXCYDPGuGdB4laeVJVgtTj4IFO3736YcjYW1jDC/A421ZkFKv1xba7e1Svzk NVOI7rbFGijobYN+40e1smj1utp8o7ychCoB/yZWV/+Bp9ifkW8NLMux6nEXU4ehzVoG eTQGKg3fw+feK+pA4LPhgZ+PzwFEjFa15EEa6R/vSx0eCsceTNQ7gBJtnxHuKqMPT/ra z1NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kAxYnvQKnQBaVpAkZolPy4HZjxkZdlAVagX264jSW7Y=; b=TWFykiKJbb7U0M1wVlApZhu+pDKHrjcKVJHWfAha7sitzcjv0SFz9lPzwBAf/Im0nz Z7UbGyIF3EG+54sC92vcVf9qhKoEXp5qP8mJ2xmNW4vTjOByHroZkyCpiUeMVS9Ynt6f TAS0eFiawLQ7R+SiFJEe9gdYvN4E/vrz29dAf+kJ+rPH/KZHDDXRED16Ss7r8xhGc5CR s5Uq/HBmdUBGBdawP5YcTcDGJGZ0mZqpd7Z+YMIX35nbUYsZ2Z4iUXaWtPl8sMe2uHtq 2kweD52QKddfXo+4wezi0bjT+vETXXy2RIyQM5L79ABI6zjxyEvqSQRiq0HyiwY5nEfR b06g==
X-Gm-Message-State: ABUngvcU7puvDUBKmU3cWYXxMSjCs81/gvJfp115LBFR6y7jJWGU3kzQ73/yA/prSaio9jJ6oiFpZCSF9l/OQA==
X-Received: by 10.36.22.85 with SMTP id a82mr9761947ita.69.1477949369909; Mon, 31 Oct 2016 14:29:29 -0700 (PDT)
MIME-Version: 1.0
From: Nick Sullivan 
Date: Mon, 31 Oct 2016 21:29:19 +0000
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11452daa30867e05402fe7df
Archived-At: 
Subject: [TLS] draft-sullivan-tls-exported-authenticator-00
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: Mon, 31 Oct 2016 21:29:55 -0000

--001a11452daa30867e05402fe7df
Content-Type: text/plain; charset=UTF-8


draft-sullivan-tls-exported-authenticator-00>


I just posted a new Internet-Draft called "Exported Authenticators in TLS"
in the TLS working group.

The intent of this draft is to enable participants in a TLS connection to
prove ownership of additional certificates. This differs from previous
proposals (https://tools.ietf.org/html/draft
-sullivan-tls-post-handshake-auth-00) in that these proofs are not sent as
part of the TLS connection, but instead exported so that they can be sent
out of band (as part of an application layer message, for example).

This proposal should enable a radical simplification of the Secondary
Certificate Authentication in HTTP/2 proposal (
https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01),
and should generally be a useful tool for binding a certificate ownership
proof to a TLS connection.

Nick Sullivan

--001a11452daa30867e05402fe7df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I jus=
t posted a new Internet-Draft called "Exported Authenticators in TLS&q=
uot; in the TLS working group.

The intent of this draft is=
 to enable participants in a TLS connection to prove ownership of additiona=
l certificates. This differs from previous proposals (https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00) in that these=
 proofs are not sent as part of the TLS connection, but instead exported so=
 that they can be sent out of band (as part of an application layer message=
, for example).

This proposal should enable a radical simplification=
 of the Secondary Certificate Authentication in HTTP/2 proposal (
Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00
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: Mon, 31 Oct 2016 21:57:24 -0000

On Mon, Oct 31, 2016 at 09:29:19PM +0000, Nick Sullivan wrote:
>  
> draft-sullivan-tls-exported-authenticator-00>
> 
> 
> I just posted a new Internet-Draft called "Exported Authenticators in TLS"
> in the TLS working group.
> 
> The intent of this draft is to enable participants in a TLS connection to
> prove ownership of additional certificates. This differs from previous
> proposals (https://tools.ietf.org/html/draft
> -sullivan-tls-post-handshake-auth-00) in that these proofs are not sent as
> part of the TLS connection, but instead exported so that they can be sent
> out of band (as part of an application layer message, for example).
> 
> This proposal should enable a radical simplification of the Secondary
> Certificate Authentication in HTTP/2 proposal (
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01),
> and should generally be a useful tool for binding a certificate ownership
> proof to a TLS connection.

This looks A LOT saner than the current post-handshake stuff in TLS 1.3
draft. Looks implementable even.

One comment about API: There should be a method to query the TLS library
capabilities with CertificateVerify algorithm verification.

The result could e.g. be list of algorithm numbers (e.g. 0403, 0503,
0603, 0804, 0805, 0806, 0807, 0808).

Also one bit unclear thing: Is RSA-PKCS1#v1.5 allowed if negotiated
TLS version is 1.2?


-Ilari


From nobody Mon Oct 31 15:08:51 2016
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 EB93312949C for ; Mon, 31 Oct 2016 15:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Wv0TSR3Urn9i for ; Mon, 31 Oct 2016 15:08:48 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307D91204D9 for ; Mon, 31 Oct 2016 15:08:48 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id v84so95323352oie.3 for ; Mon, 31 Oct 2016 15:08:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tw09mUD70ZxbdxtZ5oafTOacL9cuhFvfDCEEJDdRiZo=; b=DhdpWy82U6oGswMortSXTLRVkFHYocvCBNSOVsu0H7F4PwbcfOgEv2gkbmy7Egg5R4 Nrn9sEhb0H6Jgt07azmlkaN3LP0Kyc42stRrD6xNPSDjEfNBdY76dUgbP8MwNuSfRH2/ F2pM8n1MnZhGJiElq8jk77cO7wt11yFQEbnJBkbeJbD0SmNywEDZrFWzTj63IpgLix/+ Llw5q2yBjGf4K625SRCMpu0zlGtaTcWsUAb6c2TpVgOpVID6eG+cQDYIzOIU+XHETkxP CggyYZmWh8RRiS0FwsI7KJrNcFw89lsJz2VsozIkEPQ1dHnKUmbQnTz3yuxEpt4l+h4n mrwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tw09mUD70ZxbdxtZ5oafTOacL9cuhFvfDCEEJDdRiZo=; b=eLdb7UQ0IfEbwSTvjasLK7fusYAkdqndD4AzGA+HGZAXg9MPKNuFwCgZttyzBnpeXT nQC8HS3XRoBvlQ5Qr+sXHSVb2UzbbY6zgT8ToMfCde3DVFtV6n1lgDHQcUlYwuqI4rbx 1pcTYLpjMrvSf/qTnJZb2+e5E0dHSEaK2ye3HldBg4TVgcLotHKBlmSNZ38eEq1rwc10 pqn87jf/yCiYd/IXz6Q0+9IkAJAJacaGq1bnDQ2GqCkWdJ0k+QE0VmZKAmWRNzLRLbpa nM11bKaPwhmm7GX04evZnlEsMwtQuylHE9pBffDcRZM2UDw65eYuRSWUMi+SOC0c4a82 vshA==
X-Gm-Message-State: ABUngvei7WJDaSrz2asdF4KqQfWljgRi7t1iH4Vu6+ujDfEf//mSY/PJM/A+XGiEj9dNY7AuyQiOXycRseYyow==
X-Received: by 10.36.24.9 with SMTP id 9mr10089334itr.121.1477951727550; Mon, 31 Oct 2016 15:08:47 -0700 (PDT)
MIME-Version: 1.0
References:  <20161031215716.GA23781@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20161031215716.GA23781@LK-Perkele-V2.elisa-laajakaista.fi>
From: Nick Sullivan 
Date: Mon, 31 Oct 2016 22:08:37 +0000
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a1144a300b7463d0540307313
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00
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: Mon, 31 Oct 2016 22:08:50 -0000

--001a1144a300b7463d0540307313
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara 
wrote:

> On Mon, Oct 31, 2016 at 09:29:19PM +0000, Nick Sullivan wrote:
> >  > <
> https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>
> > draft-sullivan-tls-exported-authenticator-00>
> > <
> https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>
> >
> > I just posted a new Internet-Draft called "Exported Authenticators in
> TLS"
> > in the TLS working group.
> >
> > The intent of this draft is to enable participants in a TLS connection to
> > prove ownership of additional certificates. This differs from previous
> > proposals (https://tools.ietf.org/html/draft
> > -sullivan-tls-post-handshake-auth-00) in that these proofs are not sent
> as
> > part of the TLS connection, but instead exported so that they can be sent
> > out of band (as part of an application layer message, for example).
> >
> > This proposal should enable a radical simplification of the Secondary
> > Certificate Authentication in HTTP/2 proposal (
> >
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01
> ),
> > and should generally be a useful tool for binding a certificate ownership
> > proof to a TLS connection.
>
> This looks A LOT saner than the current post-handshake stuff in TLS 1.3
> draft. Looks implementable even.
>
> One comment about API: There should be a method to query the TLS library
> capabilities with CertificateVerify algorithm verification.
>

> The result could e.g. be list of algorithm numbers (e.g. 0403, 0503,
> 0603, 0804, 0805, 0806, 0807, 0808).
>
Good idea.

>
> Also one bit unclear thing: Is RSA-PKCS1#v1.5 allowed if negotiated
> TLS version is 1.2?
>
I'd say yes, since it's the only RSA signature type supported in TLS 1.2.
It's not allowed in TLS 1.3.


>
>
> -Ilari
>

--001a1144a300b7463d0540307313
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Oct 31, 2016 at 09:29:19PM +0000, Nick Sullivan=
 wrote:

> <https://tools.ietf.org/html/

> <https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>

> draft-sullivan-tls-exported-authenticator-00>

> <https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>

>

> I just posted a new Internet-Draft called "Exported Authenticator=
s in TLS"

> in the TLS working group.

>

> The intent of this draft is to enable participants in a TLS connection=
 to

> prove ownership of additional certificates. This differs from previous=


> proposals (https://tools.ietf.org/html/dra=
ft

> -sullivan-tls-post-handshake-auth-00) in that these proofs are not sen=
t as

> part of the TLS connection, but instead exported so that they can be s=
ent

> out of band (as part of an application layer message, for example).
>

> This proposal should enable a radical simplification of the Secondary<=
br class=3D"gmail_msg">
> Certificate Authentication in HTTP/2 proposal (

> h=
ttps://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01),

> and should generally be a useful tool for binding a certificate owners=
hip

> proof to a TLS connection.



This looks A LOT saner than the current post-handshake stuff in TLS 1.3

draft. Looks implementable even.



One comment about API: There should be a method to query the TLS library
capabilities with CertificateVerify algorithm verification. 



The result could e.g. be list of algorithm numbers (e.g. 0403, 0503,

0603, 0804, 0805, 0806, 0807, 0808).
Good idea. 



Also one bit unclear thing: Is RSA-PKCS1#v1.5 allowed if negotiated

TLS version is 1.2?





-Ilari




--001a1144a300b7463d0540307313--


From nobody Mon Oct 31 15:21:04 2016
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 6ADE0129B6D for ; Mon, 31 Oct 2016 15:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
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 XrU8w0d1NcFB for ; Mon, 31 Oct 2016 15:21:01 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 AA58F129B4D for ; Mon, 31 Oct 2016 15:21:01 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id BE5BAA8A05DB; Mon, 31 Oct 2016 22:20:59 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 710411FE023E; Mon, 31 Oct 2016 23:20:59 +0100 (CET)
Date: Mon, 31 Oct 2016 23:20:58 +0100
From: Kurt Roeckx 
To: Ilari Liusvaara 
Message-ID: <20161031222058.ejeo5nqzzev6efni@roeckx.be>
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>  <20161031193010.GC23357@LK-Perkele-V2.elisa-laajakaista.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161031193010.GC23357@LK-Perkele-V2.elisa-laajakaista.fi>
User-Agent: NeoMutt/20161014 (1.7.1)
Archived-At: 
Cc: David Benjamin , "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 22:21:03 -0000

On Mon, Oct 31, 2016 at 09:30:10PM +0200, Ilari Liusvaara wrote:
> On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
> > 
> > We could say the versions extension only applies to 1.2 and up. I.e. don't
> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> > when they see them in the version list. That keeps the protocol deployable
> > on the Internet as it exists, avoids having to evaluate too versioning
> > schemes (if you see the extension, you don't bother reading legacy_version
> > at all), while avoiding the weird behavior where, given this ClientHello:
> > 
> >    legacy_version: TLS 1.2
> >    supported_versions: {TLS 1.1}
> > 
> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
> 
> Yeah, I don't think it ever makes sense to stick TLS 1.0 or 1.1 into
> supported_versions. There are good reasons to stick TLS 1.2 there tho.

Can you give some more details about those good reasons?


Kurt


From nobody Mon Oct 31 15:34:48 2016
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 946CF129B98 for ; Mon, 31 Oct 2016 15:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level: 
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
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 M-mFl2XmKHRG for ; Mon, 31 Oct 2016 15:34:34 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 C63FE129BA4 for ; Mon, 31 Oct 2016 15:34:33 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 68D60A8A0406; Mon, 31 Oct 2016 22:34:32 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 27C671FE023E; Mon, 31 Oct 2016 23:34:31 +0100 (CET)
Date: Mon, 31 Oct 2016 23:34:31 +0100
From: Kurt Roeckx 
To: David Benjamin 
Message-ID: <20161031223431.6j23de5gyqx6vpop@roeckx.be>
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20161014 (1.7.1)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 22:34:39 -0000

On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara 
> wrote:
> 
> > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
> > > A few supported_versions questions:
> > >
> > > 1) What should a server do if supported_versions is received but
> > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> > > ignore legacy_version?
> >
> > If legacy_version > TLS1.2, the spec requires server to ignore
> > legacy_version.
> >
> > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> > ignoring legacy_version is reasonable in this case too.
> >
> > > 2) What should a server do if supported_versions is received,
> > > ClientHello.legacy_version == TLS1.2, but supported_versions does not
> > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> > > handshake, use the legacy_version, or use use the versions in
> > > supported_versions?
> >
> > There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
> > the latter the server has never heard about...
> >
> > > 3) If the answer to (2) above is ignore the legacy_version, and just
> > > use the versions in supported_versions, which client_version should be
> > > used in the RSA pre-master secret calculation? The one in
> > > legacy_version, or the highest one in supported_versions? Presumably
> > > it has to be the one in legacy_version, otherwise thing will fail when
> > > the client talks to a server that doesn't understand
> > > supported_versions?
> >
> > Yeah, I presume putting the version in legacy_version is the only sane
> > thing to do. But causes other problems with downgrade protection.
> >
> > OTOH, RSA key exchange is known to be very broken and is affected by
> > all kinds of downgrade (and other) attacks. So if one wants actual
> > security, it needs to be removed.
> >
> 
> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate too versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
> 
>    legacy_version: TLS 1.2
>    supported_versions: {TLS 1.1}
> 
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

So I guess you're also saying that a server that implements TLS
1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
ignore the supported_versions even when it knows about it?

I guess I have same questions but with only TLS 1.3 disabled, to
be sure when we need to look at it.


Kurt


From nobody Mon Oct 31 16:13:29 2016
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 E6A491294BE for ; Mon, 31 Oct 2016 16:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level: 
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 woV_6V9Gl_Zh for ; Mon, 31 Oct 2016 16:13:25 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7D2127078 for ; Mon, 31 Oct 2016 16:13:24 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id v84so98562713oie.3 for ; Mon, 31 Oct 2016 16:13:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xO0kVYUhufrhdloX5uLrHkrLrA8N/UB6vW5bQZIorcE=; b=MwlvTt1b5w7HwkGp+Eehe++uUuHmhtNiU7PGMKwa2BX7HmE667VMpxDsi/XzvzdTvN 8FOm5ly1E8OmP4gh1NvOm1Adf9uXpZZKWN3Jw+3aG6IwHkhd6WfutKBJSHjXTQs0baDp tVOiLfKYOAj5BDQjj+E42JVBawFJ3jyhbqBUY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xO0kVYUhufrhdloX5uLrHkrLrA8N/UB6vW5bQZIorcE=; b=lCiDxic0XKA7zH5doadoWeQLHB+mfRKRU3xrWoIShcdZW3fvJC5kVZQaYR+UsguJEW hGNCAAWQZnesFCktcqw1NonJ78M7wEBoaPmCCMkvk6R0k+x5Un/zSu9D8EeOueyLnKEA MZ6/84Asxl8Hc4kVrQfIuwW5gfPiiShL3rQsdSkZQgViQJwMm8kbCpAgPYnqDbRwmLcE SfbHEiXgMv/tjLclfSV4Jq2+XkoguT5tHb5W61ulmzEIyzTspe1eho6dKOI1Vogud8eO iOVdwoyve/5dE8SEpXkf+2IuMOVSQ2G+RuBivtOIm+AUXxYQXLmTxRTQrN756ng/RsLn Vsog==
X-Gm-Message-State: ABUngve3e5pQ/i/8po/mnml/qYg9a0YfYKE0yFHCrB7Vb8xTlqAAOKaIq6GKUgKZt0lYQBmL5KQj8QqGCUDXy4og
X-Received: by 10.107.10.96 with SMTP id u93mr592826ioi.174.1477955603870; Mon, 31 Oct 2016 16:13:23 -0700 (PDT)
MIME-Version: 1.0
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>  <20161031223431.6j23de5gyqx6vpop@roeckx.be>
In-Reply-To: <20161031223431.6j23de5gyqx6vpop@roeckx.be>
From: David Benjamin 
Date: Mon, 31 Oct 2016 23:13:12 +0000
Message-ID: 
To: Kurt Roeckx 
Content-Type: multipart/alternative; boundary=001a113ee79cc3835c0540315a05
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 23:13:27 -0000

--001a113ee79cc3835c0540315a05
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:

On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara 
> wrote:
>
> > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
> > > A few supported_versions questions:
> > >
> > > 1) What should a server do if supported_versions is received but
> > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> > > ignore legacy_version?
> >
> > If legacy_version > TLS1.2, the spec requires server to ignore
> > legacy_version.
> >
> > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> > ignoring legacy_version is reasonable in this case too.
> >
> > > 2) What should a server do if supported_versions is received,
> > > ClientHello.legacy_version == TLS1.2, but supported_versions does not
> > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> > > handshake, use the legacy_version, or use use the versions in
> > > supported_versions?
> >
> > There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
> > the latter the server has never heard about...
> >
> > > 3) If the answer to (2) above is ignore the legacy_version, and just
> > > use the versions in supported_versions, which client_version should be
> > > used in the RSA pre-master secret calculation? The one in
> > > legacy_version, or the highest one in supported_versions? Presumably
> > > it has to be the one in legacy_version, otherwise thing will fail when
> > > the client talks to a server that doesn't understand
> > > supported_versions?
> >
> > Yeah, I presume putting the version in legacy_version is the only sane
> > thing to do. But causes other problems with downgrade protection.
> >
> > OTOH, RSA key exchange is known to be very broken and is affected by
> > all kinds of downgrade (and other) attacks. So if one wants actual
> > security, it needs to be removed.
> >
>
> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate too versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
>
>    legacy_version: TLS 1.2
>    supported_versions: {TLS 1.1}
>
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

So I guess you're also saying that a server that implements TLS
1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
ignore the supported_versions even when it knows about it?

I guess I have same questions but with only TLS 1.3 disabled, to
be sure when we need to look at it.


Hrm, actually I hadn't thought of that. Yeah, I guess a server which
disables versions must then gate supported_version handling on whether TLS
1.3 is enabled. That's not a dealbreaker, but is certainly additional
gnarliness.

(Our current implementation just processes the extension uncondtionally,
but we'll also happily negotiate old versions out of it.)

David

--001a113ee79cc3835c0540315a05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx <kurt@roeckx.be<=
/a>> wrote:
On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara <ilariliusva=
ara@welho.com>

> wrote:

>

> > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:

> > > A few supported_versions questions:

> > >

> > > 1) What should a server do if supported_versions is received=
 but

> > > ClientHello.legacy_version !=3D TLS1.2? Fail the handshake, =
or just

> > > ignore legacy_version?

> >

> > If legacy_version > TLS1.2, the spec requires server to ignore=


> > legacy_version.

> >

> > The case where legacy_version < TLS1.2 IIRC isn't specifie=
d, but

> > ignoring legacy_version is reasonable in this case too.

> >

> > > 2) What should a server do if supported_versions is received=
,

> > > ClientHello.legacy_version =3D=3D TLS1.2, but supported_vers=
ions does not

> > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)?=
 Fail the

> > > handshake, use the legacy_version, or use use the versions i=
n

> > > supported_versions?

> >

> > There's also the case where supported_versions has TLS 1.1 an=
d TLS 1.4,

> > the latter the server has never heard about...

> >

> > > 3) If the answer to (2) above is ignore the legacy_version, =
and just

> > > use the versions in supported_versions, which client_version=
 should be

> > > used in the RSA pre-master secret calculation? The one in
> > > legacy_version, or the highest one in supported_versions? Pr=
esumably

> > > it has to be the one in legacy_version, otherwise thing will=
 fail when

> > > the client talks to a server that doesn't understand

> > > supported_versions?

> >

> > Yeah, I presume putting the version in legacy_version is the only=
 sane

> > thing to do. But causes other problems with downgrade protection.=


> >

> > OTOH, RSA key exchange is known to be very broken and is affected=
 by

> > all kinds of downgrade (and other) attacks. So if one wants actua=
l

> > security, it needs to be removed.

> >

>

> We could say the versions extension only applies to 1.2 and up. I.e. d=
on't

> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and =
1.0

> when they see them in the version list. That keeps the protocol deploy=
able

> on the Internet as it exists, avoids having to evaluate too versioning=


> schemes (if you see the extension, you don't bother reading legacy=
_version

> at all), while avoiding the weird behavior where, given this ClientHel=
lo:

>

>=C2=A0 =C2=A0 legacy_version: TLS 1.2

>=C2=A0 =C2=A0 supported_versions: {TLS 1.1}

>

> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.=
2.



So I guess you're also saying that a server that implements TLS

1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should

ignore the supported_versions even when it knows about it?



I guess I have same questions but with only TLS 1.3 disabled, to

be sure when we need to look at it.

Hrm, actually I had=
n't thought of that. Yeah, I guess a server which disables versions mus=
t then gate supported_version handling on whether TLS 1.3 is enabled. That&=
#39;s not a dealbreaker, but is certainly additional gnarliness.

=
(Our current implementation just processes the extension uncondtionally, bu=
t we'll also happily negotiate old versions out of it.)

David=C2=A0


--001a113ee79cc3835c0540315a05--


From nobody Mon Oct 31 16:26:37 2016
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 D93D6127078 for ; Mon, 31 Oct 2016 16:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
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 xBYiXLgBNnjB for ; Mon, 31 Oct 2016 16:26:35 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B621E1294B3 for ; Mon, 31 Oct 2016 16:26:34 -0700 (PDT)
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id C11B5C5B for ; Mon, 31 Oct 2016 23:26:32 +0000 (GMT)
Received: by mail-qk0-f174.google.com with SMTP id o68so181845797qkf.3 for ; Mon, 31 Oct 2016 16:26:32 -0700 (PDT)
X-Gm-Message-State: ABUngvcpoG8JfLeq1Cl2PY2ph/rcoG1c1egG2hnZtETE04f6mnFAuSvdMDxfPw5UJ/RPzBevq6eOwUbRUz3BEg==
X-Received: by 10.55.27.226 with SMTP id m95mr29804554qkh.143.1477956391014; Mon, 31 Oct 2016 16:26:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.34.61 with HTTP; Mon, 31 Oct 2016 16:26:30 -0700 (PDT)
In-Reply-To: 
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>  <20161031223431.6j23de5gyqx6vpop@roeckx.be> 
From: Matt Caswell 
Date: Mon, 31 Oct 2016 23:26:30 +0000
X-Gmail-Original-Message-ID: 
Message-ID: 
To: David Benjamin 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 23:26:37 -0000

On 31 October 2016 at 23:13, David Benjamin  wrote:
> On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:
>>
>> On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
>> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
>> > 
>> > wrote:
>> >
>> > > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
>> > > > A few supported_versions questions:
>> > > >
>> > > > 1) What should a server do if supported_versions is received but
>> > > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
>> > > > ignore legacy_version?
>> > >
>> > > If legacy_version > TLS1.2, the spec requires server to ignore
>> > > legacy_version.
>> > >
>> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
>> > > ignoring legacy_version is reasonable in this case too.
>> > >
>> > > > 2) What should a server do if supported_versions is received,
>> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does
>> > > > not
>> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail
>> > > > the
>> > > > handshake, use the legacy_version, or use use the versions in
>> > > > supported_versions?
>> > >
>> > > There's also the case where supported_versions has TLS 1.1 and TLS
>> > > 1.4,
>> > > the latter the server has never heard about...
>> > >
>> > > > 3) If the answer to (2) above is ignore the legacy_version, and just
>> > > > use the versions in supported_versions, which client_version should
>> > > > be
>> > > > used in the RSA pre-master secret calculation? The one in
>> > > > legacy_version, or the highest one in supported_versions? Presumably
>> > > > it has to be the one in legacy_version, otherwise thing will fail
>> > > > when
>> > > > the client talks to a server that doesn't understand
>> > > > supported_versions?
>> > >
>> > > Yeah, I presume putting the version in legacy_version is the only sane
>> > > thing to do. But causes other problems with downgrade protection.
>> > >
>> > > OTOH, RSA key exchange is known to be very broken and is affected by
>> > > all kinds of downgrade (and other) attacks. So if one wants actual
>> > > security, it needs to be removed.
>> > >
>> >
>> > We could say the versions extension only applies to 1.2 and up. I.e.
>> > don't
>> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and
>> > 1.0
>> > when they see them in the version list. That keeps the protocol
>> > deployable
>> > on the Internet as it exists, avoids having to evaluate too versioning
>> > schemes (if you see the extension, you don't bother reading
>> > legacy_version
>> > at all), while avoiding the weird behavior where, given this
>> > ClientHello:
>> >
>> >    legacy_version: TLS 1.2
>> >    supported_versions: {TLS 1.1}
>> >
>> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
>>
>> So I guess you're also saying that a server that implements TLS
>> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
>> ignore the supported_versions even when it knows about it?
>>
>> I guess I have same questions but with only TLS 1.3 disabled, to
>> be sure when we need to look at it.
>
>
> Hrm, actually I hadn't thought of that. Yeah, I guess a server which
> disables versions must then gate supported_version handling on whether TLS
> 1.3 is enabled. That's not a dealbreaker, but is certainly additional
> gnarliness.
>
> (Our current implementation just processes the extension uncondtionally, but
> we'll also happily negotiate old versions out of it.)

I came up with some alternative wording that I think captures the discussion:

https://github.com/tlswg/tls13-spec/pull/748

Matt


From nobody Mon Oct 31 16:35:55 2016
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 9343C129BC6 for ; Mon, 31 Oct 2016 16:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 IxWJWPR0pL6r for ; Mon, 31 Oct 2016 16:35:52 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32A7129ADD for ; Mon, 31 Oct 2016 16:35:51 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l124so20848134ywb.3 for ; Mon, 31 Oct 2016 16:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A9Y61Zm2IIobsMFeMNgurKXS4WxHrX90GprLUSUYZ/o=; b=VDJSJxF2Jt9yJsSWWGZNJaDXfhrbTyoeBOgkkVsgx2hl5D/wrZSc9F32iGjsNx5CQi Sd06YOze4mOM9nGhsXLPp/IBaz1BYrnDyo4Ne1kfLn9QYS3uTkJOw6+3+crTPCuju54v DxOSFp8wPRLJnKqwMtK0tljDbNtBs6FbEB8V7WdhqGbAeKvU6loIwG5YmdNnJc1wgvsX 8G8hl5RvDBZix6EDihQhyiDUYnHdqZ3yczrBg9+XfZcf6jPH6mMfzqjr1bmF/nhRcNcs PBoz7ixM7bsfFcmKVcSZpaMHxDTAP+rUS+VGkuv19Tbfl1FHRQA9r0o+CVKXWF05NDUZ mGMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A9Y61Zm2IIobsMFeMNgurKXS4WxHrX90GprLUSUYZ/o=; b=k8Lm7QlbouO8Qnd/dRwdHb2pBFKXNM0CfXDWLbtkILx6fPVxQOQtF7kHa8ZV+ru2W/ idCfnkc9L0qbQDTEdGjDB61d2KpTe/7VjvdXLYZEQ/t1gauGdbcVb4yQu41+WrBfyYmd JHZZVPrXx8p8XKwXWl1sI+a9kKMVd8crlLs/3jnNR3ot8+87MVUUk34YJ4tE1OG+ZUMi 4+wXuJaAJgu5tgexFnE1Gz+ICK0PaUjO79vkry96Jfy1EtJ/+Aoj/zBJ9k2j8SPCuuW4 ALArn82W7Oewk1NXJPuZmH73EBFsgTmHk9C5NrHSHG61vrhtJq1At2KEh8kiAQ9lC4ND YE2Q==
X-Gm-Message-State: ABUngvd4gBmOVSG66riCBzhu6CB3Nm3RWLYB6kBBMWiUxwJo74QUQPtEjTHx9oll6i83vboMjsb0Dg49r9NaCQ==
X-Received: by 10.129.121.1 with SMTP id u1mr8085763ywc.146.1477956950956; Mon, 31 Oct 2016 16:35:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.159.141 with HTTP; Mon, 31 Oct 2016 16:35:10 -0700 (PDT)
In-Reply-To: 
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>  <20161031223431.6j23de5gyqx6vpop@roeckx.be> 
From: Eric Rescorla 
Date: Mon, 31 Oct 2016 16:35:10 -0700
Message-ID: 
To: David Benjamin 
Content-Type: multipart/alternative; boundary=94eb2c0a8f820e72a0054031abff
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 23:35:54 -0000

--94eb2c0a8f820e72a0054031abff
Content-Type: text/plain; charset=UTF-8

Our current implementation also processes the extension unconditionally.

I'm not convinced that this represents an improvement, both for the reason
that Kurt
indicates and just in terms of simplicity of story. The current design is
simply
"if supported_versions is present, then use it", whereas trying to clip it
on 1.2
is inherently more complicated. I'm not particularly bothered by the anomaly
that David mentions between legacy_version and supported_versions,
especially
given that we're perfectly happy to tolerate deviation the other way.

-Ekr


On Mon, Oct 31, 2016 at 4:13 PM, David Benjamin 
wrote:

> On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:
>
> On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> >
> > > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
> > > > A few supported_versions questions:
> > > >
> > > > 1) What should a server do if supported_versions is received but
> > > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> > > > ignore legacy_version?
> > >
> > > If legacy_version > TLS1.2, the spec requires server to ignore
> > > legacy_version.
> > >
> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> > > ignoring legacy_version is reasonable in this case too.
> > >
> > > > 2) What should a server do if supported_versions is received,
> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does not
> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> > > > handshake, use the legacy_version, or use use the versions in
> > > > supported_versions?
> > >
> > > There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
> > > the latter the server has never heard about...
> > >
> > > > 3) If the answer to (2) above is ignore the legacy_version, and just
> > > > use the versions in supported_versions, which client_version should
> be
> > > > used in the RSA pre-master secret calculation? The one in
> > > > legacy_version, or the highest one in supported_versions? Presumably
> > > > it has to be the one in legacy_version, otherwise thing will fail
> when
> > > > the client talks to a server that doesn't understand
> > > > supported_versions?
> > >
> > > Yeah, I presume putting the version in legacy_version is the only sane
> > > thing to do. But causes other problems with downgrade protection.
> > >
> > > OTOH, RSA key exchange is known to be very broken and is affected by
> > > all kinds of downgrade (and other) attacks. So if one wants actual
> > > security, it needs to be removed.
> > >
> >
> > We could say the versions extension only applies to 1.2 and up. I.e.
> don't
> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> > when they see them in the version list. That keeps the protocol
> deployable
> > on the Internet as it exists, avoids having to evaluate too versioning
> > schemes (if you see the extension, you don't bother reading
> legacy_version
> > at all), while avoiding the weird behavior where, given this ClientHello:
> >
> >    legacy_version: TLS 1.2
> >    supported_versions: {TLS 1.1}
> >
> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
>
> So I guess you're also saying that a server that implements TLS
> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
> ignore the supported_versions even when it knows about it?
>
> I guess I have same questions but with only TLS 1.3 disabled, to
> be sure when we need to look at it.
>
>
> Hrm, actually I hadn't thought of that. Yeah, I guess a server which
> disables versions must then gate supported_version handling on whether TLS
> 1.3 is enabled. That's not a dealbreaker, but is certainly additional
> gnarliness.
>
> (Our current implementation just processes the extension uncondtionally,
> but we'll also happily negotiate old versions out of it.)
>
> David
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c0a8f820e72a0054031abff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Our current implementation also processes the extension un=
conditionally.

I'm not convinced that this represent=
s an improvement, both for the reason that Kurt
indicates and jus=
t in terms of simplicity of story. The current design is simply
&=
quot;if supported_versions is present, then use it", whereas trying to=
 clip it on 1.2
is inherently more complicated. I'm not parti=
cularly bothered by the anomaly
that David mentions between legac=
y_version and supported_versions, especially
given that we're=
 perfectly happy to tolerate deviation the other way.

<=
div>
-Ekr

On Mon, Oct 31, 2016 at 4:13 PM, David Benjami=
n <davidben@chromium.org> wrote:
On Mon, Oct 31,=
 2016 at 6:34 PM Kurt Roeckx <kurt@roeckx.be> w=
rote:
On Mon, Oct 31, 2016 at 07:11:=
10PM +0000, David Benjamin wrote:

> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara <ilariliusvaara@welho.com>

> wrote:

>

> > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:

> > > A few supported_versions questions:

> > >

> > > 1) What should a server do if supported_versions is received=
 but

> > > ClientHello.legacy_version !=3D TLS1.2? Fail the handshake, =
or just

> > > ignore legacy_version?

> >

> > If legacy_version > TLS1.2, the spec requires server to ignore=


> > legacy_version.

> >

> > The case where legacy_version < TLS1.2 IIRC isn't specifie=
d, but

> > ignoring legacy_version is reasonable in this case too.

> >

> > > 2) What should a server do if supported_versions is received=
,

> > > ClientHello.legacy_version =3D=3D TLS1.2, but supported_vers=
ions does not

> > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)?=
 Fail the

> > > handshake, use the legacy_version, or use use the versions i=
n

> > > supported_versions?

> >

> > There's also the case where supported_versions has TLS 1.1 an=
d TLS 1.4,

> > the latter the server has never heard about...

> >

> > > 3) If the answer to (2) above is ignore the legacy_version, =
and just

> > > use the versions in supported_versions, which client_version=
 should be

> > > used in the RSA pre-master secret calculation? The one in
> > > legacy_version, or the highest one in supported_versions? Pr=
esumably

> > > it has to be the one in legacy_version, otherwise thing will=
 fail when

> > > the client talks to a server that doesn't understand

> > > supported_versions?

> >

> > Yeah, I presume putting the version in legacy_version is the only=
 sane

> > thing to do. But causes other problems with downgrade protection.=


> >

> > OTOH, RSA key exchange is known to be very broken and is affected=
 by

> > all kinds of downgrade (and other) attacks. So if one wants actua=
l

> > security, it needs to be removed.

> >

>

> We could say the versions extension only applies to 1.2 and up. I.e. d=
on't

> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and =
1.0

> when they see them in the version list. That keeps the protocol deploy=
able

> on the Internet as it exists, avoids having to evaluate too versioning=


> schemes (if you see the extension, you don't bother reading legacy=
_version

> at all), while avoiding the weird behavior where, given this ClientHel=
lo:

>

>=C2=A0 =C2=A0 legacy_version: TLS 1.2

>=C2=A0 =C2=A0 supported_versions: {TLS 1.1}

>

> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.=
2.



So I guess you're also saying that a server that implements TLS

1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should

ignore the supported_versions even when it knows about it?



I guess I have same questions but with only TLS 1.3 disabled, to

be sure when we need to look at it.

Hrm, act=
ually I hadn't thought of that. Yeah, I guess a server which disables v=
ersions must then gate supported_version handling on whether TLS 1.3 is ena=
bled. That's not a dealbreaker, but is certainly additional gnarliness.=


(=
Our current implementation just processes the extension uncondtionally, but=
 we'll also happily negotiate old versions out of it.)

Davi=
d=C2=A0


_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c0a8f820e72a0054031abff--


From nobody Mon Oct 31 16:49:39 2016
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 9DE8F129BE8 for ; Mon, 31 Oct 2016 16:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
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 gqx6_aWty9Yt for ; Mon, 31 Oct 2016 16:49:36 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C804B129BE7 for ; Mon, 31 Oct 2016 16:49:35 -0700 (PDT)
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 144E9AF9 for ; Mon, 31 Oct 2016 23:49:33 +0000 (GMT)
Received: by mail-qk0-f180.google.com with SMTP id q130so61872621qke.1 for ; Mon, 31 Oct 2016 16:49:33 -0700 (PDT)
X-Gm-Message-State: ABUngvde3YA6rvaDzeE3BYghVen8VVGU5l6jXUq8HxWs8i7WiT0PlqpZPTaEQRJpZqwnKejvFL7gpVon6YzMIQ==
X-Received: by 10.55.177.5 with SMTP id a5mr17859682qkf.153.1477957772651; Mon, 31 Oct 2016 16:49:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.34.61 with HTTP; Mon, 31 Oct 2016 16:49:31 -0700 (PDT)
In-Reply-To: 
References:  <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>  <20161031223431.6j23de5gyqx6vpop@roeckx.be>  
From: Matt Caswell 
Date: Mon, 31 Oct 2016 23:49:31 +0000
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 23:49:37 -0000

On 31 October 2016 at 23:35, Eric Rescorla  wrote:
> Our current implementation also processes the extension unconditionally.
>
> I'm not convinced that this represents an improvement, both for the reason
> that Kurt
> indicates and just in terms of simplicity of story. The current design is
> simply
> "if supported_versions is present, then use it", whereas trying to clip it
> on 1.2
> is inherently more complicated. I'm not particularly bothered by the anomaly
> that David mentions between legacy_version and supported_versions,
> especially
> given that we're perfectly happy to tolerate deviation the other way.

My biggest concern is that there are a number of corner cases here
where it is unclear what to do because the current wording doesn't
specify it (see my original questions at the start of this thread).
Like, I said earlier, it could be made to work If retaining 
> -Ekr
>
>
> On Mon, Oct 31, 2016 at 4:13 PM, David Benjamin 
> wrote:
>>
>> On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:
>>>
>>> On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
>>> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
>>> > 
>>> > wrote:
>>> >
>>> > > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
>>> > > > A few supported_versions questions:
>>> > > >
>>> > > > 1) What should a server do if supported_versions is received but
>>> > > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
>>> > > > ignore legacy_version?
>>> > >
>>> > > If legacy_version > TLS1.2, the spec requires server to ignore
>>> > > legacy_version.
>>> > >
>>> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
>>> > > ignoring legacy_version is reasonable in this case too.
>>> > >
>>> > > > 2) What should a server do if supported_versions is received,
>>> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does
>>> > > > not
>>> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail
>>> > > > the
>>> > > > handshake, use the legacy_version, or use use the versions in
>>> > > > supported_versions?
>>> > >
>>> > > There's also the case where supported_versions has TLS 1.1 and TLS
>>> > > 1.4,
>>> > > the latter the server has never heard about...
>>> > >
>>> > > > 3) If the answer to (2) above is ignore the legacy_version, and
>>> > > > just
>>> > > > use the versions in supported_versions, which client_version should
>>> > > > be
>>> > > > used in the RSA pre-master secret calculation? The one in
>>> > > > legacy_version, or the highest one in supported_versions?
>>> > > > Presumably
>>> > > > it has to be the one in legacy_version, otherwise thing will fail
>>> > > > when
>>> > > > the client talks to a server that doesn't understand
>>> > > > supported_versions?
>>> > >
>>> > > Yeah, I presume putting the version in legacy_version is the only
>>> > > sane
>>> > > thing to do. But causes other problems with downgrade protection.
>>> > >
>>> > > OTOH, RSA key exchange is known to be very broken and is affected by
>>> > > all kinds of downgrade (and other) attacks. So if one wants actual
>>> > > security, it needs to be removed.
>>> > >
>>> >
>>> > We could say the versions extension only applies to 1.2 and up. I.e.
>>> > don't
>>> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and
>>> > 1.0
>>> > when they see them in the version list. That keeps the protocol
>>> > deployable
>>> > on the Internet as it exists, avoids having to evaluate too versioning
>>> > schemes (if you see the extension, you don't bother reading
>>> > legacy_version
>>> > at all), while avoiding the weird behavior where, given this
>>> > ClientHello:
>>> >
>>> >    legacy_version: TLS 1.2
>>> >    supported_versions: {TLS 1.1}
>>> >
>>> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS
>>> > 1.2.
>>>
>>> So I guess you're also saying that a server that implements TLS
>>> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
>>> ignore the supported_versions even when it knows about it?
>>>
>>> I guess I have same questions but with only TLS 1.3 disabled, to
>>> be sure when we need to look at it.
>>
>>
>> Hrm, actually I hadn't thought of that. Yeah, I guess a server which
>> disables versions must then gate supported_version handling on whether TLS
>> 1.3 is enabled. That's not a dealbreaker, but is certainly additional
>> gnarliness.
>>
>> (Our current implementation just processes the extension uncondtionally,
>> but we'll also happily negotiate old versions out of it.)
>>
>> David
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Mon Oct 31 16:53:32 2016
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 4EC53129BD0 for ; Mon, 31 Oct 2016 16:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 X8dW1Ocxje_9 for ; Mon, 31 Oct 2016 16:53:28 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEBA129462 for ; Mon, 31 Oct 2016 16:53:28 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id z190so180926016qkc.2 for ; Mon, 31 Oct 2016 16:53:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=JZxEwWU/31Uf5d8EmX4xFYqoG3j/tjqstcglxlCz5RQ=; b=mC0TL1q4jAdd75xeqqMcsSQ89MzXHcMUa15XRC3XnsjqQhWGixpbqSXbG/nzpLFGSI gfbVAvLnXUjegQQiq/OOGaRqlmuDt/QHawEpwpX/ttCqAwQdOAdrJNTTWeYSa/5M/LAh 8igEH1sHl9asIRl8f0Y5TW9qJ8f9ZZzuhRwtODG1xtQduJPieRK7l94g3UsnMhb11IAH 3HXNwTJKNUKQYpajfE7OTkVsW1JilF5A/MVcPYMHwACLTGAADJodaYglXX70pJluuAny arEo9HR55n0FpRK+dcC71mICGRoShs/1SiIAqZIiWBKbHHXUHU3G9CbQmEGhRBCZSqik nw/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=JZxEwWU/31Uf5d8EmX4xFYqoG3j/tjqstcglxlCz5RQ=; b=OIbhg5+HgXivc0zCbjmBTUwpcVEVhydlRmSoDZaSq8ZzPGYnoSFkO317+lMTf/IR2V j9F9QFp9Z66KeVLPI1OKINWweXLPmLOn/BHrezq3u8WwtoliIx+uIDl/lmkSx+3Rtk4R Xylayr+flhgNLZWk9CKqmKsNJdNPGS2KqjwKdLO8WFRGLllI6flYEPGXM9ZKr8rRJmo8 wpxb7xMvrH+/MY1wJO2J7AS6NUimKLJruiO/hYb25j3wo7F51nqoM9SzPlt6f8fTT3mL z3bI6iAnDxE70JW5cXcgTg8CnS9IXZyyMLILImYyVg5gulCoooYDBFfFCq9Cgbgvkpce qenA==
X-Gm-Message-State: ABUngvcTdOjhAxCBI5apYBzYjIj90UXCm6gvVxKxkOE4PV6Uf6ao4661YAy99yG5EhjBOw==
X-Received: by 10.55.170.131 with SMTP id t125mr26937568qke.15.1477958007350;  Mon, 31 Oct 2016 16:53:27 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id v10sm14464375qkg.20.2016.10.31.16.53.26 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 31 Oct 2016 16:53:26 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Mon, 31 Oct 2016 19:53:25 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:   
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201610311953.25606.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] supported_versions question
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: Mon, 31 Oct 2016 23:53:30 -0000

On Monday, October 31, 2016 07:26:30 pm Matt Caswell wrote:
> On 31 October 2016 at 23:13, David Benjamin  wrote:
> > On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:
> >>
> >> On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
> >> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
> >> > 
> >> > wrote:
> >> >
> >> > > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
> >> > > > A few supported_versions questions:
> >> > > >
> >> > > > 1) What should a server do if supported_versions is received but
> >> > > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> >> > > > ignore legacy_version?
> >> > >
> >> > > If legacy_version > TLS1.2, the spec requires server to ignore
> >> > > legacy_version.
> >> > >
> >> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> >> > > ignoring legacy_version is reasonable in this case too.
> >> > >
> >> > > > 2) What should a server do if supported_versions is received,
> >> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does
> >> > > > not
> >> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail
> >> > > > the
> >> > > > handshake, use the legacy_version, or use use the versions in
> >> > > > supported_versions?
> >> > >
> >> > > There's also the case where supported_versions has TLS 1.1 and TLS
> >> > > 1.4,
> >> > > the latter the server has never heard about...
> >> > >
> >> > > > 3) If the answer to (2) above is ignore the legacy_version, and just
> >> > > > use the versions in supported_versions, which client_version should
> >> > > > be
> >> > > > used in the RSA pre-master secret calculation? The one in
> >> > > > legacy_version, or the highest one in supported_versions? Presumably
> >> > > > it has to be the one in legacy_version, otherwise thing will fail
> >> > > > when
> >> > > > the client talks to a server that doesn't understand
> >> > > > supported_versions?
> >> > >
> >> > > Yeah, I presume putting the version in legacy_version is the only sane
> >> > > thing to do. But causes other problems with downgrade protection.
> >> > >
> >> > > OTOH, RSA key exchange is known to be very broken and is affected by
> >> > > all kinds of downgrade (and other) attacks. So if one wants actual
> >> > > security, it needs to be removed.
> >> > >
> >> >
> >> > We could say the versions extension only applies to 1.2 and up. I.e.
> >> > don't
> >> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and
> >> > 1.0
> >> > when they see them in the version list. That keeps the protocol
> >> > deployable
> >> > on the Internet as it exists, avoids having to evaluate too versioning
> >> > schemes (if you see the extension, you don't bother reading
> >> > legacy_version
> >> > at all), while avoiding the weird behavior where, given this
> >> > ClientHello:
> >> >
> >> >    legacy_version: TLS 1.2
> >> >    supported_versions: {TLS 1.1}
> >> >
> >> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
> >>
> >> So I guess you're also saying that a server that implements TLS
> >> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
> >> ignore the supported_versions even when it knows about it?
> >>
> >> I guess I have same questions but with only TLS 1.3 disabled, to
> >> be sure when we need to look at it.
> >
> >
> > Hrm, actually I hadn't thought of that. Yeah, I guess a server which
> > disables versions must then gate supported_version handling on whether TLS
> > 1.3 is enabled. That's not a dealbreaker, but is certainly additional
> > gnarliness.
> >
> > (Our current implementation just processes the extension uncondtionally, but
> > we'll also happily negotiate old versions out of it.)
> 
> I came up with some alternative wording that I think captures the discussion:
> 
> https://github.com/tlswg/tls13-spec/pull/748

I see no reason to require servers to validate the legacy version value. That's just excess complexity. If the extension is there, then it should take absolute precedence. If not, use the old system. Nothing will have a higher value there except old probers.

Ditching TLS 1.0/1.1 from the extension sounds fine, though. There's not going to be any servers accepting this extension that won't negotiate 1.2+.


Dave


From nobody Mon Oct 31 17:06:06 2016
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 AC828129C01 for ; Mon, 31 Oct 2016 17:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 0q6blaPSL4zd for ; Mon, 31 Oct 2016 17:06:03 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0E4129BFC for ; Mon, 31 Oct 2016 17:06:03 -0700 (PDT)
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id A40BDAD5 for ; Tue,  1 Nov 2016 00:06:01 +0000 (GMT)
Received: by mail-qk0-f179.google.com with SMTP id v138so91272944qka.0 for ; Mon, 31 Oct 2016 17:06:01 -0700 (PDT)
X-Gm-Message-State: ABUngvcUHcVcxhtL+GoSFAOREVgdecicmoa0MOLQ8ib1fbC6jaH6kht+fPPEdI94V7SL2kVbhqP/a6avKSqMow==
X-Received: by 10.55.27.226 with SMTP id m95mr29943391qkh.143.1477958760217; Mon, 31 Oct 2016 17:06:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.34.61 with HTTP; Mon, 31 Oct 2016 17:05:59 -0700 (PDT)
In-Reply-To: <201610311953.25606.davemgarrett@gmail.com>
References:    <201610311953.25606.davemgarrett@gmail.com>
From: Matt Caswell 
Date: Tue, 1 Nov 2016 00:05:59 +0000
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dave Garrett 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Tue, 01 Nov 2016 00:06:04 -0000

On 31/10/16 23:53, Dave Garrett wrote:
>> I came up with some alternative wording that I think captures the discus=
sion:
>>
>> https://github.com/tlswg/tls13-spec/pull/748
>
> I see no reason to require servers to validate the legacy version value. =
That's just excess complexity. If the extension is there, then it should ta=
ke absolute precedence. If not, use the old system. Nothing will have a hig=
her value there except old probers.

If legacy_version =3D=3D 0x0302 (TLS1.1), but highest supported_version is
0x0303 (TLS1.2) - or vice versa, which client_version should be used
in an RSA key exchange calculation?

Matt


From nobody Mon Oct 31 17:19:21 2016
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 24EC1129BFB for ; Mon, 31 Oct 2016 17:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 khi1d2A_IYny for ; Mon, 31 Oct 2016 17:19:18 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69570129981 for ; Mon, 31 Oct 2016 17:19:18 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id z190so181455517qkc.2 for ; Mon, 31 Oct 2016 17:19:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=XbsNC2Q1QJAObatZgAo8/ik6jRmn5Q3E5HCyLFzv/+s=; b=GxbVhZ5e7GGmHNpT6xbwNInguStvy4X3lXS+4hn5yKokPJPjzYalt2kPWPkXUOp1RA omGTLgUtViyUoXSBkOtz4fiB1SEQFdgk+4Tj/llCWtTN4ms2lcTYP1IRG/UHD5DAeW/g Ew+kyZQfI8ifMfA5wZSjtRSZR7JHAI2IOeaAHFZmOD/In/3iPavHmSimSvwZffZVMIjp e8N8DipdLk4PImP8kDfsmmlF8wKniMBXvI4QmnoX4Gj4gMFvIO6ybpSvFEJOVQzHTVTQ mE2wWNcmFidk+Y4yGe28OFEvzeaqFeVeahtJ6T9/XybDWyv4ezoY5x6JrMFCKQqQuliK fi8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=XbsNC2Q1QJAObatZgAo8/ik6jRmn5Q3E5HCyLFzv/+s=; b=CblqQkWJe72SRiZaUnfuS03EqB/UdDL1NLp5ZQ6wGEQkxio/0i7B1po80A7s4TGpMm zSdX+dKiyd1W0XXWzbCFnNPSHS652R5QxC27GnsSASPtHV7ssYyilrxYLegMYoIkV47E XdAYKEgkmtLrQqb9h9lct92ctePuBxTWtZd3JHVHmIMJC/cDswjLzlnNpctEvPbo26t5 a4/bIZwPP+66N6nmql66SosR+Y+QtsYYL2V9tcTlO2kY8frdq8CWI0Rh6ypvDPnsMcER G+14v9Xjcs4RwDz95zzwHlcKT7Vzlcij6dYj3kw+5agAhJkH9/CogWPqgQszLrazbITv ToJA==
X-Gm-Message-State: ABUngve7D6oqpWDIwm515sVWMX1MD8D0H2XzNyHa5q4mrEBrW28o3kHGk6V4mAPIJDsOfw==
X-Received: by 10.55.68.80 with SMTP id r77mr24574832qka.318.1477959557539; Mon, 31 Oct 2016 17:19:17 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id o31sm128014qtf.20.2016.10.31.17.19.16 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 31 Oct 2016 17:19:16 -0700 (PDT)
From: Dave Garrett 
To: Matt Caswell 
Date: Mon, 31 Oct 2016 20:19:15 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:  <201610311953.25606.davemgarrett@gmail.com> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201610312019.15918.davemgarrett@gmail.com>
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] supported_versions question
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: Tue, 01 Nov 2016 00:19:20 -0000

On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> On 31/10/16 23:53, Dave Garrett wrote:
> >> I came up with some alternative wording that I think captures the discussion:
> >>
> >> https://github.com/tlswg/tls13-spec/pull/748
> >
> > I see no reason to require servers to validate the legacy version value. That's just excess complexity. If the extension is there, then it should take absolute precedence. If not, use the old system. Nothing will have a higher value there except old probers.
> 
> If legacy_version == 0x0302 (TLS1.1), but highest supported_version is
> 0x0303 (TLS1.2) - or vice versa, which client_version should be used
> in an RSA key exchange calculation?

Why would this ever happen? What client is offering to support TLS 1.1 via the ClientHello field but offers only TLS 1.2 via the TLS 1.3 extension? This is a very contrived implementation error; if you need to account for it, abort the connection with an error. As to the vice versa, dropping 1.0/1.1 support from the extension avoids that.

The simplest route here is to always use the extension if it exists, and use the legacy value if not. With 1.0/1.1 removed from the extension, that means that 1.0/1.1 cannot be negotiated with the extension, which I see as fine; they'll only be negotiated with servers that don't support the extension. (the theoretical case of a server wanting to negotiate 1.0/1.1 with a client using the extension is not one worth supporting; 1.2+ or bust is reasonable, here)


Dave


All,



It=92s time to put this one to bed.  ekr=92s going to put back user_ma=
pping for Andrei/MS, but we=92re going to ban/orphan the client_authz and s=
erver_authz extensions.  If it turns out that there=92s some need to l=
ater unban/unorphan them, then somebody can write
 a draft that specifies how they=92re used with TLS1.3.



spt



> On Sep 06, 2016, at 23:58, Russ Housley <housley@vigilsec.com> w=
rote:

> 

> I agree that client_authz and server_authz have not enjoyed much imple=
mentation.

> 

> Russ

> 

> 

> On Sep 3, 2016, at 3:54 PM, Eric Rescorla <ekr@rtfm.com> wrote:<=
br>
> 

>> https://g=
ithub.com/tlswg/tls13-spec/pull/624

>> 

>> We currently have code points assigned for

>> 

>>  user_mapping [RFC4681]     

>>  client_authz [RFC5878]      

>>  server_authz [RFC5878] 

>> 

>> These aren't well-specified for use in TLS 1.3 and my sense is tha=
t they

>> are barely used. Any objections to just banning them? If not, I'll=
 merge this

>> PR end of next week.

>> 

>> -Ekr

> 

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/=
mailman/listinfo/tls







--_000_CO1PR07MB2837765F8C72641CD28058EC3C70CO1PR07MB283namprd_--


From nobody Thu Oct  6 17:55:43 2016
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 394F41294E2 for ; Thu,  6 Oct 2016 17:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 37XwFlEW1unr for ; Thu,  6 Oct 2016 17:55:40 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5438212947F for ; Thu,  6 Oct 2016 17:55:39 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id l13so2657852itl.1 for ; Thu, 06 Oct 2016 17:55:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S6YLLjNv+aOLEboEEOXgKw+5jrVFRF13dNLfL6iPgZ0=; b=aEw9+Y/FCP5GuT/TjBfoRQHHq/WdiMMOQQcgeMAJvDDTQHVJxrlVMMBrOgxSEu9uFN p09pYAOFw3dcD7IvIWrE16GzNV8Kitfyzm37IuuAJ1HiSm8/j4tRY6aPajaHvCG3zH9S O8Vu1X7NfmAWTGcPhbESOfwS7AlK0If08hrAPj+f7zxjxU4kkY+aNoWGP+xiJ18jbtxu HikKnYkluCiUH/8PoSChbfNcEN03WKpTSjVFUMGflkiA+TNvMHksHIt4EmGPS6WwtVn2 h29OWjVacDhpW3B/Zi7o5YOcMHLTSYGPc8V8SksCJ3WteLQPRz+kNWMG3LzXGl1D3kMj /6Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S6YLLjNv+aOLEboEEOXgKw+5jrVFRF13dNLfL6iPgZ0=; b=ABbXbhgdbQQ4NxwovlvW4xNmNRzFiqzjKWjtfpATAnksbWq5sBtaSxvJdUbDCSIyJA 9sNc2D0ea8Q4kBL8ozcywNHfRxjL4SMQIXEGubOnPjZOGA1DhB2+H+munssxmRAu2apP P7yPBiKfQfnhwuwhl0dOOMcavQMu8R1XmEV4FE+XmjAOD9WeCJHRybmhZOr/gQVAqmJE JEhBQR/KBl0RGc3odG35/zJLVus6CXVD3MOuY7wHNi0t6S57wti2q8qGdPBUkfrNudL5 wH6vZ8ZRR6RVHlGozai3MAfKF9m9FxcqZSEnvTZKqVjX77bfcBOORR2VbYy2xt3V/bU0 45vw==
X-Gm-Message-State: AA6/9RmhZL6rSsEsRdV4JtlPsskuQfWKACiTDmd6ZWGI9k8lUVmPJh8eG0ASqadLwuncTcqyiVrdhZdOYCdVBg==
X-Received: by 10.36.253.200 with SMTP id m191mr15489930ith.35.1475801739138;  Thu, 06 Oct 2016 17:55:39 -0700 (PDT)
MIME-Version: 1.0
References:   <20161005194028.GA26154@LK-Perkele-V2.elisa-laajakaista.fi>  <20161006064220.GA30076@LK-Perkele-V2.elisa-laajakaista.fi> 
In-Reply-To: 
From: Nick Sullivan 
Date: Fri, 07 Oct 2016 00:55:28 +0000
Message-ID: 
To: Martin Thomson , Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=94eb2c0361e26c32ce053e3bde98
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposed Change to Certificate message (#654)
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: Fri, 07 Oct 2016 00:55:42 -0000

--94eb2c0361e26c32ce053e3bde98
Content-Type: text/plain; charset=UTF-8

This seems resolved.

I'll update the text to reflect that per-chain extensions should be
included as extensions of the end-entity certificate. For RFC 7250
client/server_certificate_type values (such as X.509) that apply to the
entire chain should be extensions of the EE cert.

The client_certificate_type extension sent from the server in RFC 7250 can
go in either the encrypted extensions or the proposed CertificateRequest
extension field, but that has no bearing on this proposal.



On Thu, Oct 6, 2016 at 2:26 AM Martin Thomson 
wrote:

> On 6 October 2016 at 17:42, Ilari Liusvaara 
> wrote:
> > Perhaps also put server_certificate_type/client_certificate_type
> > there? That would eliminate the anomaly that one must know the
> > server certificate type before sending the certiifcate.
>
>
> Sounds like a perfect use for the CertificateRequest extension field,
> for the client certificate anyway.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c0361e26c32ce053e3bde98
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This seems resolved.

I'll update th=
e text to reflect that per-chain extensions should be included as extension=
s of the end-entity certificate. For RFC 7250 client/server_certificate_typ=
e values (such as X.509) that apply to the entire chain should be extension=
s of the EE cert.

The client_certificate_type exte=
nsion sent from the server in RFC 7250 can go in either the encrypted exten=
sions or the proposed=C2=A0CertificateRequest extension field, but that has=
 no bearing on this proposal.



=

On Thu, Oct 6, 2016 at 2:26 AM =
Martin Thomson <martin.thoms=
on@gmail.com> wrote:
On 6 Oc=
tober 2016 at 17:42, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:

> Perhaps also put server_certificate_type/client_certificate_type

> there? That would eliminate the anomaly that one must know the

> server certificate type before sending the certiifcate.





Sounds like a perfect use for the CertificateRequest extension field,

for the client certificate anyway.



_______________________________________________

TLS mailing list

TLS@i=
etf.org

https://www.ietf.org/mailman/listinfo/t=
ls




--94eb2c0361e26c32ce053e3bde98--


From nobody Fri Oct  7 00:48:40 2016
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 1820B129520 for ; Fri,  7 Oct 2016 00:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.291
X-Spam-Level: 
X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=ham autolearn_force=no
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 Zt1VgXaBXMgR for ; Fri,  7 Oct 2016 00:48:37 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7F1129508 for ; Fri,  7 Oct 2016 00:48:36 -0700 (PDT)
Received: from [192.168.91.133] ([80.92.121.244]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M34eJ-1azlVV1WgZ-00szgQ for ; Fri, 07 Oct 2016 09:48:34 +0200
To: "" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net>
Date: Fri, 7 Oct 2016 09:48:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="go1n95DXRtFOAjDB9ddS5P6n1PxoNtDLk"
X-Provags-ID: V03:K0:p6aY8Gw5aP+c97KQEXA7gyxi54uWDP0zWc9nVdlr4GsetSiepaa Ta5loyGD8AXY9JVsgZJJglS3vLOQ27x9WmmeIYeSar7onA480qVahTtKs3uQnM504zoLeAp j0EWuiiUW0DheA0U7xXwNQacbeQYygcSZ0cIvNXP39r7aczcGdY6Iz+BTQt4ew6PW+mZNeT QxT3yVpUuBEXOq+2BXwMw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:iqK8S9endmE=:nNUZrX8gR75JaxDFbJbhKe 0jJXsSo/KpCsdL0sYyW15YDD5Ikq6qf4E1eNDls9bIqI1VF92N+qSn8l9YO7YNfThwtdRJUiP cpScpc2OiSlszC5bbDkTyWQ/a+VIx5jL5G6eQ7LcslG1fEDYHDBWkb/jEjLAzw76It2+PsLXZ VI5U2RwJpfgQUq6ROlccR33Be4rtrUXc4WMzNPMzEoPADBisBVeYtCGv9Jkr11lg1lmJL0AjG PPxs2tjygmbi+ZjkUEqSzkrVdWSXXzop8hS8gTJf29214IpqkQ/1LZfXJgiykgPD3rQMQABnL jIQK2tuBhoFXBRYo6XUMoAx0j2jpid7UAzlULYE8ukci+pyPJKMfqpaFG5JG0Cn+PZ2cpyGAe SbzsWX/XIe2OqzG2UduW9vTK3hiW6pQ1JCTLL+bOfuzhhrHjUVDKIgMS16w9XtCx7sMr0Naxl k0ft+bKXEOJEcSyl6HzgEVL0x7eCfwdfoSr0hvE91tXN2kAdwW/kvmpFchnBsJ8IUlm082oTx EbAYQWipJ5tfzRzVcSDpaQ1dDsGVy7UV5tiAua4pyY2e6r/QCxprdEIkjJsTjAfHNnTa85qUv PY/mWiUgoJtL7vV2QjmlK+BE1kus/CLwluSjjf7lC0iwCpYDpgUBfq9yooPxPXxd5Z0nhb7iv Vta77yw0qKtIjY34IZtjN0WY2eniwWHQJvLKFuCPqYhye2+kVPV6hBqNdaVLMjb+8aFvcGjr7 RGFKpqQKd8E7gM+Wt9WwBR+m7+hUFUpTOkFYigiuf/6schr3tv05z7QKMN0=
Archived-At: 
Subject: [TLS] certificate_request_context
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: Fri, 07 Oct 2016 07:48:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--go1n95DXRtFOAjDB9ddS5P6n1PxoNtDLk
Content-Type: multipart/mixed; boundary="JBT88nmBIr0w9GoNjVFRM5OK2u2Lr0Gg6";
 protected-headers="v1"
From: Hannes Tschofenig 
To: "" 
Message-ID: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net>
Subject: certificate_request_context

--JBT88nmBIr0w9GoNjVFRM5OK2u2Lr0Gg6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

I am wondering why the certificate_request_context field found in the
CertificateRequest and in the Certificate message is so long. It is
supposed to be used to match a certificate request against incoming
certificate.

Does the field really need to be up to 256 bytes long? I think 8 bytes
should be more than enough.

I would also like to suggest to change the definition of
certificate_request_context:

Here is the current text since the last sentence feels misleading:

"
certificate_request_context

An opaque string which identifies the certificate request and which will
be echoed in the client=E2=80=99s Certificate message. The
certificate_request_context MUST be unique within the scope of this
connection (thus preventing replay of client CertificateVerify
messages). Within the handshake, this field MUST be empty.
"

"
certificate_request_context

An opaque string which identifies the certificate request and which will
be echoed in the client=E2=80=99s Certificate message. The
certificate_request_context MUST be unique within the scope of this
connection (thus preventing replay of client CertificateVerify
messages). This field SHALL be zero length unless used for
post-handshake authentication described in Section 4.5.2.
"


Ciao
Hannes


--JBT88nmBIr0w9GoNjVFRM5OK2u2Lr0Gg6--

--go1n95DXRtFOAjDB9ddS5P6n1PxoNtDLk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJX91NQAAoJEGhJURNOOiAtjewH/0fVLszhfW7RfpHSZe6JX+hc
iKerO3KRlMDCKnvCM6lPqlMmquyqEyc9gu7+yhU2ZBGhOU1ZP0mfnvhHI5Rc5qn8
bgccnnXAVWnRuEYovWju5mka/W+KN4CcznRx9pSMQ832mkNNojHPdDXQDTqca1In
oAYlcf0gXRERsNTs/HMF87dR0lKTOrqRA7lE3P3a1/hQ6QWB0QWBY7qx+4GC3BIQ
fPCKtj0FuVVBUg9o2jUlCGbc2jubSPP/fwUa647uEVJ/2dDJCAoauOwOvPZi9ASe
IC2Y7PZHfIS11/Kl6tFIdbZnQdkFzuYGiv6dXO5TpmYr+f7mnBlkC/GLagpnKrk=
=A9Uy
-----END PGP SIGNATURE-----

--go1n95DXRtFOAjDB9ddS5P6n1PxoNtDLk--


From nobody Fri Oct  7 01:34:28 2016
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 D9540129497 for ; Fri,  7 Oct 2016 01:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level: 
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
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 gxA8VKz6Qm7q for ; Fri,  7 Oct 2016 01:34:25 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id D4BE5129481 for ; Fri,  7 Oct 2016 01:34:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 9A44B12D20; Fri,  7 Oct 2016 11:34:22 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id IW0UmggEwNKh; Fri,  7 Oct 2016 11:34:22 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 41A7421C; Fri,  7 Oct 2016 11:34:22 +0300 (EEST)
Date: Fri, 7 Oct 2016 11:34:16 +0300
From: Ilari Liusvaara 
To: Hannes Tschofenig 
Message-ID: <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "" 
Subject: Re: [TLS] certificate_request_context
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: Fri, 07 Oct 2016 08:34:27 -0000

On Fri, Oct 07, 2016 at 09:48:32AM +0200, Hannes Tschofenig wrote:
> Hi all,
> 
> I am wondering why the certificate_request_context field found in the
> CertificateRequest and in the Certificate message is so long. It is
> supposed to be used to match a certificate request against incoming
> certificate.
> 
> Does the field really need to be up to 256 bytes long? I think 8 bytes
> should be more than enough.

I presume 255, but whatever...

If application supports any sort of multiplexing (e.g. HTTP/2), one
presumably wants the context to be non-opaque and identify the stream
that caused the request + some parameters about the request (to avoid
duplicating those in application layer).


-Ilari


From nobody Fri Oct  7 01:59:47 2016
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 E69EA129546 for ; Fri,  7 Oct 2016 01:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 n-ZPwgOTJ2F7 for ; Fri,  7 Oct 2016 01:59:44 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812DF129537 for ; Fri,  7 Oct 2016 01:59:44 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id f128so17992154qkb.1 for ; Fri, 07 Oct 2016 01:59:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7xY+IF8OOR7Cdz+Fvpz+4Zdnko9bmNjANu3JAAgeiUg=; b=pGTltb1lrz/6FGCrLcKQ0O76SXJTj0q8epBT8F4cvfEZKm4hTlMViQrid2aIyXRgl9 caE5qas/ybNhbDXcgYWULkl6DRU0vFRHNIdpaVrTbSFOzpmdblRmmQFDcHxx/8Uabids k/pewy+DmrLYVko9LyU0CTnawo3WJGHIGs3ny3JxjI/Ft4Zh1D78AqZcw8Fr7iuTITfA RKn4AD//Q04W0iHCqkt2crO7rD4jiskGgLqIFYM9E9xw45D+BhUn7CA01OPd3q9mjXBk 6aGIDIIFgL3rqmw2H918TgBNDW3+xynYVPxN0QNeOKyQQXJrBZ3i3u/ulrlkd0xRW425 onJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7xY+IF8OOR7Cdz+Fvpz+4Zdnko9bmNjANu3JAAgeiUg=; b=aRO0dgvReKA6NPX8Tvl/lDpnwY/fpuTl8tsXfQrBPeVeyAcWT0II223Le6MXBFqhYh HfqcH4oCFf+xFk470L2ZvwGS9sMRdh762T+gECyW0WO1f0/T6+kidKjGAdTTgtEZOsIe k9BA774206IYSuPbEOOAAjqhuz9VU0IdqhT/8F3jyng3UWiZojLN4wYNBy1JE26s6PpZ pmoIUczl7BRKf9AIUrD4MNMIlNEmtZgA/HdKIJBtEPU3bX9WdIJmttDkWpgiObNhYpeI fbxaTmMFQAz5x1tJ3cL8uCD77W4SbgU173vCSmqJrAvxv/jVgeP5iS9CuMiFy6RLIUup k/Tw==
X-Gm-Message-State: AA6/9RmbL4HCKMvIcKgiAvCVuNiE/OAmk2EfJ4X7/7QLOYnZsmnJ0Fb4OZ+rdxXrWv8IpFiwZB+wauWxybbfrw==
X-Received: by 10.55.165.16 with SMTP id o16mr18771366qke.5.1475830783703; Fri, 07 Oct 2016 01:59:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Fri, 7 Oct 2016 01:59:43 -0700 (PDT)
In-Reply-To: <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net> <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>
From: Martin Thomson 
Date: Fri, 7 Oct 2016 19:59:43 +1100
Message-ID: 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "" 
Subject: Re: [TLS] certificate_request_context
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: Fri, 07 Oct 2016 08:59:46 -0000

On 7 October 2016 at 19:34, Ilari Liusvaara  wrote:
> If application supports any sort of multiplexing (e.g. HTTP/2), one
> presumably wants the context to be non-opaque and identify the stream
> that caused the request + some parameters about the request (to avoid
> duplicating those in application layer).


It's opaque to TLS.  And 255 simply establishes the number of octets
in the length (1), if you don't need that much context (few will even
if they implement this), don't use the extra space.


From nobody Fri Oct  7 02:41:41 2016
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 06766129528 for ; Fri,  7 Oct 2016 02:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1ODrwRlhSnqV for ; Fri,  7 Oct 2016 02:41:38 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A2312944D for ; Fri,  7 Oct 2016 02:41:38 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id f193so3379068wmg.0 for ; Fri, 07 Oct 2016 02:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=GO6YDQ9OEupUP1Pt/ff7l7IghH3rOQExWudGVCzdKKg=; b=L1TYBs+rmg3PZLiDFh4aPN1mWFhKRrla21HsxWjEUx5XzT7mRehoxxVYs5aI+T5ETx rn2o0TDfczje4Kg4xu+HGaT+q02s6bBruD3omwWxvtyH574N8vrTFnk2JBn4wYkbHLsL XUWcg9tUHaJ0e0Z52okPkXbRknr/LLrJTLukJ71/ChUy4TLvZtRh9r1p9KoKbN78DaBd r92/pLMlTZ4L5KkJg/laH29jKPEM84fGyVMY8f0N9VOsJUZekfzvsGz+2NrkNF4WrSwJ YxjBuxPjJg3IOwztsZn8rNV+3cBDBiXcG6pu8XZb8nGD8NkX3DilOLAlCwSfOMrNMtXh AWqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=GO6YDQ9OEupUP1Pt/ff7l7IghH3rOQExWudGVCzdKKg=; b=XmtvLkcRnijGcZsQ+uhyg4kQ2k8I2hZ06eOjdiplIpccyOxWdcO+GlTwmhjfj6HQ9L xdEflozLGQKvpPadfcItjxpW1FB2e2fGBLHMIm1APr522EPT00w4PhGy7fDcoJO63F1T iSKzvqpxe+7h5P0g3okNcAwGBLbaQ+uW7sK0oHOP8QzGzCkfGW1M/CwbSr9D2YnA2w2R fG9FEt9u+50Lqaul5hJbxF0xkJFIUyxJBXeVk3czZR14PZIlx+5Fcpzu/Yb85VqONSVR +2WNVZE/HM9G7BABG4VIUvALShewalRxzKBhYGL/IOwW8L4e4V+Dixv+zvuaxN+G9chg aF8g==
X-Gm-Message-State: AA6/9Rm03O8SQ8IbZ5VxOkLLd9Fogy+0kRLCRBEQ+Js6/UJZ7yuz32H/toqbkbX0ydp2BoHld7M1B3hfNdHDLA==
X-Received: by 10.194.155.35 with SMTP id vt3mr1669354wjb.223.1475833296561; Fri, 07 Oct 2016 02:41:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Fri, 7 Oct 2016 02:41:35 -0700 (PDT)
From: Kazuho Oku 
Date: Fri, 7 Oct 2016 18:41:35 +0900
Message-ID: 
To: tls@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [TLS] HMAC context of ClientFinished in TLS 1.3
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: Fri, 07 Oct 2016 09:41:40 -0000

Hi,

Recently I have started writing a TLS 1.3 implementation. While
working on it, I have noticed the following.

In section 4.4.3, the hash value used for building the HMAC is defined
as: Hash(Handshake Context + Certificate* + CertificateVerify*).

For ServerFinished, this corresponds to the statement following the
formula that states, quote:

    the HMAC input can generally be implemented by a running hash,
i.e., just the handshake hash at this point.

since Handshake Context for 1-RTT server is (as defined in section
4.4): ClientHello =E2=80=A6 later of EncryptedExtensions/CertificateRequest=
.

However, for ClientFinished, the two descriptions do not match, since
Handshake Context for 1RTT client is: ClientHello =E2=80=A6 ServerFinished.

If we follow the way it is defined in the formula, then Certificate
and CertificateVerify needs to be applied to the hash after
ServerFinished, which is in discordance with the statement that it
could be implemented using a running hash.

Is this an error in the draft?

--=20
Kazuho Oku


From nobody Fri Oct  7 02:45:18 2016
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 29B03129528 for ; Fri,  7 Oct 2016 02:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.597
X-Spam-Level: 
X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 VUwezc-5TYKq for ; Fri,  7 Oct 2016 02:45:14 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF2E12944D for ; Fri,  7 Oct 2016 02:45:14 -0700 (PDT)
Received: from [192.168.91.133] ([80.92.121.244]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LkTSx-1bKkaj1Og7-00cSW4; Fri, 07 Oct 2016 11:45:10 +0200
To: Martin Thomson , Ilari Liusvaara 
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net> <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi> 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: 
Date: Fri, 7 Oct 2016 11:45:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HI7CRkNBWvUces3uvTpbC4VaE95Q4o4On"
X-Provags-ID: V03:K0:QkMLeCzoWxfu4Zp8DypevLKhTS9RwK5H+aoqf763p25nUlfDMjm vDDsC9fCTUt7LoJZv+QGxNeBpR7IwHNalTKvAKjodI+SW27+DuWKE5g3PLRuzhqEfnMvFIn 6qbg/pytWdn1mh04r2/MOiGMOE9RXeeq1PjhfNpuIAAyWc463Gm7YWQ2ge3gD2GDfh3X+xD qyQrucSJ+ALBjAPIkEG3Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:MwZw9gU81L8=:SYhGtQmsC9HkY5Y4oHrr/3 5o3KakJtXKMYfFD1KZ1qEnF8WDqMGospQMAUUdpWWoBWpaXu3ASKjx5HN9yCG3ethJQn2oPni YVxmPEs5uFpS80Z5hG5e6DMMUH4GqLpSzCZLW4tGZyzN9g+6jNP4JyGeG+sFYrDu4KS74JDmK oOKg1CFKu25pSoZSY25Ziztblk4Xvg6mUu2CwiMs5asug7f2a1uh64Tw/Wg/w2snWi6gWHS0R hirnm0OHy8brus1mRwj18TSs71/gaH5RjDeyV6IvERMFzI5lta8g68Gw59fHeL9SQ1WYmycRD npSsOxy0hMLZoCc3Sn5u1JYkJz+8iyihFjZNr2xyKaDnypHl7QLlgoIwdcUnhCtBT+e3yogZU r0nkCpn01vWJTizmCNyt6C61459AB5Xq1TeL0uCvyaQ8svjPOu7gl91sQu0A0pjO4FJfGTzxD fXBK6lB0KVMj2Dujuvly8zhYbkLM0za4N7Jwfcl0tJGkZq+l5EUjullRjdHQ0VnrkEJe9gQV1 HxcxGK1E4jyc5gFw92dNIwekvwfDrLJmx9emEEgw6SMf8+hG39vOIkMjXllE69M+q7+6jtZAD o4XNwzM7yP4TPLeKru4LhGeSTDVTj5Cer+BIWwQ0LhMBODYS7MlKIl7csZrKmwPb0T0UsPi6m s0LZcHkS7ctNExo5KD0L9W8Q9EPiMMkqE86hWPo/GeW0yy6LEqdSvRtMdPr5/5i89AGtoZXUw Es/iKAd74/lVsfqQ6S3ecQvzSyy1qTToj1gX8RQhVjbreqonc04jJNht1Q8=
Archived-At: 
Cc: "" 
Subject: Re: [TLS] certificate_request_context
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: Fri, 07 Oct 2016 09:45:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HI7CRkNBWvUces3uvTpbC4VaE95Q4o4On
Content-Type: multipart/mixed; boundary="Lb1dBIrjpb3SWKqRgqbBalMRIx48c6ceo";
 protected-headers="v1"
From: Hannes Tschofenig 
To: Martin Thomson ,
 Ilari Liusvaara 
Cc: "" 
Message-ID: 
Subject: Re: [TLS] certificate_request_context
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net>
 <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>
 
In-Reply-To: 

--Lb1dBIrjpb3SWKqRgqbBalMRIx48c6ceo
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Martin,

the problem is that with embedded implementations you need to be
prepared to receive this amount of data when the specification says so.


On 10/07/2016 10:59 AM, Martin Thomson wrote:
> On 7 October 2016 at 19:34, Ilari Liusvaara  =
wrote:
>> If application supports any sort of multiplexing (e.g. HTTP/2), one
>> presumably wants the context to be non-opaque and identify the stream
>> that caused the request + some parameters about the request (to avoid
>> duplicating those in application layer).
>=20
>=20
> It's opaque to TLS.  And 255 simply establishes the number of octets
> in the length (1), if you don't need that much context (few will even
> if they implement this), don't use the extra space.
>=20


--Lb1dBIrjpb3SWKqRgqbBalMRIx48c6ceo--

--HI7CRkNBWvUces3uvTpbC4VaE95Q4o4On
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJX926kAAoJEGhJURNOOiAt5GYH/AkFuJThf4aq4XJhOPmfa4yX
vKzZ1d6MJXJMyGdoqLMpNf+XDTzultJSOR6c/l5PLln5vp0tvZXI0pikXnDay6NF
uMjXbiuf7Wrd+KrHJl7cYQTa0b+dCjIS2qB3SKPaQ/rqKo4gVnbCbVAZ+oxK/hX3
HujlSN2A24ZMp2U1qO7zPitYuakgzdgHG2M+9XUbeluHenEcBG3ncCDuXEaEeVIm
ooHXL23ClpoCfHjOw84bKEBDNO01ar+Q8doI4JaCv/3ltevcbqLiHFkoYo825Gc3
w97t6NV3RuOXYA/ow5cKvZNlbUjPB0DAUDdafMpvxkXFQS4B/QA4Oa846nt4ies=
=HJL8
-----END PGP SIGNATURE-----

--HI7CRkNBWvUces3uvTpbC4VaE95Q4o4On--


From nobody Fri Oct  7 02:59:38 2016
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 83591129551 for ; Fri,  7 Oct 2016 02:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 I_ZbM38rpyCZ for ; Fri,  7 Oct 2016 02:59:35 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E586129548 for ; Fri,  7 Oct 2016 02:59:35 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id z190so26151678qkc.2 for ; Fri, 07 Oct 2016 02:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LDSiASnZZ044hrdlCxPMkcoduJ6tdkppjtVdSFs1DJc=; b=qd9AeLGv7c9j/vXl0Wl89Nil7cRL6iAozS4YogGwubbGbJLy6XNlRRyvmSQhCl9Fzy 8kcxtq161X1+6cjJFlZgAisLkirUQml874oJRiCTSCXzSUPeQORz1GMAbowEz28XN/55 ZdwYz2XoNgcV8PuxLNtU/vt9A7IgmTkaOpFOUw4+8NCEAS21bZnhxwsmnbAoJc7uehh+ fbBbZDr3qDSy8XGH8CKrBC29rfygwChPmiVtF/WxUAvSzpuvKCbgBulIezlrK96oiHzi gfObvPepBkbBI5gL7GJLO6chcbm0G6mM2pW1bOf7UHrgTaAbEHawB5Gaw8BtbbALNtE+ CRNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LDSiASnZZ044hrdlCxPMkcoduJ6tdkppjtVdSFs1DJc=; b=D/a3n4C15WwNOhvL/5HwGASrQ7QBZApemIVgJlDvBqT0pVbIdIN831zfoFYnBltxHO e5Q7jUJQNKfA4nzMLTcX/FKspiy7OVWQ+41BaSkP6kVdIToEBb1AyYGTEhdapj6DN6q8 VZacUOI+mSQuFtxTfBUvcRPGiFPKdYVjXYizzxFQXnsNzhRsAbrivwaMbgtSwrPKyXMo mgSuLyz+lzir0wTmO6CkF1MIplUomIwgAoPgi2oPtSl2WpoDljGsT4140dijqdLBGKsd 1pZcVRI2zq9ooHLdqvSfn/Yz65GTzIt7sPCko/OmXeA4tp4lVlDrHXp3jJN/yJIEv8rd hbOQ==
X-Gm-Message-State: AA6/9RmAFJozXOO1mV70ghjcqDr6gwdIx1vZ1Nn138F1USi1e1XiGaaTLqcB1qs6uJ91YnDztHN10ZGHlxmTlA==
X-Received: by 10.55.158.139 with SMTP id h133mr19917866qke.202.1475834374400;  Fri, 07 Oct 2016 02:59:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Fri, 7 Oct 2016 02:59:34 -0700 (PDT)
In-Reply-To: 
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net> <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>  
From: Martin Thomson 
Date: Fri, 7 Oct 2016 20:59:34 +1100
Message-ID: 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "" 
Subject: Re: [TLS] certificate_request_context
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: Fri, 07 Oct 2016 09:59:36 -0000

On 7 October 2016 at 20:45, Hannes Tschofenig  wrote:
> the problem is that with embedded implementations you need to be
> prepared to receive this amount of data when the specification says so.

How are you managing 65k session tickets, extensions, cipher suite
lists, supported group lists, etc...?


From nobody Fri Oct  7 03:14:48 2016
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 C5C6D129552 for ; Fri,  7 Oct 2016 03:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level: 
X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
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 tpgMTcs14sbB for ; Fri,  7 Oct 2016 03:14:44 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4B11294B1 for ; Fri,  7 Oct 2016 03:14:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7739E16871; Fri,  7 Oct 2016 13:14:42 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id P0dNtGVaC-pp; Fri,  7 Oct 2016 13:14:42 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1ABB421C; Fri,  7 Oct 2016 13:14:42 +0300 (EEST)
Date: Fri, 7 Oct 2016 13:14:36 +0300
From: Ilari Liusvaara 
To: Kazuho Oku 
Message-ID: <20161007101436.GA8774@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] HMAC context of ClientFinished in TLS 1.3
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: Fri, 07 Oct 2016 10:14:47 -0000

On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote:
> Hi,
> 
> Recently I have started writing a TLS 1.3 implementation. While
> working on it, I have noticed the following.
> 
> In section 4.4.3, the hash value used for building the HMAC is defined
> as: Hash(Handshake Context + Certificate* + CertificateVerify*).
> 
> For ServerFinished, this corresponds to the statement following the
> formula that states, quote:
> 
>     the HMAC input can generally be implemented by a running hash,
> i.e., just the handshake hash at this point.
> 
> since Handshake Context for 1-RTT server is (as defined in section
> 4.4): ClientHello … later of EncryptedExtensions/CertificateRequest.
> 
> However, for ClientFinished, the two descriptions do not match, since
> Handshake Context for 1RTT client is: ClientHello … ServerFinished.
> 
> If we follow the way it is defined in the formula, then Certificate
> and CertificateVerify needs to be applied to the hash after
> ServerFinished, which is in discordance with the statement that it
> could be implemented using a running hash.

Nope, it is a running hash:

The server Finished includes the following messages, in this order:

- ClientHello
- HelloRetryRequest (if sent)
- Clienthello (another, if HRR was sent)
- ServerHello
- EncryptedExtensions
- CertificateRequest (if sent)
- Certificate (server's)
- CertificateVerify (server's)

And this exactly corresponds to the send/receive order.


The client finished includes, in this order:

- ClientHello
- HelloRetryRequest (if sent)
- Clienthello (another, if HRR was sent)
- ServerHello
- EncryptedExtensions
- CertificateRequest (if sent)
- Certificate (server's)
- CertificateVerify (server's)
- Finished (server's)
- Certificate (client's, if CR was sent).
- CertificateVerify (client's, if non-empty client cert was sent)

And this exactly corresponds to the send/receive order.


One place to be careful of is client application keys: The hash used
for those is taken immediately after ServerFinished, but the keys are
only commissioned after ClientFinished (whereas server keys have the
hash taken in the same time as those are commissioned in).



-Ilari


From nobody Fri Oct  7 03:30:44 2016
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 0F64F129480 for ; Fri,  7 Oct 2016 03:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.597
X-Spam-Level: 
X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 UA581mGCEWQG for ; Fri,  7 Oct 2016 03:30:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E66D1294B1 for ; Fri,  7 Oct 2016 03:30:40 -0700 (PDT)
Received: from [192.168.91.133] ([80.92.121.244]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lg0sd-1b7Vxu0Qx9-00pb7P; Fri, 07 Oct 2016 12:30:37 +0200
To: Martin Thomson 
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net> <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>   
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <68427910-70db-5545-5500-2d86517f667a@gmx.net>
Date: Fri, 7 Oct 2016 12:30:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jBNIOSdi1NVVHVjBlifnq9WiwAorDR7JR"
X-Provags-ID: V03:K0:4B0f6f74MWunhZOazFV53bhgIAeGAn6/eZAUCUmBXo/peTXMfPI 8iDGopMTJc8xWW03UyoJtCgDEFkMwuGl3C8+MX76J2vUqmO4CJG14Bl+Arg0yImgmkMQCwy kPPkeTp+NfavJcyY5MyIj2uxZ7whfvOniFke6PCNkQ0PIcAa9Wz/afj5+wKT73/lnvFCY+X KyJezzWYxS9eW4asjwM5Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:QNhfLNO6Yms=:B6KKzzNOK77C/+htvnID2e T3Xq9WJEDwgwbjtzs+b4S7ctOpVIBy+HxU/WwBLtyHYgttYT625Uw3r1FoLMl2rLAHSmK/92e zTBziyJA4+JKgPQ+OZR/ISnt1C4+4hVGSuylioD2JLluWxgyQ1MDYyLs70lKjtbfUknx2uJqd dl+DGX10dAnH7CxfYxE5n0MzwdvCnbkunXH2jYkyr5St30325e3cGxSCkM6cJbzTO4YOwh9x8 +xQHuW4yOFLWI04zWiVMKaJD1LkValDGIHoPGFbb7cvdCzsi7h6d4OVgij9P1qBWd3s2e8gQb LdpJXGnlqDUj6fwAFkXZMOnw5+HE7QMf9q8yHei1xjtI/UwWa0M/ZJvTKjlwv0OKiDs4fut1x EBYWz19kCqJFSDS7Xv9d0R1ycjUpIKe05funvCo5AF+Amd9q0dF+iwlxWbByF3TcTT1J4a0BY BS07QrypZh1oRvuDBpizbYnKE/75EXAPLl1gmlo7dg0Xz9ISruXziGAoUWdpvJrCfRYJ8znBD OjUk3WlicYrOUnNu38QNguZxVfkfLg9vpxQS+s335QFTg2U/szRXWl0EKiowTpyCSTEAaNOjz QqZOhT/4NnHa9035RxSO7hZbGFGA4H3ilBwxINbV8R0/DF8s6y0X8Vz1eUDQdznti/m/DoZoZ yHE7yjpp779usnC9a6DieQdbRY2ZH8h57kw/xm92ruwaPYqlD7Z19lf5HaYyN56L/Fvabl5EP 3EbduBqK00e5kegq4eqZhijcgsaMmcNUliRKZUwWRT1tjl+3H4qMI8rKLao=
Archived-At: 
Cc: "" 
Subject: Re: [TLS] certificate_request_context
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: Fri, 07 Oct 2016 10:30:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--jBNIOSdi1NVVHVjBlifnq9WiwAorDR7JR
Content-Type: multipart/mixed; boundary="gJVQjIiePwnGoQeWMN9U3LBLQp5eX4X99";
 protected-headers="v1"
From: Hannes Tschofenig 
To: Martin Thomson 
Cc: Ilari Liusvaara , ""
 
Message-ID: <68427910-70db-5545-5500-2d86517f667a@gmx.net>
Subject: Re: [TLS] certificate_request_context
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net>
 <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>
 
 
 
In-Reply-To: 

--gJVQjIiePwnGoQeWMN9U3LBLQp5eX4X99
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Martin,

this may be an implementation specific issue but some of the parameters
I have to keep in memory while others I "only" have to parse. In some
cases the embedded implementation also has control over the number of
parameters being included in a message (which is useful for bandwidth
reasons as well).

Ideally, I would prefer to have the length of a field somehow relate to
the content.

Going through all the parameters and re-evaluating whether the size is
indeed appropriate might be a good idea.

Ciao
Hannes

PS: For the reason that embedded devices don't have an endless amount of
RAM the max_fragment_length extension was introduced and in
https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00
we suggest to also apply this concepts to lightweight TLS server
implementations.

On 10/07/2016 11:59 AM, Martin Thomson wrote:
> On 7 October 2016 at 20:45, Hannes Tschofenig  wrote:
>> the problem is that with embedded implementations you need to be
>> prepared to receive this amount of data when the specification says so=
=2E
>=20
> How are you managing 65k session tickets, extensions, cipher suite
> lists, supported group lists, etc...?
>=20


--gJVQjIiePwnGoQeWMN9U3LBLQp5eX4X99--

--jBNIOSdi1NVVHVjBlifnq9WiwAorDR7JR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJX93lLAAoJEGhJURNOOiAtNgwH/jMQsCMOU7xGX1fETWqFJLkX
xmUY0XmVVgZak/CQZ00zb7g5xFRA6FO0FMHfjocixkOUT8hOpnaE//rpc0owqzgG
wTMa2a+cloCEuTqBWES5JNha4s0GRUC0ADL3cGbDBxkYm8pcYATsuQn+7T1BLdqr
wcO2CdiZvD38l4UfB2krx8VAb+OqWj2XHnkC5Bd5Ek/2XDri0eG3lz/WaiZK0AdG
mOBb5u1eCpo6Ljg2ghdIa9YQMUjjDl/qUfi9w769Qdwkb5tI3TvoEt3C0E2zPKQB
tycwL/m0MKLd2scAJKxeoGwtmDbMaKDOU4WnlmMj/7Ivim5xa/byNUwvAPDv+Bo=
=XMU2
-----END PGP SIGNATURE-----

--jBNIOSdi1NVVHVjBlifnq9WiwAorDR7JR--


From nobody Fri Oct  7 04:04:01 2016
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5054129552 for ; Fri,  7 Oct 2016 04:03:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147583823980.8922.16371060969705220828.idtracker@ietfa.amsl.com>
Date: Fri, 07 Oct 2016 04:03:59 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [TLS] Milestones changed for tls WG
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 07 Oct 2016 11:04:00 -0000

Changed milestone "Move ECC-based CS to Standards Track", set state to
active from review, accepting new milestone.

Changed milestone "DANE Record and DNSSEC Authentication Chain
Extension for TLS to IESG", set state to active from review, accepting
new milestone.

Changed milestone "DTLS1.3 to IESG", set state to active from review,
accepting new milestone.

URL: https://datatracker.ietf.org/wg/tls/charter/


From nobody Fri Oct  7 04:51:51 2016
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 9A50B12950A for ; Fri,  7 Oct 2016 04:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PB-1tZosZMcL for ; Fri,  7 Oct 2016 04:51:48 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5D5129481 for ; Fri,  7 Oct 2016 04:51:48 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id z190so28121843qkc.2 for ; Fri, 07 Oct 2016 04:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yYdKvY2Kqgl6t+CGo6aeoeqtGXZy7QP7oLDxWxwL3zI=; b=E2c0rmhvZj0YYCPpA4pTgM+QFeT7m9+e4C9PInV/M5M43TL7PgWp3X/6QcX8dcQQfy rZCGVjebvSisgHnjWdzLO4U0RSWZFZwXaoOaSbOckmII07VxMJVq5rwttVZ92XHv/MwO 28ctvBa8yCYTqjNgtT1PG5s6x8RRvfPwW/c76IZqBdlL7W2Te7tznBp1glv34tegwfGy 80gd9uZg30FW4vb6XPQbuMAmXjDuzh+rg/YM5S+d3l9kfRD08GLVsRN9rZyw09e8cRgc bppwT8sA4DARCkjEQAguXhoZ9KRWJKoZESyUJK58Af86VWaLI9Wr5eLFQ1UdNSY0s+QA lErw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yYdKvY2Kqgl6t+CGo6aeoeqtGXZy7QP7oLDxWxwL3zI=; b=kyN3isEZ33R6ait5S0+DJujMFmeeT9d8ksWbsogwHB41otQoS8pRo/Xj5A6tBMrdQf hDjmIuREahvsdXa/aXARbeOnyZkT0gPN6nnAsh0sQL/z91Fle1EA6mErr7znMX5Lf6EF C4oU07rY3KvQD0ppLfcft8AGPVRfGn2qxad4jif5u1XMlqjhKmLwyrUDFrlGLyQ0hpee 82zoEa/Pmo6yZD8GGWE/RZryp+S3nXrVLQZX69WzWVcpJ76gKysrellS2FpmN/Ld3gLu 8Fb7Xx2y/W5unPLVFC+u+EcW9WOhslVW5sEAzrY5GMqNbDbhegnrzMWyI19OD7+8fsQ7 Zbqw==
X-Gm-Message-State: AA6/9RmMkotOKwPEoej151hKTbXjXve5X2o5OmRDCxbJbgV41/6mFwakELtwLQOWmSncOIBjca2ycX1HWLDO/Q==
X-Received: by 10.55.71.3 with SMTP id u3mr14052063qka.144.1475841107223; Fri, 07 Oct 2016 04:51:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Fri, 7 Oct 2016 04:51:46 -0700 (PDT)
In-Reply-To: <68427910-70db-5545-5500-2d86517f667a@gmx.net>
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net> <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>    <68427910-70db-5545-5500-2d86517f667a@gmx.net>
From: Martin Thomson 
Date: Fri, 7 Oct 2016 22:51:46 +1100
Message-ID: 
To: Hannes Tschofenig 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "" 
Subject: Re: [TLS] certificate_request_context
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: Fri, 07 Oct 2016 11:51:49 -0000

I don't think it would be sensible to set an upper limit in this case
(those lead to regrets in my experience), however, recommending that
the value be kept as small as possible seems OK.  It's probably
redundant advice though.

Since this is extremely transitory state, I sort-of assumed that it
would be OK. And it's zero-length during the handshake.  Were you
planning on having super-constrained devices with post-handshake auth
support?

On 7 October 2016 at 21:30, Hannes Tschofenig  wrote:
> Hi Martin,
>
> this may be an implementation specific issue but some of the parameters
> I have to keep in memory while others I "only" have to parse. In some
> cases the embedded implementation also has control over the number of
> parameters being included in a message (which is useful for bandwidth
> reasons as well).
>
> Ideally, I would prefer to have the length of a field somehow relate to
> the content.
>
> Going through all the parameters and re-evaluating whether the size is
> indeed appropriate might be a good idea.
>
> Ciao
> Hannes
>
> PS: For the reason that embedded devices don't have an endless amount of
> RAM the max_fragment_length extension was introduced and in
> https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00
> we suggest to also apply this concepts to lightweight TLS server
> implementations.
>
> On 10/07/2016 11:59 AM, Martin Thomson wrote:
>> On 7 October 2016 at 20:45, Hannes Tschofenig  wrote:
>>> the problem is that with embedded implementations you need to be
>>> prepared to receive this amount of data when the specification says so.
>>
>> How are you managing 65k session tickets, extensions, cipher suite
>> lists, supported group lists, etc...?
>>
>


From nobody Fri Oct  7 04:56:38 2016
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 97E07129537 for ; Fri,  7 Oct 2016 04:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8ZvNCaEsb2vz for ; Fri,  7 Oct 2016 04:56:34 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EB0129510 for ; Fri,  7 Oct 2016 04:56:34 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id 128so3988135pfz.2 for ; Fri, 07 Oct 2016 04:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lCgtFdNNlmLW9O/pO1To6BeWOepelb2Ho/4rOqtujtc=; b=xgIYXriVjAJCcMqkWYmlrCyJL5vGWLt9bpc+M32J5lmA1I4gy6LJiRqeWISYC2LIAC 5I/bKlWR/6xRiuNRAmekCZZx8OPtL0sK9k+JWCxXZnptWofslwjegkVx42lbEdAMJ6tf n7CP+PLOSpkqVwloyraTIT+RG4sg9bZHtaoJdonpPxg0dg1O61iRLUsG3JfSnFfRtEq1 GFrQYM93hlcfX0uGJFVWNbj9uSnxioCAtqW4srLin6MkIYNvyIrVv42q/wM3U48io07o r2ZRztIAbZWSC9ButljvZsvJ5xNa9XiJpwmyeY8EY4WT6jCKJaoxXYdA0wAGEmlyH9s3 BqkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lCgtFdNNlmLW9O/pO1To6BeWOepelb2Ho/4rOqtujtc=; b=Be0CTEVQ9jJQQ/6hPNn/HmPh0Rb5OLS3zHu/+eqBEiSawZ8ybZQhSo4PXUh96B59+D fEyvqob+sQuMQYzWCKI3ySAOl54flfk/GAKhHownD6rpQUZ3hCEnwz74b66lit9i+AkZ LOJ8SGnt4gylIMTJyoh+YMtiD2hT+ZLYJlTrpM/XFg463lsFxlHSACfLFtrHo6rBjCER T2PMWknBxs4wktCIben1Qjsl8NMVm2LNDCDy4qeHP22Px3NONBdGPgyNQZ+nIWh4er8c RlnAdrD4n+t0grksdxLKqHDWtSVbfn7/gCpir7i1F2qL4m/ZlkcxYKFJ4lMcWyGpqm1q 1mgA==
X-Gm-Message-State: AA6/9RkWAm9WRh15yLCXKB0/t6hJrCcEQvdEs7EVZsB3OM1uSXXOsSr1swrpI7/ybTUmhA==
X-Received: by 10.98.34.212 with SMTP id p81mr35963471pfj.18.1475841393594; Fri, 07 Oct 2016 04:56:33 -0700 (PDT)
Received: from [192.168.0.4] (p1679242-ipngn15801marunouchi.tokyo.ocn.ne.jp. [153.204.204.242]) by smtp.gmail.com with ESMTPSA id b197sm13465194pfb.52.2016.10.07.04.56.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Oct 2016 04:56:32 -0700 (PDT)
From: Kazuho Oku 
X-Google-Original-From: Kazuho Oku 
Content-Type: text/plain; charset=iso-2022-jp
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (13G36)
In-Reply-To: <20161007101436.GA8774@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Fri, 7 Oct 2016 20:56:29 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <14A4B8BA-31FC-4C2A-BC6D-3C0F6F1A5FDD@gmail.com>
References:  <20161007101436.GA8774@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara 
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] HMAC context of ClientFinished in TLS 1.3
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: Fri, 07 Oct 2016 11:56:35 -0000

Hi,

Thank you very much for the clarification and the advise.

I had indeed forgotten to consider the client certificate and its verify mes=
sage.

iPhone=1B$B$+$iAw?.=1B(B

2016/10/07 19:14=1B$B!"=1B(BIlari Liusvaara  =1B$B=
$N%a%C%;!<%8=1B(B:

>> On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote:
>> Hi,
>>=20
>> Recently I have started writing a TLS 1.3 implementation. While
>> working on it, I have noticed the following.
>>=20
>> In section 4.4.3, the hash value used for building the HMAC is defined
>> as: Hash(Handshake Context + Certificate* + CertificateVerify*).
>>=20
>> For ServerFinished, this corresponds to the statement following the
>> formula that states, quote:
>>=20
>>    the HMAC input can generally be implemented by a running hash,
>> i.e., just the handshake hash at this point.
>>=20
>> since Handshake Context for 1-RTT server is (as defined in section
>> 4.4): ClientHello =1B$B!D=1B(B later of EncryptedExtensions/CertificateRe=
quest.
>>=20
>> However, for ClientFinished, the two descriptions do not match, since
>> Handshake Context for 1RTT client is: ClientHello =1B$B!D=1B(B ServerFini=
shed.
>>=20
>> If we follow the way it is defined in the formula, then Certificate
>> and CertificateVerify needs to be applied to the hash after
>> ServerFinished, which is in discordance with the statement that it
>> could be implemented using a running hash.
>=20
> Nope, it is a running hash:
>=20
> The server Finished includes the following messages, in this order:
>=20
> - ClientHello
> - HelloRetryRequest (if sent)
> - Clienthello (another, if HRR was sent)
> - ServerHello
> - EncryptedExtensions
> - CertificateRequest (if sent)
> - Certificate (server's)
> - CertificateVerify (server's)
>=20
> And this exactly corresponds to the send/receive order.
>=20
>=20
> The client finished includes, in this order:
>=20
> - ClientHello
> - HelloRetryRequest (if sent)
> - Clienthello (another, if HRR was sent)
> - ServerHello
> - EncryptedExtensions
> - CertificateRequest (if sent)
> - Certificate (server's)
> - CertificateVerify (server's)
> - Finished (server's)
> - Certificate (client's, if CR was sent).
> - CertificateVerify (client's, if non-empty client cert was sent)
>=20
> And this exactly corresponds to the send/receive order.
>=20
>=20
> One place to be careful of is client application keys: The hash used
> for those is taken immediately after ServerFinished, but the keys are
> only commissioned after ClientFinished (whereas server keys have the
> hash taken in the same time as those are commissioned in).
>=20
>=20
>=20
> -Ilari


From nobody Fri Oct  7 05:26:16 2016
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 7746F129581 for ; Fri,  7 Oct 2016 05:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.597
X-Spam-Level: 
X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 77RBt7mw-qH6 for ; Fri,  7 Oct 2016 05:26:12 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60CC129579 for ; Fri,  7 Oct 2016 05:26:11 -0700 (PDT)
Received: from [192.168.91.133] ([80.92.121.244]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MOf5S-1bmPxO0h1i-0069mR; Fri, 07 Oct 2016 14:26:08 +0200
To: Martin Thomson 
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net> <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>    <68427910-70db-5545-5500-2d86517f667a@gmx.net> 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: 
Date: Fri, 7 Oct 2016 14:26:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tCkUEoUEngbTdsVrrvPJWdA7QbMTQTSc6"
X-Provags-ID: V03:K0:uyGYQsRtH/40Tn2wrDsMvGMiAR7/yuoh+yjzilGJ+eGs8rSxz7S lVrIdE/a4nc9kdqeNZikClyT5ssf4c1VYB4DejhA0pxRfG4XvnD25dXhkNNpKXHg4b1U3rR 2LPsQIb9ZglBvwYbtCC9yeGWG/S0oLT0J6iJY55KCa3ymMnINLqDClh0stUeQw+2IZC1Dkg ioYb8dcozyF8TDhqZ3a0g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:dv4FVbLEMwc=:LMs8TEksbxxEaQVUO9j0/i yzkXwZd7SYtB5yKNmmMFl9QQySrHKTTCK2JMxh5gBs6pOqy+vYfOFK1QLNUj70jc4angiVHQy EQdJDQepniaMCKdJ4LdRqwyr/ZHsKYY5UqEwb3QULvLfqP+kcW9jDjyOpnYcj7Vfzq03H65wF CPsK20p2f3YsFVDP10VeIHqDXD90kB3CygHN5KkZe/4Uj+rcs2B+ib857CKKtyF5mLyqpJsPe 6GBbd9ZFIzXwtCdSzPZi7mXMaMlgKHo/QavqLajszBE6Q73PMFCfs0tv08cwTOp4ml4AZb2Pf 4w/g7u4u+Aauig9oJbuPknhmO5IDd+F60dbD5kg0s73u2F7P1l+TD9Mo8/SJzEeC4y9pOUHh1 QkZp0EQrY5lCVufTFalui+WOdeBEU7elfvMVKRtNc2WmuYu8elSVn9KWQK1u599wy4tEjeqjL ERzh+3SSe6zi9tfCHnmt8SqV+kzJ7zTmdxFaO9TfjUwHN12hOmcwtcLHWfTC3pZGcRtcCYB67 GWk2UQ1F6DiwEfLC31eU71xX8WGR/ABzG/vklkmw40IpS0dQDn+ceuMeHBb0tZw5ilGL0/jOy L2EFc5Nc//9/wZ4aht/tfsroTqiQ3ixqp0ipRgsaaB1Iolo58IZvpuC3otgVgbZ0h95VsuIOy wdsCxlGts940y086CfTJsAaxkdiBxDh8pja7AtOtzzdbhMbCVjsh8TAsa0mhQpCgpV6cTaF0E 5cqpDMgY792sY55FKCKQ04eOp04aTcFnxLFFxpmQgtSEZHqpUm8VntfeM7o=
Archived-At: 
Cc: "" 
Subject: Re: [TLS] certificate_request_context
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: Fri, 07 Oct 2016 12:26:14 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--tCkUEoUEngbTdsVrrvPJWdA7QbMTQTSc6
Content-Type: multipart/mixed; boundary="RX0ftMh8LAj0188HQMDgVPrv0mCv2rjC9";
 protected-headers="v1"
From: Hannes Tschofenig 
To: Martin Thomson 
Cc: Ilari Liusvaara , ""
 
Message-ID: 
Subject: Re: [TLS] certificate_request_context
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net>
 <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi>
 
 
 
 <68427910-70db-5545-5500-2d86517f667a@gmx.net>
 
In-Reply-To: 

--RX0ftMh8LAj0188HQMDgVPrv0mCv2rjC9
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Martin,

post-handshake authentication is indeed probably something that is less
likely to happen in the embedded environment and I will check whether
there are some use cases that require it.

If it isn't required then the best possible alternative at the moment is
for an embedded client implementation to immediately return a
Certificate message containing no certificates followed by Finished.

Thanks for your thoughts on this topic!

Ciao
Hannes

On 10/07/2016 01:51 PM, Martin Thomson wrote:
> I don't think it would be sensible to set an upper limit in this case
> (those lead to regrets in my experience), however, recommending that
> the value be kept as small as possible seems OK.  It's probably
> redundant advice though.
>=20
> Since this is extremely transitory state, I sort-of assumed that it
> would be OK. And it's zero-length during the handshake.  Were you
> planning on having super-constrained devices with post-handshake auth
> support?
>=20
> On 7 October 2016 at 21:30, Hannes Tschofenig  wrote:
>> Hi Martin,
>>
>> this may be an implementation specific issue but some of the parameter=
s
>> I have to keep in memory while others I "only" have to parse. In some
>> cases the embedded implementation also has control over the number of
>> parameters being included in a message (which is useful for bandwidth
>> reasons as well).
>>
>> Ideally, I would prefer to have the length of a field somehow relate t=
o
>> the content.
>>
>> Going through all the parameters and re-evaluating whether the size is=

>> indeed appropriate might be a good idea.
>>
>> Ciao
>> Hannes
>>
>> PS: For the reason that embedded devices don't have an endless amount =
of
>> RAM the max_fragment_length extension was introduced and in
>> https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00
>> we suggest to also apply this concepts to lightweight TLS server
>> implementations.
>>
>> On 10/07/2016 11:59 AM, Martin Thomson wrote:
>>> On 7 October 2016 at 20:45, Hannes Tschofenig  wrote:
>>>> the problem is that with embedded implementations you need to be
>>>> prepared to receive this amount of data when the specification says =
so.
>>>
>>> How are you managing 65k session tickets, extensions, cipher suite
>>> lists, supported group lists, etc...?
>>>
>>


--RX0ftMh8LAj0188HQMDgVPrv0mCv2rjC9--

--tCkUEoUEngbTdsVrrvPJWdA7QbMTQTSc6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJX95ReAAoJEGhJURNOOiAtkSAH/1CabAiR0ku0DdBYKkR+57/E
j56aLtlP9ili6A58Cz2k3mtc3MuEiQs3qBuXzAvS6hVxPhpoppg06L7HC7VDea9G
vWAFSMt0PezNarsWCvSlSWAfMOE+LXcxzXh4Dh0ShqT+vnnfqEUfcsUNrsFbgOGm
MPHYqhIkmfRkqrftGk8HRSqMF6y5qlMW4gNXcXPyQLWhPAwAdpAuY1hfRoVKoWzG
yA1SZ4X6TXtA7P9RiUFtfy9utLGuYoI5/ATMtlgIRqPyDiIPxxgBdDAJYKmX6o9p
unbF7spsNRlmdbrbo5g0wg7l8T5QT4gC2y1+gvlkk4UEabUWWjN5en14IxgCmWc=
=uZFC
-----END PGP SIGNATURE-----

--tCkUEoUEngbTdsVrrvPJWdA7QbMTQTSc6--


From nobody Fri Oct  7 08:02:29 2016
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 397FB1295F0 for ; Fri,  7 Oct 2016 08:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 fBnLwkUT8kHW for ; Fri,  7 Oct 2016 08:02:25 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928E5129426 for ; Fri,  7 Oct 2016 08:02:25 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id e2so17129460ybi.1 for ; Fri, 07 Oct 2016 08:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=S6my0EkbGT5Eby0qeZtjQ4FDBwNq/JnlJGn3RlukSGA=; b=oyTxActuAARLQ/jnFl0yzzvepLKNyTdLMFZWxvX3bUzQebahqWgh3mwR0Jd8JFIBna YdZ5hru3kach/AacHyE8ai7ul9CTxPzm+ig3anh+6BmWHQyh8z5oMFdBKdm//29ba06G hSxSuk5gvZXJmeoIYqgaD2LAaplWppsE5UT/mISZ9cjDIMiasPv7ypwF6sgym7QK2RK1 Rw6n775TVsMpLbzIenKHolCZYQTDM12wxbek8p51P3ceOqJtWQeA9c4m6T9zKglC45rR ZbXcyWC+vonRawteRMUoZLX3w+v0AnPrRAy75CP1hJqsbiRNwGp3EHKkgb1umeRkVZ0b 4jNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=S6my0EkbGT5Eby0qeZtjQ4FDBwNq/JnlJGn3RlukSGA=; b=PONH/TXg6ml3w/1hzBiKqB1/GJtm7gy5eIr5O/bQ05q3Eze7b8S2QioVwb9271rIQU 5WrS1jSOr0uY7yzLvk3ZEJlcZP8vKSmqbVGd08J3H9eupR8D3RlaweCYG4olmo8ecWL6 Pr+hHcc4YintWUfW81pawjn1MoWVX13+J9Rk37SXOjPhYpxtFXE96Ev2y6ArX99QCV7i q5DXFiwtCwhiyVuf4ME7cB0XD7t3239y7sgYVpkiYrFam1HgyDeOw3DefyfanQoxea+K +ggTRMdRI77uzpKpKt4I+PEKG6GNfbeOueSahwxS0tUIo4RLJiYBILj+oKaGOlAQjxUQ kJ8A==
X-Gm-Message-State: AA6/9RlMk0fqdQimuiEMXeFzszZpUg/AhS9fAkBoacZ9/6yX5R0VKIp0oMtVBJ+cy0pRNITMm8bjkab+yCSMpQ==
X-Received: by 10.37.174.11 with SMTP id a11mr4221283ybj.180.1475852544541; Fri, 07 Oct 2016 08:02:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.212 with HTTP; Fri, 7 Oct 2016 08:01:43 -0700 (PDT)
From: Eric Rescorla 
Date: Fri, 7 Oct 2016 08:01:43 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=f403045db83ea8d580053e47b211
Archived-At: 
Subject: [TLS] Finished stuffing/PSK Binders
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: Fri, 07 Oct 2016 15:02:28 -0000

--f403045db83ea8d580053e47b211
Content-Type: text/plain; charset=UTF-8

After the discussion on PR #615, I took another pass at this with some
help from the research community. Please see:

   https://github.com/tlswg/tls13-spec/pull/672


Key changes in this PR:

1. I have merged the HMAC into the PreSharedKey message, where it is
now called "PSK Binder" to make very clear what the purpose of the
HMAC it is (this suggestion due to Karthik Bhargavan) This also makes
implementation somewhat easier and avoids creating another extension.

2. It is now possible to have >1 PSK, each with its own binder.

3. The binder is now computed over the ClientHello prefix rather than
filling the MAC with zeroes.

4. I've taken a suggestion from David Benjamin to move the negotiation
of the PSK key exchange parameters out of the PSK itself and into a
separate message. This cleans things up and also lets us drop the
currently non-useful auth_mode parameter.

This text is still a bit rough but I think shows the right direction.

As usual, comments welcome, but I think the key question we need
to resolve is whether we really need multiple PSKs. It's clearly
simpler not to support them but it seems like we need to worry about
the case where we are resuming a session created with a PSK. I've come
to the conclusion that if we want to have multiple concurrent PSKs at
all, then this is the right structure, rather than having one PSK and
using HRR to fix it.

ISTM that the other major alternatives are to say:

1. You can't resume sessions created with a PSK.
2. Tickets created in sessions created with a PSK have a hard lifetime
   value and it's a failure if the server forgets during the lifetime
   (this seems like it's going to interact badly with clock skew).

Note that if we decide that we only want one PSK, I'll just revise the
PreSharedKey section to have one, not a list [0].

Thanks,
-Ekr

[0] In fairness, it's also worth noting that if we decide to only
have one, it's possible in the future to replace the PreSharedKey
extension with a MultiplePreSharedKey extension.

--f403045db83ea8d580053e47b211
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable