From nobody Thu Oct 1 09:27:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245F81A900B for ; Tue, 29 Sep 2015 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhL5mXFhGGEW for ; Tue, 29 Sep 2015 08:13:16 -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 9751E1A8AF4 for ; Tue, 29 Sep 2015 08:13:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYE11950; Tue, 29 Sep 2015 15:13:13 +0000 (GMT) Received: from SZXEMI401-HUB.china.huawei.com (10.82.75.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 29 Sep 2015 16:13:12 +0100 Received: from SZXEMI501-MBX.china.huawei.com ([169.254.1.73]) by SZXEMI401-HUB.china.huawei.com ([10.82.75.33]) with mapi id 14.03.0235.001; Tue, 29 Sep 2015 23:13:00 +0800 From: Jayaraghavendran k To: "tls@ietf.org" Thread-Topic: New Version Notification for draft-jay-tls-psk-identity-extension-00.txt Thread-Index: AQHQ+i0nI/MOejU4rUGw40Mk9iq3hJ5TmcWQ Date: Tue, 29 Sep 2015 15:12:59 +0000 Message-ID: <8D925D4C0B78EE41857D407022ECD163BFEE48E8@SZXEMI501-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.218] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Thu, 01 Oct 2015 09:27:04 -0700 Cc: Raja ashok , Ashutosh prakash Subject: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Sep 2015 15:13:18 -0000 SGkgQWxsLA0KDQpBIG5ldyBUTFMgZXh0ZW5zaW9uIGRyYWZ0IGZvciBvcHRpbWl6aW5nIFRMUy9E VExTIGhhbmRzaGFrZSB3aGVuIFBTSyBpcyB1c2VkIGhhcyBiZWVuIHByb3Bvc2VkLiBUaGlzIGV4 dGVuc2lvbiBhbGxvd3MgdGhlIENsaWVudCBIZWxsbyAmIFNlcnZlciBIZWxsbyBtZXNzYWdlcyB0 byBuZWdvdGlhdGUgdGhlIFBTSyBJZGVudGl0eSB0byBiZSB1c2VkIHRoZXJlYnkgcmVkdWNpbmcg dGhlIGhhbmRzaGFrZSBsYXRlbmN5IHRvIDEgUlRULg0KDQpUaGlzIG1heSBiZSB1c2VmdWwgaW4g SW9UIGVudmlyb25tZW50cyB3aGVyZSBEVExTIDEuMiArIFBTSyBpcyBiZWluZyBwcm9wb3NlZCBm b3IgbWFueSBzY2VuYXJpb3MuDQoNClJlcXVlc3QgeW91ciBjb21tZW50cyAmIHN1Z2dlc3Rpb25z Lg0KDQpUaGFua3MhDQogDQpSZWdhcmRzLA0KSmF5DQoNCioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KVGhpcyBlLW1haWwgYW5kIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFs IGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUg cGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBv ZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcs IGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1 Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50J3MpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1t ZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogMjkgU2VwdGVt YmVyIDIwMTUgMDI6MDUNClRvOiBKYXlhcmFnaGF2ZW5kcmFuIGs7IEpheWFyYWdoYXZlbmRyYW4g azsgUmFqYSBhc2hvazsgUmFqYSBhc2hvaw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1qYXktdGxzLXBzay1pZGVudGl0eS1leHRlbnNpb24tMDAudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWpheS10bHMtcHNrLWlkZW50aXR5LWV4dGVuc2lv bi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmF5YXJhZ2hhdmVu ZHJhbiBLIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWpheS10bHMtcHNrLWlkZW50aXR5LWV4dGVuc2lvbg0KUmV2aXNpb246CTAwDQpUaXRsZToJCVRM Uy9EVExTIFBTSyBJZGVudGl0eSBFeHRlbnNpb24NCkRvY3VtZW50IGRhdGU6CTIwMTUtMDktMjgN Ckdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWpheS10bHMtcHNr LWlkZW50aXR5LWV4dGVuc2lvbi0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qYXktdGxzLXBzay1pZGVudGl0eS1leHRlbnNpb24v DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpheS10 bHMtcHNrLWlkZW50aXR5LWV4dGVuc2lvbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgUHJlLVNoYXJl ZCBLZXkgKFBTSykgYmFzZWQgS2V5IEV4Y2hhbmdlIE1lY2hhbmlzbSBpcyBwcmltYXJpbHkgdXNl ZA0KICAgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzIHdoZXJlIHJlc291cmNlIGludGVuc2l2 ZSBBc3ltbWV0cmljDQogICBDcnlwdG9ncmFwaHkgY2Fubm90IGJlIHVzZWQuIEluIHRoZSBJbnRl cm5ldCBvZiBUaGluZ3MgKElvVCkNCiAgIGRlcGxveW1lbnRzLCBjb25zdHJhaW5lZCBkZXZpY2Vz IGFyZSBjb21tb25seSB1c2VkIGZvciBjb2xsZWN0aW5nDQogICBkYXRhIHZpYSBzZW5zb3JzIGZv ciB1c2UgaW4gaG9tZSBhdXRvbWF0aW9uLCBzbWFydCBlbmVyZ3kgZXRjLiBJbg0KICAgdGhpcyBj b250ZXh0LCBEVExTIGlzIGJlaW5nIGNvbnNpZGVyZWQgYXMgdGhlIHByaW1hcnkgcHJvdG9jb2wg Zm9yDQogICBjb21tdW5pY2F0aW9uIHNlY3VyaXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBh bmQgaW4gc29tZSBjYXNlcywgaXQNCiAgIGlzIGFsc28gYmVpbmcgY29uc2lkZXJlZCBmb3IgbmV0 d29yayBhY2Nlc3MgYXV0aGVudGljYXRpb24uDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg YSBzcGVjaWZpY2F0aW9uIGZvciBhIG5ldyBleHRlbnNpb24gZm9yDQogICBPcHRpbWl6aW5nIERU TFMgYW5kIFRMUyBIYW5kc2hha2Ugd2hlbiB0aGUgUHJlLVNoYXJlZCBLZXkgKFBTSykgYmFzZWQN CiAgIEtleSBFeGNoYW5nZSBpcyB1c2VkLiBUaGlzIGV4dGVuc2lvbiBpcyBhaW1lZCBhdCByZWR1 Y2luZyB0aGUgbnVtYmVyDQogICBvZiBtZXNzYWdlcyBleGNoYW5nZWQgYW5kIHRoZSBSVFQgb2Yg dGhlIFRMUyAmIERUTFMgSGFuZHNoYWtlcy4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= From nobody Fri Oct 2 06:08:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426F61A1B8A for ; Fri, 2 Oct 2015 06:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 FyJ_QDzJcA9q for ; Fri, 2 Oct 2015 06:08:15 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 3FE9C1A1B91 for ; Fri, 2 Oct 2015 06:08:15 -0700 (PDT) Received: by pacex6 with SMTP id ex6so106735775pac.0 for ; Fri, 02 Oct 2015 06:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=HuVu/kxoHP/DzkLn7KVaflnwe6Wj6PUaMdnG/Q6L6Ig=; b=B3ZL4KVjRGYig5WMZzmsgVxVz+O4RCCL7e2Yol/JeI3p43g3imfi014yxFz38lxF8p wBxQVB1eojmTtyYa8ln+LwzrYE+UE6NdsON34iA/CyAaBPqiiZ7f1cIFxk8up0bW4JX1 xyPbu/83SI2BKNuUDIbc5eeFWt7CbfaSur2Mx1PaaTsEOCoiT5WOhh1BQ9xIq/x83YNI R6tKIF+ERrMGJ7ZGelg7S2jdVdbA0KU2dRB16hfTcqyx9NtVdoFqTTvm1qp608J73qPp dO7Y9WdrLzSH2erh7GgQwgcoYh+j540nPeMzTFVe2vXSxdrwR19oDSYzlw2lx+FwBEzX LSlA== X-Received: by 10.66.255.42 with SMTP id an10mr19626051pad.107.1443791294795; Fri, 02 Oct 2015 06:08:14 -0700 (PDT) Received: from [192.168.11.7] (27-142-114-198.rev.home.ne.jp. [27.142.114.198]) by smtp.gmail.com with ESMTPSA id qn5sm12034045pac.41.2015.10.02.06.08.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 06:08:14 -0700 (PDT) Sender: "saito@cs.meiji.ac.jp" Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: takamichi saito In-Reply-To: <55FC7343.3090301@trigofacile.com> Date: Fri, 2 Oct 2015 22:08:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> To: tls@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2015 13:08:17 -0000 >=20 > Do we know how many protocols currently suffer from CRIME? >=20 >=20 > Maybe a best practice could be suggested by UTA for the implementation = of TLS in software, to disable compression if vulnerable. And for the = others, to implement a way to enable/disable compression in case one day = a vulnerability is found. I agree. Again, 1) We know CRIME threat, but it can not be risk for everyone. e.g., CVSS v2 Base Score: 2.6 (LOW) 2) If we need to have comp/decomp in an application layer,=20 clients such like browser need their own comp/decomp codes. 3) If there is no comp in tls1.3, some people may continue to use = tls1.2.=20 Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? That's why we explore the way to keep compression in TLSv1.3. How about making an option only in server-side? The spec has the compression but default is off, and also provides the = suggestion. >=20 > --=20 > Julien =C9LIE >=20 > =AB La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. =BB >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ;; takamixhi saito c2xhYWlidHNvcw From nobody Fri Oct 2 06:59:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99E61A00BD for ; Fri, 2 Oct 2015 06:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] autolearn=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 y_eBleerFrGj for ; Fri, 2 Oct 2015 06:59:06 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 A5EB51A00B1 for ; Fri, 2 Oct 2015 06:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1443794342; l=1612; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=ijeaPpST6I/xbM3XREFjmU8GJDRpEQaK7Ni9KpBGLWI=; b=k4xra6mOOv8wyY1ih1fWRCuYvlbFAoeVqL+XCkjcpcjCUuBqHNYkTI7iz4QEpceGk6x bj3KTGfG8bR8HviEtPlkfNDUWhv+zFoorI6PQYqSYNSWCyaja/koGCb2EiBNZPpWYM6GR asJcwR79Wv3B6jAC0TF831OYqNbI6+IjQEM= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyImrcrs/b6npEJc9Go+veNVQOkuw== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:98b9:74fd:ff27:7ec7] ([2001:4dd0:ff67:0:98b9:74fd:ff27:7ec7]) by smtp.strato.de (RZmta 37.12 AUTH) with ESMTPSA id 6015a7r92Dx2vX7 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 2 Oct 2015 15:59:02 +0200 (CEST) To: tls@ietf.org References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> From: Roland Zink Message-ID: <560E8DA8.8020903@zinks.de> Date: Fri, 2 Oct 2015 15:59:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2015 13:59:07 -0000 Browsers are not a concern as they already have their own comp/decomp codes. HTTP/1 can compress content (Content-encoding and transfer-encoding) and HTTP2 has additional header compression. Regards, Roland Am 02.10.2015 um 15:08 schrieb takamichi saito: >> Do we know how many protocols currently suffer from CRIME? >> >> >> Maybe a best practice could be suggested by UTA for the implementation of TLS in software, to disable compression if vulnerable. And for the others, to implement a way to enable/disable compression in case one day a vulnerability is found. > I agree. > > Again, > > 1) We know CRIME threat, but it can not be risk for everyone. > e.g., CVSS v2 Base Score: 2.6 (LOW) > > 2) If we need to have comp/decomp in an application layer, > clients such like browser need their own comp/decomp codes. > > 3) If there is no comp in tls1.3, some people may continue to use tls1.2. > Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? > > That's why we explore the way to keep compression in TLSv1.3. > How about making an option only in server-side? > The spec has the compression but default is off, and also provides the suggestion. > > >> -- >> Julien ÉLIE >> >> « La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. » >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > ;; takamixhi saito > c2xhYWlidHNvcw > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Oct 2 08:24:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047E41A86E0 for ; Fri, 2 Oct 2015 08:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwgVI2puzlXO for ; Fri, 2 Oct 2015 08:24:12 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 711E91A7D84 for ; Fri, 2 Oct 2015 08:24:12 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A3AB1200051; Fri, 2 Oct 2015 15:24:11 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 8D39320004E; Fri, 2 Oct 2015 15:24:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1443799451; bh=g/SipJVHS4Nn0yy87wsTMCAJxBf6+nuAUyku4ho9vVQ=; l=398; h=From:To:Date:References:In-Reply-To:From; b=bLGf0FBs694JgbU1D/MllpAVNGPpq0fjKP7Ze9PMZ0k2xhIUwCXY2AYkR6LEyUm6O dvykZ5ovOmfQL0QiFOhMGJRuKzm6NkYa0JYDRAiQSXSw5CGAHsizbfIMIqOJD+quIO MG5XBzIMVV3eeiWM0WqZJip+t15rXGJFR4JndyE4= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 88D2A1E08F; Fri, 2 Oct 2015 15:24:11 +0000 (GMT) Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 2 Oct 2015 10:24:11 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1076.000; Fri, 2 Oct 2015 10:24:11 -0500 From: "Salz, Rich" To: takamichi saito , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed Thread-Index: AQHQ8kBAS4S1zYgQwkGNXxwEQUlpup5CsHewgABfN4CAFYZrAP//wsRw Date: Fri, 2 Oct 2015 15:24:10 +0000 Message-ID: <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> In-Reply-To: <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> 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.56.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2015 15:24:14 -0000 > 1) We know CRIME threat, but it can not be risk for everyone. > e.g., CVSS v2 Base Score: 2.6 (LOW) CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called i= t 7.5 > Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? They are equivalent. If you use AES-GCM and ECDHE, and you don't need 0RTT= , then there is no compelling reason to use TLS 1.3. =20 From nobody Fri Oct 2 08:43:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1271B2C10 for ; Fri, 2 Oct 2015 08:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Ki6ZPZ4_U2 for ; Fri, 2 Oct 2015 08:43:35 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 565CA1B2C2B for ; Fri, 2 Oct 2015 08:43:29 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so36543013wic.1 for ; Fri, 02 Oct 2015 08:43:28 -0700 (PDT) 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-type; bh=VB2zUhfW07R0itRJrLIUofVnrsEmmvVXay3gzUZ33nM=; b=GhHZZvfZPOVbQ4I95JVri/yki5szw4RSpmS3s1tG06yM0ggYUaoeVyUFcIlQS+ytQ/ eG/ypSk7ZTrGb5dsIWDis+lcrIjvf6KYpCqO4LgyWgzFGp34aAdq1Un6C5NTznjESLuX ypohY/N1lQHkvYuysI952dvYiEXOr+szzI+nRpHe8YOkmWFljMnDiApZtD51NwVMlWdF 5YaO2zbvO0Fi5GYV+06uYSLr+i8JoLG+0aZ18IJ/0ltZnDXhckAL4fN5AuHd+OwxYQqT lq/QbQPjBmSzGG7adKpJJUVVi0JiULjk+HJNtsJAzExuOSs5RPm1tgvt4BIVrXCcCYve BpEQ== X-Gm-Message-State: ALoCoQkrzGi+5bxOxu/bzXBzkjsgUgYJ9NEvziZpmt3fWNl6/arA3Bsuuhwldh4vi8qIwoK8VEmt X-Received: by 10.180.106.98 with SMTP id gt2mr5264131wib.31.1443800607775; Fri, 02 Oct 2015 08:43:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Fri, 2 Oct 2015 08:42:47 -0700 (PDT) In-Reply-To: <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> From: Eric Rescorla Date: Fri, 2 Oct 2015 08:42:47 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=f46d04428f1c5a78ec0521210692 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2015 15:43:36 -0000 --f46d04428f1c5a78ec0521210692 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich wrote: > > > 1) We know CRIME threat, but it can not be risk for everyone. > > e.g., CVSS v2 Base Score: 2.6 (LOW) > > CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called > it 7.5 > > > Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? > > They are equivalent. If you use AES-GCM and ECDHE, and you don't need > 0RTT, then there is no compelling reason to use TLS 1.3. I don't want to take a position on what's compelling or not, but there are a number of other reasons to use TLS 1.3, including support for real padding, encrypted content types, privacy for client authentication, etc. -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04428f1c5a78ec0521210692 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich <rsalz@akamai.com> wrote:

> 1) We know CRIME threat, but it can not be risk for everyone.
> e.g., CVSS v2 Base Score: 2.6 (LOW)

CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS = v3 called it 7.5

> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/dec= omp" ?

They are equivalent.=C2=A0 If you use AES-GCM and ECDHE, and you don= 't need 0RTT, then there is no compelling reason to use TLS 1.3.

I don't want to take a position on what's= compelling or not, but there are a number of
other reasons to us= e TLS 1.3, including support for real padding, encrypted content types,
privacy for client authentication, etc.

-Ek= r
=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--f46d04428f1c5a78ec0521210692-- From nobody Fri Oct 2 08:47:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1671E1B2C4F for ; Fri, 2 Oct 2015 08:47:04 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkpvMy_muIYJ for ; Fri, 2 Oct 2015 08:47:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 07B9C1B2C56 for ; Fri, 2 Oct 2015 08:47:03 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 601BBF984; Fri, 2 Oct 2015 11:46:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 98B1E202B8; Fri, 2 Oct 2015 11:46:16 -0400 (EDT) From: Daniel Kahn Gillmor To: "Salz\, Rich" , takamichi saito , "tls\@ietf.org" In-Reply-To: <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 02 Oct 2015 11:46:16 -0400 Message-ID: <87d1wx6zp3.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2015 15:47:04 -0000 On Fri 2015-10-02 11:24:10 -0400, Salz, Rich wrote: >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? > > They are equivalent. If you use AES-GCM and ECDHE, and you don't need 0RTT, then there is no compelling reason to use TLS 1.3. ...and you use session-hash, and you either don't do renegotiation or require secure renegotiation, and you don't use TLS-Unique, and you're ok with fully-cleartext handshakes, and (maybe something(s) else i'm forgetting) ... I don't think we should be claiming that TLS 1.2 is equivalent to TLS 1.3 without many more caveats. :) --dkg From nobody Fri Oct 2 08:50:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D251A7012 for ; Fri, 2 Oct 2015 08:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M12ZyxNDPpYi for ; Fri, 2 Oct 2015 08:50:22 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id BF89D1A702A for ; Fri, 2 Oct 2015 08:50:22 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EE385496C56; Fri, 2 Oct 2015 15:50:21 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id D8221496C32; Fri, 2 Oct 2015 15:50:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1443801021; bh=Qam6QvWTwXIMWdEd8lqLkHFnBdqSOk6FhNlPeyRuzaA=; l=126; h=From:To:Date:References:In-Reply-To:From; b=SDe/j90FbrSzvN7ad31ft2XRpcKeQKDA6KSninnhSkIQv2Y/5QA7EbL5rXS2x5Lqf k9GUVI+3UNiYc0Ejnc/WmskD0x3XT1ks7F5hcpgJ5p2ji1CtIatDwGR2weBv/J4NrZ 9+2A45fqm/h63x3Czad64GKpIyguxN6B4OdNbzNs= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id CD6A798082; Fri, 2 Oct 2015 15:50:21 +0000 (GMT) Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 2 Oct 2015 10:50:21 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1076.000; Fri, 2 Oct 2015 10:50:21 -0500 From: "Salz, Rich" To: Daniel Kahn Gillmor , takamichi saito , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed Thread-Index: AQHQ8kBAS4S1zYgQwkGNXxwEQUlpup5CsHewgABfN4CAFYZrAP//wsRwgABpZgD//61CwA== Date: Fri, 2 Oct 2015 15:50:21 +0000 Message-ID: <8313a05a28a4420382343962c51d82cb@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <87d1wx6zp3.fsf@alice.fifthhorseman.net> In-Reply-To: <87d1wx6zp3.fsf@alice.fifthhorseman.net> 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.56.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2015 15:50:26 -0000 > I don't think we should be claiming that TLS 1.2 is equivalent to TLS > 1.3 without many more caveats. :) Fair enough. From nobody Fri Oct 2 09:24:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE671B2CB1 for ; Fri, 2 Oct 2015 09:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: 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-sN-MKV3T5s for ; Fri, 2 Oct 2015 09:24:27 -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 E2DB21B2CB0 for ; Fri, 2 Oct 2015 09:24:26 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 7C77D2A584; Fri, 2 Oct 2015 18:24:24 +0200 (CEST) X-purgate-ID: 152705::1443803064-00005D2B-462C83B4/0/0 X-purgate-size: 1812 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 6D7844064E; Fri, 2 Oct 2015 18:24:24 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 63B871A2BA; Fri, 2 Oct 2015 18:24:24 +0200 (CEST) In-Reply-To: To: Eric Rescorla Date: Fri, 2 Oct 2015 18:24:24 +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: <20151002162424.63B871A2BA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 16:24:29 -0000 Eric Rescorla wrote: > On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich wrote: >> >>> 1) We know CRIME threat, but it can not be risk for everyone. >>> e.g., CVSS v2 Base Score: 2.6 (LOW) >> >> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called >> it 7.5 >> >>> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? >> >> They are equivalent. If you use AES-GCM and ECDHE, and you don't need >> 0RTT, then there is no compelling reason to use TLS 1.3. > > > I don't want to take a position on what's compelling or not, but there are > a number of other reasons to use TLS 1.3, including support for > real padding, > encrypted content types > privacy for client authentication, etc. privacy for client authentication is the only real benefit on this list of 3. The value of real padding is highly dependent of whether and how it will actually get used, and is far from automatic. Btw. retrofitting real padding as "compression alg" into TLSv1.0-TLSv1.2 would be trivial, and work fine with TLSv1.2 AEAD. encrypted content types looks like lame duck with zero value to me. "Is not readily distinguishable by existing deep packet inspection (DPI) filter types" is pretty much the only thing--and adjusting DPI will be far from rocket science. Trying to make a single bit of information stick out less prominently will only create a false sense of security whenever that bit of information can be trivially detected from the traffic pattern. But the collateral damage is that you break stuff that feeds on the outer record layer structure and state, which can easily push adoption of TLSv1.3 from the 5-years-spec-to-usage for TLSv1.2 to the 15-years-spec-to-marginal-use marginal use seen with IPv6. -Martin From nobody Fri Oct 2 12:44:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A618E1A879A for ; Fri, 2 Oct 2015 12:44:03 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYqq3ZZzgU7l for ; Fri, 2 Oct 2015 12:44:02 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c: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 150331A8788 for ; Fri, 2 Oct 2015 12:44:02 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so44193691wic.1 for ; Fri, 02 Oct 2015 12:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=YIdZC3Q3nkDVqO7j3FGWf0JWG6ap1P7VTzRTUOn4om0=; b=kC2QRwpaMds0tClApqwxAhDFsW+w+I4LA7v93Uogwu+6L6PSCJq2T1ig6QcQTzHOI4 YQpEz4vLOJMwvJyvhtmOYUAKrE/4l2Gr36cvFtR61k1BBTwPaLRLpKF7hmm4caZ7zyZS LDh7FxmSA7FZyMnAQdK+vyZqdJ40X4OLzpaH0myn8HHdLM4JnU2Uo/0LLPiDyFC54+gb 7ERspslAMc6UnzMoUnxuEQCjlX9LafwnZJuGvIs2IVpvkGbfuU28eYYomP9WhAqURvV0 xlAIfNFI2Ag9DkDvOOf7epmUEYYS/sUzeTBVyPEerR1WM19n52ntvOb+z1YvHnV/C+5m +aMw== X-Received: by 10.180.182.14 with SMTP id ea14mr577576wic.23.1443815040697; Fri, 02 Oct 2015 12:44:00 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id t7sm541138wia.9.2015.10.02.12.43.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 12:43:59 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FCC749B3-8CAC-424F-95D6-4F5D126F2AAA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: Date: Fri, 2 Oct 2015 22:43:55 +0300 Message-Id: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> To: Eric Rescorla X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2015 19:44:03 -0000 --Apple-Mail=_FCC749B3-8CAC-424F-95D6-4F5D126F2AAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 2, 2015, at 6:42 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich > wrote: >=20 > > 1) We know CRIME threat, but it can not be risk for everyone. > > e.g., CVSS v2 Base Score: 2.6 (LOW) >=20 > CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 = called it 7.5 >=20 > > Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? >=20 > They are equivalent. If you use AES-GCM and ECDHE, and you don't need = 0RTT, then there is no compelling reason to use TLS 1.3. >=20 > I don't want to take a position on what's compelling or not, but there = are a number of > other reasons to use TLS 1.3, including support for real padding, = encrypted content types, > privacy for client authentication, etc. And client certificate authentication in HTTP/2 (This assumes that HTTP/2 is required) --Apple-Mail=_FCC749B3-8CAC-424F-95D6-4F5D126F2AAA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Oct 2, 2015, at 6:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich <rsalz@akamai.com> wrote:

> 1) We know CRIME threat, but it can not be risk for everyone.
> e.g., CVSS v2 Base Score: 2.6 (LOW)

CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called it 7.5

> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?

They are equivalent.  If you use AES-GCM and ECDHE, and you don't need 0RTT, then there is no compelling reason to use TLS 1.3.

I don't want to take a position on what's compelling or not, but there are a number of
other reasons to use TLS 1.3, including support for real padding, encrypted content types,
privacy for client authentication, etc.

And client certificate authentication in HTTP/2

(This assumes that HTTP/2 is required)

--Apple-Mail=_FCC749B3-8CAC-424F-95D6-4F5D126F2AAA-- From nobody Sat Oct 3 09:34:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B119F1B3690 for ; Sat, 3 Oct 2015 09:34:18 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaZRanxdoYs1 for ; Sat, 3 Oct 2015 09:34:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 134D51B368F for ; Sat, 3 Oct 2015 09:34:16 -0700 (PDT) Received: from fifthhorseman.net (184-209-11-164.pools.spcsdns.net [184.209.11.164]) by che.mayfirst.org (Postfix) with ESMTPSA id F2352F98B; Sat, 3 Oct 2015 12:34:14 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D0249209D8; Sat, 3 Oct 2015 12:02:38 -0400 (EDT) From: Daniel Kahn Gillmor To: mrex@sap.com, Eric Rescorla In-Reply-To: <20151002162424.63B871A2BA@ld9781.wdf.sap.corp> References: <20151002162424.63B871A2BA@ld9781.wdf.sap.corp> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sat, 03 Oct 2015 12:02:38 -0400 Message-ID: <87a8s0549t.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Oct 2015 16:34:18 -0000 On Fri 2015-10-02 12:24:24 -0400, Martin Rex wrote: > The value of real padding is highly dependent of whether and how it > will actually get used, and is far from automatic. Sure, but we have no existing mechanism to do that in TLS 1.2 or earlier. We need the mechanism before anyone can establish sensible policy. Understanding what policy is sensible is likely to be endpoint-specific, and is definitely something that needs research. But we can't implement any policy at all without having the mechanism in place. > Btw. retrofitting real padding as "compression alg" into TLSv1.0-TLSv1.2 > would be trivial, and work fine with TLSv1.2 AEAD. "would be trivial" is not "has been specified". It also requires negotiation, whereas hopefully in 1.3, we will not need to negotiate padding. Furthermore, If you treat padding as a "compression alg" in 1.2, then the folks who started this thread who want 1.2 because of its support for compression would not be able to use padding in conjunction with compression (if someone has a use case for such a combination, which seems counterintuitive at first glance). So this proposal doesn't really address the original reason for the suggestion of "stay on 1.2". > encrypted content types looks like lame duck with zero value to me. > > "Is not readily distinguishable by existing deep packet inspection (DPI) > filter types" is pretty much the only thing--and adjusting DPI will be > far from rocket science. I beg to differ -- if there is any interleaving of application_data and other content types, and if records can be arbitrarily-sized, it's not clear to me how a DPI can distinguish one from the other. Can you be more specific? > Trying to make a single bit of information stick out less prominently > will only create a false sense of security whenever that bit of information > can be trivially detected from the traffic pattern. We need to be looking at things the other way around: if there's a sensible way to leak less metadata, we should be leaking less metadata, even if there are other ways that the same information can be recovered by a similar adversary. "don't fix X because Y has the same problem" is a great symmetric recipe for not getting anything done. We should be saying "we need to fix both X and Y" instead. > But the collateral damage is that you break stuff that feeds on the > outer record layer structure and state, which can easily push adoption > of TLSv1.3 from the 5-years-spec-to-usage for TLSv1.2 to the > 15-years-spec-to-marginal-use marginal use seen with IPv6. Can you enumerate the stuff you expect to break from encrypted content type that will cause a decade-long delay in adoption? It would be great to have a list of those things so we can evaluate them. --dkg From nobody Sat Oct 3 10:55:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEB31B2FF4 for ; Sat, 3 Oct 2015 10:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ona6O7wcE9DW for ; Sat, 3 Oct 2015 10:55:17 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43C91B371E for ; Sat, 3 Oct 2015 10:55:16 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 8308969974; Sat, 3 Oct 2015 20:55:13 +0300 (EEST) Date: Sat, 3 Oct 2015 20:55:13 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20151003175512.GA26293@LK-Perkele-VII> References: <20151002162424.63B871A2BA@ld9781.wdf.sap.corp> <87a8s0549t.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87a8s0549t.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Oct 2015 17:55:19 -0000 On Sat, Oct 03, 2015 at 12:02:38PM -0400, Daniel Kahn Gillmor wrote: > On Fri 2015-10-02 12:24:24 -0400, Martin Rex wrote: > > > But the collateral damage is that you break stuff that feeds on the > > outer record layer structure and state, which can easily push adoption > > of TLSv1.3 from the 5-years-spec-to-usage for TLSv1.2 to the > > 15-years-spec-to-marginal-use marginal use seen with IPv6. > > Can you enumerate the stuff you expect to break from encrypted content > type that will cause a decade-long delay in adoption? It would be great > to have a list of those things so we can evaluate them. I personally would expect that anything that would be broken by content type encryption is already broken by fixing the handshake (it has number of known flaws). That version number field that has absolutely no use in encrypted records is still there... For compatiblity. Also, new user protocols (like TLS) are much much easier to deploy than new addressing protocols (like IPv6). And the stuff that breaks... Probably some badly done "middleware" in "enterprise" environment. -Ilari From nobody Sat Oct 3 15:36:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E251A87BE for ; Sat, 3 Oct 2015 15:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 riWELZO1EGnO for ; Sat, 3 Oct 2015 15:36:22 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 2FFA01A87BD for ; Sat, 3 Oct 2015 15:36:21 -0700 (PDT) Received: by pacex6 with SMTP id ex6so139046602pac.0 for ; Sat, 03 Oct 2015 15:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=I5GQOR9tdLRGdevy9Dm/mOpZbFNrfW1Z9dQKLK60akI=; b=JvaopcpPQ6v1tAj87hHztg3Xom2GjP35HF2mlisNCqWYS7IZ+s3l4ZwMoH09Uy7lAX DIEXh8niwzj6D/wi001tNlkVUNLPaHM74raySECUIzrp/Wjmu5Q8fld1jaXyPxSUPJ6j 4zKNUDy1hmPOWqLheNCBJBua53q1xY8Tr1cz/dHdUjrqqr1RwtH8sMzadkJ10UuGZgW6 TxS2aG5VfeggiNv2R+P76ehsXn9Te1Sn8260PL1CKUj7H0JEgKN2NU6O2B5fwIwJULMa 0RnbVmhuqEouCs3pyv35cJ/cWlVbpinUgTdumLPU/rmvi4rrKpBbmVIW5joOTifOcXL8 XADw== X-Received: by 10.66.216.1 with SMTP id om1mr29361692pac.51.1443911781516; Sat, 03 Oct 2015 15:36:21 -0700 (PDT) Received: from [192.168.11.7] (27-142-114-198.rev.home.ne.jp. [27.142.114.198]) by smtp.gmail.com with ESMTPSA id bz4sm19268085pbd.6.2015.10.03.15.36.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Oct 2015 15:36:20 -0700 (PDT) Sender: "saito@cs.meiji.ac.jp" Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: takamichi saito In-Reply-To: <560E8DA8.8020903@zinks.de> Date: Sun, 4 Oct 2015 07:36:22 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <775C14FF-8F23-44E4-9A80-9F4F65217B86@cs.meiji.ac.jp> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <560E8DA8.8020903@zinks.de> To: tls@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Oct 2015 22:36:23 -0000 On 2015/10/02, at 22:59, Roland Zink wrote: > Browsers are not a concern as they already have their own comp/decomp = codes. HTTP/1 can compress content (Content-encoding and = transfer-encoding) and HTTP2 has additional header compression. >=20 > Regards, > Roland >=20 I see, but contrary, tls is only for browser? And more, if you kick out comp/decomp from tls, can we be safer when we use tls? If you know the paper, please teach me. Or, rfc or good teacher should notify us, "When you use TLSv1.3, you never use compression, sorry!" I know it may be out scope, but we have to estimate the risk. regards, >=20 > Am 02.10.2015 um 15:08 schrieb takamichi saito: >>> Do we know how many protocols currently suffer from CRIME? >>>=20 >>>=20 >>> Maybe a best practice could be suggested by UTA for the = implementation of TLS in software, to disable compression if vulnerable. = And for the others, to implement a way to enable/disable compression in = case one day a vulnerability is found. >> I agree. >>=20 >> Again, >>=20 >> 1) We know CRIME threat, but it can not be risk for everyone. >> e.g., CVSS v2 Base Score: 2.6 (LOW) >>=20 >> 2) If we need to have comp/decomp in an application layer, >> clients such like browser need their own comp/decomp codes. >>=20 >> 3) If there is no comp in tls1.3, some people may continue to use = tls1.2. >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? >>=20 >> That's why we explore the way to keep compression in TLSv1.3. >> How about making an option only in server-side? >> The spec has the compression but default is off, and also provides = the suggestion. >>=20 >>=20 >>> --=20 >>> Julien =C9LIE >>>=20 >>> =AB La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. =BB >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> ;; takamixhi saito >> c2xhYWlidHNvcw >>=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 ;; takamixhi saito From nobody Sat Oct 3 15:44:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7141A883D for ; Sat, 3 Oct 2015 15:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 cZXxiMkLgzWS for ; Sat, 3 Oct 2015 15:44:23 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 EC4BD1A883C for ; Sat, 3 Oct 2015 15:44:22 -0700 (PDT) Received: by pablk4 with SMTP id lk4so138152960pab.3 for ; Sat, 03 Oct 2015 15:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=2mwYaEYLCixJd85BmR0meP6Ny9Se0uX6A4HRSTOhoYg=; b=RYl0VbsKqLo5yWxV1i19HmnVmJFrAgjWASOlBEKo51VEEVLjwJCtK8XRogPBYt+Njn NkAo35thiuuRpEQfgDtdnRMeAin79giD0RN0tgMyY0AZlm5xHMDjxKnGpo0DV42W2lHp LptG4OtYvSA5zC3IvSmUgS95xEUTMhBt1k06fp4S0XUns5X8leDfHGhEKtCuenJ55Igv PPDwtRQr7bdXZK5jIaGJjH4rVvS8vZjjcuUuhSCeiDSmDvXeCG0+yQ/eNBU2awuSnXMb 8llMUzFbHAXG5uC0Nks7OaT1W+lqOsFK80R5xN1ouI4HGG6uRM8OSh7NJ77sZj/Ao4vY xrjg== X-Received: by 10.69.2.69 with SMTP id bm5mr29053325pbd.41.1443912262618; Sat, 03 Oct 2015 15:44:22 -0700 (PDT) Received: from [192.168.11.7] (27-142-114-198.rev.home.ne.jp. [27.142.114.198]) by smtp.gmail.com with ESMTPSA id xz5sm19274410pbb.12.2015.10.03.15.44.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Oct 2015 15:44:21 -0700 (PDT) Sender: "saito@cs.meiji.ac.jp" Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: takamichi saito In-Reply-To: <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> Date: Sun, 4 Oct 2015 07:44:21 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> To: tls@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Oct 2015 22:44:24 -0000 On 2015/10/03, at 0:24, Salz, Rich wrote: >=20 >> 1) We know CRIME threat, but it can not be risk for everyone. >> e.g., CVSS v2 Base Score: 2.6 (LOW) >=20 > CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 = called it 7.5 >=20 We know it, but one of indicators. How can you say the dangerous or risk instead of it?=20 My point is, CRIME is risk for every case? even when we have option in = tls1.3, in case that default is off.=20 >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? >=20 > They are equivalent. If you use AES-GCM and ECDHE, and you don't need = 0RTT, then there is no compelling reason to use TLS 1.3. >=20 If so, some people can skip tls1.3. ;; takamixhi saito From nobody Sat Oct 3 15:56:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF571A887A for ; Sat, 3 Oct 2015 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdZJS9QcdxdK for ; Sat, 3 Oct 2015 15:56:29 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 B99BC1A885B for ; Sat, 3 Oct 2015 15:56:28 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so70548741wic.0 for ; Sat, 03 Oct 2015 15:56:27 -0700 (PDT) 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-type; bh=zd52+gJKpCeNEEFdugjZWaXmumBBW+/4dQw1bL9FUl0=; b=Pw4/97M8YWsqH7Zd4/+jznMONNGQN7OsmbYDnL3+4AdZ8SPx1kg5d+fovg3zwG6gJ4 AU+4sl1LRLXRKxYXuBY/tj5io/xTFg0Df3jk2DWefhZW/hDftMdbMwYpgvKuogrzMJqt f9Bx7RXVolYpQmA+3kdX8fIIDl7sSrfQZUCqBHybUPLOo//W1qiybyo5aZbI8yElV3Vc awqcQGdaC0iTs2ZAFAFb5/FIasdWDZ5JjuTXoWjeBGnMlcskq5VZWcYyAf6Gisu9SNSg n9niK6lOK0PbjsTvC5l8b9vH1VmUNjhENm4gfkCrPBvuNJMYg94HvAXL5P3i7hw0dEwE ba4A== X-Gm-Message-State: ALoCoQngpS4u13TttCwC2iP1Te52M1apEoDbdfdJyR2PmhBrDjmD2w8XbBPGgoJGgzjVYCXSE8MP X-Received: by 10.194.48.81 with SMTP id j17mr22148574wjn.81.1443912987132; Sat, 03 Oct 2015 15:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Sat, 3 Oct 2015 15:55:47 -0700 (PDT) In-Reply-To: <775C14FF-8F23-44E4-9A80-9F4F65217B86@cs.meiji.ac.jp> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <560E8DA8.8020903@zinks.de> <775C14FF-8F23-44E4-9A80-9F4F65217B86@cs.meiji.ac.jp> From: Eric Rescorla Date: Sat, 3 Oct 2015 15:55:47 -0700 Message-ID: To: takamichi saito Content-Type: multipart/alternative; boundary=047d7b86c190af5f4605213b30da Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Oct 2015 22:56:31 -0000 --047d7b86c190af5f4605213b30da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Oct 3, 2015 at 3:36 PM, takamichi saito wrote: > > On 2015/10/02, at 22:59, Roland Zink wrote: > > > Browsers are not a concern as they already have their own comp/decomp > codes. HTTP/1 can compress content (Content-encoding and transfer-encodin= g) > and HTTP2 has additional header compression. > > > > Regards, > > Roland > > > > I see, > but contrary, > tls is only for browser? > > And more, > if you kick out comp/decomp from tls, > can we be safer when we use tls? > If you know the paper, please teach me. > > Or, rfc or good teacher should notify us, > "When you use TLSv1.3, you never use compression, sorry!" > That is what the document says: "Versions of TLS before 1.3 supported compression and the list of compression methods was supplied in this field. For any TLS 1.3 ClientHello, this field MUST contain only the =E2=80=9Cnull=E2=80=9D compre= ssion method with the code point of 0. If a TLS 1.3 ClientHello is received with any other value in this field, the server MUST generate a fatal =E2=80=9Cillegal_parameter=E2=80=9D alert. Note that TLS 1.3 servers may re= ceive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS." -Ekr > I know it may be out scope, > but we have to estimate the risk. > > regards, > > > > > > Am 02.10.2015 um 15:08 schrieb takamichi saito: > >>> Do we know how many protocols currently suffer from CRIME? > >>> > >>> > >>> Maybe a best practice could be suggested by UTA for the implementatio= n > of TLS in software, to disable compression if vulnerable. And for the > others, to implement a way to enable/disable compression in case one day = a > vulnerability is found. > >> I agree. > >> > >> Again, > >> > >> 1) We know CRIME threat, but it can not be risk for everyone. > >> e.g., CVSS v2 Base Score: 2.6 (LOW) > >> > >> 2) If we need to have comp/decomp in an application layer, > >> clients such like browser need their own comp/decomp codes. > >> > >> 3) If there is no comp in tls1.3, some people may continue to use > tls1.2. > >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? > >> > >> That's why we explore the way to keep compression in TLSv1.3. > >> How about making an option only in server-side? > >> The spec has the compression but default is off, and also provides the > suggestion. > >> > >> > >>> -- > >>> Julien =C3=89LIE > >>> > >>> =C2=AB La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. = =C2=BB > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >> ;; takamixhi saito > >> c2xhYWlidHNvcw > >> > >> _______________________________________________ > >> 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 > > > ;; takamixhi saito > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b86c190af5f4605213b30da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 3, 2015 at 3:36 PM, takamichi saito <<= a href=3D"mailto:saito@cs.meiji.ac.jp" target=3D"_blank">saito@cs.meiji.ac.= jp> wrote:

On 2015/10/02, at 22:59, Roland Zink wrote:

> Browsers are not a concern as they already have their own comp/decomp = codes. HTTP/1 can compress content (Content-encoding and transfer-encoding)= and HTTP2 has additional header compression.
>
> Regards,
> Roland
>

I see,
but contrary,
tls is only for browser?

And more,
if you kick out comp/decomp from tls,
can we be safer when we use tls?
If you know the paper, please teach me.

Or, rfc or good teacher should notify us,
"When you use TLSv1.3, you never use compression, sorry!"

That is what the document says:
&quo= t;Versions of TLS before 1.3 supported compression and the list of=20 compression methods was supplied in this field. For any TLS 1.3=20 ClientHello, this field MUST contain only the =E2=80=9Cnull=E2=80=9D compre= ssion method=20 with the code point of 0. If a TLS 1.3 ClientHello is received with any=20 other value in this field, the server MUST generate a fatal=20 =E2=80=9Cillegal_parameter=E2=80=9D alert. Note that TLS 1.3 servers may re= ceive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST=20 follow the procedures for the appropriate prior version of TLS."
=

-Ekr

=C2=A0
I know it may be out scope,
but we have to estimate the risk.

regards,


>
> Am 02.10.2015 um 15:08 schrieb takamichi saito:
>>> Do we know how many protocols currently suffer from CRIME?
>>>
>>>
>>> Maybe a best practice could be suggested by UTA for the implem= entation of TLS in software, to disable compression if vulnerable.=C2=A0 An= d for the others, to implement a way to enable/disable compression in case = one day a vulnerability is found.
>> I agree.
>>
>> Again,
>>
>> 1) We know CRIME threat, but it can not be risk for everyone.
>> e.g., CVSS v2 Base Score: 2.6 (LOW)
>>
>> 2) If we need to have comp/decomp in an application layer,
>>=C2=A0 clients such like browser need their own comp/decomp codes.<= br> >>
>> 3) If there is no comp in tls1.3, some people may continue to use = tls1.2.
>> Which one is safer, "tls1.2" v.s. "tls1.3 with comp= /decomp" ?
>>
>> That's why we explore the way to keep compression in TLSv1.3.<= br> >> How about making an option only in server-side?
>> The spec has the compression but default is off, and also provides= the suggestion.
>>
>>
>>> --
>>> Julien =C3=89LIE
>>>
>>> =C2=AB La vraie valeur d'un homme se mesure lorsqu'il = a tout perdu. =C2=BB
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls<= br> >>
>> ;; takamixhi saito
>> c2xhYWlidHNvcw
>>
>> _______________________________________________
>> 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


;; takamixhi saito

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

--047d7b86c190af5f4605213b30da-- From nobody Sat Oct 3 16:54:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27F61A897B for ; Sat, 3 Oct 2015 16:54:33 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPTCY2yTGh3N for ; Sat, 3 Oct 2015 16:54:32 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 08F931A8974 for ; Sat, 3 Oct 2015 16:54:31 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so75321280wic.1 for ; Sat, 03 Oct 2015 16:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0ki9W8GU2CibD9Eho/OjVRUPk6F3Rd77n73wWY8182o=; b=FEUMLGm+8EOgWAIZLf8jSGmm06Yi01RuLVxVoGXyRJ7lpIRC8iHSMlhdVXU6gJpNyc LwcmKJGKR4AMYmBnj6ZExF+50wBBasjDUYHw3erFY1y79zNPxc4JatH2YgzZYDLZs49W cUC1j93nkCq6ghlSZ02oOZ13diT2hGXen/LbDgAi9yUmKZwEwdcX1oH4IBl3V07xX+01 3xCX2am0F2/AafRRvoi8Q9qHRbDOWIlYXB9mU8ofC4wot0TqXCKIoUsq2i1iTUANINJI W5tapIu7YSG/QSGNUM++si+lSzdTPJXwJLaoAJo58WFcwHA2yDXU7D98KVqdkWtyWKe/ m12g== X-Received: by 10.180.188.169 with SMTP id gb9mr3947657wic.44.1443916470436; Sat, 03 Oct 2015 16:54:30 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id mc20sm6442936wic.16.2015.10.03.16.54.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Oct 2015 16:54:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> Date: Sun, 4 Oct 2015 02:54:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> To: takamichi saito X-Mailer: Apple Mail (2.2104) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Oct 2015 23:54:33 -0000 > On Oct 4, 2015, at 1:44 AM, takamichi saito = wrote: >=20 >=20 > On 2015/10/03, at 0:24, Salz, Rich wrote: >=20 >>=20 >>> 1) We know CRIME threat, but it can not be risk for everyone. >>> e.g., CVSS v2 Base Score: 2.6 (LOW) >>=20 >> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 = called it 7.5 >>=20 >=20 > We know it, but one of indicators. > How can you say the dangerous or risk instead of it?=20 > My point is, CRIME is risk for every case? =20 I don=E2=80=99t know. Probably not.=20 But consider that we had been using HTTP with TLS for over 15 years = before we found out about CRIME. It=E2=80=99s a subtle attack that = relies on specific structures in HTTP and the peculiar way that browsers = allow a script from one site to issue requests on behalf of another = site. But still, it took researches all these years to find it.=20 There are many lessons to be learned from this: that a bearer token that = is repeated many times is not a good idea; that the trust model in the = web is not great; but also that blindly compressing content with no = regard to its structure and sources is dangerous and reveals information = about the cleartext. A security protocol should not do that.=20 An even more executive-level lesson might be that security layers should = not provide non-security services, but that is not really convincing = because if there was a separate compression layer that you could compose = with the security layer in TLS, CRIME would still be possible. To = compress HTTP without the danger of CRIME you need to either not = compress header fields with sensitive information, not compress header = fields that might be controlled by an attacker, or at least delegate = those to a separate compression state. That is not something that any = transport layer shim can provide. Yoav From nobody Sun Oct 4 10:50:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2FF1B33F0 for ; Sun, 4 Oct 2015 10:50:16 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4pnRG-eVz0K for ; Sun, 4 Oct 2015 10:50:14 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 625911B33EF for ; Sun, 4 Oct 2015 10:50:14 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so48917071igb.0 for ; Sun, 04 Oct 2015 10:50: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:content-type; bh=ExsEFgkR/p4EB7uGbGFCK0RHRJtLDjSinSY0qHdqo20=; b=sn82P1kKX52VzdCtVYOoZu4GLeXzG6X1puS2tzJJrCIdjMIoSTtCLeSO/Vuv5OLvvT J4KkbNScjq2u1Kxi8c2lZs2foU6V5G9PYV0OhDQc43/HPgxLz/KRoAgpRZJuyAGLe8vc c0gqwb6B9llyySSAjWn/kBwmmAPHfJ12cwF7a6VbNQJPOPSP3HvTPReEPEepd319BAaa LcRC+PGQ6XV4EHtx70fpxsPGGEG6H9Wp0xI9vgSUwxXk73YhGalMYyO9Olu6xK2CC39A YzpCL5cCj7bgPO+eShgveu6Thy5jT2q0lxWDtvVgs3MHj9lO4yrgNr/yJilBM2cfef1G Qz1g== X-Received: by 10.50.66.141 with SMTP id f13mr5787278igt.51.1443981013571; Sun, 04 Oct 2015 10:50:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.19.67 with HTTP; Sun, 4 Oct 2015 10:49:53 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> From: Tony Arcieri Date: Sun, 4 Oct 2015 10:49:53 -0700 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7bdc0dd260610805214b0722 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 17:50:16 -0000 --047d7bdc0dd260610805214b0722 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 3, 2015 at 4:54 PM, Yoav Nir wrote: > An even more executive-level lesson might be that security layers should > not provide non-security services, but that is not really convincing > because if there was a separate compression layer that you could compose > with the security layer in TLS, CRIME would still be possible. To compress > HTTP without the danger of CRIME you need to either not compress header > fields with sensitive information, not compress header fields that might be > controlled by an attacker, or at least delegate those to a separate > compression state. The attack you're describing (or one fairly close to it) already happened, and it's called BREACH. It impacts HTTP compression, and allows attackers to recover things like CSRF tokens in page bodies. The takeaway for me is you can't mix compression, any fixed value an attacker wishes to learn, and attacker-controlled data, or there will be a compression side-channel. -- Tony Arcieri --047d7bdc0dd260610805214b0722 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Oct 3, 2015 at 4:54 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
An even more executive-level lesson might be that security layers sho= uld not provide non-security services, but that is not really convincing be= cause if there was a separate compression layer that you could compose with= the security layer in TLS, CRIME would still be possible. To compress HTTP= without the danger of CRIME you need to either not compress header fields = with sensitive information, not compress header fields that might be contro= lled by an attacker, or at least delegate those to a separate compression s= tate.

The attack you're describing (or = one fairly close to it) already happened, and it's called BREACH. It im= pacts HTTP compression, and allows attackers to recover things like CSRF to= kens in page bodies.

The takeaway for me is you ca= n't mix compression, any fixed value an attacker wishes to learn, and a= ttacker-controlled data, or there will be a compression side-channel.
=
=C2=A0
--
Tony Arcieri
--047d7bdc0dd260610805214b0722-- From nobody Sun Oct 4 10:58:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BB21B3415 for ; Sun, 4 Oct 2015 10:58:11 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge0wP3NqBgEY for ; Sun, 4 Oct 2015 10:58:10 -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 1FFE41B3414 for ; Sun, 4 Oct 2015 10:58:10 -0700 (PDT) Received: by iow1 with SMTP id 1so128129131iow.1 for ; Sun, 04 Oct 2015 10:58:09 -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:date:message-id :subject:from:to:cc:content-type; bh=QeOwR2rT2YSJJ9FO3ESNSPRvlUKw/S+UjDeyfLBSHGE=; b=EQlsWkHz3+lBFvfpqCN8tSeQhKOjF6XpMeNZ3pWF8doo5HGtTXGW32W6ArbS1pb45h XF2wh5jKtl0TDUy6WTCYISJsfxZgygcnOIkCn7wwm3Bi2Cictzq21Z0B/K1mo1FWqj4B a3ErRLJKGAkVJFcWArlek8Zu/V5wJaAKdmWwmnZutDUk/G1bF6/pBp9ZZif6L+9gldkL K0TZFMfK070zNBKTiz07vKEo0zhCgx3gy0zRHtEA/vKqnnsslX95reZGJId+JDJR8Hjr 7rzKkzKCm++/JlNe2qiezSqbkm5KlCEKl2n/XlRCjn+A9d41bBGXTNf1f2s65rCz4T9B yklg== MIME-Version: 1.0 X-Received: by 10.107.135.218 with SMTP id r87mr24973983ioi.153.1443981489572; Sun, 04 Oct 2015 10:58:09 -0700 (PDT) Received: by 10.36.123.131 with HTTP; Sun, 4 Oct 2015 10:58:09 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> Date: Sun, 4 Oct 2015 13:58:09 -0400 Message-ID: From: Jeffrey Walton To: Tony Arcieri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 04 Oct 2015 17:58:11 -0000 >> An even more executive-level lesson might be that security layers should >> not provide non-security services, but that is not really convincing because >> if there was a separate compression layer that you could compose with the >> security layer in TLS, CRIME would still be possible. To compress HTTP >> without the danger of CRIME you need to either not compress header fields >> with sensitive information, not compress header fields that might be >> controlled by an attacker, or at least delegate those to a separate >> compression state. > > > The attack you're describing (or one fairly close to it) already happened, > and it's called BREACH. It impacts HTTP compression, and allows attackers to > recover things like CSRF tokens in page bodies. > > The takeaway for me is you can't mix compression, any fixed value an > attacker wishes to learn, and attacker-controlled data, or there will be a > compression side-channel. Is that necessarily true? Deflate violates semantic security by allowing the attacker to gain information across messages (even though any single message is secure). So perhaps its the mode of compression ot the way compression was implemented, and not compression itself. Jeff From nobody Sun Oct 4 11:10:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64FE1B3445 for ; Sun, 4 Oct 2015 11:10: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMMnsAT9cTiJ for ; Sun, 4 Oct 2015 11:10:10 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 1F0431B3448 for ; Sun, 4 Oct 2015 11:10:10 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so47069426igb.0 for ; Sun, 04 Oct 2015 11:10: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:content-type; bh=kY4Cu+HaF7JFmM3zhH0OrvclvZjhJImBOs0sYA8vrYI=; b=yo4K1N3PpBzQQBA55gUMNVUKtA7o/8TUemWnh0drkmDr1O1kwQ2QXUJLPrY4m4vecT ES5fnzdeLOjEFpcyGLKJfiZDJeu86TMZKj0IPYd0a4aMDc+CnuLFk3pWVBg82aeys2RG U26I0EEzEcnzr/t3KV5Es4qVHskG/t9bMTjcc1m7r5tNU1kFvD8pcw/aviNMcg0S6lhz SgjfeMsCfrONMail0fUTfW3kaa0EpzSwe7CY6FqyyQx9yJlKe+C/B9XRXe2DwsUb+hSD VvUmb4P4rK2wXgbT6komr98uguWsVNYoIjWp+KmsSKfhztGvvdi4N+wkkHrMxPWv/jyf pVCQ== X-Received: by 10.50.57.84 with SMTP id g20mr6369601igq.18.1443982209569; Sun, 04 Oct 2015 11:10:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.19.67 with HTTP; Sun, 4 Oct 2015 11:09:49 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> From: Tony Arcieri Date: Sun, 4 Oct 2015 11:09:49 -0700 Message-ID: To: Jeffrey Walton Content-Type: multipart/alternative; boundary=047d7bdc12eaa9db7305214b4eb9 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 18:10:11 -0000 --047d7bdc12eaa9db7305214b4eb9 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 4, 2015 at 10:58 AM, Jeffrey Walton wrote: > > The takeaway for me is you can't mix compression, any fixed value an > > attacker wishes to learn, and attacker-controlled data, or there will be > a > > compression side-channel. > > Is that necessarily true? > > Deflate violates semantic security by allowing the attacker to gain > information across messages (even though any single message is > secure). So perhaps its the mode of compression ot the way compression > was implemented, and not compression itself. The only property of compression that this class of side-channel attack relies on is that the compression algorithm produces a smaller output for message a || a than a || b (where a and b are of identical length), so really it would seem to be a conceptual problem with mixing compression and encryption. If someone has produced a secure system for "compression side-channel resistant encryption", I haven't seen it. -- Tony Arcieri --047d7bdc12eaa9db7305214b4eb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Oct 4, 2015 at 10:58 AM, Jeffrey Walton <noloader@gmail.com> wrote:
> The takeaway for me is you can't mi= x compression, any fixed value an
> attacker wishes to learn, and attacker-controlled data, or there will = be a
> compression side-channel.

Is that necessarily true?

Deflate violates semantic security by allowing the attacker to gain
information across messages (even though any single message is
secure). So perhaps its the mode of compression ot the way compression
was implemented, and not compression itself.

The only property of compression that this class of side-channel attack r= elies on is that the compression algorithm produces a smaller output for me= ssage a || a than a || b (where a and b are of identical length), so really= it would seem to be a conceptual problem with mixing compression and encry= ption.

If someone has produced a secure system for= "compression side-channel resistant encryption", I haven't s= een it.

--
Ton= y Arcieri
--047d7bdc12eaa9db7305214b4eb9-- From nobody Sun Oct 4 11:32:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6961B3489 for ; Sun, 4 Oct 2015 11:32:39 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEBvWUJVH0xe for ; Sun, 4 Oct 2015 11:32:38 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 698521B3487 for ; Sun, 4 Oct 2015 11:32:38 -0700 (PDT) Received: by qgez77 with SMTP id z77so133237437qge.1 for ; Sun, 04 Oct 2015 11:32:37 -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-type:content-transfer-encoding:message-id; bh=fVBq6Y4MLcn5am1mCIdRRWP9aQ10xWAyTl+OKgmNF0s=; b=FS/QoFZCSltGt6m1DxgAv3HsrlO2yJF9U5GxUEowhEgkJrnYNP/YW5Ap7bA3Q4jOX1 59ZElFwYHfa8tHdp5fYCiHh0zKVRHmgV/YELbo/ao9hh5diPPRgYI4cSChmVNfG5vB9o F6g8RBjUvbWU4+hGH6BUGuIAijNlDdwL90bi0ouAl1/QDJZOqIo8zZrdHgtPtD9EdYM4 pBtkVtDJru68wFseX4oj7AOArp+Ia8uMXiWQHlj/nMemzMhcuTvf8sKKjyRtqMY5MvUz vN/l7xaSp4Y3Ot9gWRH9Q564rupsYZzIJlZ/d/zrypKrKko/4sXEXfbVs4TCEZATJUg/ kkww== X-Received: by 10.140.19.175 with SMTP id 44mr33545299qgh.50.1443983557469; Sun, 04 Oct 2015 11:32:37 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id c7sm9501262qgc.2.2015.10.04.11.32.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 04 Oct 2015 11:32:36 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, noloader@gmail.com Date: Sun, 4 Oct 2015 14:32:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510041432.35903.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 18:32:39 -0000 On Sunday, October 04, 2015 01:58:09 pm Jeffrey Walton wrote: > Is that necessarily true? It should be apparent by now that the dominant opinion is that compression in TLS is not worth the risk and not worth the time to attempt to deal with here. Whether or not a generic compression algorithm could theoretically be made safe is irrelevant at this point. It's a known-dangerous attack surface that we don't want the risk of. Dave From nobody Sun Oct 4 11:54:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737D91B3496 for ; Sun, 4 Oct 2015 11:54: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xdTsUuGFLeD for ; Sun, 4 Oct 2015 11:54:00 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 C659C1B2D8D for ; Sun, 4 Oct 2015 11:48:19 -0700 (PDT) Received: by igcrk20 with SMTP id rk20so47564622igc.1 for ; Sun, 04 Oct 2015 11:48:19 -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:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=hu3X+zcIt/pnobfTiUKDaqSHWOCqiQrg+/RmcBZ4HHw=; b=0Dgyb671y4H1kqIgaBqPIiBZfy3QebecMrqWaGHFJlgKv8sUYLDGFwFL+uA7PeL6Ke ZVC7wfY8QLIXBls/7Agr6AXX1eX/BxIpI2xfaSPRKa6va/Tg1BTVSNauFHUSnwrhjqqw QLw2fEHSK9y516hvT0A3JEBtcJXgzgMExcKBTo5HM0hKlKQaiNPwZ7EXHYZ5QA22/v1G ZbZlx7/ynwLodFvdifDuK2ROQKlGllJWWVJep/zrUTH5SnGi8zHwJRrOM3ctWTfKaoPh WyE0EL/lYphP3Vo5HYWjgORiw+KgLvzD6P9e+UXFDtnQtGL3YUn3ShY62s7zTVBtMDNT nVwg== MIME-Version: 1.0 X-Received: by 10.50.66.137 with SMTP id f9mr5897781igt.22.1443984499308; Sun, 04 Oct 2015 11:48:19 -0700 (PDT) Received: by 10.36.123.131 with HTTP; Sun, 4 Oct 2015 11:48:19 -0700 (PDT) In-Reply-To: <201510041432.35903.davemgarrett@gmail.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041432.35903.davemgarrett@gmail.com> Date: Sun, 4 Oct 2015 14:48:19 -0400 Message-ID: From: Jeffrey Walton To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 04 Oct 2015 18:54:01 -0000 On Sun, Oct 4, 2015 at 2:32 PM, Dave Garrett wrote= : > On Sunday, October 04, 2015 01:58:09 pm Jeffrey Walton wrote: >> Is that necessarily true? > > It should be apparent by now that the dominant opinion is that compressio= n in TLS is not worth the risk and not worth the time to attempt to deal wi= th here. Whether or not a generic compression algorithm could theoretically= be made safe is irrelevant at this point. It's a known-dangerous attack su= rface that we don't want the risk of. > If I am reading things correctly: the group has effectively encountered a security problem, deemed it to be too hard for them, and then pushed it into another layer where folks are even less equipped to deal with it. Is that correct? I might be missing something, but I don't believe the "problems created by compression" have gone away. Rather, they have been moved around so the risk remains. The underlying problem still exists because the group responsible for providing those security services have not addressed them. Jeff From nobody Sun Oct 4 11:54:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A262E1B349A for ; Sun, 4 Oct 2015 11:54:13 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XinjE0l0PeSg for ; Sun, 4 Oct 2015 11:54:12 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 BB6BB1B2DD6 for ; Sun, 4 Oct 2015 11:50:26 -0700 (PDT) Received: by qgez77 with SMTP id z77so133416670qge.1 for ; Sun, 04 Oct 2015 11:50:26 -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-type:content-transfer-encoding:message-id; bh=LLHKE7RW1BcotiCHbvQ40M6uQq5dOmr2mJf8qi4D2sQ=; b=YQb7ePySiDk2bf54pogog7p3tV484wr+OSYwjOUrACPPmix5Lmsu4RZKLat56BI7wf Q7P/ZLeWw+GBGXzH8I4i6unNb0Oy2ceSuaq9q6qyTME1eXx2f909RArdLBY4ssQDaGi1 sKUU1Oeic8PRnQTvJj5U7rCP459KmCQCB27wf82/eaT5OCQr7e4V0WaPTvf1TqTOwdAY onTQiQCdNlIQgz8yKH2VHo6fRxYBDEckq+sW3mvcdurcm3DXUIo/D5tUBLE7XjQUbGzt 9t5QeB2I6Y1ynFGb3K0/0+XIPYtozrmAyXHU6/59mXZyTX3UCaj/EnBs+JR5ZJ9iCgIj bY4Q== X-Received: by 10.141.28.2 with SMTP id f2mr36141491qhe.59.1443984626004; Sun, 04 Oct 2015 11:50:26 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id e6sm9525522qga.14.2015.10.04.11.50.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 04 Oct 2015 11:50:25 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Tony Arcieri Date: Sun, 4 Oct 2015 14:50:24 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201510041450.24540.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 18:54:13 -0000 On Sunday, October 04, 2015 02:09:49 pm Tony Arcieri wrote: > If someone has produced a secure system for "compression side-channel > resistant encryption", I haven't seen it. I can think of a way to do this, but the people who want compression badly probably won't like it due to the need to pad heavily. 1) Pick a fixed bandwidth 2) Compress & encrypt the stream 3) Send the compressed stream at a rate blocked to the cap 4) Whenever below the cap, pad the stream to the cap Maintain a fixed transmission of data per unit time and there's no way to tell the size of anything (even if delivery doesn't match the rate). However, this relies on being able to pick a usable fixed bandwidth (in each direction). The bandwidth cap size and length of transmission times still gives quite a bit of info, e.g. 1GB vs 1KB total is quite telling, but that's true without compression. With a good compression algorithm, the above could probably produce an overall more efficient stream rather easily for many things. If your idea of compression is to keep using DEFLATE forever, however, you should probably just reevaluate what you're doing. Dave From nobody Sun Oct 4 11:55:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31A01B3492 for ; Sun, 4 Oct 2015 11:55:27 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FGtqMd6zqmv for ; Sun, 4 Oct 2015 11:55:26 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::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 4D0C31B347B for ; Sun, 4 Oct 2015 11:55:26 -0700 (PDT) Received: by qgt47 with SMTP id 47so133237616qgt.2 for ; Sun, 04 Oct 2015 11:55:25 -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-type:content-transfer-encoding:message-id; bh=+U+dhj5SJHWtLn5O6l615g4Vy0OL5wo0kR3teS+KCuI=; b=AkC3TTWolpIJXrYYOPd5Agom5jUaittYc45RUuKYlxmx8QKqKQUsLBxsz0b2nT0KiG GLf1DWUoH3zMDg2uIOpRyfzZboXVsMyLfDgF+Ph9tE1crI7uEoaycH7eUCOjOfTyGpgk bAcDGl0VVxI9OO8wkmJir3b+b2IXvqShlcnyLyU8e0N0PooVTOC4jNEVdYRDZV49iLY8 8A6VBXaIshAug+Ov/i3TblJ90+q5vmNY5O43tWxDZ3eRlmJQgQCJY2zEZxs3PU/D6w60 aUf9wl8ixCNPfrpUkLOlvi3oKtWc9kULl756dOu0nLvAsO7AAU9WD2HRlp7Xwe+eREgX VLNw== X-Received: by 10.140.32.200 with SMTP id h66mr32933358qgh.99.1443984925550; Sun, 04 Oct 2015 11:55:25 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id h89sm9525621qgh.33.2015.10.04.11.55.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 04 Oct 2015 11:55:24 -0700 (PDT) From: Dave Garrett To: noloader@gmail.com Date: Sun, 4 Oct 2015 14:55:23 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041432.35903.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201510041455.24050.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 18:55:27 -0000 On Sunday, October 04, 2015 02:48:19 pm Jeffrey Walton wrote: > If I am reading things correctly: the group has effectively > encountered a security problem, deemed it to be too hard for them, and > then pushed it into another layer where folks are even less equipped > to deal with it. Is that correct? > > I might be missing something, but I don't believe the "problems > created by compression" have gone away. Rather, they have been moved > around so the risk remains. The underlying problem still exists > because the group responsible for providing those security services > have not addressed them. TLS & SPDY + HTTP compression was broken due to CRIME. The fix was to disable it, and then HTTP/2 introduced HPACK to compress headers safely. Yes, the security issue has been moved around, but to a place that can actually fix it properly. There is nothing TLS could do to implement a fix like HPACK here. I don't claim this is the only way to fix this problem, but it is a straightforward one and the one that is being done. Dave From nobody Sun Oct 4 12:00:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF741B34A8 for ; Sun, 4 Oct 2015 12:00:56 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ8-FijaqnF0 for ; Sun, 4 Oct 2015 12:00:54 -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 D6D331A1F70 for ; Sun, 4 Oct 2015 12:00:53 -0700 (PDT) Received: by ioii196 with SMTP id i196so165392728ioi.3 for ; Sun, 04 Oct 2015 12:00:53 -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-type; bh=z2Zq90Fk/9IdfVPy/Qw5ZnphJpDHjFgstRkAZQMv70o=; b=R0UaMapKQ5oBn0UqxtNyYO+i/kfTCFyaAZBsUohsUW7bAc/k6SbjdGmoBfNHh67OwD lpDe1Zh9WX9bhRwAo0AqG9ajhYwyT4+/s49IzF9v7raDGVwurE83264WxMSYDh7zkB0x tx0bSbMgkQ6okeXz9mJ1Nd98oT5x/mLUWIp/offtL45zqomdjzGPWj67jsIEvCDYyuMN EyQQT19HiHrLaJGRPeYSqvG1wAf1Z2ipTmsG3hCPqbKcHVIYszltn19KPtSXJMLsdUrm JfNvu6gUGcig9rCcW9ijcS8cENxpGs0w68Y1k6VDvOUtzo2Ac2zOCbESYSwM8xwJVxYa rqrQ== X-Received: by 10.107.128.41 with SMTP id b41mr24795910iod.74.1443985253288; Sun, 04 Oct 2015 12:00:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.19.67 with HTTP; Sun, 4 Oct 2015 12:00:33 -0700 (PDT) In-Reply-To: <201510041450.24540.davemgarrett@gmail.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041450.24540.davemgarrett@gmail.com> From: Tony Arcieri Date: Sun, 4 Oct 2015 12:00:33 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113f8bf015575f05214c04d2 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 19:00:56 -0000 --001a113f8bf015575f05214c04d2 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 4, 2015 at 11:50 AM, Dave Garrett wrote: > I can think of a way to do this, but the people who want compression badly > probably won't like it due to the need to pad heavily. > > 1) Pick a fixed bandwidth > 2) Compress & encrypt the stream > 3) Send the compressed stream at a rate blocked to the cap > 4) Whenever below the cap, pad the stream to the cap > > Maintain a fixed transmission of data per unit time and there's no way to > tell the size of anything (even if delivery doesn't match the rate). This sounds like Constant Bitrate (CBR) compression, which works for encrypted media (e.g. encrypted voice and video), but probably isn't particularly useful outside the realm of realtime media. It was a solution that seems to work for attacks that could e.g. transcribe encrypted phone calls by studying patterns in Variable Bitrate (VBR) compression on speech. Typically compression is used to lower the overall size of data, working on a wide class of inputs. In the perceptual coding case the class of inputs is constrained, and the goal is to keep the data rate constant, not optimally small. -- Tony Arcieri --001a113f8bf015575f05214c04d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Oct 4, 2015 at 11:50 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
I can think of a way to do this, but the people who wan= t compression badly probably won't like it due to the need to pad heavi= ly.

1) Pick a fixed bandwidth
2) Compress & encrypt the stream
3) Send the compressed stream at a rate blocked to the cap
4) Whenever below the cap, pad the stream to the cap

Maintain a fixed transmission of data per unit time and there's no way = to tell the size of anything (even if delivery doesn't match the rate).=

This sounds like Constant Bitrate (CBR) co= mpression, which works for encrypted media (e.g. encrypted voice and video)= , but probably isn't particularly useful outside the realm of realtime = media. It was a solution that seems to work for attacks that could e.g. tra= nscribe encrypted phone calls by studying patterns in Variable Bitrate (VBR= ) compression on speech.

Typically compression is = used to lower the overall size of data, working on a wide class of inputs. = In the perceptual coding case the class of inputs is constrained, and the g= oal is to keep the data rate constant, not optimally small.

--
Tony Arcieri
--001a113f8bf015575f05214c04d2-- From nobody Sun Oct 4 12:27:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06CA1A6FB6 for ; Sun, 4 Oct 2015 12:27:09 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlGsUVgoUL33 for ; Sun, 4 Oct 2015 12:27:08 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 712D21A21C0 for ; Sun, 4 Oct 2015 12:27:08 -0700 (PDT) Received: by qgt47 with SMTP id 47so133565500qgt.2 for ; Sun, 04 Oct 2015 12:27:07 -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-type:content-transfer-encoding:message-id; bh=swUu1P98lhUY9Ex2eggxuEhiPIwXSfKodRVpQbEL2g4=; b=M65eWaG8pSkMIJxRc4ccXjkTwGbzUfVTVpXA/MEfcN1c9ZrG55enNERRUit4ggHekY /rg7zjzs/sPImxAVmLGZWCLuv8xCG2bhiWAypZeS7Tr1AjGsK+b0GepOxHL0aBkHhm5B ayv2TWw+x71t322Uko6483mu7RQxdoseYMUdXXFsII796zUwaqsQfTIMOfI7yCc1HSBU L67YyrL8sNmEjqPID0Ij+zohPkYwwE3uGg9ljIsJWAaslYsvydqYr0Kt+5QtWD6RZ6tf oVAMyv4cPABSP5OQMqIE+5Y+SFgWbc8U6/EMy1kgh+H3Qa0714bRcNU/e22FmoxIXr2c 4H/g== X-Received: by 10.140.27.130 with SMTP id 2mr34973774qgx.72.1443986827296; Sun, 04 Oct 2015 12:27:07 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w78sm9574849qge.42.2015.10.04.12.27.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 04 Oct 2015 12:27:06 -0700 (PDT) From: Dave Garrett To: Tony Arcieri Date: Sun, 4 Oct 2015 15:27:04 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041450.24540.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201510041527.04800.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 19:27:10 -0000 On Sunday, October 04, 2015 03:00:33 pm Tony Arcieri wrote: > On Sun, Oct 4, 2015 at 11:50 AM, Dave Garrett > wrote: > > I can think of a way to do this, but the people who want compression badly > > probably won't like it due to the need to pad heavily. > > > > 1) Pick a fixed bandwidth > > 2) Compress & encrypt the stream > > 3) Send the compressed stream at a rate blocked to the cap > > 4) Whenever below the cap, pad the stream to the cap > > > > Maintain a fixed transmission of data per unit time and there's no way to > > tell the size of anything (even if delivery doesn't match the rate). > > This sounds like Constant Bitrate (CBR) compression, which works for > encrypted media (e.g. encrypted voice and video), but probably isn't > particularly useful outside the realm of realtime media. It was a solution > that seems to work for attacks that could e.g. transcribe encrypted phone > calls by studying patterns in Variable Bitrate (VBR) compression on speech. > > Typically compression is used to lower the overall size of data, working on > a wide class of inputs. In the perceptual coding case the class of inputs > is constrained, and the goal is to keep the data rate constant, not > optimally small. Yep. You could do this in bursts with different caps each time to get it to work with bursty things like HTTP & other general data transfer protocols. Without a really good modern compression algorithm, though, it isn't that appealing. Once these caveats and tweaks start getting added to the simple concept, it starts treading into the territory that is better handled by the application protocol that actually *knows what it's sending*. This seems to be the logical wall we keep hitting, which is why TLS doesn't seem like the place to do this. Maybe some new transport protocol could be fed information to tell it how to handle compression safely, but TLS is not a transport protocol nor a young one that can be fundamentally changed to accommodate everything. Dave From nobody Sun Oct 4 13:01:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36E71A00BF for ; Sun, 4 Oct 2015 13:01:16 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F9XyI28bowx for ; Sun, 4 Oct 2015 13:01:15 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 6CFDD1A00BE for ; Sun, 4 Oct 2015 13:01:15 -0700 (PDT) Received: by igbni9 with SMTP id ni9so45372579igb.0 for ; Sun, 04 Oct 2015 13:01:14 -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:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=nIW+mvOZUhKHFN/4MgnpID+MuGZVyYW6Ef0COm+X0TU=; b=HyD6flsSBCbaJIhQ51eRho+zQnk3H+nMDKjbmtstBewmO3J7IzsQnNnvEaVppqd5Md MFvGtC24gh2UkSaZB6i4hNJ9OkgNsR45nSXTOWkIK0aqkapcFMzMiNh7U8D0pOlb3mQB 03nrMOVfQILO8MLUyotFSTilrjRr5E+U7El0H38apRM47p6bpaFEzVZMWs+Sh0+427G9 rI2Qnj6jMGZfj3rtktnNgql1FXkoL9Di+NX0Ex2PHPDRL3p43Q6YlZrX8LRiJ0rKJvBn aB+97du85e1VEUZPCXznHpXz46Y4qGQFm3b0GQc8bUFoUVkgP1jGChPaHu9oyyk/pUB0 rqcQ== MIME-Version: 1.0 X-Received: by 10.50.124.2 with SMTP id me2mr7079522igb.46.1443988874760; Sun, 04 Oct 2015 13:01:14 -0700 (PDT) Received: by 10.36.123.131 with HTTP; Sun, 4 Oct 2015 13:01:14 -0700 (PDT) In-Reply-To: <201510041527.04800.davemgarrett@gmail.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041450.24540.davemgarrett@gmail.com> <201510041527.04800.davemgarrett@gmail.com> Date: Sun, 4 Oct 2015 16:01:14 -0400 Message-ID: From: Jeffrey Walton To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 04 Oct 2015 20:01:16 -0000 >> Typically compression is used to lower the overall size of data, working= on >> a wide class of inputs. In the perceptual coding case the class of input= s >> is constrained, and the goal is to keep the data rate constant, not >> optimally small. > > Yep. You could do this in bursts with different caps each time to get it = to work with bursty things like HTTP & other general data transfer protocol= s. Without a really good modern compression algorithm, though, it isn't tha= t appealing. Once these caveats and tweaks start getting added to the simpl= e concept, it starts treading into the territory that is better handled by = the application protocol that actually *knows what it's sending*. This seem= s to be the logical wall we keep hitting, which is why TLS doesn't seem lik= e the place to do this. > I think two concepts are blending into one.... You appear to be arguing for efficiency, and I'm more concerned with safely/securely. I'm fairly certain the internet community at large would benefit from "compression done safely/securely", even if its not the most efficient. If the application layer wants to provide a more efficient implementations, then that's fine too. I think this I where things now stand (if I am surveying correctly): (1) TLS WG did not fix the problem (bad); (2) users don't have a choice (bad); (3) applications will have to provide their own compression when desired, which will likely increase overall risk for users (bad). For (3) keep in mind browsers are not the only user agents or consumers of web services. All-in-all, I think its a win for NSA, GCHQ and other miscreants; and an overall loss for user. Jeff From nobody Sun Oct 4 13:10:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985541A1B29 for ; Sun, 4 Oct 2015 13:10:52 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqx8zaD2rvno for ; Sun, 4 Oct 2015 13:10:51 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c: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 A6BA11A1B2B for ; Sun, 4 Oct 2015 13:10:50 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so89228766wic.1 for ; Sun, 04 Oct 2015 13:10: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:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=53pkuYWow8+x6mYjg0z9I5k4JDVL+r24yJpcgvXdJC4=; b=tz0keRqLO3f7f0KgJDBzoMM0i4XslUDM0QeX1fcFneDmEvYscK+OXGHnd7cGpldi42 yrUfhQ6mWV4V0rjb6Q+UlDWkvQOnTQiEtmPbVbw9JvetW+HFc9TBylI3JJoJMa9BrVAg mKbPg4BuGFiEw6WfPXgvDYgeNWAenActXNyZG2nK/mvwuVhlYdhrI5sq+KVcqhmZXxXt 67YBeDCzLl82HNZ/kEUBrTKfo9EDHEe+N6stoA/oJjQQ1ciB8v6p0OSOcbeRbKypfqYI 1pvregSZKmpY1HaivtglDYeeSBK07UX30G4AhbXxOnUec4/4/GAKnPozhG6oFIC9m+rT uXqg== MIME-Version: 1.0 X-Received: by 10.180.198.142 with SMTP id jc14mr8370408wic.32.1443989449196; Sun, 04 Oct 2015 13:10:49 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Sun, 4 Oct 2015 13:10:48 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041450.24540.davemgarrett@gmail.com> <201510041527.04800.davemgarrett@gmail.com> Date: Sun, 4 Oct 2015 16:10:48 -0400 Message-ID: From: Watson Ladd To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 20:10:52 -0000 On Sun, Oct 4, 2015 at 4:01 PM, Jeffrey Walton wrote: >>> Typically compression is used to lower the overall size of data, workin= g on >>> a wide class of inputs. In the perceptual coding case the class of inpu= ts >>> is constrained, and the goal is to keep the data rate constant, not >>> optimally small. >> >> Yep. You could do this in bursts with different caps each time to get it= to work with bursty things like HTTP & other general data transfer protoco= ls. Without a really good modern compression algorithm, though, it isn't th= at appealing. Once these caveats and tweaks start getting added to the simp= le concept, it starts treading into the territory that is better handled by= the application protocol that actually *knows what it's sending*. This see= ms to be the logical wall we keep hitting, which is why TLS doesn't seem li= ke the place to do this. >> > I think two concepts are blending into one.... You appear to be > arguing for efficiency, and I'm more concerned with safely/securely. > > I'm fairly certain the internet community at large would benefit from > "compression done safely/securely", even if its not the most > efficient. If the application layer wants to provide a more efficient > implementations, then that's fine too. > > I think this I where things now stand (if I am surveying correctly): > (1) TLS WG did not fix the problem (bad); (2) users don't have a > choice (bad); (3) applications will have to provide their own > compression when desired, which will likely increase overall risk for > users (bad). For (3) keep in mind browsers are not the only user > agents or consumers of web services. > > All-in-all, I think its a win for NSA, GCHQ and other miscreants; and > an overall loss for user. As we've tried to explain to you, TLS is a channel encryption abstraction, and does not know which parts of the stream of bytes it is being asked to send are controlled by who. Absent this information, there is no way to know what can be compressed how. By contrast applications know this information, and can design the compression scheme accordingly. How does this increase risk over TLS providing an inappropriate scheme which isn't secure? > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Oct 4 13:16:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7261A1B96 for ; Sun, 4 Oct 2015 13:16:30 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwgtKOt-F3-8 for ; Sun, 4 Oct 2015 13:16:29 -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 EACD31A1B8C for ; Sun, 4 Oct 2015 13:16:28 -0700 (PDT) Received: by iofh134 with SMTP id h134so166917644iof.0 for ; Sun, 04 Oct 2015 13:16:28 -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-type; bh=ocBoMqG5IMG0t/GVHyEZB6roDaV7aGUkYiEWOhc/sZ0=; b=K8uXB5cFu/nGTUpfDzfQacJYY1SDad9owpU7iLZpw6awQl2uRy44RoFiEqhq1Hh6qP IXYwXDbZlLnRSGH7+kdelj6q39arBK1jxiq48+GQctnf1l/ZTq6r0c28PFR3HjaLnSgf 9hFeS5rIGEHHz2MnYIAR4irccE/0hlEe+dU8UlfnTAeYUez/AHiI3RLn++v9/AMOndxl Qd637XWZ2OXBlQG2BgKnyF/FC9rFHlZS8Z50kIboeT/qOe3YRRl0Fv6kLu0H5wOVlGqR p/y00VKEu1H7j2wzirdoOyd2PHtBP8IU83FAzhsbP/ipky+4RNdzAxdL4s/rXDwwp4Vc EItA== X-Received: by 10.107.130.220 with SMTP id m89mr25714724ioi.146.1443989788347; Sun, 04 Oct 2015 13:16:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.19.67 with HTTP; Sun, 4 Oct 2015 13:16:08 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041450.24540.davemgarrett@gmail.com> <201510041527.04800.davemgarrett@gmail.com> From: Tony Arcieri Date: Sun, 4 Oct 2015 13:16:08 -0700 Message-ID: To: Jeffrey Walton Content-Type: multipart/alternative; boundary=001a113eee3c64d52505214d12af Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 20:16:30 -0000 --001a113eee3c64d52505214d12af Content-Type: text/plain; charset=UTF-8 On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton wrote: > >> Typically compression is used to lower the overall size of data, > working on > >> a wide class of inputs. In the perceptual coding case the class of > inputs > >> is constrained, and the goal is to keep the data rate constant, not > >> optimally small. > > > > Yep. You could do this in bursts with different caps each time to get it > to work with bursty things like HTTP & other general data transfer > protocols. Without a really good modern compression algorithm, though, it > isn't that appealing. Once these caveats and tweaks start getting added to > the simple concept, it starts treading into the territory that is better > handled by the application protocol that actually *knows what it's > sending*. This seems to be the logical wall we keep hitting, which is why > TLS doesn't seem like the place to do this. > > > I think two concepts are blending into one.... You appear to be > arguing for efficiency, and I'm more concerned with safely/securely. > No, you're just not following the conversation or understanding the concepts. > I'm fairly certain the internet community at large would benefit from > "compression done safely/securely", even if its not the most > efficient. If the application layer wants to provide a more efficient > implementations, then that's fine too. Doing compression safely/securely is an application-specific problem. Using constant bitrate perceptual coding allows us to compress audio/video streams in such a way that there is no compression side-channel, because the data rate is kept constant per unit time. If we were to try to use TLS compression instead, not only would it fail to compress as well, but it would have a compression side-channel an attacker could use to potentially recover a transcript of an encrypted conversation (such attacks against against VBR audio compression). TLS is the wrong layer at which to solve the problem of compression. -- Tony Arcieri --001a113eee3c64d52505214d12af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Oct 4, 2015 at 1:01 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>> Typically compression is used to lower t= he overall size of data, working on
>> a wide class of inputs. In the perceptual coding case the class of= inputs
>> is constrained, and the goal is to keep the data rate constant, no= t
>> optimally small.
>
> Yep. You could do this in bursts with different caps each time to get = it to work with bursty things like HTTP & other general data transfer p= rotocols. Without a really good modern compression algorithm, though, it is= n't that appealing. Once these caveats and tweaks start getting added t= o the simple concept, it starts treading into the territory that is better = handled by the application protocol that actually *knows what it's send= ing*. This seems to be the logical wall we keep hitting, which is why TLS d= oesn't seem like the place to do this.
>
I think two concepts are blending into one.... You appear to be
arguing for efficiency, and I'm more concerned with safely/securely.

No, you're just not following the con= versation or understanding the concepts.
=C2=A0
I'm fairly certain the internet community at large w= ould benefit from
"compression done safely/securely", even if its not the most
efficient. If the application layer wants to provide a more efficient
implementations, then that's fine too.

= Doing compression safely/securely is an application-specific problem.
=

Using constant bitrate perceptual coding allows us to c= ompress audio/video streams in such a way that there is no compression side= -channel, because the data rate is kept constant per unit time.
<= br>
If we were to try to use TLS compression instead, not only wo= uld it fail to compress as well, but it would have a compression side-chann= el an attacker could use to potentially recover a transcript of an encrypte= d conversation (such attacks against against VBR audio compression).
<= /div>

TLS is the wrong layer at which to solve the probl= em of compression.

--
Tony Arcieri
--001a113eee3c64d52505214d12af-- From nobody Sun Oct 4 13:18:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C3A1A1B34 for ; Sun, 4 Oct 2015 13:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8jnCQEFJ68m for ; Sun, 4 Oct 2015 13:18:17 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.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 A59901A00DB for ; Sun, 4 Oct 2015 13:18:16 -0700 (PDT) Received: by wicge5 with SMTP id ge5so94396545wic.0 for ; Sun, 04 Oct 2015 13:18:15 -0700 (PDT) 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-type; bh=y7znLVpNp8H4UNuW4mR4IvdgAJ1q1JUQa3Fnwx9U06E=; b=IJjemytlrYAro7cKnsn0Gvka1ZCiURmz4bzRMpHgHp69GwTwNYTqsBFJm6xW1JVAUT GcbVqeUatsXIIFUMSjnyzjxegOJ+lx8iO7jV22NlFjC9AzR1PDFzEjY31cWs5DaktNyd N5HkuATaAHv1aG620n4GyOM3+m+YGq/CSsLJgOYxVfZLgfF6tisxLmJMs52xK/Uqb99i bWB630+5z1ibmsRMzcTvcQt1lSzPVfjk2zWnrfzvWb/HdqkbOkxm/l6xuHd2NyRbBJKq BkhK3LoY7/MyyH0jgk1limG0JN11iCdwPULV/vo9SsLcEb2eyqp5Q9x+EQfWEPbu/kZJ 4Cng== X-Gm-Message-State: ALoCoQlNOuViwwB+0lvfbg2IehXG9LVHDZjX1iTfyiKiWtr47NFQ13BPwBtMMZ0POaVA4VZScYM4 X-Received: by 10.180.106.98 with SMTP id gt2mr8115220wib.31.1443989895207; Sun, 04 Oct 2015 13:18:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Sun, 4 Oct 2015 13:17:35 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041450.24540.davemgarrett@gmail.com> <201510041527.04800.davemgarrett@gmail.com> From: Eric Rescorla Date: Sun, 4 Oct 2015 13:17:35 -0700 Message-ID: To: noloader@gmail.com Content-Type: multipart/alternative; boundary=f46d04428f1cc3794405214d18a3 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Oct 2015 20:18:19 -0000 --f46d04428f1cc3794405214d18a3 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton wrote: > >> Typically compression is used to lower the overall size of data, > working on > >> a wide class of inputs. In the perceptual coding case the class of > inputs > >> is constrained, and the goal is to keep the data rate constant, not > >> optimally small. > > > > Yep. You could do this in bursts with different caps each time to get it > to work with bursty things like HTTP & other general data transfer > protocols. Without a really good modern compression algorithm, though, it > isn't that appealing. Once these caveats and tweaks start getting added to > the simple concept, it starts treading into the territory that is better > handled by the application protocol that actually *knows what it's > sending*. This seems to be the logical wall we keep hitting, which is why > TLS doesn't seem like the place to do this. > > > I think two concepts are blending into one.... You appear to be > arguing for efficiency, and I'm more concerned with safely/securely. > > I'm fairly certain the internet community at large would benefit from > "compression done safely/securely", even if its not the most > efficient. If the application layer wants to provide a more efficient > implementations, then that's fine too. > > I think this I where things now stand (if I am surveying correctly): > (1) TLS WG did not fix the problem (bad); (2) users don't have a > choice (bad); (3) applications will have to provide their own > compression when desired, which will likely increase overall risk for > users (bad). For (3) keep in mind browsers are not the only user > agents or consumers of web services. > The problem is that we don't know how to generically provide compression safely. To take a concrete example: HTTP2's solution to header compression, HPACK, is extremely limited compared to a generic compression system like gzip, LZ77, etc., as well as being tightly-coupled to HTTP, and yet we still know that there are potential security problems [0]. Doing something generically secure is much harder. If you have a solution to this problem, then great. But the mere fact that it's desirable doesn't mean we have an answer. -Ekr [0] Specifically, that the attacker can confirm specific guesses about the contents of a header field. > All-in-all, I think its a win for NSA, GCHQ and other miscreants; and > an overall loss for user. > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04428f1cc3794405214d18a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>= > Typically compression is used to lower the overall size of data, worki= ng on
>> a wide class of inputs. In the perceptual coding case the class of= inputs
>> is constrained, and the goal is to keep the data rate constant, no= t
>> optimally small.
>
> Yep. You could do this in bursts with different caps each time to get = it to work with bursty things like HTTP & other general data transfer p= rotocols. Without a really good modern compression algorithm, though, it is= n't that appealing. Once these caveats and tweaks start getting added t= o the simple concept, it starts treading into the territory that is better = handled by the application protocol that actually *knows what it's send= ing*. This seems to be the logical wall we keep hitting, which is why TLS d= oesn't seem like the place to do this.
>
I think two concepts are blending into one.... You appear to be
arguing for efficiency, and I'm more concerned with safely/securely.
I'm fairly certain the internet community at large would benefit from "compression done safely/securely", even if its not the most
efficient. If the application layer wants to provide a more efficient
implementations, then that's fine too.

I think this I where things now stand (if I am surveying correctly):
(1) TLS WG did not fix the problem (bad); (2) users don't have a
choice (bad); (3) applications will have to provide their own
compression when desired, which will likely increase overall risk for
users (bad). For (3) keep in mind browsers are not the only user
agents or consumers of web services.

Th= e problem is that we don't know how to generically provide compression<= /div>
safely. To take a concrete example: HTTP2's solution to heade= r compression,
HPACK, is extremely limited compared to a generic = compression system
like gzip, LZ77, etc., as well as being tightl= y-coupled to HTTP, and yet we
still know that there are potential= security problems [0]. Doing something
generically secure is muc= h harder.

If you have a solution to this problem, = then great. But the mere fact that it's
desirable doesn't= mean we have an answer.

-Ekr

=
[0] Specifically, that the attacker can confirm specific guesses about= the contents
of a header field.


=C2=A0
All-in-all, I think its a win for NSA, GCHQ and other miscreants; and
an overall loss for user.

Jeff

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

--f46d04428f1cc3794405214d18a3-- From nobody Sun Oct 4 18:28:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64E01B3D59 for ; Sun, 4 Oct 2015 18:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qlc1agxlaHq8 for ; Sun, 4 Oct 2015 18:28:03 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 43E721B3D57 for ; Sun, 4 Oct 2015 18:28:02 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 411D4200056; Mon, 5 Oct 2015 01:28:02 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 2B45020003C; Mon, 5 Oct 2015 01:28:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444008482; bh=sxd16knMQFgjwqvYwLcTDfpjakOvw4Ea4W8r6Yr2WPU=; l=694; h=From:To:CC:Date:References:In-Reply-To:From; b=HHOsnN0QNmnjGxPyhl8BluzHzdYHVbPVExFT/0p5SlE+iIzp85QgPsPtsuga0kAm9 xj0YOgHhQoKrpv/V2wYGF+hzqn7efVHxHnSroYsFy/xvO+qYxH04Y9L1sPPjBXB8Cx VZM7tAVGCKnA+kPS2hdqx+8CriwEQSv6gqzKc/LM= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 283A99808A; Mon, 5 Oct 2015 01:28:02 +0000 (GMT) Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 4 Oct 2015 20:28:01 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1076.000; Sun, 4 Oct 2015 20:28:01 -0500 From: "Salz, Rich" To: Yoav Nir , takamichi saito Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed Thread-Index: AQHQ8kBAS4S1zYgQwkGNXxwEQUlpup5CsHewgABfN4CAFYZrAP//wsRwgAJwioCAABOVAIABWGgg Date: Mon, 5 Oct 2015 01:28:01 +0000 Message-ID: <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> 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.33.0] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2015 01:28:05 -0000 PiBUaGVyZSBhcmUgbWFueSBsZXNzb25zIHRvIGJlIGxlYXJuZWQgZnJvbSB0aGlzOiB0aGF0IGEg YmVhcmVyIHRva2VuIHRoYXQgaXMNCj4gcmVwZWF0ZWQgbWFueSB0aW1lcyBpcyBub3QgYSBnb29k IGlkZWE7IHRoYXQgdGhlIHRydXN0IG1vZGVsIGluIHRoZSB3ZWIgaXMNCj4gbm90IGdyZWF0OyBi dXQgYWxzbyB0aGF0IGJsaW5kbHkgY29tcHJlc3NpbmcgY29udGVudCB3aXRoIG5vIHJlZ2FyZCB0 byBpdHMNCj4gc3RydWN0dXJlIGFuZCBzb3VyY2VzIGlzIGRhbmdlcm91cyBhbmQgcmV2ZWFscyBp bmZvcm1hdGlvbiBhYm91dCB0aGUNCj4gY2xlYXJ0ZXh0LiAgQSBzZWN1cml0eSBwcm90b2NvbCBz aG91bGQgbm90IGRvIHRoYXQuDQoNClRoaXMgaXMgYSBncmVhdCBub3RlLCBhbmQgZXhjZWxsZW50 IGV4cGxhbmF0aW9uLg0KDQotLSAgDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9n aWVzDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg0K From nobody Sun Oct 4 19:19:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5738C1B3F24 for ; Sun, 4 Oct 2015 19:19:18 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXHU9xPl0uee for ; Sun, 4 Oct 2015 19:19:17 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 092B91B3F21 for ; Sun, 4 Oct 2015 19:19:17 -0700 (PDT) Received: by iofh134 with SMTP id h134so171579696iof.0 for ; Sun, 04 Oct 2015 19:19:16 -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:date:message-id :subject:from:to:cc:content-type; bh=Fl7Bm5Cz/pPyxkH/nFNeMC6QgijlVWskBrFXz0eOd/Q=; b=BGFqCzRaC7G92SHq1Uwz/dFCakQec618k7jM8wGMYxVE1yEgI5djaCDxUuN3iDSm4O fRUJKkMtAyvkPf9iStM7zNZa9OR9Wwkkso9j10OSp95bJ51nX6xTx5RV9gQsUO98UrAA vo4lnOMvtk0+GoVK22nl0odKm/+a2GmcZXTYPsaPO6E4VPhANdoOjw+lhOFU5dzds7KQ 8COVAfYWC8NAYx3kMikB49z1jLToqFwM9xokbMt65GZaKNJLMeSM6QftnAkd/wY+zbol /XeDP9ljlqQ0cKm5utfsmwoosoPIJ847Bnx4XwdMmFVmcJZKcFs7KyMOZsWeR10PU1eN hVqw== MIME-Version: 1.0 X-Received: by 10.107.135.218 with SMTP id r87mr25983005ioi.153.1444011556401; Sun, 04 Oct 2015 19:19:16 -0700 (PDT) Received: by 10.36.123.131 with HTTP; Sun, 4 Oct 2015 19:19:16 -0700 (PDT) In-Reply-To: <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.com> Date: Sun, 4 Oct 2015 22:19:16 -0400 Message-ID: From: Jeffrey Walton To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 05 Oct 2015 02:19:18 -0000 On Sun, Oct 4, 2015 at 9:28 PM, Salz, Rich wrote: >> There are many lessons to be learned from this: that a bearer token that is >> repeated many times is not a good idea; that the trust model in the web is >> not great; but also that blindly compressing content with no regard to its >> structure and sources is dangerous and reveals information about the >> cleartext. A security protocol should not do that. > > This is a great note, and excellent explanation. I'm not sure about some of it (I'm not trying to be argumentative). If compression leaks information from a structured message, then surely an uncompressed message leaks the same information. As Kurt eloquently put it, only the density of the information changed. Naively, that means the encryption services are defective, and not compression. Or maybe I should back pedal and ask: when is it safe to use TLS with a structured message? Is it safe to use with HTTP? How about SMTP? If HTTP always sends the cookie in the same position in unique messages, then wouldn't that mean its not safe to use with HTTP over TLS? Perhaps I'm missing something obvious.... Jeff From nobody Sun Oct 4 19:26:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B311B3F66 for ; Sun, 4 Oct 2015 19:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7pS33MBr-QC for ; Sun, 4 Oct 2015 19:26:52 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 820E71B3F65 for ; Sun, 4 Oct 2015 19:26:52 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so99300982wic.1 for ; Sun, 04 Oct 2015 19:26:51 -0700 (PDT) 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-type; bh=YsOpz/RRqwPq1t/lVJTUsgUXGUBpW/40xJMAcSiMg00=; b=hwGDVLLHmm3zNWBqP0UZAj0ec0AUQnkRIs1hR2DDqLoB1nINVis+Y/WJW7KNOfgRD+ xp7q9SbdiRQDdNX70S5JaVrkIUcfVa5m4VQJ9uMSmcFCPxfwnlS2x4j1ofy40mHya+QI pJMMpsiwpTouyrAAIwI/JtIb7jdPbngT8qXz9VecwI/sqAmqhc2qhBADmPgmBh9rehR+ lv5uuU2vF0oCOrhAWUPR6wNVVCXl3uFRbbYXSscdLsUqR0/+/Cg74Na2w+APImTKt9TR 1FfzwuOdRfArwu8wx33DrBvXs7hoGdCyPVWWUd9yef0sDPgNlBTv/m7V9w3BqXd6U+TK Gm8A== X-Gm-Message-State: ALoCoQlRBq5WayODlo4xBZgqzoWdbAxnOUVpLo/rdmO9QfxBL7nU+WXnSqs/l9p7iUZLitGxhib0 X-Received: by 10.194.94.71 with SMTP id da7mr27700785wjb.8.1444012011118; Sun, 04 Oct 2015 19:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Sun, 4 Oct 2015 19:26:11 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.com> From: Eric Rescorla Date: Sun, 4 Oct 2015 19:26:11 -0700 Message-ID: To: noloader@gmail.com Content-Type: multipart/alternative; boundary=047d7bf0c102f979de0521523e35 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2015 02:26:54 -0000 --047d7bf0c102f979de0521523e35 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 4, 2015 at 7:19 PM, Jeffrey Walton wrote: > On Sun, Oct 4, 2015 at 9:28 PM, Salz, Rich wrote: > >> There are many lessons to be learned from this: that a bearer token > that is > >> repeated many times is not a good idea; that the trust model in the web > is > >> not great; but also that blindly compressing content with no regard to > its > >> structure and sources is dangerous and reveals information about the > >> cleartext. A security protocol should not do that. > > > > This is a great note, and excellent explanation. > > I'm not sure about some of it (I'm not trying to be argumentative). > > If compression leaks information from a structured message, then > surely an uncompressed message leaks the same information. No, not when they are encrypted. Consider the trivial case of ASCII text. Each character takes up the same amount of room, but if you compress (as an intuition pump, think of a simple Huffman code), then more common characters take up less room than less common characters. For a more complicated case, see: http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf -Ekr > As Kurt > eloquently put it, only the density of the information changed. > Naively, that means the encryption services are defective, and not > compression. > > Or maybe I should back pedal and ask: when is it safe to use TLS with > a structured message? Is it safe to use with HTTP? How about SMTP? If > HTTP always sends the cookie in the same position in unique messages, > then wouldn't that mean its not safe to use with HTTP over TLS? > > Perhaps I'm missing something obvious.... > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bf0c102f979de0521523e35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 4, 2015 at 7:19 PM, Jeffrey Walton <noloader@gmail.com> wrote:
On Sun, Oct 4, 2015 at 9:28 P= M, Salz, Rich <rsa= lz@akamai.com> wrote:
>> There are many lessons to be learned from this: that a bearer toke= n that is
>> repeated many times is not a good idea; that the trust model in th= e web is
>> not great; but also that blindly compressing content with no regar= d to its
>> structure and sources is dangerous and reveals information about t= he
>> cleartext.=C2=A0 A security protocol should not do that.
>
> This is a great note, and excellent explanation.

I'm not sure about some of it (I'm not trying to be argument= ative).

If compression leaks information from a structured message, then
surely an uncompressed message leaks the same information.

No, not when they are encrypted.

C= onsider the trivial case of ASCII text. Each character takes up the
same amount of room, but if you compress (as an intuition pump,
think of a simple Huffman code), then more common characters
ta= ke up less room than less common characters.

For a= more complicated case, see:

-Ekr
= =C2=A0



=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> As Kurt
eloquently put it, only the density of the information changed.
Naively, that means the encryption services are defective, and not
compression.

Or maybe I should back pedal and ask: when is it safe to use TLS with
a structured message? Is it safe to use with HTTP? How about SMTP? If
HTTP always sends the cookie in the same position in unique messages,
then wouldn't that mean its not safe to use with HTTP over TLS?

Perhaps I'm missing something obvious....

Jeff

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

--047d7bf0c102f979de0521523e35-- From nobody Sun Oct 4 21:01:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84DF1B2EB6 for ; Sun, 4 Oct 2015 21:01:21 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsjoljhwoN0A for ; Sun, 4 Oct 2015 21:01:20 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 1E7561B2EB3 for ; Sun, 4 Oct 2015 21:01:20 -0700 (PDT) Received: by ykft14 with SMTP id t14so160108255ykf.0 for ; Sun, 04 Oct 2015 21:01: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:date:message-id:subject:from:to :cc:content-type; bh=XvXaqPQXk3yIpNJ5meEsFPlK22wTktORgT9WbQQF900=; b=U2fItwORody3LZKwrd1JSX3ngdt+PJCJ/p+/7uSBwjD+0fdIH2xYTEn5Is8jPNM9C5 FW1rGRjvfM1Dyk1luVrh2hBNB7B1T36SmcKPZlcdWn/Hvis2ZwI0DqDW1CTm98sPvlHv lV6mVVx8sU8OP+udoznaosE6BgBQ7jQWayE3PIn1WmTPVvvaB/qexYBBfEyzuDEYUhcj 7l87GQixPk6JQaxHnxo10JllO8zfH2By1H51Fy4XnGFskU/oJ52l063g5ya+ZTRqo91e stFCL+k0K5hEOlaQ1bNZ1loQtR+L8RNIOINJSwD8O4LKA4hgH6QHUrNMW9Pd6fDQw+eU 7BbA== MIME-Version: 1.0 X-Received: by 10.170.173.1 with SMTP id p1mr22650032ykd.101.1444017679312; Sun, 04 Oct 2015 21:01:19 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Sun, 4 Oct 2015 21:01:18 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.com> Date: Sun, 4 Oct 2015 21:01:18 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2015 04:01:21 -0000 On 4 October 2015 at 19:26, Eric Rescorla wrote: > Consider the trivial case of ASCII text. Each character takes up the > same amount of room, but if you compress (as an intuition pump, > think of a simple Huffman code), then more common characters > take up less room than less common characters. This is right, but it's also not the case that revealing information like that is necessarily bad. Perhaps it isn't that interesting to an adversary that they can learn that there is (for example) English text being exchanged. That wouldn't be particularly relevant in helping them distinguish between ciphertext that contains interesting text from ciphertext containing uninteresting text. HPACK for instance compresses base64-encoded data unevenly. But the study that was run in 2013 determined that it wasn't especially interesting. [32] shows ~2 bits regained from a 30 character word. Of course, you should examine the conditions on that claim; such a result is not generally applicable. Mixing attacker-controlled data with secrets has shown to make protecting those secrets extremely difficult. [32] http://pdl.cmu.edu/PDL-FTP/associated/CMU-PDL-13-106.pdf From nobody Sun Oct 4 21:06:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371F11B2F21 for ; Sun, 4 Oct 2015 21:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iczH91LfmD5r for ; Sun, 4 Oct 2015 21:06:55 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 464AF1B2F28 for ; Sun, 4 Oct 2015 21:06:53 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so96209265wic.0 for ; Sun, 04 Oct 2015 21:06:51 -0700 (PDT) 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-type; bh=rRmr7Tw/9vgEOGIClCMNHZDOjlbSciTIRk9WL9Z4Snw=; b=eGBizPoR+zGLD0dn5QoyIUtnB+EDhcmt+ZWzb4oVxvkYsZ+0/Pcx6ktd2WEZpj09vk lVKFEuTeAxgyeD1Lnp/ie1OSlS/Aqd6jW1z1LbWddAgDy185JddfbAC0VlIHBuD3QRgC tabIsmXdjP2O8p/TCbfGkbolCJs3fxMyAiwcmbyFlavnsHvfP+Jm8QZ/iixE0x9GbDMx dDHZLDXfdwn4YLPiCZmIdlakbHvbTM59ZJHQrkfQ/Aizw2IXmTZqx2LuX5xFzX72cqil fFPk0/jbGlytx/TSjpweQa1FGjGJKzahVQhz1tTDlZtsZQK3pCOS4DRsbugpBfVWCj7+ LxvQ== X-Gm-Message-State: ALoCoQmqnkR3XXwyzzyBhBb+L2VonmYoFhOx8qvBTHKPNg0coGiVzjSWiP5Usn7uZBz2tMtuFKiR X-Received: by 10.180.184.201 with SMTP id ew9mr9810707wic.53.1444018011829; Sun, 04 Oct 2015 21:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Sun, 4 Oct 2015 21:06:11 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.com> From: Eric Rescorla Date: Sun, 4 Oct 2015 21:06:11 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c384c4a515b1052153a451 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2015 04:06:57 -0000 --001a11c384c4a515b1052153a451 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 4, 2015 at 9:01 PM, Martin Thomson wrote: > On 4 October 2015 at 19:26, Eric Rescorla wrote: > > Consider the trivial case of ASCII text. Each character takes up the > > same amount of room, but if you compress (as an intuition pump, > > think of a simple Huffman code), then more common characters > > take up less room than less common characters. > > This is right, but it's also not the case that revealing information > like that is necessarily bad. I didn't say it was. But it's also leaking information that the encryption didn't, which is intended as a simple counterexample to Jeffrey's claim. HPACK for instance compresses base64-encoded data unevenly. But the > study that was run in 2013 determined that it wasn't especially > interesting. [32] shows ~2 bits regained from a 30 character word. Of > course, you should examine the conditions on that claim; such a result > is not generally applicable. Mixing attacker-controlled data with > secrets has shown to make protecting those secrets extremely > difficult. > Yes, if the attacker can provide their own data, it makes matters worse, but as the reference I provided indicated, there are potential security issues even if the attacker is not able to do so, provided that the data is sufficiently redundant. -Ekr --001a11c384c4a515b1052153a451 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 4, 2015 at 9:01 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 4 October 2015 at 19:26, Eric Rescorla <ekr@rtfm.com> wrote:
> Consider the trivial case of ASCII text. Each character takes up the > same amount of room, but if you compress (as an intuition pump,
> think of a simple Huffman code), then more common characters
> take up less room than less common characters.

This is right, but it's also not the case that revealing informa= tion
like that is necessarily bad.=C2=A0

I didn&= #39;t say it was. But it's also leaking information that the encryption=
didn't, which is intended as a simple counterexample to Jeff= rey's claim.
=C2=A0

HPACK for instance compresses base64-encoded data unevenly.=C2=A0 But the study that was run in 2013 determined that it wasn't especially
interesting. [32] shows ~2 bits regained from a 30 character word.=C2=A0 Of=
course, you should examine the conditions on that claim; such a result
is not generally applicable.=C2=A0 Mixing attacker-controlled data with
secrets has shown to make protecting those secrets extremely
difficult.

Yes, if the attacker can pro= vide their own data, it makes matters worse,
but as the reference= I provided indicated, there are potential security
issues ev= en if the attacker is not able to do so, provided that the data
i= s sufficiently redundant.

-Ekr
--001a11c384c4a515b1052153a451-- From nobody Sun Oct 4 21:12:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A701B31B7 for ; Sun, 4 Oct 2015 21:12:02 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsggMKGFlwYZ for ; Sun, 4 Oct 2015 21:12:01 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 EB0BA1B31C4 for ; Sun, 4 Oct 2015 21:12:00 -0700 (PDT) Received: by ykdz138 with SMTP id z138so159857701ykd.2 for ; Sun, 04 Oct 2015 21:12: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:date:message-id:subject:from:to :cc:content-type; bh=vLQcLAhfwFsoiGbb9Xj45eC0vE1Q8vIvoh10miqtvNk=; b=bnV1EvCGQ+snFQxAle5wrp+lMulpcsXuJdx1aclWydRp7fB8jHGfPPol4kTyjzbObn JkSbWold5SPDC2WDrzuwQKvezI+7WC+jR5YEO6/gMG2SWAOM+MGDRQ5ZqZG45QNK1v+T OlYi8A6izI735GCWMAWmhBPyJlFri4cng5ov9tpigDGk8PL0zJmjGqSEE/ubwJIlGFG6 mM0TC4inJoQdE4ZBd+g7XRaVqjHpqk7fohrhqUbbfTBUULceRtV3vuLsu3Ga7zp1+rB/ /lhyeDflInOGpxLSh62Uqz2CoZSAFpkzRrgzaAgySt/RY0LrIyruVsM/eVaYSBtcIP8z mCWg== MIME-Version: 1.0 X-Received: by 10.129.51.88 with SMTP id z85mr23657822ywz.148.1444018320093; Sun, 04 Oct 2015 21:12:00 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Sun, 4 Oct 2015 21:11:59 -0700 (PDT) In-Reply-To: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> <7E1B8B3D-DEF5-439A-8E56-0CB2DFC061A8@cs.meiji.ac.jp> <84faf2113b9946f79763886867d65925@ustx2ex-dag1mb3.msg.corp.akamai.com> Date: Sun, 4 Oct 2015 21:11:59 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2015 04:12:02 -0000 On 4 October 2015 at 21:06, Eric Rescorla wrote: > > Yes, if the attacker can provide their own data, it makes matters worse, > but as the reference I provided indicated, there are potential security > issues even if the attacker is not able to do so, provided that the data > is sufficiently redundant. Sometimes, it's OK. Sometimes, not. Agreed. From nobody Mon Oct 5 11:31:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA9C1B32EB; Mon, 5 Oct 2015 11:31:43 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNs34hpDzCYR; Mon, 5 Oct 2015 11:31:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EBB1B32ED; Mon, 5 Oct 2015 11:31:41 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151005183141.1587.71823.idtracker@ietfa.amsl.com> Date: Mon, 05 Oct 2015 11:31:41 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 05 Oct 2015 18:31:44 -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 Working Group of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-09.txt Pages : 105 Date : 2015-10-05 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-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 Mon Oct 5 12:54:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6E91B4F62 for ; Mon, 5 Oct 2015 12:54:06 -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, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi_X1z1Pzq95 for ; Mon, 5 Oct 2015 12:54:05 -0700 (PDT) Received: from st11p02im-asmtp002.me.com (st11p02im-asmtp002.me.com [17.172.220.114]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4C71B4F44 for ; Mon, 5 Oct 2015 12:54:05 -0700 (PDT) Received: from [192.168.1.71] (KD113151025165.ppp-bb.dion.ne.jp [113.151.25.165]) by st11p02im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NVR00RD0JA1T010@st11p02im-asmtp002.me.com> for tls@ietf.org; Mon, 05 Oct 2015 19:54:04 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-10-05_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=2.25930052444312e-10 compositescore=0.0617480165324052 phishscore=0 kscore.is_spamscore=0 rbsscore=0.0617480165324052 recipient_to_sender_totalscore=0 spamscore=0 urlsuspectscore=0.0617480165324052 adultscore=0 kscore.compositescore=0 circleOfTrustscore=0 suspectscore=1 recipient_domain_to_sender_totalscore=0 bulkscore=0 recipient_domain_to_sender_domain_totalscore=0 recipient_to_sender_domain_totalscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1412110000 definitions=main-1510050269 From: Shin'ichiro Matsuo Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Date: Tue, 06 Oct 2015 04:54:01 +0900 Message-id: To: tls@ietf.org MIME-version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [TLS] Comments from CELLOS consortium X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2015 19:54:06 -0000 Dear all, Members in the CELLOS consortium (https://www.cellos-consortium.org), = which is the consortium on security of cryptographic protocols, are = studying on the TLS 1.3 protocol. We have several comments and = suggestions to make the specification of TLS1.3 better.=20 Please find the comments at the following URL. = https://www.cellos-consortium.org/studygroup/tls_1_3-draft_08_issues_rev1.= pdf The comments are on the following matters. - AEAD - KDF - Full Handshake - Hello Retry Request - Shared Secret - Client Authentication - Cipher Suite - 0-RTT - Resumption and PSK Some of them are already fixed, such as HFDF. However, we left it as a = result of our study. Regards, Shin=E2=80=99ichiro Matsuo= From nobody Mon Oct 5 22:27:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66101B3785 for ; Mon, 5 Oct 2015 22:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynoTmlwgUXvG for ; Mon, 5 Oct 2015 22:27:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0608.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31B41B335D for ; Mon, 5 Oct 2015 22:27:06 -0700 (PDT) Received: from CY1PR0101MB1145.prod.exchangelabs.com (10.161.163.19) by CY1PR0101MB1147.prod.exchangelabs.com (10.161.163.21) with Microsoft SMTP Server (TLS) id 15.1.280.20; Tue, 6 Oct 2015 05:26:49 +0000 Received: from CY1PR0101MB1145.prod.exchangelabs.com ([10.161.163.19]) by CY1PR0101MB1145.prod.exchangelabs.com ([10.161.163.19]) with mapi id 15.01.0280.017; Tue, 6 Oct 2015 05:26:49 +0000 From: Douglas Stebila To: Eric Rescorla Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed Thread-Index: AQHQ8kAU1B1pnDigPUukKjRvULWuLJ5YQmOLgAAl4gCAAg1RgIAAE5UAgAEseoCAAAJPgIAAA0OAgAAOWS6AABDioIAABHeAgAIryAA= Date: Tue, 6 Oct 2015 05:26:49 +0000 Message-ID: <4CC27FE0-84EE-4A94-9AC3-72B4C9811E01@qut.edu.au> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041450.24540.davemgarrett@gmail.com> <201510041527.04800.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) authentication-results: spf=none (sender IP is ) smtp.mailfrom=stebila@qut.edu.au; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [218.235.200.44] x-microsoft-exchange-diagnostics: 1; CY1PR0101MB1147; 5:L1PwcuEATiTuKRi2kGO0BUwqdGSIQdYftjHnWDgMVuxyMnbJkRIsFiDi5zeAxH6qDxg7xalVWoH2F3t8sRLPuU6yNOoLm+0+EHlv1+Fy1fMzVpZxqUvCFIwReuY9i8CjEPMujat69XS3zlYSiS8RQg==; 24:1rxTKQWzGzW1QY2wTZq1QpCisppJKEiCw+Z0W9lHhR1JOFFEzrhXHXJ5W81mIBQA9kjtk4QQ/HKroi8yw4KihVqnYFSkqc3h7lyfM8mz1Nk=; 20:4oWAMAOGHPGC8++dnN41zZ+qxTTqZe3vS9+9zeFRRBqmkdNor3dITmzhkogAKs0FBJYU7HBd9AdrHQQ2ATnRDA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0101MB1147; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:CY1PR0101MB1147; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0101MB1147; x-forefront-prvs: 07215D0470 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(377454003)(24454002)(93886004)(87936001)(33656002)(82746002)(5004730100002)(40100003)(81156007)(74482002)(77096005)(19580405001)(88552001)(5002640100001)(5008740100001)(97736004)(110136002)(19580395003)(36756003)(5001960100002)(11100500001)(189998001)(106356001)(5007970100001)(101416001)(76176999)(105586002)(66066001)(64706001)(2900100001)(50226001)(102836002)(106116001)(46102003)(50986999)(86362001)(92566002)(57306001)(10400500002)(122556002)(2950100001)(74826001)(83716003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0101MB1147; H:CY1PR0101MB1145.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: qut.edu.au does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <1205801B7EF4F043A95943B4118E5B68@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qut.edu.au X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2015 05:26:49.8915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dc0b52a3-68c5-44f7-881d-9383d8850b96 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1147 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2015 05:27:14 -0000 On Oct 5, 2015, at 5:17 AM, Eric Rescorla wrote: >=20 > The problem is that we don't know how to generically provide compression > safely. To take a concrete example: HTTP2's solution to header compressio= n, > HPACK, is extremely limited compared to a generic compression system > like gzip, LZ77, etc., as well as being tightly-coupled to HTTP, and yet = we > still know that there are potential security problems [0]. Doing somethin= g > generically secure is much harder. >=20 > If you have a solution to this problem, then great. But the mere fact tha= t it's > desirable doesn't mean we have an answer. A very very limited answer is that, if you use a compression method with a = fixed, small dictionary and non-adaptive compression (i.e., the dictionary = is not updated), then recovery of a high entropy secret from a compressed-t= hen-encrypted value is hard, even with an adversary adaptively choosing the= prefix/suffix of the plaintext. This is a much weaker security property t= han the standard indistinguishability / semantic security of encryption, an= d would be unsuitable for general encryption purposes. Being a non-adaptiv= e technique, the compression rate is also quite poor, but can be better tha= n nothing for a dictionary that's chosen well for the typical document. Douglas= From nobody Tue Oct 6 16:22:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ADF1B4228 for ; Tue, 6 Oct 2015 16:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc3OJpORGD7C for ; Tue, 6 Oct 2015 16:22:56 -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 4BF311B4226 for ; Tue, 6 Oct 2015 16:22:56 -0700 (PDT) Received: by qkas79 with SMTP id s79so354549qka.0 for ; Tue, 06 Oct 2015 16:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=aF4CFaYWdAi+DKw0d42HoPc3Xr5Y6j2X2FpxgHceNDo=; b=fbHMwJSUld+9gkGB+y99SFl3rZDrAtIru0YfkvZetdxjaCETB8P+qDDMsArWGzVrLh ON3QaxGIfbmapstlazZA25HESkSmtprbdhsLBElXFd01CFNQA9o15SdNI5ITgmvR0zum r+JAashfsEjGvga4eCo1VNyERRZ/tGLchW4qY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=aF4CFaYWdAi+DKw0d42HoPc3Xr5Y6j2X2FpxgHceNDo=; b=BrFCGxGW0GZWPuwrhJOWge+f+XzkvCYm9oWCz33sCaInX76N9vf9IpjMcb8akXsUjg ugv8EaB212qEmQ/i+j4IgLeZC9t/IY3pnmGQ7r5b65zJTkiv8+Ttsf3wKj/xqZ6QVFus pzg50Z9RqK+TLnFu1O8tDjSyDn/joUGOV2TQpH6xAxKhNATLdRK8R1t30I3PFujlJF5P VrG7pkBbWvq+tt0+mk6nuWv3tE+KMaMgS1h5M9z5hhNd7GOhrrc/nzVmFUteFkVMJQUj GbQC6BWn4mfcZYOk+WBOUONLTR4nEsbHhGnqIMkPtVEiarO68Ekx/A4yRW7ap4LfrIMn GmOA== X-Gm-Message-State: ALoCoQkHM68T3LPwuBlme1zvBk+t3oDd7rDk+7oDgdCK9T918p0UmI2oqBCQw8konmywzgcowWoa X-Received: by 10.55.198.212 with SMTP id s81mr16009231qkl.108.1444173775461; Tue, 06 Oct 2015 16:22:55 -0700 (PDT) Received: from [5.5.33.65] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id j193sm14879454qhc.17.2015.10.06.16.22.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Oct 2015 16:22:54 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Tue, 6 Oct 2015 19:22:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <269DC017-DB07-4AE7-97D2-F7B700F77704@sn3rd.com> References: To: "" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] '15 TLS Fall Interim Minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2015 23:22:57 -0000 On Sep 22, 2015, at 19:27, Sean Turner wrote: > I=92ve gone ahead and posted the minutes/list of decisions to: >=20 > = https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-in= terim-2015-tls-3 >=20 > spt Revised minutes posted to the same link. spt= From nobody Wed Oct 7 12:52:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2E31B2FBD for ; Wed, 7 Oct 2015 12:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWRqykLfjAXw for ; Wed, 7 Oct 2015 12:51:59 -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 BE2861B2FB8 for ; Wed, 7 Oct 2015 12:51:59 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 DBE992AE12; Wed, 7 Oct 2015 21:51:57 +0200 (CEST) X-purgate-ID: 152705::1444247517-00001EB9-7107A675/0/0 X-purgate-size: 2006 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 mail05.wdf.sap.corp (Postfix) with ESMTP id CD10D4082C; Wed, 7 Oct 2015 21:51:57 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C346C1A2C5; Wed, 7 Oct 2015 21:51:57 +0200 (CEST) In-Reply-To: To: Eric Rescorla Date: Wed, 7 Oct 2015 21:51:57 +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: <20151007195157.C346C1A2C5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2015 19:52:02 -0000 Eric Rescorla wrote: > > That is what the document says: > "Versions of TLS before 1.3 supported compression and the list of > compression methods was supplied in this field. For any TLS 1.3 > ClientHello, this field MUST contain only the ?null? compression method > with the code point of 0. If a TLS 1.3 ClientHello is received with any > other value in this field, the server MUST generate a fatal > ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2 or > prior ClientHellos which contain other compression methods and MUST follow > the procedures for the appropriate prior version of TLS." The quoted wording calls for a fatal handshake failure when ClientHello offers TLSv1.2+compression _or_ TLSv1.3 while at the same time the last requirement asserts that a ClientHello with TLSv1.2+compression is perfectly OK. To me, this looks quite odd. If you want compression removed from TLSv1.3, how about something like this: "Versions of TLS before 1.3 supported compression and the list of compression methods was supplied in this field. All TLS protocol versions require the "null" compression method MUST be included/present in the compression_methods list of ClientHello. A TLSv1.3 server that is offered and selects/negotiates protocol version TLSv1.3, MUST select the "null" compression method, and MUST ignore all other compression methods that might appear in the compression_methods list of ClientHello. Btw. for the last requirement, I would appreciate an additional recommendation for a configuration option to disable compression, maybe something like This document does not impose restrictions on the use of compression with TLS protocol versions prior to TLSv1.3. However, it is RECOMMENDED that implementations which support compression provide a configuration option allowing consumers to disable the use of compression in TLS. -Martin From nobody Wed Oct 7 13:01:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798891B2A69 for ; Wed, 7 Oct 2015 13:01:34 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtbA2vPr6Htp for ; Wed, 7 Oct 2015 13:01:33 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 501B61B2A65 for ; Wed, 7 Oct 2015 13:01:33 -0700 (PDT) Received: by qgx61 with SMTP id 61so24552881qgx.3 for ; Wed, 07 Oct 2015 13:01:32 -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-type:content-transfer-encoding:message-id; bh=FBrszeWoz87z0OBrRk+HgteInmn45L/0r9yC2uzUtKA=; b=fPw9xSZSr8TINuOkiiMXlorMgV30ZFJDHNL46/zqBVdfs2JBjp+c9AvN6a9sR4+j0n 41tVDpI8cSDu8Mw+dlLJPFJ0e1rvxfs5rFVArwJuT4lzAWn6HQUkofbsm2GtYk3O7Duk /KzkWR6+JU0GdAxbK2A5Krt9cKbWDT7XQI/EfENLPPZpLCrd8G3zuXchetCu9C/otvy6 WcV7dz/VlQKE37Pe9BkkNstNtikWYF/rXtJo6V6+SMZ+76X7r/sFX3kRh2plqzd5WJvq LpIbEHNt6NFDVH7xNf6KuqBKB7krEWCKk36/Sxi+VJyYADvmkfyGpDp4k2tEgIucSCcb neEQ== X-Received: by 10.140.147.146 with SMTP id 140mr4100099qht.68.1444248092526; Wed, 07 Oct 2015 13:01:32 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id d66sm16931813qgd.36.2015.10.07.13.01.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 Oct 2015 13:01:31 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, mrex@sap.com Date: Wed, 7 Oct 2015 16:01:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151007195157.C346C1A2C5@ld9781.wdf.sap.corp> In-Reply-To: <20151007195157.C346C1A2C5@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510071601.30677.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2015 20:01:34 -0000 On Wednesday, October 07, 2015 03:51:57 pm Martin Rex wrote: > However, it is RECOMMENDED > that implementations which support compression provide a configuration > option allowing consumers to disable the use of compression in TLS. Risky features like compression should be off by default. Dave From nobody Wed Oct 7 13:43:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223FE1B305D for ; Wed, 7 Oct 2015 13:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGQdgE9gWla2 for ; Wed, 7 Oct 2015 13:43:54 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 3D43A1B305C for ; Wed, 7 Oct 2015 13:43:54 -0700 (PDT) Received: by wicge5 with SMTP id ge5so230257787wic.0 for ; Wed, 07 Oct 2015 13:43:52 -0700 (PDT) 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-type; bh=yRHg2XXq7DHzZ0Mo5prUXS5lJA6GHGeBTdLkKySIidE=; b=Bp4X/fMzVWkV/mGFJnNbrxhZFg9o3w5PnQFixbcKhgIP+n0as4sz4fBaCIvNh8YVFQ T2IZkYihjjmuLiIUtoTRpIC/Ttd8kJhh3FuMRBHchLINwj5tXltLpgNK856pk57iklSi 1Xg018r/uxNvuyyrcm0UPM9+meAuVHQvxtNrgDnYvHbs5I2VBkP7jkzGFgP80KF7ilaA ffxVs64l6CttUaamIzTh0MWYNqRfSd9sjWrKloTjnvcKOq1oeamIiMLwKL/JgCTNY0Sj u7WGp2EMQba6wxxM5KZMXlo+4Agra9yYHrp9qLJEaY3/CRyEy40gkBouZfJGpG6a83Vg Dk4w== X-Gm-Message-State: ALoCoQksscm5DM5jnsTNqDaBMHmFDWV3YVl3bkKGYuK+I+miXWs4nrSRO7eVPWjI0PaF5/wKYPWy X-Received: by 10.194.94.71 with SMTP id da7mr3505671wjb.8.1444250632759; Wed, 07 Oct 2015 13:43:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Wed, 7 Oct 2015 13:43:12 -0700 (PDT) In-Reply-To: <20151007195157.C346C1A2C5@ld9781.wdf.sap.corp> References: <20151007195157.C346C1A2C5@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Wed, 7 Oct 2015 22:43:12 +0200 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=047d7bf0c102eec604052189cdec Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2015 20:43:56 -0000 --047d7bf0c102eec604052189cdec Content-Type: text/plain; charset=UTF-8 On Wed, Oct 7, 2015 at 9:51 PM, Martin Rex wrote: > Eric Rescorla wrote: > > > > That is what the document says: > > "Versions of TLS before 1.3 supported compression and the list of > > compression methods was supplied in this field. For any TLS 1.3 > > ClientHello, this field MUST contain only the ?null? compression method > > with the code point of 0. If a TLS 1.3 ClientHello is received with any > > other value in this field, the server MUST generate a fatal > > ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2 > or > > prior ClientHellos which contain other compression methods and MUST > follow > > the procedures for the appropriate prior version of TLS." > > The quoted wording calls for a fatal handshake failure when ClientHello > offers > > TLSv1.2+compression _or_ TLSv1.3 > > while at the same time the last requirement asserts that a ClientHello with > > TLSv1.2+compression > > is perfectly OK. To me, this looks quite odd. > That's not how I read this text. Rather, I read it as: If ClientHelloVersion >= TLS 1.3 then the compression field must be empty else: the compression field is dictated by other versions This doesn't seem inconsistent to me. If you still think that the paragraph reads differently, can you help me by diagramming it? > If you want compression removed from TLSv1.3, how about something like > this: > > > "Versions of TLS before 1.3 supported compression and the list of > compression methods was supplied in this field. > All TLS protocol > versions require the "null" compression method MUST be included/present > in the compression_methods list of ClientHello. A TLSv1.3 server that > is offered and selects/negotiates protocol version TLSv1.3, MUST select > the "null" compression method, and MUST ignore all other compression > methods that might appear in the compression_methods list of ClientHello. > > > Btw. for the last requirement, I would appreciate an additional > recommendation > for a configuration option to disable compression, maybe something like > > This document does not impose restrictions on the use of compression > with TLS protocol versions prior to TLSv1.3. However, it is RECOMMENDED > that implementations which support compression provide a configuration > option allowing consumers to disable the use of compression in TLS. > > > -Martin > --047d7bf0c102eec604052189cdec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 7, 2015 at 9:51 PM, Martin Rex <mrex@sap.com> wro= te:
Eric Rescorla wrote:
>
> That is what the document says:
> "Versions of TLS before 1.3 supported compression and the list of=
> compression methods was supplied in this field. For any TLS 1.3
> ClientHello, this field MUST contain only the ?null? compression metho= d
> with the code point of 0. If a TLS 1.3 ClientHello is received with an= y
> other value in this field, the server MUST generate a fatal
> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1= .2 or
> prior ClientHellos which contain other compression methods and MUST fo= llow
> the procedures for the appropriate prior version of TLS."

The quoted wording calls for a fatal handshake failure when ClientHello
offers

=C2=A0 TLSv1.2+compression=C2=A0 _or_=C2=A0 TLSv1.3

while at the same time the last requirement asserts that a ClientHello with=

=C2=A0 TLSv1.2+compression

is perfectly OK.=C2=A0 To me, this looks quite odd.
That's not how I read this text.

= Rather, I read it as:
If ClientHelloVersion >=3D TLS 1.3
=
=C2=A0 =C2=A0then the compression field must be empty
else:<= /div>
=C2=A0 =C2=A0the compression field is dictated by other versions<= /div>

This doesn't seem inconsistent to me. If you s= till think that the paragraph
reads differently, can you help= me by diagramming it?

=C2=A0
If you want compression removed from TLSv1.3, how about something like this= :


=C2=A0"Versions of TLS before 1.3 supported compression and the list o= f
=C2=A0compression methods was supplied in this field.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 All TLS protocol
=C2=A0versions require the "null" compression method MUST be incl= uded/present
=C2=A0in the compression_methods list of ClientHello.=C2=A0 A TLSv1.3 serve= r that
=C2=A0is offered and selects/negotiates protocol version TLSv1.3, MUST sele= ct
=C2=A0the "null" compression method, and MUST ignore all other co= mpression
=C2=A0methods that might appear in the compression_methods list of ClientHe= llo.


Btw. for the last requirement, I would appreciate an additional recommendat= ion
for a configuration option to disable compression, maybe something like

=C2=A0This document does not impose restrictions on the use of compression<= br> =C2=A0with TLS protocol versions prior to TLSv1.3.=C2=A0 However, it is REC= OMMENDED
=C2=A0that implementations which support compression provide a configuratio= n
=C2=A0option allowing consumers to disable the use of compression in TLS.

-Martin

--047d7bf0c102eec604052189cdec-- From nobody Wed Oct 7 14:12:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8BA1B30BF for ; Wed, 7 Oct 2015 14:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB9W9Mm9TNcJ for ; Wed, 7 Oct 2015 14:11:59 -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 353D71B30E2 for ; Wed, 7 Oct 2015 14:11:57 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 5109C2ADFE; Wed, 7 Oct 2015 23:11:55 +0200 (CEST) X-purgate-ID: 152705::1444252315-00000827-62F88C98/0/0 X-purgate-size: 2243 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 407D24072B; Wed, 7 Oct 2015 23:11:55 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 384AC1A2C5; Wed, 7 Oct 2015 23:11:55 +0200 (CEST) In-Reply-To: To: Eric Rescorla Date: Wed, 7 Oct 2015 23:11:55 +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: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2015 21:12:01 -0000 Eric Rescorla wrote: > Martin Rex wrote: >> Eric Rescorla wrote: >>> >>> That is what the document says: >>> "Versions of TLS before 1.3 supported compression and the list of >>> compression methods was supplied in this field. For any TLS 1.3 >>> ClientHello, this field MUST contain only the ?null? compression method >>> with the code point of 0. If a TLS 1.3 ClientHello is received with any >>> other value in this field, the server MUST generate a fatal >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS 1.2 >>> or prior ClientHellos which contain other compression methods and MUST >>> follow the procedures for the appropriate prior version of TLS." >> >> The quoted wording calls for a fatal handshake failure when ClientHello >> offers >> >> TLSv1.2+compression _or_ TLSv1.3 >> >> while at the same time the last requirement asserts that a ClientHello with >> >> TLSv1.2+compression >> >> is perfectly OK. To me, this looks quite odd. > > That's not how I read this text. > > Rather, I read it as: > If ClientHelloVersion >= TLS 1.3 > then the compression field must be empty > else: > the compression field is dictated by other versions > > This doesn't seem inconsistent to me. If you still think that the paragraph > reads differently, can you help me by diagramming it? What you describe would be considerable worse that what I understood, because it would mean that a TLSv1.3 ClientHello will be unconditionally invalid for a TLSv1.2 server. https://tools.ietf.org/html/rfc5246#page-42 compression_methods This is a list of the compression methods supported by the client, sorted by client preference. If the session_id field is not empty (implying a session resumption request), it MUST include the Dierks & Rescorla Standards Track [Page 41] RFC 5246 TLS August 2008 *> compression_method from that session. This vector MUST contain, *> and all implementations MUST support, CompressionMethod.null. Thus, a client and server will always be able to agree on a compression method. -Martin From nobody Wed Oct 7 14:15:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C80F1B3082 for ; Wed, 7 Oct 2015 14:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J57KrsdqRgtF for ; Wed, 7 Oct 2015 14:15:41 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 1F0E11B3076 for ; Wed, 7 Oct 2015 14:15:41 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so46596694wic.1 for ; Wed, 07 Oct 2015 14:15:39 -0700 (PDT) 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-type; bh=Xb/t5p6qpcXVfTSH+B0d6SUswFA5tbOKskIgt0ZIrZs=; b=BjpUOVsF9LrAk2/lApMwHUSnDIghmykSG5Lvudf8jirhGTC4d0bCHCEjbR0fCYGTtt PS0bhxQGucUEvD9wgLiuIWIoeTZP1cvPtAQcXZLK+gHZAWLfmg4VZLA2JmuBIZ1oXWaX Jsfr7ycFISM2YsWOugUQqmsspKHwFtwIJMTEP9+Vl2IX6qALCWgY6/4MXnvRoYr2I1ML 1dIWIVNypO5/mIvznOlN3U3R5TTa1haKLAlT4/vpPcSuNHRQySxivn2BitG9qwpejjMA Og3dLmBZwLBV2TyxCJ6EV/LI7Yh72IPPkCH5IrjE6S1sDPlWxdNi2I3QqiUw5jx5aDCu LLFQ== X-Gm-Message-State: ALoCoQlx1vdfYxLk5wLgtI8550vj0xOuvhzamVIRaLTmvpVL6nMuQ0l5bXW+uZABkK+KH92Y4BTW X-Received: by 10.180.106.98 with SMTP id gt2mr26543283wib.31.1444252539573; Wed, 07 Oct 2015 14:15:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Wed, 7 Oct 2015 14:15:00 -0700 (PDT) In-Reply-To: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Wed, 7 Oct 2015 23:15:00 +0200 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=f46d04428f1c9671bb05218a3fb8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2015 21:15:43 -0000 --f46d04428f1c9671bb05218a3fb8 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex wrote: > Eric Rescorla wrote: > > Martin Rex wrote: > >> Eric Rescorla wrote: > >>> > >>> That is what the document says: > >>> "Versions of TLS before 1.3 supported compression and the list of > >>> compression methods was supplied in this field. For any TLS 1.3 > >>> ClientHello, this field MUST contain only the ?null? compression method > >>> with the code point of 0. If a TLS 1.3 ClientHello is received with any > >>> other value in this field, the server MUST generate a fatal > >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS > 1.2 > >>> or prior ClientHellos which contain other compression methods and MUST > >>> follow the procedures for the appropriate prior version of TLS." > >> > >> The quoted wording calls for a fatal handshake failure when ClientHello > >> offers > >> > >> TLSv1.2+compression _or_ TLSv1.3 > >> > >> while at the same time the last requirement asserts that a ClientHello > with > >> > >> TLSv1.2+compression > >> > >> is perfectly OK. To me, this looks quite odd. > > > > That's not how I read this text. > > > > Rather, I read it as: > > If ClientHelloVersion >= TLS 1.3 > > then the compression field must be empty > > else: > > the compression field is dictated by other versions > > > > This doesn't seem inconsistent to me. If you still think that the > paragraph > > reads differently, can you help me by diagramming it? > > What you describe would be considerable worse that what I understood, > because it would mean that a TLSv1.3 ClientHello will be unconditionally > invalid for a TLSv1.2 server. > > https://tools.ietf.org/html/rfc5246#page-42 > > compression_methods > This is a list of the compression methods supported by the client, > sorted by client preference. If the session_id field is not empty > (implying a session resumption request), it MUST include the > > Dierks & Rescorla Standards Track [Page 41] > > RFC 5246 TLS August 2008 > > *> compression_method from that session. This vector MUST contain, > *> and all implementations MUST support, CompressionMethod.null. > Thus, a client and server will always be able to agree on a > compression method. Sorry, I spoke carelessly. It must contain solely the null method. -Ekr --f46d04428f1c9671bb05218a3fb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex <mrex@sap.com> wr= ote:
Eric Rescorla wrote:
> Martin Rex <mrex@sap.com> wr= ote:
>> Eric Rescorla wrote:
>>>
>>> That is what the document says:
>>> "Versions of TLS before 1.3 supported compression and the= list of
>>> compression methods was supplied in this field. For any TLS 1.= 3
>>> ClientHello, this field MUST contain only the ?null? compressi= on method
>>> with the code point of 0. If a TLS 1.3 ClientHello is received= with any
>>> other value in this field, the server MUST generate a fatal >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may recei= ve TLS 1.2
>>> or prior ClientHellos which contain other compression methods = and MUST
>>> follow the procedures for the appropriate prior version of TLS= ."
>>
>> The quoted wording calls for a fatal handshake failure when Client= Hello
>> offers
>>
>>=C2=A0 =C2=A0TLSv1.2+compression=C2=A0 _or_=C2=A0 TLSv1.3
>>
>> while at the same time the last requirement asserts that a ClientH= ello with
>>
>>=C2=A0 =C2=A0TLSv1.2+compression
>>
>> is perfectly OK.=C2=A0 To me, this looks quite odd.
>
> That's not how I read this text.
>
> Rather, I read it as:
> If ClientHelloVersion >=3D TLS 1.3
>=C2=A0 =C2=A0 then the compression field must be empty
> else:
>=C2=A0 =C2=A0 the compression field is dictated by other versions
>
> This doesn't seem inconsistent to me. If you still think that the = paragraph
> reads differently, can you help me by diagramming it?

What you describe would be considerable worse that what I under= stood,
because it would mean that a TLSv1.3 ClientHello will be unconditionally invalid for a TLSv1.2 server.

=C2=A0 =C2=A0https://tools.ietf.org/html/rfc5246#page-42<= /a>

=C2=A0 =C2=A0compression_methods
=C2=A0 =C2=A0 =C2=A0 This is a list of the compression methods supported by= the client,
=C2=A0 =C2=A0 =C2=A0 sorted by client preference.=C2=A0 If the session_id f= ield is not empty
=C2=A0 =C2=A0 =C2=A0 (implying a session resumption request), it MUST inclu= de the

Dierks & Rescorla=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Standards Tra= ck=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Pa= ge 41]

RFC 5246=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 TLS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 August 2008

*>=C2=A0 =C2=A0 compression_method from that session.=C2=A0 This vector = MUST contain,
*>=C2=A0 =C2=A0 and all implementations MUST support, CompressionMethod.= null.
=C2=A0 =C2=A0 =C2=A0 Thus, a client and server will always be able to agree= on a
=C2=A0 =C2=A0 =C2=A0 compression method.


--f46d04428f1c9671bb05218a3fb8-- From tshort@akamai.com Wed Oct 7 14:28:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58D21B310B for ; Wed, 7 Oct 2015 14:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbqbc-eIzzGB for ; Wed, 7 Oct 2015 14:28:32 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id AD2211B30F7 for ; Wed, 7 Oct 2015 14:28:32 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E2CA0200041; Wed, 7 Oct 2015 21:28:31 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id CAB5520002D; Wed, 7 Oct 2015 21:28:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444253311; bh=EASXD6Buim8j3XV7g7vSU5CvQngtnEg6yV59FcCbe6U=; l=14795; h=From:To:CC:Date:References:In-Reply-To:From; b=KwZkpQl0qNBaN5+A6lMJ7D+8WAu5UzkrJ0oZL38xeTXTfaFL5gaz+VQlZ/1iZ2lfl shdJJgdEnqn7XmJ49CsGzbNclte+H7p0QxUg5BDSbef+oPLnQaTULapCxqXLX7zSZM Mybrx/RZ4z0nnMCJlYO/s7gS8KbsG4O+M2/Q/iyc= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 9B16D1E0AC; Wed, 7 Oct 2015 21:28:31 +0000 (GMT) Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 7 Oct 2015 16:28:31 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Wed, 7 Oct 2015 16:28:30 -0500 From: "Short, Todd" To: Eric Rescorla Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed Thread-Index: AQHRATmlz8vkrT+RfEa++i1UEDH43Z5g0u4AgAAIBoCAAADdAIAAA8SA Date: Wed, 7 Oct 2015 21:28:29 +0000 Message-ID: <49943603-287F-4C78-AEC1-45628554C190@akamai.com> References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> 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.43.61] Content-Type: multipart/alternative; boundary="_000_49943603287F4C78AEC145628554C190akamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2015 22:17:21 -0000 --_000_49943603287F4C78AEC145628554C190akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93ZXZlciwgZm9yIHRob3NlIENsaWVudEhlbGxv4oCZcyB0aGF0IHN1cHBvcnQgb2xkZXIgdmVy c2lvbnMsIHRoZSBjb21wcmVzc2lvbl9tZXRob2QgZmllbGQgbWF5IGNvbnRhaW4gb3RoZXIgdmFs dWVzLiBUaGlzIG1lYW5zIHRoYXQgaWYgYSBUTFN2MS4zIGNsaWVudCBoYXBwZW5lZCB0byBzdXBw b3J0IGNvbXByZXNzaW9uIGZvciBUTFN2MS4yLCBpdCB3b3VsZCBiZSB1bmFibGUgdG8gbmVnb3Rp YXRlIHRoYXQgdmlhIGEgc2luZ2xlIENsaWVudEhlbGxvLiBUaGVyZeKAmXMgbm8gd2F5IHRvIGF0 dGVtcHQgdG8gbmVnb3RpYXRlIFRMU3YxLjIrY29tcHJlc3Npb24gYW5kIFRMU3YxLjMrbm8tY29t cHJlc3Npb24gaW4gYSBzaW5nbGUgQ2xpZW50SGVsbG8uDQoNCkluIGVmZmVjdCwgdGhlIGRvY3Vt ZW50IGlzIHN0YXRpbmcgdGhhdCBhIFRMU3YxLjMgY2xpZW50IE1VU1QgTk9UIHN1cHBvcnQgY29t cHJlc3Npb24sIHJlZ2FyZGxlc3Mgb2YgdGhlIHByb3RvY29sIHZlcnNpb24gdGhhdCBtYXkgYmUg bmVnb3RpYXRlZC4NCg0KLS0NCi1Ub2RkIFNob3J0DQovLyB0c2hvcnRAYWthbWFpLmNvbTxtYWls dG86dHNob3J0QGFrYW1haS5jb20+DQovLyAiT25lIGlmIGJ5IGxhbmQsIHR3byBpZiBieSBzZWEs IHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4iDQoNCk9uIE9jdCA3LCAyMDE1LCBhdCA1OjE1IFBN LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3Rl Og0KDQoNCg0KT24gV2VkLCBPY3QgNywgMjAxNSBhdCAxMToxMSBQTSwgTWFydGluIFJleCA8bXJl eEBzYXAuY29tPG1haWx0bzptcmV4QHNhcC5jb20+PiB3cm90ZToNCkVyaWMgUmVzY29ybGEgd3Jv dGU6DQo+IE1hcnRpbiBSZXggPG1yZXhAc2FwLmNvbTxtYWlsdG86bXJleEBzYXAuY29tPj4gd3Jv dGU6DQo+PiBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPj4+DQo+Pj4gVGhhdCBpcyB3aGF0IHRoZSBk b2N1bWVudCBzYXlzOg0KPj4+ICJWZXJzaW9ucyBvZiBUTFMgYmVmb3JlIDEuMyBzdXBwb3J0ZWQg Y29tcHJlc3Npb24gYW5kIHRoZSBsaXN0IG9mDQo+Pj4gY29tcHJlc3Npb24gbWV0aG9kcyB3YXMg c3VwcGxpZWQgaW4gdGhpcyBmaWVsZC4gRm9yIGFueSBUTFMgMS4zDQo+Pj4gQ2xpZW50SGVsbG8s IHRoaXMgZmllbGQgTVVTVCBjb250YWluIG9ubHkgdGhlID9udWxsPyBjb21wcmVzc2lvbiBtZXRo b2QNCj4+PiB3aXRoIHRoZSBjb2RlIHBvaW50IG9mIDAuIElmIGEgVExTIDEuMyBDbGllbnRIZWxs byBpcyByZWNlaXZlZCB3aXRoIGFueQ0KPj4+IG90aGVyIHZhbHVlIGluIHRoaXMgZmllbGQsIHRo ZSBzZXJ2ZXIgTVVTVCBnZW5lcmF0ZSBhIGZhdGFsDQo+Pj4gP2lsbGVnYWxfcGFyYW1ldGVyPyBh bGVydC4gTm90ZSB0aGF0IFRMUyAxLjMgc2VydmVycyBtYXkgcmVjZWl2ZSBUTFMgMS4yDQo+Pj4g b3IgcHJpb3IgQ2xpZW50SGVsbG9zIHdoaWNoIGNvbnRhaW4gb3RoZXIgY29tcHJlc3Npb24gbWV0 aG9kcyBhbmQgTVVTVA0KPj4+IGZvbGxvdyB0aGUgcHJvY2VkdXJlcyBmb3IgdGhlIGFwcHJvcHJp YXRlIHByaW9yIHZlcnNpb24gb2YgVExTLiINCj4+DQo+PiBUaGUgcXVvdGVkIHdvcmRpbmcgY2Fs bHMgZm9yIGEgZmF0YWwgaGFuZHNoYWtlIGZhaWx1cmUgd2hlbiBDbGllbnRIZWxsbw0KPj4gb2Zm ZXJzDQo+Pg0KPj4gICBUTFN2MS4yK2NvbXByZXNzaW9uICBfb3JfICBUTFN2MS4zDQo+Pg0KPj4g d2hpbGUgYXQgdGhlIHNhbWUgdGltZSB0aGUgbGFzdCByZXF1aXJlbWVudCBhc3NlcnRzIHRoYXQg YSBDbGllbnRIZWxsbyB3aXRoDQo+Pg0KPj4gICBUTFN2MS4yK2NvbXByZXNzaW9uDQo+Pg0KPj4g aXMgcGVyZmVjdGx5IE9LLiAgVG8gbWUsIHRoaXMgbG9va3MgcXVpdGUgb2RkLg0KPg0KPiBUaGF0 J3Mgbm90IGhvdyBJIHJlYWQgdGhpcyB0ZXh0Lg0KPg0KPiBSYXRoZXIsIEkgcmVhZCBpdCBhczoN Cj4gSWYgQ2xpZW50SGVsbG9WZXJzaW9uID49IFRMUyAxLjMNCj4gICAgdGhlbiB0aGUgY29tcHJl c3Npb24gZmllbGQgbXVzdCBiZSBlbXB0eQ0KPiBlbHNlOg0KPiAgICB0aGUgY29tcHJlc3Npb24g ZmllbGQgaXMgZGljdGF0ZWQgYnkgb3RoZXIgdmVyc2lvbnMNCj4NCj4gVGhpcyBkb2Vzbid0IHNl ZW0gaW5jb25zaXN0ZW50IHRvIG1lLiBJZiB5b3Ugc3RpbGwgdGhpbmsgdGhhdCB0aGUgcGFyYWdy YXBoDQo+IHJlYWRzIGRpZmZlcmVudGx5LCBjYW4geW91IGhlbHAgbWUgYnkgZGlhZ3JhbW1pbmcg aXQ/DQoNCldoYXQgeW91IGRlc2NyaWJlIHdvdWxkIGJlIGNvbnNpZGVyYWJsZSB3b3JzZSB0aGF0 IHdoYXQgSSB1bmRlcnN0b29kLA0KYmVjYXVzZSBpdCB3b3VsZCBtZWFuIHRoYXQgYSBUTFN2MS4z IENsaWVudEhlbGxvIHdpbGwgYmUgdW5jb25kaXRpb25hbGx5DQppbnZhbGlkIGZvciBhIFRMU3Yx LjIgc2VydmVyLg0KDQogICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NiNwYWdl LTQyPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f dG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MjQ2LTIzcGFnZS0yRDQyJmQ9QlFNRmFRJmM9OTZaYlpa Y2FNRjR3MEY0anBONkxaZyZyPVFCRWNRc3FvVURkazFRMjZDemx6TlBQVWtLWVdJaDFMWXNpSEF3 bXRSaWsmbT1JeFVUbnpGNlNONnk2QzR6VFhYZmdRbWlWMUZvalhXdExaMFM4aFM1ZUdZJnM9VXUz TlBCczF0NTJOX2ZHVkdQcVhhelRBU3RHN2NQVWVDZk5oNmVDVHRrayZlPT4NCg0KICAgY29tcHJl c3Npb25fbWV0aG9kcw0KICAgICAgVGhpcyBpcyBhIGxpc3Qgb2YgdGhlIGNvbXByZXNzaW9uIG1l dGhvZHMgc3VwcG9ydGVkIGJ5IHRoZSBjbGllbnQsDQogICAgICBzb3J0ZWQgYnkgY2xpZW50IHBy ZWZlcmVuY2UuICBJZiB0aGUgc2Vzc2lvbl9pZCBmaWVsZCBpcyBub3QgZW1wdHkNCiAgICAgIChp bXBseWluZyBhIHNlc3Npb24gcmVzdW1wdGlvbiByZXF1ZXN0KSwgaXQgTVVTVCBpbmNsdWRlIHRo ZQ0KDQpEaWVya3MgJiBSZXNjb3JsYSAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAg ICAgICAgICAgICBbUGFnZSA0MV0NCg0KUkZDIDUyNDYgICAgICAgICAgICAgICAgICAgICAgICAg IFRMUyAgICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA4DQoNCio+ICAgIGNvbXByZXNz aW9uX21ldGhvZCBmcm9tIHRoYXQgc2Vzc2lvbi4gIFRoaXMgdmVjdG9yIE1VU1QgY29udGFpbiwN Cio+ICAgIGFuZCBhbGwgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCwgQ29tcHJlc3Npb25N ZXRob2QubnVsbC4NCiAgICAgIFRodXMsIGEgY2xpZW50IGFuZCBzZXJ2ZXIgd2lsbCBhbHdheXMg YmUgYWJsZSB0byBhZ3JlZSBvbiBhDQogICAgICBjb21wcmVzc2lvbiBtZXRob2QuDQoNClNvcnJ5 LCBJIHNwb2tlIGNhcmVsZXNzbHkuIEl0IG11c3QgY29udGFpbiBzb2xlbHkgdGhlIG51bGwgbWV0 aG9kLg0KDQotRWtyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_49943603287F4C78AEC145628554C190akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <0379F46DEC529A4486A917271424674D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSG93ZXZlciwgZm9yIHRob3NlIENs aWVudEhlbGxv4oCZcyB0aGF0IHN1cHBvcnQgb2xkZXIgdmVyc2lvbnMsIHRoZSBjb21wcmVzc2lv bl9tZXRob2QgZmllbGQgbWF5IGNvbnRhaW4gb3RoZXIgdmFsdWVzLiBUaGlzIG1lYW5zIHRoYXQg aWYgYSBUTFN2MS4zIGNsaWVudCBoYXBwZW5lZCB0byBzdXBwb3J0IGNvbXByZXNzaW9uIGZvciBU TFN2MS4yLCBpdCB3b3VsZCBiZSB1bmFibGUgdG8gbmVnb3RpYXRlIHRoYXQgdmlhIGEgc2luZ2xl IENsaWVudEhlbGxvLg0KIFRoZXJl4oCZcyBubyB3YXkgdG8gYXR0ZW1wdCB0byBuZWdvdGlhdGUg VExTdjEuMiYjNDM7Y29tcHJlc3Npb24gYW5kIFRMU3YxLjMmIzQzO25vLWNvbXByZXNzaW9uIGlu IGEgc2luZ2xlIENsaWVudEhlbGxvLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+SW4gZWZmZWN0LCB0aGUgZG9jdW1lbnQgaXMgc3RhdGluZyB0aGF0 IGEgVExTdjEuMyBjbGllbnQgTVVTVCBOT1Qgc3VwcG9ydCBjb21wcmVzc2lvbiwgcmVnYXJkbGVz cyBvZiB0aGUgcHJvdG9jb2wgdmVyc2lvbiB0aGF0IG1heSBiZSBuZWdvdGlhdGVkLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0 cnVlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdl YmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPi0tPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPi1Ub2RkIFNob3J0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vIDxhIGhyZWY9Im1haWx0bzp0 c2hvcnRAYWthbWFpLmNvbSIgY2xhc3M9IiI+dHNob3J0QGFrYW1haS5jb208L2E+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPi8vICZxdW90O09uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJl ZSBpZiBieSB0aGUgSW50ZXJuZXQuJnF1b3Q7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIE9jdCA3LCAyMDE1LCBhdCA1OjE1IFBNLCBFcmljIFJlc2Nvcmxh ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiBjbGFzcz0iIj5la3JAcnRmbS5jb208 L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBXZWQsIE9jdCA3LCAyMDE1IGF0IDExOjExIFBNLCBNYXJ0aW4gUmV4IDxz cGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86bXJleEBzYXAuY29t IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bXJleEBzYXAuY29tPC9hPiZndDs8L3NwYW4+IHdy b3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxkaXYgY2xhc3M9Img1Ij5FcmljIFJlc2Nv cmxhIHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsgTWFydGluIFJleCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1yZXhAc2FwLmNvbSIgY2xhc3M9IiI+bXJleEBzYXAuY29tPC9hPiZndDsgd3JvdGU6PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgRXJpYyBSZXNjb3JsYSB3cm90ZTo8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgVGhhdCBpcyB3aGF0IHRoZSBk b2N1bWVudCBzYXlzOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyAmcXVvdDtWZXJzaW9ucyBv ZiBUTFMgYmVmb3JlIDEuMyBzdXBwb3J0ZWQgY29tcHJlc3Npb24gYW5kIHRoZSBsaXN0IG9mPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IGNvbXByZXNzaW9uIG1ldGhvZHMgd2FzIHN1cHBsaWVk IGluIHRoaXMgZmllbGQuIEZvciBhbnkgVExTIDEuMzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0 OyBDbGllbnRIZWxsbywgdGhpcyBmaWVsZCBNVVNUIGNvbnRhaW4gb25seSB0aGUgP251bGw/IGNv bXByZXNzaW9uIG1ldGhvZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyB3aXRoIHRoZSBjb2Rl IHBvaW50IG9mIDAuIElmIGEgVExTIDEuMyBDbGllbnRIZWxsbyBpcyByZWNlaXZlZCB3aXRoIGFu eTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBvdGhlciB2YWx1ZSBpbiB0aGlzIGZpZWxkLCB0 aGUgc2VydmVyIE1VU1QgZ2VuZXJhdGUgYSBmYXRhbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0 OyA/aWxsZWdhbF9wYXJhbWV0ZXI/IGFsZXJ0LiBOb3RlIHRoYXQgVExTIDEuMyBzZXJ2ZXJzIG1h eSByZWNlaXZlIFRMUyAxLjI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgb3IgcHJpb3IgQ2xp ZW50SGVsbG9zIHdoaWNoIGNvbnRhaW4gb3RoZXIgY29tcHJlc3Npb24gbWV0aG9kcyBhbmQgTVVT VDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBmb2xsb3cgdGhlIHByb2NlZHVyZXMgZm9yIHRo ZSBhcHByb3ByaWF0ZSBwcmlvciB2ZXJzaW9uIG9mIFRMUy4mcXVvdDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFRoZSBxdW90ZWQgd29yZGluZyBjYWxscyBm b3IgYSBmYXRhbCBoYW5kc2hha2UgZmFpbHVyZSB3aGVuIENsaWVudEhlbGxvPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgb2ZmZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDtUTFN2MS4yJiM0Mztjb21wcmVzc2lvbiZuYnNwOyBfb3JfJm5i c3A7IFRMU3YxLjM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 IHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgdGhlIGxhc3QgcmVxdWlyZW1lbnQgYXNzZXJ0cyB0aGF0 IGEgQ2xpZW50SGVsbG8gd2l0aDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7VExTdjEuMiYjNDM7Y29tcHJlc3Npb248YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IGlzIHBlcmZlY3RseSBPSy4mbmJzcDsg VG8gbWUsIHRoaXMgbG9va3MgcXVpdGUgb2RkLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7IFRoYXQncyBub3QgaG93IEkgcmVhZCB0aGlzIHRleHQuPGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgUmF0aGVyLCBJIHJlYWQgaXQgYXM6PGJyIGNsYXNzPSIi Pg0KJmd0OyBJZiBDbGllbnRIZWxsb1ZlcnNpb24gJmd0Oz0gVExTIDEuMzxiciBjbGFzcz0iIj4N CiZndDsmbmJzcDsgJm5ic3A7IHRoZW4gdGhlIGNvbXByZXNzaW9uIGZpZWxkIG11c3QgYmUgZW1w dHk8YnIgY2xhc3M9IiI+DQomZ3Q7IGVsc2U6PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJz cDsgdGhlIGNvbXByZXNzaW9uIGZpZWxkIGlzIGRpY3RhdGVkIGJ5IG90aGVyIHZlcnNpb25zPGJy IGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgVGhpcyBkb2Vzbid0IHNlZW0gaW5j b25zaXN0ZW50IHRvIG1lLiBJZiB5b3Ugc3RpbGwgdGhpbmsgdGhhdCB0aGUgcGFyYWdyYXBoPGJy IGNsYXNzPSIiPg0KJmd0OyByZWFkcyBkaWZmZXJlbnRseSwgY2FuIHlvdSBoZWxwIG1lIGJ5IGRp YWdyYW1taW5nIGl0PzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQpXaGF0IHlvdSBkZXNjcmliZSB3b3VsZCBiZSBjb25zaWRlcmFibGUgd29yc2UgdGhhdCB3aGF0 IEkgdW5kZXJzdG9vZCw8YnIgY2xhc3M9IiI+DQpiZWNhdXNlIGl0IHdvdWxkIG1lYW4gdGhhdCBh IFRMU3YxLjMgQ2xpZW50SGVsbG8gd2lsbCBiZSB1bmNvbmRpdGlvbmFsbHk8YnIgY2xhc3M9IiI+ DQppbnZhbGlkIGZvciBhIFRMU3YxLjIgc2VydmVyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNTI0Ni0yM3BhZ2Ut MkQ0MiZhbXA7ZD1CUU1GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1RQkVj UXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210UmlrJmFtcDttPUl4VVRuekY2U042 eTZDNHpUWFhmZ1FtaVYxRm9qWFd0TFowUzhoUzVlR1kmYW1wO3M9VXUzTlBCczF0NTJOX2ZHVkdQ cVhhelRBU3RHN2NQVWVDZk5oNmVDVHRrayZhbXA7ZT0iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2I3Bh Z2UtNDI8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2NvbXBy ZXNzaW9uX21ldGhvZHM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGlzIGlz IGEgbGlzdCBvZiB0aGUgY29tcHJlc3Npb24gbWV0aG9kcyBzdXBwb3J0ZWQgYnkgdGhlIGNsaWVu dCw8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzb3J0ZWQgYnkgY2xpZW50IHBy ZWZlcmVuY2UuJm5ic3A7IElmIHRoZSBzZXNzaW9uX2lkIGZpZWxkIGlzIG5vdCBlbXB0eTxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IChpbXBseWluZyBhIHNlc3Npb24gcmVzdW1w dGlvbiByZXF1ZXN0KSwgaXQgTVVTVCBpbmNsdWRlIHRoZTxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkRpZXJrcyAmYW1wOyBSZXNjb3JsYSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7U3RhbmRhcmRzIFRyYWNrJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtQYWdlIDQxXTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NClJGQyA1MjQ2Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFRMUyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1Z3VzdCAyMDA4PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KKiZndDsmbmJzcDsgJm5ic3A7IGNvbXByZXNzaW9uX21ldGhv ZCBmcm9tIHRoYXQgc2Vzc2lvbi4mbmJzcDsgVGhpcyB2ZWN0b3IgTVVTVCBjb250YWluLDxiciBj bGFzcz0iIj4NCiomZ3Q7Jm5ic3A7ICZuYnNwOyBhbmQgYWxsIGltcGxlbWVudGF0aW9ucyBNVVNU IHN1cHBvcnQsIENvbXByZXNzaW9uTWV0aG9kLm51bGwuPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgVGh1cywgYSBjbGllbnQgYW5kIHNlcnZlciB3aWxsIGFsd2F5cyBiZSBhYmxl IHRvIGFncmVlIG9uIGE8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBjb21wcmVz c2lvbiBtZXRob2QuPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U29ycnksIEkgc3Bva2UgY2FyZWxlc3NseS4gSXQgbXVzdCBj b250YWluIHNvbGVseSB0aGUgbnVsbCBtZXRob2QuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tRWtyPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpUTFMg bWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIg Y2xhc3M9IiI+VExTQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_49943603287F4C78AEC145628554C190akamaicom_-- From nobody Wed Oct 7 17:56:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42071B3190 for ; Wed, 7 Oct 2015 17:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s2ncauQyEeE for ; Wed, 7 Oct 2015 17:56:27 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8521C1B318D for ; Wed, 7 Oct 2015 17:56:27 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id A482B33D284; Thu, 8 Oct 2015 00:56:25 +0000 (UTC) Sender: geoffk@localhost.localdomain To: "Short, Todd" References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> <49943603-287F-4C78-AEC1-45628554C190@akamai.com> From: Geoffrey Keating Date: 07 Oct 2015 17:56:25 -0700 In-Reply-To: <49943603-287F-4C78-AEC1-45628554C190@akamai.com> Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 00:56:29 -0000 "Short, Todd" writes: > In effect, the document is stating that a TLSv1.3 client MUST NOT > support compression, regardless of the protocol version that may be > negotiated. I believe that is the intent, yes. I support both the current wording in draft 09 (no compression for clients or servers, reject ClientHellos that allow compression and TLS 1.3) and the intent as described above. From nobody Wed Oct 7 21:44:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17961A8768 for ; Wed, 7 Oct 2015 21:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F83v6zGXTBna for ; Wed, 7 Oct 2015 21:44:22 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 E94471A8764 for ; Wed, 7 Oct 2015 21:44:21 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so7792390wic.0 for ; Wed, 07 Oct 2015 21:44:20 -0700 (PDT) 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-type; bh=auZE5aIdbTMqL598x8tauePqGf1hWAabfb9wg901mI8=; b=h9eVqm/hL/mcmDOxv1+fgumedLLr/wNAsiCzTZE5D80hpVtQrdoYdsztbmguQTU2DQ j7y+eEZ48/lPdEY/wQi3v5iiPtQyvVLRMdUKknWUEzouWI89bQNJveUKfrfjFmmXL+zr o/PzM0BI2jpOocc2lBJ4VL69WBZjuCE7rSMHRVjJs84qFu3M9ALug0mPr3d5HWNebRcs bAjecxWGHtpEUKeI02pVMVX3A12xJAXxq3pLIiYHHRIv3hnnnmo1NZklfDmDv5QRTwwU BR5DzktQO2fkB6sCuUXE7TAHp/FW8+z6kOIFp1NbDc/qMVpH1u9WcOhOpBJzx85K0FTW xEAA== X-Gm-Message-State: ALoCoQmQasR/STjj1SxeHNRxk+g7LmMeS6DcWv/AE7L15ukGsMEjZLLtdIdBpdKvX/HZqpaMah3u X-Received: by 10.194.94.71 with SMTP id da7mr5195023wjb.8.1444279460411; Wed, 07 Oct 2015 21:44:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Wed, 7 Oct 2015 21:43:40 -0700 (PDT) In-Reply-To: <49943603-287F-4C78-AEC1-45628554C190@akamai.com> References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> <49943603-287F-4C78-AEC1-45628554C190@akamai.com> From: Eric Rescorla Date: Thu, 8 Oct 2015 06:43:40 +0200 Message-ID: To: "Short, Todd" Content-Type: multipart/alternative; boundary=047d7bf0c10231d22c05219084cc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 04:44:25 -0000 --047d7bf0c10231d22c05219084cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2015 at 11:28 PM, Short, Todd wrote: > However, for those ClientHello=E2=80=99s that support older versions, the > compression_method field may contain other values. This means that if a > TLSv1.3 client happened to support compression for TLSv1.2, it would be > unable to negotiate that via a single ClientHello. There=E2=80=99s no way= to > attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a > single ClientHello. > > In effect, the document is stating that a TLSv1.3 client MUST NOT support > compression, regardless of the protocol version that may be negotiated. > Yes, this is what I believe it says and what I believe the WG had consensus on, the reasoning being that we really wished to just remove the feature entirely. If the chairs declare consensus on something else, I will of course edit it to say something else. -Ekr -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Oct 7, 2015, at 5:15 PM, Eric Rescorla wrote: > > > > On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex wrote: > >> Eric Rescorla wrote: >> > Martin Rex wrote: >> >> Eric Rescorla wrote: >> >>> >> >>> That is what the document says: >> >>> "Versions of TLS before 1.3 supported compression and the list of >> >>> compression methods was supplied in this field. For any TLS 1.3 >> >>> ClientHello, this field MUST contain only the ?null? compression >> method >> >>> with the code point of 0. If a TLS 1.3 ClientHello is received with >> any >> >>> other value in this field, the server MUST generate a fatal >> >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may receive TLS >> 1.2 >> >>> or prior ClientHellos which contain other compression methods and MU= ST >> >>> follow the procedures for the appropriate prior version of TLS." >> >> >> >> The quoted wording calls for a fatal handshake failure when ClientHel= lo >> >> offers >> >> >> >> TLSv1.2+compression _or_ TLSv1.3 >> >> >> >> while at the same time the last requirement asserts that a ClientHell= o >> with >> >> >> >> TLSv1.2+compression >> >> >> >> is perfectly OK. To me, this looks quite odd. >> > >> > That's not how I read this text. >> > >> > Rather, I read it as: >> > If ClientHelloVersion >=3D TLS 1.3 >> > then the compression field must be empty >> > else: >> > the compression field is dictated by other versions >> > >> > This doesn't seem inconsistent to me. If you still think that the >> paragraph >> > reads differently, can you help me by diagramming it? >> >> What you describe would be considerable worse that what I understood, >> because it would mean that a TLSv1.3 ClientHello will be unconditionally >> invalid for a TLSv1.2 server. >> >> https://tools.ietf.org/html/rfc5246#page-42 >> >> >> compression_methods >> This is a list of the compression methods supported by the client, >> sorted by client preference. If the session_id field is not empty >> (implying a session resumption request), it MUST include the >> >> Dierks & Rescorla Standards Track [Page 41] >> >> RFC 5246 TLS August 2008 >> >> *> compression_method from that session. This vector MUST contain, >> *> and all implementations MUST support, CompressionMethod.null. >> Thus, a client and server will always be able to agree on a >> compression method. > > > Sorry, I spoke carelessly. It must contain solely the null method. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --047d7bf0c10231d22c05219084cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 7, 2015 at 11:28 PM, Short, Todd <tshort@akamai.com>= ; wrote:
However, for those ClientHello=E2=80=99s that support older versions, the c= ompression_method field may contain other values. This means that if a TLSv= 1.3 client happened to support compression for TLSv1.2, it would be unable = to negotiate that via a single ClientHello. There=E2=80=99s no way to attempt to negotiate TLSv1.2+compression and TLS= v1.3+no-compression in a single ClientHello.

In effect, the document is stating that a TLSv1.3 client MUST NOT supp= ort compression, regardless of the protocol version that may be negotiated.=

Yes, this is what I believe it= says and what I believe the WG had consensus
on, the reasoning b= eing that we really wished to just remove the feature
entirely. I= f the chairs declare consensus on something else, I will of course edit
it to say something else.

-Ekr
=
--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

On Oct 7, 2015, at 5:15 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex <mrex@sap.com><= /span> wrote:
Eric Rescorla wrote:
> Martin Rex <mrex@= sap.com> wrote:
>> Eric Rescorla wrote:
>>>
>>> That is what the document says:
>>> "Versions of TLS before 1.3 supported compression and the= list of
>>> compression methods was supplied in this field. For any TLS 1.= 3
>>> ClientHello, this field MUST contain only the ?null? compressi= on method
>>> with the code point of 0. If a TLS 1.3 ClientHello is received= with any
>>> other value in this field, the server MUST generate a fatal >>> ?illegal_parameter? alert. Note that TLS 1.3 servers may recei= ve TLS 1.2
>>> or prior ClientHellos which contain other compression methods = and MUST
>>> follow the procedures for the appropriate prior version of TLS= ."
>>
>> The quoted wording calls for a fatal handshake failure when Client= Hello
>> offers
>>
>>=C2=A0 =C2=A0TLSv1.2+compression=C2=A0 _or_=C2=A0 TLSv1.3
>>
>> while at the same time the last requirement asserts that a ClientH= ello with
>>
>>=C2=A0 =C2=A0TLSv1.2+compression
>>
>> is perfectly OK.=C2=A0 To me, this looks quite odd.
>
> That's not how I read this text.
>
> Rather, I read it as:
> If ClientHelloVersion >=3D TLS 1.3
>=C2=A0 =C2=A0 then the compression field must be empty
> else:
>=C2=A0 =C2=A0 the compression field is dictated by other versions
>
> This doesn't seem inconsistent to me. If you still think that the = paragraph
> reads differently, can you help me by diagramming it?

What you describe would be considerable worse that what I understood,
because it would mean that a TLSv1.3 ClientHello will be unconditionally invalid for a TLSv1.2 server.

=C2=A0 =C2=A0https:/= /tools.ietf.org/html/rfc5246#page-42

=C2=A0 =C2=A0compression_methods
=C2=A0 =C2=A0 =C2=A0 This is a list of the compression methods supported by= the client,
=C2=A0 =C2=A0 =C2=A0 sorted by client preference.=C2=A0 If the session_id f= ield is not empty
=C2=A0 =C2=A0 =C2=A0 (implying a session resumption request), it MUST inclu= de the

Dierks & Rescorla=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Standards Tra= ck=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Pa= ge 41]

RFC 5246=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 TLS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 August 2008

*>=C2=A0 =C2=A0 compression_method from that session.=C2=A0 This vector = MUST contain,
*>=C2=A0 =C2=A0 and all implementations MUST support, CompressionMethod.= null.
=C2=A0 =C2=A0 =C2=A0 Thus, a client and server will always be able to agree= on a
=C2=A0 =C2=A0 =C2=A0 compression method.

Sorry, I spoke carelessly. It must contain solely the null method.

-Ekr

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


--047d7bf0c10231d22c05219084cc-- From nobody Wed Oct 7 21:53:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCD71A87A0 for ; Wed, 7 Oct 2015 21:53:36 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22BO-JQVdj9i for ; Wed, 7 Oct 2015 21:53:35 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 E86721A8772 for ; Wed, 7 Oct 2015 21:53:34 -0700 (PDT) Received: by ioii196 with SMTP id i196so45706721ioi.3 for ; Wed, 07 Oct 2015 21:53: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:content-type; bh=JHXPX24YZvYiPxMYvVtA5pf+ihMaKZVtkzgG9VydE+g=; b=WmYoPKzkSlvn2Mwh7gdfiaQu4WW+Jl8jQJHv3ejXI+uHuaIz6MMDnSe5mafXkni4Rq 1vw8B6UaJXxZCRJ4NCg4ZNbBnpPO9pPbXg9L2p0sHYutk2sT1tFY3FcS+B3+Gb6OTTiJ KkMpe2vlI9cZ55kNd1T9+OonklgofrWA3MJ7NPAJmu5iljC8/iUS25ohfR1Gt2LwNLmN rk3PPe9TElvL0FGkDcwue53ZjueQxPV5SkN/tgkrZdk3FwT/W24aDKR1d+9IpHA2hBjA PjNWa8VOFM3Gxue5VVZl/jwDSocDPeqe15EbcNoE1dDYCezhMaMTNzycez6sz3n6uUMs pP5Q== X-Received: by 10.107.128.41 with SMTP id b41mr6051554iod.74.1444280014256; Wed, 07 Oct 2015 21:53:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.19.67 with HTTP; Wed, 7 Oct 2015 21:53:14 -0700 (PDT) In-Reply-To: References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> <49943603-287F-4C78-AEC1-45628554C190@akamai.com> From: Tony Arcieri Date: Wed, 7 Oct 2015 21:53:14 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113f8bf034c3b0052190a51a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 04:53:36 -0000 --001a113f8bf034c3b0052190a51a Content-Type: text/plain; charset=UTF-8 On Wed, Oct 7, 2015 at 9:43 PM, Eric Rescorla wrote: > Yes, this is what I believe it says and what I believe the WG had consensus > on, the reasoning being that we really wished to just remove the feature > entirely. If the chairs declare consensus on something else, I will of > course edit > it to say something else. > I think it would be prudent for the chairs to give some sort of judgment on this issue, given the high volumes of mailing list traffic created by a small number of detractors despite what is otherwise a rough consensus -- Tony Arcieri --001a113f8bf034c3b0052190a51a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 7, 2015 at 9:43 PM, Eric Rescorla <ekr@= rtfm.com> wrote:
Yes, th= is is what I believe it says and what I believe the WG had consensus
<= div>on, the reasoning being that we really wished to just remove the featur= e
entirely. If the chairs declare consensus on something else, I = will of course edit
it to say something else.

I think it would be prudent for the ch= airs to give some sort of judgment on this issue, given the high volumes of= mailing list traffic created by a small number of detractors despite what = is otherwise a rough consensus

--
Tony Arcieri
--001a113f8bf034c3b0052190a51a-- From nobody Wed Oct 7 21:56:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2261A87D1 for ; Wed, 7 Oct 2015 21:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whbj_KtQTai3 for ; Wed, 7 Oct 2015 21:56:55 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 27FE11A87C9 for ; Wed, 7 Oct 2015 21:56:55 -0700 (PDT) Received: from [173.75.83.223] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Zk3G0-0005fU-B9; Thu, 08 Oct 2015 00:56:44 -0400 Date: Wed, 7 Oct 2015 21:56:39 -0700 From: Bill Frantz To: Eric Rescorla X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec790b946754916f504b1429c7f144c1b5d0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.223 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 04:56:56 -0000 On 10/8/15 at 9:43 PM, ekr@rtfm.com (Eric Rescorla) wrote: >Yes, this is what I believe it says and what I believe the WG had consensu= s >on, the reasoning being that we really wished to just remove the feature >entirely. If the chairs declare consensus on something else, I will of >course edit >it to say something else. I would love to support compression, but I don't hear any of the=20 proponents suggesting a way to support compression that is=20 immune to the the attacks that have already been fielded. With=20 nothing safe on the table, I think compression has to be kicked=20 up a layer. It is possible to think of a parallel layer to TLS which only=20 does compression and offers no secrecy features. This facility=20 may solve the NNTP problem, but I am not qualified to say=20 whether it can solve that problem or not. In any case, such a=20 facility may have many features in common with TLS, including a=20 compatible initial negotiation, but it would not be a privacy=20 protocol. It could include integrity. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345=20 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos,=20 CA 95032 From nobody Thu Oct 8 02:30:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A491A1A1B3F for ; Thu, 8 Oct 2015 02:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 NSyLe8xZHxUr for ; Thu, 8 Oct 2015 02:30:05 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 48FD21A1A96 for ; Thu, 8 Oct 2015 02:30:05 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t989TsaG026982 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 8 Oct 2015 11:29:55 +0200 From: Simon Josefsson To: tls@ietf.org References: OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151008:sean@sn3rd.com::NAVyCWd+BTHPCqEq:1pvV X-Hashcash: 1:22:151008:tls@ietf.org::PM+VB+eSxvETQKy3:GcB8 Date: Thu, 08 Oct 2015 11:29:53 +0200 In-Reply-To: (Sean Turner's message of "Tue, 22 Sep 2015 16:27:35 -0700") Message-ID: <87vbahu2r2.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [TLS] tls-unique X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 09:30:06 -0000 --=-=-= Content-Type: text/plain The notes from the interim meeting mentions 'tls-unique' and points to issue #228 on github. I want to get your attention on the draft below. Doesn't it do what you are looking for? There is a little in the way of a problem statement in the TLS interim meeting notes, so it is hard to tell what the perceived problem with 'tls-unique' is in this context. Does my draft need to be updated for TLS 1.3 in any way? It might serve as a starting point for future work. https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWFjeRAAoJEIYLf7sy+BGd5PYH/RHPCjUnfHk1Z3dMGySsIyn+ 13mZrd44aEu3YbQBbUqamaDgRvJ4BjxGXRXD2UrVbCHNOeesovpQiixt4+mKJ581 Dq9vHCqbfEM8BRAkmw3D6rrieJwW8wrXOmafMUQem2TuhL+V5UxxN6tIbeFex/f9 bvBTg/2cUkLeBxvhdrDnFJD962KZEoJVNEEKrNVKzr3yfeBuDWi+r+UbOT3MMrgB +mzy67Lp1K7IlU375awEvnRZAZQEO6DultegU6JO3MWw0MMBZ/gnUKGjvYXkdEe7 vnixG1LTj1ODPbBVmAClrjQn2NoqO1fA29HmAip2+MjQ0d4N6xM59AUbHz1P9R0= =8yBI -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 8 03:05:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5C31ACD76 for ; Thu, 8 Oct 2015 03:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq_3kVDWZEKW for ; Thu, 8 Oct 2015 03:05:32 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 75C6F1A9172 for ; Thu, 8 Oct 2015 03:05:32 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so17607780wic.0 for ; Thu, 08 Oct 2015 03:05:31 -0700 (PDT) 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-type; bh=0+o+THzp/UFlMzuwZbDOaxM+NOv22hFKpFh2FovP+i8=; b=ECAGMXlgv+w5+IslJ6S2sPsW8y2hMQpG/Td04qGmx8q8UbSNRpij+aziaAHg9F+NGX 0ScjIhSWZcqW5XQh6XmD2ffy3GJZfxjYCpCaHj0P/Qgkw+JGIJKMPyck0uAE9HrGTpPq QKoUdDGpPFLfIR8ESbfK8yxlgy55NU9bF/poNdOxyBAP53fQBBCp31+JeNY5DRj1W16t fS3eW1JV2YklbF9EEhjuHOFfE7Y13Wzibu/8mjTh+hrczCwNeP6AZ4ySe6SiJPOiQVH7 0qFDHQdC5VQs2XpwPrAqbR+YQn++tgZk06ZxVI2FJ7L1kRoqqYW/YWbywOTMaQlUD+fB BGdg== X-Gm-Message-State: ALoCoQndcjmDTv+HYVXYgjuZOBBP84yxt30cHZ7zJwfdSxerkipewaUqBriA/2XwmL+QAo0bBl29 X-Received: by 10.194.133.129 with SMTP id pc1mr6711595wjb.148.1444298730886; Thu, 08 Oct 2015 03:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Thu, 8 Oct 2015 03:04:51 -0700 (PDT) In-Reply-To: <87vbahu2r2.fsf@latte.josefsson.org> References: <87vbahu2r2.fsf@latte.josefsson.org> From: Eric Rescorla Date: Thu, 8 Oct 2015 12:04:51 +0200 Message-ID: To: Simon Josefsson Content-Type: multipart/alternative; boundary=089e01227d94cdfd6305219500d5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] tls-unique X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 10:05:34 -0000 --089e01227d94cdfd6305219500d5 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson wrote: > The notes from the interim meeting mentions 'tls-unique' and points to > issue #228 on github. I want to get your attention on the draft below. > Doesn't it do what you are looking for? There is a little in the way of > a problem statement in the TLS interim meeting notes, so it is hard to > tell what the perceived problem with 'tls-unique' is in this context. > Does my draft need to be updated for TLS 1.3 in any way? It might serve > as a starting point for future work. > > https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF. With that said, I don't really understand the structure of your draft: Instead of referencing the PRF and session_hash directly, why not instead use RFC 5705 exporters and require the use of the session_hash extension? Then TLS 1.3 can just define exporters for 1.3 and we'll be done. -Ekr > /Simon > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e01227d94cdfd6305219500d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 8, 2015 at 11:29 AM, Simon Josefsson <simon@josefsson.org&g= t; wrote:
The notes from the inter= im meeting mentions 'tls-unique' and points to
issue #228 on github.=C2=A0 I want to get your attention on the draft below= .
Doesn't it do what you are looking for?=C2=A0 There is a little in the = way of
a problem statement in the TLS interim meeting notes, so it is hard to
tell what the perceived problem with 'tls-unique' is in this contex= t.
Does my draft need to be updated for TLS 1.3 in any way?=C2=A0 It might ser= ve
as a starting point for future work.

https://tools.ietf.org/html/draft-josefss= on-sasl-tls-cb-03

Well, TLS 1.3 doesn&#= 39;t have a PRF, but instead explicitly uses HKDF.

With that said, I don't really understand the structure of your draft:=
Instead of referencing the PRF and session_hash directly, why no= t instead
use RFC 5705 exporters and require the use of the sessi= on_hash extension?
Then TLS 1.3 can just define exporters for 1.3= and we'll be done.

-Ekr

/Simon

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


--089e01227d94cdfd6305219500d5-- From nobody Thu Oct 8 03:16:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916641ACE2D for ; Thu, 8 Oct 2015 03:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 Nzq7IFeZY4pC for ; Thu, 8 Oct 2015 03:16:45 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 D98CC1ACE96 for ; Thu, 8 Oct 2015 03:16:40 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t98AGOQ0031822 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 8 Oct 2015 12:16:25 +0200 From: Simon Josefsson To: Eric Rescorla References: <87vbahu2r2.fsf@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151008:tls@ietf.org::a7fAb+io1wxLJA+Q:GoI8 X-Hashcash: 1:22:151008:ekr@rtfm.com::ua4ccsec5ZmEjuci:c7Vh Date: Thu, 08 Oct 2015 12:16:23 +0200 In-Reply-To: (Eric Rescorla's message of "Thu, 8 Oct 2015 12:04:51 +0200") Message-ID: <87612hpsw8.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] tls-unique X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 10:16:46 -0000 --=-=-= Content-Type: text/plain Eric Rescorla writes: > On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson > wrote: > >> The notes from the interim meeting mentions 'tls-unique' and points to >> issue #228 on github. I want to get your attention on the draft below. >> Doesn't it do what you are looking for? There is a little in the way of >> a problem statement in the TLS interim meeting notes, so it is hard to >> tell what the perceived problem with 'tls-unique' is in this context. >> Does my draft need to be updated for TLS 1.3 in any way? It might serve >> as a starting point for future work. >> >> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 > > > Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF. > > With that said, I don't really understand the structure of your draft: > Instead of referencing the PRF and session_hash directly, why not instead > use RFC 5705 exporters and require the use of the session_hash > extension? The introduction says: There exists a TLS extension [I-D.ietf-tls-session-hash] that modify TLS so that the definition of 'tls-unique' [RFC5929] has the intended properties. If widely implemented and deployed, the channel binding type in this document would not offer any additional protection. The purpose of this document is to provide an alternative channel binding that offers the intended properties without requiring TLS protocol changes. However, keep in mind that TLS implementations needs to offer the appropriate APIs necessary to be able to implement the channel binding described in this document. I agree that one alternative is to require session_hash for all connections. But then what is the problem with use of 'tls-unique'? The github issue and the interim notes aren't clear on that. > Then TLS 1.3 can just define exporters for 1.3 and we'll be done. Right. My draft intends to use TLS exporters but I see that it isn't aligned with RFC 5705. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWFkJ3AAoJEIYLf7sy+BGdpFAH/3GvzF0UvXV0u/bTufLXMadJ 69N2qFGB5Kr9gTy0hpxnIsiwkRx2hDHmZy1S+PovDCDoBsyyT8v6QdjjG3A7z2aQ VMU0/dAIs4xVgRzI31vqBwaM3Z/3kdA94V9t/bDLEhAYaVpcqe7hQBPqq5HQdF1x MZTz6Hn9Zb/ijApEU6lc5+2PuneEiudssDzD1aNlkfeejhI7Tz80d8j9XzzTT7ab Vf8foxwizVazV5iaoN8DD4N/FkPtwfOKvnPn60Owit3mam9fw5sWGg0UBWMgbBxS i+fH3Zn7GqhCi0OkLTAvE6mnjG94ImdBOLj4py/axLpNvozO/dDVgUJYX4R4HdA= =y3xo -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 8 03:23:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC151AD35F for ; Thu, 8 Oct 2015 03:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca8F6YEEF4Pi for ; Thu, 8 Oct 2015 03:23:56 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.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 26BCE1B29DC for ; Thu, 8 Oct 2015 03:23:54 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so18262133wic.0 for ; Thu, 08 Oct 2015 03:23:52 -0700 (PDT) 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-type; bh=bOIW6Wf4Lc19UuHxyzL9zpQ1yjuyOD6aFL65dATiQt0=; b=cjNB9TpcN6FBH/PF0Lqa/cDaRSBOp7Ogwq5RE6nQ/yxcSZZSO6np+QPRQ1+n6rom08 Iby4UgyB6ZxEWw5xi38MAk3cp1ASgxjreSMwiFQ1ce9yzw7PXOwSWrguxjxRnBHTR8oU FAU6/Pv9NMJ0qa29TzszepnE/B5y1hfQUVXWr/JWu39VHJ8SLgoq/o3P08QxrMYpNsl7 oE8LDBpWXgjc2veKfFLbD8BLdcPLfJCO8jLbEOewQdN1cCuUojP7qGzxEZfa+Jz82i7L bcp9vXJvHh25jmT0hs1eCMNNaWX9JdoVLeJ4MQUVVwo+B1UyEXbengO4hqqkcdx6OmUK rlng== X-Gm-Message-State: ALoCoQmAFi0LcTyzxf8JyrfskhvrlEPtzd8sivZjP3M3E9CwJMXdIbx598bG8VqdK017vg2qnyTd X-Received: by 10.194.133.129 with SMTP id pc1mr6821263wjb.148.1444299832739; Thu, 08 Oct 2015 03:23:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Thu, 8 Oct 2015 03:23:13 -0700 (PDT) In-Reply-To: <87612hpsw8.fsf@latte.josefsson.org> References: <87vbahu2r2.fsf@latte.josefsson.org> <87612hpsw8.fsf@latte.josefsson.org> From: Eric Rescorla Date: Thu, 8 Oct 2015 12:23:13 +0200 Message-ID: To: Simon Josefsson Content-Type: multipart/alternative; boundary=089e01227d947ad5df0521954244 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] tls-unique X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 10:23:57 -0000 --089e01227d947ad5df0521954244 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 12:16 PM, Simon Josefsson wrote: > Eric Rescorla writes: > > > On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson > > wrote: > > > >> The notes from the interim meeting mentions 'tls-unique' and points to > >> issue #228 on github. I want to get your attention on the draft below. > >> Doesn't it do what you are looking for? There is a little in the way of > >> a problem statement in the TLS interim meeting notes, so it is hard to > >> tell what the perceived problem with 'tls-unique' is in this context. > >> Does my draft need to be updated for TLS 1.3 in any way? It might serve > >> as a starting point for future work. > >> > >> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 > > > > > > Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF. > > > > With that said, I don't really understand the structure of your draft: > > Instead of referencing the PRF and session_hash directly, why not instead > > use RFC 5705 exporters and require the use of the session_hash > > extension? > > The introduction says: > > There exists a TLS extension [I-D.ietf-tls-session-hash] that modify > TLS so that the definition of 'tls-unique' [RFC5929] has the intended > properties. If widely implemented and deployed, the channel binding > type in this document would not offer any additional protection. The > purpose of this document is to provide an alternative channel binding > that offers the intended properties without requiring TLS protocol > changes. However, keep in mind that TLS implementations needs to > offer the appropriate APIs necessary to be able to implement the > channel binding described in this document. > > I agree that one alternative is to require session_hash for all > connections. Given that you need to modify *some* software in any case, it seems like one ought to adopt session-hash. > But then what is the problem with use of 'tls-unique'? > The general consensus is that 96 bits is too short. -Ekr --089e01227d947ad5df0521954244 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 8, 2015 at 12:16 PM, Simon Josefsson <= simon@josefsson.or= g> wrote:
Eric Rescor= la <ekr@rtfm.com&g= t; writes:

> On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson <simon@josefsson.org>
> wrote:
>
>> The notes from the interim meeting mentions 'tls-unique' a= nd points to
>> issue #228 on github.=C2=A0 I want to get your attention on the dr= aft below.
>> Doesn't it do what you are looking for?=C2=A0 There is a littl= e in the way of
>> a problem statement in the TLS interim meeting notes, so it is har= d to
>> tell what the perceived problem with 'tls-unique' is in th= is context.
>> Does my draft need to be updated for TLS 1.3 in any way?=C2=A0 It = might serve
>> as a starting point for future work.
>>
>> https://tools.ietf.org/html/draft= -josefsson-sasl-tls-cb-03
>
>
> Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF= .
>
> With that said, I don't really understand the structure of your dr= aft:
> Instead of referencing the PRF and session_hash directly, why not inst= ead
> use RFC 5705 exporters and require the use of the session_hash
> extension?

The introduction says:

=C2=A0 =C2=A0There exists a TLS extension [I-D.ietf-tls-session-hash] that = modify
=C2=A0 =C2=A0TLS so that the definition of 'tls-unique' [RFC5929] h= as the intended
=C2=A0 =C2=A0properties.=C2=A0 If widely implemented and deployed, the chan= nel binding
=C2=A0 =C2=A0type in this document would not offer any additional protectio= n.=C2=A0 The
=C2=A0 =C2=A0purpose of this document is to provide an alternative channel = binding
=C2=A0 =C2=A0that offers the intended properties without requiring TLS prot= ocol
=C2=A0 =C2=A0changes.=C2=A0 However, keep in mind that TLS implementations = needs to
=C2=A0 =C2=A0offer the appropriate APIs necessary to be able to implement t= he
=C2=A0 =C2=A0channel binding described in this document.

I agree that one alternative is to require session_hash for all
connections.

Given that you need to modify = *some* software in any case, it seems
like one ought to adopt ses= sion-hash.

=C2=A0
=C2=A0 But then what is the problem with use of 'tls-unique'?

The general consensus is that 96 bits is= too short.

-Ekr

<= /div> --089e01227d947ad5df0521954244-- From nobody Thu Oct 8 04:20:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3BE1B2BDF for ; Thu, 8 Oct 2015 04:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 ypq-VZKf2ftQ for ; Thu, 8 Oct 2015 04:20:30 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 6C66E1B2BDC for ; Thu, 8 Oct 2015 04:20:30 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t98BKQdu005651 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 8 Oct 2015 13:20:27 +0200 Date: Thu, 8 Oct 2015 13:20:25 +0200 From: Simon Josefsson To: Eric Rescorla Message-ID: <20151008132025.68eb7f3a@latte.josefsson.org> In-Reply-To: References: <87vbahu2r2.fsf@latte.josefsson.org> <87612hpsw8.fsf@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/7A1Op_.bamSnNk4CMVhDO3K"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] tls-unique X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 11:20:33 -0000 --Sig_/7A1Op_.bamSnNk4CMVhDO3K Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > > The introduction says: > > > > There exists a TLS extension [I-D.ietf-tls-session-hash] that > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the > > intended properties. If widely implemented and deployed, the > > channel binding type in this document would not offer any > > additional protection. The purpose of this document is to provide > > an alternative channel binding that offers the intended properties > > without requiring TLS protocol changes. However, keep in mind that > > TLS implementations needs to offer the appropriate APIs necessary > > to be able to implement the channel binding described in this > > document. > > > > I agree that one alternative is to require session_hash for all > > connections. >=20 >=20 > Given that you need to modify *some* software in any case, it seems > like one ought to adopt session-hash. The problem is if you want to resolve this at the application level and don't have sufficient control over the TLS layer to influence it to negotiate session-hash. This is the situation for many SASL applications. If universal adoption of session-hash is a prio, then there is no problem. While RFC 7627 updates 5246 it does not talk a lot about what it actually updates in 5246, or I missed it, and I haven't seen session-hash functionality back-ported to deployed code. My current approach works with or without session-hash negotiated, but requires that you can get the session_hash value out of the TLS stack. Another approach is to say that if session-hash is in use, it uses a simple TLS exporter API call, and if it is not, it has to use TLS exporter API on the session_hash value. This would secure all cases. > > But then what is the problem with use of 'tls-unique'? >=20 > The general consensus is that 96 bits is too short. I agree -- I used 256 bits. /Simon --Sig_/7A1Op_.bamSnNk4CMVhDO3K Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFlF5AAoJEIYLf7sy+BGdWcwH/iVavQnuWDHwYrkH0QDjZtlg IgWpcWdgBRiseL6mbQ6q1/QpUkfpCB0LkGZlPf8Xkl1dI7zSSJWPWSTP5+CqvNLp 4ERparzwnRKAkYgN74SrZJpydyAUvDj6gjIMMCTOhvluGqF+D9VGVCJi5QsuStBF hBsO53tdBmk2Nfbccix6Ly5hxfdWgFURJiK3tJK1uc7vlwRxHgu06bnfBEKb2FVa BS/8+RW0+eJCjXnPM+pU+atBRKkiI/KHB1h2WSwxGcLM4Z87W3rzaSIXU3egeJ1N xTGfXxZh6e9DZE0Knb5BUubRkf7J+yhbo5dxthKllj8XVNDLk2V+eqlNODf5nME= =AuM+ -----END PGP SIGNATURE----- --Sig_/7A1Op_.bamSnNk4CMVhDO3K-- From nobody Thu Oct 8 04:56:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3FA1B32B9 for ; Thu, 8 Oct 2015 04:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLfBy8pPZoHm for ; Thu, 8 Oct 2015 04:56:34 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 8B3C71A876F for ; Thu, 8 Oct 2015 04:56:34 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so24724462wic.0 for ; Thu, 08 Oct 2015 04:56:33 -0700 (PDT) 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-type; bh=l+KdBdyj3fuCc30p96BaviJWAvJYdh/M6W+qyXGWLcU=; b=VL2oqInqLgSNRatSi0r847ntrUsbBaph8wn9w/NwrbqfWd1Rk6tNa83UrgXwT07ZuX CQ2bd71qFaTYseIoC2QKEuQT2+tmpc6c/jeJ33WillzcGZ0ZE0/a7i2NJ9fPrirC5ivR w3sZtWVQYsrYUmezNsu0/iMb5ML5trV4vYzuJqe48v0nw4UZ6v63GYy2ltGphrykTPvl 2pVDYSMkD3ibG/mttOHOgcsjHOVgJnJcdG5KAAek5uDtnu+sTbOHnF0VACpRsSd3X0Da AaCsqW5Psn3qM5oTmWwnkd9VCE/1EIdH6hjJEE/Z+PpWnInLtOQQECB15c6N7EZgpeo6 OlQw== X-Gm-Message-State: ALoCoQmEtJ87TeQPDWXXKjNrB7hlSnkqLBfrKl/XQGe5IP3fCie+XckguwHHdAdgLzeLhXhP7wyM X-Received: by 10.194.238.228 with SMTP id vn4mr7332885wjc.13.1444305392912; Thu, 08 Oct 2015 04:56:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.220.22 with HTTP; Thu, 8 Oct 2015 04:55:53 -0700 (PDT) In-Reply-To: <20151008132025.68eb7f3a@latte.josefsson.org> References: <87vbahu2r2.fsf@latte.josefsson.org> <87612hpsw8.fsf@latte.josefsson.org> <20151008132025.68eb7f3a@latte.josefsson.org> From: Eric Rescorla Date: Thu, 8 Oct 2015 13:55:53 +0200 Message-ID: To: Simon Josefsson Content-Type: multipart/alternative; boundary=001a11c25adce4715d0521968d92 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] tls-unique X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 11:56:36 -0000 --001a11c25adce4715d0521968d92 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson wrote: > > > The introduction says: > > > > > > There exists a TLS extension [I-D.ietf-tls-session-hash] that > > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the > > > intended properties. If widely implemented and deployed, the > > > channel binding type in this document would not offer any > > > additional protection. The purpose of this document is to provide > > > an alternative channel binding that offers the intended properties > > > without requiring TLS protocol changes. However, keep in mind that > > > TLS implementations needs to offer the appropriate APIs necessary > > > to be able to implement the channel binding described in this > > > document. > > > > > > I agree that one alternative is to require session_hash for all > > > connections. > > > > > > Given that you need to modify *some* software in any case, it seems > > like one ought to adopt session-hash. > > The problem is if you want to resolve this at the application level and > don't have sufficient control over the TLS layer to influence it to > negotiate session-hash. This is the situation for many SASL > applications. > > If universal adoption of session-hash is a prio, then there is no > problem. While RFC 7627 updates 5246 it does not talk a lot about what > it actually updates in 5246, or I missed it, and I haven't seen > session-hash functionality back-ported to deployed code. > I'm not sure what you mean by "backported", but I believe that BoringSSL presently has session-hash, SChannel has it soon or does already, and the next version of NSS (3.21) will have it. My current approach works with or without session-hash negotiated, but > requires that you can get the session_hash value out of the TLS stack. > I am not aware of a stack which has this function. Are you? -Ekr Another approach is to say that if session-hash is in use, it uses a > simple TLS exporter API call, and if it is not, it has to use TLS > exporter API on the session_hash value. This would secure all cases. > > > > But then what is the problem with use of 'tls-unique'? > > > > The general consensus is that 96 bits is too short. > > I agree -- I used 256 bits. > > /Simon > --001a11c25adce4715d0521968d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson <<= a href=3D"mailto:simon@josefsson.org" target=3D"_blank">simon@josefsson.org= > wrote:
&= gt; > The introduction says:
> >
> >=C2=A0 =C2=A0 There exists a TLS extension [I-D.ietf-tls-session-h= ash] that
> > modify TLS so that the definition of 'tls-unique' [RFC592= 9] has the
> > intended properties.=C2=A0 If widely implemented and deployed, th= e
> > channel binding type in this document would not offer any
> > additional protection.=C2=A0 The purpose of this document is to p= rovide
> > an alternative channel binding that offers the intended propertie= s
> > without requiring TLS protocol changes.=C2=A0 However, keep in mi= nd that
> > TLS implementations needs to offer the appropriate APIs necessary=
> > to be able to implement the channel binding described in this
> > document.
> >
> > I agree that one alternative is to require session_hash for all > > connections.
>
>
> Given that you need to modify *some* software in any case, it seems > like one ought to adopt session-hash.

The problem is if you want to resolve this at the application level = and
don't have sufficient control over the TLS layer to influence it to
negotiate session-hash.=C2=A0 This is the situation for many SASL
applications.

If universal adoption of session-hash is a prio, then there is no
problem.=C2=A0 While RFC 7627 updates 5246 it does not talk a lot about wha= t
it actually updates in 5246, or I missed it, and I haven't seen
session-hash functionality back-ported to deployed code.

I'm not sure what you mean by "backported",= but I believe that BoringSSL
presently has session-hash, SChanne= l has it soon or does already, and
the next version of NSS (3.21)= will have it.


My current approach works with or without session-hash negotiated, but
requires that you can get the session_hash value out of the TLS stack.
<= /blockquote>

I am not aware of a stack which has this fu= nction. Are you?

-Ekr

Another approach is to say that if session-hash is in use, it uses a
simple TLS exporter API call, and if it is not, it has to use TLS
exporter API on the session_hash value.=C2=A0 This would secure all cases.<= br>
> >=C2=A0 =C2=A0But then what is the problem with use of 'tls-uni= que'?
>
> The general consensus is that 96 bits is too short.

I agree -- I used 256 bits.

/Simon

--001a11c25adce4715d0521968d92-- From nobody Thu Oct 8 05:37:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF791B3342 for ; Thu, 8 Oct 2015 05:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 yVROc6nZj_Mm for ; Thu, 8 Oct 2015 05:36:58 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 157981B3344 for ; Thu, 8 Oct 2015 05:36:56 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t98Cah30012804 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 8 Oct 2015 14:36:44 +0200 From: Simon Josefsson To: Eric Rescorla References: <87vbahu2r2.fsf@latte.josefsson.org> <87612hpsw8.fsf@latte.josefsson.org> <20151008132025.68eb7f3a@latte.josefsson.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151008:tls@ietf.org::dIKM2DIGYPx4xnSQ:Ei2X X-Hashcash: 1:22:151008:ekr@rtfm.com::T+ATREeNsWKyofp+:KD3M Date: Thu, 08 Oct 2015 14:36:42 +0200 In-Reply-To: (Eric Rescorla's message of "Thu, 8 Oct 2015 13:55:53 +0200") Message-ID: <87si5lo7tx.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] tls-unique X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 12:36:59 -0000 --=-=-= Content-Type: text/plain Eric Rescorla writes: > On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson wrote: > >> > > The introduction says: >> > > >> > > There exists a TLS extension [I-D.ietf-tls-session-hash] that >> > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the >> > > intended properties. If widely implemented and deployed, the >> > > channel binding type in this document would not offer any >> > > additional protection. The purpose of this document is to provide >> > > an alternative channel binding that offers the intended properties >> > > without requiring TLS protocol changes. However, keep in mind that >> > > TLS implementations needs to offer the appropriate APIs necessary >> > > to be able to implement the channel binding described in this >> > > document. >> > > >> > > I agree that one alternative is to require session_hash for all >> > > connections. >> > >> > >> > Given that you need to modify *some* software in any case, it seems >> > like one ought to adopt session-hash. >> >> The problem is if you want to resolve this at the application level and >> don't have sufficient control over the TLS layer to influence it to >> negotiate session-hash. This is the situation for many SASL >> applications. >> >> If universal adoption of session-hash is a prio, then there is no >> problem. While RFC 7627 updates 5246 it does not talk a lot about what >> it actually updates in 5246, or I missed it, and I haven't seen >> session-hash functionality back-ported to deployed code. >> > > I'm not sure what you mean by "backported", but I believe that BoringSSL > presently has session-hash, SChannel has it soon or does already, and > the next version of NSS (3.21) will have it. If session-hash isn't backported to deployed code, like some other security fixes has been backported (e.g., secure renegotiation), it will take years until it is deployed. Using only an TLS exporter interface will therefor be insecure meanwhile, as far as I understand, since it doesn't bind the entire handshake messages. However, you could have a new TLS channel binding based on the TLS exporter interface that demands use of session-hash, as you suggest. >> My current approach works with or without session-hash negotiated, but >> requires that you can get the session_hash value out of the TLS stack. > > I am not aware of a stack which has this function. Are you? No. Either the application inspects the handshake or code has to be added. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWFmNaAAoJEIYLf7sy+BGdhoEIAJc6bR7/URxFqVABvKX6GdtA PFf6Ypv9k+K1PUAzNFSJW65VRJuRksIwwivHlA8I7MJz/dE/VW9M7GPE0oM/0rrx z24CbQLeTqWnuYz9t8C2gIUfP0UUpdqrFbh3HsSKBdITXk0dLnKfRnnDFjAYXa3/ +K+lGTSDVpYnUL60dfQl/RMaG3IfhQmqOt441pmJMTySU+bBk7l7fSzPasdzBAtb JmSfEfwpGW/yX4ux2Mfh5obdrBUQptm3sYuW+K1ikkVD4XalK8w718YRr+9wI1+m CxTKlH3cPE8PSf5RyO1FevgaoIsbL6MNeFao3w//U4fLVoZhzRcpsWr7Hyydonc= =7mGr -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 8 06:05:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABC01B337C for ; Thu, 8 Oct 2015 06:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpXkqocZ4owf for ; Thu, 8 Oct 2015 06:05:21 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99C21B3376 for ; Thu, 8 Oct 2015 06:05:20 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 02E179003A; Thu, 8 Oct 2015 16:05:17 +0300 (EEST) Date: Thu, 8 Oct 2015 16:05:17 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151008130517.GA12369@LK-Perkele-VII> References: <87vbahu2r2.fsf@latte.josefsson.org> 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.24 (2015-08-30) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] tls-unique X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 13:05:22 -0000 On Thu, Oct 08, 2015 at 12:04:51PM +0200, Eric Rescorla wrote: > > Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF. > > With that said, I don't really understand the structure of your draft: > Instead of referencing the PRF and session_hash directly, why not instead > use RFC 5705 exporters and require the use of the session_hash extension? > Then TLS 1.3 can just define exporters for 1.3 and we'll be done. TLS 1.3 is different since TLS 1.3 always behaves like session_hash was negotiated, whereas session_hash was a security fix for earlier versions. One idea for TLS-unique for TLS 1.3: Invoke TLS-EXPORTER with: label: "TLS 1.3 tls-unqiue" context: No context Length: 256 And define TLS-EXPORTER for TLS 1.3 as (this looks ugly, have some better way at handling both context and no context cases? In original RFC, those were different): tmp = HKDF-Extract(label, exporter_secret) output = HKDF-Expand(tmp, 0x01 | context, L) or (no context case) tmp = HKDF-Extract(label, exporter_secret) output = HKDF-Expand(tmp, , L) This is slightly different from other uses of HKDF. I don't mix in session hash since exporter_secret is already Secret Nonce. -Ilari From nobody Thu Oct 8 09:56:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8091AC3D2 for ; Thu, 8 Oct 2015 09:56:05 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPD_yydqN-78 for ; Thu, 8 Oct 2015 09:56:04 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 6B5511AC3BF for ; Thu, 8 Oct 2015 09:56:04 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so17343262igb.0 for ; Thu, 08 Oct 2015 09:56:03 -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:date:message-id :subject:from:to:cc:content-type; bh=Qz7KMgW//wt25cPbDZov8V/VwbSoWI5DpSMsh2jzfxI=; b=GUn7j9Rn9QuRypKz96shud3Lsz/Y/rSyznFqq7Zgmg6n5yd2KHY4RmAromBK/09RGJ dvg/JV57RiQ3hR7KwijnLEADGL9zhfjYs47umk+z6kXWR0GHgXxPwxQ7PosufW4D1n8s Wy7pfMcuWc8yFvyx4BtcxNqUyeGrAt9qpAU7JhwW1vLcOqh0XfR5H68BQRpWUw5aj2FI 5hclimLOTlqQcSuaa5PqoSCYVHPT0xvNReb599VTiPJmZhRk1xVuduY6N1nX3BatWApW 4YB3bdyi23J/u9a/81TUjMmLDaJ2mQu3RABProPIZdKbtjZQJWLekLx0dUAXThyVOvF3 quJw== MIME-Version: 1.0 X-Received: by 10.50.138.72 with SMTP id qo8mr5451797igb.46.1444323363843; Thu, 08 Oct 2015 09:56:03 -0700 (PDT) Received: by 10.36.123.131 with HTTP; Thu, 8 Oct 2015 09:56:03 -0700 (PDT) In-Reply-To: References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> <49943603-287F-4C78-AEC1-45628554C190@akamai.com> Date: Thu, 8 Oct 2015 12:56:03 -0400 Message-ID: From: Jeffrey Walton To: Tony Arcieri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 08 Oct 2015 16:56:06 -0000 On Thu, Oct 8, 2015 at 12:53 AM, Tony Arcieri wrote: > On Wed, Oct 7, 2015 at 9:43 PM, Eric Rescorla wrote: >> >> Yes, this is what I believe it says and what I believe the WG had >> consensus >> on, the reasoning being that we really wished to just remove the feature >> entirely. If the chairs declare consensus on something else, I will of >> course edit >> it to say something else. > > > I think it would be prudent for the chairs to give some sort of judgment on > this issue, given the high volumes of mailing list traffic created by a > small number of detractors despite what is otherwise a rough consensus That's kind of a loaded request. We would need to know the security goals and objectives to ensure things are progressing as expected. As far as I know, they are not stated anywhere. For example, if a goal is to ensure TLS is trouble free and does not get egg on its face, then the goal is met by removing compression altogether. If the goal is to ensure TLS users are safe, then the result will likely fail to meet expectation because there will be 1,000's of incorrect, 1-off solutions. The failed goal assumes not everyone RTFM's, which I think is reasonable given past history. I can't help but feel if RTFM was going to work, it would have happened in the last 30 or 50 years or so. Jeff From nobody Thu Oct 8 11:53:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012E91A9248 for ; Thu, 8 Oct 2015 11:53:49 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdCw0_m6tiEQ for ; Thu, 8 Oct 2015 11:53:46 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c: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 E593A1A9240 for ; Thu, 8 Oct 2015 11:53:45 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so41405494wic.1 for ; Thu, 08 Oct 2015 11:53: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:date:message-id:subject:from:to :cc:content-type; bh=WpAO7xQt4ED7rgXVBVY1oSL9LaDD03GDB/31O9YVrDw=; b=HIK+aYFFsCp9gVL/5DEfqmASdGltFEIFWU3uium6geeJ3vIrKyJdn5c2mQDcn+vArz MfYO9xqLjji9tLk47EmoWu5Mbo+Sk1twjb4wNnPX57WiidKLybBtSuHZuv0Ucs4ydAS4 4RXNK+Ys1CY65YZdlRz0YQEw92Sg5/t9wQHgRzrRPQGzzmaOa6aSuNwZofLEmmHN5Sl2 Lj/ipTRC/y0RQorMatxQSetf28Hwd4TSy7nZTVd78tjUP5fTNwD1GJGxT28h3lsA5aqg 44vR1oA5fMH84vX2WrzmHUBw4Bmmtyax7P9uMaPrBY3EAFYHoSKpuhL/hnlEvGS9AVZY AEWQ== MIME-Version: 1.0 X-Received: by 10.194.175.232 with SMTP id cd8mr10541629wjc.45.1444330424487; Thu, 08 Oct 2015 11:53:44 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Thu, 8 Oct 2015 11:53:43 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Thu, 8 Oct 2015 11:53:43 -0700 (PDT) In-Reply-To: References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> <49943603-287F-4C78-AEC1-45628554C190@akamai.com> Date: Thu, 8 Oct 2015 14:53:43 -0400 Message-ID: From: Watson Ladd To: noloader@gmail.com Content-Type: multipart/alternative; boundary=089e013d1020e3d3b005219c6144 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 18:53:49 -0000 --089e013d1020e3d3b005219c6144 Content-Type: text/plain; charset=UTF-8 On Oct 8, 2015 12:56 PM, "Jeffrey Walton" wrote: > > On Thu, Oct 8, 2015 at 12:53 AM, Tony Arcieri wrote: > > On Wed, Oct 7, 2015 at 9:43 PM, Eric Rescorla wrote: > >> > >> Yes, this is what I believe it says and what I believe the WG had > >> consensus > >> on, the reasoning being that we really wished to just remove the feature > >> entirely. If the chairs declare consensus on something else, I will of > >> course edit > >> it to say something else. > > > > > > I think it would be prudent for the chairs to give some sort of judgment on > > this issue, given the high volumes of mailing list traffic created by a > > small number of detractors despite what is otherwise a rough consensus > > That's kind of a loaded request. > > We would need to know the security goals and objectives to ensure > things are progressing as expected. As far as I know, they are not > stated anywhere. Not true: secure channel abstractions are well understood. > > For example, if a goal is to ensure TLS is trouble free and does not > get egg on its face, then the goal is met by removing compression > altogether. If the goal is to ensure TLS users are safe, then the > result will likely fail to meet expectation because there will be > 1,000's of incorrect, 1-off solutions. No generic solution will solve the problem. Knowledge of what applications do is required for secure compression. Do you have a proposal that addresses the problems we've duscussed? And please, stop using words like "safe" and "users" and start using words like "universal composability" and "adversarial model" if you actually want to think through these issuses. > > The failed goal assumes not everyone RTFM's, which I think is > reasonable given past history. I can't help but feel if RTFM was going > to work, it would have happened in the last 30 or 50 years or so. Are you denying that the TLS compression option lead to attacks? > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --089e013d1020e3d3b005219c6144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 8, 2015 12:56 PM, "Jeffrey Walton" <noloader@gmail.com> wrote:
>
> On Thu, Oct 8, 2015 at 12:53 AM, Tony Arcieri <bascule@gmail.com> wrote:
> > On Wed, Oct 7, 2015 at 9:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >>
> >> Yes, this is what I believe it says and what I believe the WG= had
> >> consensus
> >> on, the reasoning being that we really wished to just remove = the feature
> >> entirely. If the chairs declare consensus on something else, = I will of
> >> course edit
> >> it to say something else.
> >
> >
> > I think it would be prudent for the chairs to give some sort of j= udgment on
> > this issue, given the high volumes of mailing list traffic create= d by a
> > small number of detractors despite what is otherwise a rough cons= ensus
>
> That's kind of a loaded request.
>
> We would need to know the security goals and objectives to ensure
> things are progressing as expected. As far as I know, they are not
> stated anywhere.

Not true: secure channel abstractions are well understood. >
> For example, if a goal is to ensure TLS is trouble free and does not > get egg on its face, then the goal is met by removing compression
> altogether. If the goal is to ensure TLS users are safe, then the
> result will likely fail to meet expectation because there will be
> 1,000's of incorrect, 1-off solutions.

No generic solution will solve the problem. Knowledge of wha= t applications do is required for secure compression. Do you have a proposa= l that addresses the problems we've duscussed? And please, stop using w= ords like "safe" and "users" and start using words like= "universal composability" and "adversarial model" if y= ou actually want to think through these issuses.

>
> The failed goal assumes not everyone RTFM's, which I think is
> reasonable given past history. I can't help but feel if RTFM was g= oing
> to work, it would have happened in the last 30 or 50 years or so.

Are you denying that the TLS compression option lead to atta= cks?

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

--089e013d1020e3d3b005219c6144-- From nobody Thu Oct 8 12:24:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574021A1B1B for ; Thu, 8 Oct 2015 12:24:04 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T5ymGAz1pXO for ; Thu, 8 Oct 2015 12:24:03 -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 2A3711A1AC6 for ; Thu, 8 Oct 2015 12:24:03 -0700 (PDT) Received: by iofh134 with SMTP id h134so69523201iof.0 for ; Thu, 08 Oct 2015 12:24:02 -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:date:message-id :subject:from:to:cc:content-type; bh=fT80V/T6U1fsAXhjNAambafUp2qwnM7CFl7Bk3KUtOc=; b=fd3NbMiVeM6yxddtD9HI2pX9sPNLO4xzYIjDwiWOkQ4xyJXftS01PIA7gbnsC5ebWY tFnlF3df15nmw3JGQIjFsTVyy2MZAJwRM6eBTfoFeIkjVjm2aPwC0YJl+6Qjo3gaTojn cjlTIjQpm+wPRW13X7XeMsFyyvCAz4K4xy9/AnWHmhlhgvQ/ZPazsHhnQ8GfvCN3dZDd kQzYrr0qHoOSSAGqHzT4uChkIn3/1IJtAdY7Eg2RFoG7QjbTNi8DTDwstYjEJt/ex4Dn OhdGIE733as3UuMQktrm2EUdvWswJv2w+JXHrULZXu8mexmmyn2nwScOLnn84NRXIjMk MS6w== MIME-Version: 1.0 X-Received: by 10.107.14.196 with SMTP id 187mr12041774ioo.11.1444332242664; Thu, 08 Oct 2015 12:24:02 -0700 (PDT) Received: by 10.36.123.131 with HTTP; Thu, 8 Oct 2015 12:24:02 -0700 (PDT) In-Reply-To: References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> <49943603-287F-4C78-AEC1-45628554C190@akamai.com> Date: Thu, 8 Oct 2015 15:24:02 -0400 Message-ID: From: Jeffrey Walton To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 08 Oct 2015 19:24:04 -0000 >> > I think it would be prudent for the chairs to give some sort of judgment >> > on >> > this issue, given the high volumes of mailing list traffic created by a >> > small number of detractors despite what is otherwise a rough consensus >> >> That's kind of a loaded request. >> >> We would need to know the security goals and objectives to ensure >> things are progressing as expected. As far as I know, they are not >> stated anywhere. > > Not true: secure channel abstractions are well understood. Oh, please forgive my ignorance. What are the IETF's security goals and objectives? Are they listed somewhere? Can you provide a link to a document? Jeff From nobody Thu Oct 8 14:20:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC371ACE88 for ; Thu, 8 Oct 2015 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88K8vReNgxAE for ; Thu, 8 Oct 2015 14:20:48 -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 ED6A61ACE8C for ; Thu, 8 Oct 2015 14:20:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C35A8BE58 for ; Thu, 8 Oct 2015 22:20:44 +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 yeAporK77qiJ for ; Thu, 8 Oct 2015 22:20:43 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.26.211]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1E3FBE55 for ; Thu, 8 Oct 2015 22:20:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444339243; bh=ossEzk+D2DOqQ8gEHVWeTVyOiRzDC+v5XpMIjseCtuU=; h=To:From:Subject:Date:From; b=yBnRvVLc3EaF7gn6QpLNfOlYbjykqpr6zVMtW6Oh11D8T2gaZXCuDboBK/vhHve12 p43o7YJe3sVwMbDZZ8WLSdBcniLJolR2+kiZEBoD+qqafd9CU07oYoA2I7ZDzhdaMY NiQk7+JyJ3O04OGD2eJtIDen0aIQCv7ExLuoF3kU= To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <5616DE2A.6060508@cs.tcd.ie> Date: Thu, 8 Oct 2015 22:20:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] TRON workshop X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 21:20:50 -0000 Hiya, First, thanks all for all your ongoing work on TLS1.3. I'm sure we're all aware that this is important stuff that needs to be, and is being, done carefully with due attention to security analysis. Early in the process we had some brief discussion of pausing towards the end of the work to give folks a chance to do analyses of the security and other properties of TLS1.3 just before publication of the RFC. Chatting with the chairs in Prague and with various others since, we think we've reached the point where we need to start executing that bit of the plan, since doing such analyses also takes time and we don't want to add a big delay if we can avoid it. So we're organising a workshop on just that topic to be co-located with NDSS in San Diego in late February 2016. The call for papers is at [1], please read that and circulate to folks who you think could produce useful analyses that can help the WG get an even higher quality TLS1.3 out the door. I'm sure some of you will be wondering about invites to this workshop etc. We'll have to see how many submissions we get and the level of interest and figure out logistics etc closer to time, but this clearly does need a bunch of folks in the room who are important contributors to the WG but who won't be submitting papers. I'll work with the workshop programme committee and the WG chairs to figure out how best to handle that, via invites, remote access if possible etc. More on that as we figure it out. (Feel free to send me and/or the WG chairs your thoughts and offers for help on that.) And just to clarify a possible process question - this workshop will provide input - we're hoping that'll be very high quality input but the normal WG consensus process will be used to process that input in all the usual ways. Think of TRON as being a mega-big design team on steroids if that helps. (Lousy imagery, I know:-) If the workshop indicates that TLS1.3 is fine then that's fairly obviously great, if there are significant new issues identified though, those will need to be brought to this list, and to meetings at IETF95, for resolution via our normal process. Cheers, S. [1] https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers From nobody Thu Oct 8 14:23:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FF71ACE9D for ; Thu, 8 Oct 2015 14:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYSqnjvq8Ozt for ; Thu, 8 Oct 2015 14:22:58 -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 9301C1ACE8B for ; Thu, 8 Oct 2015 14:22:58 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 9AAC22AF86; Thu, 8 Oct 2015 23:22:56 +0200 (CEST) X-purgate-ID: 152705::1444339376-00000827-92144016/0/0 X-purgate-size: 2097 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 mail05.wdf.sap.corp (Postfix) with ESMTP id DB11240776; Thu, 8 Oct 2015 23:22:55 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id D1F431A2CF; Thu, 8 Oct 2015 23:22:55 +0200 (CEST) In-Reply-To: To: Eric Rescorla Date: Thu, 8 Oct 2015 23:22:55 +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: <20151008212255.D1F431A2CF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 08 Oct 2015 21:23:00 -0000 Eric Rescorla wrote: > Short, Todd wrote: >> >> However, for those ClientHello?s that support older versions, the >> compression_method field may contain other values. This means that if a >> TLSv1.3 client happened to support compression for TLSv1.2, it would be >> unable to negotiate that via a single ClientHello. There?s no way to >> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a >> single ClientHello. Yup, that is the problem with the current text. > >> In effect, the document is stating that a TLSv1.3 client MUST NOT support >> compression, regardless of the protocol version that may be negotiated. > > Yes, this is what I believe it says and what I believe the WG had consensus > on, the reasoning being that we really wished to just remove the feature > entirely. If the chairs declare consensus on something else, I will of > course edit it to say something else. The current text is trying to force a specific policy in a fashion that is in the worst conceivable violation of rfc2119 section 6 that is possible. A ClientHello with ClientHello.client_version = (3,3) ClientHello.compression_methods = (1,0) will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers. ClientHello.client_version = (3,4) ClientHello.compression_methods = (1,0) will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers, but TLSv1.3 servers that follow the stupid idea will choke and abort with an "illegal_parameter" alert. Essentially, the current wording is calling for a newly creating what must be called a "compression method intolerance" -- but essentially it is indistinguishable from a "TLS version intolerance" For a number of years, it seemed to have been consensus in the IETF TLS WG that TLS version intolerance is an implemenattion defect and a real problem. It would be sad if the current TLS WG would confirm that recklessly adding handshake failure causing new intolerances into TLSv1.3 is the new engeneering approach. -Martin From nobody Thu Oct 8 14:36:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883BF1ACED3 for ; Thu, 8 Oct 2015 14:36:55 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvOGUxX2CZia for ; Thu, 8 Oct 2015 14:36:54 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 C7FA61ACED4 for ; Thu, 8 Oct 2015 14:36:53 -0700 (PDT) Received: by igcrk20 with SMTP id rk20so22951633igc.1 for ; Thu, 08 Oct 2015 14:36:53 -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-type; bh=1sKHzXvvCMcBu2Zgfemj/MR+TrMmXgsw4BhE2s3PG0g=; b=v79SNg4u5aQQScC2pS/fSFsVEVtHxgLXBAyGP2CW4e0GFQXGM5Ylj3b3KcH9o0/2O8 CTWDc+JlHxAaU6FcniPuFK/qHzDfnMnp/PhfHvdmPVRH0nj/b2CNM2dfYmGjRK9CFr+C 73SfG6/kQ1w54ik/tJOqbPjfy9YSpSzWl8NR3vSgsJoXn5BjbbI6ODB4BgF58c+RwFm0 teSgdRBwCPYECnR/epKeH9KWTjZMGb4xDSY/ji5707tDcaUySzah+NDo85PRGbGke8Cz IJ+qhxCHku7cnN0huB0aA18o2zWJmYEAFYkL6SjGsbzYVmwrEev2E3lh8kOHJ4rvvDA0 IAYQ== X-Received: by 10.50.57.84 with SMTP id g20mr6812799igq.18.1444340213145; Thu, 08 Oct 2015 14:36:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.19.67 with HTTP; Thu, 8 Oct 2015 14:36:33 -0700 (PDT) In-Reply-To: References: <20151007211155.384AC1A2C5@ld9781.wdf.sap.corp> <49943603-287F-4C78-AEC1-45628554C190@akamai.com> From: Tony Arcieri Date: Thu, 8 Oct 2015 14:36:33 -0700 Message-ID: To: Jeffrey Walton Content-Type: multipart/alternative; boundary=047d7bdc12ea56e86205219ea93c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 21:36:55 -0000 --047d7bdc12ea56e86205219ea93c Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 9:56 AM, Jeffrey Walton wrote: > On Thu, Oct 8, 2015 at 12:53 AM, Tony Arcieri wrote: > > I think it would be prudent for the chairs to give some sort of judgment > on > > this issue, given the high volumes of mailing list traffic created by a > > small number of detractors despite what is otherwise a rough consensus > > That's kind of a loaded request. > > We would need to know the security goals and objectives to ensure > things are progressing as expected. As far as I know, they are not > stated anywhere. Jeff, It's a request against you. You are "spamming" this list. TLS is a security protocol, not a compression protocol. Providing secure compression requires application-specific domain knowledge. TLS cannot provide secure compression. A security protocol shouldn't provide insecure compression. TLS can only provide insecure compression, because it lacks the application-specific domain knowledge to implement security correctly. TLS is a security protocol. You are asking TLS, a security protocol, to provide an insecure feature it is conceptually incapable of providing securely. Please stop. That is why I asked the chairs to make a ruling and end the "spam" to the list. This is not a useful discussion. Your argument is conceptually flawed beyond repair and you are literally asking for insecure features to be added to a security protocol. This needs to stop. Please stop. -- Tony Arcieri --047d7bdc12ea56e86205219ea93c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 8, 2015 at 9:56 AM, Jeffrey Walton <noloader@gmail.com> wrote:
On Thu, Oct = 8, 2015 at 12:53 AM, Tony Arcieri <= bascule@gmail.com> wrote:
> I think it would be prudent for th= e chairs to give some sort of judgment on
> this issue, given the high volumes of mailing list traffic created by = a
> small number of detractors despite what is otherwise a rough consensus=

That's kind of a loaded request.

We would need to know the security goals and objectives to ensure
things are progressing as expected. As far as I know, they are not
stated anywhere.

Jeff,

=
It's a request against you. You are "spamming" this list= .

TLS is a security protocol, not a compression pr= otocol.

Providing secure compression requires appl= ication-specific domain knowledge. TLS cannot provide secure compression.

A security protocol shouldn't provide insecure = compression.

TLS can only provide insecure compres= sion, because it lacks the application-specific domain knowledge to impleme= nt security correctly.

TLS is a security protocol.=

You are asking TLS, a security protocol, to provi= de an insecure feature it is conceptually incapable of providing securely.<= /div>

Please stop. That is why I asked the chairs to mak= e a ruling and end the "spam" to the list. This is not a useful d= iscussion.

Your argument is conceptually flawed be= yond repair and you are literally asking for insecure features to be added = to a security protocol. This needs to stop.

Please= stop.

--
Tony= Arcieri
--047d7bdc12ea56e86205219ea93c-- From nobody Thu Oct 8 14:53:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CA61B2D41 for ; Thu, 8 Oct 2015 14:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 zx290PwmHmzp for ; Thu, 8 Oct 2015 14:53:21 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C91A1B48 for ; Thu, 8 Oct 2015 14:53:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 09D024334C2; Thu, 8 Oct 2015 21:53:16 +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 E79CE4334BF; Thu, 8 Oct 2015 21:53:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444341195; bh=U2qK+39tn+JuFpI6QQMM870okuCakmBdOQQVkFurJ0E=; l=12515; h=From:To:CC:Date:References:In-Reply-To:From; b=WlKGjhssBn0fHxu14zjUJa2PSuqfH2TcK5STqmpf5WLCctbGarT1oNDWsh7/vM5Kq zMdgiWmqEt+lUWZyv4regeh/57h8WcHLBQyXBTrLXvqcHHNFKsDFIcNswkLrj/MgS1 16ijy6dIb44y7XI1qNAohXCii0t3OzIP+z5FA3Hc= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id C4C9D203F; Thu, 8 Oct 2015 21:53:15 +0000 (GMT) Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 8 Oct 2015 16:53:15 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Thu, 8 Oct 2015 16:53:15 -0500 From: "Short, Todd" To: "mrex@sap.com" Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed Thread-Index: AQHRATmlz8vkrT+RfEa++i1UEDH43Z5g0u4AgAAIBoCAAADdAIAAA8SAgAB5lwCAARcwgIAACHeA Date: Thu, 8 Oct 2015 21:53:14 +0000 Message-ID: <60BB8707-F1CF-4DD2-88BC-883C9CCDB0A7@akamai.com> References: <20151008212255.D1F431A2CF@ld9781.wdf.sap.corp> In-Reply-To: <20151008212255.D1F431A2CF@ld9781.wdf.sap.corp> 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.182] Content-Type: multipart/alternative; boundary="_000_60BB8707F1CF4DD288BC883C9CCDB0A7akamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2015 21:53:22 -0000 --_000_60BB8707F1CF4DD288BC883C9CCDB0A7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYyBzcGVjaWZpY2FsbHkgY2xhcmlmaWVkIGl0Og0KDQpPbiBPY3QgNywgMjAxNSwgYXQgNTox NSBQTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3 cm90ZToNCg0KU29ycnksIEkgc3Bva2UgY2FyZWxlc3NseS4gSXQgbXVzdCBjb250YWluIHNvbGVs eSB0aGUgbnVsbCBtZXRob2QuDQoNCi1Fa3INCg0KU28gdGhlIHRleHQgbmVlZHMgdG8gYmUgY29y cmVjdGVkIHRvIHJlZmxlY3QgdGhhdC4gVGhpcyB3aWxsIGF2b2lkIHRoZSBiYWNrd2FyZCBjb21w YXRpYmlsaXR5IGlzc3Vlcy4NCg0KSU1ITywgdGhlIHRleHQgc2hvdWxkIGFsc28gY2xlYXJseSBz dGF0ZSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIHRoYXQg4oCcQSBUTFN2MS4zIGNsaWVudCBN VVNUIE5PVCBzdXBwb3J0IGNvbXByZXNzaW9uLCByZWdhcmRsZXNzIG9mIHRoZSBwcm90b2NvbCB2 ZXJzaW9uIHRoYXQgbWF5IGJlIG5lZ290aWF0ZWQu4oCdIFRoaXMgcmVpbmZvcmNlcyBiYWNrd2Fy ZHMtY29tcGF0aWJpbGl0eSB2aWEgdGhlIHVzZSBvZiBDaXBoZXJNZXRob2QubnVsbCwgbWFrZXMg aXQgYmxhdGFudGx5IG9idmlvdXMgdGhhdCBjb21wcmVzc2lvbiBpcyBub3Qgc3VwcG9ydGVkLCBh bmQgYSBUTFN2MS4zIGNsaWVudCBpcyBhIGdvb2QgY2l0aXplbiBpbiBhdm9pZGluZyBDUklNRS10 eXBlIGF0dGFja3MuDQoNCi0tDQotVG9kZCBTaG9ydA0KLy8gdHNob3J0QGFrYW1haS5jb208bWFp bHRvOnRzaG9ydEBha2FtYWkuY29tPg0KLy8gIk9uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2Vh LCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuIg0KDQpPbiBPY3QgOCwgMjAxNSwgYXQgNToyMiBQ TSwgTWFydGluIFJleCA8bXJleEBzYXAuY29tPG1haWx0bzptcmV4QHNhcC5jb20+PiB3cm90ZToN Cg0KRXJpYyBSZXNjb3JsYSB3cm90ZToNClNob3J0LCBUb2RkIDx0c2hvcnRAYWthbWFpLmNvbTxt YWlsdG86dHNob3J0QGFrYW1haS5jb20+PiB3cm90ZToNCg0KSG93ZXZlciwgZm9yIHRob3NlIENs aWVudEhlbGxvP3MgdGhhdCBzdXBwb3J0IG9sZGVyIHZlcnNpb25zLCB0aGUNCmNvbXByZXNzaW9u X21ldGhvZCBmaWVsZCBtYXkgY29udGFpbiBvdGhlciB2YWx1ZXMuIFRoaXMgbWVhbnMgdGhhdCBp ZiBhDQpUTFN2MS4zIGNsaWVudCBoYXBwZW5lZCB0byBzdXBwb3J0IGNvbXByZXNzaW9uIGZvciBU TFN2MS4yLCBpdCB3b3VsZCBiZQ0KdW5hYmxlIHRvIG5lZ290aWF0ZSB0aGF0IHZpYSBhIHNpbmds ZSBDbGllbnRIZWxsby4gVGhlcmU/cyBubyB3YXkgdG8NCmF0dGVtcHQgdG8gbmVnb3RpYXRlIFRM U3YxLjIrY29tcHJlc3Npb24gYW5kIFRMU3YxLjMrbm8tY29tcHJlc3Npb24gaW4gYQ0Kc2luZ2xl IENsaWVudEhlbGxvLg0KDQpZdXAsIHRoYXQgaXMgdGhlIHByb2JsZW0gd2l0aCB0aGUgY3VycmVu dCB0ZXh0Lg0KDQoNCg0KSW4gZWZmZWN0LCB0aGUgZG9jdW1lbnQgaXMgc3RhdGluZyB0aGF0IGEg VExTdjEuMyBjbGllbnQgTVVTVCBOT1Qgc3VwcG9ydA0KY29tcHJlc3Npb24sIHJlZ2FyZGxlc3Mg b2YgdGhlIHByb3RvY29sIHZlcnNpb24gdGhhdCBtYXkgYmUgbmVnb3RpYXRlZC4NCg0KWWVzLCB0 aGlzIGlzIHdoYXQgSSBiZWxpZXZlIGl0IHNheXMgYW5kIHdoYXQgSSBiZWxpZXZlIHRoZSBXRyBo YWQgY29uc2Vuc3VzDQpvbiwgdGhlIHJlYXNvbmluZyBiZWluZyB0aGF0IHdlIHJlYWxseSB3aXNo ZWQgdG8ganVzdCByZW1vdmUgdGhlIGZlYXR1cmUNCmVudGlyZWx5LiBJZiB0aGUgY2hhaXJzIGRl Y2xhcmUgY29uc2Vuc3VzIG9uIHNvbWV0aGluZyBlbHNlLCBJIHdpbGwgb2YNCmNvdXJzZSBlZGl0 IGl0IHRvIHNheSBzb21ldGhpbmcgZWxzZS4NCg0KVGhlIGN1cnJlbnQgdGV4dCBpcyB0cnlpbmcg dG8gZm9yY2UgYSBzcGVjaWZpYyBwb2xpY3kgaW4gYSBmYXNoaW9uDQp0aGF0IGlzIGluIHRoZSB3 b3JzdCBjb25jZWl2YWJsZSB2aW9sYXRpb24gb2YgcmZjMjExOSBzZWN0aW9uIDYgdGhhdA0KaXMg cG9zc2libGUuDQoNCkEgQ2xpZW50SGVsbG8gd2l0aA0KDQogICBDbGllbnRIZWxsby5jbGllbnRf dmVyc2lvbiA9ICgzLDMpDQogICBDbGllbnRIZWxsby5jb21wcmVzc2lvbl9tZXRob2RzID0gKDEs MCkNCg0Kd2lsbCBiZSBpbnRlcm9wZXJhYmxlIHdpdGggVExTdjEuMCwgVExTdjEuMSwgVExTdjEu MiBhbmQgVExTdjEuMyBzZXJ2ZXJzLg0KDQoNCiAgIENsaWVudEhlbGxvLmNsaWVudF92ZXJzaW9u ID0gKDMsNCkNCiAgIENsaWVudEhlbGxvLmNvbXByZXNzaW9uX21ldGhvZHMgPSAoMSwwKQ0KDQp3 aWxsIGJlIGludGVyb3BlcmFibGUgd2l0aCBUTFN2MS4wLCBUTFN2MS4xIGFuZCBUTFN2MS4yIHNl cnZlcnMsDQpidXQgVExTdjEuMyBzZXJ2ZXJzIHRoYXQgZm9sbG93IHRoZSBzdHVwaWQgaWRlYSB3 aWxsIGNob2tlIGFuZA0KYWJvcnQgd2l0aCBhbiAiaWxsZWdhbF9wYXJhbWV0ZXIiIGFsZXJ0Lg0K DQpFc3NlbnRpYWxseSwgdGhlIGN1cnJlbnQgd29yZGluZyBpcyBjYWxsaW5nIGZvciBhIG5ld2x5 IGNyZWF0aW5nIHdoYXQNCm11c3QgYmUgY2FsbGVkIGEgImNvbXByZXNzaW9uIG1ldGhvZCBpbnRv bGVyYW5jZSIgLS0gYnV0IGVzc2VudGlhbGx5DQppdCBpcyBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9t IGEgIlRMUyB2ZXJzaW9uIGludG9sZXJhbmNlIg0KDQoNCkZvciBhIG51bWJlciBvZiB5ZWFycywg aXQgc2VlbWVkIHRvIGhhdmUgYmVlbiBjb25zZW5zdXMgaW4gdGhlIElFVEYgVExTIFdHDQp0aGF0 IFRMUyB2ZXJzaW9uIGludG9sZXJhbmNlIGlzIGFuIGltcGxlbWVuYXR0aW9uIGRlZmVjdCBhbmQg YSByZWFsIHByb2JsZW0uDQpJdCB3b3VsZCBiZSBzYWQgaWYgdGhlIGN1cnJlbnQgVExTIFdHIHdv dWxkIGNvbmZpcm0gdGhhdCByZWNrbGVzc2x5IGFkZGluZw0KaGFuZHNoYWtlIGZhaWx1cmUgY2F1 c2luZyBuZXcgaW50b2xlcmFuY2VzIGludG8gVExTdjEuMyBpcyB0aGUgbmV3DQplbmdlbmVlcmlu ZyBhcHByb2FjaC4NCg0KDQoNCi1NYXJ0aW4NCg0K --_000_60BB8707F1CF4DD288BC883C9CCDB0A7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRXJpYyBzcGVjaWZpY2FsbHkgY2xh cmlmaWVkIGl0Og0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGNs YXNzPSIiPk9uIE9jdCA3LCAyMDE1LCBhdCA1OjE1IFBNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBo cmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiBjbGFzcz0iIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3 cm90ZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+DQo8ZGl2IGNsYXNzPSIiPlNvcnJ5LCBJIHNwb2tlIGNhcmVsZXNzbHkuIEl0IG11c3Qg Y29udGFpbiBzb2xlbHkgdGhlIG51bGwgbWV0aG9kLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LUVrcjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TbyB0 aGUgdGV4dCBuZWVkcyB0byBiZSBjb3JyZWN0ZWQgdG8gcmVmbGVjdCB0aGF0LiBUaGlzIHdpbGwg YXZvaWQgdGhlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzLg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SU1ITywgdGhlIHRleHQgc2hvdWxk IGFsc28gY2xlYXJseSBzdGF0ZSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIHRoYXQg4oCcQSBU TFN2MS4zIGNsaWVudCBNVVNUIE5PVCBzdXBwb3J0IGNvbXByZXNzaW9uLCByZWdhcmRsZXNzIG9m IHRoZSBwcm90b2NvbCB2ZXJzaW9uIHRoYXQgbWF5IGJlIG5lZ290aWF0ZWQu4oCdIFRoaXMgcmVp bmZvcmNlcyBiYWNrd2FyZHMtY29tcGF0aWJpbGl0eSB2aWEgdGhlIHVzZSBvZiBDaXBoZXJNZXRo b2QubnVsbCwNCiBtYWtlcyBpdCBibGF0YW50bHkgb2J2aW91cyB0aGF0IGNvbXByZXNzaW9uIGlz IG5vdCBzdXBwb3J0ZWQsIGFuZCBhIFRMU3YxLjMgY2xpZW50IGlzIGEgZ29vZCBjaXRpemVuIGlu IGF2b2lkaW5nIENSSU1FLXR5cGUgYXR0YWNrcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4tLTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tVG9kZCBTaG9ydDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4vLyA8YSBocmVmPSJtYWlsdG86dHNob3J0QGFrYW1haS5jb20iIGNs YXNzPSIiPnRzaG9ydEBha2FtYWkuY29tPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4vLyAmcXVv dDtPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0 LiZxdW90OzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBP Y3QgOCwgMjAxNSwgYXQgNToyMiBQTSwgTWFydGluIFJleCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1y ZXhAc2FwLmNvbSIgY2xhc3M9IiI+bXJleEBzYXAuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj5Fcmlj IFJlc2NvcmxhIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPlNob3J0LCBUb2RkICZsdDs8YSBocmVmPSJtYWlsdG86dHNob3J0QGFrYW1haS5jb20i IGNsYXNzPSIiPnRzaG9ydEBha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KSG93ZXZlciwg Zm9yIHRob3NlIENsaWVudEhlbGxvP3MgdGhhdCBzdXBwb3J0IG9sZGVyIHZlcnNpb25zLCB0aGU8 YnIgY2xhc3M9IiI+DQpjb21wcmVzc2lvbl9tZXRob2QgZmllbGQgbWF5IGNvbnRhaW4gb3RoZXIg dmFsdWVzLiBUaGlzIG1lYW5zIHRoYXQgaWYgYTxiciBjbGFzcz0iIj4NClRMU3YxLjMgY2xpZW50 IGhhcHBlbmVkIHRvIHN1cHBvcnQgY29tcHJlc3Npb24gZm9yIFRMU3YxLjIsIGl0IHdvdWxkIGJl PGJyIGNsYXNzPSIiPg0KdW5hYmxlIHRvIG5lZ290aWF0ZSB0aGF0IHZpYSBhIHNpbmdsZSBDbGll bnRIZWxsby4gVGhlcmU/cyBubyB3YXkgdG88YnIgY2xhc3M9IiI+DQphdHRlbXB0IHRvIG5lZ290 aWF0ZSBUTFN2MS4yJiM0Mztjb21wcmVzc2lvbiBhbmQgVExTdjEuMyYjNDM7bm8tY29tcHJlc3Np b24gaW4gYTxiciBjbGFzcz0iIj4NCnNpbmdsZSBDbGllbnRIZWxsby48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpZdXAsIHRoYXQgaXMg dGhlIHByb2JsZW0gd2l0aCB0aGUgY3VycmVudCB0ZXh0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkluIGVmZmVjdCwg dGhlIGRvY3VtZW50IGlzIHN0YXRpbmcgdGhhdCBhIFRMU3YxLjMgY2xpZW50IE1VU1QgTk9UIHN1 cHBvcnQ8YnIgY2xhc3M9IiI+DQpjb21wcmVzc2lvbiwgcmVnYXJkbGVzcyBvZiB0aGUgcHJvdG9j b2wgdmVyc2lvbiB0aGF0IG1heSBiZSBuZWdvdGlhdGVkLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NClllcywgdGhpcyBpcyB3aGF0IEkgYmVsaWV2ZSBpdCBzYXlz IGFuZCB3aGF0IEkgYmVsaWV2ZSB0aGUgV0cgaGFkIGNvbnNlbnN1czxiciBjbGFzcz0iIj4NCm9u LCB0aGUgcmVhc29uaW5nIGJlaW5nIHRoYXQgd2UgcmVhbGx5IHdpc2hlZCB0byBqdXN0IHJlbW92 ZSB0aGUgZmVhdHVyZTxiciBjbGFzcz0iIj4NCmVudGlyZWx5LiBJZiB0aGUgY2hhaXJzIGRlY2xh cmUgY29uc2Vuc3VzIG9uIHNvbWV0aGluZyBlbHNlLCBJIHdpbGwgb2Y8YnIgY2xhc3M9IiI+DQpj b3Vyc2UgZWRpdCBpdCB0byBzYXkgc29tZXRoaW5nIGVsc2UuPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGN1cnJlbnQgdGV4dCBpcyB0cnlpbmcgdG8gZm9y Y2UgYSBzcGVjaWZpYyBwb2xpY3kgaW4gYSBmYXNoaW9uPGJyIGNsYXNzPSIiPg0KdGhhdCBpcyBp biB0aGUgd29yc3QgY29uY2VpdmFibGUgdmlvbGF0aW9uIG9mIHJmYzIxMTkgc2VjdGlvbiA2IHRo YXQ8YnIgY2xhc3M9IiI+DQppcyBwb3NzaWJsZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpBIENsaWVudEhlbGxvIHdpdGg8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDtDbGllbnRIZWxsby5jbGllbnRfdmVyc2lvbiA9ICgzLDMpPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Q2xpZW50SGVsbG8uY29tcHJlc3Npb25fbWV0aG9kcyA9ICgx LDApPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0Kd2lsbCBiZSBpbnRlcm9wZXJhYmxlIHdp dGggVExTdjEuMCwgVExTdjEuMSwgVExTdjEuMiBhbmQgVExTdjEuMyBzZXJ2ZXJzLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO0Ns aWVudEhlbGxvLmNsaWVudF92ZXJzaW9uID0gKDMsNCk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDtDbGllbnRIZWxsby5jb21wcmVzc2lvbl9tZXRob2RzID0gKDEsMCk8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQp3aWxsIGJlIGludGVyb3BlcmFibGUgd2l0aCBUTFN2MS4wLCBU TFN2MS4xIGFuZCBUTFN2MS4yIHNlcnZlcnMsPGJyIGNsYXNzPSIiPg0KYnV0IFRMU3YxLjMgc2Vy dmVycyB0aGF0IGZvbGxvdyB0aGUgc3R1cGlkIGlkZWEgd2lsbCBjaG9rZSBhbmQ8YnIgY2xhc3M9 IiI+DQphYm9ydCB3aXRoIGFuICZxdW90O2lsbGVnYWxfcGFyYW1ldGVyJnF1b3Q7IGFsZXJ0Ljxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkVzc2VudGlhbGx5LCB0aGUgY3VycmVudCB3b3Jk aW5nIGlzIGNhbGxpbmcgZm9yIGEgbmV3bHkgY3JlYXRpbmcgd2hhdDxiciBjbGFzcz0iIj4NCm11 c3QgYmUgY2FsbGVkIGEgJnF1b3Q7Y29tcHJlc3Npb24gbWV0aG9kIGludG9sZXJhbmNlJnF1b3Q7 IC0tIGJ1dCBlc3NlbnRpYWxseTxiciBjbGFzcz0iIj4NCml0IGlzIGluZGlzdGluZ3Vpc2hhYmxl IGZyb20gYSAmcXVvdDtUTFMgdmVyc2lvbiBpbnRvbGVyYW5jZSZxdW90OzxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkZvciBhIG51bWJlciBvZiB5ZWFycywgaXQg c2VlbWVkIHRvIGhhdmUgYmVlbiBjb25zZW5zdXMgaW4gdGhlIElFVEYgVExTIFdHPGJyIGNsYXNz PSIiPg0KdGhhdCBUTFMgdmVyc2lvbiBpbnRvbGVyYW5jZSBpcyBhbiBpbXBsZW1lbmF0dGlvbiBk ZWZlY3QgYW5kIGEgcmVhbCBwcm9ibGVtLiAmbmJzcDs8YnIgY2xhc3M9IiI+DQpJdCB3b3VsZCBi ZSBzYWQgaWYgdGhlIGN1cnJlbnQgVExTIFdHIHdvdWxkIGNvbmZpcm0gdGhhdCByZWNrbGVzc2x5 IGFkZGluZzxiciBjbGFzcz0iIj4NCmhhbmRzaGFrZSBmYWlsdXJlIGNhdXNpbmcgbmV3IGludG9s ZXJhbmNlcyBpbnRvIFRMU3YxLjMgaXMgdGhlIG5ldzxiciBjbGFzcz0iIj4NCmVuZ2VuZWVyaW5n IGFwcHJvYWNoLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCi1NYXJ0aW48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_60BB8707F1CF4DD288BC883C9CCDB0A7akamaicom_-- From nobody Thu Oct 8 18:42:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7C31B301C for ; Thu, 8 Oct 2015 18:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 UpxXfPn0dnUO for ; Thu, 8 Oct 2015 18:42:47 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 D935A1B301A for ; Thu, 8 Oct 2015 18:42:46 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so48300761wic.1 for ; Thu, 08 Oct 2015 18:42:45 -0700 (PDT) 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-type; bh=CMbwpinjobsDtS9ca2KHHZD/mDf1yH6i/2CSeY5ne3U=; b=AQ/tRRN/6M2UtAiN6IKzB1GFt+qybqCbb8tKdtUUj9uCJ/NxdcjmQQRuO47OhCYJOt 5YqxKYbKBpTI8KgIoZ0BcvHk4/CX3/J3z0Cu0H/iDjdWE7ZpmzBL02qVPIc2fE/yUPfN /O39e7FXhfQ4U/MinsiuEZuLQkvq+7JOFkKyYMfwxrXkHpvRJQOsG40C0UO644p5XBDx bTgTCHtR+qBebNwTKysNH3TrPtFQXMbOExcX1e11GKqBUWBa5hDCtOOyzh4vBgMJklao +Sy1um+4ufDnC4XaIizfxbu2WVqntaeDMegP89wupKOjX+Xuus2QLftngo9XJEgDTjYD ESpg== X-Gm-Message-State: ALoCoQkUk4TRYEBW/tR7JhslaX+aWxNtqisK4x9/KJK0a5xm2a5W4Jb1GzMF+HvgPFAPmf3jR3dA X-Received: by 10.194.133.129 with SMTP id pc1mr11147085wjb.148.1444354965464; Thu, 08 Oct 2015 18:42:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Thu, 8 Oct 2015 18:42:05 -0700 (PDT) In-Reply-To: <20151008212255.D1F431A2CF@ld9781.wdf.sap.corp> References: <20151008212255.D1F431A2CF@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Fri, 9 Oct 2015 03:42:05 +0200 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=089e01227d94a574fd0521a218b0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 01:42:49 -0000 --089e01227d94a574fd0521a218b0 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex wrote: > Eric Rescorla wrote: > > Short, Todd wrote: > >> > >> However, for those ClientHello?s that support older versions, the > >> compression_method field may contain other values. This means that if a > >> TLSv1.3 client happened to support compression for TLSv1.2, it would be > >> unable to negotiate that via a single ClientHello. There?s no way to > >> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in a > >> single ClientHello. > > Yup, that is the problem with the current text. Thanks for clarifying this. > > > > > >> In effect, the document is stating that a TLSv1.3 client MUST NOT > support > >> compression, regardless of the protocol version that may be negotiated. > > > > Yes, this is what I believe it says and what I believe the WG had > consensus > > on, the reasoning being that we really wished to just remove the feature > > entirely. If the chairs declare consensus on something else, I will of > > course edit it to say something else. > > The current text is trying to force a specific policy in a fashion > that is in the worst conceivable violation of rfc2119 section 6 that > is possible. > > A ClientHello with > > ClientHello.client_version = (3,3) > ClientHello.compression_methods = (1,0) > > will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers. > > > ClientHello.client_version = (3,4) > ClientHello.compression_methods = (1,0) > > will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers, > but TLSv1.3 servers that follow the stupid idea will choke and > abort with an "illegal_parameter" alert. > > Essentially, the current wording is calling for a newly creating what > must be called a "compression method intolerance" -- but essentially > it is indistinguishable from a "TLS version intolerance" Hmm... I'm not sure I follow this argument. We have a bunch of rules for how TLS 1.3 clients MUST behave and TLS 1.3 servers will choke if they don't. This doesn't create any present interop problem and only creates a problem if in future we wish to reintroduce compression. Is that your concern? > For a number of years, it seemed to have been consensus in the IETF TLS WG > that TLS version intolerance is an implemenattion defect and a real > problem. > It would be sad if the current TLS WG would confirm that recklessly adding > handshake failure causing new intolerances into TLSv1.3 is the new > engeneering approach. As I said, I edited the document in conformance with what I believed the chair declaration of WG consensus was. If the WG consensus is to remove this requirement, then I will of course do so. So, rather than going back and forth, I would suggest that the best way for you to proceed here is to: 1. Ask the chairs to re-state the previous consensus. If I misunderstood, then that's easy. 2. If you're still not happy, then you could ask the chairs to re-assess the currnet consensus. 3. If you're still not happy, and you believe this violates 2119, then you can of course appeal. This of course also goes for people who think we should re-allow compression. Best, -Ekr --089e01227d94a574fd0521a218b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex <mrex@sap.com> wr= ote:
Eric Rescorla wrote= :
> Short, Todd <tshort@akamai.com= > wrote:
>>
>> However, for those ClientHello?s that support older version= s, the
>> compression_method field may contain other values= . This means that if a
>> TLSv1.3 client happened to support compression for TLSv1.2, it wou= ld be
>> unable to negotiate that via a single ClientHello. There?s = no way to
>> attempt to negotiate TLSv1.2+compression and TLSv= 1.3+no-compression in a
>> single ClientHello.

Yup, that is the problem with the current text.
Thanks for clarifying this.
=C2=A0


>
>> In effect, the document is stating that a TLSv1.3 client MUST NOT = support
>> compression, regardless of the protocol version that may be negoti= ated.
>
> Yes, this is what I believe it says and what I believe the WG had cons= ensus
> on, the reasoning being that we really wished to just remove the featu= re
> entirely. If the chairs declare consensus on something else, I will of=
> course edit it to say something else.

The current text is trying to force a specific policy in a fashion that is in the worst conceivable violation of rfc2119 section 6 that
is possible.

A ClientHello with

=C2=A0 =C2=A0 ClientHello.client_version =3D (3,3)
=C2=A0 =C2=A0 ClientHello.compression_methods =3D (1,0)

will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.

=C2=A0 =C2=A0 ClientHello.client_version =3D (3,4)
=C2=A0 =C2=A0 ClientHello.compression_methods =3D (1,0)

will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
but TLSv1.3 servers that follow the stupid idea will choke and
abort with an "illegal_parameter" alert.

Essentially, the current wording is calling for a newly creating what
must be called a "compression method intolerance" -- but essentia= lly
it is indistinguishable from a "TLS version intolerance"

Hmm... I'm not sure I follow this argument. We = have a bunch of rules for
how TLS 1.3 clients MUST behave and TLS= 1.3 servers will choke if
they don't. This doesn't creat= e any present interop problem and only
creates a problem if in fu= ture we wish to reintroduce compression.
Is that your concern?

=C2=A0
For a number of years, it seemed to have been consensus in the IETF TLS WG<= br> that TLS version intolerance is an implemenattion defect and a real problem= .
It would be sad if the current TLS WG would confirm that recklessly adding<= br> handshake failure causing new intolerances into TLSv1.3 is the new
engeneering approach.

As I said, I edited t= he document in conformance with what I believed the
chair declara= tion of WG consensus was. If the WG consensus is to remove
this r= equirement, then I will of course do so. So, rather than going back and
forth, I would suggest that the best way for you to proceed here is = to:

1. Ask the chairs to re-state the previous con= sensus. If I misunderstood, then that's
easy.
2. If= you're still not happy, then you could ask the chairs to re-assess the= currnet
consensus.
3. If you're still not happy, a= nd you believe this violates 2119, then you can of
course appeal.=

This of course also goes for people who think we = should re-allow compression.

Best,
-= Ekr

--089e01227d94a574fd0521a218b0-- From nobody Fri Oct 9 05:24:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883911B3AA5 for ; Fri, 9 Oct 2015 05:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMVKD3vabC2H for ; Fri, 9 Oct 2015 05:24:11 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 2A24E1B3AA0 for ; Fri, 9 Oct 2015 05:24:11 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so64799681wic.1 for ; Fri, 09 Oct 2015 05:24:09 -0700 (PDT) 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-type; bh=maZQaBAdvAei/d0wl3P3YqLzt6UQRTpl4EfORIG5O9U=; b=bkBASdm+7+JcNhD6pl2LZ01hkWmXnMWtqHnPrL81TYbTYepdbEdi5W+SipfFiEuCSo fcg0M5p5dzKgFAb7TZkerzLWaJb9db1pFYXWfLmZrEB6siBxFFezdavzte+xMK8MuKN8 NVhBmZMLhpuSssQ5dgv1Gko0o/KgFLwbGiD9DN8y94nQ+hJti77QkJJMM2TbU8aLPOEH 11uO2f3RUB5CxGQSamBWaumM8PfZ8RzaYTA6sxsgNyx6Tl+ohq5WA2YJ5LvLIY6zzEZc 0vO81ldtHwc5rtmH7AWlzWkl2enGpFJAwygubBHDPx8GnRvnwiHXciaG55ZC21RlzL2W difA== X-Gm-Message-State: ALoCoQmkOuG1oPJ0kgyBKt25zctaAz07O/rPqP/eWuxQfi1rcThx/bSr5CKsQ4BnaSJJ6ivPH82n X-Received: by 10.194.94.71 with SMTP id da7mr14166435wjb.8.1444393449631; Fri, 09 Oct 2015 05:24:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Fri, 9 Oct 2015 05:23:30 -0700 (PDT) From: Eric Rescorla Date: Fri, 9 Oct 2015 14:23:30 +0200 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0c1027b4f980521ab0eb5 Archived-At: Subject: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 12:24:13 -0000 --047d7bf0c1027b4f980521ab0eb5 Content-Type: text/plain; charset=UTF-8 Hi folks, Please take a look at the following PR which documents a suggestion made by Karthik Bhargavan about how to prevent protection against downgrade against downgrade from TLS 1.3 to TLS 1.2 and below. https://github.com/tlswg/tls13-spec/pull/284 The idea is that if a TLS 1.3 server receives a TLS 1.2 or below ClientHello, it sets the top N bits of the ServerRandom to be a specific fixed value. TLS 1.3 clients which receive a TLS 1.2 or below ServerHello check for this value and abort if they receive it. This allows for detection of downgrade attacks over and above the Finished handshake as long as ephemeral cipher suites are used (because the signature on the ServerKeyExchange covers the random values). No protection is provided for static RSA cipher suites, but this still has some value if you have an attack which only affects (EC)DHE. I've written this up with 48 bits and a specific fixed value (03 04 03 04 03 04) but that's just a strawman and we can bikeshed on that if people think this is a good idea. Thanks, -Ekr --047d7bf0c1027b4f980521ab0eb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

Please take a look= at the following PR which documents a suggestion
made by Karthik= Bhargavan about how to prevent protection against
downgrade agai= nst downgrade from TLS 1.3 to TLS 1.2 and below.


The idea is = that if a TLS 1.3 server receives a TLS 1.2 or below
ClientHello,= it sets the top N bits of the ServerRandom to be a
specific fixe= d value. TLS 1.3 clients which receive a TLS 1.2 or below
ServerH= ello check for this value and abort if they receive it. This
allo= ws for detection of downgrade attacks over and above the Finished
handshake as long as ephemeral cipher suites are used (because the
signature on the ServerKeyExchange covers the random values). No
protection is provided for static RSA cipher suites, but this still
has some value if you have an attack which only affects (EC)DHE.

I've written this up with 48 bits and a specific f= ixed value (03 04 03
04 03 04) but that's just a strawman and= we can bikeshed on that if
people think this is a good idea.

Thanks,
-Ekr

--047d7bf0c1027b4f980521ab0eb5-- From nobody Fri Oct 9 05:48:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DF31B3340 for ; Fri, 9 Oct 2015 05:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 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, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 YSIkcyVSfI2s for ; Fri, 9 Oct 2015 05:48:44 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 BA8B31B3339 for ; Fri, 9 Oct 2015 05:48:42 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so65367305wic.0 for ; Fri, 09 Oct 2015 05:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5z+Sm+UmCb7AcRRZ8u+fqWHxUzG7rg+lOu+ar0j0oUM=; b=b2TvnUSwfHQGexbezzU/WBGXx+aUp+Q/gYnQoOJXWmzfFosn5uFvd9mYgQHDoZX1Xt l6m7S42eBhsBDqrw0FMj87qOkmouE8o/4Z91ZlJJKDiFg4p6kmvqfPmHPPsk2tmNDEeo CW6Cfp4UvUABQlAa+kDXB2nEr7dX8O7OccbEpR0qhbXI3EetvroZJKno/SqhuaAzHGtc VygUDAemlmwjjemk5Q2B/nqMUwDst5mm+4707lMW6HDUXCqm/VxMb+6tizfpH3nJExGX LihXo6bXk1IQQAvRDB0lMgCZdtu54wXOvJ2uYJJuSzvvYtVL41hE1jE5a3MirtOMsmYh G+Eg== X-Received: by 10.180.188.47 with SMTP id fx15mr10029333wic.41.1444394921141; Fri, 09 Oct 2015 05:48:41 -0700 (PDT) Received: from wifi-auth-191208.inria.fr (wifi-auth-191208.inria.fr. [128.93.191.208]) by smtp.gmail.com with ESMTPSA id kr10sm1949033wjc.25.2015.10.09.05.48.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Oct 2015 05:48:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_787FDD53-BCDC-4337-845D-AF6256421D26" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 9 Oct 2015 14:48:38 +0200 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 12:48:46 -0000 --Apple-Mail=_787FDD53-BCDC-4337-845D-AF6256421D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A few more words on this proposal. - The goal is to protect TLS 1.3 clients and servers from attacks on TLS = 1.* ciphersuites. E.g. if a new attack on the MD5 | SHA1 concatenation in TLS 1.0 is = announced,=20 connections between TLS 1.3 clients and servers would still be = protected. Similarly, if the Apache default 1024-bit DHE group is broken, = connections between TLS 1.3 clients and servers remain unaffected. (In the current TLS 1.3 design, an attacker could downgrade the = connection and break it in both these cases. No, the fallback SCSV does not help.) - We propose to fix the first N bits of the server random, but we can = carry whatever information we want here. Protocol version + ciphersuite sounds like a good start to use up 4 = bytes. (This would, for example, have protected TLS 1.2 against the Logjam = attack on TLS 1.0.) - The key idea is that the server random is signed even in older = versions of TLS, and so we will get downgrade protection for free, without modifying these = older versions in any way. (A protocol extension for TLS 1.* would not work, since the extension = itself could be deleted by the attacker.) - The first 4 bytes were traditionally used for a timestamp, so using = (say) 4 bytes in a new way=20 does not lose entropy/replay-protection in comparison for servers that = implement timestamps.=20 However, we do lose some replay-protection when compared to servers = that use the full 32 bytes.=20 - There is a 1/(2^N) chance that valid connections to TLS 1.2 servers = will be dropped by TLS 1.3 clients, because of this proposal. This only happens for = servers that do not=20 use the unix timestamp (the current timestamp is greater than = 0304xxxx). Still, we need to carefully choose N so that this risk of connection = dropping is acceptable. - The proposed mechanism only protects TLS 1.3 clients and servers that = exclusively support =09 signature-based ciphersuites (DHE/ECDHE) even for older versions of = TLS. E.g. it does not=20 protect against downgrade to RSA or PSK ciphersuites.=20 - We note that RSA ciphersuites already provide a version downgrade = mitigation,=20 although it has itself caused many headaches due to bleichenbacher = attacks. But if a server implements good side-channel resistance to = bleichenbacher attacks, TLS 1.3 can be protected from downgrades to both RSA and (EC)DHE = ciphersuites in older protocol versions. > On 09 Oct 2015, at 14:23, Eric Rescorla wrote: >=20 > Hi folks, >=20 > Please take a look at the following PR which documents a suggestion > made by Karthik Bhargavan about how to prevent protection against > downgrade against downgrade from TLS 1.3 to TLS 1.2 and below. >=20 > https://github.com/tlswg/tls13-spec/pull/284 = >=20 > The idea is that if a TLS 1.3 server receives a TLS 1.2 or below > ClientHello, it sets the top N bits of the ServerRandom to be a > specific fixed value. TLS 1.3 clients which receive a TLS 1.2 or below > ServerHello check for this value and abort if they receive it. This > allows for detection of downgrade attacks over and above the Finished > handshake as long as ephemeral cipher suites are used (because the > signature on the ServerKeyExchange covers the random values). No > protection is provided for static RSA cipher suites, but this still > has some value if you have an attack which only affects (EC)DHE. >=20 > I've written this up with 48 bits and a specific fixed value (03 04 03 > 04 03 04) but that's just a strawman and we can bikeshed on that if > people think this is a good idea. >=20 > Thanks, > -Ekr >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_787FDD53-BCDC-4337-845D-AF6256421D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii A few more words on this proposal.

- The goal is to protect TLS 1.3 = clients and servers from attacks on TLS 1.* ciphersuites.
   E.g. if a new attack on the MD5 | SHA1 = concatenation in TLS 1.0 is announced, 
  =  connections between TLS 1.3 clients and servers would still be = protected.
   Similarly, if the Apache = default 1024-bit DHE group is broken, connections between
   TLS 1.3 clients and servers remain = unaffected.
   (In the current TLS 1.3 = design, an attacker could downgrade the connection and break
    it in both these cases. No, the fallback SCSV = does not help.)

- We propose to fix the first N bits of the server random, = but we can carry whatever information we want here.
   Protocol version + ciphersuite sounds like a = good start to use up 4 bytes.
   (This = would, for example, have protected TLS 1.2 against the Logjam attack on = TLS 1.0.)

- = The key idea is that the server random is signed even in older versions = of TLS, and so
   we will get downgrade = protection for free, without modifying these older versions in any = way.
   (A protocol extension for TLS 1.* = would not work, since the extension itself could be deleted by the = attacker.)

- = The first 4 bytes were traditionally used for a timestamp, so using = (say) 4 bytes in a new way 
  does not = lose entropy/replay-protection in comparison for servers that implement = timestamps. 
  However, we do lose some = replay-protection when compared to servers that use the full 32 = bytes. 

- = There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will = be dropped by
   TLS 1.3 clients, because = of this proposal. This only happens for servers that do = not 
   use the unix timestamp (the = current timestamp is greater than 0304xxxx).
  =  Still, we need to carefully choose N so that this risk of = connection dropping is acceptable.

- The proposed mechanism only protects = TLS 1.3 clients and servers that exclusively support  =
   signature-based ciphersuites = (DHE/ECDHE) even for older versions of TLS. E.g. it does = not 
   protect against downgrade to = RSA or PSK ciphersuites. 

- We note that RSA ciphersuites already = provide a version downgrade mitigation, 
  = although it has itself caused many headaches due to bleichenbacher = attacks.
  But if a server implements good = side-channel resistance to bleichenbacher attacks,
  TLS 1.3 can be protected from downgrades to both RSA = and (EC)DHE ciphersuites in
  older protocol = versions.



On = 09 Oct 2015, at 14:23, Eric Rescorla <ekr@rtfm.com> wrote:

Hi folks,

Please take a look at the following PR = which documents a suggestion
made by Karthik = Bhargavan about how to prevent protection against
downgrade against downgrade from TLS 1.3 to TLS 1.2 and = below.

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

The idea is that if a = TLS 1.3 server receives a TLS 1.2 or below
ClientHello, it sets the top N bits of the ServerRandom to be = a
specific fixed value. TLS 1.3 clients which = receive a TLS 1.2 or below
ServerHello check for = this value and abort if they receive it. This
allows = for detection of downgrade attacks over and above the Finished
handshake as long as ephemeral cipher suites are used = (because the
signature on the ServerKeyExchange = covers the random values). No
protection is = provided for static RSA cipher suites, but this still
has some value if you have an attack which only affects = (EC)DHE.

I've = written this up with 48 bits and a specific fixed value (03 04 = 03
04 03 04) but that's just a strawman and we can = bikeshed on that if
people think this is a good = idea.

Thanks,
-Ekr

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

= --Apple-Mail=_787FDD53-BCDC-4337-845D-AF6256421D26-- From nobody Fri Oct 9 06:02:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087EC1B3C6F for ; Fri, 9 Oct 2015 06:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v32B1RWzNUZZ for ; Fri, 9 Oct 2015 06:02:26 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FA41B3C70 for ; Fri, 9 Oct 2015 06:02:26 -0700 (PDT) Received: from [31.209.137.142] (port=64369 helo=lessa) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZkXJX-0008Mq-Vv for tls@ietf.org; Fri, 09 Oct 2015 15:02:24 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: Date: Fri, 09 Oct 2015 13:02:20 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (Win32) Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 13:02:29 -0000 On Fri, 09 Oct 2015 12:48:38 -0000, Karthikeyan Bhargavan wrote: > - We note that RSA ciphersuites already provide a version downgrade > mitigation, > although it has itself caused many headaches due to bleichenbacher > attacks. > But if a server implements good side-channel resistance to > bleichenbacher attacks, > TLS 1.3 can be protected from downgrades to both RSA and (EC)DHE > ciphersuites in > older protocol versions. For reference, the version field in the TLS premaster secret is not checked by many servers, IIRC some of them have large market shares. -- Sincerely, Yngve N. Pettersen From nobody Fri Oct 9 06:09:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169481B3CD7 for ; Fri, 9 Oct 2015 06:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=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 9KZdofZYux8O for ; Fri, 9 Oct 2015 06:09:40 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 982101B3C92 for ; Fri, 9 Oct 2015 06:09:39 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so69919728wic.0 for ; Fri, 09 Oct 2015 06:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LUmkiyGDhLPDvXhanbJcMEvOOh5Y73OfV1tS94oZYWE=; b=umrsHhV8b2oUEd7urQQ5j90Jygr9k8yKk0E28aLkVPjL4rfLm+EYKURavLeTOOdl5f GembjUZ4YlMfFxG5mfiIi1SXe3afQqU3db5T7IIDLAYTJpkDh+Bt60FPTc/OMVmQxiHR +tV0YtpY98EeC9PZzqKu+my2DA4CTjOsgEXw1v0apNgcQE0JifxhojioMLlgobVFHJ+6 482t29xQIIBdW5M6cYVeoyUvu6f443WPxpYJ0B9OiDJIHIFf3XNiufvwQk12if/LvHYM sa4L2fsQDJn1aEquzNOIHw0veFUgnt1ceG4k/Lmftap8MS8hDl5Id2hsRWKC06sGLkX8 12Sg== X-Received: by 10.194.204.195 with SMTP id la3mr13990630wjc.77.1444396178138; Fri, 09 Oct 2015 06:09:38 -0700 (PDT) Received: from wifi-auth-191208.inria.fr (wifi-auth-191208.inria.fr. [128.93.191.208]) by smtp.gmail.com with ESMTPSA id he3sm2019292wjc.48.2015.10.09.06.09.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Oct 2015 06:09:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 9 Oct 2015 15:09:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A91A065-3F7C-4DB7-81E7-BD5A2A4FA794@gmail.com> References: To: "Yngve N. Pettersen" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 13:09:41 -0000 > For reference, the version field in the TLS premaster secret is not = checked by many servers, IIRC some of them have large market shares. That=E2=80=99s good to know. It would be tempting to recommend that TLS = 1.3 servers disable RSA (encryption) ciphersuites for all protocol = versions, but I guess this is not likely to happen for backwards = compatibility reasons? >=20 > --=20 > Sincerely, > Yngve N. Pettersen >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Oct 9 06:17:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7FB1B3D59 for ; Fri, 9 Oct 2015 06:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysTm9B9tMGlB for ; Fri, 9 Oct 2015 06:17:30 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 85E071B3D56 for ; Fri, 9 Oct 2015 06:17:30 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so66822910wic.1 for ; Fri, 09 Oct 2015 06:17:29 -0700 (PDT) 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-type; bh=rKHHNkpokFhNwHZ3IPqbPF9rAVilLPCzoP2EhRyPh3Q=; b=isDDO5ugALf8dE1Z0Kh2+DTUM3D/33r4/Qr69Mmc/IglxOLMUx6tPJ7bDJUtVGmotF gId+aOWQsIcK+JzDiWgbozy82IN+/bz3Rh0XRrQXmPWGUX/pUY2LVIkhhmEYPLoQGNAH cnO7B3N0BpibOKkGpeXn5013hnbC5ascvW6LfQDB3AMP5zzespRkzdgoSTECPM2Kint3 J3FVIvgZhcg2Ye0WfTbK+w9LoG0VuPdESDClnzOsgnJ7nKH7hk9ywWr9LvEUz5uBEXLH xMvV2m7L11S+Qibhw/x3/CP2k538455wvhEgKgIIsMjgMKCsuorLTzlKQ03RQ8IbFEMt a36A== X-Gm-Message-State: ALoCoQlXR0/xzN3i9dfAi+DvkRLDpK34aETFEOnU2zRFSzP8OnhsbtV1dt50E4sKOyR+6zffB08O X-Received: by 10.180.106.4 with SMTP id gq4mr11155936wib.53.1444396649123; Fri, 09 Oct 2015 06:17:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Fri, 9 Oct 2015 06:16:49 -0700 (PDT) In-Reply-To: <2A91A065-3F7C-4DB7-81E7-BD5A2A4FA794@gmail.com> References: <2A91A065-3F7C-4DB7-81E7-BD5A2A4FA794@gmail.com> From: Eric Rescorla Date: Fri, 9 Oct 2015 15:16:49 +0200 Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=f46d0443069c2fae390521abcd9b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 13:17:32 -0000 --f46d0443069c2fae390521abcd9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 9, 2015 at 3:09 PM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > > > For reference, the version field in the TLS premaster secret is not > checked by many servers, IIRC some of them have large market shares. > > That=E2=80=99s good to know. It would be tempting to recommend that TLS 1= .3 > servers disable RSA (encryption) ciphersuites for all protocol versions, > but I guess this is not likely to happen for backwards compatibility > reasons? This seems like RFC 6919 Territory: https://tools.ietf.org/html/rfc6919#section-1 -Ekr > > > -- > > Sincerely, > > Yngve N. Pettersen > > > > _______________________________________________ > > 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 > --f46d0443069c2fae390521abcd9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Oct 9, 2015 at 3:09 PM, Karthikeyan Bhargavan <= ;karthik.b= hargavan@gmail.com> wrote:

> For reference, the version field in the TLS premaster secret is not ch= ecked by many servers, IIRC some of them have large market shares.

That=E2=80=99s good to know. It would be tempting to recommend that = TLS 1.3 servers disable RSA (encryption) ciphersuites for all protocol vers= ions, but I guess this is not likely to happen for backwards compatibility = reasons?

This seems like RFC 6919 Territory= :

-= Ekr

>
> --
> Sincerely,
> Yngve N. Pettersen
>
> _______________________________________________
> 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

--f46d0443069c2fae390521abcd9b-- From nobody Fri Oct 9 06:23:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D277C1B3DB4 for ; Fri, 9 Oct 2015 06:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uo6YZrE9bF21 for ; Fri, 9 Oct 2015 06:23:20 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 34B691B3DB1 for ; Fri, 9 Oct 2015 06:23:20 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 793A5496C32; Fri, 9 Oct 2015 13:23:19 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 593F3496C1E; Fri, 9 Oct 2015 13:23:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444396999; bh=6vl09cbTeM2Z9DMeL1XqralLHx3qz94V7flC1XHlBUI=; l=6801; h=From:To:CC:Date:References:In-Reply-To:From; b=IwV98fD0iNNIaSyBjjFSjccmrQCFNEBRoFhaVTxfykbHdwMZsePIh9H7f3rHDpMTD dllQwQ2m+fBO0Z/ytNHzfHosY/oxOj/j56cXf0idRymOT44j6y7Js4Xw6MPg1VV6+E d12e1XrTr5vN1/VpgyozcqbA8jPgvNWakYWLntqk= Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 55E0B98087; Fri, 9 Oct 2015 13:23:19 +0000 (GMT) Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 9 Oct 2015 08:23:19 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Fri, 9 Oct 2015 08:23:18 -0500 From: "Short, Todd" To: Karthikeyan Bhargavan Thread-Topic: [TLS] PR for anti-downgrade mechanism Thread-Index: AQHRAo1rIYkWu6+Z9kuHrxSDHQfmD55jcFkAgAAJroA= Date: Fri, 9 Oct 2015 13:23:18 +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.47.110] Content-Type: multipart/alternative; boundary="_000_ADFC607BD2B44BFBA8FBA10F1DC2B21Cakamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 13:23:23 -0000 --_000_ADFC607BD2B44BFBA8FBA10F1DC2B21Cakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE9jdCA5LCAyMDE1LCBhdCA4OjQ4IEFNLCBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gPGth cnRoaWsuYmhhcmdhdmFuQGdtYWlsLmNvbTxtYWlsdG86a2FydGhpay5iaGFyZ2F2YW5AZ21haWwu Y29tPj4gd3JvdGU6DQoNCi0gVGhlcmUgaXMgYSAxLygyXk4pIGNoYW5jZSB0aGF0IHZhbGlkIGNv bm5lY3Rpb25zIHRvIFRMUyAxLjIgc2VydmVycyB3aWxsIGJlIGRyb3BwZWQgYnkNCiAgIFRMUyAx LjMgY2xpZW50cywgYmVjYXVzZSBvZiB0aGlzIHByb3Bvc2FsLiBUaGlzIG9ubHkgaGFwcGVucyBm b3Igc2VydmVycyB0aGF0IGRvIG5vdA0KICAgdXNlIHRoZSB1bml4IHRpbWVzdGFtcCAodGhlIGN1 cnJlbnQgdGltZXN0YW1wIGlzIGdyZWF0ZXIgdGhhbiAwMzA0eHh4eCkuDQogICBTdGlsbCwgd2Ug bmVlZCB0byBjYXJlZnVsbHkgY2hvb3NlIE4gc28gdGhhdCB0aGlzIHJpc2sgb2YgY29ubmVjdGlv biBkcm9wcGluZyBpcyBhY2NlcHRhYmxlLg0KDQpJ4oCZbSB0aGlua2luZyB0aGlzIGNoYW5jZSBj YW4gYmUgcmVkdWNlZCB0byAwLg0KV291bGRu4oCZdCBhIFRMU3YxLjMgY2xpZW50IGJlIGFibGUg dG8gcmVjb2duaXplIHRoYXQgaXTigJlzIGNvbm5lY3RpbmcgdG8gYSBUTFN2MS4yIHNlcnZlciwg YW5kIG5vdCBwYXJzZSB0aGUgZmlyc3QgTiBiaXRzIG9mIHRoZSBzZXJ2ZXIgcmFuZG9tPw0KDQot LQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWkuY29tPG1haWx0bzp0c2hvcnRAYWthbWFp LmNvbT4NCi8vICJPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhl IEludGVybmV0LiINCg0K --_000_ADFC607BD2B44BFBA8FBA10F1DC2B21Cakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <9440672454B1A34A9565CB5E08834BC6@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBh cHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gT2N0IDks IDIwMTUsIGF0IDg6NDggQU0sIEthcnRoaWtleWFuIEJoYXJnYXZhbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmthcnRoaWsuYmhhcmdhdmFuQGdtYWlsLmNvbSIgY2xhc3M9IiI+a2FydGhpay5iaGFyZ2F2 YW5AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCi0gVGhlcmUgaXMgYSAxLygyXk4pIGNoYW5jZSB0aGF0 IHZhbGlkIGNvbm5lY3Rpb25zIHRvIFRMUyAxLjIgc2VydmVycyB3aWxsIGJlIGRyb3BwZWQgYnk8 L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCiZu YnNwOyAmbmJzcDtUTFMgMS4zIGNsaWVudHMsIGJlY2F1c2Ugb2YgdGhpcyBwcm9wb3NhbC4gVGhp cyBvbmx5IGhhcHBlbnMgZm9yIHNlcnZlcnMgdGhhdCBkbyBub3QmbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCiZuYnNwOyAmbmJzcDt1 c2UgdGhlIHVuaXggdGltZXN0YW1wICh0aGUgY3VycmVudCB0aW1lc3RhbXAgaXMgZ3JlYXRlciB0 aGFuIDAzMDR4eHh4KS48L2Rpdj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7Ij4NCiZuYnNwOyAmbmJzcDtTdGlsbCwgd2UgbmVlZCB0byBjYXJlZnVsbHkgY2hv b3NlIE4gc28gdGhhdCB0aGlzIHJpc2sgb2YgY29ubmVjdGlvbiBkcm9wcGluZyBpcyBhY2NlcHRh YmxlLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPknigJltIHRoaW5raW5nIHRoaXMg Y2hhbmNlIGNhbiBiZSByZWR1Y2VkIHRvIDAuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldvdWxkbuKA mXQgYSBUTFN2MS4zIGNsaWVudCBiZSBhYmxlIHRvIHJlY29nbml6ZSB0aGF0IGl04oCZcyBjb25u ZWN0aW5nIHRvIGEgVExTdjEuMiBzZXJ2ZXIsIGFuZCBub3QgcGFyc2UgdGhlIGZpcnN0IE4gYml0 cyBvZiB0aGUgc2VydmVyIHJhbmRvbT88L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPi0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1U b2RkIFNob3J0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vIDxhIGhyZWY9Im1haWx0bzp0c2hvcnRA YWthbWFpLmNvbSIgY2xhc3M9IiI+dHNob3J0QGFrYW1haS5jb208L2E+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPi8vICZxdW90O09uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBi eSB0aGUgSW50ZXJuZXQuJnF1b3Q7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_ADFC607BD2B44BFBA8FBA10F1DC2B21Cakamaicom_-- From nobody Fri Oct 9 06:43:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF221B3E71 for ; Fri, 9 Oct 2015 06:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9njaHyufIPo for ; Fri, 9 Oct 2015 06:43:05 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 3B1E71B3E6E for ; Fri, 9 Oct 2015 06:43:05 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so67852936wic.1 for ; Fri, 09 Oct 2015 06:43:03 -0700 (PDT) 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-type; bh=JjxCJNU5JyS/9oez06Vjyk4dvURcvsSkk3XIr02UoHA=; b=ma6VF4cG53Vn44aooQjvX/y61cTxP6QiHcm5Y5XEcguhFACJc9K9rXOEmAhp7qkjMI a6caI5wAnhXZnrlpUTzcz4neWm1HLsitWbpEfoGaLMYGd6lhFqm4YZAxTJEsDlixSBGd vIVi2ZiK7ufCu758+GPAK0tCpbAWWk/Td4oNTQgQhPhbDSJ8X/UuhyA/gufZNnORETvr eSdCDrwmQJkWc3hI/rYaQabaiQJiC0YO7Ar7MTzciXqP9DLdCr9GA8GYyqAEyUDlK73a 9gx8RDy8uTwCOg0crmroinnWX4X6UOeItc90i6RCnUdtzGOVQuu0Ku5CvMM/SYVpJLP8 NqQw== X-Gm-Message-State: ALoCoQntX4MufFlXdIZRnQWuYuFZ9WU3Ht2gznMlwaLQFwDy4ea/gKc704O7u6wmkBHDMuzGe+XH X-Received: by 10.194.133.129 with SMTP id pc1mr14587890wjb.148.1444398183783; Fri, 09 Oct 2015 06:43:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Fri, 9 Oct 2015 06:42:24 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 9 Oct 2015 15:42:24 +0200 Message-ID: To: "Short, Todd" Content-Type: multipart/alternative; boundary=089e01227d94a8b7d00521ac2836 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 13:43:07 -0000 --089e01227d94a8b7d00521ac2836 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 9, 2015 at 3:23 PM, Short, Todd wrote: > > > On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan < > karthik.bhargavan@gmail.com> wrote: > > - There is a 1/(2^N) chance that valid connections to TLS 1.2 servers wil= l > be dropped by > TLS 1.3 clients, because of this proposal. This only happens for > servers that do not > use the unix timestamp (the current timestamp is greater than 0304xxxx= ). > Still, we need to carefully choose N so that this risk of connection > dropping is acceptable. > > > I=E2=80=99m thinking this chance can be reduced to 0. > Wouldn=E2=80=99t a TLSv1.3 client be able to recognize that it=E2=80=99s = connecting to a > TLSv1.2 server, and not parse the first N bits of the server random? > The idea is to distinguish this case from the case where they are connecting to an attacker pretending to be a TLS 1.2 server. -Ekr -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > --089e01227d94a8b7d00521ac2836 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 9, 2015 at 3:23 PM, Short, Todd <tshort@akamai.com>= wrote:


On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.co= m> wrote:

- There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will = be dropped by
=C2=A0 =C2=A0TLS 1.3 clients, because of this proposal. This only happens f= or servers that do not=C2=A0
=C2=A0 =C2=A0use the unix timestamp (the current timestamp is greater than = 0304xxxx).
=C2=A0 =C2=A0Still, we need to carefully choose N so that this risk of conn= ection dropping is acceptable.

I=E2=80=99m thinking this chance can be reduced to 0.
Wouldn=E2=80=99t a TLSv1.3 client be able to recognize that it=E2=80= =99s connecting to a TLSv1.2 server, and not parse the first N bits of the = server random?

The idea is to d= istinguish this case from the case where they are connecting to
a= n attacker pretending to be a TLS 1.2 server.

-Ekr=

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;


--089e01227d94a8b7d00521ac2836-- From nobody Fri Oct 9 09:49:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E598A1B47B2 for ; Fri, 9 Oct 2015 09:49:10 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HufmCmjoaa8m for ; Fri, 9 Oct 2015 09:49:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB701B47B9 for ; Fri, 9 Oct 2015 09:49:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 94516284B56; Fri, 9 Oct 2015 16:49:02 +0000 (UTC) Date: Fri, 9 Oct 2015 16:49:02 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151009164902.GQ15070@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 09 Oct 2015 16:49:11 -0000 On Fri, Oct 09, 2015 at 02:23:30PM +0200, Eric Rescorla wrote: > Hi folks, > > Please take a look at the following PR which documents a suggestion > made by Karthik Bhargavan about how to prevent protection against > downgrade against downgrade from TLS 1.3 to TLS 1.2 and below. > > https://github.com/tlswg/tls13-spec/pull/284 > > The idea is that if a TLS 1.3 server receives a TLS 1.2 or below > ClientHello, it sets the top N bits of the ServerRandom to be a > specific fixed value. TLS 1.3 clients which receive a TLS 1.2 or below > ServerHello check for this value and abort if they receive it. This > allows for detection of downgrade attacks over and above the Finished > handshake as long as ephemeral cipher suites are used (because the > signature on the ServerKeyExchange covers the random values). No > protection is provided for static RSA cipher suites, but this still > has some value if you have an attack which only affects (EC)DHE. I think this is "too clever" (a "hack" not a design) and offers incomplete protection (does nothing to protect RSA key transport). So I do not support adoption of this proposal. If new attacks against TLS 1.0--1.2 emerge that enable MITM via version downgrade combined with use of weaker algorithms, then we'll just have to prohibit those weaker algorithms in TLS 1.3 servers (and possibly also clients). -- Viktor. From nobody Fri Oct 9 10:20:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125661B48E3 for ; Fri, 9 Oct 2015 10:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 Xll1xBQXHUBl for ; Fri, 9 Oct 2015 10:20:48 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 2CB491B48F1 for ; Fri, 9 Oct 2015 10:20:45 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so88810754lbc.3 for ; Fri, 09 Oct 2015 10:20:43 -0700 (PDT) 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:date :message-id:subject:from:to:content-type; bh=GvvoXhLtOE0jRxIMpOrbunII7/wfn70NNP+GOrGHFhU=; b=gBhAocPCMwgtB5V85vroaN6leCFhpYydJeLIA7RPFKlLMdrLlA7AA1+gNyhyFbscts EgT+PY5bOlh0Xf+VhBvkvevBjOahOzTUhdSLAxp4ER9SBC5RsghQBqv+kRdwRFfWqKMn vlKOWkmECUq41IWjwhczApcrFoXAAiu7+Bq57NqXjtz8eYq1pAe8Ev9qW6P2815iw8NO omsVv8s21cNvqvH3q7ARo5CdCpnxAsbD77ByOjCv3b0fjj49DErxtTNZtqjiKOcV1tOQ UmTxFgWohj0vLzDLfWEtf79tyjje+NGIh6XO01OEf23CMPs2cUlHFOw9gsEGNUNl4AM9 +qRA== X-Gm-Message-State: ALoCoQliamQ1b0nW96lDDoN41iWrPDtnDIUsoIxiP0oR8nWj3BBe8rwST70cvJsudUAdXWcFNFTN MIME-Version: 1.0 X-Received: by 10.112.210.129 with SMTP id mu1mr7265725lbc.68.1444411243389; Fri, 09 Oct 2015 10:20:43 -0700 (PDT) Received: by 10.112.2.231 with HTTP; Fri, 9 Oct 2015 10:20:43 -0700 (PDT) In-Reply-To: References: <20151008212255.D1F431A2CF@ld9781.wdf.sap.corp> Date: Fri, 9 Oct 2015 10:20:43 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c31e4c127d9b0521af33fc Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 17:20:50 -0000 --001a11c31e4c127d9b0521af33fc Content-Type: text/plain; charset=UTF-8 The chairs have read through this thread and do not see any new information that would cause the working group to reconsider the decision to remove compression from TLS 1.3. Discussions about clarifying the language and intent of the document are OK. Thanks, J&S On Thu, Oct 8, 2015 at 6:42 PM, Eric Rescorla wrote: > > > On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex wrote: > >> Eric Rescorla wrote: >> > Short, Todd wrote: >> >> >> >> However, for those ClientHello?s that support older versions, the >> >> compression_method field may contain other values. This means that if a >> >> TLSv1.3 client happened to support compression for TLSv1.2, it would be >> >> unable to negotiate that via a single ClientHello. There?s no way to >> >> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-compression in >> a >> >> single ClientHello. >> >> Yup, that is the problem with the current text. > > > Thanks for clarifying this. > > >> >> >> > >> >> In effect, the document is stating that a TLSv1.3 client MUST NOT >> support >> >> compression, regardless of the protocol version that may be negotiated. >> > >> > Yes, this is what I believe it says and what I believe the WG had >> consensus >> > on, the reasoning being that we really wished to just remove the feature >> > entirely. If the chairs declare consensus on something else, I will of >> > course edit it to say something else. >> >> The current text is trying to force a specific policy in a fashion >> that is in the worst conceivable violation of rfc2119 section 6 that >> is possible. >> >> A ClientHello with >> >> ClientHello.client_version = (3,3) >> ClientHello.compression_methods = (1,0) >> >> will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers. >> >> >> ClientHello.client_version = (3,4) >> ClientHello.compression_methods = (1,0) >> >> will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers, >> but TLSv1.3 servers that follow the stupid idea will choke and >> abort with an "illegal_parameter" alert. >> >> Essentially, the current wording is calling for a newly creating what >> must be called a "compression method intolerance" -- but essentially >> it is indistinguishable from a "TLS version intolerance" > > > Hmm... I'm not sure I follow this argument. We have a bunch of rules for > how TLS 1.3 clients MUST behave and TLS 1.3 servers will choke if > they don't. This doesn't create any present interop problem and only > creates a problem if in future we wish to reintroduce compression. > Is that your concern? > > > >> For a number of years, it seemed to have been consensus in the IETF TLS WG >> that TLS version intolerance is an implemenattion defect and a real >> problem. >> It would be sad if the current TLS WG would confirm that recklessly adding >> handshake failure causing new intolerances into TLSv1.3 is the new >> engeneering approach. > > > As I said, I edited the document in conformance with what I believed the > chair declaration of WG consensus was. If the WG consensus is to remove > this requirement, then I will of course do so. So, rather than going back > and > forth, I would suggest that the best way for you to proceed here is to: > > 1. Ask the chairs to re-state the previous consensus. If I misunderstood, > then that's > easy. > 2. If you're still not happy, then you could ask the chairs to re-assess > the currnet > consensus. > 3. If you're still not happy, and you believe this violates 2119, then you > can of > course appeal. > > This of course also goes for people who think we should re-allow > compression. > > Best, > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c31e4c127d9b0521af33fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The chairs have read through= this thread and do not see any new information that would cause the workin= g group to reconsider the decision to remove compression from TLS 1.3. =C2= =A0 Discussions about clarifying the language and intent of the document ar= e OK.

Thanks,

J&S

On Thu, Oct 8, 2015 at 6:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:

=

= On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex <mrex@sap.com> wrot= e:
Eric Rescorla wrote:
> Short, Todd <tshort@akamai.com> wrote:
>>
>> However, for those ClientHello?s that support older version= s, the
>> compression_method field may contain other values. This mean= s that if a
>> TLSv1.3 client happened to support compression for TLSv1.2, it wou= ld be
>> unable to negotiate that via a single ClientHello. There?s = no way to
>> attempt to negotiate TLSv1.2+compression and TLSv1.3+no-comp= ression in a
>> single ClientHello.

Yup, that is the problem with the current text.
Thanks for clarifying this.
= =C2=A0


>
>> In effect, the document is stating that a TLSv1.3 client MUST NOT = support
>> compression, regardless of the protocol version that may be negoti= ated.
>
> Yes, this is what I believe it says and what I believe the WG had cons= ensus
> on, the reasoning being that we really wished to just remove the featu= re
> entirely. If the chairs declare consensus on something else, I will of=
> course edit it to say something else.

The current text is trying to force a specific policy in a fashion that is in the worst conceivable violation of rfc2119 section 6 that
is possible.

A ClientHello with

=C2=A0 =C2=A0 ClientHello.client_version =3D (3,3)
=C2=A0 =C2=A0 ClientHello.compression_methods =3D (1,0)

will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers.

=C2=A0 =C2=A0 ClientHello.client_version =3D (3,4)
=C2=A0 =C2=A0 ClientHello.compression_methods =3D (1,0)

will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers,
but TLSv1.3 servers that follow the stupid idea will choke and
abort with an "illegal_parameter" alert.

Essentially, the current wording is calling for a newly creating what
must be called a "compression method intolerance" -- but essentia= lly
it is indistinguishable from a "TLS version intolerance"

Hmm... I'm not sure I follow this argume= nt. We have a bunch of rules for
how TLS 1.3 clients MUST behave = and TLS 1.3 servers will choke if
they don't. This doesn'= t create any present interop problem and only
creates a problem i= f in future we wish to reintroduce compression.
Is that your conc= ern?

=C2=A0
For a number of years, it seemed to have been consensus in the IETF TLS WG<= br> that TLS version intolerance is an implemenattion defect and a real problem= .
It would be sad if the current TLS WG would confirm that recklessly adding<= br> handshake failure causing new intolerances into TLSv1.3 is the new
engeneering approach.

As I said, I e= dited the document in conformance with what I believed the
chair = declaration of WG consensus was. If the WG consensus is to remove
this requirement, then I will of course do so. So, rather than going back = and
forth, I would suggest that the best way for you to proceed h= ere is to:

1. Ask the chairs to re-state the previ= ous consensus. If I misunderstood, then that's
easy.
2. If you're still not happy, then you could ask the chairs to re-ass= ess the currnet
consensus.
3. If you're still not h= appy, and you believe this violates 2119, then you can of
course = appeal.

This of course also goes for people who th= ink we should re-allow compression.

Best,
-Ekr


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


--001a11c31e4c127d9b0521af33fc-- From nobody Fri Oct 9 13:14:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A302B1B2CF3 for ; Fri, 9 Oct 2015 13:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5MG-6GOweeu for ; Fri, 9 Oct 2015 13:14:12 -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 D474D1B2CEC for ; Fri, 9 Oct 2015 13:14:07 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 8815B44D4C; Fri, 9 Oct 2015 22:14:05 +0200 (CEST) X-purgate-ID: 152705::1444421645-00001EB9-8419F382/0/0 X-purgate-size: 3261 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 7A7C44088E; Fri, 9 Oct 2015 22:14:05 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 707081A2D3; Fri, 9 Oct 2015 22:14:05 +0200 (CEST) In-Reply-To: To: Joseph Salowey Date: Fri, 9 Oct 2015 22:14:05 +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: <20151009201405.707081A2D3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2015 20:14:14 -0000 Joseph Salowey wrote: > > The chairs have read through this thread and do not see any new information > that would cause the working group to reconsider the decision to remove > compression from TLS 1.3. I am (and I was) perfectly fine with removing compression from TLSv1.3. (btw. our own implementation never implemented TLS compression). > > Discussions about clarifying the language and > intent of the document are OK. But in the previous discussion only Todd Short seems to understand, why I am objecting to one specific requirement in the current plan to achieve removal of compression from TLSv1.3. >>> >>> A ClientHello with >>> >>> ClientHello.client_version = (3,3) >>> ClientHello.compression_methods = (DEFLATE(1),null(0)) >>> >>> will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers. >>> >>> >>> ClientHello.client_version = (3,4) >>> ClientHello.compression_methods = (DEFLATE(1),null(0)) >>> >>> will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers, The issue is about the TLSv1.3 server response for the second case above. If we want to have compression removed from TLSv1.3, then my suggested wording would be sufficient, and provide proper and robust negotiation of TLS protocol options: All TLS protocol versions require the "null" compression method MUST be included/present in the compression_methods list of ClientHello. A TLSv1.3 server that is offered and selects/negotiates protocol version TLSv1.3, MUST select the "null" compression method, and MUST ignore all other compression methods that might appear in the compression_methods list of ClientHello. The (current) text, which Eric quoted, on the other hand: For any TLS 1.3 ClientHello, this field MUST contain only the ?null? compression method with the code point of 0. If a TLS 1.3 ClientHello is received with any other value in this field, the server MUST generate a fatal 'illegal_parameter' alert. would require a TLSv1.3 server to unconditionally abort the TLS handshake rather than to negotiate the "null" compression and continue the handshake. The original intent of the ClientHello & ServerHello handshake messages is negotiation of TLS protocol parameters, and choking&aborting rather than performing selection&negotiation of the desired protocol options is what we see in the installed base in form of "TLS version intolerance" and "TLS extensions intolerance", and what caused browser implementors to come up with an insecure&dangerous scheme known as "downgrade dance", which was demonstrated to be a bad idea, because it is what made POODLE possible in the first place. The proposed "choke on everything but compression_method = (0)" rather than "you MUST select the null compression method for TLSv1.3" is particularly weird due to the statement that follows the current text: Note that TLS 1.3 servers may receive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS. -Martin From nobody Fri Oct 9 13:14:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8651A8826 for ; Fri, 9 Oct 2015 13:14:16 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8mbV2tOehn7 for ; Fri, 9 Oct 2015 13:14:14 -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 37BBD1B2CED for ; Fri, 9 Oct 2015 13:14:08 -0700 (PDT) Received: by qkht68 with SMTP id t68so37418181qkh.3 for ; Fri, 09 Oct 2015 13:14:07 -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-type:content-transfer-encoding:message-id; bh=JTUbVJ5dDte9W2AmqI/6KpY6FDnabB1O07ISEzG942I=; b=rz0A3kBhmrr86OidTB/jJVFCiMa9UWLjTkgiPTUjmB8zy27AIFLOspln57XWMNHyL7 FMIz6XAxOo4DhCtpL3WywB5NgBJPMaXvW8zljJEWobjCMvzr+GqGpB2Wf3s2bjItr4/9 /64h50uc/axm4Bo/Gn+8B83Zg0NZB4bpBY0KSAUeSruyx/n5r4/vu1UKx4ln6GUO0K4W O0pMr42FNDx7qb0rqrUfBI1uZnC9jtlWIhKzWjoz4uFpN2zxVLwimqY5KAIzik/gJSZA MglYQZ0H4ORTnbrk0OqwuNbqhgx1eiDq9gJopOCVNNBJ6VnXZZuZ9iXa9xGRTSbcntBA OCRA== X-Received: by 10.55.42.141 with SMTP id q13mr17509873qkq.13.1444421647422; Fri, 09 Oct 2015 13:14:07 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id l91sm1362360qkh.46.2015.10.09.13.14.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 09 Oct 2015 13:14:07 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Viktor Dukhovni Date: Fri, 9 Oct 2015 16:14:05 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151009164902.GQ15070@mournblade.imrryr.org> In-Reply-To: <20151009164902.GQ15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510091614.06047.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 20:14:16 -0000 On Friday, October 09, 2015 12:49:02 pm Viktor Dukhovni wrote: > I think this is "too clever" (a "hack" not a design) and offers Every fix to an issue in this 20 year old protocol will be a hack. > incomplete protection (does nothing to protect RSA key transport). Better than none, for a very low cost. > So I do not support adoption of this proposal. > > If new attacks against TLS 1.0--1.2 emerge that enable MITM via > version downgrade combined with use of weaker algorithms, then > we'll just have to prohibit those weaker algorithms in TLS 1.3 > servers (and possibly also clients). Those changes are harder to make than they should be, unless we want to do that now. Dave From nobody Fri Oct 9 13:15:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A171B2CFD for ; Fri, 9 Oct 2015 13:15:47 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEuRIk697GSI for ; Fri, 9 Oct 2015 13:15:46 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c: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 2B40C1B2CFA for ; Fri, 9 Oct 2015 13:15:46 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so80977690wic.0 for ; Fri, 09 Oct 2015 13:15: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:date:message-id:subject:from:to :cc:content-type; bh=Y7TQn6fdIu4Gt+ewUV9cYym/Ke+bKu/bc+5XBKMKrBA=; b=NTA55QUCkIeQjtOxyiROYqeeaLqpU03vN1Hr0AEWq3bD30bnkonLiKtz+baKWH8W7Q VnOInNOhTzjYkwaQMUT6r6gvsLQhcyeGeqvfNFpj/PsU0H74muQ5sWe8hSsVuFfsYMWv WWVO4kY7d1EuWjdWlQc5eEFMSqHteXTC0uFiKxFXbxa3Y3dAgX+ljObml15y10ubqmZ3 EgpE3evCt9YBnZNInCS5yoxRAoMhtgjGWWKDG3E2tMotIG2/ocj+m8VFRMepLnita5Vw +UtaT5sRyW4xN71utM/85CiTcOZCYDJ34px2SgGINgh5JTPaIKKJKX6Y/imDUWhFV+32 74Bg== MIME-Version: 1.0 X-Received: by 10.194.175.232 with SMTP id cd8mr17968930wjc.45.1444421744791; Fri, 09 Oct 2015 13:15:44 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Fri, 9 Oct 2015 13:15:44 -0700 (PDT) In-Reply-To: <20151009201405.707081A2D3@ld9781.wdf.sap.corp> References: <20151009201405.707081A2D3@ld9781.wdf.sap.corp> Date: Fri, 9 Oct 2015 16:15:44 -0400 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 20:15:47 -0000 On Fri, Oct 9, 2015 at 4:14 PM, Martin Rex wrote: > Joseph Salowey wrote: >> >> The chairs have read through this thread and do not see any new information >> that would cause the working group to reconsider the decision to remove >> compression from TLS 1.3. > > I am (and I was) perfectly fine with removing compression from TLSv1.3. > (btw. our own implementation never implemented TLS compression). > > >> >> Discussions about clarifying the language and >> intent of the document are OK. > > But in the previous discussion only Todd Short seems to understand, why I am > objecting to one specific requirement in the current plan to achieve > removal of compression from TLSv1.3. > >>>> >>>> A ClientHello with >>>> >>>> ClientHello.client_version = (3,3) >>>> ClientHello.compression_methods = (DEFLATE(1),null(0)) >>>> >>>> will be interoperable with TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3 servers. >>>> >>>> >>>> ClientHello.client_version = (3,4) >>>> ClientHello.compression_methods = (DEFLATE(1),null(0)) >>>> >>>> will be interoperable with TLSv1.0, TLSv1.1 and TLSv1.2 servers, > > The issue is about the TLSv1.3 server response for the second case above. > > If we want to have compression removed from TLSv1.3, then my suggested > wording would be sufficient, and provide proper and robust negotiation > of TLS protocol options: > > All TLS protocol > versions require the "null" compression method MUST be included/present > in the compression_methods list of ClientHello. A TLSv1.3 server that > is offered and selects/negotiates protocol version TLSv1.3, MUST select > the "null" compression method, and MUST ignore all other compression > methods that might appear in the compression_methods list of ClientHello. > > The (current) text, which Eric quoted, on the other hand: > > For any TLS 1.3 > ClientHello, this field MUST contain only the ?null? compression method > with the code point of 0. If a TLS 1.3 ClientHello is received with any > other value in this field, the server MUST generate a fatal > 'illegal_parameter' alert. > > would require a TLSv1.3 server to unconditionally abort the TLS handshake > rather than to negotiate the "null" compression and continue the handshake. Why is it important that clients be permitted to signal support for compression and TLS 1.3 conditionally? Remember, we also want to phase out the use of compression in TLS 1.2. From nobody Fri Oct 9 13:16:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0586C1B2D04 for ; Fri, 9 Oct 2015 13:16: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4npimV6yGkz for ; Fri, 9 Oct 2015 13:15:56 -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 980A21B2D03 for ; Fri, 9 Oct 2015 13:15:56 -0700 (PDT) Received: by qkap81 with SMTP id p81so37567713qka.2 for ; Fri, 09 Oct 2015 13:15:55 -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-type:content-transfer-encoding:message-id; bh=CNaHy34PjtKeaD1F0OE46mwpb45TlFjlG/ZOJPERA4Y=; b=YOYwzjuXLKt+cAc8ZyeuwSDS2Ro9fLJewEyjdv1c5XWF1/k/0gGnbG/Ks0llq50pZ1 Rvy2g7vOJxYdMQd3DYpt8xu+Mz/XPvYg3qQmOHOQ1+wU0zT6RjfYmwIBPok+shdorFzb GZrvDET9kytF+ej1Y/GgmRPrx7e7o7wSePdwgulqXknarE7jHaLeAvKhxFzNLvdjDfNv DyQc9m0o/ZzLUBd7LmzS8m/t5QnV6R8CEePKGm3LNbtRS50GreLVxQLliR3JmoGUrote rVQETdvBvbcv0WNXEoiDQplSg/6e+DbOtcyudIPpRf7prUbav+wN4dIawqTi0DnoCW8J PqFw== X-Received: by 10.55.52.210 with SMTP id b201mr17329697qka.37.1444421755743; Fri, 09 Oct 2015 13:15:55 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w3sm1378826qha.0.2015.10.09.13.15.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 09 Oct 2015 13:15:55 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Fri, 9 Oct 2015 16:15:54 -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: <201510091615.54305.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 20:16:00 -0000 On Friday, October 09, 2015 08:23:30 am Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/284 > > The idea is that if a TLS 1.3 server receives a TLS 1.2 or below > ClientHello, it sets the top N bits of the ServerRandom to be a > specific fixed value. [...] > I've written this up with 48 bits and a specific fixed value (03 04 03 > 04 03 04) but that's just a strawman and we can bikeshed on that if > people think this is a good idea. I support this, though I would like to know why 6 bytes was chosen instead of just 4. I don't object; I would just like to know the reasoning here. Dave From nobody Fri Oct 9 13:23:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4EC1B2D30 for ; Fri, 9 Oct 2015 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0OAdeBcRTYj for ; Fri, 9 Oct 2015 13:23:51 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 E45A91ACD33 for ; Fri, 9 Oct 2015 13:23:50 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so85084303wic.1 for ; Fri, 09 Oct 2015 13:23:49 -0700 (PDT) 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-type; bh=qRX5NVYf2DwGtG96i6dCYDaz/AgrF/ZXVQeQzzwZFD0=; b=lU3LfcSO483ozWzrPybBx9u70880U4T+RycyAuNrjVVZgG+w9razUidgboLXd1HQXO gBGfd+1pVRej4wrKTHBH971DFA4z59ZdN7oaHsww2OdmQBpnTHD2gp2KLO8ROMAuIOvy WCEQPjwOMVh3vgffuu5Nl+AckhmEFRC8Pwfh+4vfT8aEOzCNF/txczQuqJMGkCuunmuQ bGUa/T1P/PMOrajPUgOuOo0nK542rxthUNOHuL7PclJ1ka43LyjB9n/34MAnIg0eT6p1 hmS06taWZ6URihRBPp4X/l5UWpzPIrMFj8pPE987Oj8lqxVRokwJdGOino/M43tgME3+ HPuQ== X-Gm-Message-State: ALoCoQlmHrRu92SS/2P6mp/nErJho8Dd1uynD6/Ss32LiDCtWo/eYifT9xN6HjA36k2vw/BTeG8e X-Received: by 10.194.133.129 with SMTP id pc1mr16589804wjb.148.1444422229555; Fri, 09 Oct 2015 13:23:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Fri, 9 Oct 2015 13:23:09 -0700 (PDT) In-Reply-To: <201510091615.54305.davemgarrett@gmail.com> References: <201510091615.54305.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 9 Oct 2015 22:23:09 +0200 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e01227d94e6120a0521b1c10d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 20:23:53 -0000 --089e01227d94e6120a0521b1c10d Content-Type: text/plain; charset=UTF-8 It's largely arbitrary, but the reasoning is as follows. There are apparently some TLS 1.2 servers which randomly generate the entire server random (and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00 would encourage more to do so). The chance of a false positive between such a server and a TLS 1.3 client is 2^{-32}, which seemed a bit high. -Ekr On Fri, Oct 9, 2015 at 10:15 PM, Dave Garrett wrote: > On Friday, October 09, 2015 08:23:30 am Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/284 > > > > The idea is that if a TLS 1.3 server receives a TLS 1.2 or below > > ClientHello, it sets the top N bits of the ServerRandom to be a > > specific fixed value. > [...] > > I've written this up with 48 bits and a specific fixed value (03 04 03 > > 04 03 04) but that's just a strawman and we can bikeshed on that if > > people think this is a good idea. > > I support this, though I would like to know why 6 bytes was chosen instead > of just 4. I don't object; I would just like to know the reasoning here. > > > Dave > --089e01227d94e6120a0521b1c10d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's largely arbitrary, but the reasoning is as follow= s. There are apparently
some TLS 1.2 servers which randomly generate th= e entire server random
encourage more to do so). = The chance of a false positive between such
a server and a TLS 1.= 3 client is 2^{-32}, which seemed a bit high.

-Ekr=


On Fri, Oct 9, 2015 at 10:15 PM, Dave Garrett &= lt;davemgarrett= @gmail.com> wrote:
On Friday, October 09, 2015 08:23:30 am Eric Rescorla wrote:
>=C2=A0 =C2=A0https://github.com/tlswg/tls13-spec/pul= l/284
>
> The idea is that if a TLS 1.3 server receives a TLS 1.2 or below
> ClientHello, it sets the top N bits of the ServerRandom to be a
> specific fixed value.
[...]
> I've written this up with 48 bits and a specific = fixed value (03 04 03
> 04 03 04) but that's just a strawman and we can bikeshed on that i= f
> people think this is a good idea.

I support this, though I would like to know why 6 bytes was chosen i= nstead of just 4. I don't object; I would just like to know the reasoni= ng here.


Dave

--089e01227d94e6120a0521b1c10d-- From nobody Fri Oct 9 13:38:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37C31A1B6E for ; Fri, 9 Oct 2015 13:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 Mz3YMzWMvXTU for ; Fri, 9 Oct 2015 13:38:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA8E1A1B6B for ; Fri, 9 Oct 2015 13:38:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3D047284B56; Fri, 9 Oct 2015 20:38:00 +0000 (UTC) Date: Fri, 9 Oct 2015 20:38:00 +0000 From: Viktor Dukhovni Cc: tls@ietf.org Message-ID: <20151009203759.GU15070@mournblade.imrryr.org> References: <201510091615.54305.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 09 Oct 2015 20:38:03 -0000 On Fri, Oct 09, 2015 at 10:23:09PM +0200, Eric Rescorla wrote: > It's largely arbitrary, but the reasoning is as follows. There are > apparently some TLS 1.2 servers which randomly generate the entire server > random (and https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00 would > encourage more to do so). The chance of a false positive between such > a server and a TLS 1.3 client is 2^{-32}, which seemed a bit high. Yes, law of large numbers. While any one session is unlikely to fail, the chance of some sessions failing needlessly becomes appreciable, and some of failures may be have high criticality and be latency sensitive. Of course packet corruption undetected by TCP checksums is perhaps more likely, and the client should treat this like as data corruption, rather than a MITM attack, and just reconnect and try again. The problem is that reconnecting is not something the TLS layer can do. And applications might not be instrumented to recover as quickly or as gracefully as they should. Plus, not all use of TLS is over unreliable network transports. TLS is also used over Unix domain sockets, where one does not expect either MITM attacks or data corruption. So even 2^{-48} is perhaps not quite low enough. I still think we're better off fixing serious problems in TLS 1.2 as we find them regardles of whether the server and client happen to also support 1.3. -- Viktor. From nobody Fri Oct 9 13:49:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E830A1ACC8B for ; Fri, 9 Oct 2015 13:49:49 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4kGGh_623me for ; Fri, 9 Oct 2015 13:49:48 -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 9996C1ACC88 for ; Fri, 9 Oct 2015 13:49:48 -0700 (PDT) Received: by qkht68 with SMTP id t68so37814213qkh.3 for ; Fri, 09 Oct 2015 13:49:47 -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-type:content-transfer-encoding:message-id; bh=DjgEMBL33HvE25U2uFkRpmQBOUSzLZG8ilz0KtpUjIk=; b=p8Ph+6MzpjEBFT2XTkddE/y78AetHOtakoiSGq42oo5qimoHEpJoSNb4GT5sBipnhI E1uPZSOWGmN+oO3MMzNB2wO+rRsLhWeSQMfxA8ISfRbSqs1ABmX7aAY/KAXlInx1jBkW Jo2EhXSk48IyLFlfUQNwwO95lGUcuv9pC10eRJYt5DagUwBGNl5gScZY4yeLwSQERCCg vr45yEeojyqGNPbHfr4vku9OyEMefaD0wqOep4rdtfSV8hFEV6QOKu5ipWBX3ZuYvuRq 6aXek9jbGJLjbyCqxYxS3jPgNAEIXBwyKYdUL6VNklMaxq+he3BgIz9g3bxYlHAwFMk8 ntBg== X-Received: by 10.55.198.217 with SMTP id s86mr17749822qkl.75.1444423787667; Fri, 09 Oct 2015 13:49:47 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 65sm1419122qha.41.2015.10.09.13.49.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 09 Oct 2015 13:49:47 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Fri, 9 Oct 2015 16:49:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151009203759.GU15070@mournblade.imrryr.org> In-Reply-To: <20151009203759.GU15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510091649.46056.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 20:49:50 -0000 On Friday, October 09, 2015 04:38:00 pm Viktor Dukhovni wrote: > So even 2^{-48} is perhaps not quite low enough. Going to a full 64-bit looks like a good idea to me. The loss of those 4 bytes of entropy for old versions isn't likely to matter at all, though, please correct me if someone thinks otherwise. On a related note, I think it might be a good idea to add a note somewhere stating that TLS 1.3 now only uses the hello random values indirectly, but they're still used via the session hash. On a tangential note, if anyone sees the need to increase the entropy introduced in the hellos, a supplemental random extension sent by both endpoints would be trivial to create with the current design. (questioning the size of the randoms here is an explicit question in the current TLS WG charter, as is the topic of additional downgrade mechanisms) Dave From nobody Fri Oct 9 13:59:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1AE1ACD55 for ; Fri, 9 Oct 2015 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftHd9srg2Oeu for ; Fri, 9 Oct 2015 13:59:06 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6151ACD54 for ; Fri, 9 Oct 2015 13:59:06 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C95BC20005C; Fri, 9 Oct 2015 20:59:05 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id B3E3220005B; Fri, 9 Oct 2015 20:59:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444424345; bh=3lxfYIKyqilMSOxvLqLl+e+7CEAXJoDmBCrww+OxQJ4=; l=174; h=From:To:CC:Date:References:In-Reply-To:From; b=oaLdK9dW4UZWyY49+XoFmlGgMiX8fT6baGIKRnW3FJorvcDDF/isv8Ge9smFSEglA cBljr7SM0SGm0JdmDMqEn5JQRdKAGsIJ2KKhIsQlNUfHhQn6vUjK3UWJNkBB8xK7XL 4dMRaSmp75ruEf9CGVALCrFBFhTBDf2aPuqUiS1M= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id B0B151E08F; Fri, 9 Oct 2015 20:59:05 +0000 (GMT) Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 9 Oct 2015 15:59:05 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1076.000; Fri, 9 Oct 2015 15:59:05 -0500 From: "Salz, Rich" To: Eric Rescorla , Dave Garrett Thread-Topic: [TLS] PR for anti-downgrade mechanism Thread-Index: AQHRAo2Q0IEKIsBrDEGbJYrdidEk7p5j7VAAgAACBoD//7YWEA== Date: Fri, 9 Oct 2015 20:59:05 +0000 Message-ID: References: <201510091615.54305.davemgarrett@gmail.com> 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.44.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 20:59:08 -0000 PiBJdCdzIGxhcmdlbHkgYXJiaXRyYXJ5LCBidXQgdGhlIHJlYXNvbmluZyBpcyBhcyBmb2xsb3dz Lg0KDQpBbmQgc28gdGhhdCB3ZSBjYW4gcHV0ICJUTFMxLjMiIGFzIHRoZSBzaXggYnl0ZXMgaW4g VVRGLTguDQoNCg== From nobody Fri Oct 9 15:18:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A941B4DD3 for ; Fri, 9 Oct 2015 15:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjHSz5Qw5MpT for ; Fri, 9 Oct 2015 15:18:08 -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 51BF61B4DC3 for ; Fri, 9 Oct 2015 15:18:08 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 5B1972B151; Sat, 10 Oct 2015 00:18:06 +0200 (CEST) X-purgate-ID: 152705::1444429086-00001EB9-FC60DD1D/0/0 X-purgate-size: 754 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 4A99040257; Sat, 10 Oct 2015 00:18:06 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3D6EA1A2D4; Sat, 10 Oct 2015 00:18:06 +0200 (CEST) In-Reply-To: To: Watson Ladd Date: Sat, 10 Oct 2015 00:18: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: <20151009221806.3D6EA1A2D4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2015 22:18:10 -0000 Watson Ladd wrote: > > Why is it important that clients be permitted to signal support for > compression and TLS 1.3 conditionally? Remember, we also want to phase > out the use of compression in TLS 1.2. compression in TLS is *NOT* generally bad, and not generally a problem. It may be a problem for usage scenarios where attacker-supplied content and unknown content are mixed prior to compression, and in particular where an attacker is freely given elaborate control over the behaviour of one of the endpoints (e.g. SSL-VPNs and Web-Browsers), but there are many more, perfectly valid usage scenarios, where TLS compression is in current use, such as copying huge sparse files over a TLS-protected communication channel. -Martin From nobody Fri Oct 9 15:40:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C998B1B2D83 for ; Fri, 9 Oct 2015 15:40:19 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5No5t3CCW-w for ; Fri, 9 Oct 2015 15:40:18 -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 444D11B2D7C for ; Fri, 9 Oct 2015 15:40:18 -0700 (PDT) Received: by qkas79 with SMTP id s79so38830509qka.0 for ; Fri, 09 Oct 2015 15:40:17 -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-type:content-transfer-encoding:message-id; bh=m0jvyVf9dzZ/PRiNUPcqpXb1WKZzSWVgj1reMdZF8Tg=; b=PTFHcRE9psVy2iQDKivzoKTbjtf2p5IizViBaH0gNoWPU0PiPzyG0K3DVulJxYaHI9 z7dYe0shGXcVm0lqhfPUjb2E6zjiLf5GETGR+4mL+xA8665QyOBNVlFMIunfAP7Q5ZAh HLmQ2qPLgH9bv0klVnCc5rarF+CnMGiQwPvuOveXb5S0etJjo/f0iAxckxTD52cu5lL9 Op2CvWHkRPCpdDJtGU5KQqaHgmFKoaHNWtZOhDkLRi9uOujwV71lKy8a+aqPzT5VJnyA 8wU7IlAxZlMGKVEOKQjnrs8HhwAlBdZd89FsJvZSwDOcqWhikAuJV3k5rJ/VqWEH4X9w uWAg== X-Received: by 10.55.20.2 with SMTP id e2mr18513884qkh.27.1444430417528; Fri, 09 Oct 2015 15:40:17 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 4sm1614996qhr.33.2015.10.09.15.40.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 09 Oct 2015 15:40:16 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, mrex@sap.com Date: Fri, 9 Oct 2015 18:40:15 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151009221806.3D6EA1A2D4@ld9781.wdf.sap.corp> In-Reply-To: <20151009221806.3D6EA1A2D4@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510091840.15898.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 22:40:20 -0000 On Friday, October 09, 2015 06:18:06 pm Martin Rex wrote: > are many more, perfectly valid usage scenarios, where TLS compression > is in current use, such as copying huge sparse files over a > TLS-protected communication channel. The better solution is to not do that and actually used compressed file formats optimized for their content types. That will work better than TLS compression or even application layer compression. Dave From nobody Fri Oct 9 15:41:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2F61B2D9A for ; Fri, 9 Oct 2015 15:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwpHWD6xPK22 for ; Fri, 9 Oct 2015 15:40:59 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (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 13B441B2D88 for ; Fri, 9 Oct 2015 15:40:59 -0700 (PDT) Received: by obbda8 with SMTP id da8so73275109obb.1 for ; Fri, 09 Oct 2015 15:40:58 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=lHkQY0EmpTsrs37u1EnpPMsSUr3Zr5KhjldidNvRENs=; b=QOmADJqrqB6nFsoXNb6ALAQlqMJh6Z2fYeg0Yh0ML+lWNgkcDrxtJ40mQj6GaU2IBw 8kOfs5UxrGr6AALWPqdBksFUgHcHDQVwk7vAr85frBuibsUPpO2ReoJyD5GZDaSlLEOq +hHR9zgIVoUtAkZq1eN+sJ37Ho112Cfmn8DDjRYmLQklWjnIF7EfKIhHYeui8e1ihfJw RaN3Rq756ZwSDSdub0vt1BKe10JVwU7gRg+m4HkqAk4ZvPCqeRKdd7hOfjyaltmUhE5O roxmX51w5PgjrI71i6wMaX7A1boJt+BeErgcGZCNzodLpKRk6ae6blN3K3RpTd4c4Q4l 4lxw== X-Gm-Message-State: ALoCoQnqXLEbz3oI88FWDHSVtauOxU6P0ImZGzUgc7mTRaC9w096rEKTfav2X+DVw+YQUmozUIHT MIME-Version: 1.0 X-Received: by 10.182.97.97 with SMTP id dz1mr9456216obb.17.1444430458444; Fri, 09 Oct 2015 15:40:58 -0700 (PDT) Received: by 10.76.100.36 with HTTP; Fri, 9 Oct 2015 15:40:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Oct 2015 12:40:58 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b2e438660fad20521b3ac69 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2015 22:41:01 -0000 --047d7b2e438660fad20521b3ac69 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 9, 2015 at 2:23 AM, Eric Rescorla wrote: > Please take a look at the following PR which documents a suggestion > made by Karthik Bhargavan about how to prevent protection against > downgrade against downgrade from TLS 1.3 to TLS 1.2 and below. > > https://github.com/tlswg/tls13-spec/pull/284 > > The idea is that if a TLS 1.3 server receives a TLS 1.2 or below > ClientHello, it sets the top N bits of the ServerRandom to be a > specific fixed value. > 1. Why would the server ever receive a TLS 1.2 or below ClientHello from a client that supports TLS 1.3? Why doesn't the already-standardized downgrade SCSV mechanism work for those cases? 2. My understanding is that every TLS 1.3 ClientHello contains a ClientKeyShare extension and that no TLS 1.2 or below ClientHello contains a ClientKeyShare extension. Therefore, the presence or absence of the ClientKeyShare extension already signals whether the client is attempting a TLS 1.3 handshake, or a handshake for a lower TLS version. Thus, also specifying ClientHello.client_version = 0x0304 is redundant. And, we've already seen clear evidence that ClientHello.client_version = 0x0304 leads to severe compatibility issues. So, why not just use ClientHello.client_version = 0x0303 and rely on the presence of the ClientKeyShare extension to disambiguate TLS 1.3 vs TLS 1.2 or below? Cheers, Brian --047d7b2e438660fad20521b3ac69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 9, 2015 at 2:23 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Please take a look at the followin= g PR which documents a suggestion
made by Karthik Bhargavan a= bout how to prevent protection against
downgrade against downgrad= e from TLS 1.3 to TLS 1.2 and below.


The ide= a is that if a TLS 1.3 server receives a TLS 1.2 or below
ClientH= ello, it sets the top N bits of the ServerRandom to be a
specific= fixed value.

1. Why would the = server ever receive a TLS 1.2 or below ClientHello from a client that suppo= rts TLS 1.3? Why doesn't the already-standardized downgrade SCSV mechan= ism work for those cases?

2. My understanding is t= hat every TLS 1.3 ClientHello contains a ClientKeyShare extension and that = no TLS 1.2 or below ClientHello contains a ClientKeyShare extension. Theref= ore, the presence or absence of the ClientKeyShare extension already signal= s whether the client is attempting a TLS 1.3 handshake, or a handshake for = a lower TLS version. Thus, also specifying ClientHello.client_version =3D 0= x0304 is redundant. And, we've already seen clear evidence that ClientH= ello.client_version =3D 0x0304 leads to severe compatibility issues. So, wh= y not just use ClientHello.client_version =3D 0x0303 and rely on the presen= ce of the ClientKeyShare extension to disambiguate TLS 1.3 vs TLS 1.2 or be= low?

Cheers,
Brian
--047d7b2e438660fad20521b3ac69-- From nobody Fri Oct 9 18:01:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4BE1B2EBE for ; Fri, 9 Oct 2015 18:01:54 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPJToJSVmEBd for ; Fri, 9 Oct 2015 18:01:52 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c: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 0C9151B2EC6 for ; Fri, 9 Oct 2015 18:01:51 -0700 (PDT) Received: by wicge5 with SMTP id ge5so88845412wic.0 for ; Fri, 09 Oct 2015 18:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IvrHfv5m9QtOvHBCYvpO/em4zgTRFYle8WOhhJxL7FI=; b=s6xiKNEIGkWD7RtUix9evcnRYaUlOSk5QV9m51j5O/jHqkUzIIBh8pwQnQXPuC/jVQ OSXYPi9QBXhv/pCNaGfcAVLUbgDTaRhHNgfvaM4WQHxZ6GNDMHSV6aYnP4GtBVzp8CT6 8IWIVUDLxmGTFFKGRqlzZ7hbBEYgBOXSztse/xSfpM8V6i7oV8xVAgZ4ROrnfgpTTbs5 LFcKzT4n6qLZ1FduAXDoHEDjs5rOXJb4rzncdONlknNPCP5Vb2C83zbdeA9L3Wnd94Pt fMMSBSvm8awCfAickf/4lk0N1SdVE9jzJgEPp80vVjDWGqQw7hB3pIvIHhu6SUGL90KW WW7g== X-Received: by 10.194.82.198 with SMTP id k6mr17330899wjy.139.1444438910581; Fri, 09 Oct 2015 18:01:50 -0700 (PDT) Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id ly4sm5050932wjb.4.2015.10.09.18.01.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Oct 2015 18:01:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Sat, 10 Oct 2015 03:01:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Smith X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 01:01:54 -0000 > 1. Why would the server ever receive a TLS 1.2 or below ClientHello = from a client that supports TLS 1.3? Why doesn't the = already-standardized downgrade SCSV mechanism work for those cases? The attack we=E2=80=99re protecting against is the following: - a TLS 1.3 client sends a client hello and the MitM changes the version = field to TLS 1.0 (say) with some weak signature-based ciphersuite (e.g. = DHE/DHE-EXPORT + AES-CBC) - for good measure, the MitM also drops any protocol extensions that are = inconvenient (e.g. FFDHE/extended master secret/=E2=80=A6) - the TLS 1.3 server thinks the client does not support TLS 1.3 and so = falls back to the requested protocol - in TLS 1.0, the server signature does not include the version, = ciphersuite, or extensions, so the client accepts the server flight and = computes a master secret and finished message Now, the crucial step is that if the downgraded protocol is so weak that = the attacker can (with some computational effort) forge the server=E2=80=99= s finished message, the connection will complete. There are some instances in which the attacker may be able to achieve = this: by breaking SHA-1, or a weak DHE group, by redoing some variation = of the triple handshake attack, or by=20 exploiting some software bug in a rarely used low-preference = ciphersuite. Note that the client did not fallback, the server did, so = Fallback SCSV does not apply. The key observation is that downgrade protection in TLS 1.2 (and below) = relies on the Finished MAC, but the elements that go into computing this = MAC (DH group, hash algorithm) are themselves negotiated within the handshake and may be downgraded. = This is a fundamental protocol limitation that is addressed by TLS 1.3. = Now, our goal is to protect TLS 1.3 itself from older protocol versions. =46rom an academic researcher=E2=80=99s viewpoint, there are two reasons = to suggest such a countermeasure.=20 1) Historically, signalling the ciphersuite in the server signature = would have prevented high-profile attacks like FREAK, Logjam, and the = cross-protocol attack between ECDHE/DHE in 2012. I agree that trying to protect from potential attacks may seem = speculative, but the idea is to provide some additional protection = against future attacks even if all TLS clients and servers are not = immediately patched. 2) Looking forward, a number of researchers would like to give a strong = security theorem for TLS 1.3, but at present we would not be able to = guarantee security for any TLS 1.3 implementation=20 that also implements older protocol versions, because we would then = also have to prove secure all the ciphersuites used in these old = versions (some of which are certainly broken from the point of view of provable security). For our proofs, we=E2=80=99d = like nothing better than to be able to assume that older versions of TLS = have been disabled, but I guess that is unlikely to happen soon. It would have been nice not to rely on a =E2=80=9Cclever=E2=80=9D trick, = but we could not see how else to add any mechanism that could itself not = be deleted by an attacker in older versions.=20 TLS has a long history of signalling downgrades in strange ways. The = RSA PMS still includes the protocol version due to an old SSL3->SSL2 = downgrade attack.=20 The Fallback SCSV is a signal encoded in a bogus ciphersuite, because = SSL3 does not support extensions.=20 These are all unfortunate hacks, made necessary by the limited handshake = protections in older versions. The chief benefit is that we can then protect clients and servers that = implement our brand new protocol version. Best, Karthik >=20 > Cheers, > Brian > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Oct 9 19:45:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E8D1B5356 for ; Fri, 9 Oct 2015 19:44:59 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yybi2NtOoNrE for ; Fri, 9 Oct 2015 19:44:58 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 281DA1B5352 for ; Fri, 9 Oct 2015 19:44:58 -0700 (PDT) Received: by qgew37 with SMTP id w37so25537819qge.0 for ; Fri, 09 Oct 2015 19:44:57 -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-type:content-transfer-encoding:message-id; bh=lRKmMMBd33PoYWe9zNENIakh5PQdxdnYi1JkudS9KEM=; b=d/4BY0Bl7tH8JhtvtqZj2oasHDGARTbUDzaN+DYbuj8jYO1ltcH/sgfSQulHwfFPV8 x5c01Bta2OJ9JHzmG6GtPMz073BP+jxdutCqJEfsgCgdbuJk3PdpWAYSRkOWNVTcoBp1 8QtYJ4MSSQwOpb470UcsywEC46NEhUAKLnQJqDAfjBbI5omCBMGXV2Xcy+02GC5nBRcH tp2UbDqrbnXMhZMRd8tGTeFAeSFE6Fhr7JBr7WItwAMOcMFswUjR+KA47nb4lm9pnOyL yDomycmsiIywzfo/1ckv0RZfYLwl/Xc38M0fNX/xXPN3j5VRN0pZWCanEmb3moPQrL4e xjrg== X-Received: by 10.140.235.216 with SMTP id g207mr19990799qhc.98.1444445097375; Fri, 09 Oct 2015 19:44:57 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 89sm2017191qgf.43.2015.10.09.19.44.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 09 Oct 2015 19:44:56 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 9 Oct 2015 22:44:55 -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: <201510092244.55467.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 02:44:59 -0000 There is one problem with the current proposed sentinel value, 0x030403040304. It limits what can be done with future versions. It's not as simple as just making that use 0x030503050305, because we want 1.3 clients to be able to recognize sentinel values from all future versions, not just this one. Thus, for future proofing, (just) using the version number isn't a great idea. It's probably safest to just pick one static value and be done with it forever. And now, for my proposed bikeshed color: 0x0b501e7e5e1ec7ed ("obsoleteselected"; 64-bit value) I'd like to say I was clever enough to come up with neat hex words, but I Googled for a list and found 2 to put together. ;) Dave From nobody Sat Oct 10 07:31:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E24F1B3C52 for ; Sat, 10 Oct 2015 07:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foo0qz45ehGt for ; Sat, 10 Oct 2015 07:31:38 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 6FBD71B3C4F for ; Sat, 10 Oct 2015 07:31:38 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so101595146wic.1 for ; Sat, 10 Oct 2015 07:31:37 -0700 (PDT) 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-type; bh=sMr6yEikvI2OgDHv4p/xc7EQ3FPBOO5w4AJzAi0lYeo=; b=DcG197aClH1Mnm0ybizyF/piMsyAclAyk3dF0QALZbaSO64CZ7iF5X8y6+B4bK6sUT U5odHLYqCNMAeeHHr8s2tSt2gxCTVTf64XOE52fCjr4psp53HhhaqKGC8XKZqgHOSR5u GR2o14/mk7P92LX8EDwl5SewOwnFWu7VKMA16EfF5YXl4c8DamI/f1aVJkj7PDR5nGfF rUfN5cOovKDANFR10h4mEfwCyQmRuJhmt7VxY580JqjEF+edurG6f2SPf/4hlt6vZmyk Bbwjz9bz6MEG5tDS9QIIl6Hp3PwfUrcJZbk/10PksAE2zzhjOqYJy9x9Dw7W8NGmPtl2 KKTg== X-Gm-Message-State: ALoCoQkPxhiWfH21JwG3AN7pdyAS3Nll8uX1pzwovwr3TCg3ApoRu9FAKJbkYPMagkejBtyKcQcY X-Received: by 10.194.48.81 with SMTP id j17mr19949374wjn.81.1444487497017; Sat, 10 Oct 2015 07:31:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Sat, 10 Oct 2015 07:30:57 -0700 (PDT) In-Reply-To: <201510092244.55467.davemgarrett@gmail.com> References: <201510092244.55467.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 10 Oct 2015 16:30:57 +0200 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b86c1902482e50521c0f4cf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 14:31:40 -0000 --047d7b86c1902482e50521c0f4cf Content-Type: text/plain; charset=UTF-8 On Sat, Oct 10, 2015 at 4:44 AM, Dave Garrett wrote: > There is one problem with the current proposed sentinel value, > 0x030403040304. It limits what can be done with future versions. It's not > as simple as just making that use 0x030503050305, because we want 1.3 > clients to be able to recognize sentinel values from all future versions, > not just this one. Thus, for future proofing, (just) using the version > number isn't a great idea. It's probably safest to just pick one static > value and be done with it forever. > That may be true, but then this value is as good as any other. An alternative would be to burn N-8 bits on a sentinel and then 8 bits on the version number. E.g., 01 02 03 04 05 34 [0] BTW, I'm basically indifferent between 48 and 64 bits. -Ekr [0] I didn't use 00 00 00 00 00 as the sentinel because I have some vague memory that there are implementations which use 0s in the timestamp. And now, for my proposed bikeshed color: > > 0x0b501e7e5e1ec7ed > ("obsoleteselected"; 64-bit value) > > I'd like to say I was clever enough to come up with neat hex words, but I > Googled for a list and found 2 to put together. ;) > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b86c1902482e50521c0f4cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 10, 2015 at 4:44 AM, Dave Garrett <davemgarrett@gmail= .com> wrote:
There is one p= roblem with the current proposed sentinel value, 0x030403040304. It limits = what can be done with future versions. It's not as simple as just makin= g that use 0x030503050305, because we want 1.3 clients to be able to recogn= ize sentinel values from all future versions, not just this one. Thus, for = future proofing, (just) using the version number isn't a great idea. It= 's probably safest to just pick one static value and be done with it fo= rever.

That may be true, but then this = value is as good as any other.

An alternative woul= d be to burn N-8 bits on a sentinel and then
8 bits on the versio= n number. E.g.,

01 02 03 04 05 34 =C2=A0[0]
<= div>
BTW, I'm basically indifferent between 48 and 64 bit= s.

-Ekr

[0] I did= n't use 00 00 00 00 00 as the sentinel because I have some vague memory=
that there are implementations which use 0s in the timestamp.

And now, for my proposed bikeshed color:

0x0b501e7e5e1ec7ed
("obsoleteselected"; 64-bit value)

I'd like to say I was clever enough to come up with neat hex words, but= I Googled for a list and found 2 to put together. ;)


Dave

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

--047d7b86c1902482e50521c0f4cf-- From nobody Sat Oct 10 10:37:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8821B4294 for ; Sat, 10 Oct 2015 10:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xflnY8ws3AvF for ; Sat, 10 Oct 2015 10:37: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 B968A1B4282 for ; Sat, 10 Oct 2015 10:37:31 -0700 (PDT) Received: by qkht68 with SMTP id t68so44798299qkh.3 for ; Sat, 10 Oct 2015 10:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=0W/7qjfin+VeVON1bE24J+0kcdzh1F2GKEeV9dorIg0=; b=A6TqsbxnCchGRSITDe3MaQK7PGxj6xv5JG45H6W7P2INEiOjqrAR2677JltWZjJPbC WM4sj8KzyVoN+cSj9+E4GYJfoBQRHt/GT9Hqe6/1/+DgkHY5D7pegdVs5zOz+uBVlY7N ZHCy6qeIIYeYrz+tPIZW6SjoJuHKblH+ISMAGLSdscohEOB10qqOAT7K0zBgHJFzK4dO bLJPpIWDv67rlQoY4ocjJnsr3OtvUi7pAF68FythbDPyo/IzsFn7frVf/Eux2rGA3PW9 +cPWU+yabHpT/P1VoJiQj2OBPsA+aaev4ThHKPVBRmcF1jHJk+6p/f2vgNxPQjiYLvOZ MLTA== X-Received: by 10.55.41.165 with SMTP id p37mr22374782qkp.73.1444498650863; Sat, 10 Oct 2015 10:37:30 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id h10sm3318293qgf.29.2015.10.10.10.37.30 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 10 Oct 2015 10:37:30 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 10 Oct 2015 13:37:28 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201510101337.29335.davemgarrett@gmail.com> Archived-At: Subject: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 17:37:33 -0000 In light of completely unsurprising recent events [0], I think it's time to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3. Currently, it's allowed if needed by servers that have nothing better [1]. I propose we stop playing around and just prohibit it under TLS 1.3+. Implementations that can negotiate nothing better would be permitted to fall back to TLS 1.2 with the security restrictions currently in the draft [2] (which is still a concession I'd rather not make, but it's currently needed). I have submitted a PR [3] to this effect in order to have specific text to discuss here, though WG consensus and chair approval is of course required to change the current status. Please note that TLS 1.3 is not coming out tomorrow, nor will its deployment be instant. By the time servers even decide to consider an upgrade, SHA-1 will be in an even less secure state than it already is. To answer the obvious question: Prohibiting it in new versions reduces the risk of mistakes, draws a clear line where support is killed, and puts an actual impetus on PKI to transition faster. TLS 1.2 is potentially vulnerable, depending on configuration (nothing new there), but TLS 1.3 should be known to be secure in all valid configurations. The discussion to have with non-experts should not be about specific algorithms to pick and choose (RC4, MD5, SHA1, EXPORT ciphers, non-AEAD, non-PFS, weak DH groups, etc. etc.); we should be able to point at the current version and say "use this, not the old thing", or we can't expect it to be understood and taken seriously. [0] https://sites.google.com/site/itstheshappening/ [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60 [2] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#appendix-C.3 [3] https://github.com/tlswg/tls13-spec/pull/287 Dave From nobody Sat Oct 10 10:44:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23921B42D1 for ; Sat, 10 Oct 2015 10:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_Yark5rMQ0Z for ; Sat, 10 Oct 2015 10:44:45 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 14A451B42D0 for ; Sat, 10 Oct 2015 10:44:45 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so103941293wic.1 for ; Sat, 10 Oct 2015 10:44:43 -0700 (PDT) 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-type; bh=zMQVXoG75Bq+UrMQiU4WjdF7yMUl4OHo0cxGq4OfTnE=; b=YTvG12+TkclbXe+b7Y41eRO2Mpl3HAMayHhJRaMU9i1xDKUigTNJFx447u3zN9wb8A Wgb+7IBn47xgCZpsf6wU9EI5KoeviD/xlJdCiFLb7H4Uxja2pO71t1HcJpF+wqtf3oCf O1HLZby44FZBUmwg1QHOcctiFdLM+z0G1Ba/5EfL7NuVi+JLpSGH2FPbbrwZPTXLSfub oTpch4UojLjy3xI7naDjlKHmA2mEThFTEMhJBppKUP4qLPIhBO260fxRRC9bO7z18WeU UdjQn7pWO5N9dnORVHzZWUCmw1UdrCbMJO9nidyMMljRNUwXL15VwoM/Sx2JxPBHcdpO LOhA== X-Gm-Message-State: ALoCoQltINb/AfQQmZ8a/+5kacg4q5LIJs/JCdINSS0XAl93dHPy7DadZJf2JtqSbotkTKYm2xBC X-Received: by 10.194.94.71 with SMTP id da7mr21162652wjb.8.1444499083697; Sat, 10 Oct 2015 10:44:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Sat, 10 Oct 2015 10:44:04 -0700 (PDT) In-Reply-To: <201510101337.29335.davemgarrett@gmail.com> References: <201510101337.29335.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 10 Oct 2015 19:44:04 +0200 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7bf0c102c33dcb0521c3a602 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 17:44:47 -0000 --047d7bf0c102c33dcb0521c3a602 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett wrote: > In light of completely unsurprising recent events [0], I think it's time > to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3. > Currently, it's allowed if needed by servers that have nothing better [1]. To be clear, the only thing that's allowed is SHA-1 in *certificates*. It's forbidden in CertificateVerify. -Ekr > I propose we stop playing around and just prohibit it under TLS 1.3+. > Implementations that can negotiate nothing better would be permitted to > fall back to TLS 1.2 with the security restrictions currently in the draft > [2] (which is still a concession I'd rather not make, but it's currently > needed). I have submitted a PR [3] to this effect in order to have specific > text to discuss here, though WG consensus and chair approval is of course > required to change the current status. > > Please note that TLS 1.3 is not coming out tomorrow, nor will its > deployment be instant. By the time servers even decide to consider an > upgrade, SHA-1 will be in an even less secure state than it already is. > > To answer the obvious question: Prohibiting it in new versions reduces the > risk of mistakes, draws a clear line where support is killed, and puts an > actual impetus on PKI to transition faster. TLS 1.2 is potentially > vulnerable, depending on configuration (nothing new there), but TLS 1.3 > should be known to be secure in all valid configurations. The discussion to > have with non-experts should not be about specific algorithms to pick and > choose (RC4, MD5, SHA1, EXPORT ciphers, non-AEAD, non-PFS, weak DH groups, > etc. etc.); we should be able to point at the current version and say "use > this, not the old thing", or we can't expect it to be understood and taken > seriously. > > [0] https://sites.google.com/site/itstheshappening/ > [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60 > [2] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#appendix-C.3 > [3] https://github.com/tlswg/tls13-spec/pull/287 > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bf0c102c33dcb0521c3a602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Oct 10, 2015 at 7:37 PM, Dave Garrett <davemgarrett@gmail.com= > wrote:
In light of completely= unsurprising recent events [0], I think it's time to reconsider the cu= rrent consensus on how to deal with SHA-1 in TLS 1.3. Currently, it's a= llowed if needed by servers that have nothing better [1].

To be clear, the only thing that's allowed is SHA-1 in = *certificates*.
It's forbidden in CertificateVerify.

-Ekr
=C2=A0
= I propose we stop playing around and just prohibit it under TLS 1.3+. Imple= mentations that can negotiate nothing better would be permitted to fall bac= k to TLS 1.2 with the security restrictions currently in the draft [2] (whi= ch is still a concession I'd rather not make, but it's currently ne= eded). I have submitted a PR [3] to this effect in order to have specific t= ext to discuss here, though WG consensus and chair approval is of course re= quired to change the current status.

Please note that TLS 1.3 is not coming out tomorrow, nor will its deploymen= t be instant. By the time servers even decide to consider an upgrade, SHA-1= will be in an even less secure state than it already is.

To answer the obvious question: Prohibiting it in new versions reduces the = risk of mistakes, draws a clear line where support is killed, and puts an a= ctual impetus on PKI to transition faster. TLS 1.2 is potentially vulnerabl= e, depending on configuration (nothing new there), but TLS 1.3 should be kn= own to be secure in all valid configurations. The discussion to have with n= on-experts should not be about specific algorithms to pick and choose (RC4,= MD5, SHA1, EXPORT ciphers, non-AEAD, non-PFS, weak DH groups, etc. etc.); = we should be able to point at the current version and say "use this, n= ot the old thing", or we can't expect it to be understood and take= n seriously.

[0] https://sites.google.com/site/itstheshappening/
[1] https://tools.ietf.org/html/draft-iet= f-tls-tls13-09#page-60
[2] https://tools.ietf.org/html/draf= t-ietf-tls-tls13-09#appendix-C.3
[3] https://github.com/tlswg/tls13-spec/pull/287


Dave

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

--047d7bf0c102c33dcb0521c3a602-- From nobody Sat Oct 10 13:28:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2371B4797 for ; Sat, 10 Oct 2015 13:28:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYScIA7LrOyl for ; Sat, 10 Oct 2015 13:28:35 -0700 (PDT) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 315111B4794 for ; Sat, 10 Oct 2015 13:28:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 1B8BF21BAF5; Sat, 10 Oct 2015 23:28:34 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id k6Xc2dcFPQuF; Sat, 10 Oct 2015 23:28:33 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id EA3525BC011; Sat, 10 Oct 2015 23:28:33 +0300 (EEST) Date: Sat, 10 Oct 2015 23:28:28 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151010202828.GA25875@LK-Perkele-V2.elisa-laajakaista.fi> References: <201510101337.29335.davemgarrett@gmail.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] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 20:28:36 -0000 On Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote: > On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett > wrote: > > > In light of completely unsurprising recent events [0], I think it's time > > to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3. > > Currently, it's allowed if needed by servers that have nothing better [1]. > > To be clear, the only thing that's allowed is SHA-1 in *certificates*. > It's forbidden in CertificateVerify. Isn't using it in certificates precisely more dangeous than using it in CertificateVerify (especially with TLS 1.3)? (Not that using it in CertificateVerify is a good idea). Also, AFAIK, TLS 1.3 won't be published this year, so by the time it is published, one can't get SHA-1 certs from public CAs anyway (or if you can, those don't work reliably anyway). -Ilari From nobody Sat Oct 10 13:59:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CF71A6EDA for ; Sat, 10 Oct 2015 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQWgeg5ml28k for ; Sat, 10 Oct 2015 13:59:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81AF51A1BDD for ; Sat, 10 Oct 2015 13:59:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 11ED0284B56; Sat, 10 Oct 2015 20:59:09 +0000 (UTC) Date: Sat, 10 Oct 2015 20:59:09 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151010205908.GW15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <20151010202828.GA25875@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151010202828.GA25875@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 10 Oct 2015 20:59:12 -0000 On Sat, Oct 10, 2015 at 11:28:28PM +0300, Ilari Liusvaara wrote: > > To be clear, the only thing that's allowed is SHA-1 in *certificates*. > > It's forbidden in CertificateVerify. > > Isn't using it in certificates precisely more dangeous than using it in > CertificateVerify (especially with TLS 1.3)? So long as SHA-1 self-signatures are still tolerated in root or self-signed end-entity certificates, I have no objection to TLS 1.3 specifying that a certificate signed with SHA-1 is not trusted even when issued by a trusted issuer. However, we *must* be careful about what obligations we impose on a client or server that encounters a certificate chain in which some certificate which is not self-signed uses a SHA-1 signature. It would be a big mistake to mandate fatal or even warning alerts or closing the connection. Rather, the required outcome is that the chain is simply not trusted. Whether *that* in turn leads to a connection termination depends on whether verification is required. Opportunistic clients, or servers that solicit optional client certificates need to be able to continue despite the untrusted chain, and do what they do in the absence of a peer certificate or when the peer certificate has accceptable signatures, and and yet is still untrusted (or peername does not match, ...). So if the draft language for 1.3 essentially only prohibits *trusting* SHA-1, but does not prohibit the *presence* of SHA-1 in the peer's chain, I think that should be fine. I don't want to see client's or servers hanging up just because a peer presents a SHA-1 chain that would have been simply ignored had it been SHA2-256 instead. -- Viktor. From nobody Sat Oct 10 14:03:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AC51A914E for ; Sat, 10 Oct 2015 14:03: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJNfu3NJGl5v for ; Sat, 10 Oct 2015 14:02:57 -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 B3F7F1A914B for ; Sat, 10 Oct 2015 14:02:57 -0700 (PDT) Received: by qkht68 with SMTP id t68so45826386qkh.3 for ; Sat, 10 Oct 2015 14:02:56 -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-type:content-transfer-encoding:message-id; bh=Juz6qeviSHuAbDRceGCJgCHsaVcKsCUGCpP5+e5AjP8=; b=ec4X861nf+2u38f7NFAgPQmfohOmsUEULBodb3b0W6zhGSSaJu6gXR6f+6uZdiWDcV Xxf/i/YV9GFd7SbFS8i/QZBgx+cUTVS5PWJ7vHYP0TGNAV6NSx6a7e9CGNGY9vMHgjvZ usIjJa0KDiQWNwTMMXcAyXwbx8xxPLHca+/M0h2dQyY0zVgruRbXf0B18y3DIOP/Si5J 3W0gi47mOf6j9WG1ex68piS6nTzywwUSRyT++0d6QMe4d8OgputhIHCh2wya4ULgOQZF +mMO0oMHL/GSsjNw71QOiGK10RMRCyF09IokXsju1E9CJiIc3RTyRGgecJ+jfqn2FPR9 i+8g== X-Received: by 10.55.20.2 with SMTP id e2mr23612880qkh.27.1444510976901; Sat, 10 Oct 2015 14:02:56 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id i199sm3620118qhc.44.2015.10.10.14.02.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 10 Oct 2015 14:02:56 -0700 (PDT) From: Dave Garrett To: Ilari Liusvaara Date: Sat, 10 Oct 2015 17:02:54 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <20151010202828.GA25875@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20151010202828.GA25875@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201510101702.55314.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 21:03:01 -0000 On Saturday, October 10, 2015 04:28:28 pm Ilari Liusvaara wrote: > On Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote: > > To be clear, the only thing that's allowed is SHA-1 in *certificates*. > > It's forbidden in CertificateVerify. > > Isn't using it in certificates precisely more dangeous than using it in > CertificateVerify (especially with TLS 1.3)? > > (Not that using it in CertificateVerify is a good idea). You can take all the time you need to forge something in a certificate chain (before expiry time), but to forge CertificateVerify you'd need to do it on the fly. Really dangerous vs. somewhat dangerous doesn't matter much here, though. Dave From nobody Sat Oct 10 14:10:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5061AC3A2 for ; Sat, 10 Oct 2015 14:10:47 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8IkftxF9gtv for ; Sat, 10 Oct 2015 14:10:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10931AC3A1 for ; Sat, 10 Oct 2015 14:10:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 38683284B56; Sat, 10 Oct 2015 21:10:46 +0000 (UTC) Date: Sat, 10 Oct 2015 21:10:46 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151010211045.GX15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <20151010202828.GA25875@LK-Perkele-V2.elisa-laajakaista.fi> <20151010205908.GW15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151010205908.GW15070@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 10 Oct 2015 21:10:48 -0000 On Sat, Oct 10, 2015 at 08:59:08PM +0000, Viktor Dukhovni wrote: > I don't want to see client's or servers hanging up just because a > peer presents a SHA-1 chain that would have been simply ignored > had it been SHA2-256 instead. In particular pull request 287 breaks opportunistic TLS and *must* not be adopted as-is. It needs to allow SHA-1 chains to be sent when that's all that's available. The onus to not trust such chains is on the peer. Some peers may continue with the handshake despite the untrusted chain. They may, for example, have pinned the leaf certificate and not give a hoot about any of the signatures. -- Viktor. From nobody Sat Oct 10 14:12:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F961AC3C2 for ; Sat, 10 Oct 2015 14:12: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kff0_yMevn1E for ; Sat, 10 Oct 2015 14:11:59 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 E8E871AC3BE for ; Sat, 10 Oct 2015 14:11:58 -0700 (PDT) Received: by qgx61 with SMTP id 61so95291531qgx.3 for ; Sat, 10 Oct 2015 14:11:58 -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-type:content-transfer-encoding:message-id; bh=HsAdaf5p5+oRmXf3R/r4FZeoiIMQf15I7otdEwef1gI=; b=xy4tdov/Fk2ZCcKmpjXI0xBecdby+ooq0UAsnQlKLoL/fg68r5XZ2uXJUA9qH5GZ0G Aa69gGhhLW0zp+ldBOONhU+wYGEGC4pTGpwvLlZeMYECh5VtSROUd4dPxx+n2h2lJ+QY EZWFE7l0UXDasbCSrX+hM/eNxMO5AE441S3+MYlwQApL51eeh2LkKIbuXI7zSn53dC96 6Z3zgIQexYLVNZDxBr/DNFSYwOMV7hlxkZ96uhcaJtzAiE+pX3LLdaj9guUc1/V3RuN/ ZxW5ExXQEqi6lZ629TOqChChsXgNk5TWemfzanW+gf7JkvllUPKg9LsKXHWimOBdGtaX piGg== X-Received: by 10.140.152.85 with SMTP id 82mr25477732qhy.8.1444511518015; Sat, 10 Oct 2015 14:11:58 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 28sm3686913qkw.12.2015.10.10.14.11.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 10 Oct 2015 14:11:57 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 10 Oct 2015 17:11:56 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <20151010202828.GA25875@LK-Perkele-V2.elisa-laajakaista.fi> <20151010205908.GW15070@mournblade.imrryr.org> In-Reply-To: <20151010205908.GW15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510101711.56639.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 21:12:00 -0000 On Saturday, October 10, 2015 04:59:09 pm Viktor Dukhovni wrote: > So long as SHA-1 self-signatures are still tolerated in root or > self-signed end-entity certificates, I have no objection to TLS > 1.3 specifying that a certificate signed with SHA-1 is not trusted > even when issued by a trusted issuer. > > However, we *must* be careful about what obligations we impose on > a client or server that encounters a certificate chain in which > some certificate which is not self-signed uses a SHA-1 signature. > It would be a big mistake to mandate fatal or even warning alerts > or closing the connection. Rather, the required outcome is that > the chain is simply not trusted. > > Whether *that* in turn leads to a connection termination depends > on whether verification is required. Opportunistic clients, or > servers that solicit optional client certificates need to be able > to continue despite the untrusted chain, and do what they do in > the absence of a peer certificate or when the peer certificate has > accceptable signatures, and and yet is still untrusted (or peername > does not match, ...). > > So if the draft language for 1.3 essentially only prohibits *trusting* > SHA-1, but does not prohibit the *presence* of SHA-1 in the peer's > chain, I think that should be fine. > > I don't want to see client's or servers hanging up just because a > peer presents a SHA-1 chain that would have been simply ignored > had it been SHA2-256 instead. Yes, to all points above. I feel like self-signed certs should have to use SHA-256 too, but mandating that doesn't get us that much. The current PR is a bit too general; will need revision to handle all cases. I'll of course change it to accommodate concerns that come up in discussion here. Note that opportunistic encryption is weird and getting the whole document to be perfect for it might not be entirely doable, as OE needs to tolerate more fuzziness than the main spec should allow. Dave From nobody Sat Oct 10 14:19:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A951ACAD5 for ; Sat, 10 Oct 2015 14:19:32 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNEHC3BloIa6 for ; Sat, 10 Oct 2015 14:19:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1EF1ACAD4 for ; Sat, 10 Oct 2015 14:19:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 10378284B56; Sat, 10 Oct 2015 21:19:30 +0000 (UTC) Date: Sat, 10 Oct 2015 21:19:30 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151010211929.GY15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <20151010202828.GA25875@LK-Perkele-V2.elisa-laajakaista.fi> <20151010205908.GW15070@mournblade.imrryr.org> <201510101711.56639.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510101711.56639.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 10 Oct 2015 21:19:33 -0000 On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote: > Note that opportunistic encryption is weird and getting > the whole document to be perfect for it might not be entirely doable, as > OE needs to tolerate more fuzziness than the main spec should allow. Unfortunately requirements in the base TLS document end up "set in stone" in software implementations, and then break opportunistic TLS in ways application software can't work around. So while the UTA TLS BCP can write requirements that exclude opportunistic security, the TLS specification does not have that liberty. In this case the solution is simple enough. DO NOT prohibit the exchange of certificate chains with SHA-1 in them. Just prohibit *trusting* their content. We alredy have language to allow servers and client to send "last-resort" chains that don't match the peer's advertised supported algorithms. This suffices. The necessary changes are then MUCH simpler than the current pull request 287. * Prohibit advertising SHA-1 in the supported algorithms list, (except as needed for TLS 1.2 compat, ...) * Prohibit trusting SHA-1 when found in certificates that are not self-signed. That's it. A lot less work. SHA-1 is no longer trusted, but does not impede interoperability when certificates are largely useless baggage. -- Viktor. From nobody Sat Oct 10 15:46:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B071E1B4A75 for ; Sat, 10 Oct 2015 15:46:51 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5_Uz7LEnBFq for ; Sat, 10 Oct 2015 15:46:50 -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 686441B4A73 for ; Sat, 10 Oct 2015 15:46:50 -0700 (PDT) Received: by qkas79 with SMTP id s79so46299436qka.0 for ; Sat, 10 Oct 2015 15:46:49 -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-type:content-transfer-encoding:message-id; bh=PwLoxhMWpK5nJLfsgZFOJPDvR1k4IQILA5JImBvLCxs=; b=kSVxRQlrahxO8OpEoDp4KCf5OqexDsh7jloiMEn8N1D7EYLvzfjmyqW5zYLhFVfx5l m5K037O5EakcAGvGpaO0L58Z5JsA+/qG6GwnxVjalAwGv41mUA9EK7B9fYPWH2vtonrH 2i9fU4XikkFbYx5A+GnDgLE5bKkBEseL8NyysDgUVonal3isVcvcjVH5u/kKbA3ljYlQ ks+7Msop1kUpIeCnDCUWoVsVm5C1ix9GCyUOJzbVuPw3wkroVIu0q/Y+HeoCKHAdTXmK mpBN9V6PdDxfL6wdFQ4fRCvR+bQouJmctDXWd8E/PFyrlVPHqGqSxPIUSfuIifxjRO14 xEzQ== X-Received: by 10.55.195.147 with SMTP id r19mr23345640qkl.12.1444517209592; Sat, 10 Oct 2015 15:46:49 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id e131sm3808428qhc.10.2015.10.10.15.46.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 10 Oct 2015 15:46:49 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Viktor Dukhovni Date: Sat, 10 Oct 2015 18:46:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <201510101711.56639.davemgarrett@gmail.com> <20151010211929.GY15070@mournblade.imrryr.org> In-Reply-To: <20151010211929.GY15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510101846.47847.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2015 22:46:51 -0000 On Saturday, October 10, 2015 05:19:30 pm Viktor Dukhovni wrote: > On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote: > > Note that opportunistic encryption is weird and getting > > the whole document to be perfect for it might not be entirely doable, as > > OE needs to tolerate more fuzziness than the main spec should allow. > > Unfortunately requirements in the base TLS document end up "set in > stone" in software implementations, and then break opportunistic > TLS in ways application software can't work around. I do agree with rewording the text in question to deal with this better, but honestly, OE & AE are directly opposed concepts. I'd much rather write almost everything assuming the goal is properly authenticated encryption, and have a separate section dedicated to opportunistic encryption stating that its implementation requires ignoring many of the hard requirements TLS has with regard to authentication. Trying to subtlety allow for AE & OE in all the same text might give us a more fragile specification where accidentally screwing up authentication is easier. OE can be useful, but it's the exception, not the rule; giving AE too much wiggle-room could be dangerous. (when it's explicitly requested, e.g. TOFU with raw public keys, that's a different discussion) Dave From nobody Sat Oct 10 19:35:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07471ACD4F for ; Sat, 10 Oct 2015 19:35:18 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYgj7uPY3b6j for ; Sat, 10 Oct 2015 19:35:17 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6657E1ACD4C for ; Sat, 10 Oct 2015 19:35:17 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 22EFF284B56; Sun, 11 Oct 2015 02:35:16 +0000 (UTC) Date: Sun, 11 Oct 2015 02:35:16 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151011023515.GZ15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <201510101711.56639.davemgarrett@gmail.com> <20151010211929.GY15070@mournblade.imrryr.org> <201510101846.47847.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510101846.47847.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 11 Oct 2015 02:35:19 -0000 On Sat, Oct 10, 2015 at 06:46:47PM -0400, Dave Garrett wrote: > > Unfortunately requirements in the base TLS document end up "set in > > stone" in software implementations, and then break opportunistic > > TLS in ways application software can't work around. > > I do agree with rewording the text in question to deal with this better, > but honestly, OE & AE are directly opposed concepts. I'd much rather write > almost everything assuming the goal is properly authenticated encryption, > and have a separate section dedicated to opportunistic encryption stating > that its implementation requires ignoring many of the hard requirements > TLS has with regard to authentication. Sorry that works for the UTA BCP, but *cannot* work the TLS protocol specification. The TLS protocol cannot and SHOULD NOT make any assumption about the client's security model, which can be: * PKIX with Web PKI public CAs * DANE-TA(2) with private CAs trusted via DNS * DANE-EE(3) (if you like server-side pinning via DNS). * RFC7250 bare public keys with DANE "3 1 1" bindings. * RFC7250 bare public keys with some other out-of-band keying * Trust on first use with leaf certificate pinning. * GSSAPI with channel binding * Unauthenticated opportunistic TLS. * ... It is not appropriate for this WG to be narrowly focused on just the first security model, which is certainly important, but not to the exclusion of the rest. > Trying to subtlety allow for AE & > OE in all the same text might give us a more fragile specification where > accidentally screwing up authentication is easier. OE can be useful, but > it's the exception, not the rule; giving AE too much wiggle-room could be > dangerous. (when it's explicitly requested, e.g. TOFU with raw public > keys, that's a different discussion) There is no subtlety getting in the way of not deprecating trust in SHA-1, with a tiny bit of care it can be done generally without breaking any of the use cases. If the base protocol is bifurcated into many different use-cases, implementations won't handle all the cases correctly. This is not difficult, it just requires not forgetting that there's more than one way to do (or not do) authentication, and that the TLS protocol needs to remain largely agnostic of the authentication model. Just deliver the available credentials to the peer, and let the peer decide what to do. -- Viktor. From nobody Sat Oct 10 20:00:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BBF1ACDD0 for ; Sat, 10 Oct 2015 20:00:35 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq6TavXCk6Zp for ; Sat, 10 Oct 2015 20:00:34 -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 1E22D1ACDCC for ; Sat, 10 Oct 2015 20:00:34 -0700 (PDT) Received: by qkap81 with SMTP id p81so47536521qka.2 for ; Sat, 10 Oct 2015 20:00:32 -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-type:content-transfer-encoding:message-id; bh=OdB37yWFEblzDJTcbh2ucOhhgvhhwDPHAqLaiGDrfkw=; b=DJ7mkXD4Hiym3SeiZJ3d7QVxzFhRe1q49g5a4ut+KvfKw7MQjizEyW8SJ49EGos6vL PHKz2i3ndZ2/hS6QCSc9f2iJrs+QF9sURQnzYKgXxJ7HhHNRFk/KzI/9lpkqRRDqwhuR yOgqRvpXgBE6aLukqOcVVNDmaCm5gAOpOU3yky5nhqOLMtE7l8JPWLZBoUv0cwuvJWrr W5otVMtb/EBCts8J4MCtSEO/DDCDTKCCgvAv7/0Jw1p04VM9iHuY6vaSnfsUAEMcAYQW Jqt20HFokKTvazHhjbwz0G5tfqH2NyIfftA9PEOVs2BonT4V9HGKU80NFCg5XHAzRcaU 6UQA== X-Received: by 10.55.41.165 with SMTP id p37mr24104554qkp.73.1444532432438; Sat, 10 Oct 2015 20:00:32 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 89sm4253594qgf.43.2015.10.10.20.00.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 10 Oct 2015 20:00:32 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 10 Oct 2015 23:00:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <201510101846.47847.davemgarrett@gmail.com> <20151011023515.GZ15070@mournblade.imrryr.org> In-Reply-To: <20151011023515.GZ15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510102300.30777.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 03:00:35 -0000 On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote: > This is not difficult, it just requires not forgetting that there's > more than one way to do (or not do) authentication, and that the > TLS protocol needs to remain largely agnostic of the authentication > model. Just deliver the available credentials to the peer, and > let the peer decide what to do. It's the "or not do" that's the issue, not the other ways to do authentication that I'm concerned about. As I said, it looks like we can word this properly in a way that works for everyone. I just feel like the best way to cover the OE case fully is to address it in a separate section, explicitly, rather than (just) tweak wording to accommodate it. Even TOFU is more straightforward than OE, because at least with that it always follows basically the same pattern. OE requires you take what would normally be a blatant catastrophic error, but wave a wand and say it's OK for this separate use case. That may be true, but that doesn't make it any less of a blatant catastrophic error when that's not the case. I'm worried about having these not be completely distinct for the same reason you don't put a self-destruct button next to a light switch, no matter how well labeled. ;) Also, I want the spec to anticipate some peers being incredibly stupid and avoid making it easy to mess things up. Dave From nobody Sat Oct 10 20:22:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17E91ACDF4 for ; Sat, 10 Oct 2015 20:22:55 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl9WqRwI6zcs for ; Sat, 10 Oct 2015 20:22:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB371ACDF2 for ; Sat, 10 Oct 2015 20:22:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B8312284B56; Sun, 11 Oct 2015 03:22:52 +0000 (UTC) Date: Sun, 11 Oct 2015 03:22:52 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151011032252.GA15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <201510101846.47847.davemgarrett@gmail.com> <20151011023515.GZ15070@mournblade.imrryr.org> <201510102300.30777.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510102300.30777.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 11 Oct 2015 03:22:55 -0000 On Sat, Oct 10, 2015 at 11:00:30PM -0400, Dave Garrett wrote: > On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote: > > This is not difficult, it just requires not forgetting that there's > > more than one way to do (or not do) authentication, and that the > > TLS protocol needs to remain largely agnostic of the authentication > > model. Just deliver the available credentials to the peer, and > > let the peer decide what to do. > > It's the "or not do" that's the issue, not the other ways to do > authentication that I'm concerned about. Concern is appropriate and healthy, and nevertheless the requirement to not focus too narrowly remains. For example a client doing GSSAPI with channel-binding and ignoring TLS certificates is essentially opportunistic viewed narrowly at the TLS layer, since it may well accept (and ignore) whatever certificate chain is sent its way. > As I said, it looks like we can word this properly in a way that works > for everyone. I just feel like the best way to cover the OE case fully is > to address it in a separate section, explicitly, rather than (just) tweak > wording to accommodate it. Separate (and thus possibly conflicting) language only as a last resort when a single specification is simply not possible. Most of TLS is trust model agnostic, so these differences should not matter in most or perhaps the entire specification. > Even TOFU is more straightforward than OE, because at least with that it > always follows basically the same pattern. Not when TOFU pins just the public key in the leaf cert. Nothing about the chain is then relevant, and the same SHA-1 questions are out of scope. > OE requires you take what would normally be a blatant catastrophic error, > but wave a wand and say it's OK for this separate use case. That may be > true, but that doesn't make it any less of a blatant catastrophic error > when that's not the case. I'm worried about having these not be completely > distinct for the same reason you don't put a self-destruct button next to > a light switch, no matter how well labeled. ;) TLS is silent on the trust model. It makes Web PKI, DANE, TOFU and OS/OE all equally possible. The peer gets the TLS credentials, the rest is up to the peer. > Also, I want the spec to anticipate some peers being incredibly stupid > and avoid making it easy to mess things up. Web PKI authentication is specified in other IETF specifications (RFC5280, RFC6125, ...). TLS just sends the rockets up, and it is not the job of TLS to care where they come down. :-) -- Viktor. From nobody Sat Oct 10 22:08:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B189D1AD06E for ; Sat, 10 Oct 2015 22:08:45 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq4yCybSAWCj for ; Sat, 10 Oct 2015 22:08:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1B51AD06C for ; Sat, 10 Oct 2015 22:08:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F1200284B56; Sun, 11 Oct 2015 05:08:41 +0000 (UTC) Date: Sun, 11 Oct 2015 05:08:41 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151011050841.GB15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <201510102300.30777.davemgarrett@gmail.com> <20151011032252.GA15070@mournblade.imrryr.org> <201510110033.34339.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510110033.34339.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 11 Oct 2015 05:08:45 -0000 On Sun, Oct 11, 2015 at 12:33:33AM -0400, Dave Garrett wrote: > https://github.com/tlswg/tls13-spec/pull/287 > > PR updated with some revisions. Please take a look at some point and tell me what you think. Still problematic, by changing more text than necessary. The following is wrong and should not be added. Just after which is largely fine (I would carve out an explicit exception for self-signatures which are a matter of data format necessity not trust): "Endpoints negotiating use of TLS 1.3 MUST NOT trust any signature that uses any of the deprecated hash algorithms (MD5, SHA-1, & SHA-224)" You add the incorrect: or send any certificate relying on any deprecated hash to its peer. (see {{server-certificate}}) This is still the same problem as before. The fix is to just as before say no such thing, each peer sends something with a known supported algorithm if it can, or whatever otherwise it has if it can't. Indeed with SNI, sending the right certificate (matching SAN) takes precedence over any considerations of algorithms. If the none of the certificates with the right SAN have supported algorithms, send one with an unsupported algorithm and let the peer decide. At which point, the next change is not needed: -the client a certificate chain of its choice that may include algorithms -that are not known to be supported by the client. This fallback chain MAY -use the deprecated SHA-1 hash algorithm. +the client a certificate chain of its choice that MAY include algorithms +that are not known to be supported by the client. For SHA-1 can still be sent, all that changes is that its in signatures is no longer trusted, (but tolerated in self-signatures which are not relevant in evaluating trust). At which point we get to (removed original text elided, just unchanged and new text below): If the client cannot construct an acceptable chain using the provided +certificates and decides to abort the handshake, then it MUST send a +fatal alert message and close the connection. If the chain is untrustworthy +because a certificate cannot be parsed correctly or due to use of a +deprecated hash algorithm (MD5, SHA-1, & SHA-224), then it SHOULD produce +a "bad_certificate" alert; otherwise it MUST produce an +"unsupported_certificate" alert. It is simply wrong to require any particular reaction to an untrusted chain. Elements of the chain may expired, contain unknown (more modern?) algorithms, and yet the handshake can continue in trust models which don't need the problematic portion of the chain. TLS does not mandate a trust model, it supports Web PKI trust more directly than other models, but that's as far as it goes. TLS can say that certificates with SHA-1 are no longer to be trusted. Some such intermediate certificates sent by a peer may not even end up in the (alternative) chain the verifier builds. Or the verifier may not validate any certificate chain at all. +Servers supporting both TLS 1.2 and TLS 1.3 MAY negotiate TLS 1.2 with +support for SHA-1 hashes, however servers MUST NOT downgrade to use an +older version in response to a TLS 1.3 client offering support for only +deprecated or unsupported hashes. All clients offering TLS 1.3 are REQUIRED +to offer support for at least one hash/signature pair which is not deprecated +(see {{signature-algorithms}}). This is fine, and applies to TLS PRFs, ... but the certificate chain can still contain (untrusted) SHA-1 signatures even with TLS 1.3. +MD5 hashes MUST NOT be used in any certificate in any TLS version, and any +implementation MAY reject any such certificate, without further inspection. Again this is simply too strong. Just like SHA-1, MD5 is not trusted. Its presence MUST NOT terminate the handshake, mandating this at the TLS layer is a layer violation. Trust is an application layer problem. Also the below is not appropriate: +- Have you ensured that certificate chains using SHA-1 or SHA-224 + are only used with TLS 1.2 or older, or are prohibited completely? + And this: +- When the client has requested a server certificate, but no + suitable certificate chain is available, do you correctly send a + valid fallback chain using whatever TLS 1.3 permitted algorithms + are necessary, instead of immediately aborting the connection? + The fallback chain can contain anything at all. CRC-32 if need be. Only SHA2-256, equivalent or better is to be trusted, but that's a decision for the next layer up. This pull request needs to simply specify that digest algorithms other than SHA2-256 and SHA2-384 (plus any speficified in future RFCs as sufficiently strong) are to be trusted by default. Some clients may accept GOST signatures, that's a local matter for those clients. And we may yet see some subset of SHA3-256, SHAKE256, Blake2, ... in certificates. This draft deprecates trust in SHA-1, and restates non-trust of MD5. While clarifying that presence of either in certificates does not constitude a malformed protocol message, and does not automatically lead to fatal handshake errors. Rather, when seen outside of self-signatures in certificates needed to construct the complete chain, these algorithms typically cause chain verification to fail, which may in turn cause the handshake to be aborted for lack of trust, not because of deprecated signature algorithms in the certificate chain. Is this clear yet? -- Viktor. From nobody Sat Oct 10 22:53:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB271A6F29 for ; Sat, 10 Oct 2015 22:53:39 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vABtpFKWbKxe for ; Sat, 10 Oct 2015 22:53:37 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 685691A1AC9 for ; Sat, 10 Oct 2015 22:53:37 -0700 (PDT) Received: by qgx61 with SMTP id 61so99586368qgx.3 for ; Sat, 10 Oct 2015 22:53:36 -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-type:content-transfer-encoding:message-id; bh=04L88JBjjuGxbeinTwInhQJ5wQwLnwxaojYpDTZU8mk=; b=fS3gCxvQEAMcTr7icA83ysDYm23Y8IZKtaSHhy9tIvuTux7KMGn5HUpzSfhdQkGbvm Xe7fzVMrwHPejUlUOqLgdUSPrFSej+7CuDDHPLppyFRPnhOrvzXVhltIBiZbdMrC7p9Y LkUbMwyp5Rks6oAYRqpLHyLeT/XXDyOueNkeNgY5r/lAwwH+xuScMcKk2ZvdKX2XHyGq hCADE/xm3kQ7bxpnbE3Q5eWk7RhjoWFHerynTMEa0dZOI5rW55JYmB5MWdUPzkbLkk0p QnwLsoW9YC8W2XvJNeYcyY+WqH5ojBPZt3LbL+XINX4GfyixC4VAAW1qU6Plg3WdxmWk OKjg== X-Received: by 10.140.22.133 with SMTP id 5mr24709323qgn.12.1444542816604; Sat, 10 Oct 2015 22:53:36 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id c2sm4504629qkh.6.2015.10.10.22.53.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 10 Oct 2015 22:53:36 -0700 (PDT) From: Dave Garrett To: Viktor Dukhovni Date: Sun, 11 Oct 2015 01:53:34 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <201510110033.34339.davemgarrett@gmail.com> <20151011050841.GB15070@mournblade.imrryr.org> In-Reply-To: <20151011050841.GB15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201510110153.35098.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 05:53:39 -0000 On Sunday, October 11, 2015 01:08:41 am Viktor Dukhovni wrote: > Is this clear yet? It's clear, but we disagree on a few points here. > On Sun, Oct 11, 2015 at 12:33:33AM -0400, Dave Garrett wrote: > Just after which is largely fine (I would carve out an explicit > exception for self-signatures which are a matter of data format > necessity not trust): >=20 > "Endpoints negotiating use of TLS 1.3 MUST NOT trust any > signature that uses any of the deprecated hash algorithms > (MD5, SHA-1, & SHA-224)" >=20 > You add the incorrect: >=20 > or send any certificate relying on any deprecated hash to > its peer. (see {{server-certificate}}) >=20 > This is still the same problem as before. The fix is to just as > before say no such thing, each peer sends something with a known > supported algorithm if it can, or whatever otherwise it has if it > can't. Indeed with SNI, sending the right certificate (matching > SAN) takes precedence over any considerations of algorithms. If > the none of the certificates with the right SAN have supported > algorithms, send one with an unsupported algorithm and let the peer > decide. =46rom a perspective to get it to work with the bare minimum needed, it's e= xcessive. From a perspective of killing SHA-1 wherever viable, it is not. A= ny continued legitimate allowance of a deprecated hash perpetuates other po= ssible continued allowances, even if the one in question is viable under so= me specific circumstance. The goal I'm aiming for is SHA-1 being restricted to TLS 1.2, with the exce= ption of self-signed roots. This exception does not rely on the hash, as th= e whole cert is what's trusted, so this wording is fine. In fact, two endpo= ints exchanging certs using SHA1 with intent to directly trust certs is all= owed with this wording. Shots-in-the-dark using SHA1 from general-purpose s= ervers are not. I think you wish to allow this last case; I do not. > At which point we get to (removed original text elided, just > unchanged and new text below): >=20 > If the client cannot construct an acceptable chain using the provided > +certificates and decides to abort the handshake, then it MUST send a > +fatal alert message and close the connection. If the chain is untrus= tworthy > +because a certificate cannot be parsed correctly or due to use of a > +deprecated hash algorithm (MD5, SHA-1, & SHA-224), then it SHOULD pr= oduce > +a "bad_certificate" alert; otherwise it MUST produce an > +"unsupported_certificate" alert. >=20 > It is simply wrong to require any particular reaction to an untrusted > chain. Elements of the chain may expired, contain unknown (more > modern?) algorithms, and yet the handshake can continue in trust > models which don't need the problematic portion of the chain. If the trust model doesn't need the problematic portion of the chain, then = the chain is not trustworthy and this does not apply. Also note that it is = merely saying that _if_ the client chooses to abort the handshake, that _th= en_ it must alert and abort, and then specifies which abort should be used.= If the client does not decide to abort the handshake, then the _entire_ po= rtion above is not applicable (no abort, because acceptable in its trust mo= del, therefor no alert for the trustworthy chain), which is exactly what yo= u're requesting. > +Servers supporting both TLS 1.2 and TLS 1.3 MAY negotiate TLS 1.2 wi= th > +support for SHA-1 hashes, however servers MUST NOT downgrade to use = an > +older version in response to a TLS 1.3 client offering support for o= nly > +deprecated or unsupported hashes. All clients offering TLS 1.3 are R= EQUIRED > +to offer support for at least one hash/signature pair which is not d= eprecated > +(see {{signature-algorithms}}). >=20 > This is fine, and applies to TLS PRFs, ... but the certificate > chain can still contain (untrusted) SHA-1 signatures even with TLS > 1.3. Yes. The certificate list can contain untrusted stuff, but the whatever it = builds out of that to trust cannot rely on it at any point. (e.g. can trust= a chain with a root w/ SHA1 or directly trust such a cert, but not a link = with a SHA1 sig) Also note, that I initially was OK with considering downgrade as described = above, however I feel like there's downgrade attack potential if that's all= owed (especially without further specification). > +MD5 hashes MUST NOT be used in any certificate in any TLS version, a= nd any > +implementation MAY reject any such certificate, without further insp= ection. >=20 > Again this is simply too strong. Just like SHA-1, MD5 is not > trusted. Its presence MUST NOT terminate the handshake, mandating > this at the TLS layer is a layer violation. Trust is an application > layer problem. It does not mandate termination; that's a "MAY". It says it "MUST NOT be us= ed". A client could still accept it, if it really had to, so long as it's t= rusting the cert and not using the MD5 sig. Again, show no quarter. Even the slightest implication that MD5 is valid in= any scenario involving a TLS 1.3 endpoint is too much at this point. [...] > The fallback chain can contain anything at all. CRC-32 if need > be. No. It's not just a matter of what can be trusted, but also a matter of wha= t should be considered acceptable. TLS has a lot of crippling problems beca= use they get ignored. Nobody complained about SS2 CLIENT-HELLOs for 20 year= s, so we _still_ have to allow accepting them for TLS 1.0-1.2 connection at= tempts. If your goal is to truly phase out obsolete junk, you have to put p= ressure on it everywhere viable. > Some clients may accept GOST signatures, that's a local matter for > those clients. And we may yet see some subset of SHA3-256, SHAKE256, > Blake2, ... in certificates. Yes. The goal here is blacklisting not whitelisting. > This draft deprecates trust in SHA-1, and restates non-trust of > MD5. While clarifying that presence of either in certificates does > not constitude a malformed protocol message, and does not automatically > lead to fatal handshake errors. Rather, when seen outside of > self-signatures in certificates needed to construct the complete > chain, these algorithms typically cause chain verification to fail, > which may in turn cause the handshake to be aborted for lack of > trust, not because of deprecated signature algorithms in the > certificate chain. The text still has the client making the final call on server cert chains i= n all instances. Dave From nobody Sat Oct 10 23:02:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B551A6F87 for ; Sat, 10 Oct 2015 23:02:03 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BkKSIpoEa2o for ; Sat, 10 Oct 2015 23:02:02 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 4A4F41A6F57 for ; Sat, 10 Oct 2015 23:02:02 -0700 (PDT) Received: by qgx61 with SMTP id 61so99649420qgx.3 for ; Sat, 10 Oct 2015 23:02:01 -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-type:content-transfer-encoding:message-id; bh=CwGgj2ZfNR4kEAL5vQHef8lbFYSlxspPMqwvPlz5c3g=; b=E4Pk5ewg9J+1t66YTcf4PF74YA/Vz0ecUarTR15AbCgIQvXGXrJK9rrvUUc1g72J2C MwdVYXLQkt4wMb0mkUBfPp4O0n44IZNpPWc1v/mr+4qpjE+4/4OGkC5fRgmoyNRGZwLj PEv2isGhnXxggmi3ZZuHQtSbPI4ogDo1wDtpbDfWfOpRJVt0ZG3wOe4LTIlUD3uiBRzK k1TPMYcul1v4uhzuRUNKeGunt/Be+Ymn2Ru/J1zSrrq1ElJA1PhzviwNQTtgzVgZAQNx T3e1fV9E2JFPpjWF0qjryxTJdDIMJ/CadTK4H16lJY7L6ocDLYD9fl9wNm4Y8Gp/53Ks cWRQ== X-Received: by 10.140.42.8 with SMTP id b8mr24389773qga.58.1444543321495; Sat, 10 Oct 2015 23:02:01 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 18sm4508424qgg.39.2015.10.10.23.02.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 10 Oct 2015 23:02:00 -0700 (PDT) From: Dave Garrett To: Viktor Dukhovni Date: Sun, 11 Oct 2015 02:01:59 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <20151011050841.GB15070@mournblade.imrryr.org> <201510110153.35098.davemgarrett@gmail.com> In-Reply-To: <201510110153.35098.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510110201.59970.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 06:02:03 -0000 On Sunday, October 11, 2015 01:53:34 am Dave Garrett wrote: > If the trust model doesn't need the problematic portion of the chain, then the chain is not trustworthy and this does not apply. Sorry, follow-up to fix a rather critical typo from a double negative. The "is not trustworthy" was meant to be "is not untrustworthy". If the trust model doesn't need a part to trust the peer, then it's not untrusted; it's irrelevant. The overall chain can be trustworthy regardless of what's in parts it doesn't care about. Dave From nobody Sun Oct 11 00:03:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E47D1AD374 for ; Sun, 11 Oct 2015 00:03:42 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcKsqXtJhlct for ; Sun, 11 Oct 2015 00:03:40 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c: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 1923C1AD373 for ; Sun, 11 Oct 2015 00:03:40 -0700 (PDT) Received: by wijq8 with SMTP id q8so16788246wij.0 for ; Sun, 11 Oct 2015 00:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q8dUm/lYpl4ZHrrHMa3mtRugf9OsXloTuwis40J84Lg=; b=jxoxsO6dJF657cS8Ej4dtP6RK2VxPBnxt/j8lPJAnIfN71sxl6z0RX86ZcMF9y+eYv rTveqbK7PyzxZ1mSlk3onIfSVMLDg5DojBzeROog/+w9882qWhdCQU5qhflY8ckAcUVM LisRd97aa5RGtemV49fBXdJPMNC5r6MP4BiwdpWhsMAKCDNJVuf3h71OPpQNQxm4IOK8 4y26jYJ4etExFvUiobCoFf2R4GUAlD8LqALmGM/8oZS/Muf/fDARNu4CjziHnClACR4a RQbxvkXgEmognEmTNq/zgEGtkXI9hTqnIndzL6JnQ4NlWb0VlIfKnIH6OwZTeaveeY8b ZtYw== X-Received: by 10.195.13.164 with SMTP id ez4mr2244465wjd.112.1444547018619; Sun, 11 Oct 2015 00:03:38 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id ki7sm12134799wjc.28.2015.10.11.00.03.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Oct 2015 00:03:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <201510110153.35098.davemgarrett@gmail.com> Date: Sun, 11 Oct 2015 10:03:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7DD96912-E983-483C-99D1-2D9F6C85E2A4@gmail.com> References: <201510101337.29335.davemgarrett@gmail.com> <201510110033.34339.davemgarrett@gmail.com> <20151011050841.GB15070@mournblade.imrryr.org> <201510110153.35098.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2104) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 07:03:42 -0000 On Oct 11, 2015, at 8:53 AM, Dave Garrett = wrote: > =46rom a perspective to get it to work with the bare minimum needed, = it's excessive. =46rom a perspective of killing SHA-1 wherever viable, = it is not. I don=E2=80=99t think killing SHA-1 wherever viable should be a goal of = this document. A certificate is a credential. It can be used in multiple = protocols, standard and proprietary. Whether the certificate is trusted = or not is up to the relying party regardless of what protocols that = relying party uses. It is not for the TLS spec to dictate what = properties a certificate should have, except when those properties make = a difference for the protocol. So if we=E2=80=99re removing DSA from the = spec, and have not yet standardized EdDSA signatures, it makes sense to = require that the public key (not the signature!) in the certificate be = either RSA or ECDSA. I don=E2=80=99t think it=E2=80=99s reasonable to = require stuff that doesn=E2=80=99t enter the protocol. > Any continued legitimate allowance of a deprecated hash perpetuates = other possible continued allowances, even if the one in question is = viable under some specific circumstance. >=20 > The goal I'm aiming for is SHA-1 being restricted to TLS 1.2 And assuming that TLS 1.3 has better security than TLS 1.2, how does = this goal help security on the Internet? We are not in charge of the Internet. We are only engineering some = protocols that we hope the implementers will find useful. The industry = *is* moving away from signing certificates with SHA-1, but that decision = is being made elsewhere. Yoav From nobody Sun Oct 11 00:25:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327D21B29E1 for ; Sun, 11 Oct 2015 00:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeAVOhDoqkoA for ; Sun, 11 Oct 2015 00:25:16 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6C31B29E2 for ; Sun, 11 Oct 2015 00:25:14 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id TjRB1r00410HQrX01jRCmL; Sun, 11 Oct 2015 09:25:12 +0200 Message-ID: <561A0ED6.1000505@openfortress.nl> Date: Sun, 11 Oct 2015 09:25:10 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 07:25:19 -0000 Hello TLS WG, I would like to propose new CipherSuites for TLS. The cryptography is founded on Kerberos authentication and DH encryption, cryptographically bound together. The mechanism uses mutual authentication, although clients may use anonymous tickets. Any feedback that you may have (technical, or WG-procedural) is kindly welcomed. I will also send this to the Kitten WG. Thanks, Rick van Rein > *From:* internet-drafts@ietf.org > *Date:* 1 October 2015 18:54 > *To:* "Rick van Rein" , "Rick van Rein" > > *Subject:* New Version Notification for draft-vanrein-tls-kdh-00.txt > A new version of I-D, draft-vanrein-tls-kdh-00.txt > has been successfully submitted by Rick van Rein and posted to the > IETF repository. > > Name: draft-vanrein-tls-kdh > Revision: 00 > Title: TLS-KDH: Kerberos + Diffie-Hellman in TLS > Document date: 2015-10-01 > Group: Individual Submission > Pages: 26 > URL: https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-00.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-kdh-00 > > > Abstract: > This specification extends TLS with a Kerberos-based method of mutual > authentication, and binds in Diffie-Hellman to achieve Perfect > Forward Secrecy for the session. > The IETF Secretariat > From nobody Sun Oct 11 05:17:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D64C1A8892 for ; Sun, 11 Oct 2015 05:17:13 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hapbnsc7cCD for ; Sun, 11 Oct 2015 05:17:10 -0700 (PDT) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 492841A8890 for ; Sun, 11 Oct 2015 05:17:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 3A8B821B896; Sun, 11 Oct 2015 15:17:07 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id myI1AQBHDmVx; Sun, 11 Oct 2015 15:17:07 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 127ED5BC010; Sun, 11 Oct 2015 15:17:07 +0300 (EEST) Date: Sun, 11 Oct 2015 15:17:01 +0300 From: Ilari Liusvaara To: Rick van Rein Message-ID: <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> References: <561A0ED6.1000505@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <561A0ED6.1000505@openfortress.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 12:17:13 -0000 On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: > > *From:* internet-drafts@ietf.org > > > > Name: draft-vanrein-tls-kdh > > Revision: 00 > > Hello TLS WG, > > I would like to propose new CipherSuites for TLS. The cryptography is > founded on Kerberos authentication and DH encryption, cryptographically > bound together. The mechanism uses mutual authentication, although > clients may use anonymous tickets. > > Any feedback that you may have (technical, or WG-procedural) is kindly > welcomed. I will also send this to the Kitten WG. Some quick comments: - The signed DH share does not look to be bound to anything (crypto parameters negotiation, randoms, server key exchange, etc..). I can't offhand say what that would lead to, but it looks even worse than TLS ServerKeyExchange, which has known vulernabilities due to lack of binding to things like ciphersuite. - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. - Even use of DH is questionable. [1] All the current ciphersuites have SHA-256 or SHA-384 prf-hash (the prf-hash of existing ciphers was grandfathered as SHA-256, even if the name has _SHA or _MD5). [2] AFAIK, proving security properties of TLS against active attack needs assumption that prf-hash is secure. And we know SHA-1 isn't. -Ilari From nobody Sun Oct 11 06:04:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E213A1A8931 for ; Sun, 11 Oct 2015 06:04:45 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kldiZ4hSh6U for ; Sun, 11 Oct 2015 06:04:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC261A8930 for ; Sun, 11 Oct 2015 06:04:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5F2F6284B56; Sun, 11 Oct 2015 13:04:43 +0000 (UTC) Date: Sun, 11 Oct 2015 13:04:43 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151011130443.GC15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <20151011050841.GB15070@mournblade.imrryr.org> <201510110153.35098.davemgarrett@gmail.com> <201510110201.59970.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510110201.59970.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 11 Oct 2015 13:04:46 -0000 On Sun, Oct 11, 2015 at 02:01:59AM -0400, Dave Garrett wrote: > On Sunday, October 11, 2015 01:53:34 am Dave Garrett wrote: > > If the trust model doesn't need the problematic portion of the chain, > > then the chain is not trustworthy and this does not apply. > > Sorry, follow-up to fix a rather critical typo from a double negative. > The "is not trustworthy" was meant to be "is not untrustworthy". If the > trust model doesn't need a part to trust the peer, then it's not untrusted; > it's irrelevant. The overall chain can be trustworthy regardless of what's > in parts it doesn't care about. Yes, of course. -- Viktor. From nobody Sun Oct 11 06:46:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B9F1A89F9 for ; Sun, 11 Oct 2015 06:46:07 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3_7pbo6Jxwv for ; Sun, 11 Oct 2015 06:46:06 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c: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 153A41A895E for ; Sun, 11 Oct 2015 06:46:05 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so22073710wic.1 for ; Sun, 11 Oct 2015 06:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L3QTVpZjJ/Ckcw0CsONCW8mg/uIurkEWgExZ1CPWUcY=; b=OcPfCIGwjHTTzJK2hXE9yqFL3GFzTsyVqwBrAXzG5jGpr14Wffr1q0c6N9YR0XLEmZ UxNGoIrzSVZca5MyyCmHvKFvZlr3O/oEJmJOeWQA3J6aZQAd+WqLjOMJBJanGeKu7KJ6 c3h9MDyVwif82O5wnLLF6WKtnl+vZPt6KRD2vfsv3tmP3UPqy2RhYfVPuKpMLY+HM1ep gRlbf2wCRQhsuSnhX7Yga9kz+lDexg0ok5Mi8hB+Cx6QOnzeMpfDNpv2Nc8mePhtEsgn BqXc9WM2mPrtNXYMm2w3zdLNez3K3+bnT4UXkW7RJrp2yZP8xuThQGJWnvVq44bQuVi2 RUNQ== MIME-Version: 1.0 X-Received: by 10.180.105.135 with SMTP id gm7mr8987969wib.18.1444571163567; Sun, 11 Oct 2015 06:46:03 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Sun, 11 Oct 2015 06:46:03 -0700 (PDT) In-Reply-To: <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 11 Oct 2015 09:46:03 -0400 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 13:46:07 -0000 On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara wrote: > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: >> > *From:* internet-drafts@ietf.org >> > >> > Name: draft-vanrein-tls-kdh >> > Revision: 00 >> >> Hello TLS WG, >> >> I would like to propose new CipherSuites for TLS. The cryptography is >> founded on Kerberos authentication and DH encryption, cryptographically >> bound together. The mechanism uses mutual authentication, although >> clients may use anonymous tickets. >> >> Any feedback that you may have (technical, or WG-procedural) is kindly >> welcomed. I will also send this to the Kitten WG. > > Some quick comments: > - The signed DH share does not look to be bound to anything (crypto > parameters negotiation, randoms, server key exchange, etc..). I can't > offhand say what that would lead to, but it looks even worse than > TLS ServerKeyExchange, which has known vulernabilities due to > lack of binding to things like ciphersuite. > - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC > (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. > - Even use of DH is questionable. I would suggest piggybacking on the PSK mode, using the key Kerberos provides at both ends as the PSK key. This would address all of these issues in TLS 1.3 Sincerely, Watson From nobody Sun Oct 11 07:11:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE951A0119 for ; Sun, 11 Oct 2015 07:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH2a0FlY4qEq for ; Sun, 11 Oct 2015 07:11:14 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 2861E1A1A2F for ; Sun, 11 Oct 2015 07:11:14 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so120710417wic.1 for ; Sun, 11 Oct 2015 07:11:12 -0700 (PDT) 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-type; bh=r38cbqCN+VGykLz7/50z6ZZxKlQL0BqsDxyxV3doNhM=; b=gd1z2Y07xQOo/oG/CvOmAdXPCD7mzYUKR5FySLugMYtENKDUJzXC7zjCo1Ib/EiZ+r 6gRrUOZ2xPCgWpXkwPA+ySWwOuVOtoD0udRHJa6WVXvxAY3eost6cBZZRgJ4NpT/EK84 bAUSRso9TFEw/lHGvyEyHP5lGcQl0GefZ7r9B/6E8oTDAz90mhI+w2II6J/hiCeKRlQt 017de9YIC7JwbvlD/nW448m3xPlAvfDNn69cx7lPSc0LC78YCd485lPPWNLs3I+ulB/y dthdY07nq9zkkOWICmw8Te9+zSJ3UKqHNIH6NkmM5NgooSGyevKz1wYmhNfVDp1N7xrm LGdg== X-Gm-Message-State: ALoCoQn/N71jynFP4KuARPJBbmd2dbNuH5OA+B9UIGjcfHRPknUE4xd8nz9KwJbXQs3SXUJp6DLK X-Received: by 10.194.133.129 with SMTP id pc1mr25202362wjb.148.1444572672707; Sun, 11 Oct 2015 07:11:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Sun, 11 Oct 2015 07:10:33 -0700 (PDT) In-Reply-To: References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 11 Oct 2015 07:10:33 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e01227d940269520521d4c9d1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 14:11:16 -0000 --089e01227d940269520521d4c9d1 Content-Type: text/plain; charset=UTF-8 This seems like a good approach. -Ekr On Sun, Oct 11, 2015 at 6:46 AM, Watson Ladd wrote: > On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara > wrote: > > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: > >> > *From:* internet-drafts@ietf.org > >> > > >> > Name: draft-vanrein-tls-kdh > >> > Revision: 00 > >> > >> Hello TLS WG, > >> > >> I would like to propose new CipherSuites for TLS. The cryptography is > >> founded on Kerberos authentication and DH encryption, cryptographically > >> bound together. The mechanism uses mutual authentication, although > >> clients may use anonymous tickets. > >> > >> Any feedback that you may have (technical, or WG-procedural) is kindly > >> welcomed. I will also send this to the Kitten WG. > > > > Some quick comments: > > - The signed DH share does not look to be bound to anything (crypto > > parameters negotiation, randoms, server key exchange, etc..). I can't > > offhand say what that would lead to, but it looks even worse than > > TLS ServerKeyExchange, which has known vulernabilities due to > > lack of binding to things like ciphersuite. > > - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC > > (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. > > - Even use of DH is questionable. > > I would suggest piggybacking on the PSK mode, using the key Kerberos > provides at both ends as the PSK key. This would address all of these > issues in TLS 1.3 > > Sincerely, > Watson > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e01227d940269520521d4c9d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems like a good approach.

-Ekr


On Sun, Oct 11, 2015 at 6:46 AM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
<ilariliusvaara@welho.com> wrote:
> On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
>> > *From:* internet-= drafts@ietf.org
>> >
>> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-vanrein-tls-kdh
>> > Revision:=C2=A0 =C2=A000
>>
>> Hello TLS WG,
>>
>> I would like to propose new CipherSuites for TLS.=C2=A0 The crypto= graphy is
>> founded on Kerberos authentication and DH encryption, cryptographi= cally
>> bound together.=C2=A0 The mechanism uses mutual authentication, al= though
>> clients may use anonymous tickets.
>>
>> Any feedback that you may have (technical, or WG-procedural) is ki= ndly
>> welcomed.=C2=A0 I will also send this to the Kitten WG.
>
> Some quick comments:
> - The signed DH share does not look to be bound to anything (crypto >=C2=A0 =C2=A0parameters negotiation, randoms, server key exchange, etc.= .). I can't
>=C2=A0 =C2=A0offhand say what that would lead to, but it looks even wor= se than
>=C2=A0 =C2=A0TLS ServerKeyExchange, which has known vulernabilities due= to
>=C2=A0 =C2=A0lack of binding to things like ciphersuite.
> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC
>=C2=A0 =C2=A0(don't use), apparent SHA-1 prf-hash (REALLY bad idea)= [1][2].
> - Even use of DH is questionable.

I would suggest piggybacking on the PSK mode, using the key Kerberos=
provides at both ends as the PSK key. This would address all of these
issues in TLS 1.3

Sincerely,
Watson

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

--089e01227d940269520521d4c9d1-- From nobody Sun Oct 11 08:24:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DAB1A8F33 for ; Sun, 11 Oct 2015 08:24:10 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YknQKvYTV2K8 for ; Sun, 11 Oct 2015 08:24:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E011A8EA9 for ; Sun, 11 Oct 2015 08:24:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 731BB284B56; Sun, 11 Oct 2015 15:24:03 +0000 (UTC) Date: Sun, 11 Oct 2015 15:24:03 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151011152403.GD15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <201510110033.34339.davemgarrett@gmail.com> <20151011050841.GB15070@mournblade.imrryr.org> <201510110153.35098.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510110153.35098.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 11 Oct 2015 15:24:10 -0000 On Sun, Oct 11, 2015 at 01:53:34AM -0400, Dave Garrett wrote: > On Sunday, October 11, 2015 01:08:41 am Viktor Dukhovni wrote: > > Is this clear yet? > > It's clear, but we disagree on a few points here. It is important to keep in mind that the TLS protocol specification has a reasonably well defined scope and must not intrude on matters that lie outside that scope. In particular, the TLS 1.3 protocol, when not performing PSK resumption, carries a sequence of "certificates" whose first element (possibly in fact a bare public key) signs the protocol key exchange. The protocol tries to be helpful by providing certificates that the peer will understand. Therefore, the peer's list of supported signature algorithms, whose primary purpose is to negotiate a mutually supported PRF, is overloaded to help in certificate chain selection. When multiple choices of certificate chain are available (quite rare at present) to a peer, "the best" one can be selected. Beyond that however, it is not the TLS protocol's job to preempt a peer's decision as to whether a given sequence of "certificates" is trustworthy or even well formed. That responsibility falls on related higher-level protocols (PKIX 5280, Peer name checks RFC 6125, DANE 6698 as imminently updated by RFC 7671). > From a perspective to get it to work with the bare minimum needed, it's > excessive. From a perspective of killing SHA-1 wherever viable, it is not. Is is not appropriate mission for the TLS WG to launch a wider anti-SHA1 crusade. The TLS WG just needs to just avoid SHA-1 problems in the TLS protocol itself (PRFs, ...). Avoiding SHA-1 in PKIX is outside this group's purview. Yes, libraries that implement both TLS and PKIX and provide applications with active-attack resistant "secure channels" will should avoid trusting SHA-1 in PKIX, and I'm fine with a narrow statement that the peer chain verification code in such libraries should not trust SHA-1 issued certificates when negotiating TLS 1.3. However the TLS specification MUST NOT preempt that verifier's responsibility at the supplicant. > Any continued legitimate allowance of a deprecated hash perpetuates other > possible continued allowances, even if the one in question is viable under > some specific circumstance. See above, no crusades. > The goal I'm aiming for is SHA-1 being restricted to TLS 1.2, with the > exception of self-signed roots. A lofty goal, but one that thoroughly exceeds the scope of the TLS protocol. SHA-1 must also be allowed in non-root certs, provided the peer does not trust them (possibly does not need them at all). This is something only the peer can know. > In fact, > two endpoints exchanging certs using SHA1 with intent to directly trust > certs is allowed with this wording. Shots-in-the-dark using SHA1 from > general-purpose servers are not. I think you wish to allow this last case; > I do not. I'm afraid this wish exceeds the proper scope of what the TLS protocol can properly specify. > If the trust model doesn't need the problematic portion of the chain, then > the chain is not trustworthy and this does not apply. This decision fundamentally belongs on the verifier side, and therefore, it is NOT up to the sender to make it, nor is incumbent on the verifier to reject the handshake because the chain sent contains certificate with some algorithm it does not support if it ends up not needing (to trust or use) those certificates. > Also note that it > is merely saying that _if_ the client chooses to abort the handshake, that > _then_ it must alert and abort, and then specifies which abort should be > used. If the client does not decide to abort the handshake, then the > _entire_ portion above is not applicable (no abort, because acceptable in > its trust model, therefor no alert for the trustworthy chain), which is > exactly what you're requesting. We already know what verifiers should do when they don't trust a peer's credentials. Nothing new applies when that's due do an unsupported signature algorithm. > > This is fine, and applies to TLS PRFs, ... but the certificate > > chain can still contain (untrusted) SHA-1 signatures even with TLS > > 1.3. > > Yes. The certificate list can contain untrusted stuff, but the whatever > it builds out of that to trust cannot rely on it at any point. (e.g. can > trust a chain with a root w/ SHA1 or directly trust such a cert, but not > a link with a SHA1 sig) This is something we agree on, so the pull request needs to limit itself to *exactly* this. Any trusted chain constructed by a TLS 1.3 peer cannot contain issuer->subject links that employ SHA-1 signatures. If you narrowly say just this, without making any other changes, I'm on board. > > +MD5 hashes MUST NOT be used in any certificate in any TLS version, and any > > +implementation MAY reject any such certificate, without further inspection. > > > > Again this is simply too strong. Just like SHA-1, MD5 is not > > trusted. Its presence MUST NOT terminate the handshake, mandating > > this at the TLS layer is a layer violation. Trust is an application > > layer problem. > > It does not mandate termination; that's a "MAY". It says it "MUST NOT be > used". A client could still accept it, if it really had to, so long as > it's trusting the cert and not using the MD5 sig. Well, this "MAY" is in fact used incorrectly in Schannel, which aborts connections with opportunistic TLS SMTP clients that present client certs that include CAcert's MD5 self-signed root. It aborts in the TLS library, rather than in the application verification layer (which is opportunistic and allows anonymous clients and otherwise unauthenticated clients). This language leads to breakage, and does not belong in specification. It should maximally say that MD5 is untrusted, and should not suggest that seeing MD5 in the peer's handshake cert chain is sufficient grounds to immediately abort. > Again, show no quarter. Even the slightest implication that MD5 is valid > in any scenario involving a TLS 1.3 endpoint is too much at this point. No religious zeal. It is counter-productive. The client in the above example is forced to send in the clear, that's a self-imposed downgrade from unauthenticated TLS to cleartext. Is that better? > > The fallback chain can contain anything at all. CRC-32 if need > > be. > > No. It's not just a matter of what can be trusted, but also a matter of > what should be considered acceptable. I did not say that CRC-32 is acceptable for trusted signatures. It would merely not be sufficient grounds to abort a connection just because a peer sent a certificate with that in its signature (if there hypothetically was a PKIX OID for a signature algorithm like that). Which again points out that signatures in X.509 are PKIX not TLS. It is not the job of TLS to overreach. > TLS has a lot of crippling problems > because they get ignored. Nobody complained about SS2 CLIENT-HELLOs for > 20 years, so we _still_ have to allow accepting them for TLS 1.0-1.2 > connection attempts. If your goal is to truly phase out obsolete junk, > you have to put pressure on it everywhere viable. Remove junk from TLS. Clients that use TLS with PKIX, can avail themselves of any junk cleanups that happen in PKIX and the libraries that provide both TLS and PKIX. We have a means to narrowly specify that TLS 1.3 PKIX profiles should not trust SHA-1 signatures, we should say that and move on. No religious zeal or overreach. Clients that don't do PKIX at all, will then break needlessly and possibly downgrade to cleartext. > > This draft deprecates trust in SHA-1, and restates non-trust of > > MD5. I am fine with non-trust. I object to any and all requirements to exclude these from TLS certificate messages presented to peers, or to reject handshakes in which such messages are received. If the certificates presented are critical for the peer's trust decision and trust is required to complete the handshake, *then* the handshake breaks. No new mandate to object to these algorithms in the peer's chain based solely on their presence. > > While clarifying that presence of either in certificates does > > not constitute a malformed protocol message, and does not automatically > > lead to fatal handshake errors. Rather, when seen outside of > > self-signatures in certificates needed to construct the complete > > chain, these algorithms typically cause chain verification to fail, > > which may in turn cause the handshake to be aborted for lack of > > trust, not because of deprecated signature algorithms in the > > certificate chain. > > The text still has the client making the final call on server cert chains in all instances. Not as written. It needs to be clear that clients MUST NOT *trust* these algorithms, and that's it. If trust is required the connection ends with a fatal alert. If trust is not required, or the certificates in question end up not used in whatever chain is ultimately trusted, then the handshake continues. TLS needs to do *its* job flawlessly, but not overreach. -- Viktor. From nobody Sun Oct 11 10:24:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B911A1B2BAD for ; Sun, 11 Oct 2015 10:24:41 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjXCpW8N0vow for ; Sun, 11 Oct 2015 10:24:39 -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 817CA1B2BAA for ; Sun, 11 Oct 2015 10:24:39 -0700 (PDT) Received: by qkdo1 with SMTP id o1so42007865qkd.1 for ; Sun, 11 Oct 2015 10:24:38 -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-type:content-transfer-encoding:message-id; bh=5BY8TgP4gCyU13O96yKTMhTpRI6UzYebvllnkJ/knaQ=; b=ch7QxRlOk/c+9XxPHkIfG+WWhnoiUnJHO5jmmiuxf+1pZxqdRjuZt+tCGQev/xOFEk yTbEC4wV9+i1p7OLI9bHalIJ+T3m8/FjcCWot+totAWTsg1gJvExNtMBCq8EUex7DHQy spMug1qLYKIcaEDKRLFjOSMIVC+m0Pgm+YlDAKUdOQqGTvrciyNLAkG99miYTUbAhHXY vf9GhYZ0Ld5piCMlBYxjNfEluYUhsXs3UF7aIl53ON9j5NLu4aWRcgjtaXL5lVpoat25 2BpdcJImukAIionWiyycxvBntypmOo+q7e1rRh9PZ/OvO2g9/bNwitd4w3joYJ69BnIt bFCQ== X-Received: by 10.55.197.147 with SMTP id k19mr27202386qkl.11.1444584278653; Sun, 11 Oct 2015 10:24:38 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id b104sm5476790qga.7.2015.10.11.10.24.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 Oct 2015 10:24:38 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sun, 11 Oct 2015 13:24:36 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <201510110153.35098.davemgarrett@gmail.com> <20151011152403.GD15070@mournblade.imrryr.org> In-Reply-To: <20151011152403.GD15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510111324.37258.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 17:24:41 -0000 On Sunday, October 11, 2015 11:24:03 am Viktor Dukhovni wrote: > On Sun, Oct 11, 2015 at 01:53:34AM -0400, Dave Garrett wrote: > > From a perspective to get it to work with the bare minimum needed, it's > > excessive. From a perspective of killing SHA-1 wherever viable, it is not. > > Is is not appropriate mission for the TLS WG to launch a wider > anti-SHA1 crusade. The TLS WG just needs to just avoid SHA-1 > problems in the TLS protocol itself (PRFs, ...). Avoiding SHA-1 > in PKIX is outside this group's purview. Every time something is "someone else's problem", it is ensured that the problem will not be properly fixed. Security is only as strong as the weakest link in the chain, and thus I don't believe a philosophy of complete separation of roles is realistic, especially in a world where upgrades and fixes are still deployed slowly and badly. > See above, no crusades. Calling the goal of phasing out known-bad features a "crusade" is not really helpful. I'm perfectly fine with stating that SHA-1 is reasonable to allow in areas where it needs to be for continued transition. It, however, should require justification to keep allowance rather than to remove. > SHA-1 must also be allowed in non-root certs, provided > the peer does not trust them (possibly does not need them at all). > This is something only the peer can know. If we consider the certificate authenticated cipher suite scenario within TLS to expect this to be the common case, then that gives the false impression that admins don't "have" to upgrade because they're "usable". Assuming expertise is not safe. Servers should be sending certs using SHA256 or better. If it can't do that, then that needs to be fixed as a prerequisite. The alternative is a TLS implementation that tolerates continued usage, and TLS 1.3 clients will continue to receive SHA1-reliant chains for TLS 1.3 connections, and implementors will be incentivised to ignore the spec and trust SHA1 hashes to get it to "just work". The point you're dodging here is that you can't "require" something and expect that requirement to be followed if you continue disincentivise doing so. Even if most play by the rules, just one deciding that the spec needs to be ignored can cause most others to follow suit. (e.g. the mentality that produced fallback dances) > > Also note that it > > is merely saying that _if_ the client chooses to abort the handshake, that > > _then_ it must alert and abort, and then specifies which abort should be > > used. If the client does not decide to abort the handshake, then the > > _entire_ portion above is not applicable (no abort, because acceptable in > > its trust model, therefor no alert for the trustworthy chain), which is > > exactly what you're requesting. > > We already know what verifiers should do when they don't trust a > peer's credentials. Nothing new applies when that's due do an > unsupported signature algorithm. I did leave that separate error designation as a "SHOULD" in case of it being dealt with in a library that doesn't provide sufficient feedback to properly deal with. If an endpoint fails in reaction to publicly retrievable information (e.g. server's cert chain), then it should reply with the most relevant error code in order to let the server actually have a clue as to what the issue is and get it fixed. > > > This is fine, and applies to TLS PRFs, ... but the certificate > > > chain can still contain (untrusted) SHA-1 signatures even with TLS > > > 1.3. > > > > Yes. The certificate list can contain untrusted stuff, but the whatever > > it builds out of that to trust cannot rely on it at any point. (e.g. can > > trust a chain with a root w/ SHA1 or directly trust such a cert, but not > > a link with a SHA1 sig) > > This is something we agree on, so the pull request needs to limit itself > to *exactly* this. Any trusted chain constructed by a TLS 1.3 peer cannot > contain issuer->subject links that employ SHA-1 signatures. Essentially, our disagreement is just what to do on the server side of things. I'm saying the server should be required to send non-obsolete certificates and not allowed to assume clients might be able to trust non-root certs directly, as this is not the dominant way certificate authentication is done. > If you narrowly say just this, without making any other changes, I'm > on board. > > > > +MD5 hashes MUST NOT be used in any certificate in any TLS version, and any > > > +implementation MAY reject any such certificate, without further inspection. > > > > > > Again this is simply too strong. Just like SHA-1, MD5 is not > > > trusted. Its presence MUST NOT terminate the handshake, mandating > > > this at the TLS layer is a layer violation. Trust is an application > > > layer problem. > > > > It does not mandate termination; that's a "MAY". It says it "MUST NOT be > > used". A client could still accept it, if it really had to, so long as > > it's trusting the cert and not using the MD5 sig. > > Well, this "MAY" is in fact used incorrectly in Schannel, which > aborts connections with opportunistic TLS SMTP clients that present > client certs that include CAcert's MD5 self-signed root. Why on Earth is anyone still using an MD5 self-signed root? Regardless, "non-root" is acceptable here, if that's sadly still a concern. > > Again, show no quarter. Even the slightest implication that MD5 is valid > > in any scenario involving a TLS 1.3 endpoint is too much at this point. > > No religious zeal. It is counter-productive. The client in the > above example is forced to send in the clear, that's a self-imposed > downgrade from unauthenticated TLS to cleartext. Is that better? When talking about MD5 still being around, I'm inclined to consider it acceptable collateral damage to avoid presenting a false sense of security, though if the land of half-assed email transport security is still this bad, then this may not be ideal. The correct course of action is of course to not support this connection at all, but that requires more commitment than developers are willing to make to security. That lack of will is _why_ I'm arguing for minimal tolerance of obsolete hashes. > TLS needs to do *its* job flawlessly, but not overreach. TLS is not capable of doing its job without sanity checking inputs from related layers. The job of TLS is to provide a secure connection, which it cannot do if it tolerates authentication of clearly obsolete and forgeable certificates when it does not have to. (MD5 being the most brazen example) Dave From nobody Sun Oct 11 11:17:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14DF1B2C21 for ; Sun, 11 Oct 2015 11:17:21 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8F3tyvmFll6 for ; Sun, 11 Oct 2015 11:17:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3513D1B2C2E for ; Sun, 11 Oct 2015 11:17:19 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DEF67284B56; Sun, 11 Oct 2015 18:17:17 +0000 (UTC) Date: Sun, 11 Oct 2015 18:17:17 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151011181717.GE15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <201510110153.35098.davemgarrett@gmail.com> <20151011152403.GD15070@mournblade.imrryr.org> <201510111324.37258.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510111324.37258.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 11 Oct 2015 18:17:22 -0000 On Sun, Oct 11, 2015 at 01:24:36PM -0400, Dave Garrett wrote: > > Is is not appropriate mission for the TLS WG to launch a wider > > anti-SHA1 crusade. The TLS WG just needs to just avoid SHA-1 > > problems in the TLS protocol itself (PRFs, ...). Avoiding SHA-1 > > in PKIX is outside this group's purview. > > Every time something is "someone else's problem", it is ensured that the > problem will not be properly fixed. Security is only as strong as the > weakest link in the chain, and thus I don't believe a philosophy of complete > separation of roles is realistic, especially in a world where upgrades > and fixes are still deployed slowly and badly. And yet despite your best intentions, defining the semantics of the certificates *carried* by TLS (but specified elsewhere and possibly irrelevant to the verifier) is properly outside the purview of the TLS WG. We can suggest that in TLS 1.3 SHA-1 signatures should not be trusted because they are too weak by comparison with the algorithms used elsewhere in TLS 1.3, we cannot say that peers must abort handshakes carrying certs with signature algorithms employing SHA-1, MD5 or even hypothetically CRC-32 certificates on sight. > > See above, no crusades. > > Calling the goal of phasing out known-bad features a "crusade" is not > really helpful. I'm perfectly fine with stating that SHA-1 is reasonable > to allow in areas where it needs to be for continued transition. It, > however, should require justification to keep allowance rather than to > remove. And yet what you propose is a crusade. You're no longer looking at TLS. You're suggesting we constrain choices outside of TLS, because we know better, but we don't know better, because TLS has no knowledge of the application trust model. So TLS does not get to dictate which offered certificate chains are to be rejected and which accepted. The best we can do is to specify which parameters are too weak to include in such decisions when and if processing chain elements that contain such parameters. > > SHA-1 must also be allowed in non-root certs, provided > > the peer does not trust them (possibly does not need them at all). > > This is something only the peer can know. > > If we consider the certificate authenticated cipher suite scenario within > TLS to expect this to be the common case, then that gives the false > impression that admins don't "have" to upgrade because they're "usable". Nothing of the sort. We've agreed that TLS 1.3 clients won't trust SHA-1. We need to stop there. We have no choice. We might like to be able to be beneficent dictators, but that's not an option. > > This is something we agree on, so the pull request needs to limit itself > > to *exactly* this. Any trusted chain constructed by a TLS 1.3 peer cannot > > contain issuer->subject links that employ SHA-1 signatures. > > Essentially, our disagreement is just what to do on the server side of > things. I'm saying the server should be required to send non-obsolete > certificates and not allowed to assume clients might be able to trust > non-root certs directly, as this is not the dominant way certificate > authentication is done. The difference goes further, yes the server must not unilaterally deny access to a configured SHA-1 chain, but also the client must not out of hand reject the transmission of such a chain just because SHA-1 is found. Rather the client optionally (but typically) attempts to authenticate the server's certificates, and if that requires using a SHA-1 cert it might stops there given suitable requirements in the TLS 1.3 draft, but if none of the presented SHA-1 certs were needed, then all's well that ends well. This subsumes all the use-cases in which some or all of the server's certificates go unused. > > Well, this "MAY" is in fact used incorrectly in Schannel, which > > aborts connections with opportunistic TLS SMTP clients that present > > client certs that include CAcert's MD5 self-signed root. > > Why on Earth is anyone still using an MD5 self-signed root? Regardless, > "non-root" is acceptable here, if that's sadly still a concern. Ask CAcert.org whose 4096-bit root CA is self-signed with MD5 for no good reason whatsoever. And yet there's no problem with that, the cert is slightly smaller that way, and the self-signature plays no role in security. > When talking about MD5 still being around, I'm inclined to consider it > acceptable collateral damage to avoid presenting a false sense of security, > though if the land of half-assed email transport security is still this > bad, then this may not be ideal. Your "half-assed" is my impressive success, ~80% of outbound email from Google, that used to go in clear is now encrypted. What fraction of HTTP sites have migrated from cleartext? > The correct course of action is of course > to not support this connection at all, but that requires more commitment > than developers are willing to make to security. That lack of will is > _why_ I'm arguing for minimal tolerance of obsolete hashes. There is no "lack of will", you're just doggedly ignoring legitimate use cases. In all-or-nothing security the majority gets nothing. I know that opportunistic security is major cognitive dissonance for security professionals trained to accept no compromises, but it is fact by making judicious compromises that real progress is made. > > TLS needs to do *its* job flawlessly, but not overreach. > > TLS is not capable of doing its job without sanity checking inputs from > related layers. The job of TLS is to provide a secure connection, which > it cannot do if it tolerates authentication of clearly obsolete and > forgeable certificates when it does not have to. (MD5 being the most brazen > example) For opportunistic TLS in SMTP, "secure" means unauthenticated encryption, for otherwise "secure" means "cleartext" and hope nobody is looking. Certificates are just useless baggage to make the protocol happy. There is no single all-encompassing security model, and it is important for this WG to not presume that a single model is sufficient. Yes, we're also trying to roll out DANE authentication for email, but that'll take time, and still protect a fraction of the traffic, with the majority doing just unauthenticated TLS for quite some time. Please start with a sensibly minimal proposal that achieves the essential goal of deprecating *trust* in SHA-1. Please do not overreach by requiring not sending SHA-1 or aborting when receiving SHA-1. This is adds nothing of value, just needlessly breaks legitimate (yes non-primary) TLS use-cases. Soon enough the trusted CAs will stop issuing certs with SHA-1 in them, and the problem goes away at that layer. Libraries that implement TLS 1.3 while doing PKIX authentication will help out by not trusting non-root certs with SHA-1, but will accept and process the peer's chain before deciding whether they can construct a trusted path to the leaf using any local certificate stores and whatever the server provided in addition. You need to step back and accept a reasonable compromise that makes progress without overreaching. I'm trying to help, but we must avoid collateral damage. What you think is "acceptable collateral damage" is harmful and unnecessary overreach. -- Viktor. From nobody Sun Oct 11 12:29:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB961B2D43 for ; Sun, 11 Oct 2015 12:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyK_T1pvkwud for ; Sun, 11 Oct 2015 12:29:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F0C1B2D40 for ; Sun, 11 Oct 2015 12:29:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nYtVr2JDnz3NL; Sun, 11 Oct 2015 21:29:24 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=YbEAv4s6 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id msuoxKF-xB-S; Sun, 11 Oct 2015 21:29:22 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 11 Oct 2015 21:29:22 +0200 (CEST) Received: from [193.111.228.71] (unknown [193.111.228.71]) by bofh.nohats.ca (Postfix) with ESMTPSA id E0DD280300; Sun, 11 Oct 2015 15:29:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1444591760; bh=TEDgmDwA7b4+5K7xcvBX02tYQY4PiMvLN+yqRBHIr6I=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=YbEAv4s6nFRCU2CSJrNKG4uNxIFzj6NrpZMcQWN2j5QFNNUWNpblfFHR4E0ldunws c/+b8TWVr11CtDhSHivdsUgF5m9ZTBKVXveG1RaHP+sZRHQvRMJWnEWayVkxEUHZ0/ YmA0EZHBZMvfCpbvhFA7zU8LSQ3mHgqsZNL82EdU= References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <47DCB916-0DD0-4A7D-8876-F77FB6E33502@nohats.ca> X-Mailer: iPhone Mail (13A344) From: Paul Wouters Date: Sun, 11 Oct 2015 15:29:11 -0400 To: Watson Ladd Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 19:29:30 -0000 > On Oct 11, 2015, at 09:46, Watson Ladd wrote: > > > I would suggest piggybacking on the PSK mode, using the key Kerberos > provides at both ends as the PSK key. This would address all of these > issues in TLS 1.3 > Which would also match how Kerberos is used in IKE/IPsec Paul From nobody Sun Oct 11 12:57:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5311A8F4F for ; Sun, 11 Oct 2015 12:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 F79LB5hLKSBc for ; Sun, 11 Oct 2015 12:57:46 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 E0D6B1A8F40 for ; Sun, 11 Oct 2015 12:57:45 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so126512551wic.1 for ; Sun, 11 Oct 2015 12:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=21LOX3TbOFZ2Kjm5zEs+EUhVp2+wzeNMhoHgb6storA=; b=AqId9nmdgxaaw6iUPfhArzfek0ziT6om+QEJWrzrWCVJztA0+HZg/GI958XwR88x2u vwoTOgwpN/ivD2zQcV4Up1Fb2ZarvAeqZWNX/Me/m9hiXTFPk721JP23qbjkVgcPRvgk W/ymp/AgKOx4ddeEWl6Yo9i6BOG320wTc0nj++pvSRm5rwts+EMzz0jJldQ9Rtu2wgOO ndToimSVPPCPl985NMKUdpFBwMHW7qxO78uUIMm7Z2bwqA5n4VnElxKWSXKVhUt1uFGm 6cXPgDL/aeLLu8oPxskWU6hFu6UfNf/brtzpm3Nsjx11DxqGfT9BfFVSB50BtepS/GzW g5QA== X-Received: by 10.180.10.101 with SMTP id h5mr9963842wib.22.1444593464405; Sun, 11 Oct 2015 12:57:44 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-178-5-101.red.bezeqint.net. [79.178.5.101]) by smtp.googlemail.com with ESMTPSA id eo5sm7977344wib.17.2015.10.11.12.57.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Oct 2015 12:57:43 -0700 (PDT) References: <20151011193517.30413.36864.idtracker@ietfa.amsl.com> From: Yaron Sheffer To: "tls@ietf.org" X-Forwarded-Message-Id: <20151011193517.30413.36864.idtracker@ietfa.amsl.com> Message-ID: <561ABF32.20008@gmail.com> Date: Sun, 11 Oct 2015 22:57:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151011193517.30413.36864.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-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 19:57:47 -0000 We have a standard for certificate pinning (RFC 7469), but it is rather hard to use and as a result is rarely deployed. This draft proposes a lightweight alternative that allows TLS clients to authenticate the server they're connecting to, even if a rogue CA can generate fake certificates for that server. The draft is currently TLS 1.3-only, and is based on the previous draft of 1.3 so some minor details may have changed. Comments are of course most welcome. Thanks, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt Date: Sun, 11 Oct 2015 12:35:17 -0700 From: internet-drafts@ietf.org To: Yaron Sheffer A new version of I-D, draft-sheffer-tls-pinning-ticket-00.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheffer-tls-pinning-ticket Revision: 00 Title: TLS Server Identity Pinning with Tickets Document date: 2015-10-11 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-00.txt Status: https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/ Htmlized: https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00 Abstract: Fake public-key certificates are an ongoing problem for users of TLS. Several solutions have been proposed, but none is currently in wide use. This document proposes to extend TLS with opaque tickets, similar to those being used for TLS session resumption, as a way to pin the server's identity. That is, to ensure the client that it is connecting to the right server even in the presence of corrupt certificate authorities and fake certificates. The main advantage of this solution 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 Sun Oct 11 12:59:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF7F1A9060 for ; Sun, 11 Oct 2015 12:59:48 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UpN8sw3RbKm for ; Sun, 11 Oct 2015 12:59:46 -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 460381A906C for ; Sun, 11 Oct 2015 12:59:46 -0700 (PDT) Received: by qkht68 with SMTP id t68so51824041qkh.3 for ; Sun, 11 Oct 2015 12:59:45 -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-type:content-transfer-encoding:message-id; bh=UUkSqjEoSNd3PEsUEHOhmJFtyg8dpOhtA/45KVgH+kY=; b=fda2Q3+9ACu+8V3asEdcnHW9UdZ8PrtrZQ5EG/2YvnBcUK+38yZXZOKfBjo3Vu49or zoBlT7GW8oLxMGZedhi+gYu0WQ0DzZ/13B1lWUNfQIlcWKacOPGaBpo8hYWPPHqaCXuC WvcHCQhaLYEDTPxw4Yru0dnnddDU62ZfEE/9vLOd9tcRWcd9c32W5fhEDP6iB55KMh+B XP+ZfAah9wOvs0gxFOtRBNU+I58TCvUwft3nNvJyF/ouJ6NV1odoNuIKmEGtEpeUZve5 mqUVy3ZyuiZz+52YyM1hFW+vHfztogfUnzOshfJY88PAhoPCn4Mje1NEuHfCp0xpA5jd BrOA== X-Received: by 10.55.19.211 with SMTP id 80mr26915125qkt.103.1444593585479; Sun, 11 Oct 2015 12:59:45 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id s87sm4404253qkl.5.2015.10.11.12.59.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 Oct 2015 12:59:44 -0700 (PDT) From: Dave Garrett To: Viktor Dukhovni Date: Sun, 11 Oct 2015 15:59:43 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <201510111324.37258.davemgarrett@gmail.com> <20151011181717.GE15070@mournblade.imrryr.org> In-Reply-To: <20151011181717.GE15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510111559.43946.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 19:59:48 -0000 On Sunday, October 11, 2015 02:17:17 pm Viktor Dukhovni wrote: > Please start with a sensibly minimal proposal that achieves the > essential goal of deprecating *trust* in SHA-1. Please do not > overreach by requiring not sending SHA-1 or aborting when receiving > SHA-1. This is adds nothing of value, just needlessly breaks > legitimate (yes non-primary) TLS use-cases. It's getting lost in the long replies, but again, we have already said we both agree with clients not aborting on receiving SHA-1 if trust doesn't rely on it. I am merely saying that TLS 1.3 servers should consider a certificate chain which does not rely on obsolete hashes as a prerequisite to use certificate authenticated cipher suites. Sorry, but I do not think this is unreasonable. Allowing otherwise is, in my view, an unnecessary risk and should not be the default assumption. With regard to MD5, I think it's reasonable to allow (not require) implementations to distrust based solely on that. Note that this is _reduced_ from the _current_ draft which has mandatory rejection of all MD5, as I agree that clarifying that ignoring it when not applicable (e.g. bonkers MD5 root) can be valid. > Soon enough the trusted CAs will stop issuing certs with SHA-1 in > them, and the problem goes away at that layer. Organizations can run their own CAs for private use. It's not just about the big public ones. Allowing TLS servers to send SHA-1-reliant chains means considering this to be valid forever. Someone should not be able to blindly upgrade their system to TLS 1.3 and not even notice that they're still sending SHA-1-reliant chains. One thing we should have all learned over the past couple years is that proper design requires making mistakes less possible, not merely labeling things as potentially unsafe and delegating them appropriately. > > If we consider the certificate authenticated cipher suite scenario within > > TLS to expect this to be the common case, then that gives the false > > impression that admins don't "have" to upgrade because they're "usable". > > Nothing of the sort. We've agreed that TLS 1.3 clients won't trust > SHA-1. We need to stop there. We have no choice. We might like > to be able to be beneficent dictators, but that's not an option. There's always a choice. Perpetuating all design assumptions in a 20 year old protocol ensures perpetuating all chronic flaws that it produces. Each layer cannot blindly trust the other and expect to work in a complex system. It's not that simple anymore. Case in point: HTTP/2 has a messy set of TLS restrictions because this WG decided against creating a TLS 1.2.1 it could require. Yes, it's not the application layer's role to be picking security settings like that, but the layer it relies on abdicated its role in maintaining a current version with a full set of known-safe configurations. Sure, we may want to "get it right" with TLS 1.3 to get ideal adoption rates, but that doesn't change the fact that HTTP had a problem with its security layer that it needed fixing. Likewise, we cannot safely trust the next layer down in full, because there is no overriding standard to mandate only known-safe configurations, so here we are debating how to best sanity-check cert chains. It's even messier than HTTP, as TLS is the one negotiating the supported algorithms here, so it is not even a fully separate layer. If the WG consensus agrees with your stance, so be it, but the only safe thing to do is to at least attempt to prohibit servers from considering SHA-1-reliant chains to be safe. (again, roots can do whatever & it's the hash reliance or presumption thereof, not cert itself, that's the issue) Dave From nobody Sun Oct 11 13:21:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E60D1A90F9 for ; Sun, 11 Oct 2015 13:21:38 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzb9JPMxxA6h for ; Sun, 11 Oct 2015 13:21:36 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 260221A90F6 for ; Sun, 11 Oct 2015 13:21:36 -0700 (PDT) Received: by qgt47 with SMTP id 47so107369185qgt.2 for ; Sun, 11 Oct 2015 13:21:35 -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-type:content-transfer-encoding:message-id; bh=MvlUk9ydrEUHnpYPoLV+H79v2ooZHnckv+mb7khNJ5w=; b=nfH8ZnjK5wigyGtOtyI7Q9aAa+z547rE9zpZrgwohQv+INFsUh9acIaQzqLX2UP1C5 9Q39IymUpRjzGoAe7KH/09Bt+bIj9jmw65kzcyjY2F2a0kpIK9V08U2Y5FbuWpdd2GaI 5TWDPiRNMs1ATkTx27cRO2jU8gzq5fQIkirjqDSPZi8lsGQu+gVPp3du1Sv8wtIIvLp3 MVlDZRBKEiz9NqLypvowY4fhDbhZO9BEJDmq3NBvIF//4iWauEp5yqOF3jWVkRu8qn/0 g40gC3f5voKl4860e5Ts6sJolKVzO9guIGMgiQ0zKxhzmPxzceiWM8vtczRpAtvTIyfc pcjA== X-Received: by 10.140.97.7 with SMTP id l7mr28638443qge.32.1444594895364; Sun, 11 Oct 2015 13:21:35 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id s19sm5739080qgd.27.2015.10.11.13.21.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 Oct 2015 13:21:34 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Yaron Sheffer Date: Sun, 11 Oct 2015 16:21:32 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151011193517.30413.36864.idtracker@ietfa.amsl.com> <561ABF32.20008@gmail.com> In-Reply-To: <561ABF32.20008@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510111621.32854.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 20:21:38 -0000 https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00#section-3 Your notation is incorrect. Please read the section on vectors carefully, as it *is* confusing and the notation is not what is usually assumed. I'll cite the TLS 1.2 spec as it has not changed: https://tools.ietf.org/html/rfc5246#section-4.3 For "type name;", the range [n,m] is always in _bytes_, not entry count. In particular, note the second example at the end of the vectors section: uint16 longer<0..800>; /* zero to 400 16-bit unsigned integers */ All 3 of your arrays of strings are listed with "<0..1>", which actually notates zero or one byte, not zero or one element. There is no way to explicitly state a range of allowed sizes by entry count with variable length entries, within this notation. Yes, this is not great and yes, this is often misunderstood. You'll have to mandate entry count with a "MUST" in the body of the text. No, it's probably not going to be changed any time soon, as that would contradict past specifications' notation. Maybe something like "type name[min_count..max_count];" could work, but that's probably not worth the confusion of introducing a new and more complex notation. On the actual topic of the proposal, I haven't looked into it in detail yet, but I am glad to see pinning being worked on at the TLS level. Dave On Sunday, October 11, 2015 03:57:38 pm Yaron Sheffer wrote: > We have a standard for certificate pinning (RFC 7469), but it is rather > hard to use and as a result is rarely deployed. This draft proposes a > lightweight alternative that allows TLS clients to authenticate the > server they're connecting to, even if a rogue CA can generate fake > certificates for that server. > > The draft is currently TLS 1.3-only, and is based on the previous draft > of 1.3 so some minor details may have changed. > > Comments are of course most welcome. > > Thanks, > Yaron > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-sheffer-tls-pinning-ticket-00.txt > Date: Sun, 11 Oct 2015 12:35:17 -0700 > From: internet-drafts@ietf.org > To: Yaron Sheffer > > > A new version of I-D, draft-sheffer-tls-pinning-ticket-00.txt > has been successfully submitted by Yaron Sheffer and posted to the > IETF repository. > > Name: draft-sheffer-tls-pinning-ticket > Revision: 00 > Title: TLS Server Identity Pinning with Tickets > Document date: 2015-10-11 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-00.txt > Status: > https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/ > Htmlized: > https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00 > > > Abstract: > Fake public-key certificates are an ongoing problem for users of TLS. > Several solutions have been proposed, but none is currently in wide > use. This document proposes to extend TLS with opaque tickets, > similar to those being used for TLS session resumption, as a way to > pin the server's identity. That is, to ensure the client that it is > connecting to the right server even in the presence of corrupt > certificate authorities and fake certificates. The main advantage of > this solution 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 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun Oct 11 13:48:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3883A1A1B53 for ; Sun, 11 Oct 2015 13:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3MT3vvJzzDW for ; Sun, 11 Oct 2015 13:48:13 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0131A1B44 for ; Sun, 11 Oct 2015 13:48:13 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 40772F984; Sun, 11 Oct 2015 16:48:11 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id F0B451FFED; Sun, 11 Oct 2015 16:48:10 -0400 (EDT) From: Daniel Kahn Gillmor To: Yaron Sheffer , "tls\@ietf.org" In-Reply-To: <561ABF32.20008@gmail.com> References: <20151011193517.30413.36864.idtracker@ietfa.amsl.com> <561ABF32.20008@gmail.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 11 Oct 2015 16:48:06 -0400 Message-ID: <877fmtt9mh.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] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 20:48:15 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Yaron-- On Sun 2015-10-11 15:57:38 -0400, Yaron Sheffer wrote: > We have a standard for certificate pinning (RFC 7469), but it is rather=20 > hard to use and as a result is rarely deployed. This draft proposes a=20 > lightweight alternative that allows TLS clients to authenticate the=20 > server they're connecting to, even if a rogue CA can generate fake=20 > certificates for that server. > > The draft is currently TLS 1.3-only, and is based on the previous draft=20 > of 1.3 so some minor details may have changed. I've only just skimmed thus far, but i'm happy to see this proposal. A few comments below: TACK =2D--- As you note in the draft, it addresses a similar problem as TACK, which never made it through the standards process: http://tack.io/draft-tack.html perhaps it would be useful to have a section next to the Comparison: HPKP that included a Comparison: TACK ? (dis)similarity to session tickets =2D--------------------------------- In the session-ticket case, most servers (clustered or otherwise) can afford to treat their session ticket master keys as ephemeral keys -- if the server is restarted or dies and is re-installed, the worst that happens is that a client doesn't get to resume their session -- they have to open a new connection. If the session ticket resumption master keys are used as recommended here, it seems like the risk of master key loss is bricking the server, so the master key becomes necessary to store non-ephemerally. Writing the master key to disk or storing it off-site someplace can present a risk to the forward-secrecy of ticket-resumed sessions. tracking the master key itself seems like it also adds specific operational overhead for server maintainers that doesn't currently exist. Does this reduce the advantage of the scheme over TACK or HPKP? if not, can you explain why not? Client Privacy =2D------------- section 6.6 says "TODO", and page 5 says: > The main reason for refreshing the ticket on each connection is > privacy: to avoid the ticket serving as a fixed client > identifier. It is RECOMMENDED to include a fresh ticket with > each response. If the participating client wants privacy from the server (to avoid the server using this to track the client) but also wants defense against broken CAs, how does recomending this behavior from the server actually allow the client to enforce privacy? The server is trivially capable of tying together a history of pinning_ticket objects to track specific clients, right? it just remembers the two tickets involved every time it generates a PinningTicket extension. If the pinning tickets returned by the server are different each time, the client cannot know whether the server is doing this tracking or not. public key vs. certificate =2D------------------------- In your introduction (and in the mail above), you refer to "certificate pinning" -- but i don't think there is anything out there that is "certificate pinning" -- HPKP is public key pinning, and it ignores the certificates that wrap any given public key. So your tables should really refer to "main public key" and "backup public key", not "main certificate" or "backup certificate". HPKP example workflow =2D-------------------- Your HPKP timeline seems to assume that your "old backup certificate" can't be used as your "new main certificate" -- what makes you say this? I agree with you that HPKP end-entity pinning generally makes more sense (and is more useful at defending against malicious/incompetent CAs) than authority pinning. But I'd expect an HPKP timeline using end-entity pinning to be more like: lower-case letters are public keys. we presume that the site administrator has the corresponding secret keys backed up offsite/offline somewhere, and the associated certs and secret keys needed to operate the web site get deployed as needed. Initial deployment: HPKP: { a, b } Cert: A =3D X.509-wrapped(a)=20=20 as A approaches expiry, we generate a new key c (storing its secret key offline), get a new cert made over b, and switch to: HPKP: { b, c } Cert: B =3D X.509-wrapped(b) As B approaches expiry, we do the same dance, generating d and making a cert over c: HPKP: { c, d } Cert: C =3D X.509-wrapped(c) and so on. Does this simpler cycle change your analysis of HPKP? I tend to think HPKP deployment has been slow because: (a) the risk of bricking the site makes admins (justifiably) nervous (b) having to have an additional offsite store (of your HPKP backup secret key) to avoid site-bricking is a workflow that most admins don't already have in place. But i don't think your proposal addresses these issues either (though the data stored offsite for (b) is slightly different between your proposal and HPKP). Does it address them in some way that i'm missing? Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJWGssIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcGsoP/1g7XrmpnzT7oMFxify+cq2j Z6m2cMmp9uVZNfRnUm5aC5ZNkWsqQ+T8q8L018LJzC94kw1M4mIFeGcU2ZTepdOq PWUc71ulCP1RxvzLE/y1s9lvqVUCjL514/uXdSwUFvKlR7jqQvtV1fVy/KFKQ+i4 Z7R+3xNebUpvqMLTELxN9q4gbhXGZCYT0wUbWmLgR35nuQ1F8BjFcYLtOJKXtmVt DjKUYxEpy0FQ+CAoFFdO7SOIRJ0Bj7JHCjhYWHoPc9Hr/UekCqI4PTRzlDcPok76 490tEAy9L6Kei9DOJ7lX42B+lYF30G0jzjq5NbvYWb1V78IZky95v2Dsp29BHNFS m8Hx/aMJCfqDVvO/ZcFhoLp7BMaxhlYNlRElr46+DVBOov297P0Ht0R3nXGgNdgA TBuOKjaYCFIlyVzuFkEFf8SZmRJLEHsQ/0O51SjwpBjFpSSXTvKUpCFWlLOPf8rB mIE3ghxkln5Ehy55sWcmpxHYcawQQz01ryv1CzQS85KBpfBcGSMGaAWlIGhDuFtB iENQEmtwLfEnQxnWPthxrNBh7RYqyonx0sjNq7uCQ+pmJyaEBxXnoIJ+ZUWmeAqU fdABOX1166N6k2gFNMzbJL02LOyDlQKVTFKHjhXTsUo71dGPjGF4rC/Pcbqs3HDx G7TIRG+nci0f5PCpWjPa =u+vt -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 11 14:17:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418E11B2C19 for ; Sun, 11 Oct 2015 14:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 Hkvebh5J6bSK for ; Sun, 11 Oct 2015 14:17:12 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450: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 993741B2C13 for ; Sun, 11 Oct 2015 14:17:12 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so130049177wic.1 for ; Sun, 11 Oct 2015 14:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=ndE16uk3TPTRGIv8K32J9RshIbUUEvR/wNat9wYelnE=; b=PJEn+pawqxGKeG7rUE2PXkchDxcz3dhMeOPQ9rR8/co/S50ob2WhrCq0PWYfWOXycR oBHm4DIgrpzKqotCMiTNf/vVPn9GzazhgrJodeMAVgN7yUQWNua9LQSc0knbkjv2hrcK EfU+DaMSNUatqot82Xl/tmzUwClk5t6WndBKIURs6Mjz6K9duclwYzDn7OWfZdXsONNc 9mtKsYHI5lWHKlUELxkg34xGtYYaw68MfPQivmgc0tVndoUdNBXzpwnVScO2sn04qiYH o9IbkQyl3cLbeeBx9/ZpGZtdyX2K3cxFeMhD8baAljAAzBbhCNEn7rXt4skfPIMkRErQ iLNQ== X-Received: by 10.194.113.67 with SMTP id iw3mr11706234wjb.66.1444598231178; Sun, 11 Oct 2015 14:17:11 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-178-5-101.red.bezeqint.net. [79.178.5.101]) by smtp.googlemail.com with ESMTPSA id o3sm8180665wif.22.2015.10.11.14.17.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Oct 2015 14:17:10 -0700 (PDT) To: Dave Garrett , tls@ietf.org References: <20151011193517.30413.36864.idtracker@ietfa.amsl.com> <561ABF32.20008@gmail.com> <201510111621.32854.davemgarrett@gmail.com> From: Yaron Sheffer Message-ID: <561AD1D3.7030100@gmail.com> Date: Mon, 12 Oct 2015 00:17:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201510111621.32854.davemgarrett@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 21:17:14 -0000 Hi Dave, Thanks for correcting my notation. The text in TLS 1.2 and 1.3 is confusing and I misunderstood it. This sentence is absolutely opaque to me: "The length will be in the form of a number consuming as many bytes as required to hold the vector's specified maximum (ceiling) length." Regards, Yaron On 10/11/2015 11:21 PM, Dave Garrett wrote: > https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00#section-3 > > Your notation is incorrect. Please read the section on vectors carefully, as it *is* confusing and the notation is not what is usually assumed. I'll cite the TLS 1.2 spec as it has not changed: > https://tools.ietf.org/html/rfc5246#section-4.3 > > For "type name;", the range [n,m] is always in _bytes_, not entry count. In particular, note the second example at the end of the vectors section: > uint16 longer<0..800>; > /* zero to 400 16-bit unsigned integers */ > > All 3 of your arrays of strings are listed with "<0..1>", which actually notates zero or one byte, not zero or one element. There is no way to explicitly state a range of allowed sizes by entry count with variable length entries, within this notation. Yes, this is not great and yes, this is often misunderstood. You'll have to mandate entry count with a "MUST" in the body of the text. > > No, it's probably not going to be changed any time soon, as that would contradict past specifications' notation. Maybe something like "type name[min_count..max_count];" could work, but that's probably not worth the confusion of introducing a new and more complex notation. > > On the actual topic of the proposal, I haven't looked into it in detail yet, but I am glad to see pinning being worked on at the TLS level. > > > Dave > > > On Sunday, October 11, 2015 03:57:38 pm Yaron Sheffer wrote: >> We have a standard for certificate pinning (RFC 7469), but it is rather >> hard to use and as a result is rarely deployed. This draft proposes a >> lightweight alternative that allows TLS clients to authenticate the >> server they're connecting to, even if a rogue CA can generate fake >> certificates for that server. >> >> The draft is currently TLS 1.3-only, and is based on the previous draft >> of 1.3 so some minor details may have changed. >> >> Comments are of course most welcome. >> >> Thanks, >> Yaron >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for >> draft-sheffer-tls-pinning-ticket-00.txt >> Date: Sun, 11 Oct 2015 12:35:17 -0700 >> From: internet-drafts@ietf.org >> To: Yaron Sheffer >> >> >> A new version of I-D, draft-sheffer-tls-pinning-ticket-00.txt >> has been successfully submitted by Yaron Sheffer and posted to the >> IETF repository. >> >> Name: draft-sheffer-tls-pinning-ticket >> Revision: 00 >> Title: TLS Server Identity Pinning with Tickets >> Document date: 2015-10-11 >> Group: Individual Submission >> Pages: 14 >> URL: >> https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/ >> Htmlized: >> https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00 >> >> >> Abstract: >> Fake public-key certificates are an ongoing problem for users of TLS. >> Several solutions have been proposed, but none is currently in wide >> use. This document proposes to extend TLS with opaque tickets, >> similar to those being used for TLS session resumption, as a way to >> pin the server's identity. That is, to ensure the client that it is >> connecting to the right server even in the presence of corrupt >> certificate authorities and fake certificates. The main advantage of >> this solution 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 >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> From nobody Sun Oct 11 14:59:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EB51B2E11 for ; Sun, 11 Oct 2015 14:59:26 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bglNmRhMqm_w for ; Sun, 11 Oct 2015 14:59:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18061B2E0C for ; Sun, 11 Oct 2015 14:59:23 -0700 (PDT) Received: from [10.28.0.21] (11.sub-70-209-145.myvzw.com [70.209.145.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1495C282F89; Sun, 11 Oct 2015 21:59:22 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Viktor Dukhovni In-Reply-To: <201510111559.43946.davemgarrett@gmail.com> Date: Sun, 11 Oct 2015 17:58:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7EB6726D-39A6-47B1-9E3A-A40C7826CAAB@dukhovni.org> References: <201510101337.29335.davemgarrett@gmail.com> <201510111324.37258.davemgarrett@gmail.com> <20151011181717.GE15070@mournblade.imrryr.org> <201510111559.43946.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.2104) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 21:59:26 -0000 > On Oct 11, 2015, at 3:59 PM, Dave Garrett = wrote: >=20 > On Sunday, October 11, 2015 02:17:17 pm Viktor Dukhovni wrote: >> Please start with a sensibly minimal proposal that achieves the >> essential goal of deprecating *trust* in SHA-1. Please do not >> overreach by requiring not sending SHA-1 or aborting when receiving >> SHA-1. This is adds nothing of value, just needlessly breaks >> legitimate (yes non-primary) TLS use-cases. >=20 > It's getting lost in the long replies, but again, we have already said = we both agree with clients not aborting on receiving SHA-1 if trust = doesn't rely on it. Excellent, I'm ready to +1 a PR that says just that and no more for = clients. > I am merely saying that TLS 1.3 servers should consider a certificate = chain which does not rely on obsolete hashes as a prerequisite to use = certificate authenticated cipher suites. Sorry, but I do not think this = is unreasonable. Allowing otherwise is, in my view, an unnecessary risk = and should not be the default assumption. Well, since anon_DH suites just got removed, and not all servers support = them anyway, clients that don't check certificates will still request = "certificate authenticated ciphesuites". So the server has no idea = whether its certificates are relevant or not, and must not prevent their = transmission if that's all it has. > With regard to MD5, I think it's reasonable to allow (not require) = implementations to distrust based solely on that. Note that this is = _reduced_ from the _current_ draft which has mandatory rejection of all = MD5, as I agree that clarifying that ignoring it when not applicable = (e.g. bonkers MD5 root) can be valid. We improve nothing by restricting the content of chain elements that are = not used to build trust. This just promotes the kind of needless = failures that I see with opportunistic TLS in Schannel. Sometimes more = is less and less is more. Pointless restrictions lead to fallback to even worse choices. >> Soon enough the trusted CAs will stop issuing certs with SHA-1 in >> them, and the problem goes away at that layer. >=20 > Organizations can run their own CAs for private use. It's not just = about the big public ones. Allowing TLS servers to send SHA-1-reliant = chains means considering this to be valid forever. Yes, but they won't be trusted per the core limitation we've already = agreed on. The remaining issue is whether to prohibit the transmission = of such chains, and the answer is an unequivocal NO. Not trusting is = plainly sufficient, and strictly better, by not breaking (downgrading) = use-cases in which the certificates are otherwise ignored. > Someone should not be able to blindly upgrade their system to TLS 1.3 = and not even notice that they're still sending SHA-1-reliant chains. One = thing we should have all learned over the past couple years is that = proper design requires making mistakes less possible, not merely = labeling things as potentially unsafe and delegating them appropriately. They'll notice right away if the client stops trusting them and is doing = authentication. If the client was not doing authentication it will = continue to not do authentication (ignore the certs regardless of the = signature algorithm). In your zeal to stamp out SHA-1 you're not going through the case = analysis to see that prohibiting less is strictly better. >> Nothing of the sort. We've agreed that TLS 1.3 clients won't trust >> SHA-1. We need to stop there. We have no choice. We might like >> to be able to be beneficent dictators, but that's not an option. >=20 > There's always a choice. Perpetuating all design assumptions in a 20 = year old protocol ensures perpetuating all chronic flaws that it = produces. Each layer cannot blindly trust the other and expect to work = in a complex system. It's not that simple anymore. Yes, we could publish a protocol that shoots itself in the foot and = achieves strictly less security than it otherwise would, and would be = less interoperable. I'm not going to sit idly by and let that happen. = Expect objections at every step of the way... > Case in point: HTTP/2 has a messy set of TLS restrictions because this = WG decided against creating a TLS 1.2.1 it could require. Yes, it's not = the application layer's role to be picking security settings like that, = but the layer it relies on abdicated its role in maintaining a current = version with a full set of known-safe configurations. Sure, we may want = to "get it right" with TLS 1.3 to get ideal adoption rates, but that = doesn't change the fact that HTTP had a problem with its security layer = that it needed fixing. Likewise, we cannot safely trust the next layer = down in full, because there is no overriding standard to mandate only = known-safe configurations, so here we are debating how to best = sanity-check cert chains. It's even messier than HTTP, as TLS is the one = negotiating the supported algorithms here, so it is not even a fully = separate layer. We're not reasoning by tenuous analogy. The proposal you make reduces = security, and needs to not move forward. > If the WG consensus agrees with your stance, so be it, but the only = safe thing to do is to at least attempt to prohibit servers from = considering SHA-1-reliant chains to be safe. (again, roots can do = whatever & it's the hash reliance or presumption thereof, not cert = itself, that's the issue) Once clients don't get to advertise SHA-1 in supported algorithms, = servers will use SHA-1 only when they have nothing else to offer. This = is enough. A much shorter PR solves the problem, the rest really is = just overreach. Clients that do the "authentication" in "certificate authenticated = ciphersuites" will object to SHA-1 if essential to the chain. Clients = that don't do the "authentication" don't get their connections broken if = the server has nothing better. Breaking opportunistic TLS connections typically leads to cleartext = fallback (not progress). Where's the win in you're proposing beyond a = "feel good" posture that've deprecated SHA-1 "harder". (Sorry to be a = bit blunt, but this really is NOT personal, I have a lot of respect for = all your hard work in many other PRs, I'm just trying to get this one = point across in some manner that will get through). --=20 Viktor. From nobody Sun Oct 11 16:13:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916871B2EC2 for ; Sun, 11 Oct 2015 16:13:08 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PNSzoKs63YL for ; Sun, 11 Oct 2015 16:13:07 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 1EDEC1B2EBF for ; Sun, 11 Oct 2015 16:13:07 -0700 (PDT) Received: by qgx61 with SMTP id 61so109075110qgx.3 for ; Sun, 11 Oct 2015 16:13:06 -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-type:content-transfer-encoding:message-id; bh=ugOKiPgV2eFPA6lbflrpHhRhznCvGKIp9Hpqn9LjxKw=; b=VTKMwOuIM+/JirmbxDjctARSlPhjXyvKvSIqqyjYR2AYh8SXxWqRQA0H5JB8l72Ifw 3e9EE+HNGGRZfRnZakIfFGo3TOrB7BZiGZwr4CQPK+mCdvmXgfe2bHm2cLebTBnDAkC2 c0UsZ3gyT6UJYO2PdN6UtNmK4X3OLj2MUlNB+y+dRH9PGJxdO8JhHZEWSSBr2ZpnIty4 fHmrSCvd7+nF/9ftN1V/xKRyZCW/yinq5/bZafMRVBcLSenuF+TQ4xspyRmBc/Hzj+EM Mdz501RUV84SlcQMGpRAPmCETefINyMaaxY/fPPtKbZeEhFlKOH0k0ZW8BN0WlG8+SSq RCrw== X-Received: by 10.140.106.180 with SMTP id e49mr29261913qgf.45.1444605186275; Sun, 11 Oct 2015 16:13:06 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id z19sm6026974qge.38.2015.10.11.16.13.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 Oct 2015 16:13:05 -0700 (PDT) From: Dave Garrett To: Viktor Dukhovni Date: Sun, 11 Oct 2015 19:13:03 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <201510111559.43946.davemgarrett@gmail.com> <7EB6726D-39A6-47B1-9E3A-A40C7826CAAB@dukhovni.org> In-Reply-To: <7EB6726D-39A6-47B1-9E3A-A40C7826CAAB@dukhovni.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510111913.04247.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2015 23:13:08 -0000 On Sunday, October 11, 2015 05:58:59 pm Viktor Dukhovni wrote: > Pointless restrictions lead to fallback to even worse choices. And no restrictions lead to horrible fallback choices. Running under the assumption that some population of implementors is willing to do something stupid to maintain inertia (e.g. insecure version fallback dance), sending SHA1 certs is a risk. Yes, the server doesn't know whether the client can or cannot deal with it safely, but we, from the perspective of the spec, should be assuming bad scenarios when designing things. > Yes, but they won't be trusted per the core limitation we've already agreed on. The remaining issue is whether to prohibit the transmission of such chains, and the answer is an unequivocal NO. Not trusting is plainly sufficient, and strictly better, by not breaking (downgrading) use-cases in which the certificates are otherwise ignored. A wording change might be helpful here. Instead of no sending of SHA1 certs: 1) SHA1 signatures must not be trusted 2) servers must not send cert chains they do not trust Yes, I know you'll say that the client can of course trust things the server might not be able to, but the core of what I'm concerned about is servers making an attempt to get clients to accept a chain it knows very well is not trustworthy and thus encourage implementations to accept it anyway. > They'll notice right away if the client stops trusting them and is doing authentication. "if" If servers keep on sending SHA1 indefinitely, we risk clients keep on accepting SHA1 indefinitely, no matter what it says in the spec. > In your zeal to stamp out SHA-1 you're not going through the case analysis to see that prohibiting less is strictly better. Clearly we are both analyzing the scenarios here, but coming to different conclusions based on different assumptions and priorities. Same goal; different approach. > Once clients don't get to advertise SHA-1 in supported algorithms, servers will use SHA-1 only when they have nothing else to offer. If servers still commonly send SHA-1, then clients will never stop offering support for it. > Breaking opportunistic TLS connections typically leads to cleartext fallback (not progress). Prohibiting TLS 1.3 implementations from using SHA1 certs does not break OE. TLS 1.2 does not cease to exist, and an server implementation can happily run in a TLS 1.2 only mode until both the TLS implementation and cert chain are upgraded. > Where's the win in you're proposing beyond a "feel good" posture that've deprecated SHA-1 "harder". My goal is to have fewer systems using SHA1 within a reasonable timeframe. The current TLS 1.3 draft completely delegates that issue away in a manner which does not put any onus on servers to upgrade, instead relying entirely on unspecified outside forces to deal with the issue (e.g. CA/Browser Forum; clients hopefully saying no, eventually). Dave From nobody Sun Oct 11 17:00:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ABB1B2F15 for ; Sun, 11 Oct 2015 17:00:48 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI0xp0xWCPyN for ; Sun, 11 Oct 2015 17:00:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AAE1B2F14 for ; Sun, 11 Oct 2015 17:00:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CD776284B56; Mon, 12 Oct 2015 00:00:45 +0000 (UTC) Date: Mon, 12 Oct 2015 00:00:45 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151012000045.GF15070@mournblade.imrryr.org> References: <201510101337.29335.davemgarrett@gmail.com> <201510111559.43946.davemgarrett@gmail.com> <7EB6726D-39A6-47B1-9E3A-A40C7826CAAB@dukhovni.org> <201510111913.04247.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510111913.04247.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 12 Oct 2015 00:00:49 -0000 On Sun, Oct 11, 2015 at 07:13:03PM -0400, Dave Garrett wrote: > A wording change might be helpful here. Instead of no sending of SHA1 certs: > 1) SHA1 signatures must not be trusted Excellent. > 2) servers must not send cert chains they do not trust Pointless overreach that breaks things. > Yes, I know you'll say that the client can of course trust things the > server might not be able to, but the core of what I'm concerned about is > servers making an attempt to get clients to accept a chain it knows very > well is not trustworthy and thus encourage implementations to accept it > anyway. You're still ignoring the fact that in many environments the client (correctly) does not validate the chain via trust-anchors of any kind, so signatures of certificates by some "issuer" are of interest to the client. There is no reason for the server to avoid sending the chain even if some "signer" in the chain happened to use SHA-1. At a minimum a leaf cert signed with SHA-1 may still be valid by means other than trust of its signature. > > They'll notice right away if the client stops trusting them and is doing authentication. > > "if" > If servers keep on sending SHA1 indefinitely, we risk clients keep on accepting SHA1 indefinitely, no matter what it says in the spec. Some implementations might even ignore any misguided text telling them to not send the chain. :-) We can't design for non-conformant implementations. You sure want that cherry on top. However right it might feel, it would still be counterproductive. > > Once clients don't get to advertise SHA-1 in supported algorithms, servers will use SHA-1 only when they have nothing else to offer. > > If servers still commonly send SHA-1, then clients will never stop offering support for it. No, that conclusion is unwarranted. TLS 1.3 clients will not trust SHA-1. All the key implementors are reading this interminable thread. They understand the issues. If we get consensus for at least the minimal version (no trust in SHA-1) we're done. There's no reason for pessimism, we're not trying to deprecated deployed functionality, there is no TLS 1.3 deployed base. We can start "clean" and keep it that way. > > Breaking opportunistic TLS connections typically leads to cleartext > > fallback (not progress). > > Prohibiting TLS 1.3 implementations from using SHA1 certs does not break > OE. It does when the SHA-1 leaf certificate is pinned, and/or the server has nothing else to send, and its clients rightly don't care. > > Where's the win in you're proposing beyond a "feel good" posture that've deprecated SHA-1 "harder". > > My goal is to have fewer systems using SHA1 within a reasonable timeframe. That happens automatically in the minimal version of the PR. 1. Recall that the SHA-1 certs are not trusted by TLS 1.3 clients, so the vast majority of servers will need SHA2-256 certs. 2. Recall that public CAs are phasing out SHA-1 certs sooner than a non-negligible number of systems is likely to deploy TLS 1.3 > The current TLS 1.3 draft completely delegates that issue away in a manner > which does not put any onus on servers to upgrade, instead relying entirely > on unspecified outside forces to deal with the issue (e.g. CA/Browser > Forum; clients hopefully saying no, eventually). We've agreed to require clients to not trust SHA-1 signatures. That's quite enough, and is a smaller, simpler change. -- Viktor. From nobody Sun Oct 11 19:33:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4868F1B2FDD for ; Sun, 11 Oct 2015 19:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 N6CqxzvTeKgF for ; Sun, 11 Oct 2015 19:33:51 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 9FD371B2FDF for ; Sun, 11 Oct 2015 19:33:49 -0700 (PDT) Received: by lbbk10 with SMTP id k10so17089779lbb.0 for ; Sun, 11 Oct 2015 19:33:47 -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:content-type; bh=7p9mFme9KpJ9wEeKOspQBr6QAfX8Fs+7mRIZ8TWI1tU=; b=jI/Ee/3aDf/TAzeobLVOCAN0Eis0D7/d2oidXUCcZJH2+miAZJmmCw0gR/X/ZJSHXD rooF2afQKqyVxGaI2I4QBd23aR5eUCiBB8CSgLAlZII4V1cHMJHaTOQIgHqA/d7CVLjh Nj3G8klHU5ZSIZpfjsW8KRqMgZrzC3Zmm6HLa0DIaPAz6MOT4ya+2KYsPmQzaw8dmd1/ 2sKYaDLtJzv9/99lEC24MlDmqP08lm1G2tfHlt1oqnoAiZs0GRGtZRrX/BS34h/KGb0y GZzBendU+OGnkKwtPFLogfZLDsgDqcuKziwj5FKFaQH+0/FutXi41xpbE6WLHk7AvK80 JOzw== X-Received: by 10.112.155.195 with SMTP id vy3mr11445173lbb.9.1444617227766; Sun, 11 Oct 2015 19:33:47 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.3.6 with HTTP; Sun, 11 Oct 2015 19:33:18 -0700 (PDT) In-Reply-To: References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> From: Hugo Krawczyk Date: Sun, 11 Oct 2015 22:33:18 -0400 X-Google-Sender-Auth: fdJitfcGWjIOkneiT7EcXHAYFdI Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e0115ff2ab2982f0521df2804 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 02:33:54 -0000 --089e0115ff2ab2982f0521df2804 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 11, 2015 at 9:46 AM, Watson Ladd wrote: > On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara > wrote: > > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote: > >> > *From:* internet-drafts@ietf.org > >> > > >> > Name: draft-vanrein-tls-kdh > >> > Revision: 00 > >> > >> Hello TLS WG, > >> > >> I would like to propose new CipherSuites for TLS. The cryptography is > >> founded on Kerberos authentication and DH encryption, cryptographically > >> bound together. The mechanism uses mutual authentication, although > >> clients may use anonymous tickets. > >> > >> Any feedback that you may have (technical, or WG-procedural) is kindly > >> welcomed. I will also send this to the Kitten WG. > > > > Some quick comments: > > - The signed DH share does not look to be bound to anything (crypto > > parameters negotiation, randoms, server key exchange, etc..). I can't > > offhand say what that would lead to, but it looks even worse than > > TLS ServerKeyExchange, which has known vulernabilities due to > > lack of binding to things like ciphersuite. > > - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC > > (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. > > - Even use of DH is questionable. > > I would suggest piggybacking on the PSK mode, using the key Kerberos > provides at both ends as the PSK key. This would address all of these > issues in TLS 1.3 > That's the right solution and this is why we need modular designs with generic security (generic = not tailored to a specific use case). It allows you to accommodate cases you did not necessarily think about when designing the protocol. Hugo > Sincerely, > Watson > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e0115ff2ab2982f0521df2804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 11, 2015 at 9:46 AM, Watson Ladd <wat= sonbladd@gmail.com> wrote:
= On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
<ilariliusvaara@welho.com> wrote:
> On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
>> > *From:* internet-= drafts@ietf.org
>> >
>> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-vanrein-tls-kdh
>> > Revision:=C2=A0 =C2=A000
>>
>> Hello TLS WG,
>>
>> I would like to propose new CipherSuites for TLS.=C2=A0 The crypto= graphy is
>> founded on Kerberos authentication and DH encryption, cryptographi= cally
>> bound together.=C2=A0 The mechanism uses mutual authentication, al= though
>> clients may use anonymous tickets.
>>
>> Any feedback that you may have (technical, or WG-procedural) is ki= ndly
>> welcomed.=C2=A0 I will also send this to the Kitten WG.
>
> Some quick comments:
> - The signed DH share does not look to be bound to anything (crypto >=C2=A0 =C2=A0parameters negotiation, randoms, server key exchange, etc.= .). I can't
>=C2=A0 =C2=A0offhand say what that would lead to, but it looks even wor= se than
>=C2=A0 =C2=A0TLS ServerKeyExchange, which has known vulernabilities due= to
>=C2=A0 =C2=A0lack of binding to things like ciphersuite.
> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC
>=C2=A0 =C2=A0(don't use), apparent SHA-1 prf-hash (REALLY bad idea)= [1][2].
> - Even use of DH is questionable.

I would suggest piggybacking on the PSK mode, using the key Kerberos=
provides at both ends as the PSK key. This would address all of these
issues in TLS 1.3

That's the right solution and this is why we need modular designs = with generic security (generic =3D not tailored to a specific use case). It= allows you to accommodate cases you did not necessarily think about when d= esigning the protocol.

Hugo


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Sincerely,
Watson

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

--089e0115ff2ab2982f0521df2804-- From nobody Sun Oct 11 19:41:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80B81B2FE7 for ; Sun, 11 Oct 2015 19:41:48 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDWc-SqySsMu for ; Sun, 11 Oct 2015 19:41:47 -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 5C3481B2FE4 for ; Sun, 11 Oct 2015 19:41:47 -0700 (PDT) Received: by qkht68 with SMTP id t68so53816834qkh.3 for ; Sun, 11 Oct 2015 19:41:46 -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-type:content-transfer-encoding:message-id; bh=aojZYCr2lcSUlTE/aU4f3LqUiFQGz61ECfySPtu5+ak=; b=oa9XeJq/Vh+9nBqGbBa6tOfmU0+WVt4fH7Gzc84f8eDFshWF3MzVy2PPdZJtw9L65a FF+iXpE2fhwrrqr15FkEJWi3achRdxvuqy+t2HtOdTMgoRXhYO3M3HkonrSP/FypICbC D/5f2jAc8DtZFJNwmNXV4xHIKho4aAPkfyjhJnNVpTj+1HPxfeGL5uzXoTSU0njjFj2P 8KQ+mcp09dIJAXrSJODZKTpELdk8JSyp/E549h8j3t59ickfPR5sYlV7+6zdyzz5ze4E IFVUldwn+3C1eJ9JznrgIFI1WydaUd3/HhfPO8n1PbFspDlq06FmQIeicL4ufIi5fB3g k+LQ== X-Received: by 10.55.214.80 with SMTP id t77mr29072946qki.101.1444617706517; Sun, 11 Oct 2015 19:41:46 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 65sm6305174qhu.11.2015.10.11.19.41.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 Oct 2015 19:41:46 -0700 (PDT) From: Dave Garrett To: Viktor Dukhovni Date: Sun, 11 Oct 2015 22:41:44 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <201510111913.04247.davemgarrett@gmail.com> <20151012000045.GF15070@mournblade.imrryr.org> In-Reply-To: <20151012000045.GF15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510112241.44817.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 02:41:49 -0000 On Sunday, October 11, 2015 08:00:45 pm Viktor Dukhovni wrote: > There's no reason for pessimism Sorry, I have to laugh a bit here. :p > we're not trying to deprecated deployed > functionality, there is no TLS 1.3 deployed base. Due to the fact that the vast majority of TLS implementations that will be used are going to be existing ones, upgraded to support TLS 1.3, yes we are deprecating deployed functionality for that implementation as well as their users. > > Prohibiting TLS 1.3 implementations from using SHA1 certs does not break > > OE. > > It does when the SHA-1 leaf certificate is pinned, and/or the server > has nothing else to send, and its clients rightly don't care. In the second case, a correct course of action for the server would be to send an incomplete or outright empty certificate_list fallback, in which case the clients that don't care will be fine with it. Pinning a SHA1 end-entiy (leaf) cert rather than an intermediate just seems like a bad idea that you can't expect to work forever. In cases where the server can't handle lack of SHA1, then my response is to fix that before upgrading TLS. > > My goal is to have fewer systems using SHA1 within a reasonable timeframe. > > That happens automatically in the minimal version of the PR. We're both trying to predict possible futures with different thought processes. I'm concerned that the simpler course is too slow, _not_ because we need to rush to get rid of SHA1 certs ASAP, but because going slower requires keeping SHA-1 around in implementations in the interim. Even requiring settings and code for an algorithm at all poses an attack surface by itself (we had attacks on supposedly disabled features over the past year). Every known vulnerable feature is one which we have to be wary of getting re-enabled or left on accidentally. I consider this risk to be high enough to not rely on delegation to another layer; you think that delegation cannot be changed without excessive interop risk. I'll post a follow-up question to the WG (with a changed title, as our discussion here got long) with the options phrased as a question with 3 main choices (including the option of doing nothing new). If there's no support for a full drop in SHA-1 support under the new version, then there won't be a point in pushing for it further, unless there's yet another SHA-1 revelation in the near future. Dave From nobody Sun Oct 11 19:43:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD4E1B2FED for ; Sun, 11 Oct 2015 19:43:08 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuFC_85cNgBy for ; Sun, 11 Oct 2015 19:43:07 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 C00671B2FEB for ; Sun, 11 Oct 2015 19:43:06 -0700 (PDT) Received: by qgt47 with SMTP id 47so111170072qgt.2 for ; Sun, 11 Oct 2015 19:43:06 -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-type:content-transfer-encoding:message-id; bh=Esn+tubHlbyIKTWOvIn9HrJPuPAaAPY/nQfMvfdZ6yI=; b=xJgsTVC2mUxZK9jE2lTaA7q7ykJZn7Ckef/nJYUnPq9FT1WGTmvROf18wravan4hDL 7SfM3tKuVWrrGrmbRPNXT+y3WjDF7M9ZnO+nHawWx0bclf8rt0p/qG/brT3R5SkNQeNS jlYA7ZeAFLy0ybnrNfNvGKaYm6e6nJdkfkulodToEMPISIrlqm14lSsYvqQWJxVOmfZw kPU2XkK3Ct52bZm0mTK72X2Ghl17hQo58iiogoU9RAMc5/Y7znvrrawc1F01y0RjErW/ 2R+qqSB6fT3KTYCylm2ubSTtuhe8HxIgosooPpJXYvITDCOajxmvfbnvHHSrAN/uf/CX aIrQ== X-Received: by 10.141.28.69 with SMTP id f66mr29165317qhe.67.1444617785931; Sun, 11 Oct 2015 19:43:05 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 142sm6305968qhg.13.2015.10.11.19.43.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 Oct 2015 19:43:05 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sun, 11 Oct 2015 22:43:03 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510101337.29335.davemgarrett@gmail.com> <201510111913.04247.davemgarrett@gmail.com> <20151012000045.GF15070@mournblade.imrryr.org> In-Reply-To: <20151012000045.GF15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510112243.04474.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] The SHA-1 Options (was: banning SHA-1 in TLS 1.3, a new attempt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 02:43:08 -0000 I'd like to get a sense of what the WG is willing to consider with regard to SHA-1, rather than only Viktor and myself discussing this. Basically, I see 3 options: Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully viable option in TLS 1.3 if nothing better is installed. Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1 signatures (but may trust full certificates, namely roots). Option 2: Distrust (option 1) and also prohibit endpoints from sending chains that rely on SHA-1 signatures to their peers when negotiating TLS 1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your certificates; self-signed roots still exempt) No change is proposed with regard to dealing with SHA-1 under TLS 1.2 beyond the current state. TLS 1.3 already prohibits using SHA-1 in CertificateVerify. This discussion is only for TLS 1.3+ non-root certificates. The TLS 1.3 release is not yet near (assume we're talking about 2016, when others are phasing out SHA-1 more strictly as well). I am in favor of #2, as I don't think the risk of keeping it in the spec is worth continued support (SHA-1 is on its way out, and TLS 1.3 shouldn't perpetuate its use). Viktor Dukhovni is in favor of #1, and considers prohibiting servers from sending SHA-1 certs to be sufficiently out-of-scope and not worth the interop risk (opportunistic encryption and direct trust of certificates, of note). Two opinions does not a working group make, so more input is clearly needed to move forward in any way here. This is only a preliminary call for opinions, and certainly not a policy deciding vote. The new reason to consider this: https://sites.google.com/site/itstheshappening/ Current draft language: https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60 Start of the parent thread: https://www.ietf.org/mail-archive/web/tls/current/msg17956.html Dave From nobody Sun Oct 11 20:12:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9F21B300F for ; Sun, 11 Oct 2015 20:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoxfAb88gKrr for ; Sun, 11 Oct 2015 20:12:41 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD7B1B3001 for ; Sun, 11 Oct 2015 20:12:41 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id AC51854C003; Sun, 11 Oct 2015 20:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=wvA8BslpYH+34nkjchTfIFhCFw8=; b=Gt5Z+kElcryIEi3XA Jyk/x5L2a88qvyGuOX6UbMtchwlDhmFxysh9cv8AN6LUZxbuZKLptNySBg5SXgmE ZoPixcOqFkiFb++S70DYYfAUjaEmhHr1efs6nDAXfqRWSRigtNDGB+t2+RhadsHY Y50F7ahGe7r41+J3ZWLtS4E3UA= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 660BF54C002; Sun, 11 Oct 2015 20:12:40 -0700 (PDT) Received: from 67.161.27.165 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Sun, 11 Oct 2015 20:12:40 -0700 Message-ID: In-Reply-To: <201510112243.04474.davemgarrett@gmail.com> References: <201510101337.29335.davemgarrett@gmail.com> <201510111913.04247.davemgarrett@gmail.com> <20151012000045.GF15070@mournblade.imrryr.org> <201510112243.04474.davemgarrett@gmail.com> Date: Sun, 11 Oct 2015 20:12:40 -0700 From: "Ryan Sleevi" To: "Dave Garrett" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] The SHA-1 Options (was: banning SHA-1 in TLS 1.3, a new attempt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.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, 12 Oct 2015 03:12:45 -0000 On Sun, October 11, 2015 7:43 pm, Dave Garrett wrote: > I'd like to get a sense of what the WG is willing to consider with reg= ard > to SHA-1, rather than only Viktor and myself discussing this. Basicall= y, I > see 3 options: > > Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully > viable option in TLS 1.3 if nothing better is installed. > Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1 > signatures (but may trust full certificates, namely roots). > Option 2: Distrust (option 1) and also prohibit endpoints from sending > chains that rely on SHA-1 signatures to their peers when negotiating T= LS > 1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your > certificates; self-signed roots still exempt) My personal preference, speaking on behalf of myself and neither that of my employer or colleagues (we are all individuals here, right? ;D), would be Option 0. If that's all you care to know, stop here - the rest is pontificating and poorly articulating why :) Background: It's no secret I hate SHA-1. I'm accused by a number of Chrome users as being too aggressive in the deprecation of SHA-1. I'm unquestionably accused by CAs of being too harsh on SHA-1 - my opposition towards any extension of SHA-1 signatures by CAs complying with the CA/Browser Forum Baseline Requirements is unquestionable and well known. Why would I support "do nothing"-ism, which is effectively what Option 0 = is? Two reasons: - I agree with Viktor that TLS is a protocol for which many credential types can be delivered, and while I have no desire nor intent to support = a number of them within Chrome (... I'm looking at you, DANE), I don't deny their utility or viability in some circumstances and environments beyond that of web browsers. It feels inconsistent to apply this to one specific type of credentials, with a particular policy. This is an ideological argument for specification purity, fundamentally, so I fully anticipate disagreement, as is expected with such arguments. - Simply one of complexity. The modern TLS stack, as used in Web browsers (thus revealing my bias, as if we didn't know it already) is already hair= y and complex. HTTP/2 imposes a (much needed) profile on ciphersuite negotiations. Browsers themselves key UI off a variety of factors contributing to the connection, both direct (e.g. ciphersuite) and indirect (e.g. mixed content). If we accept that browsers are only concerned with the Web PKI (I know some wish it were otherwise), then the WebPKI is messy, and whether or not a certificate is signed by SHA-1 is..= . complex and complicated and invokes path building and cross certificates and many of the things outside the remit of TLS. This certificate path building and discovery depends on a variety of factors and external resources (and here's where Martin Rex would chime i= n about how awful such a state is, but let's accept it as the state of the world today and not argue about necessity or not), and implementing such = a policy necessarily interleaves that into the connection management. The 'gross' state of my world today, which will no doubt shock and offend= , is that in many cases and ways, the verification of the server identity i= s deferred until after the overall connection has been established, before any data is transferred over it, and before any keys, session parameters, or overall state is persisted for reuse. The alternative to this is to do something akin to Firefox, which does verification semi-synchronously during handshaking, but which doesn't fetch such external resources (and thus has a much harder time interacting with nominally 'secure' sites), and which if it did, would trigger the various 'retry' logic to deal with servers that time out if the handshakes fail to happen in a 'reasonable' time. Look, I think the deprecation of SHA-1 is a noble goal - hopefully my bonafides are established such that few would want it more - but my concern is that it would add significant implementation complexity to my world, and fundamentally offer no benefit for my existing and documented plans. Were I (and my colleagues) to ignore such a MUST, for entirely pragmatic and yet equally secure reasons, we'd end up cheesing off folks like Dave and those who treat MUSTs as inviolate (reasonably and rightfully so), an= d would be seen as tacitly encouraging others to ignore such MUSTs as well. I'd like to avoid that world. I think the reasons for such a proposal are laudable, but the pragmatic application and interpretation of such a requirement would be confoundingly obnoxious, and to no obvious benefit, since I (and my counterparts at various other browser organizations) am well on my way to killing SHA-1 within the commercial space. So the only party left to all this is the Enterprise folk, those who will always override a MUST with an application profile, or who will always deal with legacy in such a way that, practically speaking, such a MUST is toothless. Such a requirement doesn't help my efforts towards the death of SHA-1 and evangelizing the need for such a death, and would only distract myself an= d my colleagues from implementing TLS 1.3 as quickly as reasonable and possible. Maybe it will help in some niche ecosystems that still hold to SHA-1 as the bastion of security, but frankly, may the deity/deities they worship have mercy on their misguided souls. From nobody Sun Oct 11 21:43:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777311B3124 for ; Sun, 11 Oct 2015 21:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGaFerxnI0Yf for ; Sun, 11 Oct 2015 21:43:12 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 358DD1B310E for ; Sun, 11 Oct 2015 21:43:12 -0700 (PDT) Received: by qgez77 with SMTP id z77so113018981qge.1 for ; Sun, 11 Oct 2015 21:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=aSxyt1ILPbaOhFKZ6m65DbfgntdxCG4fHwHRpZzl7XU=; b=kw618Z4aD9z+COxlc8Eakkj9Sr2YJI3cjC9XuuWoQkLb3mUg977gKDofRqPB5OPKap dvwHQRUr51UI+knSmyKY2ulvhpF/sSMHcaw5uUiWoz8JiDnw4cVrtHnlUTD13KXoPFoi FGlgcEvRzLxY0S9xJiDJW2uOgpNIFYb4ongg0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=aSxyt1ILPbaOhFKZ6m65DbfgntdxCG4fHwHRpZzl7XU=; b=jS0gLWz002QjfOtJaqyk2lIidXoH28jAtNTwtqhXsU8/ngEN0+frCX+6kt5Crldzvl 9LWxzhgn95v/EZiKJtv1SKkIe63IaV3rZ2DhprWXvMbUzooSW+iesxGVR2LynuYHwPMZ x3r1aRmQa1muRFk+ZGkKsGkdODyv/4Ezvacmb3lXuHBWN1NKxUuO18pXd15CwWex3tpV 2/VIjV3itgit+ZaFOQC24doYsX3ivkCCzSC7ZMspFcmxoyFCCCwwXg8oqrt2DbHK98Rn piGPIq159kbR7OAe/KPBbpRZOoJyx73U8oaCRaTduhPieV3YD5s588MixdQdUnUHAeCh KYIg== X-Gm-Message-State: ALoCoQmuQluLxYRw70qKZiiQSBzUdoAmgafux8TFMrqZro5li7Av1ZqSh9tlfOMoZRIO5VxjPwJu X-Received: by 10.140.35.75 with SMTP id m69mr30274257qgm.39.1444624991314; Sun, 11 Oct 2015 21:43:11 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id 190sm790587qha.41.2015.10.11.21.43.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Oct 2015 21:43:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <201510112243.04474.davemgarrett@gmail.com> Date: Mon, 12 Oct 2015 00:43:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201510101337.29335.davemgarrett@gmail.com> <201510111913.04247.davemgarrett@gmail.com> <20151012000045.GF15070@mournblade.imrryr.org> <201510112243.04474.davemgarrett@gmail.com> To: "" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [TLS] closing this thread: Re: The SHA-1 Options (was: banning SHA-1 in TLS 1.3, a new attempt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 04:43:13 -0000 I=92m going to close this thread. We discussed SHA-1 support in TLS on = the list and at the interim the chairs made the consensus call that = PR#231 reflects the WG=92s consensus. Note that Stephen started a thread on the saag list about further work = to remove SHA-1 from protocols [1]; maybe the references both Dave and = Stephen cite will accelerate the demise of SHA-1 issued certs. spt [1] = http://mailarchive.ietf.org/arch/msg/saag/1iiiMLJmrtEMSmghoYO6lC_xje4 From nobody Sun Oct 11 22:14:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C941B3150 for ; Sun, 11 Oct 2015 22:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn1VkiI8qveu for ; Sun, 11 Oct 2015 22:14:12 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63CE1B314D for ; Sun, 11 Oct 2015 22:14:11 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id U5E71r00D10HQrX015E83i; Mon, 12 Oct 2015 07:14:09 +0200 Message-ID: <561B419D.4010009@openfortress.nl> Date: Mon, 12 Oct 2015 07:14:05 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Ilari Liusvaara , Watson Ladd References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 05:14:14 -0000 Hello, Thanks for the feedback. Responding to it: Ilari> - The signed DH share does not look to be bound to anything (crypto Ilari> parameters negotiation, randoms, server key exchange, etc..). This is indeed easy to miss; it relies on Kerberos infra to deliver a short-lived session key to only the proper TLS client and TLS server. The ticket is part of this key delivery, and can travel over untrusted networks. An Authenticator is built especially for each connection, and encrypted with the session key by the TLS client. The only other that can decrypt it is the TLS server. With the client DH key only known to TLS client and TLS server, only they can construct the DH shared secret. What remains is MITM on the server side. This is detected when the Finished messages are off (these have more bytes for TLS-KDH). A alternative option to fighting MITM could be to include (a hash of) the server-sent DH offer in the Authenticator. Only the Kerberos- authenticated TLS server can decrypt it, making it detect MITM. Is that considered benefial? Ilari> I can't Ilari> offhand say what that would lead to, but it looks even worse than Ilari> TLS ServerKeyExchange, which has known vulernabilities due to Ilari> lack of binding to things like ciphersuite. Have I taken away these concerns? Pointers to the known vulnerabilities are welcome, of course. I'm not sure what you would like to bind to CipherSuites. Watson> I would suggest piggybacking on the PSK mode, using the key Kerberos Watson> provides at both ends as the PSK key. This would address all of these Watson> issues in TLS 1.3 You mean to add the short-lived session key to the pre-master secret, right? I have a (weak) preference to leave that key behind the API to help it being better protected. Also, I don't think it adds much to the security explained above. It might be an idea to add protected fields from the Authenticator though, such as the usec timestamp, seq-number, client name@realm. Ilari> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC Ilari> (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. Yes, this is a naive/initial list, I knew I would need to interact here to get it pruned. Thanks, your suggestions will be taken care of! Ilari> - Even use of DH is questionable. This is mod-exp DH, on account of its need for very large keys, right? I would love to take it out, and only leave ECDH; I put up mod-exp DH initially because it might be desired for backward compatibility. If I hear no warm-felt desire for mod-exp DH I will gladly remove it. Thanks! -Rick From nobody Mon Oct 12 02:01:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824C91A00B8 for ; Mon, 12 Oct 2015 02:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmUGQmcH_-Cq for ; Mon, 12 Oct 2015 02:01:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148301A00A0 for ; Mon, 12 Oct 2015 02:01:45 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-cc-561b76f7c676 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5A.32.27359.7F67B165; Mon, 12 Oct 2015 11:01:44 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.184]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Mon, 12 Oct 2015 11:01:43 +0200 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: TLS 1.3 Recommended ECC curve for 192-bit security Thread-Index: AQHRBMydOHy9F9/ta0KlukZnanicFg== Date: Mon, 12 Oct 2015 09:01:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.20] Content-Type: multipart/related; boundary="_005_D24143963D932johnmattssonericssoncom_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUyM+Jvje6PMukwgx33uS0+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsO7i9gLTs1hrNg3bwN7A+Pr6YxdjJwcEgImEheOTGCDsMUk LtxbD2RzcQgJHGWUuD+hmQXCWcIocWYhiMPJwSZgIDF3TwNQFQeHiICixKfP2SCmsIC1RM9X E5AKEQEHifbdE5kgKvQk3m9RBAmzCKhKXJveC7aKV8Bc4ubTi8wgNiPQ2u+n1jCB2MwC4hK3 nsxngjhHROLhxdNQp4lKvHz8jxVkpCjQyD3LJSHCihJXpy8H28QsUCGx5ZgWxHRBiZMzn7BM YBSehWToLISqWUiqIEpiJBbu3MMGUaIpsX6XPkRYUWJK90N2CFtDonXOXCjbWmJl11s2TDXe Elf27GOHGOMgMWeW7ixg+DELHGOU+LxkHTNEjZHEkns/GbHpnbDnK9RMB4mvv7ezwDVv6P3F DDHUSGLDNk5kvQsYhVcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBKaQg1t+G+xgfPnc8RCj AAejEg/vw9tSYUKsiWXFlbmHGKU5WJTEeZuZHoQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YOyY9My96t4km9KwXdF7zrwxaLp4X3fWTo3XR141zPa8fJhZhzdI8rmKdf3hbWy+z+LjP0lI 7NpsbGU1Y4fAlzVly7oubn0osZNzTfG6tT58oRO3huRK9HVkHPdbM6f85v2L289Ylm+rbXz4 dcmWey0xVmtiFnPyx+7X55nN+jZHljdQy6t89z4lluKMREMt5qLiRADXpk6TAgMAAA== Archived-At: Subject: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 09:01:49 -0000 --_005_D24143963D932johnmattssonericssoncom_ Content-Type: multipart/alternative; boundary="_000_D24143963D932johnmattssonericssoncom_" --_000_D24143963D932johnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgc2VsZWN0aW9uIG9mIE1USSBDaXBoZXIgU3VpdGVzIChTZWN0aW9uIDguMSBv ZiBkcmFmdC1pZXRmLXRscy10bHMxMy0wOSkgaXMgZXhjZWxsZW50LCBidXQgSSBhbSBtaXNzaW5n IGEgcmVjb21tZW5kZWQgRUNDIGN1cnZlIGZvciB0aGUg4oCcU0hPVUxE4oCdIGNpcGhlciBzdWl0 ZXMuIExpdHRsZSBiZW5lZml0IG9mIHVzaW5nIEFFUy0yNTYgd2l0aCBQLTI1NiBvciBjdXJ2ZTI1 NTE5LiBTaG91bGRu4oCZdCB0aGVyZSBiZSBhIFNIT1VMRCBpbXBsZW1lbnQgRUNDIGN1cnZlIGdp dmluZyBhdCBsZWFzdCAxOTItYml0IHNlY3VyaXR5PyBFLmcuDQoNCiJUaGVzZSBjaXBoZXIgc3Vp dGVzIFNIT1VMRCBzdXBwb3J0IGJvdGggZGlnaXRhbCBzaWduYXR1cmVzIGFuZCBrZXkgZXhjaGFu Z2Ugd2l0aCBzZWNwMzg0cjEgKE5JU1QgUC0zODQpLiINCg0KQ2hlZXJzLA0KSm9obg0KDQoNCkpP SE4gTUFUVFNTT04NCk1TYyBFbmdpbmVlcmluZyBQaHlzaWNzLCBNU2MgQnVzaW5lc3MgQWRtaW5p c3RyYXRpb24gYW5kIEVjb25vbWljcw0KRXJpY3Nzb24gSUVURiBTZWN1cml0eSBDb29yZGluYXRv cg0KU2VuaW9yIFJlc2VhcmNoZXIsIFNlY3VyaXR5DQoNCkVyaWNzc29uIEFCDQpFcmljc3NvbiBS ZXNlYXJjaA0KRsOkcsO2Z2F0YW4gNg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuDQpQaG9u ZSArNDYgMTAgNzEgNDMgNTAxDQpTTVMvTU1TICs0NiA3NiAxMSA1MyA1MDENCmpvaG4ubWF0dHNz b25AZXJpY3Nzb24uY29tPG1haWx0bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCnd3dy5l cmljc3Nvbi5jb208aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vPg0KDQoNCltodHRwOi8vd3d3LmVy aWNzc29uLmNvbS9dPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tLz4NCg0KVGhpcyBDb21tdW5pY2F0 aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRo ZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlz Y2xhaW1lcjxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPg0KDQo= --_000_D24143963D932johnmattssonericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIHRoaW5rIHRo ZSBzZWxlY3Rpb24gb2YgTVRJIENpcGhlciBTdWl0ZXMgKFNlY3Rpb24gOC4xIG9mIGRyYWZ0LWll dGYtdGxzLXRsczEzLTA5KSBpcyBleGNlbGxlbnQsIGJ1dCBJIGFtIG1pc3NpbmcgYSByZWNvbW1l bmRlZCBFQ0MgY3VydmUgZm9yIHRoZSDigJxTSE9VTETigJ0gY2lwaGVyIHN1aXRlcy4gTGl0dGxl IGJlbmVmaXQgb2YgdXNpbmcgQUVTLTI1NiB3aXRoIFAtMjU2IG9yIGN1cnZlMjU1MTkuIFNob3Vs ZG7igJl0IHRoZXJlIGJlIGEgU0hPVUxEDQogaW1wbGVtZW50IEVDQyBjdXJ2ZSBnaXZpbmcgYXQg bGVhc3QgMTkyLWJpdCBzZWN1cml0eT8gRS5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+JnF1b3Q7VGhlc2UgY2lwaGVyIHN1aXRlcyBTSE9VTEQgc3VwcG9ydCBib3RoIGRpZ2l0YWwg c2lnbmF0dXJlcyBhbmQga2V5IGV4Y2hhbmdlIHdpdGggc2VjcDM4NHIxIChOSVNUIFAtMzg0KS4m cXVvdDs8L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiPjxicj4NCjwv c3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiPkNoZWVycyw8 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7Ij5Kb2huPC9z cGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyI+Jm5ic3A7PC9z cGFuPjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBtYXJnaW46IDBjbSAwY20gMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPjxpbWcgd2lkdGg9IjI1 NSIgaGVpZ2h0PSIzIiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNpZDozOEQ5MEEwMi0wMkRGLTQy QkYtQkQ4My0xMDI1OUEwQzgzQzQiIGFsdD0ibGluZSIgdHlwZT0iaW1hZ2UvcG5nIj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoNTEsIDUx LCA1MSk7Ij5KT0hOIE1BVFRTU09OPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IG1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsiPk1TYyBFbmdpbmVlcmluZyBQ aHlzaWNzLCBNU2MgQnVzaW5lc3MgQWRtaW5pc3RyYXRpb24gYW5kIEVjb25vbWljczwvc3Bhbj48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyI+PGZvbnQgZmFjZT0i QXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzcHg7Ij48Yj5Fcmljc3NvbiBJRVRGIFNl Y3VyaXR5IENvb3JkaW5hdG9yPC9iPjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSxz YW5zLXNlcmlmIiBzaXplPSIzIj4mbmJzcDs8L2ZvbnQ+PC9zcGFuPjxiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7Ij48YnI+DQpTZW5pb3IgUmVz ZWFyY2hlciwgU2VjdXJpdHk8L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxzcGFuIHN0 eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDUxLCA1MSwgNTEpOyI+RXJpY3Nzb24gQUI8YnI+DQpFcmljc3NvbiBSZXNlYXJjaDxicj4NCkbD pHLDtmdhdGFuIDY8YnI+DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW48YnI+DQpQaG9uZSAm IzQzOzQ2IDEwIDcxIDQzIDUwMTxicj4NClNNUy9NTVMgJiM0Mzs0NiA3NiAxMSA1MyA1MDE8YnI+ DQo8YSBocmVmPSJtYWlsdG86am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xv cjogcHVycGxlOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibHVlOyI+am9obi5tYXR0c3NvbkBlcmlj c3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyI+PGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nv bi5jb20vIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmx1ZTsi Pnd3dy5lcmljc3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IG1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJp Y3Nzb24uY29tLyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNv bG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij48aW1nIGJvcmRlcj0iMCIgd2lkdGg9 IjUwMCIgaGVpZ2h0PSI4MSIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6QUJDNDQyMjEtREZB Mi00QUQyLUFGNzctOTQ3NDIxQjZFNjI2IiBhbHQ9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tLyIg dHlwZT0iaW1hZ2UvcG5nIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA4cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig1 MSwgNTEsIDUxKTsiPlRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQN CiBhdDxhIGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiIHRp dGxlPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIiBzdHlsZT0iY29s b3I6IHB1cnBsZTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmx1ZTsiPnd3dy5lcmljc3Nvbi5jb20v ZW1haWxfZGlzY2xhaW1lcjwvc3Bhbj48L2E+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJyPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D24143963D932johnmattssonericssoncom_-- --_005_D24143963D932johnmattssonericssoncom_ Content-Type: image/png; name="13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png" Content-Description: 13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png Content-Disposition: inline; filename="13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png"; size=2991; creation-date="Mon, 12 Oct 2015 09:01:43 GMT"; modification-date="Mon, 12 Oct 2015 09:01:43 GMT" Content-ID: <38D90A02-02DF-42BF-BD83-10259A0C83C4> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAP8AAAADCAIAAADTOk7/AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAABKUlEQVRI De1TMU4DQQycu5yokNKglEhIfIEf8JEoHSU/gAfkATQ8gMcgGigR0CYSDVRhzdheL7sogT6602o1 6xmPvb67TkQAvKzu7l+v1x9PSbovWwm9A+4R1EhCFhjbB2UapUwTJqHPwU1lpYlhZSaRWAU3stOf KYIeXNLpnjFBOXaQiHswH02guChbk8bzT5NGSZNdnqViCEonohMBX4HepwIW/J/6lV5nbaWsEMs1 zp61lSqNJUCSZQEpWavoRSa2BkCB7wEG0UsyPoCySmBHshPOS1CxJoMoRf1Plh4ps3KuL7VUVumb uLdkrH7hB2qrAj7HNxfTxTkBO9Tn4e3q/fPR8biPE9jjCfAfeL689Qvmr/90Nj86PNvjO49XGydQ JnCynDv+BsiTWPQxCGmXAAAAAElFTkSuQmCC --_005_D24143963D932johnmattssonericssoncom_ Content-Type: image/png; name="D377E800-0A1A-43D3-AF5E-165F697789B5[3].png" Content-Description: D377E800-0A1A-43D3-AF5E-165F697789B5[3].png Content-Disposition: inline; filename="D377E800-0A1A-43D3-AF5E-165F697789B5[3].png"; size=5392; creation-date="Mon, 12 Oct 2015 09:01:43 GMT"; modification-date="Mon, 12 Oct 2015 09:01:43 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAfQAAABRCAIAAACrEsM0AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAKiklEQVR4 Ae2dPWwURxiGA0oDCQSUVEFA6OwKE4gLBATrnEDHXZtItpFIEWEJJ1RGQoCQ7Cr8JEYpEsk2Rdo7 l4l8AgJKARicBrvjJ6FKpPAnUpLXfNHcaPe8d2u45Zh9rNNpdvab2ZlnrHe/+3ZmdtmzZ8/e4A8C EIAABMIisDys7tAbCEAAAhBYIIC4838AAQhAIEACiHuAg0qXIAABCCDu/A9AAAIQCJAA4h7goNIl CEAAAog7/wMQgAAEAiSAuAc4qHQJAhCAAOLO/wAEIACBAAkg7gEOKl2CAAQg8ObrguDO/b8r1ZkH j56qwbu7O3d3d7wuLaedEIAABLInsKz9tx+YKF+uVGenqtd9OgOlneMjB/wc0hCAAAQg4Ai0r7hf vDo/WblSmZ558HjBW4//Sdwl8fF8ciAAAQhAoO3EXeGXs+d/UQRGieThUWTmwuRwsg1nIQABCOST QLvE3B88/nei/Otk+crs/L18jgS9hgAEIPASCbx6ca8bUn+JPaQqCEAAAjkk8MrEvWFIveFg9Bd3 NLTBAAIQgEA+CWQt7s2H1JPHY6hvD09TkxFxFgIQyDOBjMT9ZYXUP1j3XrGw9VDfp0rkedjoOwQg AIFkAlmIu56RlgbPNpz9ktxQ+en7Cluk7MlmnIUABCAAARHIYirkltLRJc+B6erYID+92LttzaoV DBgEIAABCDRJoOWeu2R9CcpO+KXJ8cMMAhCAQF0CLRd32w2m7rXjmWtWrSz2btU0mPjWMbpDPJ8F f/edVW8XC108TY3TIwcCEICAI9BycXdXSk5IzaXp8fCLIvVarao1q37IXvvMaGcClqcmI+UsBCCQ ZwJZxNw39R72pdnHrfDLQki9sDUy+0WzayrTCwqu6fC+vZ8+PfyZJkT6OaQhAAEIQMAIZCHuiqj0 9I36+39Z+EWyruelkZGQnz5Vvallq5H8+CF7y8SZkAMBCEDACGQRlpGC366e0tYxv8//IVnf3LE+ HjG3kLo03b8HMEgQgAAEILA0AlmIu1qmiYx1QygWUl/afmF6srq0PlMKAhCAQPAEMhL3CEcLqcdf wRExSz4cKG1PNuAsBCAAgdwSyFrcLaSe8AqOZkZCsR09TWW1ajOssIEABPJJICNxV/ilyVdwJA+D wvf9pR0DpV0sWE0GxVkIQCDnBLIQ9/hsmbTQWbCalhj2EIBAzglkMRUyYZ57Q/rsF9YQEQYQgAAE 4gRa7rlrFdJiK5jirXE5iy1YdQYkIAABCEAggUDLxT3h2vFTCr9oEwJ565EFq7K0t/E9fPxE6Y8/ 6hjq30vYPQ6QHAhAAAJGoOXivmb1yoask/cLW3gSOz3jL27Sr4Gp6o0L54+g7w3ZYgABCOSTQBYx 957+0cW2iNlX2FZ3i0dFcuSqa2+ZhJDOsYPF44OlfA4bvYYABCCQTKDlnrsuXx4b6ukb0ZwZ1xRF XRL2C5Or7hu7UpHEpWuL7ikWseQQAhCAQN4IZCHuCp7cLJ/U8qXZuQV9147tdfcLmyj/pr188zYA 9BcCEIBAKwhkIe7Wbi0oja8plYceD6k32U/2lmkSFGYQgEAOCWQn7j7cZkLqvn3d9FDfJ3XzyYQA BCAAgUzF3fYLazKknjA2Ctlrb5n4q/gSinAKAhCAQK4IZCTuCr8cH5t68ZC6ZtdoM8h4eCdXY0Zn IQABCDQkkIW461FqafDbhk1JMNAD2IXZNb3bmNieQIlTEIAABByBLOa5r+3+0l+C5K7dMKHwi5x0 yXp8wWrDshhAAAIQyDOBlnvuWr6UVtltweq+whbCL3n+16TvEIDAixBoubinahz7haXChTEEIACB xQi0XNyb2VtGUZfF9gtbrN3kQwACEIBAAoGWi7uehcofr7u3jIVfFFKPL1hNaDGnIAABCECgIYEs Hqhqentp8Iyv74vtF9awuRhAAAIQgEAzBLIQd2uHprrPzt1VlKarYyOzX5oZG2wgAAEILJlAduK+ 5CZSEAIQgAAE0hJYnrYA9hCAAAQg0P4EEPf2HyNaCAEIQCA1AcQ9NTIKQAACEGh/Aoh7+48RLYQA BCCQmgDinhoZBSAAAQi0PwHEvf3HiBZCAAIQSE0AcU+NjAIQgAAE2p/Ay9l+QAuUHjx66vc2+TVJ 9komvWxPRbSgqatzo+1A4OdrudPu7s7kfBVXJRevzllVdV+97beKNAQgAIGcEEixiGlZZ38cyoXJ Yel4T/+ov7uAzLRvjN6EN1DaqbQVNEsdHh8rnzhXiVT1bG5Sd4ievlF/f2DVrFIT5ctfjf4Uz1cN yj9z/me/Kt0Mxke/sFuCa7C7tLXz2MHi8cGSX4o0BCAAgcAIpPbcpZv+Ro9+2kcjLd5/5Mf4u5N8 OZbPro9cfsm6ypYGz5qC2yXcTwGn7JF83SScsus2MDt3T8VV1f7hH26WT/qNOXGuvLt72M8hDQEI QCBsAqnF/fTw5wkhFzngCq309I2YXmszGd9YwRMnx/Lrh/r2GFwLqti3XH4nzarKvetDyu7nq6Be tG3FrSoZbyp8bfouZ99+NJiBKtHHb4nl8w0BCEAgVAKpH6jOzt81rbTvCJfnmbecTEf0VMFxs5dS O2VXju0jJllXWuq8qfewvHXdHvTGVIXjrYgOLV+VK18XMjdfpawqZTpBtwZYQcuU826HfEMAAhDI A4HUnrtk1+ciV90/VFDbDqW546MH/FNKO83dV/gwckqHcsAVyTEzOfj6SJfHRw5Iu83fV3HLV9Bc z1qthq7ODa6qjevetfSla/MuU8Zy5HUz0LfLJAEBCEAgbAKpxV2Cu/H9/zU0AY3c6jWr3ooYuAD9 7PyfkVM6VM3y0xVsqUzPmFcuOdarPCT6uhlMVq64fD2PNWdfpVxo3k9rV2FXvyyl7yril3JnSUAA AhAIkkDqsIzeh6epJu4TgSJHXlpsmZLjyFnnbk9Vr1tQPmKgcI1c9X+ufq+3edgp026Fd5R/u3pK Bpbv3SfuuR8EU9Ubdta58HY41L9XvyRkpoeulsM3BCAAgbAJpPbcJdkudC40credE22kBkq7LHQj R1uK7OOTNEumFSFR5pbSUfcjQHXenv6mOPjd2tUrNnes19lLV2+5ggq1FwtbpdcSeqfj8s1V3CIt mmYjB79SnbUbhnRcbXDFlVA4Xgby3O0HgX+KNAQgAIEgCaQW90jkWs54RNylpPK75ZtLSWUsCfbB lceG3Cv3/Kqk+BL0iPjqTqCPhdr9SuyOonk7mo0jQdfHgvWysVi/2uDbKy3nXQGfSP0RGw4hAAEI BEMghbgrch3vtim7H+OWzUBp+8PHT5QwR9sKmqVkV0uKKtWZqerNO/f/sgrtxXtyrv0HoYqzmwOu B6qaouMurbiQ3TBUlSZH6g4hn90up3pUibvZ+A2WcXnskP3mcNEhVycJCEAAAoERSLFCNbCe0x0I QAACARNI/UA1YBZ0DQIQgEAwBBD3YIaSjkAAAhCoEUDcayxIQQACEAiGAOIezFDSEQhAAAI1Aoh7 jQUpCEAAAsEQQNyDGUo6AgEIQKBGAHGvsSAFAQhAIBgCiHswQ0lHIAABCNQIIO41FqQgAAEIBEMA cQ9mKOkIBCAAgRqB/wAoLQQNWSy3+QAAAABJRU5ErkJggg== --_005_D24143963D932johnmattssonericssoncom_-- From nobody Mon Oct 12 02:34:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134AE1A92E5 for ; Mon, 12 Oct 2015 02:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.622 X-Spam-Level: * X-Spam-Status: No, score=1.622 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 zYCHz8HjgB-s for ; Mon, 12 Oct 2015 02:34:13 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 B7CAB1A92E4 for ; Mon, 12 Oct 2015 02:34:12 -0700 (PDT) Received: by lbbck17 with SMTP id ck17so16739538lbb.1 for ; Mon, 12 Oct 2015 02:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cinkciarz.pl; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/OgOYuTrqJin5v3Le3i8/9+vLv9GsH/sKKzMdn8S8Z8=; b=Uk/VeEw25fve3DEnLhtcdt8MEh+5x8srucg7dJX6+/pgW00aHP/ueEwyS6xNsg/m+h cDpWSBu49w0S7GCdcBQgg5VVPCvtvJAuGzx4+XU7PmihjmM76WmVkr4FkfCDB/1h2Ahu K4Wy6VX4YyPNAPj7uGPcqL51ArjYTDMZSLrlI= 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:date :message-id:subject:from:to:cc:content-type; bh=/OgOYuTrqJin5v3Le3i8/9+vLv9GsH/sKKzMdn8S8Z8=; b=Nfm5f5vqKiJi+BC5EsMzBVS86YjSV7p9CcFXM2Idew+u9ajcGZshRY/VU4fQZ6qVtK krE4Ibi7XAgxR91C43ihtWMZDoPybJQ/vEMEb1DhOeFQ6/kgQG9bXHO843Mvnm1IIiaN T5vdO3ZobbkG+fCYmjYeizbIz9jaC+2BO8j0Q8S/LLZVspGSM/TqnvNeTxX+tq70u1V9 1ABK1zdCvMvaYWUe9KJ8vwkTdafcPJTIAyQLSy7jlgiRGlG0Lhzb619Epc6djWEBwH3g GgY8LwRdH/xYW7mSFH1IXVV0c3fRM2zskeTXpnZgv7NfOloC3kbbULdFkXHigWsR+ub4 mCGQ== X-Gm-Message-State: ALoCoQm64SKkGpzHMvWOvaWygFJQ/1PnyOoCxLvAmctIGWvrAfKrchnHOgMFTO9DbSXaYh5Ec8hy MIME-Version: 1.0 X-Received: by 10.25.90.83 with SMTP id o80mr7634004lfb.47.1444642450639; Mon, 12 Oct 2015 02:34:10 -0700 (PDT) Received: by 10.25.20.214 with HTTP; Mon, 12 Oct 2015 02:34:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Oct 2015 11:34:10 +0200 Message-ID: From: =?UTF-8?Q?Micha=C5=82_Staruch?= To: John Mattsson Content-Type: multipart/related; boundary=001a1140042a1955260521e50860 Archived-At: Cc: "TLS@ietf.org" Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 09:34:15 -0000 --001a1140042a1955260521e50860 Content-Type: multipart/alternative; boundary=001a1140042a1955220521e5085f --001a1140042a1955220521e5085f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We already have "SHOULD support key exchange with X25519" in this section, so people implementing it should have no problems with adopting X448 to achieve ~224 bit security where it's needed (and better performance than P-384). On Mon, Oct 12, 2015 at 11:01 AM, John Mattsson wrote: > I think the selection of MTI Cipher Suites (Section 8.1 of > draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended ECC > curve for the =E2=80=9CSHOULD=E2=80=9D cipher suites. Little benefit of u= sing AES-256 with > P-256 or curve25519. Shouldn=E2=80=99t there be a SHOULD implement ECC cu= rve giving > at least 192-bit security? E.g. > > "These cipher suites SHOULD support both digital signatures and key > exchange with secp384r1 (NIST P-384)." > > Cheers, > John > > > [image: line] > > *JOHN MATTSSON* > > *MSc Engineering Physics, MSc Business Administration and Economics* > > *Ericsson IETF Security Coordinator* > * Senior Researcher, Security* > > > Ericsson AB > Ericsson Research > F=C3=A4r=C3=B6gatan 6 > SE-164 80 Stockholm, Sweden > Phone +46 10 71 43 501 > SMS/MMS +46 76 11 53 501 > john.mattsson@ericsson.com > > www.ericsson.com > > > > [image: http://www.ericsson.com/] > > > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out atwww.ericsson.com/email_disclaimer > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --=20 Pozdrawiam | Best Regards Micha=C5=82 Staruch | Information Security Officer ul. Sienkiewicza 9, 65-001 Zielona G=C3=B3ra msta@cinkciarz.pl Find us on Bloomberg CKPL [image: Cinkciarz.pl Sp. z.o.o] *Cinkciarz.pl Sp. z o.o.* *Siedziba:* ul. Sienkiewicza 9, 65-001 Zielona G=C3=B3ra *Biuro PL:* Al. Jerozolimskie 123A, 00-965 Warszawa *Biuro UK:* The Broadgate Tower, 20 Primrose Street, London EC2A 2EW *Biuro USA:* 401 North Michigan Avenue, Chicago, Illinois, 60611 *Sekretariat:* +48 726 666 655 | *Infolinia:* +48 68 410 99 50 biuro@cinkciarz.pl | https://cinkciarz.pl KRS 0000364722 | Kapita=C5=82 zak=C5=82adowy 23.263.500 z=C5=82 REGON 080465538 | NIP 9291830388 Audited by: Grant Thornton [image: Oficjalny sponsor Reprezentacji Polski w pi=C5=82ce no=C5=BCnej] Tre=C5=9B=C4=87 tej wiadomo=C5=9Bci zawiera informacje poufne, przeznaczone= tylko dla adresata. Udost=C4=99pnianie, ujawnianie, powielanie, rozpowszechnianie b= =C4=85d=C5=BA powo=C5=82ywanie si=C4=99 na jakikolwiek jej fragment przez inne osoby jest zabronione. W razie przypadkowego otrzymania tej wiadomo=C5=9Bci prosimy o powiadomienie o tym nadawcy oraz trwa=C5=82e jej usuni=C4=99cie. Informacje= zawarte w tej wiadomo=C5=9Bci mog=C4=85 by=C4=87 obj=C4=99te tajemnic=C4=85 zawodow= =C4=85 lub chronione innymi przepisami prawnymi. Nadawca nie bierze odpowiedzialno=C5=9Bci za jakiekolw= iek szkody spowodowane wirusem komputerowym przetransmitowanym w tej wiadomo=C5=9Bci. Pogl=C4=85dy i opinie przedstawione w tej wiadomo=C5=9Bci= s=C4=85 wy=C5=82=C4=85cznie pogl=C4=85dami i opiniami jej autora i niekoniecznie reprezentuj=C4=85 pogl= =C4=85dy i opinie firmy. This is a confidential e-mail intended solely for the use of the entity or the individual to whom it is addressed. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. If you have received this message in error please send it back to the sender and delete it. It may also be privileged or otherwise protected by work product immunity or other legal rules. The company accepts no liability for any damage caused by any virus transmitted by this e-mail. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. --001a1140042a1955220521e5085f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We already have "SHOULD support key exchange with X25= 519" in this section, so people implementing it should have no problem= s with adopting X448 to achieve ~224 bit security where it's nee= ded (and better performance than P-384).

=
On Mon, Oct 12, 2015 at 11:01 AM, John Mattsson = <john.mattsson@ericsson.com> wrote:
I think the selection of MTI Cipher Suites (Section 8.1 of draft-ietf-= tls-tls13-09) is excellent, but I am missing a recommended ECC curve for th= e =E2=80=9CSHOULD=E2=80=9D cipher suites. Little benefit of using AES-256 w= ith P-256 or curve25519. Shouldn=E2=80=99t there be a SHOULD implement ECC curve giving at least 192-bit security? E.g.

"These cipher suites SHOULD support both digital signatures and k= ey exchange with secp384r1 (NIST P-384)."

Cheers,
John
=C2=A0

3D"line"

= JOHN MATTSSON

= MSc Engineering Physics, MSc Business Administration and Economics

Er= icsson IETF Security Coordinator=C2=A0 Senior Researcher, Security


Ericsson AB
Ericsson Research
F=C3=A4r=C3=B6gatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501
john.mattsson@ericsson.com

www.ericsson.com



3D"http://www.ericsson.com/"

= =C2=A0

This Communication is Confidential. We only send and receive email on the = basis of the terms set out atwww.ericsson.com/email_disclaimer



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




--
=20

Pozdrawiam | Best Regards

Micha=C5=82 Staruch | Information Security Offi= cer

ul. Sienkiewicza 9, 65-001 Zielona G=C3=B3ra

msta@cinkciarz.pl

Find us on Bloomberg CKPL <G= O>

=09
3D"Cinkciarz.pl
=09

Cinkciarz.pl Sp. z o.o.

Siedziba: ul. Sienkiewicza 9, 65-001 Zie= lona G=C3=B3ra

Biuro PL: Al. Jerozolimskie 123A, 00-965= Warszawa

Biuro UK: The Broadgate Tower, 20 Primro= se Street, London EC2A 2EW

Biuro USA: 401 North Michigan Avenue, Ch= icago, Illinois, 60611

Sekretariat: +48 726 666 655 | Infoli= nia: +48 68 410 99 50

biuro@cinkciarz.pl | https://cinkciarz.pl

=09

KRS 0000364722 | Kapita=C5=82 zak=C5=82adowy 23= .263.500 z=C5=82

REGON 080465538 | NIP 9291830388

Audited by: Grant Thornton

=09 =09 =09

3D"Oficjalny

=09

Tre=C5=9B=C4=87 tej wiadomo=C5=9Bci zawiera inf= ormacje=20 poufne, przeznaczone tylko dla adresata. Udost=C4=99pnianie, ujawnianie,=20 powielanie, rozpowszechnianie b=C4=85d=C5=BA powo=C5=82ywanie si=C4=99 na j= akikolwiek jej=20 fragment przez inne osoby jest zabronione. W razie przypadkowego=20 otrzymania tej wiadomo=C5=9Bci prosimy o powiadomienie o tym nadawcy oraz= =20 trwa=C5=82e jej usuni=C4=99cie. Informacje zawarte w tej wiadomo=C5=9Bci mo= g=C4=85 by=C4=87=20 obj=C4=99te tajemnic=C4=85 zawodow=C4=85 lub chronione innymi przepisami pr= awnymi.=20 Nadawca nie bierze odpowiedzialno=C5=9Bci za jakiekolwiek szkody spowodowan= e=20 wirusem komputerowym przetransmitowanym w tej wiadomo=C5=9Bci.=C2=A0 Pogl= =C4=85dy i=20 opinie przedstawione w tej wiadomo=C5=9Bci s=C4=85 wy=C5=82=C4=85cznie pogl= =C4=85dami i opiniami=20 jej autora i niekoniecznie reprezentuj=C4=85 pogl=C4=85dy i opinie firmy.

This is a confidential e-mail intended=20 solely for the use of the entity or the individual to whom it is=20 addressed. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. If you have received this message in error please send it back to the sender=20 and delete it. It may also be privileged or otherwise protected by work=20 product immunity or other legal rules. The company accepts no liability=20 for any damage caused by any virus transmitted by this e-mail. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.

=09
--001a1140042a1955220521e5085f-- --001a1140042a1955260521e50860 Content-Type: image/png; name="D377E800-0A1A-43D3-AF5E-165F697789B5[3].png" Content-Disposition: inline; filename="D377E800-0A1A-43D3-AF5E-165F697789B5[3].png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: b67a3c8902c37ddd_0.0.2 iVBORw0KGgoAAAANSUhEUgAAAfQAAABRCAIAAACrEsM0AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAKiklEQVR4 Ae2dPWwURxiGA0oDCQSUVEFA6OwKE4gLBATrnEDHXZtItpFIEWEJJ1RGQoCQ7Cr8JEYpEsk2Rdo7 l4l8AgJKARicBrvjJ6FKpPAnUpLXfNHcaPe8d2u45Zh9rNNpdvab2ZlnrHe/+3ZmdtmzZ8/e4A8C EIAABMIisDys7tAbCEAAAhBYIIC4838AAQhAIEACiHuAg0qXIAABCCDu/A9AAAIQCJAA4h7goNIl CEAAAog7/wMQgAAEAiSAuAc4qHQJAhCAAOLO/wAEIACBAAkg7gEOKl2CAAQg8ObrguDO/b8r1ZkH j56qwbu7O3d3d7wuLaedEIAABLInsKz9tx+YKF+uVGenqtd9OgOlneMjB/wc0hCAAAQg4Ai0r7hf vDo/WblSmZ558HjBW4//Sdwl8fF8ciAAAQhAoO3EXeGXs+d/UQRGieThUWTmwuRwsg1nIQABCOST QLvE3B88/nei/Otk+crs/L18jgS9hgAEIPASCbx6ca8bUn+JPaQqCEAAAjkk8MrEvWFIveFg9Bd3 NLTBAAIQgEA+CWQt7s2H1JPHY6hvD09TkxFxFgIQyDOBjMT9ZYXUP1j3XrGw9VDfp0rkedjoOwQg AIFkAlmIu56RlgbPNpz9ktxQ+en7Cluk7MlmnIUABCAAARHIYirkltLRJc+B6erYID+92LttzaoV DBgEIAABCDRJoOWeu2R9CcpO+KXJ8cMMAhCAQF0CLRd32w2m7rXjmWtWrSz2btU0mPjWMbpDPJ8F f/edVW8XC108TY3TIwcCEICAI9BycXdXSk5IzaXp8fCLIvVarao1q37IXvvMaGcClqcmI+UsBCCQ ZwJZxNw39R72pdnHrfDLQki9sDUy+0WzayrTCwqu6fC+vZ8+PfyZJkT6OaQhAAEIQMAIZCHuiqj0 9I36+39Z+EWyruelkZGQnz5Vvallq5H8+CF7y8SZkAMBCEDACGQRlpGC366e0tYxv8//IVnf3LE+ HjG3kLo03b8HMEgQgAAEILA0AlmIu1qmiYx1QygWUl/afmF6srq0PlMKAhCAQPAEMhL3CEcLqcdf wRExSz4cKG1PNuAsBCAAgdwSyFrcLaSe8AqOZkZCsR09TWW1ajOssIEABPJJICNxV/ilyVdwJA+D wvf9pR0DpV0sWE0GxVkIQCDnBLIQ9/hsmbTQWbCalhj2EIBAzglkMRUyYZ57Q/rsF9YQEQYQgAAE 4gRa7rlrFdJiK5jirXE5iy1YdQYkIAABCEAggUDLxT3h2vFTCr9oEwJ565EFq7K0t/E9fPxE6Y8/ 6hjq30vYPQ6QHAhAAAJGoOXivmb1yoask/cLW3gSOz3jL27Sr4Gp6o0L54+g7w3ZYgABCOSTQBYx 957+0cW2iNlX2FZ3i0dFcuSqa2+ZhJDOsYPF44OlfA4bvYYABCCQTKDlnrsuXx4b6ukb0ZwZ1xRF XRL2C5Or7hu7UpHEpWuL7ikWseQQAhCAQN4IZCHuCp7cLJ/U8qXZuQV9147tdfcLmyj/pr188zYA 9BcCEIBAKwhkIe7Wbi0oja8plYceD6k32U/2lmkSFGYQgEAOCWQn7j7cZkLqvn3d9FDfJ3XzyYQA BCAAgUzF3fYLazKknjA2Ctlrb5n4q/gSinAKAhCAQK4IZCTuCr8cH5t68ZC6ZtdoM8h4eCdXY0Zn IQABCDQkkIW461FqafDbhk1JMNAD2IXZNb3bmNieQIlTEIAABByBLOa5r+3+0l+C5K7dMKHwi5x0 yXp8wWrDshhAAAIQyDOBlnvuWr6UVtltweq+whbCL3n+16TvEIDAixBoubinahz7haXChTEEIACB xQi0XNyb2VtGUZfF9gtbrN3kQwACEIBAAoGWi7uehcofr7u3jIVfFFKPL1hNaDGnIAABCECgIYEs Hqhqentp8Iyv74vtF9awuRhAAAIQgEAzBLIQd2uHprrPzt1VlKarYyOzX5oZG2wgAAEILJlAduK+ 5CZSEAIQgAAE0hJYnrYA9hCAAAQg0P4EEPf2HyNaCAEIQCA1AcQ9NTIKQAACEGh/Aoh7+48RLYQA BCCQmgDinhoZBSAAAQi0PwHEvf3HiBZCAAIQSE0AcU+NjAIQgAAE2p/Ay9l+QAuUHjx66vc2+TVJ 9komvWxPRbSgqatzo+1A4OdrudPu7s7kfBVXJRevzllVdV+97beKNAQgAIGcEEixiGlZZ38cyoXJ Yel4T/+ov7uAzLRvjN6EN1DaqbQVNEsdHh8rnzhXiVT1bG5Sd4ievlF/f2DVrFIT5ctfjf4Uz1cN yj9z/me/Kt0Mxke/sFuCa7C7tLXz2MHi8cGSX4o0BCAAgcAIpPbcpZv+Ro9+2kcjLd5/5Mf4u5N8 OZbPro9cfsm6ypYGz5qC2yXcTwGn7JF83SScsus2MDt3T8VV1f7hH26WT/qNOXGuvLt72M8hDQEI QCBsAqnF/fTw5wkhFzngCq309I2YXmszGd9YwRMnx/Lrh/r2GFwLqti3XH4nzarKvetDyu7nq6Be tG3FrSoZbyp8bfouZ99+NJiBKtHHb4nl8w0BCEAgVAKpH6jOzt81rbTvCJfnmbecTEf0VMFxs5dS O2VXju0jJllXWuq8qfewvHXdHvTGVIXjrYgOLV+VK18XMjdfpawqZTpBtwZYQcuU826HfEMAAhDI A4HUnrtk1+ciV90/VFDbDqW546MH/FNKO83dV/gwckqHcsAVyTEzOfj6SJfHRw5Iu83fV3HLV9Bc z1qthq7ODa6qjevetfSla/MuU8Zy5HUz0LfLJAEBCEAgbAKpxV2Cu/H9/zU0AY3c6jWr3ooYuAD9 7PyfkVM6VM3y0xVsqUzPmFcuOdarPCT6uhlMVq64fD2PNWdfpVxo3k9rV2FXvyyl7yril3JnSUAA AhAIkkDqsIzeh6epJu4TgSJHXlpsmZLjyFnnbk9Vr1tQPmKgcI1c9X+ufq+3edgp026Fd5R/u3pK Bpbv3SfuuR8EU9Ubdta58HY41L9XvyRkpoeulsM3BCAAgbAJpPbcJdkudC40credE22kBkq7LHQj R1uK7OOTNEumFSFR5pbSUfcjQHXenv6mOPjd2tUrNnes19lLV2+5ggq1FwtbpdcSeqfj8s1V3CIt mmYjB79SnbUbhnRcbXDFlVA4Xgby3O0HgX+KNAQgAIEgCaQW90jkWs54RNylpPK75ZtLSWUsCfbB lceG3Cv3/Kqk+BL0iPjqTqCPhdr9SuyOonk7mo0jQdfHgvWysVi/2uDbKy3nXQGfSP0RGw4hAAEI BEMghbgrch3vtim7H+OWzUBp+8PHT5QwR9sKmqVkV0uKKtWZqerNO/f/sgrtxXtyrv0HoYqzmwOu B6qaouMurbiQ3TBUlSZH6g4hn90up3pUibvZ+A2WcXnskP3mcNEhVycJCEAAAoERSLFCNbCe0x0I QAACARNI/UA1YBZ0DQIQgEAwBBD3YIaSjkAAAhCoEUDcayxIQQACEAiGAOIezFDSEQhAAAI1Aoh7 jQUpCEAAAsEQQNyDGUo6AgEIQKBGAHGvsSAFAQhAIBgCiHswQ0lHIAABCNQIIO41FqQgAAEIBEMA cQ9mKOkIBCAAgRqB/wAoLQQNWSy3+QAAAABJRU5ErkJggg== --001a1140042a1955260521e50860 Content-Type: image/png; name="13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png" Content-Disposition: inline; filename="13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png" Content-Transfer-Encoding: base64 Content-ID: <38D90A02-02DF-42BF-BD83-10259A0C83C4> X-Attachment-Id: b67a3c8902c37ddd_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAP8AAAADCAIAAADTOk7/AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAABKUlEQVRI De1TMU4DQQycu5yokNKglEhIfIEf8JEoHSU/gAfkATQ8gMcgGigR0CYSDVRhzdheL7sogT6602o1 6xmPvb67TkQAvKzu7l+v1x9PSbovWwm9A+4R1EhCFhjbB2UapUwTJqHPwU1lpYlhZSaRWAU3stOf KYIeXNLpnjFBOXaQiHswH02guChbk8bzT5NGSZNdnqViCEonohMBX4HepwIW/J/6lV5nbaWsEMs1 zp61lSqNJUCSZQEpWavoRSa2BkCB7wEG0UsyPoCySmBHshPOS1CxJoMoRf1Plh4ps3KuL7VUVumb uLdkrH7hB2qrAj7HNxfTxTkBO9Tn4e3q/fPR8biPE9jjCfAfeL689Qvmr/90Nj86PNvjO49XGydQ JnCynDv+BsiTWPQxCGmXAAAAAElFTkSuQmCC --001a1140042a1955260521e50860-- From nobody Mon Oct 12 02:47:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CCE1AC3C3 for ; Mon, 12 Oct 2015 02:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILsuzAxIUEpV for ; Mon, 12 Oct 2015 02:47:45 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818A01AC39E for ; Mon, 12 Oct 2015 02:47:44 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-93-561b81be2f69 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.9E.05274.EB18B165; Mon, 12 Oct 2015 11:47:42 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.184]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Mon, 12 Oct 2015 11:47:41 +0200 From: John Mattsson To: =?utf-8?B?TWljaGHFgiBTdGFydWNo?= Thread-Topic: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security Thread-Index: AQHRBMydOHy9F9/ta0KlukZnanicFp5ndysAgAAlTQA= Date: Mon, 12 Oct 2015 09:47:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.147] Content-Type: multipart/mixed; boundary="_005_D2414B813D964johnmattssonericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUyM+Jvje6+Rukwg0+L9C1eHf7IbvHpfBej A5NH38o1LB5LlvxkCmCK4rJJSc3JLEst0rdL4Mrom3aDrWBHF1NF1/qpTA2M75uYuhg5OSQE TCRmz3vFAmGLSVy4t56ti5GLQ0jgKKNE49RHTBDOEkaJWUensoFUsQkYSMzd0wBkc3CICFhI TLmUBBJmFlCU2LPtJDuILSzgKnGr5x9YuYiAm8TUptnMELaVxOXnzWCLWQRUJZ50tIAt5hUw l/jV0QDWKyRQJ/Hm0kGwGk6BQInG2xD1jEDHfT+1hglil7jErSfzoR4QkXh48TQbhC0q8fLx P1aQ00QF9CT2LJcEMSUElCSmbU2D6AyTWPL3OxvEVkGJkzOfsExgFJuFZOgsJGWzkJRBxGMk lt59yzwLaCqzgKbE+l36s6B+n9L9kB3C1pBonTMXyraWaH9xjQVTjbfEhD1f2SBsB4mvv7cD 1XAB2acYJR7OP8QGMd9IYsM2Tmx6r+zZxw5R4iAxZ5YuRBio9fE8bwjbSGLJvZ+MyFoXMAqv YhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAhMUQe3/FbdwXj5jeMhRgEORiUe3ge3pcKEWBPL iitzDzFKc7AoifM2Mz0IFRJITyxJzU5NLUgtii8qzUktPsTIxMEp1cConPSyc53WZv6fSbEP uCY17LEoVzzxdNYFL5ufu68WvhV2UXitfSSy0irnAEP3jsuN82Z7XJjCscV1p8bOZue6VseJ Qfy39969X5v1Lz8o5eEhrkrb+n+zZm6+on1RamWb8lrjmyd4z06Nu8hutPSBH9/PyPA/jlrX w5mWz5PYtOd5dOrE7sRoJZbijERDLeai4kQAvt3xlzIDAAA= Archived-At: Cc: "TLS@ietf.org" Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 09:47:48 -0000 --_005_D2414B813D964johnmattssonericssoncom_ Content-Type: multipart/alternative; boundary="_000_D2414B813D964johnmattssonericssoncom_" --_000_D2414B813D964johnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IE1pY2hhxYIgU3RhcnVjaCA8bXN0YUBjaW5rY2lhcnoucGw8bWFpbHRvOm1zdGFA Y2lua2NpYXJ6LnBsPj4NCkRhdGU6IE1vbmRheSAxMiBPY3RvYmVyIDIwMTUgMTE6MzQNClRvOiBK b2huIE1hdHRzc29uMiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmpvaG4ubWF0 dHNzb25AZXJpY3Nzb24uY29tPj4NCkNjOiAiVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5v cmc+IiA8VExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtU TFNdIFRMUyAxLjMgUmVjb21tZW5kZWQgRUNDIGN1cnZlIGZvciAxOTItYml0IHNlY3VyaXR5DQoN Cj5XZSBhbHJlYWR5IGhhdmUgIlNIT1VMRCBzdXBwb3J0IGtleSBleGNoYW5nZSB3aXRoIFgyNTUx OSIgaW4gdGhpcyBzZWN0aW9uLA0KDQpZZXMsIGJ1dCBYMjU1MTkgaXMgYWxzbyBvbmx5IHByb3Zp ZGluZyAxMjgtYml0IHNlY3VyaXR5IChvciAxMjcuNSkuDQoNCj5zbyBwZW9wbGUgaW1wbGVtZW50 aW5nIGl0IHNob3VsZCBoYXZlIG5vIHByb2JsZW1zIHdpdGggYWRvcHRpbmcgWDQ0ODxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0Zi1jZnJnLWN1cnZlcy0xMCNzZWN0aW9uLTYu Mj4gdG8gYWNoaWV2ZSB+MjI0IGJpdCBzZWN1cml0eSB3aGVyZSBpdCdzIG5lZWRlZCAoYW5kID5i ZXR0ZXIgcGVyZm9ybWFuY2UgdGhhbiBQLTM4NCkuDQoNClBlb3BsZSB3aWxsIHByb2JhYmx5IG5v dCBoYXZlIGFueSBwcm9ibGVtcyBhZG9wdGluZyBYNDQ4LCBQLTM4NCwgb3IgYnJhaW5wb29sUDM4 NHIxLiBUaGUgcHJvYmxlbSBpcyB0aGF0IGRpZmZlcmVudCBsaWJyYXJpZXMgbWF5IHN1cHBvcnQg ZGlmZmVyZW50IGN1cnZlcyBhbmQgc3RhcnQgZGl2ZXJnaW5nLiBTdGF0aW5nIFNIT1VMRCBzdXBw b3J0IGZvciBUTFNfRUNESEVfUlNBX1dJVEhfQUVTXzI1Nl9HQ01fU0hBMzg0IHdpdGhvdXQgc3Bl Y2lmeWluZyBhIG1hdGNoaW5nIEVDQyBjdXJ2ZSBpcyBqdXN0IGhhbGYgb2Ygd2hhdCBpcyBuZWVk ZWQgZm9yIGludGVyb3BlcmFiaWxpdHkuDQoNClRoZSBzZW50ZW5jZSAiVGhlc2UgY2lwaGVyIHN1 aXRlcyBTSE9VTEQgc3VwcG9ydCBib3RoIGRpZ2l0YWwgc2lnbmF0dXJlcyBhbmQga2V5IGV4Y2hh bmdlIHdpdGggWDQ0OC7igJ0gd291bGQgYmUgZXF1YWxseSBnb29kLg0KDQpPbiBNb24sIE9jdCAx MiwgMjAxNSBhdCAxMTowMSBBTSwgSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3NvbkBlcmljc3Nv bi5jb208bWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpJIHRoaW5r IHRoZSBzZWxlY3Rpb24gb2YgTVRJIENpcGhlciBTdWl0ZXMgKFNlY3Rpb24gOC4xIG9mIGRyYWZ0 LWlldGYtdGxzLXRsczEzLTA5KSBpcyBleGNlbGxlbnQsIGJ1dCBJIGFtIG1pc3NpbmcgYSByZWNv bW1lbmRlZCBFQ0MgY3VydmUgZm9yIHRoZSDigJxTSE9VTETigJ0gY2lwaGVyIHN1aXRlcy4gTGl0 dGxlIGJlbmVmaXQgb2YgdXNpbmcgQUVTLTI1NiB3aXRoIFAtMjU2IG9yIGN1cnZlMjU1MTkuIFNo b3VsZG7igJl0IHRoZXJlIGJlIGEgU0hPVUxEIGltcGxlbWVudCBFQ0MgY3VydmUgZ2l2aW5nIGF0 IGxlYXN0IDE5Mi1iaXQgc2VjdXJpdHk/IEUuZy4NCg0KIlRoZXNlIGNpcGhlciBzdWl0ZXMgU0hP VUxEIHN1cHBvcnQgYm90aCBkaWdpdGFsIHNpZ25hdHVyZXMgYW5kIGtleSBleGNoYW5nZSB3aXRo IHNlY3AzODRyMSAoTklTVCBQLTM4NCkuIg0KDQpDaGVlcnMsDQpKb2huDQoNCg0KSk9ITiBNQVRU U1NPTg0KTVNjIEVuZ2luZWVyaW5nIFBoeXNpY3MsIE1TYyBCdXNpbmVzcyBBZG1pbmlzdHJhdGlv biBhbmQgRWNvbm9taWNzDQpFcmljc3NvbiBJRVRGIFNlY3VyaXR5IENvb3JkaW5hdG9yDQpTZW5p b3IgUmVzZWFyY2hlciwgU2VjdXJpdHkNCg0KRXJpY3Nzb24gQUINCkVyaWNzc29uIFJlc2VhcmNo DQpGw6Ryw7ZnYXRhbiA2DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4NClBob25lICs0NiAx MCA3MSA0MyA1MDENClNNUy9NTVMgKzQ2IDc2IDExIDUzIDUwMQ0Kam9obi5tYXR0c3NvbkBlcmlj c3Nvbi5jb208bWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPg0Kd3d3LmVyaWNzc29u LmNvbTxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8+DQoNCg0KW2h0dHA6Ly93d3cuZXJpY3Nzb24u Y29tL108aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vPg0KDQpUaGlzIENvbW11bmljYXRpb24gaXMg Q29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lz IG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVy PGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+DQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QN ClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90bHMNCg0KDQoNCg0KLS0NCg0KUG96ZHJhd2lhbSB8IEJlc3QgUmVn YXJkcw0KDQpNaWNoYcWCIFN0YXJ1Y2ggfCBJbmZvcm1hdGlvbiBTZWN1cml0eSBPZmZpY2VyDQoN CnVsLiBTaWVua2lld2ljemEgOSwgNjUtMDAxIFppZWxvbmEgR8OzcmENCg0KbXN0YUBjaW5rY2lh cnoucGw8bWFpbHRvOm1zdGFAY2lua2NpYXJ6LnBsPg0KDQpGaW5kIHVzIG9uIEJsb29tYmVyZyBD S1BMIDxHTz4NCg0KW0NpbmtjaWFyei5wbCBTcC4gei5vLm9dPGh0dHBzOi8vY2lua2NpYXJ6LnBs Pg0KDQpDaW5rY2lhcnoucGwgU3AuIHogby5vLg0KDQpTaWVkemliYTogdWwuIFNpZW5raWV3aWN6 YSA5LCA2NS0wMDEgWmllbG9uYSBHw7NyYQ0KDQpCaXVybyBQTDogQWwuIEplcm96b2xpbXNraWUg MTIzQSwgMDAtOTY1IFdhcnN6YXdhDQoNCkJpdXJvIFVLOiBUaGUgQnJvYWRnYXRlIFRvd2VyLCAy MCBQcmltcm9zZSBTdHJlZXQsIExvbmRvbiBFQzJBIDJFVw0KDQpCaXVybyBVU0E6IDQwMSBOb3J0 aCBNaWNoaWdhbiBBdmVudWUsIENoaWNhZ28sIElsbGlub2lzLCA2MDYxMQ0KDQpTZWtyZXRhcmlh dDogKzQ4IDcyNiA2NjYgNjU1IHwgSW5mb2xpbmlhOiArNDggNjggNDEwIDk5IDUwDQoNCmJpdXJv QGNpbmtjaWFyei5wbDxtYWlsdG86Yml1cm9AY2lua2NpYXJ6LnBsPiB8IGh0dHBzOi8vY2lua2Np YXJ6LnBsDQoNCktSUyAwMDAwMzY0NzIyIHwgS2FwaXRhxYIgemFrxYJhZG93eSAyMy4yNjMuNTAw IHrFgg0KDQpSRUdPTiAwODA0NjU1MzggfCBOSVAgOTI5MTgzMDM4OA0KDQpBdWRpdGVkIGJ5OiBH cmFudCBUaG9ybnRvbg0KDQpbT2ZpY2phbG55IHNwb25zb3IgUmVwcmV6ZW50YWNqaSBQb2xza2kg dyBwacWCY2Ugbm/FvG5lal0NCg0KVHJlxZvEhyB0ZWogd2lhZG9tb8WbY2kgemF3aWVyYSBpbmZv cm1hY2plIHBvdWZuZSwgcHJ6ZXpuYWN6b25lIHR5bGtvIGRsYSBhZHJlc2F0YS4gVWRvc3TEmXBu aWFuaWUsIHVqYXduaWFuaWUsIHBvd2llbGFuaWUsIHJvenBvd3N6ZWNobmlhbmllIGLEhWTFuiBw b3dvxYJ5d2FuaWUgc2nEmSBuYSBqYWtpa29sd2llayBqZWogZnJhZ21lbnQgcHJ6ZXogaW5uZSBv c29ieSBqZXN0IHphYnJvbmlvbmUuIFcgcmF6aWUgcHJ6eXBhZGtvd2VnbyBvdHJ6eW1hbmlhIHRl aiB3aWFkb21vxZtjaSBwcm9zaW15IG8gcG93aWFkb21pZW5pZSBvIHR5bSBuYWRhd2N5IG9yYXog dHJ3YcWCZSBqZWogdXN1bmnEmWNpZS4gSW5mb3JtYWNqZSB6YXdhcnRlIHcgdGVqIHdpYWRvbW/F m2NpIG1vZ8SFIGJ5xIcgb2JqxJl0ZSB0YWplbW5pY8SFIHphd29kb3fEhSBsdWIgY2hyb25pb25l IGlubnltaSBwcnplcGlzYW1pIHByYXdueW1pLiBOYWRhd2NhIG5pZSBiaWVyemUgb2Rwb3dpZWR6 aWFsbm/Fm2NpIHphIGpha2lla29sd2llayBzemtvZHkgc3Bvd29kb3dhbmUgd2lydXNlbSBrb21w dXRlcm93eW0gcHJ6ZXRyYW5zbWl0b3dhbnltIHcgdGVqIHdpYWRvbW/Fm2NpLiAgUG9nbMSFZHkg aSBvcGluaWUgcHJ6ZWRzdGF3aW9uZSB3IHRlaiB3aWFkb21vxZtjaSBzxIUgd3nFgsSFY3puaWUg cG9nbMSFZGFtaSBpIG9waW5pYW1pIGplaiBhdXRvcmEgaSBuaWVrb25pZWN6bmllIHJlcHJlemVu dHVqxIUgcG9nbMSFZHkgaSBvcGluaWUgZmlybXkuDQoNClRoaXMgaXMgYSBjb25maWRlbnRpYWwg ZS1tYWlsIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgZW50aXR5IG9yIHRoZSBp bmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBVbmF1dGhvcml6ZWQgcHVibGljYXRp b24sIHVzZSwgZGlzc2VtaW5hdGlvbiBvciBkaXNjbG9zdXJlIG9mIHRoaXMgbWVzc2FnZSwgZWl0 aGVyIGluIHdob2xlIG9yIGluIHBhcnQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yIHBsZWFzZSBzZW5kIGl0IGJhY2sgdG8g dGhlIHNlbmRlciBhbmQgZGVsZXRlIGl0LiBJdCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkIG9yIG90 aGVyd2lzZSBwcm90ZWN0ZWQgYnkgd29yayBwcm9kdWN0IGltbXVuaXR5IG9yIG90aGVyIGxlZ2Fs IHJ1bGVzLiBUaGUgY29tcGFueSBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSBj YXVzZWQgYnkgYW55IHZpcnVzIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZS1tYWlsLiBBbnkgdmlld3Mg b3Igb3BpbmlvbnMgcHJlc2VudGVkIGluIHRoaXMgZS1tYWlsIGFyZSBzb2xlbHkgdGhvc2Ugb2Yg dGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aG9zZSBvZiB0aGUg Y29tcGFueS4NCg== --_000_D2414B813D964johnmattssonericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9A27D3B2EABB234CBA45A5FABAAAF187@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkct Qk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRF Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE SU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3Nw YW4+TWljaGHFgiBTdGFydWNoICZsdDs8YSBocmVmPSJtYWlsdG86bXN0YUBjaW5rY2lhcnoucGwi Pm1zdGFAY2lua2NpYXJ6LnBsPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSAxMiBPY3RvYmVyIDIwMTUgMTE6MzQ8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5Kb2huIE1hdHRzc29uMiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tIj5qb2huLm1hdHRzc29u QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDog PC9zcGFuPlJlOiBbVExTXSBUTFMgMS4zIFJlY29tbWVuZGVkIEVDQyBjdXJ2ZSBmb3IgMTkyLWJp dCBzZWN1cml0eTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+Jmd0O1dlIGFscmVhZHkgaGF2ZSAmcXVvdDtTSE9VTEQgc3VwcG9ydCBr ZXkgZXhjaGFuZ2Ugd2l0aCBYMjU1MTkmcXVvdDsgaW4gdGhpcyBzZWN0aW9uLDwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlllcywgYnV0IFgy NTUxOSBpcyBhbHNvIG9ubHkgcHJvdmlkaW5nIDEyOC1iaXQgc2VjdXJpdHkgKG9yIDEyNy41KS48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4mZ3Q7c28gcGVvcGxlIGltcGxlbWVudGlu ZyBpdCBzaG91bGQgaGF2ZSBubyBwcm9ibGVtcyB3aXRoIGFkb3B0aW5nIDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLWNmcmctY3VydmVzLTEwI3NlY3Rpb24t Ni4yIj4NClg0NDg8L2E+IHRvIGFjaGlldmUgfjIyNCBiaXQgc2VjdXJpdHkgd2hlcmUgaXQncyBu ZWVkZWQgKGFuZCAmZ3Q7YmV0dGVyIHBlcmZvcm1hbmNlIHRoYW4gUC0zODQpLjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBlb3BsZSB3aWxs IHByb2JhYmx5IG5vdCBoYXZlIGFueSBwcm9ibGVtcyBhZG9wdGluZyBYNDQ4LCBQLTM4NCwgb3Ig YnJhaW5wb29sUDM4NHIxLiBUaGUgcHJvYmxlbSBpcyB0aGF0IGRpZmZlcmVudCBsaWJyYXJpZXMg bWF5IHN1cHBvcnQgZGlmZmVyZW50IGN1cnZlcyBhbmQgc3RhcnQgZGl2ZXJnaW5nLiBTdGF0aW5n IFNIT1VMRCBzdXBwb3J0IGZvciBUTFNfRUNESEVfUlNBX1dJVEhfQUVTXzI1Nl9HQ01fU0hBMzg0 IHdpdGhvdXQgc3BlY2lmeWluZw0KIGEgbWF0Y2hpbmcgRUNDIGN1cnZlIGlzIGp1c3QgaGFsZiBv ZiB3aGF0IGlzIG5lZWRlZCBmb3IgaW50ZXJvcGVyYWJpbGl0eS48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoZSBzZW50ZW5jZSAmcXVvdDtUaGVzZSBjaXBoZXIgc3VpdGVzIFNIT1VM RCBzdXBwb3J0IGJvdGggZGlnaXRhbCBzaWduYXR1cmVzIGFuZCBrZXkgZXhjaGFuZ2Ugd2l0aCBY NDQ4LuKAnSB3b3VsZCBiZSBlcXVhbGx5IGdvb2QuPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBPY3Qg MTIsIDIwMTUgYXQgMTE6MDEgQU0sIEpvaG4gTWF0dHNzb24gPHNwYW4gZGlyPSJsdHIiPg0KJmx0 OzxhIGhyZWY9Im1haWx0bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj5JIHRoaW5rIHRoZSBzZWxlY3Rp b24gb2YgTVRJIENpcGhlciBTdWl0ZXMgKFNlY3Rpb24gOC4xIG9mIGRyYWZ0LWlldGYtdGxzLXRs czEzLTA5KSBpcyBleGNlbGxlbnQsIGJ1dCBJIGFtIG1pc3NpbmcgYSByZWNvbW1lbmRlZCBFQ0Mg Y3VydmUgZm9yIHRoZSDigJxTSE9VTETigJ0gY2lwaGVyIHN1aXRlcy4gTGl0dGxlIGJlbmVmaXQg b2YgdXNpbmcgQUVTLTI1NiB3aXRoIFAtMjU2IG9yIGN1cnZlMjU1MTkuIFNob3VsZG7igJl0IHRo ZXJlIGJlIGEgU0hPVUxEDQogaW1wbGVtZW50IEVDQyBjdXJ2ZSBnaXZpbmcgYXQgbGVhc3QgMTky LWJpdCBzZWN1cml0eT8gRS5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+JnF1b3Q7 VGhlc2UgY2lwaGVyIHN1aXRlcyBTSE9VTEQgc3VwcG9ydCBib3RoIGRpZ2l0YWwgc2lnbmF0dXJl cyBhbmQga2V5IGV4Y2hhbmdlIHdpdGggc2VjcDM4NHIxIChOSVNUIFAtMzg0KS4mcXVvdDs8L2Rp dj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9kaXY+ DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+Q2hlZXJzLDwvc3Bhbj48L2Rpdj4N CjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij5Kb2huPC9zcGFuPjwvZGl2Pg0KPGRp dj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O21hcmdp bjowY20gMGNtIDEycHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsiPjxpbWcgc3JjPSJjaWQ6MzhEOTBBMDItMDJERi00MkJGLUJE ODMtMTAyNTlBMEM4M0M0IiBhbHQ9ImxpbmUiIHR5cGU9ImltYWdlL3BuZyIgaGVpZ2h0PSIzIiB3 aWR0aD0iMjU1Ij48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iZm9udC1zaXplOjExcHQ7bWFyZ2luOjBjbSAwY20gMC4wMDAxcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYig1MSwgNTEsIDUxKTsiPkpPSE4gTUFUVFNTT048dT48L3U+PHU+PC91Pjwvc3Bh bj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O21h cmdpbjowY20gMGNtIDAuMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7Ij5N U2MgRW5naW5lZXJpbmcgUGh5c2ljcywgTVNjIEJ1c2luZXNzIEFkbWluaXN0cmF0aW9uIGFuZCBF Y29ub21pY3M8L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46MGNtIDBjbSAwLjAwMDFwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYig1MSw1MSw1MSkiPjxm b250IGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzcHgiPjxiPkVyaWNzc29u IElFVEYgU2VjdXJpdHkgQ29vcmRpbmF0b3I8L2I+PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiIHNpemU9IjMiPiZuYnNwOzwvZm9udD48L3NwYW4+PGIgc3R5bGU9 ImZvbnQtc2l6ZToxMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7Ij48YnI+DQpTZW5p b3IgUmVzZWFyY2hlciwgU2VjdXJpdHk8L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJmb250LXNpemU6MTFwdDttYXJnaW46MGNtIDBjbSAwLjAwMDFwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOnJnYig1MSw1MSw1MSkiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig1 MSwgNTEsIDUxKTsiPkVyaWNzc29uIEFCPGJyPg0KRXJpY3Nzb24gUmVzZWFyY2g8YnI+DQpGw6Ry w7ZnYXRhbiA2PGJyPg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuPGJyPg0KUGhvbmUgJiM0 Mzs0NiAxMCA3MSA0MyA1MDE8YnI+DQpTTVMvTU1TICYjNDM7NDYgNzYgMTEgNTMgNTAxPGJyPg0K PGEgaHJlZj0ibWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tIiBzdHlsZT0iY29sb3I6 cHVycGxlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPmpvaG4ubWF0 dHNzb25AZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC1zaXplOjExcHQ7bWFyZ2luOjBjbSAwY20g MC4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyI+PGEgaHJlZj0iaHR0cDovL3d3 dy5lcmljc3Nvbi5jb20vIiBzdHlsZT0iY29sb3I6cHVycGxlIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsdWUiPnd3dy5lcmljc3Nvbi5jb208L3NwYW4+PC9hPjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6 MTFwdDttYXJnaW46MGNtIDBjbSAwLjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0 OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij48YnI+DQo8YnI+DQo8L3NwYW4+PGEg aHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vIiBzdHlsZT0iY29sb3I6cHVycGxlIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij48aW1n IHNyYz0iY2lkOkFCQzQ0MjIxLURGQTItNEFEMi1BRjc3LTk0NzQyMUI2RTYyNiIgYWx0PSJodHRw Oi8vd3d3LmVyaWNzc29uLmNvbS8iIHR5cGU9ImltYWdlL3BuZyIgYm9yZGVyPSIwIiBoZWlnaHQ9 IjgxIiB3aWR0aD0iNTAwIj48L3NwYW4+PC9hPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0O21hcmdpbjowY20gMGNtIDAuMDAwMXB0 Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJm b250LXNpemU6MTFwdDttYXJnaW46MGNtIDBjbSAwLjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogOHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoNTEs IDUxLCA1MSk7Ij5UaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNl bmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0 PGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciIgdGl0bGU9 Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiIHN0eWxlPSJjb2xvcjpw dXJwbGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+d3d3LmVyaWNz c29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9zcGFuPjwvYT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48 YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxiciBjbGVhcj0iYWxsIj4N Cjxicj4NCi0tIDxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+DQo8ZGl2IGRpcj0i bHRyIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjoxMHB4IDIweDtmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6IzIyMiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjIwcHg7 Zm9udC1zaXplOjEwcHQiPg0KPHAgc3R5bGU9Im1hcmdpbjoxcHgiPlBvemRyYXdpYW0gfCBCZXN0 IFJlZ2FyZHM8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjFweCI+TWljaGHFgiBTdGFydWNoIHwgSW5m b3JtYXRpb24gU2VjdXJpdHkgT2ZmaWNlcjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MXB4Ij51bC4g U2llbmtpZXdpY3phIDksIDY1LTAwMSBaaWVsb25hIEfDs3JhPC9wPg0KPHAgc3R5bGU9Im1hcmdp bjoxcHgiPjxhIGhyZWY9Im1haWx0bzptc3RhQGNpbmtjaWFyei5wbCIgdGFyZ2V0PSJfYmxhbmsi Pm1zdGFAY2lua2NpYXJ6LnBsPC9hPjwvcD4NCjxwIHN0eWxlPSJmb250LXNpemU6OC41cHQ7bWFy Z2luOjFweCI+RmluZCB1cyBvbiBCbG9vbWJlcmcgQ0tQTCAmbHQ7R08mZ3Q7PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjE1cHgiPjxhIGhyZWY9Imh0dHBzOi8vY2lua2Np YXJ6LnBsIiB0YXJnZXQ9Il9ibGFuayI+PGltZyBzcmM9Imh0dHBzOi8vY2lua2NpYXJ6LnBsL2Zp bGVzL2dyYWZpa2kvd2VfMS5wbmciIGFsdD0iQ2lua2NpYXJ6LnBsIFNwLiB6Lm8ubyI+PC9hPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToyNXB4Ij4NCjxwIHN0eWxlPSJtYXJnaW46 MXB4Ij48Yj5DaW5rY2lhcnoucGwgU3AuIHogby5vLjwvYj48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjFweCI+PGI+U2llZHppYmE6PC9iPiB1bC4gU2llbmtpZXdpY3phIDksIDY1LTAwMSBaaWVsb25h IEfDs3JhIDwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MXB4Ij48Yj5CaXVybyBQTDo8L2I+IEFsLiBK ZXJvem9saW1za2llIDEyM0EsIDAwLTk2NSBXYXJzemF3YSA8L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjFweCI+PGI+Qml1cm8gVUs6PC9iPiBUaGUgQnJvYWRnYXRlIFRvd2VyLCAyMCBQcmltcm9zZSBT dHJlZXQsIExvbmRvbiBFQzJBIDJFVzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MXB4Ij48Yj5CaXVy byBVU0E6PC9iPiA0MDEgTm9ydGggTWljaGlnYW4gQXZlbnVlLCBDaGljYWdvLCBJbGxpbm9pcywg NjA2MTE8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjFweCI+PGI+U2VrcmV0YXJpYXQ6PC9iPiAmIzQz OzQ4IDcyNiA2NjYgNjU1IHwgPGI+SW5mb2xpbmlhOjwvYj4gJiM0Mzs0OCA2OCA0MTAgOTkgNTA8 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjFweCI+PGEgaHJlZj0ibWFpbHRvOmJpdXJvQGNpbmtjaWFy ei5wbCIgdGFyZ2V0PSJfYmxhbmsiPmJpdXJvQGNpbmtjaWFyei5wbDwvYT4gfA0KPGEgaHJlZj0i aHR0cHM6Ly9jaW5rY2lhcnoucGwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NpbmtjaWFyei5w bDwvYT48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206MTVweCI+DQo8cCBz dHlsZT0ibWFyZ2luOjFweCI+S1JTIDAwMDAzNjQ3MjIgfCBLYXBpdGHFgiB6YWvFgmFkb3d5IDIz LjI2My41MDAgesWCPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjoxcHgiPlJFR09OIDA4MDQ2NTUzOCB8 IE5JUCA5MjkxODMwMzg4PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjoxcHgiPkF1ZGl0ZWQgYnk6IEdy YW50IFRob3JudG9uPC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjE1cHgi Pg0KPHAgc3R5bGU9Im1hcmdpbjoxcHgiPjxpbWcgc3JjPSJodHRwczovL2NpbmtjaWFyei5wbC9m aWxlcy9ncmFmaWtpL3B6cG4vb2ZpY2phbG55XzIwMC5wbmciIGFsdD0iT2ZpY2phbG55IHNwb25z b3IgUmVwcmV6ZW50YWNqaSBQb2xza2kgdyBwacWCY2Ugbm/FvG5laiIgc3R5bGU9InZlcnRpY2Fs LWFsaWduOm1pZGRsZSI+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItdG9wOjFweCBz b2xpZCAjYTJhMmEyO2ZvbnQtc2l6ZTo2cHQ7Y29sb3I6I2EyYTJhMiI+DQo8cCBzdHlsZT0ibWFy Z2luOjFweCI+VHJlxZvEhyB0ZWogd2lhZG9tb8WbY2kgemF3aWVyYSBpbmZvcm1hY2plIHBvdWZu ZSwgcHJ6ZXpuYWN6b25lIHR5bGtvIGRsYSBhZHJlc2F0YS4gVWRvc3TEmXBuaWFuaWUsIHVqYXdu aWFuaWUsIHBvd2llbGFuaWUsIHJvenBvd3N6ZWNobmlhbmllIGLEhWTFuiBwb3dvxYJ5d2FuaWUg c2nEmSBuYSBqYWtpa29sd2llayBqZWogZnJhZ21lbnQgcHJ6ZXogaW5uZSBvc29ieSBqZXN0IHph YnJvbmlvbmUuIFcgcmF6aWUgcHJ6eXBhZGtvd2Vnbw0KIG90cnp5bWFuaWEgdGVqIHdpYWRvbW/F m2NpIHByb3NpbXkgbyBwb3dpYWRvbWllbmllIG8gdHltIG5hZGF3Y3kgb3JheiB0cndhxYJlIGpl aiB1c3VuacSZY2llLiBJbmZvcm1hY2plIHphd2FydGUgdyB0ZWogd2lhZG9tb8WbY2kgbW9nxIUg YnnEhyBvYmrEmXRlIHRhamVtbmljxIUgemF3b2Rvd8SFIGx1YiBjaHJvbmlvbmUgaW5ueW1pIHBy emVwaXNhbWkgcHJhd255bWkuIE5hZGF3Y2EgbmllIGJpZXJ6ZSBvZHBvd2llZHppYWxub8WbY2kg emEgamFraWVrb2x3aWVrDQogc3prb2R5IHNwb3dvZG93YW5lIHdpcnVzZW0ga29tcHV0ZXJvd3lt IHByemV0cmFuc21pdG93YW55bSB3IHRlaiB3aWFkb21vxZtjaS4mbmJzcDsgUG9nbMSFZHkgaSBv cGluaWUgcHJ6ZWRzdGF3aW9uZSB3IHRlaiB3aWFkb21vxZtjaSBzxIUgd3nFgsSFY3puaWUgcG9n bMSFZGFtaSBpIG9waW5pYW1pIGplaiBhdXRvcmEgaSBuaWVrb25pZWN6bmllIHJlcHJlemVudHVq xIUgcG9nbMSFZHkgaSBvcGluaWUgZmlybXkuPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjoxcHgiPlRo aXMgaXMgYSBjb25maWRlbnRpYWwgZS1tYWlsIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgZW50aXR5IG9yIHRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBV bmF1dGhvcml6ZWQgcHVibGljYXRpb24sIHVzZSwgZGlzc2VtaW5hdGlvbiBvciBkaXNjbG9zdXJl IG9mIHRoaXMgbWVzc2FnZSwgZWl0aGVyIGluIHdob2xlIG9yIGluIHBhcnQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4NCiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Ig cGxlYXNlIHNlbmQgaXQgYmFjayB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgaXQuIEl0IG1heSBh bHNvIGJlIHByaXZpbGVnZWQgb3Igb3RoZXJ3aXNlIHByb3RlY3RlZCBieSB3b3JrIHByb2R1Y3Qg aW1tdW5pdHkgb3Igb3RoZXIgbGVnYWwgcnVsZXMuIFRoZSBjb21wYW55IGFjY2VwdHMgbm8gbGlh YmlsaXR5IGZvciBhbnkgZGFtYWdlIGNhdXNlZCBieSBhbnkgdmlydXMNCiB0cmFuc21pdHRlZCBi eSB0aGlzIGUtbWFpbC4gQW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIGUt bWFpbCBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3Nhcmls eSByZXByZXNlbnQgdGhvc2Ugb2YgdGhlIGNvbXBhbnkuDQo8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_D2414B813D964johnmattssonericssoncom_-- --_005_D2414B813D964johnmattssonericssoncom_ Content-Type: image/png; name="D377E800-0A1A-43D3-AF5E-165F697789B5[3].png" Content-Description: D377E800-0A1A-43D3-AF5E-165F697789B5[3].png Content-Disposition: attachment; filename="D377E800-0A1A-43D3-AF5E-165F697789B5[3].png"; size=5392; creation-date="Mon, 12 Oct 2015 09:47:41 GMT"; modification-date="Mon, 12 Oct 2015 09:47:41 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAfQAAABRCAIAAACrEsM0AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAKiklEQVR4 Ae2dPWwURxiGA0oDCQSUVEFA6OwKE4gLBATrnEDHXZtItpFIEWEJJ1RGQoCQ7Cr8JEYpEsk2Rdo7 l4l8AgJKARicBrvjJ6FKpPAnUpLXfNHcaPe8d2u45Zh9rNNpdvab2ZlnrHe/+3ZmdtmzZ8/e4A8C EIAABMIisDys7tAbCEAAAhBYIIC4838AAQhAIEACiHuAg0qXIAABCCDu/A9AAAIQCJAA4h7goNIl CEAAAog7/wMQgAAEAiSAuAc4qHQJAhCAAOLO/wAEIACBAAkg7gEOKl2CAAQg8ObrguDO/b8r1ZkH j56qwbu7O3d3d7wuLaedEIAABLInsKz9tx+YKF+uVGenqtd9OgOlneMjB/wc0hCAAAQg4Ai0r7hf vDo/WblSmZ558HjBW4//Sdwl8fF8ciAAAQhAoO3EXeGXs+d/UQRGieThUWTmwuRwsg1nIQABCOST QLvE3B88/nei/Otk+crs/L18jgS9hgAEIPASCbx6ca8bUn+JPaQqCEAAAjkk8MrEvWFIveFg9Bd3 NLTBAAIQgEA+CWQt7s2H1JPHY6hvD09TkxFxFgIQyDOBjMT9ZYXUP1j3XrGw9VDfp0rkedjoOwQg AIFkAlmIu56RlgbPNpz9ktxQ+en7Cluk7MlmnIUABCAAARHIYirkltLRJc+B6erYID+92LttzaoV DBgEIAABCDRJoOWeu2R9CcpO+KXJ8cMMAhCAQF0CLRd32w2m7rXjmWtWrSz2btU0mPjWMbpDPJ8F f/edVW8XC108TY3TIwcCEICAI9BycXdXSk5IzaXp8fCLIvVarao1q37IXvvMaGcClqcmI+UsBCCQ ZwJZxNw39R72pdnHrfDLQki9sDUy+0WzayrTCwqu6fC+vZ8+PfyZJkT6OaQhAAEIQMAIZCHuiqj0 9I36+39Z+EWyruelkZGQnz5Vvallq5H8+CF7y8SZkAMBCEDACGQRlpGC366e0tYxv8//IVnf3LE+ HjG3kLo03b8HMEgQgAAEILA0AlmIu1qmiYx1QygWUl/afmF6srq0PlMKAhCAQPAEMhL3CEcLqcdf wRExSz4cKG1PNuAsBCAAgdwSyFrcLaSe8AqOZkZCsR09TWW1ajOssIEABPJJICNxV/ilyVdwJA+D wvf9pR0DpV0sWE0GxVkIQCDnBLIQ9/hsmbTQWbCalhj2EIBAzglkMRUyYZ57Q/rsF9YQEQYQgAAE 4gRa7rlrFdJiK5jirXE5iy1YdQYkIAABCEAggUDLxT3h2vFTCr9oEwJ565EFq7K0t/E9fPxE6Y8/ 6hjq30vYPQ6QHAhAAAJGoOXivmb1yoask/cLW3gSOz3jL27Sr4Gp6o0L54+g7w3ZYgABCOSTQBYx 957+0cW2iNlX2FZ3i0dFcuSqa2+ZhJDOsYPF44OlfA4bvYYABCCQTKDlnrsuXx4b6ukb0ZwZ1xRF XRL2C5Or7hu7UpHEpWuL7ikWseQQAhCAQN4IZCHuCp7cLJ/U8qXZuQV9147tdfcLmyj/pr188zYA 9BcCEIBAKwhkIe7Wbi0oja8plYceD6k32U/2lmkSFGYQgEAOCWQn7j7cZkLqvn3d9FDfJ3XzyYQA BCAAgUzF3fYLazKknjA2Ctlrb5n4q/gSinAKAhCAQK4IZCTuCr8cH5t68ZC6ZtdoM8h4eCdXY0Zn IQABCDQkkIW461FqafDbhk1JMNAD2IXZNb3bmNieQIlTEIAABByBLOa5r+3+0l+C5K7dMKHwi5x0 yXp8wWrDshhAAAIQyDOBlnvuWr6UVtltweq+whbCL3n+16TvEIDAixBoubinahz7haXChTEEIACB xQi0XNyb2VtGUZfF9gtbrN3kQwACEIBAAoGWi7uehcofr7u3jIVfFFKPL1hNaDGnIAABCECgIYEs Hqhqentp8Iyv74vtF9awuRhAAAIQgEAzBLIQd2uHprrPzt1VlKarYyOzX5oZG2wgAAEILJlAduK+ 5CZSEAIQgAAE0hJYnrYA9hCAAAQg0P4EEPf2HyNaCAEIQCA1AcQ9NTIKQAACEGh/Aoh7+48RLYQA BCCQmgDinhoZBSAAAQi0PwHEvf3HiBZCAAIQSE0AcU+NjAIQgAAE2p/Ay9l+QAuUHjx66vc2+TVJ 9komvWxPRbSgqatzo+1A4OdrudPu7s7kfBVXJRevzllVdV+97beKNAQgAIGcEEixiGlZZ38cyoXJ Yel4T/+ov7uAzLRvjN6EN1DaqbQVNEsdHh8rnzhXiVT1bG5Sd4ievlF/f2DVrFIT5ctfjf4Uz1cN yj9z/me/Kt0Mxke/sFuCa7C7tLXz2MHi8cGSX4o0BCAAgcAIpPbcpZv+Ro9+2kcjLd5/5Mf4u5N8 OZbPro9cfsm6ypYGz5qC2yXcTwGn7JF83SScsus2MDt3T8VV1f7hH26WT/qNOXGuvLt72M8hDQEI QCBsAqnF/fTw5wkhFzngCq309I2YXmszGd9YwRMnx/Lrh/r2GFwLqti3XH4nzarKvetDyu7nq6Be tG3FrSoZbyp8bfouZ99+NJiBKtHHb4nl8w0BCEAgVAKpH6jOzt81rbTvCJfnmbecTEf0VMFxs5dS O2VXju0jJllXWuq8qfewvHXdHvTGVIXjrYgOLV+VK18XMjdfpawqZTpBtwZYQcuU826HfEMAAhDI A4HUnrtk1+ciV90/VFDbDqW546MH/FNKO83dV/gwckqHcsAVyTEzOfj6SJfHRw5Iu83fV3HLV9Bc z1qthq7ODa6qjevetfSla/MuU8Zy5HUz0LfLJAEBCEAgbAKpxV2Cu/H9/zU0AY3c6jWr3ooYuAD9 7PyfkVM6VM3y0xVsqUzPmFcuOdarPCT6uhlMVq64fD2PNWdfpVxo3k9rV2FXvyyl7yril3JnSUAA AhAIkkDqsIzeh6epJu4TgSJHXlpsmZLjyFnnbk9Vr1tQPmKgcI1c9X+ufq+3edgp026Fd5R/u3pK Bpbv3SfuuR8EU9Ubdta58HY41L9XvyRkpoeulsM3BCAAgbAJpPbcJdkudC40credE22kBkq7LHQj R1uK7OOTNEumFSFR5pbSUfcjQHXenv6mOPjd2tUrNnes19lLV2+5ggq1FwtbpdcSeqfj8s1V3CIt mmYjB79SnbUbhnRcbXDFlVA4Xgby3O0HgX+KNAQgAIEgCaQW90jkWs54RNylpPK75ZtLSWUsCfbB lceG3Cv3/Kqk+BL0iPjqTqCPhdr9SuyOonk7mo0jQdfHgvWysVi/2uDbKy3nXQGfSP0RGw4hAAEI BEMghbgrch3vtim7H+OWzUBp+8PHT5QwR9sKmqVkV0uKKtWZqerNO/f/sgrtxXtyrv0HoYqzmwOu B6qaouMurbiQ3TBUlSZH6g4hn90up3pUibvZ+A2WcXnskP3mcNEhVycJCEAAAoERSLFCNbCe0x0I QAACARNI/UA1YBZ0DQIQgEAwBBD3YIaSjkAAAhCoEUDcayxIQQACEAiGAOIezFDSEQhAAAI1Aoh7 jQUpCEAAAsEQQNyDGUo6AgEIQKBGAHGvsSAFAQhAIBgCiHswQ0lHIAABCNQIIO41FqQgAAEIBEMA cQ9mKOkIBCAAgRqB/wAoLQQNWSy3+QAAAABJRU5ErkJggg== --_005_D2414B813D964johnmattssonericssoncom_ Content-Type: image/png; name="13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png" Content-Description: 13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png Content-Disposition: attachment; filename="13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png"; size=2991; creation-date="Mon, 12 Oct 2015 09:47:41 GMT"; modification-date="Mon, 12 Oct 2015 09:47:41 GMT" Content-ID: <38D90A02-02DF-42BF-BD83-10259A0C83C4> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAP8AAAADCAIAAADTOk7/AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAABKUlEQVRI De1TMU4DQQycu5yokNKglEhIfIEf8JEoHSU/gAfkATQ8gMcgGigR0CYSDVRhzdheL7sogT6602o1 6xmPvb67TkQAvKzu7l+v1x9PSbovWwm9A+4R1EhCFhjbB2UapUwTJqHPwU1lpYlhZSaRWAU3stOf KYIeXNLpnjFBOXaQiHswH02guChbk8bzT5NGSZNdnqViCEonohMBX4HepwIW/J/6lV5nbaWsEMs1 zp61lSqNJUCSZQEpWavoRSa2BkCB7wEG0UsyPoCySmBHshPOS1CxJoMoRf1Plh4ps3KuL7VUVumb uLdkrH7hB2qrAj7HNxfTxTkBO9Tn4e3q/fPR8biPE9jjCfAfeL689Qvmr/90Nj86PNvjO49XGydQ JnCynDv+BsiTWPQxCGmXAAAAAElFTkSuQmCC --_005_D2414B813D964johnmattssonericssoncom_-- From nobody Mon Oct 12 03:36:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E891A6FBE for ; Mon, 12 Oct 2015 03:36:56 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPmHWxk5idsn for ; Mon, 12 Oct 2015 03:36:54 -0700 (PDT) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 963E81A6FBC for ; Mon, 12 Oct 2015 03:36:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 291CD21C4A4; Mon, 12 Oct 2015 13:36:51 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id wXTJEnlIVKYh; Mon, 12 Oct 2015 13:36:50 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id DBF4E5BC011; Mon, 12 Oct 2015 13:36:50 +0300 (EEST) Date: Mon, 12 Oct 2015 13:36:50 +0300 From: Ilari Liusvaara To: Rick van Rein Message-ID: <20151012103650.GA28213@LK-Perkele-V2.elisa-laajakaista.fi> References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> <561B419D.4010009@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <561B419D.4010009@openfortress.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 10:36:56 -0000 On Mon, Oct 12, 2015 at 07:14:05AM +0200, Rick van Rein wrote: > Hello, > > Thanks for the feedback. Responding to it: > > Ilari> - The signed DH share does not look to be bound to anything (crypto > Ilari> parameters negotiation, randoms, server key exchange, etc..). > > This is indeed easy to miss; it relies on Kerberos infra to deliver a > short-lived session key to only the proper TLS client and TLS server. > The ticket is part of this key delivery, and can travel over untrusted > networks. > > A alternative option to fighting MITM could be to include (a hash of) > the server-sent DH offer in the Authenticator. Only the Kerberos- > authenticated TLS server can decrypt it, making it detect MITM. Is > that considered benefial? If I was to do things like the current proposal (as opposed to overloading DHE-PSK), I would put in hash of entiere client and server first flights. Otherwise things get "interesting" when considering tweaking handshake or replaying the encrypted CKE. And "interesting" in crypto is not good. > Ilari> I can't > Ilari> offhand say what that would lead to, but it looks even worse than > Ilari> TLS ServerKeyExchange, which has known vulernabilities due to > Ilari> lack of binding to things like ciphersuite. > > Have I taken away these concerns? Pointers to the known vulnerabilities > are welcome, of course. I'm not sure what you would like to bind to > CipherSuites. The SKE security issue (SKE isn't bound to the ciphersuite) has surfaced at least three times: 1) The DHE/ECDHE confusion. 2) FREAK 3) Logjam > Watson> I would suggest piggybacking on the PSK mode, using the key Kerberos > Watson> provides at both ends as the PSK key. This would address all of these > Watson> issues in TLS 1.3 > > You mean to add the short-lived session key to the pre-master secret, right? > > I have a (weak) preference to leave that key behind the API to help > it being better protected. Also, I don't think it adds much to > the security explained above. I think he means stuffing the key from kerberos as PSK input in (EC)DHE-PSK ciphersuite. The security properties of that are much more straightforward than properties of present proposal. > Ilari> - Even use of DH is questionable. > > This is mod-exp DH, on account of its need for very large keys, right? > > I would love to take it out, and only leave ECDH; I put up mod-exp DH > initially because it might be desired for backward compatibility. If > I hear no warm-felt desire for mod-exp DH I will gladly remove it. Backward compatiblity? I don't think you need such thing with proposal like this. -Ilari From nobody Mon Oct 12 04:40:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9D01ACE9B for ; Mon, 12 Oct 2015 04:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk5VH5zavDrQ for ; Mon, 12 Oct 2015 04:40:34 -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 F3A501ACE98 for ; Mon, 12 Oct 2015 04:40:33 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id BADA2A8E; Mon, 12 Oct 2015 11:40:33 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9CBeVR0001257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2015 07:40:32 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 12 Oct 2015 13:40:26 +0200 Message-ID: <3257371.23XkUVl0AJ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.1.10-200.fc22.x86_64; KDE/4.14.11; x86_64; ; ) In-Reply-To: <5616DE2A.6060508@cs.tcd.ie> References: <5616DE2A.6060508@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6882940.eqjKVsJ5Lz"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] TRON workshop X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 11:40:35 -0000 --nextPart6882940.eqjKVsJ5Lz Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 08 October 2015 22:20:42 Stephen Farrell wrote: > Hiya, >=20 > First, thanks all for all your ongoing work on TLS1.3. I'm sure we're= > all aware that this is important stuff that needs to be, and is being= , > done carefully with due attention to security analysis. >=20 > Early in the process we had some brief discussion of pausing towards > the end of the work to give folks a chance to do analyses of the > security and other properties of TLS1.3 just before publication of > the RFC. >=20 > Chatting with the chairs in Prague and with various others since, we > think we've reached the point where we need to start executing that > bit of the plan, since doing such analyses also takes time and we > don't want to add a big delay if we can avoid it. So we're organising= > a workshop on just that topic to be co-located with NDSS in San Diego= > in late February 2016. aren't we still missing the 0-RTT mode? =2D-=20 Regards, Hubert Kario 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 Republi= c --nextPart6882940.eqjKVsJ5Lz 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 iQIcBAABCgAGBQJWG5wqAAoJEJKo0bgB0vX1jUwP/RtNNa5hEiDchm6ZqxYvWv7r 9AqDTtoZfq2+ti7sN2eoXTcsWZpLBoGDgZpEWroembuRI2wdtctaidMzOk9CF8yi U+PE6clElFTfjxWP7Z3Gq5CrZ4E2QhHhpgBXv+HBRjCcNvC4FZXqjbXdw14NYzns W6TjlH+K8yno0CJAJbbv9QB/Fi2y5GjbMkOkOE/SkX/zCEbTAsvr0QQKV2U8M7+p xKoDen75kj5UqdpM4nvlRS8tMhQSczhjuh5e94ljKZXeZFpoJQGHnQ4DHiPmsKCv P9jaZkmwepvvsaZEVUBeRqXaf4BKtqUBiYaEdnsj+dztGCz7VL1GwoBRjDE5PPP8 mvMs0jo5lDhMgGsBLFkgtfRD01uSy5OZjKdQZ2/HUpotVe5bny3rxQ66VqLUyk49 Tr8Ccy+j+bzT0EWpuSFDhT/xWjnfGUVwX3TTXHts5XtuDasf3oK7G/oltlgxID4E 8EHquvxXAMM49DQspZkmuPPlr5uFuvOoJFPd029Go2kkDsZn+FaH/GgJAv5lDqQK D6m+89jDfewSsURhYSmUrAyuHPIpgaYSwdEmdTX505YVcVFEXEvZPIrNexfv00ci wRcsSZWYh048Rx2TAi85MmbrRrpp/zHWiJyWbzvEn7K3A7/FijwwaIUU2/h8ibgA 4QL7nfp03uDPH1psYbYf =fNaR -----END PGP SIGNATURE----- --nextPart6882940.eqjKVsJ5Lz-- From nobody Mon Oct 12 04:48:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0186C1ACEB7 for ; Mon, 12 Oct 2015 04:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zou6cnqEARST for ; Mon, 12 Oct 2015 04:48:48 -0700 (PDT) Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) (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 52AA61ACEB6 for ; Mon, 12 Oct 2015 04:48:48 -0700 (PDT) Received: by ykey125 with SMTP id y125so10164795yke.3 for ; Mon, 12 Oct 2015 04:48:47 -0700 (PDT) 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-type; bh=XZwnVFznxjRhI6lkLYeEQ9YHjGEktfaBBRzFoI46dlQ=; b=Y7Jv9J2k8FGiJUJHHyg7wPzASqkpkv8eZWf7xzfSRyWhQS99w+JzhqhUuL8KKgEEMd mINAZBnLXWuUdx5+FuMx0KPO+WBtKyFUHhCQaNyZYneaT/OhAswz3+P5Cxdxp7ik03d7 w866aWhyK9HbEZgv7FookYrWTAcZm3t+h1e+HI5RRgrIPjts6sxBY0PzMdJ0TZktdk/x rWcFnAxglgkArNxF1QV1P8n7Y+8GjIT0mZj9dJ6ZVLSnAOlYrzgP25bxzROmjHVIrxDF uSFM8IwcLMKO/xhE1dVaGynxsY52Y/QmDHj5yWDBvrH1wDsUbt7CloEb066H0PJVvGR8 NHPA== X-Gm-Message-State: ALoCoQnVmw0nfq5/YOdF+SqVycLS6WJHl1MAjv23YhS2qp75WxojHndjzSyNF492FrlPkLLuZYRh X-Received: by 10.13.229.68 with SMTP id o65mr19500892ywe.62.1444650527506; Mon, 12 Oct 2015 04:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Mon, 12 Oct 2015 04:48:08 -0700 (PDT) In-Reply-To: <3257371.23XkUVl0AJ@pintsize.usersys.redhat.com> References: <5616DE2A.6060508@cs.tcd.ie> <3257371.23XkUVl0AJ@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Mon, 12 Oct 2015 04:48:08 -0700 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=94eb2c0809ec847ef00521e6e9b0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TRON workshop X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 11:48:50 -0000 --94eb2c0809ec847ef00521e6e9b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote: > On Thursday 08 October 2015 22:20:42 Stephen Farrell wrote: > > Hiya, > > > > First, thanks all for all your ongoing work on TLS1.3. I'm sure we're > > all aware that this is important stuff that needs to be, and is being, > > done carefully with due attention to security analysis. > > > > Early in the process we had some brief discussion of pausing towards > > the end of the work to give folks a chance to do analyses of the > > security and other properties of TLS1.3 just before publication of > > the RFC. > > > > Chatting with the chairs in Prague and with various others since, we > > think we've reached the point where we need to start executing that > > bit of the plan, since doing such analyses also takes time and we > > don't want to add a big delay if we can avoid it. So we're organising > > a workshop on just that topic to be co-located with NDSS in San Diego > > in late February 2016. > > aren't we still missing the 0-RTT mode? It's in the current draft though there are a few details that we're going to need to nail down over the next few weeks and in Yokohama. -Ekr - > Regards, > Hubert Kario > 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 > > --94eb2c0809ec847ef00521e6e9b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario <hkario@redhat.com&g= t; wrote:
On Thur= sday 08 October 2015 22:20:42 Stephen Farrell wrote:
> Hiya,
>
> First, thanks all for all your ongoing work on TLS1.3. I'm sure we= 're
> all aware that this is important stuff that needs to be, and is being,=
> done carefully with due attention to security analysis.
>
> Early in the process we had some brief discussion of pausing towards > the end of the work to give folks a chance to do analyses of the
> security and other properties of TLS1.3 just before publication of
> the RFC.
>
> Chatting with the chairs in Prague and with various others since, we > think we've reached the point where we need to start executing tha= t
> bit of the plan, since doing such analyses also takes time and we
> don't want to add a big delay if we can avoid it. So we're org= anising
> a workshop on just that topic to be co-located with NDSS in San Diego<= br> > in late February 2016.

aren't we still missing the 0-RTT mode?

It's in the current draft though there are a few details that w= e're going to need
to nail down over the next few weeks and i= n Yokohama.

-Ekr

-
Regards,
Hubert Kario
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


--94eb2c0809ec847ef00521e6e9b0-- From nobody Mon Oct 12 05:49:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A361B2A49 for ; Mon, 12 Oct 2015 05:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoGwFI7xOzNu for ; Mon, 12 Oct 2015 05:49:24 -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 53BB81B2A4C for ; Mon, 12 Oct 2015 05:49:24 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id F2D0B341AC2; Mon, 12 Oct 2015 12:49:23 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9CCnLMp001598 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2015 08:49:23 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 12 Oct 2015 14:49:16 +0200 Message-ID: <5603089.J1VydmQ79E@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.1.10-200.fc22.x86_64; KDE/4.14.11; x86_64; ; ) In-Reply-To: <201510111913.04247.davemgarrett@gmail.com> References: <201510101337.29335.davemgarrett@gmail.com> <7EB6726D-39A6-47B1-9E3A-A40C7826CAAB@dukhovni.org> <201510111913.04247.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8759134.CxX5S3o9qR"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 12:49:27 -0000 --nextPart8759134.CxX5S3o9qR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 11 October 2015 19:13:03 Dave Garrett wrote: > On Sunday, October 11, 2015 05:58:59 pm Viktor Dukhovni wrote: > > Pointless restrictions lead to fallback to even worse choices. >=20 > And no restrictions lead to horrible fallback choices. Running under > the assumption that some population of implementors is willing to do > something stupid to maintain inertia (e.g. insecure version fallback > dance), sending SHA1 certs is a risk. Yes, the server doesn't know > whether the client can or cannot deal with it safely, but we, from > the perspective of the spec, should be assuming bad scenarios when > designing things. so what we need is: 1. servers SHOULD NOT send certificates with SHA-1 signatures, except=20= as a last resort (maybe even add a recommendation that=20 implementers should warn user when such certificates are configured= ) 2. clients MUST NOT trust certificates which derive their authenticity= though SHA-1 (or weaker) signatures but saying that the server MUST NOT send SHA-1 (or other certs) is, as=20= Victor said, an overreach =2D-=20 Regards, Hubert Kario 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 Republi= c --nextPart8759134.CxX5S3o9qR 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 iQIcBAABCgAGBQJWG6xMAAoJEJKo0bgB0vX1zMIP/3KER4GE4dCNU8oGbgp05aAI gxY+cvpxEXUQlLR7y6hPeo5etph2c309KLwja6GqMEIYv1eyl13rq3ezd//lJ8Dt 92vu8ge7eAopagBF7BJF79VQILUfgl1JflguaQBcUUpjdvmBKebiVTpqsfj89WLr fO+RUw+SShcS0hP5aE7FNEsVN4ZhF8fj5Qc+J3H/2L2F8g+2YWU6qAh+kR8di7+r DQTinYRipxMmnT+MBZfaT+XmeRf7YIsJfZcpX7ZmTopZyjq3YnNxSdFi0VoLx2em oq4laNPFTIZ47il5R008Ht5pYYXRBVY/HX5RrJxWiVYsOoNVJyUWZiWXdxpb//WT EVKVaNwJNJzh1mLzgVtz6rx42Ja+vxCg2ZwXosSVJ6ktmBt5ewDxDU59xxXlJSpX dPCRc0W/jIj50yM3BHwLWVdwIaPOLnN6y/weX08uY0FMwQCnOkD8nHLbGv3z8lGg HsoQZHG+GV5Z/Kf67Zm6rCgSJJ6w9HCLTS1JsMn2jcqaP4/1vYBL/sn6oTqj7wlc yzEfDsH4TMRpovR4uo6kDxD5Ng6zXurhqlMP4RhqPsCgTsc1NMcSnhFmWhw6Z5Ij QEjkHLOHIOklIqAHqmgzVQ0YWvofBiYTRgkzVicSXcYf/8ng/VuiBkdoygchkzuO d7iJXECW6iUHFBU5zX+i =bVFQ -----END PGP SIGNATURE----- --nextPart8759134.CxX5S3o9qR-- From nobody Mon Oct 12 06:18:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0322B1B2E16 for ; Mon, 12 Oct 2015 06:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 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, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by_IEKyrFZsL for ; Mon, 12 Oct 2015 06:18:23 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 48B5E1B2DDC for ; Mon, 12 Oct 2015 06:18:23 -0700 (PDT) Received: by padhy16 with SMTP id hy16so154226985pad.1 for ; Mon, 12 Oct 2015 06:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=dsn9s5ZvhuzBZwNPummpsC+ajJ/HVme41abVRCo9ZEc=; b=bRxIUbuf009IxN9Aw4VaiYlnKzGPt2tnJSK505uiCkQyJw4CvChSltt5EpDyDtfzCj ChprrRpN97U3nfQNvDCBzeQVwTiPMjosAMTDwDYCJifXYErHdaj0S/utDC0vHdWNL9z5 dRlnWjkzct/A7EJPXGw93ql1zsjBvvbgVwHpI9jsejQusD3h12mCLzHY6Lm4Tdgr4iUA bvhlbHDCkZkqMBBf8pzlnfdexZqBlhmSWETTMc8O9jU2hW9+YS2RVfrQksvVZlW7dmB+ gt004pa87fy38VoscDL07ICvvD8e0ZpMwt6mZ3F82rC0CrkaYkhetaImCnh8eh6GAqOr JmQw== X-Received: by 10.68.69.17 with SMTP id a17mr34523920pbu.10.1444655902730; Mon, 12 Oct 2015 06:18:22 -0700 (PDT) Received: from [172.18.133.33] (hoover.intuit.com. [199.16.140.25]) by smtp.googlemail.com with ESMTPSA id ir4sm16026201pbb.93.2015.10.12.06.18.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 06:18:20 -0700 (PDT) To: Daniel Kahn Gillmor , "tls@ietf.org" References: <20151011193517.30413.36864.idtracker@ietfa.amsl.com> <561ABF32.20008@gmail.com> <877fmtt9mh.fsf@alice.fifthhorseman.net> From: Yaron Sheffer Message-ID: <561BB319.3050108@gmail.com> Date: Mon, 12 Oct 2015 16:18:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <877fmtt9mh.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 13:18:26 -0000 Hi Daniel, Thanks for your review. Please see my comments inline. Yaron On 10/11/2015 11:48 PM, Daniel Kahn Gillmor wrote: > Hi Yaron-- > > On Sun 2015-10-11 15:57:38 -0400, Yaron Sheffer wrote: >> We have a standard for certificate pinning (RFC 7469), but it is rather >> hard to use and as a result is rarely deployed. This draft proposes a >> lightweight alternative that allows TLS clients to authenticate the >> server they're connecting to, even if a rogue CA can generate fake >> certificates for that server. >> >> The draft is currently TLS 1.3-only, and is based on the previous draft >> of 1.3 so some minor details may have changed. > > I've only just skimmed thus far, but i'm happy to see this proposal. A > few comments below: > > TACK > ---- > > As you note in the draft, it addresses a similar problem as TACK, which > never made it through the standards process: > > http://tack.io/draft-tack.html > > perhaps it would be useful to have a section next to the Comparison: > HPKP that included a Comparison: TACK ? > I'm not familiar enough with TACK at the moment. I can write something up, or if you'd like to contribute text, that'll be awesome. > > (dis)similarity to session tickets > ---------------------------------- > > In the session-ticket case, most servers (clustered or otherwise) can > afford to treat their session ticket master keys as ephemeral keys -- if > the server is restarted or dies and is re-installed, the worst that > happens is that a client doesn't get to resume their session -- they > have to open a new connection. > > If the session ticket resumption master keys are used as recommended > here, it seems like the risk of master key loss is bricking the server, > so the master key becomes necessary to store non-ephemerally. > > Writing the master key to disk or storing it off-site someplace can > present a risk to the forward-secrecy of ticket-resumed sessions. > > tracking the master key itself seems like it also adds specific > operational overhead for server maintainers that doesn't currently > exist. Does this reduce the advantage of the scheme over TACK or HPKP? > if not, can you explain why not? > IMO persisting the master key to disk is less of a problem than distributing it across cluster members, and this is something that needs to happen or session resumption will fail regularly. Regular rotation of the master key means that persisting it to disk is not such a risk. You are right that a session resumption master key needs not be backed up, whereas the pinning secret may need to be backed up securely for disaster recovery. > > > Client Privacy > -------------- > > section 6.6 says "TODO", and page 5 says: > >> The main reason for refreshing the ticket on each connection is >> privacy: to avoid the ticket serving as a fixed client >> identifier. It is RECOMMENDED to include a fresh ticket with >> each response. > > If the participating client wants privacy from the server (to avoid the > server using this to track the client) but also wants defense against > broken CAs, how does recomending this behavior from the server actually > allow the client to enforce privacy? > > The server is trivially capable of tying together a history of > pinning_ticket objects to track specific clients, right? it just > remembers the two tickets involved every time it generates a > PinningTicket extension. If the pinning tickets returned by the server > are different each time, the client cannot know whether the server is > doing this tracking or not. > Yes, I was thinking of privacy in the face of passive attackers who listen in to the TLS handshake. Not when the server itself is out to get you. I suspect that there is little you can do to protect your privacy when the server itself is malicious, but I'm sure you are more knowledgeable about these issues. > > public key vs. certificate > -------------------------- > > In your introduction (and in the mail above), you refer to "certificate > pinning" -- but i don't think there is anything out there that is > "certificate pinning" -- HPKP is public key pinning, and it ignores the > certificates that wrap any given public key. So your tables should > really refer to "main public key" and "backup public key", not "main > certificate" or "backup certificate". > You are right. "Certificate pinning" is the more common term, but is it less precise. > > HPKP example workflow > --------------------- > > Your HPKP timeline seems to assume that your "old backup certificate" > can't be used as your "new main certificate" -- what makes you say this? The longer you keep a keypair, the more likely it is to be compromised. So you may not want to keep a keypair in "cold storage" for a year, and then use it as a production cert for another year. Depending on your setup, the risk may be much larger on the production server than on some offline storage, and then your proposed process makes perfect sense. > > I agree with you that HPKP end-entity pinning generally makes more sense > (and is more useful at defending against malicious/incompetent CAs) than > authority pinning. But I'd expect an HPKP timeline using end-entity > pinning to be more like: > > lower-case letters are public keys. we presume that the site > administrator has the corresponding secret keys backed up > offsite/offline somewhere, and the associated certs and secret keys > needed to operate the web site get deployed as needed. > > Initial deployment: > > > HPKP: { a, b } Cert: A = X.509-wrapped(a) > > as A approaches expiry, we generate a new key c (storing its secret key > offline), get a new cert made over b, and switch to: > > HPKP: { b, c } Cert: B = X.509-wrapped(b) > > As B approaches expiry, we do the same dance, generating d and making a > cert over c: > > HPKP: { c, d } Cert: C = X.509-wrapped(c) > > and so on. > > Does this simpler cycle change your analysis of HPKP? > > I tend to think HPKP deployment has been slow because: > > (a) the risk of bricking the site makes admins (justifiably) nervous > > (b) having to have an additional offsite store (of your HPKP backup > secret key) to avoid site-bricking is a workflow that most admins > don't already have in place. > > But i don't think your proposal addresses these issues either (though > the data stored offsite for (b) is slightly different between your > proposal and HPKP). Does it address them in some way that i'm missing? One difference is that in HPKP, the data stored in (b) is security-critical, in that its compromise is just as bad as compromise of the site's regular secret key (you can use it to MITM all connections to the server). In my proposal the pinning secret is truly a "second factor". Its compromise is an issue only if you can *also* generate a fake certificate. Another major difference is that my proposal avoids the manual management steps of HPKP (at least until we have ACME widely deployed). The pinning secret can be generated automatically when the server is started and rolled over periodically, with no human in the loop. > > Regards, > > --dkg > From nobody Mon Oct 12 06:18:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B325E1B2E16 for ; Mon, 12 Oct 2015 06:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oE7LYHIcyZJ for ; Mon, 12 Oct 2015 06:18:35 -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 20F3F1B3146 for ; Mon, 12 Oct 2015 06:18:35 -0700 (PDT) Received: by qkap81 with SMTP id p81so58097542qka.2 for ; Mon, 12 Oct 2015 06:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bmO7vPXfUoORl/AcrWSiRsabWx7WFMSZxY4MMlZSvV4=; b=coXpnWTV3KwVExTdTQI+nHhEvwH+rCHQlKiK25VxtnyusTjmqA3SCv0QiXPSQnMU75 dcRmLBsGm2L2SrLGc8G5Q9Y7cUSfZ/+7jhc48zcS7tyhKTWZUa3whexPRnepVk+T3mfr NyCGOD0O+jf9XzPgNExThrm3X/BcCXuH0YXNk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=bmO7vPXfUoORl/AcrWSiRsabWx7WFMSZxY4MMlZSvV4=; b=AVpQa60Q8MZ8Bwx7K3ljOAMuBIulAGNrBgHithyAfSjiYIMjWN7zgjUJLw7TL+0XBz tuYcpkHYS62I62ey4XbOvRo00e3GdxqWFnBjMc3YOoHYXsTDOaBtmdtkJ7v8wR6YaWlR QV1EcPE543U27QGMkxZ7JG2yG0YjAoSA+qeaR1KC5PDlrIzHKxNlxU9GQ4aLw/OC9XLi QLPd/U846V+f/XdKs0XeD/dBOHeH/gsBVTzqcXUv9AHc2PnIrb090rSj3e6DvEGQG/ME uy9wY2GWTq6MbbCbDxZbvVyXF1jOfUsQdcu7W9Z7Wy2g1x+UTa5Sdj097xFBxwim7VEI zD5g== X-Gm-Message-State: ALoCoQn9mzYY7z2FONIoHMklg+fNcoRyFknUTNpuEJuIZmsxsjMMlc07QWmkH0i+sl32K3w9U9Iw X-Received: by 10.55.43.17 with SMTP id r17mr32691285qkh.96.1444655914311; Mon, 12 Oct 2015 06:18:34 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id z10sm7062022qhd.15.2015.10.12.06.18.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Oct 2015 06:18:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Mon, 12 Oct 2015 09:18:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9BB2A2C5-005B-4F2C-9CAB-EA23F07FE0D5@sn3rd.com> References: To: John Mattsson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "TLS@ietf.org" Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 13:18:37 -0000 It is interesting to note that in discussing update IPSec=92s RFC 4307 = somebody suggested making 192 a MAY because folks only use 128/256 [1]. spt [1] = http://mailarchive.ietf.org/arch/msg/ipsec/1F5h4j-dP5dLPCCAqg4iqgjjYFE On Oct 12, 2015, at 05:01, John Mattsson = wrote: > I think the selection of MTI Cipher Suites (Section 8.1 of = draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended = ECC curve for the =93SHOULD=94 cipher suites. Little benefit of using = AES-256 with P-256 or curve25519. Shouldn=92t there be a SHOULD = implement ECC curve giving at least 192-bit security? E.g. >=20 > "These cipher suites SHOULD support both digital signatures and key = exchange with secp384r1 (NIST P-384)." >=20 > Cheers, > John > =20 > <13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png> >=20 > JOHN MATTSSON > MSc Engineering Physics, MSc Business Administration and Economics > Ericsson IETF Security Coordinator=20 > Senior Researcher, Security >=20 > Ericsson AB > Ericsson Research > F=E4r=F6gatan 6 > SE-164 80 Stockholm, Sweden > Phone +46 10 71 43 501 > SMS/MMS +46 76 11 53 501 > john.mattsson@ericsson.com > www.ericsson.com >=20 >=20 > > =20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out atwww.ericsson.com/email_disclaimer >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Oct 12 06:44:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555671B3253 for ; Mon, 12 Oct 2015 06:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzm5ULCpBTWW for ; Mon, 12 Oct 2015 06:44:54 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE521B3251 for ; Mon, 12 Oct 2015 06:44:54 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t9CDipOF006010; Mon, 12 Oct 2015 09:44:51 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Dave Garrett , Viktor Dukhovni Thread-Topic: [TLS] banning SHA-1 in TLS 1.3, a new attempt Thread-Index: AQHRA4PcZmhnRFnvbU2c8qliyAuSfJ5lcHcAgAAIk4CAAAOSAIAAAh0AgAAYY4CAAD/XAIAABw0AgAAGPwD//9q4ioAAT2MAgACfZICAACGvAIAADriAgAAcn4CAACFSgIAAFLKAgAANVICAACz6AIAAdmyA Date: Mon, 12 Oct 2015 13:44:51 +0000 Message-ID: References: <201510101337.29335.davemgarrett@gmail.com> <201510111913.04247.davemgarrett@gmail.com> <20151012000045.GF15070@mournblade.imrryr.org> <201510112241.44817.davemgarrett@gmail.com> In-Reply-To: <201510112241.44817.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-originating-ip: [172.26.148.51] Content-Type: text/plain; charset="utf-8" Content-ID: <3EE7BBA942436B449B9907FDAB7A9CFB@ll.mit.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-10-12_08:2015-10-12,2015-10-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510120159 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 13:44:56 -0000 SW4gc3VtbWFyeTogDQorMSB0byBWaWt0b3LigJlzIGFyZ3VtZW50Lg0KLTEgdG8gRGF2ZeKAmXMu DQotLQ0KUmVnYXJkcywNClVyaSBCbHVtZW50aGFsDQoNCg0KDQoNCk9uIDEwLzExLzE1LCAyMjo0 MSwgIlRMUyBvbiBiZWhhbGYgb2YgRGF2ZSBHYXJyZXR0IiA8dGxzLWJvdW5jZXNAaWV0Zi5vcmcN Cm9uIGJlaGFsZiBvZiBkYXZlbWdhcnJldHRAZ21haWwuY29tPiB3cm90ZToNCg0KPk9uIFN1bmRh eSwgT2N0b2JlciAxMSwgMjAxNSAwODowMDo0NSBwbSBWaWt0b3IgRHVraG92bmkgd3JvdGU6DQo+ PiBUaGVyZSdzIG5vIHJlYXNvbiBmb3IgcGVzc2ltaXNtDQo+DQo+U29ycnksIEkgaGF2ZSB0byBs YXVnaCBhIGJpdCBoZXJlLiA6cA0KPg0KPj4gd2UncmUgbm90IHRyeWluZyB0byBkZXByZWNhdGVk IGRlcGxveWVkDQo+PiBmdW5jdGlvbmFsaXR5LCB0aGVyZSBpcyBubyBUTFMgMS4zIGRlcGxveWVk IGJhc2UuDQo+DQo+RHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIHZhc3QgbWFqb3JpdHkgb2YgVExT IGltcGxlbWVudGF0aW9ucyB0aGF0IHdpbGwNCj5iZSB1c2VkIGFyZSBnb2luZyB0byBiZSBleGlz dGluZyBvbmVzLCB1cGdyYWRlZCB0byBzdXBwb3J0IFRMUyAxLjMsIHllcw0KPndlIGFyZSBkZXBy ZWNhdGluZyBkZXBsb3llZCBmdW5jdGlvbmFsaXR5IGZvciB0aGF0IGltcGxlbWVudGF0aW9uIGFz IHdlbGwNCj5hcyB0aGVpciB1c2Vycy4NCj4NCj4+ID4gUHJvaGliaXRpbmcgVExTIDEuMyBpbXBs ZW1lbnRhdGlvbnMgZnJvbSB1c2luZyBTSEExIGNlcnRzIGRvZXMgbm90DQo+PmJyZWFrDQo+PiA+ IE9FLiAgDQo+PiANCj4+IEl0IGRvZXMgd2hlbiB0aGUgU0hBLTEgbGVhZiBjZXJ0aWZpY2F0ZSBp cyBwaW5uZWQsIGFuZC9vciB0aGUgc2VydmVyDQo+PiBoYXMgbm90aGluZyBlbHNlIHRvIHNlbmQs IGFuZCBpdHMgY2xpZW50cyByaWdodGx5IGRvbid0IGNhcmUuDQo+DQo+SW4gdGhlIHNlY29uZCBj YXNlLCBhIGNvcnJlY3QgY291cnNlIG9mIGFjdGlvbiBmb3IgdGhlIHNlcnZlciB3b3VsZCBiZSB0 bw0KPnNlbmQgYW4gaW5jb21wbGV0ZSBvciBvdXRyaWdodCBlbXB0eSBjZXJ0aWZpY2F0ZV9saXN0 IGZhbGxiYWNrLCBpbiB3aGljaA0KPmNhc2UgdGhlIGNsaWVudHMgdGhhdCBkb24ndCBjYXJlIHdp bGwgYmUgZmluZSB3aXRoIGl0LiBQaW5uaW5nIGEgU0hBMQ0KPmVuZC1lbnRpeSAobGVhZikgY2Vy dCByYXRoZXIgdGhhbiBhbiBpbnRlcm1lZGlhdGUganVzdCBzZWVtcyBsaWtlIGEgYmFkDQo+aWRl YSB0aGF0IHlvdSBjYW4ndCBleHBlY3QgdG8gd29yayBmb3JldmVyLiBJbiBjYXNlcyB3aGVyZSB0 aGUgc2VydmVyDQo+Y2FuJ3QgaGFuZGxlIGxhY2sgb2YgU0hBMSwgdGhlbiBteSByZXNwb25zZSBp cyB0byBmaXggdGhhdCBiZWZvcmUNCj51cGdyYWRpbmcgVExTLg0KPg0KPj4gPiBNeSBnb2FsIGlz IHRvIGhhdmUgZmV3ZXIgc3lzdGVtcyB1c2luZyBTSEExIHdpdGhpbiBhIHJlYXNvbmFibGUNCj4+ dGltZWZyYW1lLg0KPj4gDQo+PiBUaGF0IGhhcHBlbnMgYXV0b21hdGljYWxseSBpbiB0aGUgbWlu aW1hbCB2ZXJzaW9uIG9mIHRoZSBQUi4NCj4NCj5XZSdyZSBib3RoIHRyeWluZyB0byBwcmVkaWN0 IHBvc3NpYmxlIGZ1dHVyZXMgd2l0aCBkaWZmZXJlbnQgdGhvdWdodA0KPnByb2Nlc3Nlcy4gSSdt IGNvbmNlcm5lZCB0aGF0IHRoZSBzaW1wbGVyIGNvdXJzZSBpcyB0b28gc2xvdywgX25vdF8NCj5i ZWNhdXNlIHdlIG5lZWQgdG8gcnVzaCB0byBnZXQgcmlkIG9mIFNIQTEgY2VydHMgQVNBUCwgYnV0 IGJlY2F1c2UgZ29pbmcNCj5zbG93ZXIgcmVxdWlyZXMga2VlcGluZyBTSEEtMSBhcm91bmQgaW4g aW1wbGVtZW50YXRpb25zIGluIHRoZSBpbnRlcmltLg0KPkV2ZW4gcmVxdWlyaW5nIHNldHRpbmdz IGFuZCBjb2RlIGZvciBhbiBhbGdvcml0aG0gYXQgYWxsIHBvc2VzIGFuIGF0dGFjaw0KPnN1cmZh Y2UgYnkgaXRzZWxmICh3ZSBoYWQgYXR0YWNrcyBvbiBzdXBwb3NlZGx5IGRpc2FibGVkIGZlYXR1 cmVzIG92ZXINCj50aGUgcGFzdCB5ZWFyKS4gRXZlcnkga25vd24gdnVsbmVyYWJsZSBmZWF0dXJl IGlzIG9uZSB3aGljaCB3ZSBoYXZlIHRvIGJlDQo+d2FyeSBvZiBnZXR0aW5nIHJlLWVuYWJsZWQg b3IgbGVmdCBvbiBhY2NpZGVudGFsbHkuIEkgY29uc2lkZXIgdGhpcyByaXNrDQo+dG8gYmUgaGln aCBlbm91Z2ggdG8gbm90IHJlbHkgb24gZGVsZWdhdGlvbiB0byBhbm90aGVyIGxheWVyOyB5b3Ug dGhpbmsNCj50aGF0IGRlbGVnYXRpb24gY2Fubm90IGJlIGNoYW5nZWQgd2l0aG91dCBleGNlc3Np dmUgaW50ZXJvcCByaXNrLg0KPg0KPkknbGwgcG9zdCBhIGZvbGxvdy11cCBxdWVzdGlvbiB0byB0 aGUgV0cgKHdpdGggYSBjaGFuZ2VkIHRpdGxlLCBhcyBvdXINCj5kaXNjdXNzaW9uIGhlcmUgZ290 IGxvbmcpIHdpdGggdGhlIG9wdGlvbnMgcGhyYXNlZCBhcyBhIHF1ZXN0aW9uIHdpdGggMw0KPm1h aW4gY2hvaWNlcyAoaW5jbHVkaW5nIHRoZSBvcHRpb24gb2YgZG9pbmcgbm90aGluZyBuZXcpLiBJ ZiB0aGVyZSdzIG5vDQo+c3VwcG9ydCBmb3IgYSBmdWxsIGRyb3AgaW4gU0hBLTEgc3VwcG9ydCB1 bmRlciB0aGUgbmV3IHZlcnNpb24sIHRoZW4NCj50aGVyZSB3b24ndCBiZSBhIHBvaW50IGluIHB1 c2hpbmcgZm9yIGl0IGZ1cnRoZXIsIHVubGVzcyB0aGVyZSdzIHlldA0KPmFub3RoZXIgU0hBLTEg cmV2ZWxhdGlvbiBpbiB0aGUgbmVhciBmdXR1cmUuDQo+DQo+DQo+RGF2ZQ0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+VExTIG1haWxpbmcgbGlz dA0KPlRMU0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGxzDQoNCg== From nobody Mon Oct 12 07:31:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7971B3337 for ; Mon, 12 Oct 2015 07:31:18 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br-vCnzu3gFx for ; Mon, 12 Oct 2015 07:31:16 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c: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 465FB1B335E for ; Mon, 12 Oct 2015 07:31:16 -0700 (PDT) Received: by wicge5 with SMTP id ge5so20205540wic.0 for ; Mon, 12 Oct 2015 07:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ug4S8qDXqfu4vLxsInfGwAAFlQYgQ7yu9Aw2k4lKTT4=; b=0zCnRlCILPiHXVhQBM0vAotM3D7pbhWB6kr4mnEJQUrYEQ2Xc7fiG46EGBzTPeqV3Y /rrLec+Je82lMutwcIwbgHDLbcpLDtQZctCk3XgNxrAJKeIKaxTwjqvLcgbIRIv3Uo+0 yF+I+SnF281ScVDEyMMHnBxoaYIoQcd6wJwD4PpW5idwTfKkzVDWn4CQ6UZLnDgZYcqJ Q1qbtZbupjopi2/QKjhiHDrVNrHza/IjFnER/O8cLqEI9YKW5xKuLL7lv1thaNkBaL8k +QzJwKoaCb1pnMVWfZQi15pPMKzA1BXW4dHJNpM7qhgzxMiMQEFGNitVgkoyTUsSACbh Zf/Q== X-Received: by 10.180.186.74 with SMTP id fi10mr13916889wic.61.1444660274592; Mon, 12 Oct 2015 07:31:14 -0700 (PDT) Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id kr10sm20182142wjc.25.2015.10.12.07.31.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Oct 2015 07:31:13 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <9BB2A2C5-005B-4F2C-9CAB-EA23F07FE0D5@sn3rd.com> Date: Mon, 12 Oct 2015 17:31:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2B982337-1B4C-4703-A910-7F4D9F319003@gmail.com> References: <9BB2A2C5-005B-4F2C-9CAB-EA23F07FE0D5@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "TLS@ietf.org" Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 14:31:18 -0000 True, but that is about key length for AES specifically, not security in = general. The Suite-B recommendations also have the AES key at 256 bits = for the higher level but it=92s paired with SHA-384. Yoav > On Oct 12, 2015, at 4:18 PM, Sean Turner wrote: >=20 > It is interesting to note that in discussing update IPSec=92s RFC 4307 = somebody suggested making 192 a MAY because folks only use 128/256 [1]. >=20 > spt >=20 > [1] = http://mailarchive.ietf.org/arch/msg/ipsec/1F5h4j-dP5dLPCCAqg4iqgjjYFE >=20 > On Oct 12, 2015, at 05:01, John Mattsson = wrote: >=20 >> I think the selection of MTI Cipher Suites (Section 8.1 of = draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended = ECC curve for the =93SHOULD=94 cipher suites. Little benefit of using = AES-256 with P-256 or curve25519. Shouldn=92t there be a SHOULD = implement ECC curve giving at least 192-bit security? E.g. >>=20 >> "These cipher suites SHOULD support both digital signatures and key = exchange with secp384r1 (NIST P-384)." >>=20 >> Cheers, >> John >>=20 >> <13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png> >>=20 >> JOHN MATTSSON >> MSc Engineering Physics, MSc Business Administration and Economics >> Ericsson IETF Security Coordinator=20 >> Senior Researcher, Security >>=20 >> Ericsson AB >> Ericsson Research >> F=E4r=F6gatan 6 >> SE-164 80 Stockholm, Sweden >> Phone +46 10 71 43 501 >> SMS/MMS +46 76 11 53 501 >> john.mattsson@ericsson.com >> www.ericsson.com >>=20 >>=20 >> >>=20 >> This Communication is Confidential. We only send and receive email on = the basis of the terms set out atwww.ericsson.com/email_disclaimer >>=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 12 07:58:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0265E1A21C2 for ; Mon, 12 Oct 2015 07:58:08 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPAsTkAcTeyi for ; Mon, 12 Oct 2015 07:58:06 -0700 (PDT) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id DE6661A21B8 for ; Mon, 12 Oct 2015 07:58:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 8D00619C60C; Mon, 12 Oct 2015 17:58:04 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id RL+0hvhbGZ8o; Mon, 12 Oct 2015 17:58:04 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 64A6E5BC016; Mon, 12 Oct 2015 17:58:04 +0300 (EEST) Date: Mon, 12 Oct 2015 17:58:03 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151012145803.GA29740@LK-Perkele-V2.elisa-laajakaista.fi> References: <5616DE2A.6060508@cs.tcd.ie> <3257371.23XkUVl0AJ@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: Cc: "tls@ietf.org" Subject: Re: [TLS] TRON workshop X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 14:58:08 -0000 On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote: > On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote: > > > aren't we still missing the 0-RTT mode? > > It's in the current draft though there are a few details that we're > going to need to nail down over the next few weeks and in Yokohama. IMO, that should be nailed rather quick, given that that what there is right now isn't really sufficient to analyze it. However, some comments about 0-RTT: 1) It seems to me that if server key is compromised, MITM can substitute 0-RTT data with its own (at least if original and modified one have the same number of records). And such modification will not be detected by handshake, which will complete successfully. Perhaps the comment about impersonation with compromised server key was about this (I can't get more usual types of attacks to work)? 2) If static client authentication is used with 0-RTT data, the client authentication always preceeds 0-RTT data (it is first in early handshake, and using 1-RTT client auth is forbidden). This seems to imply 0-RTT data should be interpretted in an authenticated context, which seems dangerous given the replayability of the 0-RTT data. If such authentication is not needed, 1-RTT authentication would be equally fast as 0-RTT authentication (now that 1-RTT auth does not prohibit server 0-RTT) and much more straightforward (due to having full-fledged connection context). 3) The document talks about making 0-RTT data unreplayable by using extra identifier agreed out-of-band. Does that actually work, given the likely auto-replay by the client? -Ilari From nobody Mon Oct 12 08:05:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913711A6F49 for ; Mon, 12 Oct 2015 08:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvUKPQBenvkN for ; Mon, 12 Oct 2015 08:05:17 -0700 (PDT) Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) (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 975E71A6F2E for ; Mon, 12 Oct 2015 08:05:17 -0700 (PDT) Received: by ykoo7 with SMTP id o7so22501262yko.0 for ; Mon, 12 Oct 2015 08:05:17 -0700 (PDT) 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-type; bh=VYRPOlzHj682S+TYWxc1Hla0O3yWDxwdRkv01WNRNXM=; b=WyxJkkHLiQw7KkLLcJ6zGI0oGZf2XOKiVRPUpApNLQGbioMbT8xXpYn+ucoO7EtFmB 4Wb0Kfu0ZWJX/PKoaMLYAQGDSo+0CQzx6E6+jdxPHhluDYGGvddeUfu6BAMdb/y8fQ1p kGVHiqgfZGCClx3iMKmuXtc3UYx3H5Gcmlqe0bN/I7ehTP34L2PYW/JVI2XjNZdMUA4o ruVmxnJBprf8L5Vw/djgsQMjXOq7IDbha13aknc6p7X1UwjbWzp3BYfSqRZNj+ZC3My3 mx9r6uaMQLKEiqdD41PCQ4Fy1MM1x6semcDETMLRvv3kNOdZVQZdB0G/pBs7wvmhAVtC KuDQ== X-Gm-Message-State: ALoCoQnAq+ZX2/jIcwlC9SEzXkTGE846lXyt9X3PVF2F8QalH0pYoXT64w1y3W+W4qU0IP2ejEI8 X-Received: by 10.13.214.195 with SMTP id y186mr20783321ywd.81.1444662316913; Mon, 12 Oct 2015 08:05:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Mon, 12 Oct 2015 08:04:37 -0700 (PDT) In-Reply-To: <20151012145803.GA29740@LK-Perkele-V2.elisa-laajakaista.fi> References: <5616DE2A.6060508@cs.tcd.ie> <3257371.23XkUVl0AJ@pintsize.usersys.redhat.com> <20151012145803.GA29740@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 12 Oct 2015 08:04:37 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114fcea83889290521e9a86e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TRON workshop X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 15:05:19 -0000 --001a114fcea83889290521e9a86e Content-Type: text/plain; charset=UTF-8 On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara wrote: > On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote: > > On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote: > > > > > aren't we still missing the 0-RTT mode? > > > > It's in the current draft though there are a few details that we're > > going to need to nail down over the next few weeks and in Yokohama. > > IMO, that should be nailed rather quick, given that that what there > is right now isn't really sufficient to analyze it. > Yes, that's the plan, as noted above. > However, some comments about 0-RTT: > > > 1) It seems to me that if server key is compromised, MITM can > substitute 0-RTT data with its own (at least if original and modified > one have the same number of records). And such modification will not > be detected by handshake, which will complete successfully. > > Perhaps the comment about impersonation with compromised server key > was about this (I can't get more usual types of attacks to work)? > Yes, that's the idea. 2) If static client authentication is used with 0-RTT data, the client > authentication always preceeds 0-RTT data (it is first in early > handshake, and using 1-RTT client auth is forbidden). This seems to > imply 0-RTT data should be interpretted in an authenticated context, > which seems dangerous given the replayability of the 0-RTT data. > Well remember that applications already have this problem because they send cookies and the like in their HTTP requests. So, I don't know how much this alters the analysis. And yes, we do have settings where we need this 3) The document talks about making 0-RTT data unreplayable by using > extra identifier agreed out-of-band. Does that actually work, given > the likely auto-replay by the client? I'm assuming that in these cases the server has global state and so doesn't have a problem. -Ekr > > > -Ilari > --001a114fcea83889290521e9a86e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote: > On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario <hkario@redhat.com> wrote:
>
> > aren't we still missing the 0-RTT mod= e?
>
> It's in the current draft though there are a few details that we&#= 39;re
> going to need to nail down over the next few weeks and in Yokohama.
IMO, that should be nailed rather quick, given that that what there<= br> is right now isn't really sufficient to analyze it.

Yes, that's the plan, as noted above.

=C2=A0
However, some comments about 0-RTT:


1) It seems to me that if server key is compromised, MITM can
substitute 0-RTT data with its own (at least if original and modified
one have the same number of records). And such modification will not
be detected by handshake, which will complete successfully.

Perhaps the comment about impersonation with compromised server key
was about this (I can't get more usual types of attacks to work)?

Yes, that's the idea.

=C2=A0

2) If static client authentication is used with 0-RTT data, the client
authentication always preceeds 0-RTT data (it is first in early
handshake, and using 1-RTT client auth is forbidden). This seems to
imply 0-RTT data should be interpretted in an authenticated context,
which seems dangerous given the replayability of the 0-RTT data.

Well remember that applications already have this= problem because
they send cookies and the like in their HTTP req= uests. So, I don't
know how much this alters the analysis. An= d yes, we do have settings
where we need this



3) The document talks about making 0-RTT data unreplayable by using
extra identifier agreed out-of-band. Does that actually work, given
the likely auto-replay by the client?

I'= ;m assuming that in these cases the server has global state and so doesn= 9;t
have a problem.

-Ekr

<= /div>



-Ilari

--001a114fcea83889290521e9a86e-- From nobody Mon Oct 12 09:05:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C061A883A for ; Mon, 12 Oct 2015 09:05:43 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtNgu0e5OGew for ; Mon, 12 Oct 2015 09:05:41 -0700 (PDT) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 908721A001C for ; Mon, 12 Oct 2015 09:05:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 7626719C5CE; Mon, 12 Oct 2015 19:05:40 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id mMWg06afldiz; Mon, 12 Oct 2015 19:05:40 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 3EB485BC005; Mon, 12 Oct 2015 19:05:40 +0300 (EEST) Date: Mon, 12 Oct 2015 19:05:39 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151012160539.GA30129@LK-Perkele-V2.elisa-laajakaista.fi> References: <5616DE2A.6060508@cs.tcd.ie> <3257371.23XkUVl0AJ@pintsize.usersys.redhat.com> <20151012145803.GA29740@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] TRON workshop X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 16:05:43 -0000 On Mon, Oct 12, 2015 at 08:04:37AM -0700, Eric Rescorla wrote: > On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara > wrote: > > > > 1) It seems to me that if server key is compromised, MITM can > > substitute 0-RTT data with its own (at least if original and modified > > one have the same number of records). And such modification will not > > be detected by handshake, which will complete successfully. > > > > Perhaps the comment about impersonation with compromised server key > > was about this (I can't get more usual types of attacks to work)? > > > > Yes, that's the idea. If so, I think the note is really unclear. Maybe something like: "If the server key is compromised, then the attacker can tamper with the 0-RTT data without detection.". (The reason I can't make straightforward impersonation to work is that the signature presumably signs unknown client DH keys and server sends fresh DH keys, so one can't compute the ES and contine past when connection goes encrypted). > 2) If static client authentication is used with 0-RTT data, the client > > authentication always preceeds 0-RTT data (it is first in early > > handshake, and using 1-RTT client auth is forbidden). This seems to > > imply 0-RTT data should be interpretted in an authenticated context, > > which seems dangerous given the replayability of the 0-RTT data. > > Well remember that applications already have this problem because > they send cookies and the like in their HTTP requests. So, I don't > know how much this alters the analysis. And yes, we do have settings > where we need this At least HTTP has safe methods (GET) and also HTTP/2 has prelude (which is connection-scoped) one might want to send as 0-RTT data. And also, can you give some examples of settings where authenticating 0-RTT data is needed? > 3) The document talks about making 0-RTT data unreplayable by using > > extra identifier agreed out-of-band. Does that actually work, given > > the likely auto-replay by the client? > > I'm assuming that in these cases the server has global state and so doesn't > have a problem. I was thinking of stuff like this: 1) Client sends 1st flight to server, gets intercepted by attacker. 2) Attacker sends the 1st flight to server twice. 3) Attacker resets the connection where server accepts the data. 4) Attacker starts forwarding other data. 5) Client sees 0-RTT failed. Completes handshake. 6) Client compensates for failed 0-RTT and essentially causes a replay. (Which I think actually did come up when DKG broke the heck out of 0-RTT anti-replay). And while at it, although this isn't about 0-RTT: 4) Currently the handshake "restart" anti-tampering works by continuing the hashes. This has nice security properties seemingly difficult to replicate in other settings. I have identified three kinds of attacks against handshake "restart": - Attacker tampering with first ClientHello. - Attacker tampering with returned HelloRetryRequest. - Attacker causing handshake restart on serverside without client knowing. Current "continue the hashes" prevents all those attacks by causing handshake to unavoidably fail. It seems to me that other approaches rely on client and server performing checks, and given the complexity of things like checking ClientHello, I give chance of epsilon squared (= very^2 small) that there isn't going to be implementations that get that badly wrong. -Ilari From nobody Mon Oct 12 09:49:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B5B1A88E4 for ; Mon, 12 Oct 2015 09:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKcEZ9KO-FMa for ; Mon, 12 Oct 2015 09:49:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3741C1A88EC for ; Mon, 12 Oct 2015 09:49:49 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-e7-561be4abdd96 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.3F.29154.BA4EB165; Mon, 12 Oct 2015 18:49:47 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.184]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Mon, 12 Oct 2015 18:49:46 +0200 From: John Mattsson To: Sean Turner Thread-Topic: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security Thread-Index: AQHRBMydOHy9F9/ta0KlukZnanicFp5ntdgAgABcjYA= Date: Mon, 12 Oct 2015 16:49:46 +0000 Message-ID: References: <9BB2A2C5-005B-4F2C-9CAB-EA23F07FE0D5@sn3rd.com> In-Reply-To: <9BB2A2C5-005B-4F2C-9CAB-EA23F07FE0D5@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <5365B4596050AC4DBCB3A1BE7CDD73DA@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rnf1E+kwg4nTBSyurGpktvh0vovR gcljyZKfTB4HDzIGMEVx2aSk5mSWpRbp2yVwZZxcVluwSbzi5fInTA2MT8S6GDk5JARMJJqv fmGDsMUkLtxbD2RzcQgJHGWUmDDxCyOEs4RRYmXrLhaQKjYBA4m5exrAOkQEFCSajj5gBbGZ BRQl9mw7yQ5iCwu4Stzq+QdV4yYxtWk2M4RtJdGyaC5YPYuAqsSrH+vAangFzCXWNR1gBLGF BLIk1mw4BBTn4OAUsJX4td4FJMwIdNz3U2uYIFaJS9x6Mp8J4mgBiSV7zjND2KISLx//YwVp FRXQk9izXBIirChxdfpyJpAws4CmxPpd+hBTrCXmzv/HAnP8lO6H7BDHCEqcnPmEZQKjxCwk y2YhdM9C0j0LSfcsJN0LGFlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG38Etv612MB58 7niIUYCDUYmH98FtqTAh1sSy4srcQ4zSHCxK4rzNTA9ChQTSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTC2nFzo9uokk2ntrDdLeKTN19QuCjvcl/CeLyLe6PqleW0HV7SWHDvcOvPVaa0O5av8 wv3f2MPMz0fsW6iscuvvvBfBsyLEnZ7d1HcXVN48Pd/YIPm3YOo0p33Sy6QMPgf8dr3kU/f/ v5OVqAC3dcZK9lWspyK/eHfV7HA+456WofE8q3fn1udKLMUZiYZazEXFiQAqXN/vnwIAAA== Archived-At: Cc: "TLS@ietf.org" Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 16:49:51 -0000 VGhlIHN0YXRlbWVudCBpIFsxXSBpcyBhYm91dCBBRVMsIGFuZCBpcyB2ZXJ5IHRydWUuIEFFUy0x OTIgaXMgdmVyeSBzZWxkb20NCnVzZWQsIGFuZCBwZW9wbGUgdGVuZCB0byBqdW1wIGRpcmVjdGx5 IHRvIEFFUy0yNTYuDQoNCkZvciBFQ0MgY3VydmVzLCB0aGUgb3Bwb3NpdGUgaXMgdHJ1ZSwgcGVv cGxlIHRlbmQgdG8gdXNlIFAtMzg0IGluc3RlYWQgb2YNClAtNTIxLiBNb3N0IGxpa2VseSBiZWNh dXNlIG9mIHRoYXQgUC0zODQgaXMgdXNlZCBpbiBzdWl0ZSBCLiBBY2NvcmRpbmcgdG8NClsyXSwg R29vZ2xlIENocm9tZSByZWNlbnRseSBkcm9wcGVkIHN1cHBvcnQgb2YgUC01MjEuDQoNClsyXSAN Cmh0dHBzOi8vc3VwcG9ydC5nbG9iYWxzaWduLmNvbS9jdXN0b21lci9wb3J0YWwvYXJ0aWNsZXMv MTk5NTI4My1lY2MtY29tcGF0aQ0KYmlsaXR5DQoNCg0KDQpUaGUgc2VjdXJpdHkgbGV2ZWwgb2Yg dGhlIEFFU18yNTZfR0NNX1NIQTM4NC1hbGdvcml0aG1zIGlzIGNsZWFybHkgbm8gbW9yZQ0KdGhh biAxOTIgYXMgU0hBLTM4NCBpcyB1c2VkLg0KDQpPbiAxMi8xMC8xNSAxNToxOCwgIlNlYW4gVHVy bmVyIiA8c2VhbkBzbjNyZC5jb20+IHdyb3RlOg0KDQo+SXQgaXMgaW50ZXJlc3RpbmcgdG8gbm90 ZSB0aGF0IGluIGRpc2N1c3NpbmcgdXBkYXRlIElQU2Vj4oCZcyBSRkMgNDMwNw0KPnNvbWVib2R5 IHN1Z2dlc3RlZCBtYWtpbmcgMTkyIGEgTUFZIGJlY2F1c2UgZm9sa3Mgb25seSB1c2UgMTI4LzI1 NiBbMV0uDQo+DQo+c3B0DQo+DQo+WzFdIGh0dHA6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L21zZy9pcHNlYy8xRjVoNGotZFA1ZExQQ0NBcWc0aXFnampZRkUNCj4NCj5PbiBPY3QgMTIsIDIw MTUsIGF0IDA1OjAxLCBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4N Cj53cm90ZToNCj4NCj4+IEkgdGhpbmsgdGhlIHNlbGVjdGlvbiBvZiBNVEkgQ2lwaGVyIFN1aXRl cyAoU2VjdGlvbiA4LjEgb2YNCj4+ZHJhZnQtaWV0Zi10bHMtdGxzMTMtMDkpIGlzIGV4Y2VsbGVu dCwgYnV0IEkgYW0gbWlzc2luZyBhIHJlY29tbWVuZGVkDQo+PkVDQyBjdXJ2ZSBmb3IgdGhlIOKA nFNIT1VMROKAnSBjaXBoZXIgc3VpdGVzLiBMaXR0bGUgYmVuZWZpdCBvZiB1c2luZw0KPj5BRVMt MjU2IHdpdGggUC0yNTYgb3IgY3VydmUyNTUxOS4gU2hvdWxkbuKAmXQgdGhlcmUgYmUgYSBTSE9V TEQgaW1wbGVtZW50DQo+PkVDQyBjdXJ2ZSBnaXZpbmcgYXQgbGVhc3QgMTkyLWJpdCBzZWN1cml0 eT8gRS5nLg0KPj4gDQo+PiAiVGhlc2UgY2lwaGVyIHN1aXRlcyBTSE9VTEQgc3VwcG9ydCBib3Ro IGRpZ2l0YWwgc2lnbmF0dXJlcyBhbmQga2V5DQo+PmV4Y2hhbmdlIHdpdGggc2VjcDM4NHIxIChO SVNUIFAtMzg0KS4iDQo+PiANCj4+IENoZWVycywNCj4+IEpvaG4NCj4+ICANCj4+IDwxM0RFRkI5 NC1GNzM1LTQ5QjAtODE5Ni1CREI1QzkwMTdBMzJbM10ucG5nPg0KPj4gDQo+PiBKT0hOIE1BVFRT U09ODQo+PiBNU2MgRW5naW5lZXJpbmcgUGh5c2ljcywgTVNjIEJ1c2luZXNzIEFkbWluaXN0cmF0 aW9uIGFuZCBFY29ub21pY3MNCj4+IEVyaWNzc29uIElFVEYgU2VjdXJpdHkgQ29vcmRpbmF0b3IN Cj4+IFNlbmlvciBSZXNlYXJjaGVyLCBTZWN1cml0eQ0KPj4gDQo+PiBFcmljc3NvbiBBQg0KPj4g RXJpY3Nzb24gUmVzZWFyY2gNCj4+IEbDpHLDtmdhdGFuIDYNCj4+IFNFLTE2NCA4MCBTdG9ja2hv bG0sIFN3ZWRlbg0KPj4gUGhvbmUgKzQ2IDEwIDcxIDQzIDUwMQ0KPj4gU01TL01NUyArNDYgNzYg MTEgNTMgNTAxDQo+PiBqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbQ0KPj4gd3d3LmVyaWNzc29u LmNvbQ0KPj4gDQo+PiANCj4+IDxEMzc3RTgwMC0wQTFBLTQzRDMtQUY1RS0xNjVGNjk3Nzg5QjVb M10ucG5nPg0KPj4gIA0KPj4gVGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ug b25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uDQo+PnRoZSBiYXNpcyBvZiB0aGUgdGVybXMg c2V0IG91dCBhdHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcg0KPj4gDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gVExTIG1haWxp bmcgbGlzdA0KPj4gVExTQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Rscw0KPg0KDQo= From nobody Mon Oct 12 10:02:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E574C1A8901 for ; Mon, 12 Oct 2015 10:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, SPF_PASS=-0.001] autolearn=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 YgUFap_co0fa for ; Mon, 12 Oct 2015 10:02:17 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 44F1A1A88F0 for ; Mon, 12 Oct 2015 10:02:17 -0700 (PDT) Received: by obbda8 with SMTP id da8so111197727obb.1 for ; Mon, 12 Oct 2015 10:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mYLNK6lNeM+SR4tBQ53xq1FxOlaww2gdKEXqqW3oa5g=; b=Trq8Er5Jzu8p0bEdoAmQP+UTcvgRYFBZPBAgh/zMbBmIm/XmuDv2Qvvt8DjH1Irz42 PjwdyiKc/jExc/A0n4Dhd6+eQVI3gQLrzOAnq5Ux/qsgYOjZD2nwCdujulHRTepLTkar yL/H9HzVn0bLHOqJwuIKb3k8VCAvHzsilBv/HV3rzQ7rffGsY2ZOmU3XyplwmsopQmz6 1IWAFBJo72AQBue5ABg5riTvv+wNi55Xr03e9Uh7AR8IveGmdtiKpGh+sn7JJI8XpGQx RQEmpOFbHR2/eJUjju9E2KcTlMFgk5IwtGz0dOmAYaBwKxYuLiuUnVX+nxFM1nq/TFYS YWLA== MIME-Version: 1.0 X-Received: by 10.182.84.164 with SMTP id a4mr15097533obz.33.1444669336505; Mon, 12 Oct 2015 10:02:16 -0700 (PDT) Received: by 10.202.192.193 with HTTP; Mon, 12 Oct 2015 10:02:15 -0700 (PDT) Received: by 10.202.192.193 with HTTP; Mon, 12 Oct 2015 10:02:15 -0700 (PDT) In-Reply-To: References: <9BB2A2C5-005B-4F2C-9CAB-EA23F07FE0D5@sn3rd.com> Date: Mon, 12 Oct 2015 13:02:16 -0400 Message-ID: From: Quynh Dang To: John Mattsson Content-Type: multipart/alternative; boundary=089e010d89389efd0f0521eb4aeb Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 17:02:19 -0000 --089e010d89389efd0f0521eb4aeb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi John, Sha384 in the ciphersuite is the hash function to be used in hmac, not signatures, and the security of this hmac depends on the strenght of the hmac key and the tag size. Regards, Quynh. On Oct 12, 2015 12:50 PM, "John Mattsson" wrote: > The statement i [1] is about AES, and is very true. AES-192 is very seldo= m > used, and people tend to jump directly to AES-256. > > For ECC curves, the opposite is true, people tend to use P-384 instead of > P-521. Most likely because of that P-384 is used in suite B. According to > [2], Google Chrome recently dropped support of P-521. > > [2] > https://support.globalsign.com/customer/portal/articles/1995283-ecc-compa= ti > bility > > > > The security level of the AES_256_GCM_SHA384-algorithms is clearly no mor= e > than 192 as SHA-384 is used. > > On 12/10/15 15:18, "Sean Turner" wrote: > > >It is interesting to note that in discussing update IPSec=E2=80=99s RFC = 4307 > >somebody suggested making 192 a MAY because folks only use 128/256 [1]. > > > >spt > > > >[1] > http://mailarchive.ietf.org/arch/msg/ipsec/1F5h4j-dP5dLPCCAqg4iqgjjYFE > > > >On Oct 12, 2015, at 05:01, John Mattsson > >wrote: > > > >> I think the selection of MTI Cipher Suites (Section 8.1 of > >>draft-ietf-tls-tls13-09) is excellent, but I am missing a recommended > >>ECC curve for the =E2=80=9CSHOULD=E2=80=9D cipher suites. Little benefi= t of using > >>AES-256 with P-256 or curve25519. Shouldn=E2=80=99t there be a SHOULD i= mplement > >>ECC curve giving at least 192-bit security? E.g. > >> > >> "These cipher suites SHOULD support both digital signatures and key > >>exchange with secp384r1 (NIST P-384)." > >> > >> Cheers, > >> John > >> > >> <13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png> > >> > >> JOHN MATTSSON > >> MSc Engineering Physics, MSc Business Administration and Economics > >> Ericsson IETF Security Coordinator > >> Senior Researcher, Security > >> > >> Ericsson AB > >> Ericsson Research > >> F=C3=A4r=C3=B6gatan 6 > >> SE-164 80 Stockholm, Sweden > >> Phone +46 10 71 43 501 > >> SMS/MMS +46 76 11 53 501 > >> john.mattsson@ericsson.com > >> www.ericsson.com > >> > >> > >> > >> > >> This Communication is Confidential. We only send and receive email on > >>the basis of the terms set out atwww.ericsson.com/email_disclaimer > >> > >> _______________________________________________ > >> 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 > --089e010d89389efd0f0521eb4aeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi John,

Sha384 in the ciphersuite is the hash function to be used in= hmac, not signatures, and the security of this hmac depends on the strengh= t of the hmac key and the tag size.

Regards,
Quynh.

On Oct 12, 2015 12:50 PM, "John Mattsson&qu= ot; <john.mattsson@ericsso= n.com> wrote:
The statement i [1] is about AES, and is very true. AES-192 is very seldom=
used, and people tend to jump directly to AES-256.

For ECC curves, the opposite is true, people tend to use P-384 instead of P-521. Most likely because of that P-384 is used in suite B. According to [2], Google Chrome recently dropped support of P-521.

[2]
https://support.globalsig= n.com/customer/portal/articles/1995283-ecc-compati
bility



The security level of the AES_256_GCM_SHA384-algorithms is clearly no more<= br> than 192 as SHA-384 is used.

On 12/10/15 15:18, "Sean Turner" <sean@sn3rd.com> wrote:

>It is interesting to note that in discussing update IPSec=E2=80=99s RFC= 4307
>somebody suggested making 192 a MAY because folks only use 128/256 [1].=
>
>spt
>
>[1] http://mailarchive.iet= f.org/arch/msg/ipsec/1F5h4j-dP5dLPCCAqg4iqgjjYFE
>
>On Oct 12, 2015, at 05:01, John Mattsson <john.mattsson@ericsson.com>
>wrote:
>
>> I think the selection of MTI Cipher Suites (Section 8.1 of
>>draft-ietf-tls-tls13-09) is excellent, but I am missing a recommend= ed
>>ECC curve for the =E2=80=9CSHOULD=E2=80=9D cipher suites. Little be= nefit of using
>>AES-256 with P-256 or curve25519. Shouldn=E2=80=99t there be a SHOU= LD implement
>>ECC curve giving at least 192-bit security? E.g.
>>
>> "These cipher suites SHOULD support both digital signatures a= nd key
>>exchange with secp384r1 (NIST P-384)."
>>
>> Cheers,
>> John
>>
>> <13DEFB94-F735-49B0-8196-BDB5C9017A32[3].png>
>>
>> JOHN MATTSSON
>> MSc Engineering Physics, MSc Business Administration and Economics=
>> Ericsson IETF Security Coordinator
>> Senior Researcher, Security
>>
>> Ericsson AB
>> Ericsson Research
>> F=C3=A4r=C3=B6gatan 6
>> SE-164 80 Stockholm, Sweden
>> Phone +46 10 71 43 501
>> SMS/MMS +46 76 11 53 501
>> john.mattsson@ericss= on.com
>> www.ericsson.com
>>
>>
>> <D377E800-0A1A-43D3-AF5E-165F697789B5[3].png>
>>
>> This Communication is Confidential. We only send and receive email= on
>>the basis of the terms set out atwww.ericsson.com/= email_disclaimer
>>
>> _______________________________________________
>> 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
--089e010d89389efd0f0521eb4aeb-- From nobody Mon Oct 12 10:08:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6879F1A8974 for ; Mon, 12 Oct 2015 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rssi_1f0v3cV for ; Mon, 12 Oct 2015 10:08:33 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF0A1A8973 for ; Mon, 12 Oct 2015 10:08:32 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-f0-561be90ec909 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 89.D8.05274.E09EB165; Mon, 12 Oct 2015 19:08:30 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.184]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Mon, 12 Oct 2015 19:08:30 +0200 From: John Mattsson To: Quynh Dang Thread-Topic: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security Thread-Index: AQHRBMydOHy9F9/ta0KlukZnanicFp5ntdgAgABcjYD//+H4AIAAI0SA Date: Mon, 12 Oct 2015 17:08:29 +0000 Message-ID: References: <9BB2A2C5-005B-4F2C-9CAB-EA23F07FE0D5@sn3rd.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.5.4.150722 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D241B5A33DA33johnmattssonericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM+JvjS7fS+kwg8XvDS2On3zFbnFlVSOz xafzXYwOzB47Z91l91iy5CeTx8GDjAHMUVw2Kak5mWWpRfp2CVwZiw7/ZC2YlVRx4+F19gbG g/FdjJwcEgImEju+HmSGsMUkLtxbz9bFyMUhJHCUUeLgvn3sEM4SRomrb6czglSxCRhIzN3T wAZiiwgoSTxfsA2sm1nAXuL20aNMILawgKvErZ5/UDVuElObZjPD2N1nfoHVsAioShw9dBQs zitgLvFkzwpWiGX3GSWONVwDa+YUCJQ4feEV2GJGoPO+n1rDBLFMXOLWk/lMEGcLSCzZcx7q BVGJl4//AQ3i4BAV0JPYs1wSIqwocXX6cqjWGIk/Wz+zQOwVlDg58wnLBEaxWUimzkJSNgtJ 2SygqcwCmhLrd+lDlChKTOl+yA5ha0i0zpkLZVtL3Fm9nh1ZzQJGjlWMosWpxUm56UbGeqlF mcnFxfl5enmpJZsYgRF7cMtv1R2Ml984HmIU4GBU4uF9cFsqTIg1say4MvcQozQHi5I4bzPT g1AhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBkrqrbkNc2a9cxYIulMbnL75a128UaLNnDm fhZY+k4l/ebJYGGnD4Ft5jmzmBa4vD67qHOBGNfGfKd8pXXLOTnOmvJttlO8ZPRimUi2QvEr 38uz9fdc0G9MVzPx7t3Qe+X+mccM4cdLEopm8XsoT7pxbi+bbenqzEteS8422uZ80l+iIONy R4mlOCPRUIu5qDgRAMFhHEO5AgAA Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Recommended ECC curve for 192-bit security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 17:08:35 -0000 --_000_D241B5A33DA33johnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBteSBmYXVsdC4NCg0KRnJvbTogUXV5bmggRGFuZyA8cXV5bmg5N0BnbWFpbC5jb208bWFp bHRvOnF1eW5oOTdAZ21haWwuY29tPj4NCkRhdGU6IE1vbmRheSAxMiBPY3RvYmVyIDIwMTUgMTk6 MDINClRvOiBKb2huIE1hdHRzc29uMiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb208bWFpbHRv OmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPj4NCkNjOiAiVExTQGlldGYub3JnPG1haWx0bzpU TFNAaWV0Zi5vcmc+IiA8VExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+PiwgU2VhbiBU dXJuZXIgPHNlYW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+DQpTdWJqZWN0OiBS ZTogW1RMU10gVExTIDEuMyBSZWNvbW1lbmRlZCBFQ0MgY3VydmUgZm9yIDE5Mi1iaXQgc2VjdXJp dHkNCg0KDQpIaSBKb2huLA0KDQpTaGEzODQgaW4gdGhlIGNpcGhlcnN1aXRlIGlzIHRoZSBoYXNo IGZ1bmN0aW9uIHRvIGJlIHVzZWQgaW4gaG1hYywgbm90IHNpZ25hdHVyZXMsIGFuZCB0aGUgc2Vj dXJpdHkgb2YgdGhpcyBobWFjIGRlcGVuZHMgb24gdGhlIHN0cmVuZ2h0IG9mIHRoZSBobWFjIGtl eSBhbmQgdGhlIHRhZyBzaXplLg0KDQpSZWdhcmRzLA0KUXV5bmguDQoNCk9uIE9jdCAxMiwgMjAx NSAxMjo1MCBQTSwgIkpvaG4gTWF0dHNzb24iIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbTxt YWlsdG86am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+PiB3cm90ZToNClRoZSBzdGF0ZW1lbnQg aSBbMV0gaXMgYWJvdXQgQUVTLCBhbmQgaXMgdmVyeSB0cnVlLiBBRVMtMTkyIGlzIHZlcnkgc2Vs ZG9tDQp1c2VkLCBhbmQgcGVvcGxlIHRlbmQgdG8ganVtcCBkaXJlY3RseSB0byBBRVMtMjU2Lg0K DQpGb3IgRUNDIGN1cnZlcywgdGhlIG9wcG9zaXRlIGlzIHRydWUsIHBlb3BsZSB0ZW5kIHRvIHVz ZSBQLTM4NCBpbnN0ZWFkIG9mDQpQLTUyMS4gTW9zdCBsaWtlbHkgYmVjYXVzZSBvZiB0aGF0IFAt Mzg0IGlzIHVzZWQgaW4gc3VpdGUgQi4gQWNjb3JkaW5nIHRvDQpbMl0sIEdvb2dsZSBDaHJvbWUg cmVjZW50bHkgZHJvcHBlZCBzdXBwb3J0IG9mIFAtNTIxLg0KDQpbMl0NCmh0dHBzOi8vc3VwcG9y dC5nbG9iYWxzaWduLmNvbS9jdXN0b21lci9wb3J0YWwvYXJ0aWNsZXMvMTk5NTI4My1lY2MtY29t cGF0aQ0KYmlsaXR5DQoNCg0KDQpUaGUgc2VjdXJpdHkgbGV2ZWwgb2YgdGhlIEFFU18yNTZfR0NN X1NIQTM4NC1hbGdvcml0aG1zIGlzIGNsZWFybHkgbm8gbW9yZQ0KdGhhbiAxOTIgYXMgU0hBLTM4 NCBpcyB1c2VkLg0KDQpPbiAxMi8xMC8xNSAxNToxOCwgIlNlYW4gVHVybmVyIiA8c2VhbkBzbjNy ZC5jb208bWFpbHRvOnNlYW5Ac24zcmQuY29tPj4gd3JvdGU6DQoNCj5JdCBpcyBpbnRlcmVzdGlu ZyB0byBub3RlIHRoYXQgaW4gZGlzY3Vzc2luZyB1cGRhdGUgSVBTZWPigJlzIFJGQyA0MzA3DQo+ c29tZWJvZHkgc3VnZ2VzdGVkIG1ha2luZyAxOTIgYSBNQVkgYmVjYXVzZSBmb2xrcyBvbmx5IHVz ZSAxMjgvMjU2IFsxXS4NCj4NCj5zcHQNCj4NCj5bMV0gaHR0cDovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL2lwc2VjLzFGNWg0ai1kUDVkTFBDQ0FxZzRpcWdqallGRQ0KPg0KPk9uIE9j dCAxMiwgMjAxNSwgYXQgMDU6MDEsIEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nz b24uY29tPG1haWx0bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4+DQo+d3JvdGU6DQo+DQo+ PiBJIHRoaW5rIHRoZSBzZWxlY3Rpb24gb2YgTVRJIENpcGhlciBTdWl0ZXMgKFNlY3Rpb24gOC4x IG9mDQo+PmRyYWZ0LWlldGYtdGxzLXRsczEzLTA5KSBpcyBleGNlbGxlbnQsIGJ1dCBJIGFtIG1p c3NpbmcgYSByZWNvbW1lbmRlZA0KPj5FQ0MgY3VydmUgZm9yIHRoZSDigJxTSE9VTETigJ0gY2lw aGVyIHN1aXRlcy4gTGl0dGxlIGJlbmVmaXQgb2YgdXNpbmcNCj4+QUVTLTI1NiB3aXRoIFAtMjU2 IG9yIGN1cnZlMjU1MTkuIFNob3VsZG7igJl0IHRoZXJlIGJlIGEgU0hPVUxEIGltcGxlbWVudA0K Pj5FQ0MgY3VydmUgZ2l2aW5nIGF0IGxlYXN0IDE5Mi1iaXQgc2VjdXJpdHk/IEUuZy4NCj4+DQo+ PiAiVGhlc2UgY2lwaGVyIHN1aXRlcyBTSE9VTEQgc3VwcG9ydCBib3RoIGRpZ2l0YWwgc2lnbmF0 dXJlcyBhbmQga2V5DQo+PmV4Y2hhbmdlIHdpdGggc2VjcDM4NHIxIChOSVNUIFAtMzg0KS4iDQo+ Pg0KPj4gQ2hlZXJzLA0KPj4gSm9obg0KPj4NCj4+IDwxM0RFRkI5NC1GNzM1LTQ5QjAtODE5Ni1C REI1QzkwMTdBMzJbM10ucG5nPg0KPj4NCj4+IEpPSE4gTUFUVFNTT04NCj4+IE1TYyBFbmdpbmVl cmluZyBQaHlzaWNzLCBNU2MgQnVzaW5lc3MgQWRtaW5pc3RyYXRpb24gYW5kIEVjb25vbWljcw0K Pj4gRXJpY3Nzb24gSUVURiBTZWN1cml0eSBDb29yZGluYXRvcg0KPj4gU2VuaW9yIFJlc2VhcmNo ZXIsIFNlY3VyaXR5DQo+Pg0KPj4gRXJpY3Nzb24gQUINCj4+IEVyaWNzc29uIFJlc2VhcmNoDQo+ PiBGw6Ryw7ZnYXRhbiA2DQo+PiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4NCj4+IFBob25l ICs0NiAxMCA3MSA0MyA1MDENCj4+IFNNUy9NTVMgKzQ2IDc2IDExIDUzIDUwMQ0KPj4gam9obi5t YXR0c3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPg0K Pj4gd3d3LmVyaWNzc29uLmNvbTxodHRwOi8vd3d3LmVyaWNzc29uLmNvbT4NCj4+DQo+Pg0KPj4g PEQzNzdFODAwLTBBMUEtNDNEMy1BRjVFLTE2NUY2OTc3ODlCNVszXS5wbmc+DQo+Pg0KPj4gVGhp cyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZl IGVtYWlsIG9uDQo+PnRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdHd3dy5lcmljc3Nv bi5jb20vZW1haWxfZGlzY2xhaW1lcjxodHRwOi8vYXR3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rp c2NsYWltZXI+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IFRMUyBtYWlsaW5nIGxpc3QNCj4+IFRMU0BpZXRmLm9yZzxtYWlsdG86VExT QGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMN Cj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRM UyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== --_000_D241B5A33DA33johnmattssonericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5D7FF3C29E9A1741ADBACF6DAF5A82B3@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlllcywgbXkgZmF1bHQuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFj azsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBp bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZy b206IDwvc3Bhbj5RdXluaCBEYW5nICZsdDs8YSBocmVmPSJtYWlsdG86cXV5bmg5N0BnbWFpbC5j b20iPnF1eW5oOTdAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSAxMiBPY3RvYmVyIDIwMTUgMTk6MDI8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5Kb2huIE1hdHRzc29uMiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tIj5qb2huLm1hdHRz c29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGll dGYub3JnPC9hPiZndDssIFNlYW4gVHVybmVyICZsdDs8YSBocmVmPSJtYWlsdG86c2VhbkBzbjNy ZC5jb20iPnNlYW5Ac24zcmQuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbVExTXSBUTFMgMS4zIFJlY29tbWVuZGVkIEVD QyBjdXJ2ZSBmb3IgMTkyLWJpdCBzZWN1cml0eTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgZGlyPSJsdHIiPkhpIEpvaG4sPC9wPg0KPHAgZGlyPSJsdHIi PlNoYTM4NCBpbiB0aGUgY2lwaGVyc3VpdGUgaXMgdGhlIGhhc2ggZnVuY3Rpb24gdG8gYmUgdXNl ZCBpbiBobWFjLCBub3Qgc2lnbmF0dXJlcywgYW5kIHRoZSBzZWN1cml0eSBvZiB0aGlzIGhtYWMg ZGVwZW5kcyBvbiB0aGUgc3RyZW5naHQgb2YgdGhlIGhtYWMga2V5IGFuZCB0aGUgdGFnIHNpemUu PC9wPg0KPHAgZGlyPSJsdHIiPlJlZ2FyZHMsPGJyPg0KUXV5bmguPC9wPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIE9jdCAxMiwgMjAxNSAxMjo1MCBQTSwgJnF1b3Q7Sm9obiBNYXR0c3Nv biZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tIj5q b2huLm1hdHRzc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1 dGlvbiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NClRo ZSBzdGF0ZW1lbnQgaSBbMV0gaXMgYWJvdXQgQUVTLCBhbmQgaXMgdmVyeSB0cnVlLiBBRVMtMTky IGlzIHZlcnkgc2VsZG9tPGJyPg0KdXNlZCwgYW5kIHBlb3BsZSB0ZW5kIHRvIGp1bXAgZGlyZWN0 bHkgdG8gQUVTLTI1Ni48YnI+DQo8YnI+DQpGb3IgRUNDIGN1cnZlcywgdGhlIG9wcG9zaXRlIGlz IHRydWUsIHBlb3BsZSB0ZW5kIHRvIHVzZSBQLTM4NCBpbnN0ZWFkIG9mPGJyPg0KUC01MjEuIE1v c3QgbGlrZWx5IGJlY2F1c2Ugb2YgdGhhdCBQLTM4NCBpcyB1c2VkIGluIHN1aXRlIEIuIEFjY29y ZGluZyB0bzxicj4NClsyXSwgR29vZ2xlIENocm9tZSByZWNlbnRseSBkcm9wcGVkIHN1cHBvcnQg b2YgUC01MjEuPGJyPg0KPGJyPg0KWzJdPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9zdXBwb3J0Lmds b2JhbHNpZ24uY29tL2N1c3RvbWVyL3BvcnRhbC9hcnRpY2xlcy8xOTk1MjgzLWVjYy1jb21wYXRp IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3N1cHBvcnQuZ2xvYmFs c2lnbi5jb20vY3VzdG9tZXIvcG9ydGFsL2FydGljbGVzLzE5OTUyODMtZWNjLWNvbXBhdGk8L2E+ PGJyPg0KYmlsaXR5PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIHNlY3VyaXR5IGxldmVsIG9m IHRoZSBBRVNfMjU2X0dDTV9TSEEzODQtYWxnb3JpdGhtcyBpcyBjbGVhcmx5IG5vIG1vcmU8YnI+ DQp0aGFuIDE5MiBhcyBTSEEtMzg0IGlzIHVzZWQuPGJyPg0KPGJyPg0KT24gMTIvMTAvMTUgMTU6 MTgsICZxdW90O1NlYW4gVHVybmVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2VhbkBzbjNy ZC5jb20iPnNlYW5Ac24zcmQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0l0IGlz IGludGVyZXN0aW5nIHRvIG5vdGUgdGhhdCBpbiBkaXNjdXNzaW5nIHVwZGF0ZSBJUFNlY+KAmXMg UkZDIDQzMDc8YnI+DQomZ3Q7c29tZWJvZHkgc3VnZ2VzdGVkIG1ha2luZyAxOTIgYSBNQVkgYmVj YXVzZSBmb2xrcyBvbmx5IHVzZSAxMjgvMjU2IFsxXS48YnI+DQomZ3Q7PGJyPg0KJmd0O3NwdDxi cj4NCiZndDs8YnI+DQomZ3Q7WzFdIDxhIGhyZWY9Imh0dHA6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9pcHNlYy8xRjVoNGotZFA1ZExQQ0NBcWc0aXFnampZRkUiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2lwc2VjLzFGNWg0ai1kUDVkTFBDQ0FxZzRpcWdqallGRTwvYT48YnI+DQomZ3Q7PGJyPg0K Jmd0O09uIE9jdCAxMiwgMjAxNSwgYXQgMDU6MDEsIEpvaG4gTWF0dHNzb24gJmx0OzxhIGhyZWY9 Im1haWx0bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbSI+am9obi5tYXR0c3NvbkBlcmljc3Nv bi5jb208L2E+Jmd0Ozxicj4NCiZndDt3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgSSB0 aGluayB0aGUgc2VsZWN0aW9uIG9mIE1USSBDaXBoZXIgU3VpdGVzIChTZWN0aW9uIDguMSBvZjxi cj4NCiZndDsmZ3Q7ZHJhZnQtaWV0Zi10bHMtdGxzMTMtMDkpIGlzIGV4Y2VsbGVudCwgYnV0IEkg YW0gbWlzc2luZyBhIHJlY29tbWVuZGVkPGJyPg0KJmd0OyZndDtFQ0MgY3VydmUgZm9yIHRoZSDi gJxTSE9VTETigJ0gY2lwaGVyIHN1aXRlcy4gTGl0dGxlIGJlbmVmaXQgb2YgdXNpbmc8YnI+DQom Z3Q7Jmd0O0FFUy0yNTYgd2l0aCBQLTI1NiBvciBjdXJ2ZTI1NTE5LiBTaG91bGRu4oCZdCB0aGVy ZSBiZSBhIFNIT1VMRCBpbXBsZW1lbnQ8YnI+DQomZ3Q7Jmd0O0VDQyBjdXJ2ZSBnaXZpbmcgYXQg bGVhc3QgMTkyLWJpdCBzZWN1cml0eT8gRS5nLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg JnF1b3Q7VGhlc2UgY2lwaGVyIHN1aXRlcyBTSE9VTEQgc3VwcG9ydCBib3RoIGRpZ2l0YWwgc2ln bmF0dXJlcyBhbmQga2V5PGJyPg0KJmd0OyZndDtleGNoYW5nZSB3aXRoIHNlY3AzODRyMSAoTklT VCBQLTM4NCkuJnF1b3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0K Jmd0OyZndDsgSm9objxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmx0OzEzREVGQjk0LUY3 MzUtNDlCMC04MTk2LUJEQjVDOTAxN0EzMlszXS5wbmcmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBKT0hOIE1BVFRTU09OPGJyPg0KJmd0OyZndDsgTVNjIEVuZ2luZWVyaW5nIFBoeXNp Y3MsIE1TYyBCdXNpbmVzcyBBZG1pbmlzdHJhdGlvbiBhbmQgRWNvbm9taWNzPGJyPg0KJmd0OyZn dDsgRXJpY3Nzb24gSUVURiBTZWN1cml0eSBDb29yZGluYXRvcjxicj4NCiZndDsmZ3Q7IFNlbmlv ciBSZXNlYXJjaGVyLCBTZWN1cml0eTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRXJpY3Nz b24gQUI8YnI+DQomZ3Q7Jmd0OyBFcmljc3NvbiBSZXNlYXJjaDxicj4NCiZndDsmZ3Q7IEbDpHLD tmdhdGFuIDY8YnI+DQomZ3Q7Jmd0OyBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW48YnI+DQom Z3Q7Jmd0OyBQaG9uZSAmIzQzOzQ2IDEwIDcxIDQzIDUwMTxicj4NCiZndDsmZ3Q7IFNNUy9NTVMg JiM0Mzs0NiA3NiAxMSA1MyA1MDE8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86am9obi5t YXR0c3NvbkBlcmljc3Nvbi5jb20iPmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPC9hPjxicj4N CiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tIiByZWw9Im5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj53d3cuZXJpY3Nzb24uY29tPC9hPjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbHQ7RDM3N0U4MDAtMEExQS00M0QzLUFGNUUtMTY1 RjY5Nzc4OUI1WzNdLnBuZyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoaXMgQ29t bXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFp bCBvbjxicj4NCiZndDsmZ3Q7dGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IDxhIGhyZWY9 Imh0dHA6Ly9hdHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciIgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayI+DQphdHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1l cjwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgVExTIG1haWxpbmcgbGlzdDxi cj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwv YT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D241B5A33DA33johnmattssonericssoncom_-- From nobody Mon Oct 12 13:48:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757D91B364B for ; Mon, 12 Oct 2015 13:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 M3PgxjHS6ZEG for ; Mon, 12 Oct 2015 13:48:13 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 300091B3648 for ; Mon, 12 Oct 2015 13:48:13 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9CKlx9s003269 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 12 Oct 2015 22:48:01 +0200 X-Hashcash: 1:22:151012:tls@ietf.org::jTXpASJIPuQRYpI1:2N8 From: Simon Josefsson To: tls@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Mon, 12 Oct 2015 22:47:58 +0200 Message-ID: <87oag395kx.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [TLS] Fwd: Updated elliptic curve drafts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 20:48:14 -0000 --=-=-= Content-Type: text/plain FYI -- posted to pkix@ietf.org. Intended to work together with draft-josefsson-tls-eddsa or draft-josefsson-tls-eddsa2. /Simon From: Simon Josefsson Subject: Updated elliptic curve drafts To: pkix@ietf.org Date: Mon, 12 Oct 2015 22:25:31 +0200 Hi, I've updated my drafts on Curve25519/Curve448 support in PKIX to refer to the CFRG-Curves and CFRG-EdDSA drafts. The following document adds new EdDSA key/signature OIDs directly: https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 The following document adds new namedCurve OIDs, thus going indirectly through the existing ECDSA 3279 route: https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 These two drafts take different approaches to including the new curves into PKIX, and currently both lack applicability statements. There is potential for overlap and conflict right now. It recently came up that for PKCS#11 a namedCurve approach would be useful, but for normal PKIX Certificates, it may be that the first direct approach is preferrable. The former lack the possibility of encoding keys for DH. I believe each approach can be useful on its own, but we need to include text adressing use-cases that can be resolved by both documents to avoid conflicts. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWHBx+AAoJEIYLf7sy+BGdH0MH/jvQZTXod7ZvCipvPd8ozwhn BRypXgBQomivG+aWB5mqPXdMItUfp5UiOACN5pJbqNdRfzSN0ug5FeRvPSfYAzIS 3efsVtMeGYwi1LkzToIo4awWpOlH4gXEQdGXaZ43uWghrWf1GTZYgFQDjf3enc19 BolivHoKOdE2/qzzE/Ksv9LReNfjo09cd2s57pkD41Psc6c4VfMZEv/36S6VzTeh AbYFvMJL3+FK2wka20yQeer1MGR326iv+VPQu3C2gZ8zx+LF833Ro1BEITgAFaAL zDV1Bmtt3jceGuljbAabfS6b08LHMxcuRLdBZCl4nsbubrM7Ts6NYIyLIPVAfsg= =qMMu -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 12 15:53:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0781B2B69 for ; Mon, 12 Oct 2015 15:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 rl1qadHfOLs6 for ; Mon, 12 Oct 2015 15:53:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 928261B2B68 for ; Mon, 12 Oct 2015 15:53:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 64E2E433427 for ; Mon, 12 Oct 2015 22:53:48 +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 4EE78433419 for ; Mon, 12 Oct 2015 22:53:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444690428; bh=cdsrOB2vKtXclN/lZeR/x9H6/qIf13UWE9ELvv4O2UE=; l=2056; h=References:To:From:Date:In-Reply-To:From; b=Es3OUiZ8BCrnGuKOstsrIjzSdg2kvvl9bt9X/OXamZ2e15wqKQB5g8vZgGn9jn3rO Ndj5Ti3gqiPSh+h4JdIF3NIxhda/5OLZESpw4/xv4qFwvpFzEVjVfTcy8wmsE67h+O XuNufPvR34TdxBLjYN62CM0myw1EoWwwWOMwpK8w= 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 2F2F82027 for ; Mon, 12 Oct 2015 22:53:48 +0000 (GMT) References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> To: tls@ietf.org From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <561C39FB.6060206@akamai.com> Date: Mon, 12 Oct 2015 17:53:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2015 22:53:51 -0000 On 10/11/2015 08:46 AM, Watson Ladd wrote: > On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara > wrote: >> Some quick comments: >> - The signed DH share does not look to be bound to anything (crypto >> parameters negotiation, randoms, server key exchange, etc..). I can't >> offhand say what that would lead to, but it looks even worse than >> TLS ServerKeyExchange, which has known vulernabilities due to >> lack of binding to things like ciphersuite. >> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC >> (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. >> - Even use of DH is questionable. > I would suggest piggybacking on the PSK mode, using the key Kerberos > provides at both ends as the PSK key. This would address all of these > issues in TLS 1.3 > This would seem to require an application protocol doing some Kerberos exchanges up front to establish the Kerberos session key before pivoting into TLS-PSK in a STARTLS-esque fashion. If that's what the application protocol would look like, it seems like there's no reason not to go full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides. This proposal (as complicated as it is, and I'm not sure that I'm entirely comfortable with it yet) has the comparative advantage that the application speaks TLS from the start, with the Kerberos messages included in the TLS CKE. In that sense, at least, it is elegant. This proposal also includes a generic mechanism for the server to indicate what service type and hostname should be used in constructing the host-based service principal name for Kerberos, which is useful -- the convention for that would otherwise have to be baked into the application protocol. The considerations around client anonymity and a protocol for the server to convey its expectations are also interesting, though I'm not sure I would have put it in the -00 if it was my own document. There are some nits in the Kerberos bits that I might mention over on kitten. -Ben From nobody Mon Oct 12 20:01:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435191B2F70 for ; Mon, 12 Oct 2015 20:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqsrQHU5LeDd for ; Mon, 12 Oct 2015 20:01:32 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FF61B2F66 for ; Mon, 12 Oct 2015 20:01:31 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id UT1T1r00E10HQrX01T1UF4; Tue, 13 Oct 2015 05:01:29 +0200 Message-ID: <561C7405.8000501@openfortress.nl> Date: Tue, 13 Oct 2015 05:01:25 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Ilari Liusvaara , Watson Ladd References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> <561B419D.4010009@openfortress.nl> <20151012103650.GA28213@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20151012103650.GA28213@LK-Perkele-V2.elisa-laajakaista.fi> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Oct 2015 03:01:34 -0000 Hello Ilara / Watson / TLS WG, Thanks again, If I was to do things like the current proposal (as opposed to overloading DHE-PSK), I would put in hash of entiere client and server first flights. Now I see what you mean. Indeed, the master secret used in Finished does not take it into account in TLS 1.2, except under RFC 7627. > > > The SKE security issue (SKE isn't bound to the ciphersuite) has surfaced > at least three times: > > 1) The DHE/ECDHE confusion. > 2) FREAK > 3) Logjam Thanks, those are very good reasons indeed :) >> Watson> I would suggest piggybacking on the PSK mode, using the key Kerberos >> Watson> provides at both ends as the PSK key. This would address all of these >> Watson> issues in TLS 1.3 > I think he means stuffing the key from kerberos as PSK input in > (EC)DHE-PSK ciphersuite. That is not going to work for this. PSK communicates untyped blobs, which makes the server take a leap of faith, and so it is pretty much limited to internal use. I'm working on getting Kerberos to crossover between realms, and TLS-KDH might become the killer app for that. The key-handling approach of PSK got me thinking though (pre-master = DH-shared-secret + preshared-key). It is a strikingly simple method to make (EC)DH orthogonal to the authentication exchange. It means all the DH-specifics can go... perhaps 75% of my text! >> Ilari> - Even use of DH is questionable. >> >> This is mod-exp DH, on account of its need for very large keys, right? >> >> I would love to take it out, and only leave ECDH; I put up mod-exp DH >> initially because it might be desired for backward compatibility. If >> I hear no warm-felt desire for mod-exp DH I will gladly remove it. > > Backward compatiblity? I don't think you need such thing with proposal > like this. I am now preparing a new form, with ClientCertificate := krbTicket and CertificateVerify := krbAuthenticator. That seems to integrate really well with the rest of TLS, also for 1.3. * the Authenticator hashes all prior messages and stores them in "checksum", leading to the requested binding * the CertificateRequest can ask for various forms of authentication, even mixing Kerberos and X.509 * there will be Kerberos-only CipherSuites (mutual exclusion, so this authenticates the server) but it can also work with TLS_ECDHE_RSA_ et al * the TicketRequirementFlags will be a TLS Extension during ClientHello / ServerHello Rather different -- so a new text is coming up. -Rick From nobody Mon Oct 12 20:22:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299E31B3723 for ; Mon, 12 Oct 2015 20:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czR7uMkzrwUu for ; Mon, 12 Oct 2015 20:22:03 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2871B2F83 for ; Mon, 12 Oct 2015 20:22:03 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id UTN01r00610HQrX01TN11A; Tue, 13 Oct 2015 05:22:01 +0200 Message-ID: <561C78D6.9030405@openfortress.nl> Date: Tue, 13 Oct 2015 05:21:58 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Benjamin Kaduk References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> <561C39FB.6060206@akamai.com> In-Reply-To: <561C39FB.6060206@akamai.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Oct 2015 03:22:06 -0000 Hello Benjamin, > This would seem to require an application protocol doing some Kerberos > exchanges up front to establish the Kerberos session key before pivoting > into TLS-PSK in a STARTLS-esque fashion. If that's what the application > protocol would look like, it seems like there's no reason not to go > full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides. GSSAPI is too general IMHO; it specifies an unpredictable number of exchanges and TLS cannot carry that. An attempt for SASL-in-TLS was made in draft-williams-tls-app-sasl-opt, but it ends up piggybacking on TLS but continue afterwards -- loosing the cryptographic binding between auth from Kerberos with PFS from (EC)DH. > This proposal (as complicated as it is, and I'm not sure that I'm > entirely comfortable with it yet) has the comparative advantage that the > application speaks TLS from the start, with the Kerberos messages > included in the TLS CKE. In that sense, at least, it is elegant. Thanks. The proposed changes greatly simplify the spec, making all DH orthogonal to the spec. Watson convinced me and now I can pull a lot from the I-D, which is also more complex than I like. > This proposal also includes a generic mechanism for the server to > indicate what service type and hostname should be used in constructing > the host-based service principal name for Kerberos, which is useful -- > the convention for that would otherwise have to be baked into the > application protocol. > Actually, I did not specify such a mechanism. * Client and server assume that the application context knows what protocol it is using. AFAIK that always makes sense -- on top of TLS we're running something like imap, and imap knows that its tickets start with "imap/". * The hostname is known to the client too, it is usually included in the SNI extension, looked up in DNS, ... * However, the realm is "supposed to be derived independently" which can be done with the DNSSEC-assured _kerberos TXT that we discussed on Kitten. > The considerations around client anonymity and a > protocol for the server to convey its expectations are also interesting, > though I'm not sure I would have put it in the -00 if it was my own > document. OK :) but this was simpler than the loose end in predecessors -- sending no ticket and deciding how the server would respond to that. But it is a new idea, to have authenticated clients with unknown identities... > There are some nits in the Kerberos bits that I might mention over on > kitten. Great, thanks! -Rick From nobody Mon Oct 12 22:23:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4333B1B37CA for ; Mon, 12 Oct 2015 22:23: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTZFyRlpyPGo for ; Mon, 12 Oct 2015 22:23:32 -0700 (PDT) Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id C88291B37C8 for ; Mon, 12 Oct 2015 22:23:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id 4519656F75E; Tue, 13 Oct 2015 08:23:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id ejgmPAXc809F; Tue, 13 Oct 2015 08:23:29 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id DB3AE5BC010; Tue, 13 Oct 2015 08:23:29 +0300 (EEST) Date: Tue, 13 Oct 2015 08:23:29 +0300 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20151013052329.GA18808@LK-Perkele-V2.elisa-laajakaista.fi> References: <87oag395kx.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87oag395kx.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fwd: Updated elliptic curve drafts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Oct 2015 05:23:34 -0000 On Mon, Oct 12, 2015 at 10:47:58PM +0200, Simon Josefsson wrote: > > The following document adds new EdDSA key/signature OIDs directly: > > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 The certificate example seems to contain OID 1.3.101.100.1... Is that intended or should it be 1.3.101.101? IIRC, someone pointed mistake in OIDs before, dunno if that has been corrected. > The following document adds new namedCurve OIDs, thus going indirectly > through the existing ECDSA 3279 route: > > https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 I think this approach is unsuitable for signature keys, but it would be suitable for X25519/X448 DH public keys, which some people apparently have been requesting (IiRC, I have heard requests for that, don't remember from whom).. And AFAICT, those keys don't have associated hashes, and such public keys should be marked for DH only (1.3.132.1.12). > These two drafts take different approaches to including the new curves > into PKIX, and currently both lack applicability statements. There is > potential for overlap and conflict right now. It recently came up that > for PKCS#11 a namedCurve approach would be useful, but for normal PKIX > Certificates, it may be that the first direct approach is preferrable. > The former lack the possibility of encoding keys for DH. I believe each > approach can be useful on its own, but we need to include text adressing > use-cases that can be resolved by both documents to avoid conflicts. IMO, new algorithm is more suited for signature keys, whereas new curve is more suited for DH public keys. This is because there is currently no way to designate correct algorithm for signatures[1], whereas there is for DH, so one just needs to designate correct curve. [1] ECDSA uses "unrestricted", which has been implicated in TLS ECDH KCI MITM attack (equivalent attack doesn't work for "discrete" DH because signature keys are distinct from DH keys). -Ilari From nobody Tue Oct 13 02:12:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA021A3B9F for ; Tue, 13 Oct 2015 02:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: 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-j3PylAHHTp for ; Tue, 13 Oct 2015 02:12:49 -0700 (PDT) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id DBAD61A21B7 for ; Tue, 13 Oct 2015 02:12:48 -0700 (PDT) Received: from [10.196.1.6] (unknown [104.238.169.119]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 434FC18004D9 for ; Tue, 13 Oct 2015 10:12:46 +0100 (BST) To: "tls@ietf.org" References: <560BB34F.4070201@openssl.org> <560BB416.10602@baggins.org> From: Matt Caswell Message-ID: <561CCB0D.6020506@baggins.org> Date: Tue, 13 Oct 2015 10:12:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <560BB416.10602@baggins.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Oct 2015 09:12:51 -0000 Hello, Does anyone have any views on the below? Thanks Matt On 30/09/15 11:06, Matt Caswell wrote: > Hi all > > I have a question on how to interpret RFC 5246 with regards to the > interleaving of app data and handshake records. > > RFC 5246 (and RFC 4346 before it) contains these words: > > Note: Data of different TLS Record layer content types MAY be > interleaved. Application data is generally of lower precedence for > transmission than other content types. However, records MUST be > delivered to the network in the same order as they are protected by > the record layer. Recipients MUST receive and process interleaved > application layer traffic during handshakes subsequent to the first > one on a connection. > > This wording seems to place no limits whatsoever on when it is valid to > receive app data in the handshake. By the wording in the RFC it would be > valid for app data to be received *after* the ChangeCipherSpec has been > received but *before* the Finished has been processed. > > There is also this wording: > > Note: If a rehandshake occurs while data is flowing on a connection, > the communicating parties may continue to send data using the old > CipherSpec. However, once the ChangeCipherSpec has been sent, the > new CipherSpec MUST be used. The first side to send the > ChangeCipherSpec does not know that the other side has finished > computing the new keying material (e.g., if it has to perform a > time-consuming public key operation). Thus, a small window of time, > during which the recipient must buffer the data, MAY exist. In > practice, with modern machines this interval is likely to be fairly > short. > > I think this means that as soon as the first party sends a CCS, they > must not send any app data until they have received a CCS back - they > must buffer it until the CCS is seen - but on reading it again I'm not > sure! If that were the case then the second party should never expect to > see app data between CCS and Finished. It doesn't tell you anything > about what the first party can expect though, i.e. is the second party > allowed to send app data between the CCS and Finished? > > Finally there is also this: > > A Finished message is always sent immediately after a change > cipher spec message to verify that the key exchange and > authentication processes were successful. > > I suppose this trumps everything else, although as this section is > specifically talking about handshakes you could interpret "immediately" > as applying to the handshake sequence only without saying anything about > interleaved app data records. > > I believe the intention is that app data should not be sent between the > CCS and Finished but the RFC wording is not exactly crystal clear. This > is the interpretation I have taken whilst fixing this OpenSSL bug: > > https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest > > Can some confirm my interpretation is correct? > > Thanks > > Matt > > From nobody Tue Oct 13 07:02:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D2C1B4130 for ; Tue, 13 Oct 2015 07:02:40 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHQDEBDJbEWn for ; Tue, 13 Oct 2015 07:02:37 -0700 (PDT) Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id C0D011B4123 for ; Tue, 13 Oct 2015 07:02:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id 3A7BC432016; Tue, 13 Oct 2015 17:02:33 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id 3mWR-TWcoFgf; Tue, 13 Oct 2015 17:02:33 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 149B65BC01F; Tue, 13 Oct 2015 17:02:33 +0300 (EEST) Date: Tue, 13 Oct 2015 17:02:32 +0300 From: Ilari Liusvaara To: Matt Caswell Message-ID: <20151013140232.GB19414@LK-Perkele-V2.elisa-laajakaista.fi> References: <560BB34F.4070201@openssl.org> <560BB416.10602@baggins.org> <561CCB0D.6020506@baggins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <561CCB0D.6020506@baggins.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Oct 2015 14:02:41 -0000 On Tue, Oct 13, 2015 at 10:12:45AM +0100, Matt Caswell wrote: > > On 30/09/15 11:06, Matt Caswell wrote: > > Hi all > > > > I have a question on how to interpret RFC 5246 with regards to the > > interleaving of app data and handshake records. > > Hello, > > Does anyone have any views on the below? Well, my interpretation (can be totally off-base) is that application data can be interleaved with renegotiation, except between ChangeCipherSpec and Finished, which always appear back to back. My reading of that buffering thing was that in some conditions the receiver needs to buffer as it is receiving traffic it hasn't computed the decryption keys for (as the DH/key derivation is in progress). -Ilari From nobody Tue Oct 13 07:44:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625F81B44FA for ; Tue, 13 Oct 2015 07:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5q5kcteX1ZV for ; Tue, 13 Oct 2015 07:44:11 -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 CF9FB1B44E8 for ; Tue, 13 Oct 2015 07:44:05 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 750D84334ED; Tue, 13 Oct 2015 14:44:04 +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 5EF884334E7; Tue, 13 Oct 2015 14:44:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444747444; bh=ynS0EFKi34d9Z6l3gFzgwwyek/ZuqXHktBK0ajR2o+E=; l=1591; h=To:References:Cc:From:Date:In-Reply-To:From; b=DOcsY6EmL9/WTJ7AABXZ2B+xaLdWXhgrEdDMGDtCgjmKCQTGVi1tgAPFktQRIA1Qa fglJNdtCXFf9TeKqBt3r7wCaCpE9dsKUSNCNOWysqxBM9UA+RjLBJD3iLGWWWp5lGQ UflPl46LmuC1FjVXUi1Z4lS59T+h26TI368GGsLM= 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 25DCC2027; Tue, 13 Oct 2015 14:44:04 +0000 (GMT) To: Rick van Rein References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> <561C39FB.6060206@akamai.com> <561C78D6.9030405@openfortress.nl> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <561D18B3.4020702@akamai.com> Date: Tue, 13 Oct 2015 09:44:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561C78D6.9030405@openfortress.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Oct 2015 14:44:13 -0000 On 10/12/2015 10:21 PM, Rick van Rein wrote: > Hello Benjamin, > >> This would seem to require an application protocol doing some Kerberos >> exchanges up front to establish the Kerberos session key before pivoting >> into TLS-PSK in a STARTLS-esque fashion. If that's what the application >> protocol would look like, it seems like there's no reason not to go >> full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides. > GSSAPI is too general IMHO; it specifies an unpredictable number of exchanges > and TLS cannot carry that. There seems to be some miscommunication going on. My comment was in response to the proposal to "just use PSK" with the Kerberos session key as the "pre-shared" secret -- that is, it would be "pre-shared" immediately before initiating the TLS exchange. That would require that the application protocol send some Kerberos messages (so as to get both peers the same session key) before starting up TLS and using a PSK mode with that session key as the shared secret. If the application protocol is going to involve doing some "other stuff" before TLS, there's no reason why that "other stuff" has to be limited to pure Kerberos; multiple hops for a GSS-API exchange is fine for the "other stuff", which is *not* part of the TLS exchange. In your previous message, you (understandably) are resisting that, but I just wanted to make clear that it's just as feasible to run GSS-API to get a PSK to use for TLS as it is to run Kerberos to get a PSK, once the restriction of being part of the TLS exchange is removed. -Ben From nobody Tue Oct 13 08:01:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B1B1B4637 for ; Tue, 13 Oct 2015 08:01:47 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLXPVY3g36EO for ; Tue, 13 Oct 2015 08:01:44 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450: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 A22341B4633 for ; Tue, 13 Oct 2015 08:01:43 -0700 (PDT) Received: by wicge5 with SMTP id ge5so62212034wic.0 for ; Tue, 13 Oct 2015 08:01: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:date:message-id:subject:from:to :cc:content-type; bh=mh4pA36i198R5iKdpaVFtvmA3j88BSnv5H1bxAJpIWg=; b=nbF+FTt8PTuj78At/HoysH1kVsGghIKjUAQ6U5jIzNU3qgCJulG0qSCMvVzVUp0yr4 22vcrdCAjTFfGz1nnA3Qg6HPbOaa9XgJgYcfjie8llx3Q/SiXVN9pyNNyQ5pXI9a5ad2 BGvdBzwNHXKdaMHErhrKPS5XiluDhc4em2dK/E6H4eZJ8fs/y/tqLTnd+6mdJNqxuA0B aA5P5Cnfb573VpXczRQEMTtMAoCxMBvcwWBUzRMv8BKZ70e1aq+fUGNKYnV4dXTTeUE2 iYL586YiS6iDkcfymYINtCUY+7CBmGGEhdjFcW5k0e7X0essSmb6HiNlA7wIYPIeU9yj FnlQ== MIME-Version: 1.0 X-Received: by 10.180.105.135 with SMTP id gm7mr20591979wib.18.1444748502105; Tue, 13 Oct 2015 08:01:42 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Tue, 13 Oct 2015 08:01:42 -0700 (PDT) In-Reply-To: <561CCB0D.6020506@baggins.org> References: <560BB34F.4070201@openssl.org> <560BB416.10602@baggins.org> <561CCB0D.6020506@baggins.org> Date: Tue, 13 Oct 2015 11:01:42 -0400 Message-ID: From: Watson Ladd To: Matt Caswell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Oct 2015 15:01:47 -0000 On Tue, Oct 13, 2015 at 5:12 AM, Matt Caswell wrote: > Hello, > > Does anyone have any views on the below? > > Thanks Yes. I think we need to have a much, much tighter definition of the state machine. This has been a perennial source of bugs and interoperability issues in real world implementations. From nobody Tue Oct 13 08:06:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AE91B4692 for ; Tue, 13 Oct 2015 08:06:49 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwMLPhEfFfcv for ; Tue, 13 Oct 2015 08:06:47 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c: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 553381B468F for ; Tue, 13 Oct 2015 08:06:47 -0700 (PDT) Received: by wijq8 with SMTP id q8so36382323wij.0 for ; Tue, 13 Oct 2015 08:06: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:date:message-id:subject:from:to :cc:content-type; bh=JiyC2nJwzmXY9gEj6Mf2vGlWWUSB4qL9SyfeVsK8ono=; b=sfq2Op14APJhRtJY7DqcJZ9HZue8kO154ujdkykMczO6tPjib+QSwK0LDu55sAekA3 ZpRK5mAI3uWgo27QhuuK0cH+NMGpINcKczbRS+f9uabH5/1GF0e81xh1TxXaer+0b8XM 8JmBFHVVpNoP9+9iZMl0e/OquBVPyigLE1SSCeIgdLMQ92O1y2Pziqqn2bCWJi4SH0Th ea47IFah/RGZXo4XELqFnzKGEDCXXozrNzrCSwBCjuXRs8E824urrU1Ke9LbJcYzNzaL XgqXfQeatHuPk6K/PxAvYRQ0bMFdS6llcWUG11ZuOxp4t2uWAzk6HCJjiJW4wECNMHg5 OPVQ== MIME-Version: 1.0 X-Received: by 10.180.23.231 with SMTP id p7mr22338074wif.30.1444748777021; Tue, 13 Oct 2015 08:06:17 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Tue, 13 Oct 2015 08:06:16 -0700 (PDT) In-Reply-To: <561C39FB.6060206@akamai.com> References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> <561C39FB.6060206@akamai.com> Date: Tue, 13 Oct 2015 11:06:16 -0400 Message-ID: From: Watson Ladd To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Oct 2015 15:06:49 -0000 On Mon, Oct 12, 2015 at 6:53 PM, Benjamin Kaduk wrote: > On 10/11/2015 08:46 AM, Watson Ladd wrote: >> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara >> wrote: >>> Some quick comments: >>> - The signed DH share does not look to be bound to anything (crypto >>> parameters negotiation, randoms, server key exchange, etc..). I can't >>> offhand say what that would lead to, but it looks even worse than >>> TLS ServerKeyExchange, which has known vulernabilities due to >>> lack of binding to things like ciphersuite. >>> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC >>> (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. >>> - Even use of DH is questionable. >> I would suggest piggybacking on the PSK mode, using the key Kerberos >> provides at both ends as the PSK key. This would address all of these >> issues in TLS 1.3 >> > > This would seem to require an application protocol doing some Kerberos > exchanges up front to establish the Kerberos session key before pivoting > into TLS-PSK in a STARTLS-esque fashion. If that's what the application > protocol would look like, it seems like there's no reason not to go > full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides. > > This proposal (as complicated as it is, and I'm not sure that I'm > entirely comfortable with it yet) has the comparative advantage that the > application speaks TLS from the start, with the Kerberos messages > included in the TLS CKE. In that sense, at least, it is elegant. It would (modulo some work by me, which is unlikely to get done) be possible to do this with the PSK-ECDH extension: have the first two messages contain information used to derive the PSK, which is used to authenticate in the same manner in the second round. The problem here is that TLS is not a catchall "Transport Layer Security" capable of taking any sort of desired key exchanges and producing a secure protocol from them, but instead requires a lot of annoying work to ensure the proofs go through. Mike Hamburg has presented Keccak based designs that do do this, and TLS 1.3 by default does a lot better with this. > > This proposal also includes a generic mechanism for the server to > indicate what service type and hostname should be used in constructing > the host-based service principal name for Kerberos, which is useful -- > the convention for that would otherwise have to be baked into the > application protocol. The considerations around client anonymity and a > protocol for the server to convey its expectations are also interesting, > though I'm not sure I would have put it in the -00 if it was my own > document. > > There are some nits in the Kerberos bits that I might mention over on > kitten. > > -Ben > > _______________________________________________ > 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 Wed Oct 14 08:44:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6961ACCE1 for ; Wed, 14 Oct 2015 08:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot9wPEqcDRma for ; Wed, 14 Oct 2015 08:44:04 -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 A289A1ACCDF for ; Wed, 14 Oct 2015 08:44:03 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 000DF2AC55; Wed, 14 Oct 2015 17:44:01 +0200 (CEST) X-purgate-ID: 152705::1444837442-00001EB9-A701F08D/0/0 X-purgate-size: 3669 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 mail05.wdf.sap.corp (Postfix) with ESMTP id E6DE240498; Wed, 14 Oct 2015 17:44:01 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id DF1401A2E6; Wed, 14 Oct 2015 17:44:01 +0200 (CEST) In-Reply-To: <561CCB0D.6020506@baggins.org> To: Matt Caswell Date: Wed, 14 Oct 2015 17:44:01 +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: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2015 15:44:08 -0000 Matt Caswell wrote: > > Does anyone have any views on the below? Yup. Interleaving application & handshake records is a highly dangerous idea (and fortunately some TLS implementations will abort if you try). http://www.ietf.org/mail-archive/web/tls/current/msg07648.html http://www.ietf.org/mail-archive/web/tls/current/msg09743.html -Martin > On 30/09/15 11:06, Matt Caswell wrote: > > Hi all > > > > I have a question on how to interpret RFC 5246 with regards to the > > interleaving of app data and handshake records. > > > > RFC 5246 (and RFC 4346 before it) contains these words: > > > > Note: Data of different TLS Record layer content types MAY be > > interleaved. Application data is generally of lower precedence for > > transmission than other content types. However, records MUST be > > delivered to the network in the same order as they are protected by > > the record layer. Recipients MUST receive and process interleaved > > application layer traffic during handshakes subsequent to the first > > one on a connection. > > > > This wording seems to place no limits whatsoever on when it is valid to > > receive app data in the handshake. By the wording in the RFC it would be > > valid for app data to be received *after* the ChangeCipherSpec has been > > received but *before* the Finished has been processed. > > > > There is also this wording: > > > > Note: If a rehandshake occurs while data is flowing on a connection, > > the communicating parties may continue to send data using the old > > CipherSpec. However, once the ChangeCipherSpec has been sent, the > > new CipherSpec MUST be used. The first side to send the > > ChangeCipherSpec does not know that the other side has finished > > computing the new keying material (e.g., if it has to perform a > > time-consuming public key operation). Thus, a small window of time, > > during which the recipient must buffer the data, MAY exist. In > > practice, with modern machines this interval is likely to be fairly > > short. > > > > I think this means that as soon as the first party sends a CCS, they > > must not send any app data until they have received a CCS back - they > > must buffer it until the CCS is seen - but on reading it again I'm not > > sure! If that were the case then the second party should never expect to > > see app data between CCS and Finished. It doesn't tell you anything > > about what the first party can expect though, i.e. is the second party > > allowed to send app data between the CCS and Finished? > > > > Finally there is also this: > > > > A Finished message is always sent immediately after a change > > cipher spec message to verify that the key exchange and > > authentication processes were successful. > > > > I suppose this trumps everything else, although as this section is > > specifically talking about handshakes you could interpret "immediately" > > as applying to the handshake sequence only without saying anything about > > interleaved app data records. > > > > I believe the intention is that app data should not be sent between the > > CCS and Finished but the RFC wording is not exactly crystal clear. This > > is the interpretation I have taken whilst fixing this OpenSSL bug: > > > > https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest > > > > Can some confirm my interpretation is correct? > > > > Thanks > > > > Matt > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Oct 14 13:05:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9B31A6F3A for ; Wed, 14 Oct 2015 13:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiF2jqBp73M0 for ; Wed, 14 Oct 2015 13:05:07 -0700 (PDT) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id AB8EF1A1BCD for ; Wed, 14 Oct 2015 13:05:06 -0700 (PDT) Received: from [10.184.1.6] (unknown [104.238.169.130]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 2A33C180041E; Wed, 14 Oct 2015 21:05:00 +0100 (BST) To: mrex@sap.com References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> From: Matt Caswell Message-ID: <561EB56B.9050308@baggins.org> Date: Wed, 14 Oct 2015 21:04:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Oct 2015 20:05:10 -0000 On 14/10/15 16:44, Martin Rex wrote: > Matt Caswell wrote: >> >> Does anyone have any views on the below? > > Yup. Interleaving application & handshake records is a > highly dangerous idea (and fortunately some TLS implementations > will abort if you try). > > http://www.ietf.org/mail-archive/web/tls/current/msg07648.html > > http://www.ietf.org/mail-archive/web/tls/current/msg09743.html > > So is your recommendation that we should ignore the RFC and prevent interleaving at all? The current OpenSSL behaviour is to abort, but this is causing an interoperability problem. Since the RFC is clear that OpenSSL is in the wrong we were seeking to fix it. Matt > -Martin > >> On 30/09/15 11:06, Matt Caswell wrote: >>> Hi all >>> >>> I have a question on how to interpret RFC 5246 with regards to the >>> interleaving of app data and handshake records. >>> >>> RFC 5246 (and RFC 4346 before it) contains these words: >>> >>> Note: Data of different TLS Record layer content types MAY be >>> interleaved. Application data is generally of lower precedence for >>> transmission than other content types. However, records MUST be >>> delivered to the network in the same order as they are protected by >>> the record layer. Recipients MUST receive and process interleaved >>> application layer traffic during handshakes subsequent to the first >>> one on a connection. >>> >>> This wording seems to place no limits whatsoever on when it is valid to >>> receive app data in the handshake. By the wording in the RFC it would be >>> valid for app data to be received *after* the ChangeCipherSpec has been >>> received but *before* the Finished has been processed. >>> >>> There is also this wording: >>> >>> Note: If a rehandshake occurs while data is flowing on a connection, >>> the communicating parties may continue to send data using the old >>> CipherSpec. However, once the ChangeCipherSpec has been sent, the >>> new CipherSpec MUST be used. The first side to send the >>> ChangeCipherSpec does not know that the other side has finished >>> computing the new keying material (e.g., if it has to perform a >>> time-consuming public key operation). Thus, a small window of time, >>> during which the recipient must buffer the data, MAY exist. In >>> practice, with modern machines this interval is likely to be fairly >>> short. >>> >>> I think this means that as soon as the first party sends a CCS, they >>> must not send any app data until they have received a CCS back - they >>> must buffer it until the CCS is seen - but on reading it again I'm not >>> sure! If that were the case then the second party should never expect to >>> see app data between CCS and Finished. It doesn't tell you anything >>> about what the first party can expect though, i.e. is the second party >>> allowed to send app data between the CCS and Finished? >>> >>> Finally there is also this: >>> >>> A Finished message is always sent immediately after a change >>> cipher spec message to verify that the key exchange and >>> authentication processes were successful. >>> >>> I suppose this trumps everything else, although as this section is >>> specifically talking about handshakes you could interpret "immediately" >>> as applying to the handshake sequence only without saying anything about >>> interleaved app data records. >>> >>> I believe the intention is that app data should not be sent between the >>> CCS and Finished but the RFC wording is not exactly crystal clear. This >>> is the interpretation I have taken whilst fixing this OpenSSL bug: >>> >>> https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest >>> >>> Can some confirm my interpretation is correct? >>> >>> Thanks >>> >>> Matt >>> >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Wed Oct 14 13:30:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDADC1A86F5 for ; Wed, 14 Oct 2015 13:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 xHQH5NkTEvTB for ; Wed, 14 Oct 2015 13:30:07 -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 6B6791A7000 for ; Wed, 14 Oct 2015 13:30:07 -0700 (PDT) Received: by iofl186 with SMTP id l186so68706385iof.2 for ; Wed, 14 Oct 2015 13:30:06 -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:content-type; bh=cuUKeLtyd+nPSD0IKnfIZ+wALH379ebQk1BP8GoOGVQ=; b=kE8xSkJ8EFIZr73CJ1gZbMZC0Pwqef6Q2rpAPjXR9tdSsaNm0MqGfNc3S0N5VCU0AK DhbhgQ7KeKvqvzNN823zeDqQ+vRb6thzL/b6R64zyVkW16KUJi2xutUJVOClituQx1Al 2Xi5XbI02wIrWxKVCpBr30tDBfsgfLailN3GI= 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:content-type; bh=cuUKeLtyd+nPSD0IKnfIZ+wALH379ebQk1BP8GoOGVQ=; b=aOrLzu0pDW2YaRt2xWYvG5M+Eecx/6LQaFbBb14aYIpYrI/1+1dAnnS8VvWF3TU6Xw VpeBSEoBsZ3FcQO8Pa9/hKLNgqnJns8LJFOiI63thOmErm6AGp9StMuXQqXgurQwoBZx 2fTqNR/vmtnNCTwiYumuHeyC4SQBTCDJ7ARMLN6UHR9B3uexE0DX5T5/H68H+lCyEkwo TUqzKBvVl8qxviLiyAtPJsi+A3CaFnkKC0pMxT7tte84ZXpTiGw14W2FnBs5c41/rH78 A3epyDwpbRVHpwB0aT6YCMNVXoDpO+RnhJSly9SaNaaFcqWl0y6UIgrjxAg0tTSewiuv WSQw== X-Gm-Message-State: ALoCoQmAO+6ACC5YkYmBFN6MikFRFJx99ri+iK8ohNqo6sSZ1ohcyrq5L4EVJqkfJ5QM33ZNG5TO X-Received: by 10.107.34.207 with SMTP id i198mr6282935ioi.2.1444854606687; Wed, 14 Oct 2015 13:30:06 -0700 (PDT) MIME-Version: 1.0 References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> <561EB56B.9050308@baggins.org> In-Reply-To: <561EB56B.9050308@baggins.org> From: David Benjamin Date: Wed, 14 Oct 2015 20:29:57 +0000 Message-ID: To: Matt Caswell , mrex@sap.com Content-Type: multipart/alternative; boundary=001a11403e2495df970522166d14 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Oct 2015 20:30:10 -0000 --001a11403e2495df970522166d14 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 14, 2015 at 4:05 PM Matt Caswell wrote: > On 14/10/15 16:44, Martin Rex wrote: > > Matt Caswell wrote: > >> > >> Does anyone have any views on the below? > > > > Yup. Interleaving application & handshake records is a > > highly dangerous idea (and fortunately some TLS implementations > > will abort if you try). > > > > http://www.ietf.org/mail-archive/web/tls/current/msg07648.html > > > > http://www.ietf.org/mail-archive/web/tls/current/msg09743.html > > > > > > So is your recommendation that we should ignore the RFC and prevent > interleaving at all? The current OpenSSL behaviour is to abort, but this > is causing an interoperability problem. Since the RFC is clear that > OpenSSL is in the wrong we were seeking to fix it. > BoringSSL doesn't allow application/handshake interleave under any circumstances and further requires that renegotiate be server-initiated and at a quiescent point in the application protocol. That is, a point where the client is done writing and will not write more until receiving more data from the server, like between an HTTP/1.1 request and response. This avoids a ton of complexity and state-space explosion. (OpenSSL's in_read_app_data = 2 and the interaction with in_handshake are terrifying.) It's meant to be the bare minimum needed to support the legacy renego/client-auth mistake for unpipelined HTTP/1.1 as a client and nothing more. It's been shipping in Chrome for a while now and I've never had a report of breakage. But I also don't have to deal with the particular interop situation you came across, so this approach may not work as well for OpenSSL. If you really absolutely must support interleave and can't avoid it, I think it being allowed everywhere except between CCS and Finished is probably the closest you can get to coherent semantics. "Coherent" here is, of course, all relative since renego is involved. David Matt > > > > -Martin > > > >> On 30/09/15 11:06, Matt Caswell wrote: > >>> Hi all > >>> > >>> I have a question on how to interpret RFC 5246 with regards to the > >>> interleaving of app data and handshake records. > >>> > >>> RFC 5246 (and RFC 4346 before it) contains these words: > >>> > >>> Note: Data of different TLS Record layer content types MAY be > >>> interleaved. Application data is generally of lower precedence for > >>> transmission than other content types. However, records MUST be > >>> delivered to the network in the same order as they are protected by > >>> the record layer. Recipients MUST receive and process interleaved > >>> application layer traffic during handshakes subsequent to the first > >>> one on a connection. > >>> > >>> This wording seems to place no limits whatsoever on when it is valid to > >>> receive app data in the handshake. By the wording in the RFC it would > be > >>> valid for app data to be received *after* the ChangeCipherSpec has been > >>> received but *before* the Finished has been processed. > >>> > >>> There is also this wording: > >>> > >>> Note: If a rehandshake occurs while data is flowing on a connection, > >>> the communicating parties may continue to send data using the old > >>> CipherSpec. However, once the ChangeCipherSpec has been sent, the > >>> new CipherSpec MUST be used. The first side to send the > >>> ChangeCipherSpec does not know that the other side has finished > >>> computing the new keying material (e.g., if it has to perform a > >>> time-consuming public key operation). Thus, a small window of time, > >>> during which the recipient must buffer the data, MAY exist. In > >>> practice, with modern machines this interval is likely to be fairly > >>> short. > >>> > >>> I think this means that as soon as the first party sends a CCS, they > >>> must not send any app data until they have received a CCS back - they > >>> must buffer it until the CCS is seen - but on reading it again I'm not > >>> sure! If that were the case then the second party should never expect > to > >>> see app data between CCS and Finished. It doesn't tell you anything > >>> about what the first party can expect though, i.e. is the second party > >>> allowed to send app data between the CCS and Finished? > >>> > >>> Finally there is also this: > >>> > >>> A Finished message is always sent immediately after a change > >>> cipher spec message to verify that the key exchange and > >>> authentication processes were successful. > >>> > >>> I suppose this trumps everything else, although as this section is > >>> specifically talking about handshakes you could interpret "immediately" > >>> as applying to the handshake sequence only without saying anything > about > >>> interleaved app data records. > >>> > >>> I believe the intention is that app data should not be sent between the > >>> CCS and Finished but the RFC wording is not exactly crystal clear. This > >>> is the interpretation I have taken whilst fixing this OpenSSL bug: > >>> > >>> > https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest > >>> > >>> Can some confirm my interpretation is correct? > >>> > >>> Thanks > >>> > >>> Matt > >>> > >>> > >> > >> _______________________________________________ > >> 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 > --001a11403e2495df970522166d14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 14= , 2015 at 4:05 PM Matt Caswell <frodo@baggins.org> wrote:
On 14/10/15 16:44, Martin Rex wrote:
> Matt Caswell wrote:
>>
>> Does anyone have any views on the below?
>
> Yup.=C2=A0 Interleaving application & handshake records is a
> highly dangerous idea (and fortunately some TLS implementations
> will abort if you try).
>
> http://www.ietf.org/mail-archive/= web/tls/current/msg07648.html
>
> http://www.ietf.org/mail-archive/= web/tls/current/msg09743.html
>
>

So is your recommendation that we should ignore the RFC and prevent
interleaving at all? The current OpenSSL behaviour is to abort, but this is causing an interoperability problem. Since the RFC is clear that
OpenSSL is in the wrong we were seeking to fix it.
BoringSSL doe= sn't allow application/handshake interleave under any circumstances and= further requires that renegotiate be server-initiated and at a quiescent p= oint in the application protocol. That is, a point where the client is done= writing and will not write more until receiving more data from the server,= like between an HTTP/1.1 request and response. This avoids a ton of comple= xity and state-space explosion. (OpenSSL's in_read_app_data =3D 2 and t= he interaction with in_handshake are terrifying.) It's meant to be the = bare minimum needed to support the legacy renego/client-auth mistake for un= pipelined HTTP/1.1 as a client and nothing more.

I= t's been shipping in Chrome for a while now and I've never had a re= port of breakage. But I also don't have to deal with the particular int= erop situation you came across, so this approach may not work as well for O= penSSL.

If you really absolutely must support inte= rleave and can't avoid it, I think it being allowed everywhere except b= etween CCS and Finished is probably the closest you can get to coherent sem= antics. "Coherent" here is, of course, all relative since renego = is involved.
<= div>
David


Matt


> -Martin
>
>> On 30/09/15 11:06, Matt Caswell wrote:
>>> Hi all
>>>
>>> I have a question on how to interpret RFC 5246 with regards to= the
>>> interleaving of app data and handshake records.
>>>
>>> RFC 5246 (and RFC 4346 before it) contains these words:
>>>
>>>=C2=A0 =C2=A0 Note: Data of different TLS Record layer content = types MAY be
>>>=C2=A0 =C2=A0 interleaved.=C2=A0 Application data is generally = of lower precedence for
>>>=C2=A0 =C2=A0 transmission than other content types.=C2=A0 Howe= ver, records MUST be
>>>=C2=A0 =C2=A0 delivered to the network in the same order as the= y are protected by
>>>=C2=A0 =C2=A0 the record layer.=C2=A0 Recipients MUST receive a= nd process interleaved
>>>=C2=A0 =C2=A0 application layer traffic during handshakes subse= quent to the first
>>>=C2=A0 =C2=A0 one on a connection.
>>>
>>> This wording seems to place no limits whatsoever on when it is= valid to
>>> receive app data in the handshake. By the wording in the RFC i= t would be
>>> valid for app data to be received *after* the ChangeCipherSpec= has been
>>> received but *before* the Finished has been processed.
>>>
>>> There is also this wording:
>>>
>>>=C2=A0 =C2=A0 Note: If a rehandshake occurs while data is flowi= ng on a connection,
>>>=C2=A0 =C2=A0 the communicating parties may continue to send da= ta using the old
>>>=C2=A0 =C2=A0 CipherSpec.=C2=A0 However, once the ChangeCipherS= pec has been sent, the
>>>=C2=A0 =C2=A0 new CipherSpec MUST be used.=C2=A0 The first side= to send the
>>>=C2=A0 =C2=A0 ChangeCipherSpec does not know that the other sid= e has finished
>>>=C2=A0 =C2=A0 computing the new keying material (e.g., if it ha= s to perform a
>>>=C2=A0 =C2=A0 time-consuming public key operation).=C2=A0 Thus,= a small window of time,
>>>=C2=A0 =C2=A0 during which the recipient must buffer the data, = MAY exist.=C2=A0 In
>>>=C2=A0 =C2=A0 practice, with modern machines this interval is l= ikely to be fairly
>>>=C2=A0 =C2=A0 short.
>>>
>>> I think this means that as soon as the first party sends a CCS= , they
>>> must not send any app data until they have received a CCS back= - they
>>> must buffer it until the CCS is seen - but on reading it again= I'm not
>>> sure! If that were the case then the second party should never= expect to
>>> see app data between CCS and Finished. It doesn't tell you= anything
>>> about what the first party can expect though, i.e. is the seco= nd party
>>> allowed to send app data between the CCS and Finished?
>>>
>>> Finally there is also this:
>>>
>>>=C2=A0 =C2=A0 A Finished message is always sent immediately aft= er a change
>>>=C2=A0 =C2=A0 cipher spec message to verify that the key exchan= ge and
>>>=C2=A0 =C2=A0 authentication processes were successful.
>>>
>>> I suppose this trumps everything else, although as this sectio= n is
>>> specifically talking about handshakes you could interpret &quo= t;immediately"
>>> as applying to the handshake sequence only without saying anyt= hing about
>>> interleaved app data records.
>>>
>>> I believe the intention is that app data should not be sent be= tween the
>>> CCS and Finished but the RFC wording is not exactly crystal cl= ear. This
>>> is the interpretation I have taken whilst fixing this OpenSSL = bug:
>>>
>>> h= ttps://rt.openssl.org/Ticket/Display.html?id=3D3712&user=3Dguest&pa= ss=3Dguest
>>>
>>> Can some confirm my interpretation is correct?
>>>
>>> Thanks
>>>
>>> Matt
>>>
>>>
>>
>> _______________________________________________
>> 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
--001a11403e2495df970522166d14-- From nobody Wed Oct 14 13:36:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F891A873D for ; Wed, 14 Oct 2015 13:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulkHFbgP0QtA for ; Wed, 14 Oct 2015 13:36:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A5B1A873B for ; Wed, 14 Oct 2015 13:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fA9n864dC2PQEvQAdP25OsVlGS8Jqdk9dcqBDiyfCck=; b=nTnaVBzo7MzfeKSjp6gCj3Bn9HddMdan+QLvg3Yy2QS6us0nKJbNP53GNBJPy9TJD8hAJkNswBnUoSJh5+gyXWxp8Ris9rFiebqDtY2ZXZZ+juMvvQaKs9/hSf3/IWpceMVnvTjQIlZcrjMaoDQ+8ZH9xfKAGYmKb7txZRypQfU= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 14 Oct 2015 20:36:31 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0293.007; Wed, 14 Oct 2015 20:36:31 +0000 From: Andrei Popov To: "'tls@ietf.org'" Thread-Topic: PR #290: Removing certificate_types and adding certificate_extensions Thread-Index: AdEGvkcWCUPX/ZnAT+KfrtOmU8gMdA== Date: Wed, 14 Oct 2015 20:36:31 +0000 Message-ID: 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:2::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:4/iXb0AIDcbSzR4C4jIXW/Fqs/6nnkpw7xygkzdwuqLaVxVPSuSegxuUwISVgEghwhtK4xDhZy2GqK4diRu8liESdVrIRcSdnwKvLPjhLk4gSB1ab4PArFqUuv6f0p513NdZknw8EidxoD7to3B9hA==; 24:KmtTLNN0p65xD7MKwC2OCSS40nx623okQT9bsglfE+JPLpozHEAitWuNblXhvhWlqDJ+l/lYejBGVUedZxqBwkTnD2yAQLHzsjaqyXNbgnc=; 20:VEF7CkyQI9/GPMM70d4GcCK9exCedprl5nfvO0ZHgfZQ9HHZXdYIFULZYm8Rf4+xSrHHiB5EZ7YxmO8XH2KMaw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671)(42673675456677)(83020558694031); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(61426024)(61427024); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(189002)(199003)(19625215002)(19617315012)(54356999)(189998001)(19580395003)(16236675004)(76576001)(229853001)(33656002)(87936001)(46102003)(106356001)(99286002)(110136002)(5007970100001)(5003600100002)(40100003)(101416001)(50986999)(2900100001)(64706001)(107886002)(5005710100001)(86362001)(450100001)(105586002)(10290500002)(19300405004)(102836002)(92566002)(5002640100001)(11100500001)(5004730100002)(10400500002)(81156007)(5001960100002)(74316001)(97736004)(77096005)(15975445007)(86612001)(5008740100001)(122556002)(8990500004)(10090500001)(3826002)(491001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396EB7C5BD75D98D4EE68A88C3F0BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2015 20:36:31.5667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Subject: [TLS] PR #290: Removing certificate_types and adding certificate_extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Oct 2015 20:36:36 -0000 --_000_BLUPR03MB1396EB7C5BD75D98D4EE68A88C3F0BLUPR03MB1396namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As discussed at the Interim, I've submitted a separate PR for TLS 1.3 Certi= ficateRequest changes: https://github.com/tlswg/tls13-spec/pull/290 PR #290 includes the following changes: 1. Removes certificate_types, which are no longer needed. 2. Adds client cert selection by certificate extension values. This helps m= ake CertificateRequest more specific and reduce the need for the confusing = "choose a certificate" UI. Suggested text includes specific matching rules for KU and EKU extensions (= these are most commonly asked for by the customers). Please review, Cheers, Andrei --_000_BLUPR03MB1396EB7C5BD75D98D4EE68A88C3F0BLUPR03MB1396namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As discussed at the Interim, I’ve submitted a = separate PR for TLS 1.3 CertificateRequest changes: https://github.com= /tlswg/tls13-spec/pull/290

 

PR #290 includes the following changes:

1. Removes certificate_types, which are no longer ne= eded.

2. Adds client cert selection by certificate extensi= on values. This helps make CertificateRequest more specific and reduce the = need for the confusing "choose a certificate" UI.

 

Suggested text includes specific matching rules for = KU and EKU extensions (these are most commonly asked for by the customers).=

 

Please review,

 

Cheers,

 

Andrei

--_000_BLUPR03MB1396EB7C5BD75D98D4EE68A88C3F0BLUPR03MB1396namp_-- From nobody Wed Oct 14 13:42:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D421A882B for ; Wed, 14 Oct 2015 13:42:51 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScCeQZX887Zc for ; Wed, 14 Oct 2015 13:42:50 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002: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 350451A87F2 for ; Wed, 14 Oct 2015 13:42:50 -0700 (PDT) Received: by ykoo7 with SMTP id o7so59338206yko.0 for ; Wed, 14 Oct 2015 13:42: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:date:message-id:subject:from:to :cc:content-type; bh=ccpfbyte+WyxeNtNP8hA5UBTG5wsNdjpbqbl6+xFp34=; b=tqjSfaA/vD60gmM3rgrJ+G45m28XBscaaZ1My00oADjVBRKBlQvS61k0UhX4rfnpMV Hun1KxvWekRp3rMhgSxGD22iWAjZvsA0Z3X5M3INVCncUyqV1RXf2vre2e+Vvdp6yWUC i+erc9V32HT+linL4EDOpKnF7zGDulMO7iIx52ulUOMm3YDBhRLlxs3z2TRwIF2h2s3g vx9KBOy/WMe7Jo17Bntm+JI1BQeQip1TDeu9Sp2Lz+GIoJzpWMlVD9BCaRfAzKYuwMLp 0/r01hKR8VZLJs9aOGIAViD1K/TCtU2hBKzbhOWkWm7O/CwlxjWhYxnf935vVqnD+FpP qcDw== MIME-Version: 1.0 X-Received: by 10.13.196.196 with SMTP id g187mr4385708ywd.98.1444855369478; Wed, 14 Oct 2015 13:42:49 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Wed, 14 Oct 2015 13:42:49 -0700 (PDT) In-Reply-To: References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> <561EB56B.9050308@baggins.org> Date: Wed, 14 Oct 2015 13:42:49 -0700 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Oct 2015 20:42:51 -0000 On 14 October 2015 at 13:29, David Benjamin wrote: > If you really absolutely must support interleave and can't avoid it, I think > it being allowed everywhere except between CCS and Finished is probably the > closest you can get to coherent semantics. "Coherent" here is, of course, > all relative since renego is involved. I think that it needs to be more than that. I would say: 1. You should not interleave data with handshake messages from the same flight. 2. You should not report any change to handshake status until the renegotiation is complete. That means no callbacks/events about new peer certificates, or anything of that nature until you have received and validated the Finished. You would have to exercise caution here for the callbacks that are necessary during the process, like the "please choose a certificate and private key to use" callback on either side. If you can somehow manage to do all of that, then you might be able get away with not halting progress entirely. Because - as far as the application is concerned - application data is sent as though it were before the renegotiation. In essence, you are keeping the application ignorant of any changes until the whole process is over. I've heard it recommended that you add other stipulations, such as 3. The server cannot change certificate. I'm ambivalent on that because I don't believe it to materially change the security properties (assuming that we have a good handshake, i.e., at least R-I and session hash). I don't have proof of that, of course. From nobody Wed Oct 14 14:10:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0921A8937 for ; Wed, 14 Oct 2015 14:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 i8nnL9mgYTP5 for ; Wed, 14 Oct 2015 14:10:26 -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 D41131A8928 for ; Wed, 14 Oct 2015 14:10:24 -0700 (PDT) Received: by ioii196 with SMTP id i196so69353068ioi.3 for ; Wed, 14 Oct 2015 14:10: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:content-type; bh=qp3JZPc/xDlaQifADZBUy1+XA7rOF+Rl9T5kT7XTi/c=; b=DBcTDM34AkIjgE4Pa/Zl2FFN9O/3dA2pHfx73O9ufHmfiC/eGK1bZzRPZcbi+lM3JB WWBIsOdnggTKWUIhknVI5X369cVj5tslyvptqdAlNE+H5j17D4bnL/Z4/qKTcUS55cPt xEgcvZh4CQtvtWYUXdZnw7IRPsbi147h9//c8= 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:content-type; bh=qp3JZPc/xDlaQifADZBUy1+XA7rOF+Rl9T5kT7XTi/c=; b=PbJAbW6ZD1w8IPXXQ8YdGaxYjgMEZ2Ivwb6ut8wBd/J4plXElk3QY9CdNf/N0A61it OcgpL/CT8zNnKSCNEpr7QLLadeT9XkqYyUySh5IDq72U5a8hj1Rnv2yNuZidhCdRaIE+ /ohiJra3HeXpizqmDrCgQl/daaloAjAMfmEU4jgIObRDE6s2e4erTfFh7TK7ts2pbRlH vZO76bXropckYAEIaj0H2E6+WcKTcaQOc+C3jj3o5rv2iJRuBf5kpuUkUbvslM0a1HEM 1kaS9sWnBYjV7JsFUNDu1RzcqIjalI2kbrJBKuRw8yyixmdApFzd2E9bN/FvUEkn4p6l 8MqA== X-Gm-Message-State: ALoCoQkdLlDHIy5uNqsicQV0pesJzZEv9zC1jW3FG9JjN3lZAOCzny3tkdSiJzKXTEQiWF61S95V X-Received: by 10.107.136.216 with SMTP id s85mr3309252ioi.142.1444857024164; Wed, 14 Oct 2015 14:10:24 -0700 (PDT) MIME-Version: 1.0 References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> <561EB56B.9050308@baggins.org> In-Reply-To: From: David Benjamin Date: Wed, 14 Oct 2015 21:10:14 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113ec0caad6b79052216fd71 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Oct 2015 21:10:27 -0000 --001a113ec0caad6b79052216fd71 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 14, 2015 at 4:42 PM Martin Thomson wrote: > On 14 October 2015 at 13:29, David Benjamin wrote: > > If you really absolutely must support interleave and can't avoid it, I > think > > it being allowed everywhere except between CCS and Finished is probably > the > > closest you can get to coherent semantics. "Coherent" here is, of course, > > all relative since renego is involved. > > I think that it needs to be more than that. I would say: > > 1. You should not interleave data with handshake messages from the same > flight. > 2. You should not report any change to handshake status until the > renegotiation is complete. That means no callbacks/events about new > peer certificates, or anything of that nature until you have received > and validated the Finished. You would have to exercise caution here > for the callbacks that are necessary during the process, like the > "please choose a certificate and private key to use" callback on > either side. > > If you can somehow manage to do all of that, then you might be able > get away with not halting progress entirely. Because - as far as the > application is concerned - application data is sent as though it were > before the renegotiation. In essence, you are keeping the application > ignorant of any changes until the whole process is over. > Indeed. This is, IMO, one of the core reasons renegotiation was a horrible mistake and one we should make sure never to repeat in the future. :-) I didn't mention it since it's more an API concern than what's over the wire, but that certainly doesn't make it any less a problem! What renego even means for the application data is extremely weird. A lot of TLS APIs and implementations I've seen don't do a very good job of scoping their private state or even public APIs properly, so it's very unclear what, say, querying the peer certificate even means at various points mid-renego. (Mid-initial-handshake is weird too, but most consumers are sensible enough not to query such stuff while some abstract "connect" operation is still going on.) This is especially problematic because handling renegotiations transparently seems a fairly popular implementation strategy. (Both NSS and OpenSSL do this. OpenSSL even allows them by default and doesn't have a good way to turn them off. Not sure about NSS. BoringSSL makes it opt-in.) Above all, by far the best way to handle renegotiation is "never do it, period". I think it's most important that any attempt to hammer down semantics in the "we already got it wrong" cases should be clear on this. New protocols should implicitly forbid renego, implementations should turn it off by default, and that at least gives a bounded body of existing mistakes to consider. David > I've heard it recommended that you add other stipulations, such as > > 3. The server cannot change certificate. > > I'm ambivalent on that because I don't believe it to materially change > the security properties (assuming that we have a good handshake, i.e., > at least R-I and session hash). I don't have proof of that, of > course. > --001a113ec0caad6b79052216fd71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 14= , 2015 at 4:42 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 14 October 2015 at 13:29, David Benjamin &l= t;davidben@chrom= ium.org> wrote:
> If you really absolutely must support interleave and can't avoid i= t, I think
> it being allowed everywhere except between CCS and Finished is probabl= y the
> closest you can get to coherent semantics. "Coherent" here i= s, of course,
> all relative since renego is involved.

I think that it needs to be more than that.=C2=A0 I would say:

1. You should not interleave data with handshake messages from the same fli= ght.
2. You should not report any change to handshake status until the
renegotiation is complete.=C2=A0 That means no callbacks/events about new peer certificates, or anything of that nature until you have received
and validated the Finished.=C2=A0 You would have to exercise caution here for the callbacks that are necessary during the process, like the
"please choose a certificate and private key to use" callback on<= br> either side.

If you can somehow manage to do all of that, then you might be able
get away with not halting progress entirely.=C2=A0 Because - as far as the<= br> application is concerned - application data is sent as though it were
before the renegotiation.=C2=A0 In essence, you are keeping the application=
ignorant of any changes until the whole process is over.

In= deed. This is, IMO, one of the core reasons renegotiation was a horrible mi= stake and one we should make sure never to repeat in the future. :-) I didn= 't mention it since it's more an API concern than what's over t= he wire, but that certainly doesn't make it any less a problem! What re= nego even means for the application data is extremely weird. A lot of TLS A= PIs and implementations I've seen don't do a very good job of scopi= ng their private state or even public APIs properly, so it's very uncle= ar what, say, querying the peer certificate even means at various points mi= d-renego. (Mid-initial-handshake is weird too, but most consumers are sensi= ble enough not to query such stuff while some abstract "connect" = operation is still going on.)

This is especially p= roblematic because handling renegotiations transparently seems a fairly pop= ular implementation strategy. (Both NSS and OpenSSL do this. OpenSSL even a= llows them by default and doesn't have a good way to turn them off. Not= sure about NSS. BoringSSL makes it opt-in.)

Above= all, by far the best way to handle renegotiation is "never do it, per= iod". I think it's most important that any attempt to hammer down = semantics in the "we already got it wrong" cases should be clear = on this. New protocols should implicitly forbid renego, implementations sho= uld turn it off by default, and that at least gives a bounded body of exist= ing mistakes to consider.

David
=C2=A0
I've heard it recommended that you add other stipulations, such as

3. The server cannot change certificate.

I'm ambivalent on that because I don't believe it to materially cha= nge
the security properties (assuming that we have a good handshake, i.e.,
at least R-I and session hash).=C2=A0 I don't have proof of that, of course.
--001a113ec0caad6b79052216fd71-- From nobody Wed Oct 14 15:44:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732191AD0B1 for ; Wed, 14 Oct 2015 15:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vax9pgGRX-tf for ; Wed, 14 Oct 2015 15:44:10 -0700 (PDT) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id A58F21ACEE5 for ; Wed, 14 Oct 2015 15:44:10 -0700 (PDT) Received: from [10.100.1.6] (unknown [104.238.169.148]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 95374180040A; Wed, 14 Oct 2015 23:43:57 +0100 (BST) To: Martin Thomson , David Benjamin References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> <561EB56B.9050308@baggins.org> From: Matt Caswell X-Enigmail-Draft-Status: N1110 Message-ID: <561EDAAA.3050600@baggins.org> Date: Wed, 14 Oct 2015 23:43:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Oct 2015 22:44:12 -0000 On 14/10/15 21:42, Martin Thomson wrote: > On 14 October 2015 at 13:29, David Benjamin wrote: >> If you really absolutely must support interleave and can't avoid it, I think >> it being allowed everywhere except between CCS and Finished is probably the >> closest you can get to coherent semantics. "Coherent" here is, of course, >> all relative since renego is involved. > > I think that it needs to be more than that. I would say: > > 1. You should not interleave data with handshake messages from the same flight. > 2. You should not report any change to handshake status until the > renegotiation is complete. That means no callbacks/events about new > peer certificates, or anything of that nature until you have received > and validated the Finished. You would have to exercise caution here > for the callbacks that are necessary during the process, like the > "please choose a certificate and private key to use" callback on > either side. > > If you can somehow manage to do all of that, then you might be able > get away with not halting progress entirely. Because - as far as the > application is concerned - application data is sent as though it were > before the renegotiation. In essence, you are keeping the application > ignorant of any changes until the whole process is over. > > I've heard it recommended that you add other stipulations, such as That would be very challenging to implement. Almost certainly not possible for the stable released versions. I would hesitate to do so for the new development version too without explicit published advice in the form of an RFC/errata...it would add significant complexity. It seems my options in reality are: 1) Allow interleaved data everywhere except between CCS and Finished, as per the (hopelessly unclear) RFC. This would leave us conformant, would solve our interoperability problems, but is a "highly dangerous idea" according to your advice. or 2) Leave things as they are now where we abort on interleaved application data. This would leave us unconformant and with an interoperability problem which is causing real issues for users (who will point the finger at us for failing to fix it). "Rock" meet "hard place". :-( Matt From nobody Wed Oct 14 16:06:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BCF1A044F for ; Wed, 14 Oct 2015 16:06:05 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly11ai788838 for ; Wed, 14 Oct 2015 16:06:04 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 CDDDD1A037F for ; Wed, 14 Oct 2015 16:06:00 -0700 (PDT) Received: by ykdt21 with SMTP id t21so2246519ykd.3 for ; Wed, 14 Oct 2015 16:06: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:date:message-id:subject:from:to :cc:content-type; bh=isTYPEPWdMQ15fQzCweSvcVXfLx1xA4c3bGaXhgZxog=; b=vaJkOKyVk6GSNtaWyzBQICSAa7UygdOrLLMsI3+OqQdscTGOX2qHZbTTFvFoDrcy/l 0gyPeHp0Ne71YYqVI5URg6/x9TCmVJ+UwyL3bHLebsfUFzchWqCIsun0dDulAElHOiJc +V4zhZCzXBcCHTavhqJ9nv9f3Ny1OsXOa1pRBAGJOSmPfespR74ItlwKWW4c6R/Ww9vI 90XJN2TBoTQMpHR9SwTrNWCiZoHjwOqr88PZZ/VOy3/q+9CqL65KCxoQk4GOPKV76sH0 RoON0UbfMfeMiUwM1WDyiuQraGZGlxxrYQZeAFEsom9fsI7W1jFUwkNfl07XfQ9LMyqO qe0A== MIME-Version: 1.0 X-Received: by 10.13.223.194 with SMTP id i185mr4340040ywe.43.1444863960096; Wed, 14 Oct 2015 16:06:00 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Wed, 14 Oct 2015 16:06:00 -0700 (PDT) In-Reply-To: <561EDAAA.3050600@baggins.org> References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> <561EB56B.9050308@baggins.org> <561EDAAA.3050600@baggins.org> Date: Wed, 14 Oct 2015 16:06:00 -0700 Message-ID: From: Martin Thomson To: Matt Caswell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Oct 2015 23:06:06 -0000 On 14 October 2015 at 15:43, Matt Caswell wrote: > "highly dangerous idea" Wrong Martin. I agree that there is a need for caution, but in reality, it's not like you can use renegotiation to hand-off to someone else entirely. The person you are talking to hasn't changed. What is dangerous is making assertions about *new* things that the renegotiation introduces. From nobody Thu Oct 15 01:35:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8F31A90B1 for ; Thu, 15 Oct 2015 01:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: 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-m6MedNVh7a for ; Thu, 15 Oct 2015 01:35:12 -0700 (PDT) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id 30E661A90AD for ; Thu, 15 Oct 2015 01:35:12 -0700 (PDT) Received: from [10.192.1.6] (unknown [104.238.169.25]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 3CE6B1800072; Thu, 15 Oct 2015 09:35:08 +0100 (BST) To: Watson Ladd , "tls@ietf.org" References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> <561EB56B.9050308@baggins.org> <561EDAAA.3050600@baggins.org> From: Matt Caswell Message-ID: <561F653B.2010802@baggins.org> Date: Thu, 15 Oct 2015 09:35:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2015 08:35:14 -0000 On 15/10/15 00:04, Watson Ladd wrote: > On Wed, Oct 14, 2015 at 6:43 PM, Matt Caswell wrote: >> >> >> On 14/10/15 21:42, Martin Thomson wrote: >>> On 14 October 2015 at 13:29, David Benjamin wrote: >>>> If you really absolutely must support interleave and can't avoid it, I think >>>> it being allowed everywhere except between CCS and Finished is probably the >>>> closest you can get to coherent semantics. "Coherent" here is, of course, >>>> all relative since renego is involved. >>> >>> I think that it needs to be more than that. I would say: >>> >>> 1. You should not interleave data with handshake messages from the same flight. >>> 2. You should not report any change to handshake status until the >>> renegotiation is complete. That means no callbacks/events about new >>> peer certificates, or anything of that nature until you have received >>> and validated the Finished. You would have to exercise caution here >>> for the callbacks that are necessary during the process, like the >>> "please choose a certificate and private key to use" callback on >>> either side. >>> >>> If you can somehow manage to do all of that, then you might be able >>> get away with not halting progress entirely. Because - as far as the >>> application is concerned - application data is sent as though it were >>> before the renegotiation. In essence, you are keeping the application >>> ignorant of any changes until the whole process is over. >>> >>> I've heard it recommended that you add other stipulations, such as >> >> That would be very challenging to implement. Almost certainly not >> possible for the stable released versions. I would hesitate to do so for >> the new development version too without explicit published advice in the >> form of an RFC/errata...it would add significant complexity. >> >> It seems my options in reality are: >> >> 1) Allow interleaved data everywhere except between CCS and Finished, as >> per the (hopelessly unclear) RFC. This would leave us conformant, would >> solve our interoperability problems, but is a "highly dangerous idea" >> according to your advice. >> >> or >> >> 2) Leave things as they are now where we abort on interleaved >> application data. This would leave us unconformant and with an >> interoperability problem which is causing real issues for users (who >> will point the finger at us for failing to fix it). > > It takes two sides here to have an interop problem. What > implementations are doing this? The specific report I have is for Oracle JRE 1.7.0_71 and 1.7.0_75 but my assumption is that this affects all Oracle JRE versions. The problem ticket in question describes a scenario where a PostgreSQL server (which uses OpenSSL) is talking to a PostgreSQL JDBC client. Due to that fact that these connections are long running, PostgreSQL server has a config parameter "ssl_renegotiation_limit" which triggers a renegotiation after a certain amount of data has been transferred over the connection. Matt From nobody Thu Oct 15 01:46:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E4D1A90AA for ; Thu, 15 Oct 2015 01:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdNF1Negef9p for ; Thu, 15 Oct 2015 01:46:46 -0700 (PDT) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id 05C431A6FF9 for ; Thu, 15 Oct 2015 01:46:46 -0700 (PDT) Received: from [10.192.1.6] (unknown [104.238.169.25]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 17F49180006E; Thu, 15 Oct 2015 09:46:39 +0100 (BST) To: Martin Thomson References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> <561EB56B.9050308@baggins.org> <561EDAAA.3050600@baggins.org> From: Matt Caswell X-Enigmail-Draft-Status: N1110 Message-ID: <561F67EE.4070702@baggins.org> Date: Thu, 15 Oct 2015 09:46:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2015 08:46:47 -0000 On 15/10/15 00:06, Martin Thomson wrote: > On 14 October 2015 at 15:43, Matt Caswell wrote: >> "highly dangerous idea" > > Wrong Martin. Oops. Sorry. > I agree that there is a need for caution, but in > reality, it's not like you can use renegotiation to hand-off to > someone else entirely. The person you are talking to hasn't changed. > What is dangerous is making assertions about *new* things that the > renegotiation introduces. > OpenSSL will not itself use anything from the new handshake until the CCS/Finished has been processed. I couldn't make the same guarantee about applications using OpenSSL APIs/callbacks (although no doubt applications could do all manner of dangerous things if they chose to). So that leaves me unclear whether you are advising me to "fix" the "bug" because its not that dangerous really, or whether the risk of applications using info they shouldn't is too great so we should maintain the status quo and leave things as they are (i.e. broken in certain scenarios). Matt From nobody Thu Oct 15 06:00:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08A01B316E for ; Thu, 15 Oct 2015 06:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGIUR0n2jTIv for ; Thu, 15 Oct 2015 06:00:43 -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 EBF021B3161 for ; Thu, 15 Oct 2015 06:00:42 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 BB08D44962; Thu, 15 Oct 2015 15:00:40 +0200 (CEST) X-purgate-ID: 152705::1444914040-00001EB9-7FB97F96/0/0 X-purgate-size: 1750 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 mail05.wdf.sap.corp (Postfix) with ESMTP id AC5AF40531; Thu, 15 Oct 2015 15:00:40 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9F1BB1A2EF; Thu, 15 Oct 2015 15:00:40 +0200 (CEST) In-Reply-To: <561F653B.2010802@baggins.org> To: Matt Caswell Date: Thu, 15 Oct 2015 15:00:40 +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: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 15 Oct 2015 13:00:49 -0000 Is the particular interop problem that you want to address caused by a necessity to really process application data and handshake data with arbitrary interleave, or is it rather a problem of getting back into half-duplex operation, i.e. a client being able to continue receiving application data up to a ServerHello when it has sent out ClientHello, or a server being able to continue receiving application data up to a ClientHello (or warning level no-renegotiation alert) after the server has sent a ClientHelloRequest? -Martin Matt Caswell wrote: > >>> 1) Allow interleaved data everywhere except between CCS and Finished, as >>> per the (hopelessly unclear) RFC. This would leave us conformant, would >>> solve our interoperability problems, but is a "highly dangerous idea" >>> according to your advice. >>> >>> or >>> >>> 2) Leave things as they are now where we abort on interleaved >>> application data. This would leave us unconformant and with an >>> interoperability problem which is causing real issues for users (who >>> will point the finger at us for failing to fix it). >> >> It takes two sides here to have an interop problem. What >> implementations are doing this? > > The specific report I have is for Oracle JRE 1.7.0_71 and 1.7.0_75 but > my assumption is that this affects all Oracle JRE versions. > > The problem ticket in question describes a scenario where a PostgreSQL > server (which uses OpenSSL) is talking to a PostgreSQL JDBC client. Due > to that fact that these connections are long running, PostgreSQL server > has a config parameter "ssl_renegotiation_limit" which triggers a > renegotiation after a certain amount of data has been transferred over > the connection. From nobody Thu Oct 15 06:09:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E651B3194 for ; Thu, 15 Oct 2015 06:09: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd4m6Tm39evf for ; Thu, 15 Oct 2015 06:09:42 -0700 (PDT) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 20C031B3193 for ; Thu, 15 Oct 2015 06:09:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id D838E19C651 for ; Thu, 15 Oct 2015 16:09:40 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id ZIVNhTHztZRa for ; Thu, 15 Oct 2015 16:09:40 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id AF2A15BC015 for ; Thu, 15 Oct 2015 16:09:40 +0300 (EEST) Date: Thu, 15 Oct 2015 16:09:39 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20151015130939.GA19330@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.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] New curves work and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2015 13:09:44 -0000 As you might know, CFRG has been working on new curves (the document has been sent to IRSG) and is working on signatures (main issues seem to be selecting prehash for prehashed version of 448-bit signatures and KDF for 448-bit signatures). I have been thinking how to integrate this work into TLS. Diffie-Hellman: --------------- There is already a WG draft about this. The one remaining technical issue seems to be wheither to share the curves with signatures or dedicate those for DH. I propose dedicating the codepoints (like draft currently does). The complexity of implementing signatures is significantly above complexity of implementing ECDH. This is magnified by the differences between the signature primitive (one is based on SHA-512, the other on some still-TBD KDF). It is not like there is imminent shortage of curve codepoint space, as we have >64,000 codepoints free. There's also editorial issue of tracking the renaming of the DHFs in CFRG-CURVES (Curve25519->X25519 and similarly for Curve448). Signatures: ----------- The base algorithm for signatures work is EdDSA. It looks like Ed25519 is standardized as-is (at least compatible enough for existing verifiers to be used). Then there is version that first does SHA-512. For 448-bit versions, the KDF and prehash to be done first (for version that does prehashing) is TBD. So, there are four primitives: Ed25519, Ed25519ph, Ed448 and Ed448ph. And keys MUST NOT be mixed between those. I propose the following: - EdDSA uses one SignatureAlgorithm value (5?[1]). - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and another for Ed448/Ed448ph - If there is ever EdDSA instantiation with Edwards448 curve (the same one Ed448 uses) with another KDF, it gets a new curve distinct from Ed448/Ed448ph. - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or value matching the prehash (but the prehash is always done once[2]). [TBD: resolve this] - To be useful, one needs PKIX SPKI representation for the keys. There is a draft about that, to be progressed via other channels (Security area presumably, as PKIX WG is no more). [1] TLS 1.3 introduces one new value for RSA-PSS (which is IIRC marked as 4 in the spec). [2] Technically Ed25519 and Ed448 do have prehash function PH, it just is the identity function. -Ilari From nobody Thu Oct 15 06:12:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4A21A1BFE for ; Thu, 15 Oct 2015 06:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7EVH6FT8Uyg for ; Thu, 15 Oct 2015 06:12:19 -0700 (PDT) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id 716ED1A1BF4 for ; Thu, 15 Oct 2015 06:12:19 -0700 (PDT) Received: from [10.182.1.6] (unknown [104.238.169.124]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 92F7918011F5; Thu, 15 Oct 2015 14:12:13 +0100 (BST) To: mrex@sap.com References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> From: Matt Caswell X-Enigmail-Draft-Status: N1110 Message-ID: <561FA62C.9030801@baggins.org> Date: Thu, 15 Oct 2015 14:12:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2015 13:12:21 -0000 On 15/10/15 14:00, Martin Rex wrote: > Is the particular interop problem that you want to address > caused by a necessity to really process application data and > handshake data with arbitrary interleave, > > or is it rather a problem of getting back into half-duplex operation, > i.e. a client being able to continue receiving application data > up to a ServerHello when it has sent out ClientHello, or a server being > able to continue receiving application data up to a ClientHello > (or warning level no-renegotiation alert) after the server has sent > a ClientHelloRequest? The former. The existing code should cope with the half-duplex issue. In the reported problem we (OpenSSL) are running as a server and we have received application data from the Client *after* we have sent our ServerHelloDone. Matt From nobody Thu Oct 15 12:17:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFCF1A0033 for ; Thu, 15 Oct 2015 12:17:56 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAoQsvBFVV4d for ; Thu, 15 Oct 2015 12:17:54 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 B20E31A0032 for ; Thu, 15 Oct 2015 12:17:54 -0700 (PDT) Received: by qgeo38 with SMTP id o38so36209985qge.0 for ; Thu, 15 Oct 2015 12:17:54 -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-type:content-transfer-encoding:message-id; bh=EmoqVJbBsVFaSYHIkKRMx/uy+sMGzAWYEXzEMWBwYJo=; b=vtPnI/b5vtQVIuS5KhcEGchOxyJV7AX0c+MIjKQJJVFDNkc/3BLEryUBNfa+QKdwcW uYlp1EANzXjTNukwxjc5r85e+wE4YHfOUfFWxf02eQDnb7wqtZINmcFgADb86JRbymoR Br2ITpodaeB59lu3TBcJdONrE53rRm9vFoJpNWHJHdkp5jyickNYBleWG1XKXCvtM1bJ 9sIlQejpds8t/h+ECRveHlWu0FFb4bFyA5kNv9LRAgtraHm+NcAt/YEJWTC2vZ9hvXTW u4XexNna/M+qsBupYNHztE7B2CcdmbKP20TD8yVwGdHZteHw3+AbdbyPBDeYTVBYo2xC /Wog== X-Received: by 10.140.146.13 with SMTP id 13mr12080110qhs.1.1444936673969; Thu, 15 Oct 2015 12:17:53 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id j193sm6012309qhc.17.2015.10.15.12.17.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 15 Oct 2015 12:17:53 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Ilari Liusvaara Date: Thu, 15 Oct 2015 15:17:51 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510151517.52101.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] New curves work and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2015 19:17:56 -0000 On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote: > So, there are four primitives: Ed25519, Ed25519ph, Ed448 and > Ed448ph. And keys MUST NOT be mixed between those. > > I propose the following: > - EdDSA uses one SignatureAlgorithm value (5?[1]). > - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and > another for Ed448/Ed448ph > - If there is ever EdDSA instantiation with Edwards448 curve (the same > one Ed448 uses) with another KDF, it gets a new curve distinct from > Ed448/Ed448ph. > - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or > value matching the prehash (but the prehash is always done once[2]). > [TBD: resolve this] I've been thinking about the issue of how to handle SignatureAndHashAlgorithm values better. I think this time, I'd like to propose going the opposite way we'd normally want to move: let's consider enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of having independent values. We're moving to signature algorithms that don't have arbitrary hashes, so the current system isn't really ideal anymore. Current draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-09#section-6.3.2.1 (text) https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-88 (full registry) ---------------------------------------- enum { none(0), md5_RESERVED(1), sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; enum { anonymous_RESERVED(0), rsa(1), dsa(2), ecdsa(3), rsapss(4), (255) } SignatureAlgorithm; struct { HashAlgorithm hash; SignatureAlgorithm signature; } SignatureAndHashAlgorithm; ---------------------------------------- Proposed replacement backwards-compatible registry: ---------------------------------------- struct { anonymous_RESERVED(0x0000), rsa_nohash(0x0001), dsa_nohash(0x0002), ecdsa_nohash(0x0003), rsapss_nohash(0x0004), md5_RESERVED (0x0100..0x01FF), rsa_sha1(0x0201), dsa_sha1(0x0202), ecdsa_sha1(0x0203), rsapss_sha1(0x0204), sha224_RESERVED (0x0300..0x03FF), rsa_sha256(0x0401), dsa_sha256(0x0402), ecdsa_sha256(0x0403), rsapss_sha256(0x0404), rsa_sha384(0x0501), dsa_sha384(0x0502), ecdsa_sha384(0x0503), rsapss_sha384(0x0504), rsa_sha512(0x0601), dsa_sha512(0x0602), ecdsa_sha512(0x0603), rsapss_sha512(0x0604), (0xFFFF) } SignatureAndHashAlgorithm; ---------------------------------------- New values could be assigned specific combinations as needed. This would also let hashes & signatures be deprecated independently easily, e.g. allow rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from the start). Dave From nobody Thu Oct 15 12:25:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8BA1A00E4 for ; Thu, 15 Oct 2015 12:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP1T77sI2HJA for ; Thu, 15 Oct 2015 12:25:38 -0700 (PDT) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) (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 941651A00C0 for ; Thu, 15 Oct 2015 12:25:38 -0700 (PDT) Received: by ykfy204 with SMTP id y204so64643303ykf.1 for ; Thu, 15 Oct 2015 12:25:38 -0700 (PDT) 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-type; bh=Uxr595TLZLJYG3xreNMhhhIbFcMTeNj1CJ8y6e6lkHQ=; b=Icdsva36qXDatsVkP5pLOGERn8h4nkXZQUkNc2o4/jEPGIKpGHoxiJiJcxMQKzIpFk UJR4GKemsQ63h6X8znizeijtEmhkGF5UTNkcIlhgPPdfxaomZ/7bemT7h2OERvdlDB16 P2FYRr8ig2xJoCjrHEaoLxS0YjB0QeT+VilTQP8RPnk4f+RrMLhuslv67FmhTr/10SLE +NkKQF5VsIaV0SLr+G6pcxlEWEgbpviibiNgHpw2Mzv1UCGN+2SGvVNgxcZQ0lW2p7+I Kkc3AKNZHp3JWBFsIu7mtxQI9AFkfIWttbZS9bLONbIaBDz4xOaqGk9kkE5jJ9wGJxAy nxcA== X-Gm-Message-State: ALoCoQmoQ95wnj90M+V1DVDetQ1bikhw1Jh/79vbf428PJTWwPnY4D8/B+VXG5Kj6poZQwlhXUzG X-Received: by 10.13.214.195 with SMTP id y186mr7939926ywd.81.1444937137805; Thu, 15 Oct 2015 12:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Thu, 15 Oct 2015 12:24:58 -0700 (PDT) In-Reply-To: <201510151517.52101.davemgarrett@gmail.com> References: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi> <201510151517.52101.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 15 Oct 2015 12:24:58 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114fcea8d28ecf052229a41b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New curves work and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2015 19:25:41 -0000 --001a114fcea8d28ecf052229a41b Content-Type: text/plain; charset=UTF-8 On Thu, Oct 15, 2015 at 12:17 PM, Dave Garrett wrote: > On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote: > > So, there are four primitives: Ed25519, Ed25519ph, Ed448 and > > Ed448ph. And keys MUST NOT be mixed between those. > > > > I propose the following: > > - EdDSA uses one SignatureAlgorithm value (5?[1]). > > - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and > > another for Ed448/Ed448ph > > - If there is ever EdDSA instantiation with Edwards448 curve (the same > > one Ed448 uses) with another KDF, it gets a new curve distinct from > > Ed448/Ed448ph. > > - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or > > value matching the prehash (but the prehash is always done once[2]). > > [TBD: resolve this] > > I've been thinking about the issue of how to handle > SignatureAndHashAlgorithm values better. I think this time, I'd like to > propose going the opposite way we'd normally want to move: let's consider > enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of > having independent values. We're moving to signature algorithms that don't > have arbitrary hashes, so the current system isn't really ideal anymore. > > Current draft: > https://tools.ietf.org/html/draft-ietf-tls-tls13-09#section-6.3.2.1 > (text) > https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-88 (full > registry) > ---------------------------------------- > enum { > none(0), > md5_RESERVED(1), > sha1(2), > sha224_RESERVED(3), > sha256(4), sha384(5), sha512(6), > (255) > } HashAlgorithm; > > enum { > anonymous_RESERVED(0), > rsa(1), > dsa(2), > ecdsa(3), > rsapss(4), > (255) > } SignatureAlgorithm; > > struct { > HashAlgorithm hash; > SignatureAlgorithm signature; > } SignatureAndHashAlgorithm; > ---------------------------------------- > > Proposed replacement backwards-compatible registry: > ---------------------------------------- > struct { > anonymous_RESERVED(0x0000), > rsa_nohash(0x0001), > dsa_nohash(0x0002), > ecdsa_nohash(0x0003), > rsapss_nohash(0x0004), > md5_RESERVED (0x0100..0x01FF), > rsa_sha1(0x0201), > dsa_sha1(0x0202), > ecdsa_sha1(0x0203), > rsapss_sha1(0x0204), > sha224_RESERVED (0x0300..0x03FF), > rsa_sha256(0x0401), > dsa_sha256(0x0402), > ecdsa_sha256(0x0403), > rsapss_sha256(0x0404), > rsa_sha384(0x0501), > dsa_sha384(0x0502), > ecdsa_sha384(0x0503), > rsapss_sha384(0x0504), > rsa_sha512(0x0601), > dsa_sha512(0x0602), > ecdsa_sha512(0x0603), > rsapss_sha512(0x0604), > (0xFFFF) > } SignatureAndHashAlgorithm; > ---------------------------------------- > > New values could be assigned specific combinations as needed. This would > also let hashes & signatures be deprecated independently easily, e.g. allow > rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from > the start). I am not in favor of this change. Because we can already indicate combinations, this doesn't seem to add significant new value. If we need to indicate "signature algorithm without a hash" then a "none" hash is the simplest solution. -Ekr --001a114fcea8d28ecf052229a41b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 15, 2015 at 12:17 PM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote:
> So, there are four primitives: Ed25519, Ed25519ph, Ed448 and
> Ed448ph. And keys MUST NOT be mixed between those.
>
> I propose the following:
> - EdDSA uses one SignatureAlgorithm value (5?[1]).
> - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and >=C2=A0 =C2=A0another for Ed448/Ed448ph
> - If there is ever EdDSA instantiation with Edwards448 curve (the same=
>=C2=A0 =C2=A0one Ed448 uses) with another KDF, it gets a new curve dist= inct from
>=C2=A0 =C2=A0Ed448/Ed448ph.
> - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or >=C2=A0 =C2=A0value matching the prehash (but the prehash is always done= once[2]).
>=C2=A0 =C2=A0[TBD: resolve this]

I've been thinking about the issue of how to handle SignatureAnd= HashAlgorithm values better. I think this time, I'd like to propose goi= ng the opposite way we'd normally want to move: let's consider enum= erating all combinations of HashAlgorithm+SignatureAlgorithm instead of hav= ing independent values. We're moving to signature algorithms that don&#= 39;t have arbitrary hashes, so the current system isn't really ideal an= ymore.

Current draft:
https://tools.ietf.org/html/draft= -ietf-tls-tls13-09#section-6.3.2.1=C2=A0 (text)
https://tools.ietf.org/html/draft-ietf-tl= s-tls13-09#page-88=C2=A0 (full registry)
----------------------------------------
enum {
=C2=A0 =C2=A0 none(0),
=C2=A0 =C2=A0 md5_RESERVED(1),
=C2=A0 =C2=A0 sha1(2),
=C2=A0 =C2=A0 sha224_RESERVED(3),
=C2=A0 =C2=A0 sha256(4), sha384(5), sha512(6),
=C2=A0 =C2=A0 (255)
} HashAlgorithm;

enum {
=C2=A0 =C2=A0 anonymous_RESERVED(0),
=C2=A0 =C2=A0 rsa(1),
=C2=A0 =C2=A0 dsa(2),
=C2=A0 =C2=A0 ecdsa(3),
=C2=A0 =C2=A0 rsapss(4),
=C2=A0 =C2=A0 (255)
} SignatureAlgorithm;

struct {
=C2=A0 =C2=A0 HashAlgorithm hash;
=C2=A0 =C2=A0 SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
----------------------------------------

Proposed replacement backwards-compatible registry:
----------------------------------------
struct {
=C2=A0 =C2=A0 anonymous_RESERVED(0x0000),
=C2=A0 =C2=A0 rsa_nohash(0x0001),
=C2=A0 =C2=A0 dsa_nohash(0x0002),
=C2=A0 =C2=A0 ecdsa_nohash(0x0003),
=C2=A0 =C2=A0 rsapss_nohash(0x0004),
=C2=A0 =C2=A0 md5_RESERVED (0x0100..0x01FF),
=C2=A0 =C2=A0 rsa_sha1(0x0201),
=C2=A0 =C2=A0 dsa_sha1(0x0202),
=C2=A0 =C2=A0 ecdsa_sha1(0x0203),
=C2=A0 =C2=A0 rsapss_sha1(0x0204),
=C2=A0 =C2=A0 sha224_RESERVED (0x0300..0x03FF),
=C2=A0 =C2=A0 rsa_sha256(0x0401),
=C2=A0 =C2=A0 dsa_sha256(0x0402),
=C2=A0 =C2=A0 ecdsa_sha256(0x0403),
=C2=A0 =C2=A0 rsapss_sha256(0x0404),
=C2=A0 =C2=A0 rsa_sha384(0x0501),
=C2=A0 =C2=A0 dsa_sha384(0x0502),
=C2=A0 =C2=A0 ecdsa_sha384(0x0503),
=C2=A0 =C2=A0 rsapss_sha384(0x0504),
=C2=A0 =C2=A0 rsa_sha512(0x0601),
=C2=A0 =C2=A0 dsa_sha512(0x0602),
=C2=A0 =C2=A0 ecdsa_sha512(0x0603),
=C2=A0 =C2=A0 rsapss_sha512(0x0604),
=C2=A0 =C2=A0 (0xFFFF)
} SignatureAndHashAlgorithm;
----------------------------------------

New values could be assigned specific combinations as needed. This would al= so let hashes & signatures be deprecated independently easily, e.g. all= ow rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should b= e from the start).

I am not in favor of thi= s change. Because we can already indicate combinations, this
does= n't seem to add significant new value. If we need to indicate "sig= nature algorithm
without a hash" then a "none" has= h is the simplest solution.

-Ekr

--001a114fcea8d28ecf052229a41b-- From nobody Thu Oct 15 15:37:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D9B1A877E for ; Thu, 15 Oct 2015 15:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 73uPZrvk3r8b for ; Thu, 15 Oct 2015 15:37:55 -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 0694D1A8775 for ; Thu, 15 Oct 2015 15:37:55 -0700 (PDT) Received: by lffv3 with SMTP id v3so53193167lff.0 for ; Thu, 15 Oct 2015 15:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=ikjGFAiDnL1jgKLEOhuqVQR5iX75zDEEemaBCfWuKuI=; b=joulW7vIG2RCRYuXuotOzPSGox6r9OpJYr3YNsWjeeNYrQlpFEVQYUgO5vYZ4lvfv7 nLLvH7FNHJX5vxeULAbnvDLEAq5wsuu9sNi/mb7lKUNbd1jYlqnn0+cBvgansRcidivt h8gqAlb/SksZDCOKiV03b9SoacckIjlXtBxUNw4RpJzMlXFsI4CoJhyUdiz8GkX+8bU+ 97O6PeOusI5UuLm8rvZliLH+vGUvbcByemM0awlmdQeSWmrr6d3brzaCDbADCjoJ0Ixh bqe/FAktP763Wg1CTHHI5rc/yhlTVhnLUG4eKk3/p76/AbhYw89+IjPv612TIMuyVQLU 5iiw== X-Received: by 10.25.165.4 with SMTP id o4mr4057817lfe.4.1444948673137; Thu, 15 Oct 2015 15:37:53 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.168.84 with HTTP; Thu, 15 Oct 2015 15:37:23 -0700 (PDT) From: Hugo Krawczyk Date: Thu, 15 Oct 2015 18:37:23 -0400 X-Google-Sender-Auth: -Dajkeh_6Im8SyCWoewSjjXb_YA Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113f236261943605222c544e Archived-At: Cc: Hoeteck Wee Subject: [TLS] OPTLS paper posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2015 22:37:57 -0000 --001a113f236261943605222c544e Content-Type: text/plain; charset=UTF-8 The OPTLS paper (preprint) explaining the rationale of the protocol and its analysis is posted here: http://eprint.iacr.org/2015/978. The OPTLS design provides the basis for the handshake modes specified in the current TLS 1.3 draft including 0-RTT, 1-RTT variants, and PSK modes (client authentication is not covered). OPTLS dispenses with elements that are not essential to achieve the basic cryptographic security of the protocol. By following such a "minimalistic" approach, the OPTLS design provides the flexibility of building different protocol variants that provide varied performance trade-offs and security features. Some of these variants give rise to the current TLS 1.3 modes while others may be useful in the future. In the latter class it is worth noting the ability to obtain a protocol that completely eliminates online signatures while keeping most of TLS 1.3 unchanged. The analysis part of the paper covers the basics of key exchange security. More comprehensive analyses including validation of TLS 1.3 specifications and implementations is expected to be covered by future work. We would like to take this opportunity to thank the TLS Working Group for insightful discussions and invaluable feedback that led to this work. Hoeteck and Hugo --001a113f236261943605222c544e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

<= div class=3D"gmail_default" style=3D"">T= he OPTLS paper (preprint) explaining the rationale of the protocol and its<= /font>
analysis is posted here: http://eprint.iacr.org/2015/978.=C2=A0

The OPTLS design provides the basis for the handshake modes specified in= the
current TLS 1.3 draft including 0-RTT, 1-RTT variants, and= PSK modes (client
authentication is not covered). OPTLS dispen= ses with elements that are not
essential to achieve the basic c= ryptographic security of the protocol.=C2=A0
By following such = a "minimalistic" approach, the OPTLS design provides the
flexibility of building different protocol variants that provide varied=
performance trade-offs and security features. Some of these va= riants give rise
to the current TLS 1.3 modes while others may = be useful in the future. In the
latter class it is worth noting= the ability to obtain a protocol that completely
eliminates on= line signatures while keeping most of TLS 1.3 unchanged.

The analysis part of the paper covers the basics of key exchange= security. =C2=A0
More comprehensive analyses including validat= ion of TLS 1.3 specifications and
implementations is expected t= o be covered by future work.

We would like to = take this opportunity to thank the TLS Working Group for
insigh= tful discussions and invaluable feedback that led to this work.

Hoeteck and Hugo
--001a113f236261943605222c544e-- From nobody Thu Oct 15 16:55:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85451A897B for ; Thu, 15 Oct 2015 16:55:21 -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=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R0yat_mfRF1 for ; Thu, 15 Oct 2015 16:55:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 358B31A8974 for ; Thu, 15 Oct 2015 16:55:19 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 6EBBEF984; Thu, 15 Oct 2015 19:55:17 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 618851FFA8; Thu, 15 Oct 2015 19:54:49 -0400 (EDT) From: Daniel Kahn Gillmor To: Yaron Sheffer , "tls\@ietf.org" In-Reply-To: <561BB319.3050108@gmail.com> References: <20151011193517.30413.36864.idtracker@ietfa.amsl.com> <561ABF32.20008@gmail.com> <877fmtt9mh.fsf@alice.fifthhorseman.net> <561BB319.3050108@gmail.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 15 Oct 2015 19:54:49 -0400 Message-ID: <874mhrr8l2.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2015 23:55:21 -0000 On Mon 2015-10-12 09:18:17 -0400, Yaron Sheffer wrote: > I'm not familiar enough with TACK at the moment. I can write something > up, or if you'd like to contribute text, that'll be awesome. i'm not up-to-speed yet either, and am unlikely to be able to get to this soon, sorry! > IMO persisting the master key to disk is less of a problem than > distributing it across cluster members, and this is something that > needs to happen or session resumption will fail regularly. Regular > rotation of the master key means that persisting it to disk is not > such a risk. You are right that a session resumption master key needs > not be backed up, whereas the pinning secret may need to be backed up > securely for disaster recovery. hm, i'm not convinced of this tradeoff in general -- in today's "cloud-y" age, backing up to disk rather than keeping in RAM might trigger writes to data storage that's owned by yet another entity. This means you have the potential for traffic decryption not only to those who can access your CPU and RAM, but those who run your storage backend. Even worse, if the pinning secret is derived from the session resumption master secret as recommended in section 4.2, then the temptation will be to store the session resumption master secret to disk, which puts the forward secrecy of resumed sessions at risk. If admins don't persist the resumption master secret, but persist only the derived secret, then there are two modes of operation: one running from the derived secret, and one running from the backup secret, which sounds messy. Perhaps some implementation guidance is warranted here? > Yes, I was thinking of privacy in the face of passive attackers who > listen in to the TLS handshake. Not when the server itself is out to get > you. I suspect that there is little you can do to protect your privacy > when the server itself is malicious, but I'm sure you are more > knowledgeable about these issues. TLS servers themselves should not be able to track a TLS client in the event that the client decides to not be tracked. For example, a client could refuse to initiate session resumption, and could offer a standardized, common TLS Client Hello. Maybe privacy from a pinned-ticket server can be achieved by a client by simply never sending the ticket pinning extension, or by never sending it on subsequent connections? this would come at the cost of losing the ability to detect when a server's identity gets swapped out, of course. It's not a particularly satisfying tradeoff. > You are right. "Certificate pinning" is the more common term, but is it > less precise. fwiw, "certificate pinning" is also used in https://tools.ietf.org/html/rfc6125#page-11 to describe what browsers often call a "security exception" -- a non-validating certificate that the user explicitly decides to allow for a given site. this kind of additional grant is the *opposite* of the additional restriction you're describing. better to stick to "public key pinning", which has no such connotations. > The longer you keep a keypair, the more likely it is to be compromised. > So you may not want to keep a keypair in "cold storage" for a year, and > then use it as a production cert for another year. > > Depending on your setup, the risk may be much larger on the production > server than on some offline storage, and then your proposed process > makes perfect sense. yes, i intended the proposal to be for an admin who has access to offline storage (though even an encrypted thumb drive locked in a drawer would do). > One difference is that in HPKP, the data stored in (b) is > security-critical, in that its compromise is just as bad as compromise > of the site's regular secret key (you can use it to MITM all > connections to the server). In my proposal the pinning secret is truly > a "second factor". Its compromise is an issue only if you can *also* > generate a fake certificate. I'm not sure about this distinction. No certificate has been issued for the HPKP backup key until just before it is deployed. So the attacker has to get a certificate issued for that secret key anyway, right? > Another major difference is that my proposal avoids the manual > management steps of HPKP (at least until we have ACME widely > deployed). The pinning secret can be generated automatically when the > server is started and rolled over periodically, with no human in the > loop. Since you'd still need to persist the secret to disk in some reliable way that handles rotation, backup, etc. safely if you don't want to risk bricking the site, I think you're saying that hypothetical software stack X has a better chance at successful implementation and deployment than hypothetical software stack Y. ;) Thanks for proposing this, Yaron. --dkg From nobody Fri Oct 16 02:50:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CBD1B34C9 for ; Fri, 16 Oct 2015 02:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwZ5EtPaZxUJ for ; Fri, 16 Oct 2015 02:50: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 133DD1B34C8 for ; Fri, 16 Oct 2015 02:50:42 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 6B5EBC0B64C1; Fri, 16 Oct 2015 09:50:42 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-54.ams2.redhat.com [10.36.112.54]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9G9obMi012919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2015 05:50:41 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 16 Oct 2015 11:50:30 +0200 Message-ID: <55580670.jzLYtZ8hkN@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.1.10-200.fc22.x86_64; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <20151014154401.DF1401A2E6@ld9781.wdf.sap.corp> <561EDAAA.3050600@baggins.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1526812.lyuG49bKPV"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 09:50:44 -0000 --nextPart1526812.lyuG49bKPV Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 14 October 2015 16:06:00 Martin Thomson wrote: > On 14 October 2015 at 15:43, Matt Caswell wrote: > > "highly dangerous idea" >=20 > Wrong Martin. I agree that there is a need for caution, but in > reality, it's not like you can use renegotiation to hand-off to > someone else entirely. The person you are talking to hasn't changed.= > What is dangerous is making assertions about *new* things that the > renegotiation introduces. Also, we're talking with a peer that does implement RFC 5746, so we can= =20 be *sure* that we're talking to the same peer still. So the problem happens when application is querying the library for=20 connection information (certificates mainly) and getting info from new=20= connection while still actually receiving application data from the old= =20 context. The problem is, that we can verify the handshake only after we receive=20= Finished message, until then, the server can present any certificate it= =20 wants and client has no way of verifying if it (for *DH it can even=20 receive information sent by client after its Finished message). For=20 server it's nicer, as the certificate can be verified much quicker (in=20= the same flight), but the window still exists. That makes it dangerous when going from low to high security context,=20= not so much other way round. =2D-=20 Regards, Hubert Kario 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 Republi= c --nextPart1526812.lyuG49bKPV 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 iQIcBAABCgAGBQJWIMhmAAoJEJKo0bgB0vX1wEEP/iW3QVZPelYTlDF1A2b0Ky90 CUs8sO9fRtt/kzu2c1d9nvEFZEw/6fq3ylwoVP2WSokdfqgKxb/q2i8frIe9NoRl lgyy2npFxqyX/9muzoczpTR2kC/dIG2U5nCZJfj/oHTbvtcZgzkZ7dJBhlMB/myE CH9QXIb67PO+zuY7IUhAofFP2xQ/k0NlcZQEq66gufN9Sp7h+ecm9NO+GheOELzT UVcU0D0jXY4LbgklRmsKAGmeLrqeKdc1q5b2jVi+oNZDUvPHmEyRm7avHm4pvlIx WaI4ItGvl8VJBnsI6OikjGchQ1aRQyQi2OgeNWqBHGYFrdCTBKLN30pj7jy/MN4w EaMiLfUO/UrX3Dve7ZV0l7oDJqlGuKZl3hzs2DLqeyvu1hqkWIuf58CTLFgEgfne 4QFdIbIIO2JATLNK4egRaexgIcHsXweLiz++mAcFH1rZuJFDQf40DSRp7DCy+WN0 IAGYY/NV46RTT5GVfwHhk4+ynQINZygdRyk7BcIALYnZ4b6/adErt4tZFK46xhxF j565S935R15CrL16y2sfP9wxdvG4ThbSOh8eZWrjz4CHc9FlO1jbP/J8RWYCcTBS ltLnuvD+pUO3xRsy223paPfaFAGp5FRcgFRvmlq/UL8WywsGAK0rDSWMmFJPDsFb QIj/o0pI9Iz+O9A/5cZD =pL0i -----END PGP SIGNATURE----- --nextPart1526812.lyuG49bKPV-- From nobody Fri Oct 16 06:16:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49AF1B2AA9 for ; Fri, 16 Oct 2015 06:16:04 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz868JmO7iKq for ; Fri, 16 Oct 2015 06:16:03 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450: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 3CA5D1B2AA7 for ; Fri, 16 Oct 2015 06:16:03 -0700 (PDT) Received: by wicll6 with SMTP id ll6so9555387wic.0 for ; Fri, 16 Oct 2015 06:16: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:date:message-id:subject:from:to :cc:content-type; bh=GThZTNAIoDvVaJyLFJjVeUcAbUvTY96//k7acxYcBVA=; b=IktHqiml0jx1vqtjl6XZQxWIrq14JDMmvvfxcsBqyjxEpntsJVLOVDwPHtQMG3cxU3 ov415tnrwCNr9av92db8uEzzqY6lYRqWT94xRt3wg1jlJka629X648LBZW/xOPdwI8nQ J4+VCDBHQ2/h1SNMi8y2l7jvpYL1vt+TvuVuv7VVR9BNdXZSOzFArCLst1AitumzwuYI XELwcvXHnq7+8I/JDFYA5vMF5YK0hisrgFD5Z3KouLl67qkKJmlkwD4CVME8ZKd6S32i xKvAytEOs6yksItrPXIUpaw5shuOcUi7esHR5TbvGGT4tmJtElMkMLO3GAXMSCeG2oA+ Avag== MIME-Version: 1.0 X-Received: by 10.180.186.10 with SMTP id fg10mr4814825wic.30.1445001361788; Fri, 16 Oct 2015 06:16:01 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Fri, 16 Oct 2015 06:16:01 -0700 (PDT) In-Reply-To: <561FA62C.9030801@baggins.org> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <561FA62C.9030801@baggins.org> Date: Fri, 16 Oct 2015 09:16:01 -0400 Message-ID: From: Watson Ladd To: Matt Caswell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 13:16:05 -0000 On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell wrote: > > > On 15/10/15 14:00, Martin Rex wrote: >> Is the particular interop problem that you want to address >> caused by a necessity to really process application data and >> handshake data with arbitrary interleave, >> >> or is it rather a problem of getting back into half-duplex operation, >> i.e. a client being able to continue receiving application data >> up to a ServerHello when it has sent out ClientHello, or a server being >> able to continue receiving application data up to a ClientHello >> (or warning level no-renegotiation alert) after the server has sent >> a ClientHelloRequest? > > The former. The existing code should cope with the half-duplex issue. In > the reported problem we (OpenSSL) are running as a server and we have > received application data from the Client *after* we have sent our > ServerHelloDone. After thinking about this a bit this should be okay so long as you properly present the authentication state associated with the data. The hypothetical problem is using this to evade the protection of the secure renegotiation extension. As a solution the new authentication state should only be made visible to application code after receiving a CSS/Finished. This is supposed to have exactly the same semantics as pretending that the application data was sent before any handshake data. Unfortunately I don't know how to verify this. Can miTLS cover this case? > > Matt -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Oct 16 07:06:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA91A1B2BD8 for ; Fri, 16 Oct 2015 07:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1-hFjtno-jT for ; Fri, 16 Oct 2015 07:06:01 -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 5B6CA1A92EB for ; Fri, 16 Oct 2015 07:06:01 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 11AAB19D05F; Fri, 16 Oct 2015 14:05:46 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-54.ams2.redhat.com [10.36.112.54]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9GE5f0H016005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2015 10:05:44 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 16 Oct 2015 16:05:34 +0200 Message-ID: <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.1.10-200.fc22.x86_64; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <561FA62C.9030801@baggins.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7087523.pVVqRUb5c3"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 14:06:04 -0000 --nextPart7087523.pVVqRUb5c3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 16 October 2015 09:16:01 Watson Ladd wrote: > On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell =20 wrote: > > On 15/10/15 14:00, Martin Rex wrote: > >> Is the particular interop problem that you want to address > >> caused by a necessity to really process application data and > >> handshake data with arbitrary interleave, > >>=20 > >> or is it rather a problem of getting back into half-duplex > >> operation, > >> i.e. a client being able to continue receiving application data > >> up to a ServerHello when it has sent out ClientHello, or a server > >> being able to continue receiving application data up to a > >> ClientHello (or warning level no-renegotiation alert) after the > >> server has sent a ClientHelloRequest? > >=20 > > The former. The existing code should cope with the half-duplex > > issue. In the reported problem we (OpenSSL) are running as a server= > > and we have received application data from the Client *after* we > > have sent our ServerHelloDone. >=20 > After thinking about this a bit this should be okay so long as you > properly present the authentication state associated with the data. > The hypothetical problem is using this to evade the protection of the= > secure renegotiation extension. As a solution the new authentication > state should only be made visible to application code after receiving= > a CSS/Finished. This is supposed to have exactly the same semantics a= s > pretending that the application data was sent before any handshake > data. >=20 > Unfortunately I don't know how to verify this. Can miTLS cover this > case? you mean, you want an implementation that can insert application data i= n=20 any place of the handshake? we've been using my project for that:=20 https://github.com/tomato42/tlsfuzzer the specific test cases are: https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-interlea= ved-application-data-and-fragmented-handshakes-in-renegotiation.py https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-interlea= ved-application-data-in-renegotiation.py https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-openssl-= 3712.py you can run them by: pip install tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=3D. python scripts/test-openssl-3712.py (they do expect a HTTP server on the other side) =2D-=20 Regards, Hubert Kario 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 Republi= c --nextPart7087523.pVVqRUb5c3 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 iQIcBAABCgAGBQJWIQQuAAoJEJKo0bgB0vX1QtIP/3ICwZgnzsQ8m0P9DC0jK99U qO7dJqoclNZdRaBud3lpd+U+MGqmmeVgi02Rag3GN0EtbjsBUSbHsojXrQL+go6L X1ehbQ5kqnL/6PUs74MAN31L46MgLpLxLw3zzlz88QRtBcReK3dv6WpMP9l+sRdJ /5rS0C+VKSyeE9g8qhlvytONhwk/GvWwPXT9vRtQrAP+JX1BNRWiaTjO1Hc+DwbE vzISvV8HBj8KNWwBBVAcWnkQMELJ7OabVei6wHd+16s23j3z2ns1rnf/kkF4jC9f 4GKbPleFOaenxopyv0TWbLcuXtLKfuVj27I0c1JGsbD7OP6eHLtXq3hQcJGpscVq SmsryAtSUEm/aYgOM5vP59LeDpuMbOZXUnFu30jdnht9ocCZXdJKWKkUDaHo3dSr LyHrCop3UpitSuV8NCtxfRrGzAudY/zwAKJ/OFyOQOpi4Fo/hwwetShMF2JFoU3w 6vBEnxunQb7kTdLk3PcvU0wMmE1+RTdeXHQX0GaPdAD4zgMAw/cpMsctIJbiuchs tW89Tur35UUqE3XX5CPDHhg64IZ/7Clt1w5lR+6nICSnA9g/voPQhmp2IFjG5PuW AsMNJzH4k6Z8dFXrbdokER0cLIsCxmqBndmAvecPC+eTQA2O4nW0314Lfg7YNkp9 gXJCqBzbEIxHer3UQm9o =JMI6 -----END PGP SIGNATURE----- --nextPart7087523.pVVqRUb5c3-- From nobody Fri Oct 16 09:31:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668E1A89FC for ; Fri, 16 Oct 2015 09:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi7TJc_TuQeV for ; Fri, 16 Oct 2015 09:31:22 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847FA1A896F for ; Fri, 16 Oct 2015 09:31:21 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id VsXH1r00A10HQrX01sXJ2U; Fri, 16 Oct 2015 18:31:19 +0200 Message-ID: <56212653.6050702@openfortress.nl> Date: Fri, 16 Oct 2015 18:31:15 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 16:31:25 -0000 Hello, Based on the feedback in this WG, I'm now redefining TLS-KDH to keep ECDH and Kerberos orthogonal. That simplifies matters enormously. I can now see a few design alternatives. If you have any response to them, it is kindly appreciated! 1) Continue to use KeyExchange This variation sends a Ticket + Authenticator in the ClientKeyExchange, but DH is now mentioned in plaintext instead of encrypted in the Authenticator. PRO: Prior handshake can be taken into account in an Authenticator hash (a.k.a. "checksum"). CON: Special case for KeyExchange; doesn't integrate automatically with TLS 1.3. 2) Embed the Ticket + Authenticator in a PSK This uses the binary blurb of the PSK to wrap the Ticket and Authenticator. PRO: Client authenticates very early, in the ClientHello. CON: PSK is untyped, so it requires separate agreement on the contents. It is impossible to incorporate ServerHello information in the exchange. The server has not indicated if it supports Kerberos, so the client must make a leap of faith. PSK replies the selected PSK identifier, rather than send a response message; it is not designed for messaging purposes. 3) Similar to OpenPGP: Negotiate cert-type There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets. PRO: Good integration with TLS: Tickets are transported in the ClientCertificate, and an Authenticator is the ClientVerify. DH is independent and can move to the earlier phase for TLS 1.3. CON: Decision on client credential type must be made in ClientHello, when not all data may be available (namely, the sequence of tickets leading to the TLS-protected service). Also impacts the cert-type used in the ServerCert. 4) Define an X.509 embedding for Tickets Certificates provide an id/key binding with a signature by a trusted party; although the AlgorithmIdentifiers used here are new, they do fit in the X.509 framework. This is rather out-of-the-box thinking, so I tested the idea, see https://github.com/arpa2/kerberos2pkix PRO: Minimal changes to TLS, since Kerberos is now a signing algorithm. The server can independently authenticate using RSA & co (on top of Kerberos' mutual authentication). Ticket + timestamp-Authenticator go into an X.509 ClientCertificate, and an Authenticator including the hash over prior TLS messages can go into ClientVerify. CertificateRequest can mix options for Kerberos, RSA, and so on, and client selects whatever it can get to locally, giving the best user experience. We can also support user-to-user connections and S4U2Proxy a.k.a. "Constrained Delegation". CON: These certificates are symmetrically keyed, which is uncommon. Certificates are not readable to anyone, but only to the remote peer. Certificate owner is ideally read from the embedded ticket, rather than from the subject field. My money is on the last two, but option 4. really needs feedback because it is a bit wild. When I get an idea where to go, I will be happy to write a new draft version... a much smaller and simpler one this time! Cheers, -Rick From nobody Fri Oct 16 11:48:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626AA1ACDA7 for ; Fri, 16 Oct 2015 11:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 mpq0z5G7f2d6 for ; Fri, 16 Oct 2015 11:48:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E4A1ACDA2 for ; Fri, 16 Oct 2015 11:48:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ncxMK3RSkzCfM; Fri, 16 Oct 2015 20:48:29 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=O4jH9H6A X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id V9uuZBgEP1DL; Fri, 16 Oct 2015 20:48:28 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 16 Oct 2015 20:48:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EC79280030; Fri, 16 Oct 2015 14:48:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1445021306; bh=MAAWKSZqqs45BJTXQOard/ggthkw4JwNW5wd1Zxe1Ic=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O4jH9H6AbZlHa1UEgLRaoSkzy1dvpDbgMUSuMvXej1nGJvbUwME2DCFbxR8f9OV4z gtmbWb/nyspEmsNynXNki4lJR+EpkwtnOvJumvHut1IJmwFREUnuMteZ93Lo+X9b/b jscOkixn5YBDt1KezOx8cfi6r2ld23vhtT9ekvHI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t9GImQLV011421; Fri, 16 Oct 2015 14:48:26 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 16 Oct 2015 14:48:26 -0400 (EDT) From: Paul Wouters To: Rick van Rein In-Reply-To: <56212653.6050702@openfortress.nl> Message-ID: References: <56212653.6050702@openfortress.nl> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 18:48:35 -0000 On Fri, 16 Oct 2015, Rick van Rein wrote: > 3) Similar to OpenPGP: Negotiate cert-type > > There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets. > > PRO: Good integration with TLS: Tickets are transported in the ClientCertificate, and an Authenticator is the ClientVerify. DH is independent and can move to the earlier phase for TLS 1.3. How is this type of TLS connection prevented from being MITM'ed by someone replaying kerberos tickets (which it cannot read itself) Paul From nobody Fri Oct 16 12:11:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D3B1ACE8B for ; Fri, 16 Oct 2015 12:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BiFM9jke9FO for ; Fri, 16 Oct 2015 12:11:06 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9486B1ACE9E for ; Fri, 16 Oct 2015 12:11:06 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 13E4A496C2A; Fri, 16 Oct 2015 19:11:06 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id DE7E9496C15; Fri, 16 Oct 2015 19:11:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445022665; bh=vsTibMsg7hRAVCMYI2/vjW9GBM5ZhFs2B2McAluxzsQ=; l=11740; h=From:To:CC:Date:References:In-Reply-To:From; b=XTf/DCFZ7lVvF3AeP8RfFsOcNpFkocNDcDch7/roFJNBBkgis6f0qL3eOsXSJGw4s 77bTr6sibhDJgnQqNrUmIKoUfIfLET4TtnHcvXq9k7wudu5fMK3mjMomn5GN8TBK1t zCRdA1ObTCAxVuXv4LtoyFE5UXjQuKNKotoMAh8w= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id D93049808B; Fri, 16 Oct 2015 19:11:05 +0000 (GMT) Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 16 Oct 2015 14:11:05 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Fri, 16 Oct 2015 14:11:05 -0500 From: "Short, Todd" To: Matt Caswell Thread-Topic: [TLS] Clarification on interleaving app data and handshake records Thread-Index: AQHRCEZnMGJCacmCHEiMi6ZvuMhhCg== Date: Fri, 16 Oct 2015 19:11:04 +0000 Message-ID: <578EBE44-433F-4008-A856-4A53F39D0554@akamai.com> References: <560BB34F.4070201@openssl.org> <560BB416.10602@baggins.org> <561CCB0D.6020506@baggins.org> In-Reply-To: <561CCB0D.6020506@baggins.org> 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.45.92] Content-Type: multipart/alternative; boundary="_000_578EBE44433F4008A8564A53F39D0554akamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 19:11:09 -0000 --_000_578EBE44433F4008A8564A53F39D0554akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matt: I agree with your interpretation, in that there should be no records of any= type between the CSS and the Handshake/Finished message, even during re-ha= ndshake. The full handshake (and subsequent key material) cannot be validat= ed until the Handshake/Finished messages has been received and processed. Any AppData received between a CSS and Handshake/Finished is potentially ma= licious data trying to sneak in before the Handshake is verified; forwardin= g this data to an upper layer would be potentially harmful. A MITM would ho= pe that the data would be processed by an application before the TLS layer = receives and verifies the Handshake/Finished message. -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." On Oct 13, 2015, at 5:12 AM, Matt Caswell > wrote: Hello, Does anyone have any views on the below? Thanks Matt On 30/09/15 11:06, Matt Caswell wrote: Hi all I have a question on how to interpret RFC 5246 with regards to the interleaving of app data and handshake records. RFC 5246 (and RFC 4346 before it) contains these words: Note: Data of different TLS Record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. This wording seems to place no limits whatsoever on when it is valid to receive app data in the handshake. By the wording in the RFC it would be valid for app data to be received *after* the ChangeCipherSpec has been received but *before* the Finished has been processed. There is also this wording: Note: If a rehandshake occurs while data is flowing on a connection, the communicating parties may continue to send data using the old CipherSpec. However, once the ChangeCipherSpec has been sent, the new CipherSpec MUST be used. The first side to send the ChangeCipherSpec does not know that the other side has finished computing the new keying material (e.g., if it has to perform a time-consuming public key operation). Thus, a small window of time, during which the recipient must buffer the data, MAY exist. In practice, with modern machines this interval is likely to be fairly short. I think this means that as soon as the first party sends a CCS, they must not send any app data until they have received a CCS back - they must buffer it until the CCS is seen - but on reading it again I'm not sure! If that were the case then the second party should never expect to see app data between CCS and Finished. It doesn't tell you anything about what the first party can expect though, i.e. is the second party allowed to send app data between the CCS and Finished? Finally there is also this: A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. I suppose this trumps everything else, although as this section is specifically talking about handshakes you could interpret "immediately" as applying to the handshake sequence only without saying anything about interleaved app data records. I believe the intention is that app data should not be sent between the CCS and Finished but the RFC wording is not exactly crystal clear. This is the interpretation I have taken whilst fixing this OpenSSL bug: https://rt.openssl.org/Ticket/Display.html?id=3D3712&user=3Dguest&pass=3Dgu= est Can some confirm my interpretation is correct? Thanks Matt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_578EBE44433F4008A8564A53F39D0554akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Matt:

I agree with your interpretation, in that there should be n= o records of any type between the CSS and the Handshake/Finished message, e= ven during re-handshake. The full handshake (and subsequent key material) c= annot be validated until the Handshake/Finished messages has been received and processed.

Any AppData received between a CSS and Handshake/Finished i= s potentially malicious data trying to sneak in before the Handshake is ver= ified; forwarding this data to an upper layer would be potentially harmful.= A MITM would hope that the data would be processed by an application before the TLS layer receives and verifies = the Handshake/Finished message.

--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

On Oct 13, 2015, at 5:12 AM, Matt Caswell <frodo@baggins.org> wrote:

Hello,

Does anyone have any views on the below?

Thanks

Matt

On 30/09/15 11:06, Matt Caswell wrote:
Hi all

I have a question on how to interpret RFC 5246 with regards to the
interleaving of app data and handshake records.

RFC 5246 (and RFC 4346 before it) contains these words:

  Note: Data of different TLS Record layer content types MAY be   interleaved.  Application data is generally of lower prece= dence for
  transmission than other content types.  However, records M= UST be
  delivered to the network in the same order as they are protecte= d by
  the record layer.  Recipients MUST receive and process int= erleaved
  application layer traffic during handshakes subsequent to the f= irst
  one on a connection.

This wording seems to place no limits whatsoever on when it is valid to
receive app data in the handshake. By the wording in the RFC it would be valid for app data to be received *after* the ChangeCipherSpec has been
received but *before* the Finished has been processed.

There is also this wording:

  Note: If a rehandshake occurs while data is flowing on a connec= tion,
  the communicating parties may continue to send data using the o= ld
  CipherSpec.  However, once the ChangeCipherSpec has been s= ent, the
  new CipherSpec MUST be used.  The first side to send the   ChangeCipherSpec does not know that the other side has finished=
  computing the new keying material (e.g., if it has to perform a=
  time-consuming public key operation).  Thus, a small windo= w of time,
  during which the recipient must buffer the data, MAY exist. &nb= sp;In
  practice, with modern machines this interval is likely to be fa= irly
  short.

I think this means that as soon as the first party sends a CCS, they
must not send any app data until they have received a CCS back - they
must buffer it until the CCS is seen - but on reading it again I'm not
sure! If that were the case then the second party should never expect to see app data between CCS and Finished. It doesn't tell you anything
about what the first party can expect though, i.e. is the second party
allowed to send app data between the CCS and Finished?

Finally there is also this:

  A Finished message is always sent immediately after a change   cipher spec message to verify that the key exchange and
  authentication processes were successful.

I suppose this trumps everything else, although as this section is
specifically talking about handshakes you could interpret "immediately= "
as applying to the handshake sequence only without saying anything about interleaved app data records.

I believe the intention is that app data should not be sent between the
CCS and Finished but the RFC wording is not exactly crystal clear. This
is the interpretation I have taken whilst fixing this OpenSSL bug:

https://rt.openssl.org/Ticket/Display.ht= ml?id=3D3712&user=3Dguest&pass=3Dguest

Can some confirm my interpretation is correct?

Thanks

Matt



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

--_000_578EBE44433F4008A8564A53F39D0554akamaicom_-- From nobody Fri Oct 16 12:22:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E451B2DC7 for ; Fri, 16 Oct 2015 12:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV82mmqtEiVP for ; Fri, 16 Oct 2015 12:22:12 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (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 B54131B2A5D for ; Fri, 16 Oct 2015 12:22:07 -0700 (PDT) Received: by oiad129 with SMTP id d129so7521969oia.0 for ; Fri, 16 Oct 2015 12:22:07 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=gM+ehJZ9wuKVh5ZuXCBGrJkZ8HhRD16ASkBm5zVgIE8=; b=c6xCpfNLWHUmU5JvhtZF8SEWTqZyPuQDZML7keeNJl8xcgBylGHonMFneTg/CWSBr6 TasNBKnzq7TOBJBu2jAb8mQnqrbk3OPGv6Ln5VYyLwi4dJcd9dqSzYmzmy1qIZ9hJ2CS kGhsgroCAC1xrWkMhLHvICaUOvmODrYP0/SjK/svDMsMOjSMkWosc+Y5rS9WKuMSME0n 4TFjn3q5XORT1ipnms1f829pHyjuPW4H0xHo1jdKbmWs5N8haDcpInwJQcfQL3z1bf9O EZY3Gvq1B/3GqS1q0TzodgPATEfI44yitBtAF7jZ3/VSJYfcSXe75al6cvAQg2prVfRD N7mQ== X-Gm-Message-State: ALoCoQlPJeQbzfXYFFl31o+m4J5rIyVjjP1yoNDd1ePigLhhWSrNF3/14aOl7/ndouriBKzpNYQo MIME-Version: 1.0 X-Received: by 10.202.80.67 with SMTP id e64mr10411290oib.125.1445023327103; Fri, 16 Oct 2015 12:22:07 -0700 (PDT) Received: by 10.76.100.36 with HTTP; Fri, 16 Oct 2015 12:22:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Oct 2015 09:22:06 -1000 Message-ID: From: Brian Smith To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a113d843e1acb1805223db6a6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 19:22:15 -0000 --001a113d843e1acb1805223db6a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Karthikeyan Bhargavan wrote: > The attack we=E2=80=99re protecting against is the following: > [snip] > The key observation is that downgrade protection in TLS 1.2 (and below) > relies on the Finished MAC, but the elements that go into computing this > MAC (DH group, hash algorithm) > are themselves negotiated within the handshake and may be downgraded. Thi= s > is a fundamental protocol limitation that is addressed by TLS 1.3. Now, o= ur > goal is to protect TLS 1.3 itself > from older protocol versions. > Thanks for explaining. I think this is a good idea. Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile to protect TLS 1.2 from the downgrade too, in a similar way. Or, is there something specific about TLS 1.3 that makes the downgrade worse? > 2) Looking forward, a number of researchers would like to give a strong > security theorem for TLS 1.3, but at present we would not be able to > guarantee security for any TLS 1.3 implementation > that also implements older protocol versions, because we would then > also have to prove secure all the ciphersuites used in these old versions > (some of which are certainly broken from the > point of view of provable security). For our proofs, we=E2=80=99d lik= e nothing > better than to be able to assume that older versions of TLS have been > disabled, but I guess that is unlikely to happen soon. > No doubt it is more interesting to work on TLS 1.3. But, I think that it would also be useful to have such work done, insofar as it is possible, for at least a subset of TLS 1.2--e.g. the subset that is used in DICE, which prescribes TLS 1.2. I understand that the people working on proofs for TLS 1.3 may not be the same ones that might undertake the work for TLS 1.2. Cheers, Brian --=20 https://briansmith.org/ --001a113d843e1acb1805223db6a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kart= hikeyan Bhargavan <karthik.bhargavan@gmail.com> wr= ote:
The attack we=E2=80=99re protecting = against is the following:
[snip]

The key observation is that downgrade protection in = TLS 1.2 (and below) relies on the Finished MAC, but the elements that go in= to computing this MAC (DH group, hash algorithm)
are themselves negotiated within the handshake and may be downgraded. This = is a fundamental protocol limitation that is addressed by TLS 1.3. Now, our= goal is to protect TLS 1.3 itself
from older protocol versions.

Thanks fo= r explaining. I think this is a good idea.

Why onl= y protect TLS 1.3 from such a downgrade? I think it is worthwhile to protec= t TLS 1.2 from the downgrade too, in a similar way. Or, is there something = specific about TLS 1.3 that makes the downgrade worse?
=C2=A0
2) Looking forward, a number of researcher= s would like to give a strong security theorem for TLS 1.3, but at present = we would not be able to guarantee security for any TLS 1.3 implementation =C2=A0 =C2=A0 that also implements older protocol versions, because we woul= d then also have to prove secure all the ciphersuites used in these old ver= sions (some of which are certainly broken from the
=C2=A0 =C2=A0 point of view of provable security). For our proofs, we=E2=80= =99d like nothing better than to be able to assume that older versions of T= LS have been disabled, but I guess that is unlikely to happen soon.

No doubt it is more interesting to work on TLS= 1.3. But, I think that it would also be useful to have such work done, ins= ofar as it is possible, for at least a subset of TLS 1.2--e.g. the subset t= hat is used in DICE, which prescribes TLS 1.2. I understand that the people= working on proofs for TLS 1.3 may not be the same ones that might undertak= e the work for TLS 1.2.

Cheers,
Brian
--
--001a113d843e1acb1805223db6a6-- From nobody Fri Oct 16 12:49:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669D21B337E for ; Fri, 16 Oct 2015 12:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 2HLFhYYev5zO for ; Fri, 16 Oct 2015 12:49:00 -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 368181B337B for ; Fri, 16 Oct 2015 12:49:00 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 31CCC43341C; Fri, 16 Oct 2015 19:48:59 +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 1BDA5433409; Fri, 16 Oct 2015 19:48:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445024939; bh=GdBwgiYgkh6gWEzdAjDYO72alw6PpEe0JL40+xYM1ls=; l=919; h=To:References:Cc:From:Date:In-Reply-To:From; b=Rp7C0GwviFFY/v6Yr8rKl/FOet7O+J5PRzDw4JdO7L6PJiAKNUViqadoKdEtbRpP0 P6gQs7/FUqj8OMHNobGnAdJQ4rV7PmipaoSilhQU+Rl35t0zwY6pOgixVJldVt9fBT N0sLrXQrY1KDJAuiJVM3F86gCsbfRGMAZRUA7P3E= 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 CB2042044; Fri, 16 Oct 2015 19:48:58 +0000 (GMT) To: Paul Wouters , Rick van Rein References: <56212653.6050702@openfortress.nl> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <562154AA.2070704@akamai.com> Date: Fri, 16 Oct 2015 14:48:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 19:49:01 -0000 On 10/16/2015 01:48 PM, Paul Wouters wrote: > On Fri, 16 Oct 2015, Rick van Rein wrote: > >> 3) Similar to OpenPGP: Negotiate cert-type >> >> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos >> Tickets. >> >> PRO: Good integration with TLS: Tickets are transported in the >> ClientCertificate, and an Authenticator is the ClientVerify. DH is >> independent and can move to the earlier phase for TLS 1.3. > > How is this type of TLS connection prevented from being MITM'ed by > someone replaying kerberos tickets (which it cannot read itself) I think it is not, if the Kerberos and DH parts are completely orthogonal [and the Kerberos exchange is not mixed into the master secret other than via the session hash]. Having the authenticator include the DH public value or mixing the Kerberos session key into the master secret are two options that come to mind right away. -Ben From nobody Fri Oct 16 13:04:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D551B33A4 for ; Fri, 16 Oct 2015 13:04:25 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHwkWx84RkhX for ; Fri, 16 Oct 2015 13:04:24 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 378B01B33A5 for ; Fri, 16 Oct 2015 13:04:24 -0700 (PDT) Received: by ykfy204 with SMTP id y204so95259796ykf.1 for ; Fri, 16 Oct 2015 13:04: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:date:message-id:subject:from:to :cc:content-type; bh=JyR094bCLG3m+Ge5XO+KUymXjThwe3lLuw9/J3AciiQ=; b=mjQTghYHNbUBaCEBo88+Mzp7LX+dbBd6wCOfH3aRHMJrosRQpxMNdCsipqC47uwrLI A6bPIfL9maJ5IEp/y95T6YuOm2iLfIK/Xii/O0p+DJsSabrLEQC5ITw4hV34THi/M9Qp YIw9MekexHMFfqMDX0+8xEalJc9YczGyFhYymskSdtLF1DFZQEMd5cOmmm7ZJF2XF4nS wF3ED15OdSyCP7U6iJUa3NQXeehG58QB/+383VuaVPe7FlKlh3x5blRvaC4QKNPk2SNK sLBEkD/RcyS2XYbGrLALP/Ths61whgCvsgdnlrHDvOUu4RTbnAuCLEOR/nAuo6cAQ/kT 2kHA== MIME-Version: 1.0 X-Received: by 10.13.196.196 with SMTP id g187mr13046375ywd.98.1445025863555; Fri, 16 Oct 2015 13:04:23 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Fri, 16 Oct 2015 13:04:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Oct 2015 13:04:23 -0700 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 20:04:25 -0000 On 16 October 2015 at 12:22, Brian Smith wrote: > Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile to > protect TLS 1.2 from the downgrade too, in a similar way. Or, is there > something specific about TLS 1.3 that makes the downgrade worse? Given that we can't expect TLS 1.2 servers to implement the hack, I'm not sure that this is of great utility, but if we can bake a version number in there, I'm not opposed to the notion. From nobody Fri Oct 16 13:36:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BB31A0423 for ; Fri, 16 Oct 2015 13:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9mrz3jl0jUZ for ; Fri, 16 Oct 2015 13:35:57 -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 90A2F1A03E3 for ; Fri, 16 Oct 2015 13:35:57 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 12FD7A8A0CF3; Fri, 16 Oct 2015 20:35:55 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 868621FE0152; Fri, 16 Oct 2015 22:36:10 +0200 (CEST) Date: Fri, 16 Oct 2015 22:36:10 +0200 From: Kurt Roeckx To: Hubert Kario Message-ID: <20151016203610.GA5596@roeckx.be> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <561FA62C.9030801@baggins.org> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 20:35:59 -0000 On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote: > On Friday 16 October 2015 09:16:01 Watson Ladd wrote: > > Unfortunately I don't know how to verify this. Can miTLS cover this > > case? > > you mean, you want an implementation that can insert application data in > any place of the handshake? Have you tried running any of your tests against miTLS? Kurt From nobody Fri Oct 16 13:39:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02BB1A06E9 for ; Fri, 16 Oct 2015 13:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb7kFgma9IMr for ; Fri, 16 Oct 2015 13:39:25 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (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 A69EF1A1A3C for ; Fri, 16 Oct 2015 13:39:25 -0700 (PDT) Received: by oiev17 with SMTP id v17so23241642oie.2 for ; Fri, 16 Oct 2015 13:39:25 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=sAp3baoZgWhU8RIgrca4V24YGY11D1b0NMAUl0R/2LQ=; b=W0qtADPYPj0ARmqDsoZC12WFcK+HTazreETziKlR+RoczqaYphMyhzwlX6VajNJasE iPyOnatz9x3Zv8CWPbrCJrfJWfnJnre5FbXBx5pPl0wtZdAjHc4ojr4VpseH4AxcLN01 yR+fxdQQWTbVwBtTbDRMdHycgDx1431hvthL3xoTQwrR8HH59JZGZ1gDBC/xHPkCubhl lxBzZx/qhuj+5SJau/jCrcWkgkGd34LQ5G7rVB2wr0uLYNMkc42F2vbl/LsN1hsBi+Sb f6EC4FDmLPF7hDn701ecg4wpbl/MFRUrmbsX9lfzuNah8OSECaQ2BBv/h7DPBLS+KvHp cnYQ== X-Gm-Message-State: ALoCoQkHJLMx0oGGGbQFoP7w2EufuXM56DyVZaUXuzNidwlxlwcHOo2+6V4nhWLqa5hhLAmPe4WP MIME-Version: 1.0 X-Received: by 10.202.174.80 with SMTP id x77mr10484772oie.50.1445027964938; Fri, 16 Oct 2015 13:39:24 -0700 (PDT) Received: by 10.76.100.36 with HTTP; Fri, 16 Oct 2015 13:39:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Oct 2015 10:39:24 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113ce8ce8a86b805223eca48 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 20:39:29 -0000 --001a113ce8ce8a86b805223eca48 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 16, 2015 at 10:04 AM, Martin Thomson wrote: > On 16 October 2015 at 12:22, Brian Smith wrote: > > Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile > to > > protect TLS 1.2 from the downgrade too, in a similar way. Or, is there > > something specific about TLS 1.3 that makes the downgrade worse? > > Given that we can't expect TLS 1.2 servers to implement the hack, I'm > not sure that this is of great utility, but if we can bake a version > number in there, I'm not opposed to the notion. > I think TLS 1.2 servers would implement the mechanism, if it were documented in an update to the downgrade-scsv document. I mean, this mechanism is basically a replacement for the downgrade-scsv mechanism, because the downgrade-scsv mechanism doesn't (at least, can't be proven) to work, right? That would be especially true for an implementation that does False Start for TLS 1.2. Cheers, Brian -- https://briansmith.org/ --001a113ce8ce8a86b805223eca48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 16, 2015 at 10:04 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 16 Oc= tober 2015 at 12:22, Brian Smith <brian@briansmith.org> wrote:
> Why only protect TLS 1.3 from such a downgrade? I think it is worthwhi= le to
> protect TLS 1.2 from the downgrade too, in a similar way. Or, is there=
> something specific about TLS 1.3 that makes the downgrade worse?

Given that we can't expect TLS 1.2 servers to implement the hack= , I'm
not sure that this is of great utility, but if we can bake a version
number in there, I'm not opposed to the notion.

I think TLS 1.2 servers would implement the mechanis= m, if it were documented in an update to the downgrade-scsv document. I mea= n, this mechanism is basically a replacement for the downgrade-scsv mechani= sm, because the downgrade-scsv mechanism doesn't (at least, can't b= e proven) to work, right? That would be especially true for an implementati= on that does False Start for TLS 1.2.

<= /div>
Cheers,
Bri= an
--
--001a113ce8ce8a86b805223eca48-- From nobody Fri Oct 16 14:13:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B149C1A004A for ; Fri, 16 Oct 2015 14:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUx-LHjaKePa for ; Fri, 16 Oct 2015 14:13:24 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (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 7A0CD1A002A for ; Fri, 16 Oct 2015 14:13:24 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9GLDN4F014568; Fri, 16 Oct 2015 17:13:23 -0400 Date: Fri, 16 Oct 2015 17:13:23 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Rick van Rein Message-ID: <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> In-Reply-To: <56212653.6050702@openfortress.nl> References: <56212653.6050702@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.182] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF38 (Linux)/8.0.6_GA_5922) Thread-Topic: Design Alternatives for Kerberos + DH Thread-Index: f0dZjKwTCgL0b26bbJDDzf8VwfTS4A== Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 21:13:25 -0000 ----- Original Message ----- > Hello, > 3) Similar to OpenPGP: Negotiate cert-type > > There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets. > PRO: Good integration with TLS: Tickets are transported in the > ClientCertificate, and an Authenticator is the ClientVerify. DH is > independent and can move to the earlier phase for TLS 1.3. > CON: Decision on client credential type must be made in ClientHello, when not > all data may be available (namely, the sequence of tickets leading to the > TLS-protected service). Also impacts the cert-type used in the ServerCert. What messages do you need to transfer for Kerberos? Is it only a ping-pong? In that case, do the supplemental data from RFC4680 provide a solution with PSK in TLS 1.2? regards, Nikos From nobody Fri Oct 16 14:34:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82231B2C32 for ; Fri, 16 Oct 2015 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAGwpKKdgYmU for ; Fri, 16 Oct 2015 14:33:53 -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 EC0D61B3413 for ; Fri, 16 Oct 2015 14:33:44 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0530F433517; Fri, 16 Oct 2015 21:33: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 E3325433516; Fri, 16 Oct 2015 21:33:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445031223; bh=C0G12fDohob04CfP/QMy4BYvdy7oD6Sq8qpCBL8TwtM=; l=1912; h=To:References:Cc:From:Date:In-Reply-To:From; b=IVBy/a946+JfHV22A7CX2v0zFSDxkH9BwolZ3DC4DdygBslYeqTyuPmydLV1WkX7R 22QYFRi+S0zEMBsWa6aCtvozwnyX1cJibgK6OOeYbBUjP/c+s0ENQA07m+suFnwlBC zby37N8NDsMp0rcvibZke/1F2Ro90nw9Yo6pzVF0= 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 A691F204E; Fri, 16 Oct 2015 21:33:43 +0000 (GMT) To: Nikos Mavrogiannopoulos , Rick van Rein References: <56212653.6050702@openfortress.nl> <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <56216D37.1050701@akamai.com> Date: Fri, 16 Oct 2015 16:33:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 21:34:01 -0000 On 10/16/2015 04:13 PM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- >> Hello, >> 3) Similar to OpenPGP: Negotiate cert-type >> >> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets. >> PRO: Good integration with TLS: Tickets are transported in the >> ClientCertificate, and an Authenticator is the ClientVerify. DH is >> independent and can move to the earlier phase for TLS 1.3. >> CON: Decision on client credential type must be made in ClientHello, when not >> all data may be available (namely, the sequence of tickets leading to the >> TLS-protected service). Also impacts the cert-type used in the ServerCert. > > What messages do you need to transfer for Kerberos? Is it only a ping-pong? In that > case, do the supplemental data from RFC4680 provide a solution with PSK in TLS 1.2? > 4680 says "[a]ny such data MUST NOT need to be processed by the TLS protocol.", which seems to disqualify it from applicability here. In any case, the messages needed for Kerberos vary somewhat depending on the desired properties. When using Kerberos solely for client authentication, the combination of a Ticket and Authenticator is valid as essentially a bearer token within the clock skew window of five minutes and subject to replay. The client (or server, or both) can pick a subsession key encrypted by the session key in the Ticket, and if another message is passed that uses a subsession key for confidentiality/integrity (such as a response from the server to perform "mutual" (i.e., server) authentication, then there is less need for a replay cache. An additional key-confirmation message to validate the server-selected subsession key (such as actual application traffic being encrypted in that key) is helpful for the security analysis, but not always available depending on the constraints of the application protocol. -Ben From nobody Fri Oct 16 15:12:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3A31B3454 for ; Fri, 16 Oct 2015 15:12: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em9zd4DXSSJa for ; Fri, 16 Oct 2015 15:12:20 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002: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 CD3571B3452 for ; Fri, 16 Oct 2015 15:12:19 -0700 (PDT) Received: by yknn9 with SMTP id n9so46995531ykn.0 for ; Fri, 16 Oct 2015 15:12: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:date:message-id:subject:from:to :cc:content-type; bh=HB6OeOyzN8OhVbRZ9ZYYEo+lsJLNqJ09uyA8CyDVp0U=; b=O3htyF2g8LJtF4OB3rZHeV1EfDlIrTSteV8ukaQeNrGBLMi/8wSP9MIKQY2wF8x8Eu l14a8wFS+zKdqL5d5Xb/HikkF9V99h2yLx0jNoK7CML7wCMm9UOehiujipMIuIgYWQ6D QRuNU3ezxbuqGPGYJPSGJJQtOz+AsmVqTFN3k+/M59DwwZKNLCaf70bxZhQFRPF+f8fW mroDdG5h6JGJIwvrfOARbZ6ppflXra3O4eZY2WfHAIMW9soRWJy3dp6iZi4sS9AjVuFn QUNxcoPNPF1OVM0L6rtXKXii/rti0Za8Vli1QcKQzaeTIdmhdfphuLjj+cKRM3kJ/NX/ yxzw== MIME-Version: 1.0 X-Received: by 10.129.80.5 with SMTP id e5mr4429476ywb.105.1445033539086; Fri, 16 Oct 2015 15:12:19 -0700 (PDT) Received: by 10.13.230.78 with HTTP; Fri, 16 Oct 2015 15:12:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Oct 2015 15:12:18 -0700 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 22:12:23 -0000 On 16 October 2015 at 13:39, Brian Smith wrote: > That would be especially true for an implementation that does False Start > for TLS 1.2. I don't see how false start plays into this. We could have clients reject false start if they see this sentinel value. But don't we want to just treat this as an attack and abort instead? From nobody Fri Oct 16 15:34:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605E81A6FB9 for ; Fri, 16 Oct 2015 15:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge00ILQ9MzLi for ; Fri, 16 Oct 2015 15:34:30 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (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 CD74E1A6FA0 for ; Fri, 16 Oct 2015 15:34:29 -0700 (PDT) Received: by obbda8 with SMTP id da8so101811296obb.1 for ; Fri, 16 Oct 2015 15:34:29 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=A43psK8Nso2sK7mjnHpnKQ3ny74Atsm3m5GO+xhnY+8=; b=K2VtlIwD43Dz3jTIWGs64LvgSCDS157mZd56uQoY9YGvGT+6ECLn957ukjeph8CBqd 6VkXR1ztFjTddmqsg5/1s/OE9caoauUrWxVS3lX//GjjBVyOxncmKsqJZbHtmOHT/X6l uIeDIApqbhM6zH4XiT/RQdkyC7Grn7teAtCrRz0EhimyY/DluQ8kHR/3SldxUYcNVyxc 7EVBJjoCcf3SGOBW5CDBvpI06hVM75uUORyLaCusAxldugcndLoLyhBR5x+yK5Ydu4RK m53lqgxOuDTbvGK+uX3wGv/QPmuOPQGygkscubwhfaGZQtscs9UHVhRXSxBGcV4p7TUJ jN6w== X-Gm-Message-State: ALoCoQkZboi7G5NbjcUjV7k4NobMchCZWo/WJa7ppHApkPTY9iWd5m4i81TCmMtHh0IlCWTC9cZW MIME-Version: 1.0 X-Received: by 10.60.70.40 with SMTP id j8mr11163939oeu.78.1445034869095; Fri, 16 Oct 2015 15:34:29 -0700 (PDT) Received: by 10.76.100.36 with HTTP; Fri, 16 Oct 2015 15:34:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Oct 2015 12:34:28 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11330ab40f9b9d0522406638 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2015 22:34:31 -0000 --001a11330ab40f9b9d0522406638 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson wrote: > On 16 October 2015 at 13:39, Brian Smith wrote: > > That would be especially true for an implementation that does False Start > > for TLS 1.2. > > I don't see how false start plays into this. We could have clients > reject false start if they see this sentinel value. But don't we want > to just treat this as an attack and abort instead? > Yes. The client needs the sentinel to know to abort the connection, if its willing to false start with TLS 1.2 when it also support TLS 1.3, right? Cheers, Brian -- https://briansmith.org/ --001a11330ab40f9b9d0522406638 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 16, 2015 at 12:12 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 16 October 2015 at 13:39, Brian Smith <brian@briansmith.org> wrote:
> That would be especially true for an implementation that does False St= art
> for TLS 1.2.

I don't see how false start plays into this.=C2=A0 We could have= clients
reject false start if they see this sentinel value.=C2=A0 But don't we = want
to just treat this as an attack and abort instead?

Yes. The client needs the sentinel to know to abort = the connection, if its willing to false start with TLS 1.2 when it also sup= port TLS 1.3, right?

Ch= eers,
Brian
--
--001a11330ab40f9b9d0522406638-- From nobody Fri Oct 16 23:23:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5C1A802A for ; Fri, 16 Oct 2015 23:23:35 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBkS0YrRBIFS for ; Fri, 16 Oct 2015 23:23:33 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 4871B1A711A for ; Fri, 16 Oct 2015 23:23:33 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so33738657wic.1 for ; Fri, 16 Oct 2015 23:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vXgk85iaBQNRscK/TSzAwIz4SnT7n+czlbXYqKUu/q0=; b=VwED1glaaaRpJEsn2r3MScPIdrJvh5w5UI2gCKvnnhb33WjzIWHwakAnqoAzE+vHzN SBx2IL/GmdMcaSkoN1lAJEjwH5OEP39nLFR2eXycQunTJGxtLDMyx0jbe9gZMcK0VbTc S9pdKJnILAjPgTwfaC+7s+zzC2QSVpixZqpE2cADpNk633jjFPuYZWszAkJh09Jo1xKR 5G8ziPmiTHL6Y0oLnH8+i3KAt/5BoY9mEb1KmL+14wF17JOtYqixCAlQykfS6pC9lr6i GJugsHF1Y2ztKo0zl8MpNTCtbnjkMx/1jwyMWT827A6zwNF0YBBGqaoiDw7W6ziM2bGS ZJtw== X-Received: by 10.180.102.195 with SMTP id fq3mr8949227wib.7.1445063011552; Fri, 16 Oct 2015 23:23:31 -0700 (PDT) Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id cc8sm26532562wjc.46.2015.10.16.23.23.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Oct 2015 23:23:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D6968D6-A549-40CE-83F8-54126E2F1657" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Sat, 17 Oct 2015 08:23:29 +0200 Message-Id: <02BF1D46-DC94-4D4C-B0E6-5FE0E7D7F95B@gmail.com> References: To: Brian Smith X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 06:23:35 -0000 --Apple-Mail=_1D6968D6-A549-40CE-83F8-54126E2F1657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, yes, the mechanism proposed here could also be used by TLS 1.2 implementations to signal each other about their preferred connection = parameters. To make most use of the bytes provided, one could use the sentinel value = to indicate=20 support for an extension, which then carries a signed server = configuration of arbitrary size.=20 The attacker would then be unable to downgrade the connection by = deleting this extension. False Start is an interesting use case, because=20 (a) it sends data before the server has confirmed the chosen = version/ciphersuite/etc and=20 (b) it already tries to prevent downgrades by whitelisting versions and = ciphersuites.=20 Some downgrade attacks fail because of (b), but others are easier to = exploit because of (a). For example, Logjam was easier to mount on False Start clients since the = attacker could=20 collect the False Start data and decrypt it at leisure. =20 Extended master secret (EMS) provides some additional protection to = False Start, because the encryption keys implicitly include the full handshake transcript and, so if the = MitM tampers with the connection, the False Start data would not be accepted by a server. (However, that = this would not have prevented Logjam.) Moreover, even the EMS extension can be deleted by a MitM.=20 The current proposal could protect EMS from downgrade by indicating = support for it in the server hello. To sum up, we=E2=80=99re focusing on TLS 1.3 because we have a chance to = bake in strong downgrade protection into its implementations from the very beginning. I think this could be = useful for older versions too, as an optional mechanism which protects clients and servers that both implement it, and = does not affect others. -Karthik > On 17 Oct 2015, at 00:34, Brian Smith wrote: >=20 > On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson = > wrote: > On 16 October 2015 at 13:39, Brian Smith > wrote: > > That would be especially true for an implementation that does False = Start > > for TLS 1.2. >=20 > I don't see how false start plays into this. We could have clients > reject false start if they see this sentinel value. But don't we want > to just treat this as an attack and abort instead? >=20 > Yes. The client needs the sentinel to know to abort the connection, if = its willing to false start with TLS 1.2 when it also support TLS 1.3, = right? >=20 > Cheers, > Brian > --=20 > https://briansmith.org/ >=20 --Apple-Mail=_1D6968D6-A549-40CE-83F8-54126E2F1657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Brian, yes, the mechanism proposed here = could also be used by TLS 1.2
implementations to = signal each other about their preferred connection parameters.

To make most use of the = bytes provided, one could use the sentinel value to = indicate 
support for an extension, which then = carries a signed server configuration of arbitrary size. 
The attacker would then be unable to downgrade the connection = by deleting this extension.

False Start is an interesting use case, = because 
(a) it sends data before the server = has confirmed the chosen version/ciphersuite/etc and 
(b) it already tries to prevent downgrades by whitelisting = versions and ciphersuites. 
Some downgrade = attacks fail because of (b), but others are easier to exploit because of = (a).
For example, Logjam was easier to mount on = False Start clients since the attacker could 
collect the False Start data and decrypt it at leisure. =  

Extended = master secret (EMS) provides some additional protection to False Start, = because the encryption
keys implicitly include the = full handshake transcript and, so if the MitM tampers with the = connection,
the False Start data would not be = accepted by a server. (However, that this would not have prevented = Logjam.)
Moreover, even the EMS extension can be = deleted by a MitM. 
The current proposal could = protect EMS from downgrade by indicating support for it in the server = hello.

To sum = up, we=E2=80=99re focusing on TLS 1.3 because we have a chance to bake = in strong downgrade protection
into its = implementations from the very beginning. I think this could be useful = for older versions too, as an optional
mechanism = which protects clients and servers that both implement it, and does not = affect others.

-Karthik

On 17 Oct 2015, at 00:34, Brian Smith <brian@briansmith.org> wrote:

On Fri, = Oct 16, 2015 at 12:12 PM, Martin Thomson <martin.thomson@gmail.com> = wrote:
On = 16 October 2015 at 13:39, Brian Smith <brian@briansmith.org> wrote:
> That would be especially true for an implementation that does False = Start
> for TLS 1.2.

I don't see how false start plays into this.  We could have = clients
reject false start if they see this sentinel value.  But don't we = want
to just treat this as an attack and abort instead?

Yes. The client needs the sentinel to = know to abort the connection, if its willing to false start with TLS 1.2 = when it also support TLS 1.3, right?

Cheers,
Brian
--
https://briansmith.org/


= --Apple-Mail=_1D6968D6-A549-40CE-83F8-54126E2F1657-- From nobody Fri Oct 16 23:36:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C90D1A8762 for ; Fri, 16 Oct 2015 23:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Th_6x7TBEX8 for ; Fri, 16 Oct 2015 23:36:30 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D941A8761 for ; Fri, 16 Oct 2015 23:36:29 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id W6cQ1r00E10HQrX016cSip; Sat, 17 Oct 2015 08:36:27 +0200 Message-ID: <5621EC66.7050104@openfortress.nl> Date: Sat, 17 Oct 2015 08:36:22 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Paul Wouters References: <56212653.6050702@openfortress.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 06:36:32 -0000 Hello Paul, >> 3) Similar to OpenPGP: Negotiate cert-type >> >> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos >> Tickets. > > How is this type of TLS connection prevented from being MITM'ed by > someone replaying kerberos tickets (which it cannot read itself) In Kerberos, the KDC-generated and client-cached Tickets are always sent with an additional Authenticator; this is client-signed message that is generated while sending and holds a timestamp to the ms level. The combination is rejected when the timestamp is more off than a small clock skew window at the server. Replay is avoided in Kerberos by observing the Authenticator's uniqueness within that small window. This however, has scaling problems, for instance in redundant server farms. An Authenticator can hold a "checksum", which is a hash nowadays. We can use this field to store a hash of the prior TLS messages, including the ECDH exchange and ServerRandom. This is already done by default in the ClientVerify, so nothing special needs to be done for that. The hashes are typed, with an IANA registry; unkeyed hashes are possible, though none beyond SHA1 appears to have been needed for its current uses, but we can expand that. Finally, the pre-master secret for all four design alternatives consists of the ECDH session key and the session key exchanged by the Ticket. Replay of ECDH is impossible if the server continually refreshes its offers, at least not to be repeated within the clock skew window, which has been a major focus point in my 00 draft. Lacking the session key, an attacker that attempts replay of a Ticket will not be able to generate the proper Finished messages. FWIW, I am proposing to extend the sizes of those hashes. Thanks, -Rick From nobody Fri Oct 16 23:48:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB501A8839 for ; Fri, 16 Oct 2015 23:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqx2j433uHD3 for ; Fri, 16 Oct 2015 23:48:20 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5041A8838 for ; Fri, 16 Oct 2015 23:48:19 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id W6oH1r00210HQrX016oJVW; Sat, 17 Oct 2015 08:48:18 +0200 Message-ID: <5621EF30.8040300@openfortress.nl> Date: Sat, 17 Oct 2015 08:48:16 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Benjamin Kaduk References: <56212653.6050702@openfortress.nl> <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> <56216D37.1050701@akamai.com> In-Reply-To: <56216D37.1050701@akamai.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 06:48:21 -0000 Hello, >> What messages do you need to transfer for Kerberos? Is it only a ping-pong? Yes, the plan is to send a Ticket + Authenticator and since the server cannot send "pong", to use the (elongated) "Finished" message to replace the validating function of the "pong". > The client (or server, or both) can pick > a subsession key encrypted by the session key in the Ticket, Currently, only the client could do this. We might pile the subsession key into the pre-master secret if we decide that it adds to security. If we really want the server to send one too, it might send a random string of the right size, and it could be decrypted to a key. That's possible with symmetric algorithms after all... and after receiving the Ticket, the server can do the same to discover its secret subsession key :) > if > another message is passed that uses a subsession key for > confidentiality/integrity (such as a response from the server to perform > "mutual" (i.e., server) authentication, then there is less need for a > replay cache. The key idea in 00 was to not use a subsession key but instead rely on Diffie-Hellman for the same function, to avoid replay caches. Because a replay cache would be a devastating part of a TLS infrastructure that could block these CipherSuites from being rolled out. > An additional key-confirmation message to validate the > server-selected subsession key (such as actual application traffic being > encrypted in that key) is helpful for the security analysis, but not > always available depending on the constraints of the application protocol. It still surprises me, but Kerberos is able to send a message one-way and achieve mutual authentication. The trick is of course that prior key exchanges have setup links that make this possible. That's already been taken care of in client apps and libraries, so I'm trying to make good use of it in TLS. -Rick From nobody Sat Oct 17 00:21:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470601A8A6D for ; Sat, 17 Oct 2015 00:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_82=0.6, SPF_PASS=-0.001] autolearn=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 Ta6QConcPzw6 for ; Sat, 17 Oct 2015 00:20:58 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450: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 949CF1A8A6C for ; Sat, 17 Oct 2015 00:20:58 -0700 (PDT) Received: by wicll6 with SMTP id ll6so37928777wic.1 for ; Sat, 17 Oct 2015 00:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:mime-version:content-type:in-reply-to:date:cc :message-id:references:to; bh=mCJeSPj0ynfW/tQGfnzPWrwgxkh6ZZb/mZbaTedmA5A=; b=kYsdE7QLZO0apILBi8QBT/es4SHOolePdc9HCQtCaLokqHzBqhGLhHBncdoz7yrZka mS7PamDtAiLgHGdCQto8X3poa18a4H7P9LRfiAeOgwReZqjnOndcE99b2VWSveRE688R hwWlDxq3aeI2tgpoAGEoqBLIf8vmZIZ6exKb6Qq90F3de/gj1Ij0Lh9jm5tCwFKOrXV6 ULNSBR/BLV+iBBafvHBm0+l00Dkk0s4/Gr0Y5xJe31FORaXWCU/SW6CqZcuWRUYpvoVy jxlK4c7L64iHVILaikXFx2gYYUngljA4diCLaoLrxkskJSGzj5huFpLM2qUXd6E8RwUl 7IdA== X-Received: by 10.180.207.235 with SMTP id lz11mr9359110wic.1.1445066457222; Sat, 17 Oct 2015 00:20:57 -0700 (PDT) Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id r15sm6044457wib.18.2015.10.17.00.20.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 00:20:56 -0700 (PDT) From: Karthikeyan Bhargavan X-Google-Original-From: Karthikeyan Bhargavan Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_609FFEDF-2624-45B8-81C8-CFBF557248D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 In-Reply-To: <56212653.6050702@openfortress.nl> Date: Sat, 17 Oct 2015 09:20:55 +0200 Message-Id: References: <56212653.6050702@openfortress.nl> To: Rick van Rein X-Mailer: Apple Mail (2.2104) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 07:21:00 -0000 --Apple-Mail=_609FFEDF-2624-45B8-81C8-CFBF557248D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 2) Embed the Ticket + Authenticator in a PSK I don=E2=80=99t fully understand the constraints of the Kerberos+DH = use-case, but using DHE-PSK seems like the best idea. The planned session resumption mechanism for TLS 1.3 also uses DHE-PSK, = and uses a session ticket mechanism that is not so far from the Kerberos ticket. The Kerberos session key = would then get mixed in (as a semi-static secret) to the ECDHE shared secret and both client and server would obtain = mutual authentication (based on the Kerberos key). It may be best to try and fit Kerberos into this existing mechanism, = unless there is some fundamental incompatibility. Best, Karthik >=20 > This uses the binary blurb of the PSK to wrap the Ticket and = Authenticator. >=20 > PRO: Client authenticates very early, in the ClientHello. >=20 > CON: PSK is untyped, so it requires separate agreement on the = contents. It is impossible to incorporate ServerHello information in = the exchange. The server has not indicated if it supports Kerberos, so = the client must make a leap of faith. PSK replies the selected PSK = identifier, rather than send a response message; it is not designed for = messaging purposes. >=20 >=20 > 3) Similar to OpenPGP: Negotiate cert-type >=20 > There is a cert-type for X.509 and for OpenPGP; add one for Kerberos = Tickets. >=20 > PRO: Good integration with TLS: Tickets are transported in the = ClientCertificate, and an Authenticator is the ClientVerify. DH is = independent and can move to the earlier phase for TLS 1.3. >=20 > CON: Decision on client credential type must be made in ClientHello, = when not all data may be available (namely, the sequence of tickets = leading to the TLS-protected service). Also impacts the cert-type used = in the ServerCert. >=20 >=20 > 4) Define an X.509 embedding for Tickets >=20 > Certificates provide an id/key binding with a signature by a trusted = party; although the AlgorithmIdentifiers used here are new, they do fit = in the X.509 framework. This is rather out-of-the-box thinking, so I = tested the idea, see https://github.com/arpa2/kerberos2pkix >=20 > PRO: Minimal changes to TLS, since Kerberos is now a signing = algorithm. The server can independently authenticate using RSA & co (on = top of Kerberos' mutual authentication). Ticket + = timestamp-Authenticator go into an X.509 ClientCertificate, and an = Authenticator including the hash over prior TLS messages can go into = ClientVerify. CertificateRequest can mix options for Kerberos, RSA, and = so on, and client selects whatever it can get to locally, giving the = best user experience. We can also support user-to-user connections and = S4U2Proxy a.k.a. "Constrained Delegation". >=20 > CON: These certificates are symmetrically keyed, which is uncommon. = Certificates are not readable to anyone, but only to the remote peer. = Certificate owner is ideally read from the embedded ticket, rather than = from the subject field. >=20 >=20 > My money is on the last two, but option 4. really needs feedback = because it is a bit wild. When I get an idea where to go, I will be = happy to write a new draft version... a much smaller and simpler one = this time! >=20 > Cheers, > -Rick >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_609FFEDF-2624-45B8-81C8-CFBF557248D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWIfbXAAoJEB/WSo9veuUKvU4H/3kkBgf/V6+ParugeVNZgQkJ B0cQmpjrTrgauo5rwI4YyeckXH9Jn1qGmbh5lCmJe4vvzbLLt07BUbdZeBraxzXP xCyTqOTU2GU+bYJqfVZ4ORU/EBalsaEcgtb/aDVP/aMAnYlE01txY4g/XXPR/eG2 ABJQNKB5MuKICCk61zxg3fRfoLv5AKvWyDuU6Pf+jqaZfRAOb8nk/Z4bc/lR6/fd v8RtfwRxHzdMedHm6Kp74F8i7nqrHuU67mcO9MsU8K1T/B/gbL2BvnZPUy0meysS Z1+pfp1dzz+rOfSUy1+dNKLlyNFQ9F8wjpBjfYzICXn2bexm+cPdpS8Zmqp7l/A= =16Ql -----END PGP SIGNATURE----- --Apple-Mail=_609FFEDF-2624-45B8-81C8-CFBF557248D3-- From nobody Sat Oct 17 00:33:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16701A8AB4 for ; Sat, 17 Oct 2015 00:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8nMdctFr3Hr for ; Sat, 17 Oct 2015 00:33:40 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (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 A82151A8A72 for ; Sat, 17 Oct 2015 00:33:40 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9H7XcAs031751; Sat, 17 Oct 2015 03:33:38 -0400 Date: Sat, 17 Oct 2015 03:33:37 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Benjamin Kaduk Message-ID: <877054424.34248008.1445067217270.JavaMail.zimbra@redhat.com> In-Reply-To: <56216D37.1050701@akamai.com> References: <56212653.6050702@openfortress.nl> <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> <56216D37.1050701@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.181] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF38 (Linux)/8.0.6_GA_5922) Thread-Topic: Design Alternatives for Kerberos + DH Thread-Index: 2yfCy7jLi6aMc5EOfg0XFQ5i4QN1ng== Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 07:33:42 -0000 > ----- Original Message ----- >>> Hello, >>> 3) Similar to OpenPGP: Negotiate cert-type >>> >>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets. >>> PRO: Good integration with TLS: Tickets are transported in the >>> ClientCertificate, and an Authenticator is the ClientVerify. DH is >>> independent and can move to the earlier phase for TLS 1.3. >>> CON: Decision on client credential type must be made in ClientHello, when not >>> all data may be available (namely, the sequence of tickets leading to the >>> TLS-protected service). Also impacts the cert-type used in the ServerCert. >> >> What messages do you need to transfer for Kerberos? Is it only a ping-pong? In that >> case, do the supplemental data from RFC4680 provide a solution with PSK in TLS 1.2? >> > 4680 says "[a]ny such data MUST NOT need to be processed by the TLS > protocol.", which seems to disqualify it from applicability here. That's interesting and open to interpretation, but I don't think it is applicable. If you simply use it to derive a key for PSK, it is equivalent to reading a key from a password file using the username provided. regards, Nikos From nobody Sat Oct 17 01:18:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74341A8F34 for ; Sat, 17 Oct 2015 01:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhdte5wb4hKQ for ; Sat, 17 Oct 2015 01:17:56 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2811A8BC5 for ; Sat, 17 Oct 2015 01:17:55 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id W8Hs1r00910HQrX018HtDt; Sat, 17 Oct 2015 10:17:53 +0200 Message-ID: <5622042D.4050200@openfortress.nl> Date: Sat, 17 Oct 2015 10:17:49 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Karthikeyan Bhargavan References: <56212653.6050702@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 08:17:58 -0000 Hi Karthikeyan, > I don’t fully understand the constraints of the Kerberos+DH use-case, but using DHE-PSK seems like the best idea. It certainly has some virtue to view Kerberos as a preshared key (on steroids). But let me explain what bothers me about that appraoch :- * PSK was designed to carry "hints", not "wrapped-up keys". It feels like we'd not be using it entirely properly. * To avoid replay without (distributed) replay-protection caches, we need a ping-pong exchange. PSK sends back a literal copy of what it got sent, which means that we cannot send back a cryptographic reply. Normally, we would do just that in the Kerberos Application Protocol. When we have an Authenticator in a separate ClientVerify message, it automatically ranges over all past TLS messages, incorporating DH, server random and the Ticket that is being proposed. With the PSK approach, it all gets stuffed into one TLS message and we'll be defining things that are not in line with generic structures for TLS. * PSK carries untyped information. This means that a client and server need out-of-band agreement on the meaning of the PSK format. And we probably agree that educated guesses based on magic numbers are not good for a security protocol. This means that use of PSK is limited to pre-arranged client/server combinations. Meanwhile, Kerberos is hoping to expand to make clients and services authenticate even when they have never met before. > The planned session resumption mechanism for TLS 1.3 also uses DHE-PSK, and uses a session ticket mechanism > that is not so far from the Kerberos ticket. The Kerberos session key would then get mixed in (as a semi-static secret) > to the ECDHE shared secret and both client and server would obtain mutual authentication (based on the Kerberos key). Yes, that is nice and orthogonal. However, we do need the entropy of ECDHE and server random to be mixed in with the Authenticator to make replay undoable. The best way to do that orthogonally is to rely on a hash of prior exchanges, which is not possible, at least under 1.2, with structures that mix Diffie-Hellman and PSK fields. Combined with this being a variation of PSK, I would expect it to lead to more exceptional code than what is being proposed as 3) and 4) -- and exceptional code often is badly-tested code. > It may be best to try and fit Kerberos into this existing mechanism, unless there is some fundamental incompatibility. I follow the same line of thought, but think integration with the ClientCertificate / ClientVerify is more natural. Tickets are not just keys, they also carry identity, and bind them together. Once again, the reasoning is that this directs the questions to a TLS stack to the right place, without a need to bypass it to elsewhere for this one usecase. Thanks! -Rick From nobody Sat Oct 17 05:30:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3E1B2A2C for ; Sat, 17 Oct 2015 05:30:57 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjoP836RPqE0 for ; Sat, 17 Oct 2015 05:30:56 -0700 (PDT) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA241B2A2B for ; Sat, 17 Oct 2015 05:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 43AE121C121 for ; Sat, 17 Oct 2015 15:30:55 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id clLW3Zt68+MQ for ; Sat, 17 Oct 2015 15:30:55 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 19B845BC018 for ; Sat, 17 Oct 2015 15:30:55 +0300 (EEST) Date: Sat, 17 Oct 2015 15:30:53 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20151017123053.GA21936@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] New curves work and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 12:30:57 -0000 On Thu, Oct 15, 2015 at 04:09:39PM +0300, Ilari Liusvaara wrote: > > Diffie-Hellman: > --------------- > There is already a WG draft about this. The one remaining technical > issue seems to be wheither to share the curves with signatures or > dedicate those for DH. Okay, did a review of draft-ietf-tls-curve25519 (since it still doesn't seem to have been WGLC'd): Major issues: ------------- None Minor issues: ------------- - The functions got renamed in cfrg spec (which seems to just be concluding IESG review[1]). - Some references look pretty obsolete (e.g. cfrg-curves from January?). - Maybe add an example key exchanges (just copy test vectors out of cfrg-curves and rename things a bit to fit the way values are used in TLS)? [1] In chacha20-poly1305 document processing, IESG review was followed by sending the spec to the RFC editor. -Ilari From nobody Sat Oct 17 10:29:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098241B2B44 for ; Sat, 17 Oct 2015 10:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMi64Vdikgfm for ; Sat, 17 Oct 2015 10:29:35 -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 4BD861B2B43 for ; Sat, 17 Oct 2015 10:29:35 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 447C6462FE2; Sat, 17 Oct 2015 17:29:34 +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 2EA2E462FDF; Sat, 17 Oct 2015 17:29:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445102974; bh=9nRqKmStnvjswjJAH1/iyx7/hbkBJfuZhXfoTuwIbic=; l=980; h=To:References:Cc:From:Date:In-Reply-To:From; b=h/PhbwHoj6hpbvwkikXS8EsuDwGIZhT04abHr07tJg76PPlO+EbZ8vVDWciWMLbLQ vmcWHV2kMiKgjAoHSW4YGw68ik6PRpLsykMgnjV2WfDCE8QZBYLuYt8Pmvqve/5+83 A22p186jM0ltltcFdYW3GNAe2Gm2mV+TM3G6nQ08= 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 E9CAC204E; Sat, 17 Oct 2015 17:29:33 +0000 (GMT) To: Rick van Rein References: <56212653.6050702@openfortress.nl> <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> <56216D37.1050701@akamai.com> <5621EF30.8040300@openfortress.nl> From: Benjamin Kaduk Message-ID: <5622857D.90304@akamai.com> Date: Sat, 17 Oct 2015 12:29:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5621EF30.8040300@openfortress.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 17:29:37 -0000 On 10/17/2015 01:48 AM, Rick van Rein wrote: > It still surprises me, but Kerberos is able to send a message one-way > and achieve mutual authentication. The trick is of course that prior > key exchanges have setup links that make No, mutual authentication requires the client to receive a message from the server. This could be implicit as part of the first application message, encrypted in a subsession key, but it does need to happen. (The krb5 GSSAPI mechanism sends a token from acceptor to initiator to effect mutual authentication, in addition to the initial token from initiator to acceptor.) Without the additional return message, the client has sent a message to some other party, and knows that that other party cannot do something useful with that message unless it is the party the client is intending to talk to, but the client could well have been talking to an impostor that does not know the target service's shared secret with the KDC. -Ben From nobody Sat Oct 17 11:36:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A571B2C09 for ; Sat, 17 Oct 2015 11:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFDVbLi_i8D5 for ; Sat, 17 Oct 2015 11:36:15 -0700 (PDT) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) (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 744121B2C07 for ; Sat, 17 Oct 2015 11:36:15 -0700 (PDT) Received: by ykfy204 with SMTP id y204so111730036ykf.1 for ; Sat, 17 Oct 2015 11:36:14 -0700 (PDT) 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-type; bh=BAYlUzgOxdB8IO6iwNqAg8sNcuAP1WbuVtoRGyPMafY=; b=AZIgjD0hACnXxw9Iq6jOqPcRzzUifO/8qkuwx2+++KbS2IFGQ5UGi/1OG0tEGQi0AI HrLVlYN3ejBQj3/O9XLvlrXZWz6ME2ZyWbK57a5qQgnL65DUQusAnyYrlXOBc/JmBGqI qD7hLI2OG8T9QOAVVC3hr5DJSyDtK7JrnOwjVs34zq8+OC/VgzOdfdAaXrcOZ5z2DnnC LOX5cRSd1ixOJzGpqYleU6W082KYcKj6Dy6ZgesnfE2c/I2tZZEUsawjEL7jLvOEz644 HR8mXy3swbQ21CGgyMO2wjPo18ndRhFmRYDPPYLNKrwuHfT3U4O11w4S7wCUk+JdDQBH yInw== X-Gm-Message-State: ALoCoQmKvtInUt+Pwef1RG0t8FCdHk4Jvn0/1rGFrTK13W2wO04KvqvtYLgQblCsSTbn8xKkM5Uw X-Received: by 10.13.217.207 with SMTP id b198mr14455329ywe.166.1445106974669; Sat, 17 Oct 2015 11:36:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Sat, 17 Oct 2015 11:35:35 -0700 (PDT) In-Reply-To: <02BF1D46-DC94-4D4C-B0E6-5FE0E7D7F95B@gmail.com> References: <02BF1D46-DC94-4D4C-B0E6-5FE0E7D7F95B@gmail.com> From: Eric Rescorla Date: Sat, 17 Oct 2015 11:35:35 -0700 Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a114fb244e374c20522512fea Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 18:36:17 -0000 --001a114fb244e374c20522512fea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Trying to close the loop on this, I think people are generally in favor of this mechanism, so we just need a concrete construction. I propose we use an N bit field divided as follows - N - 8 bits of fixed sentinel. - 8 bits of version number with the semantics being the highest TLS version number supported by the server, encoded with the high nibble being the major version and the low version being the minor version. So, concretely a TLS 1.3 implementation would use 0x34 here. I imagine people have opinions about N and the sentinel, but for concreteness I suggest that N =3D 64 bits, and that we use the ASCII string 'DOWNGRD' as the sentinel. Let the bikeshedding begin! -Ekr On Fri, Oct 16, 2015 at 11:23 PM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > Hi Brian, yes, the mechanism proposed here could also be used by TLS 1.2 > implementations to signal each other about their preferred connection > parameters. > > To make most use of the bytes provided, one could use the sentinel value > to indicate > support for an extension, which then carries a signed server configuratio= n > of arbitrary size. > The attacker would then be unable to downgrade the connection by deleting > this extension. > > False Start is an interesting use case, because > (a) it sends data before the server has confirmed the chosen > version/ciphersuite/etc and > (b) it already tries to prevent downgrades by whitelisting versions and > ciphersuites. > Some downgrade attacks fail because of (b), but others are easier to > exploit because of (a). > For example, Logjam was easier to mount on False Start clients since the > attacker could > collect the False Start data and decrypt it at leisure. > > Extended master secret (EMS) provides some additional protection to False > Start, because the encryption > keys implicitly include the full handshake transcript and, so if the MitM > tampers with the connection, > the False Start data would not be accepted by a server. (However, that > this would not have prevented Logjam.) > Moreover, even the EMS extension can be deleted by a MitM. > The current proposal could protect EMS from downgrade by indicating > support for it in the server hello. > > To sum up, we=E2=80=99re focusing on TLS 1.3 because we have a chance to = bake in > strong downgrade protection > into its implementations from the very beginning. I think this could be > useful for older versions too, as an optional > mechanism which protects clients and servers that both implement it, and > does not affect others. > > -Karthik > > On 17 Oct 2015, at 00:34, Brian Smith wrote: > > On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson > wrote: > >> On 16 October 2015 at 13:39, Brian Smith wrote: >> > That would be especially true for an implementation that does False >> Start >> > for TLS 1.2. >> >> I don't see how false start plays into this. We could have clients >> reject false start if they see this sentinel value. But don't we want >> to just treat this as an attack and abort instead? >> > > Yes. The client needs the sentinel to know to abort the connection, if it= s > willing to false start with TLS 1.2 when it also support TLS 1.3, right? > > Cheers, > Brian > -- > https://briansmith.org/ > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114fb244e374c20522512fea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Trying to close the loop on this, I think people are gener= ally in favor of this
mechanism, so we just need a concrete constructio= n.

I propose we use an N bit field divided as foll= ows

- N - 8 bits of fixed sentinel.
= - 8 bits of version number with the semantics being the highest TLS version=
=C2=A0 number supported by the server, encoded with the high nib= ble being
=C2=A0 the major version and the low version being the = minor version. So,
=C2=A0 concretely a TLS 1.3 implementation wou= ld use 0x34 here.

I imagine people have opinions a= bout N and the sentinel, but for concreteness
I suggest that N = =3D 64 bits, and that we use the ASCII string
'DOWNGRD' a= s the sentinel.

Let the bikeshedding begin!

-Ekr










On Fri, Oct 16, 2015 at 11:23 PM, Karthikeyan Bhargavan <= karthik.bhargavan@gmail.com> wrote:
Hi Brian, yes, the mechan= ism proposed here could also be used by TLS 1.2
implementations t= o signal each other about their preferred connection parameters.
=
To make most use of the bytes provided, one could use the se= ntinel value to indicate=C2=A0
support for an extension, which th= en carries a signed server configuration of arbitrary size.=C2=A0
The attacker would then be unable to downgrade the connection by deleting = this extension.

False Start is an interesting use = case, because=C2=A0
(a) it sends data before the server has confi= rmed the chosen version/ciphersuite/etc and=C2=A0
(b) it already = tries to prevent downgrades by whitelisting versions and ciphersuites.=C2= =A0
Some downgrade attacks fail because of (b), but others are ea= sier to exploit because of (a).
For example, Logjam was easier to= mount on False Start clients since the attacker could=C2=A0
coll= ect the False Start data and decrypt it at leisure. =C2=A0

Extended master secret (EMS) provides some additional protection t= o False Start, because the encryption
keys implicitly include the= full handshake transcript and, so if the MitM tampers with the connection,=
the False Start data would not be accepted by a server. (However= , that this would not have prevented Logjam.)
Moreover, even the = EMS extension can be deleted by a MitM.=C2=A0
The current proposa= l could protect EMS from downgrade by indicating support for it in the serv= er hello.

To sum up, we=E2=80=99re focusing on TLS= 1.3 because we have a chance to bake in strong downgrade protection
<= div>into its implementations from the very beginning. I think this could be= useful for older versions too, as an optional
mechanism which pr= otects clients and servers that both implement it, and does not affect othe= rs.

-Karthik

=
On 17 Oct 2015, at 00:34, Bri= an Smith <bria= n@briansmith.org> wrote:

On Fri, Oct 16, 2015 at 12:12 P= M, Martin Thomson <martin.thomson@gmail.com> wrote:
On 16 October 2015 at 13:39, Brian S= mith <brian@br= iansmith.org> wrote:
> That would be especially true for an implementation that does False St= art
> for TLS 1.2.

I don't see how false start plays into this.=C2=A0 We could have= clients
reject false start if they see this sentinel value.=C2=A0 But don't we = want
to just treat this as an attack and abort instead?

Yes. The client needs the sentinel to know to abort = the connection, if its willing to false start with TLS 1.2 when it also sup= port TLS 1.3, right?

Ch= eers,
Brian
--


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


--001a114fb244e374c20522512fea-- From nobody Sat Oct 17 12:00:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AD91B2C76 for ; Sat, 17 Oct 2015 12:00:54 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSIHZ6KJ4YtA for ; Sat, 17 Oct 2015 12:00:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD7D1B2C5F for ; Sat, 17 Oct 2015 12:00:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 13DFC284B56; Sat, 17 Oct 2015 19:00:37 +0000 (UTC) Date: Sat, 17 Oct 2015 19:00:37 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151017190036.GD15070@mournblade.imrryr.org> References: <02BF1D46-DC94-4D4C-B0E6-5FE0E7D7F95B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 17 Oct 2015 19:00:55 -0000 On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote: > Trying to close the loop on this, I think people are generally in favor of > this > mechanism, so we just need a concrete construction. > > I propose we use an N bit field divided as follows > > - N - 8 bits of fixed sentinel. > - 8 bits of version number with the semantics being the highest TLS version > number supported by the server, encoded with the high nibble being > the major version and the low version being the minor version. So, > concretely a TLS 1.3 implementation would use 0x34 here. > > I imagine people have opinions about N and the sentinel, but for > concreteness > I suggest that N = 64 bits, and that we use the ASCII string > 'DOWNGRD' as the sentinel. > > Let the bikeshedding begin! IIRC for TLS >= 1.3 the entire server hello (as part of a session transcript digest that includes it) is signed with the key exchange. So TLS 1.3 already protects against rollbacks from 1.4 to 1.3. If so, is it necessary to have a variable high octet? Just a single fixed patter signalling ">= 1.3" would then suffice. I must admit to not have looked closely, so perhaps wrong end of the stick... If the above is however correct, I think simpler is better, over-engineering this work-around "side-channel" is I think unwise. This seems to be a protection against rollback to TLS < 1.3, for TLS >= 1.3, the protocol should solve any issues more naturally than by overloading the server-random. -- Viktor. From nobody Sat Oct 17 12:04:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF761A6FA9 for ; Sat, 17 Oct 2015 12:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6fEOBhcNGvY for ; Sat, 17 Oct 2015 12:04:13 -0700 (PDT) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) (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 090DC1A6F33 for ; Sat, 17 Oct 2015 12:04:13 -0700 (PDT) Received: by yknn9 with SMTP id n9so61030895ykn.0 for ; Sat, 17 Oct 2015 12:04:12 -0700 (PDT) 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:content-type; bh=x9t4s3oMzUJ3AUMKObaKbve59DaVyuUbvS6AIBGJ3V0=; b=R0D3XJrwTgUlGv52pPh/tNDb4OqCgYhDvIsSGdmLB/htJj5QtGEs7XgWqRpZLBSZyJ P7iccAutHv0TwLLz33Ek27s6iJO34UN2rFf4u8xIHd4qqZmSdvZMvNXTbJjs9MVCAr1T D8hi+kqbTateVLAZbi+pkgOhIKwbkKFl0DdksKJKYgEYuCFh42b251psVX34zvaA1H25 KayyAkbc3/XF2BKAEs6P6/gYEsaEXGuAhbIDdT57bTgapVyF+gOkjIqp0LHxeWpmykH2 n0WeZ5DBT7GmL8UrlrBPZRg3E5xhOl1zPfKgyWqAzDNQMCYemNyse847E7vqgs2tJ6Fv vQaQ== X-Gm-Message-State: ALoCoQkebVhX8kopCdGYjHnlfkX/fnqY3rybLMY2SErQYDiJWc/NBEDB3z4iyDu742uf73HpE9X7 X-Received: by 10.13.193.133 with SMTP id c127mr14229913ywd.79.1445108652254; Sat, 17 Oct 2015 12:04:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Sat, 17 Oct 2015 12:03:32 -0700 (PDT) In-Reply-To: <20151017190036.GD15070@mournblade.imrryr.org> References: <02BF1D46-DC94-4D4C-B0E6-5FE0E7D7F95B@gmail.com> <20151017190036.GD15070@mournblade.imrryr.org> From: Eric Rescorla Date: Sat, 17 Oct 2015 12:03:32 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e761ee15bbd05225193a4 Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 19:04:15 -0000 --001a114e761ee15bbd05225193a4 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 17, 2015 at 12:00 PM, Viktor Dukhovni wrote: > On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote: > > > Trying to close the loop on this, I think people are generally in favor > of > > this > > mechanism, so we just need a concrete construction. > > > > I propose we use an N bit field divided as follows > > > > - N - 8 bits of fixed sentinel. > > - 8 bits of version number with the semantics being the highest TLS > version > > number supported by the server, encoded with the high nibble being > > the major version and the low version being the minor version. So, > > concretely a TLS 1.3 implementation would use 0x34 here. > > > > I imagine people have opinions about N and the sentinel, but for > > concreteness > > I suggest that N = 64 bits, and that we use the ASCII string > > 'DOWNGRD' as the sentinel. > > > > Let the bikeshedding begin! > > IIRC for TLS >= 1.3 the entire server hello (as part of a session > transcript digest that includes it) is signed with the key exchange. > So TLS 1.3 already protects against rollbacks from 1.4 to 1.3. > Hopefully, yes. If so, is it necessary to have a variable high octet? Note: I am proposing this in the low octet. Not that it's that important either way. > Just a single > fixed patter signalling ">= 1.3" would then suffice. > If you wanted to cover 1.2 -> 1.1, then you would want this. -Ekr > I must admit to not have looked closely, so perhaps wrong end of > the stick... If the above is however correct, I think simpler is > better, over-engineering this work-around "side-channel" is I think > unwise. This seems to be a protection against rollback to TLS < > 1.3, for TLS >= 1.3, the protocol should solve any issues more > naturally than by overloading the server-random. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114e761ee15bbd05225193a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Oct 17, 2015 at 12:00 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
O= n Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote:

> Trying to close the loop on this, I think people are generally in favo= r of
> this
> mechanism, so we just need a concrete construction.
>
> I propose we use an N bit field divided as follows
>
> - N - 8 bits of fixed sentinel.
> - 8 bits of version number with the semantics being the highest TLS ve= rsion
>=C2=A0 =C2=A0number supported by the server, encoded with the high nibb= le being
>=C2=A0 =C2=A0the major version and the low version being the minor vers= ion. So,
>=C2=A0 =C2=A0concretely a TLS 1.3 implementation would use 0x34 here. >
> I imagine people have opinions about N and the sentinel, but for
> concreteness
> I suggest that N =3D 64 bits, and that we use the ASCII string
> 'DOWNGRD' as the sentinel.
>
> Let the bikeshedding begin!

IIRC for TLS >=3D 1.3 the entire server hello (as part of a sessi= on
transcript digest that includes it) is signed with the key exchange.
So TLS 1.3 already protects against rollbacks from 1.4 to 1.3.

Hopefully, yes.


=
If so, is it necessary to have a variable high octet?=C2=A0

Note: I am proposing this in the low octet. Not that it= 9;s that
important either way.

=C2=A0
Just a single
fixed patter signalling ">=3D 1.3" would then suffice.

If you wanted to cover 1.2 -> 1.1, then you= would want this.

-Ekr
=C2=A0
I must admit to not have looked closely, so perhaps wrong end of
the stick...=C2=A0 If the above is however correct, I think simpler is
better, over-engineering this work-around "side-channel" is I thi= nk
unwise.=C2=A0 This seems to be a protection against rollback to TLS < 1.3, for TLS >=3D 1.3, the protocol should solve any issues more
naturally than by overloading the server-random.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a114e761ee15bbd05225193a4-- From nobody Sat Oct 17 12:10:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4684E1A6F9E for ; Sat, 17 Oct 2015 12:10:21 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKuEMr9otCux for ; Sat, 17 Oct 2015 12:10:19 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 96D851A6FAA for ; Sat, 17 Oct 2015 12:10:19 -0700 (PDT) Received: by ykfy204 with SMTP id y204so112094042ykf.1 for ; Sat, 17 Oct 2015 12:10: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:date:message-id:subject:from:to :cc:content-type; bh=CKrqFwHgpbOzMNhAVAc/IqIXih2jYPUtjoxorQZjTfw=; b=f2vIjIkYp+MnHKOq/ECPRYy10PPSYq98XFUMUqAD0WJ2z4DjJyNdAZlSVJzyDZIUDe xmDyzeLOQxWsv3AcgI0e+SJCCRjOP8pC6O5bZSZbM3Omsnfwgp10opz8Xvjx6fZr0Xwa cKZPqSio2RnQrpIhHln3vUaEo2GByUZpr/jDpL4XZD8/ZfFxn3ASQ+J6NIQyhX462ARV OzbGKAxNAueEJhqToSz1AtZYcd9oL5/uHN9JNFCcuRVZmiRO0xKgxq895XGlDbKlwSAi mTPcc/t6sJYDkN2FzoFAQuyTyixqO12+U5dWQ8HKX3qCFrDSm00ovRM2beuSWLAiCdkY bLCQ== MIME-Version: 1.0 X-Received: by 10.13.213.141 with SMTP id x135mr1560146ywd.43.1445109018881; Sat, 17 Oct 2015 12:10:18 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Sat, 17 Oct 2015 12:10:18 -0700 (PDT) In-Reply-To: References: <02BF1D46-DC94-4D4C-B0E6-5FE0E7D7F95B@gmail.com> <20151017190036.GD15070@mournblade.imrryr.org> Date: Sat, 17 Oct 2015 12:10:18 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 19:10:21 -0000 On 17 October 2015 at 12:03, Eric Rescorla wrote: >> Just a single >> fixed patter signalling ">= 1.3" would then suffice. > > > If you wanted to cover 1.2 -> 1.1, then you would want this. The observation is still valuable in the sense that prohibiting values > 1.3 would reduce the likelihood of a false positive by some miniscule amount. In other words, I agree with ekr here, though we could cap the value to 1.3. Maybe we could just define two values: one for TLS 1.3 (and greater, presumably) and one for TLS 1.2. I don't see any value in protecting 1.1 or 1.0 from downgrade any more given relative prevalence of those protocols and their age. From nobody Sat Oct 17 14:08:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3957D1ACEB0 for ; Sat, 17 Oct 2015 14:08:20 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jadcZI5hjTYv for ; Sat, 17 Oct 2015 14:08:19 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 066521ACE98 for ; Sat, 17 Oct 2015 14:08:19 -0700 (PDT) Received: by qgbb65 with SMTP id b65so23270766qgb.2 for ; Sat, 17 Oct 2015 14:08: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:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=1MGiAFQnIgLeezCjfDDx4+xwXT3qbvknUHsu5ZVag3U=; b=VNdv1Dovk2A40jcexei7wA3HcSM2jpByzTgvKc2CDhpfImWgj+lKPEZIfg5Eqksqjk hKudG6WsJiFB7+EjZhN9JKCBY+RURTQg6hQHeNFpsGpfp/ZLYu1NY260uCwY23V2cWTX WFYqereG3tFuhzJcJI7m5ZIkoFoG/ZYj8zX0MZ6lXrrgt/KxMfDUMbe2ocg7XIwlsPXA 9OPMLeYSDQ+4M2Do4WsV1zDsSgqAcqsOMxjttuzrju6E6/81yLS3+hz2r924da879cUG y46A/MxQJAbIY8hgKpdweZLtDtaTLuDfadzHsUUM47mQtchAMgIuI2Ldu4j1dkWm9pBB clQg== X-Received: by 10.140.98.206 with SMTP id o72mr2845302qge.2.1445116098274; Sat, 17 Oct 2015 14:08:18 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id i139sm1953383qhc.30.2015.10.17.14.08.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 17 Oct 2015 14:08:17 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Martin Thomson , Eric Rescorla Date: Sat, 17 Oct 2015 17:08:16 -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: <201510171708.16547.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 21:08:20 -0000 On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote: > The observation is still valuable in the sense that prohibiting values > > 1.3 would reduce the likelihood of a false positive by some > miniscule amount. In other words, I agree with ekr here, though we > could cap the value to 1.3. > > Maybe we could just define two values: one for TLS 1.3 (and greater, > presumably) and one for TLS 1.2. I don't see any value in protecting > 1.1 or 1.0 from downgrade any more given relative prevalence of those > protocols and their age. Two values seems like a good compromise to me if one isn't considered sufficient. I don't particularly want them changing in the future so old (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to worry about seeing something new here and making a mistake. Checks would be for one of two 64-bit values, rather than 56-bit values with a byte with a possibly unknown value. Dave From nobody Sat Oct 17 14:13:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B4C1ACEDF for ; Sat, 17 Oct 2015 14:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=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 i76pnlLqZipK for ; Sat, 17 Oct 2015 14:13:14 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 2F0B81ACEDC for ; Sat, 17 Oct 2015 14:13:14 -0700 (PDT) Received: by ykfy204 with SMTP id y204so113338500ykf.1 for ; Sat, 17 Oct 2015 14:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=F5e9xHTjFVNnNz5htRaYUSsitiDjSy2db6qchf58Y/Y=; b=K2ZaJ0NQy4Sb0wqCfPmu9rsriAQddpwrTDBtfSXRNLQF+E9lnxTNimQ/A/wl4a7FEY UVAQ6OfRMOtAJ92bTyzeKQSugo/ZKiGDhFbnlxL9cVWuA/j2mZlaH+acO8PNhbfQsIvl UO3j1gi2sRsKoAgsMj9eVbGlf9FkGsDoCDKsI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=F5e9xHTjFVNnNz5htRaYUSsitiDjSy2db6qchf58Y/Y=; b=EhwDg/pRlPipzBsQCgcJD5T6AgcUjO8jozuox/bvPnVDz/WNKQZroIDUfONI+Nrkvj vIvFJnEfu9UY7O0pkqomL6dpmDi9fnzLClSRxC1NPpg+Sjtop64haikgpl2DQ+OmezP0 /4xFShKDYndli7zL4rTeyOh5FscUmpKFaXRe1AJH3XJ+l+mz1Ro+hufsVJK+N96lpEZx q3doukI3Kjfm7c84TTlWrBxaCux/LoVkTK57ImTfaYiAnJIXz8xTMOfzx4rBfBckz8bn kXQJbDuX4LdHPiht3ZS/b1Ln8Uml2ICeEHNkW4oiKEJw+sek9E9u0JKKKjkKtqFDxBZU TliA== X-Gm-Message-State: ALoCoQnmZZcVWr9HCKU3EjXq1HbwuIbACXmyVzONvxGvFquct56K5ZWP2y0n3F3lgNRSSaH5w9ZX X-Received: by 10.129.91.68 with SMTP id p65mr14522636ywb.252.1445116393246; Sat, 17 Oct 2015 14:13:13 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id f67sm20347772ywd.19.2015.10.17.14.13.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 14:13:12 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Sat, 17 Oct 2015 17:13:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <258F3808-1046-4B59-B0BC-CB2AF9B7D0FE@sn3rd.com> References: To: "" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] Comments from CELLOS consortium X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 21:13:15 -0000 Since we=92ve been using github as an issue tracker, I=92m going to copy = these comments there. I=92m going to put =93CELLOS=94 somewhere in the = issue so they can be easily found. Also note that some of these are = resolved, similar to others, or over taken by events so I expect some to = be closed almost immediately. spt On Oct 05, 2015, at 15:54, Shin'ichiro Matsuo wrote: > Dear all, >=20 > Members in the CELLOS consortium (https://www.cellos-consortium.org), = which is the consortium on security of cryptographic protocols, are = studying on the TLS 1.3 protocol. We have several comments and = suggestions to make the specification of TLS1.3 better.=20 >=20 > Please find the comments at the following URL. >=20 > = https://www.cellos-consortium.org/studygroup/tls_1_3-draft_08_issues_rev1.= pdf >=20 > The comments are on the following matters. >=20 > - AEAD > - KDF > - Full Handshake > - Hello Retry Request > - Shared Secret > - Client Authentication > - Cipher Suite > - 0-RTT > - Resumption and PSK >=20 > Some of them are already fixed, such as HFDF. However, we left it as a = result of our study. >=20 >=20 > Regards, > Shin=92ichiro Matsuo > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Oct 17 14:17:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390E51A19E4 for ; Sat, 17 Oct 2015 14:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgkklIIhXING for ; Sat, 17 Oct 2015 14:17:30 -0700 (PDT) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) (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 CD77E1A0AF8 for ; Sat, 17 Oct 2015 14:17:29 -0700 (PDT) Received: by ykdz2 with SMTP id z2so28425276ykd.3 for ; Sat, 17 Oct 2015 14:17:29 -0700 (PDT) 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-type; bh=v4QFbCrImc61j7leaQGq27DzpzF3kddwc8dal7DAHEg=; b=nEfWxArNdnni8GOoFyg/u06IzCfQbaqoVFcIaZ+kGM2sIdKk0lNZX+vRVugGor4ygV wFuhzopxX58inD2POZFxh4ciiZQPvAysw7LliBcuPP3wlObFZGVu0SpVdBmuzYpe9tDg vitGeRdgPTvKP+Os8mI0JHXMMmD3+Z16PU0kQUJ8DBkhNFi46ieiMkeXRxa4zHJKHxWT HH+mNgfW/B0obo9eI4EBI0btTEfnms288jR1PUwDD8FDEllMhzSRRbCGk/p6H8Otl+An oU4TuHiw4RRVwvJ2u4D51Y1kGahfOD2K38ZKiI2bVEmrDUG88jkXQINGo65Kv+BGYffG xj8g== X-Gm-Message-State: ALoCoQl8vezZFeUue81Xv/5DbcKAb/N2/oGbxi8SAWHPbSwACfa1g148CR55BDIDP384EkHFqhFY X-Received: by 10.129.89.131 with SMTP id n125mr6946941ywb.61.1445116649121; Sat, 17 Oct 2015 14:17:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Sat, 17 Oct 2015 14:16:49 -0700 (PDT) In-Reply-To: <201510171708.16547.davemgarrett@gmail.com> References: <201510171708.16547.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 17 Oct 2015 14:16:49 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114920c687dfcc05225370d6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 21:17:31 -0000 --001a114920c687dfcc05225370d6 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett wrote: > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote: > > The observation is still valuable in the sense that prohibiting values > > > 1.3 would reduce the likelihood of a false positive by some > > miniscule amount. In other words, I agree with ekr here, though we > > could cap the value to 1.3. > > > > Maybe we could just define two values: one for TLS 1.3 (and greater, > > presumably) and one for TLS 1.2. I don't see any value in protecting > > 1.1 or 1.0 from downgrade any more given relative prevalence of those > > protocols and their age. > > Two values seems like a good compromise to me if one isn't considered > sufficient. I don't particularly want them changing in the future so old > (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to > worry about seeing something new here and making a mistake. Checks would be > for one of two 64-bit values, rather than 56-bit values with a byte with a > possibly unknown value My assumption here was that the client would do the following: 1. Look to see if the server negotiated its highest version. If so, then all is good. 2. If the server did not negotiate the highest version, then look for the sentinel. If it's set, you have a downgrade. 3. (Optional) If you have a downgrade, parse the last byte to see the server's actual version. In any case, abort. What have I missed? -Ekr > > > Dave > --001a114920c687dfcc05225370d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> The observation is still valuable in the sense that prohibiting values=
> > 1.3 would reduce the likelihood of a false positive by some
> miniscule amount.=C2=A0 In other words, I agree with ekr here, though = we
> could cap the value to 1.3.
>
> Maybe we could just define two values: one for TLS 1.3 (and greater, > presumably) and one for TLS 1.2.=C2=A0 I don't see any value in pr= otecting
> 1.1 or 1.0 from downgrade any more given relative prevalence of those<= br> > protocols and their age.

Two values seems like a good compromise to me if one isn't consi= dered sufficient. I don't particularly want them changing in the future= so old (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't= need to worry about seeing something new here and making a mistake. Checks= would be for one of two 64-bit values, rather than 56-bit values with a by= te with a possibly unknown value

My assumpt= ion here was that the client would do the following:

1. Look to see if the server negotiated its highest version. If so, then= all is good.
2. If the server did not negotiate the highest vers= ion, then look for the sentinel.
=C2=A0 =C2=A0 If it's set, y= ou have a downgrade.
3. (Optional) If you have a downgrade, parse= the last byte to see the server's actual version.
=C2=A0 =C2= =A0 In any case, abort.

What have I missed?
<= div>
-Ekr

=C2=A0 =C2=A0=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Dave

--001a114920c687dfcc05225370d6-- From nobody Sat Oct 17 14:28:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DBB1ACEDB for ; Sat, 17 Oct 2015 14:28:08 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twCHwlBBXYxi for ; Sat, 17 Oct 2015 14:28:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6098B1A0121 for ; Sat, 17 Oct 2015 14:28:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5B61B284DA3; Sat, 17 Oct 2015 21:28:06 +0000 (UTC) Date: Sat, 17 Oct 2015 21:28:06 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151017212805.GE15070@mournblade.imrryr.org> References: <201510171708.16547.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 17 Oct 2015 21:28:08 -0000 On Sat, Oct 17, 2015 at 02:16:49PM -0700, Eric Rescorla wrote: > 3. (Optional) If you have a downgrade, parse the last byte to see the > server's actual version. > In any case, abort. > > What have I missed? >From my perspective, there's not much benefit to knowing the actual version, and an unnecessary loss of 7 to 8 bits of protection against false positives with actually random input from legacy peers. If it is "in any case abort", why waste bits on the version. If 56 bits are enough FP-protection, use the rest for real randomness in the server-random. If just to be safe the FP protection is 64 bits, fix those bits, except perhaps 1 to indicate 1.2 vs. >= 1.3 (if this mechanism is intended to be "backported" to TLS 1.2 systems). -- Viktor. From nobody Sat Oct 17 14:34:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBFB1B2A4E for ; Sat, 17 Oct 2015 14:34:30 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6IGWkYP0gnw for ; Sat, 17 Oct 2015 14:34:29 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 49DCD1B2A1A for ; Sat, 17 Oct 2015 14:34:29 -0700 (PDT) Received: by qgez77 with SMTP id z77so128426129qge.1 for ; Sat, 17 Oct 2015 14:34: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-type:content-transfer-encoding:message-id; bh=YC3asJQV1rQoLjn8RVOC/a62IOT0n5WLBhUuTwbt158=; b=owYyiJtUQyqDKK+YU4ecjwrqxV2BcDuEleCsayuj8XVe+9MQKug3LsGMFP4MjRdXeb U+SV0+ynODp9wHkL0JjVz/WVGNVlbZDKR2vk7MElg65ZVrXJQr2W+LcWOn4erzVFEW3Z f59hVPNbka6xz2StSJvAd76C6lXGuvj1KeuXboZln9I4CBaL13mVkIxAHFDJGtLYsTZa WYQkft2alx9Z6JtlvxG9sRfV8RMZOaz59lK2D6ugIsb4A4KkVlTP9FUzyPbCvL6ay8Go J9M6U+4jeGhGoZRo9kmyWlO7uxJOrfzIgKINPII9pRpbyToAm/gQ7McOrfFjcFyQ+rN4 29eA== X-Received: by 10.140.237.14 with SMTP id i14mr28544412qhc.28.1445117668528; Sat, 17 Oct 2015 14:34:28 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 28sm10913363qkw.12.2015.10.17.14.34.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 17 Oct 2015 14:34:27 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Sat, 17 Oct 2015 17:34:26 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510171708.16547.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201510171734.26589.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 21:34:30 -0000 On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote: > On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett > wrote: > > > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote: > > > The observation is still valuable in the sense that prohibiting values > > > > 1.3 would reduce the likelihood of a false positive by some > > > miniscule amount. In other words, I agree with ekr here, though we > > > could cap the value to 1.3. > > > > > > Maybe we could just define two values: one for TLS 1.3 (and greater, > > > presumably) and one for TLS 1.2. I don't see any value in protecting > > > 1.1 or 1.0 from downgrade any more given relative prevalence of those > > > protocols and their age. > > > > Two values seems like a good compromise to me if one isn't considered > > sufficient. I don't particularly want them changing in the future so old > > (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to > > worry about seeing something new here and making a mistake. Checks would be > > for one of two 64-bit values, rather than 56-bit values with a byte with a > > possibly unknown value > > > My assumption here was that the client would do the following: > > 1. Look to see if the server negotiated its highest version. If so, then > all is good. > 2. If the server did not negotiate the highest version, then look for the > sentinel. > If it's set, you have a downgrade. > 3. (Optional) If you have a downgrade, parse the last byte to see the > server's actual version. > In any case, abort. > > What have I missed? A 64-bit sentinel can be trivially checked as a 64-bit uint. If we have an open-ended series, we could have implementations checking for a set of 64-bit integers rather than a 56-bit followed by another byte to be inspected. I'm being paranoid, yes, but it's simpler just to have a round number bits value or two and I don't think you get much by encoding further information. It also has a slightly better collision risk, though it's already down quite low. Dave From nobody Sat Oct 17 14:54:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A9A1B2C6C for ; Sat, 17 Oct 2015 14:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ5xzb3nWVr5 for ; Sat, 17 Oct 2015 14:54:38 -0700 (PDT) Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) (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 00F0B1B2C6B for ; Sat, 17 Oct 2015 14:54:38 -0700 (PDT) Received: by ykaz22 with SMTP id z22so111086317yka.2 for ; Sat, 17 Oct 2015 14:54:37 -0700 (PDT) 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-type; bh=grRzlBhlQPkQirECkg0wf7Mh3BxwLpY6dQLy3jLYOmE=; b=TBzpRzQXD3bIefNCp9arbNIXI9wQrbzj4Hn1+hwQ1DK8MN0QD7tXEyzwDamgPxMahl +pg8EhlSoMzhYy8cNmLtE/nnGXwWm1KpgNezTtJ/eO0AHMiThLUUueKo2zlceH0PRPKo yXbQEdJ3Yn5ZlhlgSHeYrq4k6iCX0FbQpFqzJSzCo0phUqGZY5p1wOl4RBzU4OCY8ypm PtDCPwiEr1ZakVi6X2JpTSEXjtD1+DgzLO9mqWkqECrLa1fyGjXnc3Y99Mct2gVqwoKg aZE216D1CaL/XGbWfD1ipjq7S/qipgfpCToyAmoh0WF4L6LS2HVy52jMSmcSWpvUOaBx PG4w== X-Gm-Message-State: ALoCoQmxmKj6YKgExC0NHu6j77dlulaXhqvDU/Jk2fwM6vOmjrN1cANnDlHjRJk807ul8DFQlx3k X-Received: by 10.129.41.148 with SMTP id p142mr16543974ywp.274.1445118877223; Sat, 17 Oct 2015 14:54:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Sat, 17 Oct 2015 14:53:57 -0700 (PDT) In-Reply-To: <201510171734.26589.davemgarrett@gmail.com> References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> From: Eric Rescorla Date: Sat, 17 Oct 2015 14:53:57 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a11421e285600fa052253f502 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 21:54:40 -0000 --001a11421e285600fa052253f502 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett wrote: > On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote: > > On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett > > wrote: > > > > > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote: > > > > The observation is still valuable in the sense that prohibiting > values > > > > > 1.3 would reduce the likelihood of a false positive by some > > > > miniscule amount. In other words, I agree with ekr here, though we > > > > could cap the value to 1.3. > > > > > > > > Maybe we could just define two values: one for TLS 1.3 (and greater, > > > > presumably) and one for TLS 1.2. I don't see any value in protecting > > > > 1.1 or 1.0 from downgrade any more given relative prevalence of those > > > > protocols and their age. > > > > > > Two values seems like a good compromise to me if one isn't considered > > > sufficient. I don't particularly want them changing in the future so > old > > > (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to > > > worry about seeing something new here and making a mistake. Checks > would be > > > for one of two 64-bit values, rather than 56-bit values with a byte > with a > > > possibly unknown value > > > > > > My assumption here was that the client would do the following: > > > > 1. Look to see if the server negotiated its highest version. If so, then > > all is good. > > 2. If the server did not negotiate the highest version, then look for the > > sentinel. > > If it's set, you have a downgrade. > > 3. (Optional) If you have a downgrade, parse the last byte to see the > > server's actual version. > > In any case, abort. > > > > What have I missed? > > A 64-bit sentinel can be trivially checked as a 64-bit uint. And a 56-bit value can be trivially checked by masking off the last byte. Or, memcmp(). If we have an open-ended series, we could have implementations checking for > a set of 64-bit integers,rather than a 56-bit followed by another byte to > be inspected. As noted, nobody is making you check it. > I'm being paranoid, yes, but it's simpler just to have a round number bits > value or two and I don't think you get much by encoding further information. > > It also has a slightly better collision risk, though it's already down > quite low Given that the TCP checksum has a false negative rate far higher than 2^{-56} and any TCP errors cause TLS handshake failures, this doesn't seem like much of an argument. -Ekr > > Dave > --001a11421e285600fa052253f502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
>
> > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote: > > > The observation is still valuable in the sense that prohibit= ing values
> > > > 1.3 would reduce the likelihood of a false positive by = some
> > > miniscule amount.=C2=A0 In other words, I agree with ekr her= e, though we
> > > could cap the value to 1.3.
> > >
> > > Maybe we could just define two values: one for TLS 1.3 (and = greater,
> > > presumably) and one for TLS 1.2.=C2=A0 I don't see any v= alue in protecting
> > > 1.1 or 1.0 from downgrade any more given relative prevalence= of those
> > > protocols and their age.
> >
> > Two values seems like a good compromise to me if one isn't co= nsidered
> > sufficient. I don't particularly want them changing in the fu= ture so old
> > (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don'= ;t need to
> > worry about seeing something new here and making a mistake. Check= s would be
> > for one of two 64-bit values, rather than 56-bit values with a by= te with a
> > possibly unknown value
>
>
> My assumption here was that the client would do the following:
>
> 1. Look to see if the server negotiated its highest version. If so, th= en
> all is good.
> 2. If the server did not negotiate the highest version, then look for = the
> sentinel.
>=C2=A0 =C2=A0 =C2=A0If it's set, you have a downgrade.
> 3. (Optional) If you have a downgrade, parse the last byte to see the<= br> > server's actual version.
>=C2=A0 =C2=A0 =C2=A0In any case, abort.
>
> What have I missed?

A 64-bit sentinel can be trivially checked as a 64-bit uint.

And a 56-bit value can be trivially checked b= y masking off the last byte.
Or, memcmp().


If we have an open-ended series, we could ha= ve implementations checking for a set of 64-bit integers,rather than a 56-b= it followed by another byte to be inspected.

As noted, nobody is making you check it.

=C2=A0=
I'm being paranoid, yes, but it's simpler ju= st to have a round number bits value or two and I don't think you get m= uch by encoding further information.

It also has a slightly better collision risk, though it's already down = quite low

Given that the TCP checksum has a= false negative rate far higher than 2^{-56} and
any TCP errors c= ause TLS handshake failures, this doesn't seem like much of an argument= .

-Ekr




Dave

--001a11421e285600fa052253f502-- From nobody Sat Oct 17 15:05:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEA11B2C82 for ; Sat, 17 Oct 2015 15:04:52 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ5l08igx47s for ; Sat, 17 Oct 2015 15:04:51 -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 4F1321B2C84 for ; Sat, 17 Oct 2015 15:04:51 -0700 (PDT) Received: by qkcy65 with SMTP id y65so713292qkc.0 for ; Sat, 17 Oct 2015 15:04:50 -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-type:content-transfer-encoding:message-id; bh=lB+g+VOEvevC8Iy+7OR7SB+XqOm8Na2ZwDZVHT+44II=; b=uyTJhZ7+oADC7yvMnOxc0RH1uunvdLkPcqgB7JvH3TpCj+CdIdFeFAdAc8bYl7pHSi x8SnbdKXz9dz3SdAiYw00lwHrcjw4wuECjPn1LlwjzriTlxubarSRUxY6Xacl1/yRZmV 60ze3srZolhtLhLGAbapIPl9H8cx3opI4ZPgGXkjIHk3WEm5GmHjjcITveKKyGRKzFW3 IaDN0IDtCW994P7w5zX/Vc1kBQneWVQ8obBS4jchw2XhedJeEdOru6vwrtiPymWIZHPh MnSPw1B+vp0v/VE7uxuo3IId0hCrqe7XEKkrUBGnI22/ZBp7CNpJa+TYt1lejVoW27jq 1Epg== X-Received: by 10.55.42.141 with SMTP id q13mr27305667qkq.13.1445119490554; Sat, 17 Oct 2015 15:04:50 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id d64sm10931800qgf.34.2015.10.17.15.04.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 17 Oct 2015 15:04:49 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Sat, 17 Oct 2015 18:04:47 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201510171734.26589.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201510171804.48330.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 22:04:52 -0000 On Saturday, October 17, 2015 05:53:57 pm Eric Rescorla wrote: > On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett > wrote: > > A 64-bit sentinel can be trivially checked as a 64-bit uint. > > And a 56-bit value can be trivially checked by masking off the last byte. > Or, memcmp(). My point is that one is more trivial and someone might check for 64 when they shouldn't be. It's the same thought process that deals with bad user agent sniffing; developers come up with algorithms that are ideal now, not necessarily in the future. It's not a world-ending complaint, but I do think it's simpler to just use a uint64 or 2. > > It also has a slightly better collision risk, though it's already down > > quite low > > > Given that the TCP checksum has a false negative rate far higher than > 2^{-56} and > any TCP errors cause TLS handshake failures, this doesn't seem like much of > an argument. I'll concede the collision risk argument on that point, then. As I said, already smaller than it was in the first proposal. Dave From nobody Sat Oct 17 15:05:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2006D1B2C8B for ; Sat, 17 Oct 2015 15:05:57 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED7DxaNhELxL for ; Sat, 17 Oct 2015 15:05:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533571B2C84 for ; Sat, 17 Oct 2015 15:05:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 71A6F284DA3; Sat, 17 Oct 2015 22:05:48 +0000 (UTC) Date: Sat, 17 Oct 2015 22:05:48 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151017220548.GF15070@mournblade.imrryr.org> References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 17 Oct 2015 22:05:57 -0000 On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote: > > It also has a slightly better collision risk, though it's already down > > quite low > > Given that the TCP checksum has a false negative rate far higher than > 2^{-56} and > any TCP errors cause TLS handshake failures, this doesn't seem like much of > an argument. This argument is not complete. The false negative rate from TCP is not by itself sufficient to determine the observed error rate. One needs to combine that with the undetected error rate from underlying network to obtain the frequency of TCP errors that percolate up to the TLS layer. There are of course also errors in the memory subsystem, or machine crashes, ... that all interrupt TLS connections. Indeed 2^{-64} is a very low error probability, it is I would guess substantially smaller that any of the other possible error sources, and this is a good thing. The question is not so much whether 48, 56 or 64 bits is the right amount of protection against random false positives, though if 64 bits is way overkill and the original 48 is more than enough, we could look more closely at that. Rather, I think the question is whether this work-around should be as simple as possible, or should be a more feature-full new sub-protocol. I'm in the keep it simple camp (if we should do this at all). -- Viktor. From nobody Sat Oct 17 15:10:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CAB1B2C9E for ; Sat, 17 Oct 2015 15:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KtPwD65qM8u for ; Sat, 17 Oct 2015 15:10:41 -0700 (PDT) Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) (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 50D221B2C97 for ; Sat, 17 Oct 2015 15:10:41 -0700 (PDT) Received: by ykdz2 with SMTP id z2so28929290ykd.3 for ; Sat, 17 Oct 2015 15:10:40 -0700 (PDT) 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:content-type; bh=p8YNrKbvh3DzHSuwqyseGDnE3fBOOZhSc75nxLiQgq0=; b=lgdqnnPoWxVNei+KX3Tmrl8XX3YuNl0Nk5M+BN8/sPgHXJR2BSax3c3Tu22lU+5m79 zt/RQtDMeKoQaIgPzKC78sJFI/9JKaYj94ONa+ZI6sI6vBg2wKzszh58uh5TEdnh0oU+ Rp8OgeKUnwzCwdQFK0AkgAMd272h0ZBL0POd3Wc+uq4BF9dpvJp/clsBLjv5CySeVuaK Y33j6YWoA36FuNxpGHvNIAK9r6o8SllhzSzSTa+mvih0bzDlRcylavqauCrxQryvA0EK wIRv1+Z5B/7cReolQBdYLf5rJLRGJG0Y4Ar7YfH9ATWf7RdKYdx2llzg6c1QctabefAI AN4A== X-Gm-Message-State: ALoCoQmPGU7ztIzCb32Ul8G0Wm31tVRCR7TBsy0iQAeb2IAQiRXXS1a354nhBDWOWdgm7N1aV/R0 X-Received: by 10.129.70.197 with SMTP id t188mr15004106ywa.292.1445119840625; Sat, 17 Oct 2015 15:10:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Sat, 17 Oct 2015 15:10:01 -0700 (PDT) In-Reply-To: <20151017220548.GF15070@mournblade.imrryr.org> References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> From: Eric Rescorla Date: Sat, 17 Oct 2015 15:10:01 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114d70eec25bc80522542ed5 Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 22:10:43 -0000 --001a114d70eec25bc80522542ed5 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 17, 2015 at 3:05 PM, Viktor Dukhovni wrote: > On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote: > > > > It also has a slightly better collision risk, though it's already down > > > quite low > > > > Given that the TCP checksum has a false negative rate far higher than > > 2^{-56} and > > any TCP errors cause TLS handshake failures, this doesn't seem like much > of > > an argument. > > This argument is not complete. The false negative rate from TCP > is not by itself sufficient to determine the observed error rate. > One needs to combine that with the undetected error rate from > underlying network to obtain the frequency of TCP errors that > percolate up to the TLS layer. > A bit old but see: http://www.ir.bbn.com/documents/articles/crc-sigcomm00.pdf "After an analysis we conclude that the checksum will fail to detect errors for roughly 1 in 16 million to 10 billion packets". -Ekr > The question is not so much whether 48, 56 or 64 bits is the right > amount of protection against random false positives, though if 64 > bits is way overkill and the original 48 is more than enough, we > could look more closely at that. Rather, I think the question is > whether this work-around should be as simple as possible, or should > be a more feature-full new sub-protocol. I'm in the keep it simple > camp (if we should do this at all). --001a114d70eec25bc80522542ed5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 17, 2015 at 3:05 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:
On Sat, = Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:

> > It also has a slightly better collision risk, though it's alr= eady down
> > quite low
>
> Given that the TCP checksum has a false negative rate far higher than<= br> > 2^{-56} and
> any TCP errors cause TLS handshake failures, this doesn't seem lik= e much of
> an argument.

This argument is not complete.=C2=A0 The false negative rate from TC= P
is not by itself sufficient to determine the observed error rate.
One needs to combine that with the undetected error rate from
underlying network to obtain the frequency of TCP errors that
percolate up to the TLS layer.

A bit ol= d but see:

"After an analysis we conclude that the = checksum will fail to detect
errors for roughly 1 in 16 million t= o 10 billion packets".

-Ekr

=C2=A0
The question is not so much whether 48= , 56 or 64 bits is the right
amount of protection against random false positives, though if 64
bits is way overkill and the original 48 is more than enough, we
could look more closely at that.=C2=A0 Rather, I think the question is
whether this work-around should be as simple as possible, or should
be a more feature-full new sub-protocol.=C2=A0 I'm in the keep it simpl= e
camp (if we should do this at all).

=C2=A0<= /div>
--001a114d70eec25bc80522542ed5-- From nobody Sat Oct 17 15:17:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447C11A1B76 for ; Sat, 17 Oct 2015 15:17:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO4_5VC_IxHp for ; Sat, 17 Oct 2015 15:17:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC22C1A1B74 for ; Sat, 17 Oct 2015 15:17:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 06D8E284DA3; Sat, 17 Oct 2015 22:17:34 +0000 (UTC) Date: Sat, 17 Oct 2015 22:17:33 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151017221733.GG15070@mournblade.imrryr.org> References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 17 Oct 2015 22:17:36 -0000 On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote: > > This argument is not complete. The false negative rate from TCP > > is not by itself sufficient to determine the observed error rate. > > One needs to combine that with the undetected error rate from > > underlying network to obtain the frequency of TCP errors that > > percolate up to the TLS layer. > > A bit old but see: > http://www.ir.bbn.com/documents/articles/crc-sigcomm00.pdf > > "After an analysis we conclude that the checksum will fail to detect > errors for roughly 1 in 16 million to 10 billion packets". That's all fine and good, but my point is that this is a distraction. Though the specific numbers depend greatly on the underlying layer-2 networks traversed by the TCP frame, let's accept the 1:10^10 estimate, in which case anything better than ~2^{-40} is quite enough. If so, send a shorter sentinel. > > The question is not so much whether 48, 56 or 64 bits is the right > > amount of protection against random false positives, though if 64 > > bits is way overkill and the original 48 is more than enough, we > > could look more closely at that. Rather, I think the question is > > whether this work-around should be as simple as possible, or should > > be a more feature-full new sub-protocol. I'm in the keep it simple > > camp (if we should do this at all). However, the question of simplicity still remains... I would go with at most a 1 bit field for "TLS 1.2" vs. "TLS 1.3" in whatever length sentinel is used. -- VIktor. From nobody Sat Oct 17 15:20:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9561A000B for ; Sat, 17 Oct 2015 15:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS3VA0azfZaL for ; Sat, 17 Oct 2015 15:20:49 -0700 (PDT) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (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 A905F1A0006 for ; Sat, 17 Oct 2015 15:20:48 -0700 (PDT) Received: by ykfy204 with SMTP id y204so113974586ykf.1 for ; Sat, 17 Oct 2015 15:20:48 -0700 (PDT) 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:content-type; bh=MhqkISrw6jqWkKcMNqJ7QZHcD15p2DYFjP6b/9D/Xlw=; b=gyClqJxxcuBk2ilqiuoFKy+DJ6jbh5qJ5AWwllO5xz3q3nlijYCQ0LO8lRRiXD0keI n8kVk4Yev5GW6BWhHn2hj+o5rZDlIDcPoeLvTzY5ixFyDCshXm+kA5yQoNo+6y+Bylhb E8ZoVCJENMjAoE7uSlZhq0YUb037qKZcKljSERYc0wdAirLgA5cZ9CD1ddJmEnO3NNJi 5xQ70AdTdbBa8McewsfFdR12hraEvW9V/pw0i9BFyeJLkfUEmvHqhQ4CkDKCiKhdd4kG j2vULihv1mmumcu/wljZTKRM8Uj9SVlbGfkhscx5m5ynTElsUU98NrW1n+I7R7zOielL xrNw== X-Gm-Message-State: ALoCoQnBRJF5rdl8f/DWMetdWOvXsMaBrO/YU2sit4mH174AXlP31CacppETgezp/YUxOsyUbLfl X-Received: by 10.129.70.197 with SMTP id t188mr15024199ywa.292.1445120447932; Sat, 17 Oct 2015 15:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Sat, 17 Oct 2015 15:20:08 -0700 (PDT) In-Reply-To: <20151017221733.GG15070@mournblade.imrryr.org> References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> From: Eric Rescorla Date: Sat, 17 Oct 2015 15:20:08 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114d70eef4f3770522545293 Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 22:20:51 -0000 --001a114d70eef4f3770522545293 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 17, 2015 at 3:17 PM, Viktor Dukhovni wrote: > On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote: > > > > This argument is not complete. The false negative rate from TCP > > > is not by itself sufficient to determine the observed error rate. > > > One needs to combine that with the undetected error rate from > > > underlying network to obtain the frequency of TCP errors that > > > percolate up to the TLS layer. > > > > A bit old but see: > > http://www.ir.bbn.com/documents/articles/crc-sigcomm00.pdf > > > > "After an analysis we conclude that the checksum will fail to detect > > errors for roughly 1 in 16 million to 10 billion packets". > > That's all fine and good, but my point is that this is a distraction. > Though the specific numbers depend greatly on the underlying layer-2 > networks traversed by the TCP frame, let's accept the 1:10^10 > estimate, in which case anything better than ~2^{-40} is quite > enough. If so, send a shorter sentinel. Sure, that's fine. I'm simply dispensing with arguments that we need to avoid sending a version because we need the bits to avoid false positives. > > The question is not so much whether 48, 56 or 64 bits is the right > > > amount of protection against random false positives, though if 64 > > > bits is way overkill and the original 48 is more than enough, we > > > could look more closely at that. Rather, I think the question is > > > whether this work-around should be as simple as possible, or should > > > be a more feature-full new sub-protocol. I'm in the keep it simple > > > camp (if we should do this at all). > > However, the question of simplicity still remains... I would go > with at most a 1 bit field for "TLS 1.2" vs. "TLS 1.3" in whatever > length sentinel is used. I don't feel strongly about this, but I don't see how what you suggest is any simpler than the version number encoding I proposed. Arguably, it's more complicated since you can't implement the sentinel check with memcmp(). -Ekr > VIktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114d70eef4f3770522545293 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 17, 2015 at 3:17 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:
On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:

> > This argument is not complete.=C2=A0 The false negative rate from= TCP
> > is not by itself sufficient to determine the observed error rate.=
> > One needs to combine that with the undetected error rate from
> > underlying network to obtain the frequency of TCP errors that
> > percolate up to the TLS layer.
>
> A bit old but see:
> http://www.ir.bbn.com/documents/artic= les/crc-sigcomm00.pdf
>
> "After an analysis we conclude that the checksum will fail to det= ect
> errors for roughly 1 in 16 million to 10 billion packets".

That's all fine and good, but my point is that this is a distrac= tion.
Though the specific numbers depend greatly on the underlying layer-2
networks traversed by the TCP frame, let's accept the 1:10^10
estimate, in which case anything better than ~2^{-40} is quite
enough.=C2=A0 If so, send a shorter sentinel.

Sure, that's fine. I'm simply dispensing with arguments that we = need to
avoid sending a version because we need the bits to avoid= false
positives.


> > The question is not so much whether 48, 56 or 64 bits is the righ= t
> > amount of protection against random false positives, though if 64=
> > bits is way overkill and the original 48 is more than enough, we<= br> > > could look more closely at that.=C2=A0 Rather, I think the questi= on is
> > whether this work-around should be as simple as possible, or shou= ld
> > be a more feature-full new sub-protocol.=C2=A0 I'm in the kee= p it simple
> > camp (if we should do this at all).

However, the question of simplicity still remains...=C2=A0 I would g= o
with at most a 1 bit field for "TLS 1.2" vs. "TLS 1.3" = in whatever
length sentinel is used.

I don't feel s= trongly about this, but I don't see how what you suggest
is a= ny simpler than the version number encoding I proposed.=C2=A0 Arguably,
it's more complicated since you can't implement the sentinel= check with
memcmp().

-Ekr


=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 VIktor.

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

--001a114d70eef4f3770522545293-- From nobody Sat Oct 17 16:03:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEBC1A0398 for ; Sat, 17 Oct 2015 16:03:00 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QFMfhwghcfZ for ; Sat, 17 Oct 2015 16:02:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669CA1A0395 for ; Sat, 17 Oct 2015 16:02:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2922C284DA3; Sat, 17 Oct 2015 23:02:58 +0000 (UTC) Date: Sat, 17 Oct 2015 23:02:58 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151017230257.GI15070@mournblade.imrryr.org> References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 17 Oct 2015 23:03:01 -0000 On Sat, Oct 17, 2015 at 03:20:08PM -0700, Eric Rescorla wrote: > I don't feel strongly about this, but I don't see how what you suggest > is any simpler than the version number encoding I proposed. Arguably, > it's more complicated since you can't implement the sentinel check with > memcmp(). The simplicity I have in mind minimality of the design, not so much the implementation. The bit in question could be the high bit of of the first octet of server random. The code doing the comparing would need a mutable copy of the test value, and would clone the bit in question from the input to the test value, then memcmp. tls13 = peerrand[0] & 0x80; sentinel[0] = tls13 | (sentinel[0] & 0x7f); if (memcmp(srand, test, len) == 0) { if (tls13) { /* Peer indicates TLS >= 1.3 support */ ... } else { /* Peer indicates TLS 1.2 support */ ... } } -- Viktor. From nobody Sat Oct 17 16:25:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4319D1A1B66 for ; Sat, 17 Oct 2015 16:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbAM-3g5ImvL for ; Sat, 17 Oct 2015 16:25:46 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::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 CB15B1A1B63 for ; Sat, 17 Oct 2015 16:25:46 -0700 (PDT) Received: by ykdz2 with SMTP id z2so29598376ykd.3 for ; Sat, 17 Oct 2015 16:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oDnftTKZ3Vdre2wO0H7UpAn1sesxgxMzG0vPzG39FXc=; b=SJoOck28vUYa02kFQWieM+bS8X5VabveNusbTiw9CIvCQ0XsmoaWghsYDGJguwg1VP b0i/kwf6ZP41tF9Q8dwOUiAek8ZY6ncGRgER0dxWb3IbzxEn4iC/mbNii1dhY9J32S3y 3mPBrtI6RIOIIKvZiVpXY8oRoTgkfbjnQLWR0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=oDnftTKZ3Vdre2wO0H7UpAn1sesxgxMzG0vPzG39FXc=; b=eJ3e0vO0Bm6o1eBMjs6BihI4BNx2m0Hm2KU6rhDoD/wk7YQGp1u1bXI/SAL7rezqyh l6+8B6CdHCJUXyOIJ7hlinJTY/8uahmzQS2/f5mOuYb5rKUKHm8wO1CHt0IOiZCJBUHV kmh79Sqa4EvTkp1gIDMzBno9UwJEmqwJ3G/pa86yt6TGn+C9TvGmbW28vnPcOtOnkLUG hymfBuPnnmUfmuXTnANX+Ilc/o6GXiimGpbhyhX9yFiM0hYZRYvB7CZynLh+QzdodAq2 5gGIvXjCeACZz53V7gwDLk/3/5/62+JfIGruzmzj+nSgTtrjwyWr+mD3VEj2lDUaSvYy iinw== X-Gm-Message-State: ALoCoQnYc+K0/ctPHvYKunde5vyk4JSzIKBYEuJQ8IbScIi1j5BYwKLyEVYt7vVGWEo5SG89fh1A X-Received: by 10.129.128.65 with SMTP id q62mr16957415ywf.210.1445124346037; Sat, 17 Oct 2015 16:25:46 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id z205sm20757503ywz.14.2015.10.17.16.25.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 16:25:45 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20151017123053.GA21936@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sat, 17 Oct 2015 19:25:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <70D5E7FA-27E0-4DEA-9F37-F50006E07757@sn3rd.com> References: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi> <20151017123053.GA21936@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New curves work and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2015 23:25:48 -0000 On Oct 17, 2015, at 08:30, Ilari Liusvaara = wrote: > Okay, did a review of draft-ietf-tls-curve25519 (since it still > doesn't seem to have been WGLC'd): Note that draft-ietf-tls-curve25519 is getting merged into = draft-ietf-tls-rfc4492bis. Note that the cfrg-curves draft=92s RFC5742-review (aka the end-run = review) ended up in =93approved no problem=94 on Thursday: = https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-curves/history/= Basically, now the cfrg draft will just need to work its way through the = RFC editor=92s publication queue. spt= From nobody Sat Oct 17 17:28:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A1C1A6F44 for ; Sat, 17 Oct 2015 17:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sjcm_VLSknC for ; Sat, 17 Oct 2015 17:28:22 -0700 (PDT) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (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 C0AE61A6F3E for ; Sat, 17 Oct 2015 17:28:21 -0700 (PDT) Received: by lfaz124 with SMTP id z124so93044651lfa.1 for ; Sat, 17 Oct 2015 17:28:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=uNb4uG1/BI0smOGlVM4XQ71+U8K1tBjJSEcwKOktT4Q=; b=dHoJ2DzLJsO4Qr7OqjrhhbxKLy/OFNixMYugIAWQjCBqwGRr2vkMirvHpsoLqZmTJ4 HD+YL+/uN4lrkgqB5KtVSwzwwjQjxiJ7LD1COzeIF25L0vTWCGMwmbQhu09bylWX6Ocl D9DzZGAPDLBTg8p8sOtfiuVGXJrJ6xfQ2XBoxK5CK+vK1FKOHRlyvT4HHHO7F88Ux9DT 4LbbVudNRIFCMpIB7KyBqIZQZD+rXX5P4BNz2laRSzqtOCqbHUB9BBLeR0tFYfpwlC8y 9HnNiqo+rFke2ax4yyJcpE5RkO/OirNqnWuOfgV/YrZ/d+2uBK+HPKV8N3Qp4oMX0u4f HoNA== X-Gm-Message-State: ALoCoQmsfX2Uvdl492ETzCZwf22q0n0xMhJhvOIt8VFEVG1S5H4WOmuRD8mHAj/uJ/lPmWgjfkU1 MIME-Version: 1.0 X-Received: by 10.25.163.199 with SMTP id m190mr7591014lfe.13.1445128099946; Sat, 17 Oct 2015 17:28:19 -0700 (PDT) Received: by 10.112.2.231 with HTTP; Sat, 17 Oct 2015 17:28:19 -0700 (PDT) Date: Sat, 17 Oct 2015 17:28:19 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1141184c0d7bc80522561b7b Archived-At: Subject: [TLS] Agenda items for Yokohama X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Oct 2015 00:28:23 -0000 --001a1141184c0d7bc80522561b7b Content-Type: text/plain; charset=UTF-8 Please email the chairs if you have a request for time on the agenda. We expect to spend the meeting time discussing TLS 1.3 and other working group items. You can request time for non-working group items, however we cannot guarantee that there will be time for them. Thanks, J&S --001a1141184c0d7bc80522561b7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please email the chairs if = you have a request for time on the agenda.=C2=A0 We expect to spend =C2=A0t= he meeting time discussing TLS 1.3 and other working group items. =C2=A0 Yo= u can request time for non-working group items, however we cannot guarantee= that there will be time for them. =C2=A0

Thanks,

J&S
--001a1141184c0d7bc80522561b7b-- From lilyemily1985@gmail.com Sat Oct 17 23:51:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C561B2D8A for ; Sat, 17 Oct 2015 23:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.224 X-Spam-Level: X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, 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, SPF_PASS=-0.001] autolearn=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 m7OpsffqTm0N for ; Sat, 17 Oct 2015 23:51:18 -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 A6CEE1B2D89 for ; Sat, 17 Oct 2015 23:51:18 -0700 (PDT) Received: by qkcy65 with SMTP id y65so3082415qkc.0 for ; Sat, 17 Oct 2015 23:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=SLKdqXzzSYTPPTD65DFiQBvITm1KNCFrZlgkBnvrynY=; b=0u68j0miN8SA7FdZA6tXdu4ZPnBXNAEAutRoNLCUtpS4FnHHwU7EAYkXr2irzVhHYh iJ9stLb2F1t08ieNcYuAdgPywBid19OEPX6EDCbawzqxa85LUXv2EJFB9cKdMgZV8uLb pAyUJBUMxd4aiVMlSLwjE0kFRmN+lFT+kK3WzpLQfmjHA79VIi078wA0iIzANyP1f0lB tCTOSv+nONj9ODZbYkbS/LGjNNU5ItYMe/B+nWXKoWospno86dW6hFxsuFSgxOOpptLQ k9V93Kau2OyojydRIGYZ0mbRh/lLGWZdmsi/405XMDVOCsClooSC5FSlfKLmE7214m6w UzOw== X-Received: by 10.55.217.20 with SMTP id u20mr28721094qki.98.1445151077886; Sat, 17 Oct 2015 23:51:17 -0700 (PDT) Received: from hedwig-72.prd.orcali.com (ec2-54-85-253-145.compute-1.amazonaws.com. [54.85.253.145]) by smtp.gmail.com with ESMTPSA id i124sm11666169qhc.12.2015.10.17.23.51.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 23:51:17 -0700 (PDT) Date: Sat, 17 Oct 2015 23:51:17 -0700 (PDT) X-Google-Original-Date: Sun, 18 Oct 2015 06:51:17 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1445151077104.a63f147@Nodemailer> In-Reply-To: References: X-Orchestra-Oid: 9B87580E-47AD-4306-822F-FCAA9E07D3FB X-Orchestra-Sig: c7750d94f0463ead854552fecc6e0de0309fd391 X-Orchestra-Thrid: T4EA62985-EFFE-40D1-9914-B4FC20ADE01B_1515326653239053577 X-Orchestra-Thrid-Sig: 4e2fe16b5d1806ca7830ef6c71d0b1afea15058b X-Orchestra-Account: 6764023008d33fdfa4b5a4b2d029149568db1734 From: lilyemily1985@gmail.com To: "Joseph Salowey" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1445151077295" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Agenda items for Yokohama X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Oct 2015 06:56:01 -0000 ------Nodemailer-0.5.0-?=_1-1445151077295 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable dear sir, I am very much interested about the meeting regardingnon working = group item and reavent agenda. I am requesting you for a time on the agenda= .My local time Dhaka(+6.00). thanking you =E2=80=94 Sent from Mailbox On Sun, Oct 18, 2015 at 6:28 AM, Joseph Salowey wrote: > Please email the chairs if you have a request for time on the agenda. = We > expect to spend the meeting time discussing TLS 1.3 and other working > group items. You can request time for non-working group items, however = we > cannot guarantee that there will be time for them. > Thanks, > J&S ------Nodemailer-0.5.0-?=_1-1445151077295 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
dear sir, I am very much interested about the meeting regardingnon = working group item and reavent agenda. I am requesting you for a time on = the agenda .My local time Dhaka(+6.00). thanking you

=E2=80=94
Sent from Mailbox


On Sun, Oct 18, 2015 at 6:28 AM= , Joseph Salowey <joe@salowey.net> = wrote:

Please email the chairs if you have a = request for time on the agenda.=C2=A0 We expect to spend =C2=A0the meeting = time discussing TLS 1.3 and other working group items. =C2=A0 You can = request time for non-working group items, however we cannot guarantee that = there will be time for them. =C2=A0

Thanks,

J&S

------Nodemailer-0.5.0-?=_1-1445151077295-- From nobody Sun Oct 18 03:39:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B941B2ED1 for ; Sun, 18 Oct 2015 03:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drQ-rz_wYUK6 for ; Sun, 18 Oct 2015 03:39:25 -0700 (PDT) Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.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 1DC631B2ED0 for ; Sun, 18 Oct 2015 03:39:25 -0700 (PDT) Received: by ykaz22 with SMTP id z22so117408839yka.2 for ; Sun, 18 Oct 2015 03:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j57uWwV3JMbUsgHrBE5jCPZhMuHE0rca5pIPJJZ/FHo=; b=06bXy2nlZJDUq5X85oHsav63pvhoVz0LG6+HZ9qUM+7YsyUDzIjfDyHSVzMdHv6Znt B0xRo1NSCtVHwvMIW/SjeiIYKXBfZTjFFmH7mab47exgj+NxgdXoet/DFgBtMeriCfBJ zj8bZYomsmOxuGmseeLyOkMVaTHD748I/Fd0BeeU09Mn5mRQNzIBLcx4GkBUKKYJ+kuF qVJeUVIKwfsnnAakVH7+9Lf3l5moqXdFXoSBQvmvlWSsT5rgP28GnyX2r89zQHDWSZks n5v7fDqTjzvKI331DOVjlmUYK/roxeILmKB8k5ruMHsM4TMhz88mcitSYxrA2KgzuTOa kZZg== MIME-Version: 1.0 X-Received: by 10.129.0.2 with SMTP id 2mr18139993ywa.127.1445164764312; Sun, 18 Oct 2015 03:39:24 -0700 (PDT) Received: by 10.37.113.11 with HTTP; Sun, 18 Oct 2015 03:39:24 -0700 (PDT) Date: Sun, 18 Oct 2015 16:39:24 +0600 Message-ID: From: Sultana Parveen To: "tls@ietfa.amsl.com" Content-Type: multipart/alternative; boundary=001a1140bcb26b3c6b05225ea480 Archived-At: Subject: [TLS] "Re" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Oct 2015 10:39:26 -0000 --001a1140bcb26b3c6b05225ea480 Content-Type: text/plain; charset=UTF-8 it ok -- Sent from Gmail Mobile --001a1140bcb26b3c6b05225ea480 Content-Type: text/html; charset=UTF-8 it ok

--
Sent from Gmail Mobile
--001a1140bcb26b3c6b05225ea480-- From nobody Sun Oct 18 05:26:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80A51A1BA5 for ; Sun, 18 Oct 2015 05:25: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgjeeMCVvyiO for ; Sun, 18 Oct 2015 05:25:55 -0700 (PDT) Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id 929EE1A1BA2 for ; Sun, 18 Oct 2015 05:25:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id A9B8D42E034; Sun, 18 Oct 2015 15:25:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id TwCqEHPg0zsZ; Sun, 18 Oct 2015 15:25:53 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 7BA915BC002; Sun, 18 Oct 2015 15:25:53 +0300 (EEST) Date: Sun, 18 Oct 2015 15:25:52 +0300 From: Ilari Liusvaara To: Sean Turner Message-ID: <20151018122552.GA22896@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi> <20151017123053.GA21936@LK-Perkele-V2.elisa-laajakaista.fi> <70D5E7FA-27E0-4DEA-9F37-F50006E07757@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <70D5E7FA-27E0-4DEA-9F37-F50006E07757@sn3rd.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] New curves work and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Oct 2015 12:25:58 -0000 On Sat, Oct 17, 2015 at 07:25:46PM -0400, Sean Turner wrote: > On Oct 17, 2015, at 08:30, Ilari Liusvaara wrote: > > > Okay, did a review of draft-ietf-tls-curve25519 (since it still > > doesn't seem to have been WGLC'd): > > Note that draft-ietf-tls-curve25519 is getting merged into > draft-ietf-tls-rfc4492bis. Do we also intend to put CFRG signatures work into that? Might be a good idea to merge the CFRG work already. The DHFs are stable. The characteristics of the signature scheme are known well- enough to already put the needed stuff in (if this is to be done), even if CFRG draft is still under work. My thoughts on how CFRG sigs are to be put in: - Reuse the ECDSA ciphersuites. - New signature algorithm EdDSA. - The hash algorithm is always 0 (None), even for Ed25519ph/ Ed448ph. - Two new curves, Ed25519 and Ed448, distinct from X25519 and X448. - If new hashes for existing curves are ever defined, those will get their own NamedCurve value. - Reference document specifying new algorithm for putting EdDSA public keys into PKIX SPKI. - All keys and signatures are octet strings with no internal structure when handled outside the signing and verification functions. - Don't use Ed25519 keys as Ed25519ph keys (and similarly for Ed448/Ed448ph). The CFRG spec specifically warns about this. And how the existing Curve25519 ECDH draft did things: - Reuse the ECDHE ciphersuites. - The X25519/X448 native point format is interpretted as "uncompressed". - Two new curves, X25519 and X448 (different names in that draft tho). - All keys are handled as octet strings with no internal structure outside the DHF. - There are no prefix bytes, so all fields containg public keys (ECPoint.point) and the ECDH result Z are both always 32 or 56 octets. Also, on reading the document, in numerious place it places the restriction that RSA end-entity certificate MUST be signed with RSA and ECDSA end-entity certificate MUST be signed with ECDSA. Why is this? To me, that kind of thing sounds like a leftover from TLS 1.1 days, when signature negotiation was a lot less flexible. It also seems like a special case where uniform handling would work just fine. Also, I think it explicitly contradicts TLS 1.2 RFC, which states that TLS 1.1 did have that restriction and then notes it is lifted (it also updates RFC4492). -Ilari From nobody Mon Oct 19 02:12:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3131A878B for ; Mon, 19 Oct 2015 02:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjjgQ9SB8yjM for ; Mon, 19 Oct 2015 02:12:51 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBDE1A8760 for ; Mon, 19 Oct 2015 02:12:50 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id WxCn1r00F10HQrX01xCoGh; Mon, 19 Oct 2015 11:12:48 +0200 Message-ID: <5624B40D.4080504@openfortress.nl> Date: Mon, 19 Oct 2015 11:12:45 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Benjamin Kaduk References: <56212653.6050702@openfortress.nl> <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> <56216D37.1050701@akamai.com> <5621EF30.8040300@openfortress.nl> <5622857D.90304@akamai.com> <5623528B.7000302@openfortress.nl> <5624553A.8090103@akamai.com> In-Reply-To: <5624553A.8090103@akamai.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 09:12:53 -0000 Hello Benjamin / TLS WG, I didn't mean to drop the list, so your full response is hereby included. >>> No, mutual authentication requires the client to receive a message from >>> the server. >> Yes, I know -- the server needs to handle the session key or the subkey >> to prove posession of its KDC-stored service key. By using it, the client >> can be convinced or server identity. > > Good to hear. Other readers, perhaps, did not. >>> This could be implicit >> I think it automatically is with TLS, since the Finished messages won't >> succeed until both parties have derived the same master secret, which >> if it involves the session key or subkey proves the server's identity in an >> implicit manner. > > From just your short descriptions, it was unclear to me what exactly > went into the master secret from the Kerberos side, so I wanted to be sure. Yes, balancing with terseness. The master secret is calculated as always, incorporating the pre-master secret as well as client/server random and, under RFC 7627, all of the handshake messages up to and including ClientKeyExchange. The pre-master is the combination of the ECDH shared secret and the session key(s) from Kerberos. For the latter, we can choose one or more from: * The session key generated by the KDC for this client/server combination session (lasting as long as the service ticket, usually about a day) * A subkey inserted into the Authenticator by the client for this particular connection (which can avoid replay during ticket life) * Possibly: a random byte string from the server, "decrypted" with the session key, to form a connection-specific key that hinges on server-side entropy I think my preference would be a combination of 2nd and 3rd because that incorporates entropy from both sides; although entropy from both sides is also incorporated through the ClientHello and ServerHello Random bytes, these are not encrypted to conceal it from MITM as in the 2nd and 3rd options. This is a bit paranoid perhaps --the ECDH mechanism achieves a similar thing already-- but the appeal of 2nd and 3rd as very light-weight and makes it much more difficult to crack. >> I do believe a long-enough Finished message is required though. For >> the TLS_ECDHE_KRB_ CipherSuites I've proposed a verify_data_lenth >> to match the required certainty from the message; if we mix Kerberos >> client "certificates" info other CipherSuites like TLS_ECDHE_RSA_ then >> a client SHOULD negotiate a high-enough value and the server MUST >> support that. It requires TLS 1.2 to do these things. >> > > Well, hmm, that's an interesting question. (Note, of course, that the > current Kerberos AES enctypes only use 96 bits of HMAC-SHA1 for their > MIC.) Keyed hashes such as HMAC-SHA1 don't seem to add much here, and they would have a grave impact on how the hashes are calculated in TLS stacks (because the key is only known later in the exchange). I would suggest that we follow TLS' hash preferences, since we are going to rely on those hashes having been computed through the prior exchange of TLS messages, and add those to the IANA Registry for Kerberos Checksum Type Numbers; this currently includes SHA1 and I doubt that anyone would protest to extensions with stronger unkeyed hashes. > The client can obtain information indicating that the server has > the correct Kerberos key both from the decrypted contents of the > Finished message I assume you meant "by matching the Finished message with one generated locally". > and also from the integrity protection of the > TLSCiphertext, since both use material derived from the master secret. Yes, TLSCiphertext is also protected, but my main concern is with Finished, because I would not like accept a TLS connection under doubtful circumstances, just to be OK when an application only sets up TLS as a means of authentication. With the longer Finished messages, that would not happen. > So I guess I'm not yet convinced that the verify_data_length should be > twice the bitlength of the negotiated symmetric cipher, but perhaps I'm > missing something obvious. I'm not sure if it should be 1x or 2x the cipher length. Most important to me is that it must be longer than the 12 bytes that were standard up to TLS 1.1 and default in TLS 1.2. -RIck From nobody Mon Oct 19 07:37:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5271A6F7F for ; Mon, 19 Oct 2015 07:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbEcWo6c43BH for ; Mon, 19 Oct 2015 07:37:53 -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 335DD1A87DE for ; Mon, 19 Oct 2015 07:37:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D62714334C7 for ; Mon, 19 Oct 2015 14:37:51 +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 BC20C4334BA for ; Mon, 19 Oct 2015 14:37:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445265471; bh=8Kat9V0n5F3+d09J7HrUt1K+/Pah8aFOZdm517IiV28=; l=11877; h=From:To:Date:References:In-Reply-To:From; b=NYoMoM2zPACRV196x6ExfDka4luLq4dZVAXGCgmdTyXEmd9rgUKIM+dSR4WnNcWyQ e1SEaK8/AwKiaIXGT9N171H7TDF4K2CEh7CJJyTEjdgTVFEjdB6cbWLle0+ui00nU0 qaQP2oC3kHV+t0DIstTlDcCfzOIhEOm3A24YhpVo= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 960EC2030 for ; Mon, 19 Oct 2015 14:37:51 +0000 (GMT) Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 19 Oct 2015 09:37:51 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Mon, 19 Oct 2015 09:37:51 -0500 From: "Short, Todd" To: "tls@ietf.org" Thread-Topic: [TLS] PR for anti-downgrade mechanism Thread-Index: AQHRAo1rIYkWu6+Z9kuHrxSDHQfmD55kFdgAgAAnWQCACqFpAIAAC9CAgAAJyQCAABn0AIAABjIAgACDCoCAAMyMgIAABv+AgAAA0ACAAAHkAIAAIPYAgAACZICAAATsAIAABXSAgAADTwCAAAEugIAAAhuAgAAAuACAAAv4AIACl4gA Date: Mon, 19 Oct 2015 14:37:50 +0000 Message-ID: <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> In-Reply-To: <20151017230257.GI15070@mournblade.imrryr.org> 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.41.97] Content-Type: multipart/alternative; boundary="_000_84C5B67DF2364BFDAA135CC13062B8C5akamaicom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 14:37:55 -0000 --_000_84C5B67DF2364BFDAA135CC13062B8C5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9lcyB0aGUgc2VudGluZWwgaGF2ZSB0byBiZSB0aGUgZmlyc3QgTiBieXRlcz8NCg0KUkZDIDUy NDYgKFM3LjQuMS4yKSBzcGVjaWZpZXMgUmFuZG9tIGFzIGEgY29tYmluYXRpb24gb2YgYSB1aW50 MzIgdGltZSB2YWx1ZSBhbmQgMjggcmFuZG9tIGJ5dGVzLg0KDQpSYXRoZXIgdGhhbiByaXNrIGJy ZWFraW5nIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGJ5IGNoYW5naW5nIHRoZSBkZWZpbml0aW9u IG9mIHRoZSBmaXJzdCA0IGJ5dGVzLCBwZXJoYXBzIHRoZSBzZW50aW5lbCBjYW4gYmUgbW92ZWQg dG8gYW5vdGhlciBsb2NhdGlvbiB3aXRoaW4gdGhlIFNlcnZlclJhbmRvbSBmaWVsZD8gRWl0aGVy IHRoZSAgc2Vjb25kIHNldCBvZiBOIGJ5dGVzIG9yIHRoZSBsYXN0IHNldCBvZiBOIGJ5dGVzPyBX aGVyZSB0aGUgc2VudGluZWwgaXMgbG9jYXRlZCBzaG91bGRu4oCZdCByZWFsbHkgbWF0dGVyLiBT dWJzZXF1ZW50bHksIHRoZSBzZW50aW5lbCBjYW4gYmUgY2hvc2VuIHdpdGggbW9yZSBmcmVlZG9t LiBBcyBJIHJlY2FsbCwgb25lIHJlYXNvbiAoYnV0IG5vdCB0aGUgb25seSByZWFzb24pIHRoZSBs ZW5ndGggd2FzIGV4dGVuZGVkIHRvIDggYnl0ZXMgZHVlIHRvIHRoZSBnbXRfdW5peF90aW1lIGlz c3VlOyBpcyBhbiA4LWJ5dGUgc2VudGluZWwgc3RpbGwgbmVlZGVkIGlmIGl04oCZcyBub3Qgb3Zl cmxhcHBpbmcgdGhlIGdtdF91bml4X3RpbWUgKHllcywgSeKAmW0gY29uY2VybmVkIGFib3V0IGEg cmVkdWN0aW9uIG9mIGVudHJvcHkgYnkgMjUlKT8NCg0KSW4gZXh0ZW5kaW5nIHRoaXMsIHNob3Vs ZCB0aGUgQ2xpZW50SGVsbG8gcmFuZG9tIHZhbHVlIGFsc28gaW5jbHVkZSB0aGUgc2VudGluZWw/ IChZZXMsIEkga25vdyB0aGlzIGFnYWluIHJlZHVjZXMgZW50cm9weS4pIEEgTUlUTSBjYW4gaW1w bGVtZW50IGEgZG93bmdyYWRlIGF0dGFjayBpbiBlaXRoZXIgZGlyZWN0aW9uLiBUaGUgc2VydmVy IGNhbiB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24gdGhhdCBtdWNoIGVhcmxpZXIuIChSaXNrOiB+ Ml57LTY0fSB0aGF0IGFuIG9sZGVyIGNsaWVudCBtaWdodCBiZSByZWplY3RlZCBmb3IgaGF2aW5n IGEgbWlzbWF0Y2hlZCBzZW50aW5lbC92ZXJzaW9uLikNCg0KVmlrdG9yIER1a2hvdm5pIGhhZCBw cm9wb3NlZCBhIH41IGJ5dGUgc2VudGluZWw6DQoNCnN0cnVjdCB7DQogICAgdWludDMyIGdtdF91 bml4X3RpbWU7DQogICAgb3BhcXVlIHJhbmRvbV9ieXRlc1syM107DQogICAgdWludDggc2VudGlu ZWxbNV07DQp9IFJhbmRvbTsNCg0KLS0NCi1Ub2RkIFNob3J0DQovLyB0c2hvcnRAYWthbWFpLmNv bTxtYWlsdG86dHNob3J0QGFrYW1haS5jb20+DQovLyAiT25lIGlmIGJ5IGxhbmQsIHR3byBpZiBi eSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4iDQoNCk9uIE9jdCAxNywgMjAxNSwgYXQg NzowMiBQTSwgVmlrdG9yIER1a2hvdm5pIDxpZXRmLWRhbmVAZHVraG92bmkub3JnPG1haWx0bzpp ZXRmLWRhbmVAZHVraG92bmkub3JnPj4gd3JvdGU6DQoNCk9uIFNhdCwgT2N0IDE3LCAyMDE1IGF0 IDAzOjIwOjA4UE0gLTA3MDAsIEVyaWMgUmVzY29ybGEgd3JvdGU6DQoNCkkgZG9uJ3QgZmVlbCBz dHJvbmdseSBhYm91dCB0aGlzLCBidXQgSSBkb24ndCBzZWUgaG93IHdoYXQgeW91IHN1Z2dlc3QN CmlzIGFueSBzaW1wbGVyIHRoYW4gdGhlIHZlcnNpb24gbnVtYmVyIGVuY29kaW5nIEkgcHJvcG9z ZWQuICBBcmd1YWJseSwNCml0J3MgbW9yZSBjb21wbGljYXRlZCBzaW5jZSB5b3UgY2FuJ3QgaW1w bGVtZW50IHRoZSBzZW50aW5lbCBjaGVjayB3aXRoDQptZW1jbXAoKS4NCg0KVGhlIHNpbXBsaWNp dHkgSSBoYXZlIGluIG1pbmQgbWluaW1hbGl0eSBvZiB0aGUgZGVzaWduLCBub3Qgc28gbXVjaA0K dGhlIGltcGxlbWVudGF0aW9uLg0KDQpUaGUgYml0IGluIHF1ZXN0aW9uIGNvdWxkIGJlIHRoZSBo aWdoIGJpdCBvZiBvZiB0aGUgZmlyc3Qgb2N0ZXQgb2YNCnNlcnZlciByYW5kb20uICBUaGUgY29k ZSBkb2luZyB0aGUgY29tcGFyaW5nIHdvdWxkIG5lZWQgYSBtdXRhYmxlDQpjb3B5IG9mIHRoZSB0 ZXN0IHZhbHVlLCBhbmQgd291bGQgY2xvbmUgdGhlIGJpdCBpbiBxdWVzdGlvbiBmcm9tDQp0aGUg aW5wdXQgdG8gdGhlIHRlc3QgdmFsdWUsIHRoZW4gbWVtY21wLg0KDQp0bHMxMyA9IHBlZXJyYW5k WzBdICYgMHg4MDsNCnNlbnRpbmVsWzBdID0gdGxzMTMgfCAoc2VudGluZWxbMF0gJiAweDdmKTsN CmlmIChtZW1jbXAoc3JhbmQsIHRlc3QsIGxlbikgPT0gMCkgew0KICAgaWYgKHRsczEzKSB7DQov KiBQZWVyIGluZGljYXRlcyBUTFMgPj0gMS4zIHN1cHBvcnQgKi8NCi4uLg0KICAgfSBlbHNlIHsN Ci8qIFBlZXIgaW5kaWNhdGVzIFRMUyAxLjIgc3VwcG9ydCAqLw0KLi4uDQogICB9DQp9DQoNCi0t DQpWaWt0b3IuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_84C5B67DF2364BFDAA135CC13062B8C5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <934E00FFD2D91B44A603822C2372937A@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRG9lcyB0aGUgc2VudGluZWwgaGF2 ZSB0byBiZSB0aGUgZmlyc3QgTiBieXRlcz8NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJGQyA1MjQ2IChTNy40LjEuMikgc3BlY2lmaWVzIFJhbmRv bSBhcyBhIGNvbWJpbmF0aW9uIG9mIGEgdWludDMyIHRpbWUgdmFsdWUgYW5kIDI4IHJhbmRvbSBi eXRlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlJhdGhlciB0aGFuIHJpc2sgYnJlYWtpbmcgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkg YnkgY2hhbmdpbmcgdGhlIGRlZmluaXRpb24gb2YgdGhlIGZpcnN0IDQgYnl0ZXMsIHBlcmhhcHMg dGhlIHNlbnRpbmVsIGNhbiBiZSBtb3ZlZCB0byBhbm90aGVyIGxvY2F0aW9uIHdpdGhpbiB0aGUg U2VydmVyUmFuZG9tIGZpZWxkPyBFaXRoZXIgdGhlICZuYnNwO3NlY29uZCBzZXQgb2YgTiBieXRl cyBvciB0aGUgbGFzdCBzZXQgb2YgTiBieXRlcz8NCiBXaGVyZSB0aGUgc2VudGluZWwgaXMgbG9j YXRlZCBzaG91bGRu4oCZdCByZWFsbHkgbWF0dGVyLiBTdWJzZXF1ZW50bHksIHRoZSBzZW50aW5l bCBjYW4gYmUgY2hvc2VuIHdpdGggbW9yZSBmcmVlZG9tLiBBcyBJIHJlY2FsbCwgb25lIHJlYXNv biAoYnV0IG5vdCB0aGUgb25seSByZWFzb24pIHRoZSBsZW5ndGggd2FzIGV4dGVuZGVkIHRvIDgg Ynl0ZXMgZHVlIHRvIHRoZSBnbXRfdW5peF90aW1lIGlzc3VlOyBpcyBhbiA4LWJ5dGUgc2VudGlu ZWwgc3RpbGwNCiBuZWVkZWQgaWYgaXTigJlzIG5vdCBvdmVybGFwcGluZyB0aGUgZ210X3VuaXhf dGltZSAoeWVzLCBJ4oCZbSBjb25jZXJuZWQgYWJvdXQgYSByZWR1Y3Rpb24gb2YgZW50cm9weSBi eSAyNSUpPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SW4gZXh0ZW5kaW5nIHRoaXMsIHNob3VsZCB0aGUgQ2xpZW50SGVsbG8gcmFuZG9t IHZhbHVlIGFsc28gaW5jbHVkZSB0aGUgc2VudGluZWw/IChZZXMsIEkga25vdyB0aGlzIGFnYWlu IHJlZHVjZXMgZW50cm9weS4pIEEgTUlUTSBjYW4gaW1wbGVtZW50IGEgZG93bmdyYWRlIGF0dGFj ayBpbiBlaXRoZXIgZGlyZWN0aW9uLiBUaGUgc2VydmVyIGNhbiB0ZXJtaW5hdGUgdGhlIGNvbm5l Y3Rpb24gdGhhdCBtdWNoIGVhcmxpZXIuDQogKFJpc2s6IH4yXnstNjR9IHRoYXQgYW4gb2xkZXIg Y2xpZW50IG1pZ2h0IGJlIHJlamVjdGVkIGZvciBoYXZpbmcgYSBtaXNtYXRjaGVkIHNlbnRpbmVs L3ZlcnNpb24uKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VmlrdG9yIER1a2hvdm5pIGhhZCBwcm9wb3NlZCBhIH41IGJ5dGUgc2VudGlu ZWw6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+c3RydWN0IHsmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyB1aW50MzIgZ210X3VuaXhfdGltZTs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyBvcGFxdWUgcmFuZG9tX2J5dGVzWzIzXTs8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Jm5ic3A7ICZuYnNwOyB1aW50OCBzZW50aW5lbFs1XTs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ fSBSYW5kb207PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdiBhcHBsZS1j b250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tLTwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4tVG9kZCBTaG9ydDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4vLyA8 YSBocmVmPSJtYWlsdG86dHNob3J0QGFrYW1haS5jb20iIGNsYXNzPSIiPnRzaG9ydEBha2FtYWku Y29tPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4vLyAmcXVvdDtPbmUgaWYgYnkgbGFuZCwgdHdv IGlmIGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiZxdW90OzwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3QgMTcsIDIwMTUsIGF0IDc6MDIg UE0sIFZpa3RvciBEdWtob3ZuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtZGFuZUBkdWtob3Zu aS5vcmciIGNsYXNzPSIiPmlldGYtZGFuZUBkdWtob3ZuaS5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rp dj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIi Pk9uIFNhdCwgT2N0IDE3LCAyMDE1IGF0IDAzOjIwOjA4UE0gLTA3MDAsIEVyaWMgUmVzY29ybGEg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+SSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IHRoaXMsIGJ1dCBJIGRvbid0 IHNlZSBob3cgd2hhdCB5b3Ugc3VnZ2VzdDxiciBjbGFzcz0iIj4NCmlzIGFueSBzaW1wbGVyIHRo YW4gdGhlIHZlcnNpb24gbnVtYmVyIGVuY29kaW5nIEkgcHJvcG9zZWQuICZuYnNwO0FyZ3VhYmx5 LDxiciBjbGFzcz0iIj4NCml0J3MgbW9yZSBjb21wbGljYXRlZCBzaW5jZSB5b3UgY2FuJ3QgaW1w bGVtZW50IHRoZSBzZW50aW5lbCBjaGVjayB3aXRoPGJyIGNsYXNzPSIiPg0KbWVtY21wKCkuPGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHNpbXBsaWNpdHkg SSBoYXZlIGluIG1pbmQgbWluaW1hbGl0eSBvZiB0aGUgZGVzaWduLCBub3Qgc28gbXVjaDxiciBj bGFzcz0iIj4NCnRoZSBpbXBsZW1lbnRhdGlvbi4gJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KVGhlIGJpdCBpbiBxdWVzdGlvbiBjb3VsZCBiZSB0aGUgaGlnaCBiaXQgb2Ygb2Yg dGhlIGZpcnN0IG9jdGV0IG9mPGJyIGNsYXNzPSIiPg0Kc2VydmVyIHJhbmRvbS4gJm5ic3A7VGhl IGNvZGUgZG9pbmcgdGhlIGNvbXBhcmluZyB3b3VsZCBuZWVkIGEgbXV0YWJsZTxiciBjbGFzcz0i Ij4NCmNvcHkgb2YgdGhlIHRlc3QgdmFsdWUsIGFuZCB3b3VsZCBjbG9uZSB0aGUgYml0IGluIHF1 ZXN0aW9uIGZyb208YnIgY2xhc3M9IiI+DQp0aGUgaW5wdXQgdG8gdGhlIHRlc3QgdmFsdWUsIHRo ZW4gbWVtY21wLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBs ZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPnRsczEzID0gcGVlcnJh bmRbMF0gJmFtcDsgMHg4MDs8YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5zZW50aW5lbFswXSA9IHRsczEzIHwg KHNlbnRpbmVsWzBdICZhbXA7IDB4N2YpOzxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBs ZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPmlmIChtZW1jbXAoc3Jh bmQsIHRlc3QsIGxlbikgPT0gMCkgezxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPiZuYnNwOyZuYnNwOyZuYnNw O2lmICh0bHMxMykgezxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIg c3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3Bh biIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPi8qIFBlZXIgaW5kaWNhdGVzIFRMUyAm Z3Q7PSAxLjMgc3VwcG9ydCAqLzxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPi4uLjxiciBjbGFzcz0iIj4N CjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9z cGFuPiZuYnNwOyZuYnNwOyZuYnNwO30gZWxzZSB7PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LyogUGVl ciBpbmRpY2F0ZXMgVExTIDEuMiBzdXBwb3J0ICovPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+Li4uPGJy IGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3Bh Y2U6cHJlIj48L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPn08YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLSA8YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0i QXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5WaWt0b3IuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpUTFMgbWFpbGluZyBsaXN0PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgY2xhc3M9IiI+VExTQGlldGYub3Jn PC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGxzPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_84C5B67DF2364BFDAA135CC13062B8C5akamaicom_-- From nobody Mon Oct 19 08:10:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35C81ACD18 for ; Mon, 19 Oct 2015 08:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvlaPxNSClvj for ; Mon, 19 Oct 2015 08:10:14 -0700 (PDT) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) (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 768A91AC3CA for ; Mon, 19 Oct 2015 08:09:12 -0700 (PDT) Received: by ykdz2 with SMTP id z2so60328140ykd.3 for ; Mon, 19 Oct 2015 08:09:11 -0700 (PDT) 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-type; bh=QP4oPWGkYO+SKGHIG6psl2hpNCtjf3Dk1c5sKOMXCqY=; b=kKVGp9MnPwFw0YyFYNbKQpCQVcNtlYzAmm1mljvKuTIoHQBVgfBT8QebIeswYdw+Gs cBPpdBQRlSmIrXPyKDOZcgxRbzND+5RuzjsKM8ncCCQGM+AZPQsFmsticfsvE7zmbxQA 6NdJo6WsD3Uau2fcoQ1wlMhE9mGeXpOcQ4e1XA/oiZ/H+vRrBF7uPkJDj3t3hRMKX6+R MoY6ZuZldtItsgaTGTmZio2GauW5Zo0EaA5AFWl24G/7tpWng+P40DhjTmXjgNZbdOWM oZdYSgy3JNAgeSPb6bP5gnyHECqNO36FyF4dvmdSDxNl/WpGzgPrnDmmtiGbt9RyF9BR bcMw== X-Gm-Message-State: ALoCoQlxlFGTjm9jczYzhx6m9BIvvkuo6mPbFlZ2VHHMIUqE5RtqmBZAPKH3+Fxwiordpn8UQTFo X-Received: by 10.129.154.85 with SMTP id r82mr2414682ywg.81.1445267351625; Mon, 19 Oct 2015 08:09:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Mon, 19 Oct 2015 08:08:31 -0700 (PDT) In-Reply-To: <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> From: Eric Rescorla Date: Mon, 19 Oct 2015 08:08:32 -0700 Message-ID: To: "Short, Todd" Content-Type: multipart/alternative; boundary=94eb2c0b77cc1996b60522768714 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 15:10:15 -0000 --94eb2c0b77cc1996b60522768714 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote: > Does the sentinel have to be the first N bytes? > > RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time > value and 28 random bytes. > > Rather than risk breaking backwards compatibility by changing the > definition of the first 4 bytes, perhaps the sentinel can be moved to > another location within the ServerRandom field? Either the second set of= N > bytes or the last set of N bytes? Where the sentinel is located shouldn= =E2=80=99t > really matter. Subsequently, the sentinel can be chosen with more freedom= . > As I recall, one reason (but not the only reason) the length was extended > to 8 bytes due to the gmt_unix_time issue; is an 8-byte sentinel still > needed if it=E2=80=99s not overlapping the gmt_unix_time (yes, I=E2=80=99= m concerned about > a reduction of entropy by 25%)? > Maybe it's because I haven't had my coffee yet, but ISTM that overloading the time field lowers the risk of false positives because we can choose a sentinel that will never collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in the randomly generated portion always has a 2^{-n} chance of collision. > In extending this, should the ClientHello random value also include the > sentinel? (Yes, I know this again reduces entropy.) A MITM can implement = a > downgrade attack in either direction. The server can terminate the > connection that much earlier > How does this help? The attacker will just rewrite the ClientHello.random. -Ekr --94eb2c0b77cc1996b60522768714 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd <tshort@akamai.com>= ; wrote:
Does the sentinel have to be the first N bytes?

RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time= value and 28 random bytes.

Rather than risk breaking backwards compatibility by changing the defi= nition of the first 4 bytes, perhaps the sentinel can be moved to another l= ocation within the ServerRandom field? Either the =C2=A0second set of N byt= es or the last set of N bytes? Where the sentinel is located shouldn=E2=80=99t really matter. Subsequentl= y, the sentinel can be chosen with more freedom. As I recall, one reason (b= ut not the only reason) the length was extended to 8 bytes due to the gmt_u= nix_time issue; is an 8-byte sentinel still needed if it=E2=80=99s not overlapping the gmt_unix_time (yes, I=E2=80=99m= concerned about a reduction of entropy by 25%)?

Maybe it's because I haven't had my coffee yet, b= ut ISTM that overloading the time field
lowers the risk of false = positives because we can choose a sentinel that will never
collid= e with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in the
randomly generated portion always has a 2^{-n} chance of collision.<= /div>

=C2=A0
In extending this, should the ClientHello random value also include th= e sentinel? (Yes, I know this again reduces entropy.) A MITM can implement = a downgrade attack in either direction. The server can terminate the connec= tion that much earlier

How does= this help? The attacker will just rewrite the ClientHello.random.

-Ekr
--94eb2c0b77cc1996b60522768714-- From nobody Mon Oct 19 08:10:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4C01ACD5F for ; Mon, 19 Oct 2015 08:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcpslwBLX7Dv for ; Mon, 19 Oct 2015 08:10:18 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D2E1AC3D7 for ; Mon, 19 Oct 2015 08:09:21 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id B16311A00C8 for ; Mon, 19 Oct 2015 17:09:19 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eHHpimjN22UB for ; Mon, 19 Oct 2015 17:09:18 +0200 (CEST) Received: from mail-essen-02.secunet.de (unknown [10.53.40.205]) by a.mx.secunet.com (Postfix) with ESMTP id 812021A008A for ; Mon, 19 Oct 2015 17:09:18 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 17:09:18 +0200 From: =?utf-8?B?U2NobWlkdCwgSsO2cm4tTWFyYw==?= To: " (tls@ietf.org)" Thread-Topic: New Version Notification for draft-schmidt-pake-tls-00.txt Thread-Index: AQHRCn81EzghXtij/EWbQYzzVMy7Fp5y6YOw Date: Mon, 19 Oct 2015 15:09:17 +0000 Message-ID: <38634A9C401D714A92BB13BBA9CCD34F16711C70@mail-essen-01.secunet.de> References: <20151019150236.27390.29315.idtracker@ietfa.amsl.com> In-Reply-To: <20151019150236.27390.29315.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.208.1.80] x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0225_01D10A90.E2ACF850" MIME-Version: 1.0 Archived-At: Subject: [TLS] New Version Notification for draft-schmidt-pake-tls-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 15:10:27 -0000 ------=_NextPart_000_0225_01D10A90.E2ACF850 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear all, I just submitted a draft for integrating PAKE in TLS (see below). The = main idea is to define one PAKE-identifier that can be used for = different schemes alike instead of having to specify a = ClientHello-Extension for each and every new scheme. Any feedback/comments/further ideas are very welcome. Best regards, J=C3=B6rn -----Urspr=C3=BCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Gesendet: Montag, 19. Oktober 2015 17:03 An: Schmidt, J=C3=B6rn-Marc; Schmidt, J=C3=B6rn-Marc; "Dennis = K=C3=BCgler"; Dennis Kuegler Betreff: New Version Notification for draft-schmidt-pake-tls-00.txt A new version of I-D, draft-schmidt-pake-tls-00.txt has been successfully submitted by J=C3=B6rn-Marc Schmidt and posted to = the IETF repository. Name: draft-schmidt-pake-tls Revision: 00 Title: Using Password-Authenticated Key Agreement (PAKE) schemes in TLS Document date: 2015-10-19 Group: Individual Submission Pages: 14 URL: = https://www.ietf.org/internet-drafts/draft-schmidt-pake-tls-00.txt Status: https://datatracker.ietf.org/doc/draft-schmidt-pake-tls/ Htmlized: https://tools.ietf.org/html/draft-schmidt-pake-tls-00 Abstract: This document describes how to integrate Password-Authenticated Key Agreement (PAKE) schemes into TLS. These schemes enable two parties who share a potentially weak password to derive a common cryptographic key, allowing them to establish a secure channel. The current document defines a generic way to integrate PAKE schemes into TLS. In addition, it demonstrates how to use the well-known Password Authenticated Connection Establishment (PACE) scheme in TLS as an example for the generic construction. = =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. The IETF Secretariat ------=_NextPart_000_0225_01D10A90.E2ACF850 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILcDCCA4Aw ggJooAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAj BgNVBAoMHHNlY3VuZXQgU2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMB4XDTEzMDkx NDE4MDczN1oXDTE2MDkwMjE4MDczN1owUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0wNDEWMBQG A1UECwwNUHVibGljIFNlY3RvcjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCRqvsVVv5MbQS8cy8hB4K/W1zCJkQmiEzH+Dq6Jk+v J60qwXQW+rAkohGpglka0Cunv/nEWcTuOV2WZg+GtvQcriWs6Xgo22SCE41r5zXOtmgYrWlXOYbl clirYVzfvpeQBOklcBd2Pu7scdlN7lR6ZNkxxJjcMZh/jLkEbIWV7pew3DdafUvjH7P9ecLaB2HD 9JM7h0/uUiwWCtJ1u+1Mnqu4SVYuFTu1oUTkBjrWxO7e7F3MweO6VxjMn0vEppBDSPiK19X/hUd8 Snq2clBGy+njz+SjgIntsvTT+VAm7Ax4J+Y1dYujzA4NDFdkWvcp7+HoxmUpOKprR6WXEsKhAgMB AAGjZjBkMA4GA1UdDwEB/wQEAwIBBjAfBgNVHSMEGDAWgBTbc5QVtU5hMX1CgwnNa7eRfeSseDAS BgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQNs9mwGqcOKL6k9pOo2AZkexvv6jANBgkqhkiG 9w0BAQUFAAOCAQEAq0bGL+Dq20x3nEqUpirjsl2CKhN999HnMaybNrRpS9u4NueLdnHpTEVh2L5h WqRWm9bNpcKN+c8bOB4rC9pcKIQBzam+sDAbfAApsdfovBnmHVyeAWYJj5p04gwBS1ie8+pPJnnb 0DCOhqTwn2wZxtql2P0yLaTuZAdO7t7zFiZbdOUlniRI2dOnF9ZrsC+FMD3WE6sLgktO0+1cST4F QSAtLAJ0NfSp0e9aKJhX+4dzt3zps+GA5bP4OM4iFO0E+xVwzdERZ48lGsRIFo3DhdLwJbgM3uvn 9A63hUU/ig0hTf5gGllVSrSAPFmhsTTJgkqGOnBa0RffRxqHm2gmJDCCA5EwggJ5oAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAjBgNVBAoMHHNlY3Vu ZXQgU2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMB4XDTExMDkwNDIyMDAwMFoXDTE2 MDkwMjIyMDAwMFowTTEXMBUGA1UEAwwOc2VjdW5ldC1QS0ktMDExJTAjBgNVBAoMHHNlY3VuZXQg U2VjdXJpdHkgTmV0d29ya3MgQUcxCzAJBgNVBAYTAkRFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEArKUOCQL/pHw+XdjEHgzp8TgwonnZnVmh/8f90GdWdGb9qr2Yb/yRiP4qxGRX9fbI gY/DYoR8995d5Er9cYWfDZZErNkSW0IJIQh0xxHCLxlJG1zfp3vyJgVfpCCPVHmfLa3mH66gpLue cO+rmQ2dcrKpAMf8v9C6YLYe5gP0ng9CoHvGKVmZ/McejJMzO+36luZbo8Ueqv9S31XTeHj2FiTu JK8Vg8k/xZMVPkj1L1ZNiQi/hC9nAb6+YWAL6RKjHGtHdP7AQcmSQbTKaDmZvU/vEtty9DlQgL9z m0Ao8aZM5dJUtzfiafC1dHOnWLTmVtXDYGIhl0e4xpP0NWxW7wIDAQABo3wwejAOBgNVHQ8BAf8E BAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBATBUBgNVHR8ETTBLMEmgR6BFhkNodHRwOi8veDUwOS5z ZWN1bmV0LmNvbS9DUkw/aWQ9YjNhMWE2MzItMzRkNy00NzljLThiMTktNTBjZDNlMWI2NmY0MA0G CSqGSIb3DQEBBQUAA4IBAQBa6Bmjnd8xkB0vtybolc0A5op6EhnXNcJJsgB7CAGQD0Qt8C6Jj/6c V7mtcUg5MY/EblmJyoZfVuOuPlCOfRD25LDwQ386Lh3XdiaNeWp7t8jABHnCkNq9jLjt5VS4ZitT VmLqn78dUbypFezZnehNaELVuDCrkvKkqp9r+hw32MOgCCm42uUauIUL6N1oM0kZo9tV3m7ddBiA JPPqRgt1BUcbvN4fbSOgzFedC5vM+jobHZ1Y+qHW7FRgMkxJcNq+Rc0LeOtbU9/b0oDeUv/p75j4 eW7FZyHoGr9iWD/kqbn9pzPhI+iHgTczOSxHvw1ieSDu2QEm7XqLw+fqpiU0MIIEUzCCAzugAwIB AgIBSTANBgkqhkiG9w0BAQUFADBSMRkwFwYDVQQDDBBQdWJsaWMtU2VjdG9yLTA0MRYwFAYDVQQL DA1QdWJsaWMgU2VjdG9yMRAwDgYDVQQKDAdzZWN1bmV0MQswCQYDVQQGEwJkZTAeFw0xNDEwMjEx MjA1MjNaFw0xNjA5MDExMjA1MjNaMIGlMRswGQYDVQQDDBJKw7Zybi1NYXJjIFNjaG1pZHQxEDAO BgNVBAQMB1NjaG1pZHQxEzARBgNVBCoMCkrDtnJuLU1hcmMxEzARBgNVBAsMCkdvdmVybm1lbnQx FjAUBgNVBAsMDVB1YmxpYyBTZWN0b3IxJTAjBgNVBAoMHHNlY3VuZXQgU2VjdXJpdHkgTmV0d29y a3MgQUcxCzAJBgNVBAYTAmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn3zvWShw r9UJ9cOR9EnSf6TAFItMTptXsXT+oiQmmtOYJHaQUeJ4imehiVABAGL5azr8b4b6EFG1bo0jA1lO +hmb6WD6JEIiq0T1ppL7tZle2xVvM/xEsljMoSKroTrE6rx7AUwAhi54pqabF1HlmWsP87cXwEZZ bnR4sQuF/MfmN7mSe7SY5VG/5El+Dw4YOkjVBmSojiHEO2EBH63YCboPpMJ/hLMZ1rcBaIh9eRl2 uULeNAnGR4+R9IQGQjtJNPvw3n9ca20f8+irCqMpcv5e+VhlTTFHB0K2d/Nzh4BAVluH3u14nrCA IjHhplaOyuoPlw3Q+oPVf+C3ADg00QIDAQABo4HfMIHcMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6 Ly94NTA5LnNlY3VuZXQuY29tL0NSTD9pZD03OTZkNzQyNS0xNjU1LTRmMjctYTBmOC0wMTc1YjM1 MDk4YjYwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwHwYDVR0jBBgwFoAUDbPZsBqnDii+pPaT qNgGZHsb7+owHQYDVR0OBBYEFGOaRJ/ILBu0+4ik5ZQv6NKv0pzLMCkGA1UdEQQiMCCBHmpvZXJu LW1hcmMuc2NobWlkdEBzZWN1bmV0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAB1eAd0+CCJibZxRQ VpgQMp07AUXWyIDno76zBDUwbPioewEzJgerzOnvtGLqMeXaSfgde7nh88itchqYIPhre2pRPPI6 Jpdoqc3HkmtJYPy7cVGThsnr2f7Cn72Tv024/9ZWgN5Muzk8/PisuJa9Vd0nqzDrfcDwbRtfQq8Y kmVs3sNZsknljMfKqRyl6frO3RGGJukReVh+Puksv1Mn6Tn9Bb9w5nNropX6hmHJsyiofLs5IC03 faTKeQIufgven777EpRZePzqfdibhNOL4jvsm45dOXuzlwFDrAoBByiuWmUN3d6zPe8Z7UdUlzuv 8Q21RgJ8bMKpLyLKaa6nQjGCA18wggNbAgEBMFcwUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0w NDEWMBQGA1UECwwNUHVibGljIFNlY3RvcjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUC AUkwCQYFKw4DAhoFAKCCAd0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTUxMDE5MTUwOTE2WjAjBgkqhkiG9w0BCQQxFgQUPCPIJ5Hq3DXLUZ0NBLahVTzKUfswZgYJ KwYBBAGCNxAEMVkwVzBSMRkwFwYDVQQDDBBQdWJsaWMtU2VjdG9yLTA0MRYwFAYDVQQLDA1QdWJs aWMgU2VjdG9yMRAwDgYDVQQKDAdzZWN1bmV0MQswCQYDVQQGEwJkZQIBSTBoBgsqhkiG9w0BCRAC CzFZoFcwUjEZMBcGA1UEAwwQUHVibGljLVNlY3Rvci0wNDEWMBQGA1UECwwNUHVibGljIFNlY3Rv cjEQMA4GA1UECgwHc2VjdW5ldDELMAkGA1UEBhMCZGUCAUkwgasGCSqGSIb3DQEJDzGBnTCBmjAL BglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG 9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhow CwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA AlKpb1DaWb1h11j6NaY13C17aHJlfQ/yhtWvOqOpa2Hr0lqfWEKD6rzYM71MPxviBdF4fxtZCoRK sciXps+qXUWzNuTKi8pgYZVFRP+jQfRXRBFXvmiUdDQYUTkCXtCmLclfawFu0tffLOwxowmbzQNM lit4znvgvHMpzW5UgTtGjg/7GDQpCJw6aEMDrc8ZItI4S161qxEBXpLdKnjDbRpnKM0phs0uGRwD yIXM0Ve3NU8awdVFd4YRXmiYvMXn/9Qz8qhIv6r8b/Qwh42n/sx4U0WYlEtHDZ9NLZkBV5F5nFm4 zmbc7nBteIEYuf0gzOYsltSfh4gAdhgQg4oRJAAAAAAAAA== ------=_NextPart_000_0225_01D10A90.E2ACF850-- From nobody Mon Oct 19 08:31:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61EC1ACD9B for ; Mon, 19 Oct 2015 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 zE3T_FZMrZXK for ; Mon, 19 Oct 2015 08:31:39 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 587911ACD92 for ; Mon, 19 Oct 2015 08:31:38 -0700 (PDT) Received: by ioll68 with SMTP id l68so34541292iol.3 for ; Mon, 19 Oct 2015 08:31:37 -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:content-type; bh=Dq/cKvY8nstNX2shW3knzW/uWlOrGCL5QlKO6bk7Rko=; b=Oo8NuF1bv3lV1OGj7rknDGX//84eZICcbuTZlID+PPvoD8fjtZs1dwxC2+UEY/PCpe lIG6YOz1yCAOi643zNAwA6ZvpcjFx0b8nlBdlEa2RgbVvv1lF/cPYAlFEvo6KWnF18am cEJ+GSlUJ3LwykRpbXtFfOprqdeahzPS4iuqs= 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:content-type; bh=Dq/cKvY8nstNX2shW3knzW/uWlOrGCL5QlKO6bk7Rko=; b=e6iJ2JeApBx5DQiYnZXe3//xz1azDcl7PcWZk68b36SjgiXU5wwSbVYBq/8cDzDw/n kf/kJmosXZ5OadgbjTr/crtQJEil0Y6X84XwTz7kIExQCuW00OdOGSBSGHQ2D1ZFyA61 e1ChnUIFWFgEb9T70DVSZudI0FRJMWc2gG/K+KLA7wBWoiiP3tuFhnbgNfyrDoMRfc2D ohB2g/3aCZqN5xyptobx7DLRr5OuRXvGqbOOBw0f1ajfWtmrHtB95TdeGRwNmf+rJf41 PfzG2M03X9DyErO7R1qvEPSEK9ogUdzySGvKy8Z/5V5veRYW4Qv4rK0Q2nWyaA4xhf7W RTDQ== X-Gm-Message-State: ALoCoQkIMLSKU7fXUty1AyOXcVRqDvQvSAZ30wRe3soZg7efw4V61GoDpby8dQC2yL0bgZNJcQIz X-Received: by 10.107.148.78 with SMTP id w75mr3327546iod.26.1445268695744; Mon, 19 Oct 2015 08:31:35 -0700 (PDT) MIME-Version: 1.0 References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> In-Reply-To: From: David Benjamin Date: Mon, 19 Oct 2015 15:31:26 +0000 Message-ID: To: Eric Rescorla , "Short, Todd" Content-Type: multipart/alternative; boundary=001a113faa24375866052276d7b7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 15:31:40 -0000 --001a113faa24375866052276d7b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla wrote: > On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote: > >> Does the sentinel have to be the first N bytes? >> >> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time >> value and 28 random bytes. >> >> Rather than risk breaking backwards compatibility by changing the >> definition of the first 4 bytes, perhaps the sentinel can be moved to >> another location within the ServerRandom field? Either the second set o= f N >> bytes or the last set of N bytes? Where the sentinel is located shouldn= =E2=80=99t >> really matter. Subsequently, the sentinel can be chosen with more freedo= m. >> As I recall, one reason (but not the only reason) the length was extende= d >> to 8 bytes due to the gmt_unix_time issue; is an 8-byte sentinel still >> needed if it=E2=80=99s not overlapping the gmt_unix_time (yes, I=E2=80= =99m concerned about >> a reduction of entropy by 25%)? >> > > Maybe it's because I haven't had my coffee yet, but ISTM that overloading > the time field > lowers the risk of false positives because we can choose a sentinel that > will never > collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in > the > randomly generated portion always has a 2^{-n} chance of collision. > If I'm understanding things correctly, servers which expect to be the target of tools like tlsdate (or aren't sure) will be unable to deploy this mechanism if the sentinel collides with gmt_unix_time. If you're not sure whether you care about tlsdate, you at least risk some compatibility problems with anything that might have been making assumptions here. It seems slightly strange to me to say the reason to do it this way is that we don't risk collision with conformant TLS 1.2 ServerHellos. The reason it's not a collision is because it means servers (supporting TLS 1.3) are now required to produce non-conformant TLS 1.2 ServerHellos. David > > >> In extending this, should the ClientHello random value also include the >> sentinel? (Yes, I know this again reduces entropy.) A MITM can implement= a >> downgrade attack in either direction. The server can terminate the >> connection that much earlier >> > > How does this help? The attacker will just rewrite the ClientHello.random= . > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113faa24375866052276d7b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 19= , 2015 at 11:10 AM Eric Rescorla <ekr@rt= fm.com> wrote:
On Mon, Oct 19, 2= 015 at 7:37 AM, Short, Todd <tshort@akamai.com> wrote:
Does the sentinel have to be the first N bytes?

RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time= value and 28 random bytes.

Rather than risk breaking backwards compatibility by changing the defi= nition of the first 4 bytes, perhaps the sentinel can be moved to another l= ocation within the ServerRandom field? Either the =C2=A0second set of N byt= es or the last set of N bytes? Where the sentinel is located shouldn=E2=80=99t really matter. Subsequentl= y, the sentinel can be chosen with more freedom. As I recall, one reason (b= ut not the only reason) the length was extended to 8 bytes due to the gmt_u= nix_time issue; is an 8-byte sentinel still needed if it=E2=80=99s not overlapping the gmt_unix_time (yes, I=E2=80=99m= concerned about a reduction of entropy by 25%)?

=
Maybe it's because I haven't had my= coffee yet, but ISTM that overloading the time field
lowers the = risk of false positives because we can choose a sentinel that will never
collide with a conformant TLS 1.2 ServerHello. By contrast, a senti= nel in the
randomly generated portion always has a 2^{-n} chance = of collision.

If I&= #39;m understanding things correctly, servers which expect to be the target= of tools like tlsdate (or aren't sure) will be unable to deploy this m= echanism if the sentinel collides with gmt_unix_time. If you're not sur= e whether you care about tlsdate, you at least risk some compatibility prob= lems with anything that might have been making assumptions here.

It = seems slightly strange to me to say the reason to do it this way is that we= don't risk collision with conformant TLS 1.2 ServerHellos. The reason = it's not a collision is because it means servers (supporting TLS 1.3) a= re now required to produce non-conformant TLS 1.2 ServerHellos.
<= br>David
=C2=A0
=C2=A0
=
In extending this, should the ClientHello random value also include th= e sentinel? (Yes, I know this again reduces entropy.) A MITM can implement = a downgrade attack in either direction. The server can terminate the connec= tion that much earlier

<= /div>
How does this help? The attacker will just rewrite the ClientHello.ra= ndom.

-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113faa24375866052276d7b7-- From nobody Mon Oct 19 08:56:21 2015 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 B60941A6F0B; Mon, 19 Oct 2015 08:56:17 -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.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019155617.4544.30343.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 08:56:17 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 19 Oct 2015 15:56:17 -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 Working Group 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-04.txt Pages : 30 Date : 2015-10-19 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) as a new authentication mechanism. 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-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-04 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 Mon Oct 19 08:59:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A922A1A802D for ; Mon, 19 Oct 2015 08:59: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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: 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-fDynviKZ2o for ; Mon, 19 Oct 2015 08:58:58 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 67F381A70E1 for ; Mon, 19 Oct 2015 08:58:58 -0700 (PDT) Received: by wikq8 with SMTP id q8so12469792wik.1 for ; Mon, 19 Oct 2015 08:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=g6oF7QOgUPDhHCHAEyLaAgKFIdKK52B51NbTq27xfBg=; b=ahRFqy2Bi/JlcBUd/Hv6usL9GE6ssw0IgKuYMxVHY1RKx+TIhj8ehk6cBZLkBIZI6/ hAJ6kk9vkeN+lnei86MevYHtFeIuPXNvQdemIRqQyoVES/9wH9MHeBnE/0nEWqgGLTI7 SpLg2QRwJc1SwIGeNPRbzKvsSVsyUEDGqXbX5M0FM8rLomUtlVFESLDuUgGdWI7gll31 FxwGFMOR782rIV9aFCWbmu78o0YvN8V+eriVnwiSkUtG/c9c69s6UpOtKkXIX7Jsr2M6 f5+CMshJbU2fBwpjlga2hB4KEr2hadETb7ovqQB5rh8EOkj8/1sbfiW5IENqc/sGF2VL 5sCg== X-Received: by 10.180.210.234 with SMTP id mx10mr22249692wic.31.1445270336620; Mon, 19 Oct 2015 08:58:56 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([176.13.12.141]) by smtp.gmail.com with ESMTPSA id lv4sm41021361wjb.43.2015.10.19.08.58.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 08:58:55 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_E2C526E8-DEAE-4BD5-AD5E-4D55CC93B61E" Date: Mon, 19 Oct 2015 18:58:52 +0300 References: <20151019155617.4544.29879.idtracker@ietfa.amsl.com> To: IETF TLS Message-Id: <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 15:59:00 -0000 --Apple-Mail=_E2C526E8-DEAE-4BD5-AD5E-4D55CC93B61E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi I=E2=80=99ve submitted version -04 of this draft, incorporating the new = curves Curve25519 and Curve448. I=E2=80=99m sorry to say that I have made the merge far too quickly and = the result is quite sketchy, but I did beat the deadline. So I=E2=80=99m hoping to complete the merge soon. Yoav > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Date: 19 October 2015 at 6:56:17 PM GMT+3 > To: "Yoav Nir" , "Manuel Pegourie-Gonnard" = , "Simon Josefsson" , "Simon = Josefsson" , "Yoav Nir" , = "Manuel Pegourie-Gonnard" > Subject: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt >=20 >=20 > A new version of I-D, draft-ietf-tls-rfc4492bis-04.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. >=20 > Name: draft-ietf-tls-rfc4492bis > Revision: 04 > Title: Elliptic Curve Cryptography (ECC) Cipher Suites = for Transport Layer Security (TLS) Versions 1.2 and Earlier > Document date: 2015-10-19 > Group: tls > Pages: 30 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4492bis-04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-04 >=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) as a new > authentication mechanism. >=20 >=20 >=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 > The IETF Secretariat >=20 --Apple-Mail=_E2C526E8-DEAE-4BD5-AD5E-4D55CC93B61E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

I=E2=80=99= ve submitted version -04 of this draft, incorporating the new curves = Curve25519 and Curve448.

I=E2=80=99m sorry to say that I have made the merge far too = quickly and the result is quite sketchy, but I did beat the = deadline.

So = I=E2=80=99m hoping to complete the merge soon.

Yoav


Begin forwarded message:

From: = internet-drafts@ietf.org
Date: = 19 October 2015 at 6:56:17 PM = GMT+3
To: = "Yoav Nir" <ynir.ietf@gmail.com>, "Manuel Pegourie-Gonnard" <mpg@elzevir.fr>, "Simon = Josefsson" <simon@josefsson.org>, "Simon Josefsson" <simon@josefsson.org>, "Yoav Nir" <ynir.ietf@gmail.com>, "Manuel Pegourie-Gonnard" <mpg@elzevir.fr>
Subject: = New Version = Notification for draft-ietf-tls-rfc4492bis-04.txt

A new version of I-D, draft-ietf-tls-rfc4492bis-04.txt
has been successfully submitted by Yoav Nir and posted to = the
IETF repository.

Name: = draft-ietf-tls-rfc4492bis
Revision: 04
Title:= = Elliptic Curve Cryptography (ECC) Cipher Suites for Transport = Layer Security (TLS) Versions 1.2 and Earlier
Document = date: = 2015-10-19
Group: tls
Pages: 30
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4492bis-= 04.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/=
Htmlized:       https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-04Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-0= 4

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) as a new
=   authentication mechanism.




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


= --Apple-Mail=_E2C526E8-DEAE-4BD5-AD5E-4D55CC93B61E-- From nobody Mon Oct 19 09:04:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23ADE1A874D for ; Mon, 19 Oct 2015 09:04:41 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4p6TjMpCj38 for ; Mon, 19 Oct 2015 09:04:35 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 D99E41A8740 for ; Mon, 19 Oct 2015 09:04:31 -0700 (PDT) Received: by wicll6 with SMTP id ll6so12909505wic.1 for ; Mon, 19 Oct 2015 09:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=NvQMo1GxEiROiL8yQ7MuPVdVAFCO76B9d4AU3DhmvqM=; b=FobSYOL/m+aNbtdoOz5vrDFeXZSx23tQ9UxRUuubiSytejDXadU+xfK4geRB3YkAZc 59h8OJfQqhJvREQIsGKtw4QMV9i4O6T9m+wLfO0gs6KgC+jzPMLAwSSt56kaQKeHdDjR Lg8HRW1ImGxdRL09Udo0eJYtiIgCxA+jtykJRFCpfnk4S/n7ox/CFFAmv++bAMQNxNuR XKysrCetG7gAWiBO2K4HOKtMCGaP4ZHF/a08ql/38Obsz9Wm0s3Q/VlRI8daqXM/X26T c+jh9wLTuXOY2/UEMfoPCUXWJeSeyxx5J8sPTxWTVHxvN2XXnvOUIJ82TVidzGWqdcy5 Xk7Q== X-Received: by 10.194.104.200 with SMTP id gg8mr37206809wjb.144.1445270670432; Mon, 19 Oct 2015 09:04:30 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([176.13.12.141]) by smtp.gmail.com with ESMTPSA id ew2sm15563398wic.20.2015.10.19.09.04.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 09:04:29 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_4C4B86D0-8FBE-4FD1-B2B0-801CDF906006" Message-Id: <3A171165-2CCF-43D2-AB1D-499A53A10536@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Date: Mon, 19 Oct 2015 19:04:27 +0300 References: <20151019155617.4544.29879.idtracker@ietfa.amsl.com> <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com> To: IETF TLS In-Reply-To: <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com> X-Mailer: Apple Mail (2.3094) Archived-At: Subject: Re: [TLS] New Version Notification for draft-ietf-tls-rfc4492bis-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 16:04:41 -0000 --Apple-Mail=_4C4B86D0-8FBE-4FD1-B2B0-801CDF906006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Of course, if anyone wants to help with the merge via pull requests, = that would be great. Yoav > On 19 Oct 2015, at 6:58 PM, Yoav Nir wrote: >=20 > Hi >=20 > I=E2=80=99ve submitted version -04 of this draft, incorporating the = new curves Curve25519 and Curve448. >=20 > I=E2=80=99m sorry to say that I have made the merge far too quickly = and the result is quite sketchy, but I did beat the deadline. >=20 > So I=E2=80=99m hoping to complete the merge soon. >=20 > Yoav >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Date: 19 October 2015 at 6:56:17 PM GMT+3 >> To: "Yoav Nir" >, = "Manuel Pegourie-Gonnard" >, = "Simon Josefsson" >, = "Simon Josefsson" >, = "Yoav Nir" >, "Manuel = Pegourie-Gonnard" > >> Subject: New Version Notification for = draft-ietf-tls-rfc4492bis-04.txt >>=20 >>=20 >> A new version of I-D, draft-ietf-tls-rfc4492bis-04.txt >> has been successfully submitted by Yoav Nir and posted to the >> IETF repository. >>=20 >> Name: draft-ietf-tls-rfc4492bis >> Revision: 04 >> Title: Elliptic Curve Cryptography (ECC) Cipher Suites = for Transport Layer Security (TLS) Versions 1.2 and Earlier >> Document date: 2015-10-19 >> Group: tls >> Pages: 30 >> URL: = https://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4492bis-04.txt = >> Status: = https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ = >> Htmlized: = https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-04 = >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-04 = >>=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) as a new >> authentication mechanism. >>=20 >>=20 >>=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 >> The IETF Secretariat >>=20 >=20 --Apple-Mail=_4C4B86D0-8FBE-4FD1-B2B0-801CDF906006 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Of course, if anyone wants to help with the merge via pull = requests, that would be great.

Yoav

On 19 Oct 2015, at 6:58 PM, = Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi

I=E2=80=99ve submitted = version -04 of this draft, incorporating the new curves Curve25519 and = Curve448.

I=E2=80= =99m sorry to say that I have made the merge far too quickly and the = result is quite sketchy, but I did beat the deadline.

So I=E2=80=99m hoping to = complete the merge soon.

Yoav


Begin = forwarded message:

From: internet-drafts@ietf.org
Date: 19= October 2015 at 6:56:17 PM GMT+3
To: "Yoav Nir" <ynir.ietf@gmail.com>, "Manuel Pegourie-Gonnard" <mpg@elzevir.fr>, "Simon = Josefsson" <simon@josefsson.org>, "Simon Josefsson" <simon@josefsson.org>, "Yoav Nir" <ynir.ietf@gmail.com>, "Manuel Pegourie-Gonnard" <mpg@elzevir.fr>
Subject: New Version Notification for = draft-ietf-tls-rfc4492bis-04.txt


A new version = of I-D, draft-ietf-tls-rfc4492bis-04.txt
has been = successfully submitted by Yoav Nir and posted to the
IETF = repository.

Name: = draft-ietf-tls-rfc4492bis
Revision: 04
Title:= = Elliptic Curve Cryptography (ECC) Cipher Suites for Transport = Layer Security (TLS) Versions 1.2 and Earlier
Document = date: = 2015-10-19
Group: tls
Pages: 30
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4492bis-= 04.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/=
Htmlized:       https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-04Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-0= 4

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) as a new
=   authentication mechanism.




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



= --Apple-Mail=_4C4B86D0-8FBE-4FD1-B2B0-801CDF906006-- From nobody Mon Oct 19 09:09:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD87E1A8768 for ; Mon, 19 Oct 2015 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sutdbbu7dq1O for ; Mon, 19 Oct 2015 09:09:35 -0700 (PDT) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) (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 209E91A877C for ; Mon, 19 Oct 2015 09:09:35 -0700 (PDT) Received: by ykfy204 with SMTP id y204so147327511ykf.1 for ; Mon, 19 Oct 2015 09:09:34 -0700 (PDT) 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-type; bh=YqhS4FrU2dfvIvAWVEKoSyUu++j5n9lHjY8A7QVHxRY=; b=mmcnlKZwRzirtvsW6Ms/h/cAzkex/uZCu6XsBvlvJT2iBWb+cw4KqNJLAb3CK9GGH2 18pMWjT1BJOWl+G3UH46wSqK5vIqspaHRENeWv59YAkw6ZtSL1UXOL5maXjkObQFS3vC dzDdkFDRyUffKkfLMntuI79IzvXa7xo5ssS7/SMmH76i4M7/EATmybdtIhXUbJNOmSFy Q1Mb3cm4bWfhzLLof32jmYVGwZKJFpVxjViTD6itIgpDK5G2IoviJveByrKmK47JdPli gtHwxPs0jhGiaMRM6cLA1W6vfNY0iBmkBjbhj2cdqce/iZK7qNRZueyJ+9GL7jLnuXNf bfGg== X-Gm-Message-State: ALoCoQmRObyY+m89rHn9FLyURYjy3hSkaZUz/Z1r2l6P+dd+OeFPFwlqgCWw18WoOjS26yGf+j9i X-Received: by 10.129.89.138 with SMTP id n132mr3567119ywb.61.1445270974349; Mon, 19 Oct 2015 09:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Mon, 19 Oct 2015 09:08:55 -0700 (PDT) From: Eric Rescorla Date: Mon, 19 Oct 2015 09:08:55 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1149198807f56a0522775f78 Archived-At: Subject: [TLS] Directly signing randoms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 16:09:42 -0000 --001a1149198807f56a0522775f78 Content-Type: text/plain; charset=UTF-8 Folks, https://github.com/tlswg/tls13-spec/issues/224 At the interim we discussed whether it was worth having digital signatures explicitly include the client and server random values rather than just the transcript to enable privilege separation, as proposed by Nikos. We had a little trouble getting clarity on the desired use case, but the two we understood were: 1. Having a separate module which is signing for authentication and wants to explicitly provide a random value to ensure that it's not signing arbitrary data. 2. Having a separate module which is verifying the peer's authentication and wants to explicitly provide a challenge to be signed by the peer. The general feeling was that you could achieve both cases by simply the unprivileged portion of the system provide the module with the handshake transcript and allow it to verify that the random was present in the correct location (or at all in case #2) and so that no change was needed. As I said, there was some confusion on the exact scenario, so if I've misunderstood please clarify. Otherwise, I think we have consensus to close this as WONTFIX. -Ekr --001a1149198807f56a0522775f78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,


At the interim we discussed whether = it was worth having digital
signatures explicitly include the cli= ent and server random values
rather than just the transcript to e= nable privilege separation, as
proposed by Nikos. We had a little= trouble getting clarity on the
desired use case, but the two we = understood were:

1. Having a separate module which= is signing for authentication
=C2=A0 =C2=A0and wants to explicit= ly provide a random value to ensure
=C2=A0 =C2=A0that it's no= t signing arbitrary data.

2. Having a separate mod= ule which is verifying the peer's authentication
=C2=A0 =C2= =A0and wants to explicitly provide a challenge to be signed by the
=C2=A0 =C2=A0peer.

The general feeling was that = you could achieve both cases by simply
the unprivileged portion o= f the system provide the module with the
handshake transcript and= allow it to verify that the random
was present in the correct lo= cation (or at all in case #2) and so
that no change was needed.

As I said, there was some confusion on the exact sc= enario, so if
I've misunderstood please clarify. Otherwise, I= think we have
consensus to close this as WONTFIX.

=
-Ekr

--001a1149198807f56a0522775f78-- From nobody Mon Oct 19 09:29:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6601A89AA for ; Mon, 19 Oct 2015 09:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFfFOZDMTTBQ for ; Mon, 19 Oct 2015 09:28:52 -0700 (PDT) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) (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 CEB541A89A8 for ; Mon, 19 Oct 2015 09:28:48 -0700 (PDT) Received: by ykdz2 with SMTP id z2so62859453ykd.3 for ; Mon, 19 Oct 2015 09:28:48 -0700 (PDT) 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-type; bh=iRgOVKNu7WlApamNRbAPSNknQFTSmCzHH7ZVx8/paW0=; b=iaOm3RSnO3nOuespdZnPaLOLrodWI7UtmKXuwmvah25Z6ab4LIw1tk6RM9jM33PX2n 1AVUFoJSzHE5QfY5H6CHCgfVvox/3b3bu1ocW17a6EbA/ZU4Oq8+M82gArgLh8ZVPWwy 6ZH9Honxfhx3E4rnM8JB2mGRVDYyOJpE/GKizwPbmDN+gLzBb8NX6pHfAZYg0+0QseY7 TrJViQLGBnbRBVpGRwm6pX+hUT/XCQfEY/7D6jZLHk36LJUO/eo5Ug99n9/ZfHZjV5kT F4QuIH7ElYZW/YGe/RfFODocjU6oZZS1NFKJIPbqumGtz1yV56o+StdYjmkvKckssDs4 zCaw== X-Gm-Message-State: ALoCoQmGUUSody5TuVaOG/gWm3AnR+9vcQ+1PvfeQ1yk1Arv817PXm9i7qC1yvuKvynYUQAdOyz1 X-Received: by 10.129.70.197 with SMTP id t188mr20717299ywa.292.1445272128146; Mon, 19 Oct 2015 09:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Mon, 19 Oct 2015 09:28:08 -0700 (PDT) From: Eric Rescorla Date: Mon, 19 Oct 2015 09:28:08 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114d70eecd7e76052277a337 Archived-At: Subject: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 16:28:56 -0000 --001a114d70eecd7e76052277a337 Content-Type: text/plain; charset=UTF-8 Folks, https://github.com/tlswg/tls13-spec/issues/278 The additional data field presently includes the version: additional_data = seq_num + TLSPlaintext.record_version However, TLSPlaintext.record_version is now always {3, 1}, so this is redundant. There seem to be two primary options here: 1. Don't MAC the version at all. 2. MAC the negotiated version (which should be clear at this point). I could go either way on this (slightly leaning towards #2) but the current thing seems silly. -Ekr --001a114d70eecd7e76052277a337 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,


The additional data field presently = includes the version:

=C2=A0 =C2=A0 =C2=A0 additio= nal_data =3D seq_num + TLSPlaintext.record_version

However, TLSPlaintext.record_version is now always {3, 1}, so
th= is is redundant. There seem to be two primary options here:

<= /div>
=C2=A0 =C2=A0 =C2=A01. Don't MAC the version at all.
=C2=A0 =C2=A0 =C2=A02. MAC the negotiated version (which should be clear = at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this point).

<= div>I could go either way on this (slightly leaning towards #2) but
the current thing seems silly.

-Ekr
<= br>
--001a114d70eecd7e76052277a337-- From nobody Mon Oct 19 09:40:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925721A8A28 for ; Mon, 19 Oct 2015 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 JuqLQmj771pY for ; Mon, 19 Oct 2015 09:39:59 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (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 1E0641A8A55 for ; Mon, 19 Oct 2015 09:39:56 -0700 (PDT) Received: by oiao187 with SMTP id o187so44634708oia.3 for ; Mon, 19 Oct 2015 09:39:55 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=h8M6iVLOBU2SPpVYubs4T0HX1upJBC29I7YamkjIr1E=; b=AbvYI3MoZjvLYrm0wcLchmaQGfVgVAKgMR+hufEGM4DkaICHJ6M8Wj1511lrRhUUs9 lHomM49OXqLqqfpWpEZsMQK4nnzBBhArAq7AHO70NP6lGhG9kFreLjsRx61pVZN5C04r SNvc+ej4kJ4ZNGvf9ZMy5+uOOaQ21UpbXYHbQks/c2SIAVs2MGQIBHOb8LgdGoo+2pBD pKmyUxsTs59AFTeUDqpYgMt4r5MRUB5XoUxDaZ0tQW8Xa8CP5vtfZnKmqpg0r/kxSyg6 +NjEVSCabYyWqjuagqqqS+tlRqbEBh/vHIN16IM/QzeK/QwNsfj4O8lwl8BWaKtPvlEz XAPg== X-Gm-Message-State: ALoCoQkrIJEFzV8DJLjq6cPrETqH7/8XizDFzhopd6/fm8H58mQ5iFKzjQi1x532Q1uNSEup28CI MIME-Version: 1.0 X-Received: by 10.202.81.76 with SMTP id f73mr14450256oib.40.1445272795566; Mon, 19 Oct 2015 09:39:55 -0700 (PDT) Received: by 10.76.130.242 with HTTP; Mon, 19 Oct 2015 09:39:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 09:39:55 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113d7858956e52052277cb46 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 16:40:00 -0000 --001a113d7858956e52052277cb46 Content-Type: text/plain; charset=UTF-8 If (2.) is used, would it be nice to make it negotiated_version + seq_num? I think for some algorithms, the MAC can be partially pre-computed if things are in that order. On Mon, Oct 19, 2015 at 9:28 AM, Eric Rescorla wrote: > Folks, > > https://github.com/tlswg/tls13-spec/issues/278 > > The additional data field presently includes the version: > > additional_data = seq_num + TLSPlaintext.record_version > > However, TLSPlaintext.record_version is now always {3, 1}, so > this is redundant. There seem to be two primary options here: > > 1. Don't MAC the version at all. > 2. MAC the negotiated version (which should be clear at > this point). > > I could go either way on this (slightly leaning towards #2) but > the current thing seems silly. > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Colm --001a113d7858956e52052277cb46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If (2.) is used, would it be nice to make it =C2= =A0negotiated_version +=C2=A0seq_num? I think for some algorithms, the MAC = can be partially pre-computed if things are in that order.=C2=A0

On Mon, Oct 19, = 2015 at 9:28 AM, Eric Rescorla <ekr@rtfm.com> wrote:

<= div>The additional data field presently includes the version:
=C2=A0 =C2=A0 =C2=A0 additional_data =3D seq_num + TLSPlaintext= .record_version

However, TLSPlaintext.record_versi= on is now always {3, 1}, so
this is redundant. There seem to be t= wo primary options here:

=C2=A0 =C2=A0 =C2=A01. Do= n't MAC the version at all.
=C2=A0 =C2=A0 =C2=A02. MAC the ne= gotiated version (which should be clear at
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 this point).

I could go either way on this = (slightly leaning towards #2) but
the current thing seems silly.<= /div>

-Ekr


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




--
Colm
--001a113d7858956e52052277cb46-- From nobody Mon Oct 19 09:49:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49AE1A8A64 for ; Mon, 19 Oct 2015 09:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 TPiZ5ouwJ7m3 for ; Mon, 19 Oct 2015 09:49:13 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 2CF1C1A8A47 for ; Mon, 19 Oct 2015 09:49:13 -0700 (PDT) Received: by iofz202 with SMTP id z202so56788946iof.2 for ; Mon, 19 Oct 2015 09:49:11 -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:content-type; bh=V4Rks//eSfTsAvantYFv3UiHVTGiWCnXnbZ0ovtPxpI=; b=eAspoDJ4VN8EX8LUGLwZAd3ALXMUrIfs3h3vPTA0ZPI0fEB3PzQVRTz7CH8vdAo/w4 d4+co87bXaL1L1AwxLLOB7uC8VgHEIy39QqdAUNTLtZQoMgykbiSuehs4+DnblYM1vPg aciXWhSDv7g20yxMInmgwHfRyoRHyWHUI71NA= 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:content-type; bh=V4Rks//eSfTsAvantYFv3UiHVTGiWCnXnbZ0ovtPxpI=; b=kWMX8fyFo1Tp9qxraD1YR2lXSL74w8W0Ut9duRPc+GmcfMY27UqtmSkx/jNSkCt2/Q xLn+HKxNPzQ2N8h43rPcO+t0Wkaq4GTvZUe0WKl3jPUIXMspFIMYPQ4Ogo2PRif6k5N4 M0VsUsKUeP5TerTJPb9eDIPWlyD1RbhGaSy5KepBxdwAO0habnX5GSntCbZHp4hGMLXS 25z84O/VCtTWwu9mktwSjg34NZCo91Uw+jaInxpurxeUPsgVAUFyMBWFWXgEUsJ+k+rq 5r0DyAq1fczZXtnB55xeyF5FovVb6NuFKHKUHox3Q3Fr6wQifHzISSTZor5RtuhahJXS pW0w== X-Gm-Message-State: ALoCoQltQL+1fT48qbEXkwTvzdcsZiQZsVYbit0eqEOoCBjsV/J3mtYMzIWkJ4Dig+jwcBQJUf+t X-Received: by 10.107.30.8 with SMTP id e8mr2856487ioe.166.1445273351181; Mon, 19 Oct 2015 09:49:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Mon, 19 Oct 2015 16:49:01 +0000 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140ea4ab3c87d052277ec7b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 16:49:14 -0000 --001a1140ea4ab3c87d052277ec7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What purpose does putting the version in the AD serve? It's not harmful, sure, but just using the sequence number is simplest. It seems the only reason we'd consider putting it into the AD is because historically the record version was in there as part of the record header. In a vacuum, I'm having a hard time imagining why one would want negotiated_version in there that wouldn't also apply to putting the whole handshake hash in there. Am I missing something? David On Mon, Oct 19, 2015 at 12:40 PM Colm MacC=C3=A1rthaigh wrote: > > If (2.) is used, would it be nice to make it negotiated_version > + seq_num? I think for some algorithms, the MAC can be partially > pre-computed if things are in that order. > > On Mon, Oct 19, 2015 at 9:28 AM, Eric Rescorla wrote: > >> Folks, >> >> https://github.com/tlswg/tls13-spec/issues/278 >> >> The additional data field presently includes the version: >> >> additional_data =3D seq_num + TLSPlaintext.record_version >> >> However, TLSPlaintext.record_version is now always {3, 1}, so >> this is redundant. There seem to be two primary options here: >> >> 1. Don't MAC the version at all. >> 2. MAC the negotiated version (which should be clear at >> this point). >> >> I could go either way on this (slightly leaning towards #2) but >> the current thing seems silly. >> >> -Ekr >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > > -- > Colm > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1140ea4ab3c87d052277ec7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What purpose does putting the version in the AD serve? It&= #39;s not harmful, sure, but just using the sequence number is simplest. It= seems the only reason we'd consider putting it into the AD is because = historically the record version was in there as part of the record header. = In a vacuum, I'm having a hard time imagining why one would want negoti= ated_version in there that wouldn't also apply to putting the whole han= dshake hash in there. Am I missing something?

David

On Mon, Oct 19, 2015 at 12:40 PM Colm Ma= cC=C3=A1rthaigh <= colm@allcosts.net> wrote:

If (2.) is used, would it be nice to make it =C2=A0= negotiated_version +=C2=A0seq_num? I think for some algorithms, the MAC can= be partially pre-computed if things are in that order.=C2=A0

On Mon, Oct 19, 2015 at 9:28 AM, Eric Rescorla <ekr@rtfm.com&= gt; wrote:
F= olks,


The additional data field presently inclu= des the version:

=C2=A0 =C2=A0 =C2=A0 additional_d= ata =3D seq_num + TLSPlaintext.record_version

Howe= ver, TLSPlaintext.record_version is now always {3, 1}, so
this is= redundant. There seem to be two primary options here:

=
=C2=A0 =C2=A0 =C2=A01. Don't MAC the version at all.
=C2= =A0 =C2=A0 =C2=A02. MAC the negotiated version (which should be clear at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this point).

I= could go either way on this (slightly leaning towards #2) but
th= e current thing seems silly.

-Ekr


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




--
Colm
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1140ea4ab3c87d052277ec7b-- From nobody Mon Oct 19 09:52:17 2015 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 77E3A1A8A75; Mon, 19 Oct 2015 09:52:15 -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.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019165215.31192.89699.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 09:52:15 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 19 Oct 2015 16:52:15 -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 Working Group of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-10.txt Pages : 103 Date : 2015-10-19 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol 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-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-10 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 Mon Oct 19 10:05:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A1A1A8AE2 for ; Mon, 19 Oct 2015 10:05:05 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3qmvsZfF_e5 for ; Mon, 19 Oct 2015 10:05:03 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002: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 894681A8AC6 for ; Mon, 19 Oct 2015 10:05:03 -0700 (PDT) Received: by ykfy204 with SMTP id y204so149017621ykf.1 for ; Mon, 19 Oct 2015 10:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q0NflVhhoedXbedqhVA+idHF6ms6M10JchwDhdnVdHw=; b=01R52tOkP7WTycB0ktGLsYOncNJs7cBkHYhsX6JU+VzobHEkrM1kxBmIQ5k7kKlQbT nqb22svB28KW9f0y5S/poB550G8umr5Kn1OBdnk9d6asYHVFfQZwIbMMA1fWvzy/x7YJ fe0jykXEhoDkGKmYN+aNK2zT60I489b8mHkHVoCQ0ZeGiqZJcvYaEEgi6BanRMAXQKbk y4NF8MMeInj5jk1yov59vcNF03gCtcA3SilWV/YtspjrhIXPp0kxEDIgm5hHQ8iXYM0G 40DTFkTNXgono8Ilr6jomTHKww5J+cQ+hVz8PflGlJrkMgeerRXRw3xYjHhIWtrbIdPE KFfQ== MIME-Version: 1.0 X-Received: by 10.129.79.129 with SMTP id d123mr20676015ywb.159.1445274302840; Mon, 19 Oct 2015 10:05:02 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Mon, 19 Oct 2015 10:05:02 -0700 (PDT) In-Reply-To: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> Date: Mon, 19 Oct 2015 10:05:02 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 17:05:05 -0000 On 19 October 2015 at 08:08, Eric Rescorla wrote: > overloading the time field > lowers the risk of false positives because we can choose a sentinel that > will never > collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in > the > randomly generated portion always has a 2^{-n} chance of collision. Yes, this is right. The marginal gain is that the proportion of servers that generate a time here are immune to collisions. If servers all servers did that, we wouldn't have to worry about collisions at all. Unfortunately, we do know that some generate random values. From nobody Mon Oct 19 10:14:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9E11ACE6D for ; Mon, 19 Oct 2015 10:14:46 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9gPYGmXJuwm for ; Mon, 19 Oct 2015 10:14:45 -0700 (PDT) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id C79C01ACE62 for ; Mon, 19 Oct 2015 10:14:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id B206519C67D; Mon, 19 Oct 2015 20:14:43 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id TVDv00AipxNQ; Mon, 19 Oct 2015 20:14:43 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 8CD845BC004; Mon, 19 Oct 2015 20:14:43 +0300 (EEST) Date: Mon, 19 Oct 2015 20:14:42 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20151019171442.GB31869@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151019155617.4544.29879.idtracker@ietfa.amsl.com> <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: IETF TLS Subject: Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 17:14:46 -0000 On Mon, Oct 19, 2015 at 06:58:52PM +0300, Yoav Nir wrote: > Hi > > I’ve submitted version -04 of this draft, incorporating the new curves Curve25519 and Curve448. > > I’m sorry to say that I have made the merge far too quickly and the result is quite sketchy, but I did beat the deadline. > > So I’m hoping to complete the merge soon. Some comments: - The document seems to lack obsoletes RFC4492 (or even updates RFC4492). Isn't this supposed to supercede that document? - Curve25519 and Curve448 are called "X25519" and "X448" in the (looks to be imminently sent to RFC editor) draft. - In public key validation, X448 resists invalid point attacks the same way as X25519 (of course, all bits of X448 public keys can be nonzero, as the value can get to almost 256^56). - The document still does have restrictions on algorithms used to sign the certificate. AFAIK, TLS 1.2 (RFC5246) lifted all such restrictions (at least sections 2.2, 5.3 and 5.6). - Do we want to keep ECDH client keys? Those were used in one recent exploit against one implementation of TLS. And using one destroys forward secrecy anyway. - Is this document meant to also include the CFRG signatures work? The interfaces to functions are already known. -Ilari From nobody Mon Oct 19 10:54:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201121B2A5C for ; Mon, 19 Oct 2015 10:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ2O788_Engw for ; Mon, 19 Oct 2015 10:54:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9F11A9069 for ; Mon, 19 Oct 2015 10:54:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 27F93180473; Mon, 19 Oct 2015 10:53:43 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.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: <20151019175343.27F93180473@rfc-editor.org> Date: Mon, 19 Oct 2015 10:53:43 -0700 (PDT) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC5246 (4507) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 17:54:14 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4507 -------------------------------------- Type: Editorial Reported by: Benjamin Kaduk Section: 7.4.1.2 Original Text ------------- After sending the ClientHello message, the client waits for a ServerHello message. Any handshake message returned by the server, except for a HelloRequest, is treated as a fatal error. Corrected Text -------------- After sending the ClientHello message, the client waits for a ServerHello message. Any other handshake message returned by the server, except for a HelloRequest, is treated as a fatal error. Notes ----- A ServerHello received after a ClientHello should not be treated as a fatal error. 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. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Oct 19 11:06:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8ED81B2AA5 for ; Mon, 19 Oct 2015 11:06:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UmEX8mROcUx for ; Mon, 19 Oct 2015 11:06:35 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002: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 5DF5A1B2A96 for ; Mon, 19 Oct 2015 11:06:35 -0700 (PDT) Received: by ykaz22 with SMTP id z22so148292517yka.2 for ; Mon, 19 Oct 2015 11:06: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:date:message-id:subject:from:to :cc:content-type; bh=UF03n5MNzfT3W+Ob1QNeE69jwX8ZaGMGscaZzdW/h4c=; b=jEEPGctxS3RIVRNw3tSFlbdSeVflVDWNdCwqKGSzFPJeAif3vqxG7upN5vz+pG+jld zL8YKCgXI+1q5vmWdjV/U71ud1Pn+q53UkmdmPmPKu+Ny6HAhBnRiC/KCZH7clSFypt9 9SUhKByQUQZrfxJ0/oqxLc7J/dAr3CiEMCvH2Wfiaqd1fT8QTWar9T7pDJ8yT+A3UkrY v0LQ0UgIaXQ8cdZni35pfv20hXYfieXaZxpmgrOMeAjU/eJyhWCINGoat3odARjgha7N /ZBa2aaY7yqT+ALlXYrbUNFb4thyW0Vhk5A+1YJIeTfl27kgvb744EdOClYcebz1oVmT yBCA== MIME-Version: 1.0 X-Received: by 10.13.196.196 with SMTP id g187mr23274458ywd.98.1445277994709; Mon, 19 Oct 2015 11:06:34 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Mon, 19 Oct 2015 11:06:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 11:06:34 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 18:06:36 -0000 On 19 October 2015 at 09:28, Eric Rescorla wrote: > 1. Don't MAC the version at all. > 2. MAC the negotiated version (which should be clear at > this point). 3. Nothing The version is implicit in the key derivation (yeah, there are lots of rounds of HMAC between, but it's there. The sequence number is fed into the nonce. From nobody Mon Oct 19 11:13:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D991B2AD8 for ; Mon, 19 Oct 2015 11:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGkJOXcy4V-0 for ; Mon, 19 Oct 2015 11:12:56 -0700 (PDT) Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.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 C9A0D1B2AE2 for ; Mon, 19 Oct 2015 11:12:52 -0700 (PDT) Received: by yknn9 with SMTP id n9so99833236ykn.0 for ; Mon, 19 Oct 2015 11:12:52 -0700 (PDT) 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-type; bh=S1HgAQ6IfkWJt8DstqUPUNeH7m8TA68pLWPyi1YaqxA=; b=RUf3/btXyhRiL1jIyxePa5AlmetXbwlawyaTcMyh/y0tSWmIlppc6i5IfcTipHkdrS BY8+iRYYlDz9PCh3EdkjL6G8uG6nI3QmAZfA3vCg3sFRZjlOAxny1WnMtwGHwsidmc0U 0jjQVA9KPhubH78RIuuJ+iOgsRJ6kf8mU9uRNhAPSF6Z4l9eJGW8RL9XPJcpZZi2as4q EeG4rnH5WdPjzNwvO1XcMaYmoInExqKWgbznlB+ZbCg4OL1clUND9rhsekZwn5H5O7mM Zt6VB+mYAjdPBmL15UMLnv0n03O2wfWNU+ZYoO3aoR0BfrKQxUyAx9sSPQVNEpAQ5nJX G3Ag== X-Gm-Message-State: ALoCoQmcaxhBE7vuPCHP9oNYN1nDOo0mx13Wl6X642X7c9GScpI5y6QZbdDC71buFfD0Svz0AkMR X-Received: by 10.13.229.68 with SMTP id o65mr20325776ywe.62.1445278372092; Mon, 19 Oct 2015 11:12:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Mon, 19 Oct 2015 11:12:12 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 19 Oct 2015 11:12:12 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0809ecf891e60522791779 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 18:13:00 -0000 --94eb2c0809ecf891e60522791779 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson wrote: > On 19 October 2015 at 09:28, Eric Rescorla wrote: > > 1. Don't MAC the version at all. > > 2. MAC the negotiated version (which should be clear at > > this point). > > > 3. Nothing > > The version is implicit in the key derivation (yeah, there are lots of > rounds of HMAC between, but it's there. > > The sequence number is fed into the nonce. > How is this different from #1? -Ekr --94eb2c0809ecf891e60522791779 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
On 19 October 2015 at 09:28, Eric Rescorla <ekr@rtfm.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 1. Don't MAC the version at all.
>=C2=A0 =C2=A0 =C2=A0 2. MAC the negotiated version (which should be cle= ar at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this point).


3. Nothing

The version is implicit in the key derivation (yeah, there are lots of
rounds of HMAC between, but it's there.

The sequence number is fed into the nonce.

How is this differe= nt from #1?

-Ekr

--94eb2c0809ecf891e60522791779-- From nobody Mon Oct 19 11:14:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809201B2AE7 for ; Mon, 19 Oct 2015 11:14: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZY00c4cTp4P for ; Mon, 19 Oct 2015 11:13:59 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002: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 6C1341B2A90 for ; Mon, 19 Oct 2015 11:13:59 -0700 (PDT) Received: by ykaz22 with SMTP id z22so148509440yka.2 for ; Mon, 19 Oct 2015 11:13: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:date:message-id:subject:from:to :cc:content-type; bh=3YnqHOQHM47XXZ3WN0VIvpYv+CJgO5w1uBL8FWim27A=; b=AahNJjA0/IrbShA7aklGNmUJKx7teohLnXsnQJkHejlezc1Rp1MUXcyFt2j3HBR7V3 +tL1bIVTvRa24LFLYKv6K+SvO4cc/dl3bQrJ8mxragEFi9y4/+4yfYuLvWhfedjVtDM0 XxyJ+fJFOhhcOg4vEHB8a2NW0y+nqpZVSndjAUo3FN8R33Xkb0wsj1bH4+ZNfpaQ0b7X h53EN7dG/BdlSDZOKW3/67ui62TOHpRsE/aQpx/vMLiSXMKgr7ibJQEoH/VlW376VgOu AN3KQ0xZV975DQ7RoGVtau910t9hMEbRuGPYYc0hNZqOB+4x39thw7q/hsVSXf+xgDrZ iaSw== MIME-Version: 1.0 X-Received: by 10.13.204.207 with SMTP id o198mr23358520ywd.183.1445278438709; Mon, 19 Oct 2015 11:13:58 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Mon, 19 Oct 2015 11:13:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 11:13:58 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 18:14:00 -0000 On 19 October 2015 at 11:12, Eric Rescorla wrote: > > > On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson > wrote: >> >> On 19 October 2015 at 09:28, Eric Rescorla wrote: >> > 1. Don't MAC the version at all. >> > 2. MAC the negotiated version (which should be clear at >> > this point). >> >> >> 3. Nothing >> >> The version is implicit in the key derivation (yeah, there are lots of >> rounds of HMAC between, but it's there. >> >> The sequence number is fed into the nonce. > > > How is this different from #1? #1 implies the sequence number is covered by the MAC. From nobody Mon Oct 19 11:18:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C601B2AA9 for ; Mon, 19 Oct 2015 11:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep50ejBUpZUQ for ; Mon, 19 Oct 2015 11:18:22 -0700 (PDT) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) (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 D032A1B2B36 for ; Mon, 19 Oct 2015 11:18:20 -0700 (PDT) Received: by ykdz2 with SMTP id z2so66086301ykd.3 for ; Mon, 19 Oct 2015 11:18:20 -0700 (PDT) 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-type; bh=uPg/Nsnxc1Q/mEhFmhiGjdKFs7G1Oo1cMd1fkIFZ1Gc=; b=gkj+KbTj5jWKJSx9WpzRkrIHusenofHN8a6K8mixSVrO9k1KQSwQWXoe5vjACnCj37 dPrbfvW7s0E8nwX9T0Wo0M3XpfW23zdcRAJEQD4N5vBN33MB99Xwb+6gBN2oxCIDKySL wJzy0HH2jpFXMLrz88DuuJedl13sTBi9fDu0I/iRQd7yWcHfZkvfiy4Pcmg3nHS65fb/ wuuypA9lQ4O1AXb7dA6qUcpxuBvi30VGhvbg7F/ht+5/oFxlEdZElubl5phI3YARRFOl SW78fVvganuL2zE/qDcnpkf4TKatZVXfC7Q+dVI7skJkNgtHLxzRd0wfoVc+76FzUIby JASA== X-Gm-Message-State: ALoCoQnIjh3x10efPGiOx8U3kCRAKogV0h2xdxoUVgqooi8nH7io2rVgjGsghUDRtp5mn3Er50TU X-Received: by 10.129.154.67 with SMTP id r64mr5177108ywg.166.1445278700140; Mon, 19 Oct 2015 11:18:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.114.85 with HTTP; Mon, 19 Oct 2015 11:17:40 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 19 Oct 2015 11:17:40 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0b84cc862efd0522792b5a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 18:18:28 -0000 --94eb2c0b84cc862efd0522792b5a Content-Type: text/plain; charset=UTF-8 On Mon, Oct 19, 2015 at 11:13 AM, Martin Thomson wrote: > On 19 October 2015 at 11:12, Eric Rescorla wrote: > > > > > > On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> > >> On 19 October 2015 at 09:28, Eric Rescorla wrote: > >> > 1. Don't MAC the version at all. > >> > 2. MAC the negotiated version (which should be clear at > >> > this point). > >> > >> > >> 3. Nothing > >> > >> The version is implicit in the key derivation (yeah, there are lots of > >> rounds of HMAC between, but it's there. > >> > >> The sequence number is fed into the nonce. > > > > > > How is this different from #1? > > #1 implies the sequence number is covered by the MAC. > Yeah, I think that's riding the nonce far too hard. -Ekr --94eb2c0b84cc862efd0522792b5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 19, 2015 at 11:13 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
On 19 October 2015 at 11:12, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 19 October 2015 at 09:28, Eric Rescorla <ekr@rtfm.com> wrote:
>> >=C2=A0 =C2=A0 =C2=A0 1. Don't MAC the version at all.
>> >=C2=A0 =C2=A0 =C2=A0 2. MAC the negotiated version (which shou= ld be clear at
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this point).
>>
>>
>> 3. Nothing
>>
>> The version is implicit in the key derivation (yeah, there are lot= s of
>> rounds of HMAC between, but it's there.
>>
>> The sequence number is fed into the nonce.
>
>
> How is this different from #1?

#1 implies the sequence number is covered by the MAC.

Yeah, I think that&= #39;s riding the nonce far too hard.

-Ekr

--94eb2c0b84cc862efd0522792b5a-- From nobody Mon Oct 19 11:21:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEE71B2B5C for ; Mon, 19 Oct 2015 11:21:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSSi0lZjNjJu for ; Mon, 19 Oct 2015 11:21:34 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 A5EFA1B2B2B for ; Mon, 19 Oct 2015 11:21:34 -0700 (PDT) Received: by ykaz22 with SMTP id z22so148727733yka.2 for ; Mon, 19 Oct 2015 11:21: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:date:message-id:subject:from:to :cc:content-type; bh=nNy4g3s00wX/OzdESvhXgzKn6GQkZ0fRH9XROyv3gls=; b=u0Y9g1lfz3SQJVUMBMXsP3hSh3hESRLWS1PF3Ff8KqWK1IMgdHz4uvPzcgC/NfKnCg IMsu4O5/BlatOGeW+0ZresiVBuV6Gy5PqsJW+cbe9zDy+8FCEG1IcAUyTOImP7ftB4l6 /2iljk+cCE5qZpnUbg0f0vlorzUgcCwNtJsIPdrY1MMUdUs7OAbObxQtwFUyAL/kEktL 3MXzucsW5uP2K+wcAAuJb8d+c4wiRRiEj1s4deb6HGRfqmonmlTxoCU17y84aKdHJX8E tye2VUayOS61F8DorKmgbpzrTXX0CKAIAJJnwtcihfJRs4CmhanpxpBttgZyAdswjMmX qMMg== MIME-Version: 1.0 X-Received: by 10.13.213.141 with SMTP id x135mr7864096ywd.43.1445278893910; Mon, 19 Oct 2015 11:21:33 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Mon, 19 Oct 2015 11:21:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 11:21:33 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 18:21:36 -0000 On 19 October 2015 at 11:17, Eric Rescorla wrote: > Yeah, I think that's riding the nonce far too hard. On what basis? Any change in the nonce will cause the record decryption to fail. That's the property we're looking for here, isn't it? From nobody Mon Oct 19 12:44:27 2015 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 A39B21B2CA8; Mon, 19 Oct 2015 12:44:06 -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.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019194406.18832.30518.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 12:44:06 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-20.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 19 Oct 2015 19:44:06 -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 Working Group of the IETF. Title : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-20.txt Pages : 17 Date : 2015-10-19 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-cached-info-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 15:25:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992F51B2BA2 for ; Mon, 19 Oct 2015 15:25:32 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o3Ii009XVbO for ; Mon, 19 Oct 2015 15:25:30 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id A61721A8F4E for ; Mon, 19 Oct 2015 15:25:30 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id DC2C29A4029; Mon, 19 Oct 2015 18:25:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id i1s2djOwwjx6; Mon, 19 Oct 2015 18:23:58 -0400 (EDT) Received: from [10.0.4.224] (unknown [89.101.241.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A60289A400D; Mon, 19 Oct 2015 18:24:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-107-982318612 From: Russ Housley In-Reply-To: Date: Mon, 19 Oct 2015 18:24:30 -0400 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 22:25:32 -0000 --Apple-Mail-107-982318612 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Option #2 seems fine to me. Russ On Oct 19, 2015, at 12:28 PM, Eric Rescorla wrote: > Folks, > > https://github.com/tlswg/tls13-spec/issues/278 > > The additional data field presently includes the version: > > additional_data = seq_num + TLSPlaintext.record_version > > However, TLSPlaintext.record_version is now always {3, 1}, so > this is redundant. There seem to be two primary options here: > > 1. Don't MAC the version at all. > 2. MAC the negotiated version (which should be clear at > this point). > > I could go either way on this (slightly leaning towards #2) but > the current thing seems silly. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-107-982318612 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Folks,


The additional = data field presently includes the = version:

      additional_data =3D= seq_num + TLSPlaintext.record_version

However, = TLSPlaintext.record_version is now always {3, 1}, so
this is = redundant. There seem to be two primary options = here:

     1. Don't MAC the = version at all.
     2. MAC the negotiated = version (which should be clear at
        = this point).

I could go either way on this = (slightly leaning towards #2) but
the current thing seems = silly.

-Ekr

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

= --Apple-Mail-107-982318612-- From nobody Mon Oct 19 16:01:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0D11B2E52 for ; Mon, 19 Oct 2015 16:01:55 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkAztANq4Nnq for ; Mon, 19 Oct 2015 16:01:54 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002: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 29DEF1B2E66 for ; Mon, 19 Oct 2015 16:01:54 -0700 (PDT) Received: by ykdr3 with SMTP id r3so227261ykd.1 for ; Mon, 19 Oct 2015 16:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IBUV/Z3egp46/py2eXKNYdaBrkEUlZzmDCFUuUxiWcE=; b=HF1d96P1rDeTbLQKhIDINzHG3vnaoh8s6Swp5L9ANtansMIJzSHSwTelto4UOuRusl Cciw6hF5bULyVD67N4Q12BLLinidJA8BsPNqk1BrllDUTufu7gFhdInSPQtsWSTrtXCs F4DU+6AVFXk5s8t4M9SPv3suFwyxN2hbrtmDNdamGdlRkBCd+ESYYzmEsRyX7qNA4A5Q YCXZStbSqi3JhsTh0W54EzCOByen6pKoz8ZXILgaWaIvXANYUo6+c04yxeHBzr+347mw qiS0fav5FGT8LwGgN/k1MHtbaf8hQ5h3JaO1haNNbb3h8rWDMLTIQVEcY3UJR8d2um8I Qp0A== MIME-Version: 1.0 X-Received: by 10.129.79.129 with SMTP id d123mr21805840ywb.159.1445295713384; Mon, 19 Oct 2015 16:01:53 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Mon, 19 Oct 2015 16:01:53 -0700 (PDT) Date: Mon, 19 Oct 2015 16:01:53 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Offline configurations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Oct 2015 23:01:55 -0000 This is an exploration of what it might take to bootstrap 0RTT without a prior TLS connection. https://tools.ietf.org/html/draft-thomson-tls-offline-config-00 There are two important lessons I've learned from this: 1. authentication is important (and hard to get right) 2. TLS implicitly includes a bunch of stuff in the server configuration, these are explicitly manifest here as extensions to the server configuration On this latter point, I believe that this identifies the additional state that needs to be considered as part of a server configuration by clients. These are implicitly included in the regular 0RTT setup and don't get entered into the 0RTT handshake hash. I don't think that's a problem, but it might be worth thinking about some. For instance, if a CertificateRequest alters how the client behaves for a second connection, should that be covered by the handshake hash for that connection? Similar concerns might apply to cipher suite selection and supported groups. For an offline configuration, the entire configuration is included both under a signature and as part of the handshake transcript for the new connection. That means that the certificate is covered twice. From nobody Mon Oct 19 17:46:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E1E1B2F6B for ; Mon, 19 Oct 2015 17:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Ixc7qFFOLjR7 for ; Mon, 19 Oct 2015 17:46:19 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 C59901B2F73 for ; Mon, 19 Oct 2015 17:46:18 -0700 (PDT) Received: by lbbes7 with SMTP id es7so1998492lbb.2 for ; Mon, 19 Oct 2015 17:46:17 -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:date:message-id:subject :from:to:cc:content-type; bh=aJ5F9D45kTctugtdzDl6RbsnDNWSvEwW/8B7M/cX5XY=; b=vieN7emLvIBn4lommhb9jp9pAlqh3lyUiCtqhl2WKQZd015HGxhHslSkYg4o7YsnJX eY+Z/J1wazbH6wSLeR1d//Cxb5wg7cJsP5HsovXR67ewIouaJO8Us6rg+hqtvriLn031 X8iyF+kY2hflXypDKGOfNE/1lbyNNQ8cpWrUP+U4Vep26pfvAnRGW4pDsJU4zBb0nqeD uY8Zqd92j5yLg8Olln5+u+k9pkeO6HOIadr/Av20aCaIbywpBDN1RJ/KitwWlPWdgbUq BYViRhIbiGSjY8lpXbC+W9DF57rqffEKYV4sqyGcvwV94kxRe/+kIwIy7dTTmmfF9K2q Cd1A== MIME-Version: 1.0 X-Received: by 10.112.180.230 with SMTP id dr6mr146976lbc.72.1445301976941; Mon, 19 Oct 2015 17:46:16 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.14.1 with HTTP; Mon, 19 Oct 2015 17:46:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 17:46:16 -0700 X-Google-Sender-Auth: twqCJ1VhMGwAoS2Pn-E-J-uW2FE Message-ID: From: Adam Langley To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c345bcedca9e05227e96ab Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Version in record MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Oct 2015 00:46:20 -0000 --001a11c345bcedca9e05227e96ab Content-Type: text/plain; charset=UTF-8 On Monday, October 19, 2015, Martin Thomson wrote: > On 19 October 2015 at 11:17, Eric Rescorla > > wrote: > > Yeah, I think that's riding the nonce far too hard. > > On what basis? Any change in the nonce will cause the record > decryption to fail. That's the property we're looking for here, isn't > it? I don't believe that there's any reason to include the sequence number in the AD input of an AEAD. I think that an empty AD for TLS would be fine now that the content type is encrypted. (Not that I deeply care either way.) Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --001a11c345bcedca9e05227e96ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, October 19, 2015, Martin Thomson <martin.thomson@gmail.com> wrote:
On 19 October 2015 at 11:17, Eric Rescorla <= ekr@rtfm.com> wrote:
> Yeah, I think that's riding the nonce far too hard.

On what basis?=C2=A0 Any change in the nonce will cause the record
decryption to fail.=C2=A0 That's the property we're looking for her= e, isn't
it?

I don't believe that there's an= y reason to include the sequence number in the AD input of an AEAD. I think= that an empty AD for TLS would be fine now that the content type is encryp= ted. (Not that I deeply care either way.)


Cheers

AGL


-- Adam Langley a= gl@imperialviolet.org https://www.imperialviolet.org
--001a11c345bcedca9e05227e96ab-- From nobody Mon Oct 19 23:39:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A49D1A1B8B for ; Mon, 19 Oct 2015 23:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ardZ0HT-ICI3 for ; Mon, 19 Oct 2015 23:38:57 -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 AF5631A1B8A for ; Mon, 19 Oct 2015 23:38:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA18889; Tue, 20 Oct 2015 06:38:55 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 20 Oct 2015 07:38:54 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.231]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Tue, 20 Oct 2015 14:38:49 +0800 From: "Zhouqian (Cathy)" To: "tls@ietf.org" Thread-Topic: New Version Notification for draft-zhou-tls-server-redirect-00.txt Thread-Index: AQHRClAFVETEAy4b0kuVcHSU+YJHVJ5z7W6Q Date: Tue, 20 Oct 2015 06:38:48 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Oct 2015 06:38:59 -0000 RGVhciBhbGwsDQpUaGlzIGlzIGEgbmV3IGRvY3VtZW50IHdlIGhhdmUgc3VibWl0dGVkIG9uIHRo ZSBUTFMgZXh0ZW5zaW9uIGZvciBzZXJ2ZXIgcmVkaXJlY3QuIEl0IGFpbXMgdG8gc29sdmUgdGhl IHByb2JsZW1zIGluIHNvbWUgYXBwbGljYXRpb25zLCBlLmcuLCBIVFRQUyByZWRpcmVjdC4gDQpU aGUgIkhlbGxvIEV4dGVuc2lvbnMiIG1lc3NhZ2UgaXMgZXh0ZW5kZWQgYW5kIGEgbmV3IFRMUyBo YW5kc2hha2UgcGFja2V0IGlzIGRlZmluZWQgdG8gc3VwcG9ydCB0aGlzIGtpbmQgb2YgYXBwbGlj YXRpb25zLiANCllvdXIgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgUmVnYXJkcywNCkNh dGh5IFpob3UNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4g U2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDE1IDU6MjUgUE0NCj4gVG86IEdhb2hvbmdsaWFu ZzsgR2FvaG9uZ2xpYW5nOyBaaG91cWlhbiAoQ2F0aHkpOyBaaG91cWlhbiAoQ2F0aHkpDQo+IFN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhvdS10bHMtc2VydmVy LXJlZGlyZWN0LTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16 aG91LXRscy1zZXJ2ZXItcmVkaXJlY3QtMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgQ2F0aHkgWmhvdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRv cnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtemhvdS10bHMtc2VydmVyLXJlZGlyZWN0DQo+IFJldmlz aW9uOgkwMA0KPiBUaXRsZToJCVRoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgRXh0 ZW5zaW9uIHRvIFN1cHBvcnQgU2VydmVyDQo+IFJlZGlyZWN0DQo+IERvY3VtZW50IGRhdGU6CTIw MTUtMTAtMTkNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQk2DQo+ IFVSTDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpob3Ut dGxzLXNlcnZlci1yZWRpcmVjdC0wMC50eHQNCj4gU3RhdHVzOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC16aG91LXRscy1zZXJ2ZXItcmVkaXJlY3QvDQo+IEh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhvdS10bHMtc2Vy dmVyLXJlZGlyZWN0LTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIEluIHNvbWUgYXBwbGlj YXRpb25zLCBlLmcuLCBIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wgU2VjdXJlDQo+ICAgIChI VFRQUykgdmlzaXQsIGEgY2xpZW50IHJlcXVlc3QgbmVlZHMgdG8gYmUgcmVkaXJldGVkIHRvIHRo ZQ0KPiAgICBvcGVyYXRvcidzIHdlYiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW9uIG9yIG92ZXJk dWUgcHJvY2Vzc2luZy4gIFRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgbmV3IGV4 dGVuc2lvbiBvZiBUTFMgaGFuZHNoYWtlIHByb3RvY29sDQo+ICAgIFtSRkM1MjQ2XSB0byB0cmFu c21pdCB0aGUgcmVkaXJlY3QgVW5pZm9ybS9Vbml2ZXJzYWwgUmVzb3VyY2UgTG9jYXRvcg0KPiAg ICAoVVJMKSBmb3IgSFRUUFMgYXBwbGljYXRpb25zLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Tue Oct 20 00:42:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFED1B2AB3 for ; Tue, 20 Oct 2015 00:42:24 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5Fd3t8GagRc for ; Tue, 20 Oct 2015 00:42:23 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c: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 B05171B2AA5 for ; Tue, 20 Oct 2015 00:42:22 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so32139235wic.1 for ; Tue, 20 Oct 2015 00:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p5WyVawHX50hAf6TfrvKO7+Ulwu+DnLz5EBepz4zssc=; b=s9m9JS4A6NB2g0gDajXmVwHYmoZgchWi/4GdAypyKE2Qwtz4+xN1Dt6tPtiXkoFDdm 7kWAdr4LVIO8yF3uPZj7BiFlTNt8GTgZxDHKiOhkKCWd6ImZDWk7SAWQ+oNHhIVYogl6 UUUa4eV8iU9xIYIGsQ01TMle7v47sXBsi4tbCM/FSDTS36OO5YpBEFQxdOKYy6UzPNrV yFqWjxVXhqdMMWpXXnk7HCOsHja+i9jkppA8PjAlGwkVYb7/qGybL79Cidt36iY34ruS 5Glxf4GaJfQhUYUkBv9kcLsnn+v1nEGVcxNz5JzqxC5fupFkFyhd5XnBY4uOu3xzSBVM zsTw== X-Received: by 10.194.201.130 with SMTP id ka2mr2137540wjc.123.1445326941192; Tue, 20 Oct 2015 00:42:21 -0700 (PDT) Received: from [192.168.6.85] (bzq-28-168-31-177.red.bezeqint.net. [31.168.28.177]) by smtp.gmail.com with ESMTPSA id p4sm18170551wia.15.2015.10.20.00.42.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Oct 2015 00:42:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Yoav Nir In-Reply-To: <20151019171442.GB31869@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 20 Oct 2015 10:42:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8FA6E91D-7322-4C73-8333-4FEA82517ED7@gmail.com> References: <20151019155617.4544.29879.idtracker@ietfa.amsl.com> <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com> <20151019171442.GB31869@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3094) Archived-At: Cc: IETF TLS Subject: Re: [TLS] New Version Notification for draft-ietf-tls-rfc4492bis-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Oct 2015 07:42:25 -0000 Hi Ilari > On 19 Oct 2015, at 8:14 PM, Ilari Liusvaara = wrote: >=20 > On Mon, Oct 19, 2015 at 06:58:52PM +0300, Yoav Nir wrote: >> Hi >>=20 >> I=E2=80=99ve submitted version -04 of this draft, incorporating the = new curves Curve25519 and Curve448. >>=20 >> I=E2=80=99m sorry to say that I have made the merge far too quickly = and the result is quite sketchy, but I did beat the deadline. >>=20 >> So I=E2=80=99m hoping to complete the merge soon. >=20 > Some comments: >=20 > - The document seems to lack obsoletes RFC4492 (or even updates > RFC4492). Isn't this supposed to supercede that document? Yes. I=E2=80=99ve just updated this in = https://github.com/tlswg/rfc4492bis > - Curve25519 and Curve448 are called "X25519" and "X448" in the > (looks to be imminently sent to RFC editor) draft. The functions are called X25519 and X448 (Shouldn=E2=80=99t it have been = X4482241? Probably not). But the curves are called Curve25519 and = Curve448 as is the title of sections 4.1, 4.2, 6.1, and 6.2 in the CFRG = draft. > - In public key validation, X448 resists invalid point attacks > the same way as X25519 (of course, all bits of X448 public > keys can be nonzero, as the value can get to almost 256^56). > - The document still does have restrictions on algorithms used > to sign the certificate. AFAIK, TLS 1.2 (RFC5246) lifted all > such restrictions (at least sections 2.2, 5.3 and 5.6). Weird. I had intended to do that. I will create a pull request for this. > - Do we want to keep ECDH client keys? Those were used in one > recent exploit against one implementation of TLS. And using > one destroys forward secrecy anyway. > - Is this document meant to also include the CFRG signatures > work? The interfaces to functions are already known. That is the intention. A PR is welcome. Yoav From nobody Tue Oct 20 00:58:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2131B2BDA for ; Tue, 20 Oct 2015 00:58:03 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GfEbXB-Vtf5 for ; Tue, 20 Oct 2015 00:58:02 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 2AB8A1B2BD7 for ; Tue, 20 Oct 2015 00:58:02 -0700 (PDT) Received: by wicll6 with SMTP id ll6so15463882wic.1 for ; Tue, 20 Oct 2015 00:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vBRjXPFvMremsPyxy89V0Gt6mjw01RxH0v+tRZqF6Q0=; b=KQlhsmbncl6oDfB0mlg6P5jvS5Tj4Ru/MAhFGbq279L516t3PFhun8qyDV/ct4mD3k 19akaoJZQ77fQY/C8GBmOS7Ac4dqdaFodTIVa9ejHMq3EGQWlYlqgiY1O3IigqZkFo8N TQiFlnhau01hkq4cyuHNGK0j5KcEK/MaimDIkSSlP1jXLi2lNrEc3wYhSZ5UEc902agL CuA4g5axZ87Bs0y61JDam30kygWJw2kqeo7LNh/+MIDpo94bzYczJ7/i/Mj09v6HLzcZ k9TYma8mp54/q/ECw3BjOyRuXb7bhgWo9PCpsg/Y1pgFIJXz/YkgJAji1tkYsWoUdm7c nSSQ== X-Received: by 10.194.123.168 with SMTP id mb8mr2252691wjb.108.1445327880748; Tue, 20 Oct 2015 00:58:00 -0700 (PDT) Received: from [192.168.6.85] (bzq-28-168-31-177.red.bezeqint.net. [31.168.28.177]) by smtp.gmail.com with ESMTPSA id h8sm1799594wib.21.2015.10.20.00.57.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Oct 2015 00:58:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Yoav Nir In-Reply-To: <8FA6E91D-7322-4C73-8333-4FEA82517ED7@gmail.com> Date: Tue, 20 Oct 2015 10:57:57 +0300 Content-Transfer-Encoding: 7bit Message-Id: <3EF0C123-962C-4FF6-9075-DE109F9C1275@gmail.com> References: <20151019155617.4544.29879.idtracker@ietfa.amsl.com> <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com> <20151019171442.GB31869@LK-Perkele-V2.elisa-laajakaista.fi> <8FA6E91D-7322-4C73-8333-4FEA82517ED7@gmail.com> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3094) Archived-At: Cc: IETF TLS Subject: Re: [TLS] New Version Notification for draft-ietf-tls-rfc4492bis-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Oct 2015 07:58:04 -0000 > On 20 Oct 2015, at 10:42 AM, Yoav Nir wrote: > > >> - In public key validation, X448 resists invalid point attacks >> the same way as X25519 (of course, all bits of X448 public >> keys can be nonzero, as the value can get to almost 256^56). >> - The document still does have restrictions on algorithms used >> to sign the certificate. AFAIK, TLS 1.2 (RFC5246) lifted all >> such restrictions (at least sections 2.2, 5.3 and 5.6). > > Weird. I had intended to do that. I will create a pull request for this. https://github.com/tlswg/rfc4492bis/pull/10/files Yoav From nobody Tue Oct 20 08:36:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1711B343F for ; Tue, 20 Oct 2015 08:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WJti2UBnDTr for ; Tue, 20 Oct 2015 08:35:55 -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 532021A9083 for ; Tue, 20 Oct 2015 08:34:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 48D0F4334C1; Tue, 20 Oct 2015 15:34:15 +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 327294334AC; Tue, 20 Oct 2015 15:34:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445355255; bh=lOe8+8ZHdzDHEDven2WxU/qlqNzpZdKP8jW/UDDCa3c=; l=998; h=To:References:From:Date:In-Reply-To:From; b=hltOiIRX8I5+NQ3J67LdZ+YTkVGEIqjtYN4qwcpq8GYJM5LXGo3dqxvai5bZWuoBQ qufSmQYikvSXT1fXRCp+SA+3S0yQvvLvE8Wy5TffW4ybQQ7gSBopPgqKjpP/HIdLOz TOp9zZ8TzlphsMtFwSlrSGlJpCnS8Rr7lJbbpx3Q= 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 EACFA2035; Tue, 20 Oct 2015 15:34:14 +0000 (GMT) To: "Zhouqian (Cathy)" , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <56265EF6.2010908@akamai.com> Date: Tue, 20 Oct 2015 10:34:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Oct 2015 15:36:00 -0000 On 10/20/2015 01:38 AM, Zhouqian (Cathy) wrote: > Dear all, > This is a new document we have submitted on the TLS extension for server redirect. It aims to solve the problems in some applications, e.g., HTTPS redirect. > The "Hello Extensions" message is extended and a new TLS handshake packet is defined to support this kind of applications. > Your comments are welcome. > I am not sure I understand the "overdue" use case, but the "web authentication" use case sounds like an ordinary captive portal; there's a proposed "capport" working group exclusively for handling captive portals (https://datatracker.ietf.org/wg/capport/) which might be worth visiting. The "overdue" use case might also be considered a captive portal, but I can't quite tell given the current description. In any case, it is far from clear that HTTP-specific issues should be handled at the TLS layer -- TLS is a generic secure channel protocol used in many applications other than HTTPS. -Ben Kaduk From nobody Tue Oct 20 10:35:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329931ACD8E for ; Tue, 20 Oct 2015 10:35:49 -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, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI6TIlpc7byv for ; Tue, 20 Oct 2015 10:35:43 -0700 (PDT) Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id E588A1ACD8A for ; Tue, 20 Oct 2015 10:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id 0F82A5A7A6B; Tue, 20 Oct 2015 20:35:25 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id Pn5VBySL3JlH; Tue, 20 Oct 2015 20:35:23 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 6D07B5BC002; Tue, 20 Oct 2015 20:35:40 +0300 (EEST) From: Ilari Liusvaara To: tls@ietf.org Date: Tue, 20 Oct 2015 20:35:18 +0300 Message-Id: <1445362518-2482-1-git-send-email-ilari.liusvaara@welho.com> X-Mailer: git-send-email 2.6.1 In-Reply-To: <8FA6E91D-7322-4C73-8333-4FEA82517ED7@gmail.com> References: <8FA6E91D-7322-4C73-8333-4FEA82517ED7@gmail.com> Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] [PATCH RFC4492bis] Add EdDSA signature support X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Oct 2015 17:35:49 -0000 From: Ilari Liusvaara --- On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote: > Hi Ilari > > > - Is this document meant to also include the CFRG signatures > > work? The interfaces to functions are already known. > > That is the intention. A PR is welcome. Well, here's an attempt at a patch. Comments welcome. Idea is to use SignatureAndHash (eddsa, none) for EdDSA signatures, and have two new curves for it, one for Ed25519{,ph} and the other for Ed448{,ph}. I shared the ciphersuites and key exchange algorithms between ECDSA and EdDSA. Turned out to be bit cleaner than I expected in TLS 1.0/1.1 due to separate curves. This also should incorporate the TLS 1.2 changes to signing algorithm requirements (but I may have missed some). Also, the ECDH_fixed client signatures are still there. Should those be, those definitely destroy FPS and AFAIK aren't used in wild? Also, the ciphersuite list looks bad. RC4... Really? draft-ietf-tls-rfc4492bis.xml | 154 ++++++++++++++++++++++++++++-------------- 1 file changed, 103 insertions(+), 51 deletions(-) diff --git a/draft-ietf-tls-rfc4492bis.xml b/draft-ietf-tls-rfc4492bis.xml index acf1525..0966bb8 100644 --- a/draft-ietf-tls-rfc4492bis.xml +++ b/draft-ietf-tls-rfc4492bis.xml @@ -53,8 +53,8 @@ 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) as - a new authentication mechanism. + (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. @@ -119,7 +121,7 @@ Algorithm Description - ECDHE_ECDSAEphemeral ECDH with ECDSA signatures. + ECDHE_ECDSAEphemeral ECDH with ECDSA or EdDSA signatures. ECDHE_RSAEphemeral ECDH with RSA signatures. ECDH_anonAnonymous ephemeral ECDH, no signatures. @@ -134,7 +136,7 @@ Note that there is no structural difference between ECDH and ECDSA keys. A certificate issuer may use X.509 v3 keyUsage and extendedKeyUsage extensions to restrict the use of an ECC public key to certain computations. This document refers to an ECC key as ECDH-capable if its use in ECDH is permitted. - ECDSA-capable is defined similarly.
+ ECDSA-capable and EdDSA-cabable are defined similarly.
and of the optional ECC-specific extensions (which impact the Hello messages) until .
- In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable public key and be signed with - ECDSA. + In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable or EdDSA-capable public key. The server sends its ephemeral ECDH public key and a specification of the corresponding curve in the - ServerKeyExchange message. These parameters MUST be signed with ECDSA using the private key corresponding - to the public key in the server's Certificate. + ServerKeyExchange message. These parameters MUST be signed with ECDSA or EdDSA using the private key + corresponding to the public key in the server's Certificate. The client generates an ECDH key pair on the same curve as the server's ephemeral ECDH key and sends its public key in the ClientKeyExchange message. Both client and server perform an ECDH operation and use the resultant @@ -179,7 +180,7 @@
This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message must be - computed with the corresponding RSA private key. The server certificate MUST be signed with RSA. + computed with the corresponding RSA private key.
NOTE: Despite the name beginning with "ECDH_" (no E), the key used in ECDH_anon is ephemeral just like @@ -193,14 +194,9 @@ its public key in the ClientKeyExchange message. Both client and server perform an ECDH operation and use the resultant shared secret as the premaster secret. All ECDH calculations are performed as specified in . - Note that while the ECDHE_ECDSA and ECDHE_RSA key exchange algorithms require the server's certificate - to be signed with a particular signature scheme, this specification (following the similar cases of - DHE_DSS, and DHE_RSA in the TLS base documents) does not impose restrictions on signature schemes used - elsewhere in the certificate chain. (Often such restrictions will be useful, and it is expected that this - will be taken into account in certification authorities' signing practices. However, such restrictions are - not strictly required in general: Even if it is beyond the capabilities of a client to completely validate - a given chain, the client may be able to validate the server's certificate by relying on a trusted - certification authority whose certificate appears as one of the intermediate certificates in the chain.) + This specification does not impose restrictions on signature schemes used anywhere in the certificate chain. + The previous version of this document required the signatures to match, but this restriction, originating + in previous TLS versions is lifted here as it had been in RFC 5246.
@@ -224,7 +220,7 @@ different type than the server certificate.
To use this authentication mechanism, the client MUST possess a certificate containing an ECDSA-capable - public key and signed with ECDSA. + or EdDSA-capable public key. The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify message as described in .
@@ -291,9 +287,9 @@ cipher suites must be negotiated only if the server can successfully complete the handshake while using the curves and point formats supported by the client (cf. and ). - NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for the ECDSA - key in its certificate, and for the ephemeral ECDH key in the ServerKeyExchange message. The server MUST - consider the extensions in both cases. + NOTE: A server participating in an ECDHE_ECDSA key exchange may use different curves for the ECDSA or + EdDSA key in its certificate, and for the ephemeral ECDH key in the ServerKeyExchange message. The server + MUST consider the extensions in both cases. If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, or is unable to complete the ECC handshake while restricting itself to the enumerated curves and point formats, it MUST NOT negotiate the use of an ECC cipher suite. @@ -303,13 +299,15 @@ RFC 4492 defined 25 different curves in the NamedCurve registry for use in TLS. Only three have seen any use. This specification is deprecating the rest (with numbers 1-22). This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. It also adds the new curves - defined in . The end result is as follows: + defined in and . The end result is as follows:
. These curves are also recommended in ANSI X9.62 and FIPS 186-4 . Curve25519 and Curve448 - are defined in . Values 0xFE00 through 0xFEFF are reserved for private use. + are defined in . Ed25519 and Ed448 are signature-only curves defined in + . Values 0xFE00 through 0xFEFF are reserved for private use. The NamedCurve name space is maintained by IANA. See for information on how new value assignments are added.
Three point formats were included in the definition of ECPointFormat above. This specification deprecates all but the uncompressed point format. Implementations of this document MUST support the - uncompressed format for all of their supported curves, and MUST support no other formats for curves + uncompressed format for all of their supported curves, and MUST NOT support other formats for curves defined in this specification. For backwards compatibility purposes, the point format list extension MUST still be included, and contain exactly one value: the uncomptessed point format (0). The ECPointFormat name space is maintained by IANA. See for information on how @@ -449,7 +448,8 @@ represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this extension was used. For the Curve25519 and Curve448 curves, the only valid representation is the one specified in - - a 32- or 56-octet representation of the u value of the point. + - a 32- or 56-octet representation of the u value of the point. This structure + MUST NOT be used with Ed25519 and Ed448 public keys.
This identifies the type of the elliptic curve domain parameters. Specifies a recommended set of elliptic curve domain parameters. All those values of NamedCurve are allowed that refer to a specific curve. Values of NamedCurve that indicate - support for a class of explicitly defined curves are not allowed here (they are only permissible in - the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and - arbitrary_explicit_char2_curves(0xFF02). + support for a class of explicitly defined curves or signature-only curves are not allowed here (they are + only permissible in the ClientHello extension); this applies to Ed25519(TBD3), Ed448(TBD4), + arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02).
A hash of the params, with the signature appropriate to that hash applied. The private key corresponding to the certified public key in the server's Certificate message is used for signing.
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange algorithm and "anonymous" for ECDH_anon. - These cases are defined in TLS. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA signatures are - generated and verified as described in , and SHA in the above template for + These cases are defined in TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA. ECDSA signatures + are generated and verified as described in , and SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature consists of a pair of integers, r and s. The digitally-signed element is encoded as an opaque vector <0..2^16-1>, the contents of which are the DER encoding corresponding to the following ASN.1 @@ -511,6 +518,9 @@ s INTEGER } ]]>
 + EdDSA signatures are generated and verified according to . The digitally-signed + element is encoded as an opaque vector<0..2^16-1>, the contents of which is the octet string output of + the EdDSA signing algorithm. Actions of the sender: The server selects elliptic curve domain parameters and an ephemeral ECDH public key corresponding to these parameters according to the ECKAS-DH1 scheme from IEEE 1363 . @@ -558,14 +568,14 @@ certificates as described in . NOTE: The client's Certificate message is capable of carrying a chain of certificates. The restrictions mentioned in Table 4 apply only to the client's certificate (first in the chain). - + Client Authentication Method Client Certificate Type - ECDSA_signCertificate MUST contain an ECDSA-capable public key and be signed with ECDSA. + ECDSA_signCertificate MUST contain an ECDSA-capable or EdDSA-capable public key. ECDSA_fixed_ECDHCertificate MUST contain an ECDH-capable public key on the same elliptic curve - as the server's long-term ECDH key. This certificate MUST be signed with ECDSA. - RSA_fixed_ECDHCertificate MUST contain an ECDH-capable public key on the same elliptic curve - as the server's long-term ECDH key. This certificate MUST be signed with RSA. + as the server's long-term ECDH key. + RSA_fixed_ECDHThe same as ECDSA_fixed_ECDH. The codepoints meant different things, but due to + changes in TLS 1.2, both mean the same thing now. Structure of this message: Identical to the TLS client Certificate format. @@ -599,9 +609,10 @@ } ClientECDiffieHellmanPublic; ]]>
 Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, - which may represent an elliptic curve point in uncompressed or compressed format. Here, the format - MUST conform to what the server has requested through a Supported Point Formats Extension if this - extension was used, and MUST be uncompressed if this extension was not used.
Structure of this message: The TLS CertificateVerify message and the underlying Signature type are defined in the TLS base - specifications, and the latter is extended here in . For the ecdsa case, the signature - field in the CertificateVerify message contains an ECDSA signature computed over handshake messages - exchanged so far, exactly similar to CertificateVerify with other signing algorithms:
. For the ecdsa and eddsa cases, the + signature field in the CertificateVerify message contains an ECDSA or EdDSA (respectively) signature computed + over handshake messages exchanged so far, exactly similar to CertificateVerify with other signing + algorithms:
ECDSA signatures are computed as described in , and SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an @@ -641,6 +655,9 @@ s INTEGER } ]]>
 + EdDSA signatures are generated and verified according to . The digitally-signed + element is encoded as an opaque vector<0..2^16-1>, the contents of which is the octet string output of + the EdDSA signing algorithm. Actions of the sender: The client computes its signature over all handshake messages sent or received starting at client hello and up to but not including this message. It uses the private key corresponding to its certified public @@ -651,8 +668,12 @@
X.509 certificates containing ECC public keys or signed using ECDSA MUST comply with - or another RFC that replaces or extends it. Clients SHOULD use the elliptic - curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 . + or another RFC that replaces or extends it. X.509 certificates containing ECC + public keys or signed using EdDSA MUST comply with . Clients SHOULD use the + elliptic curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 + or in . + EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the Ed25519 curve, and Ed448 and Ed448ph keys + MUST use the Ed448 curve. Curves Curve25519, Curve448, Ed25519 and Ed448 MUST NOT be used for ECDSA.
All ECDH calculations for the NIST curves (including parameter and key generation as well as the shared @@ -675,11 +696,15 @@ signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. The default hash function is SHA-1 , and sha_size (see and ) is 20. However, an alternative hash function, such - as one of the new SHA hash functions specified in FIPS 180-2 , may be used instead. + as one of the new SHA hash functions specified in FIPS 180-2 , SHOULD be used instead. + All EdDSA computations MUST be performed according to or its succesors. Data + to be signed/verified is run through the EdDSA algorithm wih no hashing (EdDSA will internally run the data + through the PH function). RFC 4492 anticipated the standardization of a mechanism for specifying the required hash function in the certificate, perhaps in the parameters field of the subjectPublicKeyInfo. Such standardization never took place, and as a result, - SHA-1 is used in TLS 1.1 and earlier. TLS 1.2 added a SignatureAndHashAlgorithm parameter to the DigitallySigned struct, - thus allowing agility in choosing the signature hash. + SHA-1 is used in TLS 1.1 and earlier (except for EdDSA, which uses identity function). TLS 1.2 added a + SignatureAndHashAlgorithm parameter to the DigitallySigned struct, thus allowing agility in choosing the + signature hash. EdDSA signatures MUST have HashAlgorithm of 0 (None). All RSA signatures must be generated and verified according to block type 1.
@@ -688,14 +713,16 @@ key, to the point that they may recover the entire private key in a few requests, if that key is not really ephemeral. Curve25519 was designed in a way that the result of Curve25519(x, d) will never reveal information about - d, provided it was chosen as prescribed, for any value of x. + d, provided it was chosen as prescribed, for any value of x (the same holds true for Curve448). Let's define legitimate values of x as the values that can be obtained as x = Curve25519(G, d') for some d, and call the other values illegitimate. The definition of the Curve25519 function shows that legitimate - values all share the following property: the high-order bit of the last byte is not set. + values all share the following property: the high-order bit of the last byte is not set (for Ed448, any bit + can be set). Since there are some implementation of the Curve25519 function that impose this restriction on their input and others that don't, implementations of Curve25519 in TLS SHOULD reject public keys when the high-order bit of the last byte is set (in other words, when the value of the leftmost byte is greater than 0x7F) in order to prevent implementation fingerprinting. + Ed25519 and Ed448 internally do public key validation as part of signature verification. Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with Curve25519.
@@ -770,8 +797,10 @@ NOTE: IANA, please update the registries to reflect the new policy name. NOTE: RFC editor please delete these two notes prior to publication. IANA, please update these two registries to refer to this document. - IANA is requested to assign two values from the NamedCurve registry with names Curve25519(TBD1) and - Curve448(TBD2) with this document as reference. + IANA is requested to assign four values from the NamedCurve registry with names Curve25519(TBD1), + Curve448(TBD2), Ed25519(TBD3) and Ed448(TBD4) with this document as reference. + IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this + document as reference.
Most of the text is this document is taken from , the predecessor of this @@ -785,6 +814,9 @@
NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION + Changes from draft-ietf-tls-rfc4492bis-03 to draft-nir-tls-rfc4492bis-05: + Add support for CFRG curves and signatures work. + Changes from draft-ietf-tls-rfc4492bis-01 to draft-nir-tls-rfc4492bis-03: Removed unused curves. Removed unused point formats (all but uncompressed) @@ -816,6 +848,26 @@ + + + EdDSA: Ed25519 and Ed448 + + + + + + + + + + Using EdDSA in the Internet X.509 Public Key Infrastructure + + + + + + + The TLS Protocol Version 1.0 -- 2.6.1 From nobody Tue Oct 20 20:03:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1881B2D8B for ; Tue, 20 Oct 2015 20:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA1X53eu6zBq for ; Tue, 20 Oct 2015 20:03:31 -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 175BA1A92B1 for ; Tue, 20 Oct 2015 20:03:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCU95671; Wed, 21 Oct 2015 03:03:29 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 21 Oct 2015 04:03:28 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.231]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 21 Oct 2015 11:02:50 +0800 From: "Zhouqian (Cathy)" To: Benjamin Kaduk , "tls@ietf.org" Thread-Topic: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt Thread-Index: AQHRClAFVETEAy4b0kuVcHSU+YJHVJ5z7W6QgAARYQCAAUBWgA== Date: Wed, 21 Oct 2015 03:02:49 +0000 Message-ID: References: <56265EF6.2010908@akamai.com> In-Reply-To: <56265EF6.2010908@akamai.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 03:03:34 -0000 Hi Benjamin, Thank you for your comments. Please see inline. Best Regards, Cathy > -----Original Message----- > From: Benjamin Kaduk [mailto:bkaduk@akamai.com] > Sent: Tuesday, October 20, 2015 11:34 PM > To: Zhouqian (Cathy); tls@ietf.org > Subject: Re: [TLS] FW: New Version Notification for > draft-zhou-tls-server-redirect-00.txt >=20 > On 10/20/2015 01:38 AM, Zhouqian (Cathy) wrote: > > Dear all, > > This is a new document we have submitted on the TLS extension for serve= r > redirect. It aims to solve the problems in some applications, e.g., HTTPS > redirect. > > The "Hello Extensions" message is extended and a new TLS handshake pack= et > is defined to support this kind of applications. > > Your comments are welcome. > > >=20 > I am not sure I understand the "overdue" use case, but the "web > authentication" use case sounds like an ordinary captive portal; there's = a > proposed "capport" working group exclusively for handling captive portals > (https://datatracker.ietf.org/wg/capport/) which might be worth visiting.= The > "overdue" use case might also be considered a captive portal, but I can't= quite > tell given the current description. [Cathy]Yes, both web authentication and overdue use cases could be consider= ed as captive portals.=20 And I have already sent an email to the capport mailing list for their comm= ents. > In any case, it is far from clear that HTTP-specific issues should be han= dled at > the TLS layer -- TLS is a generic secure channel protocol used in many > applications other than HTTPS. [Cathy] As defined in [RFC 5246], "application protocol An application protocol is a protocol that normally layers directly on top of the transport layer (e.g., TCP/IP). Examples include HTTP, TELNET, FTP, and SMTP.", the TLS protocol could be used for HTTP applications. >=20 > -Ben Kaduk From nobody Tue Oct 20 23:12:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314E51B35D5 for ; Tue, 20 Oct 2015 23:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_75=0.6, SPF_PASS=-0.001] autolearn=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 Cyi_NlUX87of for ; Tue, 20 Oct 2015 23:11:58 -0700 (PDT) Received: from mail-wi0-x242.google.com (mail-wi0-x242.google.com [IPv6:2a00:1450:400c:c05::242]) (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 4A69C1B35D7 for ; Tue, 20 Oct 2015 23:11:58 -0700 (PDT) Received: by wicuv6 with SMTP id uv6so9840822wic.2 for ; Tue, 20 Oct 2015 23:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fj+7pZmXmemCtxoOvOO02X3h1vnVkevoG9fs7D8/0t8=; b=MY1V6Hep+AJyKBHCbX1UZ9sstIj40A4+Op01/K+lHMOtMvo8KVQNHifBCJsyvg/Mu1 YaqEzvJCqSVcQSfqEBzeGGli/DNR8tN5BRdlv34YYri0xtQbz6h5qDjDBVUD8q1ZbDfY QHGxYMrMZFLt7Q5SVl2u+Ff6t95mbK9g6geMFD7QnSxr1FOOmk/e6esYy341mNvd5Z+K eC9se8f+nRQGEwKTkNPgLmW+er/K5eR3wk8jsoN4jbNEZkVbiv38p74FfmSj+VY4p5n1 +eCgr8C/NfGfCvpRc8zhTT4j/yPl5JF2bptG8KImWd2H5n1PewbhuN1pMbfek2Aqd51/ w8yA== X-Received: by 10.194.24.68 with SMTP id s4mr9163074wjf.12.1445407916864; Tue, 20 Oct 2015 23:11:56 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([176.12.149.118]) by smtp.gmail.com with ESMTPSA id az6sm22208539wib.12.2015.10.20.23.11.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Oct 2015 23:11:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Yoav Nir In-Reply-To: <1445362518-2482-1-git-send-email-ilari.liusvaara@welho.com> Date: Wed, 21 Oct 2015 09:11:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FA6E91D-7322-4C73-8333-4FEA82517ED7@gmail.com> <1445362518-2482-1-git-send-email-ilari.liusvaara@welho.com> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3094) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [PATCH RFC4492bis] Add EdDSA signature support X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 06:12:03 -0000 LGTM. Can you push this to GitHub? > On 20 Oct 2015, at 8:35 PM, Ilari Liusvaara = wrote: >=20 > From: Ilari Liusvaara >=20 > --- > On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote: >> Hi Ilari >>=20 >>> - Is this document meant to also include the CFRG signatures >>> work? The interfaces to functions are already known. >>=20 >> That is the intention. A PR is welcome. >=20 > Well, here's an attempt at a patch. Comments welcome. >=20 > Idea is to use SignatureAndHash (eddsa, none) for EdDSA signatures, > and have two new curves for it, one for Ed25519{,ph} and the other > for Ed448{,ph}. I shared the ciphersuites and key exchange algorithms > between ECDSA and EdDSA. Turned out to be bit cleaner than I expected > in TLS 1.0/1.1 due to separate curves. >=20 > This also should incorporate the TLS 1.2 changes to signing algorithm > requirements (but I may have missed some). >=20 > Also, the ECDH_fixed client signatures are still there. Should those = be, > those definitely destroy FPS and AFAIK aren't used in wild? >=20 > Also, the ciphersuite list looks bad. RC4... Really? >=20 >=20 > draft-ietf-tls-rfc4492bis.xml | 154 = ++++++++++++++++++++++++++++-------------- > 1 file changed, 103 insertions(+), 51 deletions(-) >=20 > diff --git a/draft-ietf-tls-rfc4492bis.xml = b/draft-ietf-tls-rfc4492bis.xml > index acf1525..0966bb8 100644 > --- a/draft-ietf-tls-rfc4492bis.xml > +++ b/draft-ietf-tls-rfc4492bis.xml > @@ -53,8 +53,8 @@ > > This document describes key exchange algorithms based on = Elliptic Curve Cryptography (ECC) for the Transport=20 > Layer Security (TLS) protocol. In particular, it specifies = the use of Ephemeral Elliptic Curve Diffie-Hellman=20 > - (ECDHE) key agreement in a TLS handshake and the use of = Elliptic Curve Digital Signature Algorithm (ECDSA) as=20 > - a new authentication mechanism. > + (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. > > > > > > @@ -119,7 +121,7 @@ > > Algorithm > Description > - ECDHE_ECDSAEphemeral ECDH with ECDSA = signatures. > + ECDHE_ECDSAEphemeral ECDH with ECDSA or EdDSA = signatures. > ECDHE_RSAEphemeral ECDH with RSA signatures. > ECDH_anonAnonymous ephemeral ECDH, no = signatures. > > @@ -134,7 +136,7 @@ > Note that there is no structural difference between ECDH and = ECDSA keys. A certificate issuer may use=20 > X.509 v3 keyUsage and extendedKeyUsage extensions to restrict = the use of an ECC public key to certain=20 > computations. This document refers to an ECC key as = ECDH-capable if its use in ECDH is permitted. =20 > - ECDSA-capable is defined similarly.
> + ECDSA-capable and EdDSA-cabable are defined similarly. =
> Client Server > ------ ------ > @@ -166,11 +168,10 @@ > and of the optional = ECC-specific extensions (which impact the Hello messages)=20 > until . >
> - In ECDHE_ECDSA, the server's certificate MUST contain an = ECDSA-capable public key and be signed with=20 > - ECDSA. > + In ECDHE_ECDSA, the server's certificate MUST contain an = ECDSA-capable or EdDSA-capable public key. > The server sends its ephemeral ECDH public key and a = specification of the corresponding curve in the=20 > - ServerKeyExchange message. These parameters MUST be signed = with ECDSA using the private key corresponding=20 > - to the public key in the server's Certificate. > + ServerKeyExchange message. These parameters MUST be signed = with ECDSA or EdDSA using the private key > + corresponding to the public key in the server's = Certificate. > The client generates an ECDH key pair on the same curve as = the server's ephemeral ECDH key and sends its=20 > public key in the ClientKeyExchange message. > Both client and server perform an ECDH operation and use the resultant=20 > @@ -179,7 +180,7 @@ >
> This key exchange algorithm is the same as ECDHE_ECDSA = except that the server's certificate MUST contain=20 > an RSA public key authorized for signing, and that the = signature in the ServerKeyExchange message must be=20 > - computed with the corresponding RSA private key. The = server certificate MUST be signed with RSA. > + computed with the corresponding RSA private key. >
>
> NOTE: Despite the name beginning with "ECDH_" (no E), the = key used in ECDH_anon is ephemeral just like=20 > @@ -193,14 +194,9 @@ > its public key in the ClientKeyExchange message. > Both client and server perform an ECDH operation and use = the resultant shared secret as the premaster=20 > secret. All ECDH calculations are performed as specified in = . > - Note that while the ECDHE_ECDSA and ECDHE_RSA key = exchange algorithms require the server's certificate=20 > - to be signed with a particular signature scheme, this = specification (following the similar cases of=20 > - DHE_DSS, and DHE_RSA in the TLS base documents) does not = impose restrictions on signature schemes used=20 > - elsewhere in the certificate chain. (Often such = restrictions will be useful, and it is expected that this=20 > - will be taken into account in certification authorities' = signing practices. However, such restrictions are=20 > - not strictly required in general: Even if it is beyond the = capabilities of a client to completely validate=20 > - a given chain, the client may be able to validate the = server's certificate by relying on a trusted=20 > - certification authority whose certificate appears as one of = the intermediate certificates in the chain.) > + This specification does not impose restrictions on = signature schemes used anywhere in the certificate chain. > + The previous version of this document required the = signatures to match, but this restriction, originating > + in previous TLS versions is lifted here as it had been in = RFC 5246. >
>
>
> @@ -224,7 +220,7 @@ > different type than the server certificate. >
> To use this authentication mechanism, the client MUST = possess a certificate containing an ECDSA-capable=20 > - public key and signed with ECDSA. > + or EdDSA-capable public key. > The client proves possession of the private key = corresponding to the certified key by including a=20 > signature in the CertificateVerify message as described in = . >
> @@ -291,9 +287,9 @@ > cipher suites must be negotiated only if the server can = successfully complete the handshake while using=20 > the curves and point formats supported by the client (cf. = and=20 > ). > - NOTE: A server participating in an ECDHE-ECDSA key = exchange may use different curves for the ECDSA=20 > - key in its certificate, and for the ephemeral ECDH key in = the ServerKeyExchange message. The server MUST=20 > - consider the extensions in both cases. > + NOTE: A server participating in an ECDHE_ECDSA key = exchange may use different curves for the ECDSA or > + EdDSA key in its certificate, and for the ephemeral ECDH = key in the ServerKeyExchange message. The server > + MUST consider the extensions in both cases. > If a server does not understand the Supported Elliptic = Curves Extension, does not understand the=20 > Supported Point Formats Extension, or is unable to complete = the ECC handshake while restricting itself=20 > to the enumerated curves and point formats, it MUST NOT = negotiate the use of an ECC cipher suite. =20 > @@ -303,13 +299,15 @@ > RFC 4492 defined 25 different curves in the NamedCurve = registry for use in TLS. Only three have seen=20 > any use. This specification is deprecating the rest (with = numbers 1-22). This specification also=20 > deprecates the explicit curves with identifiers 0xFF01 and = 0xFF02. It also adds the new curves=20 > - defined in . The end result = is as follows: > + defined in and . The end result is as follows: >
enum { > deprecated(1..22), > secp256r1 (23), secp384r1 (24), secp521r1 (25), > Curve25519(TBD1), > Curve448(TBD2), > + Ed25519(TBD3), > + Ed448(TBD4), > reserved (0xFE00..0xFEFF), > deprecated(0xFF01..0xFF02), > (0xFFFF) > @@ -320,7 +318,8 @@ > curves. The named curves secp256r1, secp384r1, and = secp521r1 are specified in SEC 2=20 > . These curves are also = recommended in ANSI X9.62=20 > and FIPS 186-4 . Curve25519 and Curve448=20 > - are defined in . Values = 0xFE00 through 0xFEFF are reserved for private use. > + are defined in . Ed25519 = and Ed448 are signature-only curves defined in > + . Values 0xFE00 through = 0xFEFF are reserved for private use. > The NamedCurve name space is maintained by IANA. See = for information on how new=20 > value assignments are added. >
@@ -349,7 +348,7 @@ > ]]>
> Three point formats were included in the definition of = ECPointFormat above. This specification=20 > deprecates all but the uncompressed point format. = Implementations of this document MUST support the=20 > - uncompressed format for all of their supported curves, = and MUST support no other formats for curves > + uncompressed format for all of their supported curves, = and MUST NOT support other formats for curves > defined in this specification. For backwards compatibility = purposes, the point format list extension > MUST still be included, and contain exactly one value: the = uncomptessed point format (0). > The ECPointFormat name space is maintained by IANA. See = for information on how=20 > @@ -449,7 +448,8 @@ > represent an elliptic curve point in uncompressed or = compressed format; it MUST conform to what the=20 > client has requested through a Supported Point Formats = Extension if this extension was used. For the > Curve25519 and Curve448 curves, the only valid = representation is the one specified in=20 > - - a 32- or 56-octet = representation of the u value of the point. > + - a 32- or 56-octet = representation of the u value of the point. This structure > + MUST NOT be used with Ed25519 and Ed448 public keys. >
struct { > ECCurveType curve_type; > @@ -462,9 +462,9 @@ > This identifies the type of the = elliptic curve domain parameters. > Specifies a recommended set of = elliptic curve domain parameters. All those=20 > values of NamedCurve are allowed that refer to a specific = curve. Values of NamedCurve that indicate=20 > - support for a class of explicitly defined curves are not = allowed here (they are only permissible in=20 > - the ClientHello extension); this applies to = arbitrary_explicit_prime_curves(0xFF01) and=20 > - arbitrary_explicit_char2_curves(0xFF02). > + support for a class of explicitly defined curves or = signature-only curves are not allowed here (they are > + only permissible in the ClientHello extension); this = applies to Ed25519(TBD3), Ed448(TBD4), > + arbitrary_explicit_prime_curves(0xFF01) and = arbitrary_explicit_char2_curves(0xFF02). >
struct { > ECParameters curve_params; > @@ -488,20 +488,27 @@ > A hash of the params, with = the signature appropriate to that hash applied. =20 > The private key corresponding to the certified public key = in the server's Certificate message is used=20 > for signing.
- enum { ecdsa } SignatureAlgorithm; > + enum { ecdsa(3), eddsa(TBD5) } SignatureAlgorithm; > select (SignatureAlgorithm) { > case ecdsa: > digitally-signed struct { > opaque sha_hash[sha_size]; > }; > + case eddsa: > + digitally-signed struct { > + opaque rawdata[rawdata_size]; > + }; > } Signature; > ServerKeyExchange.signed_params.sha_hash > SHA(ClientHello.random + ServerHello.random + > ServerKeyExchange.params); > + ServerKeyExchange.signed_params.rawdata > + ClientHello.random + ServerHello.random + > + ServerKeyExchange.params; > ]]>
 > NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key = exchange algorithm and "anonymous" for ECDH_anon. =20 > - These cases are defined in TLS. SignatureAlgorithm is = "ecdsa" for ECDHE_ECDSA. ECDSA signatures are=20 > - generated and verified as described in , and SHA in the above template for=20 > + These cases are defined in TLS. SignatureAlgorithm is = "ecdsa" or "eddsa" for ECDHE_ECDSA. ECDSA signatures > + are generated and verified as described in , and SHA in the above template for > sha_hash accordingly may denote a hash algorithm other than = SHA-1. As per ANSI X9.62, an ECDSA signature=20 > consists of a pair of integers, r and s. The = digitally-signed element is encoded as an opaque vector=20 > <0..2^16-1>, the contents of which are the DER = encoding corresponding to the following ASN.1=20 > @@ -511,6 +518,9 @@ > s INTEGER > } > ]]>
 > + EdDSA signatures are generated and verified according to = . The digitally-signed > + element is encoded as an opaque vector<0..2^16-1>, = the contents of which is the octet string output of > + the EdDSA signing algorithm. > Actions of the sender: > The server selects elliptic curve domain parameters and an = ephemeral ECDH public key corresponding to=20 > these parameters according to the ECKAS-DH1 scheme from IEEE = 1363 . =20 > @@ -558,14 +568,14 @@ > certificates as described in . > NOTE: The client's Certificate message is capable of = carrying a chain of certificates. The=20 > restrictions mentioned in Table 4 apply only to the client's = certificate (first in the chain). > - > + > Client Authentication Method > Client Certificate Type > - ECDSA_signCertificate MUST contain an = ECDSA-capable public key and be signed with ECDSA. > + ECDSA_signCertificate MUST contain an = ECDSA-capable or EdDSA-capable public key. > ECDSA_fixed_ECDHCertificate MUST contain an = ECDH-capable public key on the same elliptic curve=20 > - as the server's long-term ECDH key. This certificate = MUST be signed with ECDSA. > - RSA_fixed_ECDHCertificate MUST contain an = ECDH-capable public key on the same elliptic curve=20 > - as the server's long-term ECDH key. This certificate = MUST be signed with RSA. > + as the server's long-term ECDH key. > + RSA_fixed_ECDHThe same as ECDSA_fixed_ECDH. The = codepoints meant different things, but due to > + changes in TLS 1.2, both mean the same thing now. > > Structure of this message: > Identical to the TLS client Certificate format. > @@ -599,9 +609,10 @@ > } ClientECDiffieHellmanPublic; > ]]>
 > Contains the client's ephemeral = ECDH public key as a byte string ECPoint.point,=20 > - which may represent an elliptic curve point in = uncompressed or compressed format. Here, the format=20 > - MUST conform to what the server has requested through a = Supported Point Formats Extension if this=20 > - extension was used, and MUST be uncompressed if this = extension was not used.
+ which may represent an elliptic curve point in = uncompressed or compressed format. Curves Ed25519 and > + Ed448 MUST NOT be used. Here, the format MUST conform to = what the server has requested through a Supported > + Point Formats Extension if this extension was used, and = MUST be uncompressed if this extension was not > + used.
struct { > select (KeyExchangeAlgorithm) { > case ec_diffie_hellman: ClientECDiffieHellmanPublic; > @@ -625,11 +636,14 @@ > key in the client's Certificate message. > Structure of this message: > The TLS CertificateVerify message and the underlying = Signature type are defined in the TLS base=20 > - specifications, and the latter is extended here in . For the ecdsa case, the signature=20 > - field in the CertificateVerify message contains an ECDSA = signature computed over handshake messages=20 > - exchanged so far, exactly similar to CertificateVerify with = other signing algorithms:
+ specifications, and the latter is extended here in . For the ecdsa and eddsa cases, the > + signature field in the CertificateVerify message contains = an ECDSA or EdDSA (respectively) signature computed > + over handshake messages exchanged so far, exactly similar = to CertificateVerify with other signing > + algorithms:
CertificateVerify.signature.sha_hash > SHA(handshake_messages); > + CertificateVerify.signature.rawdata > + handshake_messages; > ]]>
> ECDSA signatures are computed as described in , and SHA in the above=20 > template for sha_hash accordingly may denote a hash = algorithm other than SHA-1. As per ANSI X9.62, an=20 > @@ -641,6 +655,9 @@ > s INTEGER > } > ]]>
 > + EdDSA signatures are generated and verified according to = . The digitally-signed > + element is encoded as an opaque vector<0..2^16-1>, = the contents of which is the octet string output of > + the EdDSA signing algorithm. > Actions of the sender: > The client computes its signature over all handshake = messages sent or received starting at client hello=20 > and up to but not including this message. It uses the = private key corresponding to its certified public=20 > @@ -651,8 +668,12 @@ >
>
> X.509 certificates containing ECC public keys or signed = using ECDSA MUST comply with=20 > - or another RFC that replaces or = extends it. Clients SHOULD use the elliptic=20 > - curve domain parameters recommended in ANSI X9.62, FIPS = 186-4, and SEC 2 . > + or another RFC that replaces or = extends it. X.509 certificates containing ECC > + public keys or signed using EdDSA MUST comply with . Clients SHOULD use the > + elliptic curve domain parameters recommended in ANSI X9.62, = FIPS 186-4, and SEC 2 > + or in . > + EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use = the Ed25519 curve, and Ed448 and Ed448ph keys > + MUST use the Ed448 curve. Curves Curve25519, Curve448, = Ed25519 and Ed448 MUST NOT be used for ECDSA. >
>
> All ECDH calculations for the NIST curves (including = parameter and key generation as well as the shared=20 > @@ -675,11 +696,15 @@ > signed/verified is hashed, and the result run directly = through the ECDSA algorithm with no additional=20 > hashing. The default hash function is SHA-1 , and sha_size (see=20 > and ) = is 20. However, an alternative hash function, such=20 > - as one of the new SHA hash functions specified in FIPS = 180-2 , may be used instead. > + as one of the new SHA hash functions specified in FIPS = 180-2 , SHOULD be used instead. > + All EdDSA computations MUST be performed according to = or its succesors. Data > + to be signed/verified is run through the EdDSA algorithm = wih no hashing (EdDSA will internally run the data > + through the PH function). > RFC 4492 anticipated the standardization of a mechanism = for specifying the required hash function in the certificate, > perhaps in the parameters field of the subjectPublicKeyInfo. = Such standardization never took place, and as a result,=20 > - SHA-1 is used in TLS 1.1 and earlier. TLS 1.2 added a = SignatureAndHashAlgorithm parameter to the DigitallySigned struct,=20 > - thus allowing agility in choosing the signature hash. > + SHA-1 is used in TLS 1.1 and earlier (except for EdDSA, which = uses identity function). TLS 1.2 added a > + SignatureAndHashAlgorithm parameter to the DigitallySigned = struct, thus allowing agility in choosing the > + signature hash. EdDSA signatures MUST have HashAlgorithm of 0 = (None). > All RSA signatures must be generated and verified = according to block type 1. >
>
> @@ -688,14 +713,16 @@ > key, to the point that they may recover the entire private = key in a few requests, if that key is not really > ephemeral. > Curve25519 was designed in a way that the result of = Curve25519(x, d) will never reveal information about=20 > - d, provided it was chosen as prescribed, for any value of = x. > + d, provided it was chosen as prescribed, for any value of x = (the same holds true for Curve448). > Let's define legitimate values of x as the values that can = be obtained as x =3D Curve25519(G, d') for some=20 > d, and call the other values illegitimate. The definition = of the Curve25519 function shows that legitimate=20 > - values all share the following property: the high-order bit = of the last byte is not set. > + values all share the following property: the high-order bit = of the last byte is not set (for Ed448, any bit > + can be set). > Since there are some implementation of the Curve25519 = function that impose this restriction on their input=20 > and others that don't, implementations of Curve25519 in TLS = SHOULD reject public keys when the high-order bit=20 > of the last byte is set (in other words, when the value of = the leftmost byte is greater than 0x7F) in order=20 > to prevent implementation fingerprinting. > + Ed25519 and Ed448 internally do public key validation as = part of signature verification. > Other than this recommended check, implementations do not = need to ensure that the public keys they receive=20 > are legitimate: this is not necessary for security with = Curve25519. >
> @@ -770,8 +797,10 @@ > NOTE: IANA, please update the registries to reflect the new = policy name. > NOTE: RFC editor please delete these two notes prior to = publication. > IANA, please update these two registries to refer to this = document. > - IANA is requested to assign two values from the NamedCurve = registry with names Curve25519(TBD1) and > - Curve448(TBD2) with this document as reference. > + IANA is requested to assign four values from the NamedCurve = registry with names Curve25519(TBD1), > + Curve448(TBD2), Ed25519(TBD3) and Ed448(TBD4) with this = document as reference. > + IANA is requested to assign one value from = SignatureAlgorithm Registry with name eddsa(TBD5) with this > + document as reference. >
>
> Most of the text is this document is taken from , the predecessor of this=20 > @@ -785,6 +814,9 @@ >
>
> NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION > + Changes from draft-ietf-tls-rfc4492bis-03 to = draft-nir-tls-rfc4492bis-05: > + Add support for CFRG curves and signatures work. > + > Changes from draft-ietf-tls-rfc4492bis-01 to = draft-nir-tls-rfc4492bis-03: > Removed unused curves. > Removed unused point formats (all but uncompressed) > @@ -816,6 +848,26 @@ > > > > + > + > + EdDSA: Ed25519 and Ed448 > + > + > + > + > + > + > + > + > + > + Using EdDSA in the Internet X.509 Public Key = Infrastructure > + > + > + > + > + > + > + > > > The TLS Protocol Version 1.0 > --=20 > 2.6.1 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Oct 21 06:09:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22DC1A6FE3 for ; Wed, 21 Oct 2015 06:09:20 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd1_YVCKgdol for ; Wed, 21 Oct 2015 06:09:19 -0700 (PDT) Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id D35BC1A6FDF for ; Wed, 21 Oct 2015 06:09:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id 4C3D35A6FF2; Wed, 21 Oct 2015 16:09:01 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id ZSGGvlnTqKML; Wed, 21 Oct 2015 16:09:01 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id AC4095BC01F; Wed, 21 Oct 2015 16:09:17 +0300 (EEST) Date: Wed, 21 Oct 2015 16:09:16 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20151021130915.GA4130@LK-Perkele-V2.elisa-laajakaista.fi> References: <8FA6E91D-7322-4C73-8333-4FEA82517ED7@gmail.com> <1445362518-2482-1-git-send-email-ilari.liusvaara@welho.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [PATCH RFC4492bis] Add EdDSA signature support X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 13:09:21 -0000 On Wed, Oct 21, 2015 at 09:11:51AM +0300, Yoav Nir wrote: > LGTM. Can you push this to GitHub? > > > On 20 Oct 2015, at 8:35 PM, Ilari Liusvaara wrote: > > > > From: Ilari Liusvaara > > > > --- > > On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote: > >> Hi Ilari > >> > >>> - Is this document meant to also include the CFRG signatures > >>> work? The interfaces to functions are already known. > >> > >> That is the intention. A PR is welcome. > > > > Well, here's an attempt at a patch. Comments welcome. Okay, tlswg/rfc4492bis, PR #11. This might take some editorial improvements (I'm not that good at editorial stuff). -Ilari From nobody Wed Oct 21 09:13:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA401B29EF for ; Wed, 21 Oct 2015 09:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I94gQXQ2GBlF for ; Wed, 21 Oct 2015 09:13:10 -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 7DFBB1B29E2 for ; Wed, 21 Oct 2015 09:13:10 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C6C324EC69; Wed, 21 Oct 2015 16:13:09 +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 AFF014EC24; Wed, 21 Oct 2015 16:13:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445443989; bh=EMs1AKjjD93C6HhuYWhnpA4ZBGMb0S7tPMU1Lx3AZ8M=; l=1416; h=To:References:From:Date:In-Reply-To:From; b=IDuF3UBfcxP21PD/napB/wr0dLKB4G6TXWTuLqbPNk1FHlOmyE9EEf8PqBT+OWUdV Fiigz12PVcNLcarGoWiXoJSlboJeYICZgPoMaUMIAClnC/c7VtQZpxUDr9Qs06HlGO r0BnaKSlMEJvPKnoo2eiSFt58J5H98RHLrPxGMdQ= 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 75BBF2059; Wed, 21 Oct 2015 16:13:09 +0000 (GMT) To: "Zhouqian (Cathy)" , "tls@ietf.org" References: <56265EF6.2010908@akamai.com> From: Benjamin Kaduk Message-ID: <5627B995.6080803@akamai.com> Date: Wed, 21 Oct 2015 11:13:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 16:13:17 -0000 On 10/20/2015 10:02 PM, Zhouqian (Cathy) wrote: > [Cathy]Yes, both web authentication and overdue use cases could be > considered as captive portals. And I have already sent an email to the > capport mailing list for their comments. I mentioned capport because it sounds like they are trying to solve the same sort of problem that your solution is trying to solve, not because I think your proposal will be well-received there. I agree with Warren and Joel that directly intercepting TLS connections is not something I want to support. >> In any case, it is far from clear that HTTP-specific issues should be handled at >> the TLS layer -- TLS is a generic secure channel protocol used in many >> applications other than HTTPS. > [Cathy] As defined in [RFC 5246], "application protocol > An application protocol is a protocol that normally layers > directly on top of the transport layer (e.g., TCP/IP). Examples > include HTTP, TELNET, FTP, and SMTP.", > the TLS protocol could be used for HTTP applications. > I don't think that's quite the point I was trying to make. HTTPS is HTTP layered on top of TLS, yes, but in order for there to be a separation of layers, TLS should not include any data structures that are only useful for the HTTPS case. This document seems to add a field to TLS that is only used in the HTTPS use case, which seems like a layering violation to me. -Ben From nobody Wed Oct 21 10:06:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CBF1B2A95 for ; Wed, 21 Oct 2015 10:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9ZgYYGQuPaf for ; Wed, 21 Oct 2015 10:06:28 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC8F1B2A91 for ; Wed, 21 Oct 2015 10:06:24 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id EA5A8554096 for ; Wed, 21 Oct 2015 10:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=JhmCzQ8f17Fd4vhyflMU9CO/jF0=; b=LFvevCxZF185/ Q77hPm8bCmbh+0j5t0Zwf4FmX1TukZ03pNv2kXhSLuoVG7tBLzQwlp10+w5jXpnq sXLH+87zd9SZRpIRKWfkfHLz9PUVH0Y8nBNs9zY2w9s0hb78D+ettnlcQDOpzmex 0lUxdSY4IPAN27JCOD5nVs623cA+qM= Received: from spandex.local (63-140-97-73-radius.dynamic.acsalaska.net [63.140.97.73]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 75DAD55407D for ; Wed, 21 Oct 2015 10:06:19 -0700 (PDT) Message-ID: <5627C608.30401@nomountain.net> Date: Wed, 21 Oct 2015 09:06:16 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <56265EF6.2010908@akamai.com> <5627B995.6080803@akamai.com> In-Reply-To: <5627B995.6080803@akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 17:06:35 -0000 On 10/21/15 8:13 AM, Benjamin Kaduk wrote: > I don't think that's quite the point I was trying to make. HTTPS is > HTTP layered on top of TLS, yes, but in order for there to be a > separation of layers, TLS should not include any data structures that > are only useful for the HTTPS case. This document seems to add a field > to TLS that is only used in the HTTPS use case, which seems like a > layering violation to me. In fairness you can express all sorts of endpoint addresses as URLs, not just http. That said I agree that this is not an attractive proposal - the performance improvement over existing redirect models is marginal, there may be some unpleasant middlebox interactions, and it would require API changes. The cost/benefit tradeoff isn't favorable, on balance. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.net "Software longa, hardware brevis." From nobody Wed Oct 21 10:33:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C8B1A92FB for ; Wed, 21 Oct 2015 10:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2ryBtK-6wZp for ; Wed, 21 Oct 2015 10:33:39 -0700 (PDT) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) (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 AEB651A92F1 for ; Wed, 21 Oct 2015 10:33:39 -0700 (PDT) Received: by ykba4 with SMTP id a4so50781846ykb.3 for ; Wed, 21 Oct 2015 10:33:39 -0700 (PDT) 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-type; bh=AtDB3rdZMnBOBsS0pbi3Qa6mXchcIEngRJxXCUkdR5Y=; b=b//9l57x5OcWFjiqguy5qRjc8JWEdp1Ra9J9SO80S5lXBVVbfrtdocSXWOWJzw/h+v 5qgZ8zwYJoKkOrcP/Nc40CcqnlE35Ax/jkJIEYD3HO8KnJISpCVF2mc8M8vFfQ8lIGSe qhMYjdu0ICuEmvX048Ev70bicLz4lgwwb04Httl1fg28BErt/6cc1ilkLULisgDtPO+b 8QDM87LSu03jJO7MOyW5yQe4A3boGtRCvAUIu7YwLBfXlgNPZnjMP8bcCN3kOCG41oVq jyIlKkFuWwxWrp7c6gZ8s854ATe7l6B93D0RV6G3mcQMlRkp5nVV3UYSyDI3KJfArq8z lX6g== X-Gm-Message-State: ALoCoQkhis6fDTRK9sp2sOL7T4lB7GDLih6LWZ+EG/WKIGysV2cdTWHnd8UJ5aB1x6fwF86+o4mo X-Received: by 10.13.216.141 with SMTP id a135mr7600009ywe.12.1445448819028; Wed, 21 Oct 2015 10:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 10:32:59 -0700 (PDT) From: Eric Rescorla Date: Wed, 21 Oct 2015 10:32:59 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e488a665b340522a0c74b Archived-At: Subject: [TLS] HelloRetryRequest and stateless reject X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 17:33:42 -0000 --001a114e488a665b340522a0c74b Content-Type: text/plain; charset=UTF-8 Folks, Several of the remaining TLS 1.3 issues have to do with the ClientHello/HelloRetryRequest interaction. To recap, if the ClientHello does not contain a KeyShare with an acceptable group, the server sends a HelloRetryRequest indicating the correct group, and the client sends a ClientHello with the correct group: Client Server ClientHello + KeyShare --------> <-------- HelloRetryRequest ClientHello + KeyShare --------> ServerHello + KeyShare ... DTLS has a very similar mechanism where the server provides a HelloVerifyRequest containing a cookie in order to force the client to provide proof of routabilty at its claimed address. The client re-sends the ClientHello with the cookie and the handshake restarts. It seems natural to try to merge these mechanisms, but this raises the question of whether the handshake hashes should continue through the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104). The tension here is that you want to be able to have a stateless rejection (to avoid DoS in the DTLS scenario) but having things makes it much harder to analyze the handshake's resistance to downgrade attacks. Recently, Karthik, Martin Thomson, and I were talking and I think we've come to a good resolution. The basic observation is that it's possible to continue the handshake hash through the rejection exchange while still being stateless. We are aware of two main techniques here: - The server offloads its handshake hash state into the cookie it provides in the HelloRetryRequest (we'll need the cookie here in any case to support the DTLS case. The cookie obviously needs to be cryptographically protected, but that's what you're supposed to do for DTLS anyway (see: https://tools.ietf.org/html/rfc6347#section-4.2.1) - The server reconstructs the original ClientHello and HelloRetryRequest based on the re-sent ClientHello. This is possible because there are very strict rules about re-sent ClientHello construction (namely: send the same ClientHello except just add a KeyShareEntry for the indicated group). The cookie should also allow the server to double-check this (and will also need to indicate the reason for rejection). Because the handshake hash is continued through the entire handshake, it's much easier to analyze the downgrade properties. Moreover, servers which don't need stateless reject (because there is some other connection construct as with TLS over TCP or DTLS with ICE) don't need either of these techniques. They can just continue the handshake hash in the usual way. This seems like it fulfills both imperatives, at the primary cost of some additional complexity on servers who really care about statelesness (the client is indifferent to the server's implementation strategy). If this sounds good to people, I'll work up a PR for this, but really all it is is saying that you don't reset the hash and then a non-normative appendix describing stateless implementation techniques. Thoughts? Does anyone see anything wrong with this? -Ekr --001a114e488a665b340522a0c74b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

Several of the = remaining TLS 1.3 issues have to do with the
ClientHello/HelloRetryRequest interaction. To recap, if the
ClientHello does not contain a KeyShare with a= n acceptable group, the
server sends a= HelloRetryRequest indicating the correct group,
and the client sends a ClientHello with the correct group:
=

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server
=C2=A0=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ KeyShare =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-------- =C2=A0= =C2=A0 =C2=A0 HelloRetryRequest
=C2= =A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0ClientHello
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0+ KeyShare =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-------->
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ServerHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 + KeySha= re
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.= ..


DTLS has a very similar me= chanism where the server provides a
He= lloVerifyRequest containing a cookie in order to force the client to
<= div style=3D"font-size:12.8px">provide proof of routabilty at its claimed a= ddress. The client
re-sends the Client= Hello with the cookie and the handshake restarts.

It seems natural to t= ry to merge these mechanisms, but this raises
the question of whether the handshake hashes should continue throug= h
The tension here is that you want to be able to have a=C2=A0stateless
rejection (to = avoid DoS in the DTLS scenario) but having things
makes it much harder to analyze the handshake's resistance = to
downgrade attacks.

Recently, K= arthik, Martin Thomson, and I were talking and I think we've
come to a good resolution. The basic observation= is that it's possible
to continue= the handshake hash through the rejection exchange while
still being=C2=A0stateless. We a= re aware of two main techniques here:
=
- The server offloads its handsha= ke hash=C2=A0state=C2=A0into the cookie
=C2=A0 it provides in the HelloRetryRequest (we&#= 39;ll need the cookie here
=C2=A0 in a= ny case to support the DTLS case. The cookie obviously needs
=C2=A0 to be cryptographically protected, but that&#= 39;s what you're supposed
=C2=A0 t= o do for DTLS anyway

- The se= rver reconstructs the original ClientHello and HelloRetryRequest
=C2=A0 based on the re-sent ClientHello. This is= possible because there are
=C2=A0 ver= y strict rules about re-sent ClientHello construction
=C2=A0 (namely: send the same ClientHello except just add a= KeyShareEntry
=C2=A0 for the indicate= d group). The cookie should also allow the server
=C2=A0 to double-check this (and will also need to indicate the= reason
=C2=A0 for rejection).

Bec= ause the handshake hash is continued through the entire handshake,
it's much easier to analyze the downgrade = properties. Moreover,
servers which do= n't need=C2=A0stateless=C2=A0reject (because th= ere is some
other connection construct= as with TLS over TCP or DTLS with
ICE= ) don't need either of these techniques. They can just continue
the handshake hash in the usual way.
This= seems like it fulfills both imperatives, at the primary cost of
some additional complexity on servers who really= care about
statelesness (the client i= s indifferent to the server's implementation
strategy).

If this sounds good to people, I'll work up a= PR for this, but
really all it is is = saying that you don't reset the hash and
then a non-normative appendix describing=C2=A0state= less=C2=A0implementation
techni= ques.

Thoughts? Does anyone see anything wrong with this?
-Ekr
--001a114e488a665b340522a0c74b-- From nobody Wed Oct 21 11:02:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AE41B2BFE for ; Wed, 21 Oct 2015 11:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 vAEhFmRaGLVH for ; Wed, 21 Oct 2015 11:02:25 -0700 (PDT) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) (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 64B2B1B2BFC for ; Wed, 21 Oct 2015 11:02:25 -0700 (PDT) Received: by ykba4 with SMTP id a4so51642563ykb.3 for ; Wed, 21 Oct 2015 11:02:24 -0700 (PDT) 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-type; bh=305yaKp/MT9k5lp3cj9HlbealXfgsrMNo9E3t6FF9l8=; b=VamtqwRCHjeasg0whohxYW291f+j5lg8HYR3Gltcyes90rCh6kiOwlp5bTlEwhOHqK 9XLZJ0EzhxiG0pS5tA9aJwf60YiPVn6ab6G4IuZEzgdfqWDZYeRP9mgF2JzB9GaG+Hw+ /Hf/sZdXCb5E9XqH0nqaamf5eshFi5Vm5eRgHK8KCnLpF5Oi9oDC+Me9/MnkHRDhNF8f aIEKfbDJeAovQlCwXdDdy8ENk0tUAiMuel31NUqx6CMFHYwLleYvMaGt23th8gKRwyLb /+OO5BBV/i0Vk/einRQpS4OHac83s4tFo+h5h+EA4jeBl7SX/A24VXkTj1iLJj7USC+l ztjA== X-Gm-Message-State: ALoCoQmNsDVYEFSR7fDJRE7l9tZxXZQuqali/uFUep3XDtJY/v89Y78hRwsbIsDZ123gOWRTkaeT X-Received: by 10.13.216.141 with SMTP id a135mr7709974ywe.12.1445450544752; Wed, 21 Oct 2015 11:02:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 11:01:45 -0700 (PDT) From: Eric Rescorla Date: Wed, 21 Oct 2015 11:01:45 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e488a42e0dc0522a12ebd Archived-At: Subject: [TLS] Proposal for client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 18:02:27 -0000 --001a114e488a42e0dc0522a12ebd Content-Type: text/plain; charset=UTF-8 Folks, At the Seattle interim, we decided to have a small ad hoc design team go and figure out how to harmonize the various forms of client authentication. I've posted a WIP version of the output of that work at: https://github.com/tlswg/tls13-spec/pull/316 The basic observation (due to Karthik) is that TLS already implicitly adopts the SIGMA framework for authentication (specifically, SIGMA-I). To see this, consider the 1-RTT key exchange: ClientHello + ClientKeyShare --------> ServerHello ServerKeyShare* {EncryptedExtensions} {ServerConfiguration*} {Certificate*} <-\ {CertificateRequest*} > Signature {CertificateVerify*} <-/ <-------- {Finished} <- MAC Sign. /-> {Certificate*} \-> {CertificateVerify*} MAC -> {Finished} --------> [Application Data] <-------> [Application Data] Each signature covers the entire handshake up to that point, including both identities, and the MAC is derived from g^xy (and in the case of 0-RTT, g^xs as well). So, what this draft does is adopt the following three messages. Certificate CertificateVerify Finished As the "TLS Authentication Block" and send them whenever we want to do authentication. [Note that we may eventually merge messages here, but that doesn't affect the logic.] In every case, the input to the block would be: - A session context (SC) which is (generally) the handshake transcript up to this point. - A base key to compute the finished key from (the finished keys are directional, so the client and server keys are different). And then the signature covers: SC + Certificate And the MAC covers SC + Certificate + CertificateVerify The inputs are: Mode Handshake Context Base Key ---- ----------------- -------- 0-RTT ClientHello + ServerConfiguration xSS + Server Certificate + CertificateRequest 1-RTT (Server) ClientHello ... ServerConfiguration master_secret 1-RTT (Client) ClientHello ... ServerFinished master_secret Post-Handshake ClientHello ... ClientFinished + master_secret CertificateRequest If we just move CertificateRequest to before Certificate, than this effectively is what we already do for the TLS 1.3 handshake. The proposal, then, is to adopt the following unified flow diagram. ClientHello + ClientKeyShare ^ + EarlyDataIndication O-RTT | (Certificate*) mode | (CertificateVerify* v (Finished) // Note: new message. (Application Data*) --------> ServerHello ServerKeyShare* {EncryptedExtensions} {CertificateRequest*} {ServerConfiguration*} {Certificate*} ^ {CertificateVerify*} | Server Authentication <-------- {Finished} v 1-RTT ^ {Certificate*} Client | {CertificateVerify*} Auth | {Finished} --------> v [Application Data] <-------> [Application Data] <-------- [CertificateRequest] ^ [Certificate] | Post-Handshake [CertificateVerify] | Authentication [Finished] --------> v Note 1: I think the best plan here is to allow the server to send a CertificateRequest in 1-RTT even if the client sent a certificate in its 0-RTT first flight. This is superficially more complicated but actually simpler since it lets us regard there as being just a 1-RTT handshake plus some stuff that the client sends in 0-RTT. Obviously, this leaves the possibility that that server can ask the client for a certificate in its first flight even with the same CertificateRequest that the client is (implicitly) responding to in 0-RTT, and while this is silly there's nothing stopping the server from doing this in post-handshake auth either. Note 2: This PR also modifies the master_secret derivation so that it is computed right after ServerCertificateVerify (i.e., at the same time as we compute the server Finished message) because this allows the use of the same traffic keys regardless of whether client auth is involved. In addition, it doesn't include the client's 0-RTT client auth messages in the session hash. This isolates them more completely from the rest of the handshake, thus leading to a more unified flow. If this has a security impact then as noted elsewhere, it probably threatens post-handshake client auth entirely. The PR has more detail (and again, it's a WIP). I expect we'll need to discuss in Yokohama, but I wanted to get people's feedback now. -Ekr P.S. Thanks to Hugo, Bjoern, Karthikeyan, mt, Adam, AGL, DKG, and Hoeteck for their time working through this. --001a114e488a42e0dc0522a12ebd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdj5Gb2xrcyw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkF0IHRo ZSBTZWF0dGxlIGludGVyaW0sIHdlIGRlY2lkZWQgdG8gaGF2ZSBhIHNtYWxsIGFkIGhvYyBkZXNp Z24gdGVhbTwvZGl2PjxkaXY+Z28gYW5kIGZpZ3VyZSBvdXQgaG93IHRvIGhhcm1vbml6ZSB0aGUg dmFyaW91cyBmb3JtcyBvZiBjbGllbnQ8L2Rpdj48ZGl2PmF1dGhlbnRpY2F0aW9uLiBJJiMzOTt2 ZSBwb3N0ZWQgYSBXSVAgdmVyc2lvbiBvZiB0aGUgb3V0cHV0IG9mIHRoYXQgd29yazwvZGl2Pjxk aXY+YXQ6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj7CoCDCoCDCoCDCoCA8YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9wdWxsLzMxNiI+aHR0cHM6Ly9naXRodWIu Y29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC8zMTY8L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5UaGUgYmFzaWMgb2JzZXJ2YXRpb24gKGR1ZSB0byBLYXJ0aGlrKSBp cyB0aGF0IFRMUyBhbHJlYWR5IGltcGxpY2l0bHk8L2Rpdj48ZGl2PmFkb3B0cyB0aGUgU0lHTUEg ZnJhbWV3b3JrIGZvciBhdXRoZW50aWNhdGlvbiAoc3BlY2lmaWNhbGx5LCBTSUdNQS1JKS48L2Rp dj48ZGl2PlRvIHNlZSB0aGlzLCBjb25zaWRlciB0aGUgMS1SVFQga2V5IGV4Y2hhbmdlOjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqBDbGllbnRIZWxsbzwvZGl2Pjxk aXY+wqAgwqAgwqAgwqAgwqAgwqAgwqArIENsaWVudEtleVNoYXJlIMKgIMKgIMKgIMKgLS0tLS0t LS0mZ3Q7PC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFNlcnZlckhl bGxvPC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFNlcnZlcktleVNoYXJlKjwv ZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB7RW5jcnlwdGVkRXh0ZW5zaW9uc308L2Rpdj48ZGl2 PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHtTZXJ2ZXJDb25maWd1cmF0aW9uKn08L2Rpdj48ZGl2PsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHtDZXJ0aWZpY2F0ZSp9ICZsdDstXDwvZGl2PjxkaXY+wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB7Q2VydGlmaWNhdGVSZXF1ZXN0Kn0gwqAgwqAmZ3Q7IFNpZ25hdHVyZTwvZGl2 PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAge0NlcnRpZmljYXRlVmVyaWZ5Kn0gJmx0Oy0vPC9kaXY+ PGRpdj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCZsdDstLS0tLS0tLSDCoCDCoCDCoCDCoCDCoCDCoCDCoHtGaW5pc2hlZH0gJmx0Oy0gwqAg TUFDPC9kaXY+PGRpdj5TaWduLiDCoC8tJmd0OyB7Q2VydGlmaWNhdGUqfTwvZGl2PjxkaXY+wqAg wqAgwqAgwqBcLSZndDsge0NlcnRpZmljYXRlVmVyaWZ5Kn08L2Rpdj48ZGl2Pk1BQyDCoCDCoCAt Jmd0OyB7RmluaXNoZWR9IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLS0tLS0tLS0mZ3Q7PC9kaXY+ PGRpdj7CoCDCoCDCoCDCoCDCoCDCoFtBcHBsaWNhdGlvbiBEYXRhXSDCoCDCoCDCoCDCoCZsdDst LS0tLS0tJmd0OyDCoCDCoCDCoFtBcHBsaWNhdGlvbiBEYXRhXTwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+RWFjaCBzaWduYXR1cmUgY292ZXJzIHRoZSBlbnRpcmUgaGFu ZHNoYWtlIHVwIHRvIHRoYXQgcG9pbnQsIGluY2x1ZGluZzwvZGl2PjxkaXY+Ym90aCBpZGVudGl0 aWVzLCBhbmQgdGhlIE1BQyBpcyBkZXJpdmVkIGZyb20gZ154eSAoYW5kIGluIHRoZSBjYXNlIG9m PC9kaXY+PGRpdj4wLVJUVCwgZ154cyBhcyB3ZWxsKS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlNvLCB3aGF0IHRoaXMgZHJhZnQgZG9lcyBpcyBhZG9wdCB0aGUgZm9s bG93aW5nIHRocmVlIG1lc3NhZ2VzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+wqAgwqBDZXJ0 aWZpY2F0ZTwvZGl2PjxkaXY+wqAgwqBDZXJ0aWZpY2F0ZVZlcmlmeTwvZGl2PjxkaXY+wqAgwqBG aW5pc2hlZDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QXMgdGhlICZxdW90O1RMUyBBdXRoZW50 aWNhdGlvbiBCbG9jayZxdW90OyBhbmQgc2VuZCB0aGVtIHdoZW5ldmVyIHdlIHdhbnQgdG8gZG88 L2Rpdj48ZGl2PmF1dGhlbnRpY2F0aW9uLiBbTm90ZSB0aGF0IHdlIG1heSBldmVudHVhbGx5IG1l cmdlIG1lc3NhZ2VzIGhlcmUsIGJ1dDwvZGl2PjxkaXY+dGhhdCBkb2VzbiYjMzk7dCBhZmZlY3Qg dGhlIGxvZ2ljLl08L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkluIGV2ZXJ5IGNhc2UsIHRoZSBp bnB1dCB0byB0aGUgYmxvY2sgd291bGQgYmU6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj7CoCDC oC0gQSBzZXNzaW9uIGNvbnRleHQgKFNDKSB3aGljaCBpcyAoZ2VuZXJhbGx5KSB0aGUgaGFuZHNo YWtlPC9kaXY+PGRpdj7CoCDCoCDCoHRyYW5zY3JpcHQgdXAgdG8gdGhpcyBwb2ludC48L2Rpdj48 ZGl2PsKgIMKgLSBBIGJhc2Uga2V5IHRvIGNvbXB1dGUgdGhlIGZpbmlzaGVkIGtleSBmcm9tICh0 aGUgZmluaXNoZWQ8L2Rpdj48ZGl2PsKgIMKgIMKga2V5cyBhcmUgZGlyZWN0aW9uYWwsIHNvIHRo ZSBjbGllbnQgYW5kIHNlcnZlciBrZXlzIGFyZTwvZGl2PjxkaXY+wqAgwqAgwqBkaWZmZXJlbnQp LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QW5kIHRoZW4gdGhlIHNpZ25hdHVyZSBjb3ZlcnM6 IFNDICsgQ2VydGlmaWNhdGU8L2Rpdj48ZGl2PkFuZCB0aGUgTUFDIGNvdmVycyBTQyArIENlcnRp ZmljYXRlICsgQ2VydGlmaWNhdGVWZXJpZnk8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBp bnB1dHMgYXJlOjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TW9kZSDCoCDCoCDCoCDCoCDCoCDC oCBIYW5kc2hha2UgQ29udGV4dCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEJh c2UgS2V5PC9kaXY+PGRpdj4tLS0tIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tLS0tLS0tLS0tLS0t IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLS0tLS0tLS08L2Rpdj48ZGl2PjAt UlRUIMKgIMKgIMKgIMKgIMKgIMKgQ2xpZW50SGVsbG8gKyBTZXJ2ZXJDb25maWd1cmF0aW9uIMKg IMKgIMKgIMKgeFNTPC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCsgU2VydmVyIENlcnRpZmljYXRlPC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCsgQ2VydGlmaWNhdGVSZXF1ZXN0PC9kaXY+PGRp dj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgPC9kaXY+PGRpdj4x LVJUVCAoU2VydmVyKSDCoCBDbGllbnRIZWxsbyAuLi4gU2VydmVyQ29uZmlndXJhdGlvbiDCoCDC oCDCoG1hc3Rlcl9zZWNyZXQ8L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPC9k aXY+PGRpdj4xLVJUVCAoQ2xpZW50KSDCoCBDbGllbnRIZWxsbyAuLi4gU2VydmVyRmluaXNoZWQg wqAgwqAgwqAgwqAgwqAgbWFzdGVyX3NlY3JldDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+UG9z dC1IYW5kc2hha2UgwqAgQ2xpZW50SGVsbG8gLi4uIENsaWVudEZpbmlzaGVkICsgwqAgwqAgwqAg wqAgbWFzdGVyX3NlY3JldDwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBDZXJ0 aWZpY2F0ZVJlcXVlc3Q8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pklm IHdlIGp1c3QgbW92ZSBDZXJ0aWZpY2F0ZVJlcXVlc3QgdG8gYmVmb3JlIENlcnRpZmljYXRlLCB0 aGFuIHRoaXM8L2Rpdj48ZGl2PmVmZmVjdGl2ZWx5IGlzIHdoYXQgd2UgYWxyZWFkeSBkbyBmb3Ig dGhlIFRMUyAxLjMgaGFuZHNoYWtlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+VGhlIHByb3Bvc2FsLCB0aGVuLCBpcyB0byBhZG9wdCB0aGUgZm9sbG93aW5nIHVuaWZp ZWQgZmxvdyBkaWFncmFtLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAg wqAgQ2xpZW50SGVsbG88L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgIMKgIMKgICsgQ2xpZW50S2V5 U2hhcmU8L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgXiDCoCDCoCsgRWFybHlEYXRhSW5kaWNhdGlv bjwvZGl2PjxkaXY+wqAgTy1SVFQgwqB8IMKgKENlcnRpZmljYXRlKik8L2Rpdj48ZGl2PsKgIG1v ZGUgwqAgfCDCoChDZXJ0aWZpY2F0ZVZlcmlmeSo8L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgdiDC oChGaW5pc2hlZCkgwqAvLyBOb3RlOiBuZXcgbWVzc2FnZS48L2Rpdj48ZGl2PsKgIMKgIMKgIMKg IMKgIMKgIChBcHBsaWNhdGlvbiBEYXRhKikgwqAgwqAgwqAgLS0tLS0tLS0mZ3Q7PC9kaXY+PGRp dj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZXJ2ZXJIZWxsbzwvZGl2PjxkaXY+ wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU2VydmVyS2V5U2hhcmUqPC9kaXY+PGRpdj7CoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB7RW5jcnlwdGVkRXh0ZW5zaW9uc308L2Rpdj48ZGl2PsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHtDZXJ0aWZpY2F0ZVJlcXVlc3QqfTwvZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB7 U2VydmVyQ29uZmlndXJhdGlvbip9wqA8L2Rpdj48ZGl2PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKge0NlcnRpZmljYXRlKn0gwqBePC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHtD ZXJ0aWZpY2F0ZVZlcmlmeSp9IMKgfCBTZXJ2ZXIgQXV0aGVudGljYXRpb248L2Rpdj48ZGl2PsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZs dDstLS0tLS0tLSDCoCDCoCDCoCDCoCDCoCDCoCDCoHtGaW5pc2hlZH0gwqB2PC9kaXY+PGRpdj7C oDEtUlRUIMKgIF4gwqB7Q2VydGlmaWNhdGUqfTwvZGl2PjxkaXY+wqBDbGllbnQgwqB8IMKge0Nl cnRpZmljYXRlVmVyaWZ5Kn08L2Rpdj48ZGl2PsKgQXV0aCDCoCDCoHwgwqB7RmluaXNoZWR9IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgLS0tLS0tLS0mZ3Q7PC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDC oHYgwqBbQXBwbGljYXRpb24gRGF0YV0gwqAgwqAgwqAgwqAmbHQ7LS0tLS0tLSZndDsgwqAgwqAg wqBbQXBwbGljYXRpb24gRGF0YV08L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7LS0tLS0tLS0gwqAgwqBb Q2VydGlmaWNhdGVSZXF1ZXN0XSDCoCBePC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoCDCoCBbQ2Vy dGlmaWNhdGVdIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgUG9zdC1IYW5kc2hha2U8L2Rpdj48ZGl2PsKgIMKg IMKgIMKgIMKgIMKgIFtDZXJ0aWZpY2F0ZVZlcmlmeV0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCBBdXRoZW50aWNhdGlvbjwv ZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqAgW0ZpbmlzaGVkXSDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoC0tLS0tLS0tJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB2 PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ob3RlIDE6IEkgdGhpbmsg dGhlIGJlc3QgcGxhbiBoZXJlIGlzIHRvIGFsbG93IHRoZSBzZXJ2ZXIgdG8gc2VuZCBhPC9kaXY+ PGRpdj5DZXJ0aWZpY2F0ZVJlcXVlc3QgaW4gMS1SVFQgZXZlbiBpZiB0aGUgY2xpZW50IHNlbnQg YSBjZXJ0aWZpY2F0ZSBpbjwvZGl2PjxkaXY+aXRzIDAtUlRUIGZpcnN0IGZsaWdodC4gVGhpcyBp cyBzdXBlcmZpY2lhbGx5IG1vcmUgY29tcGxpY2F0ZWQgYnV0PC9kaXY+PGRpdj5hY3R1YWxseSBz aW1wbGVyIHNpbmNlIGl0IGxldHMgdXMgcmVnYXJkIHRoZXJlIGFzIGJlaW5nIGp1c3QgYSAxLVJU VDwvZGl2PjxkaXY+aGFuZHNoYWtlIHBsdXMgc29tZSBzdHVmZiB0aGF0IHRoZSBjbGllbnQgc2Vu ZHMgaW4gMC1SVFQuwqAgT2J2aW91c2x5LDwvZGl2PjxkaXY+dGhpcyBsZWF2ZXMgdGhlIHBvc3Np YmlsaXR5IHRoYXQgdGhhdCBzZXJ2ZXIgY2FuIGFzayB0aGUgY2xpZW50IGZvciBhPC9kaXY+PGRp dj5jZXJ0aWZpY2F0ZSBpbiBpdHMgZmlyc3QgZmxpZ2h0IGV2ZW4gd2l0aCB0aGUgc2FtZSBDZXJ0 aWZpY2F0ZVJlcXVlc3Q8L2Rpdj48ZGl2PnRoYXQgdGhlIGNsaWVudCBpcyAoaW1wbGljaXRseSkg cmVzcG9uZGluZyB0byBpbiAwLVJUVCwgYW5kIHdoaWxlIHRoaXM8L2Rpdj48ZGl2PmlzIHNpbGx5 IHRoZXJlJiMzOTtzIG5vdGhpbmcgc3RvcHBpbmcgdGhlIHNlcnZlciBmcm9tIGRvaW5nIHRoaXMg aW48L2Rpdj48ZGl2PnBvc3QtaGFuZHNoYWtlIGF1dGggZWl0aGVyLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+Tm90ZSAyOiBUaGlzIFBSIGFsc28gbW9kaWZpZXMgdGhlIG1hc3Rlcl9zZWNyZXQg ZGVyaXZhdGlvbiBzbyB0aGF0IGl0PC9kaXY+PGRpdj5pcyBjb21wdXRlZCByaWdodCBhZnRlciBT ZXJ2ZXJDZXJ0aWZpY2F0ZVZlcmlmeSAoaS5lLiwgYXQgdGhlIHNhbWU8L2Rpdj48ZGl2PnRpbWUg YXMgd2UgY29tcHV0ZSB0aGUgc2VydmVyIEZpbmlzaGVkIG1lc3NhZ2UpIGJlY2F1c2UgdGhpcyBh bGxvd3M8L2Rpdj48ZGl2PnRoZSB1c2Ugb2YgdGhlIHNhbWUgdHJhZmZpYyBrZXlzIHJlZ2FyZGxl c3Mgb2Ygd2hldGhlciBjbGllbnQgYXV0aCBpczwvZGl2PjxkaXY+aW52b2x2ZWQuIEluIGFkZGl0 aW9uLCBpdCBkb2VzbiYjMzk7dCBpbmNsdWRlIHRoZSBjbGllbnQmIzM5O3MgMC1SVFQgY2xpZW50 PC9kaXY+PGRpdj5hdXRoIG1lc3NhZ2VzIGluIHRoZSBzZXNzaW9uIGhhc2guIFRoaXMgaXNvbGF0 ZXMgdGhlbSBtb3JlIGNvbXBsZXRlbHk8L2Rpdj48ZGl2PmZyb20gdGhlIHJlc3Qgb2YgdGhlIGhh bmRzaGFrZSwgdGh1cyBsZWFkaW5nIHRvIGEgbW9yZSB1bmlmaWVkPC9kaXY+PGRpdj5mbG93LiBJ ZiB0aGlzIGhhcyBhIHNlY3VyaXR5IGltcGFjdCB0aGVuIGFzIG5vdGVkIGVsc2V3aGVyZSwgaXQ8 L2Rpdj48ZGl2PnByb2JhYmx5IHRocmVhdGVucyBwb3N0LWhhbmRzaGFrZSBjbGllbnQgYXV0aCBl bnRpcmVseS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBQUiBoYXMgbW9yZSBkZXRhaWwg KGFuZCBhZ2FpbiwgaXQmIzM5O3MgYSBXSVApLiBJIGV4cGVjdCB3ZSYjMzk7bGwgbmVlZDwvZGl2 PjxkaXY+dG8gZGlzY3VzcyBpbiBZb2tvaGFtYSwgYnV0IEkgd2FudGVkIHRvIGdldCBwZW9wbGUm IzM5O3MgZmVlZGJhY2sgbm93LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LUVrcjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+UC5TLiBUaGFua3MgdG8gSHVnbywgQmpvZXJuLCBLYXJ0aGlrZXlh biwgbXQsIEFkYW0sIEFHTCwgREtHLCBhbmQgSG9ldGVjazwvZGl2PjxkaXY+Zm9yIHRoZWlyIHRp bWUgd29ya2luZyB0aHJvdWdoIHRoaXMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+DQo= --001a114e488a42e0dc0522a12ebd-- From nobody Wed Oct 21 11:03:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA181B2C0A for ; Wed, 21 Oct 2015 11:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKYS60c7L65i for ; Wed, 21 Oct 2015 11:03:23 -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 06F061B2C18 for ; Wed, 21 Oct 2015 11:03:21 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 734814E5C6; Wed, 21 Oct 2015 18:03:20 +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 589E84DB43; Wed, 21 Oct 2015 18:03:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445450600; bh=aEbzlAsRZVcfZ2BFP6iJ6WwF+XLGNQmEXdv1fNUMohY=; l=13215; h=From:To:CC:Date:References:In-Reply-To:From; b=wMtaSaIVQ6GsWPOv0suDvuF4JaS2aGB2yf8O6/BCXuek/55a2hhMLt3Xkjh+rTRjl t5cRe3ep7I8WLwMyrpIi87wFRfHK4ZP9Xrfo2EVItAl7s3UUG+DV4jTTLk/cPJ4BYv Gzp8CIwKxWtyuSyuiH13u5Vy5zT0sIjmeETgMEHY= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 3473A202A; Wed, 21 Oct 2015 18:03:20 +0000 (GMT) Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 21 Oct 2015 13:03:19 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Wed, 21 Oct 2015 13:03:19 -0500 From: "Short, Todd" To: "Kaduk, Ben" Thread-Topic: [TLS] New Version Notification for draft-zhou-tls-server-redirect-00.txt Thread-Index: AQHRDCrEEYZBCddcR0uZuUSq7i3tJA== Date: Wed, 21 Oct 2015 18:03:18 +0000 Message-ID: References: <56265EF6.2010908@akamai.com> <5627B995.6080803@akamai.com> In-Reply-To: <5627B995.6080803@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.114] Content-Type: multipart/alternative; boundary="_000_F0B6458F24214A2DB14849E08D3F3496akamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 18:03:25 -0000 --_000_F0B6458F24214A2DB14849E08D3F3496akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEJlbiBoZXJlLiBUaGlzIGlzIHZlcnkgbXVjaCBhcHBsaWNhdGlvbi1sYXll ciAoSFRUUFMpIGZ1bmN0aW9uYWxpdHkgYmVpbmcgcHVzaGVkIGRvd24gaW50byB0aGUgc2VjdXJp dHkgKFRMUykgbGF5ZXIuIEhUVFAoUykgYWxyZWFkeSBoYXMgYSBmdWxseSBmdW5jdGlvbmFsIHJl ZGlyZWN0IG1lY2hhbmlzbSwgd2h5IGRvZXMgdGhpcyBmdW5jdGlvbmFsaXR5IG5lZWQgdG8gYmUg cHVzaGVkIHRvIGEgbG93ZXIgbGF5ZXI/IEFsbCB0aGUgY2FzZXMgZGVzY3JpYmVkIGluIHRoZSBJ bnRyb2R1Y3Rpb24gY2FuIGJlIGhhbmRsZWQgYXQgbGF5ZXJzIGluZGVwZW5kZW50IG9mIFRMUw0K DQpJbiBzZWN0aW9uIDQ6IOKAnC4uLmFuZCBhZnRlciByZWNlaXZpbmcgdGhlIEdldCBwYWNrZXQs IHRoZSBjbGllbnQgcmVzcG9uZHMgd2l0aCB0aGXigKbigJ0gSSBiZWxpZXZlIHRoYXQg4oCcY2xp ZW504oCdIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIOKAnHNlcnZlcuKAnS4NCg0KU2VjdGlvbiDi gJw1LiBTZWN1cml0eSBDb25zaWRlcmF0aW9uc+KAnSBpcyBjb21wbGV0ZWx5IGJsYW5rLg0KDQpG cm9tIHRoZSBkZXNjcmlwdGlvbiBpdCBpcyBub3QgY2xlYXIgaG93IG11Y2ggb2YgdGhlIGhhbmRz aGFrZSBjb21wbGV0ZXMgYmVmb3JlIGhhbmRsaW5nIHRoZSBSZWRpcmVjdC4gSXQgaW1wbGllcyB0 aGF0IHRoZSBSZWRpcmVjdCBtYXkgYmUgYWN0ZWQgdXBvbiAo4oCcZmF1bHQgd2FybmluZyBwYWdl IikgYmVmb3JlIHRoZSBoYW5kc2hha2UgY29tcGxldGVzLCBhbmQgdGh1cyBpdCBpcyBub3Qgc2Vj dXJlLiBBIE1JVE0gY291bGQgZWFzaWx5IGluamVjdCB0aGUgUmVkaXJlY3QgcGFja2V0IHRoYXQg aW1wYWN0cyB0aGUgY2xpZW50LCBwcmV2ZW50aW5nIGFjY2Vzcy4NCg0KQnV0IHRoYXQgaXMg4oCc c29ydGHigJ0gdGhlIHBvaW50LCBhIGNhcHRpdmUgcG9ydGFsLCBhY3RpbmcgYXMgYSBNSVRNLCBu ZWVkcyB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIsIHBvdGVudGlhbGx5IGF0IGFueSB0aW1lLiBU aGlzIG1heSBiZSBnb2luZyBvZmYgb24gYSB0YW5nZW50LCBidXQgaWYgdGhlIGNhcHRpdmUgcG9y dGFsIGFjY2VwdGVkIGFuIEhUVFBTIGNvbm5lY3Rpb24gZGVzdGluZWQgZm9yIGFueXdoZXJlLCBh bmQgaWYgaXQgY291bGQgYW5ub3VuY2UgYmFjayB0byB0aGUgY2xpZW50IHRoYXQgSSBhbSB5b3Vy IGNhcHRpdmUgcG9ydGFsLCBhbmQgdGhlIGNsaWVudCBjb3VsZCB2ZXJpZnkgdGhhdCwgdGhlbiB0 aGVyZSB3b3VsZCBiZSBubyBuZWVkIGZvciBhIFRMUy1sZXZlbCByZWRpcmVjdC4gQSBicm93c2Vy IHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSB0aGlzIGJ5IHF1ZXJ5aW5nIGZvciB0aGUgcm91dGVy IChpLmUuIGNhcHRpdmUgcG9ydGFsKSBJUCBhZGRyZXNzL0ROUyBuYW1lLCBhbmQgY29tcGFyaW5n IHRoYXQgdG8gdGhlIHJlY2VpdmVkIFRMUyAgc2VydmVyIGNyZWRlbnRpYWxzLiBJZiB0aGV5IG1h dGNoLCB0aGUgY2xpZW50IHByb2dyYW0ga25vd3MgaXTigJlzIHRhbGtpbmcgdG8gYSBjYXB0aXZl IHBvcnRhbC4gSSBjb3VsZCBnbyBpbnRvIG1vcmUgZGV0YWlsLCBidXQgaXQgb3V0c2lkZSB0aGUg c2NvcGUgb2YgdGhpcyBkcmFmdC4NCg0KLS0NCi1Ub2RkIFNob3J0DQovLyB0c2hvcnRAYWthbWFp LmNvbTxtYWlsdG86dHNob3J0QGFrYW1haS5jb20+DQovLyAiT25lIGlmIGJ5IGxhbmQsIHR3byBp ZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4iDQoNCk9uIE9jdCAyMSwgMjAxNSwg YXQgMTI6MTMgUE0sIEJlbmphbWluIEthZHVrIDxia2FkdWtAYWthbWFpLmNvbTxtYWlsdG86Ymth ZHVrQGFrYW1haS5jb20+PiB3cm90ZToNCg0KT24gMTAvMjAvMjAxNSAxMDowMiBQTSwgWmhvdXFp YW4gKENhdGh5KSB3cm90ZToNCltDYXRoeV1ZZXMsIGJvdGggd2ViIGF1dGhlbnRpY2F0aW9uIGFu ZCBvdmVyZHVlIHVzZSBjYXNlcyBjb3VsZCBiZQ0KY29uc2lkZXJlZCBhcyBjYXB0aXZlIHBvcnRh bHMuIEFuZCBJIGhhdmUgYWxyZWFkeSBzZW50IGFuIGVtYWlsIHRvIHRoZQ0KY2FwcG9ydCBtYWls aW5nIGxpc3QgZm9yIHRoZWlyIGNvbW1lbnRzLg0KDQpJIG1lbnRpb25lZCBjYXBwb3J0IGJlY2F1 c2UgaXQgc291bmRzIGxpa2UgdGhleSBhcmUgdHJ5aW5nIHRvIHNvbHZlIHRoZQ0Kc2FtZSBzb3J0 IG9mIHByb2JsZW0gdGhhdCB5b3VyIHNvbHV0aW9uIGlzIHRyeWluZyB0byBzb2x2ZSwgbm90IGJl Y2F1c2UNCkkgdGhpbmsgeW91ciBwcm9wb3NhbCB3aWxsIGJlIHdlbGwtcmVjZWl2ZWQgdGhlcmUu ICBJIGFncmVlIHdpdGggV2FycmVuDQphbmQgSm9lbCB0aGF0IGRpcmVjdGx5IGludGVyY2VwdGlu ZyBUTFMgY29ubmVjdGlvbnMgaXMgbm90IHNvbWV0aGluZyBJDQp3YW50IHRvIHN1cHBvcnQuDQoN CkluIGFueSBjYXNlLCBpdCBpcyBmYXIgZnJvbSBjbGVhciB0aGF0IEhUVFAtc3BlY2lmaWMgaXNz dWVzIHNob3VsZCBiZSBoYW5kbGVkIGF0DQp0aGUgVExTIGxheWVyIC0tIFRMUyBpcyBhIGdlbmVy aWMgc2VjdXJlIGNoYW5uZWwgcHJvdG9jb2wgdXNlZCBpbiBtYW55DQphcHBsaWNhdGlvbnMgb3Ro ZXIgdGhhbiBIVFRQUy4NCltDYXRoeV0gQXMgZGVmaW5lZCBpbiBbUkZDIDUyNDZdLCAiYXBwbGlj YXRpb24gcHJvdG9jb2wNCiAgICAgQW4gYXBwbGljYXRpb24gcHJvdG9jb2wgaXMgYSBwcm90b2Nv bCB0aGF0IG5vcm1hbGx5IGxheWVycw0KICAgICBkaXJlY3RseSBvbiB0b3Agb2YgdGhlIHRyYW5z cG9ydCBsYXllciAoZS5nLiwgVENQL0lQKS4gIEV4YW1wbGVzDQogICAgIGluY2x1ZGUgSFRUUCwg VEVMTkVULCBGVFAsIGFuZCBTTVRQLiIsDQp0aGUgVExTIHByb3RvY29sIGNvdWxkIGJlIHVzZWQg Zm9yIEhUVFAgYXBwbGljYXRpb25zLg0KDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCdzIHF1aXRlIHRo ZSBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZS4gIEhUVFBTIGlzDQpIVFRQIGxheWVyZWQgb24g dG9wIG9mIFRMUywgeWVzLCBidXQgaW4gb3JkZXIgZm9yIHRoZXJlIHRvIGJlIGENCnNlcGFyYXRp b24gb2YgbGF5ZXJzLCBUTFMgc2hvdWxkIG5vdCBpbmNsdWRlIGFueSBkYXRhIHN0cnVjdHVyZXMg dGhhdA0KYXJlIG9ubHkgdXNlZnVsIGZvciB0aGUgSFRUUFMgY2FzZS4gIFRoaXMgZG9jdW1lbnQg c2VlbXMgdG8gYWRkIGEgZmllbGQNCnRvIFRMUyB0aGF0IGlzIG9ubHkgdXNlZCBpbiB0aGUgSFRU UFMgdXNlIGNhc2UsIHdoaWNoIHNlZW1zIGxpa2UgYQ0KbGF5ZXJpbmcgdmlvbGF0aW9uIHRvIG1l Lg0KDQotQmVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_F0B6458F24214A2DB14849E08D3F3496akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <4456C40D59E739439671002AEE475227@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBhZ3JlZSB3aXRoIEJlbiBoZXJl LiBUaGlzIGlzIHZlcnkgbXVjaCBhcHBsaWNhdGlvbi1sYXllciAoSFRUUFMpIGZ1bmN0aW9uYWxp dHkgYmVpbmcgcHVzaGVkIGRvd24gaW50byB0aGUgc2VjdXJpdHkgKFRMUykgbGF5ZXIuIEhUVFAo UykgYWxyZWFkeSBoYXMgYSBmdWxseSBmdW5jdGlvbmFsIHJlZGlyZWN0IG1lY2hhbmlzbSwgd2h5 IGRvZXMgdGhpcyBmdW5jdGlvbmFsaXR5IG5lZWQgdG8gYmUgcHVzaGVkIHRvIGEgbG93ZXIgbGF5 ZXI/IEFsbA0KIHRoZSBjYXNlcyBkZXNjcmliZWQgaW4gdGhlIEludHJvZHVjdGlvbiBjYW4gYmUg aGFuZGxlZCBhdCBsYXllcnMgaW5kZXBlbmRlbnQgb2YgVExTJm5ic3A7DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SW4g c2VjdGlvbiA0OiDigJwuLi5hbmQgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBHZXQgcGFja2V0LCB0aGUg Y2xpZW50IHJlc3BvbmRzIHdpdGggdGhl4oCm4oCdIEkgYmVsaWV2ZSB0aGF0IOKAnGNsaWVudOKA nSBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCDigJxzZXJ2ZXLigJ0uPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TZWN0aW9uIOKAnDUuIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25z4oCdIGlzIGNvbXBsZXRlbHkgYmxhbmsuPGJyIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZyb20gdGhl IGRlc2NyaXB0aW9uIGl0IGlzIG5vdCBjbGVhciBob3cgbXVjaCBvZiB0aGUgaGFuZHNoYWtlIGNv bXBsZXRlcyBiZWZvcmUgaGFuZGxpbmcgdGhlIFJlZGlyZWN0LiBJdCBpbXBsaWVzIHRoYXQgdGhl IFJlZGlyZWN0IG1heSBiZSBhY3RlZCB1cG9uICjigJxmYXVsdCB3YXJuaW5nIHBhZ2UmcXVvdDsp IGJlZm9yZSB0aGUgaGFuZHNoYWtlIGNvbXBsZXRlcywgYW5kIHRodXMgaXQgaXMgbm90IHNlY3Vy ZS4gQSBNSVRNIGNvdWxkDQogZWFzaWx5IGluamVjdCB0aGUgUmVkaXJlY3QgcGFja2V0IHRoYXQg aW1wYWN0cyB0aGUgY2xpZW50LCBwcmV2ZW50aW5nIGFjY2Vzcy48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJ1dCB0aGF0IGlzIOKAnHNv cnRh4oCdIHRoZSBwb2ludCwgYSBjYXB0aXZlIHBvcnRhbCwgYWN0aW5nIGFzIGEgTUlUTSwgbmVl ZHMgdG8gYXV0aGVudGljYXRlIHRoZSB1c2VyLCBwb3RlbnRpYWxseSBhdCBhbnkgdGltZS4gVGhp cyBtYXkgYmUgZ29pbmcgb2ZmIG9uIGEgdGFuZ2VudCwgYnV0IGlmIHRoZSBjYXB0aXZlIHBvcnRh bCBhY2NlcHRlZCBhbiBIVFRQUyBjb25uZWN0aW9uIGRlc3RpbmVkIGZvciBhbnl3aGVyZSwgYW5k IGlmDQogaXQgY291bGQgYW5ub3VuY2UgYmFjayB0byB0aGUgY2xpZW50IHRoYXQgSSBhbSB5b3Vy IGNhcHRpdmUgcG9ydGFsLCBhbmQgdGhlIGNsaWVudCBjb3VsZCB2ZXJpZnkgdGhhdCwgdGhlbiB0 aGVyZSB3b3VsZCBiZSBubyBuZWVkIGZvciBhIFRMUy1sZXZlbCByZWRpcmVjdC4gQSBicm93c2Vy IHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSB0aGlzIGJ5IHF1ZXJ5aW5nIGZvciB0aGUgcm91dGVy IChpLmUuIGNhcHRpdmUgcG9ydGFsKSBJUCBhZGRyZXNzL0ROUw0KIG5hbWUsIGFuZCBjb21wYXJp bmcgdGhhdCB0byB0aGUgcmVjZWl2ZWQgVExTICZuYnNwO3NlcnZlciBjcmVkZW50aWFscy4gSWYg dGhleSBtYXRjaCwgdGhlIGNsaWVudCBwcm9ncmFtIGtub3dzIGl04oCZcyB0YWxraW5nIHRvIGEg Y2FwdGl2ZSBwb3J0YWwuIEkgY291bGQgZ28gaW50byBtb3JlIGRldGFpbCwgYnV0IGl0IG91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tLTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+LVRvZGQgU2hvcnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gPGEgaHJlZj0ibWFpbHRv OnRzaG9ydEBha2FtYWkuY29tIiBjbGFzcz0iIj50c2hvcnRAYWthbWFpLmNvbTwvYT48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Ly8gJnF1b3Q7T25lIGlmIGJ5IGxhbmQsIHR3byBpZiBieSBzZWEsIHRo cmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+T24gT2N0IDIxLCAyMDE1LCBhdCAxMjoxMyBQTSwgQmVuamFtaW4g S2FkdWsgJmx0OzxhIGhyZWY9Im1haWx0bzpia2FkdWtAYWthbWFpLmNvbSIgY2xhc3M9IiI+Ymth ZHVrQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50 ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPk9uIDEwLzIwLzIwMTUgMTA6MDIgUE0s IFpob3VxaWFuIChDYXRoeSkgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+W0NhdGh5XVllcywgYm90aCB3ZWIgYXV0aGVudGljYXRpb24gYW5kIG92 ZXJkdWUgdXNlIGNhc2VzIGNvdWxkIGJlPGJyIGNsYXNzPSIiPg0KY29uc2lkZXJlZCBhcyBjYXB0 aXZlIHBvcnRhbHMuIEFuZCBJIGhhdmUgYWxyZWFkeSBzZW50IGFuIGVtYWlsIHRvIHRoZTxiciBj bGFzcz0iIj4NCmNhcHBvcnQgbWFpbGluZyBsaXN0IGZvciB0aGVpciBjb21tZW50cy4gPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSBtZW50aW9uZWQgY2FwcG9y dCBiZWNhdXNlIGl0IHNvdW5kcyBsaWtlIHRoZXkgYXJlIHRyeWluZyB0byBzb2x2ZSB0aGU8YnIg Y2xhc3M9IiI+DQpzYW1lIHNvcnQgb2YgcHJvYmxlbSB0aGF0IHlvdXIgc29sdXRpb24gaXMgdHJ5 aW5nIHRvIHNvbHZlLCBub3QgYmVjYXVzZTxiciBjbGFzcz0iIj4NCkkgdGhpbmsgeW91ciBwcm9w b3NhbCB3aWxsIGJlIHdlbGwtcmVjZWl2ZWQgdGhlcmUuICZuYnNwO0kgYWdyZWUgd2l0aCBXYXJy ZW48YnIgY2xhc3M9IiI+DQphbmQgSm9lbCB0aGF0IGRpcmVjdGx5IGludGVyY2VwdGluZyBUTFMg Y29ubmVjdGlvbnMgaXMgbm90IHNvbWV0aGluZyBJPGJyIGNsYXNzPSIiPg0Kd2FudCB0byBzdXBw b3J0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SW4gYW55IGNhc2Us IGl0IGlzIGZhciBmcm9tIGNsZWFyIHRoYXQgSFRUUC1zcGVjaWZpYyBpc3N1ZXMgc2hvdWxkIGJl IGhhbmRsZWQgYXQ8YnIgY2xhc3M9IiI+DQp0aGUgVExTIGxheWVyIC0tIFRMUyBpcyBhIGdlbmVy aWMgc2VjdXJlIGNoYW5uZWwgcHJvdG9jb2wgdXNlZCBpbiBtYW55PGJyIGNsYXNzPSIiPg0KYXBw bGljYXRpb25zIG90aGVyIHRoYW4gSFRUUFMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K W0NhdGh5XSBBcyBkZWZpbmVkIGluIFtSRkMgNTI0Nl0sICZxdW90O2FwcGxpY2F0aW9uIHByb3Rv Y29sPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QW4gYXBwbGlj YXRpb24gcHJvdG9jb2wgaXMgYSBwcm90b2NvbCB0aGF0IG5vcm1hbGx5IGxheWVyczxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RpcmVjdGx5IG9uIHRvcCBvZiB0 aGUgdHJhbnNwb3J0IGxheWVyIChlLmcuLCBUQ1AvSVApLiAmbmJzcDtFeGFtcGxlczxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2luY2x1ZGUgSFRUUCwgVEVMTkVU LCBGVFAsIGFuZCBTTVRQLiZxdW90Oyw8YnIgY2xhc3M9IiI+DQp0aGUgVExTIHByb3RvY29sIGNv dWxkIGJlIHVzZWQgZm9yIEhUVFAgYXBwbGljYXRpb25zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgZG9uJ3QgdGhpbmsgdGhhdCdz IHF1aXRlIHRoZSBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZS4gJm5ic3A7SFRUUFMgaXM8YnIg Y2xhc3M9IiI+DQpIVFRQIGxheWVyZWQgb24gdG9wIG9mIFRMUywgeWVzLCBidXQgaW4gb3JkZXIg Zm9yIHRoZXJlIHRvIGJlIGE8YnIgY2xhc3M9IiI+DQpzZXBhcmF0aW9uIG9mIGxheWVycywgVExT IHNob3VsZCBub3QgaW5jbHVkZSBhbnkgZGF0YSBzdHJ1Y3R1cmVzIHRoYXQ8YnIgY2xhc3M9IiI+ DQphcmUgb25seSB1c2VmdWwgZm9yIHRoZSBIVFRQUyBjYXNlLiAmbmJzcDtUaGlzIGRvY3VtZW50 IHNlZW1zIHRvIGFkZCBhIGZpZWxkPGJyIGNsYXNzPSIiPg0KdG8gVExTIHRoYXQgaXMgb25seSB1 c2VkIGluIHRoZSBIVFRQUyB1c2UgY2FzZSwgd2hpY2ggc2VlbXMgbGlrZSBhPGJyIGNsYXNzPSIi Pg0KbGF5ZXJpbmcgdmlvbGF0aW9uIHRvIG1lLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Ci1CZW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClRMUyBtYWlsaW5nIGxpc3Q8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiBjbGFzcz0iIj5UTFNA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHM8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F0B6458F24214A2DB14849E08D3F3496akamaicom_-- From nobody Wed Oct 21 11:07:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D872A1A8762 for ; Wed, 21 Oct 2015 11:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ffwXtnTZYfO for ; Wed, 21 Oct 2015 11:07:39 -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 1BDCA1A8741 for ; Wed, 21 Oct 2015 11:07:39 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C228B424020; Wed, 21 Oct 2015 18:07:38 +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 AB2F04DB43; Wed, 21 Oct 2015 18:07:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445450858; bh=Od2IQ0Q7158hefOZ8ddlYrElh2B/fY2ML9gTe2G///0=; l=12528; h=To:References:From:Date:In-Reply-To:From; b=NIHxt/Xtbh4qAu09hloJN8TsHUOSxSM2GpbfSHHlF7wZ4EFc7uoxXwv/AW67X0Q1E f90HeErv7KT8njOm/w2zO0KUQ54XMkwP17uWLmUCwYXeBOrhr0850oLvTphJwCjcxQ JM25Bok+lRM+ODuQF3msl+7GVASkOVtDkwu6bMpI= 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 6928B2047; Wed, 21 Oct 2015 18:07:38 +0000 (GMT) To: Eric Rescorla , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <5627D46A.2050608@akamai.com> Date: Wed, 21 Oct 2015 13:07:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050005040006030109000108" Archived-At: Subject: Re: [TLS] HelloRetryRequest and stateless reject X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 18:07:46 -0000 This is a multi-part message in MIME format. --------------050005040006030109000108 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/21/2015 12:32 PM, Eric Rescorla wrote: > Folks, > > Several of the remaining TLS 1.3 issues have to do with the > ClientHello/HelloRetryRequest interaction. To recap, if the > ClientHello does not contain a KeyShare with an acceptable group, the > server sends a HelloRetryRequest indicating the correct group, > and the client sends a ClientHello with the correct group: > > Client Server > > ClientHello > + KeyShare --------> > <-------- HelloRetryRequest > > ClientHello > + KeyShare --------> > ServerHello > + KeyShare > ... > > > DTLS has a very similar mechanism where the server provides a > HelloVerifyRequest containing a cookie in order to force the client to > provide proof of routabilty at its claimed address. The client > re-sends the ClientHello with the cookie and the handshake restarts. > > It seems natural to try to merge these mechanisms, but this raises > the question of whether the handshake hashes should continue through > the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104 > ). > The tension here is that you want to be able to have a stateless > rejection (to avoid DoS in the DTLS scenario) but having things > makes it much harder to analyze the handshake's resistance to > downgrade attacks. > > Recently, Karthik, Martin Thomson, and I were talking and I think we've > come to a good resolution. The basic observation is that it's possible > to continue the handshake hash through the rejection exchange while > still being stateless. We are aware of two main techniques here: > > - The server offloads its handshake hash state into the cookie > it provides in the HelloRetryRequest (we'll need the cookie here > in any case to support the DTLS case. The cookie obviously needs > to be cryptographically protected, but that's what you're supposed > to do for DTLS anyway > (see: https://tools.ietf.org/html/rfc6347#section-4.2.1 > ) > > - The server reconstructs the original ClientHello and HelloRetryRequest > based on the re-sent ClientHello. This is possible because there are > very strict rules about re-sent ClientHello construction > (namely: send the same ClientHello except just add a KeyShareEntry > for the indicated group). The cookie should also allow the server > to double-check this (and will also need to indicate the reason > for rejection). > > Because the handshake hash is continued through the entire handshake, > it's much easier to analyze the downgrade properties. Moreover, > servers which don't need stateless reject (because there is some > other connection construct as with TLS over TCP or DTLS with > ICE) don't need either of these techniques. They can just continue > the handshake hash in the usual way. > > This seems like it fulfills both imperatives, at the primary cost of > some additional complexity on servers who really care about > statelesness (the client is indifferent to the server's implementation > strategy). > > If this sounds good to people, I'll work up a PR for this, but > really all it is is saying that you don't reset the hash and > then a non-normative appendix describing stateless implementation > techniques. > > Thoughts? Does anyone see anything wrong with this? > It sounds like a good plan. The only thing that comes to mind is whether a server might want to use encrypted (and MACd) serialized state instead of an HMAC'd blob for the cookie where it would have to reconstruct state from the re-sent ClientHello. (It should be easy to have text that allows for either case; I just wanted to mention it as a possibility.) -Ben --------------050005040006030109000108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 10/21/2015 12:32 PM, Eric Rescorla wrote:
Folks,

Several of the remaining TLS 1.3 issues have to do with the
ClientHello/HelloRetryRequest interaction. To recap, if the
ClientHello does not contain a KeyShare with an acceptable group, the
server sends a HelloRetryRequest indicating the correct group,
and the client sends a ClientHello with the correct group:

         Client                                               Server
  
         ClientHello
           + KeyShare              -------->
                                   <--------       HelloRetryRequest
  
         ClientHello
           + KeyShare              -------->
                                                         ServerHello
                                                          + KeyShare
         ...


DTLS has a very similar mechanism where the server provides a
HelloVerifyRequest containing a cookie in order to force the client to
provide proof of routabilty at its claimed address. The client
re-sends the ClientHello with the cookie and the handshake restarts.

It seems natural to try to merge these mechanisms, but this raises
the question of whether the handshake hashes should continue through
The tension here is that you want to be able to have a stateless
rejection (to avoid DoS in the DTLS scenario) but having things
makes it much harder to analyze the handshake's resistance to
downgrade attacks.

Recently, Karthik, Martin Thomson, and I were talking and I think we've
come to a good resolution. The basic observation is that it's possible
to continue the handshake hash through the rejection exchange while
still being stateless. We are aware of two main techniques here:

- The server offloads its handshake hash state into the cookie
  it provides in the HelloRetryRequest (we'll need the cookie here
  in any case to support the DTLS case. The cookie obviously needs
  to be cryptographically protected, but that's what you're supposed
  to do for DTLS anyway

- The server reconstructs the original ClientHello and HelloRetryRequest
  based on the re-sent ClientHello. This is possible because there are
  very strict rules about re-sent ClientHello construction
  (namely: send the same ClientHello except just add a KeyShareEntry
  for the indicated group). The cookie should also allow the server
  to double-check this (and will also need to indicate the reason
  for rejection).

Because the handshake hash is continued through the entire handshake,
it's much easier to analyze the downgrade properties. Moreover,
servers which don't need stateless reject (because there is some
other connection construct as with TLS over TCP or DTLS with
ICE) don't need either of these techniques. They can just continue
the handshake hash in the usual way.

This seems like it fulfills both imperatives, at the primary cost of
some additional complexity on servers who really care about
statelesness (the client is indifferent to the server's implementation
strategy).

If this sounds good to people, I'll work up a PR for this, but
really all it is is saying that you don't reset the hash and
then a non-normative appendix describing stateless implementation
techniques.

Thoughts? Does anyone see anything wrong with this?


It sounds like a good plan.  The only thing that comes to mind is whether a server might want to use encrypted (and MACd) serialized state instead of an HMAC'd blob for the cookie where it would have to reconstruct state from the re-sent ClientHello.  (It should be easy to have text that allows for either case; I just wanted to mention it as a possibility.)

-Ben
--------------050005040006030109000108-- From nobody Wed Oct 21 11:13:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ABC1A877B for ; Wed, 21 Oct 2015 11:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kW2lm-PmFk6b for ; Wed, 21 Oct 2015 11:13:08 -0700 (PDT) Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.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 B3EE61A8789 for ; Wed, 21 Oct 2015 11:13:07 -0700 (PDT) Received: by ykba4 with SMTP id a4so51975090ykb.3 for ; Wed, 21 Oct 2015 11:13:07 -0700 (PDT) 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-type; bh=UZeOLhh1xqfCcAG6hzggvRskuiq/+RzPZnIzahg4c4E=; b=mp0MqKVjF5CEQ53RYtclWYu4Dmq1sL2+i9AL2XKq7KIU/HqmIZS+ae4eIVOCCiKAiu ggs1d9XGQIY4MkXI0Vu6ec0H5KQx1KQF7RAnSSK87RVvBWX/wyfwpuU9fc6AHvpZJtBg n9CzbAzT3pk+6b/BGbNfDiB4hXqXJjnGlSQi2bZvtERtIdWqopJWywq0obERHvljnF1T pvpNT7TmHQaZWXr+IFqZOtj3N/uYDu9lGefrRs2ECi9BvyCiBlm7SYAUnBUwQStWlkzf dDyIlUb32qJcpHoy6m4aMvrJPjnl1CwU0IuUgNFUNuCe/69e6LGkEU9Rfun7pkN4YRfn VMZA== X-Gm-Message-State: ALoCoQn4MQ7YOeQSokp+ajsqgePYQQ2rNpPQ6qVawKXFhgWJ/9qYj8byB+XYAD1uTZl/ZywUazef X-Received: by 10.13.236.198 with SMTP id v189mr6014894ywe.231.1445451186977; Wed, 21 Oct 2015 11:13:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 11:12:27 -0700 (PDT) In-Reply-To: <5627D46A.2050608@akamai.com> References: <5627D46A.2050608@akamai.com> From: Eric Rescorla Date: Wed, 21 Oct 2015 11:12:27 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c0859d68a65670522a15489 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HelloRetryRequest and stateless reject X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 18:13:10 -0000 --94eb2c0859d68a65670522a15489 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 21, 2015 at 11:07 AM, Benjamin Kaduk wrote: > On 10/21/2015 12:32 PM, Eric Rescorla wrote: > > Folks, > > Several of the remaining TLS 1.3 issues have to do with the > ClientHello/HelloRetryRequest interaction. To recap, if the > ClientHello does not contain a KeyShare with an acceptable group, the > server sends a HelloRetryRequest indicating the correct group, > and the client sends a ClientHello with the correct group: > > Client Server > > ClientHello > + KeyShare --------> > <-------- HelloRetryRequest > > ClientHello > + KeyShare --------> > ServerHello > + KeyShare > ... > > > DTLS has a very similar mechanism where the server provides a > HelloVerifyRequest containing a cookie in order to force the client to > provide proof of routabilty at its claimed address. The client > re-sends the ClientHello with the cookie and the handshake restarts. > > It seems natural to try to merge these mechanisms, but this raises > the question of whether the handshake hashes should continue through > the rejection exchange ( > > https://github.com/tlswg/tls13-spec/issues/104). > The tension here is that you want to be able to have a stateless > rejection (to avoid DoS in the DTLS scenario) but having things > makes it much harder to analyze the handshake's resistance to > downgrade attacks. > > Recently, Karthik, Martin Thomson, and I were talking and I think we've > come to a good resolution. The basic observation is that it's possible > to continue the handshake hash through the rejection exchange while > still being stateless. We are aware of two main techniques here: > > - The server offloads its handshake hash state into the cookie > it provides in the HelloRetryRequest (we'll need the cookie here > in any case to support the DTLS case. The cookie obviously needs > to be cryptographically protected, but that's what you're supposed > to do for DTLS anyway > (see: https://tools.ietf.org/html/rfc6347#section-4.2.1 > > ) > > - The server reconstructs the original ClientHello and HelloRetryRequest > based on the re-sent ClientHello. This is possible because there are > very strict rules about re-sent ClientHello construction > (namely: send the same ClientHello except just add a KeyShareEntry > for the indicated group). The cookie should also allow the server > to double-check this (and will also need to indicate the reason > for rejection). > > Because the handshake hash is continued through the entire handshake, > it's much easier to analyze the downgrade properties. Moreover, > servers which don't need stateless reject (because there is some > other connection construct as with TLS over TCP or DTLS with > ICE) don't need either of these techniques. They can just continue > the handshake hash in the usual way. > > This seems like it fulfills both imperatives, at the primary cost of > some additional complexity on servers who really care about > statelesness (the client is indifferent to the server's implementation > strategy). > > If this sounds good to people, I'll work up a PR for this, but > really all it is is saying that you don't reset the hash and > then a non-normative appendix describing stateless implementation > techniques. > > Thoughts? Does anyone see anything wrong with this? > > > It sounds like a good plan. The only thing that comes to mind is whether > a server might want to use encrypted (and MACd) serialized state instead = of > an HMAC'd blob for the cookie where it would have to reconstruct state fr= om > the re-sent ClientHello. (It should be easy to have text that allows for > either case; I just wanted to mention it as a possibility.) > Yes, this also seems like a good alternative. Best, -Ekr -Ben > --94eb2c0859d68a65670522a15489 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 21, 2015 at 11:07 AM, Benjamin Kaduk <= bkaduk@akamai.com> wrote:
=20 =20 =20
On 10/21/2015 12:32 PM, Eric Rescorla wrote:
=20
Folks,

Several of the remaining TLS 1.3 issues have to do with the
ClientHello/HelloRetryRequest interaction. To recap, if the
ClientHello does not contain a KeyShare with an acceptable group, the
server sends a HelloRetryRequest indicating the correct group,
and the client sends a ClientHello with the correct group:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C= lient =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C= lientHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+ KeyShare =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<-------- =C2=A0 =C2=A0 =C2=A0 HelloRetryRequest
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C= lientHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+ KeyShare =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0ServerHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 + KeyShare
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.= ..


DTLS has a very similar mechanism where the server provides a
HelloVerifyRequest containing a cookie in order to force the client to
provide proof of routabilty at its claimed address. The client
re-sends the ClientHello with the cookie and the handshake restarts.

It seems natural to try to merge these mechanisms, but this raises
the question of whether the handshake hashes should continue through
The tension here is that you want to be able to have a=C2=A0stateless
rejection (to avoid DoS in the DTLS scenario) but having things
makes it much harder to analyze the handshake's resistance to
downgrade attacks.

Recently, Karthik, Martin Thomson, and I were talking and I think we've
come to a good resolution. The basic observation is that it's possible
to continue the handshake hash through the rejection exchange while
still being=C2=A0stateless. We are aware of two main techniques here:

- The server offloads its handshake hash=C2=A0state=C2=A0into the cookie
=C2=A0 it provides in the HelloRetryRequest (we'll need the cookie here
=C2=A0 in any case to support the D= TLS case. The cookie obviously needs
=C2=A0 to be cryptographically protected, but that's what you're supposed
=C2=A0 to do for DTLS anyway

- The server reconstructs the original ClientHello and HelloRetryRequest
=C2=A0 based on the re-sent ClientHello. This is possible because there are
=C2=A0 very strict rules about re-s= ent ClientHello construction
=C2=A0 (namely: send the same ClientHello except just add a KeyShareEntry
=C2=A0 for the indicated group). Th= e cookie should also allow the server
=C2=A0 to double-check this (and wi= ll also need to indicate the reason
=C2=A0 for rejection).

Because the handshake hash is continued through the entire handshake,
it's much easier to analyze the downgrade properties. Moreover,
servers which don't need=C2=A0<= span>stateless=C2=A0reject (because there is some
other connection construct as with TLS over TCP or DTLS with
ICE) don't need either of these techniques. They can just continue
the handshake hash in the usual way.

This seems like it fulfills both imperatives, at the primary cost of
some additional complexity on servers who really care about
statelesness (the client is indifferent to the server's implementation
strategy).

If this sounds good to people, I'll work up a PR for this, but
really all it is is saying that you don't reset the hash and
then a non-normative appendix describing=C2=A0stateless=C2=A0implementation
techniques.

Thoughts? Does anyone see anything wrong with this?


It sounds like a good plan.=C2=A0 The only thing that comes to mind is whether a server might want to use encrypted (and MACd) serialized state instead of an HMAC'd blob for the cookie where it would have to reconstruct state from the re-sent ClientHello.=C2=A0 (It should be easy to have text that allows for either case; I just wanted to mention it as a possibility.)

Yes, this also seems like a good alternative.



--94eb2c0859d68a65670522a15489-- From nobody Wed Oct 21 11:13:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1241A87A6 for ; Wed, 21 Oct 2015 11:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UvLhVRFooOi for ; Wed, 21 Oct 2015 11:13:13 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id F39C31A8789 for ; Wed, 21 Oct 2015 11:13:12 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6FB8E200081; Wed, 21 Oct 2015 18:13:12 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 59F5D200085; Wed, 21 Oct 2015 18:13:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445451192; bh=ZhMl/yWwvBMdOSnyg+LMwQiWeBKddnEexPMSyB98iRc=; l=15692; h=From:To:CC:Date:References:In-Reply-To:From; b=aomx7d+2MKMvFp6MhIlvUV6+dKgZKKDnJEAzgDGyQgbGwGWxDJjXSx8F6bhcaduN4 fuVQe2UmH4sg+T/1qZwKF3nVrzuNo9GABRMHmd2mvrBpOGs9NawGwnPYxw8blHO3Rk DER2ylwrn+aAMDIAoR6ECvePPOTaWV19qDnELGyM= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 577791E07C; Wed, 21 Oct 2015 18:13:12 +0000 (GMT) Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 21 Oct 2015 13:13:11 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Wed, 21 Oct 2015 13:13:11 -0500 From: "Short, Todd" To: Eric Rescorla Thread-Topic: [TLS] HelloRetryRequest and stateless reject Thread-Index: AQHRDCakKYdKRbln8EyiFg1uppImOZ52k80A Date: Wed, 21 Oct 2015 18:13:11 +0000 Message-ID: <82CE84ED-F9FF-4B93-B15B-46DD1F2C3BC3@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.114] Content-Type: multipart/alternative; boundary="_000_82CE84EDF9FF4B93B15B46DD1F2C3BC3akamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HelloRetryRequest and stateless reject X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 18:13:18 -0000 --_000_82CE84EDF9FF4B93B15B46DD1F2C3BC3akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the idea. If the functionality is to be merged, perhaps harmonizing = the names and contents of the messages (if possible)? -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." On Oct 21, 2015, at 1:32 PM, Eric Rescorla > wrote: Folks, Several of the remaining TLS 1.3 issues have to do with the ClientHello/HelloRetryRequest interaction. To recap, if the ClientHello does not contain a KeyShare with an acceptable group, the server sends a HelloRetryRequest indicating the correct group, and the client sends a ClientHello with the correct group: Client Server ClientHello + KeyShare --------> <-------- HelloRetryRequest ClientHello + KeyShare --------> ServerHello + KeyShare ... DTLS has a very similar mechanism where the server provides a HelloVerifyRequest containing a cookie in order to force the client to provide proof of routabilty at its claimed address. The client re-sends the ClientHello with the cookie and the handshake restarts. It seems natural to try to merge these mechanisms, but this raises the question of whether the handshake hashes should continue through the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104). The tension here is that you want to be able to have a stateless rejection (to avoid DoS in the DTLS scenario) but having things makes it much harder to analyze the handshake's resistance to downgrade attacks. Recently, Karthik, Martin Thomson, and I were talking and I think we've come to a good resolution. The basic observation is that it's possible to continue the handshake hash through the rejection exchange while still being stateless. We are aware of two main techniques here: - The server offloads its handshake hash state into the cookie it provides in the HelloRetryRequest (we'll need the cookie here in any case to support the DTLS case. The cookie obviously needs to be cryptographically protected, but that's what you're supposed to do for DTLS anyway (see: https://tools.ietf.org/html/rfc6347#section-4.2.1) - The server reconstructs the original ClientHello and HelloRetryRequest based on the re-sent ClientHello. This is possible because there are very strict rules about re-sent ClientHello construction (namely: send the same ClientHello except just add a KeyShareEntry for the indicated group). The cookie should also allow the server to double-check this (and will also need to indicate the reason for rejection). Because the handshake hash is continued through the entire handshake, it's much easier to analyze the downgrade properties. Moreover, servers which don't need stateless reject (because there is some other connection construct as with TLS over TCP or DTLS with ICE) don't need either of these techniques. They can just continue the handshake hash in the usual way. This seems like it fulfills both imperatives, at the primary cost of some additional complexity on servers who really care about statelesness (the client is indifferent to the server's implementation strategy). If this sounds good to people, I'll work up a PR for this, but really all it is is saying that you don't reset the hash and then a non-normative appendix describing stateless implementation techniques. Thoughts? Does anyone see anything wrong with this? -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_82CE84EDF9FF4B93B15B46DD1F2C3BC3akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1EF6F2DFBDD2A542808897B561B3D27D@akamai.com> Content-Transfer-Encoding: quoted-printable
I like the idea. If the functionality is to be merged, perh= aps harmonizing the names and contents of the messages (if possible)?
--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

On Oct 21, 2015, at 1:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:

Folks,

Several of the remaining TLS 1.3= issues have to do with the
ClientHello/HelloRetryRequest in= teraction. To recap, if the
ClientHello does not contain a K= eyShare with an acceptable group, the
server sends a HelloRetryRequest= indicating the correct group,
and the client sends a ClientHel= lo with the correct group:

        &nbs= p;Client                   &nb= sp;                     &= nbsp;     Server
  
        &nbs= p;ClientHello
        &nbs= p;  + KeyShare              ---= ----->
        &nbs= p;                     &n= bsp;    <--------       HelloRetryRequest
  
        &nbs= p;ClientHello
        &nbs= p;  + KeyShare              ---= ----->
        &nbs= p;                     &n= bsp;                     =      ServerHello
        &nbs= p;                     &n= bsp;                     =       + KeyShare
        &nbs= p;...


DTLS has a very similar mechanis= m where the server provides a
HelloVerifyRequest containing a = cookie in order to force the client to
provide proof of routabilty at i= ts claimed address. The client
re-sends the ClientHello with th= e cookie and the handshake restarts.

It seems natural to try to merge= these mechanisms, but this raises
the question of whether the hand= shake hashes should continue through
the rejection exchange (https://github.com/tlswg/tls13-spe= c/issues/104).
The tension here is that you wan= t to be able to have a stateless
rejection (to avoid DoS in the D= TLS scenario) but having things
makes it much harder to analyze = the handshake's resistance to
downgrade attacks.

Recently, Karthik, Martin Thomso= n, and I were talking and I think we've
come to a good resolution. The b= asic observation is that it's possible
to continue the handshake hash t= hrough the rejection exchange while
still being stateless. We are aware of two main techniques here:

- The server offloads its handsh= ake hash state into the cookie
  it provides in the HelloR= etryRequest (we'll need the cookie here
  in any case to support th= e DTLS case. The cookie obviously needs
  to be cryptographically p= rotected, but that's what you're supposed
  to do for DTLS anyway
  (see: https://tools.ietf.org/html/rfc6347= #section-4.2.1)

- The server reconstructs the or= iginal ClientHello and HelloRetryRequest
  based on the re-sent Clie= ntHello. This is possible because there are
  very strict rules about r= e-sent ClientHello construction
  (namely: send the same Cl= ientHello except just add a KeyShareEntry
  for the indicated group).= The cookie should also allow the server
  to double-check this (and= will also need to indicate the reason
  for rejection).

Because the handshake hash is co= ntinued through the entire handshake,
it's much easier to analyze the = downgrade properties. Moreover,
servers which don't need stateless reject (because there is some
other connection construct as wi= th TLS over TCP or DTLS with
ICE) don't need either of these = techniques. They can just continue
the handshake hash in the usual = way.

This seems like it fulfills both= imperatives, at the primary cost of
some additional complexity on se= rvers who really care about
statelesness (the client is indi= fferent to the server's implementation
strategy).

If this sounds good to people, I= 'll work up a PR for this, but
really all it is is saying that = you don't reset the hash and
then a non-normative appendix de= scribing stateless implementation
techniques.

Thoughts? Does anyone see anythi= ng wrong with this?
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--_000_82CE84EDF9FF4B93B15B46DD1F2C3BC3akamaicom_-- From nobody Wed Oct 21 11:17:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6361A0087 for ; Wed, 21 Oct 2015 11:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgiqiql3ArIn for ; Wed, 21 Oct 2015 11:17:50 -0700 (PDT) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) (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 5EB251A86F2 for ; Wed, 21 Oct 2015 11:17:50 -0700 (PDT) Received: by yknn9 with SMTP id n9so58062108ykn.0 for ; Wed, 21 Oct 2015 11:17:49 -0700 (PDT) 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-type; bh=kGuf7yz6l2UIOkpe/9PTDzIYNoHoWgFx0xqE1eCl1n4=; b=ZUxPSZZzIpHcLb95uFfDYnxf3nGT7jhOOlB8MY4M/0oeukoMqUQdcUA4hDP6tl8SLm y2smjMjk+VO4gGhcl2p6nfekEDEWg6/Tj7fwu9UEzvFx1ZJSs13if0ko+gH2qeRMMJxr rMkd356AGMfW2rbSDZegZCWGIKbRJippkEHrO2Ky0vlCBEWhhw153C3Z9ZSHSPdYHMsI 8lZYWxjAMH6B1UCo/TkrMMtGLS7wHTn9YHnJJm3yeaTsZPEJZiQsu1kA6lnJIjr5gv8F wE5jECO/94GiCGoG7KJIjVu9GZG+R3v5Jymw4wZoLE9BWaG/JYLgDIczqx0mdnJWf/Hz tCBA== X-Gm-Message-State: ALoCoQmfiEdrMiRCNgjvqJtmsv6jAp/EC2+T+y56oUEBvUjl2N3ZAsAfueGIhUNvGK/wwNP1150k X-Received: by 10.13.236.198 with SMTP id v189mr6035448ywe.231.1445451469640; Wed, 21 Oct 2015 11:17:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 11:17:10 -0700 (PDT) In-Reply-To: <82CE84ED-F9FF-4B93-B15B-46DD1F2C3BC3@akamai.com> References: <82CE84ED-F9FF-4B93-B15B-46DD1F2C3BC3@akamai.com> From: Eric Rescorla Date: Wed, 21 Oct 2015 11:17:10 -0700 Message-ID: To: "Short, Todd" Content-Type: multipart/alternative; boundary=94eb2c0859d66384500522a165f5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HelloRetryRequest and stateless reject X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 18:17:53 -0000 --94eb2c0859d66384500522a165f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd wrote: > I like the idea. If the functionality is to be merged, perhaps harmonizin= g > the names and contents of the messages (if possible)? > Yes. My plan is to name it HelloRetryRequest and get rid of HelloVerifyRequest. -Ekr > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Oct 21, 2015, at 1:32 PM, Eric Rescorla wrote: > > Folks, > > Several of the remaining TLS 1.3 issues have to do with the > ClientHello/HelloRetryRequest interaction. To recap, if the > ClientHello does not contain a KeyShare with an acceptable group, the > server sends a HelloRetryRequest indicating the correct group, > and the client sends a ClientHello with the correct group: > > Client Server > > ClientHello > + KeyShare --------> > <-------- HelloRetryRequest > > ClientHello > + KeyShare --------> > ServerHello > + KeyShare > ... > > > DTLS has a very similar mechanism where the server provides a > HelloVerifyRequest containing a cookie in order to force the client to > provide proof of routabilty at its claimed address. The client > re-sends the ClientHello with the cookie and the handshake restarts. > > It seems natural to try to merge these mechanisms, but this raises > the question of whether the handshake hashes should continue through > the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104 > > ). > The tension here is that you want to be able to have a stateless > rejection (to avoid DoS in the DTLS scenario) but having things > makes it much harder to analyze the handshake's resistance to > downgrade attacks. > > Recently, Karthik, Martin Thomson, and I were talking and I think we've > come to a good resolution. The basic observation is that it's possible > to continue the handshake hash through the rejection exchange while > still being stateless. We are aware of two main techniques here: > > - The server offloads its handshake hash state into the cookie > it provides in the HelloRetryRequest (we'll need the cookie here > in any case to support the DTLS case. The cookie obviously needs > to be cryptographically protected, but that's what you're supposed > to do for DTLS anyway > (see: https://tools.ietf.org/html/rfc6347#section-4.2.1 > > ) > > - The server reconstructs the original ClientHello and HelloRetryRequest > based on the re-sent ClientHello. This is possible because there are > very strict rules about re-sent ClientHello construction > (namely: send the same ClientHello except just add a KeyShareEntry > for the indicated group). The cookie should also allow the server > to double-check this (and will also need to indicate the reason > for rejection). > > Because the handshake hash is continued through the entire handshake, > it's much easier to analyze the downgrade properties. Moreover, > servers which don't need stateless reject (because there is some > other connection construct as with TLS over TCP or DTLS with > ICE) don't need either of these techniques. They can just continue > the handshake hash in the usual way. > > This seems like it fulfills both imperatives, at the primary cost of > some additional complexity on servers who really care about > statelesness (the client is indifferent to the server's implementation > strategy). > > If this sounds good to people, I'll work up a PR for this, but > really all it is is saying that you don't reset the hash and > then a non-normative appendix describing stateless implementation > techniques. > > Thoughts? Does anyone see anything wrong with this? > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --94eb2c0859d66384500522a165f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd <tshort@akamai.com&g= t; wrote:
I like the idea. If the functionality is to be merged, perhaps harmoni= zing the names and contents of the messages (if possible)?

Yes. My plan is to name it HelloRetryRequest an= d get rid of HelloVerifyRequest.

-Ekr
= =C2=A0
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

On Oct 21, 2015, at 1:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:

Folks,

Several of the remaining TLS 1.3 issues hav= e to do with the
ClientHello/HelloRetryRequest interaction. = To recap, if the
ClientHello does not contain a KeyShare wit= h an acceptable group, the
server sends a HelloRetryRequest indicating= the correct group,
and the client sends a ClientHello with the= correct group:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Server
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHel= lo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ = KeyShare =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<-------- =C2=A0 =C2=A0 =C2=A0 HelloRetryRequest
=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHel= lo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ = KeyShare =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0ServerHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 + KeyShare
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...


DTLS has a very similar mechanism where the= server provides a
HelloVerifyRequest containing a cookie in o= rder to force the client to
provide proof of routabilty at its claimed = address. The client
re-sends the ClientHello with the cookie an= d the handshake restarts.

It seems natural to try to merge these mech= anisms, but this raises
the question of whether the handshake hashe= s should continue through
the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104).
The tension here is that you want to be abl= e to have a=C2=A0stateless
rejection (to avoid DoS in the DTLS scenari= o) but having things
makes it much harder to analyze the handsha= ke's resistance to
downgrade attacks.

Recently, Karthik, Martin Thomson, and I we= re talking and I think we've
come to a good resolution. The basic observ= ation is that it's possible
to continue the handshake hash through the = rejection exchange while
still being=C2=A0stateless. We= are aware of two main techniques here:

- The server offloads its handshake hash=C2= =A0state=C2=A0into the cookie
=C2=A0 it provides in the HelloRetryRequest= (we'll need the cookie here
=C2=A0 in any case to support the DTLS case= . The cookie obviously needs
=C2=A0 to be cryptographically protected, b= ut that's what you're supposed
=C2=A0 to do for DTLS anyway
=C2=A0 (see:=C2=A0https://tools.ietf.org/html/rfc6347#section-4.2.1)

- The server reconstructs the original Clie= ntHello and HelloRetryRequest
=C2=A0 based on the re-sent ClientHello. Th= is is possible because there are
=C2=A0 very strict rules about re-sent Clie= ntHello construction
=C2=A0 (namely: send the same ClientHello e= xcept just add a KeyShareEntry
=C2=A0 for the indicated group). The cookie= should also allow the server
=C2=A0 to double-check this (and will also = need to indicate the reason
=C2=A0 for rejection).

Because the handshake hash is continued thr= ough the entire handshake,
it's much easier to analyze the downgra= de properties. Moreover,
servers which don't need=C2=A0sta= teless=C2=A0reject (because there is some
other connection construct as with TLS over= TCP or DTLS with
ICE) don't need either of these techniq= ues. They can just continue
the handshake hash in the usual way.

This seems like it fulfills both imperative= s, at the primary cost of
some additional complexity on servers who r= eally care about
statelesness (the client is indifferent to = the server's implementation
strategy).

If this sounds good to people, I'll wor= k up a PR for this, but
really all it is is saying that you don'= ;t reset the hash and
then a non-normative appendix describing=C2= =A0stateless=C2=A0implementation
techniques.

Thoughts? Does anyone see anything wrong wi= th this?
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--94eb2c0859d66384500522a165f5-- From nobody Wed Oct 21 11:22:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA62B1A88F6 for ; Wed, 21 Oct 2015 11:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 BksciwtlIpfv for ; Wed, 21 Oct 2015 11:22:14 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007CE1A88D8 for ; Wed, 21 Oct 2015 11:22:12 -0700 (PDT) Received: from pc1 (0x3ec7a59f.inet.dsl.telianet.dk [::ffff:62.199.165.159]) (AUTH: LOGIN hanno-default@schokokeks.org, SSL: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 21 Oct 2015 20:22:09 +0200 id 0000000000000043.000000005627D7D1.00005F43 Date: Wed, 21 Oct 2015 20:22:59 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20151021202259.276f1a56@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-24387-1445451730-0001-2" Archived-At: Subject: Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 18:22:17 -0000 X-List-Received-Date: Wed, 21 Oct 2015 18:22:17 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-24387-1445451730-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not sure if I'm getting anything wrong, but doesn't this open a huge security hole? Scenario right now is that if I want to be secure on a webpage I type in its HTTPS URL (either directly or through a bookmark) and can be pretty much sure that as long as I don't click on external links that I'll stay on that webpage. Basically this proposal would allow a man-in-the-middle to send me to another webpage each time I click on a (supposedly https protected) link. Given that there are many browsers these days (mobile) that hide the URL bar thats even more severe. This severely changes the security expectations one can have from a browser. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-24387-1445451730-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWJ9gDAAoJEKWIAHK7tR5CZfoQAIYet+yiimyTcvJL/RK/hxnp mPyEnzQ5d8kLpxnrHANQluZDRmCbFwtibZzAw2jwRrJUqMXflLaBVuleVrSyLTqS jMA5zuroLUcNhj4Umyl+avTYfFk+H51LUU1FHTQbsAoe5TsbCcT/pSJibwQlLSC8 hy0Kw5BhDGCkseWf6ASaX5tllg9AYEokXT0Mm4xqP/7g7agEfnSKfMBfNPnL6xqC iL39cyyKND3sa1yAgH5Bk6cEjITaFvPA4eyPUT36Koet0dByh0xvXQBgcpLWsqt1 zX+KUoE0iGcmaVeYr41IviTcOPTet5eP3QxAsK0rPUmKrgAH6gzuinHhFLUsoBNP ChWVJ0Y0LnfpK0W1WWhKYWpw0xID0k1W8H2bpxmLpDKlxy9xGCnwYGfhnXUzhkwV le6z3vS45UIqd7K6jjWr7IVi9Q6MlpqPlr3ppKr0AM0fmCnzYHrhvDnhVdpbQJVD kdM7a8DNEPrwWnEMxPDjQNEYvdL6STl7e62tlDjdOkvQ8HTGnSOj8gFN+jOtoM0a U+XuZcrUjBVn8AyRJ3dpOI/3RutH0cOooBv0K+jY/qFh3VQ6ZHzAiT/+Mq/d5+Iu kf+A66dzhOFV6//DMqhtR/qxR0LcxUMihaTOhmRdfsoazwTCMSDy2+w2mABzBG1M N7E8EtVuRY6zjUB7Hrvr =1AUi -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-24387-1445451730-0001-2-- From nobody Wed Oct 21 12:03:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7569E1AC424 for ; Wed, 21 Oct 2015 12:03:52 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCzgAMEFLIru for ; Wed, 21 Oct 2015 12:03:51 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 3A23F1AC401 for ; Wed, 21 Oct 2015 12:03:51 -0700 (PDT) Received: by wicfv8 with SMTP id fv8so89197820wic.0 for ; Wed, 21 Oct 2015 12:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y6R7I9b0+s+nQsEA3SEeHWkDid9qdG3j7dvkBrIpEe4=; b=FkMkMxt+CSdaJcTzkE36H3cF72hjm1bbPbaGo2GEfldnLK43upuxbVqb4sO46S3gAQ 4SSgQ5iKArz5p8pVN3ITN9AoMOBNu1+xNaIJAiXxRX7S+3oVyGONSsQsOznuR6lk66vR NJKs9m52qylKtZ6u08NolJ1W9ZPY4mLdZPrOVPS8/SfksEV2c4IwGsNHz8PdM7hPeun4 xvP3nbVCS5Jt7EDOOJkS2ol/bDp2o5U3lq/Xm/X3+iILLas3V6zi+af5kMNTtAxmxy/G TWUo37EQ0rNFgJ4lt592AFmxFLz6SL6MLjpTcKjQE4mXoIk7r9HieYO9kCx9Y0dl9N3M 2hog== X-Received: by 10.194.236.3 with SMTP id uq3mr12855758wjc.22.1445454229878; Wed, 21 Oct 2015 12:03:49 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id uj4sm12126843wjc.34.2015.10.21.12.03.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Oct 2015 12:03:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Wed, 21 Oct 2015 22:03:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56265EF6.2010908@akamai.com> <5627B995.6080803@akamai.com> To: "Short, Todd" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 19:03:52 -0000 > On 21 Oct 2015, at 9:03 PM, Short, Todd wrote: >=20 > I agree with Ben here. This is very much application-layer (HTTPS) = functionality being pushed down into the security (TLS) layer. In fairness, if the TLS layer is blocking you, you don=E2=80=99t get to = talk to the HTTP layer. So the captive portal intercept case has to be = solved at the TLS layer or lower still. Yoav From nobody Wed Oct 21 12:15:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4C11ACDE0 for ; Wed, 21 Oct 2015 12:15:29 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76FZhP2KbsnM for ; Wed, 21 Oct 2015 12:15:26 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002: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 C6F091ACDD7 for ; Wed, 21 Oct 2015 12:15:25 -0700 (PDT) Received: by ykaz22 with SMTP id z22so60168635yka.2 for ; Wed, 21 Oct 2015 12:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8m5nkaMiJWPCZu2w9QTrUNsdGUd4YAWbRHYuduZegPs=; b=ARMQXHr1Al8l54vgtHUuKVxNj5lJ9+wlPWird+i39YPKHxzU6cOqv7aGjLFKDnsBpB mpkJAHCZs2zTR9ekHc+IKYkAT/N7g7SwRRHEysaNxFQnLdP9yVaaeoMbDplL9XS+L/Or Lywjb6j1+8Hrq3MnfS3uNCcZ+5448yykFgY4iI7ru11S8hlgfUhdst5mgf4U+DD4XXQi JNCfzcTFQOQhm5aUdOSKrnfTE5t3rfF+/qVuWlG0pLqm/Bt7Hh+SEB9C2TyjI0PWE5yY /LmHkllHIiQG+DOpkrjAVqtfmjVfw2KCLkt56yBFIAa8nQHm4YMvh3pAvdiYKVoRB58T RulA== MIME-Version: 1.0 X-Received: by 10.13.255.194 with SMTP id p185mr8788673ywf.207.1445454925099; Wed, 21 Oct 2015 12:15:25 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 12:15:25 -0700 (PDT) Date: Wed, 21 Oct 2015 12:15:25 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 19:15:29 -0000 The current draft permits the use of SHA-1 in the certificate chain, which gives SHA-1 a free pass indefinitely. Since we expressly forbid the use of SHA-1 for signing in TLS itself, we can just permit clients to include it in "signature_algorithms" and use that to determine whether SHA-1 is acceptable. That means that clients that want to disable SHA-1 (real soon now, we promise), can signal that preference cleanly. I've opened PR #317 for this, but the commit is probably more useful to review, since I built this on top of ekr's client authentication changes (to avoid messy rebases): https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 From nobody Wed Oct 21 12:18:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BC41ACDF1 for ; Wed, 21 Oct 2015 12:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5XEw51uTIlT for ; Wed, 21 Oct 2015 12:18:24 -0700 (PDT) Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) (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 1493F1ACDED for ; Wed, 21 Oct 2015 12:18:24 -0700 (PDT) Received: by ykaz22 with SMTP id z22so60256638yka.2 for ; Wed, 21 Oct 2015 12:18:23 -0700 (PDT) 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-type; bh=m1VvhneBgbVr2/j8sH9qkk+U/wAC7mUY+ERb8XwhFIY=; b=kgRYEmIorDy+t66+BeSqV9prjRyZF3zXQ/bQrsEpGLnW0am/Ldj3jEQi6OO1y0W306 m0n5w/ued2pVynmF9mVEQs4NVHSgY4Qc06vRsNAojrMDsD+qqurK+Mn6liFt13Mp2L7c pebKChhmukychrqyDa+BN/+OuJUXUp42bfaY0Ee3zugIqKm6lFUQxDgFlMeqOVm9dVbN 6aI8s6BSf+fS6RmZL1eOs6/nyacVS+objML0me8/xfdCIuMOqzRFpe70abZK6GnS81vD eIDPVrMhFsdZeZqnzT2As17GE1UUyXNkvvJVHhfpXQ/rHOgydv5V8NeCTsQIOT+6a/Ma 4ZGg== X-Gm-Message-State: ALoCoQkQysXOKo2qtKYo0KmZCjYzjUrE30mObyzHUeNoDhYs99q25IuiQt4iMQk3pxHqwzARJfUD X-Received: by 10.13.198.132 with SMTP id i126mr9159000ywd.192.1445455103322; Wed, 21 Oct 2015 12:18:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 12:17:44 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 21 Oct 2015 12:17:44 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e491ef91eaa0522a23d50 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 19:18:25 -0000 --001a114e491ef91eaa0522a23d50 Content-Type: text/plain; charset=UTF-8 I think this is the right answer and parallels what we are doing with PSS. -Ekr On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson wrote: > The current draft permits the use of SHA-1 in the certificate chain, > which gives SHA-1 a free pass indefinitely. Since we expressly forbid > the use of SHA-1 for signing in TLS itself, we can just permit clients > to include it in "signature_algorithms" and use that to determine > whether SHA-1 is acceptable. > > That means that clients that want to disable SHA-1 (real soon now, we > promise), can signal that preference cleanly. > > I've opened PR #317 for this, but the commit is probably more useful > to review, since I built this on top of ekr's client authentication > changes (to avoid messy rebases): > > > https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114e491ef91eaa0522a23d50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is the right answer and parallels what we are= doing with PSS.

-Ekr


On Wed, Oct 21= , 2015 at 12:15 PM, Martin Thomson <martin.thomson@gmail.com>= ; wrote:
The current draft permits= the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine=
whether SHA-1 is acceptable.

That means that clients that want to disable SHA-1 (real soon now, we
promise), can signal that preference cleanly.

I've opened PR #317 for this, but the commit is probably more useful to review, since I built this on top of ekr's client authentication
changes (to avoid messy rebases):

https://g= ithub.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb= 1f82aa5

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

--001a114e491ef91eaa0522a23d50-- From nobody Wed Oct 21 12:29:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77F51B2D30 for ; Wed, 21 Oct 2015 12:29:21 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrzYXzkqCfG7 for ; Wed, 21 Oct 2015 12:29:20 -0700 (PDT) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8C81B2D1C for ; Wed, 21 Oct 2015 12:29:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 32A2721C144; Wed, 21 Oct 2015 22:29:19 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id OPIan4BAuqkt; Wed, 21 Oct 2015 22:29:19 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 0523B5BC008; Wed, 21 Oct 2015 22:29:19 +0300 (EEST) Date: Wed, 21 Oct 2015 22:29:17 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151021192917.GA4832@LK-Perkele-V2.elisa-laajakaista.fi> References: <82CE84ED-F9FF-4B93-B15B-46DD1F2C3BC3@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HelloRetryRequest and stateless reject X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 19:29:21 -0000 On Wed, Oct 21, 2015 at 11:17:10AM -0700, Eric Rescorla wrote: > On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd wrote: > > > I like the idea. If the functionality is to be merged, perhaps harmonizing > > the names and contents of the messages (if possible)? > > > > Yes. My plan is to name it HelloRetryRequest and get rid of > HelloVerifyRequest. Bit crazy idea: Have vector of causes handshake went wrong (e.g. required share missing, cookie required). Then the client verifies that that: - There is at least one cause - All causes are known (can't retry with unknown error) - All causes are proper (e.g. actual missing share). -Ilari From nobody Wed Oct 21 12:35:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4831B2D7F for ; Wed, 21 Oct 2015 12:35:53 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIwuAhsvWb4E for ; Wed, 21 Oct 2015 12:35:52 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::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 370A71B2D70 for ; Wed, 21 Oct 2015 12:35:52 -0700 (PDT) Received: by ykba4 with SMTP id a4so54445510ykb.3 for ; Wed, 21 Oct 2015 12:35: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:date:message-id:subject:from:to :cc:content-type; bh=luL1G7qQRE8r7J6epuyRobiWZZbqcb9JOgyz/90clYo=; b=WGXoZcFFGmt5RWMfnIq4yhLxWVu9gl4770y4ssp8MUicm8B6FNBgztiLa7W0fVbKfx FEmRsjVSBrjErK7IZkU5r7cTeDd58uDBEPfRZLkVTaFdI0ufJt+tPU65JkmMVAEDY5t3 /gFyLarRqHt2h3M8d44hrBVeQpJJAmlZhG6GI0irFXT/c2XPikbUERr26/p1qvF08RAr /yxCz29E9X1aQz419h8hfPzqr/6pjBtCwnZ30NFLYwLyaHuK439GZOJuZQ+KS3OoiUxB qrOD9K56g7KLeVo/xwtDO8aRreQTUU3bfe6rvK2owW3PHloor6E/iN+KqZ2BzrNA72ot cfOg== MIME-Version: 1.0 X-Received: by 10.13.255.194 with SMTP id p185mr8879575ywf.207.1445456151424; Wed, 21 Oct 2015 12:35:51 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 12:35:51 -0700 (PDT) In-Reply-To: <20151021192917.GA4832@LK-Perkele-V2.elisa-laajakaista.fi> References: <82CE84ED-F9FF-4B93-B15B-46DD1F2C3BC3@akamai.com> <20151021192917.GA4832@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 21 Oct 2015 12:35:51 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HelloRetryRequest and stateless reject X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 19:35:54 -0000 On 21 October 2015 at 12:29, Ilari Liusvaara wrote: > Bit crazy idea: Have vector of causes handshake went wrong > (e.g. required share missing, cookie required). Then the > client verifies that that: > - There is at least one cause > - All causes are known (can't retry with unknown error) > - All causes are proper (e.g. actual missing share). The client doesn't need this information, though the server might. That is, if it doesn't want to try several options to see which one passes the MAC, noting that there aren't that many options. Given that, I don't think we need to specify anything. Note that absence of cookie is the only valid starting state, so you don't need a bit for that. From nobody Wed Oct 21 12:45:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D581ACE30 for ; Wed, 21 Oct 2015 12:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB6VFX_jvAEz for ; Wed, 21 Oct 2015 12:45:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDF21ACE2A for ; Wed, 21 Oct 2015 12:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/3B6tXlsupVK3t2qR9+MkvThR6+OgKHXyb4jY59q1G4=; b=fS9pVlwGsD4PZcOLQZ8QF8Y0BKSs6p1J3+/kDsvXetLGNibipQqMPJByj42gOvvoJTgpGR9njb3lrX8j6nxK+Egtq1GkkXyDStuH+g5t7KrHoECAbzza0sG5NwOdyHtfgZoz+RMr99llpt7gWudfq1TZKTXMMVSClba7/WKMHls= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.300.14; Wed, 21 Oct 2015 19:45:38 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0300.010; Wed, 21 Oct 2015 19:45:38 +0000 From: Andrei Popov To: Eric Rescorla , Martin Thomson Thread-Topic: [TLS] Controlling use of SHA-1 Thread-Index: AQHRDDTgCaDFXiqkoUS7K1KHgIgBG552UekAgAAEfvA= Date: Wed, 21 Oct 2015 19:45:38 +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-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:rzaz/5x4GUJhW1a/+nVkFJeVEXHdadzEPZMEdhGmCp+vhBYoR+4g2zgX9bBcAFr5aMRuy/l2qdT55W1b2Ouve+MfhNofKf2mQlKISBNt7YzUp56kAbakUyTaT3AuONFz4y98TBDLCAGh7Jn0FTSp5g==; 24:hj0rtAVSTnBkUi7vTN2D4s+ve/XDycBQ1L+9ypsaNPlFGXtiIgBluUdMd+r9jLm1igF5HcwoZifg/D4MVAYNdj5cbebx62b+DYYiEXtWZhE=; 20:cHWiOLr2B6qxFde3uAj4IQYpV/Et0E0kY3vM/7BzlcBqXe6AdQK6fWMVWPuNpbQAUpMlC9selDMej0A5GfyEXg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102115026)(61426024)(61427024); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(189002)(377454003)(5004730100002)(5002640100001)(19580405001)(5001960100002)(5007970100001)(5003600100002)(101416001)(122556002)(19625215002)(8990500004)(10090500001)(11100500001)(189998001)(10290500002)(2950100001)(10400500002)(2900100001)(5005710100001)(92566002)(33656002)(105586002)(40100003)(99286002)(16236675004)(76176999)(106356001)(50986999)(46102003)(106116001)(54356999)(76576001)(86612001)(86362001)(19580395003)(74316001)(5008740100001)(19609705001)(19300405004)(102836002)(81156007)(5001770100001)(97736004)(15975445007)(77096005)(19617315012)(87936001)(64706001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13966D29B6F17A7E8B33F9288C380BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2015 19:45:38.0404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 19:45:44 -0000 --_000_BLUPR03MB13966D29B6F17A7E8B33F9288C380BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBpbiBmYXZvciBvZiB0aGlzIGNoYW5nZTogaXQgcHJvaGliaXRzIHRoZSBzZXJ2ZXIgdG8g c2VuZCBTSEEtMSBjZXJ0cyB3aGVuIHNpZ25hdHVyZV9hbGdvcml0aG1zIGRvZXMgbm90IGFkdmVy dGlzZSBTSEEtMS4NCg0KSU1ITyBpdCB3b3VsZCBiZSBiZXN0IHRvIG5vdCBhbGxvdyB0aGUgc2Vy dmVyIHRvIHNlbmQgY2VydHMgdXNpbmcgYW55IGFsZ29yaXRobXMgdGhhdCBkb27igJl0IGFncmVl IHdpdGggc2lnbmF0dXJlX2FsZ29yaXRobXMsIGFzIFRMUyAxLjIgZGlkLiBCdXQgdGhpcyBpcyBh IHN0ZXAgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJv bTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJl c2NvcmxhDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjEsIDIwMTUgMTI6MTggUE0NClRvOiBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KQ2M6IHRsc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtUTFNdIENvbnRyb2xsaW5nIHVzZSBvZiBTSEEtMQ0KDQpJIHRoaW5r IHRoaXMgaXMgdGhlIHJpZ2h0IGFuc3dlciBhbmQgcGFyYWxsZWxzIHdoYXQgd2UgYXJlIGRvaW5n IHdpdGggUFNTLg0KDQotRWtyDQoNCg0KT24gV2VkLCBPY3QgMjEsIDIwMTUgYXQgMTI6MTUgUE0s IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhlIGN1cnJlbnQgZHJhZnQgcGVybWl0cyB0aGUg dXNlIG9mIFNIQS0xIGluIHRoZSBjZXJ0aWZpY2F0ZSBjaGFpbiwNCndoaWNoIGdpdmVzIFNIQS0x IGEgZnJlZSBwYXNzIGluZGVmaW5pdGVseS4gU2luY2Ugd2UgZXhwcmVzc2x5IGZvcmJpZA0KdGhl IHVzZSBvZiBTSEEtMSBmb3Igc2lnbmluZyBpbiBUTFMgaXRzZWxmLCB3ZSBjYW4ganVzdCBwZXJt aXQgY2xpZW50cw0KdG8gaW5jbHVkZSBpdCBpbiAic2lnbmF0dXJlX2FsZ29yaXRobXMiIGFuZCB1 c2UgdGhhdCB0byBkZXRlcm1pbmUNCndoZXRoZXIgU0hBLTEgaXMgYWNjZXB0YWJsZS4NCg0KVGhh dCBtZWFucyB0aGF0IGNsaWVudHMgdGhhdCB3YW50IHRvIGRpc2FibGUgU0hBLTEgKHJlYWwgc29v biBub3csIHdlDQpwcm9taXNlKSwgY2FuIHNpZ25hbCB0aGF0IHByZWZlcmVuY2UgY2xlYW5seS4N Cg0KSSd2ZSBvcGVuZWQgUFIgIzMxNyBmb3IgdGhpcywgYnV0IHRoZSBjb21taXQgaXMgcHJvYmFi bHkgbW9yZSB1c2VmdWwNCnRvIHJldmlldywgc2luY2UgSSBidWlsdCB0aGlzIG9uIHRvcCBvZiBl a3IncyBjbGllbnQgYXV0aGVudGljYXRpb24NCmNoYW5nZXMgKHRvIGF2b2lkIG1lc3N5IHJlYmFz ZXMpOg0KDQpodHRwczovL2dpdGh1Yi5jb20vbWFydGludGhvbXNvbi90bHMxMy1zcGVjL2NvbW1p dC8zNTQ0NzVjZjAyODE5YTljYzgwODQ1N2YyYzA5ZmRhZWIxZjgyYWE1PGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZ2l0aHVi LmNvbSUyZm1hcnRpbnRob21zb24lMmZ0bHMxMy1zcGVjJTJmY29tbWl0JTJmMzU0NDc1Y2YwMjgx OWE5Y2M4MDg0NTdmMmMwOWZkYWViMWY4MmFhNSZkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3Yl NDBtaWNyb3NvZnQuY29tJTdjYTUwYTk1ZTM2NWVkNDRkN2EzYmQwOGQyZGE0YzY3ZDclN2M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Y0Y1VGFlc1VaRTJDQlpBUng0 VXdabWR3VjIwSzZiJTJiUlZuMmhHSXUzY09rJTNkPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3Jn PG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RsczxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZk YXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjYTUwYTk1ZTM2NWVk NDRkN2EzYmQwOGQyZGE0YzY3ZDclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 YzEmc2RhdGE9V1B1aWxQamRqQ2h3TDR5bTV4UHVoSDdWaG80cXNQT000S1FXcGtDcjJ0OCUzZD4N Cg0K --_000_BLUPR03MB13966D29B6F17A7E8B33F9288C380BLUPR03MB1396namp_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBh bSBpbiBmYXZvciBvZiB0aGlzIGNoYW5nZTogaXQgcHJvaGliaXRzIHRoZSBzZXJ2ZXIgdG8gc2Vu ZCBTSEEtMSBjZXJ0cyB3aGVuIHNpZ25hdHVyZV9hbGdvcml0aG1zIGRvZXMgbm90IGFkdmVydGlz ZSBTSEEtMS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SU1I TyBpdCB3b3VsZCBiZSBiZXN0IHRvIG5vdCBhbGxvdyB0aGUgc2VydmVyIHRvIHNlbmQgY2VydHMg dXNpbmcgYW55IGFsZ29yaXRobXMgdGhhdCBkb27igJl0IGFncmVlIHdpdGggc2lnbmF0dXJlX2Fs Z29yaXRobXMsIGFzIFRMUyAxLjIgZGlkLiBCdXQgdGhpcyBpcyBhIHN0ZXANCiBpbiB0aGUgcmln aHQgZGlyZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kcmVp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2Jl ciAyMSwgMjAxNSAxMjoxOCBQTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0O21h cnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gQ29udHJvbGxpbmcgdXNlIG9mIFNIQS0xPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGlzIGlzIHRoZSBy aWdodCBhbnN3ZXIgYW5kIHBhcmFsbGVscyB3aGF0IHdlIGFyZSBkb2luZyB3aXRoIFBTUy48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBXZWQsIE9jdCAyMSwgMjAxNSBhdCAxMjoxNSBQTSwgTWFydGluIFRob21zb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY3VycmVudCBkcmFmdCBwZXJt aXRzIHRoZSB1c2Ugb2YgU0hBLTEgaW4gdGhlIGNlcnRpZmljYXRlIGNoYWluLDxicj4NCndoaWNo IGdpdmVzIFNIQS0xIGEgZnJlZSBwYXNzIGluZGVmaW5pdGVseS4gU2luY2Ugd2UgZXhwcmVzc2x5 IGZvcmJpZDxicj4NCnRoZSB1c2Ugb2YgU0hBLTEgZm9yIHNpZ25pbmcgaW4gVExTIGl0c2VsZiwg d2UgY2FuIGp1c3QgcGVybWl0IGNsaWVudHM8YnI+DQp0byBpbmNsdWRlIGl0IGluICZxdW90O3Np Z25hdHVyZV9hbGdvcml0aG1zJnF1b3Q7IGFuZCB1c2UgdGhhdCB0byBkZXRlcm1pbmU8YnI+DQp3 aGV0aGVyIFNIQS0xIGlzIGFjY2VwdGFibGUuPGJyPg0KPGJyPg0KVGhhdCBtZWFucyB0aGF0IGNs aWVudHMgdGhhdCB3YW50IHRvIGRpc2FibGUgU0hBLTEgKHJlYWwgc29vbiBub3csIHdlPGJyPg0K cHJvbWlzZSksIGNhbiBzaWduYWwgdGhhdCBwcmVmZXJlbmNlIGNsZWFubHkuPGJyPg0KPGJyPg0K SSd2ZSBvcGVuZWQgUFIgIzMxNyBmb3IgdGhpcywgYnV0IHRoZSBjb21taXQgaXMgcHJvYmFibHkg bW9yZSB1c2VmdWw8YnI+DQp0byByZXZpZXcsIHNpbmNlIEkgYnVpbHQgdGhpcyBvbiB0b3Agb2Yg ZWtyJ3MgY2xpZW50IGF1dGhlbnRpY2F0aW9uPGJyPg0KY2hhbmdlcyAodG8gYXZvaWQgbWVzc3kg cmViYXNlcyk6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZnaXRodWIuY29tJTJmbWFydGlu dGhvbXNvbiUyZnRsczEzLXNwZWMlMmZjb21taXQlMmYzNTQ0NzVjZjAyODE5YTljYzgwODQ1N2Yy YzA5ZmRhZWIxZjgyYWE1JmFtcDtkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3Nv ZnQuY29tJTdjYTUwYTk1ZTM2NWVkNDRkN2EzYmQwOGQyZGE0YzY3ZDclN2M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWNGNVRhZXNVWkUyQ0JaQVJ4NFV3Wm1k d1YyMEs2YiUyYlJWbjJoR0l1M2NPayUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHVi LmNvbS9tYXJ0aW50aG9tc29uL3RsczEzLXNwZWMvY29tbWl0LzM1NDQ3NWNmMDI4MTlhOWNjODA4 NDU3ZjJjMDlmZGFlYjFmODJhYTU8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmdGxzJmFtcDtkYXRh PTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjYTUwYTk1ZTM2NWVkNDRk N2EzYmQwOGQyZGE0YzY3ZDclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm YW1wO3NkYXRhPVdQdWlsUGpkakNod0w0eW01eFB1aEg3VmhvNHFzUE9NNEtRV3BrQ3IydDglM2Qi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BLUPR03MB13966D29B6F17A7E8B33F9288C380BLUPR03MB1396namp_-- From nobody Wed Oct 21 12:56:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B15D1ACE9B for ; Wed, 21 Oct 2015 12:56:12 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4dMiPieA-0r for ; Wed, 21 Oct 2015 12:56:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB6A1ACE1F for ; Wed, 21 Oct 2015 12:56:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 35AED284DA6; Wed, 21 Oct 2015 19:56:09 +0000 (UTC) Date: Wed, 21 Oct 2015 19:56:09 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151021195608.GO15070@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 21 Oct 2015 19:56:12 -0000 On Wed, Oct 21, 2015 at 12:15:25PM -0700, Martin Thomson wrote: > The current draft permits the use of SHA-1 in the certificate chain, > which gives SHA-1 a free pass indefinitely. Forbidding the sending of SHA-1 chains was wrong last time we discussed this at length, and remains wrong now. Whether SHA-1 in the chain is used to make trust decisions is only known to the client, and the server MUST NOT preempt that by denying the client access to whatever chain it has on hand. Each peer MUST try to send a chain that matches an advertised signature algorithm if it has a choice of chains, but otherwise MUST send whatever it has. > That means that clients that want to disable SHA-1 (real soon now, we > promise), can signal that preference cleanly. The clients can indeed not signal SHA-1 support, and SHOULD avoid trusting SHA-1, but the server MUST still send whatever chain it has and let the client decide. > I've opened PR #317 for this, but the commit is probably more useful > to review, since I built this on top of ekr's client authentication > changes (to avoid messy rebases): > > https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 The final diff "hunk" is dejavu-all-over-again. This text must stay unchanged. indicated supported pairs, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain MAY -use the deprecated SHA-1 hash algorithm. +use the deprecated SHA-1 hash algorithm only if the "signature_algorithms" +extension provided by the client permits it. If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST send an "unsupported_certificate" alert message and close the connection. So, no to the diff above. -- Viktor. From nobody Wed Oct 21 13:11:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B001B2CF8 for ; Wed, 21 Oct 2015 13:11:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9ifdx2GX1te for ; Wed, 21 Oct 2015 13:11:35 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 B38A91B2BA3 for ; Wed, 21 Oct 2015 13:11:35 -0700 (PDT) Received: by ykba4 with SMTP id a4so55491884ykb.3 for ; Wed, 21 Oct 2015 13:11: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:date:message-id:subject:from:to :content-type; bh=bnZBqoYswQ+4vknyb6p1bjUHQtMRl5xE2p/jTS46rsg=; b=t8ZYlxLuUjlKSpbuWKmWrecSAmk4R/7nxaLvuXPPqEyJ38J3dhEcJIoS9BlzXnsooh npTtbbN1BpDIQterPAIMNK4jvlZub0DubdpyS/Smt/BK+zhvcXC/+i2rISwO6uZvidOX bp9na2b6JWjB+6ZhLGtwYvKJe78MgTAt9c5/Ual5KIp8HMkv+nXnTZFP13jOmT709Ckh 6HxE6m1h+SKZ8YnlyPLnBGYva2zoc+WSalRXJdYalo6hvUR8OaioXKN0quJjtdM5ZKWi 32jXZjICEfBMh0LhFiWfw5zkBd4XqhWoAtGCkepPl5uiNEF7cu30pCbfw/RTupBRJhqc sRNg== MIME-Version: 1.0 X-Received: by 10.13.196.196 with SMTP id g187mr8947718ywd.98.1445458295074; Wed, 21 Oct 2015 13:11:35 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 13:11:35 -0700 (PDT) In-Reply-To: <20151021195608.GO15070@mournblade.imrryr.org> References: <20151021195608.GO15070@mournblade.imrryr.org> Date: Wed, 21 Oct 2015 13:11:35 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 20:11:37 -0000 On 21 October 2015 at 12:56, Viktor Dukhovni wrote: > Each peer MUST try to send a chain that matches an advertised > signature algorithm if it has a choice of chains, but otherwise > MUST send whatever it has. Do, or do not. There is no try. It's not like any of this is ambiguous in any way. From nobody Wed Oct 21 13:43:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8461B2BB2; Wed, 21 Oct 2015 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qjOGeqWfvPS; Wed, 21 Oct 2015 13:43:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A63A31B2BB1; Wed, 21 Oct 2015 13:43:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0CECD18046A; Wed, 21 Oct 2015 13:43:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151021204320.0CECD18046A@rfc-editor.org> Date: Wed, 21 Oct 2015 13:43:20 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 20:43:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7685 Title: A Transport Layer Security (TLS) ClientHello Padding Extension Author: A. Langley Status: Standards Track Stream: IETF Date: October 2015 Mailbox: agl@google.com Pages: 4 Characters: 7034 Updates: RFC 5246 I-D Tag: draft-ietf-tls-padding-04.txt URL: https://www.rfc-editor.org/info/rfc7685 DOI: http://dx.doi.org/10.17487/RFC7685 This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Oct 21 14:04:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2641B3083; Wed, 21 Oct 2015 14:04:05 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I93DFIwhBKZV; Wed, 21 Oct 2015 14:04:04 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 625151B3082; Wed, 21 Oct 2015 14:04:04 -0700 (PDT) Received: by yknn9 with SMTP id n9so62892610ykn.0; Wed, 21 Oct 2015 14:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h+EUP0vgxhsFo2Hvb5obYf03/v6MEuv+8R24fP9e/nw=; b=mwD2IUiqxbUDPV1Ifu04KSvD4/MVaoXFvubuDaouqBYSKfJlbf24sjAAV5OHijy9Gu 220gy2F0TymZN1xXlMTvHc2AdgmKmKVI65ZrZfj/52pUtpQrWMfiLDpW4bchHHdn1Ijq MS0Tw/q47sircGRf4wbUN7/ARn6wQEtV+iXnBD5EFrZKqj4JHBvBS1e4DL8JhM0S3JMM HQUZue3WN6zw7qKggfzZX2NrLm0/ReVPNFKpT6Q+8Gay2mAEhVAHFzHy+c+FmpnZ5v/M V0St57M5iq3st2b6hvOdUKJl+yApWphs5x/AocC6IU62rjGE4e4k7wbUtqoqzPj2qlwJ sevw== MIME-Version: 1.0 X-Received: by 10.13.230.201 with SMTP id p192mr3723640ywe.43.1445461443631; Wed, 21 Oct 2015 14:04:03 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 14:04:03 -0700 (PDT) In-Reply-To: <20151021204320.0CECD18046A@rfc-editor.org> References: <20151021204320.0CECD18046A@rfc-editor.org> Date: Wed, 21 Oct 2015 14:04:03 -0700 Message-ID: From: Martin Thomson To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: drafts-update-ref@iana.org, rfc-dist@rfc-editor.org, "tls@ietf.org" , ietf-announce@ietf.org Subject: Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 21:04:05 -0000 On 21 October 2015 at 13:43, wrote: > RFC 7685 > > Title: A Transport Layer Security (TLS) > ClientHello Padding Extension That took longer than I expected. Nice work. From nobody Wed Oct 21 14:40:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387F21B3193 for ; Wed, 21 Oct 2015 14:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGCcW-Xpm6bd for ; Wed, 21 Oct 2015 14:40:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABFF1B318C for ; Wed, 21 Oct 2015 14:40:20 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-10-562799869c35 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 93.8F.26730.68997265; Wed, 21 Oct 2015 15:56:22 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Wed, 21 Oct 2015 17:40:18 -0400 From: Daniel Migault To: "tls@ietf.org" Thread-Topic: New Version Notification for draft-cairns-tls-session-key-interface-01.txt Thread-Index: AQHRCqA6FASBcLoVr0Od5v3ZQJ4nxZ52dwAA Date: Wed, 21 Oct 2015 21:40:17 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C11217CE42@eusaamb107.ericsson.se> References: <20151019185900.23693.37549.idtracker@ietfa.amsl.com> In-Reply-To: <20151019185900.23693.37549.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPuG7bTPUwg0m7dCw2HvjBYvHpfBej A5PHkiU/mTwu939gCmCK4rJJSc3JLEst0rdL4MpoXr2TsWCKbMX/CxUNjFtkuhg5OSQETCTe b1jKAmGLSVy4t56ti5GLQ0jgKKNE++WnLBDOckaJGwv2soNUsQkYSbQd6gezRQQUJXZc7Qaz mQUqJe78+sUMYgsLREq8u/iGCaImSuLr3fOMELaRxJOJx8FqWARUJR7vmQdWwyvgKzHp2w6w OUICjhI9K86DXcQp4CSx+3ATmM0IdN33U2uYIHaJS9x6Mp8J4moBiSV7zjND2KISLx//Y4Ww lSTmvL4GFOcAqteUWL9LH6JVUWJK90N2iLWCEidnPmGZwCg2C8nUWQgds5B0zELSsYCRZRUj R2lxalluupHhJkZghByTYHPcwbjgk+UhRgEORiUe3gceamFCrIllxZW5hxglOJiVRHij3quH CfGmJFZWpRblxxeV5qQWH2KU5mBREuedN+N+qJBAemJJanZqakFqEUyWiYNTqoFx55KcWxt4 VRQuqov4vz878YNYWNCjjukc7X/XBkqtcVVzYd3pMHMG1/FTXmbMZg9XvzxslTV9n/ptyyCT Vbc7P0/r1HBYMO91sfUtpUkCJa9L0tLmTb4XmWY9r+d41e64+ctFs2QvcCx5dKei7PisCLaA c15tTT+ULNg2mPxfpL5/t0Fn6U57JZbijERDLeai4kQAwk7hQIwCAAA= Archived-At: Cc: Robert Skog , Kelsey Cairns Subject: Re: [TLS] New Version Notification for draft-cairns-tls-session-key-interface-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 21:40:22 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBvdXIgbmV3IHZlcnNpb24gZnJvbSBvZiB0aGUgU2Vzc2lvbiBL ZXkgSW50ZXJmYWNlIGZvciBUTFMgYW5kIERUTFMuDQoNClRoZSBtYWluIG1vdGl2YXRpb24gZm9y IHRoaXMgaW50ZXJmYWNlIGlzIHRoYXQgdGhlIHByaXZhdGUga2V5IGlzIGNlbnRyYWxpemVkIGlu IGEgS2V5IFNlcnZlciBpbnN0ZWFkIG9mIGJlaW5nIGRpc3RyaWJ1dGVkIGFuZCBjb3BpZWQgYW1v bmcgdGhlIEVkZ2UgU2VydmVycy4gQWxsIGNyeXB0b2dyYXBoaWMgb3BlcmF0aW9uIGFyZSBwZXJm b3JtZWQgYnkgdGhlIEtleSBTZXJ2ZXIgYW5kIHRoZSBFZGdlIFNlcnZlciB1c2VzIHRoaXMgaW50 ZXJmYWNlLiAgIA0KDQpGZWVsIGZyZWUgdG8gY29tbWVudCB0aGUgZHJhZnQgYnV0IGhlcmUgYXJl IHNvbWUgb3VyIGNvbmNlcm5zIGFuZCB3ZSB3b3VsZCBsaWtlIHRvIGtub3cgeW91ciBvcGluaW9u Og0KDQpRVUVTVElPTiAxKSBBbiBpbnRlcmFjdGlvbiBvY2N1cnMgd2hlbiBSU0Egb3IgZXBoZW1l cmFsIERpZmZpZSBIZWxsbWFuIChESEVfUlNBLCBFQ0RIRV9SU0Egb3IgRUNESEVfRUNEU0EpIGtl eSBhZ3JlZW1lbnQgLiBJbiB5b3VyIG9waW5pb24sIHNob3VsZCB3ZSBjb25zaWRlciBSU0E/DQoN ClFVRVNUSU9OIDIpIFdoZW4gRGlmZmllIEhlbGxtYW4gaXMgdXNlZCwgdG8gYnVpbGQgdGhlIHNp Z25hdHVyZSwgdGhlIEVkZ2UgU2VydmVyIHByb3ZpZGVzIGFsbCBwYXJhbWV0ZXJzIHRvIHRoZSBr ZXkgU2VydmVyLCBhbmQgdGhlIEtleSBTZXJ2ZXIgaGFzaGVzIGFuZCBzaWducy4gQW4gYWx0ZXJu YXRpdmUgd291bGQgYmUgdGhlIEVkZ2UgU2VydmVyIGhhc2hlcyBhbmQgcmVxdWVzdHMgdGhlIEtl eSBTZXJ2ZXIgdG8gc2lnbiBpdC4gV2UgYmVsaWV2ZSB0aGUgZmlyc3QgYWx0ZXJuYXRpdmUgaXMg bW9yZSBzZWN1cmUsIGJ1dCB0aGUgc2Vjb25kIGdlbmVyYXRlcyBsZXNzIGxvYWQgb24gdGhlIG5l dHdvcmsgLiBEbyB5b3UgaGF2ZSBhbnkgb3BpbmlvbiByZWdhcmRpbmcgdGhlc2UgdHdvIGFsdGVy bmF0aXZlcy4NCg0KQlIsIA0KRGFuaWVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDE1IDc6NTkgUE0NClRvOiBLZWxz ZXkgQ2Fpcm5zOyBKb2huIE1hdHRzc29uOyBEYW5pZWwgTWlnYXVsdDsgUm9iZXJ0IFNrb2cNClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2Fpcm5zLXRscy1zZXNz aW9uLWtleS1pbnRlcmZhY2UtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWNhaXJucy10bHMtc2Vzc2lvbi1rZXktaW50ZXJmYWNlLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIE1hdHRzc29uIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWNhaXJucy10bHMtc2Vzc2lvbi1rZXktaW50ZXJm YWNlDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJU2Vzc2lvbiBLZXkgSW50ZXJmYWNlIChTS0kpIGZv ciBUTFMgYW5kIERUTFMNCkRvY3VtZW50IGRhdGU6CTIwMTUtMTAtMTkNCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTI0DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNhaXJucy10bHMtc2Vzc2lvbi1rZXktaW50 ZXJmYWNlLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWNhaXJucy10bHMtc2Vzc2lvbi1rZXktaW50ZXJmYWNlLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYWlybnMtdGxzLXNlc3Np b24ta2V5LWludGVyZmFjZS0wMQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1jYWlybnMtdGxzLXNlc3Npb24ta2V5LWludGVyZmFjZS0wMQ0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2Vzc2lvbiBrZXkgaW50 ZXJmYWNlIHRoYXQgY2FuIGJlIHVzZWQgZm9yDQogICBUTFMgYW5kIERUTFMuICBUaGUgSGVhcnRi bGVlZCBhdHRhY2sgaGFzIGNsZWFybHkgaWxsdXN0cmF0ZWQgdGhlDQogICBzZWN1cml0eSBwcm9i bGVtcyB3aXRoIHN0b3JpbmcgcHJpdmF0ZSBrZXlzIGluIHRoZSBtZW1vcnkgb2YgdGhlIFRMUw0K ICAgc2VydmVyLiAgSGFyZHdhcmUgU2VjdXJpdHkgTW9kdWxlcyAoSFNNKSBvZmZlciBiZXR0ZXIg cHJvdGVjdGlvbiBidXQNCiAgIGFyZSBpbmZsZXhpYmxlLCBlc3BlY2lhbGx5IGFzIG1vcmUgKEQp VExTIHNlcnZlcnMgYXJlIHJ1bm5pbmcgb24NCiAgIHZpcnR1YWxpemVkIHNlcnZlcnMgaW4gZGF0 YSBjZW50ZXJzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Oct 21 15:45:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB831B3326 for ; Wed, 21 Oct 2015 15:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY8F9PhaPBtw for ; Wed, 21 Oct 2015 15:44:58 -0700 (PDT) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) (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 BCC5E1B3325 for ; Wed, 21 Oct 2015 15:44:58 -0700 (PDT) Received: by ykba4 with SMTP id a4so59358516ykb.3 for ; Wed, 21 Oct 2015 15:44:58 -0700 (PDT) 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-type; bh=R7VYQ4Mi0iV4Jtwha3WVfG8MZ6/21+2FjX7XnG1dv14=; b=cZCsS8E6oq4K4mQU0EvyBnGN7A1yGc+zmfjhtqtgrFqcY3SnStd8+DVdTKguTtCXFp XUqtw0fTsfyIMijv6oymAW6X8ElheRd4wh7fXxrlojmH1auhDiaO4joS6nuAXbIY+YuB qyh4v4CFapLKiw7vEPpkhgiGewgIk6rw6UVbZmT8QnrqD684lLKNKJyzLz8VWGzNBIYp tkI6tjbt3UQWaEYhaKX6xJuzyPvg3n2U+5FLsxgVByUHyOhnnrb+8l/+ur8sqKxMTz1r nkEg60ezWDPAzzK0p2nfyZ1Jhc91bt2g4tvtWfoiuaS6FmfdagB7mo6lDu9Or822R7mJ kidg== X-Gm-Message-State: ALoCoQkE6nfhmczHVwI41lsGjGTCf32hIgomG+VfbXrIyXWegMYO1J+3ydLYSAF95GoeT/xAuMdi X-Received: by 10.13.216.141 with SMTP id a135mr8730805ywe.12.1445467497876; Wed, 21 Oct 2015 15:44:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 15:44:18 -0700 (PDT) From: Eric Rescorla Date: Wed, 21 Oct 2015 15:44:18 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e488abf1db40522a520d5 Archived-At: Subject: [TLS] Remove extra 0-RTT content types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 22:45:00 -0000 --001a114e488abf1db40522a520d5 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/311 I initially added this to make it easier to determine the end of the 0-RTT handshake if the server had forgotten the key, but with content type encryption this is no longer relevant. I propose we remove this and simply use Handshake here, allowing the keying material to differentiate these. -Ekr --001a114e488abf1db40522a520d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
I initially added this to make it easier to determine the end of= the 0-RTT
handshake if the server had forgotten the key, but wit= h content type encryption
this is no longer relevant. I propose w= e remove this and simply use
Handshake here, allowing the keying = material to differentiate these.

-Ekr
--001a114e488abf1db40522a520d5-- From nobody Wed Oct 21 15:52:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905FA1B334C for ; Wed, 21 Oct 2015 15:52:06 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgdmeMmVYjgJ for ; Wed, 21 Oct 2015 15:52:05 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 16A241B334B for ; Wed, 21 Oct 2015 15:52:05 -0700 (PDT) Received: by ykaz22 with SMTP id z22so65869714yka.2 for ; Wed, 21 Oct 2015 15:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VJqm1omAODeLO7iqRxV5onp1VNhQzx5KI0ZtkrwFccw=; b=gVP9w+EZFORuG/YZpfcfhdzc8KQ1rn1fqbIvWA+u+iZNPDfVFd+rGkrMXstvut9wpa dXB/KmqMh521C+ipJejCbLGks7XcvbRh/F1Tgwmot4ChjvwN5fCWguRqkq0/LAacd7he X6dVRqixcR/iwmdbt8Dns9AsxJYBMV0oVyX0Hu21NDpkNbd2cRHEK1TXO+f+PSu12/kz gaeCpPtQqY3cB8XDeMqAUruYsdPMko9mye0wbSpuyFZP7EODn1A90qT6+Bpm9HXlJL15 dVpTo85gqVVQawgC7HQJH3TEEbnJzkkICnevoQmOClEVTzrVDFVjtKfK1/QLKL8ainZe DGxg== MIME-Version: 1.0 X-Received: by 10.13.230.201 with SMTP id p192mr4064325ywe.43.1445467924399; Wed, 21 Oct 2015 15:52:04 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 15:52:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Oct 2015 15:52:04 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove extra 0-RTT content types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 22:52:06 -0000 I'm not sure that I follow. Are all the records in 0RTT going to use a content of handshake, or just the Certificate/CertificateVerify/Finished? I assume that you meant just the handshake messages, in which case yes, this is OK. It does make identification of what goes into the handshake hash marginally more difficult. With your client authentication changes, you could just concatenate up everything with content type of handshake. Now you have to be a little more selective. On 21 October 2015 at 15:44, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/311 > > I initially added this to make it easier to determine the end of the 0-RTT > handshake if the server had forgotten the key, but with content type > encryption > this is no longer relevant. I propose we remove this and simply use > Handshake here, allowing the keying material to differentiate these. > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Oct 21 15:53:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5951C1B3354 for ; Wed, 21 Oct 2015 15:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woKKFXJbSaVh for ; Wed, 21 Oct 2015 15:53:37 -0700 (PDT) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) (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 B40A51B3355 for ; Wed, 21 Oct 2015 15:53:37 -0700 (PDT) Received: by ykaz22 with SMTP id z22so65900555yka.2 for ; Wed, 21 Oct 2015 15:53:37 -0700 (PDT) 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-type; bh=TGR7K6plcJ+sWUhpVmVRWWNGG9QR5n8ND0aZ+6BN9B0=; b=E9L6RB1t8w9ut4gvzF7SxitgtKoj6wrukjxTQLIGludNCVOEEKnbHkR2IkNnCNCnTJ JIMvDAPKlfoGQWLa2HosmH3GjEjj7Mbx6I1Dx8rDwCjCpb/CbXgGQnMXOf45a1GQn89B 4zD2IH53CGryC6b4vwamVDA89EnOBeD7aCMNZgcvHCklNBzD2PQxvSh+TXjM6bEZMyAa mF2CKUAUnOqBqvXsdciAStIptwUtm1LCXHtPT3aM4PMijzbCFCzgpHBj0nqxd2O7fuce zEapgB0bq376vkulU1EZyNiLyG683AkRftl+ktLEKkO2Q4WvGcOOYaqYv9xS2LNOHT7l lJAQ== X-Gm-Message-State: ALoCoQk6cn8A2HB+hjGSMWybYqekxxeA8qYF+XNwoG662uTdqi4TeyOczQ5z7hxtWjOeEl27iL/9 X-Received: by 10.13.198.132 with SMTP id i126mr9983178ywd.192.1445468017075; Wed, 21 Oct 2015 15:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 15:52:57 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 21 Oct 2015 15:52:57 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e491eb159bc0522a53f71 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove extra 0-RTT content types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 22:53:39 -0000 --001a114e491eb159bc0522a53f71 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 21, 2015 at 3:52 PM, Martin Thomson wrote: > I'm not sure that I follow. Are all the records in 0RTT going to use > a content of handshake, or just the > Certificate/CertificateVerify/Finished? I assume that you meant just > the handshake messages, in which case yes, this is OK. Yes. The application data would be application_data, etc. > It does make > identification of what goes into the handshake hash marginally more > difficult. > > With your client authentication changes, you could just concatenate up > everything with content type of handshake. Now you have to be a > little more selective. I don't think this will make the implementation that hard :) -Ekr On 21 October 2015 at 15:44, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/issues/311 > > > > I initially added this to make it easier to determine the end of the > 0-RTT > > handshake if the server had forgotten the key, but with content type > > encryption > > this is no longer relevant. I propose we remove this and simply use > > Handshake here, allowing the keying material to differentiate these. > > > > -Ekr > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --001a114e491eb159bc0522a53f71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 21, 2015 at 3:52 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
I'm = not sure that I follow.=C2=A0 Are all the records in 0RTT going to use
a content of handshake, or just the
Certificate/CertificateVerify/Finished?=C2=A0 I assume that you meant just<= br> the handshake messages, in which case yes, this is OK.=C2=A0

Yes. The application data would be application_data, etc.=


=C2=A0
It does make
identification of what goes into the handshake hash marginally more
difficult.

With your client authentication changes, you could just concatenate up
everything with content type of handshake.=C2=A0 Now you have to be a
little more selective.

I don't think th= is will make the implementation that hard :)


--001a114e491eb159bc0522a53f71-- From nobody Wed Oct 21 15:56:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964561B3373 for ; Wed, 21 Oct 2015 15:56:51 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv8CSM67cJXB for ; Wed, 21 Oct 2015 15:56:50 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002: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 5E1E71B3371 for ; Wed, 21 Oct 2015 15:56:50 -0700 (PDT) Received: by ykaz22 with SMTP id z22so65965949yka.2 for ; Wed, 21 Oct 2015 15:56: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:date:message-id:subject:from:to :cc:content-type; bh=VU7MC6Zn733jBDs/+/Q2ThryQkRcgVoXS6E5g6ROJIo=; b=AUMvHvvDU9fpFS+6ErLo63xzIjvwGbVQvLD6acx6FXzgywrq37iyVPzc7LQ6PIYjMO IItAwtskeBNfMqLLfDUnWHkTF5lJRcrEq1sOa6v7ozOk1S0cdC1kIFTcdW59jLHs+biB s0kkieKjL1UyMBizmbOpOCZvIYYay42V5Ww0rra5ROgZT3gcp6GhP8AjfKc08jahLLjs 048WCsWWS53DePSWul1EDIopYKI9cQiGQslv5uIOUQZe9ZFTuZkO/md3bQh+nPpXz8vf ILoO1qkXzfTuGyKRDNvCzRgvV/Q0cUlvxhoL+zP7A5MeKS1G+SALuLF36Z0QQUhUYev5 7guA== MIME-Version: 1.0 X-Received: by 10.13.196.196 with SMTP id g187mr9531120ywd.98.1445468209691; Wed, 21 Oct 2015 15:56:49 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 15:56:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Oct 2015 15:56:49 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove extra 0-RTT content types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 22:56:51 -0000 On 21 October 2015 at 15:52, Eric Rescorla wrote: > I don't think this will make the implementation that hard :) Yeah, you have to actually pay attention to the early_data extension. That might not be a bad thing in the end. From nobody Wed Oct 21 16:01:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF3B1B33A5 for ; Wed, 21 Oct 2015 16:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 IJULdTpjyEGG for ; Wed, 21 Oct 2015 16:01:51 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 760E51B33A4 for ; Wed, 21 Oct 2015 16:01:50 -0700 (PDT) Received: by yknn9 with SMTP id n9so65630548ykn.0 for ; Wed, 21 Oct 2015 16:01: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:content-type; bh=4r5Dhrf5n7NTpbTmrmYqW4RfNj7revFup2wusjtAKi8=; b=P6mDp0nZkHOJ4mjZka0lEtQdNrEMblyG/Z90sNQQHrsM6qz1GLpDgTBcygkwR8jgBo g5k69WeRz/Pu6qyyT5EgEsgdzNojoHfgFZxLR3/p8Bu57CeyXMTja5tEB+PAy8tz9WqB MugoJZWsogQuhdjFgF5Ec4J7G7bMb7XGuauUw1nVv+38eDenvjQttB8dJn9jERl+u1y8 IVw4m7ZL+wLA3olT83mfiiME4eW15dEbXEyrxlnNv+Y5iSl52ULtXyVpbqZGIahYsMgY a/mPDe0J55yxXD+ETJEnZfn6QGqoKRuS95jp3NAF40tlHUQmxe7J++clWRtNvuOOg4wd tsUQ== 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-type; bh=4r5Dhrf5n7NTpbTmrmYqW4RfNj7revFup2wusjtAKi8=; b=Ql4pSJ8QFTX9CM3Q8zu6syBuNFkQePpu92DVwJ40UiT6kgJrcQxmxZ+0bIg09Usz/6 +wGimKjA0dCjuqhYtIbArJTbxH4jBKfc2G+b4uEAz1pjR1MKjznRkfwsEWi1ZnEiLQQY j8rHMeIx2EvpOMS5wDurDqG5iYwKKn3pUVf/CRgWc59KWxWxNMilKKx6UVcXMVX3qdlD wafdlHGFkpEQHv+MSHlb0b+1cffYB6r27YNhXnBSHlRPsVS7Rb+IEDZw/fRErFtQqr6e ATuvU11F6/E543olTnifedQHs3YeLPU4ACVY8udDNRvI7PvBAaaPxWC05uBHVPyr6aIT 79JQ== X-Gm-Message-State: ALoCoQkVDUXpw/7PF58odBzVF1PcKBKxN7puKVO3F5oGGTZNLWMxs7UXqP3OVhUK6XNNwXqClXuT X-Received: by 10.129.130.6 with SMTP id s6mr8741937ywf.155.1445468509713; Wed, 21 Oct 2015 16:01:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 16:01:10 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 21 Oct 2015 16:01:10 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c07c35e0e6ff90522a55d59 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove extra 0-RTT content types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 23:01:52 -0000 --94eb2c07c35e0e6ff90522a55d59 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 21, 2015 at 3:56 PM, Martin Thomson wrote: > On 21 October 2015 at 15:52, Eric Rescorla wrote: > > I don't think this will make the implementation that hard :) > > Yeah, you have to actually pay attention to the early_data extension. > That might not be a bad thing in the end. > Yes, you do have to. -Ekr --94eb2c07c35e0e6ff90522a55d59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 21, 2015 at 3:56 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 21 October 2015 at 15:52, Eric Rescorla <ekr@rtfm.com> wrote:
> I don't think this will make the implementation that hard :)

Yeah, you have to actually pay attention to the early_data extension= .
That might not be a bad thing in the end.

Yes, you do have to= .

-Ekr=

--94eb2c07c35e0e6ff90522a55d59-- From nobody Wed Oct 21 16:52:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4F71B33C0 for ; Wed, 21 Oct 2015 16:52:05 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8kmjwDGuZ44 for ; Wed, 21 Oct 2015 16:52:04 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 C91B21B33BE for ; Wed, 21 Oct 2015 16:52:03 -0700 (PDT) Received: by ykdr3 with SMTP id r3so66734730ykd.1 for ; Wed, 21 Oct 2015 16:52:03 -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-type:content-transfer-encoding:message-id; bh=MWLhQ4W4LWmFGDm+IeUx5n45A6Wqw06J5/bHOPVUTWk=; b=ebXvmUzHj6BwABcG9kk+JY5J77FfPL5BTdUTFCl1kie7ltap9jbsJrSnDf6MSK1Ghu Mty/0Z3l2vwHK0dB2tRX48GmN0GtwHVHb3xQWNhfjeUoCOQoqC2x4gfBFrnk4qphH8qE NJ+tlTRE0cpkF0RAjQNbfnY4jh9laBI+Xz1wqpklZZW5d5d9BjFFBk/6vwbBW4iFtMlR l4YnvW/d8tXA/5c7n7x4OLQ1EOsWKhZUAN4F7C8aOgKWe0veiER5YYeLktlxiGWzTtke LnVK6RUEsEEwJk3011NdOl/K6X29g7LLROtFkJmTUjBHhOYTa3yTKNd5O636nWESFiDI yT/w== X-Received: by 10.129.57.130 with SMTP id g124mr8790324ywa.250.1445471523113; Wed, 21 Oct 2015 16:52:03 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w135sm7772600ywd.38.2015.10.21.16.52.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 21 Oct 2015 16:52:02 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 21 Oct 2015 19:52:01 -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: <201510211952.01479.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 23:52:05 -0000 I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE, but I think it's better than the alternative. Dave On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote: > I think this is the right answer and parallels what we are doing with PSS. > > -Ekr > > > On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson > wrote: > > > The current draft permits the use of SHA-1 in the certificate chain, > > which gives SHA-1 a free pass indefinitely. Since we expressly forbid > > the use of SHA-1 for signing in TLS itself, we can just permit clients > > to include it in "signature_algorithms" and use that to determine > > whether SHA-1 is acceptable. > > > > That means that clients that want to disable SHA-1 (real soon now, we > > promise), can signal that preference cleanly. > > > > I've opened PR #317 for this, but the commit is probably more useful > > to review, since I built this on top of ekr's client authentication > > changes (to avoid messy rebases): > > > > > > https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 From nobody Wed Oct 21 16:57:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865D51B33DF for ; Wed, 21 Oct 2015 16:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 vwBLG84ES9VX for ; Wed, 21 Oct 2015 16:56:53 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002: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 6FBAF1B33DE for ; Wed, 21 Oct 2015 16:56:53 -0700 (PDT) Received: by ykaz22 with SMTP id z22so67145524yka.2 for ; Wed, 21 Oct 2015 16:56:52 -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:content-type; bh=1kPh98QRdB5n1Nmco8QvXj2UxJJuWw4e5GcL9pOS/9I=; b=uHH28B4ALsk4uTnsPWg4UFSJH4RFJVkC+lCVkJDWEjdTToFIiU5SxdkxykDD2rdjFr sKd2LEb/KiDywr/anSOAsn85uEwI8McVcXxZ0O2TsHTNqRbsjJXR1baaAnKWIn+vl5qj t7UgpZ9MTHZljBlRYxiOpipUqloIyzHWjOxTwNJq2QG0rrU41e8/LKSlXF2ZQz+fvvgs BhNC6eksC0fJpJEe7nHvZlr+Reg/EUPIx4qL2m9fxfu/RtsbAIZ4SABCWYN8Txo5XBZM 0RAbCH+oSQK74ZnHbvDBbgPHwrR7wOqDqozGVAcKJF2QfXn7vUh+3ZMxQn2wNjPbsVcG MDmw== 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-type; bh=1kPh98QRdB5n1Nmco8QvXj2UxJJuWw4e5GcL9pOS/9I=; b=cdWuqVPrHbv2S9L2pvYz3EyFGlW1I1NNBtSQMqFFiLISpkUNM9PgkrKAoIpxTR4/u7 lI5zRMdWqobYojukW4Sby0TsgSEG9Giq6Clzgn7I6WpbF0vmfF8x+aleUrz8cVyCyp1b OqctuERJzDneXHmTBZIOn3Kf6+A8aO1wV2Gu95VYNg3uAC3pFSuXtSwiG/y46L6AejsP U/igtmVNT3LwMW3lAPLSoqIe4X3xKi15Mi//M6nRNAlT2WqsgfKAkqqIFsmA3+FV2CTZ w/SaKjInXhM1nyrBOHc0o+2YFOo60R8YuRZEoAd/17Tnblwt/Iv+eFmJGi28S+cx2mWS uyoA== X-Gm-Message-State: ALoCoQnNTOMCjGqJm6MRKy8Wek+6Li399BOJhQldNGKBClPe4CyH543EZ2oSUd546I8lPkJkOvSI X-Received: by 10.13.216.141 with SMTP id a135mr8924763ywe.12.1445471812731; Wed, 21 Oct 2015 16:56:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 16:56:13 -0700 (PDT) From: Eric Rescorla Date: Wed, 21 Oct 2015 16:56:13 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e488aee745c0522a62153 Archived-At: Subject: [TLS] Allow NamedGroups from the server? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2015 23:56:54 -0000 --001a114e488aee745c0522a62153 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/292 Presently, RFC 4492 only specifies the EC points it can support in ServerHello, but does not let the server indicate which EC curves it supports. Unless I'm missing something, this means that there's no way for the server to indicate what groups it would support. That seems less than ideal. There seem like three options here: 1. Put it in CertificateRequest 2. Send it in ServerHello 3. Do nothing. Thoughts? -Ekr --001a114e488aee745c0522a62153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://github.com/tlswg/tls13-spec/issues/292

Pres= ently, RFC 4492 only specifies the EC points it can support in
ServerHe= llo, but does not let the server indicate which EC curves it
supp= orts. Unless I'm missing something, this means that there's
no way for the server to indicate what groups it would support.

That seems less than ideal. There seem like three options = here:

1. Put it in CertificateRequest
2.= Send it in ServerHello
3. Do nothing.

T= houghts?
-Ekr


--001a114e488aee745c0522a62153-- From nobody Wed Oct 21 17:01:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9991C1B33F2 for ; Wed, 21 Oct 2015 17:01:08 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGK_Cn6le_j1 for ; Wed, 21 Oct 2015 17:01:07 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002: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 DDC741B33F3 for ; Wed, 21 Oct 2015 17:01:06 -0700 (PDT) Received: by ykba4 with SMTP id a4so60851726ykb.3 for ; Wed, 21 Oct 2015 17:01: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:date:message-id:subject:from:to :cc:content-type; bh=XFDwvRIWQLnOTo3ySlT02Iy90snubC0Oa2etBTAvMXE=; b=Mo0h6+xNu9KfY2pKeLA+70fdDgjMhTSFkHPuKc5P6huR8Of3hT9FlTp6/r+nNMNy7R rW0CDLicGpn+is54k8OFrS587QaBWBr4Ng46n80UXmiO3N/m0L9Se4nni+jvZmjYxngg 7eqLiazdKAn2VWVPSXfjoh3jEql4jK+rEmwrZolDyekkg8n0viQUFjHc1W+Lpj6qm7o8 Gcjks1ragLMAGFTy+ykUCSRKFLEiY4HqKx1wrTTrUaOMK0pB+MbYGyMLtrbUi8/UE6wT pPb1bFChyeb4AoDReNsQuotmoeM6QXp+3gnlvYk4mnfwTVNhuAnEGvhvkz3BJPr03grg SPEw== MIME-Version: 1.0 X-Received: by 10.129.132.83 with SMTP id u80mr8840844ywf.187.1445472066227; Wed, 21 Oct 2015 17:01:06 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 17:01:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Oct 2015 17:01:06 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Allow NamedGroups from the server? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 00:01:08 -0000 2b. encrypted extensions over ServerHello If we make this like signature_algorithms, then I think that I prefer option 1. I don't like that signature_algorithms is built that way, I think that it's repulsive, but there are some advantages to doing it that way, especially if we accept the fact that the client can authenticate multiple times, so I'm willing to live with that. On 21 October 2015 at 16:56, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/292 > > Presently, RFC 4492 only specifies the EC points it can support in > ServerHello, but does not let the server indicate which EC curves it > supports. Unless I'm missing something, this means that there's > no way for the server to indicate what groups it would support. > > That seems less than ideal. There seem like three options here: > > 1. Put it in CertificateRequest > 2. Send it in ServerHello > 3. Do nothing. > > Thoughts? > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Oct 21 17:09:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16D91AC39D for ; Wed, 21 Oct 2015 17:09:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiHmNCezCUln for ; Wed, 21 Oct 2015 17:09:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9938F1AC39C for ; Wed, 21 Oct 2015 17:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oA8UDjB52y2YwMxgGOcjxb//lnf73461cd5QaJIoxeQ=; b=ckF8OgtGHxIJaNWytr3PllsBr1NeVFaZdKfkQjLCGEfSuPxWBC6rkZNmAKgpZ9yEuwy0kRXOAnVQNvMpsXZvCMWwAuXh3S4IeCeGfzZSy7WjRujyelIBtedVyUPVwvizM2f5J+9ccmstviQsATAi/uOUf7IMEfxmr4G2ZrFbCoQ= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 00:09:34 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 00:09:33 +0000 From: Andrei Popov To: Martin Thomson , Eric Rescorla Thread-Topic: [TLS] Allow NamedGroups from the server? Thread-Index: AQHRDFwySYYLbapvF0OM4bIxRSdhpp52oMYAgAABhkA= Date: Thu, 22 Oct 2015 00:09: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::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:roMt1Wl8O0XT7sbQc6HTsaMNrMkuUhk6LptmYfYjUDaaksnMBh+QbQi/5zM9vQSMgogqdQMvq3XPch3E5PXWZDKlSoYq1QXnqQIwBClEiEaeUCRTNCVNXwzVfIiuNNzzHKKfDLhX1txsluGNbS5I5g==; 24:uVKWCe0P5jP8IJB2b7NICFApKhj5uTaHymm+DN/IuAEh+88AhqgJcrig+dq7Ucgl+Vlsgx26NIJtMW+kbtT3UcueWHVq3S7BG5mvz9KNcoc=; 20:whoHrUG5AARjWAEFj0+1R6SiolOr0qpPZdxDC6PTQB2oxSltQS83PRsqBEHMNrq8IvRScdfoU6Up8jczouq8dA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(61426024)(61427024); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51444003)(377454003)(199003)(13464003)(24454002)(5007970100001)(8990500004)(10400500002)(33656002)(101416001)(50986999)(10290500002)(5005710100001)(5004730100002)(76176999)(54356999)(81156007)(64706001)(5001960100002)(46102003)(5008740100001)(5001770100001)(122556002)(40100003)(97736004)(106116001)(19580405001)(87936001)(86362001)(102836002)(189998001)(86612001)(77096005)(10090500001)(19580395003)(15975445007)(5003600100002)(5002640100001)(105586002)(106356001)(74316001)(76576001)(92566002)(2950100001)(2900100001)(99286002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.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:23 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: 22 Oct 2015 00:09:33.6003 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Allow NamedGroups from the server? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 00:09:38 -0000 If it's true that the only use of this indication is client auth, then opti= on 1 makes the most sense to me. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Wednesday, October 21, 2015 5:01 PM To: Eric Rescorla Cc: tls@ietf.org Subject: Re: [TLS] Allow NamedGroups from the server? 2b. encrypted extensions over ServerHello If we make this like signature_algorithms, then I think that I prefer optio= n 1. I don't like that signature_algorithms is built that way, I think tha= t it's repulsive, but there are some advantages to doing it that way, espec= ially if we accept the fact that the client can authenticate multiple times= , so I'm willing to live with that. On 21 October 2015 at 16:56, Eric Rescorla wrote: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fgithu > b.com%2ftlswg%2ftls13-spec%2fissues%2f292&data=3D01%7c01%7cAndrei.Popov% > 40microsoft.com%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af9 > 1ab2d7cd011db47%7c1&sdata=3DqOVO5xpSgVIXG6%2fiMyP3zQSbeFwZlrDW1kcqvONCRD > Y%3d > > Presently, RFC 4492 only specifies the EC points it can support in=20 > ServerHello, but does not let the server indicate which EC curves it=20 > supports. Unless I'm missing something, this means that there's no way=20 > for the server to indicate what groups it would support. > > That seems less than ideal. There seem like three options here: > > 1. Put it in CertificateRequest > 2. Send it in ServerHello > 3. Do nothing. > > Thoughts? > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i > etf.org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40micro > soft.com%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af91ab2d7c > d011db47%7c1&sdata=3D%2f612ldpCER8pXNtxSxUfQjhuYcMAIZ2S3o1ozmxqqWI%3d > _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7c6625ee4cf40f4f52917108d2da73ea39%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3D%2f612ldpCER8pXNtxSxUfQjhuYcMAIZ2S3o1ozmxqqWI%3d From nobody Wed Oct 21 17:14:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7901ACC91 for ; Wed, 21 Oct 2015 17:14:23 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J86uZMQ_pG1k for ; Wed, 21 Oct 2015 17:14:22 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 E1BE51ACC8D for ; Wed, 21 Oct 2015 17:14:21 -0700 (PDT) Received: by yknn9 with SMTP id n9so67033664ykn.0 for ; Wed, 21 Oct 2015 17:14:21 -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-type:content-transfer-encoding:message-id; bh=sbX1IJifQkweTFnRcG8n0TO7z+mWAwx7eefUlNYcNd8=; b=nan6/k6sqEE6O5PKr8sZ05ckc6bKjum8ZLVq8ps3l8E9/o3+bAc1gGvfBDs4iCN+m9 AYdid5SbjUmwbEh3+j/CqwiG9G4aMpXSnkbOqBxHNDrERqPI4621ptmyjK2pfVjyrocJ eaDasFU680uBKauN4M+ff4K8ZslnnbWOuL06wKIDfj4nuolLbL7J0WtrINEjQkzBaifa YvRSZNIurxCYCc7H2y1dn1DdG4Jrx88erIU21Ug/jNFI0tFR+jlg0lsn163Nbf6Bihbq /JeUFBdd42q2ZxjdCvrIs8CnWLWE94+pyl6Up1Jtqn+/2/6HDJYVnJ8sjgvgbsjo4OOh HXGQ== X-Received: by 10.13.223.17 with SMTP id i17mr9767843ywe.189.1445472861199; Wed, 21 Oct 2015 17:14:21 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id q2sm7863814ywd.11.2015.10.21.17.14.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 21 Oct 2015 17:14:20 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 21 Oct 2015 20:14:19 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151021195608.GO15070@mournblade.imrryr.org> In-Reply-To: <20151021195608.GO15070@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510212014.19467.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 00:14:23 -0000 On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote: > Whether SHA-1 in the chain is used to make trust decisions is only > known to the client, and the server MUST NOT preempt that by denying > the client access to whatever chain it has on hand. Can we please just fix this issue properly and add an "any(0xFF)" value to the enum so clients can explicitly tell the server that they're capable of trusting certs directly (or is doing OE) and the hash is potentially irrelevant? Note that the current proposed change does not break your use-case. Those clients can simply offer SHA-1 support indefinitely. Sure, they don't strictly support using SHA-1, but they support receiving certs using it, which is all the signal is really for. Dave From nobody Wed Oct 21 17:17:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34481A92BA for ; Wed, 21 Oct 2015 17:17:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHkUKM80X9T6 for ; Wed, 21 Oct 2015 17:17:34 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 CD6D61A9054 for ; Wed, 21 Oct 2015 17:17:33 -0700 (PDT) Received: by ykdr3 with SMTP id r3so67220097ykd.1 for ; Wed, 21 Oct 2015 17:17:33 -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-type:content-transfer-encoding:message-id; bh=sC4Y4zYTyYqAmJyTi51d1xDcVKFNJkIcvKm9etMVBo8=; b=wzufnQmYA9l6DfNvRw5ciJ+3cBvFhlHQwazAFDqV50er4oZJMyuJ4k5KB8WnB8s1od M1VxZMgcQX3WbxHrE9EWll+UhGcv2+1Eupd17XWlHXhRq/JX9v+OYUmZBzTAPStd/luK YX2jYt/7vmzS9eMLNZLow+u/DJHK+aZekNdfSeElTy6h6CrE+ZlM1M02/FqvaDfRgRwp e/59HO/RsG1FM8oLGPjDy90uDC5B7tGUDUYKJW4H3bPzwMJ6D1tU6Cv++6D16XcR6BE3 dDJ52EEzEl0XAG1ILSpPODvaIowqYDmxpEs6gToNkvKS84gLeBChH/gH4O9xl7OebyM3 sAoA== X-Received: by 10.13.230.204 with SMTP id p195mr8894228ywe.213.1445473053175; Wed, 21 Oct 2015 17:17:33 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id j23sm7877159ywb.10.2015.10.21.17.17.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 21 Oct 2015 17:17:32 -0700 (PDT) From: Dave Garrett To: agl@google.com Date: Wed, 21 Oct 2015 20:17:31 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151021204320.0CECD18046A@rfc-editor.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201510212017.31856.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 00:17:37 -0000 Congrats on releasing an RFC that has day one 100% server support. :p Dave From nobody Wed Oct 21 17:29:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56E21B3431 for ; Wed, 21 Oct 2015 17:29:10 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc5YvN6iVFru for ; Wed, 21 Oct 2015 17:29:09 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 3BB131B342F for ; Wed, 21 Oct 2015 17:29:09 -0700 (PDT) Received: by ykdr3 with SMTP id r3so67435885ykd.1 for ; Wed, 21 Oct 2015 17:29:08 -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-type:content-transfer-encoding:message-id; bh=rClN8n/mP0ty0ToGUI96/vVUyRwje7f3g4tyTNt5AVI=; b=T9payWaGKSPfx5BZwekFTyMBlERyJY3wx/ZVLxy45c8Ps4n6U68+jEJ2JUh5ZVhrXj njQRPrErtA5SKZf++doqfoQqN7VVEaY59lKR3bW3CtcH4taZ0pYEszGS9NOCDSzC8pcU qKeGDJ1L+N3j2wHJF8MVorXCtW/mt1P0xqNkoyOMU1Ut7c4Vz0WmrTt/i/gB43SLjEyD fPOI7yxmTVmxv0druwwPqTjI0DCqWhwpwpJEwxUKQqtZ9GHpp/5UygeGzxeHhWAn39iO heFqI2+/P47NOIvtnF7vPhs2NuGctw1pS2bfQu6nBdDpmalsog2bpiBweGLLXmLlg1Rv GABA== X-Received: by 10.129.147.198 with SMTP id k189mr8812837ywg.282.1445473748635; Wed, 21 Oct 2015 17:29:08 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id n16sm7294329ywn.4.2015.10.21.17.29.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 21 Oct 2015 17:29:08 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 21 Oct 2015 20:29:06 -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: <201510212029.06992.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Allow NamedGroups from the server? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 00:29:10 -0000 On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/292 > > Presently, RFC 4492 only specifies the EC points it can support in > ServerHello, but does not let the server indicate which EC curves it > supports. Unless I'm missing something, this means that there's > no way for the server to indicate what groups it would support. > > That seems less than ideal. There seem like three options here: > > 1. Put it in CertificateRequest > 2. Send it in ServerHello > 3. Do nothing. I prefer #2. I don't think encryption is necessarily required for this, but EncryptedExtensions is fine too (Martin's 2b). I'm generally against putting it in CertificateRequest, as we're reusing an existing hello extension so keeping it in a hello message (or it's trailing encrypted field) seems best. (restricted to TLS 1.3+ clients, though) Dave From nobody Wed Oct 21 17:35:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBD91B3467 for ; Wed, 21 Oct 2015 17:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 lJrgC-aeibMj for ; Wed, 21 Oct 2015 17:35:42 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002: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 473B61B3463 for ; Wed, 21 Oct 2015 17:35:42 -0700 (PDT) Received: by ykaz22 with SMTP id z22so67883623yka.2 for ; Wed, 21 Oct 2015 17:35: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:content-type; bh=Xh9UotmwP1OyUJfMVI/P7a2ai3pUm0Wz+jLEF/NBjw4=; b=UrzY92KrcRxb5xmX2vZ40lvEuwFE5SMmYZkhyJN4a1mQxJkWWtZgRElrk/+aM2k4uf rl87/oxDA2OvJNCs0JDSrmfdmLndm8PmQS1gVQqIqaZ3PyKNsBSo++w1U7Qv8StY6kfY +lJTW13ra6ROZKlwDfhFpWCmU7SLqBlJcgFEsUskzWi/gaiIyxtGVBEWgqQ3V8HJ+a4C fTdzr9SQAUPyi+ZHG4IQPDmh72ySDhxTrpUCUXESQzqOohq1ObCkf2IlWLlTOhzkkVHi +f3jNPjfJPpp9gQLbSTNaRAFKznTDFYAAvbhm1XwUeiG34k4YkJobtpvwgDjynIM3Vtz ggOA== 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-type; bh=Xh9UotmwP1OyUJfMVI/P7a2ai3pUm0Wz+jLEF/NBjw4=; b=jVG0CjpaYa+LJjHd3fpYmA6HKFBj9bFIalZVLonM3fgfuVbvITIRhOX94u3nCrfkHH MH0hf2xAi3qGXHNkUyGpyhbSZ+PykUUrpkBteP34rRwM0JIC4DBvM8/a5dRdZAbR1kUi LFkJZuvmldeBPTdlB+T9AZJYIunfmQbdFka1WSW890RuI5V/r7bIinpnCfSzOE4lbLPr g4aMo7kgV2WZjceHqxvEKelzK0mQYzWLFVIrN7JgazaVnBwZm5kfj2xjbtmTL+HazmSi 4hPet7VrUuyksZZ/E5ofsG53H4vlJnJwqUBDMVjYuQekELAASqKWrUuamDLZGR/u5t2q M82Q== X-Gm-Message-State: ALoCoQmmLplyo5yCXxGmo7MylGwZe/p4rfs5u9gbTx6eEZEQOt7/+QgDPqjmxMaxxToKOuir8Ika X-Received: by 10.129.70.139 with SMTP id t133mr8905991ywa.115.1445474141584; Wed, 21 Oct 2015 17:35:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.85 with HTTP; Wed, 21 Oct 2015 17:35:02 -0700 (PDT) In-Reply-To: <201510212029.06992.davemgarrett@gmail.com> References: <201510212029.06992.davemgarrett@gmail.com> From: Eric Rescorla Date: Wed, 21 Oct 2015 17:35:02 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114d7256bdf2430522a6ac38 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Allow NamedGroups from the server? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 00:35:43 -0000 --001a114d7256bdf2430522a6ac38 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 21, 2015 at 5:29 PM, Dave Garrett wrote: > On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/issues/292 > > > > Presently, RFC 4492 only specifies the EC points it can support in > > ServerHello, but does not let the server indicate which EC curves it > > supports. Unless I'm missing something, this means that there's > > no way for the server to indicate what groups it would support. > > > > That seems less than ideal. There seem like three options here: > > > > 1. Put it in CertificateRequest > > 2. Send it in ServerHello > > 3. Do nothing. > > I prefer #2. I don't think encryption is necessarily required for this, > but EncryptedExtensions is fine too (Martin's 2b). > > I'm generally against putting it in CertificateRequest, as we're reusing > an existing hello extension so keeping it in a hello message (or it's > trailing encrypted field) seems best. (restricted to TLS 1.3+ clients, > though) This would need to be limited to 1.3 in any case because in all the other cases it would be illegal. -Ekr > > > Dave > --001a114d7256bdf2430522a6ac38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 21, 2015 at 5:29 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/issues/292
>
> Presently, RFC 4492 only specifies the EC points it can support in
> ServerHello, but does not let the server indicate which EC curves it > supports. Unless I'm missing something, this means that there'= s
> no way for the server to indicate what groups it would support.
>
> That seems less than ideal. There seem like three options here:
>
> 1. Put it in CertificateRequest
> 2. Send it in ServerHello
> 3. Do nothing.

I prefer #2. I don't think encryption is necessarily required fo= r this, but EncryptedExtensions is fine too (Martin's 2b).

I'm generally against putting it in CertificateRequest, as we're re= using an existing hello extension so keeping it in a hello message (or it&#= 39;s trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,= though)




Dave

--001a114d7256bdf2430522a6ac38-- From nobody Wed Oct 21 19:12:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70B1B35B8 for ; Wed, 21 Oct 2015 19:12:01 -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, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=0.6, MALFORMED_FREEMAIL=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC8Jzo5ECst7 for ; Wed, 21 Oct 2015 19:11:59 -0700 (PDT) Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com [17.172.220.113]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE811B35B6 for ; Wed, 21 Oct 2015 19:11:59 -0700 (PDT) Received: from [172.20.10.4] (KD106130123250.au-net.ne.jp [106.130.123.250]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NWL0055UNFRVV10@st11p02im-asmtp001.me.com> for tls@ietf.org; Thu, 22 Oct 2015 02:11:57 +0000 (GMT) Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Shin'ichiro Matsuo In-reply-to: <258F3808-1046-4B59-B0BC-CB2AF9B7D0FE@sn3rd.com> Date: Thu, 22 Oct 2015 11:11:49 +0900 Content-transfer-encoding: quoted-printable Message-id: <27539F90-E0AA-4447-ACD2-952A3B84CAD0@mac.com> References: <258F3808-1046-4B59-B0BC-CB2AF9B7D0FE@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3094) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-10-22_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510090000 definitions=main-1510220040 Archived-At: Subject: Re: [TLS] Comments from CELLOS consortium X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 02:12:01 -0000 Dear Sean, Eric, Dave, and all, We appreciate much kind treatment for our comments at GitHub on the = following items. CELLOS: AEAD-1/2 CELLOS: 0-RTT 1/2/3 CELLOS: Resumption & PSK 2 CELLOS: KDF CELLOS: SharedSecret CELLOS: ClientAuthentication CELLOS: HelloRetryRequest With Best Regards, Shin=92ichiro Matsuo > On Oct 18, 2015, at 6:13 AM, Sean Turner wrote: >=20 > Since we=92ve been using github as an issue tracker, I=92m going to = copy these comments there. I=92m going to put =93CELLOS=94 somewhere in = the issue so they can be easily found. Also note that some of these are = resolved, similar to others, or over taken by events so I expect some to = be closed almost immediately. >=20 > spt >=20 >=20 > On Oct 05, 2015, at 15:54, Shin'ichiro Matsuo wrote: >=20 >> Dear all, >>=20 >> Members in the CELLOS consortium (https://www.cellos-consortium.org), = which is the consortium on security of cryptographic protocols, are = studying on the TLS 1.3 protocol. We have several comments and = suggestions to make the specification of TLS1.3 better.=20 >>=20 >> Please find the comments at the following URL. >>=20 >> = https://www.cellos-consortium.org/studygroup/tls_1_3-draft_08_issues_rev1.= pdf >>=20 >> The comments are on the following matters. >>=20 >> - AEAD >> - KDF >> - Full Handshake >> - Hello Retry Request >> - Shared Secret >> - Client Authentication >> - Cipher Suite >> - 0-RTT >> - Resumption and PSK >>=20 >> Some of them are already fixed, such as HFDF. However, we left it as = a result of our study. >>=20 >>=20 >> Regards, >> Shin=92ichiro Matsuo >> _______________________________________________ >> 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 Wed Oct 21 20:13:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392E11B2B83 for ; Wed, 21 Oct 2015 20:13: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FdJ6qpKpL6p for ; Wed, 21 Oct 2015 20:13:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912121B2B7E for ; Wed, 21 Oct 2015 20:13:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 10923284D22; Thu, 22 Oct 2015 03:13:32 +0000 (UTC) Date: Thu, 22 Oct 2015 03:13:32 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151022031331.GQ15070@mournblade.imrryr.org> References: <20151021195608.GO15070@mournblade.imrryr.org> <201510212014.19467.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201510212014.19467.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 22 Oct 2015 03:13:35 -0000 On Wed, Oct 21, 2015 at 08:14:19PM -0400, Dave Garrett wrote: > On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote: > > Whether SHA-1 in the chain is used to make trust decisions is only > > known to the client, and the server MUST NOT preempt that by denying > > the client access to whatever chain it has on hand. > > Can we please just fix this issue properly and add an "any(0xFF)" value > to the enum so clients can explicitly tell the server that they're capable > of trusting certs directly (or is doing OE) and the hash is potentially > irrelevant? This forces a new signalling channel from TLS clients that need this to their TLS library to enable this new "any" value. Not an API that's found in existing libraries or applications. Previously the TLS library would just let clients validate chains as they fit. > Note that the current proposed change does not break your use-case. Those > clients can simply offer SHA-1 support indefinitely. Sure, they don't > strictly support using SHA-1, but they support receiving certs using it, > which is all the signal is really for. Yes, the signal "would" suffice, if it were practical to inject it. On the other hand, interposing on trust decisions for RFC 5280 chains is not the proper job of TLS. And the chain the server has may not get used by the client in full (the client might replace some issuer certs with alternative certs for the "same" issuer). So, just as before, why is the TLS server the proper vehicle for hiding SHA-1 certs from potentially, but not necessarily PKIX clients? What's wrong with just having the various CAs no longer issue SHA-1 certs, and the PKIX code in TLS libraries no longer trusting SHA-1 certs by default? Do we really need a third counter-measure that exceeds the proper scope of TLS? -- Viktor. From nobody Thu Oct 22 00:28:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478DF1A6FCC for ; Thu, 22 Oct 2015 00:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.91 X-Spam-Level: X-Spam-Status: No, score=-99.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-EqCqk33qwx for ; Thu, 22 Oct 2015 00:28:00 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9461B1A86EF for ; Thu, 22 Oct 2015 00:28:00 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 42CA79A4019; Thu, 22 Oct 2015 03:27:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id p12z1Mwcfwwo; Thu, 22 Oct 2015 03:26:17 -0400 (EDT) Received: from [10.196.207.51] (237-194.icannmeeting.org [199.91.194.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D7CEA9A400D; Thu, 22 Oct 2015 03:27:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-30--959810090 From: Russ Housley In-Reply-To: Date: Thu, 22 Oct 2015 03:27:04 -0400 Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 07:28:02 -0000 --Apple-Mail-30--959810090 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =20 I am also in favor of this change: it prohibits the server to send SHA-1 = certs when signature_algorithms does not include SHA-1. Russ On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson = wrote: The current draft permits the use of SHA-1 in the certificate chain, which gives SHA-1 a free pass indefinitely. Since we expressly forbid the use of SHA-1 for signing in TLS itself, we can just permit clients to include it in "signature_algorithms" and use that to determine whether SHA-1 is acceptable. That means that clients that want to disable SHA-1 (real soon now, we promise), can signal that preference cleanly. I've opened PR #317 for this, but the commit is probably more useful to review, since I built this on top of ekr's client authentication changes (to avoid messy rebases): = https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457= f2c09fdaeb1f82aa5 --Apple-Mail-30--959810090 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

 

I am also in favor of this change: it prohibits the server to send SHA-1 certs when signature_algorithms does not include SHA-1.


Russ


On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The current draft permits the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine
whether SHA-1 is acceptable.

That means that clients that want to disable SHA-1 (real soon now, we
promise), can signal that preference cleanly.

I've opened PR #317 for this, but the commit is probably more useful
to review, since I built this on top of ekr's client authentication
changes (to avoid messy rebases):

https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5

--Apple-Mail-30--959810090-- From nobody Thu Oct 22 00:42:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0833B1B2A27 for ; Thu, 22 Oct 2015 00:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG77K4mxOHyr for ; Thu, 22 Oct 2015 00:42:54 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mail1.comodoca.com [91.209.196.72]) (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 EE0FB1AD255 for ; Thu, 22 Oct 2015 00:42:53 -0700 (PDT) Received: (qmail 11184 invoked by uid 1004); 22 Oct 2015 07:42:52 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 22 Oct 2015 08:42:52 +0100 Received: (qmail 8595 invoked by uid 1000); 22 Oct 2015 07:42:52 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 22 Oct 2015 08:42:52 +0100 To: Dave Garrett , tls@ietf.org References: <201510211952.01479.davemgarrett@gmail.com> From: Rob Stradling Message-ID: <5628937B.9060403@comodo.com> Date: Thu, 22 Oct 2015 08:42:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201510211952.01479.davemgarrett@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Controlling use of SHA-1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 07:42:58 -0000 On 22/10/15 00:52, Dave Garrett wrote: > I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE, IINM this also changes the fallback for servers that choose to include a PKIX trust anchor certificate in the Server Certificate message. Lots of publicly trusted root certificates have sha1WithRSAEncryption signatures. TLS clients typically don't verify these SHA-1 signatures, so there's no rush to remove them from trust anchor stores. > but I think it's better than the alternative. Why would it make sense to prohibit the sending of PKIX trust anchor certificates that have sha1WithRSAEncryption signatures? > Dave > > > On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote: >> I think this is the right answer and parallels what we are doing with PSS. >> >> -Ekr >> >> >> On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson >> wrote: >> >>> The current draft permits the use of SHA-1 in the certificate chain, >>> which gives SHA-1 a free pass indefinitely. Since we expressly forbid >>> the use of SHA-1 for signing in TLS itself, we can just permit clients >>> to include it in "signature_algorithms" and use that to determine >>> whether SHA-1 is acceptable. >>> >>> That means that clients that want to disable SHA-1 (real soon now, we >>> promise), can signal that preference cleanly. >>> >>> I've opened PR #317 for this, but the commit is probably more useful >>> to review, since I built this on top of ekr's client authentication >>> changes (to avoid messy rebases): >>> >>> >>> https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Oct 22 01:20:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301F61B2F45 for ; Thu, 22 Oct 2015 01:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=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 ZLP4n30vg3aw for ; Thu, 22 Oct 2015 01:20:10 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 BD36F1B2F3B for ; Thu, 22 Oct 2015 01:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1445502006; l=3648; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=f8bsxPjCGXeM41elE2eSXzxYV7COvjldY9UAFI8MXdk=; b=r6JaMU+RxGeHLU7GTgp8MinoQ2HBtimm2S8/SyeZNxb+Yi+LO7TJ6tF+LigODsAsjDU PadWN8Qu0J1V9lxjgl2A+aUtMw7J6Vx8AbwdR1Z40rrnuhykE55NH1cRubxE1z/58yypc hiYAouB7DbEqF2Gz3N9H9sm2HmIkkLQMbLY= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyCUKIQHiyECo3tkjU4/3GtoHX1WQ== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:3043:b81f:84f6:759f] ([2001:4dd0:ff67:0:3043:b81f:84f6:759f]) by smtp.strato.de (RZmta 37.14 AUTH) with ESMTPSA id g00b98r9M8K6jWU (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 22 Oct 2015 10:20:06 +0200 (CEST) To: tls@ietf.org References: <20151021202259.276f1a56@pc1> From: Roland Zink Message-ID: <56289C3A.6090807@zinks.de> Date: Thu, 22 Oct 2015 10:20:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151021202259.276f1a56@pc1> Content-Type: multipart/alternative; boundary="------------030204080602070200010803" Archived-At: Subject: Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2015 08:20:13 -0000 This is a multi-part message in MIME format. --------------030204080602070200010803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Am 21.10.2015 um 20:22 schrieb Hanno Böck: > Not sure if I'm getting anything wrong, but doesn't this open a huge > security hole? Yes I think so. Mitm may redirect you. > > Scenario right now is that if I want to be secure on a webpage I type > in its HTTPS URL (either directly or through a bookmark) and can be > pretty much sure that as long as I don't click on external links that > I'll stay on that webpage. No the server may redirect you and even worse the parts may be retrieved from dozens of places and you have no clue from where. Common practice is that your privacy is sold to third parties through ads, analytics, like or pin buttons. This is not what I would expect from a secure site. > Basically this proposal would allow a man-in-the-middle to send > me to another webpage each time I click on a (supposedly https > protected) link. Given that there are many browsers these days > (mobile) that hide the URL bar thats even more severe. > > This severely changes the security expectations one can have from a > browser. Regards, Roland > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------030204080602070200010803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Am 21.10.2015 um 20:22 schrieb Hanno Böck:
Not sure if I'm getting anything wrong, but doesn't this open a huge
security hole?
Yes I think so. Mitm may redirect you.

Scenario right now is that if I want to be secure on a webpage I type
in its HTTPS URL (either directly or through a bookmark) and can be
pretty much sure that as long as I don't click on external links that
I'll stay on that webpage.
No the server may redirect you and even worse the parts may be retrieved from dozens of places and you have no clue from where. Common practice is that your privacy is sold to third parties through ads, analytics, like or pin buttons. This is not what I would expect from a secure site.
Basically this proposal would allow a man-in-the-middle to send
me to another webpage each time I click on a (supposedly https
protected) link. Given that there are many browsers these days
(mobile) that hide the URL bar thats even more severe.

This severely changes the security expectations one can have from a
browser.
Regards,
Roland

      

      

      

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


    

    

  


--------------030204080602070200010803--


From nobody Thu Oct 22 05:56:08 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356301A1B92 for ; Thu, 22 Oct 2015 05:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQqF9MEkc-Nt for ; Thu, 22 Oct 2015 05:56:00 -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 CA4BA1A1B83 for ; Thu, 22 Oct 2015 05:55:59 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 B8A3F2AC63; Thu, 22 Oct 2015 14:55:57 +0200 (CEST)
X-purgate-ID: 152705::1445518557-00001EB9-91C68767/0/0
X-purgate-size: 1607
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 mail05.wdf.sap.corp (Postfix) with ESMTP id A52464200D; Thu, 22 Oct 2015 14:55:57 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9B1651A31C; Thu, 22 Oct 2015 14:55:57 +0200 (CEST)
In-Reply-To: 
To: Eric Rescorla 
Date: Thu, 22 Oct 2015 14:55:57 +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: <20151022125557.9B1651A31C@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 22 Oct 2015 12:56:04 -0000

Eric Rescorla wrote:
> Dave Garrett  wrote:
> 
>> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
>>> https://github.com/tlswg/tls13-spec/issues/292
>>>
>>> Presently, RFC 4492 only specifies the EC points it can support in
>>> ServerHello, but does not let the server indicate which EC curves it
>>> supports. Unless I'm missing something, this means that there's
>>> no way for the server to indicate what groups it would support.
>>>
>>> That seems less than ideal. There seem like three options here:
>>>
>>> 1. Put it in CertificateRequest
>>> 2. Send it in ServerHello
>>> 3. Do nothing.
>>
>> I prefer #2. I don't think encryption is necessarily required for this,
>> but EncryptedExtensions is fine too (Martin's 2b).
>>
>> I'm generally against putting it in CertificateRequest, as we're reusing
>> an existing hello extension so keeping it in a hello message (or it's
>> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
>> though)
> 
> 
> This would need to be limited to 1.3 in any case because in all the other
> cases it would be illegal.


Why do you believe that it would be "illegal" for a TLSv1.[012] server
to return a "Supported Elliptic Curves" TLS extension in ServerHello
in response to the presence of such a TLS extension in ClientHello?

rfc4492 does not define semantics for the presence of "Supported Elliptic
Curves" TLS extension in ServerHello, but on a quick read, it also does
not prohibit including/sending it.

https://tools.ietf.org/html/rfc4492#section-5.2


-Martin


From nobody Thu Oct 22 06:30:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C7C1A898F for ; Thu, 22 Oct 2015 06:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 XGBw1P785WG1 for ; Thu, 22 Oct 2015 06:30:02 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002: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 769501A8A59 for ; Thu, 22 Oct 2015 06:30:02 -0700 (PDT)
Received: by ykaz22 with SMTP id z22so82458021yka.2 for ; Thu, 22 Oct 2015 06:30:01 -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:content-type; bh=vZegLwJbUthZGbhl1BpS3U2uC1aFUjd+kdmLT3V0gB0=; b=oZr9gf4uOLNXzoEjOxGyd+n3nqNm29FDoSBczjYyUFmcYs1sBXA/+uxFvqgwpz8Zzy N3i8n7VGX9Qzo+oqKbouXpXKK8TSWjARGnlkEuv1wvlt/G/Tja/SHDCTNq0M6hv2/AN3 q4CbQQPnAYErH1EeRXi8UgFMq6E0DTq6dU0vdaGNaF15KCsiuXDewIoQi0OGNzqJ7qPL Zq6J6TBCw+tctxtM+tP7hra/9AvyNEHP+y3RrqUaQsyfTvTbBCTsXapKDZ5N8pG1VUr+ GxTwdj3G8gVh1IZnT94O5bgCf9YaaXvls35mSZr8Pp4MBkN+sG7Wt9bVANHCnr3cNpud oZcg==
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-type; bh=vZegLwJbUthZGbhl1BpS3U2uC1aFUjd+kdmLT3V0gB0=; b=MFq7/SvoYXGMIqz2YvGVIxgZ+5wPvjhACgS2Q+X2sNzCru7U6UF+Wj+2ycbPeD8P0K xUmQx0LS4J2uvbo07QVVvAGtftHmVcLp7lKSpvAmKXMhb1VyYrBCFHCjOcaXmx1ehH9d pNexvmiwsaCvh2Vrkg9NeRtX83pAwa/DHJTX7eBoOQ8lN4X3C3RHsktxGz+pv/f+6RN0 imewl0ebOSEhbHfHnzoWWBJ6shFY+yceE8Y21nwtBWPxWktlR8KpPJqczqRkTWUiMgyx FS0KHATA1efZq/ZfHagWuOyPZaBHz8xwpE6IOIW+3AuVXMEfpZlt05Fo5QHPAeL9pRGb 2gYg==
X-Gm-Message-State: ALoCoQnemxySt0FBERozXzWlgA0i/KhThrPOdNd4nxiGiP/kdM69RtQyjWpPrpFosF40xO9/Rx0h
X-Received: by 10.129.130.6 with SMTP id s6mr11027748ywf.155.1445520601807; Thu, 22 Oct 2015 06:30:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 06:29:22 -0700 (PDT)
In-Reply-To: <20151022125557.9B1651A31C@ld9781.wdf.sap.corp>
References:  <20151022125557.9B1651A31C@ld9781.wdf.sap.corp>
From: Eric Rescorla 
Date: Thu, 22 Oct 2015 06:29:22 -0700
Message-ID: 
To: "mrex@sap.com" 
Content-Type: multipart/alternative; boundary=94eb2c07c35efcaffd0522b17d9d
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 13:30:09 -0000

--94eb2c07c35efcaffd0522b17d9d
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex  wrote:

> Eric Rescorla wrote:
> > Dave Garrett  wrote:
> >
> >> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> >>> https://github.com/tlswg/tls13-spec/issues/292
> >>>
> >>> Presently, RFC 4492 only specifies the EC points it can support in
> >>> ServerHello, but does not let the server indicate which EC curves it
> >>> supports. Unless I'm missing something, this means that there's
> >>> no way for the server to indicate what groups it would support.
> >>>
> >>> That seems less than ideal. There seem like three options here:
> >>>
> >>> 1. Put it in CertificateRequest
> >>> 2. Send it in ServerHello
> >>> 3. Do nothing.
> >>
> >> I prefer #2. I don't think encryption is necessarily required for this,
> >> but EncryptedExtensions is fine too (Martin's 2b).
> >>
> >> I'm generally against putting it in CertificateRequest, as we're reusing
> >> an existing hello extension so keeping it in a hello message (or it's
> >> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
> >> though)
> >
> >
> > This would need to be limited to 1.3 in any case because in all the other
> > cases it would be illegal.
>
>
> Why do you believe that it would be "illegal" for a TLSv1.[012] server
> to return a "Supported Elliptic Curves" TLS extension in ServerHello
> in response to the presence of such a TLS extension in ClientHello?
>
> rfc4492 does not define semantics for the presence of "Supported Elliptic
> Curves" TLS extension in ServerHello, but on a quick read, it also does
> not prohibit including/sending it.
>
> https://tools.ietf.org/html/rfc4492#section-5.2


Well, the draft says that it is defining two ClientHello extensions
(supported elliptic curves and supported point formats) and that it is
defining
one ServerHello extension, so if the server is sending supported elliptic
curves it's doing something undefined. I don't think you need to have
an explicit prohibition to suggest that doing something undefined isn't
great.

>From an implementation perspective, I wouldn't be surprised if client
implementations choked on the server sending this. I had to check
to see if NSS would do so. It doesn't, but given the way the code
is written, it wouldn't have surprised me if it checked that all extensions
were handled and choked otherwise.

-Ekr


>
>
-Martin
>

--94eb2c07c35efcaffd0522b17d9d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex <mrex@sap.com> wr=
ote:
Eric Rescorla wrote:

> Dave Garrett <davemgarrett@gmail.com> wrote:

>

>> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
>>> https://github.com/tlswg/tls13-spec/issue=
s/292

>>>

>>> Presently, RFC 4492 only specifies the EC points it can suppor=
t in

>>> ServerHello, but does not let the server indicate which EC cur=
ves it

>>> supports. Unless I'm missing something, this means that th=
ere's

>>> no way for the server to indicate what groups it would support=
.

>>>

>>> That seems less than ideal. There seem like three options here=
:

>>>

>>> 1. Put it in CertificateRequest

>>> 2. Send it in ServerHello

>>> 3. Do nothing.

>>

>> I prefer #2. I don't think encryption is necessarily required =
for this,

>> but EncryptedExtensions is fine too (Martin's 2b).

>>

>> I'm generally against putting it in CertificateRequest, as we&=
#39;re reusing

>> an existing hello extension so keeping it in a hello message (or i=
t's

>> trailing encrypted field) seems best. (restricted to TLS 1.3+ clie=
nts,

>> though)

>

>

> This would need to be limited to 1.3 in any case because in all the ot=
her

> cases it would be illegal.





Why do you believe that it would be "illegal" for a TLSv1.=
[012] server

to return a "Supported Elliptic Curves" TLS extension in ServerHe=
llo

in response to the presence of such a TLS extension in ClientHello?



rfc4492 does not define semantics for the presence of "Supported Ellip=
tic

Curves" TLS extension in ServerHello, but on a quick read, it also doe=
s

not prohibit including/sending it.



https://tools.ietf.org/html/rfc4492#section-5.2

Well, the draft says that it is defining two=
 ClientHello extensions
(supported elliptic curves and supported =
point formats) and that it is defining
one ServerHello extension,=
 so if the server is sending supported elliptic
curves it's d=
oing something undefined. I don't think you need to have
an e=
xplicit prohibition to suggest that doing something undefined isn't
great.

From an implementation perspective, =
I wouldn't be surprised if client
implementations choked on t=
he server sending this. I had to check
to see if NSS would do so.=
 It doesn't, but given the way the code
is written, it wouldn=
't have surprised me if it checked that all extensions
were h=
andled and choked otherwise.

-Ekr
=C2=A0=

=C2=A0

-Martin





--94eb2c07c35efcaffd0522b17d9d--


From nobody Thu Oct 22 06:33:27 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0981A6F86 for ; Thu, 22 Oct 2015 06:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 oQLaiKiL3JhO for ; Thu, 22 Oct 2015 06:33:25 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002: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 52DDD1A6F6B for ; Thu, 22 Oct 2015 06:33:25 -0700 (PDT)
Received: by ykaz22 with SMTP id z22so82567322yka.2 for ; Thu, 22 Oct 2015 06:33: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:content-type; bh=of9RnE+bIk1veR/Vr4v3eBaNJXkW2KpVUbr24uDrVJo=; b=jy2JclNpuBJjorT4APJo1AefQrpNeg6+rzKS0ebqYFTQ0ku9smaR0zj8+00a4LmJDO lbKfQaogEFAnMGznczkWwdiEymLIQ+vGUit73GK495KCnB/ByPZmmUlDehf4EeK2i984 WiIbw7/8xS4mf8dgfKuT/AxqdGy10Wt7SluC/UjqORXVdPp/rtW/1hPRjy0WdPWOO9+D Roh8lVLd38POB2xsc8kd+/StHdZV2glPwSK749XKBf2XPPJqVl7rGSlpGaZtkkDuIC7o AuxF9ed0KSEbwTsbKA8A1BJumAz5FipB6vYyRXnsQq6Bvu1/pw7qn7RAFmUI/19J6oG0 v8pA==
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-type; bh=of9RnE+bIk1veR/Vr4v3eBaNJXkW2KpVUbr24uDrVJo=; b=GhyXkAlE7tCvvYcPrf7k6x3ZGsJm2VMO32y2BJ8SIuY/1wb8CI/pWKZql3IarvPB/D mwDwhyeQrh2TRPnEZ8fcQO2VP+tjC/S+YQ/6r2eNNpiTqpNSek0AbdJ8cRJ3mn7FaaP5 M5W/T4w0gHw2X9vA3CUnEWEtf/o5Afcw2Yf7+1SsSxjBT4TEDq564UKUrBP3CfiE5tJw 3BqRdi1JFtRmvvBTD4EMOfmlU5ZCHpLS5/W3KjL9T0FoRHG21Qgw/bIdg4Yoi1AiY0Gc /OViZve3p56JAm5i3m0F7pLfs9XM5E2hz0BJWMIne22O8e+BCFkklbG7hGhrLWoPZwyT +omg==
X-Gm-Message-State: ALoCoQnv3i9ofNdEpR48npB52f3k4YDc5oFpFYDqrgQAGPc6ObRimK6nW30sX8G/MEWSppGdRiwf
X-Received: by 10.129.106.9 with SMTP id f9mr11987897ywc.223.1445520804635; Thu, 22 Oct 2015 06:33:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 06:32:45 -0700 (PDT)
In-Reply-To: 
References:       
From: Eric Rescorla 
Date: Thu, 22 Oct 2015 06:32:45 -0700
Message-ID: 
To: Adam Langley 
Content-Type: multipart/alternative; boundary=001a114934da139abe0522b18a91
Archived-At: 
Cc: David McGrew , "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 13:33:27 -0000

--001a114934da139abe0522b18a91
Content-Type: text/plain; charset=UTF-8

I'm mostly convinced by this text in RFC 5116:
http://tools.ietf.org/html/rfc5116#section-2.1

   Because the authenticated decryption process
   detects incorrect nonce values, no security failure will result if a
   nonce is incorrectly reconstructed and fed into an authenticated
   decryption operation.  Any nonce reconstruction method will need to
   take into account the possibility of loss or reorder of ciphertexts
  between the encryption and decryption processes.

It would probably be worth checking with the cryptographers in the room.

CCing Hugo and McGrew.

-Ekr




On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley 
wrote:

> On Monday, October 19, 2015, Martin Thomson 
> wrote:
>
>> On 19 October 2015 at 11:17, Eric Rescorla  wrote:
>> > Yeah, I think that's riding the nonce far too hard.
>>
>> On what basis?  Any change in the nonce will cause the record
>> decryption to fail.  That's the property we're looking for here, isn't
>> it?
>
>
> I don't believe that there's any reason to include the sequence number in
> the AD input of an AEAD. I think that an empty AD for TLS would be fine now
> that the content type is encrypted. (Not that I deeply care either way.)
>
>
> Cheers
>
> AGL
>
>
> --
> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>

--001a114934da139abe0522b18a91
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm mostly convinced by this text in RFC 5116:

   Because the authenticated =
decryption process
   detects incorrect nonce values, no security failure will result if a
   nonce is incorrectly reconstructed and fed into an authenticated
   decryption operation.  Any nonce reconstruction method will need to
   take into account the possibility of loss or reorder of ciphertex=
ts
   between the encryption and d=
ecryption processes.

It would =
probably be worth checking with the cryptographers in the room.
CCing Hugo and=
 McGrew.
-Ekr



On Mon, Oct 19=
, 2015 at 5:46 PM, Adam Langley <agl@imperialviolet.org> wrote:
On Monday, October 19, 2015, Martin Thomson <martin.thomson@gmail.com>=
 wrote:
On 19 October 2015 at 11:17, Eric=
 Rescorla <ekr@rtfm.com> wrote:

> Yeah, I think that's riding the nonce far too hard.



On what basis?=C2=A0 Any change in the nonce will cause the record

decryption to fail.=C2=A0 That's the property we're looking for her=
e, isn't

it?

I don't believe that th=
ere's any reason to include the sequence number in the AD input of an A=
EAD. I think that an empty AD for TLS would be fine now that the content ty=
pe is encrypted. (Not that I deeply care either way.)

<=
div>
Cheers

AGL


-- 
Adam Langley agl@imperialviolet.org https://www.imperi=
alviolet.org





--001a114934da139abe0522b18a91--


From nobody Thu Oct 22 07:00:12 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB261ACDB9 for ; Thu, 22 Oct 2015 07:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbS5M7Me2f2C for ; Thu, 22 Oct 2015 07:00:04 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5AE1ACDBF for ; Thu, 22 Oct 2015 07:00:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13522; q=dns/txt; s=iport; t=1445522404; x=1446732004; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6hNTz1zQpWmao2ZcWoHU7CJi5bC23GwQCntSxWGbO/4=; b=cDEH5MktrvLXKjQyHO3tzSYEJn2krQq1MJlVDJFtwkRfTW+xCNOFM8qz 5M7sdQJwCAesPRigCg9CwN16h0f8wQQ6WYbCFlovx48w/hHLWIJYeR8R+ MaN3uYPijbyHagM1HN/twbtOBjZVwT6TCwVR+Zplwl3dHmj1p0Jho4pjH o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D2AQBl6yhW/4oNJK1egmlNVG8GvhUBDYFZIYV8AhyBKDgUAQEBAQEBAYEKhC4BAQEEIwpMEAIBCA4DBAEBARUSAwICAh8RFAkIAgQBDQUIiBMDEg2yFY4ZDYRnAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIt1glCCOQQGAQqCX4FFBZJdg04BhRiGEIFugieSOYdMAREOAQFChANyAYU8gQYBAQE
X-IronPort-AV: E=Sophos; i="5.20,182,1444694400"; d="scan'208,217"; a="38074362"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP; 22 Oct 2015 14:00:03 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9ME03RX006064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 14:00:03 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 08:59:42 -0500
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 08:59:43 -0500
From: "David McGrew (mcgrew)" 
To: Eric Rescorla , Adam Langley 
Thread-Topic: [TLS] Version in record MAC
Thread-Index: AQHRDM4vbQUJq0igmkWy2KnwRiRoYZ53iiqA
Date: Thu, 22 Oct 2015 13:59:42 +0000
Message-ID: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.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: [10.24.41.221]
Content-Type: multipart/alternative; boundary="_000_811734cd29d64adc98c5388870611575XCHALN004ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 14:00:11 -0000

--_000_811734cd29d64adc98c5388870611575XCHALN004ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogVGh1cnNk
YXksIE9jdG9iZXIgMjIsIDIwMTUgOTozMyBBTQ0KVG86IEFkYW0gTGFuZ2xleQ0KQ2M6IE1hcnRp
biBUaG9tc29uOyB0bHNAaWV0Zi5vcmc7IEh1Z28gS3Jhd2N6eWs7IERhdmlkIE1jR3JldyAobWNn
cmV3KQ0KU3ViamVjdDogUmU6IFtUTFNdIFZlcnNpb24gaW4gcmVjb3JkIE1BQw0KDQpJJ20gbW9z
dGx5IGNvbnZpbmNlZCBieSB0aGlzIHRleHQgaW4gUkZDIDUxMTY6DQpodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9yZmM1MTE2I3NlY3Rpb24tMi4xDQoNCg0KICAgQmVjYXVzZSB0aGUgYXV0aGVu
dGljYXRlZCBkZWNyeXB0aW9uIHByb2Nlc3MNCg0KICAgZGV0ZWN0cyBpbmNvcnJlY3Qgbm9uY2Ug
dmFsdWVzLCBubyBzZWN1cml0eSBmYWlsdXJlIHdpbGwgcmVzdWx0IGlmIGENCg0KICAgbm9uY2Ug
aXMgaW5jb3JyZWN0bHkgcmVjb25zdHJ1Y3RlZCBhbmQgZmVkIGludG8gYW4gYXV0aGVudGljYXRl
ZA0KDQogICBkZWNyeXB0aW9uIG9wZXJhdGlvbi4gIEFueSBub25jZSByZWNvbnN0cnVjdGlvbiBt
ZXRob2Qgd2lsbCBuZWVkIHRvDQoNCiAgIHRha2UgaW50byBhY2NvdW50IHRoZSBwb3NzaWJpbGl0
eSBvZiBsb3NzIG9yIHJlb3JkZXIgb2YgY2lwaGVydGV4dHMNCg0KICAgYmV0d2VlbiB0aGUgZW5j
cnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBwcm9jZXNzZXMuDQoNCkl0IHdvdWxkIHByb2JhYmx5IGJl
IHdvcnRoIGNoZWNraW5nIHdpdGggdGhlIGNyeXB0b2dyYXBoZXJzIGluIHRoZSByb29tLg0KDQpD
Q2luZyBIdWdvIGFuZCBNY0dyZXcuDQoNCi1Fa3INCg0KDQoNCg0KDQpPbiBNb24sIE9jdCAxOSwg
MjAxNSBhdCA1OjQ2IFBNLCBBZGFtIExhbmdsZXkgPGFnbEBpbXBlcmlhbHZpb2xldC5vcmc8bWFp
bHRvOmFnbEBpbXBlcmlhbHZpb2xldC5vcmc+PiB3cm90ZToNCk9uIE1vbmRheSwgT2N0b2JlciAx
OSwgMjAxNSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86
bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpPbiAxOSBPY3RvYmVyIDIwMTUgYXQg
MTE6MTcsIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4g
d3JvdGU6DQo+IFllYWgsIEkgdGhpbmsgdGhhdCdzIHJpZGluZyB0aGUgbm9uY2UgZmFyIHRvbyBo
YXJkLg0KDQpPbiB3aGF0IGJhc2lzPyAgQW55IGNoYW5nZSBpbiB0aGUgbm9uY2Ugd2lsbCBjYXVz
ZSB0aGUgcmVjb3JkDQpkZWNyeXB0aW9uIHRvIGZhaWwuICBUaGF0J3MgdGhlIHByb3BlcnR5IHdl
J3JlIGxvb2tpbmcgZm9yIGhlcmUsIGlzbid0DQppdD8NCg0KSSBkb24ndCBiZWxpZXZlIHRoYXQg
dGhlcmUncyBhbnkgcmVhc29uIHRvIGluY2x1ZGUgdGhlIHNlcXVlbmNlIG51bWJlciBpbiB0aGUg
QUQgaW5wdXQgb2YgYW4gQUVBRC4gSSB0aGluayB0aGF0IGFuIGVtcHR5IEFEIGZvciBUTFMgd291
bGQgYmUgZmluZSBub3cgdGhhdCB0aGUgY29udGVudCB0eXBlIGlzIGVuY3J5cHRlZC4gKE5vdCB0
aGF0IEkgZGVlcGx5IGNhcmUgZWl0aGVyIHdheS4pDQoNCkFncmVlZC4gIEFueSB2YWx1ZSB0aGF0
IGFsd2F5cyBnb2VzIGludG8gdGhlIG5vbmNlIGRvZXNu4oCZdCBuZWVkIHRvIGdvIGludG8gdGhl
IEFELg0KDQpEYXZpZA0KDQoNCkNoZWVycw0KDQpBR0wNCg0KDQotLQ0KQWRhbSBMYW5nbGV5IGFn
bEBpbXBlcmlhbHZpb2xldC5vcmc8bWFpbHRvOmFnbEBpbXBlcmlhbHZpb2xldC5vcmc+IGh0dHBz
Oi8vd3d3LmltcGVyaWFsdmlvbGV0Lm9yZw0KDQo=

--_000_811734cd29d64adc98c5388870611575XCHALN004ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv
Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD
aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0
dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7
DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6
aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz
aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2
LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i
MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs
YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk
U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g
RXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU
aHVyc2RheSwgT2N0b2JlciAyMiwgMjAxNSA5OjMzIEFNPGJyPg0KPGI+VG86PC9iPiBBZGFtIExh
bmdsZXk8YnI+DQo8Yj5DYzo8L2I+IE1hcnRpbiBUaG9tc29uOyB0bHNAaWV0Zi5vcmc7IEh1Z28g
S3Jhd2N6eWs7IERhdmlkIE1jR3JldyAobWNncmV3KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W1RMU10gVmVyc2lvbiBpbiByZWNvcmQgTUFDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij5JJ20gbW9zdGx5IGNvbnZpbmNlZCBieSB0aGlzIHRleHQgaW4gUkZDIDUxMTY6PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUxMTYjc2VjdGlvbi0y
LjEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUxMTYjc2VjdGlvbi0yLjE8L2E+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IEJlY2F1
c2UgdGhlIGF1dGhlbnRpY2F0ZWQgZGVjcnlwdGlvbiBwcm9jZXNzPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5i
c3A7IGRldGVjdHMgaW5jb3JyZWN0IG5vbmNlIHZhbHVlcywgbm8gc2VjdXJpdHkgZmFpbHVyZSB3
aWxsIHJlc3VsdCBpZiBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IG5vbmNlIGlzIGluY29ycmVjdGx5
IHJlY29uc3RydWN0ZWQgYW5kIGZlZCBpbnRvIGFuIGF1dGhlbnRpY2F0ZWQ8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz
cDsmbmJzcDsgZGVjcnlwdGlvbiBvcGVyYXRpb24uJm5ic3A7IEFueSBub25jZSByZWNvbnN0cnVj
dGlvbiBtZXRob2Qgd2lsbCBuZWVkIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRha2UgaW50byBh
Y2NvdW50IHRoZSBwb3NzaWJpbGl0eSBvZiBsb3NzIG9yIHJlb3JkZXIgb2YgYzwvc3Bhbj5pcGhl
cnRleHRzPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYmV0d2VlbiB0aGUgZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlv
biBwcm9jZXNzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQgd291bGQgcHJvYmFibHkgYmUgd29ydGggY2hlY2tpbmcg
d2l0aCB0aGUgY3J5cHRvZ3JhcGhlcnMgaW4gdGhlIHJvb20uPC9zcGFuPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q0NpbmcgSHVnbyBh
bmQgTWNHcmV3Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPi1Fa3I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIE1vbiwgT2N0IDE5LCAyMDE1IGF0IDU6NDYgUE0sIEFkYW0g
TGFuZ2xleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFnbEBpbXBlcmlhbHZpb2xldC5vcmciIHRhcmdl
dD0iX2JsYW5rIj5hZ2xAaW1wZXJpYWx2aW9sZXQub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj5PbiBNb25kYXksIE9jdG9iZXIgMTksIDIwMTUsIE1hcnRpbiBUaG9tc29uICZs
dDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gMTkgT2N0
b2JlciAyMDE1IGF0IDExOjE3LCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWty
QHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFllYWgsIEkg
dGhpbmsgdGhhdCdzIHJpZGluZyB0aGUgbm9uY2UgZmFyIHRvbyBoYXJkLjxicj4NCjxicj4NCk9u
IHdoYXQgYmFzaXM/Jm5ic3A7IEFueSBjaGFuZ2UgaW4gdGhlIG5vbmNlIHdpbGwgY2F1c2UgdGhl
IHJlY29yZDxicj4NCmRlY3J5cHRpb24gdG8gZmFpbC4mbmJzcDsgVGhhdCdzIHRoZSBwcm9wZXJ0
eSB3ZSdyZSBsb29raW5nIGZvciBoZXJlLCBpc24ndDxicj4NCml0PzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBkb24ndCBiZWxpZXZlIHRo
YXQgdGhlcmUncyBhbnkgcmVhc29uIHRvIGluY2x1ZGUgdGhlIHNlcXVlbmNlIG51bWJlciBpbiB0
aGUgQUQgaW5wdXQgb2YgYW4gQUVBRC4gSSB0aGluayB0aGF0IGFuIGVtcHR5IEFEIGZvciBUTFMg
d291bGQgYmUgZmluZSBub3cgdGhhdCB0aGUgY29udGVudCB0eXBlIGlzIGVuY3J5cHRlZC4gKE5v
dCB0aGF0IEkgZGVlcGx5IGNhcmUgZWl0aGVyDQogd2F5Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkFncmVlZC4mbmJzcDsgQW55IHZhbHVlIHRoYXQgYWx3YXlzIGdvZXMgaW50byB0aGUg
bm9uY2UgZG9lc27igJl0IG5lZWQgdG8gZ28gaW50byB0aGUgQUQuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYXZpZDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q2hlZXJzPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QUdMPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls
ZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS0gPC9z
cGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkFkYW0gTGFuZ2xleSA8YSBocmVmPSJtYWls
dG86YWdsQGltcGVyaWFsdmlvbGV0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KYWdsQGltcGVyaWFs
dmlvbGV0Lm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaW1wZXJpYWx2aW9sZXQub3JnIiB0
YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pbXBlcmlhbHZpb2xldC5vcmc8L2E+PC9zcGFu
Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_811734cd29d64adc98c5388870611575XCHALN004ciscocom_--


From nobody Thu Oct 22 07:07:56 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090541ACE06 for ; Thu, 22 Oct 2015 07:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 RFLrSXM2h8Gz for ; Thu, 22 Oct 2015 07:07:52 -0700 (PDT)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 A0C1E1ACECD for ; Thu, 22 Oct 2015 07:07:44 -0700 (PDT)
Received: by ykaz22 with SMTP id z22so83697326yka.2 for ; Thu, 22 Oct 2015 07:07:44 -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:content-type; bh=EDZ3s74AgkhDKmixg8nV8iYhe/ZwQJDgoWq8BfEVYJc=; b=fhjxSXliyKB6vvI83lndvap2iMFIje+mUlN+cz9xXA01MqdO+Y/mYPwqcgmV2yBnsR 4bGtgbEBt3OYP9BhJUXo/xYuuzetH0pVqstLGG8FJYpBsSQBffHEhNXl+DHnA+DFDnoS PFlMlOha3HWlZxIjT/yD4XKhyomR/gRMfEBusA8ixg+HtaL2Lj0/OzoMBYcjGxKux3uK 1KqtsGQww0JJMtw9ypRSM89U3LXUWy9yDGIO/j0WDobPqAtNjW/moPypmckFP4Rj7c/R NCf624bY1okjtjnHfPDCpYgx07psJqIDEHNZveqgE77O+YeQk9HE9fiKf+gRSP53UkUB R06A==
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-type; bh=EDZ3s74AgkhDKmixg8nV8iYhe/ZwQJDgoWq8BfEVYJc=; b=UAbx+Rv/WA57i7RLWD0oRxljIGyU0Ebxqd4VY1ynyM/lC2XffgDjEiWvsEHCzVOFpD hv8Z1oFsZxPrlbBebUxL2+wP4Ab/ks9SarPlRSNaAW0K2p43ZTNS9kxnKsC/+ap/Mz4z K/uAvDB0OsM9U3Bh2nUESLN/7GDlwwWoA0+ZSGG+Wxi85biF1tFSDqsLEeHiOggV8ruU myhx//axiPnUf4QsQ7zpskxztSaqjyg7CR7ZaP4zgniN7Kv1VoKbSItM3M11MQvLpePE D08j5GJeqJSO0NqZupz1840rOKNHkOvm6ntACriyJxrui6gFkvfbo6sM+RfCEXri/NRG AcdA==
X-Gm-Message-State: ALoCoQlFNo0fADcVf/q7ZVqlvu4Ngh9uZuVQ0bAMpC/7cQ+pA9MGe9za2EWfwi7oE4YzRbAyCTVK
X-Received: by 10.13.223.132 with SMTP id i126mr10920932ywe.129.1445522863913;  Thu, 22 Oct 2015 07:07:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 07:07:04 -0700 (PDT)
In-Reply-To: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com>
References:         <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com>
From: Eric Rescorla 
Date: Thu, 22 Oct 2015 07:07:04 -0700
Message-ID: 
To: "David McGrew (mcgrew)" 
Content-Type: multipart/alternative; boundary=001a114e46c0d1ac4e0522b204ce
Archived-At: 
Cc: Adam Langley , "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 14:07:54 -0000

--001a114e46c0d1ac4e0522b204ce
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the quick response, David. I now agree with Martin and
Adam that we should remove this.

Chairs, I haven't seen any objections any reason I shouldn't make this
change?

-Ekr


On Thu, Oct 22, 2015 at 6:59 AM, David McGrew (mcgrew) 
wrote:

>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Thursday, October 22, 2015 9:33 AM
> *To:* Adam Langley
> *Cc:* Martin Thomson; tls@ietf.org; Hugo Krawczyk; David McGrew (mcgrew)
> *Subject:* Re: [TLS] Version in record MAC
>
>
>
> I'm mostly convinced by this text in RFC 5116:
>
> http://tools.ietf.org/html/rfc5116#section-2.1
>
>
>
>    Because the authenticated decryption process
>
>    detects incorrect nonce values, no security failure will result if a
>
>    nonce is incorrectly reconstructed and fed into an authenticated
>
>    decryption operation.  Any nonce reconstruction method will need to
>
>    take into account the possibility of loss or reorder of ciphertexts
>
>    between the encryption and decryption processes.
>
> It would probably be worth checking with the cryptographers in the room.
>
> CCing Hugo and McGrew.
>
> -Ekr
>
>
>
>
>
>
>
> On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley 
> wrote:
>
> On Monday, October 19, 2015, Martin Thomson 
> wrote:
>
> On 19 October 2015 at 11:17, Eric Rescorla  wrote:
> > Yeah, I think that's riding the nonce far too hard.
>
> On what basis?  Any change in the nonce will cause the record
> decryption to fail.  That's the property we're looking for here, isn't
> it?
>
>
>
> I don't believe that there's any reason to include the sequence number in
> the AD input of an AEAD. I think that an empty AD for TLS would be fine n=
ow
> that the content type is encrypted. (Not that I deeply care either way.)
>
>
>
> Agreed.  Any value that always goes into the nonce doesn=E2=80=99t need t=
o go into
> the AD.
>
>
>
> David
>
>
>
>
>
> Cheers
>
>
>
> AGL
>
>
>
> --
> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>
>
>

--001a114e46c0d1ac4e0522b204ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for the quick response, David. I now agree with Mar=
tin and
Adam that we should remove this.

=
Chairs, I haven't seen any objections any reason I shouldn't make t=
his
change?

-Ekr


On Thu, =
Oct 22, 2015 at 6:59 AM, David McGrew (mcgrew) <mcgrew@cisco.com> wrote:











=C2=A0


From: Eric Rescorla [mailto:ekr@rtfm.com]


Sent: Thursday, October 22, 2015 9:33 AM

To: Adam Langley

Cc: Martin Thomson; tls@ietf.org; Hugo Krawczyk; David McGrew (mcgrew)

Subject: Re: [TLS] Version in record MAC


=C2=A0




I'm mostly convinced =
by this text in RFC 5116:





=C2=A0






=C2=A0=C2=A0 Because the authenticated decryption=
 process


=C2=A0=C2=A0 detects incorrect nonce values, no s=
ecurity failure will result if a


=C2=A0=C2=A0 nonce is incorrectly reconstructed a=
nd fed into an authenticated


=C2=A0=C2=A0 decryption operation.=C2=A0 Any nonc=
e reconstruction method will need to


=C2=A0=C2=A0 take into account the possibility of=
 loss or reorder of ciphertexts


=C2=A0=C2=A0 between the encryption and decryptio=
n processes.


It would probably be worth checking with the cryp=
tographers in the room.


CCing Hugo and McGrew.


-Ekr


=C2=A0


=C2=A0








=C2=A0




On Mon, Oct 19, 2015 at 5=
:46 PM, Adam Langley <agl@imperialviolet.org> wrote:






On Monday, October 19, 20=
15, Martin Thomson <martin.thomson@gmail.com> wrote:


On 19 October 2015 at 11:=
17, Eric Rescorla <ekr=
@rtfm.com> wrote:

> Yeah, I think that's riding the nonce far too hard.



On what basis?=C2=A0 Any change in the nonce will cause the record

decryption to fail.=C2=A0 That's the property we're looking for her=
e, isn't

it?




=C2=A0










I don't believe that =
there's any reason to include the sequence number in the AD input of an=
 AEAD. I think that an empty AD for TLS would be fine now that the content =
type is encrypted. (Not that I deeply care either
 way.)






=C2=A0


Agreed.=C2=A0 Any value t=
hat always goes into the nonce doesn=E2=80=99t need to go into the AD.


=C2=A0


David


=C2=A0






=C2=A0






Cheers






=C2=A0






AGL








-- 

Adam Langley 
agl@imperialviolet.org 
https://www.imperialviolet.org




=C2=A0












--001a114e46c0d1ac4e0522b204ce--


From nobody Thu Oct 22 07:24:51 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B0A1ACECE for ; Thu, 22 Oct 2015 07:24:47 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkRlTe2uDHmV for ; Thu, 22 Oct 2015 07:24:45 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2941D1A87C8 for ; Thu, 22 Oct 2015 07:24:45 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 221A0284DA6; Thu, 22 Oct 2015 14:24:44 +0000 (UTC)
Date: Thu, 22 Oct 2015 14:24:44 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20151022142443.GS15070@mournblade.imrryr.org>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5628937B.9060403@comodo.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list 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, 22 Oct 2015 14:24:47 -0000

On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote:

> IINM this also changes the fallback for servers that choose to include a
> PKIX trust anchor certificate in the Server Certificate message.

The signatures of trust-anchor (i.e. self-signed) certificates MUST
NOT be constrained by this proposal, even if the WG otherwise
chooses to step outside the proper scope of TLS into PKIX chain
validation.

Please note that the self-signature of the CAcert.org 4096-bit root
CA is MD5.

> Why would it make sense to prohibit the sending of PKIX trust anchor
> certificates that have sha1WithRSAEncryption signatures?

It makes no sense to restrict the signatures of trust-anchors.  It
makes little sense to restrict the signatures certificates servers
can send to clients to be evaluated per the client's policy.

-- 
	Viktor.


From nobody Thu Oct 22 09:18:59 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1271F1A6F12 for ; Thu, 22 Oct 2015 09:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBG_O_ptn7Lu for ; Thu, 22 Oct 2015 09:18:56 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87F71A6EF4 for ; Thu, 22 Oct 2015 09:18:56 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 13A2B33D17F; Thu, 22 Oct 2015 16:18:55 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: tls@ietf.org
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org>
From: Geoffrey Keating 
Date: 22 Oct 2015 09:18:54 -0700
In-Reply-To: <20151022142443.GS15070@mournblade.imrryr.org>
Message-ID: 
Lines: 22
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 16:18:58 -0000

Viktor Dukhovni  writes:

> On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote:
> 
> > IINM this also changes the fallback for servers that choose to include a
> > PKIX trust anchor certificate in the Server Certificate message.
> 
> The signatures of trust-anchor (i.e. self-signed) certificates MUST
> NOT be constrained by this proposal, even if the WG otherwise
> chooses to step outside the proper scope of TLS into PKIX chain
> validation.

I believe nothing is constrained by this proposal in the form you're
thinking.  That is, it's only if you have two versions of the root,
one with a requested algorithm and one without, that this proposal
comes into play.

At least, I think that's the intent.  It might help to clarify this in
the proposal.  It should be noted that the situation can become quite
complicated, for example it's possible that there might be one chain
which uses only SHA-2 which chains to one newer root, and another
chain which uses mostly SHA-1 and chains to a different older root.


From nobody Thu Oct 22 09:19:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01581A6EF2 for ; Thu, 22 Oct 2015 09:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCiCJKnnWlNA for ; Thu, 22 Oct 2015 09:19:28 -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 0084F1A3BA6 for ; Thu, 22 Oct 2015 09:19:27 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3E32C424AE2 for ; Thu, 22 Oct 2015 16:19:27 +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 283414E5DA for ; Thu, 22 Oct 2015 16:19:27 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445530767; bh=aNp9RtebWJ6PTcFyr8DI3aBGjYP/u+RvCQrqnOubbzs=; l=610; h=To:References:From:Date:In-Reply-To:From; b=v/afVUXc1u0OHKWGgXsMDJUdEUgB7OOPgIc2LUKlVv6ZXGsJ2oHGQ708ApUnKZgMa mvRor2iyEr12Qy0q9MupinwthLlnkUsxTtmHZtP0FjvF87cEekQWq1UMXx6HCtZw90 MAYqOCoSfcM0jrMA/S9MyVlq1tLcFqfYPLt44YbU=
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 0B1472055 for ; Thu, 22 Oct 2015 16:19:26 +0000 (GMT)
To: tls@ietf.org
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org>
From: Benjamin Kaduk 
Message-ID: <56290C8E.9040409@akamai.com>
Date: Thu, 22 Oct 2015 11:19:26 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20151022142443.GS15070@mournblade.imrryr.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 16:19:29 -0000

On 10/22/2015 09:24 AM, Viktor Dukhovni wrote:
>
>> Why would it make sense to prohibit the sending of PKIX trust anchor
>> certificates that have sha1WithRSAEncryption signatures?
> It makes no sense to restrict the signatures of trust-anchors.  It
> makes little sense to restrict the signatures certificates servers
> can send to clients to be evaluated per the client's policy.
>

% a certificate that specifies a trust anchor MAY be omitted from the chain

The client cannot decide that the signature on the root cert the server
sent is bad, if the server does not send the root cert.

-Ben


From nobody Thu Oct 22 10:06:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641931B39C8 for ; Thu, 22 Oct 2015 10:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztWJCeG3sijR for ; Thu, 22 Oct 2015 10:06:11 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1981B39C9 for ; Thu, 22 Oct 2015 10:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qtt8DvHJOejZCiv9HyWy0AIvOSHkoIRto0k2Y2yNLCk=; b=bOHx/GFhTiMza4KqV1Ii0PfsPemfVrX0vDSlT8K+w3QpTgEBw7reoOv4g/FYrJtAC6PGX8aXEEkdoWcuDdATrAup/GDDmAkSlUC/kt4zBoDmmswJowyo7WhBhVqTHlEJOXTPv7ay2slvfhdcT6/D/GaRauIT2bF7Saq76OLdf3o=
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 17:06:04 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 17:06:04 +0000
From: Andrei Popov 
To: Eric Rescorla , "mrex@sap.com" 
Thread-Topic: [TLS] Allow NamedGroups from the server?
Thread-Index: AQHRDFwySYYLbapvF0OM4bIxRSdhpp52qJkAgAABqACAAM8DgIAACVYAgAA7XHA=
Date: Thu, 22 Oct 2015 17:06:04 +0000
Message-ID: 
References:  <20151022125557.9B1651A31C@ld9781.wdf.sap.corp> 
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-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:lOJGU5TvLh7yoy3jmHuelhAIukzme+29w7psYtiY6FH1nauzMsYAlRx4MWteYGz2FZvwfRFo1MRcGq/4YhUo648D4h3V+Gztn3uQMLjtEQ263uOwtuRer8Rj3JgCRCdqMmKom6UCDtNvY4EbeDECQw==; 24:piCGiW6Z9Gcus4MbU63FE4O6WqKp0qPIlnelgBi2wu4inenk+0TQyB6FwSipVUqa4pXB2cn1CKPkipSS7ZgaGrg8jrzmuPBXhg/X2lwjQxY=; 20:BTMSNl9c5fRpTXc8FeG+KeISgR6stFZakgRogWM4Y+DU6KkbDosGxrjhvOa9lk3SC63auwg9nhVZz4+uLVt5xQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(189930954265078)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(102215026)(61426024)(61427024); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; 
x-forefront-prvs: 0737B96801
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(377454003)(189002)(60444003)(5002640100001)(19617315012)(15975445007)(5003600100002)(10090500001)(19580395003)(105586002)(87936001)(86362001)(77096005)(19300405004)(86612001)(106356001)(189998001)(102836002)(99286002)(2950100001)(19609705001)(2900100001)(74316001)(76576001)(92566002)(10290500002)(11100500001)(50986999)(5004730100002)(16236675004)(54356999)(5005710100001)(5007970100001)(8990500004)(19580405001)(101416001)(33656002)(10400500002)(97736004)(122556002)(106116001)(5001770100001)(19625215002)(2501003)(40100003)(81156007)(64706001)(46102003)(5001960100002)(5008740100001)(76176999)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396D9A28A7F73B21E6609728C270BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 17:06:04.6829 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:06:15 -0000

--_000_BLUPR03MB1396D9A28A7F73B21E6609728C270BLUPR03MB1396namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V291bGQgdGhlIHNlcnZlci1zaWRlIOKAnHN1cHBvcnRlZCBlbGxpcHRpYyBjdXJ2ZXPigJ0gYmUg
dXNlZCBmb3IgYW55dGhpbmcgb3RoZXIgdGhhbiBndWlkaW5nIGNsaWVudCBjZXJ0IHNlbGVjdGlv
bj8NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBUaHVyc2RheSwgT2N0
b2JlciAyMiwgMjAxNSA2OjI5IEFNDQpUbzogbXJleEBzYXAuY29tDQpDYzogdGxzQGlldGYub3Jn
DQpTdWJqZWN0OiBSZTogW1RMU10gQWxsb3cgTmFtZWRHcm91cHMgZnJvbSB0aGUgc2VydmVyPw0K
DQoNCg0KT24gVGh1LCBPY3QgMjIsIDIwMTUgYXQgNTo1NSBBTSwgTWFydGluIFJleCA8bXJleEBz
YXAuY29tPG1haWx0bzptcmV4QHNhcC5jb20+PiB3cm90ZToNCkVyaWMgUmVzY29ybGEgd3JvdGU6
DQo+IERhdmUgR2FycmV0dCA8ZGF2ZW1nYXJyZXR0QGdtYWlsLmNvbTxtYWlsdG86ZGF2ZW1nYXJy
ZXR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KPg0KPj4gT24gV2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAy
MDE1IDA3OjU2OjEzIHBtIEVyaWMgUmVzY29ybGEgd3JvdGU6DQo+Pj4gaHR0cHM6Ly9naXRodWIu
Y29tL3Rsc3dnL3RsczEzLXNwZWMvaXNzdWVzLzI5MjxodHRwczovL25hMDEuc2FmZWxpbmtzLnBy
b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZmdpdGh1Yi5jb20lMmZ0bHN3
ZyUyZnRsczEzLXNwZWMlMmZpc3N1ZXMlMmYyOTImZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92
JTQwbWljcm9zb2Z0LmNvbSU3YzU1ZmEwMTlkMmI1MTQwNzc4NjgxMDhkMmRhZTRlYWI5JTdjNzJm
OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTRGZlVmRDc4V2NPS0w2SnV2
SFE0YVg0anJYWFIzNVhEODU4RGhPVE1rZGMlM2Q+DQo+Pj4NCj4+PiBQcmVzZW50bHksIFJGQyA0
NDkyIG9ubHkgc3BlY2lmaWVzIHRoZSBFQyBwb2ludHMgaXQgY2FuIHN1cHBvcnQgaW4NCj4+PiBT
ZXJ2ZXJIZWxsbywgYnV0IGRvZXMgbm90IGxldCB0aGUgc2VydmVyIGluZGljYXRlIHdoaWNoIEVD
IGN1cnZlcyBpdA0KPj4+IHN1cHBvcnRzLiBVbmxlc3MgSSdtIG1pc3Npbmcgc29tZXRoaW5nLCB0
aGlzIG1lYW5zIHRoYXQgdGhlcmUncw0KPj4+IG5vIHdheSBmb3IgdGhlIHNlcnZlciB0byBpbmRp
Y2F0ZSB3aGF0IGdyb3VwcyBpdCB3b3VsZCBzdXBwb3J0Lg0KPj4+DQo+Pj4gVGhhdCBzZWVtcyBs
ZXNzIHRoYW4gaWRlYWwuIFRoZXJlIHNlZW0gbGlrZSB0aHJlZSBvcHRpb25zIGhlcmU6DQo+Pj4N
Cj4+PiAxLiBQdXQgaXQgaW4gQ2VydGlmaWNhdGVSZXF1ZXN0DQo+Pj4gMi4gU2VuZCBpdCBpbiBT
ZXJ2ZXJIZWxsbw0KPj4+IDMuIERvIG5vdGhpbmcuDQo+Pg0KPj4gSSBwcmVmZXIgIzIuIEkgZG9u
J3QgdGhpbmsgZW5jcnlwdGlvbiBpcyBuZWNlc3NhcmlseSByZXF1aXJlZCBmb3IgdGhpcywNCj4+
IGJ1dCBFbmNyeXB0ZWRFeHRlbnNpb25zIGlzIGZpbmUgdG9vIChNYXJ0aW4ncyAyYikuDQo+Pg0K
Pj4gSSdtIGdlbmVyYWxseSBhZ2FpbnN0IHB1dHRpbmcgaXQgaW4gQ2VydGlmaWNhdGVSZXF1ZXN0
LCBhcyB3ZSdyZSByZXVzaW5nDQo+PiBhbiBleGlzdGluZyBoZWxsbyBleHRlbnNpb24gc28ga2Vl
cGluZyBpdCBpbiBhIGhlbGxvIG1lc3NhZ2UgKG9yIGl0J3MNCj4+IHRyYWlsaW5nIGVuY3J5cHRl
ZCBmaWVsZCkgc2VlbXMgYmVzdC4gKHJlc3RyaWN0ZWQgdG8gVExTIDEuMysgY2xpZW50cywNCj4+
IHRob3VnaCkNCj4NCj4NCj4gVGhpcyB3b3VsZCBuZWVkIHRvIGJlIGxpbWl0ZWQgdG8gMS4zIGlu
IGFueSBjYXNlIGJlY2F1c2UgaW4gYWxsIHRoZSBvdGhlcg0KPiBjYXNlcyBpdCB3b3VsZCBiZSBp
bGxlZ2FsLg0KDQoNCldoeSBkbyB5b3UgYmVsaWV2ZSB0aGF0IGl0IHdvdWxkIGJlICJpbGxlZ2Fs
IiBmb3IgYSBUTFN2MS5bMDEyXSBzZXJ2ZXINCnRvIHJldHVybiBhICJTdXBwb3J0ZWQgRWxsaXB0
aWMgQ3VydmVzIiBUTFMgZXh0ZW5zaW9uIGluIFNlcnZlckhlbGxvDQppbiByZXNwb25zZSB0byB0
aGUgcHJlc2VuY2Ugb2Ygc3VjaCBhIFRMUyBleHRlbnNpb24gaW4gQ2xpZW50SGVsbG8/DQoNCnJm
YzQ0OTIgZG9lcyBub3QgZGVmaW5lIHNlbWFudGljcyBmb3IgdGhlIHByZXNlbmNlIG9mICJTdXBw
b3J0ZWQgRWxsaXB0aWMNCkN1cnZlcyIgVExTIGV4dGVuc2lvbiBpbiBTZXJ2ZXJIZWxsbywgYnV0
IG9uIGEgcXVpY2sgcmVhZCwgaXQgYWxzbyBkb2VzDQpub3QgcHJvaGliaXQgaW5jbHVkaW5nL3Nl
bmRpbmcgaXQuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NDkyI3NlY3Rpb24t
NS4yPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmcmZjNDQ5MiUyM3NlY3Rpb24tNS4y
JmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2M1NWZhMDE5ZDJi
NTE0MDc3ODY4MTA4ZDJkYWU0ZWFiOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3
JTdjMSZzZGF0YT1qTm9ITSUyZnJQOWp4a1JVUEZhSXNTelhmSmNWbUJ3bnFOTThNN05tMnZ0d2Ml
M2Q+DQoNCldlbGwsIHRoZSBkcmFmdCBzYXlzIHRoYXQgaXQgaXMgZGVmaW5pbmcgdHdvIENsaWVu
dEhlbGxvIGV4dGVuc2lvbnMNCihzdXBwb3J0ZWQgZWxsaXB0aWMgY3VydmVzIGFuZCBzdXBwb3J0
ZWQgcG9pbnQgZm9ybWF0cykgYW5kIHRoYXQgaXQgaXMgZGVmaW5pbmcNCm9uZSBTZXJ2ZXJIZWxs
byBleHRlbnNpb24sIHNvIGlmIHRoZSBzZXJ2ZXIgaXMgc2VuZGluZyBzdXBwb3J0ZWQgZWxsaXB0
aWMNCmN1cnZlcyBpdCdzIGRvaW5nIHNvbWV0aGluZyB1bmRlZmluZWQuIEkgZG9uJ3QgdGhpbmsg
eW91IG5lZWQgdG8gaGF2ZQ0KYW4gZXhwbGljaXQgcHJvaGliaXRpb24gdG8gc3VnZ2VzdCB0aGF0
IGRvaW5nIHNvbWV0aGluZyB1bmRlZmluZWQgaXNuJ3QNCmdyZWF0Lg0KDQpGcm9tIGFuIGltcGxl
bWVudGF0aW9uIHBlcnNwZWN0aXZlLCBJIHdvdWxkbid0IGJlIHN1cnByaXNlZCBpZiBjbGllbnQN
CmltcGxlbWVudGF0aW9ucyBjaG9rZWQgb24gdGhlIHNlcnZlciBzZW5kaW5nIHRoaXMuIEkgaGFk
IHRvIGNoZWNrDQp0byBzZWUgaWYgTlNTIHdvdWxkIGRvIHNvLiBJdCBkb2Vzbid0LCBidXQgZ2l2
ZW4gdGhlIHdheSB0aGUgY29kZQ0KaXMgd3JpdHRlbiwgaXQgd291bGRuJ3QgaGF2ZSBzdXJwcmlz
ZWQgbWUgaWYgaXQgY2hlY2tlZCB0aGF0IGFsbCBleHRlbnNpb25zDQp3ZXJlIGhhbmRsZWQgYW5k
IGNob2tlZCBvdGhlcndpc2UuDQoNCi1Fa3INCg0KDQotTWFydGluDQoNCg==

--_000_BLUPR03MB1396D9A28A7F73B21E6609728C270BLUPR03MB1396namp_
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
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V291bGQgdGhlIHNlcnZlci1zaWRlIOKA
nHN1cHBvcnRlZCBlbGxpcHRpYyBjdXJ2ZXPigJ0gYmUgdXNlZCBmb3IgYW55dGhpbmcgb3RoZXIg
dGhhbiBndWlkaW5nIGNsaWVudCBjZXJ0IHNlbGVjdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0Bp
ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6
PC9iPiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAxNSA2OjI5IEFNPGJyPg0KPGI+VG86PC9iPiBt
cmV4QHNhcC5jb208YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSZTogW1RMU10gQWxsb3cgTmFtZWRHcm91cHMgZnJvbSB0aGUgc2VydmVyPzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgT2N0IDIyLCAyMDE1IGF0IDU6NTUgQU0sIE1hcnRp
biBSZXggJmx0OzxhIGhyZWY9Im1haWx0bzptcmV4QHNhcC5jb20iIHRhcmdldD0iX2JsYW5rIj5t
cmV4QHNhcC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5FcmljIFJlc2NvcmxhIHdyb3RlOjxicj4NCiZndDsgRGF2ZSBH
YXJyZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2ZW1nYXJyZXR0QGdtYWlsLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPmRhdmVtZ2FycmV0dEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7
PGJyPg0KJmd0OyZndDsgT24gV2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAyMDE1IDA3OjU2OjEzIHBt
IEVyaWMgUmVzY29ybGEgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v
bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJm
Z2l0aHViLmNvbSUyZnRsc3dnJTJmdGxzMTMtc3BlYyUyZmlzc3VlcyUyZjI5MiZhbXA7ZGF0YT0w
MSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3YzU1ZmEwMTlkMmI1MTQwNzc4
NjgxMDhkMmRhZTRlYWI5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFt
cDtzZGF0YT00RmZVZkQ3OFdjT0tMNkp1dkhRNGFYNGpyWFhSMzVYRDg1OERoT1RNa2RjJTNkIiB0
YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzMTMtc3BlYy9pc3N1
ZXMvMjkyPC9hPjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBQcmVzZW50bHks
IFJGQyA0NDkyIG9ubHkgc3BlY2lmaWVzIHRoZSBFQyBwb2ludHMgaXQgY2FuIHN1cHBvcnQgaW48
YnI+DQomZ3Q7Jmd0OyZndDsgU2VydmVySGVsbG8sIGJ1dCBkb2VzIG5vdCBsZXQgdGhlIHNlcnZl
ciBpbmRpY2F0ZSB3aGljaCBFQyBjdXJ2ZXMgaXQ8YnI+DQomZ3Q7Jmd0OyZndDsgc3VwcG9ydHMu
IFVubGVzcyBJJ20gbWlzc2luZyBzb21ldGhpbmcsIHRoaXMgbWVhbnMgdGhhdCB0aGVyZSdzPGJy
Pg0KJmd0OyZndDsmZ3Q7IG5vIHdheSBmb3IgdGhlIHNlcnZlciB0byBpbmRpY2F0ZSB3aGF0IGdy
b3VwcyBpdCB3b3VsZCBzdXBwb3J0Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0
OyBUaGF0IHNlZW1zIGxlc3MgdGhhbiBpZGVhbC4gVGhlcmUgc2VlbSBsaWtlIHRocmVlIG9wdGlv
bnMgaGVyZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgMS4gUHV0IGl0IGlu
IENlcnRpZmljYXRlUmVxdWVzdDxicj4NCiZndDsmZ3Q7Jmd0OyAyLiBTZW5kIGl0IGluIFNlcnZl
ckhlbGxvPGJyPg0KJmd0OyZndDsmZ3Q7IDMuIERvIG5vdGhpbmcuPGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0OyBJIHByZWZlciAjMi4gSSBkb24ndCB0aGluayBlbmNyeXB0aW9uIGlzIG5lY2Vz
c2FyaWx5IHJlcXVpcmVkIGZvciB0aGlzLDxicj4NCiZndDsmZ3Q7IGJ1dCBFbmNyeXB0ZWRFeHRl
bnNpb25zIGlzIGZpbmUgdG9vIChNYXJ0aW4ncyAyYikuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0OyBJJ20gZ2VuZXJhbGx5IGFnYWluc3QgcHV0dGluZyBpdCBpbiBDZXJ0aWZpY2F0ZVJlcXVl
c3QsIGFzIHdlJ3JlIHJldXNpbmc8YnI+DQomZ3Q7Jmd0OyBhbiBleGlzdGluZyBoZWxsbyBleHRl
bnNpb24gc28ga2VlcGluZyBpdCBpbiBhIGhlbGxvIG1lc3NhZ2UgKG9yIGl0J3M8YnI+DQomZ3Q7
Jmd0OyB0cmFpbGluZyBlbmNyeXB0ZWQgZmllbGQpIHNlZW1zIGJlc3QuIChyZXN0cmljdGVkIHRv
IFRMUyAxLjMmIzQzOyBjbGllbnRzLDxicj4NCiZndDsmZ3Q7IHRob3VnaCk8YnI+DQomZ3Q7PGJy
Pg0KJmd0Ozxicj4NCiZndDsgVGhpcyB3b3VsZCBuZWVkIHRvIGJlIGxpbWl0ZWQgdG8gMS4zIGlu
IGFueSBjYXNlIGJlY2F1c2UgaW4gYWxsIHRoZSBvdGhlcjxicj4NCiZndDsgY2FzZXMgaXQgd291
bGQgYmUgaWxsZWdhbC48YnI+DQo8YnI+DQo8YnI+DQpXaHkgZG8geW91IGJlbGlldmUgdGhhdCBp
dCB3b3VsZCBiZSAmcXVvdDtpbGxlZ2FsJnF1b3Q7IGZvciBhIFRMU3YxLlswMTJdIHNlcnZlcjxi
cj4NCnRvIHJldHVybiBhICZxdW90O1N1cHBvcnRlZCBFbGxpcHRpYyBDdXJ2ZXMmcXVvdDsgVExT
IGV4dGVuc2lvbiBpbiBTZXJ2ZXJIZWxsbzxicj4NCmluIHJlc3BvbnNlIHRvIHRoZSBwcmVzZW5j
ZSBvZiBzdWNoIGEgVExTIGV4dGVuc2lvbiBpbiBDbGllbnRIZWxsbz88YnI+DQo8YnI+DQpyZmM0
NDkyIGRvZXMgbm90IGRlZmluZSBzZW1hbnRpY3MgZm9yIHRoZSBwcmVzZW5jZSBvZiAmcXVvdDtT
dXBwb3J0ZWQgRWxsaXB0aWM8YnI+DQpDdXJ2ZXMmcXVvdDsgVExTIGV4dGVuc2lvbiBpbiBTZXJ2
ZXJIZWxsbywgYnV0IG9uIGEgcXVpY2sgcmVhZCwgaXQgYWxzbyBkb2VzPGJyPg0Kbm90IHByb2hp
Yml0IGluY2x1ZGluZy9zZW5kaW5nIGl0Ljxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEw
MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9v
bHMuaWV0Zi5vcmclMmZodG1sJTJmcmZjNDQ5MiUyM3NlY3Rpb24tNS4yJmFtcDtkYXRhPTAxJTdj
MDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjNTVmYTAxOWQyYjUxNDA3Nzg2ODEw
OGQyZGFlNGVhYjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3Nk
YXRhPWpOb0hNJTJmclA5anhrUlVQRmFJc1N6WGZKY1ZtQnducU5NOE03Tm0ydnR3YyUzZCIgdGFy
Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NDkyI3NlY3Rpb24t
NS4yPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+V2VsbCwgdGhlIGRyYWZ0IHNheXMgdGhhdCBpdCBpcyBkZWZpbmluZyB0d28g
Q2xpZW50SGVsbG8gZXh0ZW5zaW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+KHN1cHBvcnRlZCBlbGxpcHRpYyBjdXJ2ZXMgYW5kIHN1cHBvcnRl
ZCBwb2ludCBmb3JtYXRzKSBhbmQgdGhhdCBpdCBpcyBkZWZpbmluZzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b25lIFNlcnZlckhlbGxvIGV4dGVu
c2lvbiwgc28gaWYgdGhlIHNlcnZlciBpcyBzZW5kaW5nIHN1cHBvcnRlZCBlbGxpcHRpYzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y3VydmVzIGl0
J3MgZG9pbmcgc29tZXRoaW5nIHVuZGVmaW5lZC4gSSBkb24ndCB0aGluayB5b3UgbmVlZCB0byBo
YXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h
biBleHBsaWNpdCBwcm9oaWJpdGlvbiB0byBzdWdnZXN0IHRoYXQgZG9pbmcgc29tZXRoaW5nIHVu
ZGVmaW5lZCBpc24ndDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Z3JlYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkZyb20gYW4gaW1wbGVtZW50YXRpb24gcGVyc3BlY3RpdmUsIEkgd291bGRu
J3QgYmUgc3VycHJpc2VkIGlmIGNsaWVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+aW1wbGVtZW50YXRpb25zIGNob2tlZCBvbiB0aGUgc2VydmVy
IHNlbmRpbmcgdGhpcy4gSSBoYWQgdG8gY2hlY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIHNlZSBpZiBOU1Mgd291bGQgZG8gc28uIEl0IGRv
ZXNuJ3QsIGJ1dCBnaXZlbiB0aGUgd2F5IHRoZSBjb2RlPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcyB3cml0dGVuLCBpdCB3b3VsZG4ndCBoYXZl
IHN1cnByaXNlZCBtZSBpZiBpdCBjaGVja2VkIHRoYXQgYWxsIGV4dGVuc2lvbnM8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndlcmUgaGFuZGxlZCBh
bmQgY2hva2VkIG90aGVyd2lzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp
biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6Izg4ODg4OCI+LU1hcnRpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BLUPR03MB1396D9A28A7F73B21E6609728C270BLUPR03MB1396namp_--


From nobody Thu Oct 22 10:08:39 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809D81B2A1B for ; Thu, 22 Oct 2015 10:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.712
X-Spam-Level: 
X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989] autolearn=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 D5jtJuI4Rvcx for ; Thu, 22 Oct 2015 10:08:26 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002: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 8B0401B2A14 for ; Thu, 22 Oct 2015 10:08:26 -0700 (PDT)
Received: by yknn9 with SMTP id n9so89212952ykn.0 for ; Thu, 22 Oct 2015 10:08:25 -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:content-type; bh=ApzgQUs3gg17nU4vVApm1LUeTrLxsP5iZhFkR6sjKtw=; b=Bq8gfnB4O4+sWiBXJYYkr4IOttO852CpVUk48560NkSnglsm+HXDfTTSSsf7A0FsUe 3rOyiSWDKt7njH2VA+NMEexOPIf3pxplUPJSvTcnL0COiRxHH7sf6Im3y19Xd8J4TZ6V YywPmHwqDMuJXymW2n8jzZvg4L78INV/vVW+OPl9pNfgNKI6IOaMoq5Z6WmvfBNdHN6W 3bOU8P3NjA3o/vpmOm3OODJVOcjTCszrrujyHBtAt1wYQUklqEKBApIRjjONep5tlPj4 NXxrODecdxGZpiEIvueq7v5fdkjhIVbJ5fcZHAdEsd2mI5zVUU7RR748NRXRxMqEgPrC gWjQ==
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-type; bh=ApzgQUs3gg17nU4vVApm1LUeTrLxsP5iZhFkR6sjKtw=; b=mQh2S1vurqZ5U2m7TRo7F5/qrlojrUWfr9RLJWot/dS2pFwfTXdPWBZLGV3zP+GbGf MVZqX5531zPlHwvY+hp8LtS7yJK+A0X4ZduDXM+p9qv3cLitPCWxaxkk2wGQF+HBFAjx l4n8NHRgZE4orwb4pMwE6vV6KvgTU+YYsxGTQU5/horP18JcsLP/FW7NC3L6VM74wIUZ Ge2KR3ick8dv5sDrWRieRmaptmlqu1gPk58B34Hy03wNgAeWtkvVW1rukvlff8VusWGc jWrJy/92/C1GdizZ5zq49xQg3k2n3yDn85ydWuVOqhYoCeufN6Qu067ZZxtMZ29HA8Hn ouMw==
X-Gm-Message-State: ALoCoQlwyd3Eqf+aDUM5kc5sKF+HwnW6Ejoqy9rWRs6SR6VwMPd70exX0QpnEy9XQ7oOZdJoUejL
X-Received: by 10.13.198.132 with SMTP id i126mr13594878ywd.192.1445533705800;  Thu, 22 Oct 2015 10:08:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 10:07:46 -0700 (PDT)
In-Reply-To: 
References:  <20151022125557.9B1651A31C@ld9781.wdf.sap.corp>  
From: Eric Rescorla 
Date: Thu, 22 Oct 2015 10:07:46 -0700
Message-ID: 
To: Andrei Popov 
Content-Type: multipart/alternative; boundary=001a114e491e0bc8500522b48b57
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:08:28 -0000

--001a114e491e0bc8500522b48b57
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Not that I am aware of.

On Thu, Oct 22, 2015 at 10:06 AM, Andrei Popov 
wrote:

> Would the server-side =E2=80=9Csupported elliptic curves=E2=80=9D be used=
 for anything
> other than guiding client cert selection?
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, October 22, 2015 6:29 AM
> *To:* mrex@sap.com
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Allow NamedGroups from the server?
>
>
>
>
>
>
>
> On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex  wrote:
>
> Eric Rescorla wrote:
> > Dave Garrett  wrote:
> >
> >> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> >>> https://github.com/tlswg/tls13-spec/issues/292
> 
> >>>
> >>> Presently, RFC 4492 only specifies the EC points it can support in
> >>> ServerHello, but does not let the server indicate which EC curves it
> >>> supports. Unless I'm missing something, this means that there's
> >>> no way for the server to indicate what groups it would support.
> >>>
> >>> That seems less than ideal. There seem like three options here:
> >>>
> >>> 1. Put it in CertificateRequest
> >>> 2. Send it in ServerHello
> >>> 3. Do nothing.
> >>
> >> I prefer #2. I don't think encryption is necessarily required for this=
,
> >> but EncryptedExtensions is fine too (Martin's 2b).
> >>
> >> I'm generally against putting it in CertificateRequest, as we're reusi=
ng
> >> an existing hello extension so keeping it in a hello message (or it's
> >> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
> >> though)
> >
> >
> > This would need to be limited to 1.3 in any case because in all the oth=
er
> > cases it would be illegal.
>
>
> Why do you believe that it would be "illegal" for a TLSv1.[012] server
> to return a "Supported Elliptic Curves" TLS extension in ServerHello
> in response to the presence of such a TLS extension in ClientHello?
>
> rfc4492 does not define semantics for the presence of "Supported Elliptic
> Curves" TLS extension in ServerHello, but on a quick read, it also does
> not prohibit including/sending it.
>
> https://tools.ietf.org/html/rfc4492#section-5.2
> 
>
>
>
> Well, the draft says that it is defining two ClientHello extensions
>
> (supported elliptic curves and supported point formats) and that it is
> defining
>
> one ServerHello extension, so if the server is sending supported elliptic
>
> curves it's doing something undefined. I don't think you need to have
>
> an explicit prohibition to suggest that doing something undefined isn't
>
> great.
>
>
>
> From an implementation perspective, I wouldn't be surprised if client
>
> implementations choked on the server sending this. I had to check
>
> to see if NSS would do so. It doesn't, but given the way the code
>
> is written, it wouldn't have surprised me if it checked that all extensio=
ns
>
> were handled and choked otherwise.
>
>
>
> -Ekr
>
>
>
>
>
> -Martin
>
>
>

--001a114e491e0bc8500522b48b57
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Not that I am aware of.

On Thu, Oct 22, 201=
5 at 10:06 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:











Would the server-side =E2=80=9Csuppor=
ted elliptic curves=E2=80=9D be used for anything other than guiding client=
 cert selection?


=C2=A0


Cheers,


=C2=A0


Andrei


=C2=A0


From: TLS [mailto:tls-bounces@ietf.org]
On Behalf Of Eric Rescorla

Sent: Thursday, October 22, 2015 6:29 AM

To: mrex@sap.com

Cc: tls@ietf.org

Subject: Re: [TLS] Allow NamedGroups from the server?<=
/span>


=C2=A0




=C2=A0




=C2=A0




On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex <mrex@sap.com> wrote:




Eric Rescorla wrote:

> Dave Garrett <davemgarrett@gmail.com> wrote:

>

>> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
>>> 
https://github.com/tlswg/tls13-spec/issues/292

>>>

>>> Presently, RFC 4492 only specifies the EC points it can suppor=
t in

>>> ServerHello, but does not let the server indicate which EC cur=
ves it

>>> supports. Unless I'm missing something, this means that th=
ere's

>>> no way for the server to indicate what groups it would support=
.

>>>

>>> That seems less than ideal. There seem like three options here=
:

>>>

>>> 1. Put it in CertificateRequest

>>> 2. Send it in ServerHello

>>> 3. Do nothing.

>>

>> I prefer #2. I don't think encryption is necessarily required =
for this,

>> but EncryptedExtensions is fine too (Martin's 2b).

>>

>> I'm generally against putting it in CertificateRequest, as we&=
#39;re reusing

>> an existing hello extension so keeping it in a hello message (or i=
t's

>> trailing encrypted field) seems best. (restricted to TLS 1.3+ clie=
nts,

>> though)

>

>

> This would need to be limited to 1.3 in any case because in all the ot=
her

> cases it would be illegal.





Why do you believe that it would be "illegal" for a TLSv1.[012] s=
erver

to return a "Supported Elliptic Curves" TLS extension in ServerHe=
llo

in response to the presence of such a TLS extension in ClientHello?



rfc4492 does not define semantics for the presence of "Supported Ellip=
tic

Curves" TLS extension in ServerHello, but on a quick read, it also doe=
s

not prohibit including/sending it.



https://tools.ietf.org/html/rfc4492#section-5.2=







=C2=A0






Well, the draft says that it is defining two ClientH=
ello extensions






(supported elliptic curves and supported point forma=
ts) and that it is defining






one ServerHello extension, so if the server is sendi=
ng supported elliptic






curves it's doing something undefined. I don'=
;t think you need to have






an explicit prohibition to suggest that doing someth=
ing undefined isn't






great.






=C2=A0






From an implementation perspective, I wouldn't b=
e surprised if client






implementations choked on the server sending this. I=
 had to check






to see if NSS would do so. It doesn't, but given=
 the way the code






is written, it wouldn't have surprised me if it =
checked that all extensions






were handled and choked otherwise.






=C2=A0






-Ekr






=C2=A0






=C2=A0






-Martin<=
u>






=C2=A0














--001a114e491e0bc8500522b48b57--


From nobody Thu Oct 22 10:11:57 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697041B39DA for ; Thu, 22 Oct 2015 10:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBiCYAwUMXhq for ; Thu, 22 Oct 2015 10:11:53 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008E01B39E1 for ; Thu, 22 Oct 2015 10:11:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zCIsdwld50CjcbEhBCDr4Vdn6N/o0X4/caZkOv0tdy0=; b=d3jOQ6xF5nnT3LEyh9p66zyjo5CrgnoZeOvyWLtZ2cLIlillSqBagBETV9HpmTDHSnLXcZLagd404Hg9acZcnhUM64hPT9OQFSxO+scogH4t5DHSKxds+ocGfgqNqZxs7qrDYwng/oDCAlE+TEWd2VfBcwdZSY6sRR7UV/G42EQ=
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 17:11:50 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 17:11:50 +0000
From: Andrei Popov 
To: Eric Rescorla 
Thread-Topic: [TLS] Allow NamedGroups from the server?
Thread-Index: AQHRDFwySYYLbapvF0OM4bIxRSdhpp52qJkAgAABqACAAM8DgIAACVYAgAA7XHCAAAGpAIAAAMCw
Date: Thu, 22 Oct 2015 17:11:50 +0000
Message-ID: 
References:  <20151022125557.9B1651A31C@ld9781.wdf.sap.corp>   
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-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:iNJ7hmW+DxPUrPpytgqDeSgwcF8WS2dE5+BtUCbL4RuRaSeGMbO+ItWI/vLBVRGwbNy8C+BiAknzKaU3OfbQQMvVEpfa3naic3CmCB4HudxGIEKWYtM/ZlKjz2VpUR94rOXeaxZwikYnKILletvEPQ==; 24:CKaTez/AVUGenq/EAKfg/wXvYBF2PgNR/ndLKgrvqegkVWXomQXk9iNmo7evYNdolgnsQcxcfd5C3DysVCPvFJzipdOZDGBuFnrnWntjGpI=; 20:amJ6gyFn9xDyRhEs/tvhO0JnAtRxsdEa2HwbTzqdGQXYJtAnXO1XTfBd/+Hsmp95EhIUw3V1cYGCxcRCozIALg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(189930954265078)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026)(61426024)(61427024); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; 
x-forefront-prvs: 0737B96801
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(60444003)(377454003)(24454002)(5003600100002)(76176999)(5008740100001)(92566002)(99286002)(106356001)(10290500002)(5005710100001)(10400500002)(16236675004)(19300405004)(19580395003)(74316001)(19580405001)(50986999)(106116001)(11100500001)(54356999)(76576001)(105586002)(15975445007)(86362001)(2950100001)(10090500001)(2900100001)(40100003)(33656002)(8990500004)(64706001)(122556002)(86612001)(102836002)(46102003)(101416001)(77096005)(93886004)(19609705001)(19625215002)(81156007)(189998001)(97736004)(5001960100002)(19617315012)(5007970100001)(5002640100001)(110136002)(87936001)(5004730100002)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139648FE8E76BFE8A001D9CA8C270BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 17:11:50.5052 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:11:56 -0000

--_000_BLUPR03MB139648FE8E76BFE8A001D9CA8C270BLUPR03MB1396namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlbiBteSBhcmd1bWVudCB3b3VsZCBiZTogd2h5IHNlbmQgZXh0cmEgYnl0ZXMgaW4gZWFjaCBT
ZXJ2ZXJIZWxsbyB3aGVuIFRMUyBjbGllbnQgYXV0aCBpcyBub3QgdXNlZCBtb3N0IG9mIHRoZSB0
aW1lPyBJbiB0aGlzIGNhc2UsIENlcnRpZmljYXRlUmVxdWVzdCBzZWVtcyB0byBiZSBhIGJldHRl
ciBwbGFjZS4NCg0KRnJvbTogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NClNl
bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDE1IDEwOjA4IEFNDQpUbzogQW5kcmVpIFBvcG92
IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBtcmV4QHNhcC5jb207IHRsc0BpZXRm
Lm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIEFsbG93IE5hbWVkR3JvdXBzIGZyb20gdGhlIHNlcnZl
cj8NCg0KTm90IHRoYXQgSSBhbSBhd2FyZSBvZi4NCg0KT24gVGh1LCBPY3QgMjIsIDIwMTUgYXQg
MTA6MDYgQU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRv
OkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpXb3VsZCB0aGUgc2VydmVyLXNp
ZGUg4oCcc3VwcG9ydGVkIGVsbGlwdGljIGN1cnZlc+KAnSBiZSB1c2VkIGZvciBhbnl0aGluZyBv
dGhlciB0aGFuIGd1aWRpbmcgY2xpZW50IGNlcnQgc2VsZWN0aW9uPw0KDQpDaGVlcnMsDQoNCkFu
ZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxz
LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVGh1
cnNkYXksIE9jdG9iZXIgMjIsIDIwMTUgNjoyOSBBTQ0KVG86IG1yZXhAc2FwLmNvbTxtYWlsdG86
bXJleEBzYXAuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IFtUTFNdIEFsbG93IE5hbWVkR3JvdXBzIGZyb20gdGhlIHNlcnZlcj8NCg0KDQoN
Ck9uIFRodSwgT2N0IDIyLCAyMDE1IGF0IDU6NTUgQU0sIE1hcnRpbiBSZXggPG1yZXhAc2FwLmNv
bTxtYWlsdG86bXJleEBzYXAuY29tPj4gd3JvdGU6DQpFcmljIFJlc2NvcmxhIHdyb3RlOg0KPiBE
YXZlIEdhcnJldHQgPGRhdmVtZ2FycmV0dEBnbWFpbC5jb208bWFpbHRvOmRhdmVtZ2FycmV0dEBn
bWFpbC5jb20+PiB3cm90ZToNCj4NCj4+IE9uIFdlZG5lc2RheSwgT2N0b2JlciAyMSwgMjAxNSAw
Nzo1NjoxMyBwbSBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS90
bHN3Zy90bHMxMy1zcGVjL2lzc3Vlcy8yOTI8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0
aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZnaXRodWIuY29tJTJmdGxzd2clMmZ0
bHMxMy1zcGVjJTJmaXNzdWVzJTJmMjkyJmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1p
Y3Jvc29mdC5jb20lN2M1NWZhMDE5ZDJiNTE0MDc3ODY4MTA4ZDJkYWU0ZWFiOSU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT00RmZVZkQ3OFdjT0tMNkp1dkhRNGFY
NGpyWFhSMzVYRDg1OERoT1RNa2RjJTNkPg0KPj4+DQo+Pj4gUHJlc2VudGx5LCBSRkMgNDQ5MiBv
bmx5IHNwZWNpZmllcyB0aGUgRUMgcG9pbnRzIGl0IGNhbiBzdXBwb3J0IGluDQo+Pj4gU2VydmVy
SGVsbG8sIGJ1dCBkb2VzIG5vdCBsZXQgdGhlIHNlcnZlciBpbmRpY2F0ZSB3aGljaCBFQyBjdXJ2
ZXMgaXQNCj4+PiBzdXBwb3J0cy4gVW5sZXNzIEknbSBtaXNzaW5nIHNvbWV0aGluZywgdGhpcyBt
ZWFucyB0aGF0IHRoZXJlJ3MNCj4+PiBubyB3YXkgZm9yIHRoZSBzZXJ2ZXIgdG8gaW5kaWNhdGUg
d2hhdCBncm91cHMgaXQgd291bGQgc3VwcG9ydC4NCj4+Pg0KPj4+IFRoYXQgc2VlbXMgbGVzcyB0
aGFuIGlkZWFsLiBUaGVyZSBzZWVtIGxpa2UgdGhyZWUgb3B0aW9ucyBoZXJlOg0KPj4+DQo+Pj4g
MS4gUHV0IGl0IGluIENlcnRpZmljYXRlUmVxdWVzdA0KPj4+IDIuIFNlbmQgaXQgaW4gU2VydmVy
SGVsbG8NCj4+PiAzLiBEbyBub3RoaW5nLg0KPj4NCj4+IEkgcHJlZmVyICMyLiBJIGRvbid0IHRo
aW5rIGVuY3J5cHRpb24gaXMgbmVjZXNzYXJpbHkgcmVxdWlyZWQgZm9yIHRoaXMsDQo+PiBidXQg
RW5jcnlwdGVkRXh0ZW5zaW9ucyBpcyBmaW5lIHRvbyAoTWFydGluJ3MgMmIpLg0KPj4NCj4+IEkn
bSBnZW5lcmFsbHkgYWdhaW5zdCBwdXR0aW5nIGl0IGluIENlcnRpZmljYXRlUmVxdWVzdCwgYXMg
d2UncmUgcmV1c2luZw0KPj4gYW4gZXhpc3RpbmcgaGVsbG8gZXh0ZW5zaW9uIHNvIGtlZXBpbmcg
aXQgaW4gYSBoZWxsbyBtZXNzYWdlIChvciBpdCdzDQo+PiB0cmFpbGluZyBlbmNyeXB0ZWQgZmll
bGQpIHNlZW1zIGJlc3QuIChyZXN0cmljdGVkIHRvIFRMUyAxLjMrIGNsaWVudHMsDQo+PiB0aG91
Z2gpDQo+DQo+DQo+IFRoaXMgd291bGQgbmVlZCB0byBiZSBsaW1pdGVkIHRvIDEuMyBpbiBhbnkg
Y2FzZSBiZWNhdXNlIGluIGFsbCB0aGUgb3RoZXINCj4gY2FzZXMgaXQgd291bGQgYmUgaWxsZWdh
bC4NCg0KDQpXaHkgZG8geW91IGJlbGlldmUgdGhhdCBpdCB3b3VsZCBiZSAiaWxsZWdhbCIgZm9y
IGEgVExTdjEuWzAxMl0gc2VydmVyDQp0byByZXR1cm4gYSAiU3VwcG9ydGVkIEVsbGlwdGljIEN1
cnZlcyIgVExTIGV4dGVuc2lvbiBpbiBTZXJ2ZXJIZWxsbw0KaW4gcmVzcG9uc2UgdG8gdGhlIHBy
ZXNlbmNlIG9mIHN1Y2ggYSBUTFMgZXh0ZW5zaW9uIGluIENsaWVudEhlbGxvPw0KDQpyZmM0NDky
IGRvZXMgbm90IGRlZmluZSBzZW1hbnRpY3MgZm9yIHRoZSBwcmVzZW5jZSBvZiAiU3VwcG9ydGVk
IEVsbGlwdGljDQpDdXJ2ZXMiIFRMUyBleHRlbnNpb24gaW4gU2VydmVySGVsbG8sIGJ1dCBvbiBh
IHF1aWNrIHJlYWQsIGl0IGFsc28gZG9lcw0Kbm90IHByb2hpYml0IGluY2x1ZGluZy9zZW5kaW5n
IGl0Lg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ5MiNzZWN0aW9uLTUuMjxo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz
YSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZnJmYzQ0OTIlMjNzZWN0aW9uLTUuMiZkYXRh
PTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjNTVmYTAxOWQyYjUxNDA3
Nzg2ODEwOGQyZGFlNGVhYjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm
c2RhdGE9ak5vSE0lMmZyUDlqeGtSVVBGYUlzU3pYZkpjVm1Cd25xTk04TTdObTJ2dHdjJTNkPg0K
DQpXZWxsLCB0aGUgZHJhZnQgc2F5cyB0aGF0IGl0IGlzIGRlZmluaW5nIHR3byBDbGllbnRIZWxs
byBleHRlbnNpb25zDQooc3VwcG9ydGVkIGVsbGlwdGljIGN1cnZlcyBhbmQgc3VwcG9ydGVkIHBv
aW50IGZvcm1hdHMpIGFuZCB0aGF0IGl0IGlzIGRlZmluaW5nDQpvbmUgU2VydmVySGVsbG8gZXh0
ZW5zaW9uLCBzbyBpZiB0aGUgc2VydmVyIGlzIHNlbmRpbmcgc3VwcG9ydGVkIGVsbGlwdGljDQpj
dXJ2ZXMgaXQncyBkb2luZyBzb21ldGhpbmcgdW5kZWZpbmVkLiBJIGRvbid0IHRoaW5rIHlvdSBu
ZWVkIHRvIGhhdmUNCmFuIGV4cGxpY2l0IHByb2hpYml0aW9uIHRvIHN1Z2dlc3QgdGhhdCBkb2lu
ZyBzb21ldGhpbmcgdW5kZWZpbmVkIGlzbid0DQpncmVhdC4NCg0KRnJvbSBhbiBpbXBsZW1lbnRh
dGlvbiBwZXJzcGVjdGl2ZSwgSSB3b3VsZG4ndCBiZSBzdXJwcmlzZWQgaWYgY2xpZW50DQppbXBs
ZW1lbnRhdGlvbnMgY2hva2VkIG9uIHRoZSBzZXJ2ZXIgc2VuZGluZyB0aGlzLiBJIGhhZCB0byBj
aGVjaw0KdG8gc2VlIGlmIE5TUyB3b3VsZCBkbyBzby4gSXQgZG9lc24ndCwgYnV0IGdpdmVuIHRo
ZSB3YXkgdGhlIGNvZGUNCmlzIHdyaXR0ZW4sIGl0IHdvdWxkbid0IGhhdmUgc3VycHJpc2VkIG1l
IGlmIGl0IGNoZWNrZWQgdGhhdCBhbGwgZXh0ZW5zaW9ucw0Kd2VyZSBoYW5kbGVkIGFuZCBjaG9r
ZWQgb3RoZXJ3aXNlLg0KDQotRWtyDQoNCg0KLU1hcnRpbg0KDQoNCg==

--_000_BLUPR03MB139648FE8E76BFE8A001D9CA8C270BLUPR03MB1396namp_
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
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlbiBteSBhcmd1bWVudCB3b3VsZCBi
ZTogd2h5IHNlbmQgZXh0cmEgYnl0ZXMgaW4gZWFjaCBTZXJ2ZXJIZWxsbyB3aGVuIFRMUyBjbGll
bnQgYXV0aCBpcyBub3QgdXNlZCBtb3N0IG9mIHRoZSB0aW1lPyBJbiB0aGlzIGNhc2UsIENlcnRp
ZmljYXRlUmVxdWVzdCBzZWVtcw0KIHRvIGJlIGEgYmV0dGVyIHBsYWNlLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmlj
IFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz
ZGF5LCBPY3RvYmVyIDIyLCAyMDE1IDEwOjA4IEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9w
b3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbXJl
eEBzYXAuY29tOyB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIEFs
bG93IE5hbWVkR3JvdXBzIGZyb20gdGhlIHNlcnZlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHRoYXQgSSBhbSBhd2FyZSBvZi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgT2N0IDIyLCAyMDE1IGF0
IDEwOjA2IEFNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZA
bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5X
b3VsZCB0aGUgc2VydmVyLXNpZGUg4oCcc3VwcG9ydGVkIGVsbGlwdGljIGN1cnZlc+KAnSBiZSB1
c2VkIGZvciBhbnl0aGluZyBvdGhlciB0aGFuIGd1aWRpbmcgY2xpZW50IGNlcnQNCiBzZWxlY3Rp
b24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJz
LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj4gVExTIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3Rv
YmVyIDIyLCAyMDE1IDY6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptcmV4
QHNhcC5jb20iIHRhcmdldD0iX2JsYW5rIj5tcmV4QHNhcC5jb208L2E+PGJyPg0KPGI+Q2M6PC9i
PiA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzQGlldGYu
b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gQWxsb3cgTmFtZWRHcm91cHMg
ZnJvbSB0aGUgc2VydmVyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1
LCBPY3QgMjIsIDIwMTUgYXQgNTo1NSBBTSwgTWFydGluIFJleCAmbHQ7PGEgaHJlZj0ibWFpbHRv
Om1yZXhAc2FwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1yZXhAc2FwLmNvbTwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp
bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXJpYyBSZXNj
b3JsYSB3cm90ZTo8YnI+DQomZ3Q7IERhdmUgR2FycmV0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRh
dmVtZ2FycmV0dEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZlbWdhcnJldHRAZ21haWwu
Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IE9uIFdlZG5lc2RheSwg
T2N0b2JlciAyMSwgMjAxNSAwNzo1NjoxMyBwbSBFcmljIFJlc2NvcmxhIHdyb3RlOjxicj4NCiZn
dDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0
bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZmdpdGh1Yi5jb20lMmZ0bHN3ZyUyZnRsczEzLXNw
ZWMlMmZpc3N1ZXMlMmYyOTImYW1wO2RhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jv
c29mdC5jb20lN2M1NWZhMDE5ZDJiNTE0MDc3ODY4MTA4ZDJkYWU0ZWFiOSU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9NEZmVWZENzhXY09LTDZKdXZIUTRh
WDRqclhYUjM1WEQ4NThEaE9UTWtkYyUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRo
dWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvaXNzdWVzLzI5MjwvYT48YnI+DQomZ3Q7Jmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyZndDsgUHJlc2VudGx5LCBSRkMgNDQ5MiBvbmx5IHNwZWNpZmllcyB0aGUg
RUMgcG9pbnRzIGl0IGNhbiBzdXBwb3J0IGluPGJyPg0KJmd0OyZndDsmZ3Q7IFNlcnZlckhlbGxv
LCBidXQgZG9lcyBub3QgbGV0IHRoZSBzZXJ2ZXIgaW5kaWNhdGUgd2hpY2ggRUMgY3VydmVzIGl0
PGJyPg0KJmd0OyZndDsmZ3Q7IHN1cHBvcnRzLiBVbmxlc3MgSSdtIG1pc3Npbmcgc29tZXRoaW5n
LCB0aGlzIG1lYW5zIHRoYXQgdGhlcmUnczxicj4NCiZndDsmZ3Q7Jmd0OyBubyB3YXkgZm9yIHRo
ZSBzZXJ2ZXIgdG8gaW5kaWNhdGUgd2hhdCBncm91cHMgaXQgd291bGQgc3VwcG9ydC48YnI+DQom
Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhhdCBzZWVtcyBsZXNzIHRoYW4gaWRlYWwu
IFRoZXJlIHNlZW0gbGlrZSB0aHJlZSBvcHRpb25zIGhlcmU6PGJyPg0KJmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7IDEuIFB1dCBpdCBpbiBDZXJ0aWZpY2F0ZVJlcXVlc3Q8YnI+DQomZ3Q7
Jmd0OyZndDsgMi4gU2VuZCBpdCBpbiBTZXJ2ZXJIZWxsbzxicj4NCiZndDsmZ3Q7Jmd0OyAzLiBE
byBub3RoaW5nLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBwcmVmZXIgIzIuIEkgZG9u
J3QgdGhpbmsgZW5jcnlwdGlvbiBpcyBuZWNlc3NhcmlseSByZXF1aXJlZCBmb3IgdGhpcyw8YnI+
DQomZ3Q7Jmd0OyBidXQgRW5jcnlwdGVkRXh0ZW5zaW9ucyBpcyBmaW5lIHRvbyAoTWFydGluJ3Mg
MmIpLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSdtIGdlbmVyYWxseSBhZ2FpbnN0IHB1
dHRpbmcgaXQgaW4gQ2VydGlmaWNhdGVSZXF1ZXN0LCBhcyB3ZSdyZSByZXVzaW5nPGJyPg0KJmd0
OyZndDsgYW4gZXhpc3RpbmcgaGVsbG8gZXh0ZW5zaW9uIHNvIGtlZXBpbmcgaXQgaW4gYSBoZWxs
byBtZXNzYWdlIChvciBpdCdzPGJyPg0KJmd0OyZndDsgdHJhaWxpbmcgZW5jcnlwdGVkIGZpZWxk
KSBzZWVtcyBiZXN0LiAocmVzdHJpY3RlZCB0byBUTFMgMS4zJiM0MzsgY2xpZW50cyw8YnI+DQom
Z3Q7Jmd0OyB0aG91Z2gpPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgd291bGQg
bmVlZCB0byBiZSBsaW1pdGVkIHRvIDEuMyBpbiBhbnkgY2FzZSBiZWNhdXNlIGluIGFsbCB0aGUg
b3RoZXI8YnI+DQomZ3Q7IGNhc2VzIGl0IHdvdWxkIGJlIGlsbGVnYWwuPGJyPg0KPGJyPg0KPGJy
Pg0KV2h5IGRvIHlvdSBiZWxpZXZlIHRoYXQgaXQgd291bGQgYmUgJnF1b3Q7aWxsZWdhbCZxdW90
OyBmb3IgYSBUTFN2MS5bMDEyXSBzZXJ2ZXI8YnI+DQp0byByZXR1cm4gYSAmcXVvdDtTdXBwb3J0
ZWQgRWxsaXB0aWMgQ3VydmVzJnF1b3Q7IFRMUyBleHRlbnNpb24gaW4gU2VydmVySGVsbG88YnI+
DQppbiByZXNwb25zZSB0byB0aGUgcHJlc2VuY2Ugb2Ygc3VjaCBhIFRMUyBleHRlbnNpb24gaW4g
Q2xpZW50SGVsbG8/PGJyPg0KPGJyPg0KcmZjNDQ5MiBkb2VzIG5vdCBkZWZpbmUgc2VtYW50aWNz
IGZvciB0aGUgcHJlc2VuY2Ugb2YgJnF1b3Q7U3VwcG9ydGVkIEVsbGlwdGljPGJyPg0KQ3VydmVz
JnF1b3Q7IFRMUyBleHRlbnNpb24gaW4gU2VydmVySGVsbG8sIGJ1dCBvbiBhIHF1aWNrIHJlYWQs
IGl0IGFsc28gZG9lczxicj4NCm5vdCBwcm9oaWJpdCBpbmNsdWRpbmcvc2VuZGluZyBpdC48YnI+
DQo8YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZnJmYzQ0OTIl
MjNzZWN0aW9uLTUuMiZhbXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0
LmNvbSU3YzU1ZmEwMTlkMmI1MTQwNzc4NjgxMDhkMmRhZTRlYWI5JTdjNzJmOTg4YmY4NmYxNDFh
ZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1qTm9ITSUyZnJQOWp4a1JVUEZhSXNTelhm
SmNWbUJ3bnFOTThNN05tMnZ0d2MlM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjNDQ5MiNzZWN0aW9uLTUuMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZWxsLCB0aGUgZHJh
ZnQgc2F5cyB0aGF0IGl0IGlzIGRlZmluaW5nIHR3byBDbGllbnRIZWxsbyBleHRlbnNpb25zPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPihzdXBw
b3J0ZWQgZWxsaXB0aWMgY3VydmVzIGFuZCBzdXBwb3J0ZWQgcG9pbnQgZm9ybWF0cykgYW5kIHRo
YXQgaXQgaXMgZGVmaW5pbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+b25lIFNlcnZlckhlbGxvIGV4dGVuc2lvbiwgc28gaWYgdGhlIHNlcnZl
ciBpcyBzZW5kaW5nIHN1cHBvcnRlZCBlbGxpcHRpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5jdXJ2ZXMgaXQncyBkb2luZyBzb21ldGhpbmcg
dW5kZWZpbmVkLiBJIGRvbid0IHRoaW5rIHlvdSBuZWVkIHRvIGhhdmU8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YW4gZXhwbGljaXQgcHJvaGli
aXRpb24gdG8gc3VnZ2VzdCB0aGF0IGRvaW5nIHNvbWV0aGluZyB1bmRlZmluZWQgaXNuJ3Q8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Z3JlYXQu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5Gcm9tIGFuIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlLCBJIHdvdWxkbid0IGJlIHN1cnBy
aXNlZCBpZiBjbGllbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+aW1wbGVtZW50YXRpb25zIGNob2tlZCBvbiB0aGUgc2VydmVyIHNlbmRpbmcg
dGhpcy4gSSBoYWQgdG8gY2hlY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+dG8gc2VlIGlmIE5TUyB3b3VsZCBkbyBzby4gSXQgZG9lc24ndCwg
YnV0IGdpdmVuIHRoZSB3YXkgdGhlIGNvZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aXMgd3JpdHRlbiwgaXQgd291bGRuJ3QgaGF2ZSBzdXJw
cmlzZWQgbWUgaWYgaXQgY2hlY2tlZCB0aGF0IGFsbCBleHRlbnNpb25zPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPndlcmUgaGFuZGxlZCBhbmQg
Y2hva2VkIG90aGVyd2lzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LU1hcnRpbjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_BLUPR03MB139648FE8E76BFE8A001D9CA8C270BLUPR03MB1396namp_--


From nobody Thu Oct 22 10:26:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F7E1B3A3F for ; Thu, 22 Oct 2015 10:26:22 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOOca7cQ2Y6Q for ; Thu, 22 Oct 2015 10:26:20 -0700 (PDT)
Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 041481B3A3C for ; Thu, 22 Oct 2015 10:26:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 15A1521BC1F; Thu, 22 Oct 2015 20:26:19 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id 8tnT6K8P2W-X; Thu, 22 Oct 2015 20:26:18 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id B20775BC003; Thu, 22 Oct 2015 20:26:18 +0300 (EEST)
Date: Thu, 22 Oct 2015 20:26:16 +0300
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20151022172616.GA7353@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.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposal for client auth
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:26:22 -0000

On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote:
> Folks,
> 
> At the Seattle interim, we decided to have a small ad hoc design team
> go and figure out how to harmonize the various forms of client
> authentication. I've posted a WIP version of the output of that work
> at:
> 
>         https://github.com/tlswg/tls13-spec/pull/316
> 
> 
> So, what this draft does is adopt the following three messages.
> 
>    Certificate
>    CertificateVerify
>    Finished
> 
> As the "TLS Authentication Block" and send them whenever we want to do
> authentication. [Note that we may eventually merge messages here, but
> that doesn't affect the logic.]
> 
> In every case, the input to the block would be:
> 
>    - A session context (SC) which is (generally) the handshake
>      transcript up to this point.
>    - A base key to compute the finished key from (the finished
>      keys are directional, so the client and server keys are
>      different).
> 
> And then the signature covers: SC + Certificate
> And the MAC covers SC + Certificate + CertificateVerify

Perhaps I'm reading things wrong, but this change seems to pass
raw Context+Certificate+Signature to HMAC to compute Finished.
Due to the way HMAC works, this requires to know the key for
the MAC before one can start the pipe (I didn't look when it
becomes available) and requires a separate pipe from ordinary
transcript hash.

Previously, Finished messages used the same transcript hash
pipe as everything else using transcript hashing.


-Ilari


From nobody Thu Oct 22 10:30:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A45B1B3A57 for ; Thu, 22 Oct 2015 10:30:35 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLfn8Y-mPUju for ; Thu, 22 Oct 2015 10:30:34 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002: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 3A8691B3A55 for ; Thu, 22 Oct 2015 10:30:34 -0700 (PDT)
Received: by ykba4 with SMTP id a4so83984653ykb.3 for ; Thu, 22 Oct 2015 10:30:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Mu8mRUKIvx9mScLaO1duV3bYOAdhXVMgBnA7DBMvHQ=; b=ZWk7s6HhCP13H2xAxE/WhwBd1HJwuecoey6QcNCOhwJt3JPBcWqtHTyMGxwsjBR7nM Ql/D3BSLFUslrntJfZ0SEGnWk5ZqVsOLOdG6PVK+/HyKHtSYUZRqRKw4wUs3u3bPaZf8 9Al75/RtxnrT0OHG1WVpVac/m3oxnUHvXryzWvkfSVCEEyFnWAGakuuTsk20byC5fhzl 3jdKK/gXPb3pFB0QPHaO0n0SRGRllsEnGzIq6Rm3Z4BIxYbzPCKuPKpegrw8wotBRJSN w+TLvrnuDBv+KR9NUZaqk68bzDsXqYwaZFZFTgab872q71SDApu6eubOvp/RW67AwFX2 tTzA==
MIME-Version: 1.0
X-Received: by 10.13.204.207 with SMTP id o198mr13284230ywd.183.1445535033488;  Thu, 22 Oct 2015 10:30:33 -0700 (PDT)
Received: by 10.129.132.145 with HTTP; Thu, 22 Oct 2015 10:30:33 -0700 (PDT)
In-Reply-To: <56290C8E.9040409@akamai.com>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>
Date: Thu, 22 Oct 2015 10:30:33 -0700
Message-ID: 
From: Martin Thomson 
To: Benjamin Kaduk 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:30:35 -0000

On 22 October 2015 at 09:19, Benjamin Kaduk  wrote:
>
> % a certificate that specifies a trust anchor MAY be omitted from the chain
>
> The client cannot decide that the signature on the root cert the server
> sent is bad, if the server does not send the root cert.

Yes, that was my thinking.

I expect that if a certificate is sent, then it might have to be
checked.  As opposed to the roots, which are rarely sent or checked.

Maybe it would help if Victor could describe the situation in which he
thinks that it would be appropriate to send a certificate that is
signed by MD5.


From nobody Thu Oct 22 10:34:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB161B3A68 for ; Thu, 22 Oct 2015 10:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 BBYe3qF7VMHT for ; Thu, 22 Oct 2015 10:34:41 -0700 (PDT)
Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 67B0C1B2A53 for ; Thu, 22 Oct 2015 10:34:41 -0700 (PDT)
Received: by ykba4 with SMTP id a4so84108129ykb.3 for ; Thu, 22 Oct 2015 10:34: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:content-type; bh=NXTrrRqGvVsN2QwsfCgrIyJUruoVGBrBIzRgezjTnOY=; b=wYTxIRG6eZDXTre0HWXpAhzq8ALDQnECGlbNbLN4ysykkTEDRDMDrHWSxiUz7LNzWv 2r8DRrSjoMQJTL5xBERXepFYK9I2eGPxqTmSLAznir3FVF3lXIzxOYQ8QCpqSpmsTwCY JGSMjtCj9o6EmTa5J6c9Bd2xZeOU6fqFsbXoyXSGRrag1NTEXdzNZFgElwaW+n0Ejj8h WyCJm7HjRXBGX5arg6QyZ33fefSLOVnpjGZvAeUCiWnZXR0UY+l5yOTe8SrQfgNZruCm J4llwwLQZKMEOuUQFzvEOSQoFQ2ozFXx29ywd2KHhA1FqFk11ca9kLHUz7VJlky8v87f 2RSQ==
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-type; bh=NXTrrRqGvVsN2QwsfCgrIyJUruoVGBrBIzRgezjTnOY=; b=isF6Uttcu1ioT5BCT8pAk1yctm7cV7dWUGBbZJ7sVWSqwkXqnGdzS9NTJbCm6NmztP zcbHhdnMzneqkL+kM7AW0J6pNKSoM6AKk8nkwZu4bKsChk1W1LUTiWKVYSYpAb8tqWMn hnH3z+XP4iV6Mx1bwsLzLCuw87MPvSX3ovu3QMBH1gKo3RqkTbDDHnwDOAOdjLGv3ura V6Z71ulG59OPy7ANfwRgA8GtVWhiKJ//o1foGzeaBBqNR+TRAz440CP4882cDmm4i6cQ fU6KxKar6TZFUBcHXA1jWgxVStXf1a5nH5EuVUAivHn9pE+lAhULnkj0mnFD/jN9ehA8 aoSw==
X-Gm-Message-State: ALoCoQndcdWYZVgQSPNJ4ix7fHSSl7E5liMsA1htjHLgW+/XUqFF/wq8QEUskqam0ARQgcDLRiXM
X-Received: by 10.129.106.9 with SMTP id f9mr13138840ywc.223.1445535280747; Thu, 22 Oct 2015 10:34:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 10:34:01 -0700 (PDT)
In-Reply-To: <20151022172616.GA7353@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20151022172616.GA7353@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Thu, 22 Oct 2015 10:34:01 -0700
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a114934daeb862c0522b4e8ee
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Proposal for client auth
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:34:43 -0000

--001a114934daeb862c0522b4e8ee
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 22, 2015 at 10:26 AM, Ilari Liusvaara 
wrote:

> On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote:
> > Folks,
> >
> > At the Seattle interim, we decided to have a small ad hoc design team
> > go and figure out how to harmonize the various forms of client
> > authentication. I've posted a WIP version of the output of that work
> > at:
> >
> >         https://github.com/tlswg/tls13-spec/pull/316
> >
> >
> > So, what this draft does is adopt the following three messages.
> >
> >    Certificate
> >    CertificateVerify
> >    Finished
> >
> > As the "TLS Authentication Block" and send them whenever we want to do
> > authentication. [Note that we may eventually merge messages here, but
> > that doesn't affect the logic.]
> >
> > In every case, the input to the block would be:
> >
> >    - A session context (SC) which is (generally) the handshake
> >      transcript up to this point.
> >    - A base key to compute the finished key from (the finished
> >      keys are directional, so the client and server keys are
> >      different).
> >
> > And then the signature covers: SC + Certificate
> > And the MAC covers SC + Certificate + CertificateVerify
>
> Perhaps I'm reading things wrong, but this change seems to pass
> raw Context+Certificate+Signature to HMAC to compute Finished.
> Due to the way HMAC works, this requires to know the key for
> the MAC before one can start the pipe (I didn't look when it
> becomes available) and requires a separate pipe from ordinary
> transcript hash.
>
> Previously, Finished messages used the same transcript hash
> pipe as everything else using transcript hashing.


I just messed up the editing.

It's the same plan as before. HMAC(key, handshake_hash). So, for
example, the signature from the server would cover all messages
between ClientHello and Certificate (inclusive) and the MAC would
cover all messages from ClientHello and CertificateVerify inclusive.

I'll fix this in the text.

-Ekr

--001a114934daeb862c0522b4e8ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 22, 2015 at 10:26 AM, Ilari Liusvaara <=
;ilariliusvaa=
ra@welho.com> wrote:
On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote:
> Folks,

>

> At the Seattle interim, we decided to have a small ad hoc design team<=
br>
> go and figure out how to harmonize the various forms of client

> authentication. I've posted a WIP version of the output of that wo=
rk

> at:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://github.com=
/tlswg/tls13-spec/pull/316

>

>

> So, what this draft does is adopt the followin=
g three messages.

>

>=C2=A0 =C2=A0 Certificate

>=C2=A0 =C2=A0 CertificateVerify

>=C2=A0 =C2=A0 Finished

>

> As the "TLS Authentication Block" and send them whenever we =
want to do

> authentication. [Note that we may eventually merge messages here, but<=
br>
> that doesn't affect the logic.]

>

> In every case, the input to the block would be:

>

>=C2=A0 =C2=A0 - A session context (SC) which is (generally) the handsha=
ke

>=C2=A0 =C2=A0 =C2=A0 transcript up to this point.

>=C2=A0 =C2=A0 - A base key to compute the finished key from (the finish=
ed

>=C2=A0 =C2=A0 =C2=A0 keys are directional, so the client and server key=
s are

>=C2=A0 =C2=A0 =C2=A0 different).

>

> And then the signature covers: SC + Certificate

> And the MAC covers SC + Certificate + CertificateVerify



Perhaps I'm reading things wrong, but this change seems to pass<=
br>
raw Context+Certificate+Signature to HMAC to compute Finished.

Due to the way HMAC works, this requires to know the key for

the MAC before one can start the pipe (I didn't look when it

becomes available) and requires a separate pipe from ordinary

transcript hash.



Previously, Finished messages used the same transcript hash

pipe as everything else using transcript hashing.

I just messed up the editing.

It's the =
same plan as before. HMAC(key, handshake_hash). So, for
example, =
the signature from the server would cover all messages
between Cl=
ientHello and Certificate (inclusive) and the MAC would
cover all=
 messages from ClientHello and CertificateVerify inclusive.

<=
/div>
I'll fix this in the text.

-Ekr







--001a114934daeb862c0522b4e8ee--


From nobody Thu Oct 22 10:35:24 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EEF1B3A7C for ; Thu, 22 Oct 2015 10:35: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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkcRqR0UZMJu for ; Thu, 22 Oct 2015 10:35:22 -0700 (PDT)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 D40791B3A7A for ; Thu, 22 Oct 2015 10:35:21 -0700 (PDT)
Received: by ykba4 with SMTP id a4so84128733ykb.3 for ; Thu, 22 Oct 2015 10:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2352i6D+Uka9LZwBzf0AK/SpMY8Nf9kTmdFWWnCYTo8=; b=kUVt8W2q7JuweFi6i3irDnKEdQHw9Hz7EXJzOouxWuCHxfM/RNrIJq+io0R2bhCQGn ORmfnxvygkOFHuA6ci2g2azwHo/D542sOgzqtBTlGmUuDMSPatNRUq3VQmBXCToBa9hr A4v+E8R3fwOPQDZVHPu1bLVLFBXdVJCmC3IF85VWguZ6IKpX7UxePrWu6z9mr2aOowtL Zs7C1nZx4Vi59BmNEd7Q//Jn4UBP6kFn0DkTk0hoY08cKuroyGykoiTtqx1TtK5+Q7gK T7whhwF2n6KXj2toX1zv4WGORUz8aiYVpMWfeDgDwtGCWEiDD9e/72/56omuI8LsgQkm pJOg==
MIME-Version: 1.0
X-Received: by 10.129.55.209 with SMTP id e200mr13450029ywa.120.1445535321229;  Thu, 22 Oct 2015 10:35:21 -0700 (PDT)
Received: by 10.129.132.145 with HTTP; Thu, 22 Oct 2015 10:35:21 -0700 (PDT)
In-Reply-To: 
References:  <20151022125557.9B1651A31C@ld9781.wdf.sap.corp>    
Date: Thu, 22 Oct 2015 10:35:21 -0700
Message-ID: 
From: Martin Thomson 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:35:23 -0000

On 22 October 2015 at 10:11, Andrei Popov  wrote:
> Then my argument would be: why send extra bytes in each ServerHello when TLS
> client auth is not used most of the time? In this case, CertificateRequest
> seems to be a better place.

I think that this is the best argument for CertificateRequest.

We can prohibit the inclusion of the extension in ServerHello (or
Server EncryptedExtensions) as we please then.  I would argue for
prohibiting it, since it has no purpose.


From nobody Thu Oct 22 10:36:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FC71B3A87 for ; Thu, 22 Oct 2015 10:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVTpNzKjbH9x for ; Thu, 22 Oct 2015 10:36:20 -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 C26931B3A7A for ; Thu, 22 Oct 2015 10:36:20 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 CDBFE4484F; Thu, 22 Oct 2015 19:36:18 +0200 (CEST)
X-purgate-ID: 152705::1445535378-00000827-6B3AB63E/0/0
X-purgate-size: 1067
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 mail05.wdf.sap.corp (Postfix) with ESMTP id BC151440FC; Thu, 22 Oct 2015 19:36:18 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B5BCB1A31D; Thu, 22 Oct 2015 19:36:18 +0200 (CEST)
In-Reply-To: 
To: Andrei Popov 
Date: Thu, 22 Oct 2015 19:36: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: <20151022173618.B5BCB1A31D@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 22 Oct 2015 17:36:22 -0000

Andrei Popov wrote:
>
> Then my argument would be: why send extra bytes in each ServerHello
> when TLS client auth is not used most of the time? In this case,
> CertificateRequest seems to be a better place.

I'm perfectly OK with the server _not_ sending/including a TLS extension
"Supported Elliptic Curves" in ServerHello if the server is not going
to request a client certificate.

This is first of all about a fully backwards-compatible change of the
protocol, which does not need to be seperately negotiated, and which
is optional to use (for the server).

By including the information in "CertificateRequest", it will be
necessary to change the CertificateRequest PDU, and that will require
a new negotiation of such a changed PDU for existing TLS protocol
versions (TLSv1.0/1.1/1.2).

Conveying the information through ServerHello should work just fine
with existing implementations, does not need any additional negotiation
through ClientHello&ServerHello and does not need to change an existing
PDU (CertificateRequest).


-Martin


From nobody Thu Oct 22 10:40:23 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B8C1B3A9B for ; Thu, 22 Oct 2015 10:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 jjsL0cEJ-c2V for ; Thu, 22 Oct 2015 10:40:20 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002: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 CA7ED1B3A99 for ; Thu, 22 Oct 2015 10:40:19 -0700 (PDT)
Received: by ykba4 with SMTP id a4so84279436ykb.3 for ; Thu, 22 Oct 2015 10:40:19 -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:content-type; bh=eO/4p1YSbOMZFO/84nU6klnsI+JR0yKq0P5DDnBk41E=; b=RGbG0DnAgZCf7frQRV8wO6qEC6CpN6pjM+zt5o5EjKt8tqkKExeA5iz3mCKACZSdlv EfyODDsj4/TbY31NdSOgZW0ua10ramgmzzjXtNM+O5d19are+5NuEL9pVmerOn1Y3V70 22caZohRQugi2IsGtmPZpcBAYCGx/QV3oQNEtx3FmMNFCCq0SlSP2HFLpm4dXfG9K9P4 hmRAlk5Db5tcJBd4RsuIhj90npP1ntS+VvvuvfnmVrU+g5qmNdPD/mkpvforeQsWJLdg KES03Jw//XvR1L0ASqC00UNudyM9cwQfPGztcwiZsV/hx2XD5FRIMtPYIImyAddVZPo+ FoUw==
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-type; bh=eO/4p1YSbOMZFO/84nU6klnsI+JR0yKq0P5DDnBk41E=; b=Sy10krGL+STE8XZuoTIGTo4B3vbXXFUhO/GLL2s+fUvciGzXvUFYiNABch5zrB66q1 tTxmrD+6gSPL7mYWEAEF0eXtoSRuVTnKHxd5hDYftl1K67hDB4zvw3TDMl9Tx8uWQOW1 9dbmLRE+i33m4M6QyXUFBHHPLYGLoZDNVfd9FQlV0c8+aPRaivkXjH7JKgYnZip+si3Q CrJOhYYPRxCuKWcd7OEFY3zRf+GEwh32erbaqFwq9RQTUcUnpq2ZiL2T+ax97M/A0+ky SmO1f6ub80uTaoNXRDvFXfibxs+34BbsHt7sU3VU2V9wWcr05vBtQu6IJ14OoPawFlpg oN+Q==
X-Gm-Message-State: ALoCoQmm8cNGt/omhKlCa3alWoygqutxGnJYy5dRyDwjFrB2Ze9+/jEF1VpFHEd8HvxvT3JUAJj5
X-Received: by 10.129.106.9 with SMTP id f9mr13161235ywc.223.1445535619106; Thu, 22 Oct 2015 10:40:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 10:39:39 -0700 (PDT)
In-Reply-To: <20151022173618.B5BCB1A31D@ld9781.wdf.sap.corp>
References:  <20151022173618.B5BCB1A31D@ld9781.wdf.sap.corp>
From: Eric Rescorla 
Date: Thu, 22 Oct 2015 10:39:39 -0700
Message-ID: 
To: "mrex@sap.com" 
Content-Type: multipart/alternative; boundary=001a114934da1677200522b4fdb0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:40:23 -0000

--001a114934da1677200522b4fdb0
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex  wrote:

> Andrei Popov wrote:
> >
> > Then my argument would be: why send extra bytes in each ServerHello
> > when TLS client auth is not used most of the time? In this case,
> > CertificateRequest seems to be a better place.
>
> I'm perfectly OK with the server _not_ sending/including a TLS extension
> "Supported Elliptic Curves" in ServerHello if the server is not going
> to request a client certificate.
>
> This is first of all about a fully backwards-compatible change of the
> protocol, which does not need to be seperately negotiated, and which
> is optional to use (for the server).
>

It's not clear that it's in fact backwards compatible, since this is an
undefined
area in the spec.

As I mentioned earlier, I wasn't sure how NSS behaved here and so before
we even considered this [and I would still have to test to be totally sure]
and we would need to take some sort of measurement
from servers to determine that this does not cause bustage.


By including the information in "CertificateRequest", it will be
> necessary to change the CertificateRequest PDU, and that will require
> a new negotiation of such a changed PDU for existing TLS protocol
> versions (TLSv1.0/1.1/1.2).
>

We are already changing CertificateRequest in TLS 1.3 and we could (and
probably should do nothing for previous versions of TLS).

-Ekr

--001a114934da1677200522b4fdb0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex <mrex@sap.com> w=
rote:
Andrei Popov wrote=
:

>

> Then my argument would be: why send extra bytes in each ServerHello
> when TLS client auth is not used most of the time? In this case,

> CertificateRequest seems to be a better place.



I'm perfectly OK with the server _not_ sending/including a TLS e=
xtension

"Supported Elliptic Curves" in ServerHello if the server is not g=
oing

to request a client certificate.



This is first of all about a fully backwards-compatible change of the

protocol, which does not need to be seperately negotiated, and which

is optional to use (for the server).

It=
's not clear that it's in fact backwards compatible, since this is =
an undefined
area in the spec.

As I ment=
ioned earlier, I wasn't sure how NSS behaved here and so before
we even considered this [and I would still have to test to be totally su=
re]
and we would need to take some sort of measurement
=
from servers to determine that this does not cause bustage.

<=
/div>

By including the informa=
tion in "CertificateRequest", it will be

necessary to change the CertificateRequest PDU, and that will require

a new negotiation of such a changed PDU for existing TLS protocol

versions (TLSv1.0/1.1/1.2).

We are alre=
ady changing CertificateRequest in TLS 1.3 and we could (and
prob=
ably should do nothing for previous versions of TLS).

<=
div>-Ekr



--001a114934da1677200522b4fdb0--


From nobody Thu Oct 22 10:45:56 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA5B1B3AAD for ; Thu, 22 Oct 2015 10:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drP_ghC8CVVV for ; Thu, 22 Oct 2015 10:45:53 -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 C16351B3AA8 for ; Thu, 22 Oct 2015 10:45:53 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 00F374EC83; Thu, 22 Oct 2015 17:45:53 +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 DED93462B5A; Thu, 22 Oct 2015 17:45:52 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445535952; bh=i1V6L91dcaqThKRUZ2Y+TGjaARl95xEsGFKPnNIOFQo=; l=288; h=From:To:CC:Date:References:In-Reply-To:From; b=ZzwesRjzt0u4Qbdo2gj4vonck7FU5kry5neKNNwCX8uGf8Hfm5Wwlxqh8EEiRhH5U Ko3viY4UL+RvemnBvhpgmEzXo7qf0/7GQW/+TymDwRWu81o97ef113nOTFC26RDDGq 3Tznb19HSMgcPDJKvUK2DV8OZCEAUOAYGBBKGTYU=
Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id C71912042; Thu, 22 Oct 2015 17:45:52 +0000 (GMT)
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 22 Oct 2015 12:45:52 -0500
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1076.000; Thu, 22 Oct 2015 12:45:52 -0500
From: "Salz, Rich" 
To: Martin Thomson , "Kaduk, Ben" 
Thread-Topic: [TLS] Controlling use of SHA-1
Thread-Index: AQHRDDTdJWvzDWL3/UueLMUT2Olr5J52pbsAgABMooCAAIOMgIAAcEkAgAAgDACAABPfgP//sFXw
Date: Thu, 22 Oct 2015 17:45:51 +0000
Message-ID: <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com> 
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.47.117]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:45:55 -0000

> Maybe it would help if Victor could describe the situation in which he th=
inks
> that it would be appropriate to send a certificate that is signed by MD5.

Or where an application upgrades to a new library and expects EVERYTHING to=
 work exactly as it used to, with no changes.


From nobody Thu Oct 22 10:57:45 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205B41A7021 for ; Thu, 22 Oct 2015 10:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gRaP0AnQRIp for ; Thu, 22 Oct 2015 10:57:43 -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 109951A7020 for ; Thu, 22 Oct 2015 10:57:42 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 70C02424B27; Thu, 22 Oct 2015 17:57:42 +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 59A00478A9; Thu, 22 Oct 2015 17:57:42 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445536662; bh=eNPr42Y+ixNtKj0T0cpTJyvNhUwlH9RnjPT0Exzdk2M=; l=968; h=To:References:Cc:From:Date:In-Reply-To:From; b=KPs4DNzmlOyi50vqXZAdrSylOLM1CfPBHQ5GzmfMJbiKPNOF91rYJ/hF3R9IQjiAw iKPcsg7KmljvaBjosFSrGnsWky8Vu/OIjBW34So1A7FchoylcfAzAOSYrTuDP36iHF t5EZNHqvMS2IlmD3VY7xs3zIKrqnhXSsv/gcJGA4=
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 0C4C82055; Thu, 22 Oct 2015 17:57:41 +0000 (GMT)
To: "Salz, Rich" , Martin Thomson 
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com>
From: Benjamin Kaduk 
X-Enigmail-Draft-Status: N1110
Message-ID: <56292395.2050606@akamai.com>
Date: Thu, 22 Oct 2015 12:57:41 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 17:57:44 -0000

On 10/22/2015 12:45 PM, Salz, Rich wrote:
>> Maybe it would help if Victor could describe the situation in which he thinks
>> that it would be appropriate to send a certificate that is signed by MD5.
> Or where an application upgrades to a new library and expects EVERYTHING to work exactly as it used to, with no changes.
>

That one's actually not very hard -- in a system like FreeBSD ports or
NetBSD pkgsrc, the application and the library are separately maintained
within the whole tree, and when someone builds the application, they get
whatever version of the library happens to be in the tree at that time. 
The library can easily get upgraded without the application maintainer
noticing, and the automated systems are only likely to detect
compilation failure, not runtime behavior changes.

That is, the library update can be transparent to the end-user, who will
continue to expect normal functionality and expect everything to work.

-Ben


From nobody Thu Oct 22 11:00:38 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F037C1A8771 for ; Thu, 22 Oct 2015 11:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNTJA3Z3c1n4 for ; Thu, 22 Oct 2015 11:00:34 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2C21A8761 for ; Thu, 22 Oct 2015 11:00:34 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A1570200003; Thu, 22 Oct 2015 18:00:33 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 8B4FE200001; Thu, 22 Oct 2015 18:00:33 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445536833; bh=6+IeFx2j7KtyD0a8ol6kfXi8q69V4/lr8bDoC6CuNX8=; l=365; h=From:To:CC:Date:References:In-Reply-To:From; b=VFpdhjpQOb4p+A5OnjMjBxqghRcMvcTKi6Del9WrgUInz5zh+douHPGlMoxbVmKaN Nnprl1EGYlDBxBJFSILkPPQqa5GWlGZb8cHi/Ybc9lKBZt6naX4dmm/XAOq2meZRBE hRTOQKYwlX3WHyHTrsiYtzlDG6WLIDnrV3CvvJgc=
Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 875AA98088; Thu, 22 Oct 2015 18:00:33 +0000 (GMT)
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 22 Oct 2015 11:00:33 -0700
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1076.000; Thu, 22 Oct 2015 13:00:33 -0500
From: "Salz, Rich" 
To: "Kaduk, Ben" , Martin Thomson 
Thread-Topic: [TLS] Controlling use of SHA-1
Thread-Index: AQHRDDTdJWvzDWL3/UueLMUT2Olr5J52pbsAgABMooCAAIOMgIAAcEkAgAAgDACAABPfgP//sFXwgABXQID//6y6YA==
Date: Thu, 22 Oct 2015 18:00:32 +0000
Message-ID: 
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>
In-Reply-To: <56292395.2050606@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.47.117]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:00:38 -0000

> That is, the library update can be transparent to the end-user, who will
> continue to expect normal functionality and expect everything to work.

Should all applications suddenly start using TLS 1.3 without any changes?  =
Really?  Or should what *they used to do* just work as it was?  If that?  S=
uppose what they used to do is now considered bad practice?


From nobody Thu Oct 22 11:11:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDEA1B29DC for ; Thu, 22 Oct 2015 11:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktzaw9jevpkC for ; Thu, 22 Oct 2015 11:11:07 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAB01B29D4 for ; Thu, 22 Oct 2015 11:11:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iqVE7soN0V+U2aow2W3ro7pjJv4buQfo/8grlRhsUZc=; b=fKAA8YyhCTzjY8mXBK5fTEbNSzmhSDuSjxE7jLcdM2RB6YuIvNusyz/EtimVornQqEKeXEoR+1OwnpNCLPc6ssjKhccE+Cyw8WPJEeFHd4JnJNZPXPZzUSNnFo/YrRJ9Kruz5zCBB0GBX245aPvx6zftgzvbhMjgAk24dBhXRQM=
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 18:10:47 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 18:10:47 +0000
From: Andrei Popov 
To: Eric Rescorla , "mrex@sap.com" 
Thread-Topic: [TLS] Allow NamedGroups from the server?
Thread-Index: AQHRDFwySYYLbapvF0OM4bIxRSdhpp52qJkAgAABqACAAM8DgIAACVYAgAA7XHCAAAGpAIAAAMCwgAAHOQCAAADwgIAACLO3
Date: Thu, 22 Oct 2015 18:10:47 +0000
Message-ID: 
References:  <20151022173618.B5BCB1A31D@ld9781.wdf.sap.corp>, 
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: [166.198.182.36]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:S1gg77+FAHnsUkX7njBdmMLULI1T975dSiSIWEoJrZuOAoNKfewiysiK4f94E1iUT0FtJK6jxmaa3Z1XFnXFck7tbIwP0k/2A+Z+VkTyfN1FBNz/nnvwQL4fGHBbwEVWn2BvFtegz2pHGwxm3u1E3Q==; 24:4xvAipKKj0g30H/Qj6zGOPWEM/R3cDKPrHS+o2F0+zHWdLMIfdS9b1lUl2lbsqbmx00XsAXfQFQDIRRKmn24rGNeVBIwZpuCvnCt0UF9Iz0=; 20:16cI91MwyCNhlDfrj50pmXusNSuatkmJACPs/lHgltqi0j0d1BVvBzemBR5A4rejmT7RRP0NktvNxyJ4ZzTItQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026)(61426024)(61427024); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; 
x-forefront-prvs: 0737B96801
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(199003)(189002)(24454002)(377454003)(5003600100002)(76176999)(5008740100001)(92566002)(99286002)(106356001)(10290500002)(5005710100001)(10400500002)(16236675004)(74316001)(19580395003)(19580405001)(50986999)(106116001)(2501003)(11100500001)(54356999)(76576001)(105586002)(86362001)(2950100001)(10090500001)(2900100001)(33656002)(40100003)(8990500004)(66066001)(64706001)(122556002)(86612001)(46102003)(102836002)(101416001)(77096005)(81156007)(189998001)(97736004)(5001960100002)(5001770100001)(5007970100001)(5002640100001)(87936001)(5004730100002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396A76A26113E60E0BDB45B8C270BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 18:10:47.6053 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:11:09 -0000

--_000_BLUPR03MB1396A76A26113E60E0BDB45B8C270BLUPR03MB1396namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

To be clear, I'm in favor of introducing server-side NamedGroups in 1.3. I'=
ve no interest in making this change in any earlier protocol versions.

Cheers,

Andrei
________________________________
From: Eric Rescorla
Sent: 10/22/2015 10:40 AM
To: mrex@sap.com
Cc: Andrei Popov; tls@ietf.org
Subject: Re: [TLS] Allow NamedGroups from the server?



On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex > wrote:
Andrei Popov wrote:
>
> Then my argument would be: why send extra bytes in each ServerHello
> when TLS client auth is not used most of the time? In this case,
> CertificateRequest seems to be a better place.

I'm perfectly OK with the server _not_ sending/including a TLS extension
"Supported Elliptic Curves" in ServerHello if the server is not going
to request a client certificate.

This is first of all about a fully backwards-compatible change of the
protocol, which does not need to be seperately negotiated, and which
is optional to use (for the server).

It's not clear that it's in fact backwards compatible, since this is an und=
efined
area in the spec.

As I mentioned earlier, I wasn't sure how NSS behaved here and so before
we even considered this [and I would still have to test to be totally sure]
and we would need to take some sort of measurement
from servers to determine that this does not cause bustage.


By including the information in "CertificateRequest", it will be
necessary to change the CertificateRequest PDU, and that will require
a new negotiation of such a changed PDU for existing TLS protocol
versions (TLSv1.0/1.1/1.2).

We are already changing CertificateRequest in TLS 1.3 and we could (and
probably should do nothing for previous versions of TLS).

-Ekr


--_000_BLUPR03MB1396A76A26113E60E0BDB45B8C270BLUPR03MB1396namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable










To be clear, =
I'm in favor of introducing server-side NamedGroups in 1.3. I've no interes=
t in making this change in any earlier protocol versions.



Cheers,



Andrei







From:
Eric R=
escorla

Sent:
10/22/=
2015 10:40 AM

To:
mrex@s=
ap.com

Cc:
Andrei=
 Popov; tls@ietf.org

Subject:
Re: [T=
LS] Allow NamedGroups from the server?












On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex 
<mrex@sap.com><=
/span> wrote:



Andrei Popov wrote:

>

> Then my argument would be: why send extra bytes in each ServerHello
> when TLS client auth is not used most of the time? In this case,

> CertificateRequest seems to be a better place.



I'm perfectly OK with the server _not_ sending/including a TLS exten=
sion

"Supported Elliptic Curves" in ServerHello if the server is not g=
oing

to request a client certificate.



This is first of all about a fully backwards-compatible change of the

protocol, which does not need to be seperately negotiated, and which

is optional to use (for the server).









It's not clear that it's in fact backwards compatible, since this is a=
n undefined


area in the spec.







As I mentioned earlier, I wasn't sure how NSS behaved here and so befo=
re


we even considered this [and I would still have to test to be totally =
sure]


and we would need to take some sort of measurement


from servers to determine that this does not cause bustage.













By including the information in "CertificateRequest", it will be<=
br>
necessary to change the CertificateRequest PDU, and that will require

a new negotiation of such a changed PDU for existing TLS protocol

versions (TLSv1.0/1.1/1.2).









We are already changing CertificateRequest in TLS 1.3 and we could (an=
d


probably should do nothing for previous versions of TLS).







-Ekr

















--_000_BLUPR03MB1396A76A26113E60E0BDB45B8C270BLUPR03MB1396namp_--


From nobody Thu Oct 22 11:12:39 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341641B29DC for ; Thu, 22 Oct 2015 11:12:38 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6HYWMPpZNNd for ; Thu, 22 Oct 2015 11:12:36 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281161AC3A6 for ; Thu, 22 Oct 2015 11:12:36 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 542C5284DA6; Thu, 22 Oct 2015 18:12:35 +0000 (UTC)
Date: Thu, 22 Oct 2015 18:12:35 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20151022181235.GT15070@mournblade.imrryr.org>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list 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, 22 Oct 2015 18:12:38 -0000

On Thu, Oct 22, 2015 at 10:30:33AM -0700, Martin Thomson wrote:

> > % a certificate that specifies a trust anchor MAY be omitted from the chain
> >
> > The client cannot decide that the signature on the root cert the server
> > sent is bad, if the server does not send the root cert.
> 
> Yes, that was my thinking.
> 
> I expect that if a certificate is sent, then it might have to be
> checked.  As opposed to the roots, which are rarely sent or checked.

The roots are sent more frequently than you imagine.  With DANE-TA(2)
they MUST be sent if the server's TLSA record nominates a self-signed
trust-anchor.  Further-more, OpenSSL sends whatever the administrator
puts in the server "chain file", it would be wrong for it to
selectively delete the configured certificates, and many systems
include the root CA in the chain file.

> Maybe it would help if Victor could describe the situation in which he
> thinks that it would be appropriate to send a certificate that is
> signed by MD5.

The CAcert.org root is self-signed with MD5 and is sent as part of
the chain by various systems.  This self-signature is harmless,
but some systems pedantically disrupt the handshake in response.

For example, some Postfix clients are configured with CAcert.org
client cert chains, and provide client certs to the
mail.protection.outlook.com MTAs which then force a downgrade to
cleartext by refusing to continue the handshake.

The refusal to accept an MD5 self-signature is pedantic security
degradation.

-- 
	Viktor.


From nobody Thu Oct 22 11:17:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF4A1AC3E0 for ; Thu, 22 Oct 2015 11:17:14 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luw1IlNshj6v for ; Thu, 22 Oct 2015 11:17:13 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450: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 6CCE11B2A77 for ; Thu, 22 Oct 2015 11:17:12 -0700 (PDT)
Received: by wicfv8 with SMTP id fv8so618993wic.0 for ; Thu, 22 Oct 2015 11:17: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:date:message-id:subject:from:to :cc:content-type; bh=VecEHQYDlrQu3nKkfenXHhg+AuCc3QoPkCMMBMrqp3U=; b=WIFke3aWOG1s9gPf+pYnZZyL8BvM3j/IhjTA4NeFYBp07UWVMdGHn3xIRHADlR81Eu CnwPU3WXblp4BToF1DqX/qDd9u+d1VYeX+E30M5ssOyDjsi4idv+O4T2ueAqBiCaADHQ 2gO2vrJZtLMSLNqCmshu14cA5cGP9+eOZSkGQsWYanLf8GdGi3zCWNZ2eA1RAvBm0/7E MTIQio3ukwe233ArRm9yIW7mlCusv4IMf3el8a1wab5HwmhYZK37lIR94y6aLlHZXNNv By/S83hgieEA/HIx08MbsSFxqwZS6W+YXeeDmXzij/m123FkJuPma5WmEKMrdbYoHfsx IYzg==
MIME-Version: 1.0
X-Received: by 10.180.10.170 with SMTP id j10mr20111975wib.32.1445537830918; Thu, 22 Oct 2015 11:17:10 -0700 (PDT)
Received: by 10.28.101.212 with HTTP; Thu, 22 Oct 2015 11:17:09 -0700 (PDT)
Received: by 10.28.101.212 with HTTP; Thu, 22 Oct 2015 11:17:09 -0700 (PDT)
In-Reply-To: 
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com> 
Date: Thu, 22 Oct 2015 14:17:09 -0400
Message-ID: 
From: Watson Ladd 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=001a11c2660aebdffd0522b580c0
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:17:14 -0000

--001a11c2660aebdffd0522b580c0
Content-Type: text/plain; charset=UTF-8

On Oct 22, 2015 2:00 PM, "Salz, Rich"  wrote:
>
> > That is, the library update can be transparent to the end-user, who will
> > continue to expect normal functionality and expect everything to work.
>
> Should all applications suddenly start using TLS 1.3 without any
changes?  Really?  Or should what *they used to do* just work as it was?
If that?  Suppose what they used to do is now considered bad practice?

Ideally, yes. Applications never cared about what was happening, but wanted
a "secure this channel" magic call.

It's particularly important when we want to hunt down and eliminate bugs.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--001a11c2660aebdffd0522b580c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Oct 22, 2015 2:00 PM, "Salz, Rich" <rsalz@akamai.com> wrote:

>

> > That is, the library update can be transparent to the end-user, w=
ho will

> > continue to expect normal functionality and expect everything to =
work.

>

> Should all applications suddenly start using TLS 1.3 without any chang=
es?=C2=A0 Really?=C2=A0 Or should what *they used to do* just work as it wa=
s?=C2=A0 If that?=C2=A0 Suppose what they used to do is now considered bad =
practice?


Ideally, yes. Applications never cared about what was happen=
ing, but wanted a "secure this channel" magic call.


It's particularly important when we want to hunt down an=
d eliminate bugs.

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

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




--001a11c2660aebdffd0522b580c0--


From nobody Thu Oct 22 11:18:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF941B2AC3 for ; Thu, 22 Oct 2015 11:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYLqtv1zmajE for ; Thu, 22 Oct 2015 11:18:32 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149301B2ABA for ; Thu, 22 Oct 2015 11:18:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nMBOh1A0pJHAZI7Wvk/Vjmc1d2N9Ih7CTyV2yY2kcgA=; b=MIKINotQlRb4Mib0tce7IDqW90mFXsj8thoAE9YcEUNddcYemhO29MniMj91ehkTpjP+p6gA+q5hG2MDGxUjx01Ypy71T8jr1XCGDtnBTd30cZYJr8chTveM3vh+E9h0a2anNwfqBNM6L/UVYs4pTIffZ1RVXttOwuGR3Q14AOE=
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 18:18:30 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 18:18:30 +0000
From: Andrei Popov 
To: "tls@ietf.org" 
Thread-Topic: [TLS] Controlling use of SHA-1
Thread-Index: AQHRDDTgCaDFXiqkoUS7K1KHgIgBG552UekAgABMooCAAIONgIAAcEkAgAAgDACAABPegIAAC7+AgAABp+c=
Date: Thu, 22 Oct 2015 18:18:30 +0000
Message-ID: 
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com> , <20151022181235.GT15070@mournblade.imrryr.org>
In-Reply-To: <20151022181235.GT15070@mournblade.imrryr.org>
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: [166.198.182.36]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:tSQ2ljZOCBqP3Spnc1okMV2I4lf9/6W3af19nxIadpo9k9QwkXWvWbH46aHT89tcCjrzC0m1i9t6OkQeldglT1gV9YAL2lHdibeaQF1g15fojsvQER7E0bnIY2jdpWlTgTN170BIvm+6dd2Tepbz/g==; 24:g91LEC9Gkx//DTimTKmeMwGYvd8bB3rEXWcNjqAoNEUFy5vWwGB76CNkQEyL6hbeCNRVWXppZ6yX9Ij+AWMHlmdXejoTWa37isa/CfwwvqI=; 20:OCGXM18W028zafZQaT2PUx6lrslpwA6s8+tDABbBDSM3tTeLxS6AA6SDDHvVxGq1Jyc1dLhPOywSf00IMxhUwg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(189930954265078);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102215026)(61426024)(61427024); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; 
x-forefront-prvs: 0737B96801
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(189002)(199003)(479174004)(2900100001)(8990500004)(76176999)(5001960100002)(189998001)(11100500001)(5003600100002)(110136002)(5005710100001)(10290500002)(5007970100001)(10090500001)(86612001)(2950100001)(10400500002)(107886002)(81156007)(2501003)(97736004)(86362001)(575784001)(93886004)(5002640100001)(99286002)(5004730100002)(19617315012)(105586002)(54356999)(50986999)(101416001)(19625215002)(87936001)(106356001)(102836002)(15975445007)(77096005)(92566002)(5008740100001)(66066001)(2351001)(19580405001)(122556002)(16236675004)(106116001)(74316001)(19580395003)(33656002)(76576001)(40100003)(450100001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139614AEF7E997230B0A2E1A8C270BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 18:18:30.1810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:18:34 -0000

--_000_BLUPR03MB139614AEF7E997230B0A2E1A8C270BLUPR03MB1396namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

What if we just made an explicit exception for root cert hash algorithms an=
d not constrained them by the client's alg list?
________________________________
From: Viktor Dukhovni
Sent: 10/22/2015 11:12 AM
To: tls@ietf.org
Subject: Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 10:30:33AM -0700, Martin Thomson wrote:

> > % a certificate that specifies a trust anchor MAY be omitted from the c=
hain
> >
> > The client cannot decide that the signature on the root cert the server
> > sent is bad, if the server does not send the root cert.
>
> Yes, that was my thinking.
>
> I expect that if a certificate is sent, then it might have to be
> checked.  As opposed to the roots, which are rarely sent or checked.

The roots are sent more frequently than you imagine.  With DANE-TA(2)
they MUST be sent if the server's TLSA record nominates a self-signed
trust-anchor.  Further-more, OpenSSL sends whatever the administrator
puts in the server "chain file", it would be wrong for it to
selectively delete the configured certificates, and many systems
include the root CA in the chain file.

> Maybe it would help if Victor could describe the situation in which he
> thinks that it would be appropriate to send a certificate that is
> signed by MD5.

The https://na01.safelinks.protection.outlook.com/?url=3DCAcert.org&data=3D=
01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7=
c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D0kTNAt0ca9TAbtb1Gt5LanTfYajUC=
eKkuFZp59a9ljs%3d root is self-signed with MD5 and is sent as part of
the chain by various systems.  This self-signature is harmless,
but some systems pedantically disrupt the handshake in response.

For example, some Postfix clients are configured with https://na01.safelink=
s.protection.outlook.com/?url=3DCAcert.org&data=3D01%7c01%7cAndrei.Popov%40=
microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7c=
d011db47%7c1&sdata=3D0kTNAt0ca9TAbtb1Gt5LanTfYajUCeKkuFZp59a9ljs%3d
client cert chains, and provide client certs to the
https://na01.safelinks.protection.outlook.com/?url=3Dmail.protection.outloo=
k.com&data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab6720=
8d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DfKDA5Lyxn7S8P4BV=
FDD1mL1oyIzGYif5X2j4dH0NG80%3d MTAs which then force a downgrade to
cleartext by refusing to continue the handshake.

The refusal to accept an MD5 self-signature is pedantic security
degradation.

--
        Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf=
.org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c=
om%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c=
1&sdata=3DOYsiJgPkphzBreBA9Uv0aKCyw2yMEaa2QGNInB41x%2bc%3d

--_000_BLUPR03MB139614AEF7E997230B0A2E1A8C270BLUPR03MB1396namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













What if we ju=
st made an explicit exception for root cert hash algorithms and not constra=
ined them by the client's alg list?







From:
Viktor=
 Dukhovni

Sent:
10/22/=
2015 11:12 AM

To:
tls@ie=
tf.org

Subject:
Re: [T=
LS] Controlling use of SHA-1







On Thu, Oct 22, 2015 at 10:30:33AM -0700, Martin T=
homson wrote:



> > % a certificate that specifies a trust anchor MAY be omitted from=
 the chain

> >

> > The client cannot decide that the signature on the root cert the =
server

> > sent is bad, if the server does not send the root cert.

> 

> Yes, that was my thinking.

> 

> I expect that if a certificate is sent, then it might have to be

> checked.  As opposed to the roots, which are rarely sent or check=
ed.



The roots are sent more frequently than you imagine.  With DANE-TA(2)<=
br>
they MUST be sent if the server's TLSA record nominates a self-signed

trust-anchor.  Further-more, OpenSSL sends whatever the administrator<=
br>
puts in the server "chain file", it would be wrong for it to

selectively delete the configured certificates, and many systems

include the root CA in the chain file.



> Maybe it would help if Victor could describe the situation in which he=


> thinks that it would be appropriate to send a certificate that is

> signed by MD5.



The 
https://na01.safelinks.protection.outlook.com/?url=3DCAcert.org&data=3D=
01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7=
c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D0kTNAt0ca9TAbtb1Gt5LanTfY=
ajUCeKkuFZp59a9ljs%3d root is self-signed
 with MD5 and is sent as part of

the chain by various systems.  This self-signature is harmless,

but some systems pedantically disrupt the handshake in response.



For example, some Postfix clients are configured with 
https://na01.safelinks.protection.outlook.com/?url=3DCAcert.org&data=3D=
01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7=
c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D0kTNAt0ca9TAbtb1Gt5LanTfY=
ajUCeKkuFZp59a9ljs%3d

client cert chains, and provide client certs to the

https://na01.safelinks.p=
rotection.outlook.com/?url=3Dmail.protection.outlook.com&data=3D01%7c01=
%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988=
bf86f141af91ab2d7cd011db47%7c1&sdata=3DfKDA5Lyxn7S8P4BVFDD1mL1oyIzGYif5=
X2j4dH0NG80%3d
 MTAs which then force a downgrade to

cleartext by refusing to continue the handshake.



The refusal to accept an MD5 self-signature is pedantic security

degradation.



-- 

        Viktor.



_______________________________________________

TLS mailing list

TLS@ietf.org

https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.=
ietf.org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40mic=
rosoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd01=
1db47%7c1&sdata=3DOYsiJgPkphzBreBA9Uv0aKCyw2yMEaa2QGNInB41x%2bc%3d<=
br>






--_000_BLUPR03MB139614AEF7E997230B0A2E1A8C270BLUPR03MB1396namp_--


From nobody Thu Oct 22 11:19:01 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7681B2AEC for ; Thu, 22 Oct 2015 11:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN61gluDfQzI for ; Thu, 22 Oct 2015 11:18:47 -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 0FF7F1B2ABE for ; Thu, 22 Oct 2015 11:18:39 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 77C3E43349D; Thu, 22 Oct 2015 18:18:38 +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 5F2E043349C; Thu, 22 Oct 2015 18:18:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445537918; bh=3EGjZIj4jzur2k/7ehRj7zOdUB4CwuI6epIItCLX+MI=; l=646; h=To:References:Cc:From:Date:In-Reply-To:From; b=Y6eIpvGWBBLY1aUYhHodlFvGY74oNx3eSMBmY7DCNLnHJVb9lnhJHi/9j/4JsRTFf q74TEtheG9dOWaO+SfLUsahOFugVNEU0Glk5IaCUygGoSkVOscl7tuYeiqSJbHvZhs CY7pLt2Qc9gXQy8MRi0XeZudagjMN8x76KjPirFI=
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 128D1204B; Thu, 22 Oct 2015 18:18:38 +0000 (GMT)
To: "Salz, Rich" , Martin Thomson 
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com> 
From: Benjamin Kaduk 
Message-ID: <5629287D.9010905@akamai.com>
Date: Thu, 22 Oct 2015 13:18:37 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:18:50 -0000

On 10/22/2015 01:00 PM, Salz, Rich wrote:
>> That is, the library update can be transparent to the end-user, who will
>> continue to expect normal functionality and expect everything to work.
> Should all applications suddenly start using TLS 1.3 without any changes?  Really?  Or should what *they used to do* just work as it was?  If that?  Suppose what they used to do is now considered bad practice?

If we (okay, not "we", library implementors) require explicit
application opt-in to TLS 1.3, the adoption rate is probably not going
to be very good.  So, yes, I think applications should start using TLS
1.3 without any changes.

-Ben


From nobody Thu Oct 22 11:20:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEC11B2B01 for ; Thu, 22 Oct 2015 11:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWF5GjtcwAgb for ; Thu, 22 Oct 2015 11:20:12 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id A3EE71B2AE2 for ; Thu, 22 Oct 2015 11:20:12 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 41116496C9C; Thu, 22 Oct 2015 18:20:12 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 2B286496C83; Thu, 22 Oct 2015 18:20:12 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445538012; bh=JpPMwtJ58P7uJSIYmJl21zTtEgubc4P1hPDjaRzvz4Q=; l=437; h=From:To:CC:Date:References:In-Reply-To:From; b=XuuOrkaXFEZPW/9Wf2nDMQd/CKJdAnr4jYA0femjqU3vYP1aZT/xbC8UNPwLscd3I 4E3eiMWSsPZYKHbct3GghlHPrZlDv1T0Z7cYIcBXRsuvYg+6fkGKzaIX5Ht79LyC9J 5YItyw317yTH3gM9EeiXcJrdW7XtX4dzCBWit15I=
Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 289481E084; Thu, 22 Oct 2015 18:20:12 +0000 (GMT)
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 22 Oct 2015 13:20:08 -0500
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1076.000; Thu, 22 Oct 2015 13:20:08 -0500
From: "Salz, Rich" 
To: "Kaduk, Ben" , Martin Thomson 
Thread-Topic: [TLS] Controlling use of SHA-1
Thread-Index: AQHRDDTdJWvzDWL3/UueLMUT2Olr5J52pbsAgABMooCAAIOMgIAAcEkAgAAgDACAABPfgP//sFXwgABXQID//6y6YIAAWR+A//+sXZA=
Date: Thu, 22 Oct 2015 18:20:07 +0000
Message-ID: <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com>
In-Reply-To: <5629287D.9010905@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.47.117]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:20:14 -0000

> If we (okay, not "we", library implementors) require explicit application=
 opt-
> in to TLS 1.3, the adoption rate is probably not going to be very good.  =
So, yes,
> I think applications should start using TLS 1.3 without any changes.

And what about 0RTT?  Removed support for some crypto?  Various other seman=
tic changes?

What you're really saying is "just like it always used to be, just better."

And I want a pony.


From nobody Thu Oct 22 11:26:54 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEC71A874D for ; Thu, 22 Oct 2015 11:26:53 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qAXsGFJxfhz for ; Thu, 22 Oct 2015 11:26:52 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 A76F81A875A for ; Thu, 22 Oct 2015 11:26:51 -0700 (PDT)
Received: by wicfx6 with SMTP id fx6so829263wic.1 for ; Thu, 22 Oct 2015 11:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kHkwHy3W/EzooqRwISAyFDBjPMzVB+fKF4mb9J6Io20=; b=BjVcTksErHA+CnTFzfGlkDPmGGHYAaLIR9IUV9uK4E4czOIjsw5sxE+dA3c79hO3Kf MUazbSVVTf51pKl0JVZvjuK+vaY9CIwO5/VkKS7980thL1EUMPpJ3epYrEAr8CGt7zXg 0qIlOeDGKC/kLFrLKLtuV/1KL/EqbxDZrpqBlX4r0hy8cGjKpRabursBvEZqlRx9FSiQ kVdSBgZpdWOQPliTNJ33hSzunmQKMm9747SbzneUbRejD342+8Ox5Je9ejXxyEkSaE9T n49Q3uj/zFkutox1muDBfAG6+nKb8l5n+dDXGAcDc7Jxyq33yOrErohRUh8nUFF+cSO9 mqnA==
MIME-Version: 1.0
X-Received: by 10.180.36.195 with SMTP id s3mr2285617wij.30.1445538410241; Thu, 22 Oct 2015 11:26:50 -0700 (PDT)
Received: by 10.28.101.212 with HTTP; Thu, 22 Oct 2015 11:26:50 -0700 (PDT)
Received: by 10.28.101.212 with HTTP; Thu, 22 Oct 2015 11:26:50 -0700 (PDT)
In-Reply-To: <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com> <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com>
Date: Thu, 22 Oct 2015 14:26:50 -0400
Message-ID: 
From: Watson Ladd 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=e89a8f6473ff73a96f0522b5a3f3
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:26:53 -0000

--e89a8f6473ff73a96f0522b5a3f3
Content-Type: text/plain; charset=UTF-8

On Oct 22, 2015 2:20 PM, "Salz, Rich"  wrote:
>
> > If we (okay, not "we", library implementors) require explicit
application opt-
> > in to TLS 1.3, the adoption rate is probably not going to be very
good.  So, yes,
> > I think applications should start using TLS 1.3 without any changes.
>
> And what about 0RTT?  Removed support for some crypto?  Various other
semantic changes?

If you don't enable 0RTT support and ignore removed crypto, what breaks?
Most apps don't use renegotiation anyway?
>
> What you're really saying is "just like it always used to be, just
better."
>
> And I want a pony.

Most applications want a simple API that hides all the complexities of TLS.
If OpenSSL had done that, then it would be easy to see how enabling 1.2
won't cause problems for those apps which said "you take care of it".
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--e89a8f6473ff73a96f0522b5a3f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Oct 22, 2015 2:20 PM, "Salz, Rich" <rsalz@akamai.com> wrote:

>

> > If we (okay, not "we", library implementors) require ex=
plicit application opt-

> > in to TLS 1.3, the adoption rate is probably not going to be very=
 good.=C2=A0 So, yes,

> > I think applications should start using TLS 1.3 without any chang=
es.

>

> And what about 0RTT?=C2=A0 Removed support for some crypto?=C2=A0 Vari=
ous other semantic changes?


If you don't enable 0RTT support and ignore removed cryp=
to, what breaks? Most apps don't use renegotiation anyway?

>

> What you're really saying is "just like it always used to be,=
 just better."

>

> And I want a pony.


Most applications want a simple API that hides all the compl=
exities of TLS. If OpenSSL had done that, then it would be easy to see how =
enabling 1.2 won't cause problems for those apps which said "you t=
ake care of it".

>

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

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




--e89a8f6473ff73a96f0522b5a3f3--


From nobody Thu Oct 22 11:38:36 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67901B32B4 for ; Thu, 22 Oct 2015 11:38: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kz-40HYW4Zd for ; Thu, 22 Oct 2015 11:38:35 -0700 (PDT)
Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id D4C431B32B2 for ; Thu, 22 Oct 2015 11:38:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id E195821BB05; Thu, 22 Oct 2015 21:38:32 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id mKS3LYTLcImf; Thu, 22 Oct 2015 21:38:32 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id B42875BC002; Thu, 22 Oct 2015 21:38:32 +0300 (EEST)
Date: Thu, 22 Oct 2015 21:38:30 +0300
From: Ilari Liusvaara 
To: Benjamin Kaduk 
Message-ID: <20151022183830.GA7659@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5629287D.9010905@akamai.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:38:36 -0000

On Thu, Oct 22, 2015 at 01:18:37PM -0500, Benjamin Kaduk wrote:
> On 10/22/2015 01:00 PM, Salz, Rich wrote:
> >> That is, the library update can be transparent to the end-user, who will
> >> continue to expect normal functionality and expect everything to work.
> > Should all applications suddenly start using TLS 1.3 without any changes?
> >  Really?  Or should what *they used to do* just work as it was?  If that?
> > Suppose what they used to do is now considered bad practice?
> 
> If we (okay, not "we", library implementors) require explicit
> application opt-in to TLS 1.3, the adoption rate is probably not going
> to be very good.  So, yes, I think applications should start using TLS
> 1.3 without any changes.

As a note, I have personally seen bad security resulting from
application having to enable TLS versions.

I expect applications to start supporting TLS 1.3 with just upgrading
the crypto shared object, without even changing the application
executable.

Of course, features like 0-RTT won't work without application support,
but nothing existing uses those anyway.


-Ilari


From nobody Thu Oct 22 11:40:30 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D525D1B3AEA for ; Thu, 22 Oct 2015 11:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeorgEqfy_Fk for ; Thu, 22 Oct 2015 11:40: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 E568E1B3AE9 for ; Thu, 22 Oct 2015 11:40:26 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 50D4C43340B; Thu, 22 Oct 2015 18:40:26 +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 3A9C4433403; Thu, 22 Oct 2015 18:40:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445539226; bh=pgQR0F3gnMwgHI59Q0kM6tdHBtLuytGi27/KR3wkrDE=; l=1158; h=From:To:CC:Date:References:In-Reply-To:From; b=BpW988s5NFngzRNpWYuqi9uxjKpAqpcOJV1jal3wyWGikVeN78C3xZr6dL1Hk9+KS HrVY7rclRD1gZs5zWiygyTcgoVPn7ehVjTadKyXsKmOj91EqHARPI6iRDOFbyq9aMT TYwZ29Qg9jw74ukaZiZns2TjuSKNzTFlQtNAp64A=
Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 21A49202D; Thu, 22 Oct 2015 18:40:26 +0000 (GMT)
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 22 Oct 2015 11:40:25 -0700
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1076.000; Thu, 22 Oct 2015 13:40:25 -0500
From: "Salz, Rich" 
To: Watson Ladd 
Thread-Topic: [TLS] Controlling use of SHA-1
Thread-Index: AQHRDDTdJWvzDWL3/UueLMUT2Olr5J52pbsAgABMooCAAIOMgIAAcEkAgAAgDACAABPfgP//sFXwgABXQID//6y6YIAAWR+A//+sXZAACr3lAAAKNidQ
Date: Thu, 22 Oct 2015 18:40:25 +0000
Message-ID: 
References:   <201510211952.01479.davemgarrett@gmail.com>	<5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org>	<56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com> <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com> 
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.47.117]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:40:29 -0000

PiBNb3N0IGFwcGxpY2F0aW9ucyB3YW50IGEgc2ltcGxlIEFQSSB0aGF0IGhpZGVzIGFsbCB0aGUg
Y29tcGxleGl0aWVzIG9mIFRMUy4gSWYgT3BlblNTTCBoYWQgZG9uZSB0aGF0LCB0aGVuIGl0IHdv
dWxkIGJlIGVhc3kgdG8gc2VlIGhvdyBlbmFibGluZyAxLjIgd29uJ3QgY2F1c2UgcHJvYmxlbXMg
Zm9yIHRob3NlIGFwcHMgd2hpY2ggc2FpZCAieW91IHRha2UgY2FyZSBvZiBpdCIuDQoNCkFzIHNv
bWVvbmUgd2l0aCBhIGxvbmcgaGlzdG9yeSBvZiBidWlsZGluZywgaW5mbHVlbmNpbmcsIGFuZCB1
c2luZyBsaWJyYXJpZXMgYW5kIHRoZWlyIEFQSSdzLCB0aGlzIGlzIG5vdCBlYXN5Lg0KDQpXb3Vs
ZCB5b3UgZGlzYWJsZSAwUlRUIGJlY2F1c2UgdGhlIGVhcmx5ZGF0YSBtaWdodCBiZSByZXBsYXll
ZD8gIFRoYXQgd291bGQgYmUgdGhlIHNlY3VyZSB0aGluZyB0byBkbywgc28geW91IG1ha2UgYXBw
bGljYXRpb25zIHRoYXQgd2FudCB0byB1c2UgbmV3IGZlYXR1cmVzIGRvIGV4dHJhIHdvcmssIG9r
LiBXb3VsZCB5b3UgZGlzYWJsZSBBRVMtR0NNIGJlY2F1c2UgaXQncyBuZXcsIGFuZCBwZXJoYXBz
IGl0J3MgYW4gQVJNLWJhc2VkIGFwcGxpY2F0aW9uIHNvIHRoZSBDUFUgY29zdCBpcyBleHBlbnNp
dmU/IFRoYXQncyB0aGUgaW5zZWN1cmUgdGhpbmcgdG8gZG8sIGlzbid0IGl0PyAgV2hvIG1ha2Vz
IHRoYXQgdHJhZGUtb2ZmPyBTQ1NWPyAgU1NMdjI/IFRydXN0IGFuY2hvcnM/DQoNCkkgc3RpbGwg
d2FudCBhIHBvbnkuDQoNCi0tICANClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dp
ZXMNCklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg==


From nobody Thu Oct 22 11:42:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23611A897C for ; Thu, 22 Oct 2015 11:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 SVNV1O1x6gTe for ; Thu, 22 Oct 2015 11:42:16 -0700 (PDT)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 856821A8028 for ; Thu, 22 Oct 2015 11:42:16 -0700 (PDT)
Received: by ykba4 with SMTP id a4so86120712ykb.3 for ; Thu, 22 Oct 2015 11:42: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:content-type; bh=/jpb6ZDjDKdCEJ6hXHHsMrQWxQQCWyM+e4E6mwcIH3Q=; b=qRw8uEnL3EhLmZgcOJxzJGWER2vQv5CpLfqhxGizCQK9T376UaJQGGg+TsDyP3muor sVQkHnYTGouA83n/FLOPEzupRwsopUeSb7ulyT+CdCCmfA3myDiaMjlBxD249e/aoGRs O1+FYDcLm6D/lb/UlznRlL06p1YlsDXhuoHiF3vxeFYAw8GgFa9fL8fPd+JW/vKj9y04 0T/YIiGiinoE1OLSSxUeR30SLGfJ583c3NVoXng7HqeBy3puSUbnpD2NqfszqxoiVyeX 83Jr6eVR4LkE8PDywyhpRYUgo7BfJLAyG8g7CBVyQ8xJybfZAu1vwS1wz4QdsqyF7YfD YLEQ==
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-type; bh=/jpb6ZDjDKdCEJ6hXHHsMrQWxQQCWyM+e4E6mwcIH3Q=; b=eWvZhs99/734e+H9AIX3Hl8jYMBbRrZViKuQ4LMzbq+uBambhZXzCoxokKb1LOTtrM CMIZxgQd1C6b8EN+nV6k514/bSaLnp8hWtX0kSsxMTmo7p3rcCB+2ex84FkVHBPUYpyc +BTmEjyw7l7JMUZYAKU7gFn60LYedmPSlxqFLd1nfLbcsyJ+QqSDcO6BSbknstKFEsu1 gXHInRXMPYctvA1KxPkoyFrZ3v27nYgIcz4E9166PB/O9olJHYHvlK0F2+cU3sU+iHYs r7T7/72iV1anDHIuApyTiLWyJqtrAl5Vu53yx+YfqE1jsbQVuFBpObrbpKrg6ldB8+2c oW+g==
X-Gm-Message-State: ALoCoQkvcNajWI8SPBpcPgGtH/GbJB5SwI+gR5ySY2C2UZGKj5twhm8cgi94+DSwBBgHOtiTbw5Z
X-Received: by 10.13.198.132 with SMTP id i126mr13973293ywd.192.1445539335748;  Thu, 22 Oct 2015 11:42:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 11:41:36 -0700 (PDT)
In-Reply-To: 
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com> 
From: Eric Rescorla 
Date: Thu, 22 Oct 2015 11:41:36 -0700
Message-ID: 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=001a114e491e9df49d0522b5dac9
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:42:17 -0000

--001a114e491e9df49d0522b5dac9
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 22, 2015 at 11:00 AM, Salz, Rich  wrote:

> > That is, the library update can be transparent to the end-user, who will
> > continue to expect normal functionality and expect everything to work.
>
> Should all applications suddenly start using TLS 1.3 without any changes?
> Really?  Or should what *they used to do* just work as it was?  If that?
> Suppose what they used to do is now considered bad practice?


I would say anything they do that's good practice should keep working :)

-Ekr


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

--001a114e491e9df49d0522b5dac9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 22, 2015 at 11:00 AM, Salz, Rich <rsalz@akamai.com><=
/span> wrote:
> That =
is, the library update can be transparent to the end-user, who will

> continue to expect normal functionality and expect everything to work.=




Should all applications suddenly start using TLS 1.3 without any cha=
nges?=C2=A0 Really?=C2=A0 Or should what *they used to do* just work as it =
was?=C2=A0 If that?=C2=A0 Suppose what they used to do is now considered ba=
d practice?

I would say anything they do th=
at's good practice should keep working :)

-Ekr=

=C2=A0

_______________________________________________

TLS mailing list

TLS@ietf.org

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





--001a114e491e9df49d0522b5dac9--


From nobody Thu Oct 22 11:44:16 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C4D1B3AF6 for ; Thu, 22 Oct 2015 11:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 ibNduJOyGMpe for ; Thu, 22 Oct 2015 11:44:12 -0700 (PDT)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 ACA9B1B3AF7 for ; Thu, 22 Oct 2015 11:44:12 -0700 (PDT)
Received: by ykaz22 with SMTP id z22so92700951yka.2 for ; Thu, 22 Oct 2015 11:44:12 -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:content-type; bh=RJC/QzqLxqzjmGZvMDhkksTjs7SqqqSvjRQ12XVtICw=; b=vDlCGRoSYNiLXzWvU3O7PR753w8wVyXDEeXCgm6y394KkyKTpEm37X0n2Nr4AU8X0C qYrncO/cRajuWIq7qT1QjrICzhmi8T+mrZWhciJJl+sd02ZO505MhafvyhIU9bb9JSdb nOcR6Oc5eZGK8ZsfTfwHOmmyYFNfRmVe48JgZYXqUj3z+Tqo9gv8+NLtljSE2yqSBTKr GdTxCUSWY2iWTmt3TlPQvypB3I5SkRW/YxLR7/bm/u4htqdfXlLD2JsJ6YcrK9alnvU/ C1n0BvgWWXIRwOB+QJ3/ymg+JsR6NOZI5XloLOUHRS/ezuRDY34HJGh2FNTp04orgMyJ dXuA==
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-type; bh=RJC/QzqLxqzjmGZvMDhkksTjs7SqqqSvjRQ12XVtICw=; b=KU96pktJQbysuNvjW0A25tp3Oj3UG6DRr3LYJFpUN/zojGqb42o2JMgNHbZmbVuA8K zjd/ZrSjHKgD0pGZz/LsU0Xa1ReydNQiOmz3EO67qmWyLnrEq6/WxuyW1zrgMgBRF2E3 IWX2KQhy3p0gGNpl/Hi6B0Z9OPgiWTL0MnjgGvit7WYTgQar9hNOv+4SRlLf0Vr7VUcR 12k9TmCUOZ8fcZBuAJdgiftDoGW0KrhvhhvgPpQWu9bvPCt6aER2O6Xcqd6/JUCI0cjs a1C3QA+yxkrEyO6hAmWpa1EIsWImIdxKo1dqz1l7fVZGjz3nAUjyvxGxDUJQNBbQVHhG FE8A==
X-Gm-Message-State: ALoCoQkKzQzbf1US/VdkIHM3Y1r6iMXOgam4/cagtFWtg/btvzSqRXT2xIDBl0mXC60BDUevg8LC
X-Received: by 10.129.130.6 with SMTP id s6mr12416863ywf.155.1445539452001; Thu, 22 Oct 2015 11:44:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 11:43:32 -0700 (PDT)
In-Reply-To: <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com> <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com>
From: Eric Rescorla 
Date: Thu, 22 Oct 2015 11:43:32 -0700
Message-ID: 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=94eb2c07c35e8bd5630522b5e1a1
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 18:44:14 -0000

--94eb2c07c35e8bd5630522b5e1a1
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 22, 2015 at 11:20 AM, Salz, Rich  wrote:

> > If we (okay, not "we", library implementors) require explicit
> application opt-
> > in to TLS 1.3, the adoption rate is probably not going to be very good.
> So, yes,
> > I think applications should start using TLS 1.3 without any changes.
>
> And what about 0RTT?  Removed support for some crypto?  Various other
> semantic changes?
>

So, I think we've agreed that using 0-RTT should require explicit action.
And similarly if you have required some crypto algorithm that TLS 1.3
doesn't support (or you don't support any of the new ones) it should
fail. However, if you are using a conceptually compatible subset of
TLS 1.2 (i.e., modern algorithms, no renegotiation),
then I would expect you to be able to drop in TLS 1.3 and have
it work.

-Ekr



What you're really saying is "just like it always used to be, just better."
>
> And I want a pony.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c07c35e8bd5630522b5e1a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 22, 2015 at 11:20 AM, Salz, Rich <rsalz@akamai.com><=
/span> wrote:
> If we=
 (okay, not "we", library implementors) require explicit applicat=
ion opt-

> in to TLS 1.3, the adoption rate is probably not going to be very good=
.=C2=A0 So, yes,

> I think applications should start using TLS 1.3 without any changes.


And what about 0RTT?=C2=A0 Removed support for some crypto?=C2=A0 Va=
rious other semantic changes?

So, I thi=
nk we've agreed that using 0-RTT should require explicit action.
<=
div>And similarly if you have required some crypto algorithm that TLS 1.3
doesn't support (or you don't support any of the new ones)=
 it should
fail. However, if you are using a conceptually compati=
ble subset of
TLS 1.2 (i.e., modern algorithms, no renegotiation)=
,
then I would expect you to be able to drop in TLS 1.3 and have<=
br>
it work.

-Ekr




What you're really saying is "just like it always used to be, just=
 better."



And I want a pony.




_______________________________________________

TLS mailing list

TLS@ietf.org

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





--94eb2c07c35e8bd5630522b5e1a1--


From nobody Thu Oct 22 11:53:57 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0B21B3B8B for ; Thu, 22 Oct 2015 11:53:53 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1XIsIvmQl7I for ; Thu, 22 Oct 2015 11:53:51 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E873D1B3B75 for ; Thu, 22 Oct 2015 11:53:42 -0700 (PDT)
Received: from [172.16.19.180] (50-201-157-181-static.hfc.comcastbusiness.net [50.201.157.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1564A284DA6 for ; Thu, 22 Oct 2015 18:53:36 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Viktor Dukhovni 
In-Reply-To: 
Date: Thu, 22 Oct 2015 14:53:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <908A801D-92C1-45CC-8521-7E683B47F8A6@dukhovni.org>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <20151022181235.GT15070@mournblade.imrryr.org> 
To: "tls@ietf.org" 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "tls@ietf.org" 
List-Id: "This is the mailing list 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, 22 Oct 2015 18:53:54 -0000

> On Oct 22, 2015, at 2:18 PM, Andrei Popov  =
wrote:
>=20
> What if we just made an explicit exception for root cert hash =
algorithms and not constrained them by the client's alg list?

Yes, that would be substantially less bad.  I still don't see any =
compelling reason to shift chain validation policy from the verifying =
peer (typically client) to the subject (typically server).  The subject =
supplies its credentials good or bad, and the *verifier* enforces the =
right policy.

Indeed if we rely on servers never sending weak creds, clients might be =
lazy and vulnerable by not checking that they got strong creds.  The =
enforcement belongs in the verifier.

And yes, to repeat agreement with Andrei's specific point, exempting =
root-CA self-signatures would be substantially less bad than disallowing =
various signature algorithms globally.

--=20
	Viktor.



--=20
	Viktor.




From nobody Thu Oct 22 14:02:01 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7781B4192 for ; Thu, 22 Oct 2015 14:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.251
X-Spam-Level: 
X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSk9qY67FLUI for ; Thu, 22 Oct 2015 14:01:59 -0700 (PDT)
Received: from mail-pa0-f68.google.com (mail-pa0-f68.google.com [209.85.220.68]) (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 64C1E1B418E for ; Thu, 22 Oct 2015 14:01:59 -0700 (PDT)
Received: by pacik9 with SMTP id ik9so10157840pac.3 for ; Thu, 22 Oct 2015 14:01:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:message-id:subject:mime-version:content-type; bh=QdDlIOJPZcUKZCEyGgzJlCTSIgcI1yjBJlVpvJgLJlc=; b=wigpJzEuJJkKu8CxYb/IK2B/hmZMSfd/kqEtg5U9t7DaCv/EzYw7/MJcWQyvSY+UaF V0Orl03OwGmSDrUqHg9pRxOavV4TzihaOcNrXMWRQ8nITgfWwRnhBBrTByxR3+jvaVq6 hCpANeBZmqQ5v8h/KJkuhIUadvLUmk/UUeqp3BbS6PgPpZkBSVn84iID7tujrul0tVm2 Af17lpiofsOlsykGAKvu4OiixUjlQ2futAWUfCdSpoPVkzYAy7gKfMQ8ICSe94Ogjuk0 uoWzTwNodUPi1lsw6he/PLakVNhcpRb30phoeG9VZSoezgr8QNvlczXcAcPpHliEMF0P C/6A==
X-Received: by 10.66.122.98 with SMTP id lr2mr19571333pab.146.1445547718784; Thu, 22 Oct 2015 14:01:58 -0700 (PDT)
Received: from mail.outlook.com (ec2-52-10-69-246.us-west-2.compute.amazonaws.com. [52.10.69.246]) by smtp.gmail.com with ESMTPSA id nj1sm15361027pbc.2.2015.10.22.14.01.58 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Oct 2015 14:01:58 -0700 (PDT)
Date: Thu, 22 Oct 2015 21:01:57 +0000 (UTC)
From: Sultana Parveen 
To: tls@ietfa.amsl.com
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1324_335197111.1445547717884"
X-Mailer: Outlook for iOS and Android
Archived-At: 
Subject: [TLS] re
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 21:02:01 -0000

------=_Part_1324_335197111.1445547717884
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

it ok

Sent from Outlook
------=_Part_1324_335197111.1445547717884
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


it ok

Sent from Outlook


------=_Part_1324_335197111.1445547717884--


From nobody Thu Oct 22 14:02:58 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C656E1B2E5F for ; Thu, 22 Oct 2015 14:02:56 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlEzbSkNeio9 for ; Thu, 22 Oct 2015 14:02:53 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450: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 3667C1AD34C for ; Thu, 22 Oct 2015 14:02:53 -0700 (PDT)
Received: by wicfv8 with SMTP id fv8so6215716wic.0 for ; Thu, 22 Oct 2015 14:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cRxZpEtjJoT0ZyeDWj8zFkty7ilXewI8pfD9c0lMiwI=; b=fFsZrTCdSH6EUXoNydnyQcoXQPTTniZiNaxbwuOBWyeWQch3rUfXf15iVHBmgUA3rj sVNRltTGi7p91W7WMh7W6Ib27IS66E4qMT1/E6cFlFo90nvUvWCsGLVjIcuppjc/mZl0 zInjJf503//XrmJae86DKHRLmS+lDA3gUXd16vP3e8iXDW9TUCSpO7+k/yjClf6hJA4F BY0OQZeP/V8/SyEbaW3v4DQdc52fcmR7/6L45Ja9Pd4JhT1+qGXUbeZoXOlImMhRuJm8 sEEx8xeFeBvPqTKrkH20pbChZSi5rw5CuVcwippkTFLqKTsZgk7a5JTdKvS1qLaFamRh iHWA==
X-Received: by 10.194.192.72 with SMTP id he8mr640770wjc.30.1445547771534; Thu, 22 Oct 2015 14:02:51 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id lb10sm18977999wjc.9.2015.10.22.14.02.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Oct 2015 14:02:50 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6FC150B8-EA66-40F6-B5CC-6EF8299178EF"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir 
In-Reply-To: 
Date: Fri, 23 Oct 2015 00:02:45 +0300
Message-Id: <4C371712-61B1-4080-BD03-080A5E557A77@gmail.com>
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com> <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com> 
To: Watson Ladd 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 21:02:56 -0000

--Apple-Mail=_6FC150B8-EA66-40F6-B5CC-6EF8299178EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 22 Oct 2015, at 9:26 PM, Watson Ladd  wrote:
>=20
>=20
> On Oct 22, 2015 2:20 PM, "Salz, Rich" > wrote:
> >
> > > If we (okay, not "we", library implementors) require explicit =
application opt-
> > > in to TLS 1.3, the adoption rate is probably not going to be very =
good.  So, yes,
> > > I think applications should start using TLS 1.3 without any =
changes.
> >
> > And what about 0RTT?  Removed support for some crypto?  Various =
other semantic changes?
>=20
> If you don't enable 0RTT support and ignore removed crypto, what =
breaks? Most apps don't use renegotiation anyway?
> >
> > What you're really saying is "just like it always used to be, just =
better."
> >
> > And I want a pony.
>=20
> Most applications want a simple API that hides all the complexities of =
TLS. If OpenSSL had done that, then it would be easy to see how enabling =
1.2 won't cause problems for those apps which said "you take care of =
it=E2=80=9D.
>=20
That is true only if your application=E2=80=99s client component and =
server component are using the same library. That is not guaranteed in a =
protocol. Specifically that is not the case with the web.

There are some version intolerant servers out there that will choke on =
seeing a TLS 1.3 ClientHello. If the client uses some library (like =
OpenSSL) and you upgrade to OpenSSL 1.2.0 that has TLS 1.3. All of the =
sudden your application is broken. On the web this means that some =
websites don=E2=80=99t work.  Do you live with the application being =
sometimes broken?  Do you make some downgrade dance? Hard question, and =
one that the application needs to answer.=20

In any library it=E2=80=99s a major problem if an API call fails in the =
new version of the library where it would succeed in the old version. In =
a library implementing a protocol this could happen because of the =
network, because of middleboxes implementing their own version of =
=E2=80=9Csanity=E2=80=9D on the traffic, or because of peers that might =
have a different interpretation of the previous standard.

Yoav


--Apple-Mail=_6FC150B8-EA66-40F6-B5CC-6EF8299178EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 22 Oct 2015, at 9:26 PM, Watson Ladd <watsonbladd@gmail.com> wrote:



On Oct 22, 2015 2:20 PM, "Salz, Rich" <rsalz@akamai.com> =
wrote:

>

> > If we (okay, not "we", library implementors) require explicit =
application opt-

> > in to TLS 1.3, the adoption rate is probably not going to be =
very good.  So, yes,

> > I think applications should start using TLS 1.3 without any =
changes.

>

> And what about 0RTT?  Removed support for some crypto?  =
Various other semantic changes?
If you =
don't enable 0RTT support and ignore removed crypto, what breaks? Most =
apps don't use renegotiation anyway?

>

> What you're really saying is "just like it always used to be, just =
better."

>

> And I want a pony.
Most applications =
want a simple API that hides all the complexities of TLS. If OpenSSL had =
done that, then it would be easy to see how enabling 1.2 won't cause =
problems for those apps which said "you take care of it=E2=80=9D.
That is true only if your =
application=E2=80=99s client component and server component are using =
the same library. That is not guaranteed in a protocol. Specifically =
that is not the case with the web.

There are some version intolerant servers out =
there that will choke on seeing a TLS 1.3 ClientHello. If the client =
uses some library (like OpenSSL) and you upgrade to OpenSSL 1.2.0 that =
has TLS 1.3. All of the sudden your application is broken. On the web =
this means that some websites don=E2=80=99t work.  Do you live with =
the application being sometimes broken?  Do you make some downgrade =
dance? Hard question, and one that the application needs to =
answer. 

In any library it=E2=80=99=
s a major problem if an API call fails in the new version of the library =
where it would succeed in the old version. In a library implementing a =
protocol this could happen because of the network, because of =
middleboxes implementing their own version of =E2=80=9Csanity=E2=80=9D =
on the traffic, or because of peers that might have a different =
interpretation of the previous standard.

Yoav

=

--Apple-Mail=_6FC150B8-EA66-40F6-B5CC-6EF8299178EF--


From nobody Thu Oct 22 14:07:55 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027EC1B41CE for ; Thu, 22 Oct 2015 14:07:54 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ckE3HEYfkDO for ; Thu, 22 Oct 2015 14:07:53 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002: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 D535C1B2EE9 for ; Thu, 22 Oct 2015 14:07:52 -0700 (PDT)
Received: by ykba4 with SMTP id a4so90280360ykb.3 for ; Thu, 22 Oct 2015 14:07:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ea/uUdh58vjqcrek3ik9gQH7k6EXF5PlgJisk5CzBTc=; b=dANqD48Nt1H87LMbTY37FWP2yIS7I4s8QtdefDbJctcoOa02+t/EjAhlBZaUx2OKxQ L5GhVfXndbqM+uQn3mcJKMAFokbiI3zc/CEAhgcZ6mg/r1gy+mqIi/8vhAVAco8SL9Zx /N4XJlAT2NUiKbe6Ljk1F1UUh0Xdnb+f1LRbjzbNlkc0gYIYh8bCdbRZXwtW4pKIqN/z vvOVbQdMJdymBjDVmF1bihB6z6+scoOWl25LcLFiHi8QDgEXSqaPCNbqsi3xx1To52H8 EhXdwg9TUxbvnjpRvoroXINlA/jdHrVFruIBS1+0oG6Y2ZlRHdLYQPruM75y87rDZQxW 0/fw==
MIME-Version: 1.0
X-Received: by 10.129.55.209 with SMTP id e200mr14311090ywa.120.1445548072214;  Thu, 22 Oct 2015 14:07:52 -0700 (PDT)
Received: by 10.129.132.145 with HTTP; Thu, 22 Oct 2015 14:07:52 -0700 (PDT)
In-Reply-To: 
References:   <201510211952.01479.davemgarrett@gmail.com> <5628937B.9060403@comodo.com> <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  
Date: Thu, 22 Oct 2015 14:07:52 -0700
Message-ID: 
From: Martin Thomson 
To: Watson Ladd 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 21:07:54 -0000

On 22 October 2015 at 11:17, Watson Ladd  wrote:
> Ideally, yes. Applications never cared about what was happening, but wanted
> a "secure this channel" magic call.


I think that this is conditionally true.  If you are using TLS 1.2
with reasonably modern practices, then getting TLS 1.3 should be easy.
However, if you are relying on MD5 working, or limiting cipher suites
to RC4, then expect some pain.

For NSS, we probably won't turn TLS 1.3 on by default straight away,
but once it is stable, I expect that we will.  Applications that use
the defaults will get 1.3 at that point and not have to worry about
breakage.

Of course, we will be careful not to use 1.3 if things aren't
configured correctly (PFS disabled = no 1.3, etc...) This might not be
easy to perfect, but I believe that this is a goal that is worth the
extra effort.


From nobody Thu Oct 22 14:50:02 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C141A92E1 for ; Thu, 22 Oct 2015 14:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj3jZhowVp-1 for ; Thu, 22 Oct 2015 14:49:58 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id CB1A31A9176 for ; Thu, 22 Oct 2015 14:49:58 -0700 (PDT)
Received: from [174.236.38.255] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZpNk6-00088D-P9; Thu, 22 Oct 2015 17:49:51 -0400
Date: Thu, 22 Oct 2015 14:49:47 -0700
From: Bill Frantz 
To: Yoav Nir 
X-Priority: 3
In-Reply-To: <4C371712-61B1-4080-BD03-080A5E557A77@gmail.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7922e0eb1d9aa187c32033b78ae6974d02350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 174.236.38.255
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 22 Oct 2015 21:50:00 -0000

On 10/23/15 at 2:02 PM, ynir.ietf@gmail.com (Yoav Nir) wrote:

>That is true only if your application=E2=80=99s client component and=20
>server component are using the same library. That is not=20
>guaranteed in a protocol. Specifically that is not the case=20
>with the web.
>
>There are some version intolerant servers out there that will=20
>choke on seeing a TLS 1.3 ClientHello. If the client uses some=20
>library (like OpenSSL) and you upgrade to OpenSSL 1.2.0 that=20
>has TLS 1.3. All of the sudden your application is broken. On=20
>the web this means that some websites don=E2=80=99t work.

This incompatibility cuts both ways. Another way of looking at=20
it is that all of a sudden your website has lost viewers and you=20
should fix your problem. Perhaps I am unusual, but if I go the a=20
website that doesn't work, I usually conclude that I don't need=20
to see that web site. My problem is too little time, meaning I=20
don't want to bleep with things that don't work, not extra time=20
to futz with different browsers to get things working.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345=20
Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos,=20
CA 95032


From nobody Thu Oct 22 17:14:10 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BCA1B2CC8 for ; Thu, 22 Oct 2015 17:14:08 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ-y0vphEC8J for ; Thu, 22 Oct 2015 17:14:07 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 593051B2CA1 for ; Thu, 22 Oct 2015 17:14:07 -0700 (PDT)
Received: by ykaz22 with SMTP id z22so100840016yka.2 for ; Thu, 22 Oct 2015 17:14:06 -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-type:content-transfer-encoding:message-id; bh=0ChIEL92VLdXLv0yQtyXokcsQJ/3+iY5E/i7lfkFRwg=; b=ch9FPwRQzi3wuDs8mR3YB13VKKOQWaeC910+JhDz++66BlUVjKJqNGHClgSOqDaajn WzVXeaHoxsGAaLPLBhRCgCITXytksFfkzqN04rEhK6QZ/bn0aVatRRmQtFwjy4gqJnM+ nF39wk+igpmF2dMPgTmgoL+Vc6u/4j4j934hsA56Oai2V15eZ/UDXOZw5zMdc9qYwyZz Gw6klv9FgWtAoV1CLHk/3W+eJh0f1nvQnC+7HqNPVzPTtBH90rMrjp6xOCnKtmjRwxYo n3V8i5O1h+VbvC/1TJ8LZZncDFA/x7SADfsI9yIvzbLrOuccm8hFM5hm49Z84lqyu611 ieZA==
X-Received: by 10.129.103.11 with SMTP id b11mr13432874ywc.293.1445559246694;  Thu, 22 Oct 2015 17:14:06 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id j23sm11895632ywb.10.2015.10.22.17.14.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Oct 2015 17:14:06 -0700 (PDT)
From: Dave Garrett 
To: "tls@ietf.org" 
Date: Thu, 22 Oct 2015 20:14:04 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:  <20151022125557.9B1651A31C@ld9781.wdf.sap.corp> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201510222014.04719.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Allow NamedGroups from the server?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Oct 2015 00:14:08 -0000

On Thursday, October 22, 2015 09:29:22 am Eric Rescorla wrote:
> From an implementation perspective, I wouldn't be surprised if client
> implementations choked on the server sending this. [...]

Hence my side-note that we should be explicit that it's for TLS 1.3+ (even if it's implicit elsewhere).

On Thursday, October 22, 2015 01:36:18 pm Martin Rex wrote:
> Andrei Popov wrote:
> > Then my argument would be: why send extra bytes in each ServerHello
> > when TLS client auth is not used most of the time? In this case,
> > CertificateRequest seems to be a better place.
> 
> I'm perfectly OK with the server _not_ sending/including a TLS extension
> "Supported Elliptic Curves" in ServerHello if the server is not going
> to request a client certificate.

Yes, I would expect we want it in TLS 1.3+ ServerHello (or EncryptedExtensions) IFF the server is going to request a client cert.


Dave


From nobody Thu Oct 22 17:19:17 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C61B2BA0 for ; Thu, 22 Oct 2015 17:19:16 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3yQOlNOMteQ for ; Thu, 22 Oct 2015 17:19:15 -0700 (PDT)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 07FE61A21A1 for ; Thu, 22 Oct 2015 17:19:15 -0700 (PDT)
Received: by ykdr3 with SMTP id r3so100405853ykd.1 for ; Thu, 22 Oct 2015 17:19:14 -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-type:content-transfer-encoding:message-id; bh=4cC1wc7XayMRtHM85LT5pRxn/2j8sPTP6PoAwkKyzbs=; b=iJOoxY791PXQhyFNfc8zAsbLpPalrIlKtmCkyEoM3ZcrgeN7bhmUSTAwUC7AzZfcYB dWK5xjOAfBuOfPLCTgU6ZNcicneZrVT/sZNPJX+IhXfZpML8+fvld9yQ87Iu7dw1aJdV QM8PNP7Pav+WsQANs4mwlhxUpww3SM3FJTOGKWRbDs1NESYC1kbRk1VW35011Brkexee lwmEB2RRLJb+G790Wx2tDFkChVeLF+7sF329F98DwbMfWXI1I34RiS17UsRIz0mfkOC1 Xc/2dvh08V2XaJmxDrGRhQK/XdQChRDz1RGUZprXVovzwMgEze+6/Yz+/ZVkB55TBGyb lYRA==
X-Received: by 10.13.205.70 with SMTP id p67mr14648589ywd.249.1445559554347; Thu, 22 Oct 2015 17:19:14 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w3sm11875679ywf.47.2015.10.22.17.19.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Oct 2015 17:19:13 -0700 (PDT)
From: Dave Garrett 
To: tls@ietf.org
Date: Thu, 22 Oct 2015 20:19:12 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References:  <20151022181235.GT15070@mournblade.imrryr.org> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201510222019.13239.davemgarrett@gmail.com>
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Oct 2015 00:19:16 -0000

On Thursday, October 22, 2015 02:18:30 pm Andrei Popov wrote:
> What if we just made an explicit exception for root cert hash algorithms and not constrained them by the client's alg list?

+1


From nobody Thu Oct 22 21:34:02 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929F11B2C2D for ; Thu, 22 Oct 2015 21:34:01 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqq9sLpJ0Aqa for ; Thu, 22 Oct 2015 21:34:00 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FAB1B2C2C for ; Thu, 22 Oct 2015 21:33:59 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 031FD284DA3; Fri, 23 Oct 2015 04:33:58 +0000 (UTC)
Date: Fri, 23 Oct 2015 04:33:58 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20151023043358.GW15070@mournblade.imrryr.org>
References: <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com> <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list 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, 23 Oct 2015 04:34:01 -0000

On Thu, Oct 22, 2015 at 06:40:25PM +0000, Salz, Rich wrote:

> > Most applications want a simple API that hides all the complexities of
> > TLS. If OpenSSL had done that, then it would be easy to see how enabling
> > 1.2 won't cause problems for those apps which said "you take care of it".
> 
> As someone with a long history of building, influencing, and using libraries
> and their API's, this is not easy.

Binary compatibility is difficult, and requires maintaining legacy
versions of interfaces with cross-platform symbol versioning and
related magic that transcends the release engineering cycles
available to OpenSSL at this time.

That said, source compatibility is a fairly reasonable requirement.

By and large for applications doing simple things, OpenSSL remains
source compatible all the way from 0.9.5a to "master" (soon to be
1.1.0).  Postfix, which uses OpenSSL in a rather more sophisticated
way, has relatively minor adaptations to deal with source compatibility
changes from the 0.9.7 time-frame to the present (we've dropped
support for older OpenSSL versions that was present in earlier
Postfix releases, otherwise that would be 0.9.5 to the present).

Enabling TLS 1.2 (in OpenSSL 1.0.1) caused no fundamental problems
for Postfix, it largely continued to work as-is.  IIRC the padding
extension was needed in 1.0.1g to deal with interoperability with
some IronPort systems that had issues with large client HELLO
messages solved by padding.  The much larger list of ciphersuites
also caused pain with some rather dated Microsoft Exchange 2003
servers that were still in use.  But on the whole the transition
just worked, as it should have.

So recompiling a package against an OpenSSL that supports TLS 1.3,
and fixing occasional issues with now opaque data structures hidden
behind new accessors, should be sufficient for a largely unchanged
application to use TLS 1.3 with no explicit code changes to do so.

> I still want a pony.

I expect to report that Postfix works as-is when OpenSSL is released
with TLS 1.3.  This is not an unreasonable expectation.

If TLS 1.3 does not interoperate with opportunistic TLS clients
when servers are configured with pre-existing self-signed SHA-1
certificates, then IMHO the specification is broken.

If TLS 1.3 pig-headedly forbids sending non-root SHA-1 certs, and
OpenSSL with TLS 1.3 negotiates TLS 1.3 when a server has only a
CA-issued certificate signed with SHA-1, then OpenSSL is broken,
for it should then have worked around the specification brain-damage
by selecting TLS 1.2 (presumably the client still supports that).

I am perplexed that folks desperately want that server with that
SHA-1 cert to not be able to use TLS 1.3.  Surely, the decision to
not trust that cert (if certs are being checked at all) belongs in
the client.

Provided that weak self-signatures are not proscribed, I am resigned
to "come what may" if nobody else thinks that proper segregation
of duties is important, and that putting up some needless roadblocks
to TLS 1.3 use is the price of "progress".

-- 
	Viktor.


From nobody Fri Oct 23 06:55:49 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6857F1A01F7 for ; Fri, 23 Oct 2015 06:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R47e5Hu7Xt1T for ; Fri, 23 Oct 2015 06:55:45 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id A74CD1A01F6 for ; Fri, 23 Oct 2015 06:55:45 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2593C496C0A for ; Fri, 23 Oct 2015 13:55:45 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 05844496C03 for ; Fri, 23 Oct 2015 13:55:45 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445608545; bh=jRIWNRTTFE/P5TQeBfSbUcOPG69ejORVwOP2lO4RGkk=; l=17103; h=From:To:Date:References:In-Reply-To:From; b=YUNaBVSxxhf0PVbqbbDFex7TMwJyIqab3pAqBtObtfULqvhlcxg7T/9GQ2iqT9WH1 ch2ItwSvJTJDAlI59mVMZZoHy+AWDJiVKDhrlaz/XRSF1Ax6mTcHWgukrz3HI9Ei2E skmTHg4CRCLL4niW4MrbahEuAtxuh71UNiRZFnK4=
Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 026E098082 for ; Fri, 23 Oct 2015 13:55:45 +0000 (GMT)
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 23 Oct 2015 06:55:44 -0700
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1076.000; Fri, 23 Oct 2015 08:55:44 -0500
From: "Short, Todd" 
To: "tls@ietf.org" 
Thread-Topic: [TLS] Controlling use of SHA-1
Thread-Index: AQHRDDThYABxoS98qUutr6wQGpW7kJ52pboAgABMo4CAAIOMgIAAcEkAgAAgDACAABPfgIAABEaAgAADT4CAAADMAIAABQ2AgAAAa4CAAAHhAIAAA8uAgACl1gCAAJz0gA==
Date: Fri, 23 Oct 2015 13:55:43 +0000
Message-ID: 
References: <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com> <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com>   <20151023043358.GW15070@mournblade.imrryr.org>
In-Reply-To: <20151023043358.GW15070@mournblade.imrryr.org>
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.46.45]
Content-Type: multipart/alternative; boundary="_000_A919847F0A85453F93D995A2258DCBCEakamaicom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Oct 2015 13:55:48 -0000

--_000_A919847F0A85453F93D995A2258DCBCEakamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RnVuZGFtZW50YWxseSwgaXQgaXMgdXAgdG8gdGhlIGNsaWVudCAob3Igc2VydmVyIHdoZW4gZG9p
bmcgQ2xpZW50IEF1dGhlbnRpY2F0aW9uKSB0byBjaG9vc2Ugd2hldGhlciBvciBub3QgdG8gdHJ1
c3QgYSByZWNlaXZlZCBjZXJ0aWZpY2F0ZSBjaGFpbi4NCkkgYW0gYWxsIGZvciBkZXByZWNhdGlu
ZyBTSEEtMSAoYW5kIE1ELTUgYW5kIE1ELTIsIGFuZCBvdGhlciB3ZWFrZXIgbWVzc2FnZSBkaWdl
c3RzKSwgYnV0IOKAnEnigJltIG5vdCBzdXJlIGl04oCZcyBhIGdvb2QgaWRlYeKAnSAoU00pIHRv
IGZvcmNlIHRoZSBpc3N1ZSBpbiBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBwcm90b2NvbCB0aGF0IGlz
IGRlcGVuZGVudCBvbiBleHRlcm5hbCBzcGVjcyAoZS5nLiBYLjUwOSkgd2hpY2ggcGVybWl0IHRo
b3NlIG1lc3NhZ2UgZGlnZXN0cy4NCklmIHdlIHdhbnQgdG8gcHJvbW90ZSBUTFN2MS4zIGFuZCBh
dHRlbXB0IHRvIGhhdmUgZmFzdGVyIGFkb3B0aW9uIHRoYW4gVExTdjEuMiwgd2UgY2Fu4oCZdCBz
aG9vdCBvdXJzZWx2ZXMgaW4gdGhlIGZvb3QgYW5kIG5vdCB3b3JrIHdpdGggYSBsYXJnZSBtYWpv
cml0eSBvZiBzZXJ2ZXJzIG91dCB0aGVyZSBzdGlsbCB1c2luZyBvbGQgY2VydGlmaWNhdGVzLg0K
V2hpY2ggYnkgdGhlIHdheSwgZG8gZXhwaXJlLCBhbmQgc3Vic2VxdWVudGx5IHVwb24gcmVuZXdh
bCwgYXJlIHNpZ25lZCB3aXRoIHN0cm9uZ2VyIG1lc3NhZ2UgZGlnZXN0cy4gVGhlIGlzc3VlIGlz
IHdpdGggdGhlIG9sZCwgYW5jaWVudCByb290cywgdGhhdCBzdGlsbCB1c2UgbGVnYWN5IG1lc3Nh
Z2UgZGlnZXN0IGFsZ29yaXRobXMsIGFuZCBhcmUgbGVzcyBlYXN5IHRvIHVwZGF0ZS4gQnV0IGl0
IGNhbiBiZSBkb25lIQ0KSSB0aGluayB0aGUgb251cyBpcyByZWFsbHkgb24gdGhlIGxpYnJhcnkg
YXV0aG9ycyB0byB2YWxpZGF0ZSB0aGUgY2hhaW4sIGJ1dCByZXBvcnQgYW5vbWFsaWVzIHN1Y2gg
YXMgU0hBLTEgaW4gdGhlIGNoYWluLCBvciBhIE1ENS1zZWxmLXNpZ25lZC1yb290LiBUaGUgYXBw
bGljYXRpb25zIGFyZSB0aGVuIGZyZWUgdG8gYWNjZXB0IHRoZSBjaGFpbiBvciBub3QuIENocm9t
ZSBoYXMgYWxyZWFkeSBkb25lIHRoaXMsIGFuZCBhZGRpbmcgc3VwcG9ydCB0byBsaWJyYXJpZXMg
dG8gbWFrZSB0aGlzIHRoZSBkZWZhdWx0IG9yIGVhc2llciB0byBkZXRlY3QgbWFrZXMgaXQgdGhh
dCBtdWNoIGVhc2llciB0byBkZXByZWNhdGUgU0hBMS4NCkluIHN1bW1hcnksIEnigJltIGluIHRo
ZSBTSE9VTEQgTk9UIHVzZSBTSEEtMSBjYW1wLCByYXRoZXIgdGhhbiB0aGUgTVVTVCBOT1QuDQot
LQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWkuY29tPG1haWx0bzp0c2hvcnRAYWthbWFp
LmNvbT4NCi8vICJPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhl
IEludGVybmV0LiINCg0KT24gT2N0IDIzLCAyMDE1LCBhdCAxMjozMyBBTSwgVmlrdG9yIER1a2hv
dm5pIDxpZXRmLWRhbmVAZHVraG92bmkub3JnPG1haWx0bzppZXRmLWRhbmVAZHVraG92bmkub3Jn
Pj4gd3JvdGU6DQoNCk9uIFRodSwgT2N0IDIyLCAyMDE1IGF0IDA2OjQwOjI1UE0gKzAwMDAsIFNh
bHosIFJpY2ggd3JvdGU6DQoNCk1vc3QgYXBwbGljYXRpb25zIHdhbnQgYSBzaW1wbGUgQVBJIHRo
YXQgaGlkZXMgYWxsIHRoZSBjb21wbGV4aXRpZXMgb2YNClRMUy4gSWYgT3BlblNTTCBoYWQgZG9u
ZSB0aGF0LCB0aGVuIGl0IHdvdWxkIGJlIGVhc3kgdG8gc2VlIGhvdyBlbmFibGluZw0KMS4yIHdv
bid0IGNhdXNlIHByb2JsZW1zIGZvciB0aG9zZSBhcHBzIHdoaWNoIHNhaWQgInlvdSB0YWtlIGNh
cmUgb2YgaXQiLg0KDQpBcyBzb21lb25lIHdpdGggYSBsb25nIGhpc3Rvcnkgb2YgYnVpbGRpbmcs
IGluZmx1ZW5jaW5nLCBhbmQgdXNpbmcgbGlicmFyaWVzDQphbmQgdGhlaXIgQVBJJ3MsIHRoaXMg
aXMgbm90IGVhc3kuDQoNCkJpbmFyeSBjb21wYXRpYmlsaXR5IGlzIGRpZmZpY3VsdCwgYW5kIHJl
cXVpcmVzIG1haW50YWluaW5nIGxlZ2FjeQ0KdmVyc2lvbnMgb2YgaW50ZXJmYWNlcyB3aXRoIGNy
b3NzLXBsYXRmb3JtIHN5bWJvbCB2ZXJzaW9uaW5nIGFuZA0KcmVsYXRlZCBtYWdpYyB0aGF0IHRy
YW5zY2VuZHMgdGhlIHJlbGVhc2UgZW5naW5lZXJpbmcgY3ljbGVzDQphdmFpbGFibGUgdG8gT3Bl
blNTTCBhdCB0aGlzIHRpbWUuDQoNClRoYXQgc2FpZCwgc291cmNlIGNvbXBhdGliaWxpdHkgaXMg
YSBmYWlybHkgcmVhc29uYWJsZSByZXF1aXJlbWVudC4NCg0KQnkgYW5kIGxhcmdlIGZvciBhcHBs
aWNhdGlvbnMgZG9pbmcgc2ltcGxlIHRoaW5ncywgT3BlblNTTCByZW1haW5zDQpzb3VyY2UgY29t
cGF0aWJsZSBhbGwgdGhlIHdheSBmcm9tIDAuOS41YSB0byAibWFzdGVyIiAoc29vbiB0byBiZQ0K
MS4xLjApLiAgUG9zdGZpeCwgd2hpY2ggdXNlcyBPcGVuU1NMIGluIGEgcmF0aGVyIG1vcmUgc29w
aGlzdGljYXRlZA0Kd2F5LCBoYXMgcmVsYXRpdmVseSBtaW5vciBhZGFwdGF0aW9ucyB0byBkZWFs
IHdpdGggc291cmNlIGNvbXBhdGliaWxpdHkNCmNoYW5nZXMgZnJvbSB0aGUgMC45LjcgdGltZS1m
cmFtZSB0byB0aGUgcHJlc2VudCAod2UndmUgZHJvcHBlZA0Kc3VwcG9ydCBmb3Igb2xkZXIgT3Bl
blNTTCB2ZXJzaW9ucyB0aGF0IHdhcyBwcmVzZW50IGluIGVhcmxpZXINClBvc3RmaXggcmVsZWFz
ZXMsIG90aGVyd2lzZSB0aGF0IHdvdWxkIGJlIDAuOS41IHRvIHRoZSBwcmVzZW50KS4NCg0KRW5h
YmxpbmcgVExTIDEuMiAoaW4gT3BlblNTTCAxLjAuMSkgY2F1c2VkIG5vIGZ1bmRhbWVudGFsIHBy
b2JsZW1zDQpmb3IgUG9zdGZpeCwgaXQgbGFyZ2VseSBjb250aW51ZWQgdG8gd29yayBhcy1pcy4g
IElJUkMgdGhlIHBhZGRpbmcNCmV4dGVuc2lvbiB3YXMgbmVlZGVkIGluIDEuMC4xZyB0byBkZWFs
IHdpdGggaW50ZXJvcGVyYWJpbGl0eSB3aXRoDQpzb21lIElyb25Qb3J0IHN5c3RlbXMgdGhhdCBo
YWQgaXNzdWVzIHdpdGggbGFyZ2UgY2xpZW50IEhFTExPDQptZXNzYWdlcyBzb2x2ZWQgYnkgcGFk
ZGluZy4gIFRoZSBtdWNoIGxhcmdlciBsaXN0IG9mIGNpcGhlcnN1aXRlcw0KYWxzbyBjYXVzZWQg
cGFpbiB3aXRoIHNvbWUgcmF0aGVyIGRhdGVkIE1pY3Jvc29mdCBFeGNoYW5nZSAyMDAzDQpzZXJ2
ZXJzIHRoYXQgd2VyZSBzdGlsbCBpbiB1c2UuICBCdXQgb24gdGhlIHdob2xlIHRoZSB0cmFuc2l0
aW9uDQpqdXN0IHdvcmtlZCwgYXMgaXQgc2hvdWxkIGhhdmUuDQoNClNvIHJlY29tcGlsaW5nIGEg
cGFja2FnZSBhZ2FpbnN0IGFuIE9wZW5TU0wgdGhhdCBzdXBwb3J0cyBUTFMgMS4zLA0KYW5kIGZp
eGluZyBvY2Nhc2lvbmFsIGlzc3VlcyB3aXRoIG5vdyBvcGFxdWUgZGF0YSBzdHJ1Y3R1cmVzIGhp
ZGRlbg0KYmVoaW5kIG5ldyBhY2Nlc3NvcnMsIHNob3VsZCBiZSBzdWZmaWNpZW50IGZvciBhIGxh
cmdlbHkgdW5jaGFuZ2VkDQphcHBsaWNhdGlvbiB0byB1c2UgVExTIDEuMyB3aXRoIG5vIGV4cGxp
Y2l0IGNvZGUgY2hhbmdlcyB0byBkbyBzby4NCg0KSSBzdGlsbCB3YW50IGEgcG9ueS4NCg0KSSBl
eHBlY3QgdG8gcmVwb3J0IHRoYXQgUG9zdGZpeCB3b3JrcyBhcy1pcyB3aGVuIE9wZW5TU0wgaXMg
cmVsZWFzZWQNCndpdGggVExTIDEuMy4gIFRoaXMgaXMgbm90IGFuIHVucmVhc29uYWJsZSBleHBl
Y3RhdGlvbi4NCg0KSWYgVExTIDEuMyBkb2VzIG5vdCBpbnRlcm9wZXJhdGUgd2l0aCBvcHBvcnR1
bmlzdGljIFRMUyBjbGllbnRzDQp3aGVuIHNlcnZlcnMgYXJlIGNvbmZpZ3VyZWQgd2l0aCBwcmUt
ZXhpc3Rpbmcgc2VsZi1zaWduZWQgU0hBLTENCmNlcnRpZmljYXRlcywgdGhlbiBJTUhPIHRoZSBz
cGVjaWZpY2F0aW9uIGlzIGJyb2tlbi4NCg0KSWYgVExTIDEuMyBwaWctaGVhZGVkbHkgZm9yYmlk
cyBzZW5kaW5nIG5vbi1yb290IFNIQS0xIGNlcnRzLCBhbmQNCk9wZW5TU0wgd2l0aCBUTFMgMS4z
IG5lZ290aWF0ZXMgVExTIDEuMyB3aGVuIGEgc2VydmVyIGhhcyBvbmx5IGENCkNBLWlzc3VlZCBj
ZXJ0aWZpY2F0ZSBzaWduZWQgd2l0aCBTSEEtMSwgdGhlbiBPcGVuU1NMIGlzIGJyb2tlbiwNCmZv
ciBpdCBzaG91bGQgdGhlbiBoYXZlIHdvcmtlZCBhcm91bmQgdGhlIHNwZWNpZmljYXRpb24gYnJh
aW4tZGFtYWdlDQpieSBzZWxlY3RpbmcgVExTIDEuMiAocHJlc3VtYWJseSB0aGUgY2xpZW50IHN0
aWxsIHN1cHBvcnRzIHRoYXQpLg0KDQpJIGFtIHBlcnBsZXhlZCB0aGF0IGZvbGtzIGRlc3BlcmF0
ZWx5IHdhbnQgdGhhdCBzZXJ2ZXIgd2l0aCB0aGF0DQpTSEEtMSBjZXJ0IHRvIG5vdCBiZSBhYmxl
IHRvIHVzZSBUTFMgMS4zLiAgU3VyZWx5LCB0aGUgZGVjaXNpb24gdG8NCm5vdCB0cnVzdCB0aGF0
IGNlcnQgKGlmIGNlcnRzIGFyZSBiZWluZyBjaGVja2VkIGF0IGFsbCkgYmVsb25ncyBpbg0KdGhl
IGNsaWVudC4NCg0KUHJvdmlkZWQgdGhhdCB3ZWFrIHNlbGYtc2lnbmF0dXJlcyBhcmUgbm90IHBy
b3NjcmliZWQsIEkgYW0gcmVzaWduZWQNCnRvICJjb21lIHdoYXQgbWF5IiBpZiBub2JvZHkgZWxz
ZSB0aGlua3MgdGhhdCBwcm9wZXIgc2VncmVnYXRpb24NCm9mIGR1dGllcyBpcyBpbXBvcnRhbnQs
IGFuZCB0aGF0IHB1dHRpbmcgdXAgc29tZSBuZWVkbGVzcyByb2FkYmxvY2tzDQp0byBUTFMgMS4z
IHVzZSBpcyB0aGUgcHJpY2Ugb2YgInByb2dyZXNzIi4NCg0KLS0NClZpa3Rvci4NCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxp
c3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K

--_000_A919847F0A85453F93D995A2258DCBCEakamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <311E1B45C36BBB4686667705CC77730E@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5GdW5kYW1l
bnRhbGx5LCBpdCBpcyB1cCB0byB0aGUgY2xpZW50IChvciBzZXJ2ZXIgd2hlbiBkb2luZyBDbGll
bnQgQXV0aGVudGljYXRpb24pIHRvIGNob29zZSB3aGV0aGVyIG9yIG5vdCB0byB0cnVzdCBhIHJl
Y2VpdmVkIGNlcnRpZmljYXRlIGNoYWluLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIGFsbCBm
b3IgZGVwcmVjYXRpbmcgU0hBLTEgKGFuZCBNRC01IGFuZCBNRC0yLCBhbmQgb3RoZXIgd2Vha2Vy
IG1lc3NhZ2UgZGlnZXN0cyksIGJ1dCDigJxJ4oCZbSBub3Qgc3VyZSBpdOKAmXMgYSBnb29kIGlk
ZWHigJ0gKFNNKSB0byBmb3JjZSB0aGUgaXNzdWUgaW4gYSBuZXcgdmVyc2lvbiBvZiB0aGUgcHJv
dG9jb2wgdGhhdCBpcyBkZXBlbmRlbnQgb24gZXh0ZXJuYWwgc3BlY3MgKGUuZy4gWC41MDkpIHdo
aWNoIHBlcm1pdCB0aG9zZQ0KIG1lc3NhZ2UgZGlnZXN0cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
SWYgd2Ugd2FudCB0byBwcm9tb3RlIFRMU3YxLjMgYW5kIGF0dGVtcHQgdG8gaGF2ZSBmYXN0ZXIg
YWRvcHRpb24gdGhhbiBUTFN2MS4yLCB3ZSBjYW7igJl0IHNob290IG91cnNlbHZlcyBpbiB0aGUg
Zm9vdCBhbmQgbm90IHdvcmsgd2l0aCBhIGxhcmdlIG1ham9yaXR5IG9mIHNlcnZlcnMgb3V0IHRo
ZXJlIHN0aWxsIHVzaW5nIG9sZCBjZXJ0aWZpY2F0ZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldo
aWNoIGJ5IHRoZSB3YXksIGRvIGV4cGlyZSwgYW5kIHN1YnNlcXVlbnRseSB1cG9uIHJlbmV3YWws
IGFyZSBzaWduZWQgd2l0aCBzdHJvbmdlciBtZXNzYWdlIGRpZ2VzdHMuIFRoZSBpc3N1ZSBpcyB3
aXRoIHRoZSBvbGQsIGFuY2llbnQgcm9vdHMsIHRoYXQgc3RpbGwgdXNlIGxlZ2FjeSBtZXNzYWdl
IGRpZ2VzdCBhbGdvcml0aG1zLCBhbmQgYXJlIGxlc3MgZWFzeSB0byB1cGRhdGUuIEJ1dCBpdCBj
YW4gYmUgZG9uZSE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSB0aGluayB0aGUgb251cyBpcyByZWFs
bHkgb24gdGhlIGxpYnJhcnkgYXV0aG9ycyB0byB2YWxpZGF0ZSB0aGUgY2hhaW4sIGJ1dCByZXBv
cnQgYW5vbWFsaWVzIHN1Y2ggYXMgU0hBLTEgaW4gdGhlIGNoYWluLCBvciBhIE1ENS1zZWxmLXNp
Z25lZC1yb290LiBUaGUgYXBwbGljYXRpb25zIGFyZSB0aGVuIGZyZWUgdG8gYWNjZXB0IHRoZSBj
aGFpbiBvciBub3QuIENocm9tZSBoYXMgYWxyZWFkeSBkb25lIHRoaXMsIGFuZCBhZGRpbmcNCiBz
dXBwb3J0IHRvIGxpYnJhcmllcyB0byBtYWtlIHRoaXMgdGhlIGRlZmF1bHQgb3IgZWFzaWVyIHRv
IGRldGVjdCBtYWtlcyBpdCB0aGF0IG11Y2ggZWFzaWVyIHRvIGRlcHJlY2F0ZSBTSEExLjwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj5JbiBzdW1tYXJ5LCBJ4oCZbSBpbiB0aGUgU0hPVUxEIE5PVCB1c2Ug
U0hBLTEgY2FtcCwgcmF0aGVyIHRoYW4gdGhlIE1VU1QgTk9ULjxiciBjbGFzcz0iIj4NCjxkaXYg
YXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6
IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp
dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl
OyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93
czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr
aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9
IiI+LS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LVRvZGQgU2hvcnQ8L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+Ly8gPGEgaHJlZj0ibWFpbHRvOnRzaG9ydEBha2FtYWkuY29tIiBjbGFzcz0iIj50c2hvcnRA
YWthbWFpLmNvbTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gJnF1b3Q7T25lIGlmIGJ5IGxh
bmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gT2N0IDIzLCAyMDE1LCBh
dCAxMjozMyBBTSwgVmlrdG9yIER1a2hvdm5pICZsdDs8YSBocmVmPSJtYWlsdG86aWV0Zi1kYW5l
QGR1a2hvdm5pLm9yZyIgY2xhc3M9IiI+aWV0Zi1kYW5lQGR1a2hvdm5pLm9yZzwvYT4mZ3Q7IHdy
b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg
Y2xhc3M9IiI+T24gVGh1LCBPY3QgMjIsIDIwMTUgYXQgMDY6NDA6MjVQTSAmIzQzOzAwMDAsIFNh
bHosIFJpY2ggd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5N
b3N0IGFwcGxpY2F0aW9ucyB3YW50IGEgc2ltcGxlIEFQSSB0aGF0IGhpZGVzIGFsbCB0aGUgY29t
cGxleGl0aWVzIG9mPGJyIGNsYXNzPSIiPg0KVExTLiBJZiBPcGVuU1NMIGhhZCBkb25lIHRoYXQs
IHRoZW4gaXQgd291bGQgYmUgZWFzeSB0byBzZWUgaG93IGVuYWJsaW5nPGJyIGNsYXNzPSIiPg0K
MS4yIHdvbid0IGNhdXNlIHByb2JsZW1zIGZvciB0aG9zZSBhcHBzIHdoaWNoIHNhaWQgJnF1b3Q7
eW91IHRha2UgY2FyZSBvZiBpdCZxdW90Oy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8
YnIgY2xhc3M9IiI+DQpBcyBzb21lb25lIHdpdGggYSBsb25nIGhpc3Rvcnkgb2YgYnVpbGRpbmcs
IGluZmx1ZW5jaW5nLCBhbmQgdXNpbmcgbGlicmFyaWVzPGJyIGNsYXNzPSIiPg0KYW5kIHRoZWly
IEFQSSdzLCB0aGlzIGlzIG5vdCBlYXN5LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxi
ciBjbGFzcz0iIj4NCkJpbmFyeSBjb21wYXRpYmlsaXR5IGlzIGRpZmZpY3VsdCwgYW5kIHJlcXVp
cmVzIG1haW50YWluaW5nIGxlZ2FjeTxiciBjbGFzcz0iIj4NCnZlcnNpb25zIG9mIGludGVyZmFj
ZXMgd2l0aCBjcm9zcy1wbGF0Zm9ybSBzeW1ib2wgdmVyc2lvbmluZyBhbmQ8YnIgY2xhc3M9IiI+
DQpyZWxhdGVkIG1hZ2ljIHRoYXQgdHJhbnNjZW5kcyB0aGUgcmVsZWFzZSBlbmdpbmVlcmluZyBj
eWNsZXM8YnIgY2xhc3M9IiI+DQphdmFpbGFibGUgdG8gT3BlblNTTCBhdCB0aGlzIHRpbWUuPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhdCBzYWlkLCBzb3VyY2UgY29tcGF0aWJpbGl0
eSBpcyBhIGZhaXJseSByZWFzb25hYmxlIHJlcXVpcmVtZW50LjxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NCkJ5IGFuZCBsYXJnZSBmb3IgYXBwbGljYXRpb25zIGRvaW5nIHNpbXBsZSB0aGlu
Z3MsIE9wZW5TU0wgcmVtYWluczxiciBjbGFzcz0iIj4NCnNvdXJjZSBjb21wYXRpYmxlIGFsbCB0
aGUgd2F5IGZyb20gMC45LjVhIHRvICZxdW90O21hc3RlciZxdW90OyAoc29vbiB0byBiZTxiciBj
bGFzcz0iIj4NCjEuMS4wKS4gJm5ic3A7UG9zdGZpeCwgd2hpY2ggdXNlcyBPcGVuU1NMIGluIGEg
cmF0aGVyIG1vcmUgc29waGlzdGljYXRlZDxiciBjbGFzcz0iIj4NCndheSwgaGFzIHJlbGF0aXZl
bHkgbWlub3IgYWRhcHRhdGlvbnMgdG8gZGVhbCB3aXRoIHNvdXJjZSBjb21wYXRpYmlsaXR5PGJy
IGNsYXNzPSIiPg0KY2hhbmdlcyBmcm9tIHRoZSAwLjkuNyB0aW1lLWZyYW1lIHRvIHRoZSBwcmVz
ZW50ICh3ZSd2ZSBkcm9wcGVkPGJyIGNsYXNzPSIiPg0Kc3VwcG9ydCBmb3Igb2xkZXIgT3BlblNT
TCB2ZXJzaW9ucyB0aGF0IHdhcyBwcmVzZW50IGluIGVhcmxpZXI8YnIgY2xhc3M9IiI+DQpQb3N0
Zml4IHJlbGVhc2VzLCBvdGhlcndpc2UgdGhhdCB3b3VsZCBiZSAwLjkuNSB0byB0aGUgcHJlc2Vu
dCkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRW5hYmxpbmcgVExTIDEuMiAoaW4gT3Bl
blNTTCAxLjAuMSkgY2F1c2VkIG5vIGZ1bmRhbWVudGFsIHByb2JsZW1zPGJyIGNsYXNzPSIiPg0K
Zm9yIFBvc3RmaXgsIGl0IGxhcmdlbHkgY29udGludWVkIHRvIHdvcmsgYXMtaXMuICZuYnNwO0lJ
UkMgdGhlIHBhZGRpbmc8YnIgY2xhc3M9IiI+DQpleHRlbnNpb24gd2FzIG5lZWRlZCBpbiAxLjAu
MWcgdG8gZGVhbCB3aXRoIGludGVyb3BlcmFiaWxpdHkgd2l0aDxiciBjbGFzcz0iIj4NCnNvbWUg
SXJvblBvcnQgc3lzdGVtcyB0aGF0IGhhZCBpc3N1ZXMgd2l0aCBsYXJnZSBjbGllbnQgSEVMTE88
YnIgY2xhc3M9IiI+DQptZXNzYWdlcyBzb2x2ZWQgYnkgcGFkZGluZy4gJm5ic3A7VGhlIG11Y2gg
bGFyZ2VyIGxpc3Qgb2YgY2lwaGVyc3VpdGVzPGJyIGNsYXNzPSIiPg0KYWxzbyBjYXVzZWQgcGFp
biB3aXRoIHNvbWUgcmF0aGVyIGRhdGVkIE1pY3Jvc29mdCBFeGNoYW5nZSAyMDAzPGJyIGNsYXNz
PSIiPg0Kc2VydmVycyB0aGF0IHdlcmUgc3RpbGwgaW4gdXNlLiAmbmJzcDtCdXQgb24gdGhlIHdo
b2xlIHRoZSB0cmFuc2l0aW9uPGJyIGNsYXNzPSIiPg0KanVzdCB3b3JrZWQsIGFzIGl0IHNob3Vs
ZCBoYXZlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNvIHJlY29tcGlsaW5nIGEgcGFj
a2FnZSBhZ2FpbnN0IGFuIE9wZW5TU0wgdGhhdCBzdXBwb3J0cyBUTFMgMS4zLDxiciBjbGFzcz0i
Ij4NCmFuZCBmaXhpbmcgb2NjYXNpb25hbCBpc3N1ZXMgd2l0aCBub3cgb3BhcXVlIGRhdGEgc3Ry
dWN0dXJlcyBoaWRkZW48YnIgY2xhc3M9IiI+DQpiZWhpbmQgbmV3IGFjY2Vzc29ycywgc2hvdWxk
IGJlIHN1ZmZpY2llbnQgZm9yIGEgbGFyZ2VseSB1bmNoYW5nZWQ8YnIgY2xhc3M9IiI+DQphcHBs
aWNhdGlvbiB0byB1c2UgVExTIDEuMyB3aXRoIG5vIGV4cGxpY2l0IGNvZGUgY2hhbmdlcyB0byBk
byBzby48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjbGFzcz0iIj5JIHN0aWxsIHdhbnQgYSBwb255LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90
ZT4NCjxiciBjbGFzcz0iIj4NCkkgZXhwZWN0IHRvIHJlcG9ydCB0aGF0IFBvc3RmaXggd29ya3Mg
YXMtaXMgd2hlbiBPcGVuU1NMIGlzIHJlbGVhc2VkPGJyIGNsYXNzPSIiPg0Kd2l0aCBUTFMgMS4z
LiAmbmJzcDtUaGlzIGlzIG5vdCBhbiB1bnJlYXNvbmFibGUgZXhwZWN0YXRpb24uPGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYgVExTIDEuMyBkb2VzIG5vdCBpbnRlcm9wZXJhdGUgd2l0
aCBvcHBvcnR1bmlzdGljIFRMUyBjbGllbnRzPGJyIGNsYXNzPSIiPg0Kd2hlbiBzZXJ2ZXJzIGFy
ZSBjb25maWd1cmVkIHdpdGggcHJlLWV4aXN0aW5nIHNlbGYtc2lnbmVkIFNIQS0xPGJyIGNsYXNz
PSIiPg0KY2VydGlmaWNhdGVzLCB0aGVuIElNSE8gdGhlIHNwZWNpZmljYXRpb24gaXMgYnJva2Vu
LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklmIFRMUyAxLjMgcGlnLWhlYWRlZGx5IGZv
cmJpZHMgc2VuZGluZyBub24tcm9vdCBTSEEtMSBjZXJ0cywgYW5kPGJyIGNsYXNzPSIiPg0KT3Bl
blNTTCB3aXRoIFRMUyAxLjMgbmVnb3RpYXRlcyBUTFMgMS4zIHdoZW4gYSBzZXJ2ZXIgaGFzIG9u
bHkgYTxiciBjbGFzcz0iIj4NCkNBLWlzc3VlZCBjZXJ0aWZpY2F0ZSBzaWduZWQgd2l0aCBTSEEt
MSwgdGhlbiBPcGVuU1NMIGlzIGJyb2tlbiw8YnIgY2xhc3M9IiI+DQpmb3IgaXQgc2hvdWxkIHRo
ZW4gaGF2ZSB3b3JrZWQgYXJvdW5kIHRoZSBzcGVjaWZpY2F0aW9uIGJyYWluLWRhbWFnZTxiciBj
bGFzcz0iIj4NCmJ5IHNlbGVjdGluZyBUTFMgMS4yIChwcmVzdW1hYmx5IHRoZSBjbGllbnQgc3Rp
bGwgc3VwcG9ydHMgdGhhdCkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSBwZXJw
bGV4ZWQgdGhhdCBmb2xrcyBkZXNwZXJhdGVseSB3YW50IHRoYXQgc2VydmVyIHdpdGggdGhhdDxi
ciBjbGFzcz0iIj4NClNIQS0xIGNlcnQgdG8gbm90IGJlIGFibGUgdG8gdXNlIFRMUyAxLjMuICZu
YnNwO1N1cmVseSwgdGhlIGRlY2lzaW9uIHRvPGJyIGNsYXNzPSIiPg0Kbm90IHRydXN0IHRoYXQg
Y2VydCAoaWYgY2VydHMgYXJlIGJlaW5nIGNoZWNrZWQgYXQgYWxsKSBiZWxvbmdzIGluPGJyIGNs
YXNzPSIiPg0KdGhlIGNsaWVudC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQcm92aWRl
ZCB0aGF0IHdlYWsgc2VsZi1zaWduYXR1cmVzIGFyZSBub3QgcHJvc2NyaWJlZCwgSSBhbSByZXNp
Z25lZDxiciBjbGFzcz0iIj4NCnRvICZxdW90O2NvbWUgd2hhdCBtYXkmcXVvdDsgaWYgbm9ib2R5
IGVsc2UgdGhpbmtzIHRoYXQgcHJvcGVyIHNlZ3JlZ2F0aW9uPGJyIGNsYXNzPSIiPg0Kb2YgZHV0
aWVzIGlzIGltcG9ydGFudCwgYW5kIHRoYXQgcHV0dGluZyB1cCBzb21lIG5lZWRsZXNzIHJvYWRi
bG9ja3M8YnIgY2xhc3M9IiI+DQp0byBUTFMgMS4zIHVzZSBpcyB0aGUgcHJpY2Ugb2YgJnF1b3Q7
cHJvZ3Jlc3MmcXVvdDsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNz
PSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl
Ij48L3NwYW4+VmlrdG9yLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KVExTIG1h
aWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIGNs
YXNzPSIiPlRMU0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3RsczxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A919847F0A85453F93D995A2258DCBCEakamaicom_--


From nobody Fri Oct 23 09:28:42 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915141A6FF0 for ; Fri, 23 Oct 2015 09:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.622
X-Spam-Level: *
X-Spam-Status: No, score=1.622 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 5CpsGMVgstW2 for ; Fri, 23 Oct 2015 09:28:37 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 243771A6F83 for ; Fri, 23 Oct 2015 09:28:36 -0700 (PDT)
Received: by lfbn126 with SMTP id n126so55024172lfb.2 for ; Fri, 23 Oct 2015 09:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cinkciarz.pl; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yKu4NBTEvCR9k4XPlfl7hyriKvJZkatRP+rSHS+G5s4=; b=GJhJoEZd85FphftKWcBt/10/UQ0Zd9FFnPbfhxRgSsPPCYtZ9IffGC27Hg+hLGYi8I D/MjFICIlXJtoA3k45IAeg2Kh0umbQqJ+ivyKJU1FIT4CloVoTpZ3YEa896aoqO6HjfS AM22IfrcJL1744dVfe0AFnAu+Raol04EqQ+iw=
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:date :message-id:subject:from:to:cc:content-type; bh=yKu4NBTEvCR9k4XPlfl7hyriKvJZkatRP+rSHS+G5s4=; b=GkXC5R9nUhK7hJp8oqq7VzpfstZqynwbqulsb2AkTc2B4DLCZTNvg82vVYue0RwcQ+ wJzkiyatG/6uaAQ0Ljzle5ggOT9N+fEXhX61srtkDJucxb2yiBzP8Zc4MmqQY3at2ZgB D+q/n7YuD/YJvaArJ0Mj6gpKKH4ZH9KlXMOxDpUPZIDRfoKO+N5dtoCgTIOm/wzG1EeO CgGijMel/bk89C/E2YKJZBo1Posb8SeIsKj84Y9qimBWxIiSG+cUzx6eKrYe2C6SWECZ xYSwz1touaewST6YRzjOOWI0yeVd/yLT/PAIOAguWFxrUPT83WbvCyJEThrFZcYAGwI2 vfQg==
X-Gm-Message-State: ALoCoQkrtbkzPxDGGL4/RKHLsUP+loewe26P0kpvA9sTPa4LxPE8TzhYuTV592WsNHSezp7FEJIQ
MIME-Version: 1.0
X-Received: by 10.112.205.231 with SMTP id lj7mr11574366lbc.57.1445617715120;  Fri, 23 Oct 2015 09:28:35 -0700 (PDT)
Received: by 10.25.20.206 with HTTP; Fri, 23 Oct 2015 09:28:34 -0700 (PDT)
In-Reply-To: 
References: <20151022142443.GS15070@mournblade.imrryr.org> <56290C8E.9040409@akamai.com>  <3d2bf2837f3d49768b8d7847794fde0b@ustx2ex-dag1mb3.msg.corp.akamai.com> <56292395.2050606@akamai.com>  <5629287D.9010905@akamai.com> <7a963a9071a74b5ca4dbe100c1e96ac9@ustx2ex-dag1mb3.msg.corp.akamai.com>   <20151023043358.GW15070@mournblade.imrryr.org> 
Date: Fri, 23 Oct 2015 18:28:34 +0200
Message-ID: 
From: =?UTF-8?Q?Micha=C5=82_Staruch?= 
To: "Short, Todd" 
Content-Type: multipart/alternative; boundary=001a11c3c3486424ea0522c81ab2
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Oct 2015 16:28:41 -0000

--001a11c3c3486424ea0522c81ab2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

According to the CA/Browser Forum Baseline Requirements
 after 1 January
2016 CAs MUST NOT issue any new Subscriber or Subordinate CA certificates
using SHA-1, so we shouldn't see any new certificates with SHA-1 after this
date.

Another thing is cost of SHA-1 collision attacks - currently it's at $100K
level (see the Freestart collision on full SHA-1
 paper), so I think it's pretty much the
time when we should say that SHA-1 MUST NOT be used in upcoming TLS
versions.


On Fri, Oct 23, 2015 at 3:55 PM, Short, Todd  wrote:

> Fundamentally, it is up to the client (or server when doing Client
> Authentication) to choose whether or not to trust a received certificate
> chain.
> I am all for deprecating SHA-1 (and MD-5 and MD-2, and other weaker
> message digests), but =E2=80=9CI=E2=80=99m not sure it=E2=80=99s a good i=
dea=E2=80=9D (SM) to force the
> issue in a new version of the protocol that is dependent on external spec=
s
> (e.g. X.509) which permit those message digests.
> If we want to promote TLSv1.3 and attempt to have faster adoption than
> TLSv1.2, we can=E2=80=99t shoot ourselves in the foot and not work with a=
 large
> majority of servers out there still using old certificates.
> Which by the way, do expire, and subsequently upon renewal, are signed
> with stronger message digests. The issue is with the old, ancient roots,
> that still use legacy message digest algorithms, and are less easy to
> update. But it can be done!
> I think the onus is really on the library authors to validate the chain,
> but report anomalies such as SHA-1 in the chain, or a MD5-self-signed-roo=
t.
> The applications are then free to accept the chain or not. Chrome has
> already done this, and adding support to libraries to make this the defau=
lt
> or easier to detect makes it that much easier to deprecate SHA1.
> In summary, I=E2=80=99m in the SHOULD NOT use SHA-1 camp, rather than the=
 MUST NOT.
> --
> -Todd Short
> // tshort@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Oct 23, 2015, at 12:33 AM, Viktor Dukhovni 
> wrote:
>
> On Thu, Oct 22, 2015 at 06:40:25PM +0000, Salz, Rich wrote:
>
> Most applications want a simple API that hides all the complexities of
> TLS. If OpenSSL had done that, then it would be easy to see how enabling
> 1.2 won't cause problems for those apps which said "you take care of it".
>
>
> As someone with a long history of building, influencing, and using
> libraries
> and their API's, this is not easy.
>
>
> Binary compatibility is difficult, and requires maintaining legacy
> versions of interfaces with cross-platform symbol versioning and
> related magic that transcends the release engineering cycles
> available to OpenSSL at this time.
>
> That said, source compatibility is a fairly reasonable requirement.
>
> By and large for applications doing simple things, OpenSSL remains
> source compatible all the way from 0.9.5a to "master" (soon to be
> 1.1.0).  Postfix, which uses OpenSSL in a rather more sophisticated
> way, has relatively minor adaptations to deal with source compatibility
> changes from the 0.9.7 time-frame to the present (we've dropped
> support for older OpenSSL versions that was present in earlier
> Postfix releases, otherwise that would be 0.9.5 to the present).
>
> Enabling TLS 1.2 (in OpenSSL 1.0.1) caused no fundamental problems
> for Postfix, it largely continued to work as-is.  IIRC the padding
> extension was needed in 1.0.1g to deal with interoperability with
> some IronPort systems that had issues with large client HELLO
> messages solved by padding.  The much larger list of ciphersuites
> also caused pain with some rather dated Microsoft Exchange 2003
> servers that were still in use.  But on the whole the transition
> just worked, as it should have.
>
> So recompiling a package against an OpenSSL that supports TLS 1.3,
> and fixing occasional issues with now opaque data structures hidden
> behind new accessors, should be sufficient for a largely unchanged
> application to use TLS 1.3 with no explicit code changes to do so.
>
> I still want a pony.
>
>
> I expect to report that Postfix works as-is when OpenSSL is released
> with TLS 1.3.  This is not an unreasonable expectation.
>
> If TLS 1.3 does not interoperate with opportunistic TLS clients
> when servers are configured with pre-existing self-signed SHA-1
> certificates, then IMHO the specification is broken.
>
> If TLS 1.3 pig-headedly forbids sending non-root SHA-1 certs, and
> OpenSSL with TLS 1.3 negotiates TLS 1.3 when a server has only a
> CA-issued certificate signed with SHA-1, then OpenSSL is broken,
> for it should then have worked around the specification brain-damage
> by selecting TLS 1.2 (presumably the client still supports that).
>
> I am perplexed that folks desperately want that server with that
> SHA-1 cert to not be able to use TLS 1.3.  Surely, the decision to
> not trust that cert (if certs are being checked at all) belongs in
> the client.
>
> Provided that weak self-signatures are not proscribed, I am resigned
> to "come what may" if nobody else thinks that proper segregation
> of duties is important, and that putting up some needless roadblocks
> to TLS 1.3 use is the price of "progress".
>
> --
> Viktor.
>
> _______________________________________________
> 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

Pozdrawiam | Best Regards

Micha=C5=82 Staruch | Information Security Officer

ul. Sienkiewicza 9, 65-001 Zielona G=C3=B3ra

msta@cinkciarz.pl

Find us on Bloomberg CKPL 
[image: Cinkciarz.pl Sp. z.o.o] 

*Cinkciarz.pl Sp. z o.o.*

*Siedziba:* ul. Sienkiewicza 9, 65-001 Zielona G=C3=B3ra

*Biuro PL:* Al. Jerozolimskie 123A, 00-965 Warszawa

*Biuro UK:* The Broadgate Tower, 20 Primrose Street, London EC2A 2EW

*Biuro USA:* 401 North Michigan Avenue, Chicago, Illinois, 60611

*Sekretariat:* +48 726 666 655 | *Infolinia:* +48 68 410 99 50

biuro@cinkciarz.pl | https://cinkciarz.pl

KRS 0000364722 | Kapita=C5=82 zak=C5=82adowy 23.263.500 z=C5=82

REGON 080465538 | NIP 9291830388

Audited by: Grant Thornton

[image: Oficjalny sponsor Reprezentacji Polski w pi=C5=82ce no=C5=BCnej]

Tre=C5=9B=C4=87 tej wiadomo=C5=9Bci zawiera informacje poufne, przeznaczone=
 tylko dla
adresata. Udost=C4=99pnianie, ujawnianie, powielanie, rozpowszechnianie b=
=C4=85d=C5=BA
powo=C5=82ywanie si=C4=99 na jakikolwiek jej fragment przez inne osoby jest
zabronione. W razie przypadkowego otrzymania tej wiadomo=C5=9Bci prosimy o
powiadomienie o tym nadawcy oraz trwa=C5=82e jej usuni=C4=99cie. Informacje=
 zawarte w
tej wiadomo=C5=9Bci mog=C4=85 by=C4=87 obj=C4=99te tajemnic=C4=85 zawodow=
=C4=85 lub chronione innymi
przepisami prawnymi. Nadawca nie bierze odpowiedzialno=C5=9Bci za jakiekolw=
iek
szkody spowodowane wirusem komputerowym przetransmitowanym w tej
wiadomo=C5=9Bci.  Pogl=C4=85dy i opinie przedstawione w tej wiadomo=C5=9Bci=
 s=C4=85 wy=C5=82=C4=85cznie
pogl=C4=85dami i opiniami jej autora i niekoniecznie reprezentuj=C4=85 pogl=
=C4=85dy i
opinie firmy.

This is a confidential e-mail intended solely for the use of the entity or
the individual to whom it is addressed. Unauthorized publication, use,
dissemination or disclosure of this message, either in whole or in part is
strictly prohibited. If you have received this message in error please send
it back to the sender and delete it. It may also be privileged or otherwise
protected by work product immunity or other legal rules. The company
accepts no liability for any damage caused by any virus transmitted by this
e-mail. Any views or opinions presented in this e-mail are solely those of
the author and do not necessarily represent those of the company.

--001a11c3c3486424ea0522c81ab2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


According to the CA/Browser Forum Baseline Requirements after 1=
 January 2016 CAs MUST NOT issue any new Subscriber or Subordinate CA certi=
ficates using SHA-1, so we shouldn't see any new certificates with SHA-=
1 after this date.

Another thing is cost of SHA-1 collision attacks =
- currently it's at $100K level (see the Freestart collision on full SHA-1 paper), so I think it&=
#39;s pretty much the time when we should say that SHA-1 MUST NOT be used i=
n upcoming TLS versions.


On Fri, Oct 23, 2015 at 3:55 PM, Short, Todd <tshort@=
akamai.com> wrote:







Fundamentally, it is up to the client (or server when doing Client Aut=
hentication) to choose whether or not to trust a received certificate chain=
.


I am all for deprecating SHA-1 (and MD-5 and MD-2, and other weaker me=
ssage digests), but =E2=80=9CI=E2=80=99m not sure it=E2=80=99s a good idea=
=E2=80=9D (SM) to force the issue in a new version of the protocol that is =
dependent on external specs (e.g. X.509) which permit those
 message digests.


If we want to promote TLSv1.3 and attempt to have faster adoption than=
 TLSv1.2, we can=E2=80=99t shoot ourselves in the foot and not work with a =
large majority of servers out there still using old certificates.


Which by the way, do expire, and subsequently upon renewal, are signed=
 with stronger message digests. The issue is with the old, ancient roots, t=
hat still use legacy message digest algorithms, and are less easy to update=
. But it can be done!


I think the onus is really on the library authors to validate the chai=
n, but report anomalies such as SHA-1 in the chain, or a MD5-self-signed-ro=
ot. The applications are then free to accept the chain or not. Chrome has a=
lready done this, and adding
 support to libraries to make this the default or easier to detect makes it=
 that much easier to deprecate SHA1.


In summary, I=E2=80=99m in the SHOULD NOT use SHA-1 camp, rather than =
the MUST NOT.








--


-Todd Short



// "One if by land, two if by sea, three if by the Internet."=
;














On Oct 23, 2015, at 12:33 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrot=
e:




On Thu, Oct 22, 2015 at 06:40:25PM +0000, Salz, Rich wrote:






Most applications want a simple API that hides al=
l the complexities of

TLS. If OpenSSL had done that, then it would be easy to see how enabling
1.2 won't cause problems for those apps which said "you take care =
of it".





As someone with a long history of building, influencing, and using librarie=
s

and their API's, this is not easy.





Binary compatibility is difficult, and requires maintaining legacy

versions of interfaces with cross-platform symbol versioning and

related magic that transcends the release engineering cycles

available to OpenSSL at this time.



That said, source compatibility is a fairly reasonable requirement.



By and large for applications doing simple things, OpenSSL remains

source compatible all the way from 0.9.5a to "master" (soon to be=


1.1.0).=C2=A0 Postfix, which uses OpenSSL in a rather more sophisticated
way, has relatively minor adaptations to deal with source compatibility

changes from the 0.9.7 time-frame to the present (we've dropped

support for older OpenSSL versions that was present in earlier

Postfix releases, otherwise that would be 0.9.5 to the present).



Enabling TLS 1.2 (in OpenSSL 1.0.1) caused no fundamental problems

for Postfix, it largely continued to work as-is.=C2=A0 IIRC the padding

extension was needed in 1.0.1g to deal with interoperability with

some IronPort systems that had issues with large client HELLO

messages solved by padding.=C2=A0 The much larger list of ciphersuites

also caused pain with some rather dated Microsoft Exchange 2003

servers that were still in use.=C2=A0 But on the whole the transition

just worked, as it should have.



So recompiling a package against an OpenSSL that supports TLS 1.3,

and fixing occasional issues with now opaque data structures hidden

behind new accessors, should be sufficient for a largely unchanged

application to use TLS 1.3 with no explicit code changes to do so.




I still want a pony.





I expect to report that Postfix works as-is when OpenSSL is released

with TLS 1.3.=C2=A0 This is not an unreasonable expectation.



If TLS 1.3 does not interoperate with opportunistic TLS clients

when servers are configured with pre-existing self-signed SHA-1

certificates, then IMHO the specification is broken.



If TLS 1.3 pig-headedly forbids sending non-root SHA-1 certs, and

OpenSSL with TLS 1.3 negotiates TLS 1.3 when a server has only a

CA-issued certificate signed with SHA-1, then OpenSSL is broken,

for it should then have worked around the specification brain-damage

by selecting TLS 1.2 (presumably the client still supports that).



I am perplexed that folks desperately want that server with that

SHA-1 cert to not be able to use TLS 1.3.=C2=A0 Surely, the decision to

not trust that cert (if certs are being checked at all) belongs in

the client.



Provided that weak self-signatures are not proscribed, I am resigned

to "come what may" if nobody else thinks that proper segregation<=
br>
of duties is important, and that putting up some needless roadblocks

to TLS 1.3 use is the price of "progress".



-- 

Viktor.



_______________________________________________

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





-- 

		
=20
			

				
Pozdrawiam | Best Regards

				
Micha=C5=82 Staruch | Information Security Offi=
cer

				
ul. Sienkiewicza 9, 65-001 Zielona G=C3=B3ra
				
msta@cinkciarz.pl

				
Find us on Bloomberg CKPL <G=
O>

			

		=09
			

				3D"Cinkciarz.pl
			

		=09
			

				
Cinkciarz.pl Sp. z o.o.

				
Siedziba: ul. Sienkiewicza 9, 65-001 Zie=
lona G=C3=B3ra 

				
Biuro PL: Al. Jerozolimskie 123A, 00-965=
 Warszawa 

				
Biuro UK: The Broadgate Tower, 20 Primro=
se Street, London EC2A 2EW

				
Biuro USA: 401 North Michigan Avenue, Ch=
icago, Illinois, 60611

				
Sekretariat: +48 726 666 655 | Infoli=
nia: +48 68 410 99 50

				
biuro@cinkciarz.pl | https://cinkciarz.pl

			

		=09
			

				
KRS 0000364722 | Kapita=C5=82 zak=C5=82adowy 23=
.263.500 z=C5=82

				
REGON 080465538 | NIP 9291830388

				
Audited by: Grant Thornton

			

		=09
		=09
		=09
			

				
3D"Oficjalny

			

		=09
			

				
Tre=C5=9B=C4=87 tej wiadomo=C5=9Bci zawiera inf=
ormacje=20
poufne, przeznaczone tylko dla adresata. Udost=C4=99pnianie, ujawnianie,=20
powielanie, rozpowszechnianie b=C4=85d=C5=BA powo=C5=82ywanie si=C4=99 na j=
akikolwiek jej=20
fragment przez inne osoby jest zabronione. W razie przypadkowego=20
otrzymania tej wiadomo=C5=9Bci prosimy o powiadomienie o tym nadawcy oraz=
=20
trwa=C5=82e jej usuni=C4=99cie. Informacje zawarte w tej wiadomo=C5=9Bci mo=
g=C4=85 by=C4=87=20
obj=C4=99te tajemnic=C4=85 zawodow=C4=85 lub chronione innymi przepisami pr=
awnymi.=20
Nadawca nie bierze odpowiedzialno=C5=9Bci za jakiekolwiek szkody spowodowan=
e=20
wirusem komputerowym przetransmitowanym w tej wiadomo=C5=9Bci.=C2=A0 Pogl=
=C4=85dy i=20
opinie przedstawione w tej wiadomo=C5=9Bci s=C4=85 wy=C5=82=C4=85cznie pogl=
=C4=85dami i opiniami=20
jej autora i niekoniecznie reprezentuj=C4=85 pogl=C4=85dy i opinie firmy.
				
This is a confidential e-mail intended=20
solely for the use of the entity or the individual to whom it is=20
addressed. Unauthorized publication, use, dissemination or disclosure of
 this message, either in whole or in part is strictly prohibited. If you
 have received this message in error please send it back to the sender=20
and delete it. It may also be privileged or otherwise protected by work=20
product immunity or other legal rules. The company accepts no liability=20
for any damage caused by any virus transmitted by this e-mail. Any views
 or opinions presented in this e-mail are solely those of the author and
 do not necessarily represent those of the company. 

			

		

=09





--001a11c3c3486424ea0522c81ab2--


From nobody Fri Oct 23 13:05:33 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413531A8AF2 for ; Fri, 23 Oct 2015 13:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 5BusiNzM8tRb for ; Fri, 23 Oct 2015 13:05:30 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002: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 AAA371A8AEC for ; Fri, 23 Oct 2015 13:05:30 -0700 (PDT)
Received: by yknn9 with SMTP id n9so131383208ykn.0 for ; Fri, 23 Oct 2015 13:05: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:content-type; bh=WaYyKEzx4Pn3yDIkhCgD+EjPzvRU5MkS/z0tFSMxRxY=; b=UEFEPmofLuz8kIM3PhylvDAzRYWL8N8XEoKtax/80H7oaPdjM0UcROqNyWQ/SEIr23 8u6xNUSpkN+K2DL+/NMhJhzZ3BQOneCguyvAAR/JGi3r3ZOaT89REfTxCMAY+J/KfWdR 93rmokGPYtcQdlqvWl8Gchh7MKbcIzmbThLVJuP1qpdA+0zy0rSXnIJzGJC/N5F15/Jh DmsrzAcnQhyq+OZOWX7XaVQXTNDI2+mW+fca69FSFA559mCeQDvaD2ETgQe39hK84ucE Ng/q6c4a6fFM4gon3j68ukDXobB9QQdaQleGwRi/XTtkZi8+VRR1J2YJJl/hGoxwb6hc SD3A==
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-type; bh=WaYyKEzx4Pn3yDIkhCgD+EjPzvRU5MkS/z0tFSMxRxY=; b=UFW91buEXXUB/vQT72EAU1NlFUchOeeob6OUnCMhy6LLxt7Wy+BDC5oJWfVI8KfGMy osiNZRJz9eMBw1FIHZYJIL1M5DV1kEGhF/tQNCt4ezhekMA15QODVqycfu/f4YGKJet+ er9Sb438MuukNcQemYk4zpxOUwHPhE9h32fvt3SoqdGD9SvD+uT/edDAxkLgcl/7diHQ GPM8gttfWIhp8oO2isIn/m7X87FRBvrO+BLrL5ktnTr3SPiJy5uHUvuimI977sEQcd7Q Qd4q2mQuJ3CrPZMgTFv1DKLTz/tBsxsLgxqjE5PohgoqLdmSs+B4g9HkeZ/J9JCulZoS Yahw==
X-Gm-Message-State: ALoCoQkTZS9/9XcJ7V0mezUZivtWaSq0oCSho6LgH7uqgEMTjjgGirL6KBSzwv1W3Pu5OW0e7X31
X-Received: by 10.13.224.2 with SMTP id j2mr18852811ywe.165.1445630729999; Fri, 23 Oct 2015 13:05:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Fri, 23 Oct 2015 13:04:50 -0700 (PDT)
From: Eric Rescorla 
Date: Fri, 23 Oct 2015 13:04:50 -0700
Message-ID: 
To: "tls@ietf.org" ,  draft-jay-tls-omit-aead-explicit-nonce-extension@tools.ietf.org
Content-Type: multipart/alternative; boundary=94eb2c074626235c740522cb221f
Archived-At: 
Subject: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 23 Oct 2015 20:05:32 -0000

--94eb2c074626235c740522cb221f
Content-Type: text/plain; charset=UTF-8

I took a quick look at this draft and IMO it is unnecessary, for two
reasons:

1. There is already no requirement that you have an explicit nonce. RFC5246
merely requires that you specify the length of the explicit nonce, but that
length can be 0, as it is in the ChaCha/Poly drafts. So, rather than build
an extension it would be better to just define a new cipher suite if you
think
this is important.

2. TLS 1.3 already omits the explicit nonce entirely.

-Ekr

--94eb2c074626235c740522cb221f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I took a quick look at this draft and IMO it is unnecessar=
y, for two reasons:

1. There is already no requirement t=
hat you have an explicit nonce. RFC5246
merely requires that you =
specify the length of the explicit nonce, but that
length can be =
0, as it is in the ChaCha/Poly drafts. So, rather than build
an e=
xtension it would be better to just define a new cipher suite if you think<=
/div>
this is important.

2. TLS 1.3 already om=
its the explicit nonce entirely.

-Ekr




--94eb2c074626235c740522cb221f--


From nobody Fri Oct 23 14:06:07 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B46E1ACD49 for ; Fri, 23 Oct 2015 14:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vimQ6XpmvjG for ; Fri, 23 Oct 2015 14:06:03 -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 42D481AC43C for ; Fri, 23 Oct 2015 14:05:59 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 741934423A for ; Fri, 23 Oct 2015 23:05:57 +0200 (CEST)
X-purgate-ID: 152705::1445634357-00001EB9-DD594F1D/0/0
X-purgate-size: 1049
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 mail05.wdf.sap.corp (Postfix) with ESMTP id 63F2244238 for ; Fri, 23 Oct 2015 23:05:57 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5ABCE1A321; Fri, 23 Oct 2015 23:05:57 +0200 (CEST)
In-Reply-To: <20151023043358.GW15070@mournblade.imrryr.org>
To: tls@ietf.org
Date: Fri, 23 Oct 2015 23:05:57 +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: <20151023210557.5ABCE1A321@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Oct 2015 21:06:05 -0000

Viktor Dukhovni wrote:
> On Thu, Oct 22, 2015 at 06:40:25PM +0000, Salz, Rich wrote:
>>> 
>>> Most applications want a simple API that hides all the complexities of
>>> TLS. If OpenSSL had done that, then it would be easy to see how enabling
>>> 1.2 won't cause problems for those apps which said "you take care of it".
>> 
>> As someone with a long history of building, influencing, and using libraries
>> and their API's, this is not easy.
> 
> Binary compatibility is difficult, and requires maintaining legacy
> versions of interfaces with cross-platform symbol versioning and
> related magic that transcends the release engineering cycles
> available to OpenSSL at this time.

Binary compatibility is actually fairly easy.  We've been providing
it for several APIs on several platforms for the last 20 years.

What is a pain in the butt is backwards-incompatible _specifications_.
TLSv1.2 contains a few places of severe breakage, and dealing with
these in a backwards-compatible fashion is what is difficult.


-Martin


From nobody Fri Oct 23 14:27:05 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81571B2A40 for ; Fri, 23 Oct 2015 14:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level: 
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCPaAq86H7dD for ; Fri, 23 Oct 2015 14:27:02 -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 3664D1B2A3D for ; Fri, 23 Oct 2015 14:27:02 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 AE9762A023; Fri, 23 Oct 2015 23:27:00 +0200 (CEST)
X-purgate-ID: 152705::1445635620-00001EB9-8DE52EE0/0/0
X-purgate-size: 1203
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 mail05.wdf.sap.corp (Postfix) with ESMTP id A145B442FF; Fri, 23 Oct 2015 23:27:00 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 971301A321; Fri, 23 Oct 2015 23:27:00 +0200 (CEST)
In-Reply-To: 
To: Martin Thomson 
Date: Fri, 23 Oct 2015 23:27:00 +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: <20151023212700.971301A321@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Oct 2015 21:27:03 -0000

Martin Thomson wrote:
> On 21 October 2015 at 12:56, Viktor Dukhovni  wrote:
>> Each peer MUST try to send a chain that matches an advertised
>> signature algorithm if it has a choice of chains, but otherwise
>> MUST send whatever it has.
> 
> Do, or do not.  There is no try.
> 
> It's not like any of this is ambiguous in any way.

This is NOT about digitally_signed, which the server newly creates
himself, and therefore has a choice.

Very few servers, if any, can (or will) create their own server
certificate and chain certificates above on the fly during a TLS
handshake.  Instead, server's will have to choose their server
certificate & chain from whatever the server admin has previously
configured.

So similar to TLS extension SNI, the server can only use the signature
algorithms for guidance finding the best possible match for the clients
conveyed preferences.  Ultimately, it is up to the client to decide
whether to accept an trust the server's certificate chain anyway.

Even for a certificate chain with matching algorithms, the client
may decide to abort because it doesn't trust the issuer of the
server's certificate.


-Martin


From nobody Sun Oct 25 08:35:20 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30B31B305C for ; Sun, 25 Oct 2015 08:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqZKawxYDHdO for ; Sun, 25 Oct 2015 08:35:16 -0700 (PDT)
Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 859911B305B for ; Sun, 25 Oct 2015 08:35:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 607BB21C3CE; Sun, 25 Oct 2015 17:35:14 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id maMPWsozVcqG; Sun, 25 Oct 2015 17:35:13 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id DAD3B5BC017; Sun, 25 Oct 2015 17:35:13 +0200 (EET)
Date: Sun, 25 Oct 2015 17:35:12 +0200
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20151025153511.GB1400@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.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] HelloRetryRequest and stateless reject
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 25 Oct 2015 15:35:18 -0000

On Wed, Oct 21, 2015 at 10:32:59AM -0700, Eric Rescorla wrote:
> 
> It seems natural to try to merge these mechanisms, but this raises
> the question of whether the handshake hashes should continue through
> the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104).
> The tension here is that you want to be able to have a stateless
> rejection (to avoid DoS in the DTLS scenario) but having things
> makes it much harder to analyze the handshake's resistance to
> downgrade attacks.

> Because the handshake hash is continued through the entire handshake,
> it's much easier to analyze the downgrade properties.

It is not just resistance to downgrade on protocol level. It is also
resistance to downgrade at implementation level. Which is nastier
to analyze.

(I found three different ways[1] to potentially cause downgrades against
careless implementaions, continuing hashes stops all of those).

> If this sounds good to people, I'll work up a PR for this, but
> really all it is is saying that you don't reset the hash and
> then a non-normative appendix describing stateless implementation
> techniques.
> 
> Thoughts? Does anyone see anything wrong with this?

Sounds good to me. Combines the resistance to downgrade continuing
hashes offers with the possibility of being stateless (for DTLS).


Aside: Has anyone looked at making DTLS 1.3? I would think the main
issue to look at would be how to arrange retransmissions (especially
with things like 0-RTT data, encrypted handshake and final handshake
flight).



[1] 
1) Tamper with ClientHello so server generates HRR causing the client
   to downgrade.
2) Tamper with HRR to cause the client to downgrade.
3) Insert ClientHello causing server to latch weak parameters, eat
   the HRR and replay ClientHello.


-Ilari


From nobody Tue Oct 27 05:50:20 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44281A886F for ; Tue, 27 Oct 2015 05:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 sGRj6Tgs_JOh for ; Tue, 27 Oct 2015 05:50:16 -0700 (PDT)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 B76661A886B for ; Tue, 27 Oct 2015 05:50:15 -0700 (PDT)
Received: by ykdr3 with SMTP id r3so216479165ykd.1 for ; Tue, 27 Oct 2015 05:50: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:content-type; bh=uXGekH/igubDPMfYx/fSWEOBTWTBndLsXKj4VUz4ZEc=; b=Jsr6oH4uG99RtGCunXZRqzBVNIIDiuqSbMJvFzcj+nOApkD2DSA36g4B/gigoYLMDM +EvN9Pq1dUKtP5iYD4b36tQDNnR4BHuajOrepENdUHsZHp1c56bbVVWG+7OM/8kw4P7E MC+NcIapGfXj1o5wKgtloIXyhE56rVnYj9hnx1P3mlqD7r2aVta8LWK9uNjIIJtvmBn9 R3yulflW/Buy/n8rqQWigRkHFI39UciBCHjPoDRYI6GkzAa88cinnRGqMWO9/KjATSCV ec9hUkVNSREM8j4zn5J0i0Dv8pW5Eod0B7Zx71SX3dTVUDpqtGsDlXRiz2ofUCZBoRFL fTiQ==
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-type; bh=uXGekH/igubDPMfYx/fSWEOBTWTBndLsXKj4VUz4ZEc=; b=DzYekB9KrUbGbdMeJqDIRwIZp00KYTjtCVWWuxY1N6yDrk0DC72m2owtfNy8kY+Kig hWMfDKCU/RI4/hsZTqk7Qk/5+12AfCltX8AGSNi1P0Q6SIuVWrZqmii0NUcTGwb0dUZi HYMulTHNpfyfHVdhGPqP6/QARUTcUtRMbomSnujXhRmbETa6AIUae3hGGUguAogNIF6g jttnM5HG2sRrUfa/6GKt8mSJtUbJsiAgurtF7c9KJq2j4meBeWJeX6oNEhaQAztAuZJB mHzYB9a4N20W21aWyrpjWGHNIGYJu5kXzEVKiMi10JWqgsa2m/XhoU1TuBGp6XfQgYP9 m4ew==
X-Gm-Message-State: ALoCoQnH8yFC8vtSv/GMM1j/odzsSfTnqIHyrheZro8CNpDORKUwPfyTX3rP9XtKQ7bVoEZHa5+S
X-Received: by 10.13.213.138 with SMTP id x132mr10846606ywd.223.1445950214966;  Tue, 27 Oct 2015 05:50:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Tue, 27 Oct 2015 05:49:35 -0700 (PDT)
In-Reply-To: 
References:         <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> 
From: Eric Rescorla 
Date: Tue, 27 Oct 2015 08:49:35 -0400
Message-ID: 
To: "David McGrew (mcgrew)" 
Content-Type: multipart/alternative; boundary=001a114fa914ed41130523158420
Archived-At: 
Cc: Adam Langley , "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 27 Oct 2015 12:50:19 -0000

--001a114fa914ed41130523158420
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thinking about this a little more:

If we ever change the nonce construction to have an explicit nonce or
otherwise
not depend on the RSN (e.g., something like SIV) we're going to be sad if
we don't have the RSN in the AD. Obviously, we'd also need to change the
text about the nonce construction, so it's not like you could drop in a
construction
like this, but it would be slightly easier to do if we already MACed the
RSN.

I'm not sure which side of the fence I'm on here. What do others think?

-Ekr


On Thu, Oct 22, 2015 at 10:07 AM, Eric Rescorla  wrote:

> Thanks for the quick response, David. I now agree with Martin and
> Adam that we should remove this.
>
> Chairs, I haven't seen any objections any reason I shouldn't make this
> change?
>
> -Ekr
>
>
> On Thu, Oct 22, 2015 at 6:59 AM, David McGrew (mcgrew) 
> wrote:
>
>>
>>
>> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
>> *Sent:* Thursday, October 22, 2015 9:33 AM
>> *To:* Adam Langley
>> *Cc:* Martin Thomson; tls@ietf.org; Hugo Krawczyk; David McGrew (mcgrew)
>> *Subject:* Re: [TLS] Version in record MAC
>>
>>
>>
>> I'm mostly convinced by this text in RFC 5116:
>>
>> http://tools.ietf.org/html/rfc5116#section-2.1
>>
>>
>>
>>    Because the authenticated decryption process
>>
>>    detects incorrect nonce values, no security failure will result if a
>>
>>    nonce is incorrectly reconstructed and fed into an authenticated
>>
>>    decryption operation.  Any nonce reconstruction method will need to
>>
>>    take into account the possibility of loss or reorder of ciphertexts
>>
>>    between the encryption and decryption processes.
>>
>> It would probably be worth checking with the cryptographers in the room.
>>
>> CCing Hugo and McGrew.
>>
>> -Ekr
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley 
>> wrote:
>>
>> On Monday, October 19, 2015, Martin Thomson 
>> wrote:
>>
>> On 19 October 2015 at 11:17, Eric Rescorla  wrote:
>> > Yeah, I think that's riding the nonce far too hard.
>>
>> On what basis?  Any change in the nonce will cause the record
>> decryption to fail.  That's the property we're looking for here, isn't
>> it?
>>
>>
>>
>> I don't believe that there's any reason to include the sequence number i=
n
>> the AD input of an AEAD. I think that an empty AD for TLS would be fine =
now
>> that the content type is encrypted. (Not that I deeply care either way.)
>>
>>
>>
>> Agreed.  Any value that always goes into the nonce doesn=E2=80=99t need =
to go
>> into the AD.
>>
>>
>>
>> David
>>
>>
>>
>>
>>
>> Cheers
>>
>>
>>
>> AGL
>>
>>
>>
>> --
>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>>
>>
>>
>
>

--001a114fa914ed41130523158420
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thinking about this a little more:

If we ever=
 change the nonce construction to have an explicit nonce or otherwise
=

not depend on the RSN (e.g., something like SIV) we're going to be=
 sad if
we don't have the RSN in the AD. Obviously, we'd =
also need to change the
text about the nonce construction, so it&=
#39;s not like you could drop in a construction
like this, but it=
 would be slightly easier to do if we already MACed the RSN.

=

I'm not sure which side of the fence I'm on here. What d=
o others think?

-Ekr


On Thu, Oct 22=
, 2015 at 10:07 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Thanks for the quick response, Da=
vid. I now agree with Martin and
Adam that we should remove this.
=


Chairs, I haven't seen any objections any reas=
on I shouldn't make this
change?

-Ekr

<=
div class=3D"gmail_extra">
On Thu, Oct 22, 20=
15 at 6:59 AM, David McGrew (mcgrew) <mcgrew@cisco.com> wrote=
:











=C2=A0


From: Eric Rescorla [mailto:ekr@rtfm.com]


Sent: Thursday, October 22, 2015 9:33 AM

To: Adam Langley

Cc: Martin Thomson; tls@ietf.org; Hugo Krawczyk; David McGrew (mcgrew)

Subject: Re: [TLS] Version in record MAC


=C2=A0




I'm mostly convinced =
by this text in RFC 5116:





=C2=A0






=C2=A0=C2=A0 Because the authenticated decryption=
 process


=C2=A0=C2=A0 detects incorrect nonce values, no s=
ecurity failure will result if a


=C2=A0=C2=A0 nonce is incorrectly reconstructed a=
nd fed into an authenticated


=C2=A0=C2=A0 decryption operation.=C2=A0 Any nonc=
e reconstruction method will need to


=C2=A0=C2=A0 take into account the possibility of=
 loss or reorder of ciphertexts


=C2=A0=C2=A0 between the encryption and decryptio=
n processes.


It would probably be worth checking with the cryp=
tographers in the room.


CCing Hugo and McGrew.


-Ekr


=C2=A0


=C2=A0








=C2=A0




On Mon, Oct 19, 2015 at 5=
:46 PM, Adam Langley <agl@imperialviolet.org> wrote:






On Monday, October 19, 20=
15, Martin Thomson <martin.thomson@gmail.com> wrote:


On 19 October 2015 at 11:=
17, Eric Rescorla <ekr=
@rtfm.com> wrote:

> Yeah, I think that's riding the nonce far too hard.



On what basis?=C2=A0 Any change in the nonce will cause the record

decryption to fail.=C2=A0 That's the property we're looking for her=
e, isn't

it?




=C2=A0










I don't believe that =
there's any reason to include the sequence number in the AD input of an=
 AEAD. I think that an empty AD for TLS would be fine now that the content =
type is encrypted. (Not that I deeply care either
 way.)






=C2=A0


Agreed.=C2=A0 Any value t=
hat always goes into the nonce doesn=E2=80=99t need to go into the AD.


=C2=A0


David


=C2=A0






=C2=A0






Cheers






=C2=A0






AGL








-- 

Adam Langley 
agl@imperialviolet.org 
https://www.imperialviolet.org




=C2=A0















--001a114fa914ed41130523158420--


From nobody Tue Oct 27 08:09:25 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C9A1A88EF for ; Tue, 27 Oct 2015 08:09: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRdmZ4h4XDAP for ; Tue, 27 Oct 2015 08:09:22 -0700 (PDT)
Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id E11DF1A9028 for ; Tue, 27 Oct 2015 08:09:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id C9F2C21BB2C; Tue, 27 Oct 2015 17:09:19 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id O0tN+qgSCjkP; Tue, 27 Oct 2015 17:09:18 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 152E35BC02D; Tue, 27 Oct 2015 17:09:18 +0200 (EET)
Date: Tue, 27 Oct 2015 17:09:15 +0200
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20151027150915.GA8140@LK-Perkele-V2.elisa-laajakaista.fi>
References:        <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: Adam Langley , "David McGrew \(mcgrew\)" , "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 27 Oct 2015 15:09:24 -0000

On Tue, Oct 27, 2015 at 08:49:35AM -0400, Eric Rescorla wrote:
> Thinking about this a little more:
> 
> If we ever change the nonce construction to have an explicit nonce or
> otherwise
> not depend on the RSN (e.g., something like SIV) we're going to be sad if
> we don't have the RSN in the AD. Obviously, we'd also need to change the
> text about the nonce construction, so it's not like you could drop in a
> construction
> like this, but it would be slightly easier to do if we already MACed the
> RSN.
> 
> I'm not sure which side of the fence I'm on here. What do others think?

AFAIK, the only case where this would be useful with RFC5116-compliant
ciphers are the ciphers with N_MAX=0, i.e. no nonce. And such ciphers
can't currently be used.


-Ilari


From nobody Tue Oct 27 08:57:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068801A9120 for ; Tue, 27 Oct 2015 08:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 jA2M0d7OklTq for ; Tue, 27 Oct 2015 08:57:29 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 3F6111A911E for ; Tue, 27 Oct 2015 08:57:28 -0700 (PDT)
Received: by ykek133 with SMTP id k133so40897938yke.2 for ; Tue, 27 Oct 2015 08:57:27 -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:content-type; bh=QnXHBWZC80WVcGHSe5onIUzRBxh6vsxq8BPeR65zlMI=; b=PubZG4VsoCwSJtxorlOxZmf2FBKdVC0+TrnZVtdhHr5StJqqfljRRX8W9AbcyTTEEo HVjMRjTDf8Sis5Znq8TSwZx8fWYkPWqdX69n3czSz7i7taap5rdvm19T/bWYhFSQnV5J XHBDJtEt4XEXqZ2PnVOfzRTnYN+zJ8/j7hOXLedzjrRzzfPgdq/734bQG5B7d30ugAzz DpJ8l/DpAPtHPlMC82fF6lKWEqD4FnlhQSdrQKbgF/wBjLYzOW7Z9gzxJkGy6H5yFE9l ZHzpIR2FnrjHlGS8iMyyqJ9nw21JYSKU+0SzlA03dmLfPSu9VkCliLoo6t51WmzIYtkH 74eA==
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-type; bh=QnXHBWZC80WVcGHSe5onIUzRBxh6vsxq8BPeR65zlMI=; b=Ue/HAMZZePd0ZCeGDSjytzxbHPOWGwLTqfS+iddszjyIJsFHcQbqivze1BDIWRHLrS 8KCZhCVLIkYKN9poFTpwMeoNTMqo4bzr15KJHhX+EZm9fHnHJQr+8OXLyqrH9Dc8AHnD EE6WDkQl1EYWayh/NM763U3BMvjGfz9Mqb94J42k0EjjlDVnWeq/dFJIm6BHG71G3lYP 7GWjZ8kHpdhfq4qfR4t70IiqN2RzjRE7jE/YlGGceb4kt8oDnbfpv6gzbKGLZj8K+c/j u/RYnnebRPUYSf53PNh0j30LqMMgqzCoy4mY1seYAItVdLwqw0PNy2Ln+EWMBUDz8aTY K3og==
X-Gm-Message-State: ALoCoQnEKTepIf4M/SZhRPU2gvdLQGNhGMuT0M6x6jeZlJ7+KPSURCKFCnCDBiZ5Gk+dpGiR9D6O
X-Received: by 10.129.70.139 with SMTP id t133mr30270417ywa.115.1445961447505;  Tue, 27 Oct 2015 08:57:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Tue, 27 Oct 2015 08:56:48 -0700 (PDT)
In-Reply-To: <20151027150915.GA8140@LK-Perkele-V2.elisa-laajakaista.fi>
References:        <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com>   <20151027150915.GA8140@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Tue, 27 Oct 2015 11:56:48 -0400
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a114d72567035c505231822db
Archived-At: 
Cc: Adam Langley , "David McGrew \(mcgrew\)" , "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 27 Oct 2015 15:57:31 -0000

--001a114d72567035c505231822db
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 27, 2015 at 11:09 AM, Ilari Liusvaara 
wrote:

> On Tue, Oct 27, 2015 at 08:49:35AM -0400, Eric Rescorla wrote:
> > Thinking about this a little more:
> >
> > If we ever change the nonce construction to have an explicit nonce or
> > otherwise
> > not depend on the RSN (e.g., something like SIV) we're going to be sad if
> > we don't have the RSN in the AD. Obviously, we'd also need to change the
> > text about the nonce construction, so it's not like you could drop in a
> > construction
> > like this, but it would be slightly easier to do if we already MACed the
> > RSN.
> >
> > I'm not sure which side of the fence I'm on here. What do others think?
>
> AFAIK, the only case where this would be useful with RFC5116-compliant
> ciphers are the ciphers with N_MAX=0, i.e. no nonce. And such ciphers
> can't currently be used.


Yes, that's correct. But we could relax that restriction and make those work
if we wanted...

-Ekr


>
>
> -Ilari
>

--001a114d72567035c505231822db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Oct 27, 2015 at 11:09 AM, Ilari Liusvaara <=
;ilariliusvaa=
ra@welho.com> wrote:
On Tue, Oct 27, 2015 at 08:49:35AM -0400, Eric Rescorla wrote:
> Thinking about this a little more:

>

> If we ever change the nonce construction to have an explicit nonce or<=
br>
> otherwise

> not depend on the RSN (e.g., something like SIV) we're going to be=
 sad if

> we don't have the RSN in the AD. Obviously, we'd also need to =
change the

> text about the nonce construction, so it's not like you could drop=
 in a

> construction

> like this, but it would be slightly easier to do if we already MACed t=
he

> RSN.

>

> I'm not sure which side of the fence I'm on here. What do othe=
rs think?



AFAIK, the only case where this would be useful with RFC5116-complia=
nt

ciphers are the ciphers with N_MAX=3D0, i.e. no nonce. And such ciphers

can't currently be used.

Yes, that'=
s correct. But we could relax that restriction and make those work
if we wanted...

-Ekr
=C2=A0



-Ilari





--001a114d72567035c505231822db--


From nobody Tue Oct 27 11:49:19 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EC31A1A59 for ; Tue, 27 Oct 2015 11:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 lHnewmbx3E_v for ; Tue, 27 Oct 2015 11:49:16 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 0C8761A1B5B for ; Tue, 27 Oct 2015 11:49:16 -0700 (PDT)
Received: by qgeo38 with SMTP id o38so153872564qge.0 for ; Tue, 27 Oct 2015 11:49:15 -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:date:message-id:subject :from:to:cc:content-type; bh=iRN46UuI9YP8fu2l4oYomfxuTuC78SysWm+8SkdSOPY=; b=w7guqzbbQjJDG5zpGM1NEuJuFZ31WJi1whx9+CULGrecUrudFwe7Px9CiotWf3Qzx6 ETl0qhI/wd3b+FfWtt1F12epnpC1bcMCdFi8vaEIbA5VnVsfZrgKXkEvW5yJFjI6aaBe 0sXEP+ZTKZY/K4zRMYemAhuERcACdSAOfY4MO8XIMs1wt8xn6HPN/oRKJi217XZTG5iV qTNcHgan3x9FAaO7A0q/wqvERe1T876P8P+2Bxjm4VpPXHoP/dVB2KrHMcd0Zbrm/uZM u5voY/bZs471xB06NkfY3UMP/+4LTAthyt8RIWPH7wLdhdX+sGQrMpj8RbFrrqL/HVV1 akgw==
MIME-Version: 1.0
X-Received: by 10.141.28.76 with SMTP id f73mr35574938qhe.17.1445971755258; Tue, 27 Oct 2015 11:49:15 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.140.81.241 with HTTP; Tue, 27 Oct 2015 11:49:15 -0700 (PDT)
In-Reply-To: 
References:        <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com>   <20151027150915.GA8140@LK-Perkele-V2.elisa-laajakaista.fi> 
Date: Tue, 27 Oct 2015 11:49:15 -0700
X-Google-Sender-Auth: V34T0SO1j0fSk_UtciVLajOg1Zc
Message-ID: 
From: Adam Langley 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "David McGrew \(mcgrew\)" , "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 27 Oct 2015 18:49:18 -0000

On Tue, Oct 27, 2015 at 8:56 AM, Eric Rescorla  wrote:
> Yes, that's correct. But we could relax that restriction and make those work
> if we wanted...

Explicit nonces should not be used in TLS. I'm happy to be building
things without them in mind.

SIV modes, if turned into AEADs, would have to authenticate their
nonces internally. RFC 5297 basically says that already
(https://tools.ietf.org/html/rfc5297#section-3). That might mean that
the nonce is prepended to the AD inside the AEAD abstraction, but that
wouldn't be TLS's concern.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org


From nobody Tue Oct 27 11:54:41 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A141ACE0E for ; Tue, 27 Oct 2015 11:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 6UmeFQtBBk8l for ; Tue, 27 Oct 2015 11:54:37 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002: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 0F9101ACE0D for ; Tue, 27 Oct 2015 11:54:37 -0700 (PDT)
Received: by ykft191 with SMTP id t191so46236305ykf.0 for ; Tue, 27 Oct 2015 11:54: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:content-type; bh=bHXIgJvf5Wr5umZE3ucPuRPRr4rVAVeYJOcJ36bNeJc=; b=mLYa0uIFpqwcvf1GdlxdMmCbQYovRF+rBuptnMO3DpBEH7LuymDrdr4PCsbPb7N7cA KbkUpMaCN4fZznM5nO6hROyPjAtZL4baL4XdbyIq7K3oeuXVzNoDzrgais6AqcrM43Qq E+at+cDxErpQM3+p7yxUV0QMU+LO5gtQOauFkvsa4lOaeEyzaf4Silz9IF/2cm0miW7s O0aWK8ZuweqKMKyrmtzh136nbYbcVTxi/5P8XCfyZcwgKlZpajhK5s2AEhGM+8AQq5sf GG8Bb387HOKclEYC35XEyY2deUZcwpKKtRq/kdqY+mopnai8+sHQAMzI4W41s5OXsnwo Pf8A==
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-type; bh=bHXIgJvf5Wr5umZE3ucPuRPRr4rVAVeYJOcJ36bNeJc=; b=Sr361thmTom/to5YtEymufIHOXt0guQ5/x3/cL7ZE5ordvwc5rhB20h9MahV2rh4Cb +cKNQpE54PrJ2zGi1Wd3OpdBn7paENUzceSMuuM4zlTv6F3SJNb9qNWjFcK76/lqo8Zu q/0FLvf0L0yR2Ov0CKP8h5OEncnx4AuFQzjTljRR7sbt0f0vL57mW2SiOXnCZJPpQxvs O77+8G92QQ5+izuFwJvUUD+5isYfLCRCRRbWU2gj0uAuY5mzzhCMPvFq4NKGIDdpDTGM xmmfUQyvD+rxX+o3aaTDboc6nTQBy98g2w859SEpb0/bmlyIvQATXGzSYu0+kFW9JEin sAnw==
X-Gm-Message-State: ALoCoQn/E4X2bT2YDIMMJqXvJk9wm4TV/CVzRRKcYlHMoWUsGqKvj0LSlWRvFLIaq9YLXU2mP/F2
X-Received: by 10.129.70.139 with SMTP id t133mr30969574ywa.115.1445972076320;  Tue, 27 Oct 2015 11:54:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Tue, 27 Oct 2015 11:53:56 -0700 (PDT)
In-Reply-To: 
References:        <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com>   <20151027150915.GA8140@LK-Perkele-V2.elisa-laajakaista.fi>  
From: Eric Rescorla 
Date: Tue, 27 Oct 2015 14:53:56 -0400
Message-ID: 
To: Adam Langley 
Content-Type: multipart/alternative; boundary=001a114d7256f70c3205231a9b5d
Archived-At: 
Cc: "David McGrew \(mcgrew\)" , "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 27 Oct 2015 18:54:39 -0000

--001a114d7256f70c3205231a9b5d
Content-Type: text/plain; charset=UTF-8

Sure. Like I said, I don't feel strongly about this, I just wanted to take
people's
temperature. I'm find with removing the seq from the AD.

-Ekr

On Tue, Oct 27, 2015 at 2:49 PM, Adam Langley 
wrote:

> On Tue, Oct 27, 2015 at 8:56 AM, Eric Rescorla  wrote:
> > Yes, that's correct. But we could relax that restriction and make those
> work
> > if we wanted...
>
> Explicit nonces should not be used in TLS. I'm happy to be building
> things without them in mind.
>
> SIV modes, if turned into AEADs, would have to authenticate their
> nonces internally. RFC 5297 basically says that already
> (https://tools.ietf.org/html/rfc5297#section-3). That might mean that
> the nonce is prepended to the AD inside the AEAD abstraction, but that
> wouldn't be TLS's concern.
>
>
> Cheers
>
> AGL
>
> --
> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>

--001a114d7256f70c3205231a9b5d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Sure. Like I said, I don't =
feel strongly about this, I just wanted to take people's
temperature. I'm find with removing the seq from the =
AD.

-E=
kr

On Tue, Oct 27, 2015 at 2:49 PM, Adam Langley <agl@imperialviolet.org> wrote:
On Tue, Oct 27, 2015 at 8:56 AM, Eric Rescorla <<=
a href=3D"mailto:ekr@rtfm.com">ekr@rtfm.com> wrote:

> Yes, that's correct. But we could relax that restriction and make =
those work

> if we wanted...



Explicit nonces should not be used in TLS. I'm happy to be build=
ing

things without them in mind.



SIV modes, if turned into AEADs, would have to authenticate their

nonces internally. RFC 5297 basically says that already

(https://tools.ietf.org/html/rfc5297#section-3). Th=
at might mean that

the nonce is prepended to the AD inside the AEAD abstraction, but that

wouldn't be TLS's concern.






Cheers



AGL



--

Adam Langley agl@imperialviolet.o=
rg https://www.imperialviolet.org





--001a114d7256f70c3205231a9b5d--


From nobody Wed Oct 28 19:27:06 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F791B622B for ; Wed, 28 Oct 2015 19:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level: 
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL4IUNxEmAKn for ; Wed, 28 Oct 2015 19:27:02 -0700 (PDT)
Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DFCCF1B6226 for ; Wed, 28 Oct 2015 19:27:02 -0700 (PDT)
Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 49C5F2005D901 for ; Wed, 28 Oct 2015 19:27:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h=to:from :subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=nomountain.net; bh=51lLKjkof/5d/Cd 4qoKU5nu9mY8=; b=vDtANqGEN9c0zSvAClTDRGj+Dv9izHNhlgcdOUQZuWJ+LUu FILq0CqXv0leDW7k8zvHf/1756q5cmakOrkGkX8lZoUl0XYmjkkbJeilOrZ+ZCf2 WCTktjeXFBaBbFUuryCrUqy8EjYGhwV6fqlPPls8rsIneisE0iYX8txFt3S4=
Received: from [100.64.17.52] (unknown [210.227.101.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id DFCBF2005D82D for ; Wed, 28 Oct 2015 19:27:01 -0700 (PDT)
To: tls@ietf.org
From: Melinda Shore 
Message-ID: <563183F4.4070000@nomountain.net>
Date: Wed, 28 Oct 2015 18:27:00 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [TLS] draft-shore-tls-dnssec-chain-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Oct 2015 02:27:04 -0000

Hi, all:

We haven't been pushing on this because we recognize that getting
TLS 1.3 published is top priority, but we've got a new version
posted 
(https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-02)
that addresses many of the concerns raised both here and on the DANE
mailing list, including encoding the validation chain within the
extension in DNS wire format.  Once things quiet down a bit we plan
to ask the working group to adopt the draft for publication.

Thanks,

Melinda et al.


From nobody Wed Oct 28 21:15:27 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F7B1B6499 for ; Wed, 28 Oct 2015 21:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrpvhMVL54-t for ; Wed, 28 Oct 2015 21:15:25 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 E3BC91B6493 for ; Wed, 28 Oct 2015 21:15:24 -0700 (PDT)
Received: by padhy1 with SMTP id hy1so21510259pad.0 for ; Wed, 28 Oct 2015 21:15:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mvdk4bcG5I0mObJ8ukCDeivdgmBspru0L8e7HT8CC7g=; b=MdGp0/uYIvz/+Y2nFcrA63k8xHETsmQOjdnkQ5wbR1H6CosThuA9va1GwtvSyvvLDV 9xyHBMD6gF9Vh7l/RttMEOzlEpBBg+Ahdrt1hpYZ4GFTU8JorKHZFsvapyBDmlZ1Yusa nn4PZ7Z2hGl1JbKX3Qbj7jZQQ64GUDQSa9v0E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Mvdk4bcG5I0mObJ8ukCDeivdgmBspru0L8e7HT8CC7g=; b=UAo+Qk8n5zVDkUAaPclFi9NJxctc7nHYw6tMlbI7P7QHMq7StLuiO4kr5xfmCJeaC/ svkMtSQ/1Q6J8h9yJeE2qwtAbJGTFTpcml6UWe5t7habQ/uX/MFVlqB8bmG0LArCPC6V Gi/NRpzpzgeIAxNb/chJwtRpvwWmjpWlvgpWn0p+/GNfQi0eQCUZlkvvuYjZ2bR+0Ry3 9R48AOVeyXlz/JTN6Hs3ZoOZNLRvg1IHSwfEXTDOgYCLT/0Ft9NEMcd2uZr+hxgqPuqa IFZzrOBw+XHfN/FTUfLAF9TblYpNMrquPf5wDodX03Kgswtuo5wGZa9KaI05tXZV938r S1Kw==
X-Gm-Message-State: ALoCoQlSWbxy8J6l2nFWLokGxKjxS7w/Rfk5dh2Xv51lNqx6ipKWuI1zE+HW/iCpiFwVGOD4SOHY
X-Received: by 10.68.69.108 with SMTP id d12mr56639197pbu.137.1446092124494; Wed, 28 Oct 2015 21:15:24 -0700 (PDT)
Received: from [5.5.33.245] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id ey17sm48423951pac.26.2015.10.28.21.15.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Oct 2015 21:15:24 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Sean Turner 
In-Reply-To: <563183F4.4070000@nomountain.net>
Date: Thu, 29 Oct 2015 13:15:16 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <693F7C67-DFB5-4A3D-80F8-EAB80CDC2679@sn3rd.com>
References: <563183F4.4070000@nomountain.net>
To: Melinda Shore 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Oct 2015 04:15:26 -0000

Melinda,

As chair, I really appreciate you holding off.

spt

> On Oct 29, 2015, at 11:27, Melinda Shore =
 wrote:
>=20
> Hi, all:
>=20
> We haven't been pushing on this because we recognize that getting
> TLS 1.3 published is top priority, but we've got a new version
> posted =
(https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-02)
> that addresses many of the concerns raised both here and on the DANE
> mailing list, including encoding the validation chain within the
> extension in DNS wire format.  Once things quiet down a bit we plan
> to ask the working group to adopt the draft for publication.
>=20
> Thanks,
>=20
> Melinda et al.
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Wed Oct 28 23:04:52 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718421A1EFE for ; Wed, 28 Oct 2015 23:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPrc44pNp5aA for ; Wed, 28 Oct 2015 23:04:48 -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 F2E511A1EFC for ; Wed, 28 Oct 2015 23:04:47 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDF52456; Thu, 29 Oct 2015 06:04:45 +0000 (GMT)
Received: from SZXEMI412-HUB.china.huawei.com (10.86.210.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 29 Oct 2015 06:04:44 +0000
Received: from SZXEMI501-MBX.china.huawei.com ([169.254.1.73]) by szxemi412-hub.china.huawei.com ([10.86.210.35]) with mapi id 14.03.0235.001; Thu, 29 Oct 2015 14:04:36 +0800
From: Jayaraghavendran k 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
Thread-Index: AQHRDc4xC8umvb5us06ZJNAT+adNe559uDnggARLZ3A=
Date: Thu, 29 Oct 2015 06:04:35 +0000
Message-ID: <8D925D4C0B78EE41857D407022ECD163BFEE9009@SZXEMI501-MBX.china.huawei.com>
References:  
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.213.218]
Content-Type: multipart/alternative; boundary="_000_8D925D4C0B78EE41857D407022ECD163BFEE9009SZXEMI501MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Oct 2015 06:04:51 -0000

--_000_8D925D4C0B78EE41857D407022ECD163BFEE9009SZXEMI501MBXchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRXJpYywNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KDQoxLiBUaGVyZSBpcyBhbHJl
YWR5IG5vIHJlcXVpcmVtZW50IHRoYXQgeW91IGhhdmUgYW4gZXhwbGljaXQgbm9uY2UuIFJGQzUy
NDYNCm1lcmVseSByZXF1aXJlcyB0aGF0IHlvdSBzcGVjaWZ5IHRoZSBsZW5ndGggb2YgdGhlIGV4
cGxpY2l0IG5vbmNlLCBidXQgdGhhdA0KbGVuZ3RoIGNhbiBiZSAwLCBhcyBpdCBpcyBpbiB0aGUg
Q2hhQ2hhL1BvbHkgZHJhZnRzLiBTbywgcmF0aGVyIHRoYW4gYnVpbGQNCmFuIGV4dGVuc2lvbiBp
dCB3b3VsZCBiZSBiZXR0ZXIgdG8ganVzdCBkZWZpbmUgYSBuZXcgY2lwaGVyIHN1aXRlIGlmIHlv
dSB0aGluaw0KdGhpcyBpcyBpbXBvcnRhbnQuDQpbSmF5XTogVGhlIGV4dGVuc2lvbiBpZGVhIHdh
cyBtYWlubHkgZm9yIHRoZSBhbHJlYWR5IGRlZmluZWQgY2lwaGVycyBpbiBSRkMgNjY1NSAoZm9y
IEFFU19DQ00gdXNhZ2UgaW4gVExTKSAmIFJGQyA1Mjg4IChmb3IgQUVTX0dDTSB1c2FnZSBpbiBU
TFMpLiBCb3RoIHRoZXNlIFJGQ3Mgc3RhdGUgdGhhdCBhbiBleHBsaWNpdCBub25jZSBvZiA4IGJ5
dGVzIE1VU1QgYmUgY2FycmllZCBpbiBlYWNoIHJlY29yZC4gU28sIGluIHRoZXNlIGNhc2VzIHRv
IGF2b2lkIHRoZSBvdmVyaGVhZCwgdGhlIG9wdGlvbnMgYXMgSSB1bmRlcnN0YW5kIGFyZSBkZWZp
bmluZyBhIG5ldyBleHRlbnNpb24gb3IgYSBuZXcgY2lwaGVyIHN1aXRlICh3aGljaCBzdWdnZXN0
cyB0aGUgbmV3IGV4cGxpY2l0IG5vbmNlIGdlbmVyYXRpb24gbWVjaGFuaXNtIGFuZCBtYWtlcyB0
aGUgcmVjb3JkIGl2IGxlbmd0aCBhcyAwKS4NCg0KVGhpcyBuZXcgZXh0ZW5zaW9uIGlzIG1vcmUg
bGlrZSBhIGZyYW1ld29yayBmb3IgbmVnb3RpYXRpbmcgdGhlIHR5cGUgb2YgZXhwbGljaXQgbm9u
Y2UgZ2VuZXJhdGlvbiBtZWNoYW5pc21zLiBJZiBhIHBhcnRpY3VsYXIgd2F5IG9mIGdlbmVyYXRp
bmcgdGhlIGV4cGxpY2l0IG5vbmNlIGlzIGZvdW5kIHRvIGJlIGV4cGxvaXRhYmxlIGluIGZ1dHVy
ZSwgYSBuZXcgbWVjaGFuaXNtIGNhbiBiZSBkZWZpbmVkIGFuZCBuZWdvdGlhdGVkIHRocm91Z2gg
dGhlIGV4dGVuc2lvbi4gIERlZmluaW5nICBhIG5ldyBjaXBoZXIgZm9yIGVhY2ggbmV3IG1lY2hh
bmlzbSBvZiBleHBsaWNpdCBub25jZSBnZW5lcmF0aW9uIG1heSBpbmNyZWFzZSB0aGUgbnVtYmVy
IG9mIGNpcGhlcnMgdGhhdCB0aGUgY2xpZW50IGhhcyB0byBjYXJyeSBpbiBpdOKAmXMgY2xpZW50
IGhlbGxvIGJ5IGEgZ29vZCBhbW91bnQgKGNvbnNpZGVyaW5nLCBpdCBuZWVkcyB0byBjYXJyeSBv
bGQgY2lwaGVycyBhbHNvIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggc2VydmVycyBu
b3Qgc3VwcG9ydGluZyBuZXcgY2lwaGVycykuDQoNCg0KMi4gVExTIDEuMyBhbHJlYWR5IG9taXRz
IHRoZSBleHBsaWNpdCBub25jZSBlbnRpcmVseS4NCltKYXldOiAgTXkgcHJpbWFyeSBnb2FsIGlz
IGZvciBEVExTIDEuMiB3aGljaCBpcyB1c2VkIHdpdGggQ29BUCBpbiB2YXJpb3VzIElvVCBTY2Vu
YXJpb3MuIFVzYWdlIG9mIERUTFMgMS4yIHdpdGggQ29BUCBoYXMgYWxyZWFkeSBzdGFydGVkIGlu
IG1hbnkgcHJvZHVjdHMgSSBiZWxpZXZlIGFuZCBEVExTIDEuMyBtYXkgdGFrZSBzb21lIHRpbWUg
YW5kIHdpbGwgbm90IGJlIGltbWVkaWF0ZWx5IGFkYXB0ZWQgYnkgcHJvZHVjdHMgYWxyZWFkeSBy
ZWxlYXNlZC4NCg0KUmVxdWVzdGluZyB5b3VyIHN1Z2dlc3Rpb25zIGluIHRoZSBhYm92ZSBjb250
ZXh0Lg0KDQpUaGFua3MgQWdhaW4uDQoNCkJlc3QgUmVnYXJkcywNCkpheQ0KKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqDQpUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBj
b25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9u
bHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3Zl
LiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkg
KGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1
cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFu
IHRoZSBpbnRlbmRlZCByZWNpcGllbnQncykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUg
dGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSBv
ciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogMjQgT2N0b2JlciAyMDE1IDAxOjM1DQpUbzog
dGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+OyBkcmFmdC1qYXktdGxzLW9taXQtYWVh
ZC1leHBsaWNpdC1ub25jZS1leHRlbnNpb25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWph
eS10bHMtb21pdC1hZWFkLWV4cGxpY2l0LW5vbmNlLWV4dGVuc2lvbkB0b29scy5pZXRmLm9yZz4N
ClN1YmplY3Q6IFtUTFNdIGRyYWZ0LWpheS10bHMtb21pdC1hZWFkLWV4cGxpY2l0LW5vbmNlLWV4
dGVuc2lvbg0KDQpJIHRvb2sgYSBxdWljayBsb29rIGF0IHRoaXMgZHJhZnQgYW5kIElNTyBpdCBp
cyB1bm5lY2Vzc2FyeSwgZm9yIHR3byByZWFzb25zOg0KDQoxLiBUaGVyZSBpcyBhbHJlYWR5IG5v
IHJlcXVpcmVtZW50IHRoYXQgeW91IGhhdmUgYW4gZXhwbGljaXQgbm9uY2UuIFJGQzUyNDYNCm1l
cmVseSByZXF1aXJlcyB0aGF0IHlvdSBzcGVjaWZ5IHRoZSBsZW5ndGggb2YgdGhlIGV4cGxpY2l0
IG5vbmNlLCBidXQgdGhhdA0KbGVuZ3RoIGNhbiBiZSAwLCBhcyBpdCBpcyBpbiB0aGUgQ2hhQ2hh
L1BvbHkgZHJhZnRzLiBTbywgcmF0aGVyIHRoYW4gYnVpbGQNCmFuIGV4dGVuc2lvbiBpdCB3b3Vs
ZCBiZSBiZXR0ZXIgdG8ganVzdCBkZWZpbmUgYSBuZXcgY2lwaGVyIHN1aXRlIGlmIHlvdSB0aGlu
aw0KdGhpcyBpcyBpbXBvcnRhbnQuDQoNCjIuIFRMUyAxLjMgYWxyZWFkeSBvbWl0cyB0aGUgZXhw
bGljaXQgbm9uY2UgZW50aXJlbHkuDQoNCi1Fa3INCg0KDQoNCg==

--_000_8D925D4C0B78EE41857D407022ECD163BFEE9009SZXEMI501MBXchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc
QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv
QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv
b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw
YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U
ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh
bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w
cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs
YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEVyaWMsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9y
IHlvdXIgcmVzcG9uc2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gVGhlcmUgaXMgYWxy
ZWFkeSBubyByZXF1aXJlbWVudCB0aGF0IHlvdSBoYXZlIGFuIGV4cGxpY2l0IG5vbmNlLiBSRkM1
MjQ2PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tZXJlbHkgcmVxdWlyZXMg
dGhhdCB5b3Ugc3BlY2lmeSB0aGUgbGVuZ3RoIG9mIHRoZSBleHBsaWNpdCBub25jZSwgYnV0IHRo
YXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxlbmd0aCBjYW4gYmUgMCwg
YXMgaXQgaXMgaW4gdGhlIENoYUNoYS9Qb2x5IGRyYWZ0cy4gU28sIHJhdGhlciB0aGFuIGJ1aWxk
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbiBleHRlbnNpb24gaXQgd291
bGQgYmUgYmV0dGVyIHRvIGp1c3QgZGVmaW5lIGEgbmV3IGNpcGhlciBzdWl0ZSBpZiB5b3UgdGhp
bms8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaXMgaXMgaW1wb3J0YW50
LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltKYXldOiBUaGUgZXh0ZW5zaW9uIGlkZWEgd2FzIG1h
aW5seSBmb3IgdGhlIGFscmVhZHkgZGVmaW5lZCBjaXBoZXJzIGluIFJGQyA2NjU1IChmb3IgQUVT
X0NDTSB1c2FnZSBpbiBUTFMpICZhbXA7IFJGQyA1Mjg4IChmb3IgQUVTX0dDTSB1c2FnZSBpbiBU
TFMpLiBCb3RoIHRoZXNlDQogUkZDcyBzdGF0ZSB0aGF0IGFuIGV4cGxpY2l0IG5vbmNlIG9mIDgg
Ynl0ZXMgTVVTVCBiZSBjYXJyaWVkIGluIGVhY2ggcmVjb3JkLiBTbywgaW4gdGhlc2UgY2FzZXMg
dG8gYXZvaWQgdGhlIG92ZXJoZWFkLCB0aGUgb3B0aW9ucyBhcyBJIHVuZGVyc3RhbmQgYXJlIGRl
ZmluaW5nIGEgbmV3IGV4dGVuc2lvbiBvciBhIG5ldyBjaXBoZXIgc3VpdGUgKHdoaWNoIHN1Z2dl
c3RzIHRoZSBuZXcgZXhwbGljaXQgbm9uY2UgZ2VuZXJhdGlvbiBtZWNoYW5pc20NCiBhbmQgbWFr
ZXMgdGhlIHJlY29yZCBpdiBsZW5ndGggYXMgMCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIG5ldyBleHRlbnNp
b24gaXMgbW9yZSBsaWtlIGEgZnJhbWV3b3JrIGZvciBuZWdvdGlhdGluZyB0aGUgdHlwZSBvZiBl
eHBsaWNpdCBub25jZSBnZW5lcmF0aW9uIG1lY2hhbmlzbXMuIElmIGEgcGFydGljdWxhciB3YXkg
b2YgZ2VuZXJhdGluZyB0aGUgZXhwbGljaXQNCiBub25jZSBpcyBmb3VuZCB0byBiZSBleHBsb2l0
YWJsZSBpbiBmdXR1cmUsIGEgbmV3IG1lY2hhbmlzbSBjYW4gYmUgZGVmaW5lZCBhbmQgbmVnb3Rp
YXRlZCB0aHJvdWdoIHRoZSBleHRlbnNpb24uICZuYnNwO0RlZmluaW5nJm5ic3A7IGEgbmV3IGNp
cGhlciBmb3IgZWFjaCBuZXcgbWVjaGFuaXNtIG9mIGV4cGxpY2l0IG5vbmNlIGdlbmVyYXRpb24g
bWF5IGluY3JlYXNlIHRoZSBudW1iZXIgb2YgY2lwaGVycyB0aGF0IHRoZSBjbGllbnQgaGFzIHRv
IGNhcnJ5IGluDQogaXTigJlzIGNsaWVudCBoZWxsbyBieSBhIGdvb2QgYW1vdW50IChjb25zaWRl
cmluZywgaXQgbmVlZHMgdG8gY2Fycnkgb2xkIGNpcGhlcnMgYWxzbyBmb3IgYmFja3dhcmQgY29t
cGF0aWJpbGl0eSB3aXRoIHNlcnZlcnMgbm90IHN1cHBvcnRpbmcgbmV3IGNpcGhlcnMpLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4yLiBUTFMgMS4zIGFscmVhZHkgb21pdHMgdGhlIGV4cGxpY2l0IG5vbmNl
IGVudGlyZWx5LjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0pheV06ICZuYnNwO015IHByaW1hcnkgZ29hbCBp
cyBmb3IgRFRMUyAxLjIgd2hpY2ggaXMgdXNlZCB3aXRoIENvQVAgaW4gdmFyaW91cyBJb1QgU2Nl
bmFyaW9zLiBVc2FnZSBvZiBEVExTIDEuMiB3aXRoIENvQVAgaGFzIGFscmVhZHkgc3RhcnRlZCBp
biBtYW55IHByb2R1Y3RzIEkNCiBiZWxpZXZlIGFuZCBEVExTIDEuMyBtYXkgdGFrZSBzb21lIHRp
bWUgYW5kIHdpbGwgbm90IGJlIGltbWVkaWF0ZWx5IGFkYXB0ZWQgYnkgcHJvZHVjdHMgYWxyZWFk
eSByZWxlYXNlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVxdWVzdGluZyB5b3VyIHN1Z2dlc3Rpb25zIGluIHRo
ZSBhYm92ZSBjb250ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIEFnYWluLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBS
ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KYXk8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZS1t
YWlsIGFuZCBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9t
IEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkg
d2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9u
IGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQg
dG8sIHRvdGFsIG9yIHBhcnRpYWwNCiBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3Nl
bWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50J3Mp
IGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVh
c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRl
bGV0ZSBpdCE8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g
MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVExTIFs8
YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzp0bHMtYm91bmNlc0Bp
ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5T
ZW50OjwvYj4gMjQgT2N0b2JlciAyMDE1IDAxOjM1PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJt
YWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJh
ZnQtamF5LXRscy1vbWl0LWFlYWQtZXhwbGljaXQtbm9uY2UtZXh0ZW5zaW9uQHRvb2xzLmlldGYu
b3JnIj4NCmRyYWZ0LWpheS10bHMtb21pdC1hZWFkLWV4cGxpY2l0LW5vbmNlLWV4dGVuc2lvbkB0
b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RMU10gZHJhZnQtamF5LXRs
cy1vbWl0LWFlYWQtZXhwbGljaXQtbm9uY2UtZXh0ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRvb2sgYSBxdWljayBsb29rIGF0IHRoaXMgZHJh
ZnQgYW5kIElNTyBpdCBpcyB1bm5lY2Vzc2FyeSwgZm9yIHR3byByZWFzb25zOjxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gVGhlcmUgaXMgYWxyZWFkeSBu
byByZXF1aXJlbWVudCB0aGF0IHlvdSBoYXZlIGFuIGV4cGxpY2l0IG5vbmNlLiBSRkM1MjQ2PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tZXJlbHkg
cmVxdWlyZXMgdGhhdCB5b3Ugc3BlY2lmeSB0aGUgbGVuZ3RoIG9mIHRoZSBleHBsaWNpdCBub25j
ZSwgYnV0IHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPmxlbmd0aCBjYW4gYmUgMCwgYXMgaXQgaXMgaW4gdGhlIENoYUNoYS9Qb2x5IGRyYWZ0
cy4gU28sIHJhdGhlciB0aGFuIGJ1aWxkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5hbiBleHRlbnNpb24gaXQgd291bGQgYmUgYmV0dGVyIHRvIGp1
c3QgZGVmaW5lIGEgbmV3IGNpcGhlciBzdWl0ZSBpZiB5b3UgdGhpbms8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaXMgaXMgaW1wb3J0YW50Ljxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBU
TFMgMS4zIGFscmVhZHkgb21pdHMgdGhlIGV4cGxpY2l0IG5vbmNlIGVudGlyZWx5LjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_8D925D4C0B78EE41857D407022ECD163BFEE9009SZXEMI501MBXchi_--


From nobody Wed Oct 28 23:11:22 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5CD1A21BB for ; Wed, 28 Oct 2015 23:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 Noy_MUi6zHQ4 for ; Wed, 28 Oct 2015 23:11:17 -0700 (PDT)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 944771A21B8 for ; Wed, 28 Oct 2015 23:11:17 -0700 (PDT)
Received: by ykft191 with SMTP id t191so32396108ykf.0 for ; Wed, 28 Oct 2015 23:11: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:content-type; bh=XsP7LRt2MYFvN9nqoP+swCXy401pBsD8oiaGWFd5Oe4=; b=FtLXJMmb+SnIuW1RegLsh5k+xIiSgBGAeshnPLFnLFaAhSy6GNw3Av4rZ4Z6bf7Upl 4Cch1pWCytgPd9C547Ciq/Pdw5LIHQzXaUWtc7vX/APtmTz4SGp2TPiKNProxp4FyEZK iabxo/5wTxjUEhfkUmFyBT2ESKizc2O4zSCd2BBnfGaZ+HAFGy1L9zQeTuZsWNwA89zb d2rRBB4Nxb+k1oS1y3P3O7Fk0kMxbPzCSJapKbnVXF+eTcYIm3eQ6tclTmrokI+5RL6F fZGwcd0qNQS1xaiHRVqYDzCJfbPYweP1DoDTfrIQTmvAnQOKBZ93p5mhy1DTtyk4ej3L BwYA==
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-type; bh=XsP7LRt2MYFvN9nqoP+swCXy401pBsD8oiaGWFd5Oe4=; b=HWewUgJebajKWo9aADqUbfr1RjmRk/GtXXVoYv9hLg9g9xgQ36KneM3+J+Zyrr36/W yVfTvCmlsSMMiC7wc14A/cXQIlMfhBX7cfq/uHU5Ny4kJcYZIWuIQJyah6LXfXNhb+0J kPwJ/cybErM2h11MyfVKL4TGtcFgz/EaGKh8/cRf99Y38dC1b8955SgJU+TvrhU5gWWo 0OXIiRe930IZd81g2joFFPGTXy2cmWBTvK+UMtyVREvJK+0qsM1LLCDHzZSM/E2cld4u sUnrDiZc8TYGLtnuZuosO5mNrhHpkVGrMPXwvtN/nwBw6tGwfcP85dskICQ13IySjSEo 5fPA==
X-Gm-Message-State: ALoCoQn6GPS+djuq9Hr9oSNIrYy8SxK6dX36O0ofgXr5RTG5SB1ClLORjDZBCa/o/IZ746dAgtL/
X-Received: by 10.129.130.6 with SMTP id s6mr37613136ywf.155.1446099076873; Wed, 28 Oct 2015 23:11:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Wed, 28 Oct 2015 23:10:37 -0700 (PDT)
In-Reply-To: <8D925D4C0B78EE41857D407022ECD163BFEE9009@SZXEMI501-MBX.china.huawei.com>
References:  <8D925D4C0B78EE41857D407022ECD163BFEE9009@SZXEMI501-MBX.china.huawei.com>
From: Eric Rescorla 
Date: Thu, 29 Oct 2015 15:10:37 +0900
Message-ID: 
To: Jayaraghavendran k 
Content-Type: multipart/alternative; boundary=94eb2c07c35ec9af1c0523382dff
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Oct 2015 06:11:20 -0000

--94eb2c07c35ec9af1c0523382dff
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 29, 2015 at 3:04 PM, Jayaraghavendran k <
jayaraghavendran.k@huawei.com> wrote:

> Hi Eric,
>
>
>
> Thanks for your response.
>
>
>
> 1. There is already no requirement that you have an explicit nonce. RFC52=
46
>
> merely requires that you specify the length of the explicit nonce, but th=
at
>
> length can be 0, as it is in the ChaCha/Poly drafts. So, rather than buil=
d
>
> an extension it would be better to just define a new cipher suite if you
> think
>
> this is important.
>
> [Jay]: The extension idea was mainly for the already defined ciphers in
> RFC 6655 (for AES_CCM usage in TLS) & RFC 5288 (for AES_GCM usage in TLS)=
.
> Both these RFCs state that an explicit nonce of 8 bytes MUST be carried i=
n
> each record. So, in these cases to avoid the overhead, the options as I
> understand are defining a new extension or a new cipher suite (which
> suggests the new explicit nonce generation mechanism and makes the record
> iv length as 0).
>

Yes, but we're already defining new cipher suites with that
(e.g., ChaCha). So given the small number of AEAD cipher
suites, defining a new cipher suite seems better.



> This new extension is more like a framework for negotiating the type of
> explicit nonce generation mechanisms. If a particular way of generating t=
he
> explicit nonce is found to be exploitable in future, a new mechanism can =
be
> defined and negotiated through the extension.  Defining  a new cipher for
> each new mechanism of explicit nonce generation may increase the number o=
f
> ciphers that the client has to carry in it=E2=80=99s client hello by a go=
od amount
> (considering, it needs to carry old ciphers also for backward compatibili=
ty
> with servers not supporting new ciphers).
>

Defining a whole pile of explicit nonce generation mechanisms seems
bad. If we actually run into a situation where the hardcoded nonce
generation technique is broken, we can define an extension then



>
> 2. TLS 1.3 already omits the explicit nonce entirely.
>
> [Jay]:  My primary goal is for DTLS 1.2 which is used with CoAP in variou=
s
> IoT Scenarios. Usage of DTLS 1.2 with CoAP has already started in many
> products I believe and DTLS 1.3 may take some time and will not be
> immediately adapted by products already released.
>

Seems like this gives them an incentive to move to 1.3.

-Ekr

Requesting your suggestions in the above context.
>
>
>
> Thanks Again.
>
>
>
> Best Regards,
>
> Jay
>
>
> *************************************************************************=
**************
> This e-mail and 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:* TLS [mailto:tls-bounces@ietf.org ] *On
> Behalf Of *Eric Rescorla
> *Sent:* 24 October 2015 01:35
> *To:* tls@ietf.org;
> draft-jay-tls-omit-aead-explicit-nonce-extension@tools.ietf.org
> *Subject:* [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
>
>
>
> I took a quick look at this draft and IMO it is unnecessary, for two
> reasons:
>
>
>
> 1. There is already no requirement that you have an explicit nonce. RFC52=
46
>
> merely requires that you specify the length of the explicit nonce, but th=
at
>
> length can be 0, as it is in the ChaCha/Poly drafts. So, rather than buil=
d
>
> an extension it would be better to just define a new cipher suite if you
> think
>
> this is important.
>
>
>
> 2. TLS 1.3 already omits the explicit nonce entirely.
>
>
>
> -Ekr
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c07c35ec9af1c0523382dff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 29, 2015 at 3:04 PM, Jayaraghavendran k &=
lt;jayar=
aghavendran.k@huawei.com> wrote:











Hi Eric,


=C2=A0


Thanks for your response.



=C2=A0


1. There is already no requirement that you h=
ave an explicit nonce. RFC5246


merely requires that you specify the length of the e=
xplicit nonce, but that


length can be 0, as it is in the ChaCha/Poly drafts.=
 So, rather than build


an extension it would be better to just define a new=
 cipher suite if you think


this is important.


[Jay]: The extensi=
on idea was mainly for the already defined ciphers in RFC 6655 (for AES_CCM=
 usage in TLS) & RFC 5288 (for AES_GCM usage in TLS). Both these
 RFCs state that an explicit nonce of 8 bytes MUST be carried in each recor=
d. So, in these cases to avoid the overhead, the options as I understand ar=
e defining a new extension or a new cipher suite (which suggests the new ex=
plicit nonce generation mechanism
 and makes the record iv length as 0).
<=
div>
Yes, but we're already defining new cipher suites wi=
th that
(e.g., ChaCha). So given the small number of AEAD cipher<=
/div>
suites, defining a new cipher suite seems better.

<=
/div>
=C2=A0


This new extension is mor=
e like a framework for negotiating the type of explicit nonce generation me=
chanisms. If a particular way of generating the explicit
 nonce is found to be exploitable in future, a new mechanism can be defined=
 and negotiated through the extension.=C2=A0 Defining=C2=A0 a new cipher fo=
r each new mechanism of explicit nonce generation may increase the number o=
f ciphers that the client has to carry in
 it=E2=80=99s client hello by a good amount (considering, it needs to carry=
 old ciphers also for backward compatibility with servers not supporting ne=
w ciphers).

D=
efining a whole pile of explicit nonce generation mechanisms seems
bad. If we actually run into a situation where the hardcoded nonce
<=
div>generation technique is broken, we can define an extension then




=C2=A0


2. TLS 1.3 already omits the explicit nonce e=
ntirely.


[Jay]: =C2=A0My primary g=
oal is for DTLS 1.2 which is used with CoAP in various IoT Scenarios. Usage=
 of DTLS 1.2 with CoAP has already started in many products I
 believe and DTLS 1.3 may take some time and will not be immediately adapte=
d by products already released.
Seems like this gives them an incentive to move to 1.3.

-Ekr

<=
div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">


Requesting your suggestio=
ns in the above context.


=C2=A0


Thanks Again.


=C2=A0


Best Regards,


Jay<=
/p>

***************************=
************************************************************

This e-mail and attachments contain confidential information from HUAWEI, w=
hich is intended only for the person or entity whose address is listed abov=
e. Any use of the information contained herein in any way (including, but n=
ot limited to, total or partial
 disclosure, reproduction, or dissemination) by persons other than the inte=
nded recipient's) is prohibited. If you receive this e-mail in error, p=
lease notify the sender by phone or email immediately and delete it!

***************************************************************************=
************


=C2=A0




From: TLS [mailto:tls-bounces@i=
etf.org]
On Behalf Of Eric Rescorla

Sent: 24 October 2015 01:35

To: tls@ietf.org; 
draft-jay-tls-omit-aead-explicit-nonce-extension@tools.ietf.org

Subject: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension




=C2=A0




I took a quick look at this draft and IMO it is unne=
cessary, for two reasons:




=C2=A0






1. There is already no requirement that you have an =
explicit nonce. RFC5246






merely requires that you specify the length of the e=
xplicit nonce, but that






length can be 0, as it is in the ChaCha/Poly drafts.=
 So, rather than build






an extension it would be better to just define a new=
 cipher suite if you think






this is important.






=C2=A0






2. TLS 1.3 already omits the explicit nonce entirely=
.






=C2=A0






-Ekr






=C2=A0








=C2=A0






=C2=A0













_______________________________________________

TLS mailing list

TLS@ietf.org

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





--94eb2c07c35ec9af1c0523382dff--


From nobody Thu Oct 29 01:33:54 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8A1B2AF9 for ; Thu, 29 Oct 2015 01:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 8IePXNH-F1UA for ; Thu, 29 Oct 2015 01:33:51 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 129021B2AF6 for ; Thu, 29 Oct 2015 01:33:51 -0700 (PDT)
Received: by ykft191 with SMTP id t191so34901282ykf.0 for ; Thu, 29 Oct 2015 01:33: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:content-type; bh=i3to58R09sssTHtvey3f0dMukWBE/w/Apdiv0xeqOe0=; b=P1pc2pRa+syrZxvLu2ER2lc6HNgxT8kgMlah4emELfkT2pZK0OAguqzZlxniksc1sG SIyZzxf+wGKaEJKir3LBXA5m8o3b3f11AQ+xXBCw9w6b77FHymIpN0YajapTS5imDwHU eoODUHRfSad6CvG7zQbNqy+uS+e/6H85bmEA/nIMp0+v+OHX9FrVLhl35U3c7xOfZ0SW /83ItWtF+pgmGIZsAcifh1lJp/zJ+wJ/0O3fsW5LgKg7X3RgxqeGHC/SVNlyTxph02dh 0xcSthbEZhKR1vU8EaiKlKC/ebwy2GJpSJewt8ueJFyMIYJBibzDXDSZ6z8d4Q+Juz0X tSIg==
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-type; bh=i3to58R09sssTHtvey3f0dMukWBE/w/Apdiv0xeqOe0=; b=QEOPbqVdT6y6xcBpnl23+asr+m+6Wgf/lP8eS3VeXVZVpUKWju8hhdqAWzrsVjrcZP n4lrTYoJgVI3KdISyCqxWZ/7J3TOnplz6wzbMDdekn429OIpzAR+ZDtYWnsjcvhGMNJz eXl618tia/qqPIaKF4i9TtDtnCLz3ybob8I2z6f1PZFQH8s3oMI3S3Vhr3OsidI4eV+E ED7bjYnxeTg3/Gl4N3rvKYiIsHtqXS34F97+AKiUJQwPS/MEOMN5zje9pmEZCngmxyHB Si0UVCj4Mu2G0HRz5p0r+s88wnUJ8ZWiumBrjWAUqYzeUyY9hmyRMCCLnH2GxGLJP/4U H7mg==
X-Gm-Message-State: ALoCoQl/HsLStuyMHuYC1OELW2xiQS8zbeORk3sQyABBos307BPSeqy4Vauu9hBVhh8isSVrVYsA
X-Received: by 10.129.130.6 with SMTP id s6mr331512ywf.155.1446107630354; Thu, 29 Oct 2015 01:33:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 29 Oct 2015 01:33:10 -0700 (PDT)
In-Reply-To: 
References:        <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com>   <20151027150915.GA8140@LK-Perkele-V2.elisa-laajakaista.fi>   
From: Eric Rescorla 
Date: Thu, 29 Oct 2015 17:33:10 +0900
Message-ID: 
To: Adam Langley 
Content-Type: multipart/alternative; boundary=94eb2c07c35e9d725405233a2b4a
Archived-At: 
Cc: "David McGrew \(mcgrew\)" , "tls@ietf.org" 
Subject: Re: [TLS] Version in record MAC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Oct 2015 08:33:52 -0000

--94eb2c07c35e9d725405233a2b4a
Content-Type: text/plain; charset=UTF-8

Per discussion with Sean, I've merged this at:
https://github.com/tlswg/tls13-spec/commit/5f30bca74fdf8ded2bf50b112487ca780faa52ef

On Wed, Oct 28, 2015 at 3:53 AM, Eric Rescorla  wrote:

> Sure. Like I said, I don't feel strongly about this, I just wanted to take
> people's
> temperature. I'm find with removing the seq from the AD.
>
> -Ekr
>
> On Tue, Oct 27, 2015 at 2:49 PM, Adam Langley 
> wrote:
>
>> On Tue, Oct 27, 2015 at 8:56 AM, Eric Rescorla  wrote:
>> > Yes, that's correct. But we could relax that restriction and make those
>> work
>> > if we wanted...
>>
>> Explicit nonces should not be used in TLS. I'm happy to be building
>> things without them in mind.
>>
>> SIV modes, if turned into AEADs, would have to authenticate their
>> nonces internally. RFC 5297 basically says that already
>> (https://tools.ietf.org/html/rfc5297#section-3). That might mean that
>> the nonce is prepended to the AD inside the AEAD abstraction, but that
>> wouldn't be TLS's concern.
>>
>>
>> Cheers
>>
>> AGL
>>
>> --
>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>>
>
>

--94eb2c07c35e9d725405233a2b4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Oct 28, 2015 at 3:53 AM, Eric Rescorla=
 <ek=
r@rtfm.com> wrote:
Sure. Like I said, I don't feel str=
ongly about this, I just wanted to take people's
temperature. I'm find with removing the seq from the AD.

-Ekr
=


On Tue, Oct 27, 2015 at 2:49 PM, Ada=
m Langley <agl@imperialviolet.org> wrote:
On Tue, Oct 27, 2015 at 8:56 AM, Eric Rescorla &=
lt;ekr@rtfm.com> w=
rote:

> Yes, that's correct. But we could relax that restriction and make =
those work

> if we wanted...



Explicit nonces should not be used in TLS. I'm happy to be build=
ing

things without them in mind.



SIV modes, if turned into AEADs, would have to authenticate their

nonces internally. RFC 5297 basically says that already

(https://tools.ietf.org/html/rfc5297#section-3). Th=
at might mean that

the nonce is prepended to the AD inside the AEAD abstraction, but that

wouldn't be TLS's concern.







--94eb2c07c35e9d725405233a2b4a--


From nobody Thu Oct 29 07:08:04 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90B91B2EA9 for ; Thu, 29 Oct 2015 07:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD9d1_q6rSDR for ; Thu, 29 Oct 2015 07:08:01 -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 ABFCB1B2EA8 for ; Thu, 29 Oct 2015 07:08:01 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 15387915A0; Thu, 29 Oct 2015 14:08:01 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-148.brq.redhat.com [10.34.0.148]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9TE7xtA007097 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 29 Oct 2015 10:08:00 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Thu, 29 Oct 2015 15:07:58 +0100
Message-ID: <9215448.5unqnllp7J@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.2.3-200.fc22.x86_64; KDE/4.14.11; x86_64; ; )
In-Reply-To: <201510212017.31856.davemgarrett@gmail.com>
References: <20151021204320.0CECD18046A@rfc-editor.org>  <201510212017.31856.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1823472.s3P9e4kDfS"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: 
Cc: agl@google.com
Subject: Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Oct 2015 14:08:03 -0000

--nextPart1823472.s3P9e4kDfS
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote:
> Congrats on releasing an RFC that has day one 100% server support. :p=


oh, I'm sure there's at least one server out there that is intolerant t=
o=20
this one specific 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 Republi=
c
--nextPart1823472.s3P9e4kDfS
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

iQIcBAABCgAGBQJWMig+AAoJEJKo0bgB0vX1oSwP/RhAVDQM2P5/fFsmGicUdawG
gfMh3uYHB5i+hF/lNcUJhEDsNm8imK6Hsm72V1IHNktUbyYPNxXEaJXGIrnyfLMF
7lj3nQRaPBNBsVNd+h+i9nxnvWIEJsUj+g1CntXMc2+dd/77wOamhk+du7BJP++3
1364RLUzSkOo7yhDYVA3B1z2ybm/tEf0MV6TwOLsPpQ6CHMqda+svVkt2Jr4Db2Z
miTGiqjUfJI/XUY0EFzXYdcqjZjzx7WNbyj3G1LPGUQGSy6s/+v4o7nR6exNa5Ml
JRIbCkjp7jNDI3n8fk0IlLw/1bOpU8ciOWngPDdwfsRtIupN5a+RahAdcsZ4DIxo
cRt3oSVhMsbCWvwc6iYInZjM/iCwRond1a6WxQWKec4tzYKrExBv5cEV4P01fomU
fpZtJBir3HEDfS4LKUfwk4dDnN2kWVlc6KhOSw0iTy2Lvj5sVme1I9C8kKLXBcJL
YKbB7qn4oBgUG5yX84j0mzh/Z2dWJr/anzIRkm6BaorNIOgQroeEFCx2p2H/DA+k
Zkq5a8M+mejjCz0ukZrNE36IjMzdcyhta9dj+ImjawOiMdiQD1cZqjELN9F3p+ZU
H21EYT9uielVjmz4Ok7yMVbkeOcOr9YVt41sKBuYUOdaJeRf8C4SuxqHFb8V5RKB
Mpl5W/5l147s9CsLw8eS
=7dcN
-----END PGP SIGNATURE-----

--nextPart1823472.s3P9e4kDfS--


From nobody Thu Oct 29 08:00:13 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348791A8763 for ; Thu, 29 Oct 2015 08:00:07 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrDklAmOlm6z for ; Thu, 29 Oct 2015 08:00:05 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF611A8771 for ; Thu, 29 Oct 2015 08:00:05 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 35A22284AED; Thu, 29 Oct 2015 15:00:04 +0000 (UTC)
Date: Thu, 29 Oct 2015 15:00:04 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20151029150003.GB5570@mournblade.imrryr.org>
References: <20151021204320.0CECD18046A@rfc-editor.org>  <201510212017.31856.davemgarrett@gmail.com> <9215448.5unqnllp7J@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9215448.5unqnllp7J@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list 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, 29 Oct 2015 15:00:07 -0000

On Thu, Oct 29, 2015 at 03:07:58PM +0100, Hubert Kario wrote:

> On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote:
> > Congrats on releasing an RFC that has day one 100% server support. :p
> 
> oh, I'm sure there's at least one server out there that is intolerant to 
> this one specific extension ]:->

When the extension was first enabled in OpenSSL 1.0.1g there were
(and perhaps some are still left unpatched) Cisco IronPort SMTP
servers that could not handle the extension.

A fix was issued promptly, but customers did need to find out about
it and apply it.

-- 
	Viktor.


From nobody Thu Oct 29 08:56:32 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266B1A894A for ; Thu, 29 Oct 2015 08:56:31 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkEsr4LRxb7Q for ; Thu, 29 Oct 2015 08:56:30 -0700 (PDT)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::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 0A1C01A8940 for ; Thu, 29 Oct 2015 08:56:30 -0700 (PDT)
Received: by ykft191 with SMTP id t191so46903969ykf.0 for ; Thu, 29 Oct 2015 08:56:29 -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-type:content-transfer-encoding:message-id; bh=GxVASUGyha4O34zYIzKiS/jMC7DYE1r8kSD8e1/tSwc=; b=L+tIypUPbKzEmztFFilWRM0ROIfdg7vl1OwWOXK8V6qz/WoxqQGERip2fmmLA2fcF6 FO70oyoqIBpFSrrE3bP6peeG0ymfnT9hn7d4pJKEkY0FiAEjbm/DNSM+kpZ4dpNYFQtJ cJjQ2I4cUH0HkKcC5WDPwTEGcSyZA+PlOsvLE1htJXM7KTSFM4kUBl0NbOgztsUVqtVR tC4bWR18ibXdNS2g1dPuwf9LoCKKz1+p7bUH7iITlq375gjKo0P++Z9Ft0CWB8Vm2YR7 jcwKjWNwk/waefsLggLgn2/T1ZFJ98tIzReyiFVi+oIiSC6O/75eNuRmx7+HAV/3TkZ5 Cn2w==
X-Received: by 10.129.133.195 with SMTP id v186mr2000686ywf.40.1446134188999;  Thu, 29 Oct 2015 08:56:28 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id k16sm1169570ywe.48.2015.10.29.08.56.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Oct 2015 08:56:28 -0700 (PDT)
From: Dave Garrett 
To: Viktor Dukhovni 
Date: Thu, 29 Oct 2015 11:56:27 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20151021204320.0CECD18046A@rfc-editor.org> <9215448.5unqnllp7J@pintsize.usersys.redhat.com> <20151029150003.GB5570@mournblade.imrryr.org>
In-Reply-To: <20151029150003.GB5570@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201510291156.27492.davemgarrett@gmail.com>
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 29 Oct 2015 15:56:31 -0000

On Thursday, October 29, 2015 11:00:04 am Viktor Dukhovni wrote:
> On Thu, Oct 29, 2015 at 03:07:58PM +0100, Hubert Kario wrote:
> > On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote:
> > > Congrats on releasing an RFC that has day one 100% server support. :p
> > 
> > oh, I'm sure there's at least one server out there that is intolerant to 
> > this one specific extension ]:->
> 
> When the extension was first enabled in OpenSSL 1.0.1g there were
> (and perhaps some are still left unpatched) Cisco IronPort SMTP
> servers that could not handle the extension.

Now I'm just curious: How? Where they essentially just intolerant to _any_ new extension or one of a certain length?


Dave


From nobody Thu Oct 29 09:35:28 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3E1A90AC for ; Thu, 29 Oct 2015 09:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.478
X-Spam-Level: 
X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URI_HEX=1.122] autolearn=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 DCuvGOXtqako for ; Thu, 29 Oct 2015 09:35:19 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292651B2F8B for ; Thu, 29 Oct 2015 09:35:19 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1210D284AED; Thu, 29 Oct 2015 16:35:18 +0000 (UTC)
Date: Thu, 29 Oct 2015 16:35:18 +0000
From: Viktor Dukhovni 
To: tls@ietf.org
Message-ID: <20151029163517.GE5570@mournblade.imrryr.org>
References: <20151021204320.0CECD18046A@rfc-editor.org> <9215448.5unqnllp7J@pintsize.usersys.redhat.com> <20151029150003.GB5570@mournblade.imrryr.org> <201510291156.27492.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201510291156.27492.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Subject: Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list 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, 29 Oct 2015 16:35:21 -0000

On Thu, Oct 29, 2015 at 11:56:27AM -0400, Dave Garrett wrote:

> On Thursday, October 29, 2015 11:00:04 am Viktor Dukhovni wrote:
> > On Thu, Oct 29, 2015 at 03:07:58PM +0100, Hubert Kario wrote:
> > > On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote:
> > > > Congrats on releasing an RFC that has day one 100% server support. :p
> > > 
> > > oh, I'm sure there's at least one server out there that is intolerant to 
> > > this one specific extension ]:->
> > 
> > When the extension was first enabled in OpenSSL 1.0.1g there were
> > (and perhaps some are still left unpatched) Cisco IronPort SMTP
> > servers that could not handle the extension.
> 
> Now I'm just curious: How? Where they essentially just intolerant to _any_ new extension or one of a certain length?

I think it was the resulting client HELLO length (512+ bytes), but
I don't recall seeing the details explained.

    http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html
    http://openssl.6102.n7.nabble.com/openssl-update-1-0-1f-to-1-0-1g-broke-sendmail-SSL23-GET-SERVER-HELLO-tlsv1-alert-decode-error-td49242.html
    https://www.mail-archive.com/search?l=openssl-dev@openssl.org&q=subject:%22Re%3A+[openssl.org+%233336]+1.0.1g+breaks+IronPORT+SMTP+appliance+%28padding+extension%29%22&o=newest&f=1

If John Foley from Cisco is on this list, perhaps he'll be willing
to elaborate.

-- 
	Viktor.


From nobody Fri Oct 30 12:35:04 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303C71B3AFA for ; Fri, 30 Oct 2015 12:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfWanNW93vme for ; Fri, 30 Oct 2015 12:35:01 -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 DEEAA1B3AF9 for ; Fri, 30 Oct 2015 12:35:01 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 09856C0BAA16; Fri, 30 Oct 2015 19:35:01 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-112-76.ams2.redhat.com [10.36.112.76]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9UJYusD006527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2015 15:35:00 -0400
From: Hubert Kario 
To: tls@ietf.org
Date: Fri, 30 Oct 2015 20:34:48 +0100
Message-ID: <10717197.NzmEmjUmiF@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.9 (Linux/4.2.3-200.fc22.x86_64; KDE/4.14.11; x86_64; ; )
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1634832.tej1drhJUj"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: 
Subject: Re: [TLS] Controlling use of SHA-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 30 Oct 2015 19:35:03 -0000

--nextPart1634832.tej1drhJUj
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Thursday 22 October 2015 14:49:47 Bill Frantz wrote:
> On 10/23/15 at 2:02 PM, ynir.ietf@gmail.com (Yoav Nir) wrote:
> >That is true only if your application=E2=80=99s client component and=

> >server component are using the same library. That is not
> >guaranteed in a protocol. Specifically that is not the case
> >with the web.
> >
> >There are some version intolerant servers out there that will
> >choke on seeing a TLS 1.3 ClientHello. If the client uses some
> >library (like OpenSSL) and you upgrade to OpenSSL 1.2.0 that
> >has TLS 1.3. All of the sudden your application is broken. On
> >the web this means that some websites don=E2=80=99t work.
>=20
> This incompatibility cuts both ways. Another way of looking at
> it is that all of a sudden your website has lost viewers and you
> should fix your problem. Perhaps I am unusual, but if I go the a
> website that doesn't work, I usually conclude that I don't need
> to see that web site. My problem is too little time, meaning I
> don't want to bleep with things that don't work, not extra time
> to futz with different browsers to get things working.

Until you have to get a refund on a $500 purchase through such broken=20=

web server...

=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 Republi=
c
--nextPart1634832.tej1drhJUj
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

iQIcBAABCgAGBQJWM8ZYAAoJEJKo0bgB0vX1isMP/iVlN4gWh3LE3BAIE39Bt3G6
P3OPbgvNllId/Z/dkqMksw2jC34m8TZxC9fJNNe2Sy5JB8YkaoH/qjmzsSmnLcQL
ZI0mcxvoKQrh87uZk3VmmBr5TUKLQKCfdz4iy2BOIUuF/VBxumZqm8pge/kWf7hN
JFcDQqru717cfueh8TJ+hisjau5kwDDd1al8oiVEXIoV8Me5QPLh2QTMuJZ5UZeM
xwuS834XjJE2l34VqLbazKYowwganCRfZRby5EqMpSUa15zndKjy4D2G1kF3l+r8
2Xp+lj4LEAqLLr+YqAXUQy0Dw/y+ZJ/cl9y1jIBm/g9BVtbc2ESfKOz63P30CTwO
hdyfXzEK3KbmMSgzz+h/Gpoxb4BBRUeq6TpxjdhgdRBhLxmX3fG+TjzpfoAeWSL/
+1QVncFzHXdG15K+XkLq6eE/ntnmpgVA1zpCzb9MfDBI3VqKJVRHMdwE9f3ogY2T
UdaAViXrhxDlwM0GrDbvehW8MXjdYlccBWs8dOm/3vdamRl157urA1clE1M6khwx
cbxwaoyUgnxEOj+KwtKJGHNt2vHErmknkqWfhO2mo9z+vUBMPjvm5ENhfDeynyGQ
m06sQ5or4t/zULtZxqmLaVlJUDkrYmZk9o264+4MFzB6sUlHRd2BVb3eRE0SAP3R
YcN2hTVzq3Aw1lfY+Zm6
=A5yV
-----END PGP SIGNATURE-----

--nextPart1634832.tej1drhJUj--


From sam.scott89@gmail.com  Sat Oct 31 04:19:25 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B221B3792 for ; Sat, 31 Oct 2015 04:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level: 
X-Spam-Status: No, score=-1.149 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, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=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 gXoZr8lg_teU for ; Sat, 31 Oct 2015 04:19:23 -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 B712B1B377F for ; Sat, 31 Oct 2015 04:19:22 -0700 (PDT)
Received: by wmll128 with SMTP id l128so28961738wml.0 for ; Sat, 31 Oct 2015 04:19:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:subject:to:message-id:date:user-agent:mime-version :content-type; bh=D7XfdGf/lbJoGa1226zEtY/pzsYNaGU6p3a4dIdwRjA=; b=Vkh9fKIyf+LMPdkW1De0yXG0Hg2PsQwHcMMTwFs1oxWZTS69tY2VyGmWxkSihaKiLP 4xF+AVJ20QqK2I1K5l0CDlrHqdJdQxSv57ywiRds9MIOJPhkn7fYOQGOz9H3ToS+iurU vioV+gyBxakpOfajGbcbLPQDPUicov4M2AZVxRxjQkzHhCxEmPePe1svlPAnBb8n9RDT MPVzbZnsa+DqF+kZ5q0USEh4HvZYW6hK8fKljkVj5OtSeVwLE7cUEQUoxFJa8V/z6wia idNzDcb8oSoUrbBBliRodukrUfXEkhW13a4Ifch7Na5KIDj8LKnsrsBgPNPVizas29gR Ob9Q==
X-Received: by 10.28.143.79 with SMTP id r76mr3378504wmd.102.1446290361376; Sat, 31 Oct 2015 04:19:21 -0700 (PDT)
Received: from [192.168.0.11] (97e4ce0a.skybroadband.com. [151.228.206.10]) by smtp.gmail.com with ESMTPSA id 5sm7435727wmg.14.2015.10.31.04.19.20 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Oct 2015 04:19:20 -0700 (PDT)
From: Sam Scott 
To: tls@ietf.org
Message-ID: <5634A3B8.7070701@gmail.com>
Date: Sat, 31 Oct 2015 11:19:20 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------060906030009050808090007"
Archived-At: 
Subject: [TLS] Revision 10: possible attack if client authentication is allowed during PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Oct 2015 11:20:33 -0000

This is a multi-part message in MIME format.
--------------060906030009050808090007
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

We [1] are in the process of performing an automated symbolic analysis
of the TLS 1.3 specification draft (revision 10) using the Tamarin
prover [2], which is a tool for automated security protocol analysis.

While revision 10 does not yet appear to permit certificate-based client
authentication in PSK (and in particular resumption using PSK), we modelled
what we believe is the intended functionality. By enabling client
authentication either in the initial handshake, or with a post- handshake
signature over the handshake hash, our Tamarin analysis finds an attack. The
result is a complete breakage of client authentication, as the attacker can
impersonate a client when communicating with a server:

Suppose a client Alice performs an initial handshake with Charlie. Charlie,
masquerading as Alice, subsequently performs a handshake with Bob. 
Following a
PSK resumption, Bob requests authentication from Charlie (impersonating 
Alice).
Charlie then requests authentication from Alice, and the returned signature
will also be a valid signature for the session with Bob.

         Initial h/s Initial h/s
      |<-------------->| |<-------------->|
      |  exchange PSK  |                               | exchange PSK  |
      |                | |                |
      |Start PSK resume| |Start PSK resume|
      |--------------->| |--------------->|
      |client_random nc| |client_random nc|
      |                | |                |
      |  Accept resume |                               | Accept resume |
Alice|<---------------|(as Charlie) Charlie (as Alice)|<---------------|Bob
      |server_random ns| |server_random ns|
      |                | |                |
      |                | |                |
      |Client auth req | |Client auth req |
      |<---------------| |<---------------|
      |                | |                |
      |  Client auth   |                               | Client auth   |
      |--------------->| |--------------->|
        sign nc,ns,... relay signature



This attack is possible because the client signature is over the handshake
hash, which only covers the nonces and other easily duplicated information,
and in particular does not contain the server certificate (because none is
presented in PSK mode [3]) or the server Finished.

While the modifications proposed in PR#316 [4] explicitly allow client
authentication in these contexts, the PR also redefines the client signature
based on a new "Handshake Context" value which includes the server Finished
message. Intuitively, this new definition appears to address the attack
because the attacker cannot transplant the Finished message between
connections. We are currently working towards a Tamarin proof that PR#316
indeed prevents our attack.

Therefore we would like to support the inclusion of Finished as
part of the handshake context, in order to address this problem.

Many thanks,

Sam Scott

[1] Cas Cremers, Marko Horvat - University of Oxford;
     Thyla van der Merwe, Sam Scott - Royal Holloway, University of London.
[2] http://www.infsec.ethz.ch/research/software/tamarin.html
[3] Except in 0-RTT where the server's Certificate is explicitly
     included.
[4] https://github.com/tlswg/tls13-spec/pull/316/

--------------060906030009050808090007
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all,

    

    We [1] are in the process of performing an automated
      symbolic analysis

    of the TLS 1.3 specification draft (revision 10) using the
      Tamarin

    prover [2], which is a tool for automated security protocol
      analysis.

    

    While revision 10 does not yet appear to permit
      certificate-based client

    authentication in PSK (and in particular resumption using
      PSK), we modelled

    what we believe is the intended functionality. By enabling
      client

    authentication either in the initial handshake, or with a
      post- handshake

    signature over the handshake hash, our Tamarin analysis
      finds an attack. The

    result is a complete breakage of client authentication, as
      the attacker can

    impersonate a client when communicating with a server:

    

    Suppose a client Alice performs an initial handshake with
      Charlie. Charlie,

    masquerading as Alice, subsequently performs a handshake
      with Bob. Following a

    PSK resumption, Bob requests authentication from Charlie
      (impersonating Alice).

    Charlie then requests authentication from Alice, and the
      returned signature

    will also be a valid signature for the session with Bob.

    

            Initial h/s                                     
      Initial h/s

         |<-------------->|                              
      |<-------------->|

         |  exchange PSK  |                               | 
      exchange PSK  |

         |                |                              
      |                |

         |Start PSK resume|                              
      |Start PSK resume|

         |--------------->|                              
      |--------------->|

         |client_random nc|                              
      |client_random nc|

         |                |                              
      |                |

         |  Accept resume |                               | 
      Accept resume |

    Alice|<---------------|(as Charlie) Charlie (as
      Alice)|<---------------|Bob

         |server_random ns|                              
      |server_random ns|

         |                |                              
      |                |

         |                |                              
      |                |

         |Client auth req |                              
      |Client auth req |

         |<---------------|                              
      |<---------------|

         |                |                              
      |                |

         |  Client auth   |                               | 
      Client auth   |

         |--------------->|                              
      |--------------->|

           sign nc,ns,...                                 
      relay signature

    

    

    

    This attack is possible because the client signature is
      over the handshake

    hash, which only covers the nonces and other easily
      duplicated information,

    and in particular does not contain the server certificate
      (because none is

    presented in PSK mode [3]) or the server Finished.

    

    While the modifications proposed in PR#316 [4] explicitly
      allow client

    authentication in these contexts, the PR also redefines the
      client signature

    based on a new "Handshake Context" value which includes the
      server Finished

    message. Intuitively, this new definition appears to
      address the attack

    because the attacker cannot transplant the Finished message
      between

    connections. We are currently working towards a Tamarin
      proof that PR#316

    indeed prevents our attack.

    

    Therefore we would like to support the inclusion of
      Finished as

    part of the handshake context, in order to address this
      problem.

    

    Many thanks,

    

    Sam Scott

    

    [1] Cas Cremers, Marko Horvat - University of Oxford;

        Thyla van der Merwe, Sam Scott - Royal Holloway,
      University of London.

    [2]
      http://www.infsec.ethz.ch/research/software/tamarin.html

    [3] Except in 0-RTT where the server's Certificate is
      explicitly

        included.

    [4] https://github.com/tlswg/tls13-spec/pull/316/
  


--------------060906030009050808090007--


From nobody Sat Oct 31 06:32:41 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3441B2BCF for ; Sat, 31 Oct 2015 06:32:39 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyP_C030i8cj for ; Sat, 31 Oct 2015 06:32:37 -0700 (PDT)
Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10A1B2BBF for ; Sat, 31 Oct 2015 06:32:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 7E27319BD3A; Sat, 31 Oct 2015 15:32:34 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id RV31YzhjPl77; Sat, 31 Oct 2015 15:32:34 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 5539C5BC00A; Sat, 31 Oct 2015 15:32:34 +0200 (EET)
Date: Sat, 31 Oct 2015 15:32:31 +0200
From: Ilari Liusvaara 
To: Sam Scott 
Message-ID: <20151031133231.GB12538@LK-Perkele-V2.elisa-laajakaista.fi>
References: <5634A3B8.7070701@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5634A3B8.7070701@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Oct 2015 13:32:39 -0000

On Sat, Oct 31, 2015 at 11:19:20AM +0000, Sam Scott wrote:
> Dear all,
> 
> While revision 10 does not yet appear to permit certificate-based client
> authentication in PSK (and in particular resumption using PSK), we modelled
> what we believe is the intended functionality.

Eh, I thought that using static client certificate auth with PSK is not
supposed to be possible.

BTW: TLS 1.2 doesn't seem to explicitly prohibit client auth with PSK, and
if client and server try to use client certs with PSK, bad things happen...

> While the modifications proposed in PR#316 [4] explicitly allow client
> authentication in these contexts, the PR also redefines the client signature
> based on a new "Handshake Context" value which includes the server Finished
> message. Intuitively, this new definition appears to address the attack
> because the attacker cannot transplant the Finished message between
> connections. We are currently working towards a Tamarin proof that PR#316
> indeed prevents our attack.

By my reading, #316 does not permit static client authentication with
PSK (it only permits dynamic auth, which didn't even exist previously),
most definitely not explicitly.

Also, found out that -10 looks to be at least unclear about if the
server Finished is included in the data to be signed or not...

I also searched when this got broken. Looks to be part of "DH-based
key exchange" changes in -07 (in -06, hashes definitely did include
finished messages).


-Ilari


From nobody Sat Oct 31 06:56:09 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E711B37D5 for ; Sat, 31 Oct 2015 06:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level: 
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] autolearn=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 r5lA618Crx_L for ; Sat, 31 Oct 2015 06:56:05 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002: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 CDE9C1B37DA for ; Sat, 31 Oct 2015 06:56:04 -0700 (PDT)
Received: by ykft191 with SMTP id t191so101528156ykf.0 for ; Sat, 31 Oct 2015 06:56:04 -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:content-type; bh=RpPcJXD+MjmAH2Z0857l7rpCOV3hrU0vvKFCUSDaXGI=; b=iTHlq1h+p/bk2guSzawGOmUVN/IN6yfer8hs8/Sguz0qxze/Vb9jseuybZbrjapfnq hKvu8o5rtL38jZNgVabHdCuxjNXsUP8ZYGIoZEVGnp1GivV2vRser6N8GC1SWj35tLh0 Seq+lqEDKuDtAY8uZiVCYzQWVZAIXiWd/kAFtcMwqW1NDbHaxaoyCMwbxaTw5MjUhp0o W2QQZtdRrkYnwQZ/rKFEqruxmicu3dWB9xsYHm9fE+ob5Zwb57H4DTnFlinHc0mnlOOO OLqxB9v/YGkDIU8EWUkoeaQIn9MQ9hCDznfC2ez9NnMxOaX8C2cmkKVyD0/joJ+q2NCg wCPw==
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-type; bh=RpPcJXD+MjmAH2Z0857l7rpCOV3hrU0vvKFCUSDaXGI=; b=cETiAq6AkBN0Pgij33KwwN7kVcBRDAbTyg5xuM1mOPhy5ENnSWFtGdiBOIi4/R0erH eqJx/CaAVmgvQGv3pN7Zyt4tFsgGTu4RCARWRkw9lycvAm84w78+vqiRZigeYH+FaV2p MbKbT7We6ZfSQgwTlhqelV7IcCpUrtNS0HS8tRz7zUcF9rneAjc8c9Hc76L+Me9+Pscu xHqU8B9Q20OWRkuZxkk+ZB43knBEHtry/2JZcemTzIs0dXG8VomtILFh5PBjfl2/xvwx o42cL7m44OouhCS4NWMeHxAXw13Oo2c43gQfEddVreEugNArWjAYcL/sQSirEMR7qNQl LwJQ==
X-Gm-Message-State: ALoCoQmV3d7DfnqLtrizrT7yV6LUDmjMPTHaekfJM6GFOT94rW8gqGNlnpiefG2Q+dtL+PtDy8Kl
X-Received: by 10.129.130.6 with SMTP id s6mr10131878ywf.155.1446299764061; Sat, 31 Oct 2015 06:56:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Sat, 31 Oct 2015 06:55:24 -0700 (PDT)
In-Reply-To: <5634A3B8.7070701@gmail.com>
References: <5634A3B8.7070701@gmail.com>
From: Eric Rescorla 
Date: Sat, 31 Oct 2015 22:55:24 +0900
Message-ID: 
To: Sam Scott 
Content-Type: multipart/alternative; boundary=94eb2c07c35ead29fb052366e74b
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Oct 2015 13:56:07 -0000

--94eb2c07c35ead29fb052366e74b
Content-Type: text/plain; charset=UTF-8

Sam,

Thanks for posting this. It's great to see people doing real formal
analysis of the TLS 1.3 draft; this is really helpful in guiding the design.

As you say, the current draft-10 doesn't permit certificate-based client
authentication when PSK is used [0], but it's clear that we want to at least
be able to have this in the post-handshake case (since otherwise you
wouldn't be able to do on-the-fly client auth with a resumed handshake),
and this shows that we have to be very careful when we do that.
Note: It's less clear we want to allow this in the initial handshake, if
only
because it complicates the state machine.

This result motivates and confirms the need to modify the handshake hashes
to contain the server Finished when we add post-handshake authentication
as is done in PR#316, which of course we'll be discussing in Yokohama.
I'd be very interested in learning of the results you get when you model
that.

Thanks again for your contribution here. It's really important to have
this kind of analysis, especially at this stage before the design is
completely
hardened.

Best,
-Ekr

[0] Client auth doesn't appear in the PSK diagram in Figure 4
and Section 6.3.5 requires that CertificateRequest appear after a
Certificate
which clearly isn't possible with PSK:

      A non-anonymous server can optionally request a certificate from
      the client, if appropriate for the selected cipher suite.  This
      message, if sent, will immediately follow the server's Certificate
      message.

https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-6.3.5

On Sat, Oct 31, 2015 at 8:19 PM, Sam Scott  wrote:

> Dear all,
>
> We [1] are in the process of performing an automated symbolic analysis
> of the TLS 1.3 specification draft (revision 10) using the Tamarin
> prover [2], which is a tool for automated security protocol analysis.
>
> While revision 10 does not yet appear to permit certificate-based client
> authentication in PSK (and in particular resumption using PSK), we modelled
> what we believe is the intended functionality. By enabling client
> authentication either in the initial handshake, or with a post- handshake
> signature over the handshake hash, our Tamarin analysis finds an attack.
> The
> result is a complete breakage of client authentication, as the attacker can
> impersonate a client when communicating with a server:
>
> Suppose a client Alice performs an initial handshake with Charlie. Charlie,
> masquerading as Alice, subsequently performs a handshake with Bob.
> Following a
> PSK resumption, Bob requests authentication from Charlie (impersonating
> Alice).
> Charlie then requests authentication from Alice, and the returned signature
> will also be a valid signature for the session with Bob.
>
>         Initial h/s                                      Initial h/s
>      |<-------------->|                               |<-------------->|
>      |  exchange PSK  |                               |  exchange PSK  |
>      |                |                               |                |
>      |Start PSK resume|                               |Start PSK resume|
>      |--------------->|                               |--------------->|
>      |client_random nc|                               |client_random nc|
>      |                |                               |                |
>      |  Accept resume |                               |  Accept resume |
> Alice|<---------------|(as Charlie) Charlie (as Alice)|<---------------|Bob
>      |server_random ns|                               |server_random ns|
>      |                |                               |                |
>      |                |                               |                |
>      |Client auth req |                               |Client auth req |
>      |<---------------|                               |<---------------|
>      |                |                               |                |
>      |  Client auth   |                               |  Client auth   |
>      |--------------->|                               |--------------->|
>        sign nc,ns,...                                  relay signature
>
>
>
> This attack is possible because the client signature is over the handshake
> hash, which only covers the nonces and other easily duplicated information,
> and in particular does not contain the server certificate (because none is
> presented in PSK mode [3]) or the server Finished.
>
> While the modifications proposed in PR#316 [4] explicitly allow client
> authentication in these contexts, the PR also redefines the client
> signature
> based on a new "Handshake Context" value which includes the server Finished
> message. Intuitively, this new definition appears to address the attack
> because the attacker cannot transplant the Finished message between
> connections. We are currently working towards a Tamarin proof that PR#316
> indeed prevents our attack.
>
> Therefore we would like to support the inclusion of Finished as
> part of the handshake context, in order to address this problem.
>
> Many thanks,
>
> Sam Scott
>
> [1] Cas Cremers, Marko Horvat - University of Oxford;
>     Thyla van der Merwe, Sam Scott - Royal Holloway, University of London.
> [2] http://www.infsec.ethz.ch/research/software/tamarin.html
> [3] Except in 0-RTT where the server's Certificate is explicitly
>     included.
> [4] https://github.com/tlswg/tls13-spec/pull/316/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c07c35ead29fb052366e74b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Sam,

Thanks for posting this. It's =
great to see people doing real formal
analysis of the TLS 1.3 dra=
ft; this is really helpful in guiding the design.

=
As you say, the current draft-10 doesn't permit certificate-based clien=
t
authentication when PSK is used [0], but it's clear that we=
 want to at least
be able to have this in the post-handshake case=
 (since otherwise you
wouldn't be able to do on-the-fly clien=
t auth with a resumed handshake),
and this shows that we have to =
be very careful when we do that.=C2=A0
Note: It's less clear =
we want to allow this in the initial handshake, if only=C2=A0
bec=
ause it complicates the state machine.

This result=
 motivates and confirms the need to modify the handshake hashes
t=
o contain the server Finished when we add post-handshake authentication
as is done in PR#316, which of course we'll be discussing in Yok=
ohama.
I'd be very interested in learning of the results you =
get when you model
that.

Thanks again fo=
r your contribution here. It's really important to have
this =
kind of analysis, especially at this stage before the design is completely<=
/div>
hardened.

Best,
-Ekr
=


[0] Client auth doesn't appear in the PSK diagram i=
n Figure 4
and Section 6.3.5 requires that CertificateRequest app=
ear after a Certificate
which clearly isn't possible with PSK=
:

=C2=A0 =C2=A0 =C2=A0 A non-anonymous server=
 can optionally request a certificate from
=C2=A0 =C2=A0 =C2=A0 t=
he client, if appropriate for the selected cipher suite.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 message, if sent, will immediately follow the serve=
r's Certificate
=C2=A0 =C2=A0 =C2=A0 message.


On Sat, Oct 31, 2015 at 8:19 PM, Sam Scott &l=
t;sam.scott89@gm=
ail.com> wrote:

 =20

   =20
 =20
  

    Dear all,

    

    We [1] are in the process of performing an automated
      symbolic analysis

    of the TLS 1.3 specification draft (revision 10) using the
      Tamarin

    prover [2], which is a tool for automated security protocol
      analysis.

    

    While revision 10 does not yet appear to permit
      certificate-based client

    authentication in PSK (and in particular resumption using
      PSK), we modelled

    what we believe is the intended functionality. By enabling
      client

    authentication either in the initial handshake, or with a
      post- handshake

    signature over the handshake hash, our Tamarin analysis
      finds an attack. The

    result is a complete breakage of client authentication, as
      the attacker can

    impersonate a client when communicating with a server:

    

    Suppose a client Alice performs an initial handshake with
      Charlie. Charlie,

    masquerading as Alice, subsequently performs a handshake
      with Bob. Following a

    PSK resumption, Bob requests authentication from Charlie
      (impersonating Alice).

    Charlie then requests authentication from Alice, and the
      returned signature

    will also be a valid signature for the session with Bob.<=
tt>

    

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Initial h/s=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
      Initial h/s

    =C2=A0=C2=A0=C2=A0=C2=A0 |<-------------->|=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
      |<-------------->|

    =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 exchange PSK=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 |=C2=A0
      exchange PSK=C2=A0 |

    =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |

    =C2=A0=C2=A0=C2=A0=C2=A0 |Start PSK resume|=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |Start PSK resume|

    =C2=A0=C2=A0=C2=A0=C2=A0 |--------------->|=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
      |--------------->|

    =C2=A0=C2=A0=C2=A0=C2=A0 |client_random nc|=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |client_random nc|

    =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |

    =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Accept resume |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0
      Accept resume |

    Alice|<---------------|(as Charlie) Charlie (as
      Alice)|<---------------|Bob

    =C2=A0=C2=A0=C2=A0=C2=A0 |server_random ns|=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |server_random ns|

    =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |

    =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |

    =C2=A0=C2=A0=C2=A0=C2=A0 |Client auth req |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |Client auth req |

    =C2=A0=C2=A0=C2=A0=C2=A0 |<---------------|=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
      |<---------------|

    =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
      |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |

    =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Client auth=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0
      Client auth=C2=A0=C2=A0 |

    =C2=A0=C2=A0=C2=A0=C2=A0 |--------------->|=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
      |--------------->|

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sign nc,ns,...=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
      relay signature

    

    

    

    This attack is possible because the client signature is
      over the handshake

    hash, which only covers the nonces and other easily
      duplicated information,

    and in particular does not contain the server certificate
      (because none is

    presented in PSK mode [3]) or the server Finished.
    

    While the modifications proposed in PR#316 [4] explicitly
      allow client

    authentication in these contexts, the PR also redefines the
      client signature

    based on a new "Handshake Context" value which inclu=
des the
      server Finished

    message. Intuitively, this new definition appears to
      address the attack

    because the attacker cannot transplant the Finished message
      between

    connections. We are currently working towards a Tamarin
      proof that PR#316

    indeed prevents our attack.

    

    Therefore we would like to support the inclusion of
      Finished as

    part of the handshake context, in order to address this
      problem.

    

    Many thanks,

    

    Sam Scott

    

    [1] Cas Cremers, Marko Horvat - University of Oxford;=


    =C2=A0=C2=A0=C2=A0 Thyla van der Merwe, Sam Scott - Royal Holl=
oway,
      University of London.

    [2]
      http://www.infsec.ethz.ch/research/software/tamarin.html<=
/a>

    [3] Except in 0-RTT where the server's Certificate is
      explicitly

    =C2=A0=C2=A0=C2=A0 included.

    [4] https://github.com/tlswg/tls13-spec/pull/316/
  



_______________________________________________

TLS mailing list

TLS@ietf.org

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





--94eb2c07c35ead29fb052366e74b--


From nobody Sat Oct 31 07:29:52 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553891B38DB for ; Sat, 31 Oct 2015 07:29:51 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5MCqWMLxmrc for ; Sat, 31 Oct 2015 07:29:50 -0700 (PDT)
Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id E6BA51B38D6 for ; Sat, 31 Oct 2015 07:29:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id B936F21BBE2; Sat, 31 Oct 2015 16:29:48 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id THxhHChCeLLA; Sat, 31 Oct 2015 16:29:48 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 8FBB15BC010; Sat, 31 Oct 2015 16:29:48 +0200 (EET)
Date: Sat, 31 Oct 2015 16:29:46 +0200
From: Ilari Liusvaara 
To: Eric Rescorla 
Message-ID: <20151031142945.GA12815@LK-Perkele-V2.elisa-laajakaista.fi>
References: <5634A3B8.7070701@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Oct 2015 14:29:51 -0000

On Sat, Oct 31, 2015 at 10:55:24PM +0900, Eric Rescorla wrote:
> Sam,
> 
> Thanks for posting this. It's great to see people doing real formal
> analysis of the TLS 1.3 draft; this is really helpful in guiding the design.
>
> This result motivates and confirms the need to modify the handshake hashes
> to contain the server Finished when we add post-handshake authentication
> as is done in PR#316, which of course we'll be discussing in Yokohama.
> I'd be very interested in learning of the results you get when you model
> that.

Looking at the issue at wider angle, this soundness hole appears anytime
handshake_messages and configuration do not jointly represent the static
secret (the inclusion of server Finished fixes it for client signature,
because server Finished represents the static secret).

If TLS ever gets mode that combines that non-representation with static
server certificate auth (no idea what such mode could be), one gets
problems with server auth.


-Ilari


From nobody Sat Oct 31 12:37:25 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77A1B2D24 for ; Sat, 31 Oct 2015 12:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 L_74KCVHp5Zj for ; Sat, 31 Oct 2015 12:37:23 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002: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 9C0061B2D23 for ; Sat, 31 Oct 2015 12:37:23 -0700 (PDT)
Received: by ykdr3 with SMTP id r3so106183278ykd.1 for ; Sat, 31 Oct 2015 12:37:23 -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:content-type; bh=PhN+YAGSAZmLvL4lYTQXgoh7coZldZ8vXMxnQYX3CWk=; b=FEjFGQqg9TqOT90zQJJOiMWLKKLO7IZFJ98HZV+4Zl8eBWkqCztLxZvcbssNRKt1W3 ti0Ps86DImzRlxno3z+lfTJ/h8ePmBRhuXcseWj0awAHC/TNe2B57jl0D2RJiBvOLL+i zQLc+S7XHizlQeOE+hh8UqIoWRicokyL+CSw09QQ2BP36Xi4tMvuj+uI6I7oRtCtcMMI LOmZ8EWwSNnM3d5+t+kWgzzNbZrVdDXM/kr162BlnzIMMYSt6U4oLCLvWzGpoS6Pzi/m ehrXWwC/2+kKj3ntN7uag/VAD2oVIXdeQ9Xdrcq5lLmbisuEB+ChyjcJwZufZyOH9+0b deRQ==
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-type; bh=PhN+YAGSAZmLvL4lYTQXgoh7coZldZ8vXMxnQYX3CWk=; b=JnmDEqwFdYp47PSwOMWLt+ApNOanfvdNut2TxD2l7bVGbN8qTetfjD9Lpg18ODnNfz 31LeH5G8T8K6SnjnEx7U39l3CYwa+5EJhOSQ8ecogihxBppSVHyEQoERmAatzEArdfHe XKGXMKwVfpKCWR4vjD/sMkSw+NmORfmrBw4cRJKWKtpl5O/NAMgtLZ8PuDbXimmWYc4m 7+wG0uxyuNXD0yzpCmQy0IjxApgxu3mvCnC9+76oheA2QCmKntonILMyVGuh80n8Tt7a jtb0NKzMfVpi0mIjwT7XBVHt+ukByI4aj5xKV/+hqqFAXZG6S4ug6vXw4aJLH7J3LvSE oGSA==
X-Gm-Message-State: ALoCoQkHJGW6dBl+oV2Qfq94y1kkaAEuCNAx8bsfTg4+QuYUFWH1hgVcdtcmdrDu1NLnnkox/WLx
X-Received: by 10.13.213.138 with SMTP id x132mr12046501ywd.223.1446320242948;  Sat, 31 Oct 2015 12:37:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Sat, 31 Oct 2015 12:36:43 -0700 (PDT)
In-Reply-To: <20151031142945.GA12815@LK-Perkele-V2.elisa-laajakaista.fi>
References: <5634A3B8.7070701@gmail.com>  <20151031142945.GA12815@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla 
Date: Sun, 1 Nov 2015 04:36:43 +0900
Message-ID: 
To: Ilari Liusvaara 
Content-Type: multipart/alternative; boundary=001a114fa914502db205236bac69
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 31 Oct 2015 19:37:25 -0000

--001a114fa914502db205236bac69
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 31, 2015 at 11:29 PM, Ilari Liusvaara 
wrote:

> On Sat, Oct 31, 2015 at 10:55:24PM +0900, Eric Rescorla wrote:
> > Sam,
> >
> > Thanks for posting this. It's great to see people doing real formal
> > analysis of the TLS 1.3 draft; this is really helpful in guiding the
> design.
> >
> > This result motivates and confirms the need to modify the handshake
> hashes
> > to contain the server Finished when we add post-handshake authentication
> > as is done in PR#316, which of course we'll be discussing in Yokohama.
> > I'd be very interested in learning of the results you get when you model
> > that.
>
> Looking at the issue at wider angle, this soundness hole appears anytime
> handshake_messages and configuration do not jointly represent the static
> secret (the inclusion of server Finished fixes it for client signature,
> because server Finished represents the static secret).
>
> If TLS ever gets mode that combines that non-representation with static
> server certificate auth (no idea what such mode could be), one gets
> problems with server auth.


I've been planning to do a big rewrite of the security "analysis" sections
and while I don't think it's worth having a real analysis in the protocol
(the literature is going to do a much better job here than we can), this
seems like exactly the kind of thing that we do want to capture to
explain the design and for future extensions.

Thanks,
-Ekr

--001a114fa914502db205236bac69
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, Oct 31, 2015 at 11:29 PM, Ilari Liusvaara <=
;ilariliusvaa=
ra@welho.com> wrote:
=
On Sat, Oct 31, 2015 at 10:55:24PM +0900, Eric Rescorla wrote:

> Sam,

>

> Thanks for posting this. It's great to see people doing real forma=
l

> analysis of the TLS 1.3 draft; this is really helpful in guiding the d=
esign.

>

> This result motivates and confirms the need to modify the=
 handshake hashes

> to contain the server Finished when we add post-handshake authenticati=
on

> as is done in PR#316, which of course we'll be discussing in Yokoh=
ama.

> I'd be very interested in learning of the results you get when you=
 model

> that.



Looking at the issue at wider angle, this soundness hole appears any=
time

handshake_messages and configuration do not jointly represent the static
secret (the inclusion of server Finished fixes it for client signature,

because server Finished represents the static secret).



If TLS ever gets mode that combines that non-representation with static

server certificate auth (no idea what such mode could be), one gets

problems with server auth.

I've been pl=
anning to do a big rewrite of the security "analysis" sections
and while I don't think it's worth having a real analysis i=
n the protocol
(the literature is going to do a much better job h=
ere than we can), this
seems like exactly the kind of thing that =
we do want to capture to
explain the design and for future extens=
ions.

Thanks,
-Ekr

<=
div>





--001a114fa914502db205236bac69--


From nobody Sat Oct 31 20:39:44 2015
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A098D1B5816 for ; Sat, 31 Oct 2015 20:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTSMixsF4TJf for ; Sat, 31 Oct 2015 20:39:41 -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 1E48F1B5812 for ; Sat, 31 Oct 2015 20:39:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63126BE33; Sun,  1 Nov 2015 03:39:38 +0000 (GMT)
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 SRazJrAwB_3t; Sun,  1 Nov 2015 03:39:37 +0000 (GMT)
Received: from [133.93.44.14] (unknown [133.93.44.14]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BBC62BE2F; Sun,  1 Nov 2015 03:39:35 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446349177; bh=v+1oMdXv98xQ5iP7Rf6Tq5S94PZDY+xZ4TcVYCqQJAM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=tpdf+KyanK3mu2AjUvJd9bSe2CbXk92pWMFiPuw97ws33d89YAn6++CsO50nM7eC1 NCWIq+bPC0kT0JosDkTGW+8l8ZmeK2geYfkFahE/tKiKExnIBgvE5eHfoeDXdruOXw aszrUaegxUaxjy8bODx65gKFAmfV8ggnwFcHPuPw=
To: Eric Rescorla , Sam Scott 
References: <5634A3B8.7070701@gmail.com> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56358974.5060102@cs.tcd.ie>
Date: Sun, 1 Nov 2015 03:39:32 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list 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, 01 Nov 2015 03:39:42 -0000

On 31/10/15 13:55, Eric Rescorla wrote:
> 
> Thanks again for your contribution here. It's really important to have
> this kind of analysis, especially at this stage before the design is
> completely
> hardened.

+many,

Thanks,
S.