From nobody Mon Aug 1 22:03:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3A412D0CD for ; Mon, 1 Aug 2016 22:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5ikTpI3Fw6w for ; Mon, 1 Aug 2016 22:03:16 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369C012B007 for ; Mon, 1 Aug 2016 22:03:16 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id o80so271603311wme.1 for ; Mon, 01 Aug 2016 22:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=lYpUjq2/VB/bV+XVXogMqMYhC/6y6elrk/k2PSBTL+I=; b=eRJ3/ion8dV5ybAq20ITA7OE7g2D0njV7oig7U7A6XHSQ5m50xsckbsWbH7YkbtVxR 9jGwNb3hkmFRKKXP67a0O1dfbt7QG4lvwskgLRVpD85SC2y36hjAuedLaQHIKuuChfle qUp927XWgyxCqC/MXIXLurvWa02N/ED4DIu6psYvYZ5isJolN6lf4BEj2LcNnrjWuza/ LwO/0hOWwW7lLHIvUVwvJGePlsKPLidAeMkOo0B8un36yVDYGtFnm4dDOnoBXuP2aqho fOPlqaXIwwV7Vpq0uv9y8+luXP0ujeKEokktBFKL8/rrfBidUY3EALJ32KyI8YxNvoTs wgpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lYpUjq2/VB/bV+XVXogMqMYhC/6y6elrk/k2PSBTL+I=; b=jiMOJGP7gQCk26AdOI7IZfwiDar5lCe84whGOe8YuGnPOiMJ3bwusabfRIM68dmNKS ZweAWuJ/3Xy6AGwibQFzA3pPC6y0FXemwIKBGVnX/2mLH7bZ/1OKILytLkrgA8PISWHC n+lYT5w56wjij/5qUDZM1ybUrLBRggwJlauVsOFOv7cfcAphH7LiAtAXrowAFEBRA8q2 1m14XXxbHXxjlCZIpwJA/AbF0g1lz9RbthQcNQaaiPebQlaJpS3xhVMOrTDr/nXby4w0 9kGUr0h5QWmxWh91Ou09MgceCF+5r8NWK8UVcCj/zroTqcF5QaMYJLBCYNKLVVa+3Ftk UUyA== X-Gm-Message-State: AEkoouv3pxcsI5E8J7FHOoiIsZkHSde9kippAfAF38J1AFb8JjkTzAbxplvWvvXKNOeIMiACTDCsjwdqaaPK0A== X-Received: by 10.194.47.206 with SMTP id f14mr58251115wjn.98.1470114194358; Mon, 01 Aug 2016 22:03:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.150 with HTTP; Mon, 1 Aug 2016 22:03:13 -0700 (PDT) From: Martin Thomson Date: Tue, 2 Aug 2016 15:03:13 +1000 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Post-handshake Finished when rejecting a CertificateRequest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 05:03:18 -0000 https://github.com/tlswg/tls13-spec/issues/572 Discuss. From nobody Mon Aug 1 23:59:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572ED12B004 for ; Mon, 1 Aug 2016 23:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2Lth-TDzg8k for ; Mon, 1 Aug 2016 23:58:55 -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 E569D127078 for ; Mon, 1 Aug 2016 23:58:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COS74379; Tue, 02 Aug 2016 06:58:50 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 2 Aug 2016 07:58:30 +0100 Received: from BLREML502-MBX.china.huawei.com ([10.20.5.202]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Tue, 2 Aug 2016 12:28:17 +0530 From: Raja ashok To: David Benjamin , "tls@ietf.org" Thread-Topic: [TLS] Keeping TLS extension points working Thread-Index: AQHR5sSGP8jlE9Wa4UKbNZzI09Q7v6A0G4+w Date: Tue, 2 Aug 2016 06:58:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF559blreml502mbx_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.57A044AB.014C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c7d1f084f708807fb0e4f5e49953032 Archived-At: Subject: Re: [TLS] Keeping TLS extension points working X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 06:58:58 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF559blreml502mbx_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF559blreml502mbx_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF559blreml502mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVuamFtaW4sDQoNCkkgaGF2ZSBnb25lIHRocm91Z2ggdGhlIEdSRUFTRSBtZWNoYW5pc20g d2hpY2ggeW91IHByb3Bvc2VkIGluIHlvdXIgbmV3IGRyYWZ0LiBJdOKAmXMgcmVhbGx5IGEgbmlj ZSBpZGVhIGZvciBmaW5kaW5nIGEgYnVnZ3kgc2VydmVyIGJlZm9yZSBpdCB0aHJpdmVzLg0KDQpJ IGFtIGhhdmluZyBmZXcgZG91YnRzIG9uIHRoaXMsIHdoaWNoIGFyZSBsaXN0ZWQgYmVsb3cuDQoN CmEpICAgICAgV2hhdCBzaG91bGQgYmUgdGhlIGJlaGF2aW91ciBvZiBjbGllbnQgaW5jYXNlIGlm IGEgYnVnZ3kgc2VydmVyIHJlc3BvbmRlZCBmb3IgYSBHUkVBU0UgdmFsdWUgPw0KDQotICAgICAg ICAgIENvbnNpZGVyIGEgY2xpZW50IHNlbmRzIGEgR1JFQVNFIGNpcGhlciB2YWx1ZSBhdCBmaXJz dCBwbGFjZSBhbmQgZm9sbG93ZWQgYnkgdmFsaWQgY2lwaGVyIHN1aXRlcywgaW4gaXRzIGNsaWVu dCBoZWxsby4NCg0KLSAgICAgICAgICBJZiBhIGJ1Z2d5IHNlcnZlciBzZWxlY3RzIHRoYXQgY2lw aGVyIHRoZW4gaXQgd2lsbCByZXNwb25zZSBzZXJ2ZXIgaGVsbG8gd2l0aCB0aGF0IEdSRUFTRSBj aXBoZXIgdmFsdWUuIEF0IHRoaXMgY2FzZSBpZiBjbGllbnQgc2VuZHMgRkFUQUwgYWxlcnQgdGhl biBib3RoIHNpZGUgVExTIGFuZCBUQ1AgbmVlZHMgdG8gYmUgY2xvc2VkIGFuZCBjbGllbnQgbmVl ZHMgdG8gcmVjcmVhdGUgYSBuZXcgVENQIGNvbm5lY3Rpb24sIGFuZCB0aGVuIHJlc3RhcnQgVExT IGhhbmRzaGFrZSB3aXRob3V0IEdSRUFTRSBjaXBoZXIgdmFsdWUuDQoNCi0gICAgICAgICAgSW5z dGVhZCBvZiB0aGlzIHdlIGNhbiBtYWtlIGNsaWVudCB0byBzZW5kIHdhcm5pbmcgYWxlcnQgKHdp dGggbmV3IFRMUyBhbGVydCBjb2RlIEdSRUFTRV9DSVBIRVJfVkFMVUVfU0VMRUNURUQoMTExKSkg YW5kIHJlc3RhcnQgVExTIGhhbmRzaGFrZSBieSBzZW5kaW5nIGNsaWVudCBoZWxsbyBhZ2Fpbi4N Cg0KLSAgICAgICAgICBJZiBhIHNlcnZlciByZWNlaXZlcyB0aGlzIG5ldyB3YXJuaW5nLCB0aGVu IGl0IHNob3VsZCBiZSByZWFkeSB0byByZWNlaXZlIG5ldyBjbGllbnQgaGVsbG8gdG8gcmVzdGFy dCBoYW5kc2hha2UuDQoNCg0KDQpTRVJWRVIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ0xJRU5UDQoNCkNIIChHUkVBU0UgQ2lw aGVyIHZhbHVlICYgVmFsaWQgQ2lwaGVyIHZhbHVlKSAgICAgICAgICAtLS0tLS0+DQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwtLS0tLS0tICAgICAgICAgICAgICAgICAgU0ggKEdSRUFTRSBjaXBoZXIgdmFs dWUpDQoNCkZhdGFsIGFsZXJ0ICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLT4NCg0KVENQIChT WU4pICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLT4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0gICAgICAgICAgICAgICAgVENQKFNZ TiBBQ0spDQoNClRDUCAoQUNLKSAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0+DQoNCkNIIChW YWxpZCBjaXBoZXIgdmFsdWUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tLS0tLS0+DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFNj ZW5hcmlvIDEgOiBTZW5kaW5nIEZBVEFMIGFsZXJ0IGZvciBzZXJ2ZXIgc2VsZWN0aW5nIEdSRUFT RSB2YWx1ZQ0KDQoNCg0KU0VSVkVSICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENMSUVOVA0KDQpDSCAoR1JFQVNFIENpcGhlciB2 YWx1ZSAmIFZhbGlkIENpcGhlciB2YWx1ZSkgICAgICAgICAgLS0tLS0tLT4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC0tLS0tLS0gICAgICAgICAgICAgICAgICBTSCAoR1JFQVNFIGNpcGhlciB2YWx1ZSkN Cg0KV2FybmluZyBhbGVydCAgICAgICAgICAgICAtLS0tLS0tLT4NCg0KQ0ggKFZhbGlkIGNpcGhl ciB2YWx1ZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0tLS0tLT4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgU2NlbmFyaW8gMiA6 IFNlbmRpbmcgV0FSTklORyBhbGVydCBmb3Igc2VydmVyIHNlbGVjdGluZyBHUkVBU0UgdmFsdWUN Cg0KDQoNCi0gICAgICAgICAgSSBob3BlIHNlbmRpbmcgd2FybmluZyBtc2cgYW5kIHJlc3RhcnRp bmcgVExTIGhhbmRzaGFrZSB3aWxsIGJlIGVmZmljaWVudC4NCg0KLSAgICAgICAgICBUTFMgU2Vy dmVyIG11c3Qgbm90aWZ5IHRoZSBhcHBsaWNhdGlvbiwgd2hlbmV2ZXIgaXQgcmVjZWl2ZXMgYSBH UkVBU0Ugd2FybmluZyBhbGVydC4NCg0KDQoNCmIpICAgICAgV2h5IG9ubHkgZmV3IHZhbHVlcyBh cmUgc3BlY2lmaWVkIGFzIEdSRUFTRSB2YWx1ZSA/IEJhc2ljYWxseSBhbGwgdmFsdWUgd2hpY2gg YXJlIG5vdCBzcGVjaWZpZWQgYnkgSUFOQSBzaG91bGQgYmUgY29uc2lkZXJlZCBhcyBHUkVBU0Ug dmFsdWUgcmlnaHQgPw0KDQotICAgICAgICAgIEJhc2ljYWxseSBjbGllbnQgc2hvdWxkIG1haW50 YWluIHRoZSBsaXN0IG9mIHZhbHVlcyAoY2lwaGVyIHN1aXRlLCBleHRlbnNpb25zKSBzcGVjaWZp ZWQgYnkgSUFOQS4gVGhlIHJhbmdlIG9mIHZhbHVlcy4NCg0KLSAgICAgICAgICBGb3IgZXhhbXBs ZSBJQU5BIHNwZWNpZmllZCBjaXBoZXIgc3VpdGUgdmFsdWVzIGFyZSB7ezB4MDAwMCwweDAwNUN9 LCB7MHgwMDYwLDB4MDA2RH0sIHsweDAwODQsIDB4MDBDNX0sIHsweDAwRkYsIDB4MDBGRn0g4oCm Li4gfS4gVGhpcyBzaG91bGQgYmUgbWFpbnRhaW5lZCBpbiBjbGllbnQuDQoNCi0gICAgICAgICAg V2Ugc2hvdWxkIG1ha2UgdGhlIGNsaWVudCB0byBjaG9vc2UgYSByYW5kb20gdmFsdWUgd2hpY2gg YXJlIG5vdCBpbiB0aGlzIHN1cHBvcnRlZCB2YWx1ZSBsaXN0LiBUaGF0IGNpcGhlciB2YWx1ZSBz aG91bGQgYmUgY29uc2lkZXJlZCBhcyBHUkVBU0UgdmFsdWUgYW5kIG5lZWQgdG8ga2VlcCBpbiBm aXJzdCBwbGFjZSBvZiBpdHMgY2lwaGVyIGxpc3QuDQoNCi0gICAgICAgICAgSWYgaXRzIHNlbGVj dGVkIGJ5IGEgYnVnZ3kgc2VydmVyLCB0aGVuIGNsaWVudCBzaG91bGQgYmVoYXZlIGFzIG1lbnRp b25lZCBpbiBhYm92ZSBzY2VuYXJpbyAyLg0KDQotICAgICAgICAgIEV2ZW4gaW4gZnV0dXJlIGlm IElBTkEgcHJvdmlkZXMgbmV3IHZhbHVlcyB0byBuZXcgY2lwaGVyLCB0aGVuIHRoaXMgbGlzdCBh bHNvIHNob3VsZCBiZSB1cGRhdGVkLiBDb25zaWRlciBpbiB0aGlzIGNhc2Ugc2VydmVyIGlzIHN1 cHBvcnRpbmcgdGhhdCBuZXcgY2lwaGVyIGFuZCBjbGllbnQgaXMgbm90IGF3YXJlIGFib3V0IGl0 LCBzbyBjbGllbnQgY2FuIHByb3Bvc2UgdGhhdCB2YWx1ZSBhcyBHUkVBU0UgdmFsdWUsIHRoZW4g c3RpbGwgY29ubmVjdGlvbiB3aWxsIHdvcmsgd2l0aCB0aGUgMm5kIGhhbmRzaGFrZS4NCg0KLSAg ICAgICAgICBJIGFtIG5vdCB1bmRlcnN0YW5kaW5nIHdoeSB3ZSBhcmUgcGxhbm5pbmcgdG8gbWFp bnRhaW4gYSBmZXcgc2V0IG9mIEdSRUFTRSB2YWx1ZXMgezB4MEEwQSwgMHgxQTFBIOKApi4gfS4g SWYgSSBhbSBtaXNzaW5nIHNvbWV0aGluZywgcGxlYXNlIGNsYXJpZnkgbWUuDQoNClJlZ2FyZHMs DQpSIEFzaG9rDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSYWphIEFzaG9r IFZLDQrljY7kuLrmioDmnK/mnInpmZDlhazlj7ggSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0 ZC4NCltDb21wYW55X2xvZ29dDQoNClBob25lOg0KRmF4Og0KTW9iaWxlOg0KRW1haWw6DQpIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KQmFuZ2Fsb3JlLCBJbmRpYQ0KaHR0cDovL3d3dy5o dWF3ZWkuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5pys6YKu5Lu25Y+K 5YW26ZmE5Lu25ZCr5pyJ5Y2O5Li65YWs5Y+455qE5L+d5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R 6YCB57uZ5LiK6Z2i5Zyw5Z2A5Lit5YiX5Ye655qE5Liq5Lq65oiW576k57uE44CC56aBDQrmraLk u7vkvZXlhbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7l hajpg6jmiJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bk uK0NCueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WN s+eUteivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gQ0KVGhp cyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24g b3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0K aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBu b3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9u LCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpy ZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSBpdCENCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQgQmVuamFtaW4NClNlbnQ6IDI2IEp1bHkgMjAxNiAwNDow Mg0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gS2VlcGluZyBUTFMgZXh0ZW5zaW9u IHBvaW50cyB3b3JraW5nDQoNCkhpIGZvbGtzLA0KDQpJJ20gbm90IHN1cmUgaG93IHRoaXMgcHJv Y2VzcyB1c3VhbGx5IHdvcmtzLCBidXQgSSB3b3VsZCBsaWtlIHRvIHJlc2VydmUgYSBidW5jaCBv ZiB2YWx1ZXMgaW4gdGhlIFRMUyByZWdpc3RyaWVzIHRvIGFzIHBhcnQgb2YgYW4gaWRlYSB0byBr ZWVwIG91ciBleHRlbnNpb24gcG9pbnRzIHdvcmtpbmcuIEhlcmUncyBhbiBJLUQ6DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGF2aWRiZW4tdGxzLWdyZWFzZS0wMA0KDQooVGhl IG5hbWUgR1JFQVNFIGlzIGluIGhvbm9yIG9mIEFHTCdzIHJ1c3RlZCB2cy4gd2VsbC1vaWxlZCBq b2ludHMgYW5hbG9neSBmcm9tIGh0dHBzOi8vd3d3LmltcGVyaWFsdmlvbGV0Lm9yZy8yMDE2LzA1 LzE2L2FnaWxpdHkuaHRtbCApDQoNCk9uZSBwcm9ibGVtIHdlIHJlcGVhdGVkbHkgcnVuIGludG8g aXMgc2VydmVycyBmYWlsaW5nIHRvIGltcGxlbWVudCBUTFMncyB2YXJpb3VzIGV4dGVuc2lvbiBw b2ludHMgY29ycmVjdGx5LiBUaGUgbW9zdCBvYnZpb3VzIGJlaW5nIHZlcnNpb24gaW50b2xlcmFu Y2UuIFdoZW4gd2UgZGVwbG95ZWQgWDI1NTE5IGluIENocm9tZSwgd2UgZGlzY292ZXJlZCBhbiBp bnRvbGVyYW50IGltcGxlbWVudGF0aW9uLiAoVGhhbmtmdWxseSBpdCB3YXMgcmFyZSBlbm91Z2gg dG8gbm90IHdhcnJhbnQgYSBmYWxsYmFjayBvciByZXZlcnQhKSBJdCBhcHBlYXJzIHRoYXQgc2ln bmF0dXJlIGFsZ29yaXRobXMgbWF5YmUgYWxzbyBiZSBnYXRoZXJpbmcgcnVzdC4gQ2lwaGVycyBh bmQgZXh0ZW5zaW9ucyBzZWVtIHRvIGhhdmUgaGVsZCB1cCwgYnV0IEkgd291bGQgbGlrZSB0byBl bnN1cmUgdGhleSBzdGF5IHRoYXQgd2F5Lg0KDQpUaGUgcm9vdCBwcm9ibGVtIGhlcmUgaXMgdGhl c2UgYnJva2VuIHNlcnZlcnMgaW50ZXJvcGVyYXRlIGZpbmUgd2l0aCBjbGllbnRzIGF0IHRoZSB0 aW1lIHRoZXkgYXJlIGRlcGxveWVkLiBJdCBpcyBvbmx5IGFmdGVyIG5ldyB2YWx1ZXMgZ2V0IGRl ZmluZWQgZG8gd2Ugbm90aWNlLCBieSB3aGljaCB0aW1lIGl0IGlzIHRvbyBsYXRlLg0KDQpJIHdv dWxkIGxpa2UgdG8gZml4IHRoaXMgYnkgcmVzZXJ2aW5nIGEgZmV3IHZhbHVlcyBpbiBvdXIgcmVn aXN0cmllcyBzbyB0aGF0IGNsaWVudHMgbWF5IGFkdmVydGlzZSByYW5kb20gb25lcyBhbmQgcmVn dWxhcmx5IGV4ZXJjaXNlIHRoZXNlIGNvZGVwYXRocyBpbiBzZXJ2ZXJzLiBJZiBlbm91Z2ggb2Yg dGhlIGNsaWVudCBiYXNlIGRvZXMgdGhpcywgd2UgY2FuIHR1cm4gYSBsYXJnZSBjbGFzcyBvZiB0 b21vcnJvdydzIGludGVyb3AgZmFpbHVyZXMgaW50byB0b2RheSdzIGludGVyb3AgZmFpbHVyZXMu IFRoaXMgaXMgaW1wb3J0YW50IGJlY2F1c2UgYW4gYnVnIHdpbGwgbm90IHRocml2ZSBpbiB0aGUg ZWNvc3lzdGVtIGlmIGl0IGRvZXMgbm90IHdvcmsgYWdhaW5zdCB0aGUgY3VycmVudCBkZXBsb3lt ZW50Lg0KDQpJZiB5b3Ugd2VyZSBpbiBCZXJsaW4sIHlvdSBtYXkgcmVjb2duaXplIHRoaXMgaWRl YSBmcm9tIHRoZSB2ZXJzaW9uIG5lZ290aWF0aW9uIGRlYmF0ZS4gQWxhcyB0aGF0IGFsbCBoYXBw ZW5lZCBpbiB0aGUgd3Jvbmcgb3JkZXIgYXMgSSBoYWRuJ3Qgd3JpdHRlbiB0aGlzIHVwIHlldC4g VGhpcyBpZGVhIGNhbid0IGJlIGFwcGxpZWQgdG8gdmVyc2lvbmluZyB3aXRob3V0IGdpdmluZyB1 cCBvbiBDbGllbnRIZWxsby52ZXJzaW9uLCBidXQgd2UgY2FuIHN0YXJ0IHdpdGggdGhlIHJlc3Qg b2YgdGhlIHByb3RvY29sLg0KDQpEYXZpZA0KDQpQUzogVGhpcyBpcyBhY3R1YWxseSBteSBmaXJz dCBJLUQsIHNvIGFwb2xvZ2llcyBpZiBJJ3ZlIG1lc3NlZCBpdCB1cCBzb21ld2hlcmUhDQo= --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF559blreml502mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTsN CglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxA5Y2O5paH57uG6buRIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0 b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyNjI1Njg4 MDk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzQ1 Njg4ODg0IC0yMTAwNjg0ODkwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTYzMjI1MTYxNTsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NDQyMDMyNDMyIDY3Njk4NzExIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjIwNTAiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBCZW5qYW1pbiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgaGF2ZSBnb25lIHRocm91Z2ggdGhlIEdSRUFTRSBtZWNoYW5pc20gd2hpY2ggeW91 IHByb3Bvc2VkIGluIHlvdXIgbmV3IGRyYWZ0LiBJdOKAmXMgcmVhbGx5IGEgbmljZSBpZGVhIGZv ciBmaW5kaW5nIGEgYnVnZ3kgc2VydmVyIGJlZm9yZSBpdCB0aHJpdmVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh bSBoYXZpbmcgZmV3IGRvdWJ0cyBvbiB0aGlzLCB3aGljaCBhcmUgbGlzdGVkIGJlbG93LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+V2hhdCBzaG91bGQgYmUgdGhlIGJlaGF2aW91ciBvZiBjbGllbnQgaW5jYXNl IGlmIGEgYnVnZ3kgc2VydmVyIHJlc3BvbmRlZCBmb3IgYSBHUkVBU0UgdmFsdWUgPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NTQuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db25z aWRlciBhIGNsaWVudCBzZW5kcyBhIEdSRUFTRSBjaXBoZXIgdmFsdWUgYXQgZmlyc3QgcGxhY2Ug YW5kIGZvbGxvd2VkIGJ5IHZhbGlkIGNpcGhlciBzdWl0ZXMsIGluIGl0cyBjbGllbnQgaGVsbG8u DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SWYgYSBidWdneSBzZXJ2ZXIgc2VsZWN0cyB0aGF0IGNpcGhlciB0aGVuIGl0IHdpbGwg cmVzcG9uc2Ugc2VydmVyIGhlbGxvIHdpdGggdGhhdCBHUkVBU0UgY2lwaGVyIHZhbHVlLiBBdCB0 aGlzIGNhc2UgaWYgY2xpZW50IHNlbmRzIEZBVEFMIGFsZXJ0IHRoZW4NCiBib3RoIHNpZGUgVExT IGFuZCBUQ1AgbmVlZHMgdG8gYmUgY2xvc2VkIGFuZCBjbGllbnQgbmVlZHMgdG8gcmVjcmVhdGUg YSBuZXcgVENQIGNvbm5lY3Rpb24sIGFuZCB0aGVuIHJlc3RhcnQgVExTIGhhbmRzaGFrZSB3aXRo b3V0IEdSRUFTRSBjaXBoZXIgdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluc3RlYWQgb2YgdGhpcyB3ZSBjYW4gbWFrZSBj bGllbnQgdG8gc2VuZCB3YXJuaW5nIGFsZXJ0ICh3aXRoIG5ldyBUTFMgYWxlcnQgY29kZSBHUkVB U0VfQ0lQSEVSX1ZBTFVFX1NFTEVDVEVEKDExMSkpIGFuZCByZXN0YXJ0IFRMUyBoYW5kc2hha2Ug YnkNCiBzZW5kaW5nIGNsaWVudCBoZWxsbyBhZ2Fpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgYSBzZXJ2ZXIgcmVjZWl2ZXMg dGhpcyBuZXcgd2FybmluZywgdGhlbiBpdCBzaG91bGQgYmUgcmVhZHkgdG8gcmVjZWl2ZSBuZXcg Y2xpZW50IGhlbGxvIHRvIHJlc3RhcnQgaGFuZHNoYWtlLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDo1NC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TRVJWRVImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogQ0xJRU5UPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDo1NC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5D SCAoR1JFQVNFIENpcGhlciB2YWx1ZSAmYW1wOyBWYWxpZCBDaXBoZXIgdmFsdWUpJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLSZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjU0LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0tLS0tLS0mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0ggKEdSRUFTRSBjaXBoZXIgdmFsdWUpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDo1NC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5GYXRhbCBhbGVydCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRDUCAoU1lOKSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLSZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 Oy0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogVENQKFNZTiBBQ0sp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDo1NC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UQ1AgKEFDSykmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DSCAoVmFsaWQgY2lwaGVyIHZh bHVlKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLS0tLS0tJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNjZW5hcmlv IDEgOiBTZW5kaW5nIEZBVEFMIGFsZXJ0IGZvciBzZXJ2ZXIgc2VsZWN0aW5nIEdSRUFTRSB2YWx1 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjU0LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlNFUlZFUiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiBDTElFTlQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjU0LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNIIChHUkVBU0UgQ2lwaGVyIHZhbHVlICZhbXA7IFZhbGlkIENpcGhlciB2YWx1ZSkmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLSZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy0tLS0tLS0mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0ggKEdSRUFTRSBjaXBoZXIgdmFsdWUp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDo1NC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5XYXJuaW5nIGFsZXJ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NTQuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Q0ggKFZhbGlkIGNpcGhlciB2YWx1ZSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBTY2VuYXJpbyAyIDogU2VuZGluZyBXQVJOSU5HIGFsZXJ0IGZvciBzZXJ2ZXIg c2VsZWN0aW5nIEdSRUFTRSB2YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaG9wZSBzZW5kaW5nIHdh cm5pbmcgbXNnIGFuZCByZXN0YXJ0aW5nIFRMUyBoYW5kc2hha2Ugd2lsbCBiZSBlZmZpY2llbnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRMUyBTZXJ2ZXIgbXVzdCBub3RpZnkgdGhlIGFwcGxpY2F0aW9uLCB3aGVuZXZlciBpdCBy ZWNlaXZlcyBhIEdSRUFTRSB3YXJuaW5nIGFsZXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+Yik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5XaHkgb25seSBmZXcgdmFsdWVzIGFyZSBzcGVjaWZpZWQgYXMgR1JFQVNFIHZhbHVlID8g QmFzaWNhbGx5IGFsbCB2YWx1ZSB3aGljaCBhcmUgbm90IHNwZWNpZmllZCBieSBJQU5BIHNob3Vs ZCBiZSBjb25zaWRlcmVkIGFzIEdSRUFTRSB2YWx1ZSByaWdodA0KID88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0 LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmFzaWNhbGx5IGNs aWVudCBzaG91bGQgbWFpbnRhaW4gdGhlIGxpc3Qgb2YgdmFsdWVzIChjaXBoZXIgc3VpdGUsIGV4 dGVuc2lvbnMpIHNwZWNpZmllZCBieSBJQU5BLiBUaGUgcmFuZ2Ugb2YgdmFsdWVzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZv ciBleGFtcGxlIElBTkEgc3BlY2lmaWVkIGNpcGhlciBzdWl0ZSB2YWx1ZXMgYXJlIHt7MHgwMDAw LDB4MDA1Q30sIHsweDAwNjAsMHgwMDZEfSwgezB4MDA4NCwgMHgwMEM1fSwgezB4MDBGRiwgMHgw MEZGfSDigKYuLiB9LiBUaGlzIHNob3VsZCBiZSBtYWludGFpbmVkDQogaW4gY2xpZW50LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NTQuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X ZSBzaG91bGQgbWFrZSB0aGUgY2xpZW50IHRvIGNob29zZSBhIHJhbmRvbSB2YWx1ZSB3aGljaCBh cmUgbm90IGluIHRoaXMgc3VwcG9ydGVkIHZhbHVlIGxpc3QuIFRoYXQgY2lwaGVyIHZhbHVlIHNo b3VsZCBiZSBjb25zaWRlcmVkIGFzIEdSRUFTRSB2YWx1ZQ0KIGFuZCBuZWVkIHRvIGtlZXAgaW4g Zmlyc3QgcGxhY2Ugb2YgaXRzIGNpcGhlciBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBpdHMgc2VsZWN0ZWQgYnkgYSBi dWdneSBzZXJ2ZXIsIHRoZW4gY2xpZW50IHNob3VsZCBiZWhhdmUgYXMgbWVudGlvbmVkIGluIGFi b3ZlIHNjZW5hcmlvIDIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkV2ZW4gaW4gZnV0dXJlIGlmIElBTkEgcHJvdmlkZXMgbmV3IHZh bHVlcyB0byBuZXcgY2lwaGVyLCB0aGVuIHRoaXMgbGlzdCBhbHNvIHNob3VsZCBiZSB1cGRhdGVk LiBDb25zaWRlciBpbiB0aGlzIGNhc2Ugc2VydmVyIGlzIHN1cHBvcnRpbmcgdGhhdCBuZXcNCiBj aXBoZXIgYW5kIGNsaWVudCBpcyBub3QgYXdhcmUgYWJvdXQgaXQsIHNvIGNsaWVudCBjYW4gcHJv cG9zZSB0aGF0IHZhbHVlIGFzIEdSRUFTRSB2YWx1ZSwgdGhlbiBzdGlsbCBjb25uZWN0aW9uIHdp bGwgd29yayB3aXRoIHRoZSAyPHN1cD5uZDwvc3VwPiBoYW5kc2hha2UuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjU0LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBub3Qg dW5kZXJzdGFuZGluZyB3aHkgd2UgYXJlIHBsYW5uaW5nIHRvIG1haW50YWluIGEgZmV3IHNldCBv ZiBHUkVBU0UgdmFsdWVzIHsweDBBMEEsIDB4MUExQSDigKYuIH0uIElmIEkgYW0gbWlzc2luZyBz b21ldGhpbmcsIHBsZWFzZSBjbGFyaWZ5DQogbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SIEFzaG9rPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk65a6L5L2TO2NvbG9yOiMxRjQ5N0QiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAl IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+WNjuaWh+e7hum7 kSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmFqYSBBc2hvayBWSzxicj4N CjxzcGFuIGxhbmc9IlpILUNOIj7ljY7kuLrmioDmnK/mnInpmZDlhazlj7g8L3NwYW4+IEh1YXdl aSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuPGJyPg0KPC9zcGFuPjwhLS1baWYgZ3RlIHZtbCAxXT48 djpzaGFwZXR5cGUgaWQ9Il94MDAwMF90NzUiIGNvb3Jkc2l6ZT0iMjE2MDAsMjE2MDAiIG86c3B0 PSI3NSIgbzpwcmVmZXJyZWxhdGl2ZT0idCIgcGF0aD0ibUA0QDVsQDRAMTFAOUAxMUA5QDV4ZSIg ZmlsbGVkPSJmIiBzdHJva2VkPSJmIj4NCjx2OnN0cm9rZSBqb2luc3R5bGU9Im1pdGVyIiAvPg0K PHY6Zm9ybXVsYXM+DQo8djpmIGVxbj0iaWYgbGluZURyYXduIHBpeGVsTGluZVdpZHRoIDAiIC8+ DQo8djpmIGVxbj0ic3VtIEAwIDEgMCIgLz4NCjx2OmYgZXFuPSJzdW0gMCAwIEAxIiAvPg0KPHY6 ZiBlcW49InByb2QgQDIgMSAyIiAvPg0KPHY6ZiBlcW49InByb2QgQDMgMjE2MDAgcGl4ZWxXaWR0 aCIgLz4NCjx2OmYgZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVsSGVpZ2h0IiAvPg0KPHY6ZiBlcW49 InN1bSBAMCAwIDEiIC8+DQo8djpmIGVxbj0icHJvZCBANiAxIDIiIC8+DQo8djpmIGVxbj0icHJv ZCBANyAyMTYwMCBwaXhlbFdpZHRoIiAvPg0KPHY6ZiBlcW49InN1bSBAOCAyMTYwMCAwIiAvPg0K PHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxIZWlnaHQiIC8+DQo8djpmIGVxbj0ic3VtIEAx MCAyMTYwMCAwIiAvPg0KPC92OmZvcm11bGFzPg0KPHY6cGF0aCBvOmV4dHJ1c2lvbm9rPSJmIiBn cmFkaWVudHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9InJlY3QiIC8+DQo8bzpsb2NrIHY6ZXh0 PSJlZGl0IiBhc3BlY3RyYXRpbz0idCIgLz4NCjwvdjpzaGFwZXR5cGU+PHY6c2hhcGUgaWQ9InJp ZEltZyIgbzpzcGlkPSJfeDAwMDBfczEwMjYiIHR5cGU9IiNfeDAwMDBfdDc1IiBhbHQ9IkNvbXBh bnlfbG9nbyIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRv cDowO3dpZHRoOjc2LjVwdDtoZWlnaHQ6MjRwdDt6LWluZGV4OjE7dmlzaWJpbGl0eTp2aXNpYmxl O21zby13cmFwLXN0eWxlOnNxdWFyZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjA7bXNvLXdyYXAt ZGlzdGFuY2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6MDttc28td3JhcC1kaXN0YW5j ZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDpsZWZ0O21zby1wb3NpdGlvbi1ob3Jp em9udGFsLXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1w b3NpdGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTpsaW5lJyBvOmFsbG93b3ZlcmxhcD0iZiI+DQo8djpp bWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDFFQ0I5LjU3RjY5REUwIiBvOmhyZWY9 ImZpbGU6Ly8vQzpcVXNlcnNccjAwOTAyNzM2XEFwcGxpY2F0aW9uJTIwRGF0YVxNaWNyb3NvZnRc U2lnbmF0dXJlc1xjb21wYW55X2xvZ28uanBnIiAvPg0KPHc6d3JhcCB0eXBlPSJzcXVhcmUiIGFu Y2hvcnk9ImxpbmUiLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48aW1nIHdp ZHRoPSIxMDIiIGhlaWdodD0iMzIiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQxRUNCOS41N0Y2 OURFMCIgYWxpZ249ImxlZnQiIGFsdD0iQ29tcGFueV9sb2dvIiB2OnNoYXBlcz0icmlkSW1nIj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5Y2O5paH57uG6buRJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8 YnI+DQpQaG9uZTogPGJyPg0KRmF4OiA8YnI+DQpNb2JpbGU6IDxicj4NCkVtYWlsOiA8YnI+DQpI dWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxicj4NCkJhbmdhbG9yZSwgSW5kaWE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDvljY7mlofnu4bpu5EmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPmh0dHA6Ly93d3cuaHVhd2VpLmNvbTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOiMxRjQ5N0QiPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZM7Y29sb3I6IzFG NDk3RCI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFu PjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75Y2O5paH57uG6buRJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOmdyYXkiPuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4 uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4 reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+WNjuaWh+e7hum7kSZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpncmF5Ij48YnI+DQo8c3BhbiBsYW5nPSJaSC1DTiI+5q2i5Lu75L2V5YW2 5LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW 6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitPC9zcGFu Pjxicj4NCjxzcGFuIGxhbmc9IlpILUNOIj7nmoTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobm nKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbl iKDpmaTmnKzpgq7ku7bvvIE8L3NwYW4+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpncmF5Ij5UaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4g Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KPGJyPg0KaXMgaW50 ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0 ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQo8YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVy ZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBw YXJ0aWFsDQo8YnI+DQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24p IGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgPGJyPg0KcmVjaXBpZW50KHMpIGlz IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYnkNCjxicj4NCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgaXQhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVExTIFttYWlsdG86dGxzLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhdmlkIEJlbmphbWluPGJyPg0K PGI+U2VudDo8L2I+IDI2IEp1bHkgMjAxNiAwNDowMjxicj4NCjxiPlRvOjwvYj4gdGxzQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUTFNdIEtlZXBpbmcgVExTIGV4dGVuc2lvbiBwb2lu dHMgd29ya2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBzdXJlIGhvdyB0aGlzIHByb2Nlc3MgdXN1YWxs eSB3b3JrcywgYnV0IEkgd291bGQgbGlrZSB0byByZXNlcnZlIGEgYnVuY2ggb2YgdmFsdWVzIGlu IHRoZSBUTFMgcmVnaXN0cmllcyB0byBhcyBwYXJ0IG9mIGFuIGlkZWEgdG8ga2VlcCBvdXIgZXh0 ZW5zaW9uIHBvaW50cyB3b3JraW5nLiBIZXJlJ3MgYW4gSS1EOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWRhdmlkYmVuLXRscy1ncmVhc2UtMDAiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1kYXZpZGJlbi10bHMtZ3JlYXNlLTAwPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4oVGhlIG5hbWUgR1JFQVNFIGlzIGluIGhvbm9yIG9mIEFHTCdzIHJ1c3RlZCB2cy4gd2VsbC1v aWxlZCBqb2ludHMgYW5hbG9neSBmcm9tDQo8YSBocmVmPSJodHRwczovL3d3dy5pbXBlcmlhbHZp b2xldC5vcmcvMjAxNi8wNS8xNi9hZ2lsaXR5Lmh0bWwiPmh0dHBzOi8vd3d3LmltcGVyaWFsdmlv bGV0Lm9yZy8yMDE2LzA1LzE2L2FnaWxpdHkuaHRtbDwvYT4mbmJzcDspPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIHByb2Js ZW0gd2UgcmVwZWF0ZWRseSBydW4gaW50byBpcyBzZXJ2ZXJzIGZhaWxpbmcgdG8gaW1wbGVtZW50 IFRMUydzIHZhcmlvdXMgZXh0ZW5zaW9uIHBvaW50cyBjb3JyZWN0bHkuIFRoZSBtb3N0IG9idmlv dXMgYmVpbmcgdmVyc2lvbiBpbnRvbGVyYW5jZS4gV2hlbiB3ZSBkZXBsb3llZCBYMjU1MTkgaW4g Q2hyb21lLCB3ZSBkaXNjb3ZlcmVkIGFuIGludG9sZXJhbnQgaW1wbGVtZW50YXRpb24uIChUaGFu a2Z1bGx5DQogaXQgd2FzIHJhcmUgZW5vdWdoIHRvIG5vdCB3YXJyYW50IGEgZmFsbGJhY2sgb3Ig cmV2ZXJ0ISkgSXQgYXBwZWFycyB0aGF0IHNpZ25hdHVyZSBhbGdvcml0aG1zIG1heWJlIGFsc28g YmUgZ2F0aGVyaW5nIHJ1c3QuIENpcGhlcnMgYW5kIGV4dGVuc2lvbnMgc2VlbSB0byBoYXZlIGhl bGQgdXAsIGJ1dCBJIHdvdWxkIGxpa2UgdG8gZW5zdXJlIHRoZXkgc3RheSB0aGF0IHdheS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJv b3QgcHJvYmxlbSBoZXJlIGlzIHRoZXNlIGJyb2tlbiBzZXJ2ZXJzIGludGVyb3BlcmF0ZSBmaW5l IHdpdGggY2xpZW50cyBhdCB0aGUgdGltZSB0aGV5IGFyZSBkZXBsb3llZC4gSXQgaXMgb25seSBh ZnRlciBuZXcgdmFsdWVzIGdldCBkZWZpbmVkIGRvIHdlIG5vdGljZSwgYnkgd2hpY2ggdGltZSBp dCBpcyB0b28gbGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIGZpeCB0aGlzIGJ5Jm5ic3A7cmVzZXJ2aW5nIGEg ZmV3IHZhbHVlcyBpbiBvdXIgcmVnaXN0cmllcyBzbyB0aGF0IGNsaWVudHMgbWF5IGFkdmVydGlz ZSByYW5kb20gb25lcyBhbmQgcmVndWxhcmx5IGV4ZXJjaXNlIHRoZXNlIGNvZGVwYXRocyBpbiBz ZXJ2ZXJzLiBJZiBlbm91Z2ggb2YgdGhlIGNsaWVudCBiYXNlIGRvZXMgdGhpcywgd2UgY2FuIHR1 cm4gYSBsYXJnZSBjbGFzcyBvZiB0b21vcnJvdydzDQogaW50ZXJvcCBmYWlsdXJlcyBpbnRvIHRv ZGF5J3MgaW50ZXJvcCBmYWlsdXJlcy4gVGhpcyBpcyBpbXBvcnRhbnQgYmVjYXVzZSBhbiBidWcg d2lsbCBub3QgdGhyaXZlIGluIHRoZSBlY29zeXN0ZW0gaWYgaXQgZG9lcyBub3Qgd29yayBhZ2Fp bnN0IHRoZSBjdXJyZW50IGRlcGxveW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3Ugd2VyZSBpbiBCZXJsaW4sIHlv dSBtYXkgcmVjb2duaXplIHRoaXMgaWRlYSBmcm9tIHRoZSB2ZXJzaW9uIG5lZ290aWF0aW9uIGRl YmF0ZS4gQWxhcyB0aGF0IGFsbCBoYXBwZW5lZCBpbiB0aGUgd3Jvbmcgb3JkZXIgYXMgSSBoYWRu J3Qgd3JpdHRlbiB0aGlzIHVwIHlldC4gVGhpcyBpZGVhIGNhbid0IGJlIGFwcGxpZWQgdG8gdmVy c2lvbmluZyB3aXRob3V0IGdpdmluZyB1cCBvbiBDbGllbnRIZWxsby52ZXJzaW9uLA0KIGJ1dCB3 ZSBjYW4gc3RhcnQgd2l0aCB0aGUgcmVzdCBvZiB0aGUgcHJvdG9jb2wuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlBTOiBUaGlzIGlzIGFjdHVhbGx5IG15IGZpcnN0IEktRCwgc28gYXBvbG9naWVzIGlm IEkndmUgbWVzc2VkIGl0IHVwIHNvbWV3aGVyZSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF559blreml502mbx_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF559blreml502mbx_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Tue, 02 Aug 2016 06:58:16 GMT"; modification-date="Tue, 02 Aug 2016 06:58:16 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF559blreml502mbx_-- From nobody Tue Aug 2 00:49:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA3412B008 for ; Tue, 2 Aug 2016 00:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoaAlNzt2LRZ for ; Tue, 2 Aug 2016 00:49:05 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1D12B004 for ; Tue, 2 Aug 2016 00:49:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 47943E996; Tue, 2 Aug 2016 10:49:02 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ofmIafubFPiU; Tue, 2 Aug 2016 10:49:01 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 280502310; Tue, 2 Aug 2016 10:49:01 +0300 (EEST) Date: Tue, 2 Aug 2016 10:48:54 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160802074854.GA21071@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 07:49:07 -0000 On Tue, Aug 02, 2016 at 03:03:13PM +1000, Martin Thomson wrote: > https://github.com/tlswg/tls13-spec/issues/572 > > Discuss. Yeah, noticed that when trying to implement stuff. I do not see any point in sending Finished in that case. Not sending Finished would also make implementations that don't support post-handshake auth simpler. Also, what exact base key does that Finished use? Client's current traffic secret at the beginning of the Finished (the sequence of traffic secrets is the same client and server, but the values may be out of sync.)? I also noticed the hash forking issue. Even if I personally nowadays deal with forkable hashes (even to the point of implmenting multitap via forking) that is the only place forking is done. However, those hash constructs look different from the ones in handshake (not just different base context), which means those would likely have to be implemented separtedly, increasing implmentation effort. However, if one wanted to use extra hashing there, so construction is both compatible with the in-handshake one and doesn't require forking, one would need to be a bit careful to stay out of cryptographic roughs. E.g. it might be necressary to pad the hash to multiple of hash input blocksize (like how HMAC does such padding with the key). -Ilari From nobody Tue Aug 2 03:40:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E9512B049 for ; Tue, 2 Aug 2016 03:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhFlwNuPh89U for ; Tue, 2 Aug 2016 03:40:11 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 D1F4A12D513 for ; Tue, 2 Aug 2016 03:40:10 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id i5so283424123wmg.0 for ; Tue, 02 Aug 2016 03:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Avp9Z3pW7X+FKHCh4jUyC0lax/AABG/p9gmjooYo3Ls=; b=f0AWgxMQmJi8Ve/Lsq+irGfb7WkozI5BoyHKOUrEkFzGfMj1XqnzTmOF6vOaOY0HEo zIqSwf15HO1n2J5rwEnhb+nWeePpql/nEYr2MTvSvQco+n91kFwKQaP9+uMxPTib7QGy eKajMTOVMx9FBgUbDrQRXZF8/6rRFMURtN1TQlyoKTquGUpF/72pTmCjPfBYOf248PE1 H0w1mUwwpqK5+CPmuWHIKcYYV2PRQH5Vfc0WCVpN8ifrE5zquMrstYu4b8sId0rMrRqZ cDsaJsjf4e8Yq/mCIBukfyXl9nyuYgCoWzYDx9CTzRuASEtaxm3wiICZ9ATPWDr2xF1z MyFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Avp9Z3pW7X+FKHCh4jUyC0lax/AABG/p9gmjooYo3Ls=; b=Vtdoo+WPrG6U+S5HkOFHmD3NZ4CyVXRwZ18zbyp8F+3mnweEQClerUXmlhIY2cx9Uq 9+7EI2CPTWkXqK/Y4sQT55b0M+Z7Zadjvn9drXBL6PyorqKZukeSbepyZ7a64jyg4S+D GrGTqsjtYZswn9ZDnxuMFAXkobPyQmaMD1GXbXMQFOilbk8r8P6NAxMiVN+xxzsSg0La kdtz+PIYcT1G+oZDbR5fEID+F5AKjoSYjsSjj63rsx8omzaRd6R4yVfr0YAxftQCddja TYH0p0yFNCjedz2w+Ztda2FeU62oOD54zfYvnHXzWjoo9pYyVfFfNgTq++HU6OmFsBef Az+A== X-Gm-Message-State: AEkoouvyGDzTddnkoBOsd3O5PBfitsjw33INtmkTMT9PMG+kro0mvDVytLqN/yLqKcre7QxS+Kmjs/JOzpMI2Q== X-Received: by 10.194.77.142 with SMTP id s14mr53962885wjw.77.1470134409366; Tue, 02 Aug 2016 03:40:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.150 with HTTP; Tue, 2 Aug 2016 03:40:08 -0700 (PDT) In-Reply-To: <20160802074854.GA21071@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160802074854.GA21071@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Tue, 2 Aug 2016 20:40:08 +1000 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 10:40:13 -0000 On 2 August 2016 at 17:48, Ilari Liusvaara wrote: > Also, what exact base key does that Finished use? Client's current > traffic secret at the beginning of the Finished (the sequence of > traffic secrets is the same client and server, but the values may > be out of sync.)? Presumably it's the traffic_secret_N that is active at the start of the sequence of messages; also presumably, the sequence of messages cannot be interrupted by something like a KeyUpdate. From nobody Tue Aug 2 05:25:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A1112D586 for ; Tue, 2 Aug 2016 05:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvBavZf3y24Z for ; Tue, 2 Aug 2016 05:25:55 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7144312D581 for ; Tue, 2 Aug 2016 05:25:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 2AE63EFD0; Tue, 2 Aug 2016 15:25:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id KWHTcb1P-JZO; Tue, 2 Aug 2016 15:25:52 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id E1BB42310; Tue, 2 Aug 2016 15:25:52 +0300 (EEST) Date: Tue, 2 Aug 2016 15:25:46 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160802122546.GA28281@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160802074854.GA21071@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 12:25:57 -0000 On Tue, Aug 02, 2016 at 08:40:08PM +1000, Martin Thomson wrote: > On 2 August 2016 at 17:48, Ilari Liusvaara wrote: > > Also, what exact base key does that Finished use? Client's current > > traffic secret at the beginning of the Finished (the sequence of > > traffic secrets is the same client and server, but the values may > > be out of sync.)? > > > Presumably it's the traffic_secret_N that is active at the start of > the sequence of messages; also presumably, the sequence of messages > cannot be interrupted by something like a KeyUpdate. It can't be interrupted by KeyUpdate from client, but can be interrupted by KeyUpdate by server. (Also, I think base key only appears in Finished). -Ilari From nobody Tue Aug 2 05:55:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A980112D590 for ; Tue, 2 Aug 2016 05:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul67xc-Cv7Yp for ; Tue, 2 Aug 2016 05:54:58 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211AC12D581 for ; Tue, 2 Aug 2016 05:54:58 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id z8so197067625ywa.1 for ; Tue, 02 Aug 2016 05:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SxaqPu7oW27UyM0cf3tw7IYGLdf6s2fbzSnC1q/Ktvs=; b=X4/7v/Rnfo7GbihEtpn+SZGVCpBlY9khYS5nlmYp8Qig5GENdo1dvsnyDFI2wQynOq Zq4KoAIUKqazZYFKidmUAZKqDAT4tzM7FAVU6ogSM4yoTqjvvcXGenGrPjqpLmualJUR RXWMUPb4fGJK3eABdUJ/44Vm4fBfNULIEOoDoa8i0/Cx8BjGCgiV3E721RbsSE7yxJlP XLeKb49bWU76IaivcVU1Dj751rYGhXvnCkuqwGo/tgc3XLNHRYaaheDmjRFoLynfXPvW ZQKe7B2X/39oFd9qllFnLuIsF5uIS3BgWH08fWXDgN06mC8Jo8F+DKrTXYEV51zD4tT6 qI/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SxaqPu7oW27UyM0cf3tw7IYGLdf6s2fbzSnC1q/Ktvs=; b=P1EiEebDZ7ERlkhPIgNM5cYKKQxl29TK6cgKEyprA8+2B9l9/2VoXgCcHGMul/Cwxo CBnE1VXH97wTrzfCz6B4ekvgdvh5PlaUFFxC5H1IrVJrU6O6RS7dK5/CLfbkUl8u+cYn lXgjHn1bhsTSVB66Y0wJJa7UQajN+6SJOFBSE4ED8wO48Whvq28dcZqF3vrkc4pHx+38 hyHSlw1DPL0x7fWwjecZWW4DcGoYK5FoYdeVeogE5JxQVnmvPrWBmTPr6d4rcip8/GTz OwBt9wM0cp/WeMxCViP6BF/qwKgTXumWJA5Cetl6GyJ4eSFLxqyTNmGAp5aqto/253yT vcCA== X-Gm-Message-State: AEkoout3g/wZVhDRPvZ+q29UwwQqCyGtxsSTYsbjT/A3GRAB2o/k3ZAxI0qCTTnQWHR74NFrDUctXkFOxxUFFA== X-Received: by 10.129.92.215 with SMTP id q206mr24941565ywb.8.1470142497434; Tue, 02 Aug 2016 05:54:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Tue, 2 Aug 2016 05:54:17 -0700 (PDT) In-Reply-To: <20160802122546.GA28281@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160802074854.GA21071@LK-Perkele-V2.elisa-laajakaista.fi> <20160802122546.GA28281@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 2 Aug 2016 05:54:17 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114d85ce545aed0539163930 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 12:55:00 -0000 --001a114d85ce545aed0539163930 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 2, 2016 at 5:25 AM, Ilari Liusvaara wrote: > On Tue, Aug 02, 2016 at 08:40:08PM +1000, Martin Thomson wrote: > > On 2 August 2016 at 17:48, Ilari Liusvaara > wrote: > > > Also, what exact base key does that Finished use? Client's current > > > traffic secret at the beginning of the Finished (the sequence of > > > traffic secrets is the same client and server, but the values may > > > be out of sync.)? > > > > > > Presumably it's the traffic_secret_N that is active at the start of > > the sequence of messages; also presumably, the sequence of messages > > cannot be interrupted by something like a KeyUpdate. > > It can't be interrupted by KeyUpdate from client, but can be interrupted > by KeyUpdate by server. > Not sure why that matters. Key Updates are unidirectional. I think it clearly has to be sender's. -Ekr > (Also, I think base key only appears in Finished). > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114d85ce545aed0539163930 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 2, 2016 at 5:25 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Tue, Aug 02, 2016 at 08:40:08PM +1000, Martin Thomson wrote: > On 2 August 2016 at 17:48, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > Also, what exact base key does that Finished use? Client's cu= rrent
> > traffic secret at the beginning of the Finished (the sequence of<= br> > > traffic secrets is the same client and server, but the values may=
> > be out of sync.)?
>
>
> Presumably it's the traffic_secret_N that is active at the start o= f
> the sequence of messages; also presumably, the sequence of messages > cannot be interrupted by something like a KeyUpdate.

It can't be interrupted by KeyUpdate from client, but can be int= errupted
by KeyUpdate by server.

Not sure why th= at matters. Key Updates are unidirectional. I think it clearly has to
=
be sender's.

-Ekr




(Also, I think base key only appears in Finished).


-Ilari

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

--001a114d85ce545aed0539163930-- From nobody Tue Aug 2 06:33:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F7612D5CE for ; Tue, 2 Aug 2016 06:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bosch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5tE7e-fpl01 for ; Tue, 2 Aug 2016 06:33:40 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [139.15.237.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 6E6D112D5CC for ; Tue, 2 Aug 2016 06:33:39 -0700 (PDT) Received: from vsmta14.fe.internet.bosch.com (unknown [10.4.98.54]) by imta24.fe.bosch.de (Postfix) with ESMTP id 3FDBAD80229 for ; Tue, 2 Aug 2016 15:33:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bosch.com; s=2015-01-21; t=1470144802; bh=Kl4TF28wa8Ae9/gHaM+w9fdT2IhMDgamsR06G2C39sw=; l=10; h=From:From:Reply-To:Sender; b=R3ElfCt8/dXld0mdUd6lwCuVcmCHh3mDJilSXGkNsMd/OPLwjwp0qUM+b0fMaDfOw fTcrTZQ1XMrK0FnUDfQuk5FDZgpsYReeJq2GETiWSEvPW79PJpYtDlY3khxf16TJ9t Hb2cYCYADpFZArRN+lToaj3lsZI9e3ALzsU8/tFg= Received: from FE-MBX1016.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta14.fe.internet.bosch.com (Postfix) with ESMTP id 1BD38A40576 for ; Tue, 2 Aug 2016 15:33:22 +0200 (CEST) Received: from FE-MBX1015.de.bosch.com (10.3.230.73) by FE-MBX1016.de.bosch.com (10.3.230.74) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 15:33:21 +0200 Received: from FE-MBX1015.de.bosch.com ([fe80::256d:ef59:31f1:323f]) by FE-MBX1015.de.bosch.com ([fe80::256d:ef59:31f1:323f%16]) with mapi id 15.00.1178.000; Tue, 2 Aug 2016 15:33:21 +0200 From: "Bauer Johannes (HOME/EFS)" To: "tls@ietf.org" Thread-Topic: RFC5746: Renegotiation Indication for minimal servers Thread-Index: AQHR7MJvU2wvbTQxuUivvvKs9ZJJXA== Date: Tue, 2 Aug 2016 13:33:20 +0000 Message-ID: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.35.28.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22488.006 X-TMASE-MatchedRID: zSOzjnUdHGB2LjL8ejT/AJ1U1lojafr/0nXvwjW2mSWctWHPLT5FfQqQ QQLMh66nAA5BrDAHhD/M9MbRv5omQKXgCCul34T6AjoaSw0EjFWDwLTbOQjvDoYQveKV5AcTB2p vl8LQRyVM4l2ujUlu81axuiGAvQnCB7W827nnV41T46Ow+EhYOFaOJcCxVHYrbcPp/oilssgWud psiFoqJsudCfJw3Q6a4RAGgJ42zZ2H/p/IBt08LME+XuSw48kCgHzgwy8qV5oKogmGusPLbxchd rJv3xSnVvV8yYebEhk0ewX4BnmyOiZywmJvYiNp84dsinZ5e1gwLjM7t3iRo3hOa4C/aON5ilm8 Za1jcglnSqefas3A04EzNEDRLP/IuBnSxs/BFcImT1pl/auP23fdMkv/4CaG32tQZY6eq1ZC+gf JIXxlOJWdXCsle5PXYcJMBLTRh5xst+jJ0LNAM+DQCXqvSA0sBcCEAZkHsGczFWOYrWw6AwqEOa aKoFK30WJYm0gohzsnAKud+dx6ru51ZMzG9kZyevGgcXS9fnJLaooQW4IyHmOv0nGkb1c64rqQI +fw+pzi8zVgXoAltnS4vQrt84k3IAcCikR3vq8QCs2RtiVpRCELmpMB68Eq4y1ICPu2vPJnRx13 SnF3QgwZwCcpXYWC Archived-At: Subject: [TLS] RFC5746: Renegotiation Indication for minimal servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 13:33:43 -0000 Dear mailing list,=0A= =0A= regarding RFC5746 (https://tools.ietf.org/rfc/rfc5746.txt) I do have a ques= tion which could not be solved in our internal discussions. Therefore I wou= ld kindly ask for your comments on my issue. If I posted to the wrong place= , please advise on where such a question would be relevant instead.=0A= =0A= The question revolves around TLS servers (and clients) which do not support= renegotiation at. The server side is the more interesting of the two, henc= e I will discuss it first. Sect 4.3 says:=0A= =0A= In order to enable clients to probe, even servers that do not support=0A= renegotiation MUST implement the minimal version of the extension=0A= described in this document for initial handshakes, thus signaling=0A= that they have been upgraded.=0A= =0A= This hint refers to Sect. 3.6 ("Server Behavior: Initial Handshake"). It sa= ys that a server in any case (independent if it supports or does not suppor= t renegotiation at all) must send a empty renegotiation_info TLS extension = as soon as it receives a client request for that info (be it either by a re= negotiation_info or by the SCSV). Sending that empty renegotiation_info is = really no problem even for deeply embedded TLS servers (the message is only= 5 bytes and always static).=0A= =0A= However, there is also this in Sect. 3.6 which has caused some confusion an= d lengthy discussion among my colleagues and myself:=0A= =0A= o When the handshake has completed, the server needs to save the=0A= client_verify_data and server_verify_data values for future use.=0A= =0A= This is something that, in my opinion, only applies to servers who do suppo= rt renegotiation. Those which do not support renegotiation at all are exemp= t from that requirement. Note that it also is not a hard ("MUST") requireme= nt, but merely informative ("needs"). At least that is my interpretation.= =0A= =0A= For deeply embedded systems, we try to save every byte of RAM -- therefore,= we really would like minimal support for RFC5746 (i.e. signal that our ser= ver will never use insecure renegotation so the clients are satisfied). How= ever, we would also not want to persist any session-relevant data in RAM (m= ore so because it doesn't make sense to save them without renegotiation cap= ability in the first place). However, we really like clarification if we're= reading the RFC correctly in this instance.=0A= =0A= If we're indeed reading the RFC correctly, could we maybe try to get an add= itional clarification in as an erratum to make this unambiguous?=0A= =0A= Thank you very much for your time,=0A= Cheers,=0A= Johannes=0A= =0A= --=0A= Johannes Bauer=0A= =0A= Engineering Field Services (HOME/EFS)=0A= Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 Stuttgart-Vaihin= gen | GERMANY | www.bosch-smarthome.com=0A= Tel. +49(711)81112906 | johannes.bauer@bosch.com=0A= Registergericht: Amtsgericht Stuttgart, HRB 754585;=0A= Gesch=E4ftsf=FChrung: Dr. Peter Schnaebele, Veronika Danner=0A= From nobody Tue Aug 2 06:47:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2BA12D600 for ; Tue, 2 Aug 2016 06:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzbF1qVC_Fxs for ; Tue, 2 Aug 2016 06:47:22 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F5D12D5D5 for ; Tue, 2 Aug 2016 06:47:21 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id z8so198325925ywa.1 for ; Tue, 02 Aug 2016 06:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6zH7BP5xFizVRVxmDo6IjnY1+3gv7E6594LH1qrptAg=; b=kLVSAfuV7W6tZaOfWzLkyEXIYxNiUBWeuTytK24SfZn0CZvyQL7HeeuTftBpdyzLep fBTJzIhJVinNmTM6YDq7jisObeqWXO7zhfkkp1MvbN3HfHEwaF8ysg2YRNHa8Dk+HUKR xWH421U7lESe0RgYvdoPLPL0pwOzqXcy4xj4zcG9N/+WOjru+Y0rifyUsC9OgOeavyZ2 xmqh7+gMPMx9abobEn/12lUKhn2VZkkDPESE6Rfm8tXOqdJTZ0YTnXa1MX3UjkJrY1vn rK88VXMBXCqwR8mEwID/hvXZM2XZsGRo3jARQcGmyngVAApTP43SuIbuDis9jX7ODg9Y 29+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6zH7BP5xFizVRVxmDo6IjnY1+3gv7E6594LH1qrptAg=; b=li1ceqL2txrqIt8OECg/XYYL7LSVV2BU2DVz5TDq757hPi6z5WBOUAM0YMzLh673me yBfz5L59a81sK/xaayhLz9Qnesx0jBLdCbfwxOUmrDdP7Inhi3n0xdHl3PgM4PpPSDTT SD23HRY/0vlYx+QkOQxHrcRSqSxtEOnU79hxOL2s1Fzk9idKYqzibje0cxetusMOVRGC OjscTQqKKes8/kn+dDlm5fSN96G5SQmU+RUMHX4h+p5/iSvdGJbhOiU3eTjZffv9MqFA ZcmyI2SE9/rcjW1HKa45DGEjv9DR5gdQ7ViRoJwOIoIwuLDnEsZrh4BGtXOSZ84xmZrk 4b9w== X-Gm-Message-State: AEkoousmmf17QkwQif2rRbxFm3/YxO0+ZpijTg6jcWMvHsKxDqOzLH8lngLIwD7jEFlW2a+TIpXqUm+hRjd0ywkO X-Received: by 10.37.199.83 with SMTP id w80mr30562160ybe.93.1470145640776; Tue, 02 Aug 2016 06:47:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steven Valdez Date: Tue, 02 Aug 2016 13:47:10 +0000 Message-ID: To: Raja ashok , David Benjamin , "tls@ietf.org" Content-Type: multipart/related; boundary=94eb2c14806ab08354053916f4fd Archived-At: Subject: Re: [TLS] Keeping TLS extension points working X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 13:47:25 -0000 --94eb2c14806ab08354053916f4fd Content-Type: multipart/alternative; boundary=94eb2c14806ab08350053916f4fc --94eb2c14806ab08350053916f4fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable a) It seems like if an implementation has updated to be able to handle a specific GREASE alert, it should be able to handle not sending an invalid cipher suite. In general, its probably cleaner for the connection to fatally shutdown and then restart if the server is behaving that poorly. Servers that are sending back non-existent ciphers are also potentially broken in other ways, and I don't know whether a client should trust that it can reset any handshake state correctly if it were to try doing a "warning" alert. b) The reasoning behind having an explicit list is so that implementations don't send a value that ends up being defined as some other valid value. Otherwise its possible that some implementations will update to include GREASE values, but they might not update immediately upon new values being assigned by IANA, which means that there will be periods of times that some clients might send "fake" values that collide with real values, confusing the peer implementation into believing they actually support something that they don't and resulting in more intolerance issues between outdated GREASE clients and newly updated servers, with this intolerance being firmly the GREASE clients fault. The hardcoded list gets around this by making sure GREASE never overlaps with an actual value, though at the trade-off that badly designed implementations could choose to just hard-code ignore the GREASE codepoints. On Tue, Aug 2, 2016 at 2:59 AM Raja ashok wrote: > Hi Benjamin, > > > > I have gone through the GREASE mechanism which you proposed in your new > draft. It=E2=80=99s really a nice idea for finding a buggy server before = it thrives. > > > > I am having few doubts on this, which are listed below. > > a) What should be the behaviour of client incase if a buggy server > responded for a GREASE value ? > > - Consider a client sends a GREASE cipher value at first place > and followed by valid cipher suites, in its client hello. > > - If a buggy server selects that cipher then it will response > server hello with that GREASE cipher value. At this case if client sends > FATAL alert then both side TLS and TCP needs to be closed and client need= s > to recreate a new TCP connection, and then restart TLS handshake without > GREASE cipher value. > > - Instead of this we can make client to send warning alert (with > new TLS alert code GREASE_CIPHER_VALUE_SELECTED(111)) and restart TLS > handshake by sending client hello again. > > - If a server receives this new warning, then it should be ready > to receive new client hello to restart handshake. > > > > SERVER > CLIENT > > CH (GREASE Cipher value & Valid Cipher value) ------> > > > <------- SH (GREASE cipher value) > > Fatal alert --------> > > TCP (SYN) --------> > > > <-------- > TCP(SYN ACK) > > TCP (ACK) --------> > > CH (Valid cipher > value) -------> > > Scenario 1 : Sending FATAL alert for server > selecting GREASE value > > > > SERVER > CLIENT > > CH (GREASE Cipher value & Valid Cipher value) -------> > > > <------- SH (GREASE cipher value) > > Warning alert --------> > > CH (Valid cipher > value) -------> > > Scenario 2 : Sending WARNING alert for server > selecting GREASE value > > > > - I hope sending warning msg and restarting TLS handshake will > be efficient. > > - TLS Server must notify the application, whenever it receives a > GREASE warning alert. > > > > b) Why only few values are specified as GREASE value ? Basically all > value which are not specified by IANA should be considered as GREASE valu= e > right ? > > - Basically client should maintain the list of values (cipher > suite, extensions) specified by IANA. The range of values. > > - For example IANA specified cipher suite values are > {{0x0000,0x005C}, {0x0060,0x006D}, {0x0084, 0x00C5}, {0x00FF, 0x00FF} =E2= =80=A6.. > }. This should be maintained in client. > > - We should make the client to choose a random value which are > not in this supported value list. That cipher value should be considered = as > GREASE value and need to keep in first place of its cipher list. > > - If its selected by a buggy server, then client should behave > as mentioned in above scenario 2. > > - Even in future if IANA provides new values to new cipher, then > this list also should be updated. Consider in this case server is > supporting that new cipher and client is not aware about it, so client ca= n > propose that value as GREASE value, then still connection will work with > the 2nd handshake. > > - I am not understanding why we are planning to maintain a few > set of GREASE values {0x0A0A, 0x1A1A =E2=80=A6. }. If I am missing someth= ing, > please clarify me. > > > > Regards, > > R Ashok > > > ------------------------------ > > Raja Ashok VK > =E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 = Huawei Technologies Co., Ltd. > [image: Company_logo] > > Phone: > Fax: > Mobile: > Email: > Huawei Technologies Co., Ltd. > Bangalore, India > > http://www.huawei.com > ------------------------------ > > =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB= =E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4= =BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB= =99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84= =E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 > =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB= =E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4= =BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88= =86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96= =E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD > =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99= =E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7= =AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F= =A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE= =E4=BB=B6=EF=BC=81 > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *David Benjamin > *Sent:* 26 July 2016 04:02 > *To:* tls@ietf.org > *Subject:* [TLS] Keeping TLS extension points working > > > > Hi folks, > > > > I'm not sure how this process usually works, but I would like to reserve = a > bunch of values in the TLS registries to as part of an idea to keep our > extension points working. Here's an I-D: > > https://tools.ietf.org/html/draft-davidben-tls-grease-00 > > > > (The name GREASE is in honor of AGL's rusted vs. well-oiled joints analog= y > from https://www.imperialviolet.org/2016/05/16/agility.html ) > > > > One problem we repeatedly run into is servers failing to implement TLS's > various extension points correctly. The most obvious being version > intolerance. When we deployed X25519 in Chrome, we discovered an intolera= nt > implementation. (Thankfully it was rare enough to not warrant a fallback = or > revert!) It appears that signature algorithms maybe also be gathering rus= t. > Ciphers and extensions seem to have held up, but I would like to ensure > they stay that way. > > > > The root problem here is these broken servers interoperate fine with > clients at the time they are deployed. It is only after new values get > defined do we notice, by which time it is too late. > > > > I would like to fix this by reserving a few values in our registries so > that clients may advertise random ones and regularly exercise these > codepaths in servers. If enough of the client base does this, we can turn= a > large class of tomorrow's interop failures into today's interop failures. > This is important because an bug will not thrive in the ecosystem if it > does not work against the current deployment. > > > > If you were in Berlin, you may recognize this idea from the version > negotiation debate. Alas that all happened in the wrong order as I hadn't > written this up yet. This idea can't be applied to versioning without > giving up on ClientHello.version, but we can start with the rest of the > protocol. > > > > David > > > > PS: This is actually my first I-D, so apologies if I've messed it up > somewhere! > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c14806ab08350053916f4fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
a) It seems like if an implementation has updated to be ab= le to handle a specific GREASE alert, it should be able to handle not sendi= ng an invalid cipher suite. In general, its probably cleaner for the connec= tion to fatally shutdown and then restart if the server is behaving that po= orly. Servers that are sending back non-existent ciphers are also potential= ly broken in other ways, and I don't know whether a client should trust= that it can reset any handshake state correctly if it were to try doing a = "warning" alert.

b) The reasoning behind havin= g an explicit list is so that implementations don't send a value that e= nds up being defined as some other valid value. Otherwise its possible that= some implementations will update to include GREASE values, but they might = not update immediately upon new values being assigned by IANA, which means = that there will be periods of times that some clients might send "fake= " values that collide with real values, confusing the peer implementat= ion into believing they actually support something that they don't and = resulting in more intolerance issues between outdated GREASE clients and ne= wly updated servers, with this intolerance being firmly the GREASE clients = fault. The hardcoded list gets around this by making sure GREASE never over= laps with an actual value, though at the trade-off that badly designed impl= ementations could choose to just hard-code ignore the GREASE codepoints.

On Tue, Aug 2, 201= 6 at 2:59 AM Raja ashok <raja.a= shok@huawei.com> wrote:

Hi Benjamin,

=C2=A0

I have gone through the G= REASE mechanism which you proposed in your new draft. It=E2=80=99s really a= nice idea for finding a buggy server before it thrives.

=C2=A0

I am having few doubts on= this, which are listed below.

a)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What should be the b= ehaviour of client incase if a buggy server responded for a GREASE value ?<= u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Consider a client se= nds a GREASE cipher value at first place and followed by valid cipher suite= s, in its client hello.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a buggy server se= lects that cipher then it will response server hello with that GREASE ciphe= r value. At this case if client sends FATAL alert then both side TLS and TCP needs to be closed and client needs to recreate a ne= w TCP connection, and then restart TLS handshake without GREASE cipher valu= e.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Instead of this we c= an make client to send warning alert (with new TLS alert code GREASE_CIPHER= _VALUE_SELECTED(111)) and restart TLS handshake by sending client hello again.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a server receives= this new warning, then it should be ready to receive new client hello to r= estart handshake.

=C2=A0

SERVER=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=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

CH (GREASE Cipher value & Valid Cipher= value)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ------>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 <-------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SH (GREASE cipher value)

Fatal alert=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -------->

TCP (SYN)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <--------=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 TCP(SYN ACK)

TCP (ACK)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -------->

CH (Valid cipher value)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Scenario 1 : Sending FATAL alert for server selecting= GREASE value

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=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

CH (GREASE Cipher value & Valid Cipher= value)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 <-------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SH (GREASE cipher value)

Warning alert=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->

CH (Valid cipher value)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Scenario 2 : Sending WARNING alert for server selecti= ng GREASE value

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I hope sending warni= ng msg and restarting TLS handshake will be efficient.=

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TLS Server must noti= fy the application, whenever it receives a GREASE warning alert.<= /u>

=C2=A0

b)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Why only few values = are specified as GREASE value ? Basically all value which are not specified= by IANA should be considered as GREASE value right ?

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Basically client sho= uld maintain the list of values (cipher suite, extensions) specified by IAN= A. The range of values.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For example IANA spe= cified cipher suite values are {{0x0000,0x005C}, {0x0060,0x006D}, {0x0084, = 0x00C5}, {0x00FF, 0x00FF} =E2=80=A6.. }. This should be maintained in client.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We should make the c= lient to choose a random value which are not in this supported value list. = That cipher value should be considered as GREASE value and need to keep in first place of its cipher list.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If its selected by a= buggy server, then client should behave as mentioned in above scenario 2.<= u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Even in future if IA= NA provides new values to new cipher, then this list also should be updated= . Consider in this case server is supporting that new cipher and client is not aware about it, so client can propose that value = as GREASE value, then still connection will work with the 2nd ha= ndshake.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am not understandi= ng why we are planning to maintain a few set of GREASE values {0x0A0A, 0x1A= 1A =E2=80=A6. }. If I am missing something, please clarify me.

=C2=A0

Regards,

R Ashok

=C2=A0

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

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

http://www.huawei.com


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

From: TLS [mai= lto:tls-bounces@i= etf.org] On Behalf Of David Benjamin
Sent: 26 July 2016 04:02
To: tls@ietf.org
Subject: [TLS] Keeping TLS extension points working

=C2=A0

Hi folks,

=C2=A0

=C2=A0

(The name GREASE is in honor of AGL's rusted vs.= well-oiled joints analogy from https://www.imperialviolet.org/2016/05/16/agility.html=C2= =A0)

=C2=A0

One problem we repeatedly run into is servers failin= g to implement TLS's various extension points correctly. The most obvio= us being version intolerance. When we deployed X25519 in Chrome, we discove= red an intolerant implementation. (Thankfully it was rare enough to not warrant a fallback or revert!) It appears that s= ignature algorithms maybe also be gathering rust. Ciphers and extensions se= em to have held up, but I would like to ensure they stay that way.

=C2=A0

The root problem here is these broken servers intero= perate fine with clients at the time they are deployed. It is only after ne= w values get defined do we notice, by which time it is too late.<= /u>

=C2=A0

I would like to fix this by=C2=A0reserving a few val= ues in our registries so that clients may advertise random ones and regular= ly exercise these codepaths in servers. If enough of the client base does t= his, we can turn a large class of tomorrow's interop failures into today's interop failures. This is important beca= use an bug will not thrive in the ecosystem if it does not work against the= current deployment.

=C2=A0

If you were in Berlin, you may recognize this idea f= rom the version negotiation debate. Alas that all happened in the wrong ord= er as I hadn't written this up yet. This idea can't be applied to v= ersioning without giving up on ClientHello.version, but we can start with the rest of the protocol.

=C2=A0

David

=C2=A0

PS: This is actually my first I-D, so apologies if I= 've messed it up somewhere!

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--94eb2c14806ab08350053916f4fc-- --94eb2c14806ab08354053916f4fd Content-Type: image/pjpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <1564b7ac2d14ce8e91> X-Attachment-Id: 1564b7ac2d14ce8e91 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --94eb2c14806ab08354053916f4fd Content-Type: image/pjpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <> X-Attachment-Id: /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --94eb2c14806ab08354053916f4fd-- From nobody Tue Aug 2 06:59:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C774512D600 for ; Tue, 2 Aug 2016 06:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Fbzh_antA6x for ; Tue, 2 Aug 2016 06:59:52 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0541612D616 for ; Tue, 2 Aug 2016 06:59:51 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id f6so271822892ith.1 for ; Tue, 02 Aug 2016 06:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=QIkQxOxS16xYedjwkREvgGn17+WLnz6ACv0V5cJ3jmY=; b=leD+umztwK/9cz44p25vnM9xAaIqs0w6GDGpnl4DuF8A9hZtYq8xphDENVu87+ga1I euXJHjHvyDvDCqs9TgxDD3StliZKz/RRlTtMVPRJWwdrgdDh31F3g2q2WtTb6bon9IL7 yqlNpLx3CKnAmwcYpwqTTwxyqY4O/tdt3+7Yk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=QIkQxOxS16xYedjwkREvgGn17+WLnz6ACv0V5cJ3jmY=; b=Usl+8AmJiEOWSDQlucbQ+KN0caCtLLnAG/xbMWZUtplOwm7dspSsZviejLoPu1HZrI W5Y9hgHwsYldCRT8b272D69XUHS8I2PERtissENV4BZHIbYKLs5PUU3vH6ww5KiNveSw n4T0L1ebQnrIqx3ZVD5W33lPH0s/+ghKGW7ffuPGjNX0y9fKV75M+YTmwhU9LthESSLH 2MUryLixt71XoPxlPu6pLeYNMPlwQ7xysqPfYcQ7AntSfaYz697IHq7iO3uXwAd4samD 76CDiEozMhYvMXAe3mK8yUVrV4MJF5rWLLngV+O8kXuHAvEWRp8cx+hmxapEMnxnrNY8 nLmA== X-Gm-Message-State: AEkoousCqE9GQZxRpgM/UPB5u4fQtB3cxZx1J6FfoWDihR/4LOhmL82slDdvY/9u8mqWqWuBE/xWYxn4fvMgqzux X-Received: by 10.36.200.134 with SMTP id w128mr65310742itf.92.1470146390899; Tue, 02 Aug 2016 06:59:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 02 Aug 2016 13:59:39 +0000 Message-ID: To: Steven Valdez , Raja ashok , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0579786655aa0539172162 Archived-At: Subject: Re: [TLS] Keeping TLS extension points working X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 13:59:55 -0000 --94eb2c0579786655aa0539172162 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To expand on that a little, since it seems comments (a) and (b) are really the same one: The purpose of having an explicitly reserved list (b) is precisely so we do not have to do a second handshake (a). The purpose here is to ensure we exercise the little-used codepaths, not introduce new ones. This is intended to be an extremely minimal mechanism. Clients add a tiny bit of code to their ClientHello and no server code changes at all. (Note that every MUST in the document is just reiterating what TLS already requires.) David On Tue, Aug 2, 2016 at 9:47 AM Steven Valdez wrote: > a) It seems like if an implementation has updated to be able to handle a > specific GREASE alert, it should be able to handle not sending an invalid > cipher suite. In general, its probably cleaner for the connection to > fatally shutdown and then restart if the server is behaving that poorly. > Servers that are sending back non-existent ciphers are also potentially > broken in other ways, and I don't know whether a client should trust that > it can reset any handshake state correctly if it were to try doing a > "warning" alert. > > b) The reasoning behind having an explicit list is so that implementation= s > don't send a value that ends up being defined as some other valid value. > Otherwise its possible that some implementations will update to include > GREASE values, but they might not update immediately upon new values bein= g > assigned by IANA, which means that there will be periods of times that so= me > clients might send "fake" values that collide with real values, confusing > the peer implementation into believing they actually support something th= at > they don't and resulting in more intolerance issues between outdated GREA= SE > clients and newly updated servers, with this intolerance being firmly the > GREASE clients fault. The hardcoded list gets around this by making sure > GREASE never overlaps with an actual value, though at the trade-off that > badly designed implementations could choose to just hard-code ignore the > GREASE codepoints. > > On Tue, Aug 2, 2016 at 2:59 AM Raja ashok wrote: > >> Hi Benjamin, >> >> >> >> I have gone through the GREASE mechanism which you proposed in your new >> draft. It=E2=80=99s really a nice idea for finding a buggy server before= it thrives. >> >> >> >> I am having few doubts on this, which are listed below. >> >> a) What should be the behaviour of client incase if a buggy server >> responded for a GREASE value ? >> >> - Consider a client sends a GREASE cipher value at first place >> and followed by valid cipher suites, in its client hello. >> >> - If a buggy server selects that cipher then it will response >> server hello with that GREASE cipher value. At this case if client sends >> FATAL alert then both side TLS and TCP needs to be closed and client nee= ds >> to recreate a new TCP connection, and then restart TLS handshake without >> GREASE cipher value. >> >> - Instead of this we can make client to send warning alert >> (with new TLS alert code GREASE_CIPHER_VALUE_SELECTED(111)) and restart = TLS >> handshake by sending client hello again. >> >> - If a server receives this new warning, then it should be >> ready to receive new client hello to restart handshake. >> >> >> >> SERVER >> CLIENT >> >> CH (GREASE Cipher value & Valid Cipher value) ------> >> >> >> <------- SH (GREASE cipher value) >> >> Fatal alert --------> >> >> TCP (SYN) --------> >> >> >> <-------- >> TCP(SYN ACK) >> >> TCP (ACK) --------> >> >> CH (Valid cipher >> value) -------> >> >> Scenario 1 : Sending FATAL alert for server >> selecting GREASE value >> >> >> >> SERVER >> CLIENT >> >> CH (GREASE Cipher value & Valid Cipher value) -------> >> >> >> <------- SH (GREASE cipher value) >> >> Warning alert --------> >> >> CH (Valid cipher >> value) -------> >> >> Scenario 2 : Sending WARNING alert for server >> selecting GREASE value >> >> >> >> - I hope sending warning msg and restarting TLS handshake will >> be efficient. >> >> - TLS Server must notify the application, whenever it receives >> a GREASE warning alert. >> >> >> >> b) Why only few values are specified as GREASE value ? Basically >> all value which are not specified by IANA should be considered as GREASE >> value right ? >> >> - Basically client should maintain the list of values (cipher >> suite, extensions) specified by IANA. The range of values. >> >> - For example IANA specified cipher suite values are >> {{0x0000,0x005C}, {0x0060,0x006D}, {0x0084, 0x00C5}, {0x00FF, 0x00FF} = =E2=80=A6.. >> }. This should be maintained in client. >> >> - We should make the client to choose a random value which are >> not in this supported value list. That cipher value should be considered= as >> GREASE value and need to keep in first place of its cipher list. >> >> - If its selected by a buggy server, then client should behave >> as mentioned in above scenario 2. >> >> - Even in future if IANA provides new values to new cipher, >> then this list also should be updated. Consider in this case server is >> supporting that new cipher and client is not aware about it, so client c= an >> propose that value as GREASE value, then still connection will work with >> the 2nd handshake. >> >> - I am not understanding why we are planning to maintain a few >> set of GREASE values {0x0A0A, 0x1A1A =E2=80=A6. }. If I am missing somet= hing, >> please clarify me. >> >> >> >> Regards, >> >> R Ashok >> >> >> ------------------------------ >> >> Raja Ashok VK >> =E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8= Huawei Technologies Co., Ltd. >> [image: Company_logo] >> >> Phone: >> Fax: >> Mobile: >> Email: >> Huawei Technologies Co., Ltd. >> Bangalore, India >> >> http://www.huawei.com >> ------------------------------ >> >> =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB= =E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4= =BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB= =99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84= =E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 >> =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB= =E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4= =BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88= =86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96= =E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD >> =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99= =E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7= =AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F= =A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE= =E4=BB=B6=EF=BC=81 >> This e-mail and its attachments contain confidential information from >> HUAWEI, which >> is intended only for the person or entity whose address is listed above. >> Any use of the >> information contained herein in any way (including, but not limited to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender by >> phone or email immediately and delete it! >> >> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *David Benjamin >> *Sent:* 26 July 2016 04:02 >> *To:* tls@ietf.org >> *Subject:* [TLS] Keeping TLS extension points working >> >> >> >> Hi folks, >> >> >> >> I'm not sure how this process usually works, but I would like to reserve >> a bunch of values in the TLS registries to as part of an idea to keep ou= r >> extension points working. Here's an I-D: >> >> https://tools.ietf.org/html/draft-davidben-tls-grease-00 >> >> >> >> (The name GREASE is in honor of AGL's rusted vs. well-oiled joints >> analogy from https://www.imperialviolet.org/2016/05/16/agility.html ) >> >> >> >> One problem we repeatedly run into is servers failing to implement TLS's >> various extension points correctly. The most obvious being version >> intolerance. When we deployed X25519 in Chrome, we discovered an intoler= ant >> implementation. (Thankfully it was rare enough to not warrant a fallback= or >> revert!) It appears that signature algorithms maybe also be gathering ru= st. >> Ciphers and extensions seem to have held up, but I would like to ensure >> they stay that way. >> >> >> >> The root problem here is these broken servers interoperate fine with >> clients at the time they are deployed. It is only after new values get >> defined do we notice, by which time it is too late. >> >> >> >> I would like to fix this by reserving a few values in our registries so >> that clients may advertise random ones and regularly exercise these >> codepaths in servers. If enough of the client base does this, we can tur= n a >> large class of tomorrow's interop failures into today's interop failures= . >> This is important because an bug will not thrive in the ecosystem if it >> does not work against the current deployment. >> >> >> >> If you were in Berlin, you may recognize this idea from the version >> negotiation debate. Alas that all happened in the wrong order as I hadn'= t >> written this up yet. This idea can't be applied to versioning without >> giving up on ClientHello.version, but we can start with the rest of the >> protocol. >> >> >> >> David >> >> >> >> PS: This is actually my first I-D, so apologies if I've messed it up >> somewhere! >> > _______________________________________________ > > >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --94eb2c0579786655aa0539172162 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To expand on that a little, since it seems comments (a) an= d (b) are really the same one:

The purpose of having an = explicitly reserved list (b) is precisely so we do not have to do a second = handshake (a). The purpose here is to ensure we exercise the little-used co= depaths, not introduce new ones.=C2=A0This = is intended to be an extremely minimal mechanism. Clients add a tiny bit of= code to their ClientHello and no server code changes at all. (Note that ev= ery MUST in the document is just reiterating what TLS already requires.)

David
=

On Tue, Aug 2, 2016 at 9:47 AM Steven Valdez <svaldez@google.com> wrote:
a) It= seems like if an implementation has updated to be able to handle a specifi= c GREASE alert, it should be able to handle not sending an invalid cipher s= uite. In general, its probably cleaner for the connection to fatally shutdo= wn and then restart if the server is behaving that poorly. Servers that are= sending back non-existent ciphers are also potentially broken in other way= s, and I don't know whether a client should trust that it can reset any= handshake state correctly if it were to try doing a "warning" al= ert.

b) The reasoning behind having an explicit list is = so that implementations don't send a value that ends up being defined a= s some other valid value. Otherwise its possible that some implementations = will update to include GREASE values, but they might not update immediately= upon new values being assigned by IANA, which means that there will be per= iods of times that some clients might send "fake" values that col= lide with real values, confusing the peer implementation into believing the= y actually support something that they don't and resulting in more into= lerance issues between outdated GREASE clients and newly updated servers, w= ith this intolerance being firmly the GREASE clients fault. The hardcoded l= ist gets around this by making sure GREASE never overlaps with an actual va= lue, though at the trade-off that badly designed implementations could choo= se to just hard-code ignore the GREASE codepoints.

On Tue,= Aug 2, 2016 at 2:59 AM Raja ashok <raja.ashok@huawei.com> wrote:
=

Hi Benjamin,

=C2=A0

I have gone through the G= REASE mechanism which you proposed in your new draft. It=E2=80=99s really a= nice idea for finding a buggy server before it thrives.

=C2=A0

I am having few doubts on= this, which are listed below.

<= span>a)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 What should be the b= ehaviour of client incase if a buggy server responded for a GREASE value ?<= u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Consider a client se= nds a GREASE cipher value at first place and followed by valid cipher suite= s, in its client hello.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a buggy server se= lects that cipher then it will response server hello with that GREASE ciphe= r value. At this case if client sends FATAL alert then both side TLS and TCP needs to be closed and client needs to recreate a ne= w TCP connection, and then restart TLS handshake without GREASE cipher valu= e.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Instead of this we c= an make client to send warning alert (with new TLS alert code GREASE_CIPHER= _VALUE_SELECTED(111)) and restart TLS handshake by sending client hello again.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a server receives= this new warning, then it should be ready to receive new client hello to r= estart handshake.

=C2=A0

SERVER=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

CH (GREASE Cipher value & Valid Cipher value)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ------>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-= ------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SH (GREASE cipher value)

Fatal alert=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --= ------>

TCP (SYN)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----= --->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <--------=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP(SYN ACK)

TCP (ACK)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----= --->

CH (Valid cipher value)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Scenario 1 : Sending FATAL alert for server selecting GREASE valu= e

=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=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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

CH (GREASE Cipher value & Valid Cipher value)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-= ------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SH (GREASE cipher value)

Warning alert=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->

CH (Valid cipher value)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Scenario 2 : Sending WARNING alert for server selecting GREASE va= lue

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I hope sending warni= ng msg and restarting TLS handshake will be efficient.=

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TLS Server must noti= fy the application, whenever it receives a GREASE warning alert.<= /u>

=C2=A0

<= span>b)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Why only few values = are specified as GREASE value ? Basically all value which are not specified= by IANA should be considered as GREASE value right ?

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Basically client sho= uld maintain the list of values (cipher suite, extensions) specified by IAN= A. The range of values.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For example IANA spe= cified cipher suite values are {{0x0000,0x005C}, {0x0060,0x006D}, {0x0084, = 0x00C5}, {0x00FF, 0x00FF} =E2=80=A6.. }. This should be maintained in client.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We should make the c= lient to choose a random value which are not in this supported value list. = That cipher value should be considered as GREASE value and need to keep in first place of its cipher list.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If its selected by a= buggy server, then client should behave as mentioned in above scenario 2.<= u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Even in future if IA= NA provides new values to new cipher, then this list also should be updated= . Consider in this case server is supporting that new cipher and client is not aware about it, so client can propose that value = as GREASE value, then still connection will work with the 2nd ha= ndshake.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am not understandi= ng why we are planning to maintain a few set of GREASE values {0x0A0A, 0x1A= 1A =E2=80=A6. }. If I am missing something, please clarify me.

=C2=A0

Regards,

R Ashok

=C2=A0

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

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

http://www.huawei.com


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

From: TLS [mai= lto:tls-bounces@i= etf.org] On Behalf Of David Benjamin
Sent: 26 July 2016 04:02
To: tls@ietf.org
Subject: [TLS] Keeping TLS extension points working

=C2=A0

Hi folks,

=C2=A0

=C2=A0

(The name GREASE is in honor of AGL's rusted vs.= well-oiled joints analogy from https://www.imperialviolet.org/2016/05/16/agility.html=C2= =A0)

=C2=A0

One problem we repeatedly run into is servers failin= g to implement TLS's various extension points correctly. The most obvio= us being version intolerance. When we deployed X25519 in Chrome, we discove= red an intolerant implementation. (Thankfully it was rare enough to not warrant a fallback or revert!) It appears that s= ignature algorithms maybe also be gathering rust. Ciphers and extensions se= em to have held up, but I would like to ensure they stay that way.

=C2=A0

The root problem here is these broken servers intero= perate fine with clients at the time they are deployed. It is only after ne= w values get defined do we notice, by which time it is too late.<= /u>

=C2=A0

I would like to fix this by=C2=A0reserving a few val= ues in our registries so that clients may advertise random ones and regular= ly exercise these codepaths in servers. If enough of the client base does t= his, we can turn a large class of tomorrow's interop failures into today's interop failures. This is important beca= use an bug will not thrive in the ecosystem if it does not work against the= current deployment.

=C2=A0

If you were in Berlin, you may recognize this idea f= rom the version negotiation debate. Alas that all happened in the wrong ord= er as I hadn't written this up yet. This idea can't be applied to v= ersioning without giving up on ClientHello.version, but we can start with the rest of the protocol.

=C2=A0

David

=C2=A0

PS: This is actually my first I-D, so apologies if I= 've messed it up somewhere!

_______________________________________________
--94eb2c0579786655aa0539172162-- From nobody Tue Aug 2 07:03:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A9412D66F for ; Tue, 2 Aug 2016 07:02: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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8UNnKjkmcPA for ; Tue, 2 Aug 2016 07:02:56 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415DA12D665 for ; Tue, 2 Aug 2016 07:02:56 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id s189so123128902vkh.1 for ; Tue, 02 Aug 2016 07:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kxGHFgedChIbkH+Hs+GG+Zw6X1XSCe+rQnLUqBNGjFU=; b=bSq7vjBWDU/aNvY2M9Vv6IV3+vBQJrwoLtJjlDtEglqy3KTlB23XqWXfyheRVKwGnB y3f+l1FQeihFken+6KZROz2/WvAkJ4IlVeRC9y5J8Ni8MI/PPxpNh66uLieNIt5xfQlZ XJ10CkBprFN7BYbBuooKSo8McdWhMxX62W97P9w41AfQxWzyST1cUb3GNUK8fPhyyhlY 60Yr+qlAqMTII1ONUEMlVzDCMLVasf3HICSOIPnCMVroceP43dKopGi93jpK+/EdMp3f 2iGcieWCzY4Q5LoFtLd1qyKo6k7fKoqF3JoOZsx1B+wwQ4vRTMqyc5ncCyHOwR+SQJ2E CGFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kxGHFgedChIbkH+Hs+GG+Zw6X1XSCe+rQnLUqBNGjFU=; b=MCz6j5Ligmj+uVwdiiyOhdK0y1r+ICprxUoWxBhhyVm1xXTyb5na7v2h/mUYvgmL7r dFUvTJsiH82P3TGwvEObA81ojvccMqgRCIG9BM1VNt3PQw/v5jXpidFuBWDw69JEJo56 GTDml2wCqEQzygTmnKnY/D8+KcqE4/w01f1rqJE2Kk1ApA1w6gug6HujGjEwbyFXte5D Xt8R2z9Mhk0v6avURlVIEyuZLHsOS3vy5vhqVC0qm0bf0fg4V8vOKTUFh1BltgKlovrA TCBjKtZL4Z1lnJqWs386a608UdmxL4+AFsgSoG2e5IujiAuDusMGr8iub5b7YyShWzb2 dDXA== X-Gm-Message-State: AEkoousCQ8vEBrOWrdH5rEXFMrc9WTNyv4HtVPsum8gdfugf0t38ZN6blAGlwEizj05E9hkmf+6aCrbyTIMPnw== X-Received: by 10.31.128.80 with SMTP id b77mr21370165vkd.31.1470146575295; Tue, 02 Aug 2016 07:02:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Tue, 2 Aug 2016 07:02:54 -0700 (PDT) In-Reply-To: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> From: Watson Ladd Date: Tue, 2 Aug 2016 07:02:54 -0700 Message-ID: To: "Bauer Johannes (HOME/EFS)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 14:02:59 -0000 On Tue, Aug 2, 2016 at 6:33 AM, Bauer Johannes (HOME/EFS) wrote: > Dear mailing list, > > regarding RFC5746 (https://tools.ietf.org/rfc/rfc5746.txt) I do have a qu= estion which could not be solved in our internal discussions. Therefore I w= ould kindly ask for your comments on my issue. If I posted to the wrong pla= ce, please advise on where such a question would be relevant instead. > > The question revolves around TLS servers (and clients) which do not suppo= rt renegotiation at. The server side is the more interesting of the two, he= nce I will discuss it first. Sect 4.3 says: > > In order to enable clients to probe, even servers that do not support > renegotiation MUST implement the minimal version of the extension > described in this document for initial handshakes, thus signaling > that they have been upgraded. > > This hint refers to Sect. 3.6 ("Server Behavior: Initial Handshake"). It = says that a server in any case (independent if it supports or does not supp= ort renegotiation at all) must send a empty renegotiation_info TLS extensio= n as soon as it receives a client request for that info (be it either by a = renegotiation_info or by the SCSV). Sending that empty renegotiation_info i= s really no problem even for deeply embedded TLS servers (the message is on= ly 5 bytes and always static). > > However, there is also this in Sect. 3.6 which has caused some confusion = and lengthy discussion among my colleagues and myself: > > o When the handshake has completed, the server needs to save the > client_verify_data and server_verify_data values for future use. Yes, and since it doesn't read them out, it should use write only memory as an optimization. Sincerely, Watson Ladd From nobody Tue Aug 2 07:33:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B1F12D75F for ; Tue, 2 Aug 2016 07:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bosch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGkBIqHJikhc for ; Tue, 2 Aug 2016 07:33:10 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [139.15.237.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 B481712D62C for ; Tue, 2 Aug 2016 07:33:10 -0700 (PDT) Received: from vsmta12.fe.internet.bosch.com (unknown [10.4.98.52]) by imta24.fe.bosch.de (Postfix) with ESMTP id 396CED80212 for ; Tue, 2 Aug 2016 16:32:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bosch.com; s=2015-01-21; t=1470148372; bh=nDZnItBVtxKd+iNers7baYZGvLoLOZUcvlPkWcju4/I=; l=10; h=From:From:Reply-To:Sender; b=rBB9sLfRypfOMpt5mIy4ZmlTOUpEyNqKLvrHeCoNnkZcaPAcwJl/BDRWszK9w+5/U Y8mDHS5WR7pmKyCiI70qVhBxtC9g8g5uzWfqniJqiHq5B+eo2Sjb1gxRAUQRfltspS LWP3smkTtIShA4nT0mkA6eEw0SaRbs5s/n2AoxFU= Received: from FE-MBX1015.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta12.fe.internet.bosch.com (Postfix) with ESMTP id 1B1F71B80249 for ; Tue, 2 Aug 2016 16:32:52 +0200 (CEST) Received: from FE-MBX1015.de.bosch.com (10.3.230.73) by FE-MBX1015.de.bosch.com (10.3.230.73) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 16:32:51 +0200 Received: from FE-MBX1015.de.bosch.com ([fe80::256d:ef59:31f1:323f]) by FE-MBX1015.de.bosch.com ([fe80::256d:ef59:31f1:323f%16]) with mapi id 15.00.1178.000; Tue, 2 Aug 2016 16:32:51 +0200 From: "Bauer Johannes (HOME/EFS)" To: "tls@ietf.org" Thread-Topic: [TLS] RFC5746: Renegotiation Indication for minimal servers Thread-Index: AQHR7MJvU2wvbTQxuUivvvKs9ZJJXKA1khQAgAAp0U4= Date: Tue, 2 Aug 2016 14:32:51 +0000 Message-ID: <1470148363699.24362@bosch.com> References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.35.28.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22488.006 X-TMASE-MatchedRID: u7Yf2n7Ca/0OwH4pD14DsPHkpkyUphL9NRv92EahEcGae6AcsiK/zS67 0e2gJiRY/OqQkvG7OOLDCwrx7OfXzR77VnTa7axqnW/laudJFeHuHZGuwo6K7cWkDW4kV3WaVhb DEH23DRPAwRlxCkpvJc/TS0hmvgWiirAuOoI0LM9/TWpwlAOFXilayzmQ9QV0iJR9DUWlpdWsDv qgCInmxur3/Mxc2X121ErQgs4x3dQkbusa5WEazm/CU2X9JBM7MUUuEZQPwBZQ3OD8q9D1sNanw ebW+WZ+a0m6sXM91wvYBuOPSxM8lywVHyAZiiCXXTIj5rfOJxUzKi5mdHI8OJsoi2XrUn/JUXy2 kgFQ7coqtq5d3cxkNUJ3Dv3/4w3bXeNO/ufOMQDA2Y+Ets8zRBfgCUkfIo4rBBLu/70QB7DAvpL E+mvX8g== Archived-At: Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 14:33:16 -0000 Hi Watson,=0A= =0A= On Tue, Aug 2, 2016 at 16:02, Watson Ladd wrote:=0A= >> However, there is also this in Sect. 3.6 which has caused some confusion= and lengthy discussion among my colleagues and myself:=0A= >>=0A= >> o When the handshake has completed, the server needs to save the=0A= >> client_verify_data and server_verify_data values for future use.= =0A= >=0A= >Yes, and since it doesn't read them out, it should use write only=0A= >memory as an optimization.=0A= =0A= So I take it my interpretation is correct -- these values are only ever req= uired for renegotiation and serve no other purpose? I.e. the hint can safel= y be ignored in this case and the implementation will still be fully RFC574= 6-compliant?=0A= =0A= All joking aside, this has seriously led to some discussions where implemen= tation of said RFC was rejected because of the overhead it might cause. And= even among some people who write SSL stacks for a living.=0A= =0A= So while, if the RFC is read correctly (it's "need", not "MUST"), this is o= bvious, it really is confusing in practice. Since wide adoption of this RFC= is of interest to everyone, I think an official clarification might help t= remendously. Even if it's really obvious for people who design TLS :-)=0A= =0A= Cheers,=0A= Johannes=0A= =0A= =0A= --=0A= Johannes Bauer=0A= =0A= Engineering Field Services (HOME/EFS)=0A= Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 Stuttgart-Vaihin= gen | GERMANY | www.bosch-smarthome.com=0A= Tel. +49(711)81112906 | johannes.bauer@bosch.com=0A= Registergericht: Amtsgericht Stuttgart, HRB 754585;=0A= Gesch=E4ftsf=FChrung: Dr. Peter Schnaebele, Veronika Danner=0A= From nobody Tue Aug 2 07:57:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719F112D787 for ; Tue, 2 Aug 2016 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be6nA0OaI4rI for ; Tue, 2 Aug 2016 07:57:23 -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 7921B12D67D for ; Tue, 2 Aug 2016 07:57:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3CF70433421; Tue, 2 Aug 2016 14:57:22 +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 2709343341C; Tue, 2 Aug 2016 14:57:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470149842; bh=fZ0FJWh1Y+SAK7F9rPStV22EGfJdSfPjT7xMsG373Ik=; l=2563; h=To:References:From:Date:In-Reply-To:From; b=hRQCDIHB8AThFjoPR5ouo3J6Q3J843TMvPVhccfPypner8sUpaQn5VHXdc5kjVl8b 7KeQMF0yqGkHOrdTLxuBj9qG0Feh1q/jFVRUAORisy2MBtXy8MA5JN2ZM0AJEHRn+M 6zGDaX80H06U4LeWYKYTEAZLqTOpnNOZKn6NsFds= 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 F20441FC86; Tue, 2 Aug 2016 14:57:21 +0000 (GMT) To: "Bauer Johannes (HOME/EFS)" , "tls@ietf.org" References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> <1470148363699.24362@bosch.com> From: Benjamin Kaduk Message-ID: <4ff68fa1-0d8e-ed1e-064c-8bb5bbf5935a@akamai.com> Date: Tue, 2 Aug 2016 09:57:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1470148363699.24362@bosch.com> Content-Type: multipart/alternative; boundary="------------0CFAC254830D4D1F59D0B388" Archived-At: Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2016 14:57:25 -0000 This is a multi-part message in MIME format. --------------0CFAC254830D4D1F59D0B388 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/02/2016 09:32 AM, Bauer Johannes (HOME/EFS) wrote: > > So I take it my interpretation is correct -- these values are only ever required for renegotiation and serve no other purpose? I.e. the hint can safely be ignored in this case and the implementation will still be fully RFC5746-compliant? > > All joking aside, this has seriously led to some discussions where implementation of said RFC was rejected because of the overhead it might cause. And even among some people who write SSL stacks for a living. > > So while, if the RFC is read correctly (it's "need", not "MUST"), this is obvious, it really is confusing in practice. Since wide adoption of this RFC is of interest to everyone, I think an official clarification might help tremendously. Even if it's really obvious for people who design TLS :-) > The next step is for someone to write proposed text that would be more clear. Maybe you have thoughts about how things could change? -Ben --------------0CFAC254830D4D1F59D0B388 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 08/02/2016 09:32 AM, Bauer Johannes (HOME/EFS) wrote:

So I take it my interpretation is correct -- these values are only ever required for renegotiation and serve no other purpose? I.e. the hint can safely be ignored in this case and the implementation will still be fully RFC5746-compliant?

All joking aside, this has seriously led to some discussions where implementation of said RFC was rejected because of the overhead it might cause. And even among some people who write SSL stacks for a living.

So while, if the RFC is read correctly (it's "need", not "MUST"), this is obvious, it really is confusing in practice. Since wide adoption of this RFC is of interest to everyone, I think an official clarification might help tremendously. Even if it's really obvious for people who design TLS :-)

The next step is for someone to write proposed text that would be more clear.  Maybe you have thoughts about how things could change?

-Ben
--------------0CFAC254830D4D1F59D0B388-- From nobody Wed Aug 3 05:52:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAA612DB37 for ; Wed, 3 Aug 2016 05:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuLEIFYlNhxP for ; Wed, 3 Aug 2016 05:52:44 -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 3F32112D16D for ; Wed, 3 Aug 2016 05:52:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTS18127; Wed, 03 Aug 2016 12:52:39 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 3 Aug 2016 13:52:37 +0100 Received: from BLREML502-MBX.china.huawei.com ([10.20.5.202]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Wed, 3 Aug 2016 18:22:27 +0530 From: Raja ashok To: David Benjamin , Steven Valdez , "tls@ietf.org" Thread-Topic: [TLS] Keeping TLS extension points working Thread-Index: AQHR5sSGP8jlE9Wa4UKbNZzI09Q7v6A0G4+wgAFDbwCAAAN9gIAB1Lyw Date: Wed, 3 Aug 2016 12:52:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF7ABblreml502mbx_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57A1E918.02D7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: eba87a304597647918d09405a345ac30 Archived-At: Subject: Re: [TLS] Keeping TLS extension points working X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Aug 2016 12:52:49 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF7ABblreml502mbx_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF7ABblreml502mbx_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF7ABblreml502mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQgJiBTdGV2ZW4sDQoNCkhlcmUgb3VyIGludGVuc2lvbiBpcyB0byBmaW5kIG91dCBi dWdneSBzZXJ2ZXIgd2hpY2ggaW1wbGVtZW50ZWQgYSBjaXBoZXIgc3VpdGUgc3VwcG9ydCB3aXRo IHdyb25nIHZhbHVlIG90aGVyIHRoYW4gc3BlY2lmaWVkIGluIFJGQy4NCg0KLSAgICAgICAgICBJ ZiB0aGF0IHdyb25nIHZhbHVlIHVzYWdlIGluIHRoYXQgYnVnZ3kgc2VydmVyIGNvbGxpZGVzIHdp dGggYW55IHJlYWwgY2lwaGVyIHN1aXRlIG9uIHRoZSBwZXJpb2Qgb2YgZGVwbG95bWVudCBtZWFu cywgdGhlIGJ1ZyB3b3VsZCBoYXZlIGlkZW50aWZpZWQgaW1tZWRpYXRlbHkgd2l0aCBzb21lIG90 aGVyIG5vbiBidWdneSBjbGllbnQuDQoNCi0gICAgICAgICAgSWYgdGhhdCB3cm9uZyB2YWx1ZSBp cyBpbiB0aGUgcmFuZ2Ugb2YgdW5zcGVjaWZpZWQgdmFsdWUsIHRoZW4gdGhhdCBidWcgdGhyaXZl cyBhbmQgaXQgd2lsbCBjb21lIG91dCBvbmx5IGFmdGVyIHNldmVyYWwgeWVhcnMgd2hlbiBJQU5B IGFzc2lnbnMgdGhhdCB2YWx1ZSB0byBzb21lIG5ldyBjaXBoZXIgc3VpdGUuDQoNCkluIHRoaXMg Y2FzZSwgY2FuIHlvdSBwbGVhc2UgdGVsbCBtZSB3aHkgd2UgZGVjaWRlZCBvbmx5IGZldyB2YWx1 ZXMgYXMgR1JFQVNFIHZhbHVlIHsweDBBMEEsIDB4MUExQSwgLi59LiBXaGV0aGVyIGNocm9tZSBi cm93c2VyIGhhcyBmb3VuZCBhIHJlYWwgYnVnZ3kgd2ViIHNlcnZlciB3aGljaCBzdXBwb3J0cyB0 aGVzZSB2YWx1ZXMgPw0KDQpSZWdhcmRzLA0KUiBBc2hvaw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClJhamEgQXNob2sgVksNCuWNjuS4uuaKgOacr+aciemZkOWFrOWPuCBIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KW0NvbXBhbnlfbG9nb10NCg0KUGhvbmU6DQpGYXg6 DQpNb2JpbGU6DQpFbWFpbDoNCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpCYW5nYWxv cmUsIEluZGlhDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQrmnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53l r4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrk urrmiJbnvqTnu4TjgILnpoENCuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eU qO+8iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOA geaIluaVo+WPke+8ieacrOmCruS7tuS4rQ0K55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG 5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm2 5Yig6Zmk5pys6YKu5Lu277yBDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRh aW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5k ZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQg YWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFu eSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpk aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3Ro ZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5 DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KRnJvbTogRGF2aWQg QmVuamFtaW4gW21haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5vcmddDQpTZW50OiAwMiBBdWd1c3Qg MjAxNiAxOTozMA0KVG86IFN0ZXZlbiBWYWxkZXo7IFJhamEgYXNob2s7IHRsc0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtUTFNdIEtlZXBpbmcgVExTIGV4dGVuc2lvbiBwb2ludHMgd29ya2luZw0K DQpUbyBleHBhbmQgb24gdGhhdCBhIGxpdHRsZSwgc2luY2UgaXQgc2VlbXMgY29tbWVudHMgKGEp IGFuZCAoYikgYXJlIHJlYWxseSB0aGUgc2FtZSBvbmU6DQoNClRoZSBwdXJwb3NlIG9mIGhhdmlu ZyBhbiBleHBsaWNpdGx5IHJlc2VydmVkIGxpc3QgKGIpIGlzIHByZWNpc2VseSBzbyB3ZSBkbyBu b3QgaGF2ZSB0byBkbyBhIHNlY29uZCBoYW5kc2hha2UgKGEpLiBUaGUgcHVycG9zZSBoZXJlIGlz IHRvIGVuc3VyZSB3ZSBleGVyY2lzZSB0aGUgbGl0dGxlLXVzZWQgY29kZXBhdGhzLCBub3QgaW50 cm9kdWNlIG5ldyBvbmVzLiBUaGlzIGlzIGludGVuZGVkIHRvIGJlIGFuIGV4dHJlbWVseSBtaW5p bWFsIG1lY2hhbmlzbS4gQ2xpZW50cyBhZGQgYSB0aW55IGJpdCBvZiBjb2RlIHRvIHRoZWlyIENs aWVudEhlbGxvIGFuZCBubyBzZXJ2ZXIgY29kZSBjaGFuZ2VzIGF0IGFsbC4gKE5vdGUgdGhhdCBl dmVyeSBNVVNUIGluIHRoZSBkb2N1bWVudCBpcyBqdXN0IHJlaXRlcmF0aW5nIHdoYXQgVExTIGFs cmVhZHkgcmVxdWlyZXMuKQ0KDQpEYXZpZA0KDQpPbiBUdWUsIEF1ZyAyLCAyMDE2IGF0IDk6NDcg QU0gU3RldmVuIFZhbGRleiA8c3ZhbGRlekBnb29nbGUuY29tPG1haWx0bzpzdmFsZGV6QGdvb2ds ZS5jb20+PiB3cm90ZToNCmEpIEl0IHNlZW1zIGxpa2UgaWYgYW4gaW1wbGVtZW50YXRpb24gaGFz IHVwZGF0ZWQgdG8gYmUgYWJsZSB0byBoYW5kbGUgYSBzcGVjaWZpYyBHUkVBU0UgYWxlcnQsIGl0 IHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSBub3Qgc2VuZGluZyBhbiBpbnZhbGlkIGNpcGhlciBz dWl0ZS4gSW4gZ2VuZXJhbCwgaXRzIHByb2JhYmx5IGNsZWFuZXIgZm9yIHRoZSBjb25uZWN0aW9u IHRvIGZhdGFsbHkgc2h1dGRvd24gYW5kIHRoZW4gcmVzdGFydCBpZiB0aGUgc2VydmVyIGlzIGJl aGF2aW5nIHRoYXQgcG9vcmx5LiBTZXJ2ZXJzIHRoYXQgYXJlIHNlbmRpbmcgYmFjayBub24tZXhp c3RlbnQgY2lwaGVycyBhcmUgYWxzbyBwb3RlbnRpYWxseSBicm9rZW4gaW4gb3RoZXIgd2F5cywg YW5kIEkgZG9uJ3Qga25vdyB3aGV0aGVyIGEgY2xpZW50IHNob3VsZCB0cnVzdCB0aGF0IGl0IGNh biByZXNldCBhbnkgaGFuZHNoYWtlIHN0YXRlIGNvcnJlY3RseSBpZiBpdCB3ZXJlIHRvIHRyeSBk b2luZyBhICJ3YXJuaW5nIiBhbGVydC4NCg0KYikgVGhlIHJlYXNvbmluZyBiZWhpbmQgaGF2aW5n IGFuIGV4cGxpY2l0IGxpc3QgaXMgc28gdGhhdCBpbXBsZW1lbnRhdGlvbnMgZG9uJ3Qgc2VuZCBh IHZhbHVlIHRoYXQgZW5kcyB1cCBiZWluZyBkZWZpbmVkIGFzIHNvbWUgb3RoZXIgdmFsaWQgdmFs dWUuIE90aGVyd2lzZSBpdHMgcG9zc2libGUgdGhhdCBzb21lIGltcGxlbWVudGF0aW9ucyB3aWxs IHVwZGF0ZSB0byBpbmNsdWRlIEdSRUFTRSB2YWx1ZXMsIGJ1dCB0aGV5IG1pZ2h0IG5vdCB1cGRh dGUgaW1tZWRpYXRlbHkgdXBvbiBuZXcgdmFsdWVzIGJlaW5nIGFzc2lnbmVkIGJ5IElBTkEsIHdo aWNoIG1lYW5zIHRoYXQgdGhlcmUgd2lsbCBiZSBwZXJpb2RzIG9mIHRpbWVzIHRoYXQgc29tZSBj bGllbnRzIG1pZ2h0IHNlbmQgImZha2UiIHZhbHVlcyB0aGF0IGNvbGxpZGUgd2l0aCByZWFsIHZh bHVlcywgY29uZnVzaW5nIHRoZSBwZWVyIGltcGxlbWVudGF0aW9uIGludG8gYmVsaWV2aW5nIHRo ZXkgYWN0dWFsbHkgc3VwcG9ydCBzb21ldGhpbmcgdGhhdCB0aGV5IGRvbid0IGFuZCByZXN1bHRp bmcgaW4gbW9yZSBpbnRvbGVyYW5jZSBpc3N1ZXMgYmV0d2VlbiBvdXRkYXRlZCBHUkVBU0UgY2xp ZW50cyBhbmQgbmV3bHkgdXBkYXRlZCBzZXJ2ZXJzLCB3aXRoIHRoaXMgaW50b2xlcmFuY2UgYmVp bmcgZmlybWx5IHRoZSBHUkVBU0UgY2xpZW50cyBmYXVsdC4gVGhlIGhhcmRjb2RlZCBsaXN0IGdl dHMgYXJvdW5kIHRoaXMgYnkgbWFraW5nIHN1cmUgR1JFQVNFIG5ldmVyIG92ZXJsYXBzIHdpdGgg YW4gYWN0dWFsIHZhbHVlLCB0aG91Z2ggYXQgdGhlIHRyYWRlLW9mZiB0aGF0IGJhZGx5IGRlc2ln bmVkIGltcGxlbWVudGF0aW9ucyBjb3VsZCBjaG9vc2UgdG8ganVzdCBoYXJkLWNvZGUgaWdub3Jl IHRoZSBHUkVBU0UgY29kZXBvaW50cy4NCg0KT24gVHVlLCBBdWcgMiwgMjAxNiBhdCAyOjU5IEFN IFJhamEgYXNob2sgPHJhamEuYXNob2tAaHVhd2VpLmNvbTxtYWlsdG86cmFqYS5hc2hva0BodWF3 ZWkuY29tPj4gd3JvdGU6DQpIaSBCZW5qYW1pbiwNCg0KSSBoYXZlIGdvbmUgdGhyb3VnaCB0aGUg R1JFQVNFIG1lY2hhbmlzbSB3aGljaCB5b3UgcHJvcG9zZWQgaW4geW91ciBuZXcgZHJhZnQuIEl0 4oCZcyByZWFsbHkgYSBuaWNlIGlkZWEgZm9yIGZpbmRpbmcgYSBidWdneSBzZXJ2ZXIgYmVmb3Jl IGl0IHRocml2ZXMuDQoNCkkgYW0gaGF2aW5nIGZldyBkb3VidHMgb24gdGhpcywgd2hpY2ggYXJl IGxpc3RlZCBiZWxvdy4NCg0KYSkgICAgICBXaGF0IHNob3VsZCBiZSB0aGUgYmVoYXZpb3VyIG9m IGNsaWVudCBpbmNhc2UgaWYgYSBidWdneSBzZXJ2ZXIgcmVzcG9uZGVkIGZvciBhIEdSRUFTRSB2 YWx1ZSA/DQoNCi0gICAgICAgICAgQ29uc2lkZXIgYSBjbGllbnQgc2VuZHMgYSBHUkVBU0UgY2lw aGVyIHZhbHVlIGF0IGZpcnN0IHBsYWNlIGFuZCBmb2xsb3dlZCBieSB2YWxpZCBjaXBoZXIgc3Vp dGVzLCBpbiBpdHMgY2xpZW50IGhlbGxvLg0KDQotICAgICAgICAgIElmIGEgYnVnZ3kgc2VydmVy IHNlbGVjdHMgdGhhdCBjaXBoZXIgdGhlbiBpdCB3aWxsIHJlc3BvbnNlIHNlcnZlciBoZWxsbyB3 aXRoIHRoYXQgR1JFQVNFIGNpcGhlciB2YWx1ZS4gQXQgdGhpcyBjYXNlIGlmIGNsaWVudCBzZW5k cyBGQVRBTCBhbGVydCB0aGVuIGJvdGggc2lkZSBUTFMgYW5kIFRDUCBuZWVkcyB0byBiZSBjbG9z ZWQgYW5kIGNsaWVudCBuZWVkcyB0byByZWNyZWF0ZSBhIG5ldyBUQ1AgY29ubmVjdGlvbiwgYW5k IHRoZW4gcmVzdGFydCBUTFMgaGFuZHNoYWtlIHdpdGhvdXQgR1JFQVNFIGNpcGhlciB2YWx1ZS4N Cg0KLSAgICAgICAgICBJbnN0ZWFkIG9mIHRoaXMgd2UgY2FuIG1ha2UgY2xpZW50IHRvIHNlbmQg d2FybmluZyBhbGVydCAod2l0aCBuZXcgVExTIGFsZXJ0IGNvZGUgR1JFQVNFX0NJUEhFUl9WQUxV RV9TRUxFQ1RFRCgxMTEpKSBhbmQgcmVzdGFydCBUTFMgaGFuZHNoYWtlIGJ5IHNlbmRpbmcgY2xp ZW50IGhlbGxvIGFnYWluLg0KDQotICAgICAgICAgIElmIGEgc2VydmVyIHJlY2VpdmVzIHRoaXMg bmV3IHdhcm5pbmcsIHRoZW4gaXQgc2hvdWxkIGJlIHJlYWR5IHRvIHJlY2VpdmUgbmV3IGNsaWVu dCBoZWxsbyB0byByZXN0YXJ0IGhhbmRzaGFrZS4NCg0KDQoNClNFUlZFUiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDTElFTlQN Cg0KQ0ggKEdSRUFTRSBDaXBoZXIgdmFsdWUgJiBWYWxpZCBDaXBoZXIgdmFsdWUpICAgICAgICAg IC0tLS0tLT4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0gICAgICAgICAgICAgICAgICBTSCAo R1JFQVNFIGNpcGhlciB2YWx1ZSkNCg0KRmF0YWwgYWxlcnQgICAgICAgICAgICAgICAgICAgIC0t LS0tLS0tPg0KDQpUQ1AgKFNZTikgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tPg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLSAgICAg ICAgICAgICAgICBUQ1AoU1lOIEFDSykNCg0KVENQIChBQ0spICAgICAgICAgICAgICAgICAgICAt LS0tLS0tLT4NCg0KQ0ggKFZhbGlkIGNpcGhlciB2YWx1ZSkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLT4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgU2NlbmFyaW8gMSA6IFNlbmRpbmcgRkFUQUwgYWxlcnQgZm9yIHNlcnZl ciBzZWxlY3RpbmcgR1JFQVNFIHZhbHVlDQoNCg0KDQpTRVJWRVIgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ0xJRU5UDQoNCkNI IChHUkVBU0UgQ2lwaGVyIHZhbHVlICYgVmFsaWQgQ2lwaGVyIHZhbHVlKSAgICAgICAgICAtLS0t LS0tPg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLSAgICAgICAgICAgICAgICAgIFNIIChHUkVB U0UgY2lwaGVyIHZhbHVlKQ0KDQpXYXJuaW5nIGFsZXJ0ICAgICAgICAgICAgIC0tLS0tLS0tPg0K DQpDSCAoVmFsaWQgY2lwaGVyIHZhbHVlKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tPg0KDQogICAgICAgICAgICAgICAgICAg ICAgICBTY2VuYXJpbyAyIDogU2VuZGluZyBXQVJOSU5HIGFsZXJ0IGZvciBzZXJ2ZXIgc2VsZWN0 aW5nIEdSRUFTRSB2YWx1ZQ0KDQoNCg0KLSAgICAgICAgICBJIGhvcGUgc2VuZGluZyB3YXJuaW5n IG1zZyBhbmQgcmVzdGFydGluZyBUTFMgaGFuZHNoYWtlIHdpbGwgYmUgZWZmaWNpZW50Lg0KDQot ICAgICAgICAgIFRMUyBTZXJ2ZXIgbXVzdCBub3RpZnkgdGhlIGFwcGxpY2F0aW9uLCB3aGVuZXZl ciBpdCByZWNlaXZlcyBhIEdSRUFTRSB3YXJuaW5nIGFsZXJ0Lg0KDQoNCg0KYikgICAgICBXaHkg b25seSBmZXcgdmFsdWVzIGFyZSBzcGVjaWZpZWQgYXMgR1JFQVNFIHZhbHVlID8gQmFzaWNhbGx5 IGFsbCB2YWx1ZSB3aGljaCBhcmUgbm90IHNwZWNpZmllZCBieSBJQU5BIHNob3VsZCBiZSBjb25z aWRlcmVkIGFzIEdSRUFTRSB2YWx1ZSByaWdodCA/DQoNCi0gICAgICAgICAgQmFzaWNhbGx5IGNs aWVudCBzaG91bGQgbWFpbnRhaW4gdGhlIGxpc3Qgb2YgdmFsdWVzIChjaXBoZXIgc3VpdGUsIGV4 dGVuc2lvbnMpIHNwZWNpZmllZCBieSBJQU5BLiBUaGUgcmFuZ2Ugb2YgdmFsdWVzLg0KDQotICAg ICAgICAgIEZvciBleGFtcGxlIElBTkEgc3BlY2lmaWVkIGNpcGhlciBzdWl0ZSB2YWx1ZXMgYXJl IHt7MHgwMDAwLDB4MDA1Q30sIHsweDAwNjAsMHgwMDZEfSwgezB4MDA4NCwgMHgwMEM1fSwgezB4 MDBGRiwgMHgwMEZGfSDigKYuLiB9LiBUaGlzIHNob3VsZCBiZSBtYWludGFpbmVkIGluIGNsaWVu dC4NCg0KLSAgICAgICAgICBXZSBzaG91bGQgbWFrZSB0aGUgY2xpZW50IHRvIGNob29zZSBhIHJh bmRvbSB2YWx1ZSB3aGljaCBhcmUgbm90IGluIHRoaXMgc3VwcG9ydGVkIHZhbHVlIGxpc3QuIFRo YXQgY2lwaGVyIHZhbHVlIHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIEdSRUFTRSB2YWx1ZSBhbmQg bmVlZCB0byBrZWVwIGluIGZpcnN0IHBsYWNlIG9mIGl0cyBjaXBoZXIgbGlzdC4NCg0KLSAgICAg ICAgICBJZiBpdHMgc2VsZWN0ZWQgYnkgYSBidWdneSBzZXJ2ZXIsIHRoZW4gY2xpZW50IHNob3Vs ZCBiZWhhdmUgYXMgbWVudGlvbmVkIGluIGFib3ZlIHNjZW5hcmlvIDIuDQoNCi0gICAgICAgICAg RXZlbiBpbiBmdXR1cmUgaWYgSUFOQSBwcm92aWRlcyBuZXcgdmFsdWVzIHRvIG5ldyBjaXBoZXIs IHRoZW4gdGhpcyBsaXN0IGFsc28gc2hvdWxkIGJlIHVwZGF0ZWQuIENvbnNpZGVyIGluIHRoaXMg Y2FzZSBzZXJ2ZXIgaXMgc3VwcG9ydGluZyB0aGF0IG5ldyBjaXBoZXIgYW5kIGNsaWVudCBpcyBu b3QgYXdhcmUgYWJvdXQgaXQsIHNvIGNsaWVudCBjYW4gcHJvcG9zZSB0aGF0IHZhbHVlIGFzIEdS RUFTRSB2YWx1ZSwgdGhlbiBzdGlsbCBjb25uZWN0aW9uIHdpbGwgd29yayB3aXRoIHRoZSAybmQg aGFuZHNoYWtlLg0KDQotICAgICAgICAgIEkgYW0gbm90IHVuZGVyc3RhbmRpbmcgd2h5IHdlIGFy ZSBwbGFubmluZyB0byBtYWludGFpbiBhIGZldyBzZXQgb2YgR1JFQVNFIHZhbHVlcyB7MHgwQTBB LCAweDFBMUEg4oCmLiB9LiBJZiBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBwbGVhc2UgY2xhcmlm eSBtZS4NCg0KUmVnYXJkcywNClIgQXNob2sNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClJhamEgQXNob2sgVksNCuWNjuS4uuaKgOacr+aciemZkOWFrOWPuCBIdWF3ZWkgVGVj aG5vbG9naWVzIENvLiwgTHRkLg0KW0NvbXBhbnlfbG9nb10NCg0KUGhvbmU6DQpGYXg6DQpNb2Jp bGU6DQpFbWFpbDoNCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpCYW5nYWxvcmUsIElu ZGlhDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQrmnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hm ga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbn vqTnu4TjgILnpoENCuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWM heaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaV o+WPke+8ieacrOmCruS7tuS4rQ0K55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu 5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk 5pys6YKu5Lu277yBDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25s eSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUu IEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkg KGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9z dXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhh biB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2 ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9u ZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KRnJvbTogVExTIFttYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVo YWxmIE9mIERhdmlkIEJlbmphbWluDQpTZW50OiAyNiBKdWx5IDIwMTYgMDQ6MDINClRvOiB0bHNA aWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtUTFNdIEtlZXBpbmcgVExT IGV4dGVuc2lvbiBwb2ludHMgd29ya2luZw0KDQpIaSBmb2xrcywNCg0KSSdtIG5vdCBzdXJlIGhv dyB0aGlzIHByb2Nlc3MgdXN1YWxseSB3b3JrcywgYnV0IEkgd291bGQgbGlrZSB0byByZXNlcnZl IGEgYnVuY2ggb2YgdmFsdWVzIGluIHRoZSBUTFMgcmVnaXN0cmllcyB0byBhcyBwYXJ0IG9mIGFu IGlkZWEgdG8ga2VlcCBvdXIgZXh0ZW5zaW9uIHBvaW50cyB3b3JraW5nLiBIZXJlJ3MgYW4gSS1E Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRhdmlkYmVuLXRscy1ncmVhc2Ut MDANCg0KKFRoZSBuYW1lIEdSRUFTRSBpcyBpbiBob25vciBvZiBBR0wncyBydXN0ZWQgdnMuIHdl bGwtb2lsZWQgam9pbnRzIGFuYWxvZ3kgZnJvbSBodHRwczovL3d3dy5pbXBlcmlhbHZpb2xldC5v cmcvMjAxNi8wNS8xNi9hZ2lsaXR5Lmh0bWwgKQ0KDQpPbmUgcHJvYmxlbSB3ZSByZXBlYXRlZGx5 IHJ1biBpbnRvIGlzIHNlcnZlcnMgZmFpbGluZyB0byBpbXBsZW1lbnQgVExTJ3MgdmFyaW91cyBl eHRlbnNpb24gcG9pbnRzIGNvcnJlY3RseS4gVGhlIG1vc3Qgb2J2aW91cyBiZWluZyB2ZXJzaW9u IGludG9sZXJhbmNlLiBXaGVuIHdlIGRlcGxveWVkIFgyNTUxOSBpbiBDaHJvbWUsIHdlIGRpc2Nv dmVyZWQgYW4gaW50b2xlcmFudCBpbXBsZW1lbnRhdGlvbi4gKFRoYW5rZnVsbHkgaXQgd2FzIHJh cmUgZW5vdWdoIHRvIG5vdCB3YXJyYW50IGEgZmFsbGJhY2sgb3IgcmV2ZXJ0ISkgSXQgYXBwZWFy cyB0aGF0IHNpZ25hdHVyZSBhbGdvcml0aG1zIG1heWJlIGFsc28gYmUgZ2F0aGVyaW5nIHJ1c3Qu IENpcGhlcnMgYW5kIGV4dGVuc2lvbnMgc2VlbSB0byBoYXZlIGhlbGQgdXAsIGJ1dCBJIHdvdWxk IGxpa2UgdG8gZW5zdXJlIHRoZXkgc3RheSB0aGF0IHdheS4NCg0KVGhlIHJvb3QgcHJvYmxlbSBo ZXJlIGlzIHRoZXNlIGJyb2tlbiBzZXJ2ZXJzIGludGVyb3BlcmF0ZSBmaW5lIHdpdGggY2xpZW50 cyBhdCB0aGUgdGltZSB0aGV5IGFyZSBkZXBsb3llZC4gSXQgaXMgb25seSBhZnRlciBuZXcgdmFs dWVzIGdldCBkZWZpbmVkIGRvIHdlIG5vdGljZSwgYnkgd2hpY2ggdGltZSBpdCBpcyB0b28gbGF0 ZS4NCg0KSSB3b3VsZCBsaWtlIHRvIGZpeCB0aGlzIGJ5IHJlc2VydmluZyBhIGZldyB2YWx1ZXMg aW4gb3VyIHJlZ2lzdHJpZXMgc28gdGhhdCBjbGllbnRzIG1heSBhZHZlcnRpc2UgcmFuZG9tIG9u ZXMgYW5kIHJlZ3VsYXJseSBleGVyY2lzZSB0aGVzZSBjb2RlcGF0aHMgaW4gc2VydmVycy4gSWYg ZW5vdWdoIG9mIHRoZSBjbGllbnQgYmFzZSBkb2VzIHRoaXMsIHdlIGNhbiB0dXJuIGEgbGFyZ2Ug Y2xhc3Mgb2YgdG9tb3Jyb3cncyBpbnRlcm9wIGZhaWx1cmVzIGludG8gdG9kYXkncyBpbnRlcm9w IGZhaWx1cmVzLiBUaGlzIGlzIGltcG9ydGFudCBiZWNhdXNlIGFuIGJ1ZyB3aWxsIG5vdCB0aHJp dmUgaW4gdGhlIGVjb3N5c3RlbSBpZiBpdCBkb2VzIG5vdCB3b3JrIGFnYWluc3QgdGhlIGN1cnJl bnQgZGVwbG95bWVudC4NCg0KSWYgeW91IHdlcmUgaW4gQmVybGluLCB5b3UgbWF5IHJlY29nbml6 ZSB0aGlzIGlkZWEgZnJvbSB0aGUgdmVyc2lvbiBuZWdvdGlhdGlvbiBkZWJhdGUuIEFsYXMgdGhh dCBhbGwgaGFwcGVuZWQgaW4gdGhlIHdyb25nIG9yZGVyIGFzIEkgaGFkbid0IHdyaXR0ZW4gdGhp cyB1cCB5ZXQuIFRoaXMgaWRlYSBjYW4ndCBiZSBhcHBsaWVkIHRvIHZlcnNpb25pbmcgd2l0aG91 dCBnaXZpbmcgdXAgb24gQ2xpZW50SGVsbG8udmVyc2lvbiwgYnV0IHdlIGNhbiBzdGFydCB3aXRo IHRoZSByZXN0IG9mIHRoZSBwcm90b2NvbC4NCg0KRGF2aWQNCg0KUFM6IFRoaXMgaXMgYWN0dWFs bHkgbXkgZmlyc3QgSS1ELCBzbyBhcG9sb2dpZXMgaWYgSSd2ZSBtZXNzZWQgaXQgdXAgc29tZXdo ZXJlIQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K VExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF7ABblreml502mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5tMjM3NzU3MDIzMzU4 NjQ3ODkwMm03ODcwNTQ1OTY1MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5Nzgw MTg4OTc2NjkzMDltc29saXN0cGFyYWdyYXBoLCBsaS5tMjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcw NTQ1OTY1MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2NjkzMDlt c29saXN0cGFyYWdyYXBoLCBkaXYubTIzNzc1NzAyMzM1ODY0Nzg5MDJtNzg3MDU0NTk2NTEwNjgw MTcwNm04Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3NjY5MzA5bXNvbGlzdHBhcmFn cmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzIzNzc1NzAyMzM1ODY0Nzg5MDJtXzc4NzA1NDU5NjUx MDY4MDE3MDZtXzgzODg1MDAyNDgxNDg3NjczMDVtXy01OTg3OTc4MDE4ODk3NjY5MzA5bXNvbGlz dHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU3NTA5MTIyMTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2OTQzNTM0MzQgMTczNjIxNzkwOCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjU0LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L 5L2TOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIyMDUwIiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRGF2aWQgJmFtcDsgU3RldmVuLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGVyZSBvdXIgaW50ZW5zaW9uIGlzIHRvIGZpbmQgb3V0IGJ1Z2d5IHNlcnZlciB3aGljaCBp bXBsZW1lbnRlZCBhIGNpcGhlciBzdWl0ZSBzdXBwb3J0IHdpdGggd3JvbmcgdmFsdWUgb3RoZXIg dGhhbiBzcGVjaWZpZWQgaW4gUkZDLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHRoYXQgd3JvbmcgdmFsdWUgdXNhZ2UgaW4g dGhhdCBidWdneSBzZXJ2ZXIgY29sbGlkZXMgd2l0aCBhbnkgcmVhbCBjaXBoZXIgc3VpdGUgb24g dGhlIHBlcmlvZCBvZiBkZXBsb3ltZW50IG1lYW5zLCB0aGUgYnVnIHdvdWxkIGhhdmUgaWRlbnRp ZmllZA0KIGltbWVkaWF0ZWx5IHdpdGggc29tZSBvdGhlciBub24gYnVnZ3kgY2xpZW50LiAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SWYgdGhhdCB3cm9uZyB2YWx1ZSBpcyBpbiB0aGUgcmFuZ2Ugb2YgdW5zcGVjaWZpZWQg dmFsdWUsIHRoZW4gdGhhdCBidWcgdGhyaXZlcyBhbmQgaXQgd2lsbCBjb21lIG91dCBvbmx5IGFm dGVyIHNldmVyYWwgeWVhcnMgd2hlbiBJQU5BIGFzc2lnbnMgdGhhdA0KIHZhbHVlIHRvIHNvbWUg bmV3IGNpcGhlciBzdWl0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHRoaXMgY2FzZSwgY2FuIHlvdSBwbGVhc2Ug dGVsbCBtZSB3aHkgd2UgZGVjaWRlZCBvbmx5IGZldyB2YWx1ZXMgYXMgR1JFQVNFIHZhbHVlIHsw eDBBMEEsIDB4MUExQSwgLi59LiBXaGV0aGVyIGNocm9tZSBicm93c2VyIGhhcyBmb3VuZCBhIHJl YWwgYnVnZ3kgd2ViDQogc2VydmVyIHdoaWNoIHN1cHBvcnRzIHRoZXNlIHZhbHVlcyA/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SIEFzaG9rPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZM7 Y29sb3I6IzFGNDk3RCI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIi Pg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO2NvbG9yOmJsYWNrIj5SYWphIEFz aG9rIFZLPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPuWNjuS4uuaKgOacr+aciemZkOWF rOWPuDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrljY7m lofnu4bpu5E7Y29sb3I6YmxhY2siPiBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxicj4N Cjwvc3Bhbj48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGV0eXBlIGlkPSJfeDAwMDBfdDc1IiBj b29yZHNpemU9IjIxNjAwLDIxNjAwIiBvOnNwdD0iNzUiIG86cHJlZmVycmVsYXRpdmU9InQiIHBh dGg9Im1ANEA1bEA0QDExQDlAMTFAOUA1eGUiIGZpbGxlZD0iZiIgc3Ryb2tlZD0iZiI+DQo8djpz dHJva2Ugam9pbnN0eWxlPSJtaXRlciIgLz4NCjx2OmZvcm11bGFzPg0KPHY6ZiBlcW49ImlmIGxp bmVEcmF3biBwaXhlbExpbmVXaWR0aCAwIiAvPg0KPHY6ZiBlcW49InN1bSBAMCAxIDAiIC8+DQo8 djpmIGVxbj0ic3VtIDAgMCBAMSIgLz4NCjx2OmYgZXFuPSJwcm9kIEAyIDEgMiIgLz4NCjx2OmYg ZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVsV2lkdGgiIC8+DQo8djpmIGVxbj0icHJvZCBAMyAyMTYw MCBwaXhlbEhlaWdodCIgLz4NCjx2OmYgZXFuPSJzdW0gQDAgMCAxIiAvPg0KPHY6ZiBlcW49InBy b2QgQDYgMSAyIiAvPg0KPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxXaWR0aCIgLz4NCjx2 OmYgZXFuPSJzdW0gQDggMjE2MDAgMCIgLz4NCjx2OmYgZXFuPSJwcm9kIEA3IDIxNjAwIHBpeGVs SGVpZ2h0IiAvPg0KPHY6ZiBlcW49InN1bSBAMTAgMjE2MDAgMCIgLz4NCjwvdjpmb3JtdWxhcz4N Cjx2OnBhdGggbzpleHRydXNpb25vaz0iZiIgZ3JhZGllbnRzaGFwZW9rPSJ0IiBvOmNvbm5lY3R0 eXBlPSJyZWN0IiAvPg0KPG86bG9jayB2OmV4dD0iZWRpdCIgYXNwZWN0cmF0aW89InQiIC8+DQo8 L3Y6c2hhcGV0eXBlPjx2OnNoYXBlIGlkPSJyaWRJbWciIG86c3BpZD0iX3gwMDAwX3MxMDI3IiB0 eXBlPSIjX3gwMDAwX3Q3NSIgYWx0PSJDb21wYW55X2xvZ28iIHN0eWxlPSdwb3NpdGlvbjphYnNv bHV0ZTttYXJnaW4tbGVmdDowO21hcmdpbi10b3A6MDt3aWR0aDo3Ni41cHQ7aGVpZ2h0OjI0cHQ7 ei1pbmRleDoyO3Zpc2liaWxpdHk6dmlzaWJsZTttc28td3JhcC1zdHlsZTpzcXVhcmU7bXNvLXdy YXAtZGlzdGFuY2UtbGVmdDowO21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFwLWRpc3Rh bmNlLXJpZ2h0OjA7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6 b250YWw6bGVmdDttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1wb3Np dGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwtcmVsYXRpdmU6bGlu ZScgbzphbGxvd292ZXJsYXA9ImYiPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDAxLmpw Z0AwMUQxRURCMy5GQjBEQ0U5MCIgbzpocmVmPSJmaWxlOi8vL0M6XFVzZXJzXHIwMDkwMjczNlxB cHBsaWNhdGlvbiUyMERhdGFcTWljcm9zb2Z0XFNpZ25hdHVyZXNcY29tcGFueV9sb2dvLmpwZyIg Lz4NCjx3OndyYXAgdHlwZT0ic3F1YXJlIiBhbmNob3J5PSJsaW5lIi8+DQo8L3Y6c2hhcGU+PCFb ZW5kaWZdLS0+PCFbaWYgIXZtbF0+PGltZyB3aWR0aD0iMTAyIiBoZWlnaHQ9IjMyIiBzcmM9ImNp ZDppbWFnZTAwMS5qcGdAMDFEMUVEQjMuRkIwRENFOTAiIGFsaWduPSJsZWZ0IiBhbHQ9IkNvbXBh bnlfbG9nbyIgdjpzaGFwZXM9InJpZEltZyI+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpibGFjayI+PGJyPg0KPGJy Pg0KUGhvbmU6IDxicj4NCkZheDogPGJyPg0KTW9iaWxlOiA8YnI+DQpFbWFpbDogPGJyPg0KSHVh d2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC48YnI+DQpCYW5nYWxvcmUsIEluZGlhPGJyPg0KaHR0 cDovL3d3dy5odWF3ZWkuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZM7 Y29sb3I6IzFGNDk3RCI+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOiMxRjQ5N0QiPg0KPGhyIHNpemU9IjIiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OuWui+S9kztjb2xvcjpncmF5Ij7mnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazl j7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJfl h7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTrljY7mlofnu4bpu5E7Y29sb3I6Z3JheSI+PGJyPg0KPC9zcGFuPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWui+S9 kztjb2xvcjpncmF5Ij7mraLku7vkvZXlhbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjl jIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbm laPlj5HvvInmnKzpgq7ku7bkuK08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTrljY7mlofnu4bpu5E7Y29sb3I6Z3JheSI+PGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xv cjpncmF5Ij7nmoTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobmnKzpgq7ku7bvvIzor7fmgqjn q4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbliKDpmaTmnKzpgq7ku7bvvIE8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrljY7mlofnu4bp u5E7Y29sb3I6Z3JheSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpncmF5Ij5UaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50 aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KPGJyPg0KaXMgaW50ZW5kZWQgb25s eSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUu IEFueSB1c2Ugb2YgdGhlDQo8YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFu eSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQo8 YnI+DQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNv bnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgPGJyPg0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0 ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYnkNCjxicj4NCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUg aXQhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRGF2aWQgQmVuamFtaW4gW21haWx0bzpkYXZp ZGJlbkBjaHJvbWl1bS5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDIgQXVndXN0IDIwMTYgMTk6 MzA8YnI+DQo8Yj5Ubzo8L2I+IFN0ZXZlbiBWYWxkZXo7IFJhamEgYXNob2s7IHRsc0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gS2VlcGluZyBUTFMgZXh0ZW5zaW9uIHBv aW50cyB3b3JraW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UbyBleHBhbmQgb24gdGhhdCBhIGxpdHRsZSwgc2luY2UgaXQgc2VlbXMgY29tbWVudHMgKGEp IGFuZCAoYikgYXJlIHJlYWxseSB0aGUgc2FtZSBvbmU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHVycG9zZSBvZiBoYXZpbmcgYW4gZXhwbGljaXRs eSByZXNlcnZlZCBsaXN0IChiKSBpcyBwcmVjaXNlbHkgc28gd2UgZG8gbm90IGhhdmUgdG8gZG8g YSBzZWNvbmQgaGFuZHNoYWtlIChhKS4gVGhlIHB1cnBvc2UgaGVyZSBpcyB0byBlbnN1cmUgd2Ug ZXhlcmNpc2UgdGhlIGxpdHRsZS11c2VkIGNvZGVwYXRocywgbm90IGludHJvZHVjZSBuZXcgb25l cy4mbmJzcDtUaGlzIGlzIGludGVuZGVkIHRvIGJlIGFuIGV4dHJlbWVseQ0KIG1pbmltYWwgbWVj aGFuaXNtLiBDbGllbnRzIGFkZCBhIHRpbnkgYml0IG9mIGNvZGUgdG8gdGhlaXIgQ2xpZW50SGVs bG8gYW5kIG5vIHNlcnZlciBjb2RlIGNoYW5nZXMgYXQgYWxsLiAoTm90ZSB0aGF0IGV2ZXJ5IE1V U1QgaW4gdGhlIGRvY3VtZW50IGlzIGp1c3QgcmVpdGVyYXRpbmcgd2hhdCBUTFMgYWxyZWFkeSBy ZXF1aXJlcy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU dWUsIEF1ZyAyLCAyMDE2IGF0IDk6NDcgQU0gU3RldmVuIFZhbGRleiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnN2YWxkZXpAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN2YWxkZXpAZ29vZ2xlLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEpIEl0IHNlZW1zIGxpa2UgaWYgYW4gaW1wbGVtZW50 YXRpb24gaGFzIHVwZGF0ZWQgdG8gYmUgYWJsZSB0byBoYW5kbGUgYSBzcGVjaWZpYyBHUkVBU0Ug YWxlcnQsIGl0IHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSBub3Qgc2VuZGluZyBhbiBpbnZhbGlk IGNpcGhlciBzdWl0ZS4gSW4gZ2VuZXJhbCwgaXRzIHByb2JhYmx5IGNsZWFuZXIgZm9yIHRoZSBj b25uZWN0aW9uIHRvIGZhdGFsbHkgc2h1dGRvd24gYW5kDQogdGhlbiByZXN0YXJ0IGlmIHRoZSBz ZXJ2ZXIgaXMgYmVoYXZpbmcgdGhhdCBwb29ybHkuIFNlcnZlcnMgdGhhdCBhcmUgc2VuZGluZyBi YWNrIG5vbi1leGlzdGVudCBjaXBoZXJzIGFyZSBhbHNvIHBvdGVudGlhbGx5IGJyb2tlbiBpbiBv dGhlciB3YXlzLCBhbmQgSSBkb24ndCBrbm93IHdoZXRoZXIgYSBjbGllbnQgc2hvdWxkIHRydXN0 IHRoYXQgaXQgY2FuIHJlc2V0IGFueSBoYW5kc2hha2Ugc3RhdGUgY29ycmVjdGx5IGlmIGl0IHdl cmUgdG8gdHJ5DQogZG9pbmcgYSAmcXVvdDt3YXJuaW5nJnF1b3Q7IGFsZXJ0LjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YikgVGhlIHJlYXNvbmluZyBiZWhp bmQgaGF2aW5nIGFuIGV4cGxpY2l0IGxpc3QgaXMgc28gdGhhdCBpbXBsZW1lbnRhdGlvbnMgZG9u J3Qgc2VuZCBhIHZhbHVlIHRoYXQgZW5kcyB1cCBiZWluZyBkZWZpbmVkIGFzIHNvbWUgb3RoZXIg dmFsaWQgdmFsdWUuIE90aGVyd2lzZSBpdHMgcG9zc2libGUgdGhhdCBzb21lIGltcGxlbWVudGF0 aW9ucyB3aWxsIHVwZGF0ZSB0byBpbmNsdWRlIEdSRUFTRSB2YWx1ZXMsIGJ1dA0KIHRoZXkgbWln aHQgbm90IHVwZGF0ZSBpbW1lZGlhdGVseSB1cG9uIG5ldyB2YWx1ZXMgYmVpbmcgYXNzaWduZWQg YnkgSUFOQSwgd2hpY2ggbWVhbnMgdGhhdCB0aGVyZSB3aWxsIGJlIHBlcmlvZHMgb2YgdGltZXMg dGhhdCBzb21lIGNsaWVudHMgbWlnaHQgc2VuZCAmcXVvdDtmYWtlJnF1b3Q7IHZhbHVlcyB0aGF0 IGNvbGxpZGUgd2l0aCByZWFsIHZhbHVlcywgY29uZnVzaW5nIHRoZSBwZWVyIGltcGxlbWVudGF0 aW9uIGludG8gYmVsaWV2aW5nIHRoZXkgYWN0dWFsbHkNCiBzdXBwb3J0IHNvbWV0aGluZyB0aGF0 IHRoZXkgZG9uJ3QgYW5kIHJlc3VsdGluZyBpbiBtb3JlIGludG9sZXJhbmNlIGlzc3VlcyBiZXR3 ZWVuIG91dGRhdGVkIEdSRUFTRSBjbGllbnRzIGFuZCBuZXdseSB1cGRhdGVkIHNlcnZlcnMsIHdp dGggdGhpcyBpbnRvbGVyYW5jZSBiZWluZyBmaXJtbHkgdGhlIEdSRUFTRSBjbGllbnRzIGZhdWx0 LiBUaGUgaGFyZGNvZGVkIGxpc3QgZ2V0cyBhcm91bmQgdGhpcyBieSBtYWtpbmcgc3VyZSBHUkVB U0UgbmV2ZXINCiBvdmVybGFwcyB3aXRoIGFuIGFjdHVhbCB2YWx1ZSwgdGhvdWdoIGF0IHRoZSB0 cmFkZS1vZmYgdGhhdCBiYWRseSBkZXNpZ25lZCBpbXBsZW1lbnRhdGlvbnMgY291bGQgY2hvb3Nl IHRvIGp1c3QgaGFyZC1jb2RlIGlnbm9yZSB0aGUgR1JFQVNFIGNvZGVwb2ludHMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXVn IDIsIDIwMTYgYXQgMjo1OSBBTSBSYWphIGFzaG9rICZsdDs8YSBocmVmPSJtYWlsdG86cmFqYS5h c2hva0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmFqYS5hc2hva0BodWF3ZWkuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEJlbmphbWluLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgaGF2ZSBnb25lIHRocm91Z2ggdGhlIEdSRUFTRSBtZWNoYW5pc20gd2hpY2ggeW91IHByb3Bv c2VkIGluIHlvdXIgbmV3IGRyYWZ0LiBJdOKAmXMgcmVhbGx5IGEgbmljZQ0KIGlkZWEgZm9yIGZp bmRpbmcgYSBidWdneSBzZXJ2ZXIgYmVmb3JlIGl0IHRocml2ZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh bSBoYXZpbmcgZmV3IGRvdWJ0cyBvbiB0aGlzLCB3aGljaCBhcmUgbGlzdGVkIGJlbG93Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1 OTY1MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29s aXN0cGFyYWdyYXBoIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5hKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IHNob3VsZCBiZSB0aGUgYmVoYXZpb3VyIG9mIGNs aWVudCBpbmNhc2UgaWYgYSBidWdneSBzZXJ2ZXIgcmVzcG9uZGVkIGZvciBhIEdSRUFTRSB2YWx1 ZSA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0yMzc3NTcwMjMzNTg2NDc4OTAy bTc4NzA1NDU5NjUxMDY4MDE3MDZtODM4ODUwMDI0ODE0ODc2NzMwNW0tNTk4Nzk3ODAxODg5NzY2 OTMwOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXIgYSBjbGllbnQgc2VuZHMgYSBHUkVBU0Ug Y2lwaGVyIHZhbHVlIGF0IGZpcnN0IHBsYWNlIGFuZCBmb2xsb3dlZCBieSB2YWxpZCBjaXBoZXIg c3VpdGVzLCBpbiBpdHMgY2xpZW50IGhlbGxvLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0yMzc3NTcwMjMzNTg2NDc4OTAybTc4NzA1NDU5NjUxMDY4MDE3MDZtODM4ODUwMDI0 ODE0ODc2NzMwNW0tNTk4Nzk3ODAxODg5NzY2OTMwOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDo1NC4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgYSBi dWdneSBzZXJ2ZXIgc2VsZWN0cyB0aGF0IGNpcGhlciB0aGVuIGl0IHdpbGwgcmVzcG9uc2Ugc2Vy dmVyIGhlbGxvIHdpdGggdGhhdCBHUkVBU0UgY2lwaGVyIHZhbHVlLiBBdCB0aGlzIGNhc2UgaWYg Y2xpZW50IHNlbmRzIEZBVEFMIGFsZXJ0IHRoZW4gYm90aCBzaWRlIFRMUyBhbmQgVENQDQogbmVl ZHMgdG8gYmUgY2xvc2VkIGFuZCBjbGllbnQgbmVlZHMgdG8gcmVjcmVhdGUgYSBuZXcgVENQIGNv bm5lY3Rpb24sIGFuZCB0aGVuIHJlc3RhcnQgVExTIGhhbmRzaGFrZSB3aXRob3V0IEdSRUFTRSBj aXBoZXIgdmFsdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0yMzc3NTcwMjMz NTg2NDc4OTAybTc4NzA1NDU5NjUxMDY4MDE3MDZtODM4ODUwMDI0ODE0ODc2NzMwNW0tNTk4Nzk3 ODAxODg5NzY2OTMwOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5zdGVhZCBvZiB0aGlzIHdlIGNhbiBt YWtlIGNsaWVudCB0byBzZW5kIHdhcm5pbmcgYWxlcnQgKHdpdGggbmV3IFRMUyBhbGVydCBjb2Rl IEdSRUFTRV9DSVBIRVJfVkFMVUVfU0VMRUNURUQoMTExKSkgYW5kIHJlc3RhcnQgVExTIGhhbmRz aGFrZSBieSBzZW5kaW5nIGNsaWVudCBoZWxsbyBhZ2Fpbi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0Nzg5MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04Mzg4 NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J ZiBhIHNlcnZlciByZWNlaXZlcyB0aGlzIG5ldyB3YXJuaW5nLCB0aGVuIGl0IHNob3VsZCBiZSBy ZWFkeSB0byByZWNlaXZlIG5ldyBjbGllbnQgaGVsbG8gdG8gcmVzdGFydCBoYW5kc2hha2UuDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0Nzg5MDJtNzg3 MDU0NTk2NTEwNjgwMTcwNm04Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3NjY5MzA5 bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1OTY1MTA2ODAxNzA2 bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29saXN0cGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TRVJWRVImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENM SUVOVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkw Mm03ODcwNTQ1OTY1MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2 NjkzMDltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DSCAoR1JFQVNFIENpcGhlciB2 YWx1ZSAmYW1wOyBWYWxpZCBDaXBoZXIgdmFsdWUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLSZndDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0Nzg5MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04 Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LS0tLS0tLSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTSCAoR1JFQVNFIGNpcGhlciB2 YWx1ZSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0Nzg5 MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3 NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmF0YWwgYWxlcnQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0t LS0mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0yMzc3NTcwMjMzNTg2NDc4 OTAybTc4NzA1NDU5NjUxMDY4MDE3MDZtODM4ODUwMDI0ODE0ODc2NzMwNW0tNTk4Nzk3ODAxODg5 NzY2OTMwOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRDUCAoU1lOKSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0t LSZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0Nzg5 MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3 NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LS0tLS0tLS0mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgVENQKFNZTiBBQ0spPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Im0yMzc3NTcwMjMzNTg2NDc4OTAybTc4NzA1NDU5NjUxMDY4MDE3MDZtODM4ODUwMDI0ODE0 ODc2NzMwNW0tNTk4Nzk3ODAxODg5NzY2OTMwOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDo1NC4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRDUCAoQUNLKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLS0tLS0tLSZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibTIzNzc1NzAyMzM1ODY0Nzg5MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04Mzg4NTAwMjQ4MTQ4 NzY3MzA1bS01OTg3OTc4MDE4ODk3NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjU0LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Q0ggKFZhbGlkIGNpcGhlciB2YWx1ZSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLSZndDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0Nzg5MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04 Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNjZW5hcmlvIDEgOiBTZW5k aW5nIEZBVEFMIGFsZXJ0IGZvciBzZXJ2ZXIgc2VsZWN0aW5nIEdSRUFTRSB2YWx1ZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1OTY1 MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMjM3NzU3MDIz MzU4NjQ3ODkwMm03ODcwNTQ1OTY1MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5 NzgwMTg4OTc2NjkzMDltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TRVJWRVImbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENMSUVOVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1OTY1MTA2ODAxNzA2bTgzODg1 MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29saXN0cGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5DSCAoR1JFQVNFIENpcGhlciB2YWx1ZSAmYW1wOyBWYWxpZCBDaXBoZXIgdmFs dWUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tLS0tLS0mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0yMzc3NTcwMjMz NTg2NDc4OTAybTc4NzA1NDU5NjUxMDY4MDE3MDZtODM4ODUwMDI0ODE0ODc2NzMwNW0tNTk4Nzk3 ODAxODg5NzY2OTMwOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0Oy0tLS0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgU0ggKEdSRUFTRSBjaXBoZXIgdmFsdWUpPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0yMzc3NTcwMjMzNTg2NDc4OTAybTc4NzA1NDU5NjUxMDY4MDE3MDZtODM4 ODUwMDI0ODE0ODc2NzMwNW0tNTk4Nzk3ODAxODg5NzY2OTMwOW1zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldhcm5pbmcgYWxlcnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0mZ3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0yMzc3NTcwMjMzNTg2NDc4OTAybTc4NzA1 NDU5NjUxMDY4MDE3MDZtODM4ODUwMDI0ODE0ODc2NzMwNW0tNTk4Nzk3ODAxODg5NzY2OTMwOW1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNIIChWYWxpZCBjaXBoZXIgdmFsdWUpJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t LS0tLS0mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0yMzc3NTcwMjMzNTg2 NDc4OTAybTc4NzA1NDU5NjUxMDY4MDE3MDZtODM4ODUwMDI0ODE0ODc2NzMwNW0tNTk4Nzk3ODAx ODg5NzY2OTMwOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBTY2VuYXJpbyAyIDogU2VuZGluZyBXQVJOSU5HIGFsZXJ0IGZvciBzZXJ2ZXIg c2VsZWN0aW5nIEdSRUFTRSB2YWx1ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt MjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1OTY1MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3Njcz MDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NTQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0Nzg5 MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3 NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhvcGUgc2VuZGluZyB3YXJuaW5nIG1zZyBhbmQg cmVzdGFydGluZyBUTFMgaGFuZHNoYWtlIHdpbGwgYmUgZWZmaWNpZW50Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1OTY1MTA2ODAx NzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRMUyBTZXJ2ZXIgbXVzdCBub3RpZnkgdGhlIGFwcGxpY2F0aW9uLCB3aGVuZXZlciBp dCByZWNlaXZlcyBhIEdSRUFTRSB3YXJuaW5nIGFsZXJ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1OTY1MTA2ODAxNzA2bTgzODg1 MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29saXN0cGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTIzNzc1 NzAyMzM1ODY0Nzg5MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01 OTg3OTc4MDE4ODk3NjY5MzA5bXNvbGlzdHBhcmFncmFwaCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Yik8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2h5IG9ubHkgZmV3 IHZhbHVlcyBhcmUgc3BlY2lmaWVkIGFzIEdSRUFTRSB2YWx1ZSA/IEJhc2ljYWxseSBhbGwgdmFs dWUgd2hpY2ggYXJlIG5vdCBzcGVjaWZpZWQgYnkgSUFOQSBzaG91bGQgYmUgY29uc2lkZXJlZCBh cyBHUkVBU0UgdmFsdWUgcmlnaHQgPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt MjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1OTY1MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3Njcz MDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NTQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4t PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJhc2ljYWxseSBjbGll bnQgc2hvdWxkIG1haW50YWluIHRoZSBsaXN0IG9mIHZhbHVlcyAoY2lwaGVyIHN1aXRlLCBleHRl bnNpb25zKSBzcGVjaWZpZWQgYnkgSUFOQS4gVGhlIHJhbmdlIG9mIHZhbHVlcy4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkwMm03ODcwNTQ1OTY1 MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2NjkzMDltc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkZvciBleGFtcGxlIElBTkEgc3BlY2lmaWVkIGNpcGhlciBzdWl0ZSB2YWx1 ZXMgYXJlIHt7MHgwMDAwLDB4MDA1Q30sIHsweDAwNjAsMHgwMDZEfSwgezB4MDA4NCwgMHgwMEM1 fSwgezB4MDBGRiwgMHgwMEZGfSDigKYuLiB9LiBUaGlzIHNob3VsZCBiZSBtYWludGFpbmVkIGlu IGNsaWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0 Nzg5MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4 ODk3NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBzaG91bGQgbWFrZSB0aGUgY2xpZW50IHRv IGNob29zZSBhIHJhbmRvbSB2YWx1ZSB3aGljaCBhcmUgbm90IGluIHRoaXMgc3VwcG9ydGVkIHZh bHVlIGxpc3QuIFRoYXQgY2lwaGVyIHZhbHVlIHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIEdSRUFT RSB2YWx1ZSBhbmQgbmVlZCB0byBrZWVwIGluDQogZmlyc3QgcGxhY2Ugb2YgaXRzIGNpcGhlciBs aXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMjM3NzU3MDIzMzU4NjQ3ODkw Mm03ODcwNTQ1OTY1MTA2ODAxNzA2bTgzODg1MDAyNDgxNDg3NjczMDVtLTU5ODc5NzgwMTg4OTc2 NjkzMDltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIGl0cyBzZWxlY3RlZCBieSBhIGJ1Z2d5IHNlcnZl ciwgdGhlbiBjbGllbnQgc2hvdWxkIGJlaGF2ZSBhcyBtZW50aW9uZWQgaW4gYWJvdmUgc2NlbmFy aW8gMi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTIzNzc1NzAyMzM1ODY0Nzg5 MDJtNzg3MDU0NTk2NTEwNjgwMTcwNm04Mzg4NTAwMjQ4MTQ4NzY3MzA1bS01OTg3OTc4MDE4ODk3 NjY5MzA5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVuIGluIGZ1dHVyZSBpZiBJQU5BIHByb3ZpZGVz IG5ldyB2YWx1ZXMgdG8gbmV3IGNpcGhlciwgdGhlbiB0aGlzIGxpc3QgYWxzbyBzaG91bGQgYmUg dXBkYXRlZC4gQ29uc2lkZXIgaW4gdGhpcyBjYXNlIHNlcnZlciBpcyBzdXBwb3J0aW5nIHRoYXQg bmV3IGNpcGhlciBhbmQgY2xpZW50IGlzDQogbm90IGF3YXJlIGFib3V0IGl0LCBzbyBjbGllbnQg Y2FuIHByb3Bvc2UgdGhhdCB2YWx1ZSBhcyBHUkVBU0UgdmFsdWUsIHRoZW4gc3RpbGwgY29ubmVj dGlvbiB3aWxsIHdvcmsgd2l0aCB0aGUgMjxzdXA+bmQ8L3N1cD4gaGFuZHNoYWtlLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0yMzc3NTcwMjMzNTg2NDc4OTAybTc4NzA1NDU5 NjUxMDY4MDE3MDZtODM4ODUwMDI0ODE0ODc2NzMwNW0tNTk4Nzk3ODAxODg5NzY2OTMwOW1zb2xp c3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBhbSBub3QgdW5kZXJzdGFuZGluZyB3aHkgd2UgYXJlIHBsYW5uaW5n IHRvIG1haW50YWluIGEgZmV3IHNldCBvZiBHUkVBU0UgdmFsdWVzIHsweDBBMEEsIDB4MUExQSDi gKYuIH0uIElmIEkgYW0gbWlzc2luZyBzb21ldGhpbmcsIHBsZWFzZSBjbGFyaWZ5IG1lLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UiBBc2hv azwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOiMxRjQ5 N0QiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPlJhamEgQXNob2sgVks8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFj ayI+5Y2O5Li65oqA5pyv5pyJ6ZmQ5YWs5Y+4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOmJsYWNrIj4gSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC48YnI+DQo8 L3NwYW4+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBlIGlkPSJfeDAwMDBfczEwMjYiIHR5cGU9 IiNfeDAwMDBfdDc1IiBhbHQ9IkNvbXBhbnlfbG9nbyIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRl O21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRvcDowO3dpZHRoOjc2LjVwdDtoZWlnaHQ6MjRwdDt6LWlu ZGV4OjE7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0OjA7 bXNvLXBvc2l0aW9uLWhvcml6b250YWw6bGVmdDttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxh dGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTpsaW5lJyBvOmFsbG93b3Zl cmxhcD0iZiI+DQo8djppbWFnZWRhdGEgc3JjPSIiIC8+DQo8dzp3cmFwIHR5cGU9InNxdWFyZSIv Pg0KPC92OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2bWxdPjxpbWcgd2lkdGg9IjEwMiIgaGVp Z2h0PSIzMiIgc3JjPSIiIGFsaWduPSJsZWZ0IiBhbHQ9IkNvbXBhbnlfbG9nbyIgdjpzaGFwZXM9 Il94MDAwMF9zMTAyNiI+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj48YnI+DQo8YnI+DQpQaG9uZTogPGJyPg0KRmF4OiA8YnI+DQpNb2JpbGU6IDxi cj4NCkVtYWlsOiA8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxicj4NCkJhbmdh bG9yZSwgSW5kaWE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRw Oi8vd3d3Lmh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmh1YXdlaS5jb208 L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZM7Y29sb3I6IzFGNDk3RCI+ DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OuWui+S9kztjb2xvcjojMUY0OTdEIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xv cjpncmF5Ij7mnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bk v6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrm iJbnvqTnu4TjgILnpoE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjpn cmF5Ij48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmdyYXkiPuatouS7u+S9leWFtuS7luS6uuS7peS7 u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOaz hOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8ieacrOmCruS7tuS4rTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2NvbG9yOmdyYXkiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJa SC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6Z3Jh eSI+55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z 55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Y29sb3I6Z3JheSI+PGJyPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpncmF5Ij5UaGlzIGUtbWFpbCBhbmQgaXRzIGF0 dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3 aGljaA0KPGJyPg0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hv c2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQo8YnI+DQppbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1p dGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQo8YnI+DQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24s IG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgPGJy Pg0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCjxicj4NCnBob25lIG9yIGVt YWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gVExTIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5EYXZpZCBCZW5qYW1pbjxicj4NCjxiPlNlbnQ6PC9iPiAyNiBKdWx5IDIwMTYgMDQ6 MDI8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUTFNdIEtlZXBp bmcgVExTIGV4dGVuc2lvbiBwb2ludHMgd29ya2luZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5IaSBmb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20gbm90IHN1cmUgaG93IHRoaXMgcHJvY2VzcyB1c3Vh bGx5IHdvcmtzLCBidXQgSSB3b3VsZCBsaWtlIHRvIHJlc2VydmUgYSBidW5jaCBvZiB2YWx1ZXMg aW4gdGhlIFRMUyByZWdpc3RyaWVzIHRvIGFzIHBhcnQgb2YgYW4gaWRlYSB0byBrZWVwIG91ciBl eHRlbnNpb24gcG9pbnRzIHdvcmtpbmcuIEhlcmUncw0KIGFuIEktRDo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRhdmlkYmVuLXRscy1ncmVhc2UtMDAiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGF2aWRiZW4tdGxzLWdy ZWFzZS0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPihUaGUgbmFtZSBHUkVBU0UgaXMgaW4gaG9ub3Ig b2YgQUdMJ3MgcnVzdGVkIHZzLiB3ZWxsLW9pbGVkIGpvaW50cyBhbmFsb2d5IGZyb20NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmltcGVyaWFsdmlvbGV0Lm9yZy8yMDE2LzA1LzE2L2FnaWxpdHkuaHRt bCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaW1wZXJpYWx2aW9sZXQub3JnLzIwMTYv MDUvMTYvYWdpbGl0eS5odG1sPC9hPiZuYnNwOyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25lIHByb2JsZW0gd2UgcmVw ZWF0ZWRseSBydW4gaW50byBpcyBzZXJ2ZXJzIGZhaWxpbmcgdG8gaW1wbGVtZW50IFRMUydzIHZh cmlvdXMgZXh0ZW5zaW9uIHBvaW50cyBjb3JyZWN0bHkuIFRoZSBtb3N0IG9idmlvdXMgYmVpbmcg dmVyc2lvbiBpbnRvbGVyYW5jZS4gV2hlbiB3ZSBkZXBsb3llZCBYMjU1MTkNCiBpbiBDaHJvbWUs IHdlIGRpc2NvdmVyZWQgYW4gaW50b2xlcmFudCBpbXBsZW1lbnRhdGlvbi4gKFRoYW5rZnVsbHkg aXQgd2FzIHJhcmUgZW5vdWdoIHRvIG5vdCB3YXJyYW50IGEgZmFsbGJhY2sgb3IgcmV2ZXJ0ISkg SXQgYXBwZWFycyB0aGF0IHNpZ25hdHVyZSBhbGdvcml0aG1zIG1heWJlIGFsc28gYmUgZ2F0aGVy aW5nIHJ1c3QuIENpcGhlcnMgYW5kIGV4dGVuc2lvbnMgc2VlbSB0byBoYXZlIGhlbGQgdXAsIGJ1 dCBJIHdvdWxkIGxpa2UgdG8NCiBlbnN1cmUgdGhleSBzdGF5IHRoYXQgd2F5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHJvb3Qg cHJvYmxlbSBoZXJlIGlzIHRoZXNlIGJyb2tlbiBzZXJ2ZXJzIGludGVyb3BlcmF0ZSBmaW5lIHdp dGggY2xpZW50cyBhdCB0aGUgdGltZSB0aGV5IGFyZSBkZXBsb3llZC4gSXQgaXMgb25seSBhZnRl ciBuZXcgdmFsdWVzIGdldCBkZWZpbmVkIGRvIHdlIG5vdGljZSwgYnkgd2hpY2ggdGltZSBpdA0K IGlzIHRvbyBsYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSB3b3VsZCBsaWtlIHRvIGZpeCB0aGlzIGJ5Jm5ic3A7cmVzZXJ2aW5n IGEgZmV3IHZhbHVlcyBpbiBvdXIgcmVnaXN0cmllcyBzbyB0aGF0IGNsaWVudHMgbWF5IGFkdmVy dGlzZSByYW5kb20gb25lcyBhbmQgcmVndWxhcmx5IGV4ZXJjaXNlIHRoZXNlIGNvZGVwYXRocyBp biBzZXJ2ZXJzLiBJZiBlbm91Z2ggb2YgdGhlDQogY2xpZW50IGJhc2UgZG9lcyB0aGlzLCB3ZSBj YW4gdHVybiBhIGxhcmdlIGNsYXNzIG9mIHRvbW9ycm93J3MgaW50ZXJvcCBmYWlsdXJlcyBpbnRv IHRvZGF5J3MgaW50ZXJvcCBmYWlsdXJlcy4gVGhpcyBpcyBpbXBvcnRhbnQgYmVjYXVzZSBhbiBi dWcgd2lsbCBub3QgdGhyaXZlIGluIHRoZSBlY29zeXN0ZW0gaWYgaXQgZG9lcyBub3Qgd29yayBh Z2FpbnN0IHRoZSBjdXJyZW50IGRlcGxveW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgeW91IHdlcmUgaW4gQmVy bGluLCB5b3UgbWF5IHJlY29nbml6ZSB0aGlzIGlkZWEgZnJvbSB0aGUgdmVyc2lvbiBuZWdvdGlh dGlvbiBkZWJhdGUuIEFsYXMgdGhhdCBhbGwgaGFwcGVuZWQgaW4gdGhlIHdyb25nIG9yZGVyIGFz IEkgaGFkbid0IHdyaXR0ZW4gdGhpcyB1cCB5ZXQuIFRoaXMgaWRlYSBjYW4ndA0KIGJlIGFwcGxp ZWQgdG8gdmVyc2lvbmluZyB3aXRob3V0IGdpdmluZyB1cCBvbiBDbGllbnRIZWxsby52ZXJzaW9u LCBidXQgd2UgY2FuIHN0YXJ0IHdpdGggdGhlIHJlc3Qgb2YgdGhlIHByb3RvY29sLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlBTOiBUaGlzIGlzIGFjdHVhbGx5IG15IGZpcnN0IEktRCwg c28gYXBvbG9naWVzIGlmIEkndmUgbWVzc2VkIGl0IHVwIHNvbWV3aGVyZSE8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF7ABblreml502mbx_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF7ABblreml502mbx_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Wed, 03 Aug 2016 12:52:24 GMT"; modification-date="Wed, 03 Aug 2016 12:52:24 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E18BF7ABblreml502mbx_-- From nobody Wed Aug 3 06:47:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8112DD9C for ; Wed, 3 Aug 2016 06:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3-mNQ71tqat for ; Wed, 3 Aug 2016 06:47:14 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 454EB12DDAD for ; Wed, 3 Aug 2016 06:39:53 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id f6so231402502ith.0 for ; Wed, 03 Aug 2016 06:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cLWGz3cMO16fVL00NJLN7HMD8LuZgjHdhKXmcyBOphQ=; b=QVARDenIAayx2qQHFnG7gL3GJZ3L+qd3HeQn15Jd9kOTg8mv0e46xZPB7Yqyge5l9h lvWj3M1HbV/ZNbw3K7LY1YOTny+9CTnG3hkYjfXBIqUZJ1noDRmrPQ5rhJoQ4ThihKN+ dQ3gTgTv2J/DF+RPAujn2fglWSg+7rlAbfPYg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cLWGz3cMO16fVL00NJLN7HMD8LuZgjHdhKXmcyBOphQ=; b=bXZnspOgHkkNqi1GxMp7kSs3Bc+BQ7A1df1/auave104RgJR9KaEd9iIRpWRq7Ascc xeWx+UjbSW/UYHMH5ChUmsoQrihDaGpfgUesdKjt00ZHp8XahHnpTPIcS1akeUQx7V7r b95aFslXQtHWmCk612UweYSxQRJuhq1ZGItatj8g12NK/atf5etBXKs9F/SqFXjfsZIA Q0xO9MsLmk4pPIj1Cxm7ngPq1x2JK3gsF8uEPsvYf4x6CP+6udLYlZue3ZOrZnQoMmWJ 65qkx3BEOQYEPk0BW78BUZ/bGlRhotyvFycLQEvhXlF6Ggz9AWgIsJQc/9priftlSQ5j fyLw== X-Gm-Message-State: AEkoouu8PQhsHbgS8gXMl3bIkpFbHzFEkltQ6uCHkt+qJJqmJDe7HjMukOoCnechMLo/qT+oKoVC6Bq8D+5A2y6w X-Received: by 10.36.61.201 with SMTP id n192mr26180165itn.92.1470231592284; Wed, 03 Aug 2016 06:39:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 03 Aug 2016 13:39:40 +0000 Message-ID: To: Raja ashok , Steven Valdez , "tls@ietf.org" Content-Type: multipart/related; boundary=001a11444e94cc3e8b05392af770 Archived-At: Subject: Re: [TLS] Keeping TLS extension points working X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Aug 2016 13:47:18 -0000 --001a11444e94cc3e8b05392af770 Content-Type: multipart/alternative; boundary=001a11444e94cc3e8905392af76f --001a11444e94cc3e8905392af76f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 3, 2016 at 8:52 AM Raja ashok wrote: > Hi David & Steven, > > > > Here our intension is to find out buggy server which implemented a cipher > suite support with wrong value other than specified in RFC. > > - If that wrong value usage in that buggy server collides with > any real cipher suite on the period of deployment means, the bug would ha= ve > identified immediately with some other non buggy client. > > - If that wrong value is in the range of unspecified value, then > that bug thrives and it will come out only after several years when IANA > assigns that value to some new cipher suite. > As ecosystem problems go, this is very tame one. I don't think the complexity cost of a retry (which is not compatible with existing servers anyway) far outweighs the ecosystem costs of that particular bug. Should an implementation, say, copy-and-paste the wrong value for some cipher suite and use an unallocated one then, yes, if widespread we will have difficulties using cipher suite value. But then we can simply pick a different one and document that that value has been lost. Moreover, making all values into GREASE values will not catch this bug. The probability of hitting this wrong value randomly is around 1/2^16 which is well in the noise. Flaky failures won't do any good to prevent bugs. In contrast, intolerance to *anything* unknown is a huge problem for deployment. Then we simply can't deploy new things. (At least not without fallbacks and such which have security consequences, among other problems.) In this case, can you please tell me why we decided only few values as > GREASE value {0x0A0A, 0x1A1A, ..}. Whether chrome browser has found a rea= l > buggy web server which supports these values ? > Ultimately the values need to get reserved so people don't try to use them for real ones. I picked a small-ish number so that people maintaining the registries would not become too unhappy at me. :-) Chrome has yet to ship code which does this. I figured I ought to write something up and send it to this list before squatting on quite so many values in the registry. For the moment, this idea is merely a spec. David Regards, > > R Ashok > ------------------------------ > > Raja Ashok VK > =E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 = Huawei Technologies Co., Ltd. > [image: image001.jpg] > > Phone: > Fax: > Mobile: > Email: > Huawei Technologies Co., Ltd. > Bangalore, India > http://www.huawei.com > > ------------------------------ > > =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB= =E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4= =BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB= =99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84= =E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 > =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB= =E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4= =BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88= =86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96= =E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD > =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99= =E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7= =AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F= =A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE= =E4=BB=B6=EF=BC=81 > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > *From:* David Benjamin [mailto:davidben@chromium.org] > *Sent:* 02 August 2016 19:30 > *To:* Steven Valdez; Raja ashok; tls@ietf.org > *Subject:* Re: [TLS] Keeping TLS extension points working > > > > To expand on that a little, since it seems comments (a) and (b) are reall= y > the same one: > > > > The purpose of having an explicitly reserved list (b) is precisely so we > do not have to do a second handshake (a). The purpose here is to ensure w= e > exercise the little-used codepaths, not introduce new ones. This is > intended to be an extremely minimal mechanism. Clients add a tiny bit of > code to their ClientHello and no server code changes at all. (Note that > every MUST in the document is just reiterating what TLS already requires.= ) > > > > David > > > > On Tue, Aug 2, 2016 at 9:47 AM Steven Valdez wrote: > > a) It seems like if an implementation has updated to be able to handle a > specific GREASE alert, it should be able to handle not sending an invalid > cipher suite. In general, its probably cleaner for the connection to > fatally shutdown and then restart if the server is behaving that poorly. > Servers that are sending back non-existent ciphers are also potentially > broken in other ways, and I don't know whether a client should trust that > it can reset any handshake state correctly if it were to try doing a > "warning" alert. > > > > b) The reasoning behind having an explicit list is so that implementation= s > don't send a value that ends up being defined as some other valid value. > Otherwise its possible that some implementations will update to include > GREASE values, but they might not update immediately upon new values bein= g > assigned by IANA, which means that there will be periods of times that so= me > clients might send "fake" values that collide with real values, confusing > the peer implementation into believing they actually support something th= at > they don't and resulting in more intolerance issues between outdated GREA= SE > clients and newly updated servers, with this intolerance being firmly the > GREASE clients fault. The hardcoded list gets around this by making sure > GREASE never overlaps with an actual value, though at the trade-off that > badly designed implementations could choose to just hard-code ignore the > GREASE codepoints. > > > > On Tue, Aug 2, 2016 at 2:59 AM Raja ashok wrote: > > Hi Benjamin, > > > > I have gone through the GREASE mechanism which you proposed in your new > draft. It=E2=80=99s really a nice idea for finding a buggy server before = it thrives. > > > > I am having few doubts on this, which are listed below. > > a) What should be the behaviour of client incase if a buggy server > responded for a GREASE value ? > > - Consider a client sends a GREASE cipher value at first place > and followed by valid cipher suites, in its client hello. > > - If a buggy server selects that cipher then it will response > server hello with that GREASE cipher value. At this case if client sends > FATAL alert then both side TLS and TCP needs to be closed and client need= s > to recreate a new TCP connection, and then restart TLS handshake without > GREASE cipher value. > > - Instead of this we can make client to send warning alert (with > new TLS alert code GREASE_CIPHER_VALUE_SELECTED(111)) and restart TLS > handshake by sending client hello again. > > - If a server receives this new warning, then it should be ready > to receive new client hello to restart handshake. > > > > SERVER > CLIENT > > CH (GREASE Cipher value & Valid Cipher value) ------> > > > <------- SH (GREASE cipher value) > > Fatal alert --------> > > TCP (SYN) --------> > > > <-------- > TCP(SYN ACK) > > TCP (ACK) --------> > > CH (Valid cipher > value) -------> > > Scenario 1 : Sending FATAL alert for server > selecting GREASE value > > > > SERVER > CLIENT > > CH (GREASE Cipher value & Valid Cipher value) -------> > > > <------- SH (GREASE cipher value) > > Warning alert --------> > > CH (Valid cipher > value) -------> > > Scenario 2 : Sending WARNING alert for server > selecting GREASE value > > > > - I hope sending warning msg and restarting TLS handshake will > be efficient. > > - TLS Server must notify the application, whenever it receives a > GREASE warning alert. > > > > b) Why only few values are specified as GREASE value ? Basically all > value which are not specified by IANA should be considered as GREASE valu= e > right ? > > - Basically client should maintain the list of values (cipher > suite, extensions) specified by IANA. The range of values. > > - For example IANA specified cipher suite values are > {{0x0000,0x005C}, {0x0060,0x006D}, {0x0084, 0x00C5}, {0x00FF, 0x00FF} =E2= =80=A6.. > }. This should be maintained in client. > > - We should make the client to choose a random value which are > not in this supported value list. That cipher value should be considered = as > GREASE value and need to keep in first place of its cipher list. > > - If its selected by a buggy server, then client should behave > as mentioned in above scenario 2. > > - Even in future if IANA provides new values to new cipher, then > this list also should be updated. Consider in this case server is > supporting that new cipher and client is not aware about it, so client ca= n > propose that value as GREASE value, then still connection will work with > the 2nd handshake. > > - I am not understanding why we are planning to maintain a few > set of GREASE values {0x0A0A, 0x1A1A =E2=80=A6. }. If I am missing someth= ing, > please clarify me. > > > > Regards, > > R Ashok > > > ------------------------------ > > Raja Ashok VK > =E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 = Huawei Technologies Co., Ltd. > [image: Company_logo] > > Phone: > Fax: > Mobile: > Email: > Huawei Technologies Co., Ltd. > Bangalore, India > > http://www.huawei.com > ------------------------------ > > =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB= =E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4= =BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB= =99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84= =E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 > =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB= =E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4= =BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88= =86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96= =E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD > =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99= =E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7= =AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F= =A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE= =E4=BB=B6=EF=BC=81 > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *David Benjamin > *Sent:* 26 July 2016 04:02 > *To:* tls@ietf.org > *Subject:* [TLS] Keeping TLS extension points working > > > > Hi folks, > > > > I'm not sure how this process usually works, but I would like to reserve = a > bunch of values in the TLS registries to as part of an idea to keep our > extension points working. Here's an I-D: > > https://tools.ietf.org/html/draft-davidben-tls-grease-00 > > > > (The name GREASE is in honor of AGL's rusted vs. well-oiled joints analog= y > from https://www.imperialviolet.org/2016/05/16/agility.html ) > > > > One problem we repeatedly run into is servers failing to implement TLS's > various extension points correctly. The most obvious being version > intolerance. When we deployed X25519 in Chrome, we discovered an intolera= nt > implementation. (Thankfully it was rare enough to not warrant a fallback = or > revert!) It appears that signature algorithms maybe also be gathering rus= t. > Ciphers and extensions seem to have held up, but I would like to ensure > they stay that way. > > > > The root problem here is these broken servers interoperate fine with > clients at the time they are deployed. It is only after new values get > defined do we notice, by which time it is too late. > > > > I would like to fix this by reserving a few values in our registries so > that clients may advertise random ones and regularly exercise these > codepaths in servers. If enough of the client base does this, we can turn= a > large class of tomorrow's interop failures into today's interop failures. > This is important because an bug will not thrive in the ecosystem if it > does not work against the current deployment. > > > > If you were in Berlin, you may recognize this idea from the version > negotiation debate. Alas that all happened in the wrong order as I hadn't > written this up yet. This idea can't be applied to versioning without > giving up on ClientHello.version, but we can start with the rest of the > protocol. > > > > David > > > > PS: This is actually my first I-D, so apologies if I've messed it up > somewhere! > > _______________________________________________ > > > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11444e94cc3e8905392af76f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 3,= 2016 at 8:52 AM Raja ashok <ra= ja.ashok@huawei.com> wrote:

Hi David & Steven,=

=C2=A0

Here our intension is to = find out buggy server which implemented a cipher suite support with wrong v= alue other than specified in RFC.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If that wrong value = usage in that buggy server collides with any real cipher suite on the perio= d of deployment means, the bug would have identified immediately with some other non buggy client. =C2=A0<= /p>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If that wrong value = is in the range of unspecified value, then that bug thrives and it will com= e out only after several years when IANA assigns that value to some new cipher suite.

As= ecosystem problems go, this is very tame one. I don't think the comple= xity cost of a retry (which is not compatible with existing servers anyway)= far outweighs the ecosystem costs of that particular bug.

Should an implementation, say, copy-and-paste the wrong value for = some cipher suite and use an unallocated one then, yes, if widespread we wi= ll have difficulties using cipher suite value. But then we can simply pick = a different one and document that that value has been lost.

<= /div>
Moreover, making all values into GREASE values will not catch thi= s bug. The probability of hitting this wrong value randomly is around 1/2^1= 6 which is well in the noise. Flaky failures won't do any good to preve= nt bugs.

In contrast, intolerance to *anything* un= known is a huge problem for deployment. Then we simply can't deploy new= things. (At least not without fallbacks and such which have security conse= quences, among other problems.)

In this case, can you ple= ase tell me why we decided only few values as GREASE value {0x0A0A, 0x1A1A,= ..}. Whether chrome browser has found a real buggy web server which supports these values ?

Ultimately the values need to get reserved so people don't try to us= e them for real ones. I picked a small-ish number so that people maintainin= g the registries would not become too unhappy at me. :-)

Chrome has yet to ship code which does this. I figured I ought to wr= ite something up and send it to this list before squatting on quite so many= values in the registry. For the moment, this idea is merely a spec.
<= div>
David

Regards,

R Ashok

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

3D"image001.jpg"

Phone:
Fax:
Mobile:
Email:
Huawei Technologies Co., Ltd.
Bangalore, India
http://www.huawei.com <= /u>

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

From: David Be= njamin [mailto:d= avidben@chromium.org]
Sent: 02 August 2016 19:30
To: Steven Valdez; Raja ashok; tls@ietf.org
Subject: Re: [TLS] Keeping TLS extension points working

=C2=A0

To expand on that a little, since it seems comments = (a) and (b) are really the same one:

=C2=A0

The purpose of having an explicitly reserved list (b= ) is precisely so we do not have to do a second handshake (a). The purpose = here is to ensure we exercise the little-used codepaths, not introduce new = ones.=C2=A0This is intended to be an extremely minimal mechanism. Clients add a tiny bit of code to their ClientHello and= no server code changes at all. (Note that every MUST in the document is ju= st reiterating what TLS already requires.)

=C2=A0

David

=C2=A0

On Tue, Aug 2, 2016 at 9:47 AM Steven Valdez <svaldez@google.com= > wrote:

a) It seems like if an implementation has updated to= be able to handle a specific GREASE alert, it should be able to handle not= sending an invalid cipher suite. In general, its probably cleaner for the = connection to fatally shutdown and then restart if the server is behaving that poorly. Servers that are sendi= ng back non-existent ciphers are also potentially broken in other ways, and= I don't know whether a client should trust that it can reset any hands= hake state correctly if it were to try doing a "warning" alert.

=C2=A0

b) The reasoning behind having an explicit list is s= o that implementations don't send a value that ends up being defined as= some other valid value. Otherwise its possible that some implementations w= ill update to include GREASE values, but they might not update immediately upon new values being assigned by IANA, = which means that there will be periods of times that some clients might sen= d "fake" values that collide with real values, confusing the peer= implementation into believing they actually support something that they don't and resulting in more intolerance is= sues between outdated GREASE clients and newly updated servers, with this i= ntolerance being firmly the GREASE clients fault. The hardcoded list gets a= round this by making sure GREASE never overlaps with an actual value, though at the trade-off that badly designed= implementations could choose to just hard-code ignore the GREASE codepoint= s.

=C2=A0

On Tue, Aug 2, 2016 at 2:59 AM Raja ashok <raja.ashok@huawei.com<= /a>> wrote:

Hi Benjamin,

=C2=A0

I have gone through the G= REASE mechanism which you proposed in your new draft. It=E2=80=99s really a= nice idea for finding a buggy server before it thrives.

=C2=A0

I am having few doubts on= this, which are listed below.

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What should be the behaviour of client in= case if a buggy server responded for a GREASE value ?<= /p>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Consider a client sends a GREASE cipher v= alue at first place and followed by valid cipher suites, in its client hell= o.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a buggy server selects that cipher the= n it will response server hello with that GREASE cipher value. At this case= if client sends FATAL alert then both side TLS and TCP needs to be closed and client needs to recreate a new TCP connection, and = then restart TLS handshake without GREASE cipher value.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Instead of this we can make client to sen= d warning alert (with new TLS alert code GREASE_CIPHER_VALUE_SELECTED(111))= and restart TLS handshake by sending client hello again.<= /u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a server receives this new warning, th= en it should be ready to receive new client hello to restart handshake.

=C2=A0

SERVER=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=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

CH (GREASE Cipher value & Valid Cipher value= )=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ------>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= <-------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SH (GREASE cipher value)<= /u>

Fatal alert=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -------->

TCP (SYN)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <--------=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TC= P(SYN ACK)

TCP (ACK)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -------->

CH (Valid cipher value)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Scenario 1 : Sending FATAL alert for server selecting GREAS= E value

=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=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=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

CH (GREASE Cipher value & Valid Cipher value= )=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------><= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= <-------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SH (GREASE cipher value)<= /u>

Warning alert=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->

CH (Valid cipher value)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Scenario 2 : Sending WARNING alert for server selecting GRE= ASE value

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I hope sending warning msg and restarting= TLS handshake will be efficient.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TLS Server must notify the application, w= henever it receives a GREASE warning alert.

=C2=A0

b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Why only few values are specified as GREA= SE value ? Basically all value which are not specified by IANA should be co= nsidered as GREASE value right ?

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Basically client should maintain the list= of values (cipher suite, extensions) specified by IANA. The range of value= s.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For example IANA specified cipher suite v= alues are {{0x0000,0x005C}, {0x0060,0x006D}, {0x0084, 0x00C5}, {0x00FF, 0x0= 0FF} =E2=80=A6.. }. This should be maintained in client.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We should make the client to choose a ran= dom value which are not in this supported value list. That cipher value sho= uld be considered as GREASE value and need to keep in first place of its cipher list.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If its selected by a buggy server, then c= lient should behave as mentioned in above scenario 2.<= /p>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Even in future if IANA provides new value= s to new cipher, then this list also should be updated. Consider in this ca= se server is supporting that new cipher and client is not aware about it, so client can propose that value as GREASE value, then= still connection will work with the 2nd handshake.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am not understanding why we are plannin= g to maintain a few set of GREASE values {0x0A0A, 0x1A1A =E2=80=A6. }. If I= am missing something, please clarify me.

=C2=A0

Regards,=

R Ashok<= /u>

=C2=A0

Raja As= hok VK
=E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99= =90=E5=85=AC=E5=8F=B8 H= uawei Technologies Co., Ltd.
3D"Compan=

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

http://www.huawei.com

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

From: TLS [mai= lto:tls-bounces@i= etf.org] On Behalf Of David Benjamin
Sent: 26 July 2016 04:02
To: tls@ietf.org
Subject: [TLS] Keeping TLS extension points working=

=C2=A0

Hi folks,

=C2=A0

=C2=A0

(The name GREASE is in honor of AGL's rusted vs.= well-oiled joints analogy from https://www.imperialviolet.org/2016/05/16/agility.html=C2=A0)=

=C2=A0

One problem we repeatedly run into is servers failin= g to implement TLS's various extension points correctly. The most obvio= us being version intolerance. When we deployed X25519 in Chrome, we discovered an intolerant implementation. (Thankfully it was = rare enough to not warrant a fallback or revert!) It appears that signature= algorithms maybe also be gathering rust. Ciphers and extensions seem to ha= ve held up, but I would like to ensure they stay that way.

=C2=A0

The root problem here is these broken servers intero= perate fine with clients at the time they are deployed. It is only after ne= w values get defined do we notice, by which time it is too late.

=C2=A0

I would like to fix this by=C2=A0reserving a few val= ues in our registries so that clients may advertise random ones and regular= ly exercise these codepaths in servers. If enough of the client base does this, we can turn a large class of tomorrow's interop= failures into today's interop failures. This is important because an b= ug will not thrive in the ecosystem if it does not work against the current= deployment.

=C2=A0

If you were in Berlin, you may recognize this idea f= rom the version negotiation debate. Alas that all happened in the wrong ord= er as I hadn't written this up yet. This idea can't be applied to versioning without giving up on ClientHello.version, but we = can start with the rest of the protocol.

=C2=A0

David

=C2=A0

PS: This is actually my first I-D, so apologies if I= 've messed it up somewhere!

_______________________________________________

--001a11444e94cc3e8905392af76f-- --001a11444e94cc3e8b05392af770 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <156509a48b14ce8e91> X-Attachment-Id: 156509a48b14ce8e91 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --001a11444e94cc3e8b05392af770-- From nobody Wed Aug 3 07:07:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E69E12DCBD for ; Wed, 3 Aug 2016 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bosch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGCJr-QgRAvM for ; Wed, 3 Aug 2016 07:07:20 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [139.15.237.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 89CB812DC4F for ; Wed, 3 Aug 2016 06:59:32 -0700 (PDT) Received: from vsmta14.fe.internet.bosch.com (unknown [10.4.98.54]) by imta24.fe.bosch.de (Postfix) with ESMTP id 6761BD8022E; Wed, 3 Aug 2016 15:59:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bosch.com; s=2015-01-21; t=1470232755; bh=F+T+Gjt514oySXduPX5cWBKh2s+Y6w3R8Na8gipRQUc=; l=10; h=From:From:Reply-To:Sender; b=VKeNlgJuLhwUH0l7eqL5P4WnWAyPDtLy80V+uPkNLXdJiQ5J2hEOa5x+Yp+oX8/hh aP00Rf/74jPgesPm9HcY8731/i19bYJAZDfVK9Zvm90LyI4LcFv7XGw9l0p8ijqASg Y2eTZqXwXkHRu6OpGKiT1x1ju127JhoLlJQvPqns= Received: from SI-MBX1015.de.bosch.com (vsgw22.fe.internet.bosch.com [10.4.98.11]) by vsmta14.fe.internet.bosch.com (Postfix) with ESMTP id 2C89EA40310; Wed, 3 Aug 2016 15:59:15 +0200 (CEST) Received: from FE-MBX1015.de.bosch.com (10.3.230.73) by SI-MBX1015.de.bosch.com (10.3.230.37) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 3 Aug 2016 15:59:14 +0200 Received: from FE-MBX1015.de.bosch.com ([fe80::256d:ef59:31f1:323f]) by FE-MBX1015.de.bosch.com ([fe80::256d:ef59:31f1:323f%16]) with mapi id 15.00.1178.000; Wed, 3 Aug 2016 15:59:14 +0200 From: "Bauer Johannes (HOME/EFS)" To: Benjamin Kaduk Thread-Topic: [TLS] RFC5746: Renegotiation Indication for minimal servers Thread-Index: AQHR7MJvU2wvbTQxuUivvvKs9ZJJXKA1khQAgAAp0U7//+VmgIABowJM Date: Wed, 3 Aug 2016 13:59:14 +0000 Message-ID: <1470232754152.68803@bosch.com> References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> <1470148363699.24362@bosch.com>, <4ff68fa1-0d8e-ed1e-064c-8bb5bbf5935a@akamai.com> In-Reply-To: <4ff68fa1-0d8e-ed1e-064c-8bb5bbf5935a@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.35.28.73] X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22490.006 x-tm-as-result: No--36.812700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_147023275415268803boschcom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TMASE-MatchedRID: ufrcWL8w4aRJJDuM6qazTt35+5/2RxqmzJmqByfAaS2rzPs85fwUk8+c wCLpvDnEyLM3fIW7EpPqls0VZLxwO8U9PLpBsUYW6Zzj+kMRBrYlBKvI9NWIX2yZJ8/t392lkqO 2AbVSuPwjS7ssOLM5LyWyEfCJu9vRKmzIo+yV5o9tD1qg9KZYkVAI6wCVrE3vI/wYF6KKoMPaj9 /xSaV+b6mbwieu8yiCVrG6IYC9CcIHtbzbuedXjVPjo7D4SFg4EQn/YzVoovedYFRaUAqcE9Srq PZHzcuEy4iz7RMbp/FDZSkBhDFqipqyd2+pD08T547kEFZFT02+CP3vLx6KVqIiUozBB8xrDWI1 DnlsVGsPjcygpUCE8B3Ju+pmIrzGmNrlAIQG7r+WPQ9PzUcaKnzIY7d2+Tz9StFk/81wIJKY2sp SGP3t2CqO1+vEcPReZs76viGG3wGpvxu3mLBTOyI9MxSOQ6CSXgqwd9ijktAUtdRZTmEaIQLVL/ qx/ph44ACDWfJ2QnAjSorByreWzDe/ugX/fMWnOU88jCSC5MYtlZY1WAfRjQLO3+bb7Ofo4J/B1 ev1TO0nlz+21M/WjIAy6p60ZV62HRcIXG0b6Kij/IVP6PIDIpx+7GyJjhAUANfm9zN31SVUs5dT ObL2s6fUqLdl9YnWCc8vBJN6mFs82cpqSFYk4LJQof7Tc9NZFNApWWqrSUWiNvVt9DoQS3HC8sm oAuSHwL6SxPpr1/I= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Aug 2016 14:07:24 -0000 --_000_147023275415268803boschcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben, On Tue, Aug 2, 2016 at 17:05, Benjamin Kaduk wrote: > The next step is for someone to write proposed text that would be more cl= ear. > Maybe you have thoughts about how things could change? Sure, I can give it a shot. Below is my proposal. Curious to hear your thoughts on it. I propose slight wording changes in three parts and a new Sect. 4.6 which sums up what is to do for minimal implementations. Cheers, Johannes Sect. 3.4 (Client Behavior: Initial Handshake) o When the handshake has completed, the client needs to save the client_verify_data and server_verify_data values for future use. could be clarified as follows: o When the handshake has completed, a client that supports renegotiatio= n needs to save the client_verify_data and server_verify_data values fo= r future use. Sect. 3.6 (Server Behavior: Initial Handshake) o When the handshake has completed, the server needs to save the client_verify_data and server_verify_data values for future use. could be clarified as follows: o When the handshake has completed, a server that supports renegotiatio= n needs to save the client_verify_data and server_verify_data values fo= r future use. Sect 4.3 (Server Considerations) In order to enable clients to probe, even servers that do not support renegotiation MUST implement the minimal version of the extension described in this document for initial handshakes, thus signaling that they have been upgraded. could be clarified as follows: In order to enable clients to probe, even servers that do not support renegotiation MUST implement the minimal version of the extension described in this document for initial handshakes, thus signaling that they do not suffer from an insecure renegotiation vulnerability. New Sect 4.6 (Minimal Implementation) Signaling that insecure renegotiation is not supported is a useful effec= t of the adaptation of this RFC regardless of whether or not a specific implementation supports renegotation or not. Since minimal implementatio= ns typically do not support renegotation, they also are implicitly not vulnerable to the attacks described in the beginning of this document. Therefore it is sufficient for clients that do not support any kind of renegotation to simply include the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value in the ClientHello, as described in Sect. 3= .4. For TLS servers which do not support renegotiation, it is sufficient to parse ClientHello messages for either the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value or an emp= ty renegotiation_info TLS extension. In either cases, the server MUST respo= nd with an empty renegotation_info TLS extension, as described in Sect. 3.6= . Neither servers nor clients which do not support renegotiation will therefore have the need to store additional variable data in memory duri= ng runtime. -- Johannes Bauer Engineering Field Services (HOME/EFS) Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 Stuttgart-Vaihin= gen | GERMANY | www.bosch-smarthome.com Tel. +49(711)81112906 | johannes.bauer@bosch.com Registergericht: Amtsgericht Stuttgart, HRB 754585; Gesch=E4ftsf=FChrung: Dr. Peter Schnaebele, Veronika Danner --_000_147023275415268803boschcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ben,

On Tue, Aug 2, 2016 at 17:05, Benjamin Kaduk wrote:
> The next step is for someone to write proposed text that would be more= clear.
> Maybe you have thoughts about how things could change?

Sure, I can give it a shot. Below is my proposal. Curious to hear your
thoughts on it. I propose slight wording changes in three parts and a new Sect. 4.6 which sums up what is to do for minimal implementations.

Cheers,
Johannes



Sect. 3.4 (Client Behavior: Initial Handshake)

   o  When the handshake has completed, the client needs to = save the
      client_verify_data and server_verify_data va= lues for future use.

could be clarified as follows:

   o  When the handshake has completed, a client that suppor= ts renegotiation
      needs to save the client_verify_data and ser= ver_verify_data values for
      future use.



Sect. 3.6 (Server Behavior: Initial Handshake)

   o  When the handshake has completed, the server needs to = save the
      client_verify_data and server_verify_data va= lues for future use.

could be clarified as follows:
   
   o  When the handshake has completed, a server that suppor= ts renegotiation
      needs to save the client_verify_data and ser= ver_verify_data values for
      future use.



Sect 4.3 (Server Considerations)

   In order to enable clients to probe, even servers that do not = support
   renegotiation MUST implement the minimal version of the extens= ion
   described in this document for initial handshakes, thus signal= ing
   that they have been upgraded.

could be clarified as follows:

   In order to enable clients to probe, even servers that do not = support
   renegotiation MUST implement the minimal version of the extens= ion
   described in this document for initial handshakes, thus signal= ing
   that they do not suffer from an insecure renegotiation vulnera= bility.



New Sect 4.6 (Minimal Implementation)

   Signaling that insecure renegotiation is not supported is a us= eful effect
   of the adaptation of this RFC regardless of whether or not a s= pecific
   implementation supports renegotation or not. Since minimal imp= lementations
   typically do not support renegotation, they also are implicitl= y not
   vulnerable to the attacks described in the beginning of this d= ocument.

   Therefore it is sufficient for clients that do not support any= kind of
   renegotation to simply include the TLS_EMPTY_RENEGOTIATION_INF= O_SCSV
   signaling cipher suite value in the ClientHello, as described = in Sect. 3.4.

   For TLS servers which do not support renegotiation, it is suff= icient to
   parse ClientHello messages for either the
   TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value= or an empty
   renegotiation_info TLS extension. In either cases, the server = MUST respond
   with an empty renegotation_info TLS extension, as described in= Sect. 3.6.

   Neither servers nor clients which do not support renegotiation= will
   therefore have the need to store additional variable data in m= emory during

   runtime.



--
Johannes Bauer

Engineering Field Services (HOME/EFS)
Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 S= tuttgart-Vaihingen | GERMANY | ww= w.bosch-smarthome.com
Tel. +49(711)81112906 | johannes.bauer@bosch.com
Registergericht: Amtsgericht Stuttgart, HRB 754585;
Gesch=E4ftsf=FChrung: Dr. Peter Schnaebele, Veronika Danner <= /div>
--_000_147023275415268803boschcom_-- From nobody Wed Aug 3 08:33:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129CB12D1E3 for ; Wed, 3 Aug 2016 08:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7RC9EbL3h0v for ; Wed, 3 Aug 2016 08:33:17 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711FE12D67E for ; Wed, 3 Aug 2016 08:31:03 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j12so230504253ywb.2 for ; Wed, 03 Aug 2016 08:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=s+1yyv6sWE+ouIU1HjiHz8uE46zHZMyqiE3uhEc7C9o=; b=BfNVt3FLHD8/RXtgDvbhhvgdnsvT0lhvzZa/NtWVne2WRhPAPsi1wTrVlhRCEzGR3W Z/WnpIFo+80cefFG/bChXPO+bbXaNGXfaaCYr0ifFKiKkpugt5t038s+lbvHUXg5mOTL AJ07WCUMNUkk/KmU7NLJysJsO/NPfSbyPSmNx4id4U1v6urZVaZG6lBRz8BWZ732UqmB mlbfx17KIsf0gYNQhh4PFxeB82ajY1Zf4uXMLQhrK97RSy6awJePhIeRzMv2B3z7f4Jx vcEKNa5MK+bwWSCRV3ikqGjfbfmxAbAocV4XFD2DB8WiwSjU3lokOjQX1PvX6z4VZN70 5KVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=s+1yyv6sWE+ouIU1HjiHz8uE46zHZMyqiE3uhEc7C9o=; b=EZXJgJLzmp26vkM0muQdwxWClHmeBvEVLLgcAmy0tOTewjD1jlrmA1q5v8CxooGWM0 cmdbm4gh22GHr/bzdASwdE+df/3/kCMztSINIOPibPtjRqXiZt6Rm+1DEK+9nZhR3nNV ggfAy5nL5IVvPmMr05AywAL6X6rjgNT0Nft1vL2Uv3pFcFj2B/xSY16XyiIESMfo/Rxa NRD0KG2pMF+3NuzDKgmqB5zsj/9X+EkmMGNzihMzd4W8M6k/j5qN626PtBefSMhyiHag zRRpHa5cB7EQu5xj54hKK9MfnowAN9sT31v4BCPCmzFsO+LjyPO4IgDdhAhq86MqVsm7 wLXQ== X-Gm-Message-State: AEkoouu8H/HFgt0K/8aZRpZ/WhQZrpz4fl1D9GEukdQEMTbiNbW+3Ivcv2F+EmhkAEWDoIteou5lzqbsjnMkZQ== X-Received: by 10.13.209.129 with SMTP id t123mr55184454ywd.93.1470238262522; Wed, 03 Aug 2016 08:31:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Wed, 3 Aug 2016 08:30:22 -0700 (PDT) From: Eric Rescorla Date: Wed, 3 Aug 2016 08:30:22 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114e8ac65faa5c05392c8530 Archived-At: Subject: [TLS] PR for new negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Aug 2016 15:33:22 -0000 --001a114e8ac65faa5c05392c8530 Content-Type: text/plain; charset=UTF-8 Folks, As promised, I've written a PR that describes the new negotiation syntax we discussed in Berlin. I also have prototype implementation of this in NSS and it's quite a bit cleaner than the previous negotiation design. I think that others have found the same thing. https://github.com/tlswg/tls13-spec/pull/559 IMPORTANT: This new negotiation syntax allows for two modes that were not previously available with TLS 1.3: PSK and PSK-(EC)DHE with server-side signatures. This construction should be safe with resumption-PSK (this is why we introduced the resumption_ctx design), but as noted in Antoine's recent message [0], this is not safe with non-resumption PSK with the all-zeroes resumption context that we now use with external PSKs. I have an action item to fix that, so just keep that in the back of your head as you review this PR. Comments welcome. -Ekr [0] https://www.ietf.org/mail-archive/web/tls/current/msg20637.html --001a114e8ac65faa5c05392c8530 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

As promised, I've= written a PR that describes the new negotiation
syntax we discus= sed in Berlin. I also have prototype implementation of
this in NS= S and it's quite a bit cleaner than the previous negotiation
= design. I think that others have found the same thing.

=


IMPORTANT: This new negotiation syntax allows for two modes that were
not previously available with TLS 1.3: PSK and PSK-(EC)DHE with
=
server-side signatures. This construction should be safe with
resumption-PSK (this is why we introduced the resumption_ctx design),
but as noted in Antoine's recent message [0], this is not safe w= ith
non-resumption PSK with the all-zeroes resumption context tha= t we now
use with external PSKs. I have an action item to fix tha= t, so just
keep that in the back of your head as you review this = PR.

Comments welcome.

-Ek= r


--001a114e8ac65faa5c05392c8530-- From nobody Wed Aug 3 11:15:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F9912D0B4 for ; Wed, 3 Aug 2016 11:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYIrV0wAIAt2 for ; Wed, 3 Aug 2016 11:15:36 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9CE12B00D for ; Wed, 3 Aug 2016 11:15:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 6C12210598; Wed, 3 Aug 2016 21:15:34 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id y-JoEGfcd13M; Wed, 3 Aug 2016 21:15:33 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 45897283; Wed, 3 Aug 2016 21:15:33 +0300 (EEST) Date: Wed, 3 Aug 2016 21:15:27 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160803181527.GA31372@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for new negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Aug 2016 18:15:39 -0000 On Wed, Aug 03, 2016 at 08:30:22AM -0700, Eric Rescorla wrote: > Folks, > > As promised, I've written a PR that describes the new negotiation > syntax we discussed in Berlin. I also have prototype implementation of > this in NSS and it's quite a bit cleaner than the previous negotiation > design. I think that others have found the same thing. Yup, looks much cleaner. > https://github.com/tlswg/tls13-spec/pull/559 > > IMPORTANT: This new negotiation syntax allows for two modes that were > not previously available with TLS 1.3: PSK and PSK-(EC)DHE with > server-side signatures. This construction should be safe with > resumption-PSK (this is why we introduced the resumption_ctx design), > but as noted in Antoine's recent message [0], this is not safe with > non-resumption PSK with the all-zeroes resumption context that we now > use with external PSKs. I have an action item to fix that, so just > keep that in the back of your head as you review this PR. The idea is to essentially use "resumption master secret" as PSK and then to derive the two subkeys off that on handshake, right? Also I noticed that now there is no indication on if the group indication in HRR is valid or not (pure-PSK). Dirty hack would be to grab some reserved value (FF01?) for "I don't need any more groups" (which isn't the same as "no group"). Or perhaps one could stick it into extension[1]. Also, now that there are signatures even with 0-RTT, one should recheck the 0-RTT extension checking logic (the original logic is now invalid, but I think conclusions[2] for free certificate case are still valid). However, if the thing does not use free certificates (in which case the logic should absolutely be specified, or one WILL get massive interop problems!) the conclusions definitely are not valid.. [1] One design would be to move group to extensions, rename 'extensions' to something like 'problems'. Then require 'problems' to be non-empty and require clients to abort if they see problem types they don't recognize (but problem types don't need to be advertized). [2] The original conclusions were that out of extensions, only server_name and application_layer_protocol_negotiation matter. -Ilari From nobody Thu Aug 4 08:49:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F9E12B032 for ; Thu, 4 Aug 2016 08:49: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8efC4Xzd-w6 for ; Thu, 4 Aug 2016 08:49:04 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6F312B04C for ; Thu, 4 Aug 2016 08:49:04 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id 52so160809682qtq.3 for ; Thu, 04 Aug 2016 08:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=0qaAqcTfk2vn/mgA90FncvsOMhcnzwVLxiYS8JTbrHI=; b=HsqbgO5wpaYCWaPA2Tqp2qhm7XbLfWTk1RaP2zjgfueHARvjSQmi6ScVLjzEmnuE9D HAqEkGfoW8rpDMv4v4uCUOZG0YnjCP8wskUb0oypfkDr5s3TP0uxFtHSCeZFBz/bRNmX 1tgPIiulCEqCWWGvF5mKD8JejExEDWnt0ICg+bTDzWAtVKK8jBfuLStwYKtIB8MI4Z8w WZvObVJA69iVx8XClyN49tq5oBxlBK7QVwfFEdFD5Iy2mdR1cDl4Nkgz7T8DYyM1mfmn GhF4jnSOvdM3iJtlEaeW0uDCtZ7O6UfulJGxS7h8l1fTNHrm/Rc5QxJJUvpudb04MvyS 6BKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=0qaAqcTfk2vn/mgA90FncvsOMhcnzwVLxiYS8JTbrHI=; b=lAkbR+9Hx3ezghgbNZ4bhdJN79l87ErI4Rmx8wXzpbsBvIggOuNmlHQie93cDgVYsQ glFwSkJi0GubB3WVou8ZZObN7/mVeiCG52uAiWfQDK37ZMUHbRToNSmtarH70o8iFbHp 9okI88G3sUaQGV7djzgsPw3UX2yRtrmTg9m4GrQYE+R0f7bw4BCLgJI2c+xO5vqz3cxJ uFoKhxabgZVOIJgZozU+JS94PmY0eK/fE7GbY1CIcf00S0gfAUfX6Isgm2mHgfYuubRD oBN+lRWkFw8cZ7TqMch8SACOu5FVpVGLK5Yt1vxw/9kyO99crAfpaMVo+H0Qd81g9PC/ pnFQ== X-Gm-Message-State: AEkoout9ga7hrgpadg9bYvKTw74InssXsjgYB/HP1tDhZgfPF+eGjcQ4qtqr8tYaKxnB6fE7mjTrw/nUmI9kdA== X-Received: by 10.200.55.91 with SMTP id p27mr7039998qtb.48.1470325743489; Thu, 04 Aug 2016 08:49:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.162.22 with HTTP; Thu, 4 Aug 2016 08:48:43 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Thu, 4 Aug 2016 08:48:43 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11398802a529ab053940e3ea Archived-At: Subject: Re: [TLS] PR for new negotiation syntax X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Aug 2016 15:49:08 -0000 --001a11398802a529ab053940e3ea Content-Type: text/plain; charset=UTF-8 Hi Folks, There was significant support for this approach in Berlin so if you have concerns with this approach please post them to the list by Monday, August 8, 2016. Thanks, S&J On Wed, Aug 3, 2016 at 8:30 AM, Eric Rescorla wrote: > Folks, > > As promised, I've written a PR that describes the new negotiation > syntax we discussed in Berlin. I also have prototype implementation of > this in NSS and it's quite a bit cleaner than the previous negotiation > design. I think that others have found the same thing. > > https://github.com/tlswg/tls13-spec/pull/559 > > > IMPORTANT: This new negotiation syntax allows for two modes that were > not previously available with TLS 1.3: PSK and PSK-(EC)DHE with > server-side signatures. This construction should be safe with > resumption-PSK (this is why we introduced the resumption_ctx design), > but as noted in Antoine's recent message [0], this is not safe with > non-resumption PSK with the all-zeroes resumption context that we now > use with external PSKs. I have an action item to fix that, so just > keep that in the back of your head as you review this PR. > > Comments welcome. > > -Ekr > > [0] https://www.ietf.org/mail-archive/web/tls/current/msg20637.html > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11398802a529ab053940e3ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks,

There was s= ignificant support for this approach in Berlin so if you have concerns with= this approach please post them to the list by Monday, August 8, 2016.

= Thanks,

S&J

On Wed, Aug 3, 2016 at 8:30 AM, Eric Rescorla <ekr@rtfm.com&g= t; wrote:
Fo= lks,

As promised, I've written a PR that descr= ibes the new negotiation
syntax we discussed in Berlin. I also ha= ve prototype implementation of
this in NSS and it's quite a b= it cleaner than the previous negotiation
design. I think that oth= ers have found the same thing.



IMPOR= TANT: This new negotiation syntax allows for two modes that were
= not previously available with TLS 1.3: PSK and PSK-(EC)DHE with
s= erver-side signatures. This construction should be safe with
resu= mption-PSK (this is why we introduced the resumption_ctx design),
but as noted in Antoine's recent message [0], this is not safe with
non-resumption PSK with the all-zeroes resumption context that we n= ow
use with external PSKs. I have an action item to fix that, so = just
keep that in the back of your head as you review this PR.

Comments welcome.


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


--001a11398802a529ab053940e3ea-- From nobody Fri Aug 5 18:38:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F220212D73B for ; Fri, 5 Aug 2016 18:38:56 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLZxNqkxL4qn for ; Fri, 5 Aug 2016 18:38:55 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE8A12D17A for ; Fri, 5 Aug 2016 18:38:52 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id f6so39235031ith.0 for ; Fri, 05 Aug 2016 18:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=vWB6ua8g51cu+etztsoIN4giPHxN06hFtP3JLxItBCk=; b=CRxBfTae/arUPVBrIyCqS7wrfFCMWsergI2x6eBBamg7wCGSCH0UowsTz2BD7Jd7gp dA1Vq6V2BvvaHmBzJ0QhmapkZPxG7vXplSN/Yr8HKpto5+dimOtiCn1EZILo7w0Kg3Rj yZJMsksXepmfhJZISH5LT9rOzG0zIBwClm96ZOWK1YtWazgKzvleMmbqR58C3o76ghU8 f23CUlBH1YJSSR8MrOGB9yAYjSpACcIJpHptNr5eFvzqBx+yfna5HUZXc1wno2hOQzn4 rrOiqlKWeXLL8btB0/nI0sElZRfXSULNbvO7EdoYcISCxlIhN37+YIoeff/+1Dl35S5d YU9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vWB6ua8g51cu+etztsoIN4giPHxN06hFtP3JLxItBCk=; b=WkbBrJ25Rt64TQeLUKiKhiOgYhpfh5rcEkngOBZF5813MvXmBRVstBF/F/5LWAkNzi sG16My8ccQoif26h41ftTm59mJao96hqpdUhkXtTeevYOCVh319MWjoyd/vWaUQkCgWc U164SlWTYAE7RSg6qKlBmBUCdEPXByk4KKSYCHDvczuBTrd6x0llsRhTtLcNyZKIPFis T8y86f24ij/EmmfaMcg0sYg4RZm18ckg/nCZ49nlMvSmJdLGNAsYTUFOoX30QK+ZGyER 1aBXzQpzspQtq6xr7F7YIaVc1tKp4nrrd3gA/hrXSa9/1JFiqhtjPSFQh/T+LsLlLG9J b1fw== X-Gm-Message-State: AEkooutZOkWMvle8HsdlOGucvm1rmi3XPNnr2V+UF3SJt9a3FgBvyJBTGFcihPAPGOTaXAgIge+jwYgQS5FBpQ== X-Received: by 10.36.246.8 with SMTP id u8mr7538711ith.23.1470447531419; Fri, 05 Aug 2016 18:38:51 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Sat, 06 Aug 2016 01:38:40 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0551a4c56d9f05395d3ecc Archived-At: Subject: [TLS] draft-sullivan-tls-post-handshake-auth-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 01:38:57 -0000 --94eb2c0551a4c56d9f05395d3ecc Content-Type: text/plain; charset=UTF-8 We discussed on this list a proposal to allow secondary certificate authentication in HTTP/2 (https://tools.ietf.org/html/draft-bishop-httpbis- http2-additional-certs). In that discussion, some questions were raised around whether or not certificate authentication should be handled in the HTTP/2 layer or at the TLS layer. This draft is our attempt to create a more complete mechanism for post-handshake authentication in TLS 1.3 that supports standard use cases like in-browser client certificate authentication as well as new use cases like secondary certificate authentication in HTTP/2. This draft takes the post-handshake client authentication mechanism from TLS 1.3 (Section 4.4.2.) and generalizes it to allow four types of post-handshake authentication: * solicited client authentication * spontaneous client authentication * solicited server authentication * spontaneous server authentication Support for these modes is negotiated in a new TLS extension. As written, this draft is complementary to the current TLS 1.3 draft, however, it makes use of modified versions of the Certificate and CertificateRequest structures instead of those from TLS 1.3. If the working group agrees that a separate draft is a reasonable approach for post-handshake authentication, it may make sense to merge the structure changes from this draft into the TLS 1.3 specification and remove post-handshake authentication from TLS 1.3. Doing so would likely make both TLS 1.3 and this draft smaller, simpler to analyze, and easier to implement. This draft comes with the caveat that the new post-handshake flows still need formal a security proof. Nick Sullivan --94eb2c0551a4c56d9f05395d3ecc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We discussed o= n this list a proposal to allow secondary certificate authentication in HTT= P/2 (https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs). In that discussion,= some questions were raised around whether or not certificate authenticatio= n should be handled in the HTTP/2 layer or at the TLS layer. This draft is = our attempt to create a more complete mechanism for post-handshake authenti= cation in TLS 1.3 that supports standard use cases like in-browser client c= ertificate authentication as well as new use cases like secondary certifica= te authentication in HTTP/2.

This draft takes the = post-handshake client authentication mechanism from TLS 1.3 (Section 4.4.2.= ) and generalizes it to allow four types of post-handshake authentication:<= /div>
* solicited client authentication
* spontaneous client = authentication
* solicited server authentication
*= spontaneous server authentication
Support for these modes is neg= otiated in a new TLS extension.

As written, = this draft is complementary to the current TLS 1.3 draft, however, it makes= use of modified versions of the Certificate and CertificateRequest structu= res instead of those from TLS 1.3. If the working group agrees that a separ= ate draft is a reasonable approach for post-handshake authentication, it ma= y make sense to merge the structure changes from this draft into the TLS 1.= 3 specification and remove post-handshake authentication from TLS 1.3. Doin= g so would likely make both TLS 1.3 and this draft smaller, simpler to anal= yze, and easier to implement.

This draft comes wit= h the caveat that the new post-handshake flows still need formal a security= proof.

Nick Sullivan
--94eb2c0551a4c56d9f05395d3ecc-- From nobody Sat Aug 6 10:26:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACC312D52C for ; Sat, 6 Aug 2016 10:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BWteqO9vksk for ; Sat, 6 Aug 2016 10:26:15 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 38BF012D520 for ; Sat, 6 Aug 2016 10:26:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 24840E8D5; Sat, 6 Aug 2016 20:26:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id lO26lzxFlrIW; Sat, 6 Aug 2016 20:26:12 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 767932316; Sat, 6 Aug 2016 20:26:12 +0300 (EEST) Date: Sat, 6 Aug 2016 20:26:05 +0300 From: Ilari Liusvaara To: Nick Sullivan Message-ID: <20160806172605.fqgtphnurlqzxfpo@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.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-sullivan-tls-post-handshake-auth-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 17:26:18 -0000 On Sat, Aug 06, 2016 at 01:38:40AM +0000, Nick Sullivan wrote: > > > We discussed on this list a proposal to allow secondary certificate > authentication in HTTP/2 (https://tools.ietf.org/html/draft-bishop-httpbis- > http2-additional-certs). In that discussion, some questions were raised > around whether or not certificate authentication should be handled in the > HTTP/2 layer or at the TLS layer. This draft is our attempt to create a > more complete mechanism for post-handshake authentication in TLS 1.3 that > supports standard use cases like in-browser client certificate > authentication as well as new use cases like secondary certificate > authentication in HTTP/2. Also, how would this be used in applications that need higher-level coordination above TLS layer (like HTTP/2)? Can applications specify and receive the context values used? E.g. to act as handles to refer to the resulting authority objects (HTTP/2 absolutely needs to be able to refer to client authority). Also, are all errors (including things like getting extensions wrong or CA wrong) fatal to the whole connection, or how is error reporting handled? One can't use alerts for non-fatal reports. Also, are applications expected to be able to specify exactly where in stream to put an authentication (response)? Especially so they can immediately follow with appdata coordinating the usage. > This draft takes the post-handshake client authentication mechanism from > TLS 1.3 (Section 4.4.2.) and generalizes it to allow four types of > post-handshake authentication: > * solicited client authentication > * spontaneous client authentication > * solicited server authentication > * spontaneous server authentication > Support for these modes is negotiated in a new TLS extension. The crypto used looks bit odd. AFAIU, if one wants to chain hashes, one should expand the chaining value to multiple of input block and continue from there. One could even use the normal TLS authentication block with extended_handshake_hash as base context (with certificate request included if present). extended_handshake_hash can either be the same handshake_hash used for calculating EMS/RMS but padded to multiple of blocksize, or special HKDF-extracted value that is one hash input in size. For SHA-256 "one hash input" is 64 bytes, for SHA-384, it is 128 bytes [1] I.e. the signature TBS (without context) is: hash(extended_handshake_hash + certificate_request* + certificate) + resumption_context And the MAC input is: hash(extended_handshake_hash + certificate_request* + certificate + certificate_verify) + resumption_context Where extended_handshake_hash can be: hash(ClientHello...ClientFinished), padded to input block. or HKDF-Expand-Label result with HashValue=hash(ClientHello...ClientFinished) and length being hash input block. > As written, this draft is complementary to the current TLS 1.3 draft, > however, it makes use of modified versions of the Certificate and > CertificateRequest structures instead of those from TLS 1.3. If the working > group agrees that a separate draft is a reasonable approach for > post-handshake authentication, it may make sense to merge the structure > changes from this draft into the TLS 1.3 specification and remove > post-handshake authentication from TLS 1.3. Doing so would likely make both > TLS 1.3 and this draft smaller, simpler to analyze, and easier to implement. Yeah, the post-handshake parts are annoying to implement even if one does not support actual post-handshake auth (due to the requirement to send Finished) if one wants to do anything else except just plain not respond to server requests (or even worse, just terminate the connection). > This draft comes with the caveat that the new post-handshake flows still > need formal a security proof. Just keep in mind that even if it is secure at TLS level, does not mean it is secure at application level! [1] SHA3-256 would have 136, SHA3-384 would have 104. BLAKE2b would have 128. -Ilari From nobody Sat Aug 6 21:55:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9CD12D15F for ; Sat, 6 Aug 2016 21:54:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BXJLPMvdB41 for ; Sat, 6 Aug 2016 21:54:58 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 109BC120727 for ; Sat, 6 Aug 2016 21:54:57 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id u186so51516722ita.0 for ; Sat, 06 Aug 2016 21:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=UJ0AeF2U8PvvvUffOEiMbRT6yJMx31QfnAvIBcJyZRk=; b=jILzVrbWp1ZAR9x0XgsJwut5D7aybSctkRNVWdRypKBQDAXkCPk8owTqQxEhTfbUxv GtAC+U+0Uf1eJTgrekzZ9+LMMSU5P3nBGe2jcGChmNflHWi1fHfyBSs6XjNXZ98h8b4O ts3oZOMJX8YDUWmya8Q2wPaUgW+gtYAikNN7R12gZbAdLk8Agn0EI8YnAfOM/zrVFyXq D1s1v/6AWN+uLs2gDDvV9gJrlX0p4HiE3rdZAvz5w5jIHASJr5ErHwaS8KVdEjxfLL2k y6mQEGZV8JDrxnQ9rY4yNBXAP5FKzxsnBZU+Xb1E4Aw3b1tppTkzf2OhntfPOj+vBGuf BX4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UJ0AeF2U8PvvvUffOEiMbRT6yJMx31QfnAvIBcJyZRk=; b=Of1dnp4FwGYeSse5umB2reHX3aWh0f7xY+Vytmiao2hWAW3r/amAYt5ejUPgojWxbZ iTH3Rc6762sZ6GTbYS35sP/IiOx7SgFs+Wakvf1QzuBXZ2ryhnqgm0ZWQsbKsYQ6nL9W ea8aHs9bKuBW0qqSuTAfopy79/rvNgeoXwodBHmNBdov9lnlLu/TC8AQkexCRl1AL/Hi PPSaFiKNsJsB4WKs3cTrZx8yEnWpuopiYegJgj4ietMt4o49pYsF8uDpwYI1lTj+Ue80 //qqg518zuzyVWEd/erBsBSt/t1xOm81fFqzDx7sBEhQys3U40hVWuvvh6L2RvUvIjlj LuYA== X-Gm-Message-State: AEkoouvMqlhGW4dMoJ8Xa6gTBWfI82IJWHsGsrg1yaOcv1VQmanuSAOC9vlbxcOTkVdAFuucWjHDhcVpGBGb+Q== X-Received: by 10.36.202.199 with SMTP id k190mr12949618itg.36.1470545696925; Sat, 06 Aug 2016 21:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.74.73 with HTTP; Sat, 6 Aug 2016 21:54:56 -0700 (PDT) From: Brian Smith Date: Sat, 6 Aug 2016 18:54:56 -1000 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Aug 2016 04:54:59 -0000 The current draft says "It is RECOMMENDED that implementations implement 'deterministic ECDSA' as specified in [RFC6979]." The current draft also says, regarding RSA-PSS signatures: "When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest output." I think it would be ideal if we could find a way to specify the RSA-PSS salt requirement in a way that meets the requirements for provable security that motivated the switch to RSA-PSS and also recommends a deterministic method of salt generation analogous to what RFC6979 does for ECDSA. However, I don't know of any such method. Perhaps other people do; if so, the spec to include a recommendation to use such a method be used. Also, I think it would be great if people working on proofs of security for TLS could take into consideration the fact that some--perhaps many--implementations will intentionally or accidentally use some form of deterministic or less-than-random salt generation for RSA-PSS. For example, it would be great to see a "What if the salt(s) in the RSA PSS signature(s) were generated deterministically?" section of papers describing such proofs. Cheers, Brian -- https://briansmith.org/ From nobody Sat Aug 6 23:57:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C3D12D09A for ; Sat, 6 Aug 2016 23:57:27 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxlksvEcQp72 for ; Sat, 6 Aug 2016 23:57:24 -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 3201512B03D for ; Sat, 6 Aug 2016 23:57:23 -0700 (PDT) Received: from pc1 (wsip-24-120-54-20.lv.lv.cox.net [::ffff:24.120.54.20]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sun, 07 Aug 2016 08:57:20 +0200 id 0000000000000051.0000000057A6DBD0.00001AF8 Date: Sat, 6 Aug 2016 23:57:16 -0700 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20160806235716.726a0e4e@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-6904-1470553040-0001-2" Archived-At: Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Aug 2016 06:57:27 -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-6904-1470553040-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Sat, 6 Aug 2016 18:54:56 -1000 Brian Smith wrote: > Also, I think it would be great if people working on proofs of > security for TLS could take into consideration the fact that > some--perhaps many--implementations will intentionally or accidentally > use some form of deterministic or less-than-random salt generation for > RSA-PSS. For example, it would be great to see a "What if the salt(s) > in the RSA PSS signature(s) were generated deterministically?" section > of papers describing such proofs. Actually there is some info on that in the PSS spec [1]. What I write here is my limited understanding, but roughly I'd interpret it as this: It says that if you use a non-random salt the security gets reduced to the security of full domain hashing, which was kinda the predecessor of PSS. I'd conclude from that that even in a situation where the salt generation is a non-random value nothing really bad happens. The security of a PSS scheme without randomness is still better than that of a PKCS #1 1.5 signature. Maybe some more knowledgable people want to add something, but the bottom line is I think that we don't need to worry too much about the randomness part here. Unlike with other situations (e.g. ecdsa/dsa) the randomness is not a piece that once you take it away everything blows up. [1] https://tools.ietf.org/html/rfc3447 --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-6904-1470553040-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXptvMAAoJEKWIAHK7tR5CuokP/1rpMKrgcNxIQpU6hr5Oz59K ubDOEwoQpcM0M8NaBX9QjZBTSNdSxuYdBa2JLg3wDofZN4ZyaRWjGNHWjdahvbgf 0VtCz0+nSEVns+lU/kIVXTExyc4kEGVOev/OeMbecYNJeV+5N1834wQY/U+wTf7u 7fZUg/ZQVs4O5ALDan31Pp1zzXc/wYjh/UEggY91g5W95SpQno36762e0NyY0pXq Wll3uUV2mn4p/3+Wny5JckzKlT3d3LmJKs0QqbtngbcYsmj5yA8r4wJwbHmTmn0B W9STw+V0K8MZfLvQGhKeG2QBnPdRlFdx9okTFTzry2G7/VX0vvYt4kgzMIf/fvIi KTGlF1OfuWTxF/4tKAmyhue6Mz6RzDqPH98OX5g2hVsH3Fs2m8xruJbuDOzTbz3/ 6E1oqoY3A0Cg2H3dH/iCFRbDXTKFGuGDit4Lg1ZunIWzaF2h+fZGun1f+XVfQj77 Rsu/zklh0xNuBL5YqZa20LMYl+rVceFmb7EpLJXD7vShQ+R+zaYFMUC9FTvMua+Z /u03fDG1fkrrDCSr+a8//8Y2WzFDjqV3vHyyG6ALegsdocyBewSdv1288V4MWFaT K3TETDfDEi4ifZUzGOCvlwHhezgIL6vrJuXY3d1Y6ThqylMsuatkyPqY1khNLVkJ eeqexkwDyLDYFeY3xAcO =tijW -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-6904-1470553040-0001-2-- From nobody Sun Aug 7 08:41:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0373612B03A for ; Sun, 7 Aug 2016 08:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTm3bii6_UF8 for ; Sun, 7 Aug 2016 08:41:47 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 AEEEF128874 for ; Sun, 7 Aug 2016 08:41:47 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id 52so194229115qtq.3 for ; Sun, 07 Aug 2016 08:41:47 -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; bh=Okgji6aLoakGWYfXLkCw0m2qBxDQtvKWLNkUOpHG3Vk=; b=LrgZp8fKYzmJ2V1eKzgNaNnGGA/Ad5cKqDDa+JNqn0XpnGM6CM/nimgwEou1L3z1LP 1MI0wgQ6EhMKuYe8yBM38scapFDioJTzSbTusG6CHPJO3tCqJpqOhVAxFDH/LThHkYDa UAk09/r/UmRgu+iMdMRWIGd2PrtxOmrVffY0TCvJMuZFPH9kNI0J8mt6f3saxH2U+Uj0 IPktwZqnDS5d6mc9VPE1xJ7ZSGdM17Z8BUnzVPrLp8eUMMq23Z3GjTyXr/Z3qUqBC1EJ JU2xDbPGKMCs64E3R9RpYZoD1gA9VlWm6VbBbgKNMdXxt4RJlDZM6kLzEUcH2brNvAfq 2fNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Okgji6aLoakGWYfXLkCw0m2qBxDQtvKWLNkUOpHG3Vk=; b=Qa40L734ZUGmdMA1uxxDL4wDbODuJDXIm5l1mRciS+Lzvh/a7tcwLAIEWQRoNfikvz /j1DevtkZpxOxxxvJ+JxjxV1TVUayXuutKOG/0ZgCe5rsipISaBQ/9Sm/NqfqQf8Pn8j 6vx6ml+7r9rGjLslDAaLKpcutgizi1xbBc2EuzRZCidZQJ9NYQ5xRnQvYdUDJDMSt5Yt tR1wwycN1DsvpyIapLDoF7+HxrgbPy0aNGlXOc/T1lTMTMuoQC3ao1kjch+BOf4EYOGK Uh8b6M54JiKBCnF50DZiOf/V+wpPuKGmp283kKYZDtJ2x7EsR2FssrtIqNBMXykzuqJb ewTg== X-Gm-Message-State: AEkoouvm+HcgkhqGTr+gO/JbBybi2sotdMdBFwtJxKt17y7qDqd8mgn0H1tT/5kLHG7kOQ== X-Received: by 10.200.53.24 with SMTP id y24mr23711212qtb.16.1470584506538; Sun, 07 Aug 2016 08:41:46 -0700 (PDT) Received: from [10.205.168.38] ([209.226.201.240]) by smtp.gmail.com with ESMTPSA id m10sm15139501qta.31.2016.08.07.08.41.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Aug 2016 08:41:45 -0700 (PDT) To: =?UTF-8?Q?Hanno_B=c3=b6ck?= , tls@ietf.org References: <20160806235716.726a0e4e@pc1> From: Rene Struik Message-ID: <782287ea-f491-0298-baa6-aa82e650fe6e@gmail.com> Date: Sun, 7 Aug 2016 11:41:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160806235716.726a0e4e@pc1> Content-Type: multipart/alternative; boundary="------------36296EF7808E1064D1336B81" Archived-At: Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Aug 2016 15:41:50 -0000 This is a multi-part message in MIME format. --------------36296EF7808E1064D1336B81 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Hanno: The papers [1] and [2] may be of interest here. In [2], Section 3.3, Alfred Menezes and Neil Koblitz compare FDH-hash RSA signatures, PSS (lots of randomness in the salt), and a scheme by Wang and Katz that only contains one bit of randomness with signing and is claimed to have tight reductions (see also [1]) and argue a "Pass on PSS". [1] Signature Schemes - Efficient, with Tight Security Reductions (Jonathan Katz, Nan Wang, CCCS 2003). Available from https://www.cs.umd.edu/~jkatz/papers/CCCS03_sigs.pdf [2] Provable Security, Another Look at (Alfred Menezes, Neal Koblitz, IACR ePrint 2004-152). Available from https://eprint.iacr.org/2004/152 On 8/7/2016 2:57 AM, Hanno Böck wrote: > Hi, > > On Sat, 6 Aug 2016 18:54:56 -1000 > Brian Smith wrote: > >> Also, I think it would be great if people working on proofs of >> security for TLS could take into consideration the fact that >> some--perhaps many--implementations will intentionally or accidentally >> use some form of deterministic or less-than-random salt generation for >> RSA-PSS. For example, it would be great to see a "What if the salt(s) >> in the RSA PSS signature(s) were generated deterministically?" section >> of papers describing such proofs. > Actually there is some info on that in the PSS spec [1]. What I write > here is my limited understanding, but roughly I'd interpret it as this: > It says that if you use a non-random salt the security gets reduced to > the security of full domain hashing, which was kinda the predecessor of > PSS. > I'd conclude from that that even in a situation where the salt > generation is a non-random value nothing really bad happens. The > security of a PSS scheme without randomness is still better than that > of a PKCS #1 1.5 signature. > > Maybe some more knowledgable people want to add something, but the > bottom line is I think that we don't need to worry too much about the > randomness part here. Unlike with other situations (e.g. ecdsa/dsa) the > randomness is not a piece that once you take it away everything blows > up. > > > [1] https://tools.ietf.org/html/rfc3447 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------36296EF7808E1064D1336B81 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Hanno:

The papers [1] and [2] may be of interest here. In [2], Section 3.3, Alfred Menezes and Neil Koblitz compare FDH-hash RSA signatures, PSS (lots of randomness in the salt), and a scheme by Wang and Katz that only contains one bit of randomness with signing and is claimed to have tight reductions (see also [1]) and argue a "Pass on PSS".

[1] Signature Schemes - Efficient, with Tight Security Reductions (Jonathan Katz, Nan Wang, CCCS 2003). Available from https://www.cs.umd.edu/~jkatz/papers/CCCS03_sigs.pdf
[2] Provable Security, Another Look at (Alfred Menezes, Neal Koblitz, IACR ePrint 2004-152). Available from https://eprint.iacr.org/2004/152

On 8/7/2016 2:57 AM, Hanno Böck wrote:
Hi,

On Sat, 6 Aug 2016 18:54:56 -1000
Brian Smith <brian@briansmith.org> wrote:


Also, I think it would be great if people working on proofs of
security for TLS could take into consideration the fact that
some--perhaps many--implementations will intentionally or accidentally
use some form of deterministic or less-than-random salt generation for
RSA-PSS. For example, it would be great to see a "What if the salt(s)
in the RSA PSS signature(s) were generated deterministically?" section
of papers describing such proofs.

Actually there is some info on that in the PSS spec [1]. What I write
here is my limited understanding, but roughly I'd interpret it as this:
It says that if you use a non-random salt the security gets reduced to
the security of full domain hashing, which was kinda the predecessor of
PSS.
I'd conclude from that that even in a situation where the salt
generation is a non-random value nothing really bad happens. The
security of a PSS scheme without randomness is still better than that
of a PKCS #1 1.5 signature.

Maybe some more knowledgable people want to add something, but the
bottom line is I think that we don't need to worry too much about the
randomness part here. Unlike with other situations (e.g. ecdsa/dsa) the
randomness is not a piece that once you take it away everything blows
up.


[1] https://tools.ietf.org/html/rfc3447




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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------36296EF7808E1064D1336B81-- From nobody Sun Aug 7 15:44:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5FA12D12E for ; Sun, 7 Aug 2016 15:44:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrDiEWUZ2kMw for ; Sun, 7 Aug 2016 15:44:33 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 6191712B019 for ; Sun, 7 Aug 2016 15:44:33 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q83so344103914iod.1 for ; Sun, 07 Aug 2016 15:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uMvKPViM45NRcvP+E4CC1qFxPPJygVUjoYAQlUW3TJY=; b=BNtOtNJTgp3ApwTDuBaxrxdvjcwW/vS+SJ1o5Y9LXEe4+NDBpXhBR0RAGpt91wYo7h S8PjGsrcc0KpSZjuklpOkU2Vr6fj+E9/JRGNkXFCkt5+6rm38UpITiwL/wLF+AAlPOyG Yon9dEe6QVqjMlTwLtQ8oeqtDIjsd9usThT938Qzl4hWI5ejMJOjhS45wHabx7E8LTT2 bg9XyIwHfR7gmbJV7/4uQgRnUTZz6O+ZJg/UuS0sw63fGsmmnJ9fyRe2fgc+zsKU6SvI 36qZ882SNQBxSqnD1LGx8ACtjI3QG38NC+Jxwz2uZdj1kuZqcFNKiqSLgjPmr4VI2FKa CD0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uMvKPViM45NRcvP+E4CC1qFxPPJygVUjoYAQlUW3TJY=; b=Oi3ZZcSD8wZzb+sj+Gl2VorWuPd0P/i9CAzrF8dBruNhmFBS21rvXEvFxlm+ImiPmZ jfSGpTmbdiaHh2tjFCoP3k1C2lctakSZAULM4x8ZpL8mUnto9UjSsuhrxG1efNcNJN+C TatZwKfVkgc0zNv7lrUN6YpKnunYBo8GO96A+xXApm0dGpHXDSa0KIxl9hDUAcIyNcAK 88yqUFQm/4lfmY6A54Wgfe3zDM7RDVD7bfS3p/imF3bR3yqdmxC0CgLjkmlqa6802Tn3 w7QCcG36YsO9rpII3zNe9zpQa/qp2bbFHmd9y5Gj1P0AqKGTsMW3bBablVLDMBhZmbpO i/7g== X-Gm-Message-State: AEkoouvWeLzTd80TqHO/ohbZ2acEhnqN9OAT8OMFHSwH0XeG/NFDQOId8O2BHoR1viE5O5pz7ZhO9Vp/K6ZVuQ== X-Received: by 10.107.9.231 with SMTP id 100mr92133343ioj.196.1470609872592; Sun, 07 Aug 2016 15:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.74.73 with HTTP; Sun, 7 Aug 2016 15:44:32 -0700 (PDT) In-Reply-To: <782287ea-f491-0298-baa6-aa82e650fe6e@gmail.com> References: <20160806235716.726a0e4e@pc1> <782287ea-f491-0298-baa6-aa82e650fe6e@gmail.com> From: Brian Smith Date: Sun, 7 Aug 2016 12:44:32 -1000 Message-ID: To: Rene Struik Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Aug 2016 22:44:35 -0000 Rene Struik wrote: > The papers [1] and [2] may be of interest here. In [2], Section 3.3, Alfred > Menezes and Neil Koblitz compare FDH-hash RSA signatures, PSS (lots of > randomness in the salt), and a scheme by Wang and Katz that only contains > one bit of randomness with signing and is claimed to have tight reductions > (see also [1]) and argue a "Pass on PSS". > > [1] Signature Schemes - Efficient, with Tight Security Reductions (Jonathan > Katz, Nan Wang, CCCS 2003). Available from > https://www.cs.umd.edu/~jkatz/papers/CCCS03_sigs.pdf > [2] Provable Security, Another Look at (Alfred Menezes, Neal Koblitz, IACR > ePrint 2004-152). Available from https://eprint.iacr.org/2004/152 Right, these are the papers I read that made me start to think it might actually be dumb to randomize the salt when generating a PSS signature. It seems like the randomization is purely needed purely as an artifact of the method used in the security reduction, and seems unlikely to actually improve security. In fact, it would hurt security because it adds significant complexity to PSS signature generation and provides a means to efficiently smuggle secrets out of the security module containing the RSA private key. Thus, an implementer of RSA-PSS signature generation who wants to maximize security likely won't want to randomize the salt. Another interesting paper is [3], which says "However, since PSS (with random salt of arbitrary length) is at least as secure as FDH, we obtain as a corollary from Section 3 a tight security proof from lossiness to the security of PSS, with random salt of arbitrary (possibly zero) length." At the time I suggested [4] that the salt length be fixed to the length of the digest function for RSA PSS signatures in TLS, I wasn't aware of all the research that had been done. Unfortunately, my under-informed suggestion is what is currently prescribed in the current draft. I'd like to make sure that whatever the spec ultimately prescribes is actually motivated by a current scientific argument, even if it means I have to admit I was wrong. [3] Optimal Security Proofs for Full Domain Hash, Revisited (Saqib A. Kakvi and Eike Kiltz). Available from https://www.iacr.org/archive/eurocrypt2012/72370533/72370533.pdf. [4] https://www.ietf.org/mail-archive/web/tls/current/msg15601.html Cheers, Brian -- https://briansmith.org/ From nobody Sun Aug 7 18:19:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4910F12D550 for ; Sun, 7 Aug 2016 18:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9PL2BBsRvkI for ; Sun, 7 Aug 2016 18:19:41 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FA212D181 for ; Sun, 7 Aug 2016 18:19:41 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id w38so197504066qtb.0 for ; Sun, 07 Aug 2016 18:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w/TrJfKbi8odNN21BxT4+zCRvq+GMBKLDU5hdEbPddA=; b=ygGvvrp5BYAKUp5knOgLKUhEMCoHyg8ttLF8HOpUzSLirH8X6X+zlV99vhfmiT3Ulk XBa756JUQL30zzu/gKVV85Gh/TsetUE56TII8GEQyN5wdpYWM6nTcunOuEe/iQZNL/Fb EhryD5MXs3ABSZGuY+RiqY01M/UMa7Ls7rwMLp3CC7txR+jvBf+uUmJkGpHw6Z33KHGN AZRHHE2t4h7RhzWLFqMddixY4T6fqDLJ0r+Cw7BX2A47b0pnc4To9xJcjdmzp3lGYP1E w6/QHXCRFaTdOwToUMZpXxe30ZxNCTxIDLjHYq3LX8mh9RswbdH8DxU/PrQj9A2i5y0D TGZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w/TrJfKbi8odNN21BxT4+zCRvq+GMBKLDU5hdEbPddA=; b=YmW5Qt8CzmRUcq9UqHM6w7PKXFZp+34bB9FZojIsSkji32U03Jt+um9EqpIwkgDG2+ 6cklAwW/7RGO6FriMdrEeYVlmiYCDYnH7BMDmCYzmGTdNrgFfmLwsEXkYT38T+plusfb UzJzeTQvXYmi1baR4hTZpouaNIiaQ2H0qXxp0rCnTIptjOLM97JwGk8Obj+21i8yuYm3 n1ol2nt+U7cV2iBF3GuMWRigzcFoO3pbg+BtDHq6KyeVOoyHg3pv0T6Nn7eetmd5RclE pz8INzxDmBq7d5syURizQ+ODGwLzCJOY2dT8i6r2efbdVHsjeYDFqCAo6x/WLEESe6Xl hR5g== X-Gm-Message-State: AEkoouvYEkgALytSfAE6YfhHQxGjZMFxcjvRiGER4vu6txHytB3f8LVBS8eqYfL/JYipBjDyeextLjpbwleDiQ== X-Received: by 10.237.52.225 with SMTP id x88mr25440314qtd.24.1470619180368; Sun, 07 Aug 2016 18:19:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 7 Aug 2016 18:19:39 -0700 (PDT) In-Reply-To: <20160806172605.fqgtphnurlqzxfpo@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160806172605.fqgtphnurlqzxfpo@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Mon, 8 Aug 2016 11:19:39 +1000 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-sullivan-tls-post-handshake-auth-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 01:19:42 -0000 On 7 August 2016 at 03:26, Ilari Liusvaara wrote: > Also, how would this be used in applications that need higher-level > coordination above TLS layer (like HTTP/2)? The companion h2 draft hasn't been updated, but this will need support from the application layer to use. The intent is to take the structure of draft-bishop-httpbis-http2-additional-certs and remove the stream 0 components and replace them with this draft. > Can applications specify and receive the context values used? E.g. > to act as handles to refer to the resulting authority objects > (HTTP/2 absolutely needs to be able to refer to client authority). The API might take one of two forms: 1. an application requests that authentication happen and get the identifier that TLS uses in return 2. an application requests authentication and specifies the identifier (the TLS stack will have to verify that this is unique and conforms to the restrictions) > Also, are all errors (including things like getting extensions > wrong or CA wrong) fatal to the whole connection, or how is error > reporting handled? One can't use alerts for non-fatal reports. Good question. Errors in encoding or otherwise problems following the rules in the spec should result in a connection-level fatal error. But if the certificate isn't trusted, handling that will be up to the application. > Also, are applications expected to be able to specify exactly > where in stream to put an authentication (response)? Especially > so they can immediately follow with appdata coordinating the > usage. Not sure where you are going here. From nobody Sun Aug 7 23:14:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082B312D688 for ; Sun, 7 Aug 2016 23:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKLIEWgJoPT2 for ; Sun, 7 Aug 2016 23:14:23 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id D4B6912D550 for ; Sun, 7 Aug 2016 23:14:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 7D62610622; Mon, 8 Aug 2016 09:14:20 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id YveBlTQbZo8o; Mon, 8 Aug 2016 09:14:20 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 372D72310; Mon, 8 Aug 2016 09:14:20 +0300 (EEST) Date: Mon, 8 Aug 2016 09:14:13 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160808061413.ylqaytfxxckted4j@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160806172605.fqgtphnurlqzxfpo@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.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-sullivan-tls-post-handshake-auth-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 06:14:25 -0000 On Mon, Aug 08, 2016 at 11:19:39AM +1000, Martin Thomson wrote: > On 7 August 2016 at 03:26, Ilari Liusvaara wrote: > > > Can applications specify and receive the context values used? E.g. > > to act as handles to refer to the resulting authority objects > > (HTTP/2 absolutely needs to be able to refer to client authority). > > The API might take one of two forms: > 1. an application requests that authentication happen and get the > identifier that TLS uses in return > 2. an application requests authentication and specifies the identifier > (the TLS stack will have to verify that this is unique and conforms to > the restrictions) In 2, I would imagine the context is probably usually a sequence number of some kind. > > Also, are all errors (including things like getting extensions > > wrong or CA wrong) fatal to the whole connection, or how is error > > reporting handled? One can't use alerts for non-fatal reports. > > Good question. Errors in encoding or otherwise problems following the > rules in the spec should result in a connection-level fatal error. > But if the certificate isn't trusted, handling that will be up to the > application. And that should presumably be communicated somehow... > > Also, are applications expected to be able to specify exactly > > where in stream to put an authentication (response)? Especially > > so they can immediately follow with appdata coordinating the > > usage. > > Not sure where you are going here. Being able for application to to wait for certificate/cv/finised message to be sent, so it can do something special in application layer immediately after that. -Ilari From nobody Sun Aug 7 23:42:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E535D12D559 for ; Sun, 7 Aug 2016 23:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoMKlEnsTs-I for ; Sun, 7 Aug 2016 23:42:11 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE04120727 for ; Sun, 7 Aug 2016 23:42:11 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id p186so187736852qkd.1 for ; Sun, 07 Aug 2016 23:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=boXaUBbnRAkEwrSAQyL8Yhi2L2SI4su/iY5YIbxGy0Q=; b=Z91np03yqbfDy1L0KEXnIlKwnvX8nufbog13m4aLlsO20eNg4qhAreSYGDNsExGN1s q1fb/pxqENg8z4gaKSPwZxv5tTZ+eow0vtpetgqelM7QCKzHMcCJKGiQvICkHAo0IpU+ diTCOQPJ2NsVI6OK6G1FSVizOogpiPBnxv4RESE+pDL3woeqycpgnGAkOwqJz++7/XQk TIaCI3SNCA2X1/0F7plLWrO/OEK/h2i2EMBuldjIzglHDkryL0qCL3UJHXsdX+9UnX2V QC8sTXN6A2ImBXsTwUwiufo3sCMh9RvMogan9PdckF/Q0VCnkMoBNWhK7qBidvIv3kJN okOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=boXaUBbnRAkEwrSAQyL8Yhi2L2SI4su/iY5YIbxGy0Q=; b=ag2CpSE5UJ0XBLFwHUo4G7SuMYWfQwNXB+0I+k2IkcLraLtWkb8zhqhmOLz86stUSK Jcr+89N9VYk1IgdcQgQ0ECbOb5o3ggWe4EeKrC222s4mLwMo0MqZip0vuH9gzDUyGaR9 QWdj7AFws3wtTAN0/XoJA1hZrgf7I5FSxq1kDVTlp+LwXN7JBcNl3/sEg5i2voFirlFx x/gFW14LuT8mdr6JahIjzriyYZQAX0qGO/esoy+tPvywUrsgXfqHY8yz1xgWYyiDg3Rl mhP/N2wWAt83rNMx176n+icsF6Nhkz77ZjceBKWQidO5xlRj9j5Nnuz/+f5aEKE6MiIT TMPA== X-Gm-Message-State: AEkoouuAE3AKhT+4C/IUD++kww/pm0jAhH6mFRgdt9/mODRgxN0GtBR2s9FBtj0ck8+uhps8w7HuxvYPC/+OgQ== X-Received: by 10.55.184.2 with SMTP id i2mr25059849qkf.261.1470638530716; Sun, 07 Aug 2016 23:42:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 7 Aug 2016 23:42:10 -0700 (PDT) In-Reply-To: <20160808061413.ylqaytfxxckted4j@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160806172605.fqgtphnurlqzxfpo@LK-Perkele-V2.elisa-laajakaista.fi> <20160808061413.ylqaytfxxckted4j@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Mon, 8 Aug 2016 16:42:10 +1000 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-sullivan-tls-post-handshake-auth-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 06:42:13 -0000 On 8 August 2016 at 16:14, Ilari Liusvaara wrote: > In 2, I would imagine the context is probably usually a sequence > number of some kind. The draft defines some rules for construction of identifiers that prevent collisions and the like. >> Good question. Errors in encoding or otherwise problems following the >> rules in the spec should result in a connection-level fatal error. >> But if the certificate isn't trusted, handling that will be up to the >> application. > > And that should presumably be communicated somehow... Of course. See https://github.com/grittygrease/tls13-post-handshake-auth/issues/18 (feel free to contribute) > Being able for application to to wait for certificate/cv/finised > message to be sent, so it can do something special in application > layer immediately after that. Sure. The usual async API guarantees apply here; I don't know that this needs special treatment in the spec though. If you disagree, I'm sure that my coauthors would be happy to take suggestions for improvements. From nobody Mon Aug 8 01:17:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79DD12D501 for ; Mon, 8 Aug 2016 01:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIP9fA_G2l9G for ; Mon, 8 Aug 2016 01:17: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 4DC24128874 for ; Mon, 8 Aug 2016 01:17:43 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B04A9C05681D for ; Mon, 8 Aug 2016 08:17:42 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.68]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u788Helh015652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 8 Aug 2016 04:17:42 -0400 Message-ID: <1470644260.3026.13.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Mon, 08 Aug 2016 10:17:40 +0200 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 08 Aug 2016 08:17:42 +0000 (UTC) Archived-At: Subject: [TLS] TLS1.3 + PSK with multiple identities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 08:17:45 -0000 Hello,  I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3 draft [0], and I noticed quite some deviations (IMO) from typical TLS protocol behavior. No rationale is given about them so I ask on list. To summarize, the client sends a list of identitities and the server replies with an index indicating which identity is approved. 1. The server reply with an index is unique in TLS. It is not used in ciphersuite selection or in any other negotiation in TLS where the client sends multiple options. Why not have the server reply with the selected username. 2. Why does the client send multiple identities? In TLS-SRP a single identity is sent, and the same in the existing TLS-PSK rfc. How is this envisioned to be used? A client sends: I'm probably one of Bob, Nikos, George, take a look on that list and tell me who I really am? In that case why not allow the server, to reply with a username outside that list (i.e., assign a new one to be used at the next session - see point 1). 3. The maximum size of the username is 2^16. Isn't that excessive for a user name or a user identifier? Why not set 2^8? That would fit a uuid or anything similarly large. regards, Nikos [0]. https://tlswg.github.io/tls13-spec/#rfc.section.4.2.5 From nobody Mon Aug 8 01:28:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854F312D77A for ; Mon, 8 Aug 2016 01:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zBrHKp0Kzen for ; Mon, 8 Aug 2016 01:28:45 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8540012B053 for ; Mon, 8 Aug 2016 01:28:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 1450E10A26; Mon, 8 Aug 2016 11:28:44 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Attv5nGaKM_8; Mon, 8 Aug 2016 11:28:43 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D706A27F; Mon, 8 Aug 2016 11:28:43 +0300 (EEST) Date: Mon, 8 Aug 2016 11:28:37 +0300 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> References: <1470644260.3026.13.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1470644260.3026.13.camel@redhat.com> User-Agent: Mutt/1.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 + PSK with multiple identities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 08:28:48 -0000 On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos wrote: > Hello, >  I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3 > draft [0], and I noticed quite some deviations (IMO) from typical TLS > protocol behavior. No rationale is given about them so I ask on list. > > To summarize, the client sends a list of identitities and the server > replies with an index indicating which identity is approved. > > 1. The server reply with an index is unique in TLS. It is not used in > ciphersuite selection or in any other negotiation in TLS where the > client sends multiple options. Why not have the server reply with the > selected username. More compact and makes the option where server sends some bad option more clear. > 2. Why does the client send multiple identities? In TLS-SRP a single > identity is sent, and the same in the existing TLS-PSK rfc. How is this > envisioned to be used? A client sends: I'm probably one of Bob, Nikos, > George, take a look on that list and tell me who I really am? In that > case why not allow the server, to reply with a username outside that > list (i.e., assign a new one to be used at the next session - see point > 1). You already need multiple if you try to "resume"[1] DHE-PSK session (since "resumption" shares the PSK space). Additionally, TLS 1.2 had identity hint, but TLS 1.3 eliminates that due to flight limits. > 3. The maximum size of the username is 2^16. Isn't that excessive for a > user name or a user identifier? Why not set 2^8? That would fit a uuid > or anything similarly large. If one wants to do the equivalent of tickets in TLS 1.2, one needs pretty large usernames. [1] IMO, TLS 1.3 does not have session resumption (doesn't stop others from calling the relevant features "resumption"). -Ilari From nobody Mon Aug 8 02:20:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3EF12D150 for ; Mon, 8 Aug 2016 02:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBDjiVeW6-Vj for ; Mon, 8 Aug 2016 02:20:45 -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 C7519127071 for ; Mon, 8 Aug 2016 02:20:45 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 101744E328; Mon, 8 Aug 2016 09:20:45 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.68]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u789KgTn019873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Aug 2016 05:20:44 -0400 Message-ID: <1470648042.3026.44.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Ilari Liusvaara Date: Mon, 08 Aug 2016 11:20:42 +0200 In-Reply-To: <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 08 Aug 2016 09:20:45 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 + PSK with multiple identities X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 09:20:47 -0000 On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote: > On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos > wrote: > > > > Hello, > >  I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3 > > draft [0], and I noticed quite some deviations (IMO) from typical > > TLS > > protocol behavior. No rationale is given about them so I ask on > > list. > > > > To summarize, the client sends a list of identitities and the > > server > > replies with an index indicating which identity is approved. > > > > 1. The server reply with an index is unique in TLS. It is not used > > in > > ciphersuite selection or in any other negotiation in TLS where the > > client sends multiple options. Why not have the server reply with > > the > > selected username. > > More compact and makes the option where server sends some bad option > more clear. I'm not sure about being more clear. What I immediately notice is that it requires the client to remember not only the values that it sent, but also the indexes. I guess that's no big deal, but it is used nowhere else in TLS. > > 2. Why does the client send multiple identities? In TLS-SRP a > > single > > identity is sent, and the same in the existing TLS-PSK rfc. How is > > this > > envisioned to be used? A client sends: I'm probably one of Bob, > > Nikos, > > George, take a look on that list and tell me who I really am? In > > that > > case why not allow the server, to reply with a username outside > > that > > list (i.e., assign a new one to be used at the next session - see > > point > > 1). > You already need multiple if you try to "resume"[1] DHE-PSK session > (since "resumption" shares the PSK space). That's very awkward. That way the protocol mandates code like: if (!id_in_resumption_db()) {     if (!valid_ticket())       if (!try_find_user_in_psk_userfile())         proceed_with_random_psk(); /* hide the fact that username doesn't exist in db */ } which is not really sane code. Not only that, but servers who would like to prevent valid username testing in their PSK key file as above, would be forced to make resumption attempts with unknown or long- expired tickets fail. A protocol must have clarity on the data sent on the wire and their purpose. Cross protocol attacks work by exploiting data which may be interpreted in multiple ways and such generic purpose identifiers seem to be like a good candidate for that. I think at minimum identities known to the protocol (e.g., resumption) should be distinguishable from PSK usernames. The draft leaves that to the server implementor to do, but I do think such identifiers should be tagged at the protocol level since it affects all implementations. > 3. The maximum size of the username is 2^16. Isn't that excessive > > for a > > user name or a user identifier? Why not set 2^8? That would fit a > > uuid > > or anything similarly large. > If one wants to do the equivalent of tickets in TLS 1.2, one needs > pretty large usernames. I find that, as another unfortunate side-effect of combining unrelated protocol fields. regards, Nikos From nobody Mon Aug 8 05:55:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5362A126D74 for ; Mon, 8 Aug 2016 05:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3sd1eOiYGjP for ; Mon, 8 Aug 2016 05:55:18 -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 F27D312B004 for ; Mon, 8 Aug 2016 05:55:17 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3s7HSg2gTgz25P1; Mon, 8 Aug 2016 14:55:15 +0200 (CEST) X-purgate-ID: 152705::1470660915-00007F13-E4040081/0/0 X-purgate-size: 1368 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3s7HSf62YnzkxT4; Mon, 8 Aug 2016 14:55:14 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C83D71A51C; Mon, 8 Aug 2016 14:55:14 +0200 (CEST) In-Reply-To: <20160806235716.726a0e4e@pc1> To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Date: Mon, 8 Aug 2016 14:55:14 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20160808125514.C83D71A51C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 12:55:20 -0000 Hanno B=F6ck wrote: >=20 > Actually there is some info on that in the PSS spec [1]. What I write > here is my limited understanding, but roughly I'd interpret it as this: > It says that if you use a non-random salt the security gets reduced to > the security of full domain hashing, which was kinda the predecessor of > PSS. > I'd conclude from that that even in a situation where the salt > generation is a non-random value nothing really bad happens. The > security of a PSS scheme without randomness is still better than that > of a PKCS #1 1.5 signature. The urban myth about the advantages of the RSA-PSS signature scheme over PKCS#1 v1.5 keep coming up. It has been mentioned here before: Fedor Brunner wrote on 4 Mar 2016 17:45:19: >=20 > Please see the paper "Another Look at ``Provable Security''" from Neal > Koblitz and Alfred Menezes. >=20 > https://eprint.iacr.org/2004/152 >=20 > Section 7: Conclusion >=20 > "There is no need for the PSS or Katz-Wang versions of RSA; > one might as well use just the basic ?hash and exponentiate? signature > scheme (with a full-domain hash function)." The advantages of the RSA-PSS signature scheme are limited to situations where the rightful owner of the private signing key is not supposed to have access to the bits of the private key (i.e. key kept in hardware). -Martin From nobody Mon Aug 8 07:52:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE5112D5EC for ; Mon, 8 Aug 2016 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFapMOgRpEFp for ; Mon, 8 Aug 2016 07:52:07 -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 7F21212D60D for ; Mon, 8 Aug 2016 07:52:07 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4181F83F47; Mon, 8 Aug 2016 14:41:39 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.68]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u78Efbh7009168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Aug 2016 10:41:38 -0400 Message-ID: <1470667296.3026.72.camel@redhat.com> From: Nikos Mavrogiannopoulos To: mrex@sap.com Date: Mon, 08 Aug 2016 16:41:36 +0200 In-Reply-To: <20160808125514.C83D71A51C@ld9781.wdf.sap.corp> References: <20160808125514.C83D71A51C@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 08 Aug 2016 14:41:39 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Aug 2016 14:52:09 -0000 On Mon, 2016-08-08 at 14:55 +0200, Martin Rex wrote: > > Please see the paper "Another Look at ``Provable Security''" from > > Neal > > Koblitz and Alfred Menezes. > > > > https://eprint.iacr.org/2004/152 > > > > Section 7: Conclusion > > > > "There is no need for the PSS or Katz-Wang versions of RSA; > > one might as well use just the basic ?hash and exponentiate? > > signature > > scheme (with a full-domain hash function)." > The advantages of the RSA-PSS signature scheme are limited to > situations > where the rightful owner of the private signing key is not supposed > to have access to the bits of the private key (i.e. key kept in > hardware). Is that limited, so limited today? Aren't we at a time where the majority of servers will use an HSM (either real hardware or virtualized)? regards, Nikos From nobody Mon Aug 8 07:53:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE4512D5EC for ; Mon, 8 Aug 2016 07:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L15NrGrjZhm for ; Mon, 8 Aug 2016 07:53:11 -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 BF28A128E19 for ; Mon, 8 Aug 2016 07:53:11 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5B11D3F400B; Mon, 8 Aug 2016 14:53:11 +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 44F873F4008; Mon, 8 Aug 2016 14:53:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470667991; bh=aFvv6JsUxKGejxAXp3ubjd8mr6bAERDvsVOdTzlA0+E=; l=215; h=From:To:CC:Date:References:In-Reply-To:From; b=jPSiOAUhvhr0n1O3ZqG0KbMggAXS+iyttdwDnHbm8utYgMYMi7PvX3lsjRy/Q9l8l 1cKDgCM/PM4DCi8N4exBfq1pA3lIqdn82kOSx0ui1uxA3Yjlee+x+dnUvAOUY1wi9J UjaqM0mEheJjjIipn3gmT0fEnupknoliUrh9Tchg= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 42B991FC8E; Mon, 8 Aug 2016 14:53:11 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 10:53:10 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 8 Aug 2016 10:53:10 -0400 From: "Salz, Rich" To: Nikos Mavrogiannopoulos , "mrex@sap.com" Thread-Topic: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA Thread-Index: AQHR8GgMDDXIW77t1E+k6ZItFYtYx6A9VBsAgAH2WACAAB24AP//wAgA Date: Mon, 8 Aug 2016 14:53:09 +0000 Message-ID: References: <20160808125514.C83D71A51C@ld9781.wdf.sap.corp> <1470667296.3026.72.camel@redhat.com> In-Reply-To: <1470667296.3026.72.camel@redhat.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.38.87] 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] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Aug 2016 14:53:13 -0000 =20 > Is that limited, so limited today? Aren't we at a time where the majority= of > servers will use an HSM (either real hardware or virtualized)? Without even defining "virtualized HSM" the answer is no. From nobody Mon Aug 8 12:54:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01BE12B02C for ; Mon, 8 Aug 2016 12:54:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_9atojWGCYK for ; Mon, 8 Aug 2016 12:54:32 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B0312B02B for ; Mon, 8 Aug 2016 12:54:32 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id f6so92343375ith.0 for ; Mon, 08 Aug 2016 12:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KtMhGgE4nk5L5l3BBR7Y0m2Vh9T21oryy+keBRdRF0c=; b=Ct/5S7b+TpRkJcJNRoUlXpfBjL1EPjrLLN4PHrjz270tWY0QfU+t5d5OXB7O+2pYV4 eccpKmyC18KEzBCkx7F+DywDcleR6QsvuipoLQ1xJtdtrm2h9VdK88N9ET9ranbowQ39 3CwilJzisv69PZVIwcpQMuQ8u6ZHVbux+gPQL/9g0BekJk0SVR+1FTSOBVybi8wbDWei CNsvs9qCHkHiNwYotdGHDh39nPoOVfF57KGSDOYyN8UNcC3AAVj1M0eO+CxDZ2kjdmf+ 4LnvjH9+71w/4nGNxkQcdreF289yB7WMcHCXIlDWYTWLJjhsNA+BCv9q7CHjKyZSbMp/ /cdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KtMhGgE4nk5L5l3BBR7Y0m2Vh9T21oryy+keBRdRF0c=; b=Qka+pCnB/ddaqy+fZNo5EXDga8lBJBHdb+b4kD+qbwE0yrMth6adttonKBaCdVcGIL bJYXOFU1kSwHfP5sdzfUhzr3coX8Rl4x7RTtpb+q4FOHdU7tgl/auGnsRojX7De/Jr4O SBAAPTddc2d5VK73RmfFBD1GUQZMNN14HwLOGn0TAR81JkBCHXlGqgK+RlIZVCweD1v8 Dslmm3/x6mf2xvlBExVM+cy+gsxyQ29OhciCVLHV87k1e6IE7nwajaA4fn+u/sj1c0ER +8aGIDXZaE/ZwNLGMfIexyQKpouTCkC4Aq4pkU0plFPu0XaIvDFtuPxzRmNp1ZW9HdgI LX4Q== X-Gm-Message-State: AEkoouuvDWtOpwEDdLH9K8EJpBcNg97OW3pOp2iAY6mh9x7e4kFvqbhTv7O38TKuP7QB2lHDDICndePA1MxQ4A== X-Received: by 10.36.31.18 with SMTP id d18mr21115975itd.64.1470686071228; Mon, 08 Aug 2016 12:54:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.74.73 with HTTP; Mon, 8 Aug 2016 12:54:30 -0700 (PDT) In-Reply-To: <20160808125514.C83D71A51C@ld9781.wdf.sap.corp> References: <20160806235716.726a0e4e@pc1> <20160808125514.C83D71A51C@ld9781.wdf.sap.corp> From: Brian Smith Date: Mon, 8 Aug 2016 09:54:30 -1000 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Aug 2016 19:54:37 -0000 Martin Rex wrote: > The urban myth about the advantages of the RSA-PSS signature scheme > over PKCS#1 v1.5 keep coming up. PKCS#1 v1.5 is a partial-domain scheme, not a full-domain scheme. So, RSA-PSS (without a salt, or with a fixed salt) might still have an advantage over PKCS#1 v1.5 because it is a full-domain scheme. > The advantages of the RSA-PSS signature scheme are limited to situations > where the rightful owner of the private signing key is not supposed > to have access to the bits of the private key (i.e. key kept in hardware). RSA-PSS is the only (IETF) (proposed) standard for full-domain hashing we have for RSA, AFAIK. This is why I think it might still make sense to use it, in a deterministic fashion. Cheers, Brian -- https://briansmith.org/ From nobody Mon Aug 8 13:21:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E759712D09C for ; Mon, 8 Aug 2016 13:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41lE55Gyr06l for ; Mon, 8 Aug 2016 13:21:34 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 99D9112B078 for ; Mon, 8 Aug 2016 13:21:34 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 74so86232044uau.0 for ; Mon, 08 Aug 2016 13: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:from:date:message-id:subject:to :cc; bh=JgS4hBEtPebF5Abv7EB2sUA9FxXD5yqpao0kIyk2znw=; b=UCoMiHEywaQhIMEuA/F+Kx365+Eg15hjRQWn+wpLWUVbgcXzixpQYRd0VsX1E6FfuC xWJouCK/Xi1j0bQr3mvdaqCTVy6ktemhAG4Rr6xZTBOy1TYD6oG5OGhYhs7k8X1HZHGi 8KtU6MrWiz12Z192CQChYqGRgj+gqa8u4TTxC6EjJ6vXaTYSSigzI33lBZynvDEE4tUX QRhafyDk/shsUsq57TbpJWgHT0cMQPMf32xjtOqTuI1pWvN6nMDT9qZAwV7YuzJJWDbK L6zIsgYPiTiLVSXoKpCNj8R/N9OZDHMjpkolqOQ7sg6o2VFAuUKQ5nWEiLE+knGFyQhr hRZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JgS4hBEtPebF5Abv7EB2sUA9FxXD5yqpao0kIyk2znw=; b=K/VNLGTizdrTsBeL46bZfIAci3rnwy0l9sFj/Oe3tXSqZ2SUrKJm0R7zlOvMYyTaRF 0YZ8Igtf+E6Iv4BXcEupPb2Z+wK06MW5mJrN6MUZ6J+c7pUt3LDuncUwlJnIIwICHVKL D9vSgbolRvSaVnG7kpAGL+uKKkkfETJ/cAVKideR9APeUGpIlW5PrfRqkac9SETp+gqY NVjsSulC+vm95YJkfZmnMi4OmNayagb4SE3pv8rSdjqzw3B70H0I8bZMnGUqOkVh0VGX maD9YWoxwgI57J7nhW87cQ+giH9xBoBgl4hE1p/U8M2+l1vyDHSbyO9TtQwoHC9nPShf LknA== X-Gm-Message-State: AEkooutKma94NOf3nHcYcDb6v5fyu7BpZ+uzK6Vba6PZkKAlwkVCKBpq3RZgGhNFaoijC+6D7Naio4b2j29qaw== X-Received: by 10.176.2.242 with SMTP id 105mr15404681uah.10.1470687693809; Mon, 08 Aug 2016 13:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Mon, 8 Aug 2016 13:21:13 -0700 (PDT) In-Reply-To: <20160808125514.C83D71A51C@ld9781.wdf.sap.corp> References: <20160806235716.726a0e4e@pc1> <20160808125514.C83D71A51C@ld9781.wdf.sap.corp> From: Tony Arcieri Date: Mon, 8 Aug 2016 13:21:13 -0700 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=001a1142e55090aef20539952988 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Aug 2016 20:21:36 -0000 --001a1142e55090aef20539952988 Content-Type: text/plain; charset=UTF-8 On Monday, August 8, 2016, Martin Rex wrote: > > The urban myth about the advantages of the RSA-PSS signature scheme > over PKCS#1 v1.5 keep coming up. > Do you think we'll see real-world MitM attacks against RSA-PSS in TLS similar to those we've seen with PKCS#1v1.5 signature forgery, such as BERserk? --001a1142e55090aef20539952988 Content-Type: text/html; charset=UTF-8
On Monday, August 8, 2016, Martin Rex <mrex@sap.com> wrote:
The urban myth about the advantages of the RSA-PSS signature scheme
over PKCS#1 v1.5 keep coming up.

Do you think we'll see real-world MitM attacks against RSA-PSS in TLS similar to those we've seen with PKCS#1v1.5 signature forgery, such as BERserk?
--001a1142e55090aef20539952988-- From nobody Tue Aug 9 01:55:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A512D54F for ; Tue, 9 Aug 2016 01:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APhWSf3g41YN for ; Tue, 9 Aug 2016 01:55:39 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FB012D53D for ; Tue, 9 Aug 2016 01:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1470732939; x=1502268939; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EnpaDKHurbWh3ZRawCaLlRqOgsP8IkBuWYjWaJMt0rA=; b=SS8dg+WGXJk13Ccg2PiYUyzgHe9p2aQosl/Gdf/rqlwVwOcdNM+dzRoV e0m9eZXyF3uFoBCc3r1Yr6xOy0jP1FXgx2w8HWuLDboiguU4ht2cqh4U6 YIkWUUCXYSXR0Pj61nhPS0F/WhAuiv/1EnrRaCoyWMuupcXjrfR6J8FIG OAfiZLzp/FX5TbvsNAN1jsL0NICTtpUvktcu06XOohtSmJVEtil7LbAPF zF6IP8OhuBH7AFRdilMvFwrz5ckC/7N/NEI+1BCe88wCCYXJbsZ6NCVyA avj6LTRC5RUcCxxDJySq0QGVETmfm4f3TocKdiqmLCJ89tsk3GkNXSKRk g==; X-IronPort-AV: E=Sophos;i="5.28,494,1464609600"; d="scan'208";a="101629948" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Aug 2016 20:55:31 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 9 Aug 2016 20:55:31 +1200 From: Peter Gutmann To: Tony Arcieri , "mrex@sap.com" Thread-Topic: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA Thread-Index: AQHR8Gfj7F33ORxaEkOd+LaMKFmFkqA8R+IAgAH2WQCAAHybgIABm9Tz Date: Tue, 9 Aug 2016 08:55:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CE4907@uxcn10-5.UoA.auckland.ac.nz> References: <20160806235716.726a0e4e@pc1> <20160808125514.C83D71A51C@ld9781.wdf.sap.corp>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Aug 2016 08:55:42 -0000 Tony Arcieri writes:=0A= =0A= >Do you think we'll see real-world MitM attacks against RSA-PSS in TLS simi= lar=0A= >to those we've seen with PKCS#1v1.5 signature forgery, such as BERserk?=0A= =0A= Not BERserk specifically because that was an attack on the ASN.1, not the= =0A= signature format. OTOH PSS doesn't encode the hash algorithm as 1.5 does, = so=0A= here's a much simpler attack: Take a breakable hash function with an output= =0A= the same size as the one used in the sig, generate your collision, and past= e=0A= the sig onto colliding data, indicating the use of the breakable function n= ot=0A= the one used to generate the original sig. Done. Couldn't happen with 1.5= =0A= because that encodes the details of the hash function used as part of the= =0A= signature.=0A= =0A= Peter.= From nobody Tue Aug 9 07:16:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C8212D885 for ; Tue, 9 Aug 2016 07:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oAq9YyrKVoU for ; Tue, 9 Aug 2016 07:16:18 -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 E69FB12D88A for ; Tue, 9 Aug 2016 07:16:17 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3s7xCg601vz1HjV; Tue, 9 Aug 2016 16:16:15 +0200 (CEST) X-purgate-ID: 152705::1470752175-000007FB-DB3AB78F/0/0 X-purgate-size: 483 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3s7xCg2vFHzkwld; Tue, 9 Aug 2016 16:16:15 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5E17B1A520; Tue, 9 Aug 2016 16:16:15 +0200 (CEST) In-Reply-To: To: Tony Arcieri Date: Tue, 9 Aug 2016 16:16:15 +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: <20160809141615.5E17B1A520@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 14:16:20 -0000 Tony Arcieri wrote: [ Charset UTF-8 unsupported, converting... ] > On Monday, August 8, 2016, Martin Rex wrote: > > > > The urban myth about the advantages of the RSA-PSS signature scheme > > over PKCS#1 v1.5 keep coming up. > > Do you think we'll see real-world MitM attacks against RSA-PSS in TLS > similar to those we've seen with PKCS#1v1.5 signature forgery, such as > BERserk? BERserk is an implementation defect, not a crypto weakness. -Martin From nobody Tue Aug 9 11:45:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A712D50C for ; Tue, 9 Aug 2016 11:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCxIa0PSajBf for ; Tue, 9 Aug 2016 11:45:07 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D1F12D0F7 for ; Tue, 9 Aug 2016 11:45:07 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id x25so10107656qtx.2 for ; Tue, 09 Aug 2016 11:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=gQxoIFaikIPQHgp8eBIb/NCBCDY30ZbOj3604i26xYY=; b=eVvJbaj+4DFRqV8RfvEqo9F6PH8H68B+CjiVC7FmJQ1f5IOthVW3RY5Yd1Xm9F2Dh/ AzPS9d5VMaeiF6O3XLZbep4Se7yofEe7GNVO2F2Btu9Al8A4ZCB/0WvGf1JRYVP/mvRR 0/5KyWjzNt1Xe0hMWXI6ESIIssdFtA27aoY/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=gQxoIFaikIPQHgp8eBIb/NCBCDY30ZbOj3604i26xYY=; b=LsxnCLmqexP+bAFJuWWNlAnpmnPMnIoamNLVJCGrhZfBb1hkn2h8l7Rsy1D0wziNqp UaO3e1I2408i+qf0ZC/OnQae2B/Piie7ReXQpYXOAudhz0L7o/Ub7EyUcYAxJxpOcb73 uCglRoIdy4sy1965KU6eM9SuYICM6gTwMYjNF9shi9HKj8x2iUauZVaVrBj4NiGzKi7K wP0HFgFSdDpiNBXcHJU8fY2P7EOETezRZzdMlYpRw817NP/azT+yJCqh/DNXjKux0b0w vRVqNpCm7fZ8fZQ/xU/GitAl3GSJPpaN6FRwvHkdFeDfVpHZ73aleeE2qn37h3reKN8/ P9GA== X-Gm-Message-State: AEkoouucIU/ZhiWeM5dXwynVTjgRSa9N3SmPp7e070Bemn5GpSAv7Rn0P0qKH5pCD7DRxA== X-Received: by 10.200.49.129 with SMTP id h1mr36372378qte.103.1470768306785; Tue, 09 Aug 2016 11:45:06 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id y67sm21082104qka.45.2016.08.09.11.45.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Aug 2016 11:45:06 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> Date: Tue, 9 Aug 2016 14:45:05 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 18:45:09 -0000 All, We've received a request for early IANA assignments for the 6 cipher = suites listed in = https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/. Please = respond before August 23rd if you have concerns about early code point = assignment for these cipher suites.=20 J&S= From nobody Tue Aug 9 14:13:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0295012D185 for ; Tue, 9 Aug 2016 14:13: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f45KipqJlyso for ; Tue, 9 Aug 2016 14:13:47 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 32E8212D15A for ; Tue, 9 Aug 2016 14:13:47 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 74so40307350uau.0 for ; Tue, 09 Aug 2016 14:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T+JWjMW21NElWxm1lK11vZ3m7NtVmVlvIX7oC7fm7jg=; b=PBJRJvNdTeolfh4+DqnPZv9Kbn8OjspxrmjhNUlNfqwi90cc8HeVYq1XRsfRbyxEzD AQ0zTiTgZpB5oEIn9vIJIJ+mgaqmj7ZZBTljG8rez3sOrbayEBJJNgUueBgDzDwBIKKW k9OuNOYsL+BZCJiv1TsoMLue2fBIT13qiZ5CQ8iVwKVQ4g/jukXJfj4y6549yMCKtalU pGul78FcWFxJdGKZNzefGEYExRt7amqXCl1yCziW7yfcaIkuCwEYm2Cw5s9jcmHNWpg4 MTCuBrwm4ydWDzG5dsadjUIzIgOHZyo3rlcPyEIJ8bRZtHizPewx62xcQ4PHctFeJsqk hBwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T+JWjMW21NElWxm1lK11vZ3m7NtVmVlvIX7oC7fm7jg=; b=kQUabjdjrcg6O3mqm0PZMEB6pDtdCWkihZY2cugLeXj2KgVxP2yoH68093FaCUE9/v eQSRR/ahdhlL6BtTXszlN2w73R1SSoCu3ELR4mcb9qQEZIOOvaXYsb5QrWjJdeuJvJmY c9LKZlJi+lhxgQx4GYH+HvgUAxiCvP9FPYghFdzTf3FWIGP+FgZyLWeK+QJL29Rhuqfk VhIXnTmhex7XjYTJA9Netdg7jivKHJPasCn921dVR4cBEmYRxlMojEvYFbxSBcD56oNN 6S0au70noAObeSgy7XhR+WMyMgDQLqY+06E+3JpXxFexwUMNHOabTYKvOorhB4n4CciJ Fm9w== X-Gm-Message-State: AEkoousyBTF7XLPqWxsQdNZkIABcsZcBd3R+qmAVs7MS0LyEJ/HJ9dNPt7Rsf+aOdtDvpj4GjKcFXxgpSt34yA== X-Received: by 10.176.7.34 with SMTP id h31mr240004uah.127.1470777226304; Tue, 09 Aug 2016 14:13:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Tue, 9 Aug 2016 14:13:25 -0700 (PDT) In-Reply-To: <20160809141615.5E17B1A520@ld9781.wdf.sap.corp> References: <20160809141615.5E17B1A520@ld9781.wdf.sap.corp> From: Tony Arcieri Date: Tue, 9 Aug 2016 14:13:25 -0700 Message-ID: To: Martin Rex Content-Type: multipart/alternative; boundary=94eb2c1244d21e25c00539aa0260 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Aug 2016 21:13:49 -0000 --94eb2c1244d21e25c00539aa0260 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 9, 2016 at 7:16 AM, Martin Rex wrote: > BERserk is an implementation defect, not a crypto weakness. > Hence why I phrased the question the way I did. Per Izu, Shimoyama, and Takenaka 2006, PKCS#1 v1.5 has sharp edges which implementers must avoid (of course, the same can be said of BER in BERserk, and it was clearly the bigger of the two problems). Peter Gutmann's response was the sort of thing I was looking for when I originally asked the question. -- Tony Arcieri --94eb2c1244d21e25c00539aa0260 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 9, 2016 at 7:16 AM, Martin Rex <mrex@sap.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
= BERserk is an implementation defect, not a crypto weakness.

Hence why I phrased the question the wa= y I did.=C2=A0Per Izu, Shimoyama, and Takenaka 2006, PKCS#1 v1.5 has sharp = edges which implementers must avoid (of course, the same can be said of BER= in BERserk, and it was clearly the bigger of the two problems).

Peter Gutmann's response was the = sort of thing I was looking for when I originally asked the question.

--
Tony Arcieri
--94eb2c1244d21e25c00539aa0260-- From nobody Tue Aug 9 16:10:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9027712D85F for ; Tue, 9 Aug 2016 16:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3fmD7qiarWo for ; Tue, 9 Aug 2016 16:10:50 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 F286A12D8AD for ; Tue, 9 Aug 2016 16:10:49 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id n59so42928366uan.2 for ; Tue, 09 Aug 2016 16: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:from:date:message-id:subject:to :cc; bh=73x+tQzTV4u9mxsru0ol0m5IVs9o/NxYZcuWrEJZ4co=; b=BF8BvfXv7H6RzeJC1I2SnMar0td6VhN5UlT+qJisI91hJHg1qGUoMFvqAb42HTaw2/ MBnQMK2bjLqH7B0JQ74veqbcrPJtcZ5Fuecr0ay1OTua1ZrffviydxgCDI1rV8iCwihl VgvsF3kcvDk/ARy6OyFOEIPvIs8iRsTmSFyqBQiLgESb20g5mnlzcW9kM5bgg/jWYMgd gYUu6C4gxbAs2FEmoPBF2CQQPlaungxj+E2uV99BZZXZ76W5IS0vV5pkFSaD3Ntk7Y/F p/49LRr6SYyt7gZTNVzXwAQlNGJu+ImpJ7PISzdblHXap/AsXVqx0wJrdRI4ffVCjshp GdFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=73x+tQzTV4u9mxsru0ol0m5IVs9o/NxYZcuWrEJZ4co=; b=PpBbwu57yxRPiu1dAtQ3Q/1EEIkIqLdBtajwyoOw6AFmhnwgK85F3aRzXunE2q5THO UtggUac3XJdKCqnMEp7WGPGBVTn+rCQ8c3iNEPcJZLwRpxFyrEiaEHPg/opougoeqj00 1GjBcFVB8zyMVV2XbRLb03oxIEokL6lJfRdq3+dfENknmhZaC4q9ae40U0YBtnfWXhBd DH39iMgESS7kjvZ34JK7xmJNm/P2mYarbrnvMlGj/WPr/QBnBipBOSIO7rw/fgrhF9W7 muG9XVxMFx4JfrGcZOaVeXQ/KhPrlUrKJjKIvY+9+L3vbJC5LPLjYlctJvqKwbJB0++D aUpg== X-Gm-Message-State: AEkoouu8bwTIDOPKTxPIqXUw3EWmnl/NHBF80Wh5Im94E07Kfk9anFUNBGsbYdARzo2BGIZ4JlKbSsSsWKJnsA== X-Received: by 10.176.81.17 with SMTP id e17mr478809uaa.141.1470784249045; Tue, 09 Aug 2016 16:10:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Tue, 9 Aug 2016 16:10:28 -0700 (PDT) In-Reply-To: References: <20160809141615.5E17B1A520@ld9781.wdf.sap.corp> From: Tony Arcieri Date: Tue, 9 Aug 2016 16:10:28 -0700 Message-ID: To: Martin Rex Content-Type: multipart/alternative; boundary=94eb2c19172cb4a61d0539aba470 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Aug 2016 23:10:51 -0000 --94eb2c19172cb4a61d0539aba470 Content-Type: text/plain; charset=UTF-8 It's also worth noting that BERserk is one of many such incidents of this coming up in practice: https://cryptosense.com/why-pkcs1v1-5-signature-should-also-be-put-out-of-our-misery/ On Tue, Aug 9, 2016 at 2:13 PM, Tony Arcieri wrote: > On Tue, Aug 9, 2016 at 7:16 AM, Martin Rex wrote: > >> BERserk is an implementation defect, not a crypto weakness. >> > > Hence why I phrased the question the way I did. Per Izu, Shimoyama, and > Takenaka 2006, PKCS#1 v1.5 has sharp edges which implementers must avoid > (of course, the same can be said of BER in BERserk, and it was clearly the > bigger of the two problems). > > Peter Gutmann's response was the sort of thing I was looking for when I > originally asked the question. > > -- > Tony Arcieri > -- Tony Arcieri --94eb2c19172cb4a61d0539aba470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's also worth noting that BERserk is one of many suc= h incidents of this coming up in practice:=C2=A0http= s://cryptosense.com/why-pkcs1v1-5-signature-should-also-be-put-out-of-our-m= isery/

O= n Tue, Aug 9, 2016 at 2:13 PM, Tony Arcieri <bascule@gmail.com> wrote:
On Tue, Aug 9,= 2016 at 7:16 AM, Martin Rex <mrex@sap.com> wrote:
BERserk is an implement= ation defect, not a crypto weakness.
Hence why I phrased the question the way I did.=C2=A0Pe= r Izu, Shimoyama, and Takenaka 2006, PKCS#1 v1.5 has sharp edges which impl= ementers must avoid (of course, the same can be said of BER in BERserk, and= it was clearly the bigger of the two problems).

Peter Gutmann's response was the sort of thing I = was looking for when I originally asked the question.

--
Tony Arcieri



--
Tony Arcieri
--94eb2c19172cb4a61d0539aba470-- From nobody Tue Aug 9 20:42:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC0012D7C2 for ; Tue, 9 Aug 2016 20:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_nBiY0pAkvq for ; Tue, 9 Aug 2016 20:42:36 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06DA12D7B6 for ; Tue, 9 Aug 2016 20:42:31 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id w38so15368601qtb.0 for ; Tue, 09 Aug 2016 20:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0TP0H3dOFjiIzhN6IGPNtemMEsnZiyTJIuhquYAlHy8=; b=OmzgYQRXbLtF1UQVBQoztV8fDrnQa+z83bY191S8BgOvjTdWHevBmGTcdLWeLryIOe QTO/DcnaKzNOLu2VE/PqaOx3PV/tJVVV963NGjQ9USe4l3SLM8/NJ0Jp34nQLP1STAlm 1hYfSflvL0bUgUk6k7n/VQ5BX+vzqeTZOqbF475R/0HlKz/q5Wwqx1IzKHAynIj+iPUr W9Jv919AoUgvg0wjGbILRIzJhVaVSpeNzglcnolky8AI/D4AGpoCePCJoAmyt+DFHLLR WIJHpAbBFNV8CHsXXx6mxL3ynnEg9L0JR6lkSq5yK1p8u6p+AbckOFw4Zb122kV0X1l/ J3Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0TP0H3dOFjiIzhN6IGPNtemMEsnZiyTJIuhquYAlHy8=; b=VM9AfsqysWhSuenfL6SdE5CN0gHV28xTIu1kbPaao/Zv0awYMfD43/NhMuDbgCGo+t FcliTSQkfsVTJX37naL3c88fi61pDzk/zXv0penI71lqDm65i/xgeay8LmRGTVsyimcV SJxUAeZkLLsd0shezNx+fI4ioaBmIaM1AcXSzFsXRnXZ0paHsjevL1tIdvTtbsO2sIXt 9029OEdJjoYSI7/Ouoxu+8E59XhjpHUP7Z80Ynr5/7d0975wIQ4YD8ZqlBd3cxjReklc GxePLrRYxQ6Ic6D2lvVXfBhCUuGt6pLf5fDnPX4dqtuciz1Ch7vCZeQcZC7ZCluLKBCY 7cYA== X-Gm-Message-State: AEkoouu+9zRkcGZl2SgWBaUlhDS7flfqEXwrANtDhzPh9IpcDnJBekdrRvNFmTHOCzIzu2oRqVhjFbNP8JfDew== X-Received: by 10.200.50.199 with SMTP id a7mr1934235qtb.43.1470800551069; Tue, 09 Aug 2016 20:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Tue, 9 Aug 2016 20:42:30 -0700 (PDT) In-Reply-To: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> From: Martin Thomson Date: Wed, 10 Aug 2016 13:42:30 +1000 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 03:42:38 -0000 On 10 August 2016 at 04:45, Sean Turner wrote: > We've received a request for early IANA assignments for the 6 cipher suit= es listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead= /. Please respond before August 23rd if you have concerns about early code= point assignment for these cipher suites. Did that request provide justification? I know that we've done this a fair bit recently, but is there a reason why these can't wait for the docs to at least pass WGLC? From nobody Wed Aug 10 02:33:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFFB12D08D for ; Wed, 10 Aug 2016 02:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMUlkpt_UjlR for ; Wed, 10 Aug 2016 02:33:37 -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 4AD0212D0A3 for ; Wed, 10 Aug 2016 02:33:36 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 12890C04D280; Wed, 10 Aug 2016 09:33:36 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.7]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7A9XXMf025001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Aug 2016 05:33:35 -0400 Message-ID: <1470821613.2539.44.camel@redhat.com> From: Nikos Mavrogiannopoulos To: tls@ietf.org, tls@ietf.org Date: Wed, 10 Aug 2016 11:33:33 +0200 In-Reply-To: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 10 Aug 2016 09:33:36 +0000 (UTC) Archived-At: Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 09:33:39 -0000 On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: > All, > > We've received a request for early IANA assignments for the 6 cipher > suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh > e-psk-aead/.  Please respond before August 23rd if you have concerns > about early code point assignment for these cipher suites.  I have previously raised an issue [0] on these ciphersuites. The same requirement was noted also by Peter Dettman as something special in [1]. However, there has been no reaction from the authors (now in CC). regards, Nikos [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ [1]. https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds From nobody Wed Aug 10 10:57:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877E612D80B for ; Wed, 10 Aug 2016 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjcOgMapaSb3 for ; Wed, 10 Aug 2016 10:57: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 4F0E512B00E for ; Wed, 10 Aug 2016 10:57:08 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3s8f424QZzz1HQ6; Wed, 10 Aug 2016 19:57:06 +0200 (CEST) X-purgate-ID: 152705::1470851826-0000082D-DEA10433/0/0 X-purgate-size: 922 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3s8f421hGczkwMT; Wed, 10 Aug 2016 19:57:06 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3309A1A51F; Wed, 10 Aug 2016 19:57:06 +0200 (CEST) In-Reply-To: To: Tony Arcieri Date: Wed, 10 Aug 2016 19:57: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: <20160810175706.3309A1A51F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 17:57:10 -0000 Tony Arcieri wrote: > > It's also worth noting that BERserk is one of many such incidents of this > coming up in practice: > https://cryptosense.com/why-pkcs1v1-5-signature-should-also-be-put-out-of-our-misery/ With the PKCS#1 v1.5 signature verification operation, as described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) https://tools.ietf.org/html/rfc2437#section-8.1.2 it is *IMPOSSIBLE* to create an implementation with a bug such as BERserk, because there is (on purpose) *NO* ASN.1 decoding step defined for this signature verification. A useful specification that is almost 2 decades old does not protect from clueless implementors, however. Heartbleed is also not part of the underlying specification. Anyhow some very seriously broken code, for a completely useless feature (within TLS, not DTLS), was created and shipped into large parts of the installed base... -Martin From nobody Wed Aug 10 15:05:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E03C12D675; Wed, 10 Aug 2016 15:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu7lbKWJc3yt; Wed, 10 Aug 2016 15:04:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0DC12D0DF; Wed, 10 Aug 2016 15:04:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B1F48B80B40; Wed, 10 Aug 2016 15:04:59 -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: <20160810220459.B1F48B80B40@rfc-editor.org> Date: Wed, 10 Aug 2016 15:04:59 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7918 on Transport Layer Security (TLS) False Start X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 10 Aug 2016 22:05:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7918 Title: Transport Layer Security (TLS) False Start Author: A. Langley, N. Modadugu, B. Moeller Status: Informational Stream: IETF Date: August 2016 Mailbox: agl@google.com, nagendra@cs.stanford.edu, bmoeller@acm.org Pages: 11 Characters: 23825 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-falsestart-02.txt URL: https://www.rfc-editor.org/info/rfc7918 DOI: http://dx.doi.org/10.17487/RFC7918 This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip. This document is a product of the Transport Layer Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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/retrieve/bulk 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 Aug 10 15:05:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55A112D893; Wed, 10 Aug 2016 15:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byGztnQP0Fkv; Wed, 10 Aug 2016 15:05:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A0C12D866; Wed, 10 Aug 2016 15:05:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1554BB80B4A; Wed, 10 Aug 2016 15:05:12 -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: <20160810220512.1554BB80B4A@rfc-editor.org> Date: Wed, 10 Aug 2016 15:05:12 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 22:05:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7919 Title: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Author: D. Gillmor Status: Standards Track Stream: IETF Date: August 2016 Mailbox: dkg@fifthhorseman.net Pages: 29 Characters: 61937 Updates: RFC 2246, RFC 4346, RFC 4492, RFC 5246 I-D Tag: draft-ietf-tls-negotiated-ff-dhe-10.txt URL: https://www.rfc-editor.org/info/rfc7919 DOI: http://dx.doi.org/10.17487/RFC7919 Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492). 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/retrieve/bulk 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 Aug 10 21:37:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9555612D097 for ; Wed, 10 Aug 2016 21:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70gPx0zV3Qo8 for ; Wed, 10 Aug 2016 21:37:35 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBC912B04A for ; Wed, 10 Aug 2016 21:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1470890255; x=1502426255; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/IfHMx0Tc9gSe5ixKCYuq505aaz6jgEE0v37uSTM3IA=; b=TfmL/KER6QlDSoHoN74Z5Qjc3NlJfy1DWiCA3zoZoOMQXdsYgnk8Ryw5 Pjz7TPrhsw1Ndcv7IzYD+y0+YNCUAl80ry9PlQJjxjbPhVTD8YEPJtrhB +1Y0689K2ksYzRMJ2VsiLCrh/QTBwopBOrwJ93WrcSeyuJbTj3LDwdb1Y mkdugm+UxifteZw4U4sVgYI7TuVXbEySu72zoMOKNedSRxY9JGn/IBa60 5xR9wdzhdrTjKz8dnmdS7WAR6DwA+qCDjtRgdw+c4neDljXensytR8+L8 bpj5TGUMKySvJ8BtYgGGgEswPcKPVIN7kzxFsG7FRAGGtnOpgLS9eAfV+ A==; X-IronPort-AV: E=Sophos;i="5.28,503,1464609600"; d="scan'208";a="101876560" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Aug 2016 16:37:33 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Thu, 11 Aug 2016 16:37:33 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Thread-Index: AQHR81Ow8Nhj26F0xEu9pacCGmr1pKBDLMQC Date: Thu, 11 Aug 2016 04:37:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CE982D@uxcn10-5.UoA.auckland.ac.nz> References: <20160810220512.1554BB80B4A@rfc-editor.org> In-Reply-To: <20160810220512.1554BB80B4A@rfc-editor.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 04:37:38 -0000 rfc-editor@rfc-editor.org writes:=0A= =0A= > RFC 7919=0A= >=0A= > Title: Negotiated Finite Field Diffie-Hellman Ephemeral=0A= > Parameters for Transport Layer Security (TLS)=0A= =0A= Does anyone have a test server running that implements this? Since I menti= on=0A= it in TLS-LTS, I'd like to do some interop testing on it to see if there's= =0A= anything that needs to be mentioned in -LTS.=0A= =0A= Peter.=0A= From nobody Thu Aug 11 01:39:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128B212B031 for ; Thu, 11 Aug 2016 01:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbWLGAhtmunr for ; Thu, 11 Aug 2016 01:39:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F5F12B026 for ; Thu, 11 Aug 2016 01:39:16 -0700 (PDT) Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LZynd-1amqB40oaj-00llZQ for ; Thu, 11 Aug 2016 10:39:15 +0200 To: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 11 Aug 2016 10:39:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bubpu9M6NEFIi1wLR5hf3hIIkHqccRdGH" X-Provags-ID: V03:K0:dGhT88/1ZK3vFDgLxhu9dUOqk8VjeR1/V6RG5z5HdZJ6Ue59ldH Pth8hhGTchZQ7b9/ZUmKe6udI6e3KT3+/H9ZCfHy0nU8sTnRCWp66EC2vshASoTrhENDCe5 1LO93cu7VI74ugqVenhZHuuGykA/bo82guUXFuWgibxw8Imuz9iK8bDZTdjb9DLcFfM0BGY nFC1aE1/7G/IpleVGFDjQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ax0kp5nZmhI=:2Q8ZYDlE/mcMNDZfcPMYl7 kc6s3+DUVB3td/N7MJK0JIsE4ucx7ED5jnGvcLV/+ReTSgYONHtrEIyOhcuLKb5P9DIEK6AAv t7jB7+PRtYdNc7d368M2Goe3HtsfL8xrfXeyU+6EkZr/taL1s6/Cb0AcnpYP1k0WrVivLaD5u JsemiRwLJ72B3SJh50E1dX5oRJx0UFIVdjditKWgjABZuSTI/cj6nljg0MdzBJ1sCbS9QM4L8 9oqZnkW1COE3CqYhGwfHv3LmWbPqZMwyrYMAXHDkqJHKrnpecJ7boZhrDBcp4/3qk2H34pwbf RKlvbON6evL4QzOVBh9wF0hOMevikelAjCJESmh5HwgI+VDejRNb7SYZ+ggm+CQMtg7HXlxJi nyCk6fDyDZoMO8TI+Yb0N5vP8EHPA3/xCPS9jUGe79jlHjVF7Xo9U2TYGKdx2I/6gJRuAe4CK HIQ0B53y4EjlUl5JtZV8swbhZzPu45Y+Ebt8E3yo137cfsnTA5j51riHsNTKmh14iLQQ5nTR7 VzBA7Xkh9hpQplEfPc6UcS81blj1VUreTqypzHaB6SbW1HVBT/6ePcy3IqWota9wX7G6+lI4L uuggp4+X45PX3lNnzn2qZDiMQwVZLRpwTrtct6YXdaJC64uXuH8w49vb2yUdqnMKMM6sUINC0 E1fiNuNnm2UxpWt19ubOMoWDorPN9ZD1dfge6ON8OSHyV80SpkCaLDEdb7zzV5BUyoHZxjQVW QWqRBGmXlIKg4NLMA03eLYyunwt96itUZq2VnOBzxpMLXNrlFsTz0fsQUfY= Archived-At: Subject: [TLS] Pre_shared_key Extension Question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 08:39:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bubpu9M6NEFIi1wLR5hf3hIIkHqccRdGH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, the currently defined =E2=80=9Cpre_shared_key=E2=80=9D extension allows c= lients to send a list of the identities. I was wondering in what use cases this is useful and what policy guides the server to pick the most appropriate psk identity. I couldn't find any discussion in the document about this aspect. Ciao Hannes --bubpu9M6NEFIi1wLR5hf3hIIkHqccRdGH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXrDmzAAoJEGhJURNOOiAtbCwIAKCnETh+Urrc/fSRhJThJlux jMkJ51dWdwUP0tD7r47AFwZdS+mcTEc0HHY2HdbtddpviNXn/s12RISajjl0VRpo KtHuVyE95Vj0gVbXg2tp7x21wvSbBC/tXtHcfaYxwyxW1d3uvKH4UfbZlayhU2Xw 3zQhdY3FaFGDEou+ym2OQJt9JJ8vycp4nEA5j0R1XPDRWNAyoNSJv0jAQ1ywvawE WfnHCp3pcyJ9dgtSzqYHTG4L02UYicGW8/7V0N32YpA/aWmkGi6GkRH8zmt1+OeU k/BMUsWUOq4j0g1/DbL33DOmk6sEmMoGwFeLfv9gWxQHD3TxeB7ZicE6JJcbG0M= =iEH8 -----END PGP SIGNATURE----- --bubpu9M6NEFIi1wLR5hf3hIIkHqccRdGH-- From nobody Thu Aug 11 11:56:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C11712D842 for ; Thu, 11 Aug 2016 11:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbGqLEHf9MP6 for ; Thu, 11 Aug 2016 11:56:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEFB12D8EB for ; Thu, 11 Aug 2016 11:56:30 -0700 (PDT) Received: from [192.168.10.131] ([195.149.223.166]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MUoma-1bhnZH0uNA-00Y9Xs for ; Thu, 11 Aug 2016 20:56:27 +0200 To: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 11 Aug 2016 20:56:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UxQQvoR3WeDnmdx2Fv5iMvqTFMVPITtw8" X-Provags-ID: V03:K0:QF0mPyM7hHSef5vg8H4swOB8L4uPWYW0UgOn3TyESJvshBMNQDT lNIcdAONlJqjX5jgPmtvk+6D+3J7DLIFyPqu8jEuGoYaiU48k24iGYPT9dn+YZ6p3zYaxjh 6qv2QmA/zQeki2Eul1BXnzM5RD4zloOeMqDAR7zsRBDtbklF85HLqUE5QThDmHy9L0r/QBL VW/3LECXMu+3Wvg4DugLQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:bD8WMIY9xn4=:+CbE4IriIcvRlv39CN8R+y ltG0tsfMOTy9PaMry/0trjZsLOY/84q0KTUdG5wpYejf0XhMprWQOoyN+uHHK1yv1WFG5AKcJ HcoSKt+w95/BWnS3t7M7v7EBrgf9oPsMeRb4gtyed9i49168ktSATvfQ7pne+yER8WU7FzBHl tl1PsziLPXMdjO+jTQb4ASYTBgPmXw+EeF+QcYCNEtL9N0e7ICQUOfA8+r6X8yIgjj0cuhHT1 /pNS5TJqka3wo3x5T5nJCwvDCa+itEhHEoEFS6b2HAjFbaSct8H9ZTCLLEZJhpsUv7nKlGOdP 3y58lK17d07cxruepJBZcAEBqRmIU/pYic0UaTo5U8YA9BpbktiLvgJzUj5qyrNbeICIdzL+p yMUQGObboao6Zc++8aZDnyE47HNxMEg0K9pisyjFBt0rrQcTwpH7bocc+E5q6NePVEMLGV1Mj 5QqpHif9BtrG/zwtgLdAEpBMgEEO+OcumklHustNb7eF9o/d+yDkU5YTOt9ubsOvHE3je/mDd vv6MGM04vLLLrRk4kO36lefVkkFyy7L0uqMMJNLUq03+xbauHfipI27A7RVILblfUE470Sffz 0sgp62mAV5PVDTNxz6saxOtAgl4feT8TU1I+KZQJJXSFe2rZnRCNBaAmGCfLuZhX05NBu/mRM ljfCkEnbcO8amzcsFo+ffJkiWKR6SijVzlPrafa5bYnkE7kyGGaYXezIjSucRKBaNil+uGfIE q5PUImr9vqsP28ABOPm7cxLvn+LCEjDz/o//Lmi95SCiRHc5whjd/y5er7Y= Archived-At: Subject: [TLS] TLS ExtensionType Registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2016 18:56:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UxQQvoR3WeDnmdx2Fv5iMvqTFMVPITtw8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, Hi all, reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I noticed the TLS ExtensionType Registry on page 77 & page 78. The "TLS 1.3" column has one of four values, namely - "Client", indicating that the server shall not send them. - "Clear", indicating that they shall be in the ServerHello. - "Encrypted", indicating that they shall be in the EncryptedExtensions block - "No" indicating that they are not used in TLS 1.3. The following values deserve a closer look: +-------------------------------+-----------+-----------------------+ | Extension | Recommend | TLS 1.3 | | | ed | | +-------------------------------+-----------+-----------------------+ | server_name [RFC6066] | Yes | Encrypted | | | | | | max_fragment_length [RFC6066] | Yes | Encrypted | | | | | | key_share [[this document]] | Yes | Clear | | | | | | pre_shared_key [[this | Yes | Clear | | document]] | | | | | | | | cookie [[this document]] | Yes | Encrypted/HelloRetryR | | | | equest | +-------------------------------+-----------+-----------------------+ The server_name extension is sent in the initial ClientHello and will not be encrypted since it will be used to select the right server in a hosting environment. The max_fragment_length extension is sent in the initial ClientHello but is not as essential as the server_name extension. Still, in most cases there is no security context established at the time of sending the ClientHello (at least not in the full handshake when ECDHE is used). The key_share & the pre_shared_key extension is sent in clear in the ClientHello and in the ServerHello. The cookie is not sent encrypted in the HelloRetryRequest since the HelloRetryRequest is sent when the client has not provided a suitable "key_share" value. The DoS protection feature used in the HelloRetryRequest is most likely useful only in context of an unreliable transport protocol. If you want DoS protection then the server should not store per-session state, which establishing security context would require. I believe the definition of 'clear' should be changed to: "Clear", indicating that they shall be sent in clear in the ClientHello and in the ServerHello. I fear that the use of extension in the encrypted block may be dependent on where they can first be used and also in what handshake variant. It is also a question whether it makes sense to send an extension encrypted in the ServerHello when it first appeared in clear in the ClientHello. I wonder whether the "TLS 1.3" column in this table could actually be simplified to only provide information about extensions that can be used in TLS 1.3. Whether something is sent in clear, encrypted or only be the client is something that should be described in the protocol specification itself. Ciao Hannes --UxQQvoR3WeDnmdx2Fv5iMvqTFMVPITtw8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXrMpaAAoJEGhJURNOOiAtQ24H/R2nnHFvEeTlv7inXjpqO3FI j/zE+EqYwlj8eKIP7T7Zhp0QcTTlKcP/DAv629wF6DxtMbWheasy95BavlKmXLIp h2zzzTv8JUNfqdeHRi7aUdpJRrRcepVE5obJH5sfj4OrsP5nl23mugjNkPF9dhKv lyyk759qsVv6Zw9i2bLhMeXninnStQ8qsW4jLhbObBf8kN25sQLgZwExeloylASi ZMa/lhhcoW8KhFCDAdLugrw5DSRIes7xIOWFEkpAUSoipRi77j/Fl/EAHNkG/6Wx +i4UjTax9ufQ8QC1LIcdjS+PeoXRfGolpCs7J7agTnUGZnXd/lOfGFXFq3ilv54= =s00w -----END PGP SIGNATURE----- --UxQQvoR3WeDnmdx2Fv5iMvqTFMVPITtw8-- From nobody Thu Aug 11 12:09:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7789012D1BC for ; Thu, 11 Aug 2016 12:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb_w-2El3rYW for ; Thu, 11 Aug 2016 12:09:41 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD212B020 for ; Thu, 11 Aug 2016 12:09:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B0B67D9CB for ; Thu, 11 Aug 2016 22:09:38 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id oyZlD-KGGVUO for ; Thu, 11 Aug 2016 22:09:37 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 6A25D21C for ; Thu, 11 Aug 2016 22:09:37 +0300 (EEST) Date: Thu, 11 Aug 2016 22:09:29 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160811190929.bowe75bhjeks6bqf@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.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] TLS ExtensionType Registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 11 Aug 2016 19:09:43 -0000 On Thu, Aug 11, 2016 at 08:56:25PM +0200, Hannes Tschofenig wrote: > Hi Ekr, Hi all, > > reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I > noticed the TLS ExtensionType Registry on page 77 & page 78. > > The "TLS 1.3" column has one of four values, namely > > - "Client", indicating that the server shall not send them. > - "Clear", indicating that they shall be in the ServerHello. > - "Encrypted", indicating that they shall be > in the EncryptedExtensions block > - "No" indicating that they are not used in TLS 1.3. > > The following values deserve a closer look: > > +-------------------------------+-----------+-----------------------+ > | Extension | Recommend | TLS 1.3 | > | | ed | | > +-------------------------------+-----------+-----------------------+ > | server_name [RFC6066] | Yes | Encrypted | > | | | | > | max_fragment_length [RFC6066] | Yes | Encrypted | > | | | | > | key_share [[this document]] | Yes | Clear | > | | | | > | pre_shared_key [[this | Yes | Clear | > | document]] | | | > | | | | > | cookie [[this document]] | Yes | Encrypted/HelloRetryR | > | | | equest | > +-------------------------------+-----------+-----------------------+ > > The server_name extension is sent in the initial ClientHello and will > not be encrypted since it will be used to select the right server in a > hosting environment. Actually, the server_name could be made into 'client', since the only thing server sends about server_name is an ACK, meaning it has taken it into "consideration" (in some vague way). > The max_fragment_length extension is sent in the initial ClientHello but > is not as essential as the server_name extension. Still, in most cases > there is no security context established at the time of sending the > ClientHello (at least not in the full handshake when ECDHE is used). I think max_fragement_length should be made into 'clear', given what it is used for. > The cookie is not sent encrypted in the HelloRetryRequest since the > HelloRetryRequest is sent when the client has not provided a suitable > "key_share" value. The DoS protection feature used in the > HelloRetryRequest is most likely useful only in context of an unreliable > transport protocol. If you want DoS protection then the server should > not store per-session state, which establishing security context would > require. The "encrypted" seems to be leftover from time when there were inter- connection cookies (which were removed). > I fear that the use of extension in the encrypted block may be dependent > on where they can first be used and also in what handshake variant. It > is also a question whether it makes sense to send an extension encrypted > in the ServerHello when it first appeared in clear in the ClientHello. > I wonder whether the "TLS 1.3" column in this table could actually be > simplified to only provide information about extensions that can be used > in TLS 1.3. Whether something is sent in clear, encrypted or only be the > client is something that should be described in the protocol > specification itself. Actually, in that wide sense, all extensions can be used. TLS 1.3 just forbids negotiation of some extensions. But it does not forbid client sending any extension if downnegotiation is supported. -Ilari From nobody Thu Aug 11 23:29:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97F412D0FC for ; Thu, 11 Aug 2016 23:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eEDw_sWD4nL for ; Thu, 11 Aug 2016 23:29:01 -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 52FF0128B44 for ; Thu, 11 Aug 2016 23:29:01 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id t7so17335253qkh.0 for ; Thu, 11 Aug 2016 23:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/3UyT+RZv1DXJ1citcgp7Bx5Xk/ZjRq4yy82zo2k0Gw=; b=xiUoyyytFPVsbJdeEoejzBzA49yZCP9obecO1JN9LTHwmKPrS+NxOQxYpwN/TEdoPR VbIDy+okA1wB2XiosE1VWKwznwCLB/eo1upbjDwSj63v0exycZcE+4CfiWvQeSWX5uFf d1g+wrSun1gEesvQMXxl+A2KC/TeBqgqTwyNLC/6R2p+ZIg9arKeKNOiGygSVUwwOjF6 6qP3xWRvmsW8fVbdHf9EmnDQcucpzqQBrMvioO7zfxedbbZcjVZJh/i3RpAqK7FpvEWe URZdP5F2BpjNO7Sqq4WaNRYXgypMxuTQoSxVAnUcDFe24tVLGsQeqD9ndSgZl7tsCxzw YCfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/3UyT+RZv1DXJ1citcgp7Bx5Xk/ZjRq4yy82zo2k0Gw=; b=RH2F36NbNU4obqMhADxZ2tsqWVnGssDxS68Z3TO/1ij7S/2hWVZkkyi4Swkis2/BTu 5GJqUuPktE0ru+4VO/dzOr8FhrasgAPLM8A3gNy8XXN8PY3Y2DjsBu8HTd6rlEvAWTEB 1ucZE7z7YXHbgYWw0lM4gCstraNjA1C7no8UT6BeITwvP4s9P/SxkNDBp16qUlF4mnFu CoNuGmPvQHr4A67c5ULr/qdVXfta2Ocl1A/OznJNEF6YhRT2nd/lhQKn75HV7Wl2AUIg ofuIVi0F59RVewGO+LeDKoNDJRlVub+C5VriwAnarkY2Ji3OnlXqPpMal4hoE1V1wra6 uqng== X-Gm-Message-State: AEkooutJkMObpsA2tie2m1cOQiHXNJhHXcXoTgpupt8Wm60X8KzJbx3i3lPo17OnN4nTs46b2Igah0fKwYgAoQ== X-Received: by 10.55.11.7 with SMTP id 7mr16496824qkl.169.1470983340544; Thu, 11 Aug 2016 23:29:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Thu, 11 Aug 2016 23:29:00 -0700 (PDT) In-Reply-To: <1470821613.2539.44.camel@redhat.com> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> From: Martin Thomson Date: Fri, 12 Aug 2016 16:29:00 +1000 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 06:29:03 -0000 Looking at those emails, I am prompted to wonder if anyone can justify the existence of a ciphersuite with a double-sized key and half-sized authentication tag. RFC 6655 doesn't really explain how that is a useful thing. On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos wrote: > On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: >> All, >> >> We've received a request for early IANA assignments for the 6 cipher >> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh >> e-psk-aead/. Please respond before August 23rd if you have concerns >> about early code point assignment for these cipher suites. > > I have previously raised an issue [0] on these ciphersuites. The same > requirement was noted also by Peter Dettman as something special in > [1]. However, there has been no reaction from the authors (now in CC). > > regards, > Nikos > > [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ > [1]. https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Aug 11 23:39:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD67F12D779 for ; Thu, 11 Aug 2016 23:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHWkyh6hBPz0 for ; Thu, 11 Aug 2016 23:39:52 -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 42BF612D54D for ; Thu, 11 Aug 2016 23:39:52 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id t7so17490790qkh.0 for ; Thu, 11 Aug 2016 23:39: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:from:date:message-id:subject:to :cc; bh=NfMDToJc9G9OWe+p3JBH5kqSZG9sZewhd152HAx3YVY=; b=V55Al8mgjwe3+/SoIXEJ1iNdHLFowy0K6c8TrjpgdBlCsjwnPUoYz1DvAHJMOcrvpm K0VULDqMswc6CmuxvI+L62oTtJMNbJbkDIdtcxcSr/eWwl65cjXT8DxrcKixCujlZKj9 NNzDRVUmOPDgpwH1lrxajtYiX6DVTrx5ljs9/dqltqdWOEiFsI8zv1DIGsMkWoQk6Qf+ I1tpj03P/bCmLr54yEX9ry/3zQ75c6nCruPN8JiM78YFfsXU4xMznEXWv60ioIQ7TlSp g/45D3npZUnXxFOtBXvf9NQYaDcPnxh+ub900Ap6JBTH800GZk1zv+FJfZjubDlPpKrJ 7aeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NfMDToJc9G9OWe+p3JBH5kqSZG9sZewhd152HAx3YVY=; b=lzNKm66P8rhf5/zgAN4wqKWipAAEykNWC4CG8HLQ1R6KViCc2jlFi8HG/FGmBGFnel +obVl+Hd3sAnwiV1WyO+9TrtBg+2l6BhcrsrCrDpXa8O456FAaAO0hD4pz1N/UWFNh2u 91AB/3FQrjUzxAiIi19oY7T4/U//0eYmmi5H/1fVOqWZL93nA3uM4DfNyJsn+Ufww7dg /DdPZQZv+QPzejjpRLMilMbIaG7bSgbeMD+FoOTbOBFA0JPnCbgktLiIJJQ2wmCfZsvG kKEcC13MP/f8Xz4S5HAnn3dgJVgUz3WZiZecncz59TdRRfhkI3iarQCPZCyETkf/MWsf /j5w== X-Gm-Message-State: AEkoouunz0+b8827+ipj+K04QFOqxUSgiTuGhHCmnEgRA0HDuJkMk2/u6FsUTvirjZoDUDzsP6EOZqthIxmoXA== X-Received: by 10.55.165.65 with SMTP id o62mr16599829qke.282.1470983991416; Thu, 11 Aug 2016 23:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Thu, 11 Aug 2016 23:39:51 -0700 (PDT) In-Reply-To: <20160811190929.bowe75bhjeks6bqf@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160811190929.bowe75bhjeks6bqf@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Fri, 12 Aug 2016 16:39:51 +1000 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ExtensionType Registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Aug 2016 06:39:54 -0000 On 12 August 2016 at 05:09, Ilari Liusvaara wrote: > Actually, the server_name could be made into 'client', since the only > thing server sends about server_name is an ACK, meaning it has taken it > into "consideration" (in some vague way). I disagree. If it can be encrypted, then it should be. (I don't believe that we ack this in NSS, so it's moot there.) >> The max_fragment_length extension is sent in the initial ClientHello but >> is not as essential as the server_name extension. Still, in most cases >> there is no security context established at the time of sending the >> ClientHello (at least not in the full handshake when ECDHE is used). > > I think max_fragement_length should be made into 'clear', given what > it is used for. I disagree. The client doesn't need to use this value until it has read all of the server's first flight, so it can be encrypted. The server can still act on the client's value until that time. (I know that you might make an argument that it could appear in HelloRetryRequest to force the client to cut its second ClientHello smaller, but that's really tricky to get right, and I think that servers should just be prepared to swallow an entire ClientHello.) >> The cookie is not sent encrypted in the HelloRetryRequest since the >> HelloRetryRequest is sent when the client has not provided a suitable >> "key_share" value. The DoS protection feature used in the >> HelloRetryRequest is most likely useful only in context of an unreliable >> transport protocol. If you want DoS protection then the server should >> not store per-session state, which establishing security context would >> require. > > The "encrypted" seems to be leftover from time when there were inter- > connection cookies (which were removed). Yep, this needs to be Client* with a note that it appears in the HelloRetryRequest (a category in which this is currently the only resident). From nobody Fri Aug 12 02:02:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045E812B019 for ; Fri, 12 Aug 2016 02:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8d9p6Fy0V-8 for ; Fri, 12 Aug 2016 02:02:42 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id A703812B013 for ; Fri, 12 Aug 2016 02:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5703AF82A; Fri, 12 Aug 2016 12:02:40 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id fO5YRJNEPKJY; Fri, 12 Aug 2016 12:02:40 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 0C46D21C; Fri, 12 Aug 2016 12:02:40 +0300 (EEST) Date: Fri, 12 Aug 2016 12:02:32 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160812090231.76bskgj4wkoymvyh@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160811190929.bowe75bhjeks6bqf@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.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ExtensionType Registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Aug 2016 09:02:45 -0000 On Fri, Aug 12, 2016 at 04:39:51PM +1000, Martin Thomson wrote: > On 12 August 2016 at 05:09, Ilari Liusvaara wrote: > > Actually, the server_name could be made into 'client', since the only > > thing server sends about server_name is an ACK, meaning it has taken it > > into "consideration" (in some vague way). > > I disagree. If it can be encrypted, then it should be. (I don't > believe that we ack this in NSS, so it's moot there.) Well, I was more like "do we need this at all?". > >> The max_fragment_length extension is sent in the initial ClientHello but > >> is not as essential as the server_name extension. Still, in most cases > >> there is no security context established at the time of sending the > >> ClientHello (at least not in the full handshake when ECDHE is used). > > > > I think max_fragement_length should be made into 'clear', given what > > it is used for. > > I disagree. The client doesn't need to use this value until it has > read all of the server's first flight, so it can be encrypted. The > server can still act on the client's value until that time. (I know > that you might make an argument that it could appear in > HelloRetryRequest to force the client to cut its second ClientHello > smaller, but that's really tricky to get right, and I think that > servers should just be prepared to swallow an entire ClientHello.) Actually, the client can just abort if it observes server generating larger fragments than it requested, so it doesn't really need the ACK for anything (and if it could handle full 16k fragments, it presumably wouldn't use the extension). -Ilari From nobody Fri Aug 12 02:47:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ACA12B019 for ; Fri, 12 Aug 2016 02:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZAyaRFAxiBN for ; Fri, 12 Aug 2016 02:47:17 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2642412D0BD for ; Fri, 12 Aug 2016 02:47:17 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id x25so10047436qtx.2 for ; Fri, 12 Aug 2016 02:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pUfpYy7d21Gy17IfupKG1WMVdepMtKP1byZgArYiTeA=; b=DiP9JeQqo9XEKqv8n9IEOh8Gda/e+MYKIvVR7XV6ttLLSkKmr8cMfG3/h4OipGAhmh sWTQZ/lYbP+AART8oqGGmEJ0BGtHNlAPe+3BbqaZHAK47xa5QxrolkztE1fov/c4vTcp xy2phXGFx+Vz0UJit3y7egHTJo/3SASpRjuNrkAbz4tvCBuyqzfOJYHuDrsaVaWHKr85 VLOFt0o+GP5nzlj5uQA+y8t94r3lm549PR5H0jPx2wMOpDC8gRdxN0H1BJsiA6EydgTP 77lYdja/e8RDXdho7naRAFlTTkeqcjPkSBuBBwITKt7qrEJYYv0Bh1Bd3MpJO2VF7u2h cdUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pUfpYy7d21Gy17IfupKG1WMVdepMtKP1byZgArYiTeA=; b=FsZ7ae3iaCVF8ooaOWJn+6OicVZLmfjFJFR2qsiVzpDU22K0lWi1S1aY7VsY8wzZhR YYmD8merbRbAuz8wddfHfBiT77KU/I66AtP2+Kt97u7SjIo0iea+qH99hSg3b1RxGNsR YaILLM48n8/pVDZ0yzv6W3fRjUDOZcc/BUXqHgguVeyr0/QAUwiPpN/JOrHNIZIzvqGK jSlMOIaysrQVwEK09i4NlSszLz5Nvkx+/kqI1lSJkbn/A4/zDgVeuEf0n1eRAghiI1+w PSOEE3ikp9ft/QTNoIKDeKk+TLzCUWycVLcBOoHF8GkmT9SdgVOIYNWzcmOc3cC+oTaU dR8w== X-Gm-Message-State: AEkoouu9YnwRXPW6EZS1CbOFpW3/GvjN60dejSEQ/PwARjFgxjziAFN4eqdCMxkBVDXg6qfe4S8Cx0H8JXwBCw== X-Received: by 10.237.55.65 with SMTP id i59mr16530835qtb.62.1470995236313; Fri, 12 Aug 2016 02:47:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Fri, 12 Aug 2016 02:47:15 -0700 (PDT) In-Reply-To: <20160812090231.76bskgj4wkoymvyh@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160811190929.bowe75bhjeks6bqf@LK-Perkele-V2.elisa-laajakaista.fi> <20160812090231.76bskgj4wkoymvyh@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Fri, 12 Aug 2016 19:47:15 +1000 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS ExtensionType Registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Aug 2016 09:47:18 -0000 On 12 August 2016 at 19:02, Ilari Liusvaara wrote: > Well, I was more like "do we need this at all?". Yep, there is that :) From nobody Mon Aug 15 16:40:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1169712D539 for ; Mon, 15 Aug 2016 16:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqD_gP6viUyg for ; Mon, 15 Aug 2016 16:40:13 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 7D69512D520 for ; Mon, 15 Aug 2016 16:40:13 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 97so96467249uav.3 for ; Mon, 15 Aug 2016 16:40: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; bh=02j9NdKLTApCB7xWMhZ6GvyO1+6B4H8l12xmQ9b6Jsk=; b=Io52Ze6Q+iS4UABY7rbcFaUTjqGxKiYF5P0ZzNymstU49iKZSl4OZysbmTWXOnTq8C 3G6yh4dkMfqneXbx2qJKJA3rXlmMCUNw7+nu6HNatTOIbKLfob8/SE/FQoCzpGSUTDTH YQjvOSIpasfHTmOYCguqa4mpjDqKtEfooBBSVA5IgWxWnv3W/qMxgxkxha2U7RTYNwz8 kkoXmPFx7YXw3ZTy3fZyzoxNdkztHc+2JKIgNd7r11tHVKmmZMDUkrWJ4qIPhJz/Ksz/ QoX+MOdlri03cmTM7P+WPn7d3Q3Yf/DGd+kI1aPVceyEAvXBevMw+LsqFF9TK3buG42C Lggw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=02j9NdKLTApCB7xWMhZ6GvyO1+6B4H8l12xmQ9b6Jsk=; b=UJmGV9C4ir6nYWSPKvx6JtfHX645Yz+MsucSza4V8MS9HW8Mmz5MEeOzoMj+HGK934 N8jrHIoEuu6oTxPIQ5NIt9ZXl4m2lYGVljLrnMLU/ZsmEk2PVX0t5nRmw3d1auorxyzS Qn8iyPY58x6otAxxBGtcrlcy2fV/8EqW0Ouimneh5EWKTLzgtWVHoljt6kYbhcD3k8gt 41i9J/WBelZBmw+F17xSTaRsIDfvpEqJpeeHLmmeRID+UEXIdMxR+/d9zhdigkSkHUlz sVhi5a2gJUKq0OGMn3AntcH8kJtezjerbA+HDu/+1Vlc5siPNz9hJAquzlw9l0ZPTzB3 jKYA== X-Gm-Message-State: AEkooutd1o2QRrwLCuUMzy8ObdiqIl98LaN+BDalvT7XLfkp1DnbOQdU1sBvgkawEjUE/3dbhMEqNPIP0yJx8g== X-Received: by 10.31.186.77 with SMTP id k74mr12856073vkf.26.1471304412419; Mon, 15 Aug 2016 16:40:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Mon, 15 Aug 2016 16:40:11 -0700 (PDT) Received: by 10.176.1.209 with HTTP; Mon, 15 Aug 2016 16:40:11 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Mon, 15 Aug 2016 16:40:11 -0700 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1142f0e0dbddef053a24c0cc Archived-At: Subject: [TLS] Randomization of nonces X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2016 23:40:15 -0000 --001a1142f0e0dbddef053a24c0cc Content-Type: text/plain; charset=UTF-8 Dear TLS list, Sitting in Santa Barbara I have just learned that our nonce randomization does slightly better then GCM in the multiuser setting. However, XGCM would produce even better security. XGCM is GCM with masking applied to blocks before and after each encryption. It can be implemented on top counter mode and GHASH easily. As an alternative we could use 256 bit keys. Sincerely, Watson Ladd --001a1142f0e0dbddef053a24c0cc Content-Type: text/html; charset=UTF-8

Dear TLS list,
Sitting in Santa Barbara I have just learned that our nonce randomization does slightly better then GCM in the multiuser setting. However, XGCM would produce even better security.

XGCM is GCM with masking applied to blocks before and after each encryption. It can be implemented on top counter mode and GHASH easily.

As an alternative we could use 256 bit keys.

Sincerely,
Watson Ladd

--001a1142f0e0dbddef053a24c0cc-- From nobody Mon Aug 15 16:46:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F7212D7AE for ; Mon, 15 Aug 2016 16:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmDYXpdT8w01 for ; Mon, 15 Aug 2016 16:46:29 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20061.outbound.protection.outlook.com [40.107.2.61]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4BE712D7AC for ; Mon, 15 Aug 2016 16:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b1HLBnW5RN7ANUyWNySrCTg0ZvdpY12u2QUTJ+ZcxDA=; b=3reG2Vk41YtdvelxPYSdDPdgPq4XyBjLcw3DL3vuQikTr+C/Nx9R/B6EzfvQuBKicQawRlbkPQKsNt5/vHM4ELwzczQAOt6yRAdoMIlLcyhnw3QPC9QZzATRM7N86yzLLeXcKijDyz6/5SorbdChaLzlrPHZDJhfZ95JsMr1PFA= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 15 Aug 2016 23:46:25 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0549.026; Mon, 15 Aug 2016 23:46:25 +0000 From: "Paterson, Kenny" To: Watson Ladd Thread-Topic: [TLS] Randomization of nonces Thread-Index: AQHR905nuk1eL7qDL0+R8CMs1lZU36BKr9vY Date: Mon, 15 Aug 2016 23:46:25 +0000 Message-ID: <719DD3BC-83DD-4304-9C00-B72715A0FDA2@rhul.ac.uk> References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [169.231.115.42] x-ms-office365-filtering-correlation-id: 7dde8a55-bf41-4a60-c459-08d3c5665eac x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:hN2OOlE72jis1tQzEvFN3m1gAp5CvTxGJdvcX2wb3FrB5prRenphYMcFXUW/sN8cgilOrHnV+eORMIn0PlHbYZdZtjnlHx4rQKGMgKZ1gDRR4gojUNbjbOO2IQ47N1+3ujngMJZrDqJOLcrb2TSxEA3wa2tCMdtfH7MM0S5rnc3GaxhaHED/RtpD7IIqZ47R/P0XKY0bHV7h3bOU2BXVUDuXSwy20kurq9DLvHcPhFpyImjBu7dSER5COBAlQRKb6Vvh0kAATQRXY9qW7Meptva+UK+a17tYn6nLppt3iAE=; 5:h2GjF2+PFiFK2b3aRRk8DVbWTKwDWWqG1ZPuXukJKIftpzxvqW13IonO/m8ud9pgYI0mra6g9i7FedJeLQovot6q96WG+tpgXXxRTtjj4/wwhXG893uN9eg1FirYt48rgI4PxF4H0oKXq9Qgg/fc1g==; 24:6ZGyln5YhXQeRaWFxDRUT8+lGoW4hx6y0RHB9pxR6D8rcgeX4MN6Qn6t7f1L7teI7RFjP3qCq2t8uHp2osTkY1jQhVqA4h/zFO1FhcZfzgY=; 7:89ezn0NNCPuyx042zi6r/NGojMmvnTwbjYqo5q5sH8tDvJaCFyqMU8K9BOLqfvTtsuXUDjuMAzGGSDOwaGxyxE/B01Jroj12cCz0VQhzqsesQDLGbhV7Y3U8YQphnUSKz4RqHp1sZkJqQS4m0w01Qx0dkgmscOn8zgPSPr9f8jcrrBwi6WwiKVbvyUUhShYbIjjQ+rXZ80XJvlVRNecV4hQhIH2A5PHuEo3awJRrsEoYWqBE0lOT3p0TcEqRn82h x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0035B15214 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(189002)(199003)(7736002)(86362001)(81156014)(6116002)(2906002)(87936001)(101416001)(2950100001)(33656002)(3846002)(76176999)(7906003)(19580405001)(50986999)(8676002)(11100500001)(83716003)(92566002)(7846002)(66066001)(82746002)(54356999)(122556002)(81166006)(10400500002)(5002640100001)(1411001)(4326007)(74482002)(586003)(77096005)(189998001)(93886004)(3660700001)(102836003)(106356001)(106116001)(105586002)(3280700002)(19580395003)(2900100001)(19617315012)(97736004)(36756003)(110136002)(16236675004)(68736007)(8936002)(15975445007)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_719DD3BC83DD43049C00B72715A0FDA2rhulacuk_" MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2016 23:46:25.3857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Randomization of nonces X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2016 23:46:31 -0000 --_000_719DD3BC83DD43049C00B72715A0FDA2rhulacuk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sadly, you can't implement XGCM using an existing AES-GCM API, because of t= he way the MAC (which is keyed) is computed over the ciphertext in the stan= dard GCM scheme. This does not contradict what you wrote, but may be a barrier to adoption. Cheers Kenny On 15 Aug 2016, at 16:40, Watson Ladd > wrote: Dear TLS list, Sitting in Santa Barbara I have just learned that our nonce randomization d= oes slightly better then GCM in the multiuser setting. However, XGCM would = produce even better security. XGCM is GCM with masking applied to blocks before and after each encryption= . It can be implemented on top counter mode and GHASH easily. As an alternative we could use 256 bit keys. Sincerely, Watson Ladd _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_719DD3BC83DD43049C00B72715A0FDA2rhulacuk_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sadly, you can't implement XGCM using an existing AES-GCM API, because= of the way the MAC (which is keyed) is computed over the ciphertext in the= standard GCM scheme. 

This does not contradict what you wrote, but may be a barrier to adopt= ion. 

Cheers

Kenny

On 15 Aug 2016, at 16:40, Watson Ladd <watsonbladd@gmail.com> wrote:

Dear TLS list,
Sitting in Santa Barbara I have just learned that our nonce randomization d= oes slightly better then GCM in the multiuser setting. However, XGCM would = produce even better security.

XGCM is GCM with masking applied to blocks before and after = each encryption. It can be implemented on top counter mode and GHASH easily= .

As an alternative we could use 256 bit keys.

Sincerely,
Watson Ladd

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.iet= f.org/mailman/listinfo/tls
--_000_719DD3BC83DD43049C00B72715A0FDA2rhulacuk_-- From nobody Mon Aug 15 16:50:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5287B12D5A3 for ; Mon, 15 Aug 2016 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr4kKZvoYmez for ; Mon, 15 Aug 2016 16:50:48 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C79612D7A4 for ; Mon, 15 Aug 2016 16:50:47 -0700 (PDT) Received: from mail-wm0-f53.google.com ([74.125.82.53]) by mrelayeu.kundenserver.de (mreue004) with ESMTPSA (Nemesis) id 0LsMfM-1bBMIn1gHg-011wEZ for ; Tue, 16 Aug 2016 01:50:45 +0200 Received: by mail-wm0-f53.google.com with SMTP id i5so132892631wmg.0 for ; Mon, 15 Aug 2016 16:50:45 -0700 (PDT) X-Gm-Message-State: AEkoouu6LCrqa7tzaFATsbGxi99wswRvPf1WK0640FV3Eemn+ShaAWO8rHnrTVB+zplSFWk7fU42A4tlAci25Q== X-Received: by 10.25.139.135 with SMTP id n129mr5191195lfd.111.1471305044933; Mon, 15 Aug 2016 16:50:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.148.135 with HTTP; Mon, 15 Aug 2016 16:50:43 -0700 (PDT) In-Reply-To: References: From: Bodo Moeller Date: Tue, 16 Aug 2016 01:50:43 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113fc2f68f4603053a24e6f1 X-Provags-ID: V03:K0:HTrhKWALzulIXJFhfMD2rWw7s6oo80LZwLhngV+y5fgvXckDBvX gq0kBYumFuSId0NHarb90FI0SmC41MqZIzrVgJgsaZUidQERdlWVGYfkDCdm5rLR3M/I+tQ n4owbxLfKOn94qXoVmtLmdPMwWWPEIo4dVVaPe6SdIS+LupMItYcq2uU+7cgivtbrgJ9iED pyw6AVbLUG4SPoXveh7iA== X-UI-Out-Filterresults: notjunk:1;V01:K0:0aLFsKK0l4c=:RueUkWj7L+Nx7ckBEja56J J9idVgDTZAo3zVBD5IyWVNu3pMrEZRVi9Ng1hQnlXCjUtO9TBYnpgxnW3yXrL4FLv0PLKmvsr kIpGlRDxi5zrY1eomFtcVPv3zsj9KcGD1/bMqsrNDTFhJ6otq7PUDKpIVomEd8laX5mEGwLhi OPVzRBcxo3lqESCdyPi27SNdM1cN9+jgV5g0z7hWEfk5c43+w6npZyVe/dRA986B6+qv3QlLe y9jQZF7xWa8+NzV7lu3kHHa81dab9l/YKKSsTWxw0ZTjVNzzFfaZgGOGoJ/7pgZNRqYbvN7TE moa5n0pzXeSdwPihtWZPHtgWGpOi0/pecO/xwY9QDPaL1yLhT1yTe8JPDJZSx/j2RmUYRUS/Q wQgutK+eJtWzCoVoEbONSGKdSPcIt2eRgPMtYT87bhQGT0qHsbnxlvFnvWNTD9UXU+pOTF+Kw p28IMdRZXxa7b9zoJ7JmKu8y2h1iM9w2IkK6rvm1gR9TIJFzldfYawv4VKYQiokuSlUWKWYHo 8VE7x8JFRTxqFKe1yQ0ogEEUfZHVkOdQVBIwpp2G/4dmjMW2Acl/zpX53pA1xy5QBB7ieSP/V z464INGTFREtR0cnJGOj1B0yyJRGJxan3gNJ/zrWQNNNl/KoICda2ondcXRjBdOHZaoGwKAbq t4IyUARNoAtnRQ+C7QAzYBLb6o/Oz5dp7ShHW35SfxD+ekYhAkcLiqYKxDsKmzStjjcfxQDbw UMntw3AWDxoRJHnp Archived-At: Subject: Re: [TLS] Randomization of nonces X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Aug 2016 23:50:49 -0000 --001a113fc2f68f4603053a24e6f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's https://eprint.iacr.org/2016/564 for those who'd like to see the research (Mihir Bellare and Bj=C3=B6rn Tackmann). Bodo --001a113fc2f68f4603053a24e6f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's=C2=A0https://eprint.iacr.org/2016/564 for those who'd like to see the= research (Mihir Bellare and Bj=C3=B6rn Tackmann).

Bodo<= /div>


--001a113fc2f68f4603053a24e6f1-- From nobody Mon Aug 15 17:34:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8651E12D5D8 for ; Mon, 15 Aug 2016 17:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eng.ucsd.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4bWoZA2Toz1 for ; Mon, 15 Aug 2016 17:34:42 -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 055A812D1BC for ; Mon, 15 Aug 2016 17:34:42 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id fi15so20530494pac.1 for ; Mon, 15 Aug 2016 17:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eng.ucsd.edu; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :references:in-reply-to:to; bh=hNf+XqcTeJVk49L4gI7MIXUkqxfEeDhZFnfcVHOEEGk=; b=f8J9SOwOsVe66P2G+90h7fqh236uNcZiHP4jllC0Z7exC0sbxI+8Oe6dAhfBA6q5rF 8l1NOmsDBLdQRj0FqS3MuDN0j1537yaLKGpNOxUSc7xg+Kxzo+pkoWWyyLe4H7krhkDv IMAAkbp/ZLMTtc+MDFHtJ8GwdKB03Scoc983M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:references:in-reply-to:to; bh=hNf+XqcTeJVk49L4gI7MIXUkqxfEeDhZFnfcVHOEEGk=; b=lz6FwJuf42WjdbwjrmLmIODseQmoWn6DRunrVrPLSLBNhStJJVR/0FXzXfPgT/g690 vEYNhYdSYUR/FDvmbvbl7m5qHncOxQ7Wrtb4zwZ+gQ012FITg8Q7mjsRBxfrR7B/VXFP HMUkGhX81RscyxUkpGqESEbwreVoE3ZBKySN5TIIMgrrnZ2jfTJZyPI8QfGj1E4oa61K 9akqD2LK+8ign/M6wmpxyi1ld5joCA4UP+N4Rfu2oQxCyyl8kHdnjnApM+VM+xVDRzc1 qsmnHq2vSw6TrMNPTbmhj266o8slppR1U1q5fiHB5SFsz2B3dRLLqrlFgwfPKhXUPIRx DZ+g== X-Gm-Message-State: AEkoouv3PZJZ84423FKA2U0N3h5YbUO+9lXEcWnm9wbOs0dlJi4K7gVSqB+jDerDvYw80l9R X-Received: by 10.67.7.170 with SMTP id dd10mr8058381pad.152.1471307681346; Mon, 15 Aug 2016 17:34:41 -0700 (PDT) Received: from [21.247.131.253] ([172.56.31.144]) by smtp.gmail.com with ESMTPSA id 6sm34176990pab.11.2016.08.15.17.34.40 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Aug 2016 17:34:40 -0700 (PDT) From: =?utf-8?Q?Bj=C3=B6rn_Tackmann?= Content-Type: multipart/alternative; boundary=Apple-Mail-A58C1E92-0F6D-4652-B0C2-56B2E1175353 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <8E4790D1-BAFC-4BED-9A52-99E8A76E84E0@eng.ucsd.edu> Date: Mon, 15 Aug 2016 17:34:38 -0700 References: <719DD3BC-83DD-4304-9C00-B72715A0FDA2@rhul.ac.uk> In-Reply-To: <719DD3BC-83DD-4304-9C00-B72715A0FDA2@rhul.ac.uk> To: "tls@ietf.org" X-Mailer: iPhone Mail (13G35) Archived-At: Subject: Re: [TLS] Randomization of nonces X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2016 00:34:43 -0000 --Apple-Mail-A58C1E92-0F6D-4652-B0C2-56B2E1175353 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I wanted to explain that on my final slide but then ran over time. It is dis= cussed in the paper, though. Sorry for the confusion. Best, Bjoern > On Aug 15, 2016, at 4:46 PM, Paterson, Kenny w= rote: >=20 > Sadly, you can't implement XGCM using an existing AES-GCM API, because of t= he way the MAC (which is keyed) is computed over the ciphertext in the stand= ard GCM scheme.=20 >=20 > This does not contradict what you wrote, but may be a barrier to adoption.= =20 >=20 > Cheers >=20 > Kenny >=20 > On 15 Aug 2016, at 16:40, Watson Ladd wrote: >=20 >> Dear TLS list, >> Sitting in Santa Barbara I have just learned that our nonce randomization= does slightly better then GCM in the multiuser setting. However, XGCM would= produce even better security. >>=20 >> XGCM is GCM with masking applied to blocks before and after each encrypti= on. It can be implemented on top counter mode and GHASH easily. >>=20 >> As an alternative we could use 256 bit keys. >>=20 >> Sincerely, >> Watson Ladd >>=20 >> _______________________________________________ >> 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 --Apple-Mail-A58C1E92-0F6D-4652-B0C2-56B2E1175353 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I wanted to explain that on my final slide but then ran over time. It is discussed in the paper, though. Sorry for the confusion.

Best,
Bjoern


On Aug 15, 2016, at 4:46 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:

Sadly, you can't implement XGCM using an existing AES-GCM API, because of the way the MAC (which is keyed) is computed over the ciphertext in the standard GCM scheme. 

This does not contradict what you wrote, but may be a barrier to adoption. 

Cheers

Kenny

On 15 Aug 2016, at 16:40, Watson Ladd <watsonbladd@gmail.com> wrote:

Dear TLS list,
Sitting in Santa Barbara I have just learned that our nonce randomization does slightly better then GCM in the multiuser setting. However, XGCM would produce even better security.

XGCM is GCM with masking applied to blocks before and after each encryption. It can be implemented on top counter mode and GHASH easily.

As an alternative we could use 256 bit keys.

Sincerely,
Watson Ladd

_______________________________________________
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
--Apple-Mail-A58C1E92-0F6D-4652-B0C2-56B2E1175353-- From nobody Mon Aug 15 18:25:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3121B12D119 for ; Mon, 15 Aug 2016 18:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFknAgBH30uN for ; Mon, 15 Aug 2016 18:25:12 -0700 (PDT) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27D912B068 for ; Mon, 15 Aug 2016 18:25:12 -0700 (PDT) Received: by mail-yw0-x244.google.com with SMTP id u134so2958540ywg.3 for ; Mon, 15 Aug 2016 18:25:12 -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; bh=JYbCVzYusDdToJFS2P+myvT2qek55wkBaSxrG63EZ9U=; b=B+8SnZdO+98eB+zXmxZA5fr999vNFxH2NCRWRn4jM9zkiLChOpSKP3wyMgiAjN+RiU LsKrvPYuouVeoNyM9oij+s+Yf8ZLPTgDy0CwkgQILdBSypsE03SVM1rBa4XWFBS3/k58 +qpVIaycwlbNhBI3Iii80WSyhEcNRmQrKyYGl42B6qZajseGGz/Joi03Gf+FOXy5Y0GC 2Ph6VnoEeUdVSp+R9TdTOuPYCGWOFfT0o5NIS/F52zM2VXdZDn1lVIKOEJRmz8gt3ita iJrzQAjPiMchDwv6CQg40FwPUHsa8+dsjzlHsiNBkPsT9KLQERDvbJ/N6hTKa1oh5Njm OL/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=JYbCVzYusDdToJFS2P+myvT2qek55wkBaSxrG63EZ9U=; b=LL8Nwdj4dgRFD+jZ+7NFrlEYmmx1oHIhu9IakBXGX4OFT+lO7RGFFn+3k0qqZcuRT1 RF0BTyQEN1yjCX+CzdarCNvtF9vpZi/pXD8ld/leh4Bc9LzIUonYMIZidp8RrIDwY/Ri P+xO1+wU0RGSbHNbDCAgVLLokshoAzs6JsVbvylluou5WcT/p/3PFxeXrfkMMFv2c4wk b86Ynm/wD5sNDfBGT0eeeWzBjqlEiDOH/rbpucdUL3Lw7fWJBsJhdFff7mh29W3bngGl C1uwwTvbS75lwcjjN2xUnazKSh1Hjm8NDiYfbfvDLRlCcphWelMRqZKg1NSI2si7u3ce GLQA== X-Gm-Message-State: AEkooutCqijtAkXaUCkF+Ija5qXKgv6bznj+H2944b1h9ENQL8VrhHmw30ecuXBT1smLvf1PalzQKXcZKWY/lw== X-Received: by 10.129.102.193 with SMTP id a184mr25237049ywc.63.1471310711771; Mon, 15 Aug 2016 18:25:11 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Mon, 15 Aug 2016 18:24:31 -0700 (PDT) From: Keith Winstein Date: Mon, 15 Aug 2016 18:24:31 -0700 X-Google-Sender-Auth: 3aENf97AYUoDeojlNSc94KpmhEc Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Henry Corrigan-Gibbs , Dan Boneh , Riad Wahby , Judson Andrew Wilson Subject: [TLS] KeyUpdate receive_generation field (again) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2016 01:25:14 -0000 Hello all, After our discussion in Berlin, I wanted to try to rally consensus over adding an explicit receive_generation field to the TLS 1.3 KeyUpdate message. The KeyUpdate message allows one side of the connection to instruct the other to: 1) increment the receive-key generation, 2) de-trust and stop accepting data encrypted with receive-keys from earlier generations, and 3) advance the send-key forwards to at least the same generation if it isn't already (and send a KeyUpdate in the reverse direction as necessary). Because either side can generate a KeyUpdate message whenever they want, there's no way within the current draft to tell that this instruction has actually been carried out. For some applications, it would be helpful for an initiating side to receive a confirmation that the KeyUpdate (especially part #2, de-trusting the old receive-key) has taken effect: - An embedded device may wish to fully rotate the session keys before going to sleep. - A paranoid device might fully rotate the session keys before closing the session, with the hopes that the other side will de-trust and also delete the old session keys, so that a subsequent compromise doesn't betray the session plaintext. If an endpoint can't get confirmation that the other side has incremented the receive-key generation, it might use a higher-level mechanism to forcibly log out all open sessions from that user. - An endpoint that wishes to permit a read-only virus scanner or IDS will want to fully rotate the session before sharing the directional keys with the middlebox. Otherwise the middlebox could use them to become a MITM in at least one direction. Our proposal is to add a receive_generation field to the KeyUpdate message, so an initiating node can learn when an earlier KeyUpdate has taken effect. The KeyUpdate message would remain as async and non-blocking as it is currently. Pull request: https://github.com/tlswg/tls13-spec/pull/580 Earlier discussion: https://www.ietf.org/mail-archive/web/tls/current/msg19347.html and subsequent Cheers, Keith From nobody Mon Aug 15 21:56:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A1A12D0A6 for ; Mon, 15 Aug 2016 21:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpsQtv4noagq for ; Mon, 15 Aug 2016 21:56:08 -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 D627212B043 for ; Mon, 15 Aug 2016 21:56:07 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id v123so61078878qkh.2 for ; Mon, 15 Aug 2016 21:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R1PAZ8ECfUJ+6j+YuhrgdjR+1vLrRD9giXwVTdRPmkA=; b=Pv/Hkm8ApCsyHFbixNI8veldw2vKExgx1KLTU/9cQOIgIPIGbuL9WbfuzCzlpt+a/8 LuBKoG1/ZjxiNl1AlVWc5m3q5syMiXeKlfFHmgVBKcT0MlGHpabJWU6ep95UTdSTeAZx s75kiDGuqdOxcEd7L6I8LoEAIDcO4L7SYrvmt/orWNqd2ce2/QmugK7GlQi7zYLHzunC 5ik4ybCmP67Z1jNUeiFhCpD54/Q/knf/DWxntEcIB1Yz4l9v/UjnoY3PIXkPadQw18Fk Gcm+oTMO4cjwvlHpc801r9Yf1oCbxT6fMNIsEPzHSC7CsulSr2Uezm/F6n9HXvjMIRK+ Q+qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R1PAZ8ECfUJ+6j+YuhrgdjR+1vLrRD9giXwVTdRPmkA=; b=i0e8hyLHg/qKOVLwNYwoyOMfu2DTwr9gwJqV3Kyjs78OnvcOhXjNShErvUkgNildpw wiV7KBuPt2foY8M+SvfQXcQ7NQ8uHKC1VubghjgHFpUzExI2rpS5TUxCN8DK7ZLodahz I74YT27yxAwGr4+itGdxMgESg0SI79N7TmaCmQC0s7d19xgZ2ckOo1aaLfBgZi6leOS5 ynyJga7wp/91nND1p7EFv1AqhTL5VMuSAQ3aElHRo+bEh6ej5B0HPRJngwKFYlW8sgwY nk2wvj5CI3JDgnGGt07fvIrlrwW+2srZZtiLg+i/+yILQNTmqjA1hJnmvrVQ0/0B8e1y Ne/A== X-Gm-Message-State: AEkoouvIc4Jhn/pQNgneGsEbfgexXgn6TTFiQYkBgHoELpnR/FhkAv7Ep8LIXWu4rAzPxlx/GW1R/LonRKGCIQ== X-Received: by 10.55.165.65 with SMTP id o62mr38982842qke.282.1471323366989; Mon, 15 Aug 2016 21:56:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 15 Aug 2016 21:56:06 -0700 (PDT) In-Reply-To: <719DD3BC-83DD-4304-9C00-B72715A0FDA2@rhul.ac.uk> References: <719DD3BC-83DD-4304-9C00-B72715A0FDA2@rhul.ac.uk> From: Martin Thomson Date: Tue, 16 Aug 2016 14:56:06 +1000 Message-ID: To: "Paterson, Kenny" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Randomization of nonces X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2016 04:56:09 -0000 On 16 August 2016 at 09:46, Paterson, Kenny wrote: > Sadly, you can't implement XGCM using an existing AES-GCM API, because of > the way the MAC (which is keyed) is computed over the ciphertext in the > standard GCM scheme. Is there a reason why you can't simply XOR the plaintext stream that is fed to AES-GCM? We set N = N XOR HKDF(IKM, salt, label[N], 12), which the paper shows improves things. If we also set P = P XOR repeat(HKDF(IKM, salt, label[P], 16)) would we gain any of the advantages of XCAU? That change could be made without needing a new algorithm. From nobody Tue Aug 16 03:44:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA3312D727 for ; Tue, 16 Aug 2016 03:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nLxiBpJQ4oE for ; Tue, 16 Aug 2016 03:44:51 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D1412D672 for ; Tue, 16 Aug 2016 03:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1471344291; x=1502880291; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Iog6VSTCO5tvBJ3tzePrsgo8/m+K8nX4dsIog08nBJs=; b=NFpy0Q7of5PCCidnbfDucXIWuMqdnsFAynL2BoBa8b8i8PfQBfC+vcnT IZA1rXoyOWFeaVuQr5A353qC0vIWFm5RidRTVoa2ATUNPs3BxX8WKIrNr 5w9FLDAjOMmK8mQIwJVS/gfYnk2d6z3ms4+wG3HBMYPcJbzjHygflxikH OpM7ejDBH4m6dm9/6tC8WQ1rx6pYFe3BefbKTPNPgvaaWkCikxQCORzod jP5dqskeUnHL8Kk3UUt1QShbnnPwD9UrwSC9TtAr3ERpos2xpc22RabhJ R2S8YybKu9obQydDS1ugOVfEz7xCgT5t0BdbPJjVV63AjelcAz0/UpzqY w==; X-IronPort-AV: E=Sophos;i="5.28,529,1464609600"; d="scan'208";a="102383480" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Aug 2016 22:44:49 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 16 Aug 2016 22:44:48 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Thread-Index: AdH3qzVttHomztzDTIKlIRH23NqfIg== Date: Tue, 16 Aug 2016 10:44:47 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 10:44:56 -0000 I've been looking through this in a bit more detail and have found some pre= tty=0A= problematic text in there...=0A= =0A= If a compatible TLS server receives a Supported Groups extension from=0A= a client that includes any FFDHE group (i.e., any codepoint between=0A= 256 and 511, inclusive, even if unknown to the server), and if none=0A= of the client-proposed FFDHE groups are known and acceptable to the=0A= server, then the server MUST NOT select an FFDHE cipher suite. In=0A= this case, the server SHOULD select an acceptable non-FFDHE cipher=0A= suite from the client's offered list.=0A= =0A= As far as I can see what this text is saying is that if the client can't gu= ess=0A= in advance which PFS suite/group the server knows about, the server must=0A= disable use of PFS. In other words instead of saying "give me a PFS suite,= =0A= preferably with this group", it's saying "give me a PFS suite with exactly= =0A= this group and if you can't do that, don't do PFS". This seems like a pret= ty=0A= awful way to handle things.=0A= =0A= This is reinforced by:=0A= =0A= A compatible TLS server that receives the Supported Groups extension=0A= with FFDHE codepoints in it and that selects an FFDHE cipher suite=0A= MUST select one of the client's offered groups.=0A= =0A= In my mind this makes the FFDHE extension so toxic to use that I'd rather n= ot=0A= support it at all, because it disables PFS unless you're really lucky in=0A= guessing what the server can do. Either that or it'll be like certain part= s=0A= of TLS 1.2 where everyone knows that you need to ignore what the spec says = in=0A= order for things to work...=0A= =0A= Peter.= From nobody Tue Aug 16 07:26:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5F912D863 for ; Tue, 16 Aug 2016 07:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6p8PlCzaBFE for ; Tue, 16 Aug 2016 07:26:02 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (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 3826D12D861 for ; Tue, 16 Aug 2016 07:25:59 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: ADB811380B5.A182C X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id ADB811380B5 for ; Tue, 16 Aug 2016 16:25:54 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTP id AB7C02003B; Tue, 16 Aug 2016 16:25:54 +0200 (CEST) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id A93926002E; Tue, 16 Aug 2016 16:25:54 +0200 (CEST) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id A569B40; Tue, 16 Aug 2016 16:25:54 +0200 (CEST) Received: from c-73-189-250-42.hsd1.ca.comcast.net ([73.189.250.42]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 16 Aug 2016 16:25:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 16 Aug 2016 07:25:54 -0700 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Atul Luykx To: Martin Thomson In-Reply-To: References: <719DD3BC-83DD-4304-9C00-B72715A0FDA2@rhul.ac.uk> Message-ID: <84368c1b9e42d9317bbc466f478e777c@esat.kuleuven.be> X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99.2 at cobalt X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Randomization of nonces X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2016 14:26:04 -0000 Right now I see no reason for this not to work. In fact if you XOR the tag as well, then every block cipher call looks similar to a DESX call, like in XCAU. Atul On 2016-08-15 21:56, Martin Thomson wrote: > On 16 August 2016 at 09:46, Paterson, Kenny > wrote: >> Sadly, you can't implement XGCM using an existing AES-GCM API, because >> of >> the way the MAC (which is keyed) is computed over the ciphertext in >> the >> standard GCM scheme. > > > Is there a reason why you can't simply XOR the plaintext stream that > is fed to AES-GCM? > > We set N = N XOR HKDF(IKM, salt, label[N], 12), which the paper shows > improves things. If we also set P = P XOR repeat(HKDF(IKM, salt, > label[P], 16)) would we gain any of the advantages of XCAU? That > change could be made without needing a new algorithm. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Aug 16 07:55:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D70912D881 for ; Tue, 16 Aug 2016 07:55:51 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCpk1iVEx-q6 for ; Tue, 16 Aug 2016 07:55:49 -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 BEBE112D1CA for ; Tue, 16 Aug 2016 07:55:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B65CA284F26; Tue, 16 Aug 2016 14:55:48 +0000 (UTC) Date: Tue, 16 Aug 2016 14:55:48 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160816145548.GQ4670@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 16 Aug 2016 14:55:51 -0000 On Tue, Aug 16, 2016 at 10:44:47AM +0000, Peter Gutmann wrote: > As far as I can see what this text is saying is that if the client can't guess > in advance which PFS suite/group the server knows about, the server must > disable use of PFS. In other words instead of saying "give me a PFS suite, > preferably with this group", it's saying "give me a PFS suite with exactly > this group and if you can't do that, don't do PFS". This seems like a pretty > awful way to handle things. The client is expected to send a complete list of *all* the groups it supports if it supports (any of) the new designated groups. Which means that clients that support these groups will use only these groups with servers that likewise suppose these groups, and will not use FFDHE when the client group list and the server group list don't overlap (which is seems unlikely). > In my mind this makes the FFDHE extension so toxic to use that I'd rather not > support it at all, because it disables PFS unless you're really lucky in > guessing what the server can do. There's no guess, the client sends its full list of supported groups, and the server picks the one it likes. -- Viktor. From nobody Tue Aug 16 07:57:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECD912D1DD for ; Tue, 16 Aug 2016 07:57: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3543FJfLWjL9 for ; Tue, 16 Aug 2016 07:57:05 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 70D0C12D876 for ; Tue, 16 Aug 2016 07:51:17 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 74so125490737uau.0 for ; Tue, 16 Aug 2016 07:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FTR7DWzwkT7jqkSIY5uJedefoiLrsNBnqzD28hIDQWM=; b=AZkVSKCaTNlFAC9l9Map12aM9oKLl1RySAqU8y9dodFDC8JJoe+KOz9tOEXTlZ5QFU kbDALSSBfHuB7FukJtWXBcDfYs7Q19geVU8a6DB2P+jXebTeB/3Lb637nYXOeChZBJXW ID1/cw5DxCMzVUu1a2GMluqU+EoiQYWEVXeXyiK3pYOuEKXzKIv9ODWrt4vMPA20VqHi O56gACDDG9B3e8VxyiRBckbCmbslB4+XGulYfWPHOYaLU7RDDO/FoSHxeCxYckLMFBvZ 8AW9UGWGoGJ+Ez5eOFa2UCv1yV+8qW94lVoIo4LsfVVxAEoy1ut3QxyiOJNm1bQz6zLS NpGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FTR7DWzwkT7jqkSIY5uJedefoiLrsNBnqzD28hIDQWM=; b=dxgkv2/Lq/InHs2P8Id3tD/XIRlV7BG3lNanJ728zlp8Wm3rdMIdYhUicq4K+5+xFz rN13kyXH46yM8nBWWNSaPxvCfS9FFyFd4E4oiPMMlUtk9kA5ZGq/hKO6sAvx5Od9KVoG nP0zRI8z0PaWIH+4lrxyswPM/S4pCPxVcZhDIrOI87BUEq34y/CprZx3Np8O3QwNIXOC ZQq/JovvtZueRuhgIDPHD/KmoqNh+CCIKG39Ja14LteLxqpDmcN3+kw6RsWEkZDsUipr G8l31Yy7r8dss7HvYOogek8q2myDafscQtSFyuD+2UNqTNHDiRI1kHM5FJm3sTn4b3Mt K74A== X-Gm-Message-State: AEkoouusykEFn352/UcetGA0LgTbwLD93H7fa4OQU2m80NtE5G8h15uRNf8xgNeLNswhZRRx0HD6RF9EiK+mjg== X-Received: by 10.31.252.141 with SMTP id a135mr2695232vki.51.1471359076530; Tue, 16 Aug 2016 07:51:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Tue, 16 Aug 2016 07:51:16 -0700 (PDT) In-Reply-To: References: <719DD3BC-83DD-4304-9C00-B72715A0FDA2@rhul.ac.uk> From: Watson Ladd Date: Tue, 16 Aug 2016 07:51:16 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Randomization of nonces X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2016 14:57:09 -0000 On Mon, Aug 15, 2016 at 9:56 PM, Martin Thomson wrote: > On 16 August 2016 at 09:46, Paterson, Kenny wrote: >> Sadly, you can't implement XGCM using an existing AES-GCM API, because of >> the way the MAC (which is keyed) is computed over the ciphertext in the >> standard GCM scheme. > > > Is there a reason why you can't simply XOR the plaintext stream that > is fed to AES-GCM? > > We set N = N XOR HKDF(IKM, salt, label[N], 12), which the paper shows > improves things. If we also set P = P XOR repeat(HKDF(IKM, salt, > label[P], 16)) would we gain any of the advantages of XCAU? That > change could be made without needing a new algorithm. Yes. XOR two adjacent blocks, and you get something that is a function purely of the key. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Aug 16 11:08:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1066E12D12F for ; Tue, 16 Aug 2016 11:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8Je0IglvAzv for ; Tue, 16 Aug 2016 11:08:49 -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 057B012D0E0 for ; Tue, 16 Aug 2016 11:08:48 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id b62so114732922iod.3 for ; Tue, 16 Aug 2016 11:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=O73I0Q8PkQ9t4JKw9PhxxAeboIKg+Pq6iTUJqYWk5sc=; b=QfzwDsOnV/xO2Ys9q+lkQ/jRXLmffbDvtmy5GKTJKwEOezbB4ZmlIvE8fJ0U3hslR4 UArMUY+HxfnlgTO9VDqdqqKni1XoHAXmKTOOd5ODMDav/q5k2BnguMMimupwt2zCkM3X LMFMtz/OWG9tVYtbHvVLdOTR1QghZ3uzENXyA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=O73I0Q8PkQ9t4JKw9PhxxAeboIKg+Pq6iTUJqYWk5sc=; b=UwgLdwtwZmZF0+8p4gq+SbKyxLYIampWJe53VCjh+O9r/202Jcvb1LAi2jsIgQseXv 7XdBI9OdN1IlH4GweZrt9UiyeOWt+Jmn1Hu2lp8cPVAr4YsO7C3GR2zAj2y7RY+FKbOY o8XY9+PvVCO5jlBc5ebVITFGbse1/6W4DlN2KgqMY+apxrNZEa51vn66f+hzBzRduE5s twxFb/JZW6wfJdANhScJoblMewoztMiqxnCk8kJJckUmLmfGG4UFKYMsrkKcYd9grRfm S03A8UJ9clhWMu2rLinOtuHlTHcX8/UWZcAonZnTkPq2sdIJrSYExSIjHuw1g7tjtDp6 fk7g== X-Gm-Message-State: AEkooutmg4BN6B1kmEi2UMuS+SNLrT6wchI3PQJEO9m9SgLJDOvNStMBVlftHFyiztrsh1qyLEsD/WKel9+xD3gq X-Received: by 10.107.52.198 with SMTP id b189mr44412799ioa.6.1471370927814; Tue, 16 Aug 2016 11:08:47 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Tue, 16 Aug 2016 18:08:36 +0000 Message-ID: To: "tls@ietf.org" , EKR Content-Type: multipart/alternative; boundary=001a11440f7e7caacd053a343d84 Archived-At: Subject: [TLS] BoringSSL's TLS test suite X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2016 18:08:51 -0000 --001a11440f7e7caacd053a343d84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi folks, BoringSSL has developed a test harness[1] that consists of a fork of Go=E2= =80=99s crypto/tls package (recently dubbed =E2=80=9CBoGo" at the Berlin hackathon)= plus a test runner that allows BoGo to be run against the TLS stack under test. BoGo can be configured to behave in a number of unexpected ways that violate the TLS standard, thus enabling the testing of many scenarios that would be otherwise difficult to obtain with a standard stack. We (David Benjamin and Eric Rescorla) have been getting it to work with NSS and wanted to let others know in case they might find it useful. This system was initially designed to work with BoringSSL, but in principle can be used with any stack. The portability is still a little rough, and we'll likely make changes as we get more experience here, but it has already been used to test NSS[2] and OpenSSL[3]. We've written up some notes at [4]. The test suite should be fairly extensive for DTLS and TLS 1.2 (giving around 75% line coverage in BoringSSL=E2=80=99s TLS code at last count). It= tests TLS 1.3 as well, though those tests are still in progress. They track BoringSSL=E2=80=99s in-progress TLS 1.3 implementation. David and Eric [1] https://boringssl.googlesource.com/boringssl/+/master/ssl/test/ [2] https://hg.mozilla.org/projects/nss/file/tip/external_tests/nss_bogo_shim [3] https://github.com/google/openssl-tests [4] https://boringssl.googlesource.com/boringssl/+/master/ssl/test/PORTING.md --001a11440f7e7caacd053a343d84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

BoringSSL has deve= loped a test harness[1] that consists of a fork of Go=E2=80=99s crypto/tls = package (recently dubbed =E2=80=9CBoGo" at the Berlin hackathon) plus = a test runner that allows BoGo to be run against the TLS stack under test. = BoGo can be configured to behave in a number of unexpected ways that violat= e the TLS standard, thus enabling the testing of many scenarios that would = be otherwise difficult to obtain with a standard stack. We (David Benjamin = and Eric Rescorla) have been getting it to work with NSS and wanted to let = others know in case they might find it useful.

Thi= s system was initially designed to work with BoringSSL, but in principle ca= n be used with any stack. The portability is still a little rough, and we&#= 39;ll likely make changes as we get more experience here, but it has alread= y been used to test NSS[2] and OpenSSL[3]. We've written up some notes = at [4].

The test suite should be fairly extensive = for DTLS and TLS 1.2 (giving around 75% line coverage in BoringSSL=E2=80=99= s TLS code at last count). It tests TLS 1.3 as well, though those tests are= still in progress. They track BoringSSL=E2=80=99s in-progress TLS 1.3 impl= ementation.

David and Eric

[1] https://boringssl.googlesource.com/boringssl/+/master/ssl/test/<= /div> --001a11440f7e7caacd053a343d84-- From nobody Tue Aug 16 13:34:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFE312D5BF for ; Tue, 16 Aug 2016 13:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.967 X-Spam-Level: X-Spam-Status: No, score=-3.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h317VF_3MyOy for ; Tue, 16 Aug 2016 13:34:37 -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 798E512D769 for ; Tue, 16 Aug 2016 13:34:37 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0FDF7433403; Tue, 16 Aug 2016 20:34:37 +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 ECC33433402; Tue, 16 Aug 2016 20:34:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471379676; bh=6jmsQYVhq3DEYDNDtVVmfPnkKmld6pArUAxGQYokVBY=; l=2283; h=To:References:From:Date:In-Reply-To:From; b=xfwNCY/2S3E7DiRU4LHCYgphqYLOMToRo7iGjBMKXFJpJGU78xTx5MrteMIdmRG+o u/wqE6Q0EeXXwTn50X1PW4cH04PbIkIkAHz9w0fHLe9mmrs2UbXMZz5VIf8a8hf3MF 8TCPLz2TdkAyRqGucknAERobqJF5CgepyqLkT5Vc= 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 B5EA11FC88; Tue, 16 Aug 2016 20:34:36 +0000 (GMT) To: Peter Gutmann , "tls@ietf.org" References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> From: Benjamin Kaduk Message-ID: <0131e121-4a96-6c9f-0c28-fea0519adad4@akamai.com> Date: Tue, 16 Aug 2016 15:34:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------9FB078B366ACADCE622395EB" Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 20:34:49 -0000 This is a multi-part message in MIME format. --------------9FB078B366ACADCE622395EB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/16/2016 05:44 AM, Peter Gutmann wrote: > As far as I can see what this text is saying is that if the client can't guess > in advance which PFS suite/group the server knows about, the server must > disable use of PFS. In other words instead of saying "give me a PFS suite, > preferably with this group", it's saying "give me a PFS suite with exactly > this group and if you can't do that, don't do PFS". This seems like a pretty > awful way to handle things. > Recall that the "perfect" part depends on both sides doing what they're supposed to. And if the server wants to behave badly and is doing a not-named group, it can send something that is not prime, or has small subgroups, etc. -- not all clients will check, so the client is definitely not guaranteed forward secrecy. -Ben --------------9FB078B366ACADCE622395EB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 08/16/2016 05:44 AM, Peter Gutmann wrote:
As far as I can see what this text is saying is that if the client can't guess
in advance which PFS suite/group the server knows about, the server must
disable use of PFS.  In other words instead of saying "give me a PFS suite,
preferably with this group", it's saying "give me a PFS suite with exactly
this group and if you can't do that, don't do PFS".  This seems like a pretty
awful way to handle things.

Recall that the "perfect" part depends on both sides doing what they're supposed to.  And if the server wants to behave badly and is doing a not-named group, it can send something that is not prime, or has small subgroups, etc. -- not all clients will check, so the client is definitely not guaranteed forward secrecy.

-Ben
--------------9FB078B366ACADCE622395EB-- From nobody Tue Aug 16 13:36:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1312D5BF for ; Tue, 16 Aug 2016 13:36: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC5sC7PkrUfo for ; Tue, 16 Aug 2016 13:36:51 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 50F4E126D74 for ; Tue, 16 Aug 2016 13:36:51 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id n59so141297063uan.2 for ; Tue, 16 Aug 2016 13:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C3jNuw/eHJyKoLBUqAp+XMfUxI7uB64etxi5TxiNcTk=; b=yW+jORJENnB2VEGSLO4uFyFLrKgzFV2eUG5EsBWYOPeAcglnCZBbEuV7tiVYVk8yP0 QMudWTeFC4OSn8tBNdyZPT2gdsvcwCQMLCO2s5cjsYn6XV1ArFbzC/g6tZklGwBXNeh1 Urf2POWun4kVykAF8wgnJcf8Gn0SIMLLP4/UBWbX7/WwJ3XNAbJ83BCrPppM9/2ywWBB h9sbQWc06Nh9BgRsGG6Rwo3IDvQMp+EJtLEZ42q4+0zFWHMWxjvfDRLEca2s0LlT8EEk 3t1f3UXA9ZkVIKGaehWaoru0qCx/bb49EX/KVK1SFFhg+qPltio3qlUg/fmz4aIQB+QC w2iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C3jNuw/eHJyKoLBUqAp+XMfUxI7uB64etxi5TxiNcTk=; b=GDAEcWKIINkOKyVxEKlcbfrL6HLGyBx5P2/2Lf00w+tNWdTW7Xr/nQ1K5TVYK/4EcW Ofc66BTY4pHAjfmENc7f1icBkaNknrGpHvCBA4nScfcgXd77THm9fwVYs8aKPrLFbYSu J//plwbIlYihEyeID8dsiJEiyYCwRVH04XggShKdGIhOgmE/YV0cRefQtldVEtxZZ0Rt AUasUJC6H1ujjrOCVXhjQQTHaiIG4RYbrlNRo2JCEuOlQbGacLi9pxNy10zTu6tn4C8X 8haGFEq5YS1QOBI5JCMGO2A9M8hYkdiI1oR36no7NaMfqmXpoh7+P7YEgDL0AiA1qFkW WixA== X-Gm-Message-State: AEkooutFOqB41wccM0G4D5jA9/89PV/Xu+mBEw/kjy71G1EiWj2hPOibC5LsCFohqFB3pjFVTf4CpBL+6E/uqg== X-Received: by 10.176.65.7 with SMTP id j7mr6372392uad.117.1471379810363; Tue, 16 Aug 2016 13:36:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Tue, 16 Aug 2016 13:36:49 -0700 (PDT) In-Reply-To: <0131e121-4a96-6c9f-0c28-fea0519adad4@akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <0131e121-4a96-6c9f-0c28-fea0519adad4@akamai.com> From: Watson Ladd Date: Tue, 16 Aug 2016 13:36:49 -0700 Message-ID: To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 20:36:53 -0000 On Tue, Aug 16, 2016 at 1:34 PM, Benjamin Kaduk wrote: > On 08/16/2016 05:44 AM, Peter Gutmann wrote: > > As far as I can see what this text is saying is that if the client can't > guess > in advance which PFS suite/group the server knows about, the server must > disable use of PFS. In other words instead of saying "give me a PFS suite, > preferably with this group", it's saying "give me a PFS suite with exactly > this group and if you can't do that, don't do PFS". This seems like a > pretty > awful way to handle things. > > > Recall that the "perfect" part depends on both sides doing what they're > supposed to. And if the server wants to behave badly and is doing a > not-named group, it can send something that is not prime, or has small > subgroups, etc. -- not all clients will check, so the client is definitely > not guaranteed forward secrecy. A malicious server can also send the PMS to the Nation State Adversary. Compromised endpoints offer no security. > > -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 Tue Aug 16 16:38:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6F312D6A5 for ; Tue, 16 Aug 2016 16:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87m23ckGqneX for ; Tue, 16 Aug 2016 16:38:27 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (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 BC45B12D179 for ; Tue, 16 Aug 2016 16:38:26 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 4BECA13802C.A1A5D X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 4BECA13802C for ; Wed, 17 Aug 2016 01:38:21 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 4896340AC; Wed, 17 Aug 2016 01:38:21 +0200 (CEST) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 438BD6002E; Wed, 17 Aug 2016 01:38:21 +0200 (CEST) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 3BDF140; Wed, 17 Aug 2016 01:38:21 +0200 (CEST) Received: from 169-231-106-172.wireless.ucsb.edu ([169.231.106.172]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Wed, 17 Aug 2016 01:38:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 16 Aug 2016 16:38:21 -0700 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Atul Luykx To: Watson Ladd In-Reply-To: References: <719DD3BC-83DD-4304-9C00-B72715A0FDA2@rhul.ac.uk> Message-ID: X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99.2 at cobalt X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Randomization of nonces X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Aug 2016 23:38:30 -0000 On 2016-08-16 07:51, Watson Ladd wrote: > On Mon, Aug 15, 2016 at 9:56 PM, Martin Thomson > wrote: >> On 16 August 2016 at 09:46, Paterson, Kenny >> wrote: >>> Sadly, you can't implement XGCM using an existing AES-GCM API, >>> because of >>> the way the MAC (which is keyed) is computed over the ciphertext in >>> the >>> standard GCM scheme. >> >> >> Is there a reason why you can't simply XOR the plaintext stream that >> is fed to AES-GCM? >> >> We set N = N XOR HKDF(IKM, salt, label[N], 12), which the paper shows >> improves things. If we also set P = P XOR repeat(HKDF(IKM, salt, >> label[P], 16)) would we gain any of the advantages of XCAU? That >> change could be made without needing a new algorithm. > > Yes. XOR two adjacent blocks, and you get something that is a function > purely of the key. This is true if N XOR L is made public (where L is the secret value). As long as N XOR L is only used for encryption, and N is the value communicated, then it isn't possible to get a function purely of the key by XORing two adjacent ciphertext blocks, since the block cipher inputs will depend on L. Atul From nobody Wed Aug 17 04:43:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F27F12D91B for ; Wed, 17 Aug 2016 04:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtek8kDsTXjU for ; Wed, 17 Aug 2016 04:43:14 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53BD12D9B3 for ; Wed, 17 Aug 2016 04:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1471433653; x=1502969653; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cma6hEzCCAUJTgF6cNpksUa/aTjWZUkrhashFFia7uc=; b=04lNdKJqre47dR8DEYtosdeL6hBjUhcrjSswOt7zAQDl/3MJJMIgG6Xd 9IopJpWVz6J7yNJExopaajV3MIY/3KXmQRTjYd2RODzuM/ClR8k8xvb9x lfF++RJne2UR2EktV2JhCGb8JXKltU2lpvDJS/mn3ASNrGPgQ3OD32Vo4 3qAly8e0L2q5TjtN9Hbhyxo048v2mVUhFxzcVHKb/fyW3GB7jefNvIIlx JU3J8xGzRJXjbHNOTYQk03RcDghSgDX2o0VNWPAmvllhorpK3s+25qs3h FmgkXTU2mmpNnlXS+/ZIaRhizutsKI6jEPVeoIScytm3gTvgffS+EGmXS A==; X-IronPort-AV: E=Sophos;i="5.28,529,1464609600"; d="scan'208";a="102530104" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Aug 2016 23:34:11 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Wed, 17 Aug 2016 23:34:10 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Thread-Index: AdH3qzVttHomztzDTIKlIRH23NqfIv//fPYAgAIjA00= Date: Wed, 17 Aug 2016 11:34:10 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz>, <20160816145548.GQ4670@mournblade.imrryr.org> In-Reply-To: <20160816145548.GQ4670@mournblade.imrryr.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 11:43:15 -0000 Viktor Dukhovni writes:=0A= =0A= >The client is expected to send a complete list of *all* the groups it=0A= >supports if it supports (any of) the new designated groups. Which means th= at=0A= >clients that support these groups will use only these groups with servers= =0A= >that likewise suppose these groups, and will not use FFDHE when the client= =0A= >group list and the server group list don't overlap (which is seems unlikel= y).=0A= =0A= But the text above says that if the server doesn't support what the client= =0A= asks for, you can't use PFS/DH/FFDHE/whatever you want to call it at all. = I=0A= don't care whether the server does exactly ffdhe2048 or not, I'll take=0A= ffdhe2048 if available, otherwise anything DHE as long as it's over about 1= 536=0A= bits, and for a lot of clients my code is used in, under about 3K bits beca= use=0A= they don't have the CPU for more than that, and in addition don't need that= =0A= level of security. However, what the above text says is that if the server= =0A= can't do exactly ffdhe2048 then it's not allowed to do any DHE at all and h= as=0A= to use RSA.=0A= =0A= >There's no guess, the client sends its full list of supported groups, and = the=0A= >server picks the one it likes.=0A= =0A= ... and if the client doesn't get it exactly right, the server has to fall= =0A= back to RSA rather than use another DHE suite of its choosing.=0A= =0A= Peter.= From nobody Wed Aug 17 09:50:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A293F12DB31 for ; Wed, 17 Aug 2016 09:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaYp7lM0Nxy5 for ; Wed, 17 Aug 2016 09:50:04 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE2D12D685 for ; Wed, 17 Aug 2016 09:50:03 -0700 (PDT) Received: from mail-wm0-f47.google.com ([74.125.82.47]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0MKMb4-1bZVoC1MZy-001k0Y for ; Wed, 17 Aug 2016 18:50:02 +0200 Received: by mail-wm0-f47.google.com with SMTP id i5so244225013wmg.0 for ; Wed, 17 Aug 2016 09:50:02 -0700 (PDT) X-Gm-Message-State: AEkooutyd+lw3wesYU4lnUjxq08pWEyzoYvmREC78aejy0gW9FZtlyiS38OAOg+kEz89BcgdIdQtNW+Jspd4TQ== X-Received: by 10.25.139.135 with SMTP id n129mr7088029lfd.111.1471452601838; Wed, 17 Aug 2016 09:50:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.33.201 with HTTP; Wed, 17 Aug 2016 09:50:00 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> From: Bodo Moeller Date: Wed, 17 Aug 2016 09:50:00 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113fc2f6a30a6c053a47418e X-Provags-ID: V03:K0:6lit9UG8VdN4Gniv3w1XjAMehEzsBgU4UeflPQ5RX+fSms8vSpM NbQ8uwtBomZhcTmnxL1fAWahE/grA42VPStJthB/hYYknkbQeNtjGnZPK8xTrt2tBOxSxKB nB7K1E3LlNkHGkMOPIdDwwhi6pz2vlkPQM6XYW8udS17+UO6B6TYBvAOGvBM9EtS+0makZt oK5Tkrm44HecBamYizrfg== X-UI-Out-Filterresults: notjunk:1;V01:K0:xsAJFmPDTvk=:k26SqrUJ/GpqdEPggjsUCu XVAtW609wfcoqP86BIKOidmocxWrb+JDH01NevJAixACC+bxpmez8EGf3ElmwesQEd7//2Tfd UzHYkwBvHnRj00C2gXUWDNQWafHOSJ8p1NSfOUyXVntnW51r8SUrWcASYVW/1FQ+m7l4QDTzo pP81kf5pZEf7injYe9FnB4g6Zm2iAZ9MxVNN2QTIMXvOjMbKPKUgpnFpWDwZoOc2KDLAt7hEI IsAWe01O3OZA7ZVrjyr1WZTJRvwPmkvdLglAGVyEYD+AR6sSWV+bvrokX94m2dYoEuYbbrrO2 0BoMQW6rBVVgwOsoabmKWRBETZgwWrZ7uT+1kQuBNOn7T8viDX1jBO5iQBifc5z/PqEbHW9jN baolNILvl49WhTtU5sR+TaiacGj8tPM0WC7+rUC+ELuOnASEuTNAeHPN2yKPx72f6/AX/2Dqq yCzdlzDOu+jygVdUBVlDkPg6XxcEYkCy7J752v3zUg06f/PH9CCVcOCVrykDRF1qXaACjSGxi crY4g5FMVDrnF41yeBDK8PD0NAMSluYSolOXbu2SYck7lkC9tvrILXJmOyp6CcmMysfnMtYeU vXkQNWh536UWD8XNNiPcW70wU1d740mu5mOcRsZ3R8AjlKj+qLV1475fcImDy2Kp8VTMSLVJp z6BTGtlHEED2KEjanLsplOoQDT+tp/O9HxZFEAbAP1dbsBYMBJptgPvSkamHcdiwA7lmeG89R H2w5uoT3eiTLnU8D Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 16:50:06 -0000 --001a113fc2f6a30a6c053a47418e Content-Type: text/plain; charset=UTF-8 Peter, so your complaint is about the lack of support for explicitly specified (non-"named") groups? That's completely intentional, see the RFC's abstract. (It *shouldn't* be that much of a problem that the server might be using a ill-chosen group, because if the server does dumb things we can't save it anyway. However, given all the complexities of the TLS handshake, there's actually more that can fall apart if the group is bad.) Bodo --001a113fc2f6a30a6c053a47418e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pete= r, so your complaint is about the lack of support for explicitly specified = (non-"named") groups? That's completely intentional, see the = RFC's abstract. (It *shouldn't* be that much of a problem that the = server might be using a ill-chosen group, because if the server does dumb t= hings we can't save it anyway. However, given all the complexities of t= he TLS handshake, there's actually more that can fall apart if the grou= p is bad.)

Bodo

--001a113fc2f6a30a6c053a47418e-- From nobody Wed Aug 17 14:31:04 2016 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1582C12D799; Wed, 17 Aug 2016 14:30:58 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147146945808.23788.9425861240254855670.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 14:30:58 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-15.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:30:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-15.txt Pages : 113 Date : 2016-08-17 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-15 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 Wed Aug 17 14:47:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC0212D7A3 for ; Wed, 17 Aug 2016 14:47:38 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dhtaBKtei92 for ; Wed, 17 Aug 2016 14:47:35 -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 E885212D7A0 for ; Wed, 17 Aug 2016 14:47:35 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 95B5033D213; Wed, 17 Aug 2016 21:47:35 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> From: Geoffrey Keating Date: 17 Aug 2016 14:47:35 -0700 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> Message-ID: Lines: 16 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] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:47:38 -0000 Peter Gutmann writes: > Viktor Dukhovni writes: > > >There's no guess, the client sends its full list of supported > >groups, and the server picks the one it likes. > > ... and if the client doesn't get it exactly right, the server has to fall > back to RSA rather than use another DHE suite of its choosing. I believe that's the intention; the assumption is that the client using this extension doesn't want DHE parameters that it doesn't have configured, it only wants one of a pre-validated list of groups/generators. It especially doesn't want the server to say "well, I know the client listed only groups 2048-bit and higher, but I have this 512-bit group, let's use that". From nobody Wed Aug 17 14:50:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0266A12D7A3 for ; Wed, 17 Aug 2016 14:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WteK2KY-OFDQ for ; Wed, 17 Aug 2016 14:50:34 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1365C12D0E5 for ; Wed, 17 Aug 2016 14:50:34 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id r187so289357ybr.0 for ; Wed, 17 Aug 2016 14:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6a+B+rTXz5pw6idtCgcNpuT5l1D9gwxJfZVU7jUTunk=; b=HYNfkrLQ8gguI7HxMjGMJIuFpXTa+Wddb/DVKdATaL/YGWV7ct7EC+TSjabwI5Axhc Pxo4p6AzDYjvdi4oH1oju+1OoXtQhB9uGiwOlJR4K3WGfVOYBelHjup4D4GDod+m15DD uplfH3BYEwPBCXKG0gbvAjFU2UT16JFYxL6Q1Uoa9Y9wwJDGTLqQEg4UWhCcjrCel5sE aCoNdhJze9KpG1ij/0WgBUIiLmxeuky6Rlpz879hnvPf57/V8yVU5gssrlZ3cU2+jpiX as/mfbVNVnICX9rVBKhtRZRsNmd/o8nWXGUmNm9koqFb1ErFLc12zk7yRWo9a/ouNqpx 3XZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6a+B+rTXz5pw6idtCgcNpuT5l1D9gwxJfZVU7jUTunk=; b=lwnNcSnpqvATwDthVVBLKkRYSiQ3NZWjEtiUn0i8zbeRJZXsWPCq71LuFGVF9p8/DS 3VlZdffhqfQA4YsQcEWLAQQbe6gDu4xlGwveRT5d8gwbk2IaeiTa7FDmEQTkr/NcgUyD OXlgO/Nv71UCejivSR4+MpOAVR9U8wLnuHFTeAkW9keT+9h8YY+Y3m9DB2CNMD0LNhiB YAIeX+a0kGan2pjJl0IsgMzRwlE3DEDkW/7Ghg+M1TcfAOHUR86woFd8jZOq5VkoFQko EXSUyCDzG+iaxvq8pACus9etiBBhNqEDf008Eqigww1s7m5WAhunZ+QOTwC7v8PnDF1t kh4Q== X-Gm-Message-State: AEkoouswivjfcbrOt+TAqrtnDxI/c0x0+LRA9mgYAXdjLugQ5Zf3nCy0OuxYpGAgtqsOFlRTk1STjb6Xjmzupg== X-Received: by 10.37.211.9 with SMTP id e9mr16815244ybf.74.1471470633140; Wed, 17 Aug 2016 14:50:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Wed, 17 Aug 2016 14:49:52 -0700 (PDT) From: Eric Rescorla Date: Wed, 17 Aug 2016 14:49:52 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c147dcc62f059053a4b744e Archived-At: Subject: [TLS] draft-ietf-tls-tls13-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2016 21:50:36 -0000 --94eb2c147dcc62f059053a4b744e Content-Type: text/plain; charset=UTF-8 Folks, I've just submitted draft-ietf-tls-tls13-15. The major change in this document is the new negotiation syntax as discussed in Berlin. There are also a number of small tweaks (see ChangeLog below). Remaining significant issues: #588: The computation of the resumption context with external PSKs. Also, connected with this, should we require that the client prove knowledge of the PSK when offering a PSK. #443: 0-RTT with server signing. This is possible with the new syntax but I didn't specify it in #15. #580: receive_generation for KeyUpdate [CHAIRS: please bring to closure] Also a few smaller ones I will be bringing to the list shortly. Note to implementors: NSS is currently at draft-14 (Firefox is at draft-13). We intend to implement draft-15 immediately (hopefully in the next week) and would welcome interop testing with anyone who is interested. As usual, comments welcome. -Ekr - New negotiation syntax as discussed in Berlin (*) - Require CertificateRequest.context to be empty during handshake (*) - Forbid empty tickets (*) - Forbid application data messages in between post-handshake messages from the same flight (*) - Clean up alert guidance (*) - Clearer guidance on what is needed for TLS 1.2. - Guidance on 0-RTT time windows. - Rename a bunch of fields. - Remove old PRNG text. - Explicitly require checking that handshake records not span key changes. --94eb2c147dcc62f059053a4b744e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I've just submitt= ed draft-ietf-tls-tls13-15.

The major change in th= is document is the new negotiation syntax as
discussed in Berlin.= There are also a number of small tweaks (see
ChangeLog below).

Remaining significant issues:

<= div>#588: The computation of the resumption context with external PSKs.
=C2=A0 =C2=A0 =C2=A0 Also, connected with this, should we require th= at the client
=C2=A0 =C2=A0 =C2=A0 prove knowledge of the PSK whe= n offering a PSK.

#443: 0-RTT with server signing.= This is possible with the new syntax
=C2=A0 =C2=A0 =C2=A0 but I = didn't specify it in #15.

#580: receive_genera= tion for KeyUpdate [CHAIRS: please bring to closure]

Also a few smaller ones I will be bringing to the list shortly.


Note to implementors:
NSS is curr= ently at draft-14 (Firefox is at draft-13). We intend to
implemen= t draft-15 immediately (hopefully in the next week) and would
wel= come interop testing with anyone who is interested.

As usual, comments welcome.

-Ekr

<= /div>
- New negotiation syntax as discussed in Berlin (*)
- Require CertificateRequest.context to be empty during handsha= ke (*)

- Forbid empty tickets (*)

- Forbid application data messages in between post-handshake messa= ges
=C2=A0 from the same flight (*)

- Cl= ean up alert guidance (*)

- Clearer guidance on wh= at is needed for TLS 1.2.

- Guidance on 0-RTT time= windows.

- Rename a bunch of fields.
- Remove old PRNG text.

- Explicitly = require checking that handshake records not span
=C2=A0 key chang= es.

--94eb2c147dcc62f059053a4b744e-- From nobody Wed Aug 17 14:50:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BD812D0E5 for ; Wed, 17 Aug 2016 14:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytc2c6l68zse for ; Wed, 17 Aug 2016 14:50:48 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93A012D7C0 for ; Wed, 17 Aug 2016 14:50:43 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id f6so3546220ith.0 for ; Wed, 17 Aug 2016 14:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MTvNbKMRvLM41pbIw4TXG3w09RVw12bEBMYNes8Ed1o=; b=qLEDiFA7OViPu3bVG7MzSAVH5UFLvdKyOXVaqVGknlQHdAm7FJQ61KDa3u3Zedpqtd KbUmD95hQyZFQlDOK6nVFF+uEaCkhpUBDuCC5eQR24Ig8Mn5u4sss53Je5lvLRPI+ITB kSO5OWq6PIm5qstPkqzgDtx2dLzRrOsfA5Uo2jCuh3qtWbAERPGDMEAddRwaC6XkrVPq Mr6duNc4h9uUcKM+DHBQgX7V8VADtpjJDd9NcVwhm4RDfEMC+qyU+1jTTOEx1MdD2841 98+pqMiGQt722YPlAGZLRJzytrEqcdlgqgXx/QfTzeeoRZ4JcWaJzPULFrq5IeY4jA59 9EAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MTvNbKMRvLM41pbIw4TXG3w09RVw12bEBMYNes8Ed1o=; b=mOFwQqZc9vgmNPcNTpYI2Nz6XwNqIB9Jp/5GrEBp4Ia6VBd3FhKgFXUzh0buexckqM RquRfCYMwNKbXz02Cu0sG66SufQeNmKORTrGG0nCfmD3a6mw3naJbZOtbU1i7G2jmSfF FMSb5/Y51i5gIb5ng8NMEikOdT20iIVagAGiji7n8d5HCLzWCkfulKDqeYRg6NBrSRvt rUNMnArCOrjjT147LrLLPTVfqulMS9X7EW7UYn1KINwG6CS6IGy/QSsmxrEWtp11d29A ZeH5tBQ9ZWu8JWdCJRmargLbWjiO86vQAGsiHMIlyGwkEG09Ca6/+4DMJKcSTocv6s2F rg6A== X-Gm-Message-State: AEkoouvCPpC5BUFZd+WUr4+oy9H0AMLH9AQy3V5IC4EwYmxZt8M8bOQpl01XhFHwRPJ9vreJJp/NVJjVIHcuKQ== X-Received: by 10.36.139.129 with SMTP id g123mr22914613ite.0.1471470642995; Wed, 17 Aug 2016 14:50:42 -0700 (PDT) MIME-Version: 1.0 References: <20160806172605.fqgtphnurlqzxfpo@LK-Perkele-V2.elisa-laajakaista.fi> <20160808061413.ylqaytfxxckted4j@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: Nick Sullivan Date: Wed, 17 Aug 2016 21:50:32 +0000 Message-ID: To: Martin Thomson , Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c04b39af92aa8053a4b7424 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-sullivan-tls-post-handshake-auth-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:50:51 -0000 --94eb2c04b39af92aa8053a4b7424 Content-Type: text/plain; charset=UTF-8 Is there any support for either of the following ideas: 1) moving the OCSP and SCT server extensions to inside the Certificate message 2) removing post-handshake client authentication from TLS 1.3 in favor of dedicated and more detailed draft On Sun, Aug 7, 2016 at 11:42 PM Martin Thomson wrote: > On 8 August 2016 at 16:14, Ilari Liusvaara > wrote: > > In 2, I would imagine the context is probably usually a sequence > > number of some kind. > > The draft defines some rules for construction of identifiers that > prevent collisions and the like. > > >> Good question. Errors in encoding or otherwise problems following the > >> rules in the spec should result in a connection-level fatal error. > >> But if the certificate isn't trusted, handling that will be up to the > >> application. > > > > And that should presumably be communicated somehow... > > Of course. See > https://github.com/grittygrease/tls13-post-handshake-auth/issues/18 > (feel free to contribute) > > > Being able for application to to wait for certificate/cv/finised > > message to be sent, so it can do something special in application > > layer immediately after that. > > Sure. The usual async API guarantees apply here; I don't know that > this needs special treatment in the spec though. If you disagree, I'm > sure that my coauthors would be happy to take suggestions for > improvements. > --94eb2c04b39af92aa8053a4b7424 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there any support for either of the following idea= s:

1) moving the OCSP and SCT server extensions to inside= the Certificate message
2) removing post-handshake client authent= ication from TLS 1.3 in favor of dedicated and more detailed draft

<= br>

On Sun, Aug 7, 201= 6 at 11:42 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 8 August 2016 at 16:14, Ilari Liusvaara <ilariliusvaara@welho.com> w= rote:
> In 2, I would imagine the context is probably usually a sequence
> number of some kind.

The draft defines some rules for construction of identifiers that
prevent collisions and the like.

>> Good question.=C2=A0 Errors in encoding or otherwise problems foll= owing the
>> rules in the spec should result in a connection-level fatal error.=
>> But if the certificate isn't trusted, handling that will be up= to the
>> application.
>
> And that should presumably be communicated somehow...

Of course.=C2=A0 See
https://github.com/grittygrease/t= ls13-post-handshake-auth/issues/18
(feel free to contribute)

> Being able for application to to wait for certificate/cv/finised
> message to be sent, so it can do something special in application
> layer immediately after that.

Sure.=C2=A0 The usual async API guarantees apply here; I don't know tha= t
this needs special treatment in the spec though.=C2=A0 If you disagree, I&#= 39;m
sure that my coauthors would be happy to take suggestions for
improvements.
--94eb2c04b39af92aa8053a4b7424-- From nobody Wed Aug 17 15:10:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4691B12D7B6 for ; Wed, 17 Aug 2016 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvhTtNhO_jWr for ; Wed, 17 Aug 2016 15:10:32 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67E612B025 for ; Wed, 17 Aug 2016 15:10:32 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id u134so679048ywg.3 for ; Wed, 17 Aug 2016 15:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=T4v4V5pIM8si1hJw1T8hmRVqqZgB3816QNZAQa3RTSM=; b=ywhMbF6S7o6hDR8YRKTeU1VEmx8NeAreGYsUsNbmYnVHdJRjOrs+TL4J6g7SHHpBEb 9mvqRaXlTz4RADt+Yy4QzjYXc7Y+pNUhcj7oZX3rrD/p5OS4WJOodUYF05zH9oyW+GJT jswDLqzzdVxW+wIlVPoGUaGlKH7oa+zhJ416Couoeh9H011krNxCxlYs8Ac10pSOBKkd vAHFTnWIVe9EtN4rz0y2LolvV8WEymirHvrVsh1yAEE2q/7mQ36h7ePsZoPHYawi1xrx XDEB5Guj5GVW7OggdCnkqJ5HxVKTKxoygiyJjgcD4v95HSxC/J8zNiJejaP4JcgOOcuo lwkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=T4v4V5pIM8si1hJw1T8hmRVqqZgB3816QNZAQa3RTSM=; b=fMG2ZEnsd/A7gKaLV5hAoNpbq+/nRN2ksCxyupiRe2Xd4N6tKJk2q3rnnD7InKmqB1 c3ECqHkuK+tiPIbbxyP7SE09oJ0ugqwyVjFWdc7PQrxUXSxLX6Zhd7ROlygIalf/xYp7 CaLjtoDSAJyESLJgyULfbFFTMcCvP5T57jR3FQHIJ9iZqRM5uodLQk6Gu1DViY0WNgT7 n3hjw0Tl//raNRgHw6FkYzf3B22NDrqd7U8u2gl8sxhl2imxUsiTCsz24o9zblrkrO04 B9I5Sp/kva+lUS1lSO/7+6izRs1EqVILKhFbgYb4MtBfBMZICvdKFkVkzUvqBlc7erxx e1Dw== X-Gm-Message-State: AEkoout5/yF5lUt/egVGnNDssiwddT/f6THWa99E1lK2h8Vrx62trlGl0JUvf+Gead9/oOR0lF9wQ0AKI1Kmcw== X-Received: by 10.13.244.197 with SMTP id d188mr31682843ywf.276.1471471831892; Wed, 17 Aug 2016 15:10:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Wed, 17 Aug 2016 15:09:51 -0700 (PDT) From: Eric Rescorla Date: Wed, 17 Aug 2016 15:09:51 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c086548d67863053a4bbb26 Archived-At: Subject: [TLS] Issue 555: Generate IVs in one HKDF invocation? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2016 22:10:34 -0000 --94eb2c086548d67863053a4bbb26 Content-Type: text/plain; charset=UTF-8 Issue: https://github.com/tlswg/tls13-spec/issues/555 ADL suggested that we could slightly reduce the number of HKDF computations by generating the IVs as a single block rather than with individual HKDF-Expands. You can't generally do this kind of slice-and-dice and preserve the key boundary, but IVs are public anyway. At least for NSS, this makes things slightly more complicated because we generate the directional traffic keys independently, but it's also not a big deal to change if people want. Comments in favor or against? --94eb2c086548d67863053a4bbb26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Issue:

ADL suggested that we could slightly reduce = the number of HKDF
computations by generating the IVs as a single= block rather than
with individual HKDF-Expands. You can't ge= nerally do this kind
of slice-and-dice and preserve the key bound= ary, but IVs are
public anyway.

At least= for NSS, this makes things slightly more complicated
because we = generate the directional traffic keys independently,
but it's= also not a big deal to change if people want.

Com= ments in favor or against?










--94eb2c086548d67863053a4bbb26-- From nobody Wed Aug 17 15:18:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6EB12D0D9 for ; Wed, 17 Aug 2016 15:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rysXXuF1rW3U for ; Wed, 17 Aug 2016 15:18:00 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 4D6C812D0FB for ; Wed, 17 Aug 2016 15:17:55 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id e31so426604ybi.3 for ; Wed, 17 Aug 2016 15:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qqJLARmchcv+04G0AHUNqJ2lYMEw41iaBzyVN1OamDk=; b=A9JqQw/4mw5srrDvNmMkbFHc/6Fv3E6eHbWMkK3t98vdX4SKJZ8ZnOvdiTNHZT4xtY TWqR3XGwd6TnTGsmwyaGjj25b+HlrXNlg3fzFxsbh209xBoklE8XqRFCXwdI45ZDaD8g aqqoDik2lnqL3pjRDeWAw+NsW1b2mP+DkYWMjyVB53ZzsM7tZqOqtDloh7Bfmcgld1t6 Qth6qnwF5iriPC1tBD4MhVnKy5F407HBXjq+YDLOPLK8s6ophAWu+EvvORyMNo3JzhNJ FL3H8VmAZMN2sc6Ecw1arCtxuuZeTjVq4ygPfzVKKgzM5jg5lFmjpyz/UWyEFjXQ55Ck 13mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qqJLARmchcv+04G0AHUNqJ2lYMEw41iaBzyVN1OamDk=; b=FrOYsEEWXaUXUpE3C8RRNUXGx0lmpGZXZuA2KtPYmGD7UwzO8lA1CVJXPtP/LUMO1Y sm9X+DLawDy5SBKHbxtQ+mMYj9N/YRROWexT7Osr08JW1F/fQKTSS6wqcAdRlMXVqUvD nR2jz0QMQIkgauWS2aGN8NCcNpOR20QK5Eukts5Am1j5+uuuGr6QY7fMJ7vOtuOt4EX+ wZQwqumFgK+AWHRu5PabTJKO+NckWovoYKqjpcWoNr7nb1bM+EzKoFS4E9a7SIFdvoZf OPQjIOwDf+4hA3jlo5bBsLLllljefefsyWcj5fjHx9bsQQuzqMrJLfqoKuOLtGjsuXfq uxeQ== X-Gm-Message-State: AEkoousw1OkkOIRA49K9d78bdRdcTmBqDr16Tihq5rpBU7z6Kjp4Z03rk7BQ7KFiv8IKpQ0icxLaul3PANRoFw== X-Received: by 10.37.203.7 with SMTP id b7mr2365251ybg.162.1471472274632; Wed, 17 Aug 2016 15:17:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Wed, 17 Aug 2016 15:17:14 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 17 Aug 2016 15:17:14 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=94eb2c05a3be3a30a2053a4bd689 Archived-At: Cc: "" Subject: Re: [TLS] Pre_shared_key Extension Question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:18:01 -0000 --94eb2c05a3be3a30a2053a4bd689 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The intention here was to compensate for not having psk_identity_hint. However, it also allows you to do resumption of PSK-established sessions. It would be a fairly significant simplification to say you could only have one PSK, because then we could easily require the client to prove knowledge of the key, for instance by stuffing a MAC at the end of the ClientHello as we discussed in Berlin. So: Is there any demand for multiple identities? I do not believe there is any in the Web context. If not, we should remove this feature. -Ekr On Thu, Aug 11, 2016 at 1:39 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > the currently defined =E2=80=9Cpre_shared_key=E2=80=9D extension allows c= lients to send > a list of the identities. I was wondering in what use cases this is > useful and what policy guides the server to pick the most appropriate > psk identity. I couldn't find any discussion in the document about this > aspect. > > Ciao > Hannes > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c05a3be3a30a2053a4bd689 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The intention here was to compensate for not having psk_id= entity_hint. However, it also allows you to do resumption of PSK-establishe= d sessions.

It would be a fairly significant simplificat= ion to say you could only have one PSK, because then we could easily requir= e the client to prove knowledge of the key, for instance by stuffing a MAC = at the end of the ClientHello as we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not = believe there is any in the Web context. If not, we should remove this feat= ure.

-Ekr


On Thu, Aug 11, 2016 at 1:3= 9 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
Hi all,

the currently defined =E2=80=9Cpre_shared_key=E2=80=9D extension allows cli= ents to send
a list of the identities. I was wondering in what use cases this is
useful and what policy guides the server to pick the most appropriate
psk identity. I couldn't find any discussion in the document about this=
aspect.

Ciao
Hannes


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


--94eb2c05a3be3a30a2053a4bd689-- From nobody Wed Aug 17 15:52:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB09F12B016 for ; Wed, 17 Aug 2016 15:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU8QbxfW9XZj for ; Wed, 17 Aug 2016 15:52:55 -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 99CF912D0AC for ; Wed, 17 Aug 2016 15:52:55 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id b62so4868478iod.3 for ; Wed, 17 Aug 2016 15:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZsbPyLqj7SAx+fvvgPr3+S8yGKP8tl5ldNyYoZBCd0c=; b=YKrDf3aou+9Ygju1pB8cGPAQsCdn/6cxji5IC1s+9PLGEboJtlPRI1OnXJJ38sRpYG YS/lLqxT87szeQn/bLUlD9kKrqmbl5TivLZ1KeFfGvmkC8O6sXuYC7qLehZtkH8ylzuS DqF7YP7Nzgr99ZnKQkZwqGL/He8w2iuMnXHvI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZsbPyLqj7SAx+fvvgPr3+S8yGKP8tl5ldNyYoZBCd0c=; b=Z7D1euxv4xtljoOfjAkYitTEdu+u2bxugomG0vS42bFzKXF6JKiBjBPsyFnGqPBURN aISFUJXJDx+M2Vg2IuxRj84DUBdOTlghGvi5btPhd8CagQHhKuY3JPJ87HFobCfOctVo /TKhcFQMKWH3SlqWyMdIuG4loDuedZwfez5CgvpF8ewyyyRpEwERNuy3HTjaN97c363J MP5OzUI35afBqx+jjFuBzgq/8eqBOPD97/sguRXBYRz2DVWvi4PVly8LAjHZXe0hyPaI kG9k7k5ivbQatr+kMiDHwYzILgyPdyOV8tyf1T9D1ljFmOBnu+UHOfIJERwpt5Gx6pIE IDEw== X-Gm-Message-State: AEkoousnb3mYasM4fBpP7lKwxsPoT9YlWRatmZbuuFe9iKtGydf9jiHC2lJGCqY9TRzoDzTlssdin7wyDoETfAO+ X-Received: by 10.107.3.70 with SMTP id 67mr54819850iod.97.1471474374813; Wed, 17 Aug 2016 15:52:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 17 Aug 2016 22:52:43 +0000 Message-ID: To: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113fb72a689ed3053a4c53bb Archived-At: Subject: Re: [TLS] Issue 555: Generate IVs in one HKDF invocation? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2016 22:52:57 -0000 --001a113fb72a689ed3053a4c53bb Content-Type: text/plain; charset=UTF-8 In general one has to generate the directional traffic keys independently due to read/write epochs changing at different times, so I'd prefer it left as is. (In BoringSSL, we also generate the directional keys independently. I'd often wished that TLS 1.2 was the same.) The switch from handshake to traffic_secret_0 happens at different points because the key change happens immediately after Finished on both sides (this is important otherwise a server alert on bad client certificate is unreadable). From traffic_secret_N to traffic_secret_N+1 is similarly asymmetric because of KeyUpdate skew. Not that it's a huge deal either way. David On Wed, Aug 17, 2016 at 6:10 PM Eric Rescorla wrote: > Issue: > https://github.com/tlswg/tls13-spec/issues/555 > > ADL suggested that we could slightly reduce the number of HKDF > computations by generating the IVs as a single block rather than > with individual HKDF-Expands. You can't generally do this kind > of slice-and-dice and preserve the key boundary, but IVs are > public anyway. > > At least for NSS, this makes things slightly more complicated > because we generate the directional traffic keys independently, > but it's also not a big deal to change if people want. > > Comments in favor or against? > > > > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113fb72a689ed3053a4c53bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In general one has to generate the directional traffic key= s independently due to read/write epochs changing at different times, so I&= #39;d prefer it left as is. (In BoringSSL, we also generate the directional= keys independently. I'd often wished that TLS 1.2 was the same.)
<= br>
The switch from handshake to traffic_secret_0 happens at diff= erent points because the key change happens immediately after Finished on b= oth sides (this is important otherwise a server alert on bad client certifi= cate is unreadable). From traffic_secret_N to traffic_secret_N+1 is similar= ly asymmetric because of KeyUpdate skew.

Not that it'= ;s a huge deal either way.

David

On Wed, Aug 17, 2016 at 6:10 PM Eric Resc= orla <ekr@rtfm.com> wrote:
Issue:

<= /div>
ADL suggested that we could slightly reduce the number of HKDF
computations by generating the IVs as a single block rather than
with individual HKDF-Expands. You can't generally do this kind<= /div>
of slice-and-dice and preserve the key boundary, but IVs are
public anyway.

At least for NSS, this makes = things slightly more complicated
because we generate the directio= nal traffic keys independently,
but it's also not a big deal = to change if people want.

Comments in favor or aga= inst?










_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113fb72a689ed3053a4c53bb-- From nobody Wed Aug 17 16:08:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5887F12D0F6 for ; Wed, 17 Aug 2016 16:08:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63GU5lDgzG_z for ; Wed, 17 Aug 2016 16:08:43 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C2112B074 for ; Wed, 17 Aug 2016 16:08:42 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id f6so4772780ith.0 for ; Wed, 17 Aug 2016 16:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OV4kZNpzl/3gXMOLZdjCXTvqe56A37RH+z0U8g1Vxbk=; b=vjQD6iK+UJH2jy2lGD0NvL+ah5iSTVdJ6kFyRAeU5qpaIzVmCYo5qv8hMfZcar0oAg iLDCDD0YHH7ZrKIhQGjocQ8o13mlT5a3ymMRs/72GEdI1O9Wl9NGAqcfQ6Um/8vN+u+F LQbV28GYQyj55SlsGt+GS2NtbeKEe5L7emxFGsuWTIT/0X+VxSoRdE1j8z4+RErlo+bV WvNQlUCYgDYCoS9FRBNJQiDtDYEnNN6y9chupArDnkV5u+tsKQblAhkWhPX3LNxmu3OK zaa/MVrd7wsxDL2OdnoM07h5Fmjldxz2CwiDAzIzMWjaZTDwI4S2eq7qYt5YoVzEmF/7 I2wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OV4kZNpzl/3gXMOLZdjCXTvqe56A37RH+z0U8g1Vxbk=; b=GqcqbETUr924ms1SNrqCZnzDznpkgIsE+K/3Qzoi0NzkGWIl+BnHrv7Ez/nogEDFF5 Lo2FvywgH7gJRyOtpWXoUWNW4AGumnaWKFUE1520fAZsEKgbdiZMtR+uNU1x4woOSErq DarA+bm3P5Dd3OSNPe2YH8LDmClKrFzklaeas1+WFr3ig3mS2oivtyDfRkbST8qNiBbM zeJzsjc0oYd1fUcLPWh95MGrM4GehxJGldB4YxLBK2MWML0zSJvUzInE90B+ZBAcTKSk I6XdwebPegQhJUHCnRoEh20z7esWemt2/Qyf6H4563tidJrDqqyhxHtH84VPl71o5k7B +eHg== X-Gm-Message-State: AEkooutmIqEu2Qmdwo8Wvq+FblyRCmu4847FqJ0vQzzNGYer2ZtMlQN9z82VyB11HsSZIqsRhy0LnmeXFicMhw== X-Received: by 10.36.31.18 with SMTP id d18mr32135095itd.64.1471475322347; Wed, 17 Aug 2016 16:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.74.73 with HTTP; Wed, 17 Aug 2016 16:08:41 -0700 (PDT) In-Reply-To: References: From: Brian Smith Date: Wed, 17 Aug 2016 13:08:41 -1000 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Issue 555: Generate IVs in one HKDF invocation? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2016 23:08:44 -0000 Eric Rescorla wrote: > Issue: > https://github.com/tlswg/tls13-spec/issues/555 > > ADL suggested that we could slightly reduce the number of HKDF > computations by generating the IVs as a single block rather than > with individual HKDF-Expands. You can't generally do this kind > of slice-and-dice and preserve the key boundary, but IVs are > public anyway. When you say "IV," what are you referring to? Definitely the original intent of my proposal to use client_write_iv and server_write_iv is that they would remain secret. I suspect that some analysis might be simplified by assuming that they are publicly-known as a worst-case scenerio, but that's different than them being "public", and we should design things assuming that we're trying to keep them private. Cheers, Brian -- https://briansmith.org/ From nobody Wed Aug 17 16:48:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB4912D151 for ; Wed, 17 Aug 2016 16:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kJDwdW9QEzc for ; Wed, 17 Aug 2016 16:48:29 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3128412D0B2 for ; Wed, 17 Aug 2016 16:48:29 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id d10so960710ybi.1 for ; Wed, 17 Aug 2016 16:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hq+pAP3Ob+qwcDE3uUyhh+8k+QOkVpPN4/RefMyuFmg=; b=vVp2dinfjV8rwiUQ4+/npqDljvl6otf4xNO3+OAkMwCmxS4CvuA8ZmlcGqNhGdMPXm lmhXJWXC1kfS/zg4TiEzsgtY36OXTZPdAGSTVxHx81CHaJEtxLd8JEWb32QJJu+FYc1g PBzqRgFGZiHdpH7/tV8QqTTxqI9ktrTN44blDSfu4FU7W4GBIwRdNB+VvPwJUoESgaIo gEFsomX5bkpc4A7LzG93mwbZaSKRSwn/wEc86xzXnV6FgIo+MPXErGs9nkEOW3wEZdqG MDCiCLogVTDMmcTwy5Xi/jZqv7E96aJEI4/2dpPvrHefb5Qvkvn42ftU42tPqneIrBSn Exog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hq+pAP3Ob+qwcDE3uUyhh+8k+QOkVpPN4/RefMyuFmg=; b=Mvt0IYXJOvI8GsdB4OAUa+Di/6qiRQZuN/SXynHAOVH4PCvXjpmi7YWI9cVm9BkVSe SjvD3VFywkuCt4wMlWx1CixDoKKtO8HQwSeaCGJCTRHgQQ7j0ePguQRa/oaShQq25HnV 5tYyh2UAslycf44iQlmYhMAoXWAb9qlQQqCxs9gYgtldwGUiJq552p2QUzLeC1sh6BjL u/6nbMNjI5S3/sMAyMgrXqp6wiPGvgPbhdtx+T37Bui4mCMMoYZZJa8qUkEtT151QX/5 cnmuQ9RUmS7Qz5n216xuUzf9x7ZpAIur59nxGwOF9+TkGHfqfgAUU2sNudjYqZz0Q2JS 1ONQ== X-Gm-Message-State: AEkoouuy2qV7NwiUUrFhDESR5sWm5EM8PL60q27mmH8ufvcYSqXyMcGyvJkcz7NogWf8vxPgrK+/DWTwPa2lhQ== X-Received: by 10.37.160.99 with SMTP id x90mr30115858ybh.130.1471477708498; Wed, 17 Aug 2016 16:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Wed, 17 Aug 2016 16:47:48 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 17 Aug 2016 16:47:48 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=94eb2c19831e1c56f3053a4d1a5a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Issue 555: Generate IVs in one HKDF invocation? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2016 23:48:31 -0000 --94eb2c19831e1c56f3053a4d1a5a Content-Type: text/plain; charset=UTF-8 On Wed, Aug 17, 2016 at 4:08 PM, Brian Smith wrote: > Eric Rescorla wrote: > > Issue: > > https://github.com/tlswg/tls13-spec/issues/555 > > > > ADL suggested that we could slightly reduce the number of HKDF > > computations by generating the IVs as a single block rather than > > with individual HKDF-Expands. You can't generally do this kind > > of slice-and-dice and preserve the key boundary, but IVs are > > public anyway. > > When you say "IV," what are you referring to? Definitely the original > intent of my proposal to use client_write_iv and server_write_iv is > that they would remain secret. I suspect that some analysis might be > simplified by assuming that they are publicly-known as a worst-case > scenerio, but that's different than them being "public", and we should > design things assuming that we're trying to keep them private. > Sorry, that's bad writing on my part. I meant they should be kept private but that in practice, PKCS#11 and similar implementations almost certainly don't have support for TLS 1.3-style AES-GCM and therefore you'll have to let the IV out of the tamper boundary at least for the foreseeable future. -Ekr > > Cheers, > Brian > -- > https://briansmith.org/ > --94eb2c19831e1c56f3053a4d1a5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 17, 2016 at 4:08 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Er= ic Rescorla <ekr@rtfm.com> wrote:=
> Issue:
>=C2=A0 =C2=A0https://github.com/tlswg/tls13-s= pec/issues/555
>
> ADL suggested that we could slightly reduce the number of HKDF
> computations by generating the IVs as a single block rather than
> with individual HKDF-Expands. You can't generally do this kind
> of slice-and-dice and preserve the key boundary, but IVs are
> public anyway.

When you say "IV," what are you referring to? Definitely t= he original
intent of my proposal to use client_write_iv and server_write_iv is
that they would remain secret. I suspect that some analysis might be
simplified by assuming that they are publicly-known as a worst-case
scenerio, but that's different than them being "public", and = we should
design things assuming that we're trying to keep them private.

Sorry, that's bad writing on my part. I mea= nt they should be kept private but
that in practice, PKCS#11 and = similar implementations almost certainly don't
have support f= or TLS 1.3-style AES-GCM and therefore you'll have to let
the= IV out of the tamper boundary at least for the foreseeable future.

-Ekr
=C2=A0

Cheers,
Brian
--
ht= tps://briansmith.org/

--94eb2c19831e1c56f3053a4d1a5a-- From nobody Wed Aug 17 21:29:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B660F12D176 for ; Wed, 17 Aug 2016 21:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tmypHfSoRq5 for ; Wed, 17 Aug 2016 21:29:32 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 3F03912B00B for ; Wed, 17 Aug 2016 21:29:32 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id x131so17509750ite.0 for ; Wed, 17 Aug 2016 21:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=WBCrkeCUlAzPR/6qWbsCZKAlsytEyB3EKXA+fw/CgCE=; b=ise4/qryKieNeHkS3lgh1hrsB4E0fPtcOM0HjncKXhh21t/Yj+/A11VAsDNZwMXJB+ IE/WNnKukLIY4471H/JdNN7cdqOgHGm7xj2Vm9uU++taexYW8/WEgdk156c4TbwrmEPQ Tq9m/OKqp/MY5qW1WiT1LtgOWAsH40hPxzsB4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WBCrkeCUlAzPR/6qWbsCZKAlsytEyB3EKXA+fw/CgCE=; b=Gm88rDozsoF0IXCRk0bXpatCU5/kmhexMAyR841KKBpxRV708bASENaB/W3Ed6YlPg tmhZdAnUwCC0ugSqp3PW6Urvq6Ni2wNyWTEQVBiRznmYlVQYdpg9iEo2XGn4vDa0aN0e YNzV3V5xBcyEX8kqEY71ukOmQNaU1wE1/m/IEdJpEXOhbzUPh0q/tFFxEAiwFW0OSasQ BLFEGFk/Z6xx5g5X3wgIkvx0XPSbSIeCKUAG7J3kEYpl2yUwcvzSMjeJArIOBC1I0A0E 3n9gtDRSPOOi8/2QEZ4nQCmmdCJHOHNv7Ur/ULcmg+/RC8qIsw/+QCkCkZBPRwl45paq LH5w== X-Gm-Message-State: AEkoousKKvZoI3OW+AAd/DtJWXAcs5axfSkVhM0LvAJfUru6YHjbVjmN8vvFaAzveqejqHUhjAyjUxTrxJpM+u+a X-Received: by 10.36.189.143 with SMTP id x137mr880382ite.18.1471494571157; Wed, 17 Aug 2016 21:29:31 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Thu, 18 Aug 2016 04:29:19 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c19c026344761053a5107ac Archived-At: Subject: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 04:29:35 -0000 --94eb2c19c026344761053a5107ac Content-Type: text/plain; charset=UTF-8 Amusingly, Keith and I appear to have crossed mid-air in our respective requests to change KeyUpdate, so this will be a fun collision. Mine is a tad larger of a change I'm afraid. We've currently implemented KeyUpdate in our in-progress TLS 1.3 code, but we've for now ignored the requirement for the receiver to send KeyUpdates to catch up with the sender. It appears that honoring that will cause significant problems. A TLS stack does not know much of the read/write patterns of the higher-level application. It must handle all kinds of flows, so a dumb filter is ideal. Some TLS APIs are even structured around this. Rather than consume and provide a socket interface, they encrypt and decrypt buffers, leaving transport business to the consumer. (And socket-based APIs are often used as if they were filters using buffers for sockets.) We may then have transport reads progress faster than transport writes, or the write channel may not even be driven most of the time. (This isn't that contrived. Unpipelined HTTP/1.1 never reads and writes in parallel. HTTP/2 may not have any response to write. Or perhaps it is processing a request while an earlier response is still being written.) The receiver can then accrue KeyUpdate obligations unboundedly. When the write channel is active again, it has to dump all those out as unbounded write overhead. This is rather a mess. There should be a tight bound (one, if not zero) on KeyUpdate obligations. I'm unclear on exactly what parts of KeyUpdate the WG finds important, so I haven't written a concrete PR yet. But here is roughly the fix I have in mind: Sending one KeyUpdate and 1,000 in a row morally should be the same. But both ends share a KeyUpdate track, so any forward secrecy goals require matching generations. So branch client-write and server-write first and have two KeyUpdate ladders starting at client_traffic_secret_0 and server_traffic_secret_0. (Note bidi KeyUpdate is asynchronous, so implementations had to store separate read and write traffic secrets anyway.) As a small bonus, we can lose the client/server split from traffic key calculations (7.3), having branched at traffic secret already. However, we lose the "free" (really at the cost of this unboundedness problem) generation-based bidirectional KeyUpdate sync. Depending on what we want out of KeyUpdate, I can imagine a few options: - Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate every N records or so and leave it at that. (I think this is the best option on grounds of simplicity, assuming it meets the primary needs of KeyUpdate.) - If you receive a KeyUpdate and didn't send one in the last N minutes (where N minutes >>> 1 RTT), (optionally?) flag your next write to be preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to prevent ping-ponging. - Variations on sticking a please_echo boolean in the KeyUpdate message, generation counts, etc., to get synchronization with coalescing if we need it. I would much prefer the simpler options unless we truly need this. (KeyUpdate is right now a *required* feature, so simplicity should be a priority. Rare use cases are what extensions are for.) Thoughts? David PS: We've seen this before with renego (I've seen many OpenSSL consumers which lock up if the peer renegotiation), error alerts triggered on reads (often they don't get sent), and close_notify (also don't get sent in practice). Deviations from dumb filters are expensive. PPS: I'm wary of over-extending post-handshake auth for the same reason, though I haven't had time to look carefully at the latest proposal yet. Still, having TLS specify and analyze the crypto while lifting the actual messages into application-level framing would be preferable for these sorts of side protocols. The application gets to make assumptions about read/write flows and knows in which contexts what is and isn't allowed. --94eb2c19c026344761053a5107ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Amusingly, Keith and I appear to have crossed mid-air= in our respective requests to change KeyUpdate, so this will be a fun coll= ision. Mine is a tad larger of a change I'm afraid.

<= div>We've currently implemented KeyUpdate in our in-progress TLS 1.3 co= de, but we've for now ignored the requirement for the receiver to send = KeyUpdates to catch up with the sender. It appears that honoring that will = cause significant problems.

A TLS stack does not k= now much of the read/write patterns of the higher-level application. It mus= t handle all kinds of flows, so a dumb filter is ideal. Some TLS APIs are e= ven structured around this.=C2=A0Rather than consume and provide a socket i= nterface, they encrypt and decrypt buffers, leaving transport business to t= he consumer. (And socket-based APIs are often used as if they were filters = using buffers for sockets.)

We may then have trans= port reads progress faster than transport writes, or the write channel may = not even be driven most of the time. (This isn't that contrived. Unpipe= lined HTTP/1.1 never reads and writes in parallel. HTTP/2 may not have any = response to write. Or perhaps it is processing a request while an earlier r= esponse is still being written.) The receiver can then accrue KeyUpdate obl= igations unboundedly. When the write channel is active again, it has to dum= p all those out as unbounded write overhead. This is rather a mess. There s= hould be a tight bound (one, if not zero) on KeyUpdate obligations.

I'm unclear on exactly what parts of KeyUpdate = the WG finds important, so I haven't written a concrete PR yet.=C2=A0Bu= t here is roughly the fix I have in mind:

Sending = one KeyUpdate and 1,000 in a row morally should be the same. But both ends = share a KeyUpdate track, so any forward secrecy goals require matching gene= rations. So branch client-write and server-write first and have two KeyUpda= te ladders starting at client_traffic_secret_0 and server_traffic_secret_0.= =C2=A0(Note bidi KeyUpdate is asynchronous, so implementations had to stor= e separate read and write traffic secrets anyway.) As a small bonus, we can= lose the client/server split from traffic key calculations (7.3), having b= ranched at traffic secret already.

However, we los= e the "free" (really at the cost of this unboundedness problem)= =C2=A0generation-based bidirectional KeyUpdate sync. Depending on what we w= ant out of KeyUpdate, I can imagine a few options:

- Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate= every N records or so and leave it at that. (I think this is the best opti= on on grounds of simplicity, assuming it meets the primary needs of KeyUpda= te.)

- If you receive a KeyUpdate and didn't s= end one in the last N minutes (where N minutes >>> 1 RTT), (option= ally?) flag your next write to be preceded by KeyUpdate. This is simple but= needs an ad-hoc timeout to prevent ping-ponging.

= - Variations on sticking a please_echo boolean in the KeyUpdate message, ge= neration counts, etc., to get synchronization with coalescing if we need it= . I would much prefer the simpler options unless we truly need this.=C2=A0(= KeyUpdate is right now a *required* feature, so simplicity should be a prio= rity. Rare use cases are what extensions are for.)

Thoughts?

David

PS: We've seen this before with renego = (I've seen many OpenSSL consumers which lock up if the peer renegotiati= on), error alerts triggered on reads (often they don't get sent), and c= lose_notify (also don't get sent in practice).=C2=A0Deviations from dum= b filters are expensive.

PPS: I'm wary of over= -extending post-handshake auth for the same reason, though I haven't ha= d time to look carefully at the latest proposal yet. Still, having TLS spec= ify and analyze the crypto while lifting the actual messages into applicati= on-level framing would be preferable for these sorts of side protocols. The= application gets to make assumptions about read/write flows and knows in w= hich contexts what is and isn't allowed.
--94eb2c19c026344761053a5107ac-- From nobody Wed Aug 17 22:24:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97D212D0FD for ; Wed, 17 Aug 2016 22:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUdY3UwBUGKn for ; Wed, 17 Aug 2016 22:24:18 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1017412B015 for ; Wed, 17 Aug 2016 22:24:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 98DABF568; Thu, 18 Aug 2016 08:24:16 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id TW2wIq5QwTdx; Thu, 18 Aug 2016 08:24:16 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id F4160C4; Thu, 18 Aug 2016 08:24:15 +0300 (EEST) Date: Thu, 18 Aug 2016 08:24:07 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160818052407.e7fmkszcooymqdrg@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.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Issue 555: Generate IVs in one HKDF invocation? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 05:24:21 -0000 On Wed, Aug 17, 2016 at 03:09:51PM -0700, Eric Rescorla wrote: > Issue: > https://github.com/tlswg/tls13-spec/issues/555 > > ADL suggested that we could slightly reduce the number of HKDF > computations by generating the IVs as a single block rather than > with individual HKDF-Expands. You can't generally do this kind > of slice-and-dice and preserve the key boundary, but IVs are > public anyway. Except that actually usefully make IVs public (without it just being pointless disclosure), you would need MRAE, which is strictly stronger notion that AE(AD) required by TLS. Neither GCM nor Poly1305 are MRAE (and I don't think CCM is either). Basically, doing generic encryption with AEAD is not possible. One needs protocol-specific knowledge. This is because of the disaster that repeating nonce is. TLS 1.3 protocol-level prevention of duplicate nonces does not help any here. > At least for NSS, this makes things slightly more complicated > because we generate the directional traffic keys independently, > but it's also not a big deal to change if people want. And yes, this makes code that generates the directions independently (which is reasonable thing to do even for simple implementation) quite much more annoying, as one needs to slice the IV buffer. I don't also expect this to improve performance any: The code will probably still generate directions independently, not saving the other half of the IV, so it needs to be recomputed when the other direction is computed. So complicates code for no actual benefit. -Ilari From nobody Wed Aug 17 22:26:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D9412D53C for ; Wed, 17 Aug 2016 22:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSqxN7RzJtNk for ; Wed, 17 Aug 2016 22:26:31 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id B71AE12B015 for ; Wed, 17 Aug 2016 22:26:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 8415A102F0; Thu, 18 Aug 2016 08:26:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id PI3fl3wDq6oP; Thu, 18 Aug 2016 08:26:30 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5A0ACC4; Thu, 18 Aug 2016 08:26:30 +0300 (EEST) Date: Thu, 18 Aug 2016 08:26:22 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160818052622.zim6nxwwqw3hzmr6@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.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-tls13-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 05:26:33 -0000 On Wed, Aug 17, 2016 at 02:49:52PM -0700, Eric Rescorla wrote: > Folks, > > I've just submitted draft-ietf-tls-tls13-15. Doing brief review: - Section 4.2.2 talks EdDSA using "ECDSA cipher suites". TLS 1.3 does not have those. However, this kind of information is very relevant for TLS 1.2 backward compatiblity: you need to assign TLS 1.2 cipher suites for EdDSA in order to use it in TLS 1.2. TLS 1.3 does not care either way. - I note that accepting PSK and selecting the auth mode seem to be in separate messages, which seems quite annoying implementation- wise.. - Can the server send arbitrary certificate in response to PSK or is it somehow restricted? The document does not seem to talk about it. - The HelloRetryRequest is problematic in pure-PSK case[1]. [1] One way to do it would be to move the group to extension, which would only be sent if new group was needed. Then one could always require at least one extension (the field could also be renamed). Also, one could make it so that HRR extensions don't have to correspond to CH extensions (and unsupported one is a fatal error). -Ilari From nobody Thu Aug 18 00:30:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2564612D6AE for ; Thu, 18 Aug 2016 00:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw9k3YioqlgW for ; Thu, 18 Aug 2016 00:30:44 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C15A12B011 for ; Thu, 18 Aug 2016 00:30:44 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id d10so3147159ybi.1 for ; Thu, 18 Aug 2016 00:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vlEiNJILF91RwDf+UuZzDHYsKS3NJ4N8HwyrLFcmCCo=; b=WM1k2vZPbyE0nujaXcBSctvfrSLVX4sJN5hG1HHq0qFyTJtovmOz9LcwQaGTAN3Vck lZfJybL4cDCr1xK3qitDF+K+tsIzOSALWwb94pSjoWyB7wfH20aRkITdqVDlSJSksG2i M+bVpMke/L07eQ01YAybpXn7OENy3Vh/7ft7BfC1aLrsKZK3zADTcIVNNg09+pLjGZbG rAUVuCaMNwoVjegg305+6kzPkA7Fj5/wPMqfNomre2SGK2jP3dhd49mz/uB035GpPCkL PENIpkjzTUmlk7bVpAdBOngtgyBbX4l/45M5+p8SngXkl3z2TnU1OzVzwoLlStSbt+QV qfGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vlEiNJILF91RwDf+UuZzDHYsKS3NJ4N8HwyrLFcmCCo=; b=GZgBC//kroKiQ6CIUFXW1yyuMCnbtpl3IlnZa4jgxM7J8pWnJDMOcjXwEH2dLqnSU5 K/84LC/hQXRwk7qwBgG39gTcmjiuRnRalU1cze2XvYcWKiAumnLyNQNBglJ5FgjZN74A gSsqs+SVzkJaSUjABQbuH4t3Q2I6G8TBcTOb7LGuIG08iOaDgayk7fCY0YhHT7YEwlR3 +kmU+y0IqxKDBFDsEMo5sO3Btg3m3bfiWRetAwmhiFbVYQqco3XsHNWSvd3iPrnN3ACI 83jUJIj2h6LgOI8rWQlalAej2/BQfH6i0fc2uma7iLxWv/rV+eINf+yNbhl7O1x8T6rz vBRA== X-Gm-Message-State: AEkoous982emPWH71WYYobRn64pBMpkQ/2Yhd+XUz8nntcp11bhK4caFqW7XDtNo9JbtKdBCiO9oNel9QYipnQ== X-Received: by 10.37.79.87 with SMTP id d84mr492532ybb.165.1471505443804; Thu, 18 Aug 2016 00:30:43 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Thu, 18 Aug 2016 00:30:03 -0700 (PDT) In-Reply-To: References: From: Keith Winstein Date: Thu, 18 Aug 2016 00:30:03 -0700 X-Google-Sender-Auth: h-kgKTUADoZfxESnf3kSl07513s Message-ID: To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 07:30:47 -0000 I think it's probably possible to make everybody happy here. I appreciate the need to avoid allowing the other side to create an unbounded deferred write/compute obligation. I also think it's valuable to preserve the ability for "either side to force an update to the entire connection," and obviously I think it's valuable for the initiating side to get an ack that that has happened (hence PR #426/#580). To mitigate the unboundedness issue, what would you think about this option: 1) Keep everything the same as the current draft, but 2) Add this text: "An implementation MUST NOT advance its current sending generation to be greater than its current receiving generation plus one." That would be it. If an implementation reads a KeyUpdate that attempts to advance the receiving generation to be greater than the sending generation plus one, it may abort because the other side has behaved in an invalid manner. I think this eliminates any unbounded deferred write obligation. The KeyUpdates would still be asynchronous, but after sending one, an implementation would not be able to send another until it received one from the other side -- and whether that KeyUpdate is triggered by its own KeyUpdate, or generated independently, wouldn't matter. (Of course we also want our PR #580 to be able to resolve that ambiguity, but these can be basically orthogonal issues.) -Keith On Wed, Aug 17, 2016 at 9:29 PM, David Benjamin wrote: > Amusingly, Keith and I appear to have crossed mid-air in our respective > requests to change KeyUpdate, so this will be a fun collision. Mine is a tad > larger of a change I'm afraid. > > We've currently implemented KeyUpdate in our in-progress TLS 1.3 code, but > we've for now ignored the requirement for the receiver to send KeyUpdates to > catch up with the sender. It appears that honoring that will cause > significant problems. > > A TLS stack does not know much of the read/write patterns of the > higher-level application. It must handle all kinds of flows, so a dumb > filter is ideal. Some TLS APIs are even structured around this. Rather than > consume and provide a socket interface, they encrypt and decrypt buffers, > leaving transport business to the consumer. (And socket-based APIs are often > used as if they were filters using buffers for sockets.) > > We may then have transport reads progress faster than transport writes, or > the write channel may not even be driven most of the time. (This isn't that > contrived. Unpipelined HTTP/1.1 never reads and writes in parallel. HTTP/2 > may not have any response to write. Or perhaps it is processing a request > while an earlier response is still being written.) The receiver can then > accrue KeyUpdate obligations unboundedly. When the write channel is active > again, it has to dump all those out as unbounded write overhead. This is > rather a mess. There should be a tight bound (one, if not zero) on KeyUpdate > obligations. > > I'm unclear on exactly what parts of KeyUpdate the WG finds important, so I > haven't written a concrete PR yet. But here is roughly the fix I have in > mind: > > Sending one KeyUpdate and 1,000 in a row morally should be the same. But > both ends share a KeyUpdate track, so any forward secrecy goals require > matching generations. So branch client-write and server-write first and have > two KeyUpdate ladders starting at client_traffic_secret_0 and > server_traffic_secret_0. (Note bidi KeyUpdate is asynchronous, so > implementations had to store separate read and write traffic secrets > anyway.) As a small bonus, we can lose the client/server split from traffic > key calculations (7.3), having branched at traffic secret already. > > However, we lose the "free" (really at the cost of this unboundedness > problem) generation-based bidirectional KeyUpdate sync. Depending on what we > want out of KeyUpdate, I can imagine a few options: > > - Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate every > N records or so and leave it at that. (I think this is the best option on > grounds of simplicity, assuming it meets the primary needs of KeyUpdate.) > > - If you receive a KeyUpdate and didn't send one in the last N minutes > (where N minutes >>> 1 RTT), (optionally?) flag your next write to be > preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to prevent > ping-ponging. > > - Variations on sticking a please_echo boolean in the KeyUpdate message, > generation counts, etc., to get synchronization with coalescing if we need > it. I would much prefer the simpler options unless we truly need this. > (KeyUpdate is right now a *required* feature, so simplicity should be a > priority. Rare use cases are what extensions are for.) > > Thoughts? > > David > > PS: We've seen this before with renego (I've seen many OpenSSL consumers > which lock up if the peer renegotiation), error alerts triggered on reads > (often they don't get sent), and close_notify (also don't get sent in > practice). Deviations from dumb filters are expensive. > > PPS: I'm wary of over-extending post-handshake auth for the same reason, > though I haven't had time to look carefully at the latest proposal yet. > Still, having TLS specify and analyze the crypto while lifting the actual > messages into application-level framing would be preferable for these sorts > of side protocols. The application gets to make assumptions about read/write > flows and knows in which contexts what is and isn't allowed. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Aug 18 02:02:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFE512D0EA for ; Thu, 18 Aug 2016 02:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW_ki14dPVxQ for ; Thu, 18 Aug 2016 02:02:38 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA7212B058 for ; Thu, 18 Aug 2016 02:02:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 5F25CEBF5; Thu, 18 Aug 2016 12:02:36 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id XsB3ALx5Bl6V; Thu, 18 Aug 2016 12:02:36 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 84AA9289; Thu, 18 Aug 2016 11:53:16 +0300 (EEST) Date: Thu, 18 Aug 2016 11:53:07 +0300 From: Ilari Liusvaara To: Keith Winstein Message-ID: <20160818085306.dp2nxe7stz5qtnv6@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.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 09:02:40 -0000 On Thu, Aug 18, 2016 at 12:30:03AM -0700, Keith Winstein wrote: > I think it's probably possible to make everybody happy here. > > I appreciate the need to avoid allowing the other side to create an > unbounded deferred write/compute obligation. I also think it's > valuable to preserve the ability for "either side to force an update > to the entire connection," and obviously I think it's valuable for the > initiating side to get an ack that that has happened (hence PR > #426/#580). > > To mitigate the unboundedness issue, what would you think about this option: > > 1) Keep everything the same as the current draft, but > 2) Add this text: "An implementation MUST NOT advance its current > sending generation to be greater than its current receiving generation > plus one." That wouldn't work very well in highly asymmetric situations. One could add rule that allows rekeys in excess of that limit if RSN is above some threshold. Such RSN thresholds would greatly slow down KeyUpdate spam (e.g. reaching 2^32 takes 84GB at minimum). Also, for DTLS, one would need limits like this to avoid exessive key updating. -Ilari From nobody Thu Aug 18 05:33:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4401F12DBDD for ; Thu, 18 Aug 2016 05:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35CnaYkMdX5g for ; Thu, 18 Aug 2016 05:33:06 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B827712DB19 for ; Thu, 18 Aug 2016 05:30:15 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id r187so4850621ybr.0 for ; Thu, 18 Aug 2016 05:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xrbGW3VwS4Um4b5gVPoHWMESQmTyRQqzde/nJzQvedQ=; b=CvV24V/dclU9h/cv1DzLb4t6FCcAmBAVo9ZebL4p2IVpNj0dYGoVFXtI/+XLvDVmN9 9bv2F/zyRc55F8EoiSzkfMC8POVR+3b1+8uPVAdr44/xXUShIE8p6js7N/TPsFeBBz03 HWerTPZalBVxnDhb0v3AvnYjK1tlpvqhqKokE6y9Q7V/xtMpWLbUCu+2LmDIgtPPV2WO DI7UO+0Z/ss1HYOQm8UecBdXNFajIYhA8cYdPxLbrxm7B+6XhQwZ/Tva2xaGj6LEhQUB fzOeZCo8+AYGhQ3ZAP42wW0QqU3p1UME66Y+05id1jZQyIrPRyQK+kK27if9CpU1yFcN KGXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xrbGW3VwS4Um4b5gVPoHWMESQmTyRQqzde/nJzQvedQ=; b=dxnu0Y7DF+29OtUMtqHKnc/DY/NWskx4isNF1SsS4a1LQ5YVPK6x36h4t8WS4JWuHJ /8SyG1/+WJSdV4x5otGaHBFHty1ZbKP6CoSN6JTslWOtTqZy1KNRf/w1TJEgsGM0h7of 219nCjZ20naOifu+W//RW4hJCjCLyBFWCzSZCl48JTeN/D3CSqelAyryE4iDv04obkCq Jo2XxJWhG80szM6+EuWeg10kR5iQRIUvHv/Bs1uUX8X51a4fnjyuTGb4A04SI3MHJhaz PuS8sfkbOtJQA2cLvFdzBYnB5tcFt+RE8rIdF/PuWL6Q5G4DJTE4NZRr03hw12v/Hdxp rXsg== X-Gm-Message-State: AEkoouuK3dDYmSWxaGJCsnSZ6NUEzGkzRBQEMH4Yd7w64zmRzpIvkgo/7wiH+xXa/TBtKnJhyApLoc5gAxaESw== X-Received: by 10.37.216.67 with SMTP id p64mr1297595ybg.146.1471523414985; Thu, 18 Aug 2016 05:30:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Thu, 18 Aug 2016 05:29:34 -0700 (PDT) In-Reply-To: <20160818052622.zim6nxwwqw3hzmr6@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160818052622.zim6nxwwqw3hzmr6@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 18 Aug 2016 05:29:34 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114fd33a6e0368053a57be2d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-tls13-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 12:33:10 -0000 --001a114fd33a6e0368053a57be2d Content-Type: text/plain; charset=UTF-8 Thanks for the quick review. On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara wrote: > On Wed, Aug 17, 2016 at 02:49:52PM -0700, Eric Rescorla wrote: > > Folks, > > > > I've just submitted draft-ietf-tls-tls13-15. > > Doing brief review: > > - Section 4.2.2 talks EdDSA using "ECDSA cipher suites". TLS 1.3 does > not have those. However, this kind of information is very relevant > for TLS 1.2 backward compatiblity: you need to assign TLS 1.2 > cipher suites for EdDSA in order to use it in TLS 1.2. TLS 1.3 does > not care either way. > Thanks. Will try to fix. - I note that accepting PSK and selecting the auth mode seem to be > in separate messages, which seems quite annoying implementation- > wise.. Can you elaborate on this? The intend is that they both appear in ServerHello (in pre_shared_key and signature_algorithms respectively). - Can the server send arbitrary certificate in response to PSK or is > it somehow restricted? The document does not seem to talk about it. > The document right now is supposed to be PSK XOR server signs, so the answer is supposed to be "no". If/when we allow both together, then we'll have to address this, which is a bit tricky. > > - The HelloRetryRequest is problematic in pure-PSK case[1]. > > > [1] One way to do it would be to move the group to extension, which > would only be sent if new group was needed. Then one could always > require at least one extension (the field could also be renamed). > Also, one could make it so that HRR extensions don't have to > correspond to CH extensions (and unsupported one is a fatal error). > Agreed on both counts. PR wanted. https://github.com/tlswg/tls13-spec/issues/560 -Ekr > > > > -Ilari > --001a114fd33a6e0368053a57be2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= ks for the quick review.

On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Wed, Aug 17, 2016 at 02:49:52PM -0700,= Eric Rescorla wrote:
> Folks,
>
> I've just submitted draft-ietf-tls-tls13-15.

Doing brief review:

- Section 4.2.2 talks EdDSA using "ECDSA cipher suites". TLS 1.3 = does
=C2=A0 not have those. However, this kind of information is very relevant =C2=A0 for TLS 1.2 backward compatiblity: you need to assign TLS 1.2
=C2=A0 cipher suites for EdDSA in order to use it in TLS 1.2. TLS 1.3 does<= br> =C2=A0 not care either way.

Thanks. Wil= l try to fix.


- I note that accepting PSK and selecting the auth mode seem to be
=C2=A0 in separate messages, which seems quite annoying implementation-
=C2=A0 wise..

Can you elaborate on this? Th= e intend is that they both appear in ServerHello
(in pre_shared_k= ey and signature_algorithms respectively).


- Can the server send arbitrary certificate in response to PSK or is
=C2=A0 it somehow restricted? The document does not seem to talk about it.<= br>

The document right now is supposed to b= e PSK XOR server signs, so the
answer is supposed to be "no&= quot;. If/when we allow both together, then
we'll have to add= ress this, which is a bit tricky.

=C2=A0

- The HelloRetryRequest is problematic in pure-PSK case[1].


[1] One way to do it would be to move the group to extension, which
would only be sent if new group was needed. Then one could always
require at least one extension (the field could also be renamed).
Also, one could make it so that HRR extensions don't have to
correspond to CH extensions (and unsupported one is a fatal error).

Agreed on both counts. PR wanted.
= https://github.com/tlswg/tls13-spec/issues/560

<= /div>
-Ekr
=C2=A0



-Ilari

--001a114fd33a6e0368053a57be2d-- From nobody Thu Aug 18 05:48:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF58212DD35 for ; Thu, 18 Aug 2016 05:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YnRNCVTD34a for ; Thu, 18 Aug 2016 05:48:05 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8312DD6C for ; Thu, 18 Aug 2016 05:46:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id B51F9FD6D; Thu, 18 Aug 2016 15:46:11 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id sk8P8LKq6XrU; Thu, 18 Aug 2016 15:46:10 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 76B362315; Thu, 18 Aug 2016 15:46:10 +0300 (EEST) Date: Thu, 18 Aug 2016 15:46:02 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160818124602.syi2whfbrom7xfi6@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160818052622.zim6nxwwqw3hzmr6@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.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-tls13-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 12:48:08 -0000 On Thu, Aug 18, 2016 at 05:29:34AM -0700, Eric Rescorla wrote: > Thanks for the quick review. > > On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara > wrote: > > - I note that accepting PSK and selecting the auth mode seem to be > > in separate messages, which seems quite annoying implementation- > > wise.. > > > Can you elaborate on this? The intend is that they both appear in > ServerHello > (in pre_shared_key and signature_algorithms respectively). Eeh, I thought it was in EncryptedExtensions. Reading the text again, it is IMO really unclear where it goes. Checking the extension table, it says "Client". Which impiles that servers don't send it, but 4.2.2 says servers must send it in some cases. > > - Can the server send arbitrary certificate in response to PSK or is > > it somehow restricted? The document does not seem to talk about it. > > > > The document right now is supposed to be PSK XOR server signs, so the > answer is supposed to be "no". If/when we allow both together, then > we'll have to address this, which is a bit tricky. Then why does that server signature_algorithms exist? I think that special PSK authentication modes should be specified in the PSK extension, so non-PSK clients don't get confused and do inapporiate things with those indications. > > - The HelloRetryRequest is problematic in pure-PSK case[1]. > > > > > > [1] One way to do it would be to move the group to extension, which > > would only be sent if new group was needed. Then one could always > > require at least one extension (the field could also be renamed). > > Also, one could make it so that HRR extensions don't have to > > correspond to CH extensions (and unsupported one is a fatal error). > > > > Agreed on both counts. PR wanted. > https://github.com/tlswg/tls13-spec/issues/560 David Bejamin already posted a PR about that. Doesn't clearly say that unknown reason handling. -Ilari From nobody Thu Aug 18 05:56:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4EE12DC6A for ; Thu, 18 Aug 2016 05:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGm5Qp48DAWb for ; Thu, 18 Aug 2016 05:55:57 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227CB12DC48 for ; Thu, 18 Aug 2016 05:55:57 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id u134so9007372ywg.3 for ; Thu, 18 Aug 2016 05:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fWFuzNa9HuMgRK5qvasaPh1DIkQc1BQ4nnaz5Bi0vtI=; b=2FsoSnYcSRZ1/B92vt64Cs25uvS/J36HvXHRPjeAtEHTVeCXUiJYstMuo7fNbiHoMs kaTCojd8dxWHNSZQ0nAC8a7o6MJWu3Pfm/izBIyUnU5XawQqIjegymRgqDV7YU2QjCZJ xeXfqzzVJft9wxhLlqtR9njy9RQzbH49joYnU84/DfWNKiXyvKy9k8ysG7z3zTp3q9EJ GyALv3RZvTDJVWuWdi3mmkYmG3mD0l1sQsYhsv+kOJ/EHJSC6NJA87mgs4LQXdYaA7Yp G7FA4ZEyCBoD84HSsVXnZXbScLyGKCG8g3KVAawQ05s/alBdfGX9wg1IJFN/0l7uT5e+ PoXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fWFuzNa9HuMgRK5qvasaPh1DIkQc1BQ4nnaz5Bi0vtI=; b=SDe0lLEbvKzQYXya6JAbbA7kVdLwYsZixRZslFJjLQfOPMp9DbJuSlaZRFV0mbVeSu qeJhK1JLhdRivqduXCDCXPTVEoZwEMo7rcggxLr8PJunqWeYw0xzchKacgvM2E5xonnP QM+sqTcaVMpzu4Nthtlf4mNuftZGEuRp/gVqnd1wP27lxc0xZxlv6OCfUSe6b9bBw/wm kN0vyxHnzjS52LwkcQ00zMpgdbxkxMsLjf8jRRXXO4/XbHcw3eOlY87sCaA0dtuuP7hd 69hX2pftB8He2VaYnUSZfW/2FvCfaJCwtSzlOmaxCt3Q0W4ARcKcSr2Tp7LNhAPQPdzY gVZA== X-Gm-Message-State: AEkooust1CaQpHHf+qE7CmL3wiQDQ3XvQkKvV6Arwlui5fMBwG6HVwtlHQ/XIHlswZZ4T3haiK7tXbzjKXpqSw== X-Received: by 10.129.92.215 with SMTP id q206mr1525386ywb.8.1471524956456; Thu, 18 Aug 2016 05:55:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Thu, 18 Aug 2016 05:55:16 -0700 (PDT) In-Reply-To: <20160818124602.syi2whfbrom7xfi6@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160818052622.zim6nxwwqw3hzmr6@LK-Perkele-V2.elisa-laajakaista.fi> <20160818124602.syi2whfbrom7xfi6@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 18 Aug 2016 05:55:16 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114d85ce4ef785053a581a43 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-tls13-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 12:55:59 -0000 --001a114d85ce4ef785053a581a43 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 5:46 AM, Ilari Liusvaara wrote: > On Thu, Aug 18, 2016 at 05:29:34AM -0700, Eric Rescorla wrote: > > Thanks for the quick review. > > > > On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > - I note that accepting PSK and selecting the auth mode seem to be > > > in separate messages, which seems quite annoying implementation- > > > wise.. > > > > > > Can you elaborate on this? The intend is that they both appear in > > ServerHello > > (in pre_shared_key and signature_algorithms respectively). > > Eeh, I thought it was in EncryptedExtensions. Reading the text > again, it is IMO really unclear where it goes. > > Checking the extension table, it says "Client". Which impiles that > servers don't send it, but 4.2.2 says servers must send it in some > cases. > Agreed. Table fail. Anyway, if it goes anywhere (see below) it should go in ServerHello. That was the intent for this draft. > - Can the server send arbitrary certificate in response to PSK or is > > > it somehow restricted? The document does not seem to talk about it. > > > > > > > The document right now is supposed to be PSK XOR server signs, so the > > answer is supposed to be "no". If/when we allow both together, then > > we'll have to address this, which is a bit tricky. > > Then why does that server signature_algorithms exist? I think that > special PSK authentication modes should be specified in the PSK > extension, so non-PSK clients don't get confused and do inapporiate > things with those indications. > Can you elaborate on what you mean here? If it's what I think you mean (namely put it in the server's pre_share_key message) I used to have that and davidben convinced me this was better. There's no perfect encoding here, AFAICT, so if you want to make an alternate suggestion that we could take a look at, that would be great. > > > - The HelloRetryRequest is problematic in pure-PSK case[1]. > > > > > > > > > [1] One way to do it would be to move the group to extension, which > > > would only be sent if new group was needed. Then one could always > > > require at least one extension (the field could also be renamed). > > > Also, one could make it so that HRR extensions don't have to > > > correspond to CH extensions (and unsupported one is a fatal error). > > > > > > > Agreed on both counts. PR wanted. > > https://github.com/tlswg/tls13-spec/issues/560 > > David Bejamin already posted a PR about that. Doesn't clearly say > that unknown reason handling. > Yeah, I read the list before the PRs. I'll take a look but if you want to comment that would be great. -Ekr > > > -Ilari > --001a114d85ce4ef785053a581a43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 18, 2016 at 5:46 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Thu, Aug 18, 2016 at 05:29:34AM -0700, Eric Rescorla wrote: > Thanks for the quick review.
>
> On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> - I note that accepting PSK and selecting the = auth mode seem to be
> >=C2=A0 =C2=A0in separate messages, which seems quite annoying impl= ementation-
> >=C2=A0 =C2=A0wise..
>
>
> Can you elaborate on this? The intend is that they both appear in
> ServerHello
> (in pre_shared_key and signature_algorithms respectively).

Eeh, I thought it was in EncryptedExtensions. Reading the text
again, it is IMO really unclear where it goes.

Checking the extension table, it says "Client". Which impiles tha= t
servers don't send it, but 4.2.2 says servers must send it in some
cases.

Agreed. Table fail. Anyway, if i= t goes anywhere (see below) it should go in
ServerHello. That was= the intent for this draft.


> - Can the server send arbitrary certificate in response to PSK or is > >=C2=A0 =C2=A0it somehow restricted? The document does not seem to = talk about it.
> >
>
> The document right now is supposed to be PSK XOR server signs, so the<= br> > answer is supposed to be "no". If/when we allow both togethe= r, then
> we'll have to address this, which is a bit tricky.

Then why does that server signature_algorithms exist? I think that special PSK authentication modes should be specified in the PSK
extension, so non-PSK clients don't get confused and do inapporiate
things with those indications.

Can you = elaborate on what you mean here? If it's what I think you mean
(namely put it in the server's pre_share_key message) I used to have = that
and davidben convinced me this was better. There's no pe= rfect encoding
here, AFAICT, so if you want to make an alternate = suggestion that we could
take a look at, that would be great.

=C2=A0
> > - The HelloRetryRequest is problematic in pure-PSK case[= 1].
> >
> >
> > [1] One way to do it would be to move the group to extension, whi= ch
> > would only be sent if new group was needed. Then one could always=
> > require at least one extension (the field could also be renamed).=
> > Also, one could make it so that HRR extensions don't have to<= br> > > correspond to CH extensions (and unsupported one is a fatal error= ).
> >
>
> Agreed on both counts. PR wanted.
> https://github.com/tlswg/tls13-spec/issues/5= 60

David Bejamin already posted a PR about that. Doesn't clearly sa= y
that unknown reason handling.

Yeah, I r= ead the list before the PRs. I'll take a look but if you want to commen= t
that would be great.

-Ekr
=C2=A0


-Ilari

--001a114d85ce4ef785053a581a43-- From nobody Thu Aug 18 06:35:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF17F12DE7E for ; Thu, 18 Aug 2016 06:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG_5QLPoA7mi for ; Thu, 18 Aug 2016 06:35:52 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id D82F812DE7C for ; Thu, 18 Aug 2016 06:35:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C9609F031; Thu, 18 Aug 2016 16:35:49 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id asBhdpTL1eso; Thu, 18 Aug 2016 16:35:49 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 8C44DC4; Thu, 18 Aug 2016 16:35:49 +0300 (EEST) Date: Thu, 18 Aug 2016 16:35:41 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160818133541.6b2eb5kshva4m5br@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160818052622.zim6nxwwqw3hzmr6@LK-Perkele-V2.elisa-laajakaista.fi> <20160818124602.syi2whfbrom7xfi6@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.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-tls13-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 13:35:55 -0000 On Thu, Aug 18, 2016 at 05:55:16AM -0700, Eric Rescorla wrote: > On Thu, Aug 18, 2016 at 5:46 AM, Ilari Liusvaara > wrote: > > Agreed. Table fail. Anyway, if it goes anywhere (see below) it should go in > ServerHello. That was the intent for this draft. Okay, good to know (/me goes to change it in his code). > > Then why does that server signature_algorithms exist? I think that > > special PSK authentication modes should be specified in the PSK > > extension, so non-PSK clients don't get confused and do inapporiate > > things with those indications. > > > > Can you elaborate on what you mean here? If it's what I think you mean > (namely put it in the server's pre_share_key message) I used to have that > and davidben convinced me this was better. There's no perfect encoding > here, AFAICT, so if you want to make an alternate suggestion that we could > take a look at, that would be great. The issue I'm thinking about is that if missing signature_algorithms means no certificate, some dumb TLS implementation (and there are plenty of those) will heed that even in non-PSK mode... > > David Bejamin already posted a PR about that. Doesn't clearly say > > that unknown reason handling. > > > > Yeah, I read the list before the PRs. I'll take a look but if you want to > comment that would be great. The only comment is that I would prefer to allow extensions the without client including them in ClientHello[1] (obviously fatal if unknown one is seen[2]), instead of special-casing Cookie. [1] Of course, if the error is related to values in extension, then the client had to include it in its ClientHello. [2] Basically, if client is told that its ClientHello is wrong in some way it does not understand, obviously it can't fix it. -Ilari From nobody Thu Aug 18 08:00:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1E12DF6C for ; Thu, 18 Aug 2016 08:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTvjR5Pmzmm5 for ; Thu, 18 Aug 2016 08:00:22 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6312212DF67 for ; Thu, 18 Aug 2016 08:00:22 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id e63so2277731ith.1 for ; Thu, 18 Aug 2016 08:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iRA+zlg4wJK7ohR1PFyRVYcT01Bv9VV+soVnFSILqLc=; b=H3IdVhBG3RcrhSHo0mFGS3Fq0qU23S/F/kBAHQzU7/NcLB7iVwNRlHWkR3TFsMvwbP tIJF340qIbQD1zjubOna2yMJC6CmmgbOvw64m3N4hhDCTG2ZpBW/WB902EZ9B3btopNs IxkKjHIh9rDRo7SuUJkbrPnLe9bEk86HBKkg8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iRA+zlg4wJK7ohR1PFyRVYcT01Bv9VV+soVnFSILqLc=; b=d6zF9eOhcaEdUmaTOA6h5yqxmwtQmTLNO/Nv7Zvz6R7WGwYmsongad2ujVQtJLrSGY MGG552SyZ2a6u+p4XH19euDE6dqYGD28k2sRFy2Z8vJRr4DQqaL+GNc+co2hC/SFpbHq OBxqWw50nPNtC2h2PDsw1GSRwL7M2+KdczqkSu9nWUYl89O2F7y4f/PXaw29pKj2vHGH IZRc6ZcYG82IU+eZBA7U+QbDqbdFjPIJUkXXi0Oa8ncDq40QlRsTbFbeZSwJogXD8+OD z38lGt6eLg+1gudjn4fgquFhJXvXpEAgtxgP5eOTEOAvjmVPyVAPrlcT9hjYKk8IbSVe T9Yw== X-Gm-Message-State: AEkoouuzRlnfEa+dB2OpTWWEQ7XIM/bEU+xrr7XJAYyEOw5bS585/+Ynr2vAN0n05K9+8Vaw+0nSIE0E/lP9whXB X-Received: by 10.36.200.134 with SMTP id w128mr3900233itf.92.1471532421706; Thu, 18 Aug 2016 08:00:21 -0700 (PDT) MIME-Version: 1.0 References: <20160818052622.zim6nxwwqw3hzmr6@LK-Perkele-V2.elisa-laajakaista.fi> <20160818124602.syi2whfbrom7xfi6@LK-Perkele-V2.elisa-laajakaista.fi> <20160818133541.6b2eb5kshva4m5br@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160818133541.6b2eb5kshva4m5br@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Thu, 18 Aug 2016 15:00:10 +0000 Message-ID: To: Ilari Liusvaara , Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c05797845cc28053a59d7cc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-tls13-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 15:00:24 -0000 --94eb2c05797845cc28053a59d7cc Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 9:35 AM Ilari Liusvaara wrote: > > > David Bejamin already posted a PR about that. Doesn't clearly say > > > that unknown reason handling. > > > > > > > Yeah, I read the list before the PRs. I'll take a look but if you want to > > comment that would be great. > > The only comment is that I would prefer to allow extensions the without > client including them in ClientHello[1] (obviously fatal if unknown one is > seen[2]), instead of special-casing Cookie. > FWIW, I'm not a fan of special-casing Cookie either. I just left it alone for that PR and only bothered about moving to an extension since I wasn't sure how it should work. Just removing the requirement altogether seems reasonable? Although it doesn't give much guidance on which are and aren't MTI. Is a TLS client over TCP obligated to implement Cookie to avoid interop issues? Seems kind of pointless to require it there, just more things to remember. Whereas a DTLS client over UDP which doesn't implement cookie is unlikely to work well. But probably that kind of guidance ought to live elsewhere anyway. Or maybe we should just declare cookie MTI everywhere and leave it at that. (Though, I'm sure, in practice, no one will ever send cookie over TLS and thus some clients won't honor it.) David > > [1] Of course, if the error is related to values in extension, then the > client had to include it in its ClientHello. > > > [2] Basically, if client is told that its ClientHello is wrong in some > way it does not understand, obviously it can't fix it. > --94eb2c05797845cc28053a59d7cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 18= , 2016 at 9:35 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > David Bejamin already posted a PR about that. Doesn't clearly= say
> > that unknown reason handling.
> >
>
> Yeah, I read the list before the PRs. I'll take a look but if you = want to
> comment that would be great.

The only comment is that I would prefer to allow extensions the without
client including them in ClientHello[1] (obviously fatal if unknown one is<= br> seen[2]), instead of special-casing Cookie.

=
FWIW, I'm not a fan of special-casing Cookie either. I just left i= t alone for that PR and only bothered about moving to an extension since I = wasn't sure how it should work.

Just removing = the requirement altogether seems reasonable? Although it doesn't give m= uch guidance on which are and aren't MTI. Is a TLS client over TCP obli= gated to implement Cookie to avoid interop issues? Seems kind of pointless = to require it there, just more things to remember. Whereas a DTLS client ov= er UDP which doesn't implement cookie is unlikely to work well. But pro= bably that kind of guidance ought to live elsewhere anyway. Or maybe we sho= uld just declare cookie MTI everywhere and leave it at that.

=
(Though, I'm sure, in practice, no one will ever send cookie= over TLS and thus some clients won't honor it.)

David
=C2=A0

[1] Of course, if the error is related to values in extension, then the
client had to include it in its ClientHello.


[2] Basically, if client is told that its ClientHello is wrong in some
way it does not understand, obviously it can't fix it.
--94eb2c05797845cc28053a59d7cc-- From nobody Thu Aug 18 08:18:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5850E12DE62 for ; Thu, 18 Aug 2016 08:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdiAy4YWiFj1 for ; Thu, 18 Aug 2016 08:18:37 -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 B603112DE33 for ; Thu, 18 Aug 2016 08:18:37 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BA12F423720; Thu, 18 Aug 2016 15:18:36 +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 A043E423702; Thu, 18 Aug 2016 15:18:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471533516; bh=DfJxXWKcsKyQkPrT9gyzhOpt38LCmNxR28hxH1L4nXM=; l=1958; h=To:References:Cc:From:Date:In-Reply-To:From; b=DJFH+RDY+QRG1BY/9SoIZ1i3NxE9mv0THx8DBIutbouzy1MUHGi9BJpP1CwCRZ+NI fFEjKr6gsRqimrJfKtd9+hSsyTFn1FuaEYmE5UpUeVVWBJYOKf2oQqXSrv+nUeDpsR Q/B4Oyf2AL99bRJpG13gdec8tLgG/6KWw0MOJUP4= 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 5E2901FC8C; Thu, 18 Aug 2016 15:18:36 +0000 (GMT) To: Eric Rescorla References: From: Benjamin Kaduk Message-ID: <4458b764-8814-a3b6-0765-1692d19e278f@akamai.com> Date: Thu, 18 Aug 2016 10:18:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------85EF09C37678F826AE57430D" Archived-At: Cc: "" Subject: Re: [TLS] Pre_shared_key Extension Question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 15:18:39 -0000 This is a multi-part message in MIME format. --------------85EF09C37678F826AE57430D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/17/2016 05:17 PM, Eric Rescorla wrote: > It would be a fairly significant simplification to say you could only > have one PSK, because then we could easily require the client to prove > knowledge of the key, for instance by stuffing a MAC at the end of the > ClientHello as we discussed in Berlin. > > So: > Is there any demand for multiple identities? I do not believe there is > any in the Web context. If not, we should remove this feature. > Then at PSK rollover time, clients are expected to fall back to a new TLS connection using the other PSK? -Ben --------------85EF09C37678F826AE57430D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/17/2016 05:17 PM, Eric Rescorla wrote:
It would be a fairly significant simplification to say you could only have one PSK, because then we could easily require the client to prove knowledge of the key, for instance by stuffing a MAC at the end of the ClientHello as we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not believe there is any in the Web context. If not, we should remove this feature.


Then at PSK rollover time, clients are expected to fall back to a new TLS connection using the other PSK?

-Ben
--------------85EF09C37678F826AE57430D-- From nobody Thu Aug 18 08:30:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD55612D94D for ; Thu, 18 Aug 2016 08:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwsIphY4tHhA for ; Thu, 18 Aug 2016 08:30:12 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4619012D879 for ; Thu, 18 Aug 2016 08:30:12 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id d10so6560489ybi.1 for ; Thu, 18 Aug 2016 08:30: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; bh=XTTQjJSYvPKg2sBI+pCfuXJjYGT50Xpyvyx4Qcn6T8g=; b=RNAUkWOPYIhx2RDFDaicIm/G3ha3DViMYBTMRVfb/o40KAg9iWbJYd3u+LDS9RL5F4 734wALCwTL/ueZpIqNoeEk9W7qcEAQoQ5d8LHfZp+09SCPtlGg7VgXEk7DBgLjouybrw zKQvXu7eObXZja0xk7uKgNfg1OlqjyQ0h2WQSdYjW225PX8WjaenF6gHFj55GRpciBka KFQb5Y5L/K/kRroxR869w64NL2du/Bu6xVKRDM8lry509jNIJTF0DjDjL15yInJej61g pEkRpHxD8MbaYyv2mCZNt9gbk3bcpiJAG11mG02AY6ZZt54KWPQwh+Ycg80qVXQB6kku EqNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XTTQjJSYvPKg2sBI+pCfuXJjYGT50Xpyvyx4Qcn6T8g=; b=ArS3OUlUKRcLYiGzxk67PsI6ErXO/ksxmjvhBe5AZ7i/cJKa/+DnRlZ596uxyvCRbk mi9HZDCJmNqu3L5c2getqWpIW786w/sZgPaRaBXUzalLB7WHFuQ5S69HfMqoVZebODu7 CAVqAR7Sn6Kd2I/I+00zrHFCyDSQ/9XAaoh0gWYJ5DQHyvlv+yxlZUMQS9b9QY/EG0Yu +pcrnuEOca+K3xrbAOO7PKQyJeGFEUm1h4N8pK86IsbJl7//bEovXUnHPplcFPMky7Pd K3h5OR0amv0EvGRuoy3bPvL+yJi3Qk4wWKf20CRUqjWV9KdpCq/v2k5xIGxqwwYOoYYL zx/g== X-Gm-Message-State: AEkoousLC3nTQvNGtsusGQwQnwlyacJuGWats4knq6Gb3CZGJsDlWf2EbqnEi790oUZK8mTI08FFw4wt0T1U9g== X-Received: by 10.37.211.9 with SMTP id e9mr2136771ybf.74.1471534211500; Thu, 18 Aug 2016 08:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Thu, 18 Aug 2016 08:29:31 -0700 (PDT) In-Reply-To: <4458b764-8814-a3b6-0765-1692d19e278f@akamai.com> References: <4458b764-8814-a3b6-0765-1692d19e278f@akamai.com> From: Eric Rescorla Date: Thu, 18 Aug 2016 08:29:31 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c147dccf3dc8d053a5a4110 Archived-At: Cc: "" Subject: Re: [TLS] Pre_shared_key Extension Question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 15:30:14 -0000 --94eb2c147dccf3dc8d053a5a4110 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk wrote: > On 08/17/2016 05:17 PM, Eric Rescorla wrote: > > It would be a fairly significant simplification to say you could only have > one PSK, because then we could easily require the client to prove knowledge > of the key, for instance by stuffing a MAC at the end of the ClientHello as > we discussed in Berlin. > > So: > Is there any demand for multiple identities? I do not believe there is any > in the Web context. If not, we should remove this feature. > > > Then at PSK rollover time, clients are expected to fall back to a new TLS > connection using the other PSK? > I'm not sure I follow. Can you say more? -Ekr > -Ben > --94eb2c147dccf3dc8d053a5a4110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
=20 =20 =20
On 08/17/2016 05:17 PM, Eric Rescorla wrote:
=20
It would be a fairly significant simplification to say you could only have one PSK, because then we could easily require the client to prove knowledge of the key, for instance by stuffing a MAC at the end of the ClientHello as we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not believe there is any in the Web context. If not, we should remove this feature.


 Then at PSK rollover time, clients are expected to fall back to a new TLS connection using the other PSK?

=
I'm not sure I follow. Can you say more?

-Ekr




-Ben

--94eb2c147dccf3dc8d053a5a4110-- From nobody Thu Aug 18 08:47:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD90912DE1C for ; Thu, 18 Aug 2016 08:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.967 X-Spam-Level: X-Spam-Status: No, score=-3.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsK9v7Lez0lz for ; Thu, 18 Aug 2016 08:47:09 -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 B185612DE9E for ; Thu, 18 Aug 2016 08:47:09 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CC2F0433424; Thu, 18 Aug 2016 15:47:08 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B254F433408; Thu, 18 Aug 2016 15:47:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471535228; bh=zRLpCZ9vVjH2PH/zS30BXPFocsFHBnhn6WNery1FkJY=; l=5552; h=To:References:Cc:From:Date:In-Reply-To:From; b=fsdQvpj24FSIPgvIcs7p+ASxL4nAImby8J2HCmNyyJiF9z39EwfRW6R+tNvJpeGIq mUmwq95baqSnxI/CNEwytG+DDzdv2mxhEYSjjxreCelOX/VeckbKzJnblRBpUwn/37 QowKxB5Qfv+6EI5MkI3en4Gsgj9oQ9sgg8/fXql8= 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 7D6641FC88; Thu, 18 Aug 2016 15:47:08 +0000 (GMT) To: Eric Rescorla References: <4458b764-8814-a3b6-0765-1692d19e278f@akamai.com> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 18 Aug 2016 10:47:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EFC232BF323CBFD377C5DC31" Archived-At: Cc: "" Subject: Re: [TLS] Pre_shared_key Extension Question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 15:47:12 -0000 This is a multi-part message in MIME format. --------------EFC232BF323CBFD377C5DC31 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/18/2016 10:29 AM, Eric Rescorla wrote: > > > On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk > wrote: > > On 08/17/2016 05:17 PM, Eric Rescorla wrote: >> It would be a fairly significant simplification to say you could >> only have one PSK, because then we could easily require the >> client to prove knowledge of the key, for instance by stuffing a >> MAC at the end of the ClientHello as we discussed in Berlin. >> >> So: >> Is there any demand for multiple identities? I do not believe >> there is any in the Web context. If not, we should remove this >> feature. >> > > Then at PSK rollover time, clients are expected to fall back to a > new TLS connection using the other PSK? > > > I'm not sure I follow. Can you say more? > With caveat that I don't deploy PSK-based systems and this is before my morning coffee ... suppose I have a related group of IoT devices that use TLS+PSK to communicate. But, I don't want the long-term cryptographic secret (the PSK) to be permanent and unchanging, since that's not best practices and leaves me in a tough spot if it ever leaks. So, I generate a new PSK every three months, provide a device on the network that lets the devices retrieve the new one, and everyone is supposed to expire the old one a month after the new one is available. My PSK identities could then be something like "2016Q2" (or something more complicated; it doesn't really matter), but since the devices are autonomous and not synchronized, I can't have a "flag day" transition from using the 2016Q1 to 2016Q2 key. At some point, a device will try to use the 2016Q2 key as a client against a server device that only has the 2016Q1 key, and the handshake fails. In the rollover scenario I describe, the client can then try a new handshake with the 2016Q1 key instead of the 2016Q2 key, which should succeed. Given the benefits of only allowing one PSK identity from the client, I am fine with requiring the second hanshake in this (contrived?) scenario; I just wanted to mention it so that we know what we're getting into. -Ben --------------EFC232BF323CBFD377C5DC31 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 08/18/2016 10:29 AM, Eric Rescorla wrote:


On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 08/17/2016 05:17 PM, Eric Rescorla wrote:
It would be a fairly significant simplification to say you could only have one PSK, because then we could easily require the client to prove knowledge of the key, for instance by stuffing a MAC at the end of the ClientHello as we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not believe there is any in the Web context. If not, we should remove this feature.


 Then at PSK rollover time, clients are expected to fall back to a new TLS connection using the other PSK?

I'm not sure I follow. Can you say more?


With caveat that I don't deploy PSK-based systems and this is before my morning coffee ... suppose I have a related group of IoT devices that use TLS+PSK to communicate.  But, I don't want the long-term cryptographic secret (the PSK) to be permanent and unchanging, since that's not best practices and leaves me in a tough spot if it ever leaks.  So, I generate a new PSK every three months, provide a device on the network that lets the devices retrieve the new one, and everyone is supposed to expire the old one a month after the new one is available.  My PSK identities could then be something like "2016Q2" (or something more complicated; it doesn't really matter), but since the devices are autonomous and not synchronized, I can't have a "flag day" transition from using the 2016Q1 to 2016Q2 key.  At some point, a device will try to use the 2016Q2 key as a client against a server device that only has the 2016Q1 key, and the handshake fails.  In the rollover scenario I describe, the client can then try a new handshake with the 2016Q1 key instead of the 2016Q2 key, which should succeed.

Given the benefits of only allowing one PSK identity from the client, I am fine with requiring the second hanshake in this (contrived?) scenario; I just wanted to mention it so that we know what we're getting into.

-Ben
--------------EFC232BF323CBFD377C5DC31-- From nobody Thu Aug 18 08:54:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98112DA2C for ; Thu, 18 Aug 2016 08:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ntcRIwBecSs for ; Thu, 18 Aug 2016 08:54:50 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF99F12DA24 for ; Thu, 18 Aug 2016 08:54:49 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id j12so12195311ywb.2 for ; Thu, 18 Aug 2016 08:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mhGSs4wGTE6g1u91ft/SBp4/gZr/GHfLjgu5Vi2AyWg=; b=ciJnKRzn2gr05tN5TY4dpN3LYy0Be+uJ3K5B2YPIQE+AxufWFQWiyaKoDCvVRczAAj pG/71YS7SffFDySi61nXkbHWh7oz4H9Gvylz0+UmIkfsWcAuz2EVfOr6hQTJlCE1iFl8 i0VILJ2MEHIEzE9cnEPt+5rJTqpw569IDHdkcsa3okXipIDYTemcgDHdML1dqXtNqi6Y SkmwWf95NPD0BOff77SSQq52vs9jbjebs1FRH7KvARkJ0sdJWkilHgsgo8sBZWgtfSGj cWfcpj2Ls9veJCTbSv0EUt94Kx4J7mTtmHsExe1cyBwZyQbqhUURMwkIwo8rOiTS9rpu jZtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mhGSs4wGTE6g1u91ft/SBp4/gZr/GHfLjgu5Vi2AyWg=; b=JdkSkHc9tkHiIInImkGJBKaLBKLQugRtus0TBrLWM3hlsFsS5m9zZ0E5mzTTPuuLGB LiM00sWExfpl97aAExHelEwNe40EOQtlxt/3Hs2hO6Q4ygpbXJvfnOOPfDaQX9OfaQMv ECfwzNccSB0sZJUcXjUBsp/N0+vYhVjMbI+EIsihqOO6i5BPI4XTJCXEdTRlkqJGc+tq s1yPP3S5yJp+F3SCwvhIb2zW6yLiBKwQ+c5OJnGNh1J9Cck1LjB4+khNge2gduL9geM4 uI9ENOLx+LEr0SZxaHSe4RrAxvxI2yF3ZaOoK7BzWTC/0WF7ioaMvkCZ2QxvbuqnqutE QY4Q== X-Gm-Message-State: AEkoouu+ycgg3YjmbnihEKysUn+UwnDOCHbmA7ipSF2KpbMNIm3qL5wx+/HSMTy0RvEEyNkvv0/TB2orzJJU3A== X-Received: by 10.13.244.197 with SMTP id d188mr2408908ywf.276.1471535689264; Thu, 18 Aug 2016 08:54:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Thu, 18 Aug 2016 08:54:08 -0700 (PDT) In-Reply-To: References: <4458b764-8814-a3b6-0765-1692d19e278f@akamai.com> From: Eric Rescorla Date: Thu, 18 Aug 2016 08:54:08 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c08654808a01c053a5a9a6e Archived-At: Cc: "" Subject: Re: [TLS] Pre_shared_key Extension Question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 15:54:51 -0000 --94eb2c08654808a01c053a5a9a6e Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk wrote: > On 08/18/2016 10:29 AM, Eric Rescorla wrote: > > > > On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk wrote: > >> On 08/17/2016 05:17 PM, Eric Rescorla wrote: >> >> It would be a fairly significant simplification to say you could only >> have one PSK, because then we could easily require the client to prove >> knowledge of the key, for instance by stuffing a MAC at the end of the >> ClientHello as we discussed in Berlin. >> >> So: >> Is there any demand for multiple identities? I do not believe there is >> any in the Web context. If not, we should remove this feature. >> >> >> Then at PSK rollover time, clients are expected to fall back to a new TLS >> connection using the other PSK? >> > > I'm not sure I follow. Can you say more? > > > With caveat that I don't deploy PSK-based systems and this is before my > morning coffee ... suppose I have a related group of IoT devices that use > TLS+PSK to communicate. But, I don't want the long-term cryptographic > secret (the PSK) to be permanent and unchanging, since that's not best > practices and leaves me in a tough spot if it ever leaks. So, I generate a > new PSK every three months, provide a device on the network that lets the > devices retrieve the new one, and everyone is supposed to expire the old > one a month after the new one is available. My PSK identities could then > be something like "2016Q2" (or something more complicated; it doesn't > really matter), but since the devices are autonomous and not synchronized, > I can't have a "flag day" transition from using the 2016Q1 to 2016Q2 key. > At some point, a device will try to use the 2016Q2 key as a client against > a server device that only has the 2016Q1 key, and the handshake fails. In > the rollover scenario I describe, the client can then try a new handshake > with the 2016Q1 key instead of the 2016Q2 key, which should succeed. > That would be the implication at this point, I think, though one could imagine having some HRR version that was like "I have no idea about this PSK". This would be easy with davidben's proposed new HRR Structure. -Ekr > Given the benefits of only allowing one PSK identity from the client, I am > fine with requiring the second hanshake in this (contrived?) scenario; I > just wanted to mention it so that we know what we're getting into. > > -Ben > --94eb2c08654808a01c053a5a9a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
=20 =20 =20
On 08/18/2016 10:29 AM, Eric Rescorla wrote:
=20


On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 08/17/2016 05:17 PM, Eric Rescorla wrote:
It would be a fairly significant simplification to say you could only have one PSK, because then we could easily require the client to prove knowledge of the key, for instance by stuffing a MAC at the end of the ClientHello as we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not believe there is any in the Web context. If not, we should remove this feature.

Then at PSK rollover time, clients are expected to fall back to a new TLS connection using the other PSK?

I'm not sure I follow. Can you say more?


 With caveat that I don't deploy PSK-based systems and this is befor= e my morning coffee ... suppose I have a related group of IoT devices that use TLS+PSK to communicate.=C2=A0 But, I don't want the long-t= erm cryptographic secret (the PSK) to be permanent and unchanging, since that's not best practices and leaves me in a tough spot if it ever leaks.=C2=A0 So, I generate a new PSK every three months, provide a device on the network that lets the devices retrieve the new one, and everyone is supposed to expire the old one a month after the new one is available.=C2=A0 My PSK identities could then be something like "2016Q2" (or something more complicated; it doesn't reall= y matter), but since the devices are autonomous and not synchronized, I can't have a "flag day" transition from using the 2016Q1 to 2016Q2 = key.=C2=A0 At some point, a device will try to use the 2016Q2 key as a client against a server device that only has the 2016Q1 key, and the handshake fails.=C2=A0 In the rollover scenario I describe, the client can then try a new handshake with the 2016Q1 key instead of the 2016Q2 key, which should succeed.

=
That would be the implication at this point, I think, though one could= imagine having some HRR version that was like "I have no idea about t= his PSK". This would be easy with davidben's proposed new HRR Stru= cture.

-Ekr


Given the benefits of only allowing one PSK identity from the client, I am fine with requiring the second hanshake in this (contrived?) scenario; I just wanted to mention it so that we know what we're getting into.

-Ben

--94eb2c08654808a01c053a5a9a6e-- From nobody Thu Aug 18 09:05:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8062312DF27 for ; Thu, 18 Aug 2016 09:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo2ZBDC__mOr for ; Thu, 18 Aug 2016 09:05:52 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 5AE0C12D133 for ; Thu, 18 Aug 2016 09:05:52 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id x131so2117513ite.0 for ; Thu, 18 Aug 2016 09:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ve6TNclcLBNfias/RLz1vfGQe/nch00hh85jFFf6kIU=; b=ASguIwLWGYXtuVzj8KrpZvUOHXXBkEM/3gI3UT7Hk6DhogcC1eUwrjXpeEEOkW7/E7 xiNZTsM6Be73rOVEavRUF6Vww1llb7iVIRQncQZN1P043UO5jpjX/COTXnLe4VmziXB4 tiWdvdc+MJ49yEbzzggnLdGelBEa0zRmYzwjw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ve6TNclcLBNfias/RLz1vfGQe/nch00hh85jFFf6kIU=; b=RM6qhvmIGErgF53FyPG2BmV0WtH0rg9BAIvt7RBgraxtP4f87J05N3gFzVg/1fyL7R AGeRHeBhepyjATc7zF6EFkrwlgsHuLsKRVQHIUY6vIYMsov9MeBCzn1ZcFRHWgQxAA9o y/1ePUYq/sPBRUmxUmxJ/qOLpUi4C+5MV31hk+tA1SdCO5ltujvpPxxXrFAEO5pGSi7g pu7HT+XuKfNQCohzaL/M7dJCIDTTe7T7Iml6qtM53m/mjAmpcadlnzsrY5Kw0BfifzZZ ldfBB1/btrovPeB4ISFq/sjvKNVgYdG9nSTGgs4J2GR6Ipl/S+/9i8Oest9yBof6xaX8 cAzg== X-Gm-Message-State: AEkoouvqgW1Iwn1Yi+xfrmJE4tXHlYhuPM9b6jfVsjSrSQZDVcvwgGvYOJDZeQuE6Dw1GilnGalJodFX3uWROIGh X-Received: by 10.36.189.143 with SMTP id x137mr461022ite.18.1471536351321; Thu, 18 Aug 2016 09:05:51 -0700 (PDT) MIME-Version: 1.0 References: <4458b764-8814-a3b6-0765-1692d19e278f@akamai.com> In-Reply-To: From: David Benjamin Date: Thu, 18 Aug 2016 16:05:40 +0000 Message-ID: To: Eric Rescorla , Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c19c0267efbd8053a5ac179 Archived-At: Cc: "" Subject: Re: [TLS] Pre_shared_key Extension Question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 16:05:54 -0000 --94eb2c19c0267efbd8053a5ac179 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 11:54 AM Eric Rescorla wrote: > On Thu, Aug 18, 2016 at 8:47 AM, Benjamin Kaduk wrote: > >> On 08/18/2016 10:29 AM, Eric Rescorla wrote: >> >> >> >> On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk >> wrote: >> >>> On 08/17/2016 05:17 PM, Eric Rescorla wrote: >>> >>> It would be a fairly significant simplification to say you could only >>> have one PSK, because then we could easily require the client to prove >>> knowledge of the key, for instance by stuffing a MAC at the end of the >>> ClientHello as we discussed in Berlin. >>> >>> So: >>> Is there any demand for multiple identities? I do not believe there is >>> any in the Web context. If not, we should remove this feature. >>> >>> >>> Then at PSK rollover time, clients are expected to fall back to a new >>> TLS connection using the other PSK? >>> >> >> I'm not sure I follow. Can you say more? >> >> >> With caveat that I don't deploy PSK-based systems and this is before my >> morning coffee ... suppose I have a related group of IoT devices that use >> TLS+PSK to communicate. But, I don't want the long-term cryptographic >> secret (the PSK) to be permanent and unchanging, since that's not best >> practices and leaves me in a tough spot if it ever leaks. So, I generate a >> new PSK every three months, provide a device on the network that lets the >> devices retrieve the new one, and everyone is supposed to expire the old >> one a month after the new one is available. My PSK identities could then >> be something like "2016Q2" (or something more complicated; it doesn't >> really matter), but since the devices are autonomous and not synchronized, >> I can't have a "flag day" transition from using the 2016Q1 to 2016Q2 key. >> At some point, a device will try to use the 2016Q2 key as a client against >> a server device that only has the 2016Q1 key, and the handshake fails. In >> the rollover scenario I describe, the client can then try a new handshake >> with the 2016Q1 key instead of the 2016Q2 key, which should succeed. >> > > That would be the implication at this point, I think, though one could > imagine having some HRR version that was like "I have no idea about this > PSK". This would be easy with davidben's proposed new HRR Structure. > Note this would require that the client and server a priori agree they're doing PSK-based identities and not certificate-based identities. Otherwise the server doesn't know whether to do PSK + please use this identity instead or full handshake + certs. Though that seems an okay requirement since what kind of identities you use (PSK, X.509 web PKI, Kerberos, whatever else) is more part of the application profile and not really negotiated at TLS. Another option for your scenario is you ensure that the 2016Q2 key is installed on the servers before it is installed on any client. The server is still allowed to accept multiple PSK identities whether there's one or multiple client advertisements. The multiple client advertisement just means you can install 2016Q2 in any order. (I am not actually involved in PSK-based systems either. I too would love to have only one PSK offer since, for resumption purposes, there's no need for multiple. But I can't speak to actual PSK-based systems.) David > -Ekr > > >> Given the benefits of only allowing one PSK identity from the client, I >> am fine with requiring the second hanshake in this (contrived?) scenario; I >> just wanted to mention it so that we know what we're getting into. >> >> -Ben >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c19c0267efbd8053a5ac179 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 18= , 2016 at 11:54 AM Eric Rescorla <ekr@rt= fm.com> wrote:
On Thu, Aug 18, 2= 016 at 8:47 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20
On 08/18/2016 10:29 AM, Eric Rescorla wrote:
=20


On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 08/17/2016 05:17 PM, Eric Rescorla wrote:
It would be a fairly significant simplification to say you could only have one PSK, because then we could easily require the client to prove knowledge of the key, for instance by stuffing a MAC at the end of the ClientHello as we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not believe there is any in the Web context. If not, we should remove this feature.

Then at PSK rollover time, clients are expected to fall back to a new TLS connection using the other PSK?

I'm not sure I follow. Can you say more?


 With caveat that I don't deploy PSK-based systems and this is befor= e my morning coffee ... suppose I have a related group of IoT devices that use TLS+PSK to communicate.=C2=A0 But, I don't want the long-t= erm cryptographic secret (the PSK) to be permanent and unchanging, since that's not best practices and leaves me in a tough spot if it ever leaks.=C2=A0 So, I generate a new PSK every three months, provide a device on the network that lets the devices retrieve the new one, and everyone is supposed to expire the old one a month after the new one is available.=C2=A0 My PSK identities could then be something like "2016Q2" (or something more complicated; it doesn't reall= y matter), but since the devices are autonomous and not synchronized, I can't have a "flag day" transition from using the 2016Q1 to 2016Q2 = key.=C2=A0 At some point, a device will try to use the 2016Q2 key as a client against a server device that only has the 2016Q1 key, and the handshake fails.=C2=A0 In the rollover scenario I describe, the client can then try a new handshake with the 2016Q1 key instead of the 2016Q2 key, which should succeed.

=
That would be the implication at this point, I think, th= ough one could imagine having some HRR version that was like "I have n= o idea about this PSK". This would be easy with davidben's propose= d new HRR Structure.

Note this would require that the client and server a priori agree they= 9;re doing PSK-based identities and not certificate-based identities. Other= wise the server doesn't know whether to do PSK=C2=A0+ please use this i= dentity instead or full handshake=C2=A0+ certs. Though that seems an okay r= equirement since what kind of identities you use (PSK, X.509 web PKI, Kerbe= ros, whatever else) is more part of the application profile and not really = negotiated at TLS.

Another option for your scenari= o is you ensure that the 2016Q2 key is installed on the servers before it i= s installed on any client. The server is still allowed to accept multiple P= SK identities whether there's one or multiple client advertisements. Th= e multiple client advertisement just means you can install 2016Q2 in any or= der.

(I am not actually involved in PSK-based systems eit= her. I too would love to have only one PSK offer since, for resumption purp= oses, there's no need for multiple. But I can't speak to actual PSK= -based systems.)

David
=C2=A0
-Ekr


Given the benefits of only allowing one PSK identity from the client, I am fine with requiring the second hanshake in this (contrived?) scenario; I just wanted to mention it so that we know what we're getting into.

-Ben
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--94eb2c19c0267efbd8053a5ac179-- From nobody Thu Aug 18 10:08:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B326812D5CA for ; Thu, 18 Aug 2016 10:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.967 X-Spam-Level: X-Spam-Status: No, score=-3.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9dVJChE41yh for ; Thu, 18 Aug 2016 10:08:04 -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 DC65612B027 for ; Thu, 18 Aug 2016 10:08:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 217B8433424; Thu, 18 Aug 2016 17:08:03 +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 F3C5B43340E; Thu, 18 Aug 2016 17:08:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471540083; bh=l/T4zNmoeCeZ+Q+Ifd2EiM3EnKix6JKKUhDXucJWIMA=; l=9371; h=To:References:From:Date:In-Reply-To:From; b=yUD6qmHk9ta/XIWSA+c8cn9V5PugFAj0IaBWN1DknjJj69geMbJKtoy1rGk7+hk5+ MbAgeLd8wjO4HyAI/iz+AVU4C8z1zafoQToqB+OGEULDLzSYw1P68rn+MusgZfzrDk MsKt5ytiU6YRCsoZ4JJQu0LMtjpaCcXqWymTU8dA= 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 A93B91FC86; Thu, 18 Aug 2016 17:08:02 +0000 (GMT) To: David Benjamin , "tls@ietf.org" References: From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> Date: Thu, 18 Aug 2016 12:08:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DD6D5AB3EB5EF5D4E832D9B4" Archived-At: Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 17:08:07 -0000 This is a multi-part message in MIME format. --------------DD6D5AB3EB5EF5D4E832D9B4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/17/2016 11:29 PM, David Benjamin wrote: > However, we lose the "free" (really at the cost of this unboundedness > problem) generation-based bidirectional KeyUpdate sync. Depending on > what we want out of KeyUpdate, I can imagine a few options: > My recollection is that the only reason we have KeyUpdate is to avoid going over the limit for amount of ciphertext encrypted in the same key within our safety margin (recall the analyses debating whether such limits would even be reachable for the ciphers currently in use, as well as the disagreement as to what the safety margin should be). > - Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate > every N records or so and leave it at that. (I think this is the best > option on grounds of simplicity, assuming it meets the primary needs > of KeyUpdate.) > If we're in a world where implementations are considering leaving out the required "catch up" KeyUpdate, we may want to consider alternative options to put in the spec that are easier to implement. That is, we can write the spec in various ways to get the functionality that both write directions get the key updates needed to avoid the ciphertext limit, and we are reliant on implementations to follow the spec in order to get that safety property. So, given that we can only get the safety property if all implementations follow the spec, why not just ... require implementations to track the amount sent and rekey if it's too close to the limit? That is consistent with a unilateral/unidirectional KeyUpdate, and having per-connection byte/record counters does not seem to be a huge overhead. Keeping the two write directions' keys independent would also avoid conflict when the two peers disagree on how often a rekey is necessary (as might happen if a resource-constrained device decided to not implement byte counters and just rekey after every N records, which is "free" since you need to track serial numbers anyway). > - If you receive a KeyUpdate and didn't send one in the last N minutes > (where N minutes >>> 1 RTT), (optionally?) flag your next write to be > preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to > prevent ping-ponging. > > - Variations on sticking a please_echo boolean in the KeyUpdate > message, generation counts, etc., to get synchronization with > coalescing if we need it. I would much prefer the simpler options > unless we truly need this. (KeyUpdate is right now a *required* > feature, so simplicity should be a priority. Rare use cases are what > extensions are for.) > > Thoughts? > > David > > PS: We've seen this before with renego (I've seen many OpenSSL > consumers which lock up if the peer renegotiation), error alerts > triggered on reads (often they don't get sent), and close_notify (also > don't get sent in practice). Deviations from dumb filters are expensive. > Yes, simple is better. Well, here at least :) > PPS: I'm wary of over-extending post-handshake auth for the same > reason, though I haven't had time to look carefully at the latest > proposal yet. Still, having TLS specify and analyze the crypto while > lifting the actual messages into application-level framing would be > preferable for these sorts of side protocols. The application gets to > make assumptions about read/write flows and knows in which contexts > what is and isn't allowed. > Hmm, so [in the above proposal] that would involve the application doing the byte/record counters and pushing a "give me a rekey packet now" button when needed? I am not sure that I'm comfortable moving "crypto sensitive" code (well, sort-of) into the application, since many applications won't do it. Also, not all applications will have access to the record serial number, as I understand it, and the formulas I remember for the ciphertext limits involved both records and bytes. -Ben --------------DD6D5AB3EB5EF5D4E832D9B4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 08/17/2016 11:29 PM, David Benjamin wrote:
However, we lose the "free" (really at the cost of this unboundedness problem) generation-based bidirectional KeyUpdate sync. Depending on what we want out of KeyUpdate, I can imagine a few options:


My recollection is that the only reason we have KeyUpdate is to avoid going over the limit for amount of ciphertext encrypted in the same key within our safety margin (recall the analyses debating whether such limits would even be reachable for the ciphers currently in use, as well as the disagreement as to what the safety margin should be).

- Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate every N records or so and leave it at that. (I think this is the best option on grounds of simplicity, assuming it meets the primary needs of KeyUpdate.)


If we're in a world where implementations are considering leaving out the required "catch up" KeyUpdate, we may want to consider alternative options to put in the spec that are easier to implement.  That is, we can write the spec in various ways to get the functionality that both write directions get the key updates needed to avoid the ciphertext limit, and we are reliant on implementations to follow the spec in order to get that safety property.  So, given that we can only get the safety property if all implementations follow the spec, why not just ... require implementations to track the amount sent and rekey if it's too close to the limit?  That is consistent with a unilateral/unidirectional KeyUpdate, and having per-connection byte/record counters does not seem to be a huge overhead.

Keeping the two write directions' keys independent would also avoid conflict when the two peers disagree on how often a rekey is necessary (as might happen if a resource-constrained device decided to not implement byte counters and just rekey after every N records, which is "free" since you need to track serial numbers anyway).

- If you receive a KeyUpdate and didn't send one in the last N minutes (where N minutes >>> 1 RTT), (optionally?) flag your next write to be preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to prevent ping-ponging.

- Variations on sticking a please_echo boolean in the KeyUpdate message, generation counts, etc., to get synchronization with coalescing if we need it. I would much prefer the simpler options unless we truly need this. (KeyUpdate is right now a *required* feature, so simplicity should be a priority. Rare use cases are what extensions are for.)

Thoughts?

David

PS: We've seen this before with renego (I've seen many OpenSSL consumers which lock up if the peer renegotiation), error alerts triggered on reads (often they don't get sent), and close_notify (also don't get sent in practice). Deviations from dumb filters are expensive.


Yes, simple is better.  Well, here at least :)

PPS: I'm wary of over-extending post-handshake auth for the same reason, though I haven't had time to look carefully at the latest proposal yet. Still, having TLS specify and analyze the crypto while lifting the actual messages into application-level framing would be preferable for these sorts of side protocols. The application gets to make assumptions about read/write flows and knows in which contexts what is and isn't allowed.


Hmm, so [in the above proposal] that would involve the application doing the byte/record counters and pushing a "give me a rekey packet now" button when needed?  I am not sure that I'm comfortable moving "crypto sensitive" code (well, sort-of) into the application, since many applications won't do it.  Also, not all applications will have access to the record serial number, as I understand it, and the formulas I remember for the ciphertext limits involved both records and bytes.

-Ben
--------------DD6D5AB3EB5EF5D4E832D9B4-- From nobody Thu Aug 18 10:27:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D1812D85F for ; Thu, 18 Aug 2016 10:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKeP7QIaGI9r for ; Thu, 18 Aug 2016 10:26:56 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD8712DACC for ; Thu, 18 Aug 2016 10:26:48 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id b62so25273151iod.3 for ; Thu, 18 Aug 2016 10:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8O8QRI5JLUv32ZWdoSVAGhQHlkSu5kZSvn9Vq4mkvrQ=; b=Tjo54XA8+uYrPPGYcldr6hpG2N4ve4+IEy5oeFCKGOBmKzwL6ITyrhHDLy6WzE6wJ+ JYgqcl4aEpq83abwrm/YdvGGVdcl50gD1PNchu3RrddkmRRqls83wnKScKs8FoREQLNA 1BpR2NYP5Pms6xrIdAcJtMOn8qpBOImz4bRRs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8O8QRI5JLUv32ZWdoSVAGhQHlkSu5kZSvn9Vq4mkvrQ=; b=atQPkNf03m7cy3oK/IyB7h+99ZCfj36UuUuKS/lEgzr/YQJmIycMKHKg6NOdn6PaiH hgt+KBEz9zsiTorQGW04cvGGPz/zcDIx190wbAw+bsTQ6fksHmAv18i8Yzpl3i9W7JI2 +IUqIXt9Hl4OPW+eV+t5GvEb/m1B7fDbufiunpOSuYaPjV5ICFErrTQf9JBOVstlQ/qw TMhTu5VmqpQgOjDKs1iVLo6AyvJLcvywHf2WtHGUrFpHjv+EhbqEwNBd8ealZnV2q8Ed b3yVuVp94QlTCCsOiXfGqPzIuEaqEF3dBsjR8e5fSKcf4gaEJOO81vPnCgte+yD5N92f e3Pg== X-Gm-Message-State: AEkooutfHV/fEk6S41ton/iRQiCs6n9ai6yx2NeFxQsXamxXLkV3BQlK4dI5UIUwvRSusfMdGTLCRubwT4EPOKPx X-Received: by 10.107.52.198 with SMTP id b189mr4755476ioa.6.1471541207370; Thu, 18 Aug 2016 10:26:47 -0700 (PDT) MIME-Version: 1.0 References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> In-Reply-To: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: David Benjamin Date: Thu, 18 Aug 2016 17:26:37 +0000 Message-ID: To: Benjamin Kaduk , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11440f7ef06d32053a5be21b Archived-At: Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 17:27:00 -0000 --001a11440f7ef06d32053a5be21b Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk wrote: > On 08/17/2016 11:29 PM, David Benjamin wrote: > > However, we lose the "free" (really at the cost of this unboundedness > problem) generation-based bidirectional KeyUpdate sync. Depending on what > we want out of KeyUpdate, I can imagine a few options: > > > My recollection is that the only reason we have KeyUpdate is to avoid > going over the limit for amount of ciphertext encrypted in the same key > within our safety margin (recall the analyses debating whether such limits > would even be reachable for the ciphers currently in use, as well as the > disagreement as to what the safety margin should be). > > > - Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate > every N records or so and leave it at that. (I think this is the best > option on grounds of simplicity, assuming it meets the primary needs of > KeyUpdate.) > > > If we're in a world where implementations are considering leaving out the > required "catch up" KeyUpdate, we may want to consider alternative options > to put in the spec that are easier to implement. That is, we can write the > spec in various ways to get the functionality that both write directions > get the key updates needed to avoid the ciphertext limit, and we are > reliant on implementations to follow the spec in order to get that safety > property. So, given that we can only get the safety property if all > implementations follow the spec, why not just ... require implementations > to track the amount sent and rekey if it's too close to the limit? That is > consistent with a unilateral/unidirectional KeyUpdate, and having > per-connection byte/record counters does not seem to be a huge overhead. > > Keeping the two write directions' keys independent would also avoid > conflict when the two peers disagree on how often a rekey is necessary (as > might happen if a resource-constrained device decided to not implement byte > counters and just rekey after every N records, which is "free" since you > need to track serial numbers anyway). > Yup. If we say implementations SHOULD/MUST/whatever send KeyUpdates frequently and we're fine with just saying we rely on each sender to honor that w.r.t. their own send keys with little other fanfare, I think this option is the clear winner. We're already relying on the sender to not, say, exfiltrate all data somewhere nasty. There seemed to be other motivations for KeyUpdate (Keith's passive observer use case, I've heard some theories around one side knowing more about the cipher than another, etc.), so I left that alone for now. I'm not currently convinced by those use cases, but perhaps the working group feels differently. I'm reasonably confident splitting the key tracks is correct regardless, but I wasn't sure which KeyUpdate motivations were considered important and which weren't. > - If you receive a KeyUpdate and didn't send one in the last N minutes > (where N minutes >>> 1 RTT), (optionally?) flag your next write to be > preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to > prevent ping-ponging. > > - Variations on sticking a please_echo boolean in the KeyUpdate message, > generation counts, etc., to get synchronization with coalescing if we need > it. I would much prefer the simpler options unless we truly need > this. (KeyUpdate is right now a *required* feature, so simplicity should be > a priority. Rare use cases are what extensions are for.) > > Thoughts? > > David > > PS: We've seen this before with renego (I've seen many OpenSSL consumers > which lock up if the peer renegotiation), error alerts triggered on reads > (often they don't get sent), and close_notify (also don't get sent in > practice). Deviations from dumb filters are expensive. > > > Yes, simple is better. Well, here at least :) > > > PPS: I'm wary of over-extending post-handshake auth for the same reason, > though I haven't had time to look carefully at the latest proposal yet. > Still, having TLS specify and analyze the crypto while lifting the actual > messages into application-level framing would be preferable for these sorts > of side protocols. The application gets to make assumptions about > read/write flows and knows in which contexts what is and isn't allowed. > > > Hmm, so [in the above proposal] that would involve the application doing > the byte/record counters and pushing a "give me a rekey packet now" button > when needed? I am not sure that I'm comfortable moving "crypto sensitive" > code (well, sort-of) into the application, since many applications won't do > it. Also, not all applications will have access to the record serial > number, as I understand it, and the formulas I remember for the ciphertext > limits involved both records and bytes. > Sorry, that was unclear. That was more of a side comment to help explain why I have such strong visceral reactions to any post-handshake auth mechanisms since part of it is the same issue. I am not proposing we lift KeyUpdate to the application layer. I'm proposing we split the KeyUpdate tracks in two and do [insert preferred option here] w.r.t. the bidirectionality issue. Probably should not have mentioned it since it's mostly a distraction for this topic. I ramble a lot. :-) David --001a11440f7ef06d32053a5be21b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 18= , 2016 at 1:08 PM Benjamin Kaduk <b= kaduk@akamai.com> wrote:
On 08/17/2016 11:29 PM, David Benjamin wrote:
However, we lose the "free" (really at the= cost of this unboundedness problem)=C2=A0generation-based bidirectional KeyUpdate sync. Depending on what we want out of KeyUpdate, I can imagine a few options:


My recollection is that the only reason we have KeyUpdate is to avoid going over the limit for amount of ciphertext encrypted in the same key within our safety margin (recall the analyses debating whether such limits would even be reachable for the ciphers currently in use, as well as the disagreement as to what the safety margin should be).


- Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate every N records or so and leave it at that. (I think this is the best option on grounds of simplicity, assuming it meets the primary needs of KeyUpdate.)


If we're in a world where implementations are considering leaving out the required "catch up" KeyUpdate, we may want to conside= r alternative options to put in the spec that are easier to implement.=C2=A0 That is, we can write the spec in various ways to get the functionality that both write directions get the key updates needed to avoid the ciphertext limit, and we are reliant on implementations to follow the spec in order to get that safety property.=C2=A0 So, given that we can only get the safety property if a= ll implementations follow the spec, why not just ... require implementations to track the amount sent and rekey if it's too clos= e to the limit?=C2=A0 That is consistent with a unilateral/unidirectional KeyUpdate, and having per-connection byte/record counters does not seem to be a huge overhead.

Keeping the two write directions' keys independent would also avoid conflict when the two peers disagree on how often a rekey is necessary (as might happen if a resource-constrained device decided to not implement byte counters and just rekey after every N records, which is "free" since you need to track serial numbers anyway= ).

Yup. If we say implementations SHO= ULD/MUST/whatever send KeyUpdates frequently and we're fine with just s= aying we rely on each sender to honor that w.r.t. their own send keys with = little other fanfare, I think this option is the clear winner. We're al= ready relying on the sender to not, say, exfiltrate all data somewhere nast= y.

There seemed to be other motivations for KeyUpd= ate (Keith's passive observer use case, I've heard some theories ar= ound one side knowing more about the cipher than another, etc.), so I left = that alone for now. I'm not currently convinced by those use cases, but= perhaps the working group feels differently. I'm reasonably confident = splitting the key tracks is correct regardless, but I wasn't sure which= KeyUpdate motivations were considered important and which weren't.
=C2=A0
- If you receive a KeyUpdate and didn't send one in the last N minutes (where N minutes >>> 1 RTT), (optionally?) flag your next write to be preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to prevent ping-ponging.

- Variations on sticking a please_echo boolean in the KeyUpdate message, generation counts, etc., to get synchronization with coalescing if we need it. I would much prefer the simpler options unless we truly need this.=C2=A0(KeyUpdate is right now a *required* feature, so simplicity should be a priority. Rare use cases are what extensions are for.)

Thoughts?

David

PS: We've seen this before with renego (I've seen ma= ny OpenSSL consumers which lock up if the peer renegotiation), error alerts triggered on reads (often they don't get sent)= , and close_notify (also don't get sent in practice).=C2=A0Deviations from dumb filters are expensive.


Yes, simple is better.=C2=A0 Well, here at least :)


PPS: I'm wary of over-extending post-handshake auth for the same reason, though I haven't had time to look carefull= y at the latest proposal yet. Still, having TLS specify and analyze the crypto while lifting the actual messages into application-level framing would be preferable for these sorts of side protocols. The application gets to make assumptions about read/write flows and knows in which contexts what is and isn't allowed.


Hmm, so [in the above proposal] that would involve the application doing the byte/record counters and pushing a "give me a rekey pack= et now" button when needed?=C2=A0 I am not sure that I'm comforta= ble moving "crypto sensitive" code (well, sort-of) into the application,= since many applications won't do it.=C2=A0 Also, not all applications wil= l have access to the record serial number, as I understand it, and the formulas I remember for the ciphertext limits involved both records and bytes.

Sorry, that was un= clear. That was more of a side comment to help explain why I have such stro= ng visceral reactions to any post-handshake auth mechanisms since part of i= t is the same issue. I am not proposing we lift KeyUpdate to the applicatio= n layer. I'm proposing we split the KeyUpdate tracks in two and do [ins= ert preferred option here] w.r.t. the bidirectionality issue. Probably shou= ld not have mentioned it since it's mostly a distraction for this topic= . I ramble a lot. :-)

David=C2=A0
--001a11440f7ef06d32053a5be21b-- From nobody Thu Aug 18 10:48:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD32612B051 for ; Thu, 18 Aug 2016 10:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4TVBZPxPVBE for ; Thu, 18 Aug 2016 10:48:18 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0096.outbound.protection.outlook.com [104.47.38.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF38A12D733 for ; Thu, 18 Aug 2016 10:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PFzF4GNTPYfrwOXmMfy7VTMs2WEZTY6W3Pd9790jiKQ=; b=QvDtWEt8/aF8479pdE8V3Q+eIXrkPqaHomfGaqyAyfhNv6ZeufHwFKBa/qfDPAx7Vt7IDs5Rw4YAMKfPdl+qK6PbPeUoqSz3eVPcgJTgTdFUTuy8KFBTvVveHAsZMY+GXb7tYgqw39O2hhPwkv2wuJHKx8B3mrNTiuzVrRBprgs= Received: from BN6PR03MB2675.namprd03.prod.outlook.com (10.173.143.150) by BN6PR03MB2675.namprd03.prod.outlook.com (10.173.143.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 18 Aug 2016 17:47:58 +0000 Received: from BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) by BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) with mapi id 15.01.0549.027; Thu, 18 Aug 2016 17:47:58 +0000 From: Christian Huitema To: "" , "imiers@cs.jhu.edu" , "mgreen@cs.jhu.edu" , Eric Rescorla Thread-Topic: Short Authentication Strings for TLS Thread-Index: AdH5ctgVeV1w1b1MRb+YwaKtrD5Lxw== Date: Thu, 18 Aug 2016 17:47:58 +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=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:f::4dd] x-ms-office365-filtering-correlation-id: 38600514-fc15-4566-2816-08d3c78fcafd x-microsoft-exchange-diagnostics: 1; BN6PR03MB2675; 6:y9+PvGZAUVcLkHVOAGEtROzZK8PSrTJH4DmM+U7SEu5mx9af9EcFHMLEdouoHPateMsW3U8xAQnEBK6wodPqUqLLqgwNSCmVUoYgWsqosoqGXoLkgEw0biXngsu/tW6GmAhSi+Em50wtsTLEgydJkXk4yQqY2A+5jvMPhUm2aa847qN+ZZ83EO16EgKRVEhPdYqfuNd7Rpwp55yesh+X6kjC6cDr9WP05SLhjBkcAdoJVyThYe+KG8w0WBuT/BQzefEogDu2BzvlhnWuCeT5YBDyp/XugkuO6NRK9EMBmNfxBSR5soGvIY9ONgZapbxpjzh33CW/i/d0I6ngfLdBJw==; 5:TSuSMf3OF8CCrI9iSvQLt1Q+hF+MaY4NApl3f5CNUekKP1nQnRaeed8PcTnhrEo8KUx8DG+C1VWYN1ErQ0lWnLN5Kfyw6JLZXuYobm4sTXM7+s5hzGpDM4IMGDTwFwg+ArzN4HvzPej+9fjHT24nmg==; 24:vF7EA9KS8b9QTBPjXtkiwGyHxIrRPLnbHtfV/WVruGcLQ62oIhbXwvYjm/q4idp0PJu0WzMJ4HX79Pyi9NIdDQTd0ZgvluvZR5iu9uThl7w=; 7:QjhuCKByzPq0jFC/J3PhcCptasBfckHqjoMUDDwnBfYG6VchoAoIKRTLHizuXn5KiSEB3pTc9Miuakwx0bcEjdSXVLvCkOxi9xrJ7JZyqyOuCTlUf7SoOQqmC9Rqvag1njNNqZPJXj2KSlzeTmiKHwqbK3oOsoekPjgyxpb8wwgyF5h5IyL0XvsXxzG20u6a/g1Vt3r6tDbDUWNQwmU9MJj/dx6G8P8mSOkDsurYxcSZoUj315ROVOlDgSEEubQF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2675; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2675; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2675; x-forefront-prvs: 0038DE95A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(101416001)(77096005)(97736004)(102836003)(122556002)(15975445007)(4326007)(19300405004)(81166006)(86612001)(8676002)(229853001)(54356999)(19617315012)(81156014)(11100500001)(8936002)(10090500001)(33656002)(3280700002)(68736007)(92566002)(50986999)(110136002)(19625215002)(5005710100001)(5002640100001)(2201001)(106356001)(16236675004)(3660700001)(2171001)(105586002)(790700001)(8990500004)(99286002)(10290500002)(2900100001)(86362001)(2501003)(7736002)(7846002)(189998001)(586003)(74316002)(87936001)(7906003)(2906002)(19580395003)(6116002)(10400500002)(9686002)(76576001)(7696003)(3826002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2675; H:BN6PR03MB2675.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2675BA146E2ACC19C754B2DCA8150BN6PR03MB2675namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2016 17:47:58.6819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2675 Archived-At: Cc: Daniel Kaiser Subject: [TLS] Short Authentication Strings for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 17:48:39 -0000 --_000_BN6PR03MB2675BA146E2ACC19C754B2DCA8150BN6PR03MB2675namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daniel Kaiser and I are working on a "pairing" specification in the context= of DNS SD. Short Authentication Strings are one of the preferred methods f= or verifying pairings. I would like to use TLS as much as possible in the p= airing protocol. EKR pointed me to the expired draft by Ian Miers, Matthew = Green and him: https://tools.ietf.org/html/draft-miers-tls-sas-00. I am int= erested in reviving that draft. The draft implements a classic "coin flipping" protocol into TLS, using a "= commit before disclose" logic to prevent Nessie from hiding as an MITM betw= een Alice and Bob. From my superficial reading, this looks fine. I could us= e a reference to http://people.csail.mit.edu/shaih/pubs/hm96.pdf, both to e= xplain why the attack by Halevi and Micali does not apply to this particula= r construct, and also to provide a 20 years old reference to similar algori= thms, which may be useful in this day and age. One nit, though. If Nessie has infinite computing resource, she can build a= catalog of multiple random values that all hash to the same string, and th= en use that catalog to work around the commitment protocol. The scheme in t= he draft prevents that attack by using a hash keyed with the master secret,= which defeats catalog attacks, and also by limiting the length of the nonc= e to be below the length of the hash, which in theory prevents collision at= tacks. Explaining that would be neat. As I said, I am interested in reviving that draft, and adapting it to TLS 1= .3. Does someone else share the feeling? -- Christian Huitema --_000_BN6PR03MB2675BA146E2ACC19C754B2DCA8150BN6PR03MB2675namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Daniel Kaiser and I are working on a “pairing&= #8221; specification in the context of DNS SD. Short Authentication Strings= are one of the preferred methods for verifying pairings. I would like to u= se TLS as much as possible in the pairing protocol. EKR pointed me to the expired draft by Ian Miers, Matthe= w Green and him: https://tool= s.ietf.org/html/draft-miers-tls-sas-00. I am interested in reviving tha= t draft.

 

The draft implements a classic = 220;coin flipping” protocol into TLS, using a “commit be= fore disclose” logic to prevent Nessie from hiding as an MITM between= Alice and Bob. From my superficial reading, this looks fine. I could use a reference to http://people.csail.mit.edu/shaih/pubs/hm96.pdf, both to explain why th= e attack by Halevi and Micali does not apply to this particular construct, = and also to provide a 20 years old reference to similar algorithms, which m= ay be useful in this day and age.

 

One nit, though. If Nessie has infinite computing re= source, she can build a catalog of multiple random values that all hash to = the same string, and then use that catalog to work around the commitment pr= otocol. The scheme in the draft prevents that attack by using a hash keyed with the master secret, which defeats ca= talog attacks, and also by limiting the length of the nonce to be below the= length of the hash, which in theory prevents collision attacks. Explaining= that would be neat.

 

As I said, I am interested in reviving that draft, a= nd adapting it to TLS 1.3. Does someone else share the feeling?<= /p>

 

-- Christian Huitema

 

=  

--_000_BN6PR03MB2675BA146E2ACC19C754B2DCA8150BN6PR03MB2675namp_-- From nobody Thu Aug 18 11:21:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664B612D8F9 for ; Thu, 18 Aug 2016 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONk7f_jVmeFX for ; Thu, 18 Aug 2016 11:21:52 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D7812D140 for ; Thu, 18 Aug 2016 11:21:52 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id r9so14687586ywg.0 for ; Thu, 18 Aug 2016 11:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hEjODIWCN4jatVVU2AR06q9OCG9pT95KQaOQcWcUVkU=; b=0osdHyeLZx4ahrGP7LgjtuJnWZN9T4SM3fTx5tT56iEu6MHajPhnyK9rBKIfh4VF7G 4JlZhFG4QUM+djeNZ0g/81O0ddXjegKE49Je/wX3jxngxNaW/UAS3xOYyTagoTAP4613 n8o5Xul7yW374vb7iN39bwz4X/Wip9KbDATErgEHiLbEk2XsthOj5xAIUwPPQ+8spN0G UvxByyw2iEnEH+iN77nROtGo+sV0kaQroQXJvRNndHXi+Xq0eq9JBukVNmhAU64UEthy ahUBRC6jNRJc03hc494kRBrzln5NiU/0pGKejqKqfA+BCoFXTfgZ18sGNN7PhGEVLNDG lVQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hEjODIWCN4jatVVU2AR06q9OCG9pT95KQaOQcWcUVkU=; b=YGX+ac2FXNjDnz5qlJy8TMkfy2ekvXzERK9oIVuviw8MmtSYRQxYlnM4sklW8p/3Kv Iplmd05xO3h2Ey1/RIh+xWqvsoZ8ejUNA5eTYG/r8H1yikD7yTxttDrm9oUYY7htp5pT B/MGGHazur2xr76efVqyFDfNr1aUtnsdGW812jqrIxQZvGDQxODlnDaaBN1Bh0SxojjU mcYdjYCCYWKkrJm0BY2cOomDgVMuTWAg3NcYX/0t9iQcQ3856CjuLHMi1MAksBEBzSPO rQ3PrWVkd9dLWh0MrAIgpUpi/A2NEhtjhDjQ9HF2dfr/CSRlUoZfJtEOPrJ7uqrUyKWi I3kQ== X-Gm-Message-State: AEkooutXrOB78UpApzU16mRtulqbDc7RLN6YjmCPLypQI4JYXdKT3pSWP1pKpzTHemo8BLPScmI/IdNWQDMlzg== X-Received: by 10.13.249.135 with SMTP id j129mr2981410ywf.267.1471544511213; Thu, 18 Aug 2016 11:21:51 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Thu, 18 Aug 2016 11:21:10 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Keith Winstein Date: Thu, 18 Aug 2016 11:21:10 -0700 X-Google-Sender-Auth: 6U1JHddhLqu2kgy43EY9uSn27RI Message-ID: To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 18:21:55 -0000 It sounds like there are four properties in play here: P1: Either side can rekey its outgoing traffic whenever it wants. P2: Either side can "force an update to the entire connection," i.e. can ask the other side to rekey *its* outgoing traffic. P3: A side can learn that P1 has been read by the other side. P4: Neither side can cause the other to accrue an unbounded deferred write obligation; in fact the maximum accruable deferred write obligation is one KeyUpdate. The current draft has P1 and P2 only. My view: all four properties are important. I've previously argued for the benefit of P3. Re: P2, there seems to be some disagreement about the value. I think it is -- one endpoint may well have knowledge (about the traffic or its future susceptibility to compromise) that makes it want to ratchet the session. Forward secrecy is not only valuable to the sender. I don't think it's enough to recommend that each side rekey its own direction occasionally. I don't think it's a particularly hard design or implementation challenge to get all four properties. Here a simple explicit and verbose design as a straw-man, that gets P1, P2, P3, and P4: 1) As David proposes, separate the tracks and have two KeyUpdate ladders. 2) Define KeyUpdate like this: struct { uint64 desired_minimum_receive_generation; uint64 current_receive_generation; } KeyUpdate; Language: "An implementation MAY update its send keys by sending a KeyUpdate. An implementation MAY request that the other side update its send keys by increasing the desired_minimum_receive_generation. An implementation MUST NOT set desired_minimum_receive_generation to be greater than its current_receive_generation plus one." "Upon receiving a KeyUpdate, the receiver MUST increment their receiving generation by one. If the desired_minimum_receive_generation is greater than its current send generation, the receiver MUST update its send keys and send a KeyUpdate. If the desired_minimum_receive_generation is greater than the current send generation plus one, the receiver SHOULD abort." -Keith On Thu, Aug 18, 2016 at 10:26 AM, David Benjamin wrote: > On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk wrote: >> >> On 08/17/2016 11:29 PM, David Benjamin wrote: >> >> However, we lose the "free" (really at the cost of this unboundedness >> problem) generation-based bidirectional KeyUpdate sync. Depending on what we >> want out of KeyUpdate, I can imagine a few options: >> >> >> My recollection is that the only reason we have KeyUpdate is to avoid >> going over the limit for amount of ciphertext encrypted in the same key >> within our safety margin (recall the analyses debating whether such limits >> would even be reachable for the ciphers currently in use, as well as the >> disagreement as to what the safety margin should be). >> >> >> - Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate >> every N records or so and leave it at that. (I think this is the best option >> on grounds of simplicity, assuming it meets the primary needs of KeyUpdate.) >> >> >> If we're in a world where implementations are considering leaving out the >> required "catch up" KeyUpdate, we may want to consider alternative options >> to put in the spec that are easier to implement. That is, we can write the >> spec in various ways to get the functionality that both write directions get >> the key updates needed to avoid the ciphertext limit, and we are reliant on >> implementations to follow the spec in order to get that safety property. >> So, given that we can only get the safety property if all implementations >> follow the spec, why not just ... require implementations to track the >> amount sent and rekey if it's too close to the limit? That is consistent >> with a unilateral/unidirectional KeyUpdate, and having per-connection >> byte/record counters does not seem to be a huge overhead. >> >> Keeping the two write directions' keys independent would also avoid >> conflict when the two peers disagree on how often a rekey is necessary (as >> might happen if a resource-constrained device decided to not implement byte >> counters and just rekey after every N records, which is "free" since you >> need to track serial numbers anyway). > > > Yup. If we say implementations SHOULD/MUST/whatever send KeyUpdates > frequently and we're fine with just saying we rely on each sender to honor > that w.r.t. their own send keys with little other fanfare, I think this > option is the clear winner. We're already relying on the sender to not, say, > exfiltrate all data somewhere nasty. > > There seemed to be other motivations for KeyUpdate (Keith's passive observer > use case, I've heard some theories around one side knowing more about the > cipher than another, etc.), so I left that alone for now. I'm not currently > convinced by those use cases, but perhaps the working group feels > differently. I'm reasonably confident splitting the key tracks is correct > regardless, but I wasn't sure which KeyUpdate motivations were considered > important and which weren't. > >> >> - If you receive a KeyUpdate and didn't send one in the last N minutes >> (where N minutes >>> 1 RTT), (optionally?) flag your next write to be >> preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to prevent >> ping-ponging. >> >> - Variations on sticking a please_echo boolean in the KeyUpdate message, >> generation counts, etc., to get synchronization with coalescing if we need >> it. I would much prefer the simpler options unless we truly need this. >> (KeyUpdate is right now a *required* feature, so simplicity should be a >> priority. Rare use cases are what extensions are for.) >> >> Thoughts? >> >> David >> >> PS: We've seen this before with renego (I've seen many OpenSSL consumers >> which lock up if the peer renegotiation), error alerts triggered on reads >> (often they don't get sent), and close_notify (also don't get sent in >> practice). Deviations from dumb filters are expensive. >> >> >> Yes, simple is better. Well, here at least :) >> >> >> PPS: I'm wary of over-extending post-handshake auth for the same reason, >> though I haven't had time to look carefully at the latest proposal yet. >> Still, having TLS specify and analyze the crypto while lifting the actual >> messages into application-level framing would be preferable for these sorts >> of side protocols. The application gets to make assumptions about read/write >> flows and knows in which contexts what is and isn't allowed. >> >> >> Hmm, so [in the above proposal] that would involve the application doing >> the byte/record counters and pushing a "give me a rekey packet now" button >> when needed? I am not sure that I'm comfortable moving "crypto sensitive" >> code (well, sort-of) into the application, since many applications won't do >> it. Also, not all applications will have access to the record serial >> number, as I understand it, and the formulas I remember for the ciphertext >> limits involved both records and bytes. > > > Sorry, that was unclear. That was more of a side comment to help explain why > I have such strong visceral reactions to any post-handshake auth mechanisms > since part of it is the same issue. I am not proposing we lift KeyUpdate to > the application layer. I'm proposing we split the KeyUpdate tracks in two > and do [insert preferred option here] w.r.t. the bidirectionality issue. > Probably should not have mentioned it since it's mostly a distraction for > this topic. I ramble a lot. :-) > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Aug 18 11:56:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42BC12D7F2 for ; Thu, 18 Aug 2016 11:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoQaVugt6H0w for ; Thu, 18 Aug 2016 11:55:58 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 7530712D7D7 for ; Thu, 18 Aug 2016 11:55:58 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m101so27638980ioi.2 for ; Thu, 18 Aug 2016 11:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k+u63FaIPn85+o2+tV+5Bh/h02+km/oNi7/Ty6DDYe8=; b=c7mpGn4ubRxeeqwYPJzdDHtyl37bl+bublF+15Qovme15ZxhNQC7+kgcjEfCV3jSyY flS7IsdR9pCKTaAHqsAD3lmeWvgv/cdhZlrHHg66HYZZxr2jPPU5r/cOmmrEpBLcVmtJ usJrFl4yAENxHrbgXxWW2UaKr0l1IF7q061+A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k+u63FaIPn85+o2+tV+5Bh/h02+km/oNi7/Ty6DDYe8=; b=JoC9cX2XnUtNc+WT8eeAYplhxMtK4yaI7pDlhK0lOaH8fkr6bRgoV3xQRn58DheLmR 8k1nrioV1tHIsLxJeNf/U1rDw9JUP2DnYXVh2kNbe2NZEEztBS5ASQLmDW4k8Jp3jiJe se21nqdYVQSk5rb8Mp9ZdO/vfsqxjRMJmFsB1ChndGJxWJO/LLaNZ2QtozMJ0qjCQbi0 O5t3El6PMf55eD7IjXSM5FROMPCDtPeQx4NPeKU3O/7ChSkgXC124P3oFMH4i8HoX/Ey 65Ubz5iFEY70mC+rlSHBjxeU/KMOQpdsRbbMoyyJeqG+dO6ojTiz2aEogtTYkKdDLTLp 8jpg== X-Gm-Message-State: AEkoouulZxi9d50jk1hbHoTfkEowHIklk2x2CosJMcRdncTOhT6QStDnv2bESwfu0ECdNf4G4qIciugKsvofP16m X-Received: by 10.107.52.198 with SMTP id b189mr5209152ioa.6.1471546557366; Thu, 18 Aug 2016 11:55:57 -0700 (PDT) MIME-Version: 1.0 References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> In-Reply-To: From: David Benjamin Date: Thu, 18 Aug 2016 18:55:46 +0000 Message-ID: To: Keith Winstein Content-Type: multipart/alternative; boundary=001a11440f7ed2c3ba053a5d21a2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 18:56:02 -0000 --001a11440f7ed2c3ba053a5d21a2 Content-Type: text/plain; charset=UTF-8 Yeah, something of this sort should work. I'm fuzzy on P2 and especially unconvinced by P3, so I default to preferring less mechanism than more, but I'm certainly wrong a lot of the time and am not totally clear on which properties the WG cares about. As you say, it's not particularly invasive to get all of them. I'd be even happier if the bound were zero instead of one, but one is fine. On Thu, Aug 18, 2016 at 2:21 PM Keith Winstein wrote: > It sounds like there are four properties in play here: > > P1: Either side can rekey its outgoing traffic whenever it wants. > > P2: Either side can "force an update to the entire connection," i.e. > can ask the other side to rekey *its* outgoing traffic. > > P3: A side can learn that P1 has been read by the other side. > > P4: Neither side can cause the other to accrue an unbounded deferred > write obligation; in fact the maximum accruable deferred write > obligation is one KeyUpdate. > > The current draft has P1 and P2 only. > > My view: all four properties are important. > > I've previously argued for the benefit of P3. > > Re: P2, there seems to be some disagreement about the value. I think > it is -- one endpoint may well have knowledge (about the traffic or > its future susceptibility to compromise) that makes it want to ratchet > the session. Forward secrecy is not only valuable to the sender. I > don't think it's enough to recommend that each side rekey its own > direction occasionally. > > I don't think it's a particularly hard design or implementation > challenge to get all four properties. > > Here a simple explicit and verbose design as a straw-man, that gets > P1, P2, P3, and P4: > > 1) As David proposes, separate the tracks and have two KeyUpdate ladders. > > 2) Define KeyUpdate like this: > > struct { > uint64 desired_minimum_receive_generation; > uint64 current_receive_generation; > } KeyUpdate; > > Language: "An implementation MAY update its send keys by sending a > KeyUpdate. An implementation MAY request that the other side update > its send keys by increasing the desired_minimum_receive_generation. An > implementation MUST NOT set desired_minimum_receive_generation to be > greater than its current_receive_generation plus one." > It seems desired_minimum_receive_generation can only be current_receive_generation or current_receive_generation + 1. In that case, a boolean should be sufficient and saves 7 bytes. Nit: Do you really need that large of a generation number? DTLS renego only ever let you count 2^16 epochs. Not that it matters. > "Upon receiving a KeyUpdate, the receiver MUST increment their > receiving generation by one. If the desired_minimum_receive_generation > is greater than its current send generation, the receiver MUST update > its send keys and send a KeyUpdate. If the > desired_minimum_receive_generation is greater than the current send > generation plus one, the receiver SHOULD abort." > Nit: Probably should explicitly say to fail with illegal_parameter or so. > -Keith > > On Thu, Aug 18, 2016 at 10:26 AM, David Benjamin > wrote: > > On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk > wrote: > >> > >> On 08/17/2016 11:29 PM, David Benjamin wrote: > >> > >> However, we lose the "free" (really at the cost of this unboundedness > >> problem) generation-based bidirectional KeyUpdate sync. Depending on > what we > >> want out of KeyUpdate, I can imagine a few options: > >> > >> > >> My recollection is that the only reason we have KeyUpdate is to avoid > >> going over the limit for amount of ciphertext encrypted in the same key > >> within our safety margin (recall the analyses debating whether such > limits > >> would even be reachable for the ciphers currently in use, as well as the > >> disagreement as to what the safety margin should be). > >> > >> > >> - Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate > >> every N records or so and leave it at that. (I think this is the best > option > >> on grounds of simplicity, assuming it meets the primary needs of > KeyUpdate.) > >> > >> > >> If we're in a world where implementations are considering leaving out > the > >> required "catch up" KeyUpdate, we may want to consider alternative > options > >> to put in the spec that are easier to implement. That is, we can write > the > >> spec in various ways to get the functionality that both write > directions get > >> the key updates needed to avoid the ciphertext limit, and we are > reliant on > >> implementations to follow the spec in order to get that safety property. > >> So, given that we can only get the safety property if all > implementations > >> follow the spec, why not just ... require implementations to track the > >> amount sent and rekey if it's too close to the limit? That is > consistent > >> with a unilateral/unidirectional KeyUpdate, and having per-connection > >> byte/record counters does not seem to be a huge overhead. > >> > >> Keeping the two write directions' keys independent would also avoid > >> conflict when the two peers disagree on how often a rekey is necessary > (as > >> might happen if a resource-constrained device decided to not implement > byte > >> counters and just rekey after every N records, which is "free" since you > >> need to track serial numbers anyway). > > > > > > Yup. If we say implementations SHOULD/MUST/whatever send KeyUpdates > > frequently and we're fine with just saying we rely on each sender to > honor > > that w.r.t. their own send keys with little other fanfare, I think this > > option is the clear winner. We're already relying on the sender to not, > say, > > exfiltrate all data somewhere nasty. > > > > There seemed to be other motivations for KeyUpdate (Keith's passive > observer > > use case, I've heard some theories around one side knowing more about the > > cipher than another, etc.), so I left that alone for now. I'm not > currently > > convinced by those use cases, but perhaps the working group feels > > differently. I'm reasonably confident splitting the key tracks is correct > > regardless, but I wasn't sure which KeyUpdate motivations were considered > > important and which weren't. > > > >> > >> - If you receive a KeyUpdate and didn't send one in the last N minutes > >> (where N minutes >>> 1 RTT), (optionally?) flag your next write to be > >> preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to > prevent > >> ping-ponging. > >> > >> - Variations on sticking a please_echo boolean in the KeyUpdate message, > >> generation counts, etc., to get synchronization with coalescing if we > need > >> it. I would much prefer the simpler options unless we truly need this. > >> (KeyUpdate is right now a *required* feature, so simplicity should be a > >> priority. Rare use cases are what extensions are for.) > >> > >> Thoughts? > >> > >> David > >> > >> PS: We've seen this before with renego (I've seen many OpenSSL consumers > >> which lock up if the peer renegotiation), error alerts triggered on > reads > >> (often they don't get sent), and close_notify (also don't get sent in > >> practice). Deviations from dumb filters are expensive. > >> > >> > >> Yes, simple is better. Well, here at least :) > >> > >> > >> PPS: I'm wary of over-extending post-handshake auth for the same reason, > >> though I haven't had time to look carefully at the latest proposal yet. > >> Still, having TLS specify and analyze the crypto while lifting the > actual > >> messages into application-level framing would be preferable for these > sorts > >> of side protocols. The application gets to make assumptions about > read/write > >> flows and knows in which contexts what is and isn't allowed. > >> > >> > >> Hmm, so [in the above proposal] that would involve the application doing > >> the byte/record counters and pushing a "give me a rekey packet now" > button > >> when needed? I am not sure that I'm comfortable moving "crypto > sensitive" > >> code (well, sort-of) into the application, since many applications > won't do > >> it. Also, not all applications will have access to the record serial > >> number, as I understand it, and the formulas I remember for the > ciphertext > >> limits involved both records and bytes. > > > > > > Sorry, that was unclear. That was more of a side comment to help explain > why > > I have such strong visceral reactions to any post-handshake auth > mechanisms > > since part of it is the same issue. I am not proposing we lift KeyUpdate > to > > the application layer. I'm proposing we split the KeyUpdate tracks in two > > and do [insert preferred option here] w.r.t. the bidirectionality issue. > > Probably should not have mentioned it since it's mostly a distraction for > > this topic. I ramble a lot. :-) > > > > David > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --001a11440f7ed2c3ba053a5d21a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, something of this sort should work. I'm fuzzy on= P2 and especially unconvinced by P3, so I default to preferring less mecha= nism than more, but I'm certainly wrong a lot of the time and am not to= tally clear on which properties the WG cares about.

As y= ou say, it's not particularly invasive to get all of them. I'd be e= ven happier if the bound were zero instead of one, but one is fine.
On Thu, Aug 18, 2016 at 2:21 P= M Keith Winstein <keithw@cs.st= anford.edu> wrote:
It sound= s like there are four properties in play here:

P1: Either side can rekey its outgoing traffic whenever it wants.

P2: Either side can "force an update to the entire connection," i= .e.
can ask the other side to rekey *its* outgoing traffic.

P3: A side can learn that P1 has been read by the other side.

P4: Neither side can cause the other to accrue an unbounded deferred
write obligation; in fact the maximum accruable deferred write
obligation is one KeyUpdate.

The current draft has P1 and P2 only.

My view: all four properties are important.

I've previously argued for the benefit of P3.

Re: P2, there seems to be some disagreement about the value. I think
it is -- one endpoint may well have knowledge (about the traffic or
its future susceptibility to compromise) that makes it want to ratchet
the session. Forward secrecy is not only valuable to the sender. I
don't think it's enough to recommend that each side rekey its own direction occasionally.

I don't think it's a particularly hard design or implementation
challenge to get all four properties.

Here a simple explicit and verbose design as a straw-man, that gets
P1, P2, P3, and P4:

1) As David proposes, separate the tracks and have two KeyUpdate ladders.
2) Define KeyUpdate like this:

=C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uint64 desired_minimum_receive_generation;
=C2=A0 =C2=A0 =C2=A0 =C2=A0uint64 current_receive_generation;
=C2=A0 =C2=A0} KeyUpdate;

Language: "An implementation MAY update its send keys by sending a
KeyUpdate. An implementation MAY request that the other side update
its send keys by increasing the desired_minimum_receive_generation. An
implementation MUST NOT set desired_minimum_receive_generation to be
greater than its current_receive_generation plus one."

It seems desired_minimum_receive_generation can only b= e current_receive_generation or=C2=A0current_receive_generation=C2=A0+ 1. I= n that case, a boolean should be sufficient and saves 7 bytes.

Nit: = Do you really need that large of a generation number? DTLS renego only ever= let you count 2^16 epochs. Not that it matters.
=C2=A0
"Upon receiving a KeyUpdate, the receiver MUST increment their
receiving generation by one. If the desired_minimum_receive_generation
is greater than its current send generation, the receiver MUST update
its send keys and send a KeyUpdate. If the
desired_minimum_receive_generation is greater than the current send
generation plus one, the receiver SHOULD abort."
=
Nit: Probably should explicitly say to fail with illegal_par= ameter or so.
=C2=A0
-Keith

On Thu, Aug 18, 2016 at 10:26 AM, David Benjamin <davidben@chromium.org> wrote: > On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
>>
>> On 08/17/2016 11:29 PM, David Benjamin wrote:
>>
>> However, we lose the "free" (really at the cost of this = unboundedness
>> problem) generation-based bidirectional KeyUpdate sync. Depending = on what we
>> want out of KeyUpdate, I can imagine a few options:
>>
>>
>> My recollection is that the only reason we have KeyUpdate is to av= oid
>> going over the limit for amount of ciphertext encrypted in the sam= e key
>> within our safety margin (recall the analyses debating whether suc= h limits
>> would even be reachable for the ciphers currently in use, as well = as the
>> disagreement as to what the safety margin should be).
>>
>>
>> - Don't. KeyUpdates are unilateral. Recommend in the spec to K= eyUpdate
>> every N records or so and leave it at that. (I think this is the b= est option
>> on grounds of simplicity, assuming it meets the primary needs of K= eyUpdate.)
>>
>>
>> If we're in a world where implementations are considering leav= ing out the
>> required "catch up" KeyUpdate, we may want to consider a= lternative options
>> to put in the spec that are easier to implement.=C2=A0 That is, we= can write the
>> spec in various ways to get the functionality that both write dire= ctions get
>> the key updates needed to avoid the ciphertext limit, and we are r= eliant on
>> implementations to follow the spec in order to get that safety pro= perty.
>> So, given that we can only get the safety property if all implemen= tations
>> follow the spec, why not just ... require implementations to track= the
>> amount sent and rekey if it's too close to the limit?=C2=A0 Th= at is consistent
>> with a unilateral/unidirectional KeyUpdate, and having per-connect= ion
>> byte/record counters does not seem to be a huge overhead.
>>
>> Keeping the two write directions' keys independent would also = avoid
>> conflict when the two peers disagree on how often a rekey is neces= sary (as
>> might happen if a resource-constrained device decided to not imple= ment byte
>> counters and just rekey after every N records, which is "free= " since you
>> need to track serial numbers anyway).
>
>
> Yup. If we say implementations SHOULD/MUST/whatever send KeyUpdates > frequently and we're fine with just saying we rely on each sender = to honor
> that w.r.t. their own send keys with little other fanfare, I think thi= s
> option is the clear winner. We're already relying on the sender to= not, say,
> exfiltrate all data somewhere nasty.
>
> There seemed to be other motivations for KeyUpdate (Keith's passiv= e observer
> use case, I've heard some theories around one side knowing more ab= out the
> cipher than another, etc.), so I left that alone for now. I'm not = currently
> convinced by those use cases, but perhaps the working group feels
> differently. I'm reasonably confident splitting the key tracks is = correct
> regardless, but I wasn't sure which KeyUpdate motivations were con= sidered
> important and which weren't.
>
>>
>> - If you receive a KeyUpdate and didn't send one in the last N= minutes
>> (where N minutes >>> 1 RTT), (optionally?) flag your next= write to be
>> preceded by KeyUpdate. This is simple but needs an ad-hoc timeout = to prevent
>> ping-ponging.
>>
>> - Variations on sticking a please_echo boolean in the KeyUpdate me= ssage,
>> generation counts, etc., to get synchronization with coalescing if= we need
>> it. I would much prefer the simpler options unless we truly need t= his.
>> (KeyUpdate is right now a *required* feature, so simplicity should= be a
>> priority. Rare use cases are what extensions are for.)
>>
>> Thoughts?
>>
>> David
>>
>> PS: We've seen this before with renego (I've seen many Ope= nSSL consumers
>> which lock up if the peer renegotiation), error alerts triggered o= n reads
>> (often they don't get sent), and close_notify (also don't = get sent in
>> practice). Deviations from dumb filters are expensive.
>>
>>
>> Yes, simple is better.=C2=A0 Well, here at least :)
>>
>>
>> PPS: I'm wary of over-extending post-handshake auth for the sa= me reason,
>> though I haven't had time to look carefully at the latest prop= osal yet.
>> Still, having TLS specify and analyze the crypto while lifting the= actual
>> messages into application-level framing would be preferable for th= ese sorts
>> of side protocols. The application gets to make assumptions about = read/write
>> flows and knows in which contexts what is and isn't allowed. >>
>>
>> Hmm, so [in the above proposal] that would involve the application= doing
>> the byte/record counters and pushing a "give me a rekey packe= t now" button
>> when needed?=C2=A0 I am not sure that I'm comfortable moving &= quot;crypto sensitive"
>> code (well, sort-of) into the application, since many applications= won't do
>> it.=C2=A0 Also, not all applications will have access to the recor= d serial
>> number, as I understand it, and the formulas I remember for the ci= phertext
>> limits involved both records and bytes.
>
>
> Sorry, that was unclear. That was more of a side comment to help expla= in why
> I have such strong visceral reactions to any post-handshake auth mecha= nisms
> since part of it is the same issue. I am not proposing we lift KeyUpda= te to
> the application layer. I'm proposing we split the KeyUpdate tracks= in two
> and do [insert preferred option here] w.r.t. the bidirectionality issu= e.
> Probably should not have mentioned it since it's mostly a distract= ion for
> this topic. I ramble a lot. :-)
>
> David
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
--001a11440f7ed2c3ba053a5d21a2-- From nobody Thu Aug 18 12:03:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9B12D99C for ; Thu, 18 Aug 2016 12:03:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWjBPFMOWm6X for ; Thu, 18 Aug 2016 12:03: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 8B8C312D782 for ; Thu, 18 Aug 2016 12:03:47 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D3ADB43342B; Thu, 18 Aug 2016 19:03:46 +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 B21FA433404; Thu, 18 Aug 2016 19:03:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471547026; bh=3dxRNRyLtKNPhnMOrBt1CX9BHSCWfmAdq10LcY1We2A=; l=22422; h=To:References:Cc:From:Date:In-Reply-To:From; b=EsqQEjSlWBUgRjX2hU3MeuMT/3SNKk6LKWL54iyCTOq71gkJqgcx1r+sp3lCZI52Q Eksh3SlJBEpqHNJlon4F0ossPS7aGDImGlCyvCYO7aAD8PDPAkVKZg7H0eogCf+T4P bj5LG2zNoqIabmfe+HOEGURhrryeNZFpkSyY63Rg= 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 503431FC86; Thu, 18 Aug 2016 19:03:46 +0000 (GMT) To: David Benjamin , Keith Winstein References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Benjamin Kaduk Message-ID: <6499a3f9-f50a-4028-b62f-81836f9372bd@akamai.com> Date: Thu, 18 Aug 2016 14:03:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6E04A8EDD22B25150356D1E7" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 19:03:52 -0000 This is a multi-part message in MIME format. --------------6E04A8EDD22B25150356D1E7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I am also fuzzy on P2 and P3, but don't have any complaints with this strawman scheme. -Ben On 08/18/2016 01:55 PM, David Benjamin wrote: > Yeah, something of this sort should work. I'm fuzzy on P2 and > especially unconvinced by P3, so I default to preferring less > mechanism than more, but I'm certainly wrong a lot of the time and am > not totally clear on which properties the WG cares about. > > As you say, it's not particularly invasive to get all of them. I'd be > even happier if the bound were zero instead of one, but one is fine. > > On Thu, Aug 18, 2016 at 2:21 PM Keith Winstein > wrote: > > It sounds like there are four properties in play here: > > P1: Either side can rekey its outgoing traffic whenever it wants. > > P2: Either side can "force an update to the entire connection," i.e. > can ask the other side to rekey *its* outgoing traffic. > > P3: A side can learn that P1 has been read by the other side. > > P4: Neither side can cause the other to accrue an unbounded deferred > write obligation; in fact the maximum accruable deferred write > obligation is one KeyUpdate. > > The current draft has P1 and P2 only. > > My view: all four properties are important. > > I've previously argued for the benefit of P3. > > Re: P2, there seems to be some disagreement about the value. I think > it is -- one endpoint may well have knowledge (about the traffic or > its future susceptibility to compromise) that makes it want to ratchet > the session. Forward secrecy is not only valuable to the sender. I > don't think it's enough to recommend that each side rekey its own > direction occasionally. > > I don't think it's a particularly hard design or implementation > challenge to get all four properties. > > Here a simple explicit and verbose design as a straw-man, that gets > P1, P2, P3, and P4: > > 1) As David proposes, separate the tracks and have two KeyUpdate > ladders. > > 2) Define KeyUpdate like this: > > struct { > uint64 desired_minimum_receive_generation; > uint64 current_receive_generation; > } KeyUpdate; > > Language: "An implementation MAY update its send keys by sending a > KeyUpdate. An implementation MAY request that the other side update > its send keys by increasing the desired_minimum_receive_generation. An > implementation MUST NOT set desired_minimum_receive_generation to be > greater than its current_receive_generation plus one." > > > It seems desired_minimum_receive_generation can only be > current_receive_generation or current_receive_generation + 1. In that > case, a boolean should be sufficient and saves 7 bytes. > > Nit: Do you really need that large of a generation number? DTLS renego > only ever let you count 2^16 epochs. Not that it matters. > > > "Upon receiving a KeyUpdate, the receiver MUST increment their > receiving generation by one. If the desired_minimum_receive_generation > is greater than its current send generation, the receiver MUST update > its send keys and send a KeyUpdate. If the > desired_minimum_receive_generation is greater than the current send > generation plus one, the receiver SHOULD abort." > > > Nit: Probably should explicitly say to fail with illegal_parameter or so. > > > -Keith > > On Thu, Aug 18, 2016 at 10:26 AM, David Benjamin > > wrote: > > On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk > > wrote: > >> > >> On 08/17/2016 11:29 PM, David Benjamin wrote: > >> > >> However, we lose the "free" (really at the cost of this > unboundedness > >> problem) generation-based bidirectional KeyUpdate sync. > Depending on what we > >> want out of KeyUpdate, I can imagine a few options: > >> > >> > >> My recollection is that the only reason we have KeyUpdate is to > avoid > >> going over the limit for amount of ciphertext encrypted in the > same key > >> within our safety margin (recall the analyses debating whether > such limits > >> would even be reachable for the ciphers currently in use, as > well as the > >> disagreement as to what the safety margin should be). > >> > >> > >> - Don't. KeyUpdates are unilateral. Recommend in the spec to > KeyUpdate > >> every N records or so and leave it at that. (I think this is > the best option > >> on grounds of simplicity, assuming it meets the primary needs > of KeyUpdate.) > >> > >> > >> If we're in a world where implementations are considering > leaving out the > >> required "catch up" KeyUpdate, we may want to consider > alternative options > >> to put in the spec that are easier to implement. That is, we > can write the > >> spec in various ways to get the functionality that both write > directions get > >> the key updates needed to avoid the ciphertext limit, and we > are reliant on > >> implementations to follow the spec in order to get that safety > property. > >> So, given that we can only get the safety property if all > implementations > >> follow the spec, why not just ... require implementations to > track the > >> amount sent and rekey if it's too close to the limit? That is > consistent > >> with a unilateral/unidirectional KeyUpdate, and having > per-connection > >> byte/record counters does not seem to be a huge overhead. > >> > >> Keeping the two write directions' keys independent would also avoid > >> conflict when the two peers disagree on how often a rekey is > necessary (as > >> might happen if a resource-constrained device decided to not > implement byte > >> counters and just rekey after every N records, which is "free" > since you > >> need to track serial numbers anyway). > > > > > > Yup. If we say implementations SHOULD/MUST/whatever send KeyUpdates > > frequently and we're fine with just saying we rely on each > sender to honor > > that w.r.t. their own send keys with little other fanfare, I > think this > > option is the clear winner. We're already relying on the sender > to not, say, > > exfiltrate all data somewhere nasty. > > > > There seemed to be other motivations for KeyUpdate (Keith's > passive observer > > use case, I've heard some theories around one side knowing more > about the > > cipher than another, etc.), so I left that alone for now. I'm > not currently > > convinced by those use cases, but perhaps the working group feels > > differently. I'm reasonably confident splitting the key tracks > is correct > > regardless, but I wasn't sure which KeyUpdate motivations were > considered > > important and which weren't. > > > >> > >> - If you receive a KeyUpdate and didn't send one in the last N > minutes > >> (where N minutes >>> 1 RTT), (optionally?) flag your next write > to be > >> preceded by KeyUpdate. This is simple but needs an ad-hoc > timeout to prevent > >> ping-ponging. > >> > >> - Variations on sticking a please_echo boolean in the KeyUpdate > message, > >> generation counts, etc., to get synchronization with coalescing > if we need > >> it. I would much prefer the simpler options unless we truly > need this. > >> (KeyUpdate is right now a *required* feature, so simplicity > should be a > >> priority. Rare use cases are what extensions are for.) > >> > >> Thoughts? > >> > >> David > >> > >> PS: We've seen this before with renego (I've seen many OpenSSL > consumers > >> which lock up if the peer renegotiation), error alerts > triggered on reads > >> (often they don't get sent), and close_notify (also don't get > sent in > >> practice). Deviations from dumb filters are expensive. > >> > >> > >> Yes, simple is better. Well, here at least :) > >> > >> > >> PPS: I'm wary of over-extending post-handshake auth for the > same reason, > >> though I haven't had time to look carefully at the latest > proposal yet. > >> Still, having TLS specify and analyze the crypto while lifting > the actual > >> messages into application-level framing would be preferable for > these sorts > >> of side protocols. The application gets to make assumptions > about read/write > >> flows and knows in which contexts what is and isn't allowed. > >> > >> > >> Hmm, so [in the above proposal] that would involve the > application doing > >> the byte/record counters and pushing a "give me a rekey packet > now" button > >> when needed? I am not sure that I'm comfortable moving "crypto > sensitive" > >> code (well, sort-of) into the application, since many > applications won't do > >> it. Also, not all applications will have access to the record > serial > >> number, as I understand it, and the formulas I remember for the > ciphertext > >> limits involved both records and bytes. > > > > > > Sorry, that was unclear. That was more of a side comment to help > explain why > > I have such strong visceral reactions to any post-handshake auth > mechanisms > > since part of it is the same issue. I am not proposing we lift > KeyUpdate to > > the application layer. I'm proposing we split the KeyUpdate > tracks in two > > and do [insert preferred option here] w.r.t. the > bidirectionality issue. > > Probably should not have mentioned it since it's mostly a > distraction for > > this topic. I ramble a lot. :-) > > > > David > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > --------------6E04A8EDD22B25150356D1E7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I am also fuzzy on P2 and P3, but don't have any complaints with this strawman scheme.

-Ben

On 08/18/2016 01:55 PM, David Benjamin wrote:
Yeah, something of this sort should work. I'm fuzzy on P2 and especially unconvinced by P3, so I default to preferring less mechanism than more, but I'm certainly wrong a lot of the time and am not totally clear on which properties the WG cares about.

As you say, it's not particularly invasive to get all of them. I'd be even happier if the bound were zero instead of one, but one is fine.

On Thu, Aug 18, 2016 at 2:21 PM Keith Winstein <keithw@cs.stanford.edu> wrote:
It sounds like there are four properties in play here:

P1: Either side can rekey its outgoing traffic whenever it wants.

P2: Either side can "force an update to the entire connection," i.e.
can ask the other side to rekey *its* outgoing traffic.

P3: A side can learn that P1 has been read by the other side.

P4: Neither side can cause the other to accrue an unbounded deferred
write obligation; in fact the maximum accruable deferred write
obligation is one KeyUpdate.

The current draft has P1 and P2 only.

My view: all four properties are important.

I've previously argued for the benefit of P3.

Re: P2, there seems to be some disagreement about the value. I think
it is -- one endpoint may well have knowledge (about the traffic or
its future susceptibility to compromise) that makes it want to ratchet
the session. Forward secrecy is not only valuable to the sender. I
don't think it's enough to recommend that each side rekey its own
direction occasionally.

I don't think it's a particularly hard design or implementation
challenge to get all four properties.

Here a simple explicit and verbose design as a straw-man, that gets
P1, P2, P3, and P4:

1) As David proposes, separate the tracks and have two KeyUpdate ladders.

2) Define KeyUpdate like this:

   struct {
       uint64 desired_minimum_receive_generation;
       uint64 current_receive_generation;
   } KeyUpdate;

Language: "An implementation MAY update its send keys by sending a
KeyUpdate. An implementation MAY request that the other side update
its send keys by increasing the desired_minimum_receive_generation. An
implementation MUST NOT set desired_minimum_receive_generation to be
greater than its current_receive_generation plus one."

It seems desired_minimum_receive_generation can only be current_receive_generation or current_receive_generation + 1. In that case, a boolean should be sufficient and saves 7 bytes.

Nit: Do you really need that large of a generation number? DTLS renego only ever let you count 2^16 epochs. Not that it matters.
 
"Upon receiving a KeyUpdate, the receiver MUST increment their
receiving generation by one. If the desired_minimum_receive_generation
is greater than its current send generation, the receiver MUST update
its send keys and send a KeyUpdate. If the
desired_minimum_receive_generation is greater than the current send
generation plus one, the receiver SHOULD abort."

Nit: Probably should explicitly say to fail with illegal_parameter or so.
 
-Keith

On Thu, Aug 18, 2016 at 10:26 AM, David Benjamin <davidben@chromium.org> wrote:
> On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
>>
>> On 08/17/2016 11:29 PM, David Benjamin wrote:
>>
>> However, we lose the "free" (really at the cost of this unboundedness
>> problem) generation-based bidirectional KeyUpdate sync. Depending on what we
>> want out of KeyUpdate, I can imagine a few options:
>>
>>
>> My recollection is that the only reason we have KeyUpdate is to avoid
>> going over the limit for amount of ciphertext encrypted in the same key
>> within our safety margin (recall the analyses debating whether such limits
>> would even be reachable for the ciphers currently in use, as well as the
>> disagreement as to what the safety margin should be).
>>
>>
>> - Don't. KeyUpdates are unilateral. Recommend in the spec to KeyUpdate
>> every N records or so and leave it at that. (I think this is the best option
>> on grounds of simplicity, assuming it meets the primary needs of KeyUpdate.)
>>
>>
>> If we're in a world where implementations are considering leaving out the
>> required "catch up" KeyUpdate, we may want to consider alternative options
>> to put in the spec that are easier to implement.  That is, we can write the
>> spec in various ways to get the functionality that both write directions get
>> the key updates needed to avoid the ciphertext limit, and we are reliant on
>> implementations to follow the spec in order to get that safety property.
>> So, given that we can only get the safety property if all implementations
>> follow the spec, why not just ... require implementations to track the
>> amount sent and rekey if it's too close to the limit?  That is consistent
>> with a unilateral/unidirectional KeyUpdate, and having per-connection
>> byte/record counters does not seem to be a huge overhead.
>>
>> Keeping the two write directions' keys independent would also avoid
>> conflict when the two peers disagree on how often a rekey is necessary (as
>> might happen if a resource-constrained device decided to not implement byte
>> counters and just rekey after every N records, which is "free" since you
>> need to track serial numbers anyway).
>
>
> Yup. If we say implementations SHOULD/MUST/whatever send KeyUpdates
> frequently and we're fine with just saying we rely on each sender to honor
> that w.r.t. their own send keys with little other fanfare, I think this
> option is the clear winner. We're already relying on the sender to not, say,
> exfiltrate all data somewhere nasty.
>
> There seemed to be other motivations for KeyUpdate (Keith's passive observer
> use case, I've heard some theories around one side knowing more about the
> cipher than another, etc.), so I left that alone for now. I'm not currently
> convinced by those use cases, but perhaps the working group feels
> differently. I'm reasonably confident splitting the key tracks is correct
> regardless, but I wasn't sure which KeyUpdate motivations were considered
> important and which weren't.
>
>>
>> - If you receive a KeyUpdate and didn't send one in the last N minutes
>> (where N minutes >>> 1 RTT), (optionally?) flag your next write to be
>> preceded by KeyUpdate. This is simple but needs an ad-hoc timeout to prevent
>> ping-ponging.
>>
>> - Variations on sticking a please_echo boolean in the KeyUpdate message,
>> generation counts, etc., to get synchronization with coalescing if we need
>> it. I would much prefer the simpler options unless we truly need this.
>> (KeyUpdate is right now a *required* feature, so simplicity should be a
>> priority. Rare use cases are what extensions are for.)
>>
>> Thoughts?
>>
>> David
>>
>> PS: We've seen this before with renego (I've seen many OpenSSL consumers
>> which lock up if the peer renegotiation), error alerts triggered on reads
>> (often they don't get sent), and close_notify (also don't get sent in
>> practice). Deviations from dumb filters are expensive.
>>
>>
>> Yes, simple is better.  Well, here at least :)
>>
>>
>> PPS: I'm wary of over-extending post-handshake auth for the same reason,
>> though I haven't had time to look carefully at the latest proposal yet.
>> Still, having TLS specify and analyze the crypto while lifting the actual
>> messages into application-level framing would be preferable for these sorts
>> of side protocols. The application gets to make assumptions about read/write
>> flows and knows in which contexts what is and isn't allowed.
>>
>>
>> Hmm, so [in the above proposal] that would involve the application doing
>> the byte/record counters and pushing a "give me a rekey packet now" button
>> when needed?  I am not sure that I'm comfortable moving "crypto sensitive"
>> code (well, sort-of) into the application, since many applications won't do
>> it.  Also, not all applications will have access to the record serial
>> number, as I understand it, and the formulas I remember for the ciphertext
>> limits involved both records and bytes.
>
>
> Sorry, that was unclear. That was more of a side comment to help explain why
> I have such strong visceral reactions to any post-handshake auth mechanisms
> since part of it is the same issue. I am not proposing we lift KeyUpdate to
> the application layer. I'm proposing we split the KeyUpdate tracks in two
> and do [insert preferred option here] w.r.t. the bidirectionality issue.
> Probably should not have mentioned it since it's mostly a distraction for
> this topic. I ramble a lot. :-)
>
> David
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--------------6E04A8EDD22B25150356D1E7-- From nobody Thu Aug 18 12:10:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FF312D794 for ; Thu, 18 Aug 2016 12:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWww_YrrO1cO for ; Thu, 18 Aug 2016 12:10:50 -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 61B1A12D122 for ; Thu, 18 Aug 2016 12:10:50 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id v123so25823329qkh.2 for ; Thu, 18 Aug 2016 12:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SA/iNS54Bo67wXljCNAW32IteOHR0+eF7P7fnC3dSBg=; b=h30nnAD/YQ4qCEiALQZAzDoIBbjcB3W5ocZyVSU+HcWU6eU+Tfrrad385Y3HmyaZ0L qhmBeRjea1vFBpmFxqiXdOwHdccM+qDC8PYCMJjtRjfpmW3dtK5PvTprdF5tRRP/0OVR UuK5Uou/u27w0rwXTr0SFpx1lQ3KaSWzoxT0ixKIz4oPN9NsEgchG0QGLGQd8NotPgp1 /RtcBn08PufySmkUFOAwDC2R6Uc0F6vO9KvdTOd/iB9MF0Of8KOwwXihWi7Nit+Ngyrr /+ayHYI9l9RaZkgxZWC2i8vF77O5V/1G8KF6tpnmvFkqva3CG5ytTVi8RvtE24blL6Fe WoCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SA/iNS54Bo67wXljCNAW32IteOHR0+eF7P7fnC3dSBg=; b=RKbdZr0H9L3sRU/I3oqhHN31myJ0JeHFOsX5H+49zJs0Bkg1T3H4cGq+j68eUnnbd6 m7eqD16M9PYvN/BNKumCDb89yoqIkqrLBPA+g18ajQ5OQroVrxM2Z0KnGu/6o+Hu2IEm unsGuJoXRruoJjAdRy+CZc+mcmpSXUlaIOceZ4glgxqvBXEbStMQnqwDMYqLvAumrcz4 iKqBwEcCvVTKaGrTk3wgZASKoj1wkOBFM5tfrUpfG4OfND5xEI/83Uu/QmFHS81loH/k er81DAa+OPgCWc8UVvmsZHvmLJ+GVU+Pdk+bMBP1gf4SGH58ceOhtz3D3/435b6zFQeZ Wq5w== X-Gm-Message-State: AEkoouuId6w89KXKCiYlb7Zjfg9sqX7/oISftPRZI8KC96x1+KHRqZhhuYx1LGnElRJRkUEMu42YjcgQz6JJFA== X-Received: by 10.55.58.68 with SMTP id h65mr4602693qka.210.1471547449493; Thu, 18 Aug 2016 12:10:49 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.200.36.199 with HTTP; Thu, 18 Aug 2016 12:10:48 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Adam Langley Date: Thu, 18 Aug 2016 12:10:48 -0700 X-Google-Sender-Auth: hNDWa5yUYnzfCHoeJEThbqfTx5k Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a1148b7c6ff4de4053a5d56aa Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 19:10:52 -0000 --001a1148b7c6ff4de4053a5d56aa Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 11:55 AM, David Benjamin wrote: > It seems desired_minimum_receive_generation can only be > current_receive_generation or current_receive_generation + 1. In that > case, a boolean should be sufficient and saves 7 bytes. > Given that simplification, is there a purpose for current_receive_generation? It seems that scheme might be equal to a "please_echo" flag. Cheers AGL --001a1148b7c6ff4de4053a5d56aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Given= that simplification, is there a purpose for=C2=A0current_receive_generation? It seems that scheme might be equal to = a "please_echo" flag.


= Cheers

AGL
--001a1148b7c6ff4de4053a5d56aa-- From nobody Thu Aug 18 12:14:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD7712D794 for ; Thu, 18 Aug 2016 12:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqoBOq-I-I1h for ; Thu, 18 Aug 2016 12:14:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D284512D122 for ; Thu, 18 Aug 2016 12:14:09 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 18 Aug 2016 12:25:57 -0700 From: Jim Schaad To: 'Keith Winstein' , 'David Benjamin' References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> In-Reply-To: Date: Thu, 18 Aug 2016 12:13:37 -0700 Message-ID: <08a201d1f984$a16b2d10$e4418730$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLBzL2rhv6uAYGgpFsZh/u28QZ33wIMUf02AbA1oKIB270F0p5CrRLg Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 19:14:13 -0000 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Keith Winstein > Sent: Thursday, August 18, 2016 11:21 AM > To: David Benjamin > Cc: tls@ietf.org > Subject: Re: [TLS] KeyUpdate and unbounded write obligations > > It sounds like there are four properties in play here: > > P1: Either side can rekey its outgoing traffic whenever it wants. > > P2: Either side can "force an update to the entire connection," i.e. > can ask the other side to rekey *its* outgoing traffic. > > P3: A side can learn that P1 has been read by the other side. If you are not getting any traffic back, it seems that this might a problem. P1 + P3 causing P4. Unless you are willing to not know the difference between traffic getting lost and traffic being processed. Jim > > P4: Neither side can cause the other to accrue an unbounded deferred write > obligation; in fact the maximum accruable deferred write obligation is one > KeyUpdate. > > The current draft has P1 and P2 only. > > My view: all four properties are important. > > I've previously argued for the benefit of P3. > > Re: P2, there seems to be some disagreement about the value. I think it is -- one > endpoint may well have knowledge (about the traffic or its future susceptibility > to compromise) that makes it want to ratchet the session. Forward secrecy is > not only valuable to the sender. I don't think it's enough to recommend that > each side rekey its own direction occasionally. > > I don't think it's a particularly hard design or implementation challenge to get all > four properties. > > Here a simple explicit and verbose design as a straw-man, that gets P1, P2, P3, > and P4: > > 1) As David proposes, separate the tracks and have two KeyUpdate ladders. > > 2) Define KeyUpdate like this: > > struct { > uint64 desired_minimum_receive_generation; > uint64 current_receive_generation; > } KeyUpdate; > > Language: "An implementation MAY update its send keys by sending a > KeyUpdate. An implementation MAY request that the other side update its send > keys by increasing the desired_minimum_receive_generation. An > implementation MUST NOT set desired_minimum_receive_generation to be > greater than its current_receive_generation plus one." > > "Upon receiving a KeyUpdate, the receiver MUST increment their receiving > generation by one. If the desired_minimum_receive_generation > is greater than its current send generation, the receiver MUST update its send > keys and send a KeyUpdate. If the desired_minimum_receive_generation is > greater than the current send generation plus one, the receiver SHOULD abort." > > -Keith > > On Thu, Aug 18, 2016 at 10:26 AM, David Benjamin > wrote: > > On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk > wrote: > >> > >> On 08/17/2016 11:29 PM, David Benjamin wrote: > >> > >> However, we lose the "free" (really at the cost of this unboundedness > >> problem) generation-based bidirectional KeyUpdate sync. Depending on > >> what we want out of KeyUpdate, I can imagine a few options: > >> > >> > >> My recollection is that the only reason we have KeyUpdate is to avoid > >> going over the limit for amount of ciphertext encrypted in the same > >> key within our safety margin (recall the analyses debating whether > >> such limits would even be reachable for the ciphers currently in use, > >> as well as the disagreement as to what the safety margin should be). > >> > >> > >> - Don't. KeyUpdates are unilateral. Recommend in the spec to > >> KeyUpdate every N records or so and leave it at that. (I think this > >> is the best option on grounds of simplicity, assuming it meets the > >> primary needs of KeyUpdate.) > >> > >> > >> If we're in a world where implementations are considering leaving out > >> the required "catch up" KeyUpdate, we may want to consider > >> alternative options to put in the spec that are easier to implement. > >> That is, we can write the spec in various ways to get the > >> functionality that both write directions get the key updates needed > >> to avoid the ciphertext limit, and we are reliant on implementations to follow > the spec in order to get that safety property. > >> So, given that we can only get the safety property if all > >> implementations follow the spec, why not just ... require > >> implementations to track the amount sent and rekey if it's too close > >> to the limit? That is consistent with a unilateral/unidirectional > >> KeyUpdate, and having per-connection byte/record counters does not seem > to be a huge overhead. > >> > >> Keeping the two write directions' keys independent would also avoid > >> conflict when the two peers disagree on how often a rekey is > >> necessary (as might happen if a resource-constrained device decided > >> to not implement byte counters and just rekey after every N records, > >> which is "free" since you need to track serial numbers anyway). > > > > > > Yup. If we say implementations SHOULD/MUST/whatever send KeyUpdates > > frequently and we're fine with just saying we rely on each sender to > > honor that w.r.t. their own send keys with little other fanfare, I > > think this option is the clear winner. We're already relying on the > > sender to not, say, exfiltrate all data somewhere nasty. > > > > There seemed to be other motivations for KeyUpdate (Keith's passive > > observer use case, I've heard some theories around one side knowing > > more about the cipher than another, etc.), so I left that alone for > > now. I'm not currently convinced by those use cases, but perhaps the > > working group feels differently. I'm reasonably confident splitting > > the key tracks is correct regardless, but I wasn't sure which > > KeyUpdate motivations were considered important and which weren't. > > > >> > >> - If you receive a KeyUpdate and didn't send one in the last N > >> minutes (where N minutes >>> 1 RTT), (optionally?) flag your next > >> write to be preceded by KeyUpdate. This is simple but needs an ad-hoc > >> timeout to prevent ping-ponging. > >> > >> - Variations on sticking a please_echo boolean in the KeyUpdate > >> message, generation counts, etc., to get synchronization with > >> coalescing if we need it. I would much prefer the simpler options unless we > truly need this. > >> (KeyUpdate is right now a *required* feature, so simplicity should be > >> a priority. Rare use cases are what extensions are for.) > >> > >> Thoughts? > >> > >> David > >> > >> PS: We've seen this before with renego (I've seen many OpenSSL > >> consumers which lock up if the peer renegotiation), error alerts > >> triggered on reads (often they don't get sent), and close_notify > >> (also don't get sent in practice). Deviations from dumb filters are expensive. > >> > >> > >> Yes, simple is better. Well, here at least :) > >> > >> > >> PPS: I'm wary of over-extending post-handshake auth for the same > >> reason, though I haven't had time to look carefully at the latest proposal yet. > >> Still, having TLS specify and analyze the crypto while lifting the > >> actual messages into application-level framing would be preferable > >> for these sorts of side protocols. The application gets to make > >> assumptions about read/write flows and knows in which contexts what is and > isn't allowed. > >> > >> > >> Hmm, so [in the above proposal] that would involve the application > >> doing the byte/record counters and pushing a "give me a rekey packet > >> now" button when needed? I am not sure that I'm comfortable moving > "crypto sensitive" > >> code (well, sort-of) into the application, since many applications > >> won't do it. Also, not all applications will have access to the > >> record serial number, as I understand it, and the formulas I remember > >> for the ciphertext limits involved both records and bytes. > > > > > > Sorry, that was unclear. That was more of a side comment to help > > explain why I have such strong visceral reactions to any > > post-handshake auth mechanisms since part of it is the same issue. I > > am not proposing we lift KeyUpdate to the application layer. I'm > > proposing we split the KeyUpdate tracks in two and do [insert preferred option > here] w.r.t. the bidirectionality issue. > > Probably should not have mentioned it since it's mostly a distraction > > for this topic. I ramble a lot. :-) > > > > David > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Aug 18 12:21:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8112D5DB for ; Thu, 18 Aug 2016 12:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT0JibpAUEP3 for ; Thu, 18 Aug 2016 12:21:02 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5545D12B01C for ; Thu, 18 Aug 2016 12:21:02 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u134so348847ywg.3 for ; Thu, 18 Aug 2016 12:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4VLxHh6YqK/cFg32Uh6U3hfuaUZphgPmf6oV9FR07CA=; b=jskTMvrhJkWW2kyHSvTfuQ83M1jCI/wov55ju6Zy3ezS24Yiem3+RBd7RzD/pEjQbi 3713F6W+YYO8Ul+BOVL0e99rh8h04DO9vPez/cfhVoUSCYf5uNk7kp9jMI3P1GT3grl5 u64IWtKY+VznCyogqtcW2nCQJaPrHERAxMkx8wb5RwR6a2GD3DW1V3oj3PerrJNhG0s5 orLmbpncM4mvuTodJpTbSGz9j6VsI3u7VU5sCZ4eCrbST9FmjK4M2p85ijdKN2J1JumK FAiFkoIXwoembr7+tNQU98fQNExrITnoOMSYNBZK/F9nYlbI8spnfyF/3xolFdhmtd1X z1+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4VLxHh6YqK/cFg32Uh6U3hfuaUZphgPmf6oV9FR07CA=; b=cE9GM4HB8m9aR5xmjCBnmsbAJYgL6IkOhbd+m1Vt7BC/BsQexA+p1FBQpU3960adYn lVuzuGrgqcwfJDafx6Av3xjbuIsM8qkoZ2ut40kDzaKtOqdtFHw2u595u4T60Bdjp37m Rmx5xOBNrqQIq6av2EG3B8ihvBln5yrPG3gmvRFqyTTuj1Yc1IpcdWDCgMH4JO3eJ9yN zjzI7HCnFxAPn761KDXNUs5fndYnhdJN+ydEOv5/Ls24g5a6QxDd6n+WRKWAyUjzMR7k Mszhd9wsjxfXoScwgk5tGD4G6ZG74xNLC7SvVNegQAfYNyixtPd5xoSD9Rx7VUAD6Kp/ dP2w== X-Gm-Message-State: AEkoouuqs69Fjok+ZQWcgL7xc+43x/p6CYnTJsVsud2dCmhK2VqXZsOwZHExuLs/1joTzFGfBiG0+UgBeZPVxQ== X-Received: by 10.129.52.68 with SMTP id b65mr3171155ywa.50.1471548061592; Thu, 18 Aug 2016 12:21:01 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Thu, 18 Aug 2016 12:20:21 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Keith Winstein Date: Thu, 18 Aug 2016 12:20:21 -0700 X-Google-Sender-Auth: wfue2neIa4VM5nZqwCuRGrj8WLM Message-ID: To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 19:21:04 -0000 Yes, you need current_receive_generation, or something like it, to get P3. This is the subject of our PR #426/580. -Keith On Thu, Aug 18, 2016 at 12:10 PM, Adam Langley wrote: > On Thu, Aug 18, 2016 at 11:55 AM, David Benjamin > wrote: >> >> It seems desired_minimum_receive_generation can only be >> current_receive_generation or current_receive_generation + 1. In that case, >> a boolean should be sufficient and saves 7 bytes. > > > Given that simplification, is there a purpose for > current_receive_generation? It seems that scheme might be equal to a > "please_echo" flag. > > > Cheers > > AGL From nobody Thu Aug 18 12:42:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143FE12B01C for ; Thu, 18 Aug 2016 12:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Balo6kZx50SI for ; Thu, 18 Aug 2016 12:42:49 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E1312B012 for ; Thu, 18 Aug 2016 12:42:48 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id l2so26703195qkf.3 for ; Thu, 18 Aug 2016 12:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VPnM2ewi0sKE9Mxw/sTGsswAz7wRcE+u9IHvFXyaA74=; b=ABLf07Mqf2HE3RrOiQiOMaIShrhflZzGtt6a5MdPQ2s6NT29Uq6cyBGFYqJYRWztUf N4D8RJVsLcBKBPOHCgUD2zK6VlyKLD6RGpMsx9m769S+fN+usjxknYp5SOMkWRgTrB/j Ydp9cUKQiQ6833CPuOpghYSHZFdOaq3XPDVtlYI7BGX2gsmFCtImQ6ozYlEvrnkdEuSY Z7BWUpntoKyaNnVePLxaW5qiQMAHcDPA2IKN86PBrIwiqQ2apz7UeNPUYxfY2uOgLZoZ 965V/2VSirNjcWbmEbQoyq1h58x6/tbNPjsRx1gI5dosVxK7qIbc89KapTcjVW4/ZHH3 sMsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VPnM2ewi0sKE9Mxw/sTGsswAz7wRcE+u9IHvFXyaA74=; b=R6t6IAmE5A8UKfqXnwdKiz1Td7S07dZ+CSmFxHbSbU2hTiRsWLq0svNItmzcgc0G6G vqReJRnMX5d65eKVgjn0PGCZwYpJHNkQx++chYGkaYMA5wtL2mU9oQRzh+B/qLeu8H3N FxzAVmZjdvAweY3px9FRcr7wMwFX+CK41vKoqmW1wtKhjD0mEo0ijKGWZlhY/3G0gfCi BpAs+tYgD8F3QorD2KGnP7I/UxqVsDj69WUHdnt2jwzeUSF+tExj7tnK+5KclN/HTQQv NIaAwTffW9ZDSk5ae86TywjcLrVd0L+wev4uSUb/rf/DErz5frjsbAy8R1p0W0bY4Pt+ 3tSg== X-Gm-Message-State: AEkoous2xGBn/1tRVknLLcA+OUAPzbEUbICMk5gCyN3kEE7DD6Ea2RR+FnYPcAJTiV8vFja3RtemXY/HNMgH4w== X-Received: by 10.55.101.17 with SMTP id z17mr4422160qkb.186.1471549367910; Thu, 18 Aug 2016 12:42:47 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.200.36.199 with HTTP; Thu, 18 Aug 2016 12:42:47 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Adam Langley Date: Thu, 18 Aug 2016 12:42:47 -0700 X-Google-Sender-Auth: 0cMBKw0-yCijCrik_n71B99HLHw Message-ID: To: Keith Winstein Content-Type: multipart/alternative; boundary=94eb2c05ba545807c3053a5dc96b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 19:42:51 -0000 --94eb2c05ba545807c3053a5dc96b Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 12:20 PM, Keith Winstein wrote: > Yes, you need current_receive_generation, or something like it, to get > P3. This is the subject of our PR #426/580. > The KeyUpdate messages are encrypted and thus sequenced with all the application data. Apart from the Heartbeat message (TLS 6520), which has not been significantly used in TLS (I think), we've never worried about a TLS-level ack before. PR 426 wants a way to retrospectively disclose keys to middleware and wants to make sure that the receive side is no longer going to trust those keys before doing so. Having spoken to several vendors of these products in the past and tried to persuade them to accept read-only access I don't think we should alter TLS's design for that unless there's a novel argument about why they would ever accept it. (Because they won't. Their competitive interest is to have as many "features" as possible, many of which would require modifying traffic.) Cheers AGL --94eb2c05ba545807c3053a5dc96b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 18, 2016 at 12:20 PM, Keith Winstein <keithw@cs.stanford.edu= > wrote:
Yes, you need current_receive_generation, or something like it, to get
P3. This is the subject of our PR #426/580.

=
The KeyUpdate messages are encrypted and thus sequenced with all the a= pplication data. Apart from the Heartbeat message (TLS 6520), which has not= been significantly used in TLS (I think), we've never worried about a = TLS-level ack before.

PR 426 wants a way to retros= pectively disclose keys to middleware and wants to make sure that the recei= ve side is no longer going to trust those keys before doing so. Having spok= en to several vendors of these products in the past and tried to persuade t= hem to accept read-only access I don't think we should alter TLS's = design for that unless there's a novel argument about why they would ev= er accept it. (Because they won't. Their competitive interest is to hav= e as many "features" as possible, many of which would require mod= ifying traffic.)


Cheers
<= br>
AGL=C2=A0
--94eb2c05ba545807c3053a5dc96b-- From nobody Thu Aug 18 13:36:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E4012DB4B for ; Thu, 18 Aug 2016 13:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WReD0l3t5OFM for ; Thu, 18 Aug 2016 13:36:47 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814F712D091 for ; Thu, 18 Aug 2016 13:36:47 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id z10so9313175ybh.2 for ; Thu, 18 Aug 2016 13:36: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; bh=jFELm4rta1M79ieJFAj06MO+/UqfbE34Srd3yOYNmdA=; b=DOHR84pcuBiuPYTbeAGOfEPaagxvYWXStvmnRtS4LMWz4JTK4BxNN6WpXWJSMZUtnc a2XbYOBuRwrS0NPndyHJy6pxI+JDZbJMAKOLjShzz6MQUfoC9LQ5sCUPAqwhBS5lwztK fzGCs5zmc9xv9tKB2zIVh79mvDaxFKUEDjoNZvOBWJHxEZ+e9vrIOowobKZjQEvlA1fD 8UkVwPnpTRiG1zRQPe6hFwyKAWzZCViXtQod4GT5Ad6YtroPgYbUYg5YZGzpcZfF8YoE MJSOnCZPoUKOyGsmsnLBmnYMF3/bXsH9JHw+6Hwm+IrxCnZ9A7ZH0+2E1NlPBjDXt2RA vn8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jFELm4rta1M79ieJFAj06MO+/UqfbE34Srd3yOYNmdA=; b=eRw2jP2Ju363RXikYxvPQ7U2Qj3pxS9bYeblmjSCVkMNBDFbiGaql8G97jym/TSj0B yPgcL6Kg0LG+gFbF+rDtG//diUDpaYFUuMF62g770RyZOvGVNygfQ0SqdA4DHKoBfhgw Lw2QRgBzx/e0+kWBxhR0m7yMBX8x0QJDh5R2etqIud5Sn9QR63Sh/eblkod+zIlheNMW so6nJZG8/u/OWhBpGsEKRzMEe3jp+3iE/lqJKsqWgW1g/Q1YiHuxRLPBTzCbfkRQrrg8 hAMu8RPeqBDSJnvCTmjV+mXfoQpUaL8yKfII+Li0xk/ZYTANNbgm+l5tX/vFG++Nit76 nc8Q== X-Gm-Message-State: AEkoouvM9HchC7n2tqrT05C/XR/iOTQdV4UVY7gYVeAhBjIdIkDUuwa9sQoCPBtOOHEmE5zBfHpRNNGICfYWhA== X-Received: by 10.37.160.35 with SMTP id x32mr3199850ybh.156.1471552606697; Thu, 18 Aug 2016 13:36:46 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Thu, 18 Aug 2016 13:36:05 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Keith Winstein Date: Thu, 18 Aug 2016 13:36:05 -0700 X-Google-Sender-Auth: 1wVraP9nk13uLvEm4HvjZLuu25U Message-ID: To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 20:36:50 -0000 Okay, this is a different question -- whether P3 is a valuable property or not. I made the case for this in my Monday thread[1] and in my Berlin presentation[2]. [1] https://www.ietf.org/mail-archive/web/tls/current/msg20787.html [2] https://www.ietf.org/proceedings/96/slides/slides-96-tls-3.pdf I'm happy to make the case for P3 here again but didn't want to hijack David's thread. My claim here was that there are some simple designs that satisfy everybody and grant P1+P2+P3+P4, and that David's concern's and my concerns are "basically orthogonal issues." === On the value of P3, I think you're giving us a crimped reading. We gave three use cases in Berlin and in my email: - An embedded device may wish to fully rotate the session keys before going to sleep. - A paranoid device might fully rotate the session keys before closing the session. (If confirmation is absent, the device might use a higher-level mechanism to forcibly log out all open sessions from that user.) - An endpoint that wishes to permit a read-only virus scanner or IDS will want to fully rotate the session before sharing the directional keys with the middlebox. On this last use case, I agree that incumbent IDS vendors may not be eager to support it. But adoption would probably come from a different direction. IoT devices today forbid anybody, including a middlebox controlled by the device owner, from auditing their own traffic and seeing what the devices are sending and receiving. (Unlike a browser, they don't let the user add a private CA cert to be able to MITM.) In my conversations with IoT device vendors, some expressed interest in allowing device owners to grant read-only access to themselves. I really do think this would be a good thing. Unlike Heartbeat, we are not talking about an ack that would be generated by something, and we're not really talking about altering TLS's design. We're talking about piggybacking one field in a protocol message that is going to be sent anyway, where the message (KeyUpdate) is new in TLS 1.3 anyway. As I said, it is orthogonal to David's issues here. Yes, it is possible to get P1+P2+P4 by themselves -- P3 has to live or die on its own merit. But it is really just one piggyback field to get it. -Keith On Thu, Aug 18, 2016 at 12:42 PM, Adam Langley wrote: > On Thu, Aug 18, 2016 at 12:20 PM, Keith Winstein > wrote: >> >> Yes, you need current_receive_generation, or something like it, to get >> P3. This is the subject of our PR #426/580. > > > The KeyUpdate messages are encrypted and thus sequenced with all the > application data. Apart from the Heartbeat message (TLS 6520), which has not > been significantly used in TLS (I think), we've never worried about a > TLS-level ack before. > > PR 426 wants a way to retrospectively disclose keys to middleware and wants > to make sure that the receive side is no longer going to trust those keys > before doing so. Having spoken to several vendors of these products in the > past and tried to persuade them to accept read-only access I don't think we > should alter TLS's design for that unless there's a novel argument about why > they would ever accept it. (Because they won't. Their competitive interest > is to have as many "features" as possible, many of which would require > modifying traffic.) > > > Cheers > > AGL From nobody Thu Aug 18 14:26:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAA312D1AF for ; Thu, 18 Aug 2016 14:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUebbeKy8bkh for ; Thu, 18 Aug 2016 14:26:46 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 9AD4A12D0FF for ; Thu, 18 Aug 2016 14:26:46 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id u25so2899581qtb.1 for ; Thu, 18 Aug 2016 14:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WGuc14OgVhCtqNXH1/jEzWn6hOHNrzzs8TJcE0tQHNQ=; b=fCv8y2+gqcqwCLsonp2fyiCoMWjHD4AX0s9IyIUe1lWr4+4ELK2tUs/yNMU1Ith+NF bnOIw7YThwbFSgayvlqUeCdarLigV0HlT+dWPEfYOoLNTObadekYIcJM1iQCIL0xrDHt Mf6KM20GFuQLR7kFCH4f2mYUSslqFN8fBjRbFIxB9HxaHe1olob01jDtvywAnBOWDe1a o+WaYTXjoAuetDWN2Bd4mJhhmMVWUArN57l4sk5w/ETSu8KAHsceSjg4vdgWunPGHhpL WSYg7hFyOxGASDA2wH8L0OVc6A8cvkc4FJulkiy5ukjMOC84koNBL9iyg815cszLrM4S A4SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WGuc14OgVhCtqNXH1/jEzWn6hOHNrzzs8TJcE0tQHNQ=; b=DCUqoBMcuyIzdd5jvIKZBvIHaO3aziomDCUUZYonwGjUxKpc7tax1XqD9s4Vc4KECn Biee1JQTWc3ueFkBhI1vKXxgFQ/XGPm8dSHlLJEkKrHTLOYpf9PQ4mDtKZLkJVSCGcFx /txtugec2leOmZngBsqxdTjqFnd4m3Q1kd0DNX0LFnc6XUmPl9lVJPLjoTInKbrmzzQr MEymUg1z1ZI5b9LpmoD9HTL7gfEiIXFGlcog6brYlMlMuBy1uAEeqH2Wv1Cu0eiXRq/h K/3Swslt+AYBl/sMMZzm5TbH3c9SMUj27Q9cUWzNhDbF7oefQKzOeNOsybdJ0Ur6OnjU ME1Q== X-Gm-Message-State: AEkoousZPk1PTQdx0ffnxetQtGQvEY0EEBqnp1ANTyqwADy+kZbBXV6jkwFNuS1Rbc1L3zM2sU6eaDoijFhl/g== X-Received: by 10.200.34.135 with SMTP id f7mr5012721qta.141.1471555605747; Thu, 18 Aug 2016 14:26:45 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.200.36.199 with HTTP; Thu, 18 Aug 2016 14:26:45 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Adam Langley Date: Thu, 18 Aug 2016 14:26:45 -0700 X-Google-Sender-Auth: cnnC9qjtVwkwby58rG8oi-9K91U Message-ID: To: Keith Winstein Content-Type: multipart/alternative; boundary=001a113f420c25df9e053a5f3df1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2016 21:26:49 -0000 --001a113f420c25df9e053a5f3df1 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 1:36 PM, Keith Winstein wrote: > On the value of P3, I think you're giving us a crimped reading. We > gave three use cases in Berlin and in my email: > I think I was because I hadn't seen your Berlin presentation. But I'm still going to hijack this thread and ask you to expand on some of these points so that I understand your motivation :) - An embedded device may wish to fully rotate the session keys before > going to sleep. > I imagine the argument here goes: 1) Sleep is good because it saves power. 2) To sleep we need to power down (and erase) most memory. 3) So to keep a TLS connection across sleep/wake secrets have to be saved to flash, but that's hard to erase so we don't want to expose keys that were used to encrypt traffic. For that I see why one needs KeyUpdate to be echoed: as the embedded device, you want the peer to rotate keys so that you can write only fresh keys to flash. On wake you want the other side to rotate again so that the keys in flash were only used to authenticate a new KeyUpdate. But why do you need the other side to have confirmed that it has erased your keys? I think you only care that it echos your KeyUpdate messages promptly. - A paranoid device might fully rotate the session keys before closing > the session. (If confirmation is absent, the device might use a > higher-level mechanism to forcibly log out all open sessions from that > user.) > The worry here is that a peer might be seized and subject to a cold-boot attack to lift the TLS connection keys? So if you don't hear from it every $x seconds you'll log it out? Again does the confirmation here help? What if you send a KeyUpdate and receive a change password request? The peer might well have sent it before receiving your KeyUpdate, or maybe it was seized and will just choose not to echo your KeyUpdate. (I might well be misunderstanding the details here.) On this last use case, I agree that incumbent IDS vendors may not be > eager to support it. But adoption would probably come from a different > direction. IoT devices today forbid anybody, including a middlebox > controlled by the device owner, from auditing their own traffic and > seeing what the devices are sending and receiving. (Unlike a browser, > they don't let the user add a private CA cert to be able to MITM.) In > my conversations with IoT device vendors, some expressed interest in > allowing device owners to grant read-only access to themselves. I > really do think this would be a good thing. > If they have a channel to the user where they are sending a stream of old keys, couldn't they just mirror the plaintext of the connection to keep things simple? I guess you worry about a device that's cooperative enough to put in the effort to have their audit channel but lies about the plaintext? Cheers AGL --001a113f420c25df9e053a5f3df1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 18, 2016 at 1:36 PM, Keith Winstein <keithw@cs.stanford.edu= > wrote:
On the value of P3= , I think you're giving us a crimped reading. We
gave three use cases in Berlin and in my email:

I think I was because I hadn't seen your Berlin presentation. = But I'm still going to hijack this thread and ask you to expand on some= of these points so that I understand your motivation :)

- An embedded device may wish to fully rotate the session keys before
going to sleep.

I imagine the argument = here goes:

1) Sleep is good because it saves power= .
2) To sleep we need to power down (and erase) most memory.
3) So to keep a TLS connection across sleep/wake secrets have to be s= aved to flash, but that's hard to erase so we don't want to expose = keys that were used to encrypt traffic.

For that I= see why one needs KeyUpdate to be echoed: as the embedded device, you want= the peer to rotate keys so that you can write only fresh keys to flash. On= wake you want the other side to rotate again so that the keys in flash wer= e only used to authenticate a new KeyUpdate.

But w= hy do you need the other side to have confirmed that it has erased your key= s? I think you only care that it echos your KeyUpdate messages promptly.

- A paranoid device might fully rotate the session keys before closing
the session. (If confirmation is absent, the device might use a
higher-level mechanism to forcibly log out all open sessions from that
user.)

The worry here is that a peer mi= ght be seized and subject to a cold-boot attack to lift the TLS connection = keys? So if you don't hear from it every $x seconds you'll log it o= ut?

Again does the confirmation here help? What if= you send a KeyUpdate and receive a change password request? The peer might= well have sent it before receiving your KeyUpdate, or maybe it was seized = and will just choose not to echo your KeyUpdate.

(= I might well be misunderstanding the details here.)

On this last use case, I agree that incumbent IDS vendors may not be
eager to support it. But adoption would probably come from a different
direction. IoT devices today forbid anybody, including a middlebox
controlled by the device owner, from auditing their own traffic and
seeing what the devices are sending and receiving. (Unlike a browser,
they don't let the user add a private CA cert to be able to MITM.) In my conversations with IoT device vendors, some expressed interest in
allowing device owners to grant read-only access to themselves. I
really do think this would be a good thing.

=
If they have a channel to the user where they are sending a stream of = old keys, couldn't they just mirror the plaintext of the connection to = keep things simple? I guess you worry about a device that's cooperative= enough to put in the effort to have their audit channel but lies about the= plaintext?


Cheers

AGL=C2=A0
--001a113f420c25df9e053a5f3df1-- From nobody Thu Aug 18 17:18:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12BE12D159 for ; Thu, 18 Aug 2016 17:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhKkOhXDClFE for ; Thu, 18 Aug 2016 17:18:54 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBEF12D08F for ; Thu, 18 Aug 2016 17:18:54 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id d10so10850543ybi.1 for ; Thu, 18 Aug 2016 17:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mZeqA9MsMO57u9EHR/UkdpRr3nrnyPWgKVMmC/GA+H8=; b=WJ0UOK0JvnUXbf/ol1HlzMEQ/E8XCSS2O1dw1GCu+YgPqE6dVhnDs8iUgmC+0NVB4o qZjJy7nO7lJKukAF2fLOK5heKozgr3I1iSxHyyttJkjvejq4WhdGVK6gMOm/lNs/rulh ljs/iyw9pvZ+FcwlJE52A7o4p3zbKnPDhb+Lyt0ovhnuwTJ5obfecKgou1+VgmXopuXp Up6GopsAueMMxyb9T4YbBKRQf+PyrEuJbOMiqSb67vkV72UXfLcZvj70xg/V+BatQYxD r4UWZaYfY1AdwH6lUQ06VIrza1XGg0xy39Zu+KgWwxsUJ1MH2KK+1hh66L4YzJV6sNlZ eT3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mZeqA9MsMO57u9EHR/UkdpRr3nrnyPWgKVMmC/GA+H8=; b=DBLKsuqKuplKeoJJIk2Plz+XLPJi+uum6sulonstQn80Nt43PE4LshoOH54ytf2/4n 2u/sNAVWLwZDjKVeQ++V7Il1tSM6K4SgOFjh8q1W89Xy3kaVCLzXgyjkLry8LL4pyKFE JaOVJKtHqiTJStEyPO12hu1RTD+ghajkNnRH2wefVDGzt72/6LLpnV8hxOXII48VjtUk v34OrFelFyXBcEcLZIFTFWonOPDqyZ315TEtKLuBGpbVaB9pLvTut+HDfnAO/M3GHaCR yt6iXMXicQW3nTdf7DrlXz0fFZ2vrBdHIJ6nQQOqfZsv/ie67z7vrRJZp3OhpyWvKsM0 LIow== X-Gm-Message-State: AEkoout43cHv4PEx6zeqg2ERo2QRPF2yqPZy2VfKAyjoQsdFTr1hTxQIP7076sWqdYaGY3K1njayJ9z+IUAztw== X-Received: by 10.37.64.131 with SMTP id n125mr3783832yba.32.1471565933579; Thu, 18 Aug 2016 17:18:53 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Thu, 18 Aug 2016 17:18:13 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Keith Winstein Date: Thu, 18 Aug 2016 17:18:13 -0700 X-Google-Sender-Auth: gHOnaInh04DL6woA_4taqdoB76U Message-ID: To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 19 Aug 2016 00:18:57 -0000 On Thu, Aug 18, 2016 at 2:26 PM, Adam Langley wrote: > I think I was because I hadn't seen your Berlin presentation. But I'm still > going to hijack this thread and ask you to expand on some of these points so > that I understand your motivation :) Fair enough. :-) >> - An embedded device may wish to fully rotate the session keys before >> going to sleep. > > I imagine the argument here goes: > > 1) Sleep is good because it saves power. > 2) To sleep we need to power down (and erase) most memory. > 3) So to keep a TLS connection across sleep/wake secrets have to be saved to > flash, but that's hard to erase so we don't want to expose keys that were > used to encrypt traffic. Yeah, our reasoning follows yours and goes a little further: 4) I don't know when I'm going to wake up again. 5) I don't want a subsequent compromise of me *or* the other side to reveal prior plaintext from the session. 6) Because I'm going to sleep, it's now or never to make sure the session keys aren't retained. 7) Therefore, I'd like to make sure both sides have ratcheted forwards before I go to sleep. > For that I see why one needs KeyUpdate to be echoed: as the embedded device, > you want the peer to rotate keys so that you can write only fresh keys to > flash. On wake you want the other side to rotate again so that the keys in > flash were only used to authenticate a new KeyUpdate. > > But why do you need the other side to have confirmed that it has erased your > keys? I think you only care that it echos your KeyUpdate messages promptly. Agreed, P1+P2 is sufficient if the device only cares about making sure *it* is not going to leak keying material (that can reveal prior plaintext) if there is a compromise during sleep. You need P3 if you are also concerned the peer might be holding on to an old key. >> - A paranoid device might fully rotate the session keys before closing >> the session. (If confirmation is absent, the device might use a >> higher-level mechanism to forcibly log out all open sessions from that >> user.) > > The worry here is that a peer might be seized and subject to a cold-boot > attack to lift the TLS connection keys? So if you don't hear from it every > $x seconds you'll log it out? Probably nothing that elaborate. The device is concerned that after the session is over (from its perspective), the server might get compromised, and the attacker reads the key for a long-dormant session out of the server's /dev/mem, and uses it to decrypt prior ciphertext. One approach is that the device should make sure to close every session with a secure bidirectional close, where the server actually confirms that the session is dead in both directions. But TLS does not have a secure bidirectional close. (Even when used, close_notify only promises there will be no more data in *that* direction.) However, the device can try to guarantee that both sides have ratcheted past all the keys that could reveal prior plaintext. > Again does the confirmation here help? The confirmation is the way for the device to know that the server has read its request to ratchet the client-to-server traffic key forwards. (And the idea would be, if the device doesn't get that confirmation and really wants it, it may have to raise a warning and handle this at the application layer -- e.g. by opening a new session to the server and issuing a "kill all sessions" command.) > What if you send a KeyUpdate and receive a change password request? The peer > might well have sent it before receiving your KeyUpdate, or maybe it was seized and > will just choose not to echo your KeyUpdate. Sure, there's nothing you can do if the peer gets compromised while important keys still live on it. But the idea here is for the device to be able to make sure the keys get ratcheted after all the data is sent but before there can be a later compromise. Basically approximating (some of) the semantics of an actual secure bidirectional close. > If they have a channel to the user where they are sending a stream of old > keys, couldn't they just mirror the plaintext of the connection to keep > things simple? I guess you worry about a device that's cooperative enough to > put in the effort to have their audit channel but lies about the plaintext? Right, exactly. (Ideally, the device doesn't even know it's being audited until the user logs in to the Web UI and says, "okay, now, ratchet the session and then share the old keys with this auditor that I am going to introduce you to, so it can decrypt some earlier ciphertext I've been capturing." So we don't want a parallel channel and we don't even want the device to have to know about the audit beforehand.) -Keith From nobody Fri Aug 19 05:29:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3352C12B077 for ; Fri, 19 Aug 2016 05:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEIzKFNXgCAa for ; Fri, 19 Aug 2016 05:29:29 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063A212D0D3 for ; Fri, 19 Aug 2016 05:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1471609769; x=1503145769; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CFrPZFaDSGGBe5g8/eqnLmqoTUf3/Z67luZ55c6Vt1I=; b=BC5Fil2WnhG22IKxW20U6Qaa+SknaTtx9OrzaJyZltjgdPTN7e/SsJXk 0NY2KTdEEb9YjcltgIO04MZJZEQyvwcKhkRpBEqxeFQMH2pvu3E2pccn+ zsi1hDmty8wVr/mzAXhtsuKOXAX+PeGf4WwLatC+Fwbt+HxzmMELEdMyX GJQiRVwFNFJaxL6FG1OgSs1LmCE2xOmRFKPGGGPb6bJ7Wbb8/v4wTWIKx L37xWgveMsLPSrO/U6zEAHra6AYTGsrLfXY5c7H4WgqdJOBpaBEDbngG2 ONg8owAzsQilwzEBKbumIlO+O8u1zdbitaXqwk8EGCDci57oSmr/FGOx6 w==; X-IronPort-AV: E=Sophos;i="5.28,544,1464609600"; d="scan'208";a="102835150" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Aug 2016 00:29:25 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Sat, 20 Aug 2016 00:29:25 +1200 From: Peter Gutmann To: Bodo Moeller , "tls@ietf.org" Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Thread-Index: AdH3qzVttHomztzDTIKlIRH23NqfIv//fPYAgAIjA03//486AIADpKzA Date: Fri, 19 Aug 2016 12:29:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 12:29:34 -0000 Bodo Moeller writes:=0A= =0A= >Peter, so your complaint is about the lack of support for explicitly=0A= >specified (non-"named") groups?=0A= =0A= It's the lack of support for DHE unless it's the exact parameters the serve= r=0A= wants. At the moment if your implementation wants to use DHE (which pretty= =0A= much all of them do) you have two options:=0A= =0A= 1. Ignore RFC 7919 and perform DHE with several billion devices worldwide.= =0A= =0A= 2. Implement RFC 7919 and, unless both client and server happen to choose a= n=0A= appropriate FFDHE parameter set that both sides can agree on, be forced = to=0A= fall back to the old, unsafe RSA key exchange.=0A= =0A= The problem is that 7919 doesn't say "I want to do DHE, if possible with th= ese=0A= parameters", it says "I will only accept DHE if you use these parameters,= =0A= otherwise you cannot use DHE but must drop back to RSA". Talk about cuttin= g=0A= off your nose to spite your face, you'd have to have rocks in your head to= =0A= want to break your implementation like that.=0A= =0A= Until now I hadn't had a major interest in 7919 (it's rather hard to identi= fy=0A= what problem it's actually solving), but thought I'd look at it for TLS-LTS= =0A= use. However, if using it requires giving up DHE in a lot of cases there's= no=0A= way I'll be implementing it.=0A= =0A= Peter.= From nobody Fri Aug 19 05:57:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AB512D758 for ; Fri, 19 Aug 2016 05:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2FTpkzeXUDL for ; Fri, 19 Aug 2016 05:57:10 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D72AC12D09F for ; Fri, 19 Aug 2016 05:57:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 69C181423C for ; Fri, 19 Aug 2016 15:57:07 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id zebNcwQMt-Vu for ; Fri, 19 Aug 2016 15:57:06 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id E324C21C for ; Fri, 19 Aug 2016 15:57:06 +0300 (EEST) Date: Fri, 19 Aug 2016 15:56:58 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160819125658.v6t4d6stpo6tk476@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 12:57:12 -0000 On Fri, Aug 19, 2016 at 12:29:23PM +0000, Peter Gutmann wrote: > Bodo Moeller writes: > > >Peter, so your complaint is about the lack of support for explicitly > >specified (non-"named") groups? > > It's the lack of support for DHE unless it's the exact parameters the server > wants. At the moment if your implementation wants to use DHE (which pretty > much all of them do) you have two options: > > 1. Ignore RFC 7919 and perform DHE with several billion devices worldwide. > > 2. Implement RFC 7919 and, unless both client and server happen to choose an > appropriate FFDHE parameter set that both sides can agree on, be forced to > fall back to the old, unsafe RSA key exchange. AFAIK, that failure can only happen if at least one of: - The server is buggy. - All client-supported FFDHE groups are distrusted or not implemented on server (Yes, plural). - All client-supported FFDHE groups are outside server key size range (in which case you probably wouldn't want to try to do DHE with that client anyway). Because otherwise there is always a group choice that works. (I would say that 256+257+258 [2k, 3k and 4k] is reasonable set to implement, 259 and 260 [6k and 8k] are too large). -Ilari From nobody Fri Aug 19 06:03:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B3412D7C3 for ; Fri, 19 Aug 2016 06:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPTW_8sO6NVc for ; Fri, 19 Aug 2016 06:03:26 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A7B12B02B for ; Fri, 19 Aug 2016 06:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1471611806; x=1503147806; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OqNRTJiRlWK5umguvW+HI6NGSWXFdWLFjJX7Wn4iks4=; b=3gpXETrFneHPgKNfRYX85wtMiJH0GrcPhLqK2OkLkfUuP9L4jvCrl5PM 4imoJmnz/5KAVflfRbVXYkmEQwEDnwzAasTQRLZQIXACYmyVeeewMIFFC Cz1Jez32zmYCXCf6DAw9gc0e34/A/CtDhUxEeuJX8CtvmAjjmXHAsRPN0 HlM86JcdEc0P51CaZEqWnjvZbRzk0g0+QX64mKrONUcRrITGGpmGxQm+i 7bRTPCCJjnBmBpAcJPDUaEJ4RurgOLWXGdJ/ufm70xiGtAqvRp1GLVMe3 coK+TGgi6DfEbC8tyfWNUzLRCUD2m28Bd0kkQyQSiOao9aSWmNawXVCVN g==; X-IronPort-AV: E=Sophos;i="5.28,544,1464609600"; d="scan'208";a="102836537" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Aug 2016 01:03:23 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Sat, 20 Aug 2016 01:03:23 +1200 From: Peter Gutmann To: Ilari Liusvaara , "tls@ietf.org" Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Thread-Index: AdH3qzVttHomztzDTIKlIRH23NqfIv//fPYAgAIjA03//486AIADpKzA//8+4gCAAMrJdg== Date: Fri, 19 Aug 2016 13:03:22 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF421E@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz>, <20160819125658.v6t4d6stpo6tk476@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160819125658.v6t4d6stpo6tk476@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:03:28 -0000 Ilari Liusvaara writes:=0A= =0A= >AFAIK, that failure can only happen if at least one of:=0A= =0A= [...]=0A= =0A= New groups are introduced but the server or client only support the old one= s.=0A= So the server does ffdhe2048, the client does ffdhe2048', both are quite ha= ppy=0A= to do DHE-2048 but as a result of complying with 7919 they're forced to use= =0A= RSA.=0A= =0A= Peter.= From nobody Fri Aug 19 06:21:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF99B12DA16 for ; Fri, 19 Aug 2016 06:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHZe7uMmpFcd for ; Fri, 19 Aug 2016 06:21:47 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 15D0212D9C5 for ; Fri, 19 Aug 2016 06:20:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B6D9F14331 for ; Fri, 19 Aug 2016 16:20:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 2Mup7MF8F6Zn for ; Fri, 19 Aug 2016 16:20:54 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 7834D2310 for ; Fri, 19 Aug 2016 16:20:54 +0300 (EEST) Date: Fri, 19 Aug 2016 16:20:46 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160819132046.u4bbcdssgzxmay7r@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> <20160819125658.v6t4d6stpo6tk476@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4CF421E@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF421E@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:21:50 -0000 On Fri, Aug 19, 2016 at 01:03:22PM +0000, Peter Gutmann wrote: > Ilari Liusvaara writes: > > >AFAIK, that failure can only happen if at least one of: > > [...] > > New groups are introduced but the server or client only support the old ones. > So the server does ffdhe2048, the client does ffdhe2048', both are quite happy > to do DHE-2048 but as a result of complying with 7919 they're forced to use > RSA. Oh, and if you think this is bad, wait until you get to TLS 1.3, where you don't get fallback to RSA or some random DH group, you get almost certain connection failure. :-> -Ilari From nobody Fri Aug 19 06:53:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D4912D093 for ; Fri, 19 Aug 2016 06:53: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eHN8YDi2q7H for ; Fri, 19 Aug 2016 06:53:53 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 5B98F12DAE4 for ; Fri, 19 Aug 2016 06:52:02 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id k90so80862681uak.1 for ; Fri, 19 Aug 2016 06:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2RCJsh9dDW+VB9DVWOBBwcanrN532hhIYyaS7C7aOmg=; b=udMwcI1gkByEiTVigHOjP5mqLFP5Y5LkkpDmxpHtF2UcPueiAvcVbgLcAISXuXyOOV AC3hj0Eqrx27kMv2hIZDj6YznfZWoT1C+X5kvkUAYTOnGwQzbRHf3IzpF0jkWi0bTPKA sVIm2nOF6dXfBrPUNBxlOwWEb7DWKYdTf48G1VFNDBgUhWtnq5xYm9YYlMl/gSMcQS8a kDMKfUcDWsb91hAUHcMVA4HoRDqVQw46dUfxr/6sWhy/wJvymg7lmnna04Qtig0zmdcz 3InsryRPHGuqVMrcmVxqeJ3GJppSUZRwk0NUWSEolT7Q91Ets7Gebq/JwSzlxdmPYIzz 6Bjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2RCJsh9dDW+VB9DVWOBBwcanrN532hhIYyaS7C7aOmg=; b=e2BACo0t2ymr8E3YqjroSroYSwBO9z0Z2S1OGh/xPdwIYtIgWV2W4FTOP+Llme5exJ l2RkMwM8zezt36oRjjdHoIYJ+8ny+XlqqvIgRObmNiqXIssqmO5fF7VPlqWEg+TUX4SE CnFEEt2KxPjlcoCdy4a0rYEZuZSTJIioTrg4HJyLVhIRnRiSontOorxvBbrghtcmSjVj AiafEohtvkHRt86m6vFbgpfFH0kqtLotc3265pTQF+GPmbo5DrNUhPYJhQjzt9fqQ6/U qgvpm5T+wiCZrHeVyGBCOdA+wUcwn0E2mKvilJi6lOH3zcni5R/3YmN8t3HKZcY56SWo dA/g== X-Gm-Message-State: AEkoous4Zljcl6M9cYJ3eReyKBxU2Xe9KzPAavh7WK4MMsEx435f2PvLz1LnlNRKZsELmJWnbCpKf0ghFmJx5Q== X-Received: by 10.31.252.141 with SMTP id a135mr4177424vki.51.1471614721319; Fri, 19 Aug 2016 06:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Fri, 19 Aug 2016 06:52:00 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF421E@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> <20160819125658.v6t4d6stpo6tk476@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4CF421E@uxcn10-5.UoA.auckland.ac.nz> From: Watson Ladd Date: Fri, 19 Aug 2016 06:52:00 -0700 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:53:55 -0000 On Fri, Aug 19, 2016 at 6:03 AM, Peter Gutmann wrote: > Ilari Liusvaara writes: > >>AFAIK, that failure can only happen if at least one of: > > [...] > > New groups are introduced but the server or client only support the old ones. > So the server does ffdhe2048, the client does ffdhe2048', both are quite happy > to do DHE-2048 but as a result of complying with 7919 they're forced to use > RSA. Let's assume we don't introduce more groups for no reason. Oh wait, we totally did with ECC with this outcome. Let's not do that again. > > Peter. > _______________________________________________ > 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 Fri Aug 19 11:05:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4712D82D for ; Fri, 19 Aug 2016 11:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_F9ICKObjef for ; Fri, 19 Aug 2016 11:05:36 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B660612D8C1 for ; Fri, 19 Aug 2016 11:05:34 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id q128so43927550wma.1 for ; Fri, 19 Aug 2016 11:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IQdpYRfy1F5VXiIwyGJxhUNL8u+5PgeBNRSzOCsTSTs=; b=bsRUQyILkUNBsgXs4EWZkpW0vJG7U1BZd3fSDsYXFZwoaLIfqtzMbo7gNSdRTd+OMv xXNebBclyRSUUIMQ9SiTxzi3aUduQ8ChXHRdGXEgoM99SuAnlBLyJilWRw187rON0XlE fpSYo+s+sYjSyo1sHsSRmXE6s1BfuCbSW3hupzNaKsbWEhylFDyfcijgYxrwvHe8j46a 9vuZqbLqwfGOmk3KGyK3S8QC5PWV9vb8RuGB2cedj+Mx3UOuyUvK/FVnqsquS0ex5wh3 yHHhaFopdNVc8dYg2yoMqk61XCBQ3rCes9i6ENPJ5lWbec4EeCXfBXP9CLgFoQJcSgxN 6+Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IQdpYRfy1F5VXiIwyGJxhUNL8u+5PgeBNRSzOCsTSTs=; b=BV9/HZKHG0Q/G92yeLb1v+SL4QUckUtOctu2kL0jGT+s24x95KoiNvnTt57JgZ0XWm d5EbccVwrKMJA0sO+QA0+eaiLcaDKZtlOpcMWhWkzH9wEnFI19DbvD3TwDZaX0DmHPLx eUFR2d7iinKZABKiwJxs3WDefgFYzur6D56Gl/CNLgmeH+mwZ0fzO0tItxamSzzu78nt wjQ1Y5q8fsBZMijD5mtpnVHlMerH9AYCwpVYdCzqRA9Wozb8mXpei0mwnv4lT+g324gV Xf/eE0Bd4QZm1wAA4xQ2pK04QdZji8HIfbvGgr6An29K9zqupPmES5xLTfOdxlKPLZ/h 3J+A== X-Gm-Message-State: AEkoouvqGGGR4z5cMz96Nx2IjeMpn86/6XA4UJ6xe7fOwDstia/HZkzeeOuanNJsDVBXSiePZp3da2RWLW7lHw== X-Received: by 10.28.154.208 with SMTP id c199mr5221631wme.102.1471629933018; Fri, 19 Aug 2016 11:05:33 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.28.3.133 with HTTP; Fri, 19 Aug 2016 11:05:32 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Adam Langley Date: Fri, 19 Aug 2016 11:05:32 -0700 X-Google-Sender-Auth: YZzfQZ023-BDICYxkFJ3FDUCeBg Message-ID: To: Keith Winstein Content-Type: multipart/alternative; boundary=001a114b2d306608af053a708b72 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 19 Aug 2016 18:05:39 -0000 --001a114b2d306608af053a708b72 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 5:18 PM, Keith Winstein wrote: > Yeah, our reasoning follows yours and goes a little further: > > 4) I don't know when I'm going to wake up again. > 5) I don't want a subsequent compromise of me *or* the other side to > reveal prior plaintext from the session. > 6) Because I'm going to sleep, it's now or never to make sure the > session keys aren't retained. > 7) Therefore, I'd like to make sure both sides have ratcheted forwards > before I go to sleep. > I don't think that a device can ensure that the other side doesn't get compromised. Even if it rotates keys, there are plenty of ways that a well meaning implementation could fail to erase them: copying GCs, swap, hibernation, coldboots, even hypervisor tricks like moving VMs between machines. And I don't think the device can ensure that the keys that it writes to flash aren't used to protect sensitive data without application-level support. Consider a device that does a KeyUpdate and gets a KeyUpdate in reply before sleeping. However, just after echoing the KeyUpdate, the other side says "oh, and by the way, here are the battle plans...". Those plans would be encrypted with keys that the device just wrote to flash. So there has to be an application-level concept of "we're rotating keys now because I'm going to sleep. These keys are only for authenticating another KeyUpdate when I wake, don't send me anything." Once you have an application-level concept like that then you don't need an special KeyUpdate ack system at the TLS level because the KeyUpdate messages are sequenced with the application data already. Probably nothing that elaborate. > > The device is concerned that after the session is over (from its > perspective), the server might get compromised, and the attacker reads > the key for a long-dormant session out of the server's /dev/mem, and > uses it to decrypt prior ciphertext. > > One approach is that the device should make sure to close every > session with a secure bidirectional close, where the server actually > confirms that the session is dead in both directions. But TLS does not > have a secure bidirectional close. (Even when used, close_notify only > promises there will be no more data in *that* direction.) > > However, the device can try to guarantee that both sides have > ratcheted past all the keys that could reveal prior plaintext. > So you're worried that the server might not notice that a device has closed a connection and so keep the keys in memory? Why didn't it notice? Because an attacker cut the communication? If so, couldn't the attacker cut communication just before the KeyUpdate and achieve the same thing? Or are you assuming that we can't trust an implementation to erase keys when a connection closes, but it will erase them for a KeyUpdate or a bidirectional close? If so, I don't see why that's clearly true. It could be true in practice, but I suspect that many implementations will do the same thing in both cases. (And that, even if they try, they might not be able to securely erase the keys because of swapping etc.) The confirmation is the way for the device to know that the server has > read its request to ratchet the client-to-server traffic key forwards. > (And the idea would be, if the device doesn't get that confirmation > and really wants it, it may have to raise a warning and handle this at > the application layer -- e.g. by opening a new session to the server > and issuing a "kill all sessions" command.) That suggests that you're worried about an active attacker cutting communications. But why would such an attacker let you open a new session? > If they have a channel to the user where they are sending a stream of old > > keys, couldn't they just mirror the plaintext of the connection to keep > > things simple? I guess you worry about a device that's cooperative > enough to > > put in the effort to have their audit channel but lies about the > plaintext? > > Right, exactly. (Ideally, the device doesn't even know it's being > audited until the user logs in to the Web UI and says, "okay, now, > ratchet the session and then share the old keys with this auditor that > I am going to introduce you to, so it can decrypt some earlier > ciphertext I've been capturing." So we don't want a parallel channel > and we don't even want the device to have to know about the audit > beforehand.) > I think that this is the most interesting case. I would like to think that IoTish devices would care this much about doing the right thing, although I suspect we're more likely to get more fodder for Matthew Garrett ( https://mjg59.dreamwidth.org/43486.html). I would still tend towards not including the generation because I don't believe that it's going to be used. But if, in a blaze of optimism, people think it will, I'm not going to be too upset. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --001a114b2d306608af053a708b72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 18, 2016 at 5:18 PM, Keith Winstein <keithw@cs.stanford.edu= > wrote:
Yeah, our reasoning follows yours and goes a little further:

4) I don't know when I'm going to wake up again.
5) I don't want a subsequent compromise of me *or* the other side to reveal prior plaintext from the session.
6) Because I'm going to sleep, it's now or never to make sure the session keys aren't retained.
7) Therefore, I'd like to make sure both sides have ratcheted forwards<= br> before I go to sleep.

I don't think= that a device can ensure that the other side doesn't get compromised. = Even if it rotates keys, there are plenty of ways that a well meaning imple= mentation could fail to erase them: copying GCs, swap, hibernation, coldboo= ts, even hypervisor tricks like moving VMs between machines.

=
And I don't think the device can ensure that the keys that i= t writes to flash aren't used to protect sensitive data without applica= tion-level support. Consider a device that does a KeyUpdate and gets a KeyU= pdate in reply before sleeping. However, just after echoing the KeyUpdate, = the other side says "oh, and by the way, here are the battle plans...&= quot;. Those plans would be encrypted with keys that the device just wrote = to flash. So there has to be an application-level concept of "we'r= e rotating keys now because I'm going to sleep. These keys are only for= authenticating another KeyUpdate when I wake, don't send me anything.&= quot; Once you have an application-level concept like that then you don'= ;t need an special KeyUpdate ack system at the TLS level because the KeyUpd= ate messages are sequenced with the application data already.
Probably nothing t= hat elaborate.

The device is concerned that after the session is over (from its
perspective), the server might get compromised, and the attacker reads
the key for a long-dormant session out of the server's /dev/mem, and uses it to decrypt prior ciphertext.

One approach is that the device should make sure to close every
session with a secure bidirectional close, where the server actually
confirms that the session is dead in both directions. But TLS does not
have a secure bidirectional close. (Even when used, close_notify only
promises there will be no more data in *that* direction.)

However, the device can try to guarantee that both sides have
ratcheted past all the keys that could reveal prior plaintext.

So you're worried that the server might not not= ice that a device has closed a connection and so keep the keys in memory? W= hy didn't it notice? Because an attacker cut the communication? If so, = couldn't the attacker cut communication just before the KeyUpdate and a= chieve the same thing?

Or are you assuming that we= can't trust an implementation to erase keys when a connection closes, = but it will erase them for a KeyUpdate or a bidirectional close? If so, I d= on't see why that's clearly true. It could be true in practice, but= I suspect that many implementations will do the same thing in both cases. = (And that, even if they try, they might not be able to securely erase the k= eys because of swapping etc.)

The confirmation is the way for the device to know= that the server has
read its request to ratchet the client-to-server traffic key forwards.
(And the idea would be, if the device doesn't get that confirmation
and really wants it, it may have to raise a warning and handle this at
the application layer -- e.g. by opening a new session to the server
and issuing a "kill all sessions" command.)

=
That suggests that you're worried about an active attacker c= utting communications. But why would such an attacker let you open a new se= ssion?

> If they have a channel to the user where they are s= ending a stream of old
> keys, couldn't they just mirror the plaintext of the connection to= keep
> things simple? I guess you worry about a device that's cooperative= enough to
> put in the effort to have their audit channel but lies about the plain= text?

Right, exactly. (Ideally, the device doesn't even know it's = being
audited until the user logs in to the Web UI and says, "okay, now,
ratchet the session and then share the old keys with this auditor that
I am going to introduce you to, so it can decrypt some earlier
ciphertext I've been capturing." So we don't want a parallel c= hannel
and we don't even want the device to have to know about the audit
beforehand.)

I think that this is the m= ost interesting case. I would like to think that IoTish devices would care = this much about doing the right thing, although I suspect we're more li= kely to=C2=A0get more fodder for Matthew Garrett (https://mjg59.dreamwidth.org/43486.html).

I would still tend towards not including the generat= ion because I don't believe that it's going to be used. But if, in = a blaze of optimism, people think it will, I'm not going to be too upse= t.
=C2=A0

Cheers

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org=
--001a114b2d306608af053a708b72-- From nobody Fri Aug 19 11:25:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6731512D587 for ; Fri, 19 Aug 2016 10:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cZTAe9USO-P for ; Fri, 19 Aug 2016 10:13:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D8B12D0B7 for ; Fri, 19 Aug 2016 10:13:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A5E32B80DC6; Fri, 19 Aug 2016 10:13:46 -0700 (PDT) To: sblakewilson@safenet-inc.com, nelson@bolyard.com, vipul.gupta@sun.com, chris@corriente.net, bodo@openssl.org, 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: <20160819171346.A5E32B80DC6@rfc-editor.org> Date: Fri, 19 Aug 2016 10:13:46 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 11:25:02 -0700 Cc: hello@florent-tatard.fr, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 19 Aug 2016 17:13:48 -0000 The following errata report has been submitted for RFC4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=4783 -------------------------------------- Type: Technical Reported by: Florent Tatard Section: 5.7 Original Text ------------- Actions of the sender: The client selects an ephemeral ECDH public key corresponding to the parameters it received from the server according to the ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to the client in the ClientKeyExchange message using the format defined above. Corrected Text -------------- Actions of the sender: The client selects an ephemeral ECDH public key corresponding to the parameters it received from the server according to the ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to the server in the ClientKeyExchange message using the format defined above. Notes ----- The client conveys data to the server, not itself. 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. -------------------------------------- RFC4492 (draft-ietf-tls-ecc-12) -------------------------------------- Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Publication Date : May 2006 Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Aug 19 11:35:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213B012DA2A for ; Fri, 19 Aug 2016 11:35:49 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOq9XO9j2-ru for ; Fri, 19 Aug 2016 11:35:46 -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 F1E0312DA29 for ; Fri, 19 Aug 2016 11:35:45 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 5906133D20D; Fri, 19 Aug 2016 18:35:45 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> From: Geoffrey Keating Date: 19 Aug 2016 11:35:45 -0700 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 18:35:49 -0000 Peter Gutmann writes: > The problem is that 7919 doesn't say "I want to do DHE, if possible > with these parameters", it says "I will only accept DHE if you use > these parameters, otherwise you cannot use DHE but must drop back to > RSA". Talk about cutting off your nose to spite your face, you'd > have to have rocks in your head to want to break your implementation > like that. Actually, my problem with the RFC is the reverse. If you have an implementation which won't accept certain DH groups, and those are extremely common in legacy software (1024-bit, for example), there's no way to stop those legacy implementations ignoring the extension and choosing DH, which you will then have to reject, doubling connection establishment time. So Apple's client still has DH off. However I don't see a helpful solution to this; the obvious thing is to have a new ciphersuite, but it's hard to see how that would be worth the effort if it requires new implementations and ECDHE is already standardised and already implemented in many places. From nobody Fri Aug 19 11:43:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD012DA9F for ; Fri, 19 Aug 2016 11:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ONwd6yx6Lkn for ; Fri, 19 Aug 2016 11:43:24 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 D21F712DA99 for ; Fri, 19 Aug 2016 11:43:23 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id m101so56703049ioi.2 for ; Fri, 19 Aug 2016 11:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DZYHdk1HWcCFODuhFaEAOgbptl8h555q+Nvzug6v5+w=; b=iwk4OsoznEEPuS6uJlaPr2hnXwYPG4aWCESDrlv3BesGdpnbOkZPoOCeC9HexTC4iI AF97zQT3wMgzsGPmZ3BAAqWxLe7JSlNO2E45e2gnUDyWETfz2gYeMflToajPUlCDUojR oFLlymZqbE7HQg5oigI5/bie0E84PwDsLzJVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DZYHdk1HWcCFODuhFaEAOgbptl8h555q+Nvzug6v5+w=; b=kIyp682GWTMjY5wnwZrNg+IjK4JyyyFcDlO1YxFnJmqr2dXrF3/8xmjbmdH6SqOzRt EGfsQqJTD9GpByfjI0CRzmGf9l/80kM35lfB0H8xVHzMUGiQh3ZT69pXioCpfGXrshcZ 0uSP4Kov0zNaABvnqj2nZDLhw2EpVTZwUzm5o6lbQ1NFx9M5rn3FVTGOfXv80+CK5r5N TMSZSLQbvqrVXnsS9w5y95BABCH6b8+QU5vEZ0VZLZ4eXvAObDdaCS4Z3keTo0wrYaqb H63Q3nV51xeO9lCu0yiQ5SFgj4W1LBtlb9uSUiO9wjzbYXCmzRXaQC/GrUarJ4plLKkc 74uw== X-Gm-Message-State: AEkoouuorrlaP487vVTGd/IVrCIQ4EslPs47TglIATMX4v5++fdTwQCu9yhlhZkmPaaA/2oBi+1MbXB5RkOfVCHz X-Received: by 10.107.52.198 with SMTP id b189mr12078670ioa.6.1471632203044; Fri, 19 Aug 2016 11:43:23 -0700 (PDT) MIME-Version: 1.0 References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: From: David Benjamin Date: Fri, 19 Aug 2016 18:43:12 +0000 Message-ID: To: Geoffrey Keating , Peter Gutmann Content-Type: multipart/alternative; boundary=001a11440f7eb42cac053a7112f4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 18:43:26 -0000 --001a11440f7eb42cac053a7112f4 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 19, 2016 at 2:35 PM Geoffrey Keating wrote: > Peter Gutmann writes: > > > The problem is that 7919 doesn't say "I want to do DHE, if possible > > with these parameters", it says "I will only accept DHE if you use > > these parameters, otherwise you cannot use DHE but must drop back to > > RSA". Talk about cutting off your nose to spite your face, you'd > > have to have rocks in your head to want to break your implementation > > like that. > > Actually, my problem with the RFC is the reverse. If you have an > implementation which won't accept certain DH groups, and those are > extremely common in legacy software (1024-bit, for example), there's > no way to stop those legacy implementations ignoring the extension and > choosing DH, which you will then have to reject, doubling connection > establishment time. > > So Apple's client still has DH off. > > However I don't see a helpful solution to this; the obvious thing is > to have a new ciphersuite, but it's hard to see how that would be > worth the effort if it requires new implementations and ECDHE is > already standardised and already implemented in many places. > TLS 1.3 will resolve this with the new cipher suite negotiation, but I agree this makes the specification basically undeployable with TLS 1.2. This issue also got brought up here: https://www.ietf.org/mail-archive/web/tls/current/msg18697.html Barring unforeseen problems, Chrome will also lose DH in the next release. We certainly could not deploy this without the separate cipher suite numbers. But I can't imagine Chrome deploying it with the separate cipher suite numbers either for the same reason as Geoffrey. It does not seem worth bothering when ECDHE is already widely deployed. David --001a11440f7eb42cac053a7112f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 19= , 2016 at 2:35 PM Geoffrey Keating <geoffk@geoffk.org> wrote:
Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:

> The problem is that 7919 doesn't say "I want to do DHE, if po= ssible
> with these parameters", it says "I will only accept DHE if y= ou use
> these parameters, otherwise you cannot use DHE but must drop back to > RSA".=C2=A0 Talk about cutting off your nose to spite your face, = you'd
> have to have rocks in your head to want to break your implementation > like that.

Actually, my problem with the RFC is the reverse.=C2=A0 If you have an
implementation which won't accept certain DH groups, and those are
extremely common in legacy software (1024-bit, for example), there's no way to stop those legacy implementations ignoring the extension and
choosing DH, which you will then have to reject, doubling connection
establishment time.

So Apple's client still has DH off.

However I don't see a helpful solution to this; the obvious thing is to have a new ciphersuite, but it's hard to see how that would be
worth the effort if it requires new implementations and ECDHE is
already standardised and already implemented in many places.

TLS= 1.3 will resolve this with the new cipher suite negotiation, but I agree t= his makes the specification basically undeployable with TLS 1.2. This issue= also got brought up here:

Barring unforeseen = problems, Chrome will also lose DH in the next release. We certainly could = not deploy this without the separate cipher suite numbers. But I can't = imagine Chrome deploying it with the separate cipher suite numbers either f= or the same reason as Geoffrey. It does not seem worth bothering when ECDHE= is already widely deployed.

David=C2=A0
--001a11440f7eb42cac053a7112f4-- From nobody Fri Aug 19 14:29:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F82F12D1B7 for ; Fri, 19 Aug 2016 14:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNovbxr9eiNv for ; Fri, 19 Aug 2016 14:29:53 -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 8967F127058 for ; Fri, 19 Aug 2016 14:29:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42335BE5F; Fri, 19 Aug 2016 22:29:52 +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 PbOlgJCexE_F; Fri, 19 Aug 2016 22:29:51 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 73E2DBE5C; Fri, 19 Aug 2016 22:29:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1471642190; bh=knxkSikjvweksYkSNdPDMCNsirO/Ptp2Mt5k677GH1Q=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=37JLy+lBEobWvJ9R9aCd/scXVqaBw9HFjsBQCzVqYb2JE5bX6acfKJaJCdEj8Y4YZ 8FG+R9Md7JmjuI7OBlojX9/oDG1tq4nlFrg20AlHbRa9iP8ZGb1++px2Rn1UY3M2PO m9s9jSYQ8zL6Cn5/4/s2N8KWKzFD3kE34WRomZY0= To: Adam Langley , Keith Winstein References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> Date: Fri, 19 Aug 2016 22:29:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030703000102080503030500" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 19 Aug 2016 21:29:55 -0000 This is a cryptographically signed message in MIME format. --------------ms030703000102080503030500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19/08/16 19:05, Adam Langley wrote: >> > Right, exactly. (Ideally, the device doesn't even know it's being >> > audited until the user logs in to the Web UI and says, "okay, now, >> > ratchet the session and then share the old keys with this auditor th= at >> > I am going to introduce you to, so it can decrypt some earlier >> > ciphertext I've been capturing." So we don't want a parallel channel= >> > and we don't even want the device to have to know about the audit >> > beforehand.) >> > > I think that this is the most interesting case. And for me, the dodgiest, by far. The scope for an "auditor" (what is that?) actually being an attacker is IMO way too high to consider standardising that kind of feature and any idea that it'd involve informed consent of someone seems to me fictional. I'd be opposed to that fwiw, as an individual participant. As an AD, I'd look excruciatingly closely at the process for demonstrating that there's a real WG and IETF consensus for that kind of feature and that its potential for conflicting with other BCPs and well established IETF positions is very carefully considered. S. --------------ms030703000102080503030500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MTky MTI5NTBaMC8GCSqGSIb3DQEJBDEiBCBbZiIvPEt2LROgjsT+567vkFRrDqdxCtX1zSZ91T/r GDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA4wjLU9J0F5cWyOeg9i6DNPXYpwf4crb2VZ45O1DBxYpng4FZxJGAm jIVU0yAgDxgwSP3mm0ucdKls5pZCpTKwDXkHrHIE4MfiFBa7y0gkYn2UmGMooUxDfYhMvICQ 5xOD0aH5L8+h7L4YFossxdtB4GBr5AGnvD1TwRwh/6bNun6kMInbzauZGn/XF6BG9KFnAeZN g/IdOZmojZMzscAxf1YY6BZu1VF6EoPCjjRT4kx8AUm7l1WX3/uWwKnltdRb5oHo9Ekx79+6 9wCTj2aBLwlQSnwB6EmOn9uQ7uu49p/dUWiFyj/gXGex/hA3W0KD7uRl9UVNTtML3valxAfJ AAAAAAAA --------------ms030703000102080503030500-- From nobody Fri Aug 19 14:57:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D3212D567 for ; Fri, 19 Aug 2016 14:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6w4VAkK_LM8 for ; Fri, 19 Aug 2016 14:57:15 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 1607312D151 for ; Fri, 19 Aug 2016 14:57:15 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id e31so20047479ybi.3 for ; Fri, 19 Aug 2016 14:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XCQQNOFw8yDhD5S+quUZQmbyacC7usbkmt9IhuON0vI=; b=w/fRgM/3A1emeaE52N+3dgMW/U4ZnBiRZx3bTlqej8co9etRvC52Pg6HM2dvaTbd+o XGzO2opFaWYK6UGl5SjRFlCkA9qyhEoRSk2zS//sP4Uy8nWXilDtAvwtIIjVCRLy5jDf zIXpgIDMJSZhRsnfhMLB1tmEWsGeFBNCuQcNXvk312HTGC33J7NScvTp3GwLH3MmLVQr mvAMrGUDr8wXwzr5QJSQm/Y/n9hneiGp4UF4U5lQoY7m4jbqdUMo/soM5C0vsdzf7h1H OuVu3mKDR8vEun5Rhi+ILbsNrdoqQ7KzNMuCu2BlDiMug5GO0sHUAQ8xZTsCXjdAYY+S WzRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XCQQNOFw8yDhD5S+quUZQmbyacC7usbkmt9IhuON0vI=; b=COF/sbnjhHF2SMyVoYl1ltNs4rAl7vma1qCKKYK40r649kJIuQY/p3olKAaL569C9O ZnmPps382SJhHw8TQaQ0Pu/90EJsYz7tUvvBLeRfL6YkUbOpMKc9yKUFurktf+MHIbkz WEkmcB+02RVfOIewb5Quh91X8R+WPKEQQLTWEooMUPom84FsWCiZ+NAN1sLSW5cNSy1J 97rXOEB9rUBy25hqqp2UV03XpHSLMXb1ydiGV/RhkMFQJskFHazHsTxBoCnOawiWd40u IKth07sIUNGZZ09/JoNzrI/+IetAx1fh7MOieFT7IMjzwB0+HEnrKZ97IvRYzkeRkDf/ nGzA== X-Gm-Message-State: AEkoouvwkqDAIkrzMWwISaY5cg5a2Lh9jqt45ssjwcDyOQpHYs9Wc1+SkMjOkYYiw4IvmAIYqFfmcfk8UAlOVA== X-Received: by 10.37.3.198 with SMTP id 189mr7865619ybd.57.1471643834360; Fri, 19 Aug 2016 14:57:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Fri, 19 Aug 2016 14:56:33 -0700 (PDT) In-Reply-To: References: <20160818052622.zim6nxwwqw3hzmr6@LK-Perkele-V2.elisa-laajakaista.fi> <20160818124602.syi2whfbrom7xfi6@LK-Perkele-V2.elisa-laajakaista.fi> <20160818133541.6b2eb5kshva4m5br@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 19 Aug 2016 14:56:33 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a11c02ddafbd6bf053a73c7c3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-tls13-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 19 Aug 2016 21:57:17 -0000 --001a11c02ddafbd6bf053a73c7c3 Content-Type: text/plain; charset=UTF-8 I've reviewed David's PR and I think it's basically sound. Unless I hear some objection to this over the weekend, I intend to merge it or some revised version on Monday. -Ekr On Thu, Aug 18, 2016 at 8:00 AM, David Benjamin wrote: > On Thu, Aug 18, 2016 at 9:35 AM Ilari Liusvaara > wrote: > >> > > David Bejamin already posted a PR about that. Doesn't clearly say >> > > that unknown reason handling. >> > > >> > >> > Yeah, I read the list before the PRs. I'll take a look but if you want >> to >> > comment that would be great. >> >> The only comment is that I would prefer to allow extensions the without >> client including them in ClientHello[1] (obviously fatal if unknown one is >> seen[2]), instead of special-casing Cookie. >> > > FWIW, I'm not a fan of special-casing Cookie either. I just left it alone > for that PR and only bothered about moving to an extension since I wasn't > sure how it should work. > > Just removing the requirement altogether seems reasonable? Although it > doesn't give much guidance on which are and aren't MTI. Is a TLS client > over TCP obligated to implement Cookie to avoid interop issues? Seems kind > of pointless to require it there, just more things to remember. Whereas a > DTLS client over UDP which doesn't implement cookie is unlikely to work > well. But probably that kind of guidance ought to live elsewhere anyway. Or > maybe we should just declare cookie MTI everywhere and leave it at that. > > (Though, I'm sure, in practice, no one will ever send cookie over TLS and > thus some clients won't honor it.) > > David > > >> >> [1] Of course, if the error is related to values in extension, then the >> client had to include it in its ClientHello. >> >> >> [2] Basically, if client is told that its ClientHello is wrong in some >> way it does not understand, obviously it can't fix it. >> > --001a11c02ddafbd6bf053a73c7c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've reviewed David's PR and I think it's basi= cally sound. Unless I hear some objection to this over the weekend, I inten= d to merge it or some revised version on Monday.

-Ekr


On Thu, Aug 18, 2016 at 8:00 AM, David Benjamin <davidben@chromium.or= g> wrote:
=
On Thu, Aug 18, 2016 at 9= :35 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > David Bejamin already posted a PR about that. Doesn't clearly= say
> > that unknown reason handling.
> >
>
> Yeah, I read the list before the PRs. I'll take a look but if you = want to
> comment that would be great.

The only comment is that I would prefer to allow extensions the without
client including them in ClientHello[1] (obviously fatal if unknown one is<= br> seen[2]), instead of special-casing Cookie.

=
FWIW, I'm not a fan of special-casing Cookie either. I just= left it alone for that PR and only bothered about moving to an extension s= ince I wasn't sure how it should work.

Just re= moving the requirement altogether seems reasonable? Although it doesn't= give much guidance on which are and aren't MTI. Is a TLS client over T= CP obligated to implement Cookie to avoid interop issues? Seems kind of poi= ntless to require it there, just more things to remember. Whereas a DTLS cl= ient over UDP which doesn't implement cookie is unlikely to work well. = But probably that kind of guidance ought to live elsewhere anyway. Or maybe= we should just declare cookie MTI everywhere and leave it at that.

(Though, I'm sure, in practice, no one will ever send= cookie over TLS and thus some clients won't honor it.)

David
=C2=A0

[1] Of course, if the error is related to values in extension, then the
client had to include it in its ClientHello.


[2] Basically, if client is told that its ClientHello is wrong in some
way it does not understand, obviously it can't fix it.

--001a11c02ddafbd6bf053a73c7c3-- From nobody Fri Aug 19 20:35:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ED412D597 for ; Fri, 19 Aug 2016 20:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naEvh-HPfHKu for ; Fri, 19 Aug 2016 20:35:52 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C47812D593 for ; Fri, 19 Aug 2016 20:35:52 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u134so23749453ywg.3 for ; Fri, 19 Aug 2016 20:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=h+EeRQ9FVLJgtZaQpqTz4+PNYDvgjKbsFk6IVeVCpy0=; b=MzrY4WOyisgxleeAwz0n+Lrgy9SP8QxZrHFSsBdaGRj83t9gBi7LVw2INyweni+JmV nY4q+nVpDKChuyCJjhpJ99ziJhMPeGMYJ+k5Ph6O06DeUwswvvB1K5PH3qhAu0Gjs6rY NbfVvT0gDS2dwLoE0qAg0VJ52uJIy7Rz2vjoTwCbQ3+nvv7DtxoN7fSToa7MeNBsd6He CwURgoBTgsSeritJjkcei5rqzHEOOryjLdk+SGB4PUk8gDaLKvpijiBcqNJM5YheLpvD fgwr/O9o+iwJA+QbWU5BStm5+CgxXjYuDzStaxrJCggSLY5rwgs38emLPlsZhk25NJaa ABHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=h+EeRQ9FVLJgtZaQpqTz4+PNYDvgjKbsFk6IVeVCpy0=; b=UAe9Xhj95qULscNn8U/O23qsXTtK/IzmnTWNjLct7p7BO0DTsLYndsooc63DMexK/X PeFaq6HNtUj8Qv2C0l+b+Q7Pbu04nHw31Vis9TtKWYiDQrt5nFYUvumQz0ahG719nlYB IjbmhfYbu9iTZClD3Bf9F0ALojD/CNf8ugB/PfXPJZ5NfXYaTMMOMoMztKsMLIlKICnI OgbpM6ragOFu5U1ZWHrhnNq3SY1b3ogawT80Uqc6P+AB/+6Z9hNaMePmMtLqDXjryCic F6UFDV4dLDI/tb+8V4U3aDRCisWxhi9jeAqBoEQIaL8S/3RzCNI/O/tE6JE1aWQL8gy9 k50A== X-Gm-Message-State: AEkoous2xwImZ8kd8CYCY+GREODC2d/PF+gqrjo3qPWgHzbfwWEeMg/CCfvSr/iuEDgl+loAIUIqKeSdFOrYMQ== X-Received: by 10.13.202.20 with SMTP id m20mr9266597ywd.183.1471664151356; Fri, 19 Aug 2016 20:35:51 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Fri, 19 Aug 2016 20:35:10 -0700 (PDT) In-Reply-To: References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> From: Keith Winstein Date: Fri, 19 Aug 2016 20:35:10 -0700 X-Google-Sender-Auth: qQnbNSdM-uR1yh61VhDwU8ENDMg Message-ID: To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Aug 2016 03:35:55 -0000 On Fri, Aug 19, 2016 at 11:05 AM, Adam Langley wrote: > I don't think that a device can ensure that the other side doesn't get > compromised. Even if it rotates keys, there are plenty of ways that a well > meaning implementation could fail to erase them: copying GCs, swap, > hibernation, coldboots, even hypervisor tricks like moving VMs between > machines. Sure. This is true of every forward-secret mechanism -- I don't think KeyUpdate is unique. As you probably know better than me, the hope of PFS is that key deletion (of the keys that can decrypt the ciphertext) happens in the window after the ciphertext is received and before the keys are compromised. But obviously it's different to have a protocol that supports PFS vs. actually deleting the keys. > And I don't think the device can ensure that the keys that it writes to > flash aren't used to protect sensitive data without application-level > support. Consider a device that does a KeyUpdate and gets a KeyUpdate in > reply before sleeping. However, just after echoing the KeyUpdate, the other > side says "oh, and by the way, here are the battle plans...". Sure, you're right about new data that the server sends on its own initiative after a ratchet. You do still protect all the data that was sent in the prior epoch. > Those plans > would be encrypted with keys that the device just wrote to flash. So there > has to be an application-level concept of "we're rotating keys now because > I'm going to sleep. These keys are only for authenticating another KeyUpdate > when I wake, don't send me anything." Obviously, in the real world the mechanism is much more useful if it works with typical unmodified webservers and TLS terminators. If I wanted to build my own application-layer protocol, I wouldn't be here. (Mosh *has* a secure bidi close...) > So you're worried that the server might not notice that a device has closed > a connection and so keep the keys in memory? Why didn't it notice? Because > an attacker cut the communication? If so, couldn't the attacker cut > communication just before the KeyUpdate and achieve the same thing? > > Or are you assuming that we can't trust an implementation to erase keys when > a connection closes, but it will erase them for a KeyUpdate or a > bidirectional close? I send you a close_notify, and you send me a close_notify. Have you stopped trusting input from my key? Have you deleted my key? There's no way for me to tell. That's the worry. If I send you a KeyUpdate, and you increment your receive_generation and tell me, then I know you SHOULD have deleted the prior key. That's the most I can really ask for. -Keith From nobody Fri Aug 19 20:40:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688DD12D59D for ; Fri, 19 Aug 2016 20:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCH6ZUwfw0iS for ; Fri, 19 Aug 2016 20:40:54 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47E712D593 for ; Fri, 19 Aug 2016 20:40:53 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id e31so21695119ybi.3 for ; Fri, 19 Aug 2016 20:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+lIoMlbHxKypy9PBnb28hhcThe5rFyqtALDtAiXFIa4=; b=UjWkejuP/+alTJ/TaJxco65FEyCoVMRy9sgy22xssDaraqNgo+9YNpcqQ3PcaWZAe8 YQrmKuq2K1FK/zD3/rAUmuFFIW+kvh++czZBXoqRMpoHgc/hUGJG04qgCQz+Zt6EWwNz QDRFuK6R9AAVaO0tVw/8lk+GijYaHDmV3Mjp93HnBgkHui2vO0/XVAoF4glnGzPSwnnf F5DJpGIgybMf3UzmhocACnLjYnV4WKh2eywPBH/L4Ca+7h+2CpLNp4g9WV58GvucpBWf OuaAJYN620tN2xAdUaUsw8dCFQ1JcOb8rty1rAjIGEbkk8kFWbyl/Flx9woN41uUiN2I UejA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+lIoMlbHxKypy9PBnb28hhcThe5rFyqtALDtAiXFIa4=; b=RXNNnmwahsDyShgtOWWlpl6zfKX3acc9qEL2ObELRFD/SbbtUerEF92rkdOiz+OW4h KmVhpJyX8vHmem4OCD7fFP5uEOm7th5wvyP2KbY2DNACcbaAs6jEIGaGRuq7tVuJuscw 9ngcU0dk1gmf0Uzg1bjxgo6BZUM0PAUanj3Ax6DWqCw2hxRnanf0VZDqrraNMPPoJUwQ NraIGesV4YnuHQnSAGGKE8Nyi5stQbU3D5BaGE0TMkjXEYtTampV0XpV1c2tpSFwL8s6 zE1foLszLvaQbeAGIbTbnyZ8QZLRHSNG9M0vAX8JeRH1+Kfd93OSVZmXStfWY3QB/23C XmLw== X-Gm-Message-State: AEkoous6NWSX4ovLof4BVleQ5G5/QM7xL9BHesVafWJ3WP0HAg96VJCKn+FFTG1/hsj00txIc6Ona9qjAyeSaw== X-Received: by 10.37.79.87 with SMTP id d84mr8274826ybb.165.1471664453040; Fri, 19 Aug 2016 20:40:53 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Fri, 19 Aug 2016 20:40:12 -0700 (PDT) In-Reply-To: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> From: Keith Winstein Date: Fri, 19 Aug 2016 20:40:12 -0700 X-Google-Sender-Auth: lcjwkQxk_dGL93lj35MQeZKILGU Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Aug 2016 03:40:56 -0000 On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell wrote: > > And for me, the dodgiest, by far. The scope for an "auditor" > (what is that?) actually being an attacker is IMO way too > high to consider standardising that kind of feature and any > idea that it'd involve informed consent of someone seems to > me fictional. I appreciate the sensitivity of this issue to the WG. My read of your email is that there's a concern that by standardizing a protocol mechanism that allows a node to learn when its own KeyUpdate has happened, the WG would imply approval of features that permit the bad kind of eavesdropping. Here's why I don't think that's the case: Our PR is for a piggyback integer field to provide security property P3: "An implementation can learn that its request to rekey its outgoing traffic has been read by the other side." KeyUpdate is an *instruction* to the other side: "please update my key in a forward-secure manner." We think some implementations will want to know that the instruction has been carried out. And there's an easy opportunity to do that here as a piggyback, without any extra protocol messages. A node will naturally care more about forward secrecy, and confirmation of a forward-secure ratcheting event, the more it has reason to suspect the keys might later be exposed to a third party. In Berlin, I described three escalating cases: the (1) node going to sleep, (2) node closing a connection without a mechanism for secure bidi close, and (3) node that itself intends to release keys to a read-only auditor after a ratchet is complete. By "read-only auditor," we mean a curious person or security researcher who owns an IoT device and wants to know what the heck it is sending out of their house, where the device doesn't want to allow its owner to add trusted certificates for an MITM. (This describes most such devices today.) Obviously I think it's valuable to make this mechanism available for IoT device manufacturers. Having talked to several manufacturers, I'm cautiously optimistic that some would use this. But the WG doesn't have to take a position on this. These use cases are up to implementers. There's nothing stopping an implementer today from releasing session keys, or allowing complete MITM, as is the case in the browser context with user- or admin-installed root CA certificates. The TLS WG hasn't opined on these either. To restate: Property P3 allows a node to learn that its KeyUpdate instruction has actually happened, which in our view is useful and a strict benefit over the status quo. It's also orthogonal to the issue of unbounded write obligations raised in this thread. -Keith From nobody Mon Aug 22 05:29:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6EB12D0EB for ; Mon, 22 Aug 2016 05:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TESDK4lDo1ih for ; Mon, 22 Aug 2016 05:29:29 -0700 (PDT) Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883DE12D185 for ; Mon, 22 Aug 2016 05:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date; bh=26eIexVvoOaiF6insZzUBRtMsBZKwRu7alDy/9qMr+M=; b=wyg73NhDVg/p9+yRkBUG2BixujXnlf0VowX8lotYYN3qUH3W1IEaWVYZUpI/H03/2vpC7w8uDjqsdF0jIjaSM8LaN9CuM9YJKrlK46h7usZOlVwlAST+Obgweklk55kIL5LQw+PJjDY+hsCAiKJHRJkkYSDPYdj8nyHHdNJTuHIWdT/D2am2vtzTw9APgACAk8M8XJB8BkYkAIQ5uneVq2qOfWr5b0B4XT8nmFhTVOP84HesdxIqHvjo76BJ1M0z8GDPK/o24ASvV8FH4eheDWbRWJ4ScLBM6Xk2JkNzqD5FVBat0mjd50uUevZ9WeWZerqX7hUsDe6uNr1qUH1E3w==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bboLp-0002QB-If; Mon, 22 Aug 2016 14:29:27 +0200 Date: Mon, 22 Aug 2016 14:29:10 +0200 From: Peter Wu To: tls@ietf.org Message-ID: <20160822122910.GA4465@al> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: Alexis La Goutte Subject: [TLS] TLS 1.3 draft version extension (0xff02) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2016 12:29:32 -0000 Hi, The Implementations wiki page in the Github repository (https://github.com/tlswg/tls13-spec/wiki/Implementations) states that extension 0xff02 (65282) defines the TLS draft version in use. I cannot seem to find an official registration with IANA though which might cause implementation issues in the future if this extension type is re-purposed. Question: can we rely on this extension being used only for specifying the TLS draft version? We are working on adding TLS 1.3 support to the Wireshark SSL/TLS dissector, if this extension type is not official we should probably not add it. -- Kind regards, Peter Wu https://lekensteyn.nl From nobody Mon Aug 22 05:48:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDB012D146 for ; Mon, 22 Aug 2016 05:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z84oNSj3ifZf for ; Mon, 22 Aug 2016 05:48:15 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 48E7F12D0F0 for ; Mon, 22 Aug 2016 05:48:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id CDC3B10F9C; Mon, 22 Aug 2016 15:48:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ZKj9CYvILKFP; Mon, 22 Aug 2016 15:48:12 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2FA2621C; Mon, 22 Aug 2016 15:48:12 +0300 (EEST) Date: Mon, 22 Aug 2016 15:48:03 +0300 From: Ilari Liusvaara To: Peter Wu Message-ID: <20160822124803.y2uzawtq3lytr6pw@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160822122910.GA4465@al> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160822122910.GA4465@al> User-Agent: Mutt/1.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org, Alexis La Goutte Subject: Re: [TLS] TLS 1.3 draft version extension (0xff02) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2016 12:48:17 -0000 On Mon, Aug 22, 2016 at 02:29:10PM +0200, Peter Wu wrote: > Hi, > > The Implementations wiki page in the Github repository > (https://github.com/tlswg/tls13-spec/wiki/Implementations) states that > extension 0xff02 (65282) defines the TLS draft version in use. Also, nice surprise mentioning it only there and not in the draft spec itself (complete with appropriate RFC-Editor notes). > I cannot seem to find an official registration with IANA though which > might cause implementation issues in the future if this extension type > is re-purposed. There is no registration for it. However, only draft implmentations send it (final ones won't), which should limit the damage, as draft implementations are meant for testing only, and not for general- purpose use. > Question: can we rely on this extension being used only for specifying > the TLS draft version? We are working on adding TLS 1.3 support to the > Wireshark SSL/TLS dissector, if this extension type is not official we > should probably not add it. Well, I don't suppose it will be re-used quickly... -Ilari From nobody Mon Aug 22 06:09:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C1D12D505 for ; Mon, 22 Aug 2016 06:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq7oWW2yf1tn for ; Mon, 22 Aug 2016 06:09:13 -0700 (PDT) Received: from COL004-OMC4S8.hotmail.com (col004-omc4s8.hotmail.com [65.55.34.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A637412D1EA for ; Mon, 22 Aug 2016 06:09:13 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.34.201]) by COL004-OMC4S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 22 Aug 2016 06:09:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OnnprRuDw5JKCee3FG/ds7Q1zM+bU4utEgCa5osqRQo=; b=XxqegJ4J1jm1rR9a/IaDdfV4JNT2Y2h7Ns5eVLjW/l2L2XI6akgOPfedQ/Qt7wSwPR2gRuuFheqpaKNZhaFdtlTSKGCRgJvmLxY9UXfNWR6ajtVZ+OS2hVpuwfA9YyNIC789SJsnz4Szn8ukcyY9fB1AQd8sVUS+sCgk4jP2hL+mKbSljfSeoVH6L/ErpAiZZM9t7lFq664MFgQ4ezZUxV8Z+oT9V5s4JWY61Vk+q9KXWFu02NCenQm7yWF1atpiMBbwOPIwyWroI2ldkmw/G7jFOhJLfnWj50FIwL11yGiMcN57UO+rPelLteKWXafQKudts8U7SqVUZmW82OmdwA== Received: from BL2NAM02FT057.eop-nam02.prod.protection.outlook.com (10.152.76.57) by BL2NAM02HT134.eop-nam02.prod.protection.outlook.com (10.152.77.76) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.577.8; Mon, 22 Aug 2016 13:09:09 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.76.55) by BL2NAM02FT057.mail.protection.outlook.com (10.152.77.36) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.577.8 via Frontend Transport; Mon, 22 Aug 2016 13:09:08 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0587.009; Mon, 22 Aug 2016 13:09:07 +0000 From: Xiaoyin Liu To: Ilari Liusvaara , Peter Wu Thread-Topic: [TLS] TLS 1.3 draft version extension (0xff02) Thread-Index: AQHR/HDaOCetc8ii3kevF5w9PklhUKBU7fWAgAAF4VU= Date: Mon, 22 Aug 2016 13:09:07 +0000 Message-ID: References: <20160822122910.GA4465@al>, <20160822124803.y2uzawtq3lytr6pw@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160822124803.y2uzawtq3lytr6pw@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.76.55) smtp.mailfrom=outlook.com; welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.76.55 as permitted sender) x-tmn: [jOrI7uSmBUSirwK0RRxFZnlroywfW5GW] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.76.55; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2NAM02HT134; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; BL2NAM02HT134; 6:JmoJDEp+15nl6PVZmLLXvmZcLrXeW6C/uogitS9S9GGVmkZ/hUdM3Z51cXDNtjwFcqB/gtUgzAyyDyzJPN15AvrXOHCUgRxu11MuBs0A88pvSH3WhI2XxRoYZMcs8tI8o5vm1FzT9QF0yLWLXO7JDwDl09abxarf0jcWvlzS28o+opl0crtVy0nUAkVRS0hcYJRt7Jt7sd1a1X/I6s5ZgHEV1J08yfwuPhM0+rtcDyBkicJMYcLDu8f33IjNnmxyGufY09tVVf3O8e9gNxPF1Nh/qy3BtE1usb9MYVkFYwTprI3Hz9zOZGKmMM5MAfHE; 5:3o2EghWLRR1MMPo8Ye+6/USrmp2H52Aen5xo0cQC9YTbNTlQbQfVhncVAsdm32w4BJEeGgAbswp9hnx2OdnNL2jC71zT21Kt83ve3GCAzfzXkHx90a70RbeScCHVHNtUR7JPDNYbTirF+UfAerauQw==; 24:SznX0qDl48TrixEzrx4qsA3madTvUu6MYpgMuT35CWMHTklzdh3oLZ1sCEqNl+3I9P7p8vBCn9efu5gQ+NWJBWdKQHk9FObFLHqqq2eJlnY=; 7:L0tUV3T92kjWI81dXMDJAfibdzrCkF2XDkAHCNdUZ0yIIgRV6nmbC42qUhDo79bf8VDQgtJi7fnFpi9Y0jPRUA4dEETM3qFwnmgRJ4z5orkbIr9z1rgkUvTNmMWZ5Ty1Y8rnyST69kKjdNqicECgPimp9ZH26V7QFzJ+QuNCV8DrQjAHYcYd2Xt6xw80hhA2m8i+BO4FoadDKS1ZbC9kCaQSzD62pvA0EzLA9goQbrnZU9X+d2ErV8/d/krMDcxh x-ms-office365-filtering-correlation-id: 153fad0f-9b71-4b47-aac3-08d3ca8d7fe8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1601125047); SRVR:BL2NAM02HT134; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BL2NAM02HT134; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT134; x-forefront-prvs: 00429279BA spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB077831032FA5F70B7C01A900FFE80CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2016 13:09:07.3985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT134 X-OriginalArrivalTime: 22 Aug 2016 13:09:13.0221 (UTC) FILETIME=[60E1DB50:01D1FC76] Archived-At: Cc: "tls@ietf.org" , Alexis La Goutte Subject: Re: [TLS] TLS 1.3 draft version extension (0xff02) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2016 13:09:18 -0000 --_000_CY1PR15MB077831032FA5F70B7C01A900FFE80CY1PR15MB0778namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it will be nice if IANA can reserve some extension ID numbers for p= rivate use, so that whenever we need an extension for testing purpose only,= we can pick an ID from the private pool without fear of collisions in the = future. Best, Xiaoyin From: Ilari Liusvaara Sent: Monday, August 22, 2016 8:48 To: Peter Wu Cc: tls@ietf.org; Alexis La Goutte Subject: Re: [TLS] TLS 1.3 draft version extension (0xff02) On Mon, Aug 22, 2016 at 02:29:10PM +0200, Peter Wu wrote: > Hi, > > The Implementations wiki page in the Github repository > (https://github.com/tlswg/tls13-spec/wiki/Implementations) states that > extension 0xff02 (65282) defines the TLS draft version in use. Also, nice surprise mentioning it only there and not in the draft spec itself (complete with appropriate RFC-Editor notes). > I cannot seem to find an official registration with IANA though which > might cause implementation issues in the future if this extension type > is re-purposed. There is no registration for it. However, only draft implmentations send it (final ones won't), which should limit the damage, as draft implementations are meant for testing only, and not for general- purpose use. > Question: can we rely on this extension being used only for specifying > the TLS draft version? We are working on adding TLS 1.3 support to the > Wireshark SSL/TLS dissector, if this extension type is not official we > should probably not add it. Well, I don't suppose it will be re-used quickly... -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CY1PR15MB077831032FA5F70B7C01A900FFE80CY1PR15MB0778namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think it will be nice if IANA can reserve some e= xtension ID numbers for private use, so that whenever we need an extension = for testing purpose only, we can pick an ID from the private pool without f= ear of collisions in the future.

 

Best,

Xiaoyin

 

 

 

From: Ilari Liusvaara
Sent: Monday, August 22, 2016 8:48
To: Peter Wu
Cc: tls@ietf.org; Alexis La Goutte
Subject: Re: [TLS] TLS 1.3 draft version extension (0xff02)

 

On Mon, Aug 22, 2016 at 02:29:10PM +0200, Pete= r Wu wrote:
> Hi,
>
> The Implementations wiki page in the Github repository
> (= https://github.com/tlswg/tls13-spec/wiki/Implementations) states that > extension 0xff02 (65282) defines the TLS draft version in use.

Also, nice surprise mentioning it only there and not in the draft spec
itself (complete with appropriate RFC-Editor notes).

> I cannot seem to find an official registration with IANA though which<= br> > might cause implementation issues in the future if this extension type=
> is re-purposed.

There is no registration for it. However, only draft implmentations
send it (final ones won't), which should limit the damage, as draft
implementations are meant for testing only, and not for general-
purpose use.

> Question: can we rely on this extension being used only for specifying=
> the TLS draft version? We are working on adding TLS 1.3 support to the=
> Wireshark SSL/TLS dissector, if this extension type is not official we=
> should probably not add it.

Well, I don't suppose it will be re-used quickly...


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
 --_000_CY1PR15MB077831032FA5F70B7C01A900FFE80CY1PR15MB0778namp_-- From nobody Mon Aug 22 11:07:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826DD12D0CF for ; Mon, 22 Aug 2016 11:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaaqdr6gg_YB for ; Mon, 22 Aug 2016 11:07:47 -0700 (PDT) Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86AF12B039 for ; Mon, 22 Aug 2016 11:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Xwedzxl7cfYHgZrkCMezwuQrfe94txZuRrh0SWYkC/w=; b=kB7uDlsFPCNFemyueFHStQEtD1Z/ggEMzKDQOHpirIhZT+/izJWiJ6lq6JG75GBYcwMo9FQGK/UDAjzbG2/IDejcqvopZIsx1cxGnNDe1tbZ6HMXtwLFQ7sgNTLd63AgANB/o1/B9ABD1FUL1dBmd3JoTodWGS82S93W0d0c6hYklmTAIcw4NRZMAcmUW4Buiaa5s0O3ZTWGM2AI6ErhFsmOTFy4IgasNIGGCQBs0LLnv8tBKyLTYLHwQ1eV/BuaU4LFoVH2kkNStGIVGjpvyXb52S3sxEbXzubKkHjeKoZLMnT08NBwAPTHddg68vHQze677uDMlc4Sv7HgxgI4FQ==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bbtdF-0004I6-JB; Mon, 22 Aug 2016 20:07:45 +0200 Date: Mon, 22 Aug 2016 20:07:29 +0200 From: Peter Wu To: Ilari Liusvaara Message-ID: <20160822180729.GB13425@al> References: <20160822122910.GA4465@al> <20160822124803.y2uzawtq3lytr6pw@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160822124803.y2uzawtq3lytr6pw@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.7.0 (2016-08-17) Archived-At: Cc: tls@ietf.org, Alexis La Goutte Subject: Re: [TLS] TLS 1.3 draft version extension (0xff02) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Aug 2016 18:07:49 -0000 On Mon, Aug 22, 2016 at 03:48:03PM +0300, Ilari Liusvaara wrote: > On Mon, Aug 22, 2016 at 02:29:10PM +0200, Peter Wu wrote: > > Hi, > > > > The Implementations wiki page in the Github repository > > (https://github.com/tlswg/tls13-spec/wiki/Implementations) states that > > extension 0xff02 (65282) defines the TLS draft version in use. > > Also, nice surprise mentioning it only there and not in the draft spec > itself (complete with appropriate RFC-Editor notes). > > > I cannot seem to find an official registration with IANA though which > > might cause implementation issues in the future if this extension type > > is re-purposed. > > There is no registration for it. However, only draft implmentations > send it (final ones won't), which should limit the damage, as draft > implementations are meant for testing only, and not for general- > purpose use. The same page notes: "Implementations of the final version should check for this extension and fail to negotiate TLS 1.3 if it is present. That check might be removed once sufficient time has passed." ...which suggests that implementations of the final version could actually care about it. > > Question: can we rely on this extension being used only for specifying > > the TLS draft version? We are working on adding TLS 1.3 support to the > > Wireshark SSL/TLS dissector, if this extension type is not official we > > should probably not add it. > > Well, I don't suppose it will be re-used quickly... I don't have a crystal ball, but it would be nice if use of an extension type is registered somewhere. Either directly with IANA or, as suggested by Xiaoyin, by reserving a range. -- Kind regards, Peter Wu https://lekensteyn.nl From nobody Mon Aug 22 23:44:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF4412B04D for ; Mon, 22 Aug 2016 23:44: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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oPquRZPdDr8 for ; Mon, 22 Aug 2016 23:44:23 -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 9147812B006 for ; Mon, 22 Aug 2016 23:44:23 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id t7so98724125qkh.1 for ; Mon, 22 Aug 2016 23:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KR+X1hurGWs+5goU4MksBugZKU1dIsntTwpfH7BO/vQ=; b=C+Sq46EQi3gKJjZQGME83fdAqw8J8UN0PWwmM4u/i9cdi9vr0eHZzwyvedijHqISou wfiFpRHIYnAl0VhZyY8ig4lMt1aUgGnNbNjQezfHsIJ8+13Guo/9LonTji8BfowMo0jM kwB9zYwd7/aoqU+j1d2CFZ9Vds+tnR8IrNkyafBZwAa9SNu4eXquPl9dofz3DCA8T0qD 9qbuZaA3IyObcrQ0h408cbijMQMtGyP+MO7wrA0pPPwN/wp7UBar19xC1x7PgxA3My+4 oxterRVqM2jdHGWRGnpjbKfO0XsebWZ23A3ApAJ6lrGgwlhHlchzUgmXNnNU9Y7dv4Db 38Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KR+X1hurGWs+5goU4MksBugZKU1dIsntTwpfH7BO/vQ=; b=K786rJOqopWAW7QkPJwBPaa9OAYJNpOso5xAFBlBIvOdTMIoAAwCmcsjgeH4hgWahH 2LYjObSM90WgH8vhpFnY8KPY7/CNlxhfBQ7prFTKJ/yi6phfML0a5gi2L6lzDJHMd5QB +BUCmQ8M194ys2bHll//8RT6hXLoj7YGW7tO4XLOlCmb1N7+nqsEwXW1Q3/pL8nHBH+z Jf3/ivReYabGSmHniJNzu2UK+LLOZUIZJM5FNnFN15BnXxVsL8O9knSGPtp47VzR9VF8 VtkISJaqvKzCZWPmcpwT7NYy0DhN5V9DF861XRiN5eVPHgoOUfTvE+OiM+jypDzyJM5r 2a+A== X-Gm-Message-State: AEkooutURvYxyGDNMiM2yQOu+0Njv6p3cN+hT0k+fJ7ZRA8Yikp3Z+zxxMo1j55TzAHLgkHXcJUqCR83JzB0vQ== X-Received: by 10.55.141.199 with SMTP id p190mr27895278qkd.185.1471934662797; Mon, 22 Aug 2016 23:44:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 22 Aug 2016 23:44:22 -0700 (PDT) In-Reply-To: <20160822124803.y2uzawtq3lytr6pw@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160822122910.GA4465@al> <20160822124803.y2uzawtq3lytr6pw@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Tue, 23 Aug 2016 16:44:22 +1000 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Alexis La Goutte , "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft version extension (0xff02) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Aug 2016 06:44:25 -0000 On 22 August 2016 at 22:48, Ilari Liusvaara wrote: > Also, nice surprise mentioning it only there and not in the draft spec > itself (complete with appropriate RFC-Editor notes). It's in the newly minted experimental space, and as you say, this is for private testing of implementations. (If two major browsers count for that ;) From nobody Tue Aug 23 11:47:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4994112D752 for ; Tue, 23 Aug 2016 11:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHKhmmaErqO0 for ; Tue, 23 Aug 2016 11:47:47 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8DE12D74F for ; Tue, 23 Aug 2016 11:47:46 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u7NIiNLt018897; Tue, 23 Aug 2016 11:47:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=lVDcpmYSylpeXD5yLSIcYQ0FACZSeIfoOiw6Uf+t4z8=; b=avvRDwD/NYeoK053V1ShP8jHtWSl6Lp3PEEd6AEmIyzk0AYbC7fSiV7fIfXDKMallGKL DGnDWn81E1EKZ/f432JTn5y+nBT8xv/58pxQEyH2Lwxg3BuZEbqz67ggN5OiKsQiLkEC wvjbl1lSdSntLot3nFpsjvHsXotuTiel6tA= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 250sc9sy09-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Aug 2016 11:47:34 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.36]) by PRN-CHUB02.TheFacebook.com ([fe80::5de8:34:5a87:6990%12]) with mapi id 14.03.0294.000; Tue, 23 Aug 2016 11:47:33 -0700 From: Subodh Iyengar To: Keith Winstein , Stephen Farrell Thread-Topic: [TLS] KeyUpdate and unbounded write obligations Thread-Index: AQHR+QkkZ1yLN/lJTEaEs979SYil0KBPaW4AgAAFMYCAAA8+AIAACaoAgAAENACAAAKrgIAABkSAgAAO5YCAAA4ogIAAL+iAgAEqNACAADkVAIAAZ3sAgAU5xh4= Date: Tue, 23 Aug 2016 18:47:32 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-23_10:, , signatures=0 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Aug 2016 18:47:48 -0000 For people that currently use keyupdates or who are planning to use key upd= ates, which layer are you planning to trigger a key update? Would the TLS i= mplementation itself trigger the update or would the application trigger it= ? For renegotation, I believe it was mostly triggered by the application. = =0A= =0A= For the use cases you mentioned Keith, they seem to be specific to applicat= ion triggered key updates, i.e. key updates do not mean anything to the TLS= layer apart from I got a key update and I must change keys. The fact that = other side has thrown away it's key is only meaningful to the higher layer = protocol. I imagine protocols like HTTP would not add these semantics, and = these semantics would be added to very specific IoT protocols? Would the sc= ope of the auditor be defined as a part of that protocol, or does it need t= o be defined as a part of TLS?=0A= =0A= If key update is an application triggered mechanism, does the generation id= entifier need to be an integer to be understood by the TLS layer or could i= t also be an opaque identifier sent by the application. It would be much si= mpler not to have to deal with the requirements of consistency at the TLS l= ayer and would make the API simpler.=0A= =0A= Subodh=0A= ________________________________________=0A= From: TLS [tls-bounces@ietf.org] on behalf of Keith Winstein [keithw@cs.sta= nford.edu]=0A= Sent: Friday, August 19, 2016 8:40 PM=0A= To: Stephen Farrell=0A= Cc: Adam Langley; tls@ietf.org=0A= Subject: Re: [TLS] KeyUpdate and unbounded write obligations=0A= =0A= On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell=0A= wrote:=0A= >=0A= > And for me, the dodgiest, by far. The scope for an "auditor"=0A= > (what is that?) actually being an attacker is IMO way too=0A= > high to consider standardising that kind of feature and any=0A= > idea that it'd involve informed consent of someone seems to=0A= > me fictional.=0A= =0A= I appreciate the sensitivity of this issue to the WG. My read of your=0A= email is that there's a concern that by standardizing a protocol=0A= mechanism that allows a node to learn when its own KeyUpdate has=0A= happened, the WG would imply approval of features that permit=0A= the bad kind of eavesdropping. Here's why I don't think that's the case:=0A= =0A= Our PR is for a piggyback integer field to provide security property=0A= P3: "An implementation can learn that its request to rekey its=0A= outgoing traffic has been read by the other side."=0A= =0A= KeyUpdate is an *instruction* to the other side: "please update my key=0A= in a forward-secure manner." We think some implementations will want=0A= to know that the instruction has been carried out. And there's an easy=0A= opportunity to do that here as a piggyback, without any extra protocol=0A= messages.=0A= =0A= A node will naturally care more about forward secrecy, and=0A= confirmation of a forward-secure ratcheting event, the more it has=0A= reason to suspect the keys might later be exposed to a third party. In=0A= Berlin, I described three escalating cases: the (1) node going to=0A= sleep, (2) node closing a connection without a mechanism for secure=0A= bidi close, and (3) node that itself intends to release keys to a=0A= read-only auditor after a ratchet is complete.=0A= =0A= By "read-only auditor," we mean a curious person or security=0A= researcher who owns an IoT device and wants to know what the heck it=0A= is sending out of their house, where the device doesn't want to allow=0A= its owner to add trusted certificates for an MITM. (This describes=0A= most such devices today.)=0A= =0A= Obviously I think it's valuable to make this mechanism available for=0A= IoT device manufacturers. Having talked to several manufacturers, I'm=0A= cautiously optimistic that some would use this. But the WG doesn't=0A= have to take a position on this. These use cases are up to=0A= implementers. There's nothing stopping an implementer today from=0A= releasing session keys, or allowing complete MITM, as is the case in=0A= the browser context with user- or admin-installed root CA=0A= certificates. The TLS WG hasn't opined on these either.=0A= =0A= To restate: Property P3 allows a node to learn that its KeyUpdate=0A= instruction has actually happened, which in our view is useful and a=0A= strict benefit over the status quo. It's also orthogonal to the issue=0A= of unbounded write obligations raised in this thread.=0A= =0A= -Keith=0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDQICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3DdPWRCHpTfdtxfXYBMZF__UyOa7wszKFnA6criwmMDHI&s=3DE7sRstn6vNQHPiX3CXA= a6BbWSWtMW7VKtN4f3yblZ5U&e=3D=0A= From nobody Tue Aug 23 20:44:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9305F12DC01 for ; Tue, 23 Aug 2016 18:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt1MIcXYy6Jx for ; Tue, 23 Aug 2016 18:19:53 -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 C20F312D09E for ; Tue, 23 Aug 2016 18:19:52 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z190so1963734qkc.0 for ; Tue, 23 Aug 2016 18:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3LuQj9skV5k2GrK312Yk3UR4ajTdQ7ttdVAJ0FQqF7w=; b=AbfML5ZRVafLBbc7b/I/dUtpV7emZh9l1G99qPgdavm+SQy9mcPzqC4chKC8vOtbRp hdGPWZa3fORVgoGNQ7GHxTF5lHFIQ7d1t9lozq0CBjWfGENQA0RDlwx4Oyme0uCV9bu9 FKw6ZvITFbOotlPRYWOIbxPONp/0dOgMDo3R0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3LuQj9skV5k2GrK312Yk3UR4ajTdQ7ttdVAJ0FQqF7w=; b=Q142sXtO7jKwqt7Yd+TauRRmJzmjE9E4HOIPm5QGn+D8I8mTojCyGRxgMfEYD9ZEzs 0LpPcs/1qx4XpxHYHj02VAMfpjFMzJhG37Y6ys23CS0sfmOg2VO6BdUni5iBssWv2Kox mFNFMmicxIrYe6FrXPDJU3fZkyO5+qUBFl5a4XyeSFMWImfq+QxN3XU/MveLHbk+tidV zG+twhrNyj9kNu8nRGdE62oQRKuuuIoCX42utbtdCUhZDUH9XnefSTB+ihVf+arOoVjd 4CrCacyHF7Se2bAauVThvcmCLqGSTABYP8Mu65AleuFZYsbxnSdHgEY6JtzEV4H20ZEw EkLQ== X-Gm-Message-State: AE9vXwOgoo7lNlqVZhi7588ty32vpzd1AH5lUo0oouhO6YmJud0947XEyMopBpHpikCfOw== X-Received: by 10.55.48.145 with SMTP id w139mr432436qkw.142.1472001591846; Tue, 23 Aug 2016 18:19:51 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id 48sm3316740qtu.39.2016.08.23.18.19.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Aug 2016 18:19:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160819171346.A5E32B80DC6@rfc-editor.org> Date: Tue, 23 Aug 2016 21:19:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> References: <20160819171346.A5E32B80DC6@rfc-editor.org> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 20:44:39 -0700 Cc: hello@florent-tatard.fr, sean+ietf@sn3rd.com, bodo@openssl.org, Kathleen Moriarty , chris@corriente.net, nelson@bolyard.com, vipul.gupta@sun.com Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 01:19:54 -0000 This looks correct, but I=E2=80=99d change the =E2=80=9Ctype=E2=80=9D to = editorial. Unless anybody disagrees with by next Monday, I=E2=80=99ll = ask Stephen to accept this. I=E2=80=99ve also submitted an issue in the 4492bis github repo to get = this fixed in the new draft. I=E2=80=99d submit a PR, but I=E2=80=99m = still digging out from being absent last week. spt > On Aug 19, 2016, at 13:13, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer = Security (TLS)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4492&eid=3D4783 >=20 > -------------------------------------- > Type: Technical > Reported by: Florent Tatard >=20 > Section: 5.7 >=20 > Original Text > ------------- > Actions of the sender: >=20 > The client selects an ephemeral ECDH public key corresponding to the > parameters it received from the server according to the ECKAS-DH1 > scheme from IEEE 1363 [6]. It conveys this information to the = client > in the ClientKeyExchange message using the format defined above. >=20 > Corrected Text > -------------- > Actions of the sender: >=20 > The client selects an ephemeral ECDH public key corresponding to the > parameters it received from the server according to the ECKAS-DH1 > scheme from IEEE 1363 [6]. It conveys this information to the = server > in the ClientKeyExchange message using the format defined above. >=20 > Notes > ----- > The client conveys data to the server, not itself. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4492 (draft-ietf-tls-ecc-12) > -------------------------------------- > Title : Elliptic Curve Cryptography (ECC) Cipher Suites = for Transport Layer Security (TLS) > Publication Date : May 2006 > Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, = B. Moeller > Category : INFORMATIONAL > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Tue Aug 23 21:08:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7916C12B029 for ; Tue, 23 Aug 2016 21:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hJHDrPcLrkg for ; Tue, 23 Aug 2016 21:08:44 -0700 (PDT) Received: from BLU004-OMC4S25.hotmail.com (blu004-omc4s25.hotmail.com [65.55.111.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8945912B017 for ; Tue, 23 Aug 2016 21:08:44 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com ([65.55.111.136]) by BLU004-OMC4S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 23 Aug 2016 21:08:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w7eVTTxeaHF4DEaT/eoNov8rN60Rt5Ci/fCoAwRU8eQ=; b=rirzHSglcVLNHQ/ccHEBBKkDZeQF2c8X/702x1/Yb6lcCYe5OhtX0rq03F6pnIddG/W3WPPUPVVBMqtu9kUQuFR+2pmhMM3i73d38ZkceKf3vjqz/lE8RTcUbJ6H17vQ4oGBbajqc91wIqTrUMQUbLucgLOQM9zddNHqGQGuQjW5ofSWDQBQ+eK7PziIT1N1Fjxs4ZkMWTIVyNUa+xEZ2IvBQFU+gG8Cf/vNcD/MySL7KK09dgRPXRXrRZpsrFbQtMcxM3MqHLHvs/a1P1rCED+dFyiZ+goKPsaDD0TGT1TbopwXiWialvb8yNi0h2PEvIGUTTHKa8wWNLNLVLbE0g== Received: from SN1NAM02FT007.eop-nam02.prod.protection.outlook.com (10.152.72.53) by SN1NAM02HT003.eop-nam02.prod.protection.outlook.com (10.152.73.16) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Wed, 24 Aug 2016 04:08:42 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.72.53) by SN1NAM02FT007.mail.protection.outlook.com (10.152.72.88) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Wed, 24 Aug 2016 04:08:41 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 04:08:40 +0000 From: Xiaoyin Liu To: Sean Turner , "" Thread-Topic: [TLS] [Technical Errata Reported] RFC4492 (4783) Thread-Index: AQHR+kcFTuLAAhdbwkCpcQn6uhu3paBXVqcAgAArol4= Date: Wed, 24 Aug 2016 04:08:40 +0000 Message-ID: References: <20160819171346.A5E32B80DC6@rfc-editor.org>, <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> In-Reply-To: <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.72.53) smtp.mailfrom=outlook.com; florent-tatard.fr; dkim=none (message not signed) header.d=none;florent-tatard.fr; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.72.53 as permitted sender) x-tmn: [352R6OLuyN+dbxzr2VP2txyYQfgE0+sz] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.72.53; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT003; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; SN1NAM02HT003; 6:uheUk2qqXFmciimzRkHHpLg5oMU4JgfZZ7e2pszwu3ZcEFlKZKv/n77JCIia+htZZFxN0fwD4FOImUYPHtET3WGlHw4gaSQSNHZCk3sXYm8blzGgF72zksW4uygTKuWTh3UleYkzHcHNhL7dg3SxIeAlK+H/NSpj03L8d2h0UdfgllgTG6m0uba+Kxco0H+iznL0SjHGrHsL9m8lN/hRzStXKKP1CVhLLvwFX2D4u5eQrOheRcSuC9V1122t0JAaP96ciD3xmA8ezQ8smPuBBWadHztJu1mevGrPtCAbb4wmS93R1dhI5PcHMU26k6gU; 5:RaokenvsWpRlvaqpdlIRVsX41dNdi5pHMbhV9HLJAKYN8qiGEQSPTpuCILOhqcQATe/tCe/KmV/nK0/F9u9u/Q2aww67PLkfY3STiOYlZ3OJxnb1TAsutaxu8GBBPrSOmgflauSmjZhUxb+1phPhwg==; 24:8pz2OGcOXi94+wV4N6knlOLt74LKCvDI/3Fn0kYA/yeljGHZ+oj9QghCs706410JG5fMO8IS40dwqSjQXdOZb65EuyrIUOS5i2sazg2Sp1g=; 7:QIXJkjT/G/VDDvdHkJ6dnPBRbHecMyfoXWKgKrR85Pn5D/e0QsKk7qhNGajUJm8X1vHDMoF75QsWY5eTOOuXYARLBzl62SaLYd+cXPosrEC950HFwQ9HPjLkT2sBTPmJJwihkw7uV7v0MVIpIeGBbokrzgHbj38mzV+yqwbTu+uBOE63SDa1C9ei8RjOxv4x3E5rOC+DTZfFuuuYSiVxAtXmxugx1mNO7LZ7l2ScNlqY0CJ4fOEdQEcxCdcGwtfj x-ms-office365-filtering-correlation-id: c8d0d86d-7921-436f-336a-08d3cbd454ab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1601125047); SRVR:SN1NAM02HT003; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM02HT003; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT003; x-forefront-prvs: 0044C17179 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB077818F8C3110170A5EA910EFFEA0CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 04:08:40.1541 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT003 X-OriginalArrivalTime: 24 Aug 2016 04:08:43.0759 (UTC) FILETIME=[343E27F0:01D1FDBD] Archived-At: Cc: "hello@florent-tatard.fr" , "sean+ietf@sn3rd.com" , "bodo@openssl.org" , Kathleen Moriarty , "chris@corriente.net" , "nelson@bolyard.com" , "vipul.gupta@sun.com" Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 04:08:47 -0000 --_000_CY1PR15MB077818F8C3110170A5EA910EFFEA0CY1PR15MB0778namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why is the type editorial? According to [1], an editorial errata is "a spel= ling, grammar, punctuation, or syntax error that does not affect the techni= cal meaning". Although the mistake in RFC4492 is clearly a typo, I think it= does affect the technical meaning. So I would prefer to leave the type as = technical. [1] https://www.rfc-editor.org/errata-definitions/ Best, Xiaoyin ________________________________ From: TLS on behalf of Sean Turner Sent: Tuesday, August 23, 2016 9:19 PM To: Cc: hello@florent-tatard.fr; sean+ietf@sn3rd.com; bodo@openssl.org; Kathlee= n Moriarty; chris@corriente.net; nelson@bolyard.com; vipul.gupta@sun.com Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) This looks correct, but I'd change the "type" to editorial. Unless anybody= disagrees with by next Monday, I'll ask Stephen to accept this. I've also submitted an issue in the 4492bis github repo to get this fixed i= n the new draft. I'd submit a PR, but I'm still digging out from being abs= ent last week. spt > On Aug 19, 2016, at 13:13, RFC Errata System = wrote: > > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Secu= rity (TLS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4492&eid=3D4783 > > -------------------------------------- > Type: Technical > Reported by: Florent Tatard > > Section: 5.7 > > Original Text > ------------- > Actions of the sender: > > The client selects an ephemeral ECDH public key corresponding to the > parameters it received from the server according to the ECKAS-DH1 > scheme from IEEE 1363 [6]. It conveys this information to the client > in the ClientKeyExchange message using the format defined above. > > Corrected Text > -------------- > Actions of the sender: > > The client selects an ephemeral ECDH public key corresponding to the > parameters it received from the server according to the ECKAS-DH1 > scheme from IEEE 1363 [6]. It conveys this information to the server > in the ClientKeyExchange message using the format defined above. > > Notes > ----- > The client conveys data to the server, not itself. > > 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. > > -------------------------------------- > RFC4492 (draft-ietf-tls-ecc-12) > -------------------------------------- > Title : Elliptic Curve Cryptography (ECC) Cipher Suites for= Transport Layer Security (TLS) > Publication Date : May 2006 > Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. = Moeller > Category : INFORMATIONAL > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CY1PR15MB077818F8C3110170A5EA910EFFEA0CY1PR15MB0778namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Why is the type editorial? According to [1], an editorial errata is &quo= t;a spelling, grammar, punctuation, or syntax error that does not aff= ect the technical meaning". Although the mistake in R= FC4492 is clearly a typo, I think it does affect the technical meaning. So I would prefer to leave the type as technical.


[1] https://www.rfc-editor.org/errata-definitions/

Best,

Xiaoyin



From: TLS <tls-bounc= es@ietf.org> on behalf of Sean Turner <sean@sn3rd.com>
Sent: Tuesday, August 23, 2016 9:19 PM
To: <tls@ietf.org>
Cc: hello@florent-tatard.fr; sean+ietf@sn3rd.com; bodo@openssl.o= rg; Kathleen Moriarty; chris@corriente.net; nelson@bolyard.com; vipul.gupta= @sun.com
Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783)
 
This looks correct, but I’d change the ̶= 0;type” to editorial.  Unless anybody disagrees with by next Mon= day, I’ll ask Stephen to accept this.

I’ve also submitted an issue in the 4492bis github repo to get this f= ixed in the new draft.  I’d submit a PR, but I’m still dig= ging out from being absent last week.

spt

> On Aug 19, 2016, at 13:13, RFC Errata System <rfc-editor@rfc-editor= .org> wrote:
>
> The following errata report has been submitted for RFC4492,
> "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport La= yer Security (TLS)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4492&eid=3D4783 >
> --------------------------------------
> Type: Technical
> Reported by: Florent Tatard <hello@florent-tatard.fr>
>
> Section: 5.7
>
> Original Text
> -------------
> Actions of the sender:
>
>   The client selects an ephemeral ECDH public key correspond= ing to the
>   parameters it received from the server according to the EC= KAS-DH1
>   scheme from IEEE 1363 [6].  It conveys this informati= on to the client
>   in the ClientKeyExchange message using the format defined = above.
>
> Corrected Text
> --------------
> Actions of the sender:
>
>   The client selects an ephemeral ECDH public key correspond= ing to the
>   parameters it received from the server according to the EC= KAS-DH1
>   scheme from IEEE 1363 [6].  It conveys this informati= on to the server
>   in the ClientKeyExchange message using the format defined = above.
>
> Notes
> -----
> The client conveys data to the server, not itself.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC4492 (draft-ietf-tls-ecc-12)
> --------------------------------------
> Title           = ;    : Elliptic Curve Cryptography (ECC) Cipher Suites for T= ransport Layer Security (TLS)
> Publication Date    : May 2006
> Author(s)           = : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller
> Category          &n= bsp; : INFORMATIONAL
> Source          &nbs= p;   : Transport Layer Security
> Area           =      : Security
> Stream          &nbs= p;   : IETF
> Verifying Party     : IESG
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
--_000_CY1PR15MB077818F8C3110170A5EA910EFFEA0CY1PR15MB0778namp_-- From nobody Tue Aug 23 22:45:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B529212D751 for ; Tue, 23 Aug 2016 22:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFDbQKbM2GQO for ; Tue, 23 Aug 2016 22:45:09 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 36CDA12D6AF for ; Tue, 23 Aug 2016 22:45:09 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id n128so16456446ith.1 for ; Tue, 23 Aug 2016 22:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=80278W1aZRuxcYS/JL05ggpHDUVjQTAO9Cz8rt1NmKg=; b=t/uAPGMkyxvkvMDFykPfGEawqXUAi55I3oItRC0i3ztpV/qzpbieCJU8BKJG5MQOs2 8H9n7/GIYOqZ7K6IV5U88FyIqmR/+HMR4It7QoWGgVvkfuT0geg/j5KlaRBfdnbtSGCJ ZAL1YsNfrnwCb3s4v8k3/MdWeRGrapL6RwzbxEXTwBo089tNl60Nsg3yXI5dhKurkILW AqoKM1n2Q1IUYSHFXoH5xsZx5mQGivUmwbKUL4JcfCkyDlcpBjc2IRw+iJurouGAQGES obP0EqZIW81Cz0udJ7jmfJgr9WerLLt47q/h55IyowIPAWfdYlIGDbticnQcB5snkA/e vv7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=80278W1aZRuxcYS/JL05ggpHDUVjQTAO9Cz8rt1NmKg=; b=LfCEjTW2smUjSCrf4cuNfBJEv4Gie+ZaHS3THwpDZrJ3nnM10hVyvrxNR0V8DwkI1K LHni0Iz89UdS5ZYl31YysWcZZSnxwtXyliny/hT1KqlGaIDm+gn7u0nyvAgqYkVlQBRI kGdWd/oIJR4b1eR1hIClE6vgpXDQe/r/+StioK0cMcri85ekFnRmxNj95KNWs9y7p/1Y uCbcUa8Fxlk/IYT7mpuj+eZ/0fiToBjwPFbXcULdC6O15gkUgmzIRK0rMGp/J1jSxF0X 5JTngQPHW4BhAWZmRC32Bvg88PJKbg9pXyglC/r6FV4fnoJJFN/ubhZhEMa3cl7hp2WM R1bQ== X-Gm-Message-State: AEkoousPn2SoxxLwdbaG8EhCOCchLKuLFS8H1J152uOytozRdGql2ebH3LhKStmLqaFehxOVUXmsbUb4rpaVnw== X-Received: by 10.36.2.137 with SMTP id 131mr31212911itu.30.1472017508476; Tue, 23 Aug 2016 22:45:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.240 with HTTP; Tue, 23 Aug 2016 22:45:07 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> From: Judson Wilson Date: Tue, 23 Aug 2016 22:45:07 -0700 Message-ID: To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a1144756ab22f1b053acac89a Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 05:45:13 -0000 --001a1144756ab22f1b053acac89a Content-Type: text/plain; charset=UTF-8 > > > For the use cases you mentioned Keith, they seem to be specific to > application triggered key updates, i.e. key updates do not mean anything to > the TLS layer apart from I got a key update and I must change keys. The > fact that other side has thrown away it's key is only meaningful to the > higher layer protocol. I imagine protocols like HTTP would not add these > semantics, and these semantics would be added to very specific IoT > protocols? Would the scope of the auditor be defined as a part of that > protocol, or does it need to be defined as a part of TLS? > > It makes more sense to have the TLS layer disseminate information about which keys are in use, rather than have the higher layer try to infer it. Conceivably, either endpoint can cooperate with a user to by giving the user the keys that are no longer in use on the channel. (Endpoints can already do this, but without any guarantee that the keys are not in use.) With the very small piggyback that Keith proposed, a client application could get an assurance which keys are no longer in use, without any changes on the server side. TLS termination devices, load balancers, reverse proxies, and HTTP servers would all be compatible without any further changes - the format on the wire would be unchanged. I also believe that we all agree that adding a full auditing spec is far beyond the scope of TLS. However, with this small change to KeyUpdate, there might be opportunities to add such a feature to IoT devices without having to re-engineer the front end of a cloud application - the wire compatibility is a really nice feature in this regard. An IoT device could possibly be compliant with some future auditing spec while using plain-old HTTP and TLS 1.3 in the cloud. If key update is an application triggered mechanism, does the generation > identifier need to be an integer to be understood by the TLS layer or could > it also be an opaque identifier sent by the application. It would be much > simpler not to have to deal with the requirements of consistency at the TLS > layer and would make the API simpler. I don't think this introduces any kind of consistency issues at the TLS layer. The receiver simply needs to keep count of the receive key generation, and put this number (or even a numerically smaller one) in any subsequent outgoing KeyUpdate. It would also be sufficient to transmit a boolean indicating whether the KeyUpdate message is an initiating message, or a response message (I am omitting some details), but that would not work well with mitigating this multiple KeyUpdate backlog issue which is the original topic of this thread. On Tue, Aug 23, 2016 at 11:47 AM, Subodh Iyengar wrote: > For people that currently use keyupdates or who are planning to use key > updates, which layer are you planning to trigger a key update? Would the > TLS implementation itself trigger the update or would the application > trigger it? For renegotation, I believe it was mostly triggered by the > application. > > For the use cases you mentioned Keith, they seem to be specific to > application triggered key updates, i.e. key updates do not mean anything to > the TLS layer apart from I got a key update and I must change keys. The > fact that other side has thrown away it's key is only meaningful to the > higher layer protocol. I imagine protocols like HTTP would not add these > semantics, and these semantics would be added to very specific IoT > protocols? Would the scope of the auditor be defined as a part of that > protocol, or does it need to be defined as a part of TLS? > > If key update is an application triggered mechanism, does the generation > identifier need to be an integer to be understood by the TLS layer or could > it also be an opaque identifier sent by the application. It would be much > simpler not to have to deal with the requirements of consistency at the TLS > layer and would make the API simpler. > > Subodh > ________________________________________ > From: TLS [tls-bounces@ietf.org] on behalf of Keith Winstein [ > keithw@cs.stanford.edu] > Sent: Friday, August 19, 2016 8:40 PM > To: Stephen Farrell > Cc: Adam Langley; tls@ietf.org > Subject: Re: [TLS] KeyUpdate and unbounded write obligations > > On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell > wrote: > > > > And for me, the dodgiest, by far. The scope for an "auditor" > > (what is that?) actually being an attacker is IMO way too > > high to consider standardising that kind of feature and any > > idea that it'd involve informed consent of someone seems to > > me fictional. > > I appreciate the sensitivity of this issue to the WG. My read of your > email is that there's a concern that by standardizing a protocol > mechanism that allows a node to learn when its own KeyUpdate has > happened, the WG would imply approval of features that permit > the bad kind of eavesdropping. Here's why I don't think that's the case: > > Our PR is for a piggyback integer field to provide security property > P3: "An implementation can learn that its request to rekey its > outgoing traffic has been read by the other side." > > KeyUpdate is an *instruction* to the other side: "please update my key > in a forward-secure manner." We think some implementations will want > to know that the instruction has been carried out. And there's an easy > opportunity to do that here as a piggyback, without any extra protocol > messages. > > A node will naturally care more about forward secrecy, and > confirmation of a forward-secure ratcheting event, the more it has > reason to suspect the keys might later be exposed to a third party. In > Berlin, I described three escalating cases: the (1) node going to > sleep, (2) node closing a connection without a mechanism for secure > bidi close, and (3) node that itself intends to release keys to a > read-only auditor after a ratchet is complete. > > By "read-only auditor," we mean a curious person or security > researcher who owns an IoT device and wants to know what the heck it > is sending out of their house, where the device doesn't want to allow > its owner to add trusted certificates for an MITM. (This describes > most such devices today.) > > Obviously I think it's valuable to make this mechanism available for > IoT device manufacturers. Having talked to several manufacturers, I'm > cautiously optimistic that some would use this. But the WG doesn't > have to take a position on this. These use cases are up to > implementers. There's nothing stopping an implementer today from > releasing session keys, or allowing complete MITM, as is the case in > the browser context with user- or admin-installed root CA > certificates. The TLS WG hasn't opined on these either. > > To restate: Property P3 allows a node to learn that its KeyUpdate > instruction has actually happened, which in our view is useful and a > strict benefit over the status quo. It's also orthogonal to the issue > of unbounded write obligations raised in this thread. > > -Keith > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_mailman_listinfo_tls&d=DQICAg&c=5VD0RTtNlTh3ycd41b3MUw&r= > h3Ju9EBS7mHtwg-wAyN7fQ&m=dPWRCHpTfdtxfXYBMZF__UyOa7wszKFnA6criwmMDHI&s= > E7sRstn6vNQHPiX3CXAa6BbWSWtMW7VKtN4f3yblZ5U&e= > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1144756ab22f1b053acac89a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

For = the use cases you mentioned Keith, they seem to be specific to application = triggered key updates, i.e. key updates do not mean anything to the TLS lay= er apart from I got a key update and I must change keys. The fact that othe= r side has thrown away it's key is only meaningful to the higher layer = protocol. I imagine protocols like HTTP would not add these semantics, and = these semantics would be added to very specific IoT protocols? Would the sc= ope of the auditor be defined as a part of that protocol, or does it need t= o be defined as a part of TLS?


It m= akes more sense to have the TLS layer disseminate information about which k= eys are in use, rather than have the higher layer try to infer it.=C2=A0 Co= nceivably, either endpoint can cooperate with a user to by giving the user = the keys that are no longer in use on the channel. (Endpoints can already d= o this, but without any guarantee that the keys are not in use.) With the v= ery small piggyback that Keith proposed, a client application could get an = assurance which keys are no longer in use, without any changes on the serve= r side. TLS termination devices, load balancers, reverse proxies, and HTTP = servers would all be compatible without any further changes - the format on= the wire would be unchanged.=C2=A0
=C2=A0
I also belie= ve that we all agree that adding a full auditing spec is far beyond the sco= pe of TLS. However, with this small change to KeyUpdate, there might be opp= ortunities to add such a feature to IoT devices without having to re-engine= er the front end of a cloud application - the wire compatibility is a reall= y nice feature in this regard. An IoT device could possibly be compliant wi= th some future auditing spec while using plain-old HTTP and TLS 1.3 in the = cloud.


I don't think this introduces a= ny kind of consistency issues at the TLS layer.=C2=A0 The receiver simply n= eeds to keep count of the receive key generation, and put this number (or e= ven a numerically smaller one) in any subsequent outgoing KeyUpdate.
<= div class=3D"gmail_extra">
It would als= o be sufficient to transmit a boolean indicating whether the KeyUpdate mess= age is an initiating message, or a response message (I am omitting some det= ails), but that would not work well with mitigating this multiple KeyUpdate= backlog issue which is the original topic of this thread.


On Tue, Aug 23, 2016 at 11:47 AM, Subodh Iyengar <subodh@fb.com&= gt; wrote:
For = people that currently use keyupdates or who are planning to use key updates= , which layer are you planning to trigger a key update? Would the TLS imple= mentation itself trigger the update or would the application trigger it? Fo= r renegotation, I believe it was mostly triggered by the application.

For the use cases you mentioned Keith, they seem to be specific to applicat= ion triggered key updates, i.e. key updates do not mean anything to the TLS= layer apart from I got a key update and I must change keys. The fact that = other side has thrown away it's key is only meaningful to the higher la= yer protocol. I imagine protocols like HTTP would not add these semantics, = and these semantics would be added to very specific IoT protocols? Would th= e scope of the auditor be defined as a part of that protocol, or does it ne= ed to be defined as a part of TLS?

If key update is an application triggered mechanism, does the generation id= entifier need to be an integer to be understood by the TLS layer or could i= t also be an opaque identifier sent by the application. It would be much si= mpler not to have to deal with the requirements of consistency at the TLS l= ayer and would make the API simpler.

Subodh
________________________________________
From: TLS [tls-bounces@ietf.org= ] on behalf of Keith Winstein [ke= ithw@cs.stanford.edu]
Sent: Friday, August 19, 2016 8:40 PM
To: Stephen Farrell
Cc: Adam Langley; tls@ietf.org
Subject: Re: [TLS] KeyUpdate and unbounded write obligatio= ns

On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farr= ell
<stephen.farrell@cs.tcd.ie<= /a>> wrote:
>
> And for me, the dodgiest, by far. The scope for an "auditor"=
> (what is that?) actually being an attacker is IMO way too
> high to consider standardising that kind of feature and any
> idea that it'd involve informed consent of someone seems to
> me fictional.

I appreciate the sensitivity of this issue to the WG. My read of your
email is that there's a concern that by standardizing a protocol
mechanism that allows a node to learn when its own KeyUpdate has
happened, the WG would imply approval of features that permit
the bad kind of eavesdropping. Here's why I don't think that's = the case:

Our PR is for a piggyback integer field to provide security property
P3: "An implementation can learn that its request to rekey its
outgoing traffic has been read by the other side."

KeyUpdate is an *instruction* to the other side: "please update my key=
in a forward-secure manner." We think some implementations will want to know that the instruction has been carried out. And there's an easy<= br> opportunity to do that here as a piggyback, without any extra protocol
messages.

A node will naturally care more about forward secrecy, and
confirmation of a forward-secure ratcheting event, the more it has
reason to suspect the keys might later be exposed to a third party. In
Berlin, I described three escalating cases: the (1) node going to
sleep, (2) node closing a connection without a mechanism for secure
bidi close, and (3) node that itself intends to release keys to a
read-only auditor after a ratchet is complete.

By "read-only auditor," we mean a curious person or security
researcher who owns an IoT device and wants to know what the heck it
is sending out of their house, where the device doesn't want to allow its owner to add trusted certificates for an MITM. (This describes
most such devices today.)

Obviously I think it's valuable to make this mechanism available for IoT device manufacturers. Having talked to several manufacturers, I'm cautiously optimistic that some would use this. But the WG doesn't
have to take a position on this. These use cases are up to
implementers. There's nothing stopping an implementer today from
releasing session keys, or allowing complete MITM, as is the case in
the browser context with user- or admin-installed root CA
certificates. The TLS WG hasn't opined on these either.

To restate: Property P3 allows a node to learn that its KeyUpdate
instruction has actually happened, which in our view is useful and a
strict benefit over the status quo. It's also orthogonal to the issue of unbounded write obligations raised in this thread.

-Keith

_______________________________________________
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_tls&= d=3DDQICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-= wAyN7fQ&m=3DdPWRCHpTfdtxfXYBMZF__UyOa7wszKFnA6criwmMDHI&s= =3DE7sRstn6vNQHPiX3CXAa6BbWSWtMW7VKtN4f3yblZ5U&e=3D

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

--001a1144756ab22f1b053acac89a-- From nobody Wed Aug 24 07:40:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3023212D949 for ; Wed, 24 Aug 2016 07:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42kw0rRhBC1V for ; Wed, 24 Aug 2016 07:40:38 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A8312DD98 for ; Wed, 24 Aug 2016 07:38:11 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 93so8242697qtg.2 for ; Wed, 24 Aug 2016 07:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WpZdwQXnnrcZCtLPUniP4jN533Vp5iXKRmMpowEVsz0=; b=Q7XgyP6qUFGEG1e7ssL22NUv0D0ivR4EaPd+NYzAq47fIxGwUKLbM3t6ZZYcSSpHy2 v9jZGk/nLiX0pLq0Pw4XJ2FkpsCCDTne4S+NgSV2G4vnbWoCT7LIXr+7tRjAnMzx+bFK mrP96+YN0KOyf1uE4g+O+QktMqg53X6OaToFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WpZdwQXnnrcZCtLPUniP4jN533Vp5iXKRmMpowEVsz0=; b=F2k1pEYbHmjwNs39YDxvy52Z3stV92DlaGlmOCNwDZwH466Xi2JwNcudOLdrxvSVqE oBjBf2Z00wZqAzrn6T5myckeYI33Z74qx896PPAs34zN9EkvyoIX+o0fgqr4uix++ETP wdJnQpaM/P8wq+3GRjCsDkJj+SHQd/BvIhDldO1FcoceGV4exj9t7q2lZr5Yj9kY2dGG 5IujGl4M/nGpZF56egkwkS29qAPhvYQ72Yae8ERhre1ybq0M9kVN4GS34hspCUxwdMCx TdBQKsc+2/6PFzuOLjcMO1JbzoFjc4xvPQlxsUmSjiL+TbnUJ6KI9j2hsjxUneDqmuir 2Y5w== X-Gm-Message-State: AE9vXwNk/I/ymekQ31g/ilzE7XUUqiJeon5s31PqMekGRK5BI8NPKtON1IknOhvJaHKQpg== X-Received: by 10.200.49.203 with SMTP id i11mr3861129qte.40.1472049490644; Wed, 24 Aug 2016 07:38:10 -0700 (PDT) Received: from [172.16.0.172] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id k20sm4836103qkl.2.2016.08.24.07.38.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 07:38:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-65C4328D-88DC-460B-87FE-A3AFB68DE0CD Mime-Version: 1.0 (1.0) From: Sean Turner X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Wed, 24 Aug 2016 10:38:05 -0400 Content-Transfer-Encoding: 7bit Message-Id: <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> To: Xiaoyin Liu Archived-At: Cc: "hello@florent-tatard.fr" , "sean+ietf@sn3rd.com" , "bodo@openssl.org" , "chris@corriente.net" , Kathleen Moriarty , "nelson@bolyard.com" , "" , "vipul.gupta@sun.com" Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 14:40:41 -0000 --Apple-Mail-65C4328D-88DC-460B-87FE-A3AFB68DE0CD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think it ought to editorial because I don't think an implementer would hav= e gotten it wrong; it's been like that for a decade and it's in a paragraph= talking about what the client returns in an CKE. The important part here i= s that we get it fixed. Yaron already has it fixed in the 4492bis draft. spt > On Aug 24, 2016, at 00:08, Xiaoyin Liu wrote: >=20 > Why is the type editorial? According to [1], an editorial errata is "a spe= lling, grammar, punctuation, or syntax error that does not affect the techni= cal meaning". Although the mistake in RFC4492 is clearly a typo, I think it d= oes affect the technical meaning. So I would prefer to leave the type as tec= hnical. >=20 >=20 > [1] https://www.rfc-editor.org/errata-definitions/ >=20 > Best, >=20 > Xiaoyin >=20 >=20 > From: TLS on behalf of Sean Turner = > Sent: Tuesday, August 23, 2016 9:19 PM > To: > Cc: hello@florent-tatard.fr; sean+ietf@sn3rd.com; bodo@openssl.org; Kathle= en Moriarty; chris@corriente.net; nelson@bolyard.com; vipul.gupta@sun.com > Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) > =20 > This looks correct, but I=E2=80=99d change the =E2=80=9Ctype=E2=80=9D to e= ditorial. Unless anybody disagrees with by next Monday, I=E2=80=99ll ask St= ephen to accept this. >=20 > I=E2=80=99ve also submitted an issue in the 4492bis github repo to get thi= s fixed in the new draft. I=E2=80=99d submit a PR, but I=E2=80=99m still di= gging out from being absent last week. >=20 > spt >=20 > > On Aug 19, 2016, at 13:13, RFC Errata System = wrote: > >=20 > > The following errata report has been submitted for RFC4492, > > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Sec= urity (TLS)". > >=20 > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4492&eid=3D4783 > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: Florent Tatard > >=20 > > Section: 5.7 > >=20 > > Original Text > > ------------- > > Actions of the sender: > >=20 > > The client selects an ephemeral ECDH public key corresponding to the > > parameters it received from the server according to the ECKAS-DH1 > > scheme from IEEE 1363 [6]. It conveys this information to the client > > in the ClientKeyExchange message using the format defined above. > >=20 > > Corrected Text > > -------------- > > Actions of the sender: > >=20 > > The client selects an ephemeral ECDH public key corresponding to the > > parameters it received from the server according to the ECKAS-DH1 > > scheme from IEEE 1363 [6]. It conveys this information to the server > > in the ClientKeyExchange message using the format defined above. > >=20 > > Notes > > ----- > > The client conveys data to the server, not itself. > >=20 > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary.=20 > >=20 > > -------------------------------------- > > RFC4492 (draft-ietf-tls-ecc-12) > > -------------------------------------- > > Title : Elliptic Curve Cryptography (ECC) Cipher Suites fo= r Transport Layer Security (TLS) > > Publication Date : May 2006 > > Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B.= Moeller > > Category : INFORMATIONAL > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-65C4328D-88DC-460B-87FE-A3AFB68DE0CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think it ought to editorial because I= don't think an implementer would have gotten it wrong; it's  been like= that for a decade and it's in a paragraph talking about what the client ret= urns in an CKE.  The important part here is that we get it fixed.  = ;Yaron already has it fixed in the 4492bis draft.

s= pt

On Aug 24, 2016, at 00:08, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:

Why is the type editorial? According to [1], an editorial errata is "a spelling, grammar, punctuation, or syntax error that does not affect the= technical meaning". Although the mistake in RFC4492 i= s clearly a typo, I think it does affect the technical meaning. So I would prefer to leave the type as technical.


[1] https://www.rfc-editor.org/errata-definitions/

Best,

Xiaoyin



From: TLS <tls-bounces@ietf.org> on behalf of Sean T= urner <sean@sn3rd.com>
Sent: Tuesday, August 23, 2016 9:19 PM
To: <tls@ietf.org>
Cc: hello@florent-tatard.f= r; sean+ietf@sn3rd.com; bodo@openssl.org; Kathleen Moriarty; chris@corriente.net; nelson@bolyard.com; vipul.gupta@sun.com
Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783)
 
This looks correct, but I=E2=80=99d change the =E2=80= =9Ctype=E2=80=9D to editorial.  Unless anybody disagrees with by next M= onday, I=E2=80=99ll ask Stephen to accept this.

I=E2=80=99ve also submitted an issue in the 4492bis github repo to get this f= ixed in the new draft.  I=E2=80=99d submit a PR, but I=E2=80=99m still d= igging out from being absent last week.

spt

> On Aug 19, 2016, at 13:13, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC4492,
> "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Se= curity (TLS)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4492&eid=3D4783 >
> --------------------------------------
> Type: Technical
> Reported by: Florent Tatard <hello@florent-tatard.fr>
>
> Section: 5.7
>
> Original Text
> -------------
> Actions of the sender:
>
>   The client selects an ephemeral ECDH public key correspondi= ng to the
>   parameters it received from the server according to the ECK= AS-DH1
>   scheme from IEEE 1363 [6].  It conveys this informatio= n to the client
>   in the ClientKeyExchange message using the format defined a= bove.
>
> Corrected Text
> --------------
> Actions of the sender:
>
>   The client selects an ephemeral ECDH public key correspondi= ng to the
>   parameters it received from the server according to the ECK= AS-DH1
>   scheme from IEEE 1363 [6].  It conveys this informatio= n to the server
>   in the ClientKeyExchange message using the format defined a= bove.
>
> Notes
> -----
> The client conveys data to the server, not itself.
>
> 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.
= >
> --------------------------------------
> RFC4492 (draft-ietf-tls-ecc-12)
> --------------------------------------
> Title           =     : Elliptic Curve Cryptography (ECC) Cipher Suites for Tra= nsport Layer Security (TLS)
> Publication Date    : May 2006
> Author(s)           := S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller
> Category          &nb= sp; : INFORMATIONAL
> Source           = ;   : Transport Layer Security
> Area           &= nbsp;    : Security
> Stream           = ;   : IETF
> Verifying Party     : IESG
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/m= ailman/listinfo/tls
= --Apple-Mail-65C4328D-88DC-460B-87FE-A3AFB68DE0CD-- From bodo@openssl.org Wed Aug 24 08:02:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5489612D82C for ; Wed, 24 Aug 2016 08:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4w0w256DkBF for ; Wed, 24 Aug 2016 08:02:30 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB9312D7F3 for ; Wed, 24 Aug 2016 07:51:31 -0700 (PDT) Received: from mail-qk0-f173.google.com ([209.85.220.173]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0M7bqp-1bFf5K1RQd-00xHjS for ; Wed, 24 Aug 2016 16:51:29 +0200 Received: by mail-qk0-f173.google.com with SMTP id v123so17042363qkh.2 for ; Wed, 24 Aug 2016 07:51:28 -0700 (PDT) X-Gm-Message-State: AE9vXwM3P0GtPoO9/xW55+uoOBWR9CBFW1amSFELTZMPbtVNLCNhXtYLFjkemUKnjng+eji6aup1WEXxjzbaZw== X-Received: by 10.55.102.75 with SMTP id a72mr3917589qkc.20.1472050288042; Wed, 24 Aug 2016 07:51:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.41.6 with HTTP; Wed, 24 Aug 2016 07:51:27 -0700 (PDT) In-Reply-To: <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> From: Bodo Moeller Date: Wed, 24 Aug 2016 16:51:27 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=94eb2c0580d082af30053ad26ab9 X-Provags-ID: V03:K0:ZLsN0+t31Be3HpxZWrWTY+LmUfpWnPjdZBu6Z1wACyXFfW7dFeS RFGVrZ57Bm9/xMMi0IWDbLTnxZ0uNkvqj0xpH+mO+mSLsPEmhqFKlawedn6Naa4FGeTJPy3 of6XPTSG8PD0v1oNj9KY7k3d4uzDVXSreEAGQBRvF7CvsYE/tzFjnGGIEp5UzuTHz7Ecaa8 aa++dYMitFmwKn1fotHUg== X-UI-Out-Filterresults: notjunk:1;V01:K0:VvuKUT7OROQ=:QRbj3vmnJ4zis50ccywjOb /RkjXo6tSkLV6+fmrhHVbrMec+s41Es7Jp+FXnLwHaeOSys3+a+F3Ka5s6ukFvVIUMRsTzWzj UKEj5z6xkjMD8tC/pGHACVK89ROnWP3pgEqobkl7s1opOJeMgoeroe5CvvpdZFhP3KEhIu8dW 7VdX36zeniuox7RnGy4NUyY+s/Q4qKj7pPIT6NEk7ZqVhH5+iquh7XCvrWLxEQD6JmZe43WHp fAv/51+5Vn1xZnk9zW9QGDExlAZ+d8RS9r0pB9yy8iDWRdjpmeeYjjxsHtI+lx1CkfdwuNMhM kxUelTnp5UxYsEwQ+cfznA6HxsZtYCipqCRQANgaBBph+VBIk45T8LPo7NZxnAn4OOTaA3HT/ nhxGJDxkWzBev6a4R8w9WDmfTtPG5ftkDfN+OTD2nBk9nfA9tnoaqfEudES8d1rRdB4HlVVEs QmuUYF0ZrW9OmRxOqxIqQQ3Z7B+RE0KRNBtBi8h74R3IJdRXOn/YvnkgKo79N+SXafsx5r/iY fqJnUBjND/IEh5vQw8DLi+qY8KqeAJbmcMw9dDU5z5phO1SwzKuQY/4TdEQG9OsowVeMTKOyA hvSHr96mC2ic7/yDrqfoQTN98zFGHCX3XtLCv+v072lB/1il6wJ+HCS3OYY8IArLeLcENx1xp nz6bPCxctDJOE1I1SJTLK3BdPK4w/Tzyq1yFH0cqCArdRwb3U3vphOgpz0N/tPzqx4DFK/SxC FzxRiu2ovbUTveyv Archived-At: Cc: "hello@florent-tatard.fr" , "sean+ietf@sn3rd.com" , "chris@corriente.net" , Kathleen Moriarty , "nelson@bolyard.com" , "" , "vipul.gupta@sun.com" Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 15:42:48 -0000 --94eb2c0580d082af30053ad26ab9 Content-Type: text/plain; charset=UTF-8 Sean Turner : > I think it ought to editorial because I don't think an implementer would > have gotten it wrong; > It's also not strictly technically wrong. The client TLS implementation hands the ClientKeyExchange message to the component of the client that actually sends something to the server, and in that step, the client indeed "conveys [...] information to the client in the ClientKeyExchange message": that's certainly not something that implementors need to be told about, and it's not what the authors of the specification meant to tell implementors, but it's still correct. (It's also not strictly necessary to tell the reader here that the ClientKeyExchange message will be sent to the server -- it's not as if this element of the protocol would be underspecified if we didn't have this information here.) So, I certainly think that this really is a purely editorial error. Bodo --94eb2c0580d082af30053ad26ab9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sean= Turner <sean@sn3rd.com>:
I think it ought to editorial becaus= e I don't think an implementer would have gotten it wrong;
<= /blockquote>

It's also not strictly technically wron= g. The client TLS implementation hands the=C2=A0ClientKeyExchange message t= o the component of the client that actually sends something to the server, = and in that step, the client indeed "conveys [...] information to the = client in the ClientKeyExchange message": that's certainly not som= ething that implementors need to be told about, and it's not what the a= uthors of the specification meant to tell implementors, but it's still = correct. (It's also not strictly necessary to tell the reader here that= the ClientKeyExchange message will be sent to the server -- it's not a= s if this element of the protocol would be underspecified if we didn't = have this information here.)

So, I certainly think= that this really is a purely editorial error.

Bod= o

--94eb2c0580d082af30053ad26ab9-- From nobody Wed Aug 24 08:52:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A1912DDE0 for ; Wed, 24 Aug 2016 08:52: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNexy4mdRmMa for ; Wed, 24 Aug 2016 08:52:49 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 267FE12DF46 for ; Wed, 24 Aug 2016 08:47:05 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 97so35301460uav.3 for ; Wed, 24 Aug 2016 08:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XZwU9aPtiP04Ib5hJvlv7cV7AHNzbxn/5RxxRSlQpCU=; b=lMurxF8lVvUvo67A76FfJ6lenl/tpm32bZb9CRKU2WkhrO34yQKJ2rTEZTrXbF02zh e3Y11TRLvOpjwCpK5FUmSEjdJkM6WDZyAGnPt0IijhkTgewaaIoHKGsarUGu8Bwu78xJ SVXMSUMuTo8OGpVHLBUBVf8GvE/0hMGeBIb1bRbJpOh21NMv1kS1BJ+BIky0AMhQ80Kf vf92kszPXAkI54srOfEy+/9ZWy5Ddy62f6dKQLedVPmg1Hoer79cJwyD0soQtaMok426 wtEi+tHzZcL0VeKBH/1IvFgIN76UHGncBmddwT+3FShCm3mCpjv9Q60G97f3+ISKhrbC cSdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XZwU9aPtiP04Ib5hJvlv7cV7AHNzbxn/5RxxRSlQpCU=; b=igPuU62ibSKYOQvzBbMCSdJYFpVih7B0txluFpvqcH9nM0Anqd+YHpYYr9IgpoGET2 v0dSqecgZ0kmHpfqeIxhYDNr7hJ9FIx7ZqB1q7zw6mA8QuMIkvqGp+AkXkiMb8byr7U1 4tLc19+/PYUwtTn9TYb6+Gf/igItDqcI86yj7qzuXQBwZbG/GHG8s9PlVfkwAPQNhaRX s05q3gDiwFtpOU6Q7fs05voSQUPoOBdhC97FnNRtgsJr3ilRh0Zo7dqbCeINzY8s9nQy CrbEqN06Z/XO94OEUb6b4Eq4qwnvF27m4b+6BvTEdtQZYLXDN7M5ykeIu6ehYh4Tg0dQ tJDg== X-Gm-Message-State: AEkoouvaxe1qahO7xh+rOV7/7vHhyRDT/i5ABqPaiUT3Qxug/P7d6OH3eYVdLNMnQpVD/mn2Lsixk6lx5ggTyw== X-Received: by 10.31.0.133 with SMTP id 127mr1733431vka.57.1472053624141; Wed, 24 Aug 2016 08:47:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Wed, 24 Aug 2016 08:47:03 -0700 (PDT) In-Reply-To: References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> From: Watson Ladd Date: Wed, 24 Aug 2016 08:47:03 -0700 Message-ID: To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "hello@florent-tatard.fr" , "sean+ietf@sn3rd.com" , "chris@corriente.net" , Kathleen Moriarty , "nelson@bolyard.com" , "" , "vipul.gupta@sun.com" Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 15:52:51 -0000 On Wed, Aug 24, 2016 at 7:51 AM, Bodo Moeller wrote: > Sean Turner : >> >> I think it ought to editorial because I don't think an implementer would >> have gotten it wrong; > > > It's also not strictly technically wrong. The client TLS implementation > hands the ClientKeyExchange message to the component of the client that > actually sends something to the server, and in that step, the client indeed > "conveys [...] information to the client in the ClientKeyExchange message": > that's certainly not something that implementors need to be told about, and > it's not what the authors of the specification meant to tell implementors, > but it's still correct. (It's also not strictly necessary to tell the reader > here that the ClientKeyExchange message will be sent to the server -- it's > not as if this element of the protocol would be underspecified if we didn't > have this information here.) No, this is wrong. There is a client and there is a server, and whatever internal arrangements are made are epiphenominal from the perspective of this standard. I doubt anyone was confused by what it said, but either way it needs to get fixed, and our trichotomizing is not helping with this. > > So, I certainly think that this really is a purely editorial error. > > Bodo > > > _______________________________________________ > 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 Aug 24 09:32:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D4B12D51D for ; Wed, 24 Aug 2016 09:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7oNhcqMdH9x for ; Wed, 24 Aug 2016 09:32:55 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150D612D513 for ; Wed, 24 Aug 2016 09:32:54 -0700 (PDT) Received: from mail-qk0-f182.google.com ([209.85.220.182]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0LiWYm-1azwyH0AQO-00cl4w for ; Wed, 24 Aug 2016 18:32:53 +0200 Received: by mail-qk0-f182.google.com with SMTP id z190so20241040qkc.0 for ; Wed, 24 Aug 2016 09:32:52 -0700 (PDT) X-Gm-Message-State: AE9vXwO02nU7afu1im0smzO8P2vbVzWcee6q0X2iUp41MqQKInPsFgEcXnyWoQmtKOijepkinfJtgsuRWIfmyg== X-Received: by 10.55.120.195 with SMTP id t186mr4532640qkc.118.1472056371800; Wed, 24 Aug 2016 09:32:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.41.6 with HTTP; Wed, 24 Aug 2016 09:32:50 -0700 (PDT) Received: by 10.237.41.6 with HTTP; Wed, 24 Aug 2016 09:32:50 -0700 (PDT) In-Reply-To: References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> From: Bodo Moeller Date: Wed, 24 Aug 2016 18:32:50 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=94eb2c05f92021cd19053ad3d57c X-Provags-ID: V03:K0:f72zTMZPs1sa4U7aqBvnxVZVI1WgGIw3zs4sSHsWjUxj2ISgBc4 p7tbvfVMl6xiJ4iWhZPft1iH128+ruvBUnPjhVb3J/cMB1vLpYIAh+7ilLH5JvXKwRx7etI iI26vuzIdKL97ufoMjVjICa83wJWw0nMtbxcplE0Xee6+RSjjq/hkCjg5U2JXph4NLyzUQ4 scRkgeFekgGOczLYRTgPQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:F4tNTuDuyMo=:yjRqCPj5VmI6pKxDrPfZyD 3UZIsdixOITle45QNzezEVVSL4NyQOq5czsbdL0hr8EFbi8rKQpJjUjdLVGddn12swnK0BZ+t jVw6XP3f9DlWnNy+mSg54dR4qIkhjdwNGzLB9EGJtUvqtXB2oiOLyUeikugnKwJUY0Tn/Xe6r LurZQqAg5icCPmWxuw2L6t2v1pIc0wz8NTbVRM7I2k7B8fJ+i6Umk5+9JsKkbNBDVQqGtpFvU yVFnlY2T2KAIXN60o2JFHjU3bystMhCX4OWeltmP+tbuRas+2jFMedmjrU0yNM11XeWb+0A/W p2oA9eWfp/XAgKYMogzOi9Ia+UnBO146vOgyY+KX5qs6iNj+7C3+cTMyy1Qz1D3LrCmg0wREc 9kgNYYcggCdb1ZuLXo1fdaJhSlkJdNXkfLnel08fYqOoeVgZ+pN+5fS+Wun1fIM27lw2nosmz 2m9kFdL74im4sOb8me5e1L18LgWxW6Mvg1iUxALjFmeVL0ptqhpTItNl/33cY4uQChNkcdVtE 5wdoEyYAnn4kWAmiWq6/L1WhaZrclOcC0iwGftUjjXi7SGVKcAcIKYWSwb8llxptsPFDNem9T YgzJzTO8uk2URD7PQpiNS8jgXfdIirguAtCbbrOu9Bz8tMGoXdh0pKOCK7RUMiN35VtY6U0u4 cLxAHqLJyudPgo+7FgK66zU9rvNudGLsV5Y9csG5cS+frnabnGmdCO8L71qU2goTizbTud5p0 F+rfKJEQXp/T4Uzk Archived-At: Cc: hello@florent-tatard.fr, sean+ietf@sn3rd.com, Kathleen Moriarty , Chris Hawk , Nelson B Bolyard , "" , vipul.gupta@sun.com Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 16:32:57 -0000 --94eb2c05f92021cd19053ad3d57c Content-Type: text/plain; charset=UTF-8 > No, this is wrong. There is a client and there is a server, and > whatever internal arrangements are made are epiphenominal from the > perspective of this standard. They certainly are, but that just means that, in that (unintended) reading of the spec, it's using very contrived language to discuss something that's not subject to being specified here per se (where more commonly you'd find informal language describing the "inner thoughts" of the implantation). > I doubt anyone was confused by what it > said, but either way it needs to get fixed, Exactly. My point is just that, either way, it can be seen as an editorial error rather than a technical one, so there's no need to block the erratum on that decision Bodo --94eb2c05f92021cd19053ad3d57c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> No, this is wrong. There is a client and there is a ser= ver, and
> whatever internal arrangements are made are epiphenominal from the
> perspective of this standard.

They certainly are, but that just means that, in that (unint= ended) reading of the spec, it's using very contrived language to discu= ss something that's not subject to being specified here per se (where m= ore commonly you'd find informal language describing the "inner th= oughts" of the implantation).

> I doubt anyone was confused by what it
> said, but either way it needs to get fixed,

Exactly. My point is just that, either way, it can be seen a= s an editorial error rather than a technical one, so there's no need to= block the erratum on that decision

Bodo

--94eb2c05f92021cd19053ad3d57c-- From nobody Wed Aug 24 09:58:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FC612DEBC for ; Wed, 24 Aug 2016 07:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2yxFAvPx_5r for ; Wed, 24 Aug 2016 07:59:42 -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 563B412DE03 for ; Wed, 24 Aug 2016 07:50:08 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B3FC4200097; Wed, 24 Aug 2016 14:50:07 +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 9D351200012; Wed, 24 Aug 2016 14:50:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472050207; bh=ip18rxMttJmBMLy6mXiVwED3KAaVl6xgD031iyDm+Z0=; l=88; h=From:To:CC:Date:References:In-Reply-To:From; b=IdeLUxeaL7ag2uwPrp5RBfPIf2pAUBCYm30GB3VmnsaOyQV5iANf04SX2hSbOcuR0 OHz1iqfmOYL8TmhCnSYK5+gvWIKq4gY3CwaNBkN62Vo8zk+Ukp1z6dTL838HPepgSC t8nepXfzmwd1IfewaMm2LrkxM8l/FCq/JUfqv0mI= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 829751E08C; Wed, 24 Aug 2016 14:50:07 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 24 Aug 2016 10:50:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 24 Aug 2016 10:50:06 -0400 From: "Salz, Rich" To: Sean Turner , Xiaoyin Liu Thread-Topic: [TLS] [Technical Errata Reported] RFC4492 (4783) Thread-Index: AQHR+kcEiGl9120kI0icC3Cu2uuch6BXmbUAgAAvLwCAAK/bgP//wDaw Date: Wed, 24 Aug 2016 14:50:05 +0000 Message-ID: References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> In-Reply-To: <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.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.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 24 Aug 2016 09:58:01 -0700 Cc: "hello@florent-tatard.fr" , "sean+ietf@sn3rd.com" , "bodo@openssl.org" , "chris@corriente.net" , Kathleen Moriarty , "nelson@bolyard.com" , "" , "vipul.gupta@sun.com" Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 14:59:44 -0000 U3Ryb25nbHkgYWdyZWUgdGhpcyBpcyBhbiBlZGl0b3JpYWwgZml4LCBub3QgYSB0ZWNobmljYWwg b25lLg0K From nobody Wed Aug 24 10:09:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF8312D611 for ; Wed, 24 Aug 2016 10:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-fYBgvOdNHL for ; Wed, 24 Aug 2016 10:09:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7AA712D67E for ; Wed, 24 Aug 2016 10:09:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 985F33005B6 for ; Wed, 24 Aug 2016 13:09:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Z07uzWHJdz2R for ; Wed, 24 Aug 2016 13:09:29 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 5241E300293; Wed, 24 Aug 2016 13:09:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Wed, 24 Aug 2016 13:09:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: <0C9355E6-E51E-4F76-9671-DE0A0B3CFEF7@vigilsec.com> References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "chris@corriente.net" , Kathleen Moriarty , IETF TLS Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 17:09:34 -0000 I agree this is an editorial errata, not a technical one. From nobody Wed Aug 24 10:31:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B23912D162 for ; Wed, 24 Aug 2016 10:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNG-zipJiEQH for ; Wed, 24 Aug 2016 10:31:14 -0700 (PDT) Received: from BAY004-OMC3S19.hotmail.com (bay004-omc3s19.hotmail.com [65.54.190.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F89612D5B8 for ; Wed, 24 Aug 2016 10:31:14 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com ([65.54.190.187]) by BAY004-OMC3S19.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 24 Aug 2016 10:31:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tRefvMlERC5LV4sm4gg5BGR4tLzIgIJEsJiAOFrGd18=; b=CsPYWK1RtnSVWNpkLYt6MISelwIO7xv/RdNv9QRT4QNrmlAhKcdtKMR5/J2GwA6wN05ijEsCytH5AIsI/yZwbfYZ9+qmsipp7nTnG9t3iP+DlCWxXCpesytoo/rgY4AGpEp7N5n7cBCvV9UbqG/aeXkpAkgXvUW6IasOL3pTyeHLNBUSMG5+wiYEgw8aBz705yXAa2Q8K7maV9JbWNJ/yTHlXTklIWA2udQK2ZoaW3vJQiKpFT1jdDq9c+bep0J1FosOHrA2fIz5PxvoDorIulaLtJjDtY9LQC/vb5uhXGkQCALJerGjINP2jNNIsT0VjddZjr4awOxMFr7IZxRn8A== Received: from SN1NAM01FT006.eop-nam01.prod.protection.outlook.com (10.152.64.57) by SN1NAM01HT142.eop-nam01.prod.protection.outlook.com (10.152.65.4) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Wed, 24 Aug 2016 17:31:13 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.64.52) by SN1NAM01FT006.mail.protection.outlook.com (10.152.65.154) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Wed, 24 Aug 2016 17:31:12 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 17:31:10 +0000 From: Xiaoyin Liu To: Bodo Moeller , Watson Ladd Thread-Topic: [TLS] [Technical Errata Reported] RFC4492 (4783) Thread-Index: AQHR+kcFTuLAAhdbwkCpcQn6uhu3paBXVqcAgAArol6AALNogIAAA7yAgAAPiYCAAAzKAIAAD+YO Date: Wed, 24 Aug 2016 17:31:10 +0000 Message-ID: References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.64.52) smtp.mailfrom=outlook.com; acm.org; dkim=none (message not signed) header.d=none;acm.org; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.64.52 as permitted sender) x-tmn: [TgPwgt3mK+RG2Vl2zRvfLxec/SICZFQ/] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.64.52; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM01HT142; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; SN1NAM01HT142; 6:ubHkmRwV1FMOoivOYOUUMNQnOO4Vq9g3KDu8fA0BpmNA3NxvhmwLyJs5EjK5efFvcxIJbDr97TI+wEDCkR8gpa6KP3Pf0eHcc63rLLjfw89NgumsKuNS7DTX8R63NEWw0xorEVhA2Q3OuCsu0kEDsZRjNyJFXMCjuscR+n72bGijmG9h+DFk65cMlYnEvmn+2G+WigdMFCHbov6R2hGSrdkKPgrzl5Ckdf5UT9Ulyxih9WHdzY/QO166VKbwGSUsjg+sETdi+arr7hMEuLMYdFbR4JB/ko8PwupoNEr29luvvfwpwcGTIlIt3XpLoBc1; 5:rZ+2/3VAL33cqxcsvwlniJ6+qUDfQ/D5cZvOXY9jWhoU9L/uliwmI+KvZswPuhgXW+Cc40K5wFj6FpsPQqfXsNZ/kWm3V6Gqr8WHdtOlD3vD5eD+5qPVhmbHJ7dyiFx83ayleMEdepNYUVd3oGaqGA==; 24:f+XGkBj/plxueFIcS39DFozytqG3HwGBO384OWeArp3EsILyDgcV19vrgy1nfLhSLg0afa2QmgYAjDVJFBpecjz9CJ3FS5gQxRqqtX2J5/Q=; 7:tLQ5axBzHJxtFoTa4eSsa0ZUPrJh2/utkMV2IR8g40tB2CoNndPTeBcnd0cDum4hsqk/txTPXC2mE1yQiD40wCcByjUF7dtBT5VxYONb48g2B1fU2+3o2VoMSxTmriRph1sjtsNtS5ReKY/kTd2SvVqc7dixXoj+9CK3jfzV30JWHaShZ9XhlwmDb4bnP/GWojXF5Lb3P8KFP2/KPJoFpKKpSkOpjSOtpABiXMrxvVVO//QwLlAL8OlNYkSLGjvn x-ms-office365-filtering-correlation-id: 2c157f2a-5122-4bb5-96cd-08d3cc447098 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1601125047); SRVR:SN1NAM01HT142; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM01HT142; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT142; x-forefront-prvs: 0044C17179 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB077877002193D0D119C002ABFFEA0CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 17:31:10.6891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT142 X-OriginalArrivalTime: 24 Aug 2016 17:31:14.0158 (UTC) FILETIME=[501DF8E0:01D1FE2D] Archived-At: Cc: "hello@florent-tatard.fr" , "sean+ietf@sn3rd.com" , Kathleen Moriarty , Chris Hawk , Nelson B Bolyard , "" , "vipul.gupta@sun.com" Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 17:31:15 -0000 --_000_CY1PR15MB077877002193D0D119C002ABFFEA0CY1PR15MB0778namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you everyone for your explanation! Now I see why it is editorial. Xiaoyin ________________________________ From: TLS on behalf of Bodo Moeller Sent: Wednesday, August 24, 2016 12:32:50 PM To: Watson Ladd Cc: hello@florent-tatard.fr; sean+ietf@sn3rd.com; Kathleen Moriarty; Chris = Hawk; Nelson B Bolyard; ; vipul.gupta@sun.com Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) > No, this is wrong. There is a client and there is a server, and > whatever internal arrangements are made are epiphenominal from the > perspective of this standard. They certainly are, but that just means that, in that (unintended) reading = of the spec, it's using very contrived language to discuss something that's= not subject to being specified here per se (where more commonly you'd find= informal language describing the "inner thoughts" of the implantation). > I doubt anyone was confused by what it > said, but either way it needs to get fixed, Exactly. My point is just that, either way, it can be seen as an editorial = error rather than a technical one, so there's no need to block the erratum = on that decision Bodo --_000_CY1PR15MB077877002193D0D119C002ABFFEA0CY1PR15MB0778namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you everyone for your explanation! Now I see why it is editorial.<= /p>


Xiaoyin

From: TLS <tls-bounces@i= etf.org> on behalf of Bodo Moeller <bmoeller@acm.org>
Sent: Wednesday, August 24, 2016 12:32:50 PM
To: Watson Ladd
Cc: hello@florent-tatard.fr; sean+ietf@sn3rd.com; Kathleen Moria= rty; Chris Hawk; Nelson B Bolyard; <tls@ietf.org>; vipul.gupta@sun.co= m
Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783)
 

> No, this is wrong. There is a client and there is a ser= ver, and
> whatever internal arrangements are made are epiphenominal from the
> perspective of this standard.

They certainly are, but that just means that, in that (unint= ended) reading of the spec, it's using very contrived language to discuss s= omething that's not subject to being specified here per se (where more comm= only you'd find informal language describing the "inner thoughts" of the implantation).

> I doubt anyone was confused by what it
> said, but either way it needs to get fixed,

Exactly. My point is just that, either way, it can be seen a= s an editorial error rather than a technical one, so there's no need to blo= ck the erratum on that decision

Bodo

--_000_CY1PR15MB077877002193D0D119C002ABFFEA0CY1PR15MB0778namp_-- From nobody Wed Aug 24 12:45:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B859F12D755 for ; Wed, 24 Aug 2016 12:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgyuPGJdIz9q for ; Wed, 24 Aug 2016 12:45:26 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 CCEF412D75B for ; Wed, 24 Aug 2016 12:45:25 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id u25so12793565qtb.1 for ; Wed, 24 Aug 2016 12:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=xK2J7AMupvIzr3LJKqY7i0V2er5vhJ7sJ79p5Kk/t0o=; b=BDgqfIPfATe/deFUuG8KC0VaJtnS2WLQUFPv/20MoS6txd0J90l7RNJfNl1P6ZRPBC 2hL7wA7+f/rqX5sKsBPTGPR3KG8rwZRxs5qL74cdAUQFXD+jmCb5UH+y83ynUOgEMzwC Aur7tkIPUPYulX1soqztLH+/KUa8UgVDNTMmE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=xK2J7AMupvIzr3LJKqY7i0V2er5vhJ7sJ79p5Kk/t0o=; b=IH8nwuYCelwG5z6j7JkDGl4ysBOOHwzvXcMJduLma7FLkFeCtE1Do+bLPLX/B2887n vImg6NPdSSlV7UjNUAJvaAxNZtCOBQ46+zyVqkVTGUd4ZjhFFwXwkpOaDDqy1P0X4IQb Z+Hv95aQSX2nZZaQOPekFbIMOrVsc3E3CBrD0WjbepVvhNzDSA3AaxKkaIu3SQH3jq/S NN+mb0/WVR69Dtk2gdrhrl/JMgJBQmjrAAXsxczfXcpzxpKdCDGU9naelC5bsYmWSCfl DrYOE5EV6L6ywrRcB/qXNQ5oVDZt7CCfooOJW8jV78IoNfCSSiAaHNZtCgvFndQ3R+s+ vaNg== X-Gm-Message-State: AE9vXwNMvONFgwWNo82Kqkeaybv80laEiNR6QJFSqU2lAC7bigv2hGjVHwVQ7JpQFjrwLA== X-Received: by 10.200.46.216 with SMTP id i24mr5774318qta.79.1472067924772; Wed, 24 Aug 2016 12:45:24 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id e7sm5535651qtb.9.2016.08.24.12.45.23 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 12:45:23 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 24 Aug 2016 15:45:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160727014013.F056DB80362@rfc-editor.org> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (4750) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 19:45:28 -0000 I created an issue for this in the tls13 repo so that we can settle on = whether or not we need to change. spt > On Jul 28, 2016, at 10:59, Benjamin Kaduk wrote: >=20 > Jeff Hodges came up with a slightly different proposed rewording at > https://www.ietf.org/mail-archive/web/tls/current/msg19092.html the = last time this came up, which apparently was just a mail on the list and = not an erratum submission. >=20 > -Ben >=20 > On 07/26/2016 08:40 PM, RFC Errata System wrote: >> The following errata report has been submitted for RFC5246, >> "The Transport Layer Security (TLS) Protocol Version 1.2". >>=20 >> -------------------------------------- >> You may review the report below and at: >>=20 >> http://www.rfc-editor.org/errata_search.php?rfc=3D5246&eid=3D4750 >>=20 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Adrien de Croy=20 >> >>=20 >>=20 >> Section: 4.3 Vectors >>=20 >> Original Text >> ------------- >> The length of >> an encoded vector must be an even multiple of the length of a = single >> element (for example, a 17-byte vector of uint16 would be = illegal). >>=20 >> Corrected Text >> -------------- >> The length of >> an encoded vector must be a whole multiple of the length of a = single >> element (for example, a 17-byte vector of uint16 would be = illegal). >>=20 >> Notes >> ----- >> Original text implies vectors can only contain even (0,2,4,6,8...) = numbers of elements. The example does not resolve this but indicates = the intent is that parts of elements are not allowed. It is clear from = other examples that odd numbers of elements are permitted. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> 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 >>=20 >> _______________________________________________ >> TLS mailing list >>=20 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Wed Aug 24 12:47:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AFE12D761 for ; Wed, 24 Aug 2016 12:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df3w1U8aFHCJ for ; Wed, 24 Aug 2016 12:47:03 -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 036C212D766 for ; Wed, 24 Aug 2016 12:47:02 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id t7so25856545qkh.1 for ; Wed, 24 Aug 2016 12:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=JuB9yPhj8PVY59T6WI4vWdJ8y+kc1VfOwHnb+XSe5+c=; b=b4fYDcNLal4d02+9lRLbdVvG/EnFfMzF+gHf2xOE1aEK6JSoxdn6WT8Pw1NJrqyiUb mFLpF8SJ8AzKZ3kHuQq6n1747Gxgb+QYM34Hyj3Q6uZzmOehkbzUlcG+bQI72U1l73zM sPX4bJb7AkFkRKlNVMnj5Y4J9A5mzc4sETl1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=JuB9yPhj8PVY59T6WI4vWdJ8y+kc1VfOwHnb+XSe5+c=; b=mFpa07xq6/y/0FZIRRPoAlAw/tDkLsBYVlKZI7I8RhQ4T2BVuElS4/gh/qgNceZykd JUK3TeKFq8t7hUEjVCEPsvXA5nmxQQXQkfeey0ew0mNanK/8+SADQY1xufIFOBDm/rX+ q0yyRr+QHaAlM+jYQhXxiEJtS1bAh/tOwEyHcPJm2luIyNQTCVqNaA5E9Ajbq6Gnj2aQ tiiIP1AmnIFlYDfFnsyaCVKAztzrpbAlxjeA7OwpvPg9J7YOCfRdeLd5dpnof1g7dD1n 5zTgQ2aYT5IxVdlJG0rMHC3NFnZ962RSeeKNGDL/rtqyTBJ1LQb24xrp7WB+98WJkDtq 83XA== X-Gm-Message-State: AE9vXwOpuCgZ5GRTETPOxQ/6fPgvDDX06wnhxEZsUA2tdeeUAAAoIzxlI5BDBhp7ne5nvQ== X-Received: by 10.55.95.2 with SMTP id t2mr6025188qkb.144.1472068021793; Wed, 24 Aug 2016 12:47:01 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id 50sm5556395qts.11.2016.08.24.12.47.01 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 12:47:01 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 24 Aug 2016 15:46:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F9093D0-700F-4328-9281-1F3FED958548@sn3rd.com> References: <20160727014013.F056DB80362@rfc-editor.org> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (4750) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 19:47:05 -0000 And there=92s the link to that issue: https://github.com/tlswg/tls13-spec/issues/587 spt > On Aug 24, 2016, at 15:45, Sean Turner wrote: >=20 > I created an issue for this in the tls13 repo so that we can settle on = whether or not we need to change. >=20 > spt >=20 >> On Jul 28, 2016, at 10:59, Benjamin Kaduk wrote: >>=20 >> Jeff Hodges came up with a slightly different proposed rewording at >> https://www.ietf.org/mail-archive/web/tls/current/msg19092.html the = last time this came up, which apparently was just a mail on the list and = not an erratum submission. >>=20 >> -Ben >>=20 >> On 07/26/2016 08:40 PM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC5246, >>> "The Transport Layer Security (TLS) Protocol Version 1.2". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>>=20 >>> http://www.rfc-editor.org/errata_search.php?rfc=3D5246&eid=3D4750 >>>=20 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Adrien de Croy=20 >>> >>>=20 >>>=20 >>> Section: 4.3 Vectors >>>=20 >>> Original Text >>> ------------- >>> The length of >>> an encoded vector must be an even multiple of the length of a = single >>> element (for example, a 17-byte vector of uint16 would be = illegal). >>>=20 >>> Corrected Text >>> -------------- >>> The length of >>> an encoded vector must be a whole multiple of the length of a = single >>> element (for example, a 17-byte vector of uint16 would be = illegal). >>>=20 >>> Notes >>> ----- >>> Original text implies vectors can only contain even (0,2,4,6,8...) = numbers of elements. The example does not resolve this but indicates = the intent is that parts of elements are not allowed. It is clear from = other examples that odd numbers of elements are permitted. >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary.=20= >>>=20 >>> -------------------------------------- >>> 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 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>>=20 >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 From nobody Wed Aug 24 12:58:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636AC12D76A for ; Wed, 24 Aug 2016 12:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-STAbgFzDDd for ; Wed, 24 Aug 2016 12:57:56 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 B8DB312D10D for ; Wed, 24 Aug 2016 12:57:56 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 74so47964092uau.0 for ; Wed, 24 Aug 2016 12:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dzb9j9oxGV+cxo2llY9ee36unH8TInmWvI+wvOD6eAU=; b=n/ct3b/WOphrUOFe3EKAWXhIm+t/2nPI/R7SRrKrlf0nRSi+9nk/pmT63DvAp2I7/j R2UJafJvoah5VRyt8FsqMeWznlxB2fdOm1PIuRZiQ1AUbYalrjr5ec1dCoPp4AS3YGzH hOI6aHe6kOlY9m858Oxma0x49Bw6oVuFJzpxELgmL1rbCUYG5rpDpB1AXB3j4D1Uflqe TJ30zEj8CsVYfJcZxvclwr2Z2iUfe6AbVm07VnX42wNo4Dy9ZFKl9ix9VGQhbq9WzqWN dgeGfQiDzMqz2v/qej4O8EMdo/mU/jayObDfTtcfoQpmta0Y8bEoO6gI53vBBJ/lSsQW EWOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dzb9j9oxGV+cxo2llY9ee36unH8TInmWvI+wvOD6eAU=; b=E3UcO7rZbeA7yCB8xPmZxgKBZsZG8H9c1oQjvoEmy1KDAkmVFV5wvTyklF+4DoUdhS 0zV6mtZQr0gCdU3YgbAD1va28Sd9BCHh6TszbsfRQvjSa6qQuBsHoKedrVZjUnIiVmtq MkKVNg8STScyEzUm14wIfbLY1S3YLsyJie//AXygyKdseUKhDITJYqLeHEQkJTsehN+w 5hgb3L5m9lg47V7iqi1F8/LvCAOsIvX+HelKIedIT9SToLShjRDjPZKy4OW7kagJegVJ KIhP+OZBPfMAveL/oC+0kEgQOFIu+HQw3Ynqb6rUVM78UJjWyTk/EHmZpM91Qn7fblWC 5j7w== X-Gm-Message-State: AEkooutwsbyLDHItO3m7lOd55q9soYqJ9N9hvJ0faKH5vqpHmYy+yTQ5o3b1uiTIk71R4VGpVcB/IIE/YMQTbg== X-Received: by 10.31.74.5 with SMTP id x5mr2734605vka.42.1472068675881; Wed, 24 Aug 2016 12:57:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 24 Aug 2016 12:57:55 -0700 (PDT) In-Reply-To: References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> From: Kathleen Moriarty Date: Wed, 24 Aug 2016 15:57:55 -0400 Message-ID: To: Xiaoyin Liu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "hello@florent-tatard.fr" , "sean+ietf@sn3rd.com" , Chris Hawk , Nelson B Bolyard , "" , "vipul.gupta@sun.com" Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 19:57:58 -0000 Thank you for verifying the errata. I changed the status to verified after marking it as editorial. There is another errata on this RFC, 4633. Is that errata correct? Best regards, Kathleen On Wed, Aug 24, 2016 at 1:31 PM, Xiaoyin Liu wrote: > Thank you everyone for your explanation! Now I see why it is editorial. > > > Xiaoyin > > ________________________________ > From: TLS on behalf of Bodo Moeller > > Sent: Wednesday, August 24, 2016 12:32:50 PM > To: Watson Ladd > Cc: hello@florent-tatard.fr; sean+ietf@sn3rd.com; Kathleen Moriarty; Chris > Hawk; Nelson B Bolyard; ; vipul.gupta@sun.com > Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) > > >> No, this is wrong. There is a client and there is a server, and > > >> whatever internal arrangements are made are epiphenominal from the >> perspective of this standard. > > They certainly are, but that just means that, in that (unintended) reading > of the spec, it's using very contrived language to discuss something that's > not subject to being specified here per se (where more commonly you'd find > informal language describing the "inner thoughts" of the implantation). > >> I doubt anyone was confused by what it >> said, but either way it needs to get fixed, > > Exactly. My point is just that, either way, it can be seen as an editorial > error rather than a technical one, so there's no need to block the erratum > on that decision > > Bodo -- Best regards, Kathleen From nobody Wed Aug 24 13:16:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B993412D0FC for ; Wed, 24 Aug 2016 13:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbrM5O711WmH for ; Wed, 24 Aug 2016 13:16:35 -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 7D41312B056 for ; Wed, 24 Aug 2016 13:16:35 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id v123so26686157qkh.2 for ; Wed, 24 Aug 2016 13:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kK62yDo/HWo6Dpv2RhjexIfqFGM1A8XhI5rTmGVAusU=; b=jEww7XotHKXjZ1p3By3ZuZlPmb0F+Vj+vhdYDKo2DYbCNaV9W2zKDQL7EWEwZoga6B kilFPdPMKKblJG92SBAIwJNWbp/lazD7g7omRS7eDe3uiMGmZlNl+jeA5EGOg+ciUde4 phE7+r4VvH3lEPI2bXYWBCZybID/ZUJIWrlKE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kK62yDo/HWo6Dpv2RhjexIfqFGM1A8XhI5rTmGVAusU=; b=egDeiJgliPM8Lx9n6bVaaeSpX3atxxbAWNW1xrRxz5ct1KJNJ8PmLe2n9qAQpd3rVY EmZhgTa1aIkh55mFjM+yYXGllPGoD3Cj1aW88DiSMZOCk5jJwcsM7USKVAIauRGlh7ab LAkecIlJSaJvNY4XZ8BIZWFFY82MJ26V6Ux1ajZUxGtX5GRYAojIXVu80+KOp6++qtvj LHu9EcK5z+uMLEsmAUeadyaJv7kk3R48/3BsjTWmfPqhTHnczv3tUCHH7bezau/FO0n7 sMaHZDTEsY7hm0W5tT+ihNBLIhJdQgkzCNgXhNBW6f6YPQjUPQihM0e5GL1vZ5G6hoCZ PRmA== X-Gm-Message-State: AE9vXwOObOlaKYQq4uNW3rKodTDRXLFYrp4p15L8Lyk+h7euuG/kE6BU5LOv7LtWRehKrg== X-Received: by 10.55.100.21 with SMTP id y21mr5599701qkb.274.1472069794647; Wed, 24 Aug 2016 13:16:34 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id r187sm5580687qkc.49.2016.08.24.13.16.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 13:16:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 24 Aug 2016 16:16:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160819171346.A5E32B80DC6@rfc-editor.org> <9976B7F9-B1F3-4549-A93B-7B940A61C7F5@sn3rd.com> <57F439CA-1CBA-4F52-863E-E69D3A78704C@sn3rd.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 20:16:37 -0000 > On Aug 24, 2016, at 15:57, Kathleen Moriarty = wrote: >=20 > There is another errata on this RFC, 4633. Is that errata correct? How about you mark it as =E2=80=9Cheld for document update=E2=80=9D. I = believe the 4492bis draft will address 4633. spt= From nobody Wed Aug 24 14:18:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88D12D765; Wed, 24 Aug 2016 12:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbHxwqnHPoqK; Wed, 24 Aug 2016 12:55:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFB012B02C; Wed, 24 Aug 2016 12:55:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 97E8BB803FD; Wed, 24 Aug 2016 12:55:28 -0700 (PDT) To: hello@florent-tatard.fr, sblakewilson@safenet-inc.com, nelson@bolyard.com, vipul.gupta@sun.com, chris@corriente.net, bodo@openssl.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160824195528.97E8BB803FD@rfc-editor.org> Date: Wed, 24 Aug 2016 12:55:28 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 24 Aug 2016 14:18:13 -0700 Cc: rfc-editor@rfc-editor.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, tls@ietf.org Subject: [TLS] [Errata Verified] RFC4492 (4783) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 19:55:29 -0000 The following errata report has been verified for RFC4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=4783 -------------------------------------- Status: Verified Type: Editorial Reported by: Florent Tatard Date Reported: 2016-08-19 Verified by: Kathleen Moriarty (IESG) Section: 5.7 Original Text ------------- Actions of the sender: The client selects an ephemeral ECDH public key corresponding to the parameters it received from the server according to the ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to the client in the ClientKeyExchange message using the format defined above. Corrected Text -------------- Actions of the sender: The client selects an ephemeral ECDH public key corresponding to the parameters it received from the server according to the ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to the server in the ClientKeyExchange message using the format defined above. Notes ----- The client conveys data to the server, not itself. -------------------------------------- RFC4492 (draft-ietf-tls-ecc-12) -------------------------------------- Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Publication Date : May 2006 Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Aug 24 16:02:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C329212D743 for ; Wed, 24 Aug 2016 16:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u65cXC22hTw5 for ; Wed, 24 Aug 2016 16:02:28 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065DA12D7A4 for ; Wed, 24 Aug 2016 16:02:27 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id j12so19569616ywb.2 for ; Wed, 24 Aug 2016 16:02:26 -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-transfer-encoding; bh=5p4KEF9adTHbvIDw4012NrCN/AkkQceWROF9OsbXblM=; b=G2/0Q+JjiOSfQiJ73qb/fnb8eiWgeDFf7Fk7ZCFH7CfI1Fz1zX/J6adJGnwguVhOKH F6xJzdBFT2x3k0uOZfLT/IDBmOUp24lOlMp16kNN0uZIfGcnceJnmOmYRYnyvx7sK3d7 aeukcMa002zLvdMbgzRC5wUmT/yF1HChGTiDEEuztC2iA9dXz1wY5/BXKV09uKW66+ua 0mXHo+dTlnWhkwo2v4/9vh3niWm0ZFok7V5W7oi7QLynROF0v/1vSmoBxk1e7uWgcrVs aeFf2EXbR7wvWnmPtsWxSVKjjtJFSHv38/JZJXPBZMND/v+zfl0if8yV2Oyfudf09Y1k RqVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=5p4KEF9adTHbvIDw4012NrCN/AkkQceWROF9OsbXblM=; b=X3iuBEj21CVPuYrQnAE1AGunXurOx9P6N/sX47gt91CiCAmw5IAcmmRy+GduapV5vJ RynqzUhGqcKZuXJMigg+EBjlvfSlxbZsM4qN084M9AUbGNIVfpvn02ZTy1N1+SWf8PeN 4N0KM7l/XNZNHlNrq24Ry+5b8R6/fTQ8GGAqLonTIFQF16cQuN4W+/kjbG2H4PD72y9m iPy3WYKCXVB/DPpEU7DacoFGGgJzrqvoCcdgLqqhPNL/gkfxt0ixDR3ZTC7gISCrshpE rj1iG6Y6fssMQ4EzvL6KzvrMWtCQA1aVi44tNcDFGT7gyIqy3ZqddfLEf9qS09gnT+vI dWPA== X-Gm-Message-State: AE9vXwNdD44HtcSMAMnO6VoPPBY7b3TloHlxb9AHPO/1q/BbHdBX3qtSYdZFAkCUybHJ/sdSGEUk1MB5uBuojA== X-Received: by 10.13.239.193 with SMTP id y184mr4555121ywe.85.1472079746164; Wed, 24 Aug 2016 16:02:26 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Wed, 24 Aug 2016 16:01:45 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> References: <93086b3c-ca1b-4c37-67e1-efbf417a8b58@akamai.com> <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> From: Keith Winstein Date: Wed, 24 Aug 2016 16:01:45 -0700 X-Google-Sender-Auth: Dp92vxn1COGzacHmscRhacrg8Fw Message-ID: To: Subodh Iyengar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Aug 2016 23:02:31 -0000 Hi Subodh, Interesting points. On the form of the generation identifier: The draft does already specify the generations as integers (traffic_secret_N, N+1, etc.), and the semantics of a KeyUpdate are that when you receive one, you increment the generation of the receive key. So the proposed "receive_generation" field is really just echoing the generation number back. I could imagine a different system where the KeyUpdate instead includes an opaque identifier, and the receiving implementation is then supposed to echo back the most recent opaque identifier that it got. That would also provide Property P3, and so I would be totally fine with it. But now we're talking about adding *two* fields to a KeyUpdate (the sender's opaque identifier, and also an echo of the most recently received opaque identifier), instead of one field, so I'd be surprised if there were more consensus around this alternate approach! On the API that a TLS implementation would expose: Obviously the WG doesn't have to specify this, but here are three APIs I could imagine: (1) No change to current APIs. The TLS implementation itself triggers KeyUpdate when it wants to (e.g. per recommendation on when the underlying cipher wants to be rekeyed), but doesn't expose this to the application. (2) Fire-and-forget. The TLS implementation exposes a `rekey_session()` function, which initiates a KeyUpdate. [If we adopt the proposal described earlier in this thread, maybe there's a boolean parameter about whether to request a reciprocal rekey from the other side...] (3) Fire-and-later-check. The TLS implementation exposes #2 above, but also `tls_session_generations()`, which returns a pair of integers giving the current sending and receiving generations. Any application we might want to build can be built on top of #3. Cheers, Keith On Tue, Aug 23, 2016 at 11:47 AM, Subodh Iyengar wrote: > For people that currently use keyupdates or who are planning to use key u= pdates, which layer are you planning to trigger a key update? Would the TLS= implementation itself trigger the update or would the application trigger = it? For renegotation, I believe it was mostly triggered by the application. > > For the use cases you mentioned Keith, they seem to be specific to applic= ation triggered key updates, i.e. key updates do not mean anything to the T= LS layer apart from I got a key update and I must change keys. The fact tha= t other side has thrown away it's key is only meaningful to the higher laye= r protocol. I imagine protocols like HTTP would not add these semantics, an= d these semantics would be added to very specific IoT protocols? Would the = scope of the auditor be defined as a part of that protocol, or does it need= to be defined as a part of TLS? > > If key update is an application triggered mechanism, does the generation = identifier need to be an integer to be understood by the TLS layer or could= it also be an opaque identifier sent by the application. It would be much = simpler not to have to deal with the requirements of consistency at the TLS= layer and would make the API simpler. > > Subodh > ________________________________________ > From: TLS [tls-bounces@ietf.org] on behalf of Keith Winstein [keithw@cs.s= tanford.edu] > Sent: Friday, August 19, 2016 8:40 PM > To: Stephen Farrell > Cc: Adam Langley; tls@ietf.org > Subject: Re: [TLS] KeyUpdate and unbounded write obligations > > On Fri, Aug 19, 2016 at 2:29 PM, Stephen Farrell > wrote: >> >> And for me, the dodgiest, by far. The scope for an "auditor" >> (what is that?) actually being an attacker is IMO way too >> high to consider standardising that kind of feature and any >> idea that it'd involve informed consent of someone seems to >> me fictional. > > I appreciate the sensitivity of this issue to the WG. My read of your > email is that there's a concern that by standardizing a protocol > mechanism that allows a node to learn when its own KeyUpdate has > happened, the WG would imply approval of features that permit > the bad kind of eavesdropping. Here's why I don't think that's the case: > > Our PR is for a piggyback integer field to provide security property > P3: "An implementation can learn that its request to rekey its > outgoing traffic has been read by the other side." > > KeyUpdate is an *instruction* to the other side: "please update my key > in a forward-secure manner." We think some implementations will want > to know that the instruction has been carried out. And there's an easy > opportunity to do that here as a piggyback, without any extra protocol > messages. > > A node will naturally care more about forward secrecy, and > confirmation of a forward-secure ratcheting event, the more it has > reason to suspect the keys might later be exposed to a third party. In > Berlin, I described three escalating cases: the (1) node going to > sleep, (2) node closing a connection without a mechanism for secure > bidi close, and (3) node that itself intends to release keys to a > read-only auditor after a ratchet is complete. > > By "read-only auditor," we mean a curious person or security > researcher who owns an IoT device and wants to know what the heck it > is sending out of their house, where the device doesn't want to allow > its owner to add trusted certificates for an MITM. (This describes > most such devices today.) > > Obviously I think it's valuable to make this mechanism available for > IoT device manufacturers. Having talked to several manufacturers, I'm > cautiously optimistic that some would use this. But the WG doesn't > have to take a position on this. These use cases are up to > implementers. There's nothing stopping an implementer today from > releasing session keys, or allowing complete MITM, as is the case in > the browser context with user- or admin-installed root CA > certificates. The TLS WG hasn't opined on these either. > > To restate: Property P3 allows a node to learn that its KeyUpdate > instruction has actually happened, which in our view is useful and a > strict benefit over the status quo. It's also orthogonal to the issue > of unbounded write obligations raised in this thread. > > -Keith > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_tls&d=3DDQICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wA= yN7fQ&m=3DdPWRCHpTfdtxfXYBMZF__UyOa7wszKFnA6criwmMDHI&s=3DE7sRstn6vNQHPiX3C= XAa6BbWSWtMW7VKtN4f3yblZ5U&e=3D From nobody Wed Aug 24 19:08:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8DD12D786 for ; Wed, 24 Aug 2016 19:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBVAzlAdM1sW for ; Wed, 24 Aug 2016 19:08:23 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 94B5512D77A for ; Wed, 24 Aug 2016 19:08:23 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id m60so20680621uam.3 for ; Wed, 24 Aug 2016 19:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=UXFmFkxkX9jSFHaJ+D+9YhNuQA9vo9V27dRaxh9z6Wg=; b=G4lLVureeLzbIFK+K86snC7YkRnwTC4IzzBRmHBsIpZYysVCFr2EI/0z1GFRMWxKhj NX0SlMm5tEhmUSXusTeDL9PH6hqznqzJZuzZlmr32CAyIcfJJXdbs2XJBfSxMZ0nHffg zLrJ9Rwq+rcDw8nP8U10Cli+s0lzlGZK3+jeLFMDhcr3NxJaK39d4JL7EatPic3VtS8d 66HtCXh2aNnDZMj6dLWk4PRn0xqhfDM1yFBfY1E82xP9Z1gT7+NGDaPbwce3HlDKy3X5 eCVPDJKHlUqvupicgMRGisNZQfRzaGp+0SOv6+Nt6LbNSX2ULjG3vurd46UqUIR6B+Lf z1og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UXFmFkxkX9jSFHaJ+D+9YhNuQA9vo9V27dRaxh9z6Wg=; b=hGpXOHOdn6OZZX9eHK7Sj4iU/9eL3/8oAO9crAi+yWjfbPQPqGLjveOJQGfaSXS8lN xPOxfPAO9D3iPMT+Y8uQaFPXgmRpbRUBoInUTccY8WAjAr7v7WGzy0tI2pJ/aXaaQiQQ /nLfgdb6UamcRebPrz/8PByKV/o9RpAuG4ZuXuy6wXjT4Zio4mplA4Fn+GR77KIOoJuo 35+aG8orHJAU737pbFW85eF2sbFWeB6In1lB3k3FWzOA3t+f/Nj4OMN00WMzlvtkUCtQ uOfEagEHuKSBmohHI5PMhGBhshdAVnSWhQwo/szV/vkLF2zAPHjbpVIaQEp79GhHHhcc d/ow== X-Gm-Message-State: AEkoousfHneerWWClERrDsKTWPj85JjSARIJCJU3j1ScthnxhSiWLKC2w1c85yLBfJunksYKIHNi6j5S00Qd1w== X-Received: by 10.31.148.147 with SMTP id w141mr3533874vkd.1.1472090902596; Wed, 24 Aug 2016 19:08:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Wed, 24 Aug 2016 19:08:02 -0700 (PDT) From: Tony Arcieri Date: Wed, 24 Aug 2016 19:08:02 -0700 Message-ID: To: "" , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary=001a113d33fc5393c0053adbdf1d Archived-At: Subject: [TLS] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 02:08:25 -0000 --001a113d33fc5393c0053adbdf1d Content-Type: text/plain; charset=UTF-8 This attack was published today[*]: https://sweet32.info/ I bring it up because I think the threat model is similar to the threats that lead to RC4 "diediedie" https://www.rfc-editor.org/info/rfc7465 Should there be a 3DES "diediedie"? I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense for it to be banned from TLS 1.3. [*] Lest anyone claim the contrary, I am not surprised by this attack, and have pushed to have 3DES removed from TLS prior to the publication of this attack, and can probably find a TLS implementer who can back me up on that. -- Tony Arcieri --001a113d33fc5393c0053adbdf1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This attack was published today[*]:


I bring it up because I think the threat model is similar to the thr= eats that lead to RC4 "diediedie"


Should there be a 3DES "d= iediedie"?

I believe 3DES is MTI for TLS 1.0/= 1.1(?) but I think it would make sense for it to be banned from TLS 1.3.

[*] Lest anyone claim the contrary, I am not surpris= ed by this attack, and have pushed to have 3DES removed from TLS prior to t= he publication of this attack, and can probably find a TLS implementer who = can back me up on that.

--
Tony Arcieri
--001a113d33fc5393c0053adbdf1d-- From nobody Wed Aug 24 19:32:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B1012D0CF for ; Wed, 24 Aug 2016 19:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xiF0BNnm4Mw for ; Wed, 24 Aug 2016 19:31:55 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 C057D12D09A for ; Wed, 24 Aug 2016 19:31:54 -0700 (PDT) X-AuditID: 1209190d-cfbff70000005edd-ac-57be589977a1 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 88.80.24285.9985EB75; Wed, 24 Aug 2016 22:31:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u7P2Vq91022461; Wed, 24 Aug 2016 22:31:53 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u7P2Vn7T020339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2016 22:31:52 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u7P2Vnit000179; Wed, 24 Aug 2016 22:31:49 -0400 (EDT) Date: Wed, 24 Aug 2016 22:31:49 -0400 (EDT) From: Benjamin Kaduk To: Tony Arcieri In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nojszYl+4Qd9kA4tLj1uYLLp/HGSy +HS+i9GB2WPnrLvsHkuW/GTymLzxMFsAcxSXTUpqTmZZapG+XQJXxvw18gUNLBVnz5xhaWCc y9zFyMEhIWAicfeWcxcjF4eQQBuTxKk5h1khnI2MEpt/f2eDcA4xSSxv64fKNDBKzHs9DyjD ycEioC0x7+YvFhCbTUBFYuabjWBxESB76c89YHFmAReJiz0NjCC2sICSxOHmZmYQm1MgUGL/ q5lgNbwCDhKfTp4Es4UEAiQObpzDBGKLCuhIrN4/BapGUOLkzCdQM7Uklk/fxjKBUWAWktQs JKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxgoKUU5J3B+O/u16HGAU4 GJV4eHes2hsuxJpYVlyZe4hRkoNJSZQ3vAkoxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3d+C+ cCHelMTKqtSifJiUNAeLkjjv9m/t4UIC6YklqdmpqQWpRTBZGQ4OJQnejHCgRsGi1PTUirTM nBKENBMHJ8hwHqDhy0FqeIsLEnOLM9Mh8qcYdTkW/Li9lkmIJS8/L1VKnPdxGFCRAEhRRmke 3BxwctnNpPqKURzoLWHebpBRPMDEBDfpFdASJqAlLfd3gywpSURISTUwRugqXvJMZdZq21qz 8y1n4s3dyvc3lq1+xcjNz77Vw9vM6/uaZ/NsPaPu13/W+WwsNO3i+UPd64suhRxub5vw/9DL OP9dPMEm4uHqq9NueZv8WzN7795FulPXvDsndPzk48A7OoVf552QdMr+/dDsZumRn3Hy8odF bNe6VeacVv5m+0O88mCqtRJLcUaioRZzUXEiAEcXwz8JAwAA Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 02:31:57 -0000 On Wed, 24 Aug 2016, Tony Arcieri wrote: > This attack was published today[*]: > > https://sweet32.info/ > > I bring it up because I think the threat model is similar to the threats > that lead to RC4 "diediedie" > > https://www.rfc-editor.org/info/rfc7465 > > Should there be a 3DES "diediedie"? Well, there is https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 but it is not really what you are looking for, I think, given the recipient list on the message. -Ben From nobody Wed Aug 24 19:34:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D112D127 for ; Wed, 24 Aug 2016 19:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yzHsqJHtobY for ; Wed, 24 Aug 2016 19:34:32 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 EA6AD12D09A for ; Wed, 24 Aug 2016 19:34:31 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id m60so21431341uam.3 for ; Wed, 24 Aug 2016 19:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zhLzcJbC5ibBRBzp8msE98d7IB5JfRfGZbfvzeEb3rc=; b=a4q5UG7+zZN5Ry5T48xJ+HplyCUi4YFfSNMh01RqViraRKUtCVUsBh1Bt75wAVzOY1 avP7s/O7LcFk2TJzfr83YTA6L7TJ8aiWlQu+/tX3Ks/c7nriixicNH/fmSV4RupUgiIl KF448kXuw0wjHkY/Rhzl1fo/6+x1yhaMcBym2nDBX0ACN0DiBnRcy7i7px3rgSH7d12x IFFym6Z0jgbq0fO24n0/jRk5ucDOm6TikkVSuolBJWyFH+MiADY4uR63lGg/PSICNAnh pDjRYRDxy9FS660SzS7E3G/AAeUBpxBpb69wu6g0IHhlKyvRXdyEOUgPMYuCKyhE6Ot/ Mqfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zhLzcJbC5ibBRBzp8msE98d7IB5JfRfGZbfvzeEb3rc=; b=nCzATCFZmvaCsNy6hh/UazQseTSexNzrACziElXx3rheGAP78HIQlRTgoZs2QruYUZ tAjdEDdHHLZe1uXy2BM0gPWCcOtSmGpRUpnf9CuYMczsGlAcSuxtKjFT6s6LtuskkMZK WQRrZapiKjn9GfmsTurJ7mKE+zSh9EMnANy7CsPjYbgSRQFVmhQdgLlVTlg256PHikG4 5hbU14eyPnu0mcrm8nBNPgQzsPwPoLCJO3Phcb12hQg3cDrBTapb9nZON9pnpvEnqxCM +wl3nntj8/tYxIpe9+oyocvJOVJ80UIX9xTP17rtBCfM0a0UptzG5GyVstd31YMy5uWx m6bg== X-Gm-Message-State: AE9vXwO5qpR9xDdxaVxKiNoVXmAJNn78XmNb5Bg89zdOHSYHfKSxWeqN672RQu2C3EO/8fZGBL1RdmaTguQpBA== X-Received: by 10.176.2.242 with SMTP id 105mr3740627uah.10.1472092471005; Wed, 24 Aug 2016 19:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Wed, 24 Aug 2016 19:34:10 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 24 Aug 2016 19:34:10 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a1142e550cf99a2053adc3c6d Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 02:34:35 -0000 --001a1142e550cf99a2053adc3c6d Content-Type: text/plain; charset=UTF-8 On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk wrote: > Well, there is > https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 > but it is not really what you are looking for, I think, given the > recipient list on the message. I am particularly interested in 3DES's usage in TLS, given its previous MTI status in TLS, and because it was until very recently included in the OpenSSL "DEFAULT" ciphersuite list. -- Tony Arcieri --001a1142e550cf99a2053adc3c6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk <kaduk@mit.edu> wr= ote:
Well, there is
https://tools.ietf.org/html= /draft-kaduk-kitten-des-des-des-die-die-die-00
but it is not really what you are looking for, I think, given the
recipient list on the message.

I am particu= larly interested in 3DES's usage in TLS, given its previous MTI status = in TLS, and because it was until very recently included in the OpenSSL &quo= t;DEFAULT" ciphersuite list.
=C2=A0
--
Tony Arcieri
--001a1142e550cf99a2053adc3c6d-- From nobody Wed Aug 24 19:36:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3544812D62A for ; Wed, 24 Aug 2016 19:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX9QGD7vUnSF for ; Wed, 24 Aug 2016 19:36:22 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 72AC912D127 for ; Wed, 24 Aug 2016 19:36:22 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 74so61735743uau.0 for ; Wed, 24 Aug 2016 19:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aPWAoHCs9vBIoq2sXmK3fvKx3VEV11L+dbxphPfAn+Y=; b=SlLwOzId+eveejMW1dLTWlZ26OKopOmqTw1lb6cJDUhWeniD5nq3bvmhslO8+y31v+ OzEntvDAhhggjlydlPAlx7B9Wd9NmEhlGXOFxup5nXEumiifGzzjXXEZmdAUpAFV0WGf yCNsKMKOBMaCRO0SG14Vo89TBHqrgkTbsj3MXkjqwtyQh06kkF5NiJX/GSL9uHCwyEvg 9VMyBCNQfXToIdBCW8BmYZD35JCaSXcrwBOIVtSlURmncy+OoPSc6sPMXCjW65Kq8V+T uOvsofgEylIt1WLwAd7jZgYwf+4lD5AVXBBsinCs/iRKDqFPw86lPpBOudm0yKXCfuhK dgww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aPWAoHCs9vBIoq2sXmK3fvKx3VEV11L+dbxphPfAn+Y=; b=iDwIM3PPz3zx9MD6B0x/TBcOa4uTQYDiZ2FyZ18jDqSlDch9EUHdl9nQYroWMH372n 3zoCLtz4i4fpCwYX75zcGEXQdkzskrIf7FTJhufhdi+zig6sTEfw15NxjDGzUwXDSMvl MWlbrIXp+FUYUj7MauCX5XnKoy2JPECtmqZb3qmunT8wyC/yFGOFLUtKIXTTUzFWvKG8 91NsxUd6JdI6PDCNDOOjroHo8g8W7kDQgMrhdrrzeQC2F5qW5fK94F7MIXqao0nhKw3O y83/WQL+2lFZHoeU02lEG5YgaSTVR9f9fOTCta+ZJADk8HToqWjvleEG0/FNorvcyjq3 EEIg== X-Gm-Message-State: AEkoous+a8pp0WnnyxG4PPgFfPVL53cGxZehXuAU0LgPLiamBvY3uF+H7E9MYTGgIqv4DItFsNbJtpeaF5MyoQ== X-Received: by 10.31.110.135 with SMTP id j129mr3581105vkc.81.1472092581640; Wed, 24 Aug 2016 19:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Wed, 24 Aug 2016 19:36:01 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 24 Aug 2016 19:36:01 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c14acf267c1d0053adc4385 Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 02:36:24 -0000 --94eb2c14acf267c1d0053adc4385 Content-Type: text/plain; charset=UTF-8 It appears 3DES is not supported in TLS 1.3. I would still support a "diediedie" RFC banning its use in previous versions of TLS, despite its previous MTI status. On Wed, Aug 24, 2016 at 7:34 PM, Tony Arcieri wrote: > On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk wrote: > >> Well, there is >> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 >> but it is not really what you are looking for, I think, given the >> recipient list on the message. > > > I am particularly interested in 3DES's usage in TLS, given its previous > MTI status in TLS, and because it was until very recently included in the > OpenSSL "DEFAULT" ciphersuite list. > > -- > Tony Arcieri > -- Tony Arcieri --94eb2c14acf267c1d0053adc4385 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It appears 3DES is not supported in TLS 1.3.

I would still support a "diediedie" RFC banning its use in = previous versions of TLS, despite its previous MTI status.

On Wed, Aug 24, 2016 a= t 7:34 PM, Tony Arcieri <bascule@gmail.com> wrote:
On Wed, Aug 24, 2016 at 7:31 PM, Benj= amin Kaduk <kaduk@mit.edu> wrote:
Well, there is
https://tools.ietf.org/html= /draft-kaduk-kitten-des-des-des-die-die-die-00
but it is not really what you are looking for, I think, given the
recipient list on the message.

I am = particularly interested in 3DES's usage in TLS, given its previous MTI = status in TLS, and because it was until very recently included in the OpenS= SL "DEFAULT" ciphersuite list.
=C2=A0
--
T= ony Arcieri



--
Tony Arcieri
--94eb2c14acf267c1d0053adc4385-- From nobody Wed Aug 24 19:41:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D824212D79E for ; Wed, 24 Aug 2016 19:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB0YyX-yShji for ; Wed, 24 Aug 2016 19:41:15 -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 295D812D627 for ; Wed, 24 Aug 2016 19:41:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E76E0BE77; Thu, 25 Aug 2016 03:41:11 +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 hphZ_9MAUUSs; Thu, 25 Aug 2016 03:41:10 +0100 (IST) Received: from [192.168.138.252] (unknown [58.251.152.17]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0630DBE39; Thu, 25 Aug 2016 03:41:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472092870; bh=a/L/OBXxpeyXHoMHzIhAwnhJGPPbaB/JbeOUoYV7LD4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=h+16mHHkZaargdY3Y2XCDbII5hJ5JGeq4K9me+yESLH5cJOk3AINux0p4ZbSNGiil 49Baxt7vnE5VTXw3ECjV/YLRd5aoGbo8W6iU0bVuno3m0TcB1jjhKXH4v9L58OvYjM XJVHZM4j9bIPblsEaK/I6vJDucUz7whtDn6t1x/o= To: Tony Arcieri , Benjamin Kaduk References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 25 Aug 2016 03:41:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070702030107030506090202" Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 02:41:24 -0000 This is a cryptographically signed message in MIME format. --------------ms070702030107030506090202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 25/08/16 03:34, Tony Arcieri wrote: > > https://sweet32.info/ Nice work. > On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk wrote: >=20 >> Well, there is >> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die= -00 >> but it is not really what you are looking for, I think, given the >> recipient list on the message. >=20 >=20 > I am particularly interested in 3DES's usage in TLS, given its previous= MTI > status in TLS, and because it was until very recently included in the > OpenSSL "DEFAULT" ciphersuite list. I guess there's sometimes value in those die-die-die RFCs. Given that we have RFC7525/BCP195 [1] that already has a SHOULD NOT for effective key sizes less than 128 bits, one could argue that the IETF has covered that to a reasonable extent, in terms of RFCs saying to not do that. But, if there was general support for such a draft, I'd be fine with figuring out how to help get it done. Cheers, S. [1] https://tools.ietf.org/html/rfc7525 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms070702030107030506090202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MjUw MjQxMDJaMC8GCSqGSIb3DQEJBDEiBCCfznxXmhfAUGkxRz9ZlyTNry0fZMYRt8nv86AhNR7V mDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBWnGf4o1/u1ZC/2od94FcWKD2Gh11layN703WsC4mWyo5tPlGaEFJh Lceqo9n9Cj/Cgsql2d/EKCAqojMIM0HcqyCL6pxgCN24GyMA8K5CR762GCc93jcrah28MDsg gIMEJ56C8dG/7rmgAPMPx45d5k6lMZ5Ud+j/OQpqZtd4EXRM/KY913eSpmVyhlwP5SQU65bZ 8utF6qFjW1VCZ374oV9vd4QeOpjHdD6U5m0xL2BA2ceY30RZnWh75mclOXVPSdAaY+M160Lf LJln26U+4JRT0IRZTvHGaz8mb78wpGA+q/Hy3u2vtazOZXcjs8T93BjjoWsfP0ve6DSFg1dZ AAAAAAAA --------------ms070702030107030506090202-- From nobody Wed Aug 24 19:50:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5DE12D1CA for ; Wed, 24 Aug 2016 19:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFS6ogZRw050 for ; Wed, 24 Aug 2016 19:50:31 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08EE612D59B for ; Wed, 24 Aug 2016 19:45:19 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id k90so61867724uak.1 for ; Wed, 24 Aug 2016 19:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hn00D9QQHLz/yljPkZx8HMPy8XtOG7JuroMfJ5J9fZE=; b=HKEkl9ZSH8OBncA/yWbJK3Rt0H5a63M8VzxPrkJq4n7GbMYKmSNbeNozprknCIHurT f94aZNL01JpCNUPK9xZAR65o7iE04B98C0LHeW0+HKbLkiMLG1BoRR97+jpeFj8MIZdr oswDU2PJabWS6l3TY8SbfwBQMxtMpRhvJw6RWsjAYXXP2VQqFEkNwnahX9FS0hvH+cYD jcMZNgdF5nHNEQQasy+JpqnsJauVRJ65a+Wf/e0F3KgW5Q5YgFldxiAlIk9gy9dDQSze yyTq//TrFY71ePXFr9sRA0Q/F1CFfw2cXyTy+5MPL6F8+8SvHc8Lq/DBbOxBbUreoJX5 +iZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hn00D9QQHLz/yljPkZx8HMPy8XtOG7JuroMfJ5J9fZE=; b=E+CuFIh6Y+SYgB0omzgOCi0N0iovOAd29iYEAch+UzKPHJgPvTwGFY8fNGPC2FpNcA wZ/tuYY+1R4nQaqZszV7BweOGUKYxMCTMDCFFN8LKXm3lgV5PflVFwUz9YpgnMtvEl8b 4X/MAllx0OqD6uQG/eSTDE/yjGd0ktWEu8eGTZAfxwVGW6tTq9cY/hyFTHPznFx4l4Ot IhMSMC6e7NGWSdvO/r4sJSiPyrNnbsFzQkIMQYjhf8A307NYTlhUnuJxqKFh6hdl/cF7 ff9qMBd/EJt5fA+QgUE8ELmPaUMQia5NLrt95NCE/pIh3UhuY1SINWHHdqEyNi0UNL8w 4/6g== X-Gm-Message-State: AE9vXwMmPLDLVpvF5x2ik/8EwaORS7E8TQJFV+0WnWuXyr9N8VX4fAwY9+tFfLSc0rLY3bXmP3CtyQkvigrkeA== X-Received: by 10.176.81.100 with SMTP id f33mr583389uaa.141.1472093118221; Wed, 24 Aug 2016 19:45:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Wed, 24 Aug 2016 19:44:57 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 24 Aug 2016 19:44:57 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c1914ba635303053adc630d Archived-At: Cc: "cfrg@irtf.org" , Benjamin Kaduk , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 02:50:32 -0000 --94eb2c1914ba635303053adc630d Content-Type: text/plain; charset=UTF-8 On Wed, Aug 24, 2016 at 7:41 PM, Stephen Farrell wrote: > On 25/08/16 03:34, Tony Arcieri wrote: > I guess there's sometimes value in those die-die-die RFCs. Given that > we have RFC7525/BCP195 [1] that already has a SHOULD NOT for effective > key sizes less than 128 bits, one could argue that the IETF has covered > that to a reasonable extent, in terms of RFCs saying to not do that. Yes, aside from the 64-bit block size the the 112-bit (or sometimes 108-bit) key sizes are also notable for 3DES -- Tony Arcieri --94eb2c1914ba635303053adc630d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 24, 2016 at 7:41 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
On 25/08/16 = 03:34, Tony Arcieri wrote:
I guess there's sometimes value in those = die-die-die RFCs. Given that
we have RFC7525/BCP195 [1] that already has a SHOULD NOT for effective
key sizes less than 128 bits, one could argue that the IETF has covered
that to a reasonable extent, in terms of RFCs saying to not do that.

Yes, aside from the 64-bit block size the the 112= -bit (or sometimes 108-bit) key sizes are also notable for 3DES
=

--
Tony Arcieri
--94eb2c1914ba635303053adc630d-- From nobody Wed Aug 24 19:59:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FF812D127 for ; Wed, 24 Aug 2016 19:59:27 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL_mmTagvIf0 for ; Wed, 24 Aug 2016 19:59:26 -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 5DA3B12D1B1 for ; Wed, 24 Aug 2016 19:59:25 -0700 (PDT) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id CFB47284D97; Thu, 25 Aug 2016 02:59:23 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 24 Aug 2016 22:59:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 02:59:27 -0000 > On Aug 24, 2016, at 10:34 PM, Tony Arcieri wrote: >=20 > I am particularly interested in 3DES's usage in TLS, given its = previous MTI status in TLS, and because it was until very recently = included in the OpenSSL "DEFAULT" ciphersuite list. For the record, it is only removed from the "DEFAULT" ciphersuite list = in tomorrow's (US/Eastern, today already for folks in Europe) 1.1.0 = release. In the 1.0.x releases it will change from "HIGH" to "MEDIUM", but = remains in "DEFAULT". Users who elect just "HIGH" ciphers will not use 3DES, = but those who go with "DEFAULT" or explicitly include "MEDIUM" will = generally continue to enable 3DES as a low preference ciphersuite. https://www.openssl.org/blog/blog/2016/08/24/sweet32/ My personal take is quoted in: = http://arstechnica.com/security/2016/08/new-attack-can-pluck-secrets-from-= 1-of-https-traffic-affects-top-sites/ "We're not making a fuss about the 3DES issue, and rating it 'LOW'," Dukhovni wrote. "The 3DES issue is of little practical consequence at this time. It is just a matter of good hygiene to start saying = goodbye to 3DES." I am not opposed to a "diediedie" RFC, if that is likely to be helpful. For TLS, this ciphersuite is already comparatively rare, and perhaps its disappearance will not be sped up by a "diediedie" RFC? Would an RFC help to prod vendors into action more than the already published = findings? Would our collective energies be better focused on other, more pressing goals? --=20 Viktor.= From nobody Wed Aug 24 20:28:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1B12D5A2 for ; Wed, 24 Aug 2016 20:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiuacrBwpX3l for ; Wed, 24 Aug 2016 20:28:07 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8212212D630 for ; Wed, 24 Aug 2016 20:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472095687; x=1503631687; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Bow7FQL0B68TP6a/ibo3zU26RBAzqqjRXm7ixNdYfFY=; b=YcvoSN0Ihaflq7bluyT0LypkYbahAau3O5b4hk2T+1BzwmraIbVHkBYf 6uQIFnkHc/PAEjMgcG9ah4gqt9CyIsHMEvjsfJkzHKFRzS8qg/iJJd7Q+ jBvedLLylGqPk8P0TCi5uqdyro/6Vhr1M+VVAubjQdAmacHb8qs8r1/O1 I92n3Mq75kVmFp5lrkaoWDHyYcBZyaPoQw3vgC9bmPloLjG6vEKy2yZ97 UPUTRXvC7betcP3VdOu0KQcy3nOEfOBZ7vAqpuFCbFqgTfYH6w5dwAinA OzKtBQoHdpOUgUAGXHzHnpWBg9X3U69u8xMk1dggshyjD2dC79sZh0mvE A==; X-IronPort-AV: E=Sophos;i="5.28,573,1464609600"; d="scan'208";a="103440125" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Aug 2016 15:28:04 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Thu, 25 Aug 2016 15:28:04 +1200 From: Peter Gutmann To: Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [TLS] 3DES diediedie Thread-Index: AQHR/nYBgGFjWg5clEOyDz4J8naNqqBZBEfx Date: Thu, 25 Aug 2016 03:28:03 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D01F6E@uxcn10-5.UoA.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 03:28:10 -0000 Tony Arcieri writes:=0A= =0A= >Should there be a 3DES "diediedie"?=0A= =0A= Only if there's an actualy issue. 3DES is still very widely supported =0A= (particularly in financial systems and embedded), and provides a useful=0A= backup to AES. An attack that recovers cookie if you can record 785GB=0A= of traffic isn't anything I'm losing any sleep over.=0A= =0A= Peter.= From nobody Wed Aug 24 20:38:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3836512D5C5 for ; Wed, 24 Aug 2016 20:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVxAReEeJ6vz for ; Wed, 24 Aug 2016 20:38:09 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 0F71C12D0B0 for ; Wed, 24 Aug 2016 20:38:09 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id k90so63328875uak.1 for ; Wed, 24 Aug 2016 20:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L0/J7IBG4p1Okp7VDG2HErfRhXz/SMdjWyO88gYSHXU=; b=DibTq7wnU3Tp2mGz6/qO7m/od4DmwBc5b9TrNWj0IAZ4g2RSnHqsjYZrRtkpalCiIN OBzdMXN+7YeLZ0gMIyzNoA4/tTJkOqe2QDpVn/IzzGwJoJs6myYHiqbd4PWz/1G3/Wfl RxSqGavK+Us1XAg1v0JufpWBCfislViWlUf0svZS5Q6K9JPafpC7sVA8xJ9gUwOa/Bp9 iH90tcOCL/jSxXi6jUTW7Z+i9Atpcl+lBiHca1Nk+1UnCqmf3FPHGnjq3tkm9ARTMhWE Nlr4e0z/Yp04hglERjRmdcFzwtJKoZZlEbtOqScjIEUgiPWh83U7ed7kCgwYZ5yQ66zc jCdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L0/J7IBG4p1Okp7VDG2HErfRhXz/SMdjWyO88gYSHXU=; b=advUs9EGaHKYh9yzi+v00BlWq8PPBY7j+mBWU27PN5Woc0uBvaX5NEOskusmvBJn6B 9/iIkKQTJWQt8c+DF7TAf2fIFTa3+zhAB62NfQU6HCBW1TBzkuCkvpwl/pskEiESQ4MA Yx+2s3QDLGPv3m+/teFkne3doapP8SjUupUSPxxeZa8iO5QHNgiA3grtuGxG5ArHeAKi 8VP8a38Z8GEVVOWvhYVAyYBhmDpCd4g3iyYWY1ZmItqoY/QV2Oxf6iXq+Q/LWcEn/SH2 lrX74kordooDV9wNOcXwQeZ7BkYOkzwY0PJpBF07LkIiCWyMLOO9Pobhm9g/P6kmB/31 mdLw== X-Gm-Message-State: AEkooutqjjaUc/jqHlwvtPWlCl/Yeaw6RbOs03HcX0o20pYhFRYHM3RkOWrUiBAkO+6iaTWDp6avWhDWJq2sjw== X-Received: by 10.31.110.135 with SMTP id j129mr3700537vkc.81.1472096288166; Wed, 24 Aug 2016 20:38:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Wed, 24 Aug 2016 20:37:47 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D01F6E@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D01F6E@uxcn10-5.UoA.auckland.ac.nz> From: Tony Arcieri Date: Wed, 24 Aug 2016 20:37:47 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=94eb2c14acf2551280053add208e Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 03:38:10 -0000 --94eb2c14acf2551280053add208e Content-Type: text/plain; charset=UTF-8 On Wed, Aug 24, 2016 at 8:28 PM, Peter Gutmann wrote: > Only if there's an actualy issue. 3DES is still very widely supported > (particularly in financial systems and embedded) As someone who works professionally in the payments industry alongside people who are directly implementing EMV protocols, let me note: those are not IETF protocols and should not have bearing on IETF/IRTF decisions regarding deprecations of protocols in TLS or other IETF protocols. But I'm mainly concerned with TLS... and provides a useful backup to AES. So does ChaCha20. > An attack that recovers cookie if you can record 785GB of traffic isn't > anything I'm losing any sleep over. ..but is not a terribly dissimilar traffic volume to recover plaintexts from similar attacks against RC4, which received "diediedie" in RFC7465. Perhaps notable is the RC4 attacks work across multiple session keys, whereas SWEET32 requires the same key, but I think the practical consequences regarding data volume limits are similar. -- Tony Arcieri --94eb2c14acf2551280053add208e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 24, 2016 at 8:28 PM, Peter Gutmann <pgut001@cs.auckland.ac= .nz> wrote:
Only if there&#= 39;s an actualy issue.=C2=A0 3DES is still very widely supported
(particularly in financial systems and embedded)

As someone who works professionally in the payments industry alongsid= e people who are directly implementing EMV protocols, let me note: those ar= e not IETF protocols and should not have bearing on IETF/IRTF decisions reg= arding deprecations of protocols in TLS or other IETF protocols. But I'= m mainly concerned with TLS...

and provides a useful=C2=A0backup to AES.

So does ChaCha20.
=C2=A0

..but is not = a terribly dissimilar traffic volume to recover plaintexts from similar att= acks against RC4, which received "diediedie" in RFC7465.

Perhaps notabl= e is the RC4 attacks work across multiple session keys, whereas SWEET32 req= uires the same key, but I think the practical consequences regarding data v= olume limits are similar.

--
=
Tony Arci= eri
--94eb2c14acf2551280053add208e-- From nobody Wed Aug 24 21:23:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A825012D58A for ; Wed, 24 Aug 2016 21:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2iAG8xWO1l3 for ; Wed, 24 Aug 2016 21:23:56 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id C511712D1AD for ; Wed, 24 Aug 2016 21:23:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id DDC8BF468; Thu, 25 Aug 2016 07:23:53 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id QFjaJ1RjudIq; Thu, 25 Aug 2016 07:23:53 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 935CD2310; Thu, 25 Aug 2016 07:23:53 +0300 (EEST) Date: Thu, 25 Aug 2016 07:23:44 +0300 From: Ilari Liusvaara To: Keith Winstein Message-ID: <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: ilariliusvaara@welho.com Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 04:23:59 -0000 On Wed, Aug 24, 2016 at 04:01:45PM -0700, Keith Winstein wrote: > Hi Subodh, > > Interesting points. > > On the form of the generation identifier: The draft does already > specify the generations as integers (traffic_secret_N, N+1, etc.), and > the semantics of a KeyUpdate are that when you receive one, you > increment the generation of the receive key. So the proposed > "receive_generation" field is really just echoing the generation > number back. I could imagine a different system where the KeyUpdate > instead includes an opaque identifier, and the receiving > implementation is then supposed to echo back the most recent opaque > identifier that it got. That would also provide Property P3, and so I > would be totally fine with it. But now we're talking about adding > *two* fields to a KeyUpdate (the sender's opaque identifier, and also > an echo of the most recently received opaque identifier), instead of > one field, so I'd be surprised if there were more consensus around > this alternate approach! The generations are not specified as integers. It is just some abstract sequence (nowhere in protocol is that generations are integers used). And echoing identifiers doesn't work. The key updates can cross in flight, so neither is after one another. > On the API that a TLS implementation would expose: Obviously the WG > doesn't have to specify this, but here are three APIs I could imagine: > > (1) No change to current APIs. The TLS implementation itself triggers > KeyUpdate when it wants to (e.g. per recommendation on when the > underlying cipher wants to be rekeyed), but doesn't expose this to the > application. The intended application of KeyUpdate is mostly this, with optional knobs controlling the frequency of rekeying. > (2) Fire-and-forget. The TLS implementation exposes a > `rekey_session()` function, which initiates a KeyUpdate. [If we adopt > the proposal described earlier in this thread, maybe there's a boolean > parameter about whether to request a reciprocal rekey from the other > side...] Due to design, one can't do a reciproal rekey. > (3) Fire-and-later-check. The TLS implementation exposes #2 above, but > also `tls_session_generations()`, which returns a pair of integers > giving the current sending and receiving generations. > > Any application we might want to build can be built on top of #3. Nope, the KeyUpdate is designed to deal with arbitrary latency in order to fully decouple the direction (any coupling there would lead to API problems, which apparently are more major than I initially thought). And if that is combined with request-response protocol, if you just send a KeyUpdate without application data, the response will NEVER come. -Ilari From nobody Thu Aug 25 02:54:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4658612D50B for ; Thu, 25 Aug 2016 02:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBD_HWP3gIdi for ; Thu, 25 Aug 2016 02:54:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C99012D1BD for ; Thu, 25 Aug 2016 02:54:27 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-71-57bec04fbe3f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 87.B3.06563.F40CEB75; Thu, 25 Aug 2016 11:54:26 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.215]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 11:54:23 +0200 From: John Mattsson To: Peter Gutmann , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] [TLS] 3DES diediedie Thread-Index: AQHR/raoCiRg5YveN02k55l7inXbrw== Date: Thu, 25 Aug 2016 09:54:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <20599B78BF824247A503E60AB1AD6753@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdUTfowL5wg7kbZS0uPW5hsuj+cZDJ 4uW756wWn853MTqweFxsPMDksXPWXXaPJUt+MnlM3niYLYAlissmJTUnsyy1SN8ugSujbe8D xoJPfBX77u5ibWA8wNfFyMkhIWAicejxWsYuRi4OIYH1jBLHPx5hA0kICSxhlHh8UBXEZhMw kJi7p4ENpEhEYCqjxK0lB1lBEsICGhJLr25lBLFFBDQl+r49Y4Gw9SSWnZgOZrMIqEpcXP2N qYuRg4NXwFziZ2coSJhRQEzi+6k1TCA2s4C4xK0n85kgDhKQWLLnPDOELSrx8vE/sFWiQCOf nVzMCBFXklh7eDsLyEhmoLXrd+lDmNYSZ3bLQkxUlJjS/ZAdxOYVEJQ4OfMJywRGkVlIls1C aJ6F0DwLSfMsJM0LGFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG0cEtv3V3MK5+7XiI UYCDUYmHd8GDveFCrIllxZW5hxglOJiVRHjv7tsXLsSbklhZlVqUH19UmpNafIhRmoNFSZzX /6ViuJBAemJJanZqakFqEUyWiYNTqoGx1ECP/UXTsgNvpr16oXuxyPbW0r/iBUa9XNF39Hzu zjLn1Yzsnvbs8q5jraKb33oZ9JVNMzITPRDuPu/Qny/Hpm1apPtALEjnx6E9AS63r2vXWn1g kgqctHdSQXby+T95jKYfP+sERjn5JhbV9hl43+mIY+oLvBD1u/qweYoce3fLlZff2l4rsRRn JBpqMRcVJwIA5T45sZ8CAAA= Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 09:54:32 -0000 SSB0aGluayB0aGUgcmVjZW50bHkgcHVibGlzaGVkIGF0dGFjayBoYXMgbW9yZSB0byBkbyB3aXRo IGJhZA0KaW1wbGVtZW50YXRpb25zL3NwZWNpZmljYXRpb24gdGhhbiBhIG5ld2x5IGRpc2NvdmVy ZWQgd2Vha25lc3MgaW4gM0RFUy4NClRoYXQgeW91IHNob3VsZCBuZXZlciBlbmNyeXB0IGFueXRo aW5nIG5lYXIgMl4zMiBibG9ja3MgaXMgd2VsbCBrbm93biAoYnV0DQpJIGRvbuKAmXQga25vdyBo b3cgd2VsbCB0aGlzIGlzIGV4cGxhaW5lZCBpbiBOSVNUIG9yIElFVEYgc3BlY2lmaWNhdGlvbnMs IGlmDQphdCBhbGwpLg0KDQpJIGFtIHZlcnkgc3VwcG9ydGl2ZSBvZiBldmVyeXRoaW5nIHNwZWVk aW5nIHVwIHRoZSBkZXByZWNhdGlvbiBvZiB3ZWFrDQphbGdvcml0aG1zIGFuZCBwcm90b2NvbHMs IGJ1dCAgdGhlbiBJIHRoaW5rIENGUkcgc2hvdWxkIG1ha2UgYSBicm9hZGVyDQphcHByb2FjaCBh bmQgbG9vayBhdCBtb3JlIGNhbmRpZGF0ZXMgZm9yIGdlbmVyYWwgZGVwcmVjYXRpb24gbGlrZSBT SEEtMQ0Kc2lnbmF0dXJlcywgMTAyNC1iaXQgTU9EUCwgYW5kIDEwMjQtYml0IFJTQeKApiBJIHRo aW5rIGFsbCBvZiB0aGVzZSBhcmUgZmFyDQp3ZWFrZXIgdGhhbiAzLWtleSAzREVTLg0KDQpNYWtp bmcgc3VyZSB0aGF0IElFVEYgcHJvdmlkZXMgZ29vZCBpbXBsZW1lbnRhdGlvbiBndWlkZWxpbmVz IGFuZA0KcmVxdWlyZW1lbnRzIGZvciBhbGwgY2lwaGVycyBtaWdodCBiZSBhcyBpbXBvcnRhbnQu DQoNCi9Kb2huDQoNCg0KT24gMjUvMDgvMTYgMDU6MjgsICJDZnJnIG9uIGJlaGFsZiBvZiBQZXRl ciBHdXRtYW5uIg0KPGNmcmctYm91bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYgb2YgcGd1dDAwMUBj cy5hdWNrbGFuZC5hYy5uej4gd3JvdGU6DQoNCj5Ub255IEFyY2llcmkgPGJhc2N1bGVAZ21haWwu Y29tPiB3cml0ZXM6DQo+DQo+PlNob3VsZCB0aGVyZSBiZSBhIDNERVMgImRpZWRpZWRpZSI/DQo+ DQo+T25seSBpZiB0aGVyZSdzIGFuIGFjdHVhbHkgaXNzdWUuICAzREVTIGlzIHN0aWxsIHZlcnkg d2lkZWx5IHN1cHBvcnRlZA0KPihwYXJ0aWN1bGFybHkgaW4gZmluYW5jaWFsIHN5c3RlbXMgYW5k IGVtYmVkZGVkKSwgYW5kIHByb3ZpZGVzIGEgdXNlZnVsDQo+YmFja3VwIHRvIEFFUy4gIEFuIGF0 dGFjayB0aGF0IHJlY292ZXJzIGNvb2tpZSBpZiB5b3UgY2FuIHJlY29yZCA3ODVHQg0KPm9mIHRy YWZmaWMgaXNuJ3QgYW55dGhpbmcgSSdtIGxvc2luZyBhbnkgc2xlZXAgb3Zlci4NCj4NCj5QZXRl ci4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkNm cmcgbWFpbGluZyBsaXN0DQo+Q2ZyZ0BpcnRmLm9yZw0KPmh0dHBzOi8vd3d3LmlydGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2ZyZw0KDQo= From nobody Thu Aug 25 03:01:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AD212D758 for ; Thu, 25 Aug 2016 03:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7InxXHTHFjI2 for ; Thu, 25 Aug 2016 03:01:11 -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 79D9712D7C9 for ; Thu, 25 Aug 2016 03:01:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 98FC7BE75; Thu, 25 Aug 2016 11:01:09 +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 9oAFwNiH_S1t; Thu, 25 Aug 2016 11:01:05 +0100 (IST) Received: from [192.168.138.252] (unknown [58.251.152.17]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E30CCBE5C; Thu, 25 Aug 2016 11:01:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472119265; bh=LQbsTgbfxps/RWcd3zTXloUKCfI4Ut/Lchs40/UDE5g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FNJ+hxsegu37ThZV+cpu4P1vRSf8GfcQ0QD4KctPX0E3EiJ6nq0jVBxGHQKQkE3WC HeYzVeRTPkC/LC0QRNfG56liK9Or+8wjwZ8RD7qzYkZOG30fS5qpyPjnUUwPa6bM7w iSnI3jZ2p+zBsLOuM2E1ZGh1YzvBcvkAzHINOHOY= To: John Mattsson , Peter Gutmann , Tony Arcieri , "" , "cfrg@irtf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1c39a2c0-3338-7941-a7d8-8d9535c0ccfc@cs.tcd.ie> Date: Thu, 25 Aug 2016 11:00:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000209080809070202060605" Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 10:01:23 -0000 This is a cryptographically signed message in MIME format. --------------ms000209080809070202060605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 25/08/16 10:54, John Mattsson wrote: > I think the recently published attack has more to do with bad > implementations/specification than a newly discovered weakness in 3DES.= > That you should never encrypt anything near 2^32 blocks is well known (= but > I don=E2=80=99t know how well this is explained in NIST or IETF specifi= cations, if > at all). >=20 > I am very supportive of everything speeding up the deprecation of weak Just in case folks haven't considered it, the "d" in the name of the IETF's curdle WG [1] stands for deprecation. Obviously that has to be done with care and consideration, but there is a generic venue where folks can propose that kind of thing. Cheers, S. [1] https://tools.ietf.org/wg/curdle/ > algorithms and protocols, but then I think CFRG should make a broader > approach and look at more candidates for general deprecation like SHA-1= > signatures, 1024-bit MODP, and 1024-bit RSA=E2=80=A6 I think all of the= se are far > weaker than 3-key 3DES. >=20 > Making sure that IETF provides good implementation guidelines and > requirements for all ciphers might be as important. >=20 > /John >=20 >=20 > On 25/08/16 05:28, "Cfrg on behalf of Peter Gutmann" > wrote: >=20 >> Tony Arcieri writes: >> >>> Should there be a 3DES "diediedie"? >> >> Only if there's an actualy issue. 3DES is still very widely supported= >> (particularly in financial systems and embedded), and provides a usefu= l >> backup to AES. An attack that recovers cookie if you can record 785GB= >> of traffic isn't anything I'm losing any sleep over. >> >> Peter. >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms000209080809070202060605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MjUx MDAwNTRaMC8GCSqGSIb3DQEJBDEiBCCijMIJsVZwFXHUIPqLX9cAh9FCNTQrmtrMUbNZdnG3 8TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAuDyO1BJoDZaea9D6wgAp4elQ2WNVQJGua07KWwxNIIlfq/c0hSCxv GMj/PdwVbs6249JjTGPDvPWVfzVaQpNalob0BuIm8BzNP0iiWuMXdT8Ti1xWH/3HFV/G/5by a1iwPEsuNEVguWNbAUj/phNeKjvd1/31Tt0XBnceGLHJ7cQXSW+eQlilErDRT9o4NUc1nFeN LCtxu26O2ss2hCMtBLYJzQXTV1Kwml6FGoI+BP4yI1EG6NbokGw9W1xZhDlfsXeARgVHIzhg dn3rM2SRfJJ1ZMfZT1titsLGzWiAGiPuyqHJXtYEWIcCMdt7RNJ4lEYAl2b5DLEBfDXphttH AAAAAAAA --------------ms000209080809070202060605-- From nobody Thu Aug 25 03:33:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1967712D7E0 for ; Thu, 25 Aug 2016 03:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT66nGA0yG5n for ; Thu, 25 Aug 2016 03:32:59 -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 F3BE912D7DF for ; Thu, 25 Aug 2016 03:32:58 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 654C3C057FA5; Thu, 25 Aug 2016 10:32:58 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7PAWueT016761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2016 06:32:57 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 25 Aug 2016 12:32:56 +0200 Message-ID: <6377217.GbyXToEj0o@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1918730.S5z2hGlNiR"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 25 Aug 2016 10:32:58 +0000 (UTC) Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 10:33:01 -0000 --nextPart1918730.S5z2hGlNiR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 24 August 2016 22:59:23 CEST Viktor Dukhovni wrote: > I am not opposed to a "diediedie" RFC, if that is likely to be helpful. > For TLS, this ciphersuite is already comparatively rare, and perhaps its > disappearance will not be sped up by a "diediedie" RFC? Would an RFC > help to prod vendors into action more than the already published findings? > Would our collective energies be better focused on other, more pressing > goals? People that care for support of Windows XP or Windows 2003 will use 3DES=20 either way. People that don't care about those OSes, are probably already=20 doing everything to not negotiate it, if only to conserve TLS terminator=20 resources. When RC4 die-die-die was published, a lot of servers negotiated RC4 (becaus= e=20 of BEAST), it's not the case with 3DES. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1918730.S5z2hGlNiR 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 iQIcBAABCgAGBQJXvslYAAoJEJKo0bgB0vX1iOMP/0/2DSTzsZ33ZWZVlRGYhfIn 03mloZ/uC5xE60oe4EobrsAPTp6QfbQoalArY2gtRFUbwUuT53brAUtFxmBFnG0I 5CKTr/vH4cvDixve/jqAjVyWB9E6a/2bezp5AUt/8gX34jZFvZzOpVvY1cggM7cc HpNVeaYokh5BkTQpS9zEnUXOu57Fp2roDViNQHNZhGtY0NDFxVqy0oTmQc0Rvooh p6t9RNqGJ8VQ1pCDShMtfVZhbXgOTPEOvFKvV1ZOJLmr3Oqyd8osOuN293rweNky XlPscunea6Hefohfu1+oInqfBb45NdS4lxKGTrNQBY1zcZ1N8eY9r46miwp84153 BeDBD5dh4tWlaL2+KxVfPfCDTe1lhIdOtDNSRNTP+I4CvpFDL8MzK2gabZq/18s1 GDt9arhsqbBvPbMbGCNHI/4VPp/T2r4w0X2dwXYrIvqJfbSt9xK4E2gUc8x8nJhm mttxM1Y4DJxxrJgfF78lixs1K1KM2QOMFOOHxotlbwCye1fnZIIUURpRORBkmxzm c5HT1GHqQXxMMmwEvcPQPjioVU+r41s4bk4AK70W3C1sOEHfYYrGeGz7kz7KVz+f 2egVeslrxDEleuLEVJ5LGhA7lbhMMNYKjiV1C61NycgSeXoPkPfxGwV1CKk2mp2i ITUV48kXNhvSImsPbT62 =rPU5 -----END PGP SIGNATURE----- --nextPart1918730.S5z2hGlNiR-- From nobody Thu Aug 25 06:22:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB06712D0BB for ; Thu, 25 Aug 2016 06:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjVdUYyHiRZK for ; Thu, 25 Aug 2016 06:22:01 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10C712B007 for ; Thu, 25 Aug 2016 06:22:01 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id e63so270785391ith.1 for ; Thu, 25 Aug 2016 06:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3mrTyCfR0wXrPfucftoPZJXlzq3oM0ChYSixFDRXoLI=; b=VVlJgyOV81qPxNR7xLO3/KnM0ehAVEKzBamZepdV98lpW+92jlDdwb3D03yD6UOHgd mbMJ/HPl4oUAFAGuE+quqUZ058A7MzZKi4Qf6V1tmRR9abJlLh9PM47SQ/zYY6eo7TED O56tHAe6bIJWhi/nHDTiKZU5BjWbSsf1wx7XNdWuYWccEIvqP4mapWL65KvXcbxdjx2a Tw+ktd+vgJGysqe/VjGRURsTq2wGSHf/45mp4wmGccH8bdF+Fh2aY+KaIdXYq+QVHk08 3Nb1EVBkh953nNABUeNmi1Vw6s1l2udKxoUpr+Yk75wXBL9kqzTTpe1zU/D+/DJFuAky treQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3mrTyCfR0wXrPfucftoPZJXlzq3oM0ChYSixFDRXoLI=; b=Sg8CU3DAhVW9zw61k/8l/ooxyyFq9HRQqmmem5oduKRTqDpEX2WD+lRKiryJZFUbrf LCWAQtZkLxwFueFXLj22MC5JKk/GpMUIOSfiXNJezueKWz+RS82QTuIxcczl7Isow5JL UGgT3IXRvBNr9HnFp9cUIsMny4O6xRTbzvCKUtXDUr3kfXPWVMZ2IPQcUo/41KFxMlhe sBK5LpB+POOiWzRoPUbDdaaASZVFXIiNZTgs9+j/+G/DSqW2tr7ZL8c9EaUOI3dsmk8S /kvdfiUSBStvLdLT2+QfeN7nGoE3tYdlfCREwB4Run8MkOVuVD2p7x+q8kd8SFFdkdKf cR6w== X-Gm-Message-State: AEkoouviUH5YpN2qRkGor2Kefu2ernRRjQS7AZQGnQZsaZ/sYCD/fa9KLr6o05RzxOs9QA== X-Received: by 10.36.225.72 with SMTP id n69mr4925899ith.16.1472131321043; Thu, 25 Aug 2016 06:22:01 -0700 (PDT) Received: from ?IPv6:2601:240:d700:6a00:a53f:b290:e39:9cfb? ([2601:240:d700:6a00:a53f:b290:e39:9cfb]) by smtp.gmail.com with ESMTPSA id n23sm5472749ioe.18.2016.08.25.06.21.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 06:22:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: david wong X-Mailer: iPhone Mail (13G35) In-Reply-To: <6377217.GbyXToEj0o@pintsize.usersys.redhat.com> Date: Thu, 25 Aug 2016 08:21:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6933C5DD-9C84-44E0-88D4-6E3D3C9A2C78@gmail.com> References: <6377217.GbyXToEj0o@pintsize.usersys.redhat.com> To: Hubert Kario Archived-At: Cc: "cfrg@irtf.org" , tls@ietf.org Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 13:22:05 -0000 I don't think a RFC deprecating them is a good idea: * TLS 1.3 is almost here and is already doing that * what browser still use 64-bit ciphers? Who lets his "old" browser open for= 75 hours? * in other uses of TLS. It's not always obvious if there is a possible beast= style attacks. And their implementation might really well not be vulnerable= (due to limiting number of messages according to specs) David= From nobody Thu Aug 25 06:34:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0981C12D0B4 for ; Thu, 25 Aug 2016 06:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak_lAPTxVYvr for ; Thu, 25 Aug 2016 06:34:10 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D6C12D0AA for ; Thu, 25 Aug 2016 06:34:10 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id r9so29419223ywg.0 for ; Thu, 25 Aug 2016 06:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9Z3r6EIiNm0wCOXMtRS+E9/rhqcFQpLAfwYpZxbR5PI=; b=o2Lthe1IooFd/ydWj+CY1n6iZLkAft0NUP4EQotSl/hlR6y08u2sT9gEqarTOgQSlZ LgrW2iH9/dpFnzQKtgMF0d1wypqXeVGdzRuKfvEWCjDSHyvpLqXx7Wk0RY6Awhern4/U pALpZotmnwu8VByRQh83OgWWjCPmTSQSUmwcY2aNblZB9jW3g4yYz2Qwtfe5Wo/COOWQ Cn8yV9BwQitiiWrrzd+/s8S3JnoWj4IcIAA3ZKtUjUku7I1dzMK2KazhMuxQwpGoHcg3 0zjDmMrZ1OS1YkmTtUMc/Fkpz+OSU3bGYG8m7dLbJxIwIbWyODWCpz+XJxBl6xUzK0fh emuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9Z3r6EIiNm0wCOXMtRS+E9/rhqcFQpLAfwYpZxbR5PI=; b=l4aCkAYhBVz09SP4yTQk07hDIMVtrEjxMnCyCNCL/s6uhAMUjDZii+YX5lRCXEXCHB v99Oo9fzwptvXwnvwYFCQI1QuBLZWKWyQCVXtYpdeks2hxLjsuysS50GP1Ry88jIZd8v mtfYSF63Usu+TuBeaaiAvk38ICILFbjp02iwKZM+cJiKMnQtIhSb34r3HyNBGX5MEnx/ AK6L8jntRaOaa66ZdPhBUvsqy+KVjhiSA/q/sKNQS+KIZpYTmLqRN92GeUegwQQJRk61 zvbY5SUIgNaS4fY3cmcaQoiX1GICr96mlw++IbTJ8kXBtDXltLHQLciKPiITU6k9rR0G HYaw== X-Gm-Message-State: AE9vXwNYfKtIC5SMHXXShahyXeWT8ij/3PAOagKuivwITSr1Sgi4lQdUiCemkQKInuJ7TU0hARaVep6a3boWnw== X-Received: by 10.13.220.1 with SMTP id f1mr7032826ywe.289.1472132049227; Thu, 25 Aug 2016 06:34:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Thu, 25 Aug 2016 06:33:28 -0700 (PDT) In-Reply-To: <6933C5DD-9C84-44E0-88D4-6E3D3C9A2C78@gmail.com> References: <6377217.GbyXToEj0o@pintsize.usersys.redhat.com> <6933C5DD-9C84-44E0-88D4-6E3D3C9A2C78@gmail.com> From: Eric Rescorla Date: Thu, 25 Aug 2016 06:33:28 -0700 Message-ID: To: david wong Content-Type: multipart/alternative; boundary=94eb2c0809f0db89d0053ae57372 Archived-At: Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 13:34:13 -0000 --94eb2c0809f0db89d0053ae57372 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 25, 2016 at 6:21 AM, david wong wrote: > I don't think a RFC deprecating them is a good idea: > > * TLS 1.3 is almost here and is already doing that > * what browser still use 64-bit ciphers? Who lets his "old" browser open > for 75 hours? > Actually, I believe that all the major browsers support 3DES. -Ekr * in other uses of TLS. It's not always obvious if there is a possible > beast style attacks. And their implementation might really well not be > vulnerable (due to limiting number of messages according to specs) > > David > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --94eb2c0809f0db89d0053ae57372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 25, 2016 at 6:21 AM, david wong <davidwong.crypto= @gmail.com> wrote:
I don= 9;t think a RFC deprecating them is a good idea:

* TLS 1.3 is almost here and is already doing that
* what browser still use 64-bit ciphers? Who lets his "old" brows= er open for 75 hours?

Actually, I belie= ve that all the major browsers support 3DES.=C2=A0

-Ekr

* in other uses of TLS. It's not always obvious if there is a possible = beast style attacks. And their implementation might really well not be vuln= erable (due to limiting number of messages according to specs)

David
_____________________= __________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

--94eb2c0809f0db89d0053ae57372-- From nobody Thu Aug 25 06:55:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2509512D09B for ; Thu, 25 Aug 2016 06:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuwMFY7FwtXy for ; Thu, 25 Aug 2016 06:55:31 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 5558E12B03C for ; Thu, 25 Aug 2016 06:55:31 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id e63so33142285ith.1 for ; Thu, 25 Aug 2016 06:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gaCB2wQFq10USHfXhqoBjNSw1smvh8hH04eANyvyGU4=; b=fP0vBwitUL4vdJfbtjERP7lJ99Ohc55Q3g/+DusagjtZaLDycKpRXdpBT0SfE6X0Mq SnpYvhJDS9l+B4oHjJjWBzcaaXHVgkIp2d1/FHaiU2JfjvGDvPKIvtIW4kQdnyCRGONb fwCo48cOwjfbL3b5QtyHMRELOMCY0vEzNhxvPibeC9igXRqQZHv/VRNGV+WT1Hy8iCZ5 jHLdRupQYVD/9Tog9s0iA6bZTyEwr7qHAysGTpAgPttDz5SFVpLtEFihXe3CHViBROyx Mmmd1TWTcA0yueuOWiVgOqlnp2TC8MtIJnUs/PzYYn9Wl9IKA7shCqCL0ngIyXjE8rJb xOsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gaCB2wQFq10USHfXhqoBjNSw1smvh8hH04eANyvyGU4=; b=cHKfxImXZSeETo7gQ5V0aFElNeiA0nmzEdIYDlqelO1hqKckuU/55aPV91lewUqf9a sDNxBspiVk5jQRUySuDXdAsesk3Gxccs8JEnE+g+xAQuJhb3rzvTNv/YLzl72G+DWJLi mSHksyqaERAr+WktDRzdCg3vAfl/4ublENpiDTSj4q2eHa14lRcvtJ3Zn09JRko62cVC NskStlxrSNAdVkSbdm+TNb6NksLgtINNH9l/eQxulNIDvyFC+mObHZHQkqPZNpFosaPv OMGokHvso34eZijQC7KX4IN3hymTmpk0zAigEtAIHM9uCnmH8YCcdd7FLDrr9krT4IeK Ykxg== X-Gm-Message-State: AE9vXwMtT5R6BekXOO39SpWAknR4wVE1In60JtAl3t+0aRtGVbqmTTGHgUSo7U8a1tleykdvst4pUVJUbQKkLA== X-Received: by 10.36.238.134 with SMTP id b128mr5204572iti.72.1472133330708; Thu, 25 Aug 2016 06:55:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.67 with HTTP; Thu, 25 Aug 2016 06:55:10 -0700 (PDT) In-Reply-To: References: <6377217.GbyXToEj0o@pintsize.usersys.redhat.com> <6933C5DD-9C84-44E0-88D4-6E3D3C9A2C78@gmail.com> From: Ira McDonald Date: Thu, 25 Aug 2016 09:55:10 -0400 Message-ID: To: Eric Rescorla , Ira McDonald Content-Type: multipart/alternative; boundary=f403045c0e563d2fc7053ae5c069 Archived-At: Cc: david wong , "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 13:55:33 -0000 --f403045c0e563d2fc7053ae5c069 Content-Type: text/plain; charset=UTF-8 Hi, This survey of TLS in 1 million web servers shows that 93% support 3DES - oof! https://jve.linuxwall.info/blog/index.php?post/TLS_Survey 3DES hasn't quite disappeared on the Internet. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Aug 25, 2016 at 9:33 AM, Eric Rescorla wrote: > > > On Thu, Aug 25, 2016 at 6:21 AM, david wong > wrote: > >> I don't think a RFC deprecating them is a good idea: >> >> * TLS 1.3 is almost here and is already doing that >> * what browser still use 64-bit ciphers? Who lets his "old" browser open >> for 75 hours? >> > > Actually, I believe that all the major browsers support 3DES. > > -Ekr > > * in other uses of TLS. It's not always obvious if there is a possible >> beast style attacks. And their implementation might really well not be >> vulnerable (due to limiting number of messages according to specs) >> >> David >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --f403045c0e563d2fc7053ae5c069 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This survey of TLS in= 1 million web servers shows that 93% support 3DES - oof!

https://jve.lin= uxwall.info/blog/index.php?post/TLS_Survey

3DES hasn't= quite disappeared on the Internet.

Cheers,
- Ira
=

Ira McDonald (Musician / Software Architect)
Co-Chair - T= CG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing = WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO P= WG Internet Printing Protocol WG
IETF Designated Expert - IPP & Prin= ter MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com<= br>Jan-April: 579 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-009= 4
May-Dec: PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434

On Thu, Aug 25, 2016 at 9:33 AM, Eric Rescor= la <= ekr@rtfm.com> wrote:


On Thu, Aug 25, 2016 at 6:21 AM, david wong <david= wong.crypto@gmail.com> wrote:
I don't think a RFC deprecating them is a good idea:

* TLS 1.3 is almost here and is already doing that
* what browser still use 64-bit ciphers? Who lets his "old" brows= er open for 75 hours?

Actually, = I believe that all the major browsers support 3DES.=C2=A0

-Ekr

* in other uses of TLS. It's not always obvious if there is a possible = beast style attacks. And their implementation might really well not be vuln= erable (due to limiting number of messages according to specs)

David
_______________________________________= ________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--f403045c0e563d2fc7053ae5c069-- From nobody Thu Aug 25 06:58:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5741A12D13A for ; Thu, 25 Aug 2016 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.379 X-Spam-Level: X-Spam-Status: No, score=-5.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrEFoQLMx5SX for ; Thu, 25 Aug 2016 06:58:38 -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 2D3AB12D844 for ; Thu, 25 Aug 2016 06:58:34 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CD92580F6B; Thu, 25 Aug 2016 13:58:33 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7PDwWns029185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2016 09:58:33 -0400 From: Hubert Kario To: Ira McDonald Date: Thu, 25 Aug 2016 15:58:31 +0200 Message-ID: <1609779.HlDFoKz2ng@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart98146633.705ya2F7UW"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 25 Aug 2016 13:58:33 +0000 (UTC) Archived-At: Cc: david wong , "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 13:58:39 -0000 --nextPart98146633.705ya2F7UW Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 25 August 2016 09:55:10 CEST Ira McDonald wrote: > Hi, >=20 > This survey of TLS in 1 million web servers shows that 93% support 3DES - > oof! >=20 > https://jve.linuxwall.info/blog/index.php?post/TLS_Survey >=20 > 3DES hasn't quite disappeared on the Internet. but less than 0.5% will actually negotiate it, while still between 2% and 3= %=20 will negotiate RC4: https://securitypitfalls.wordpress.com/2016/08/07/april-2016-scan-results/ =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart98146633.705ya2F7UW 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 iQIcBAABCgAGBQJXvvmHAAoJEJKo0bgB0vX1V+sP/AnjR8RyhwqS+Cp5yaTpEzSk xmMcZ68MFEhZz4s6ggfuKM267Q2fll2A6pnlZwe5iYtnkpkwTAYWdSaZ1MUa/sr5 tmCcpWsJ1hmU1FX9eaDDoWJtvsrUThkO4XVD6wOdgfDcISeGo9ZhgvXY86XHePDE DIGhvLQiuGN6UsCLF6MM4cDCzJqYfcbvbWYnoJ2nOKAMjr8fPA9+46htTJso6Eg7 MwFg5/b22i2YrVtz8DZ6Iyu81bqSSB6nQ+acfjtmaRRmTPCDOUAJuV9WIsA2nk0p f+LzFpsSs3LeJTdBft1/RI1AXVLjg1HhZsdoCUJN8zZH4puCnwCbAc3RP2rin8FO Lc6SNBDMVamG1tVgcGI6JHwJl85O5JLSdB+/vOeZG9aJTNRUdQMk/M3WpUU11qce g9314X3murF7g1mo+ywQ8RPFOpWozsXQwLhB+qcMplbosrNtaMCVFwpBaU374+VV QjUIbh3NWHfmHG5PMCyA9Tgw1KkFUCxOVC9iYEMtOqv1jQZCJxLqHNQ5AZLOyCsH Wj+g1bL4io48JZpqKY1Sb9OQFPEAYuIye7NKGdXx+uK2DRuThqK12nuH8Zf85KzZ NFG8YX7osnAYunIoP5dl7Q3oGgMmq4DswitEBizPwrLsH0xpnK7BGp3MU6Ily7WB BUu9BZ59hudTwE/H9wJD =EW/T -----END PGP SIGNATURE----- --nextPart98146633.705ya2F7UW-- From nobody Thu Aug 25 12:32:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755AE12D0A0 for ; Thu, 25 Aug 2016 12:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BviXg-I0v9qd for ; Thu, 25 Aug 2016 12:32:35 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1682212B024 for ; Thu, 25 Aug 2016 12:32:35 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id u134so35830060ywg.3 for ; Thu, 25 Aug 2016 12:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eVHLi996WQLQq2p7myxKzbbth4wGWt0FRRAqqorZNKo=; b=pqkaSmQfadZJhjB6Bvqdj/mEBj2NrV2NifVPpTogiRrbnBtAsa7tW+Lp/wBB350r5k Wc/+Hi6Tu/PgwhWm+T+pdTNrppVZM1z/K7XT18eIzV4S5AB34OCNqYIA2EIPlIRIr3XC Isqrj3S6VunwXN3dkoYRsxCUCs1EdMkB4uL7+G6SOwEJ+Ep31hq7SgHi4HL2hg++lDjr FN0jwLqitjnGoi3slah6YYySUAlsAO1ELgWAWsNi6BWJL2yrLOGpMhLl7Vnm29wg4Iaf xASHwElnqtP2J6nQUdRh8sLZ6TAJq5afX6YjBO6wPRGVorTTb1uUFeqKIc6IpobFNiy6 Wrtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eVHLi996WQLQq2p7myxKzbbth4wGWt0FRRAqqorZNKo=; b=fDs4JvNFXIgz0y5ldXs181zposOPh09c4HRki9pD3FSLgkmjA6bEjjTELqjF+hlB26 yQ0Y1pce0K79vrV+6h9NuCX+v2ybNdoUCjYtiIdYuCwaXXD8uMqIR1Gac3tpv10qJUPy nwrUjlc9FusEj7hyZ6Ob4q50tRLJ1QWWiEEBT++skno+BngWrkHkUxk7IWGskFSr2Cqe XmF0j9R3Y8tkmhb1at+Z3ABuY7tV42Yf27PCJ+McPtM+JbEFwwP85etXL3PCLk+g8zb3 zrX1E/XV4abKVjwrCGSWG14WvfxEvzvZo4SSKZHOFl7PcDHPc7vVVzuXgIBPdRwFD/m9 aEqw== X-Gm-Message-State: AE9vXwNqjpqOVh3+jDFlss0+glTy2vmRCUYKSCj/By+BzEhnOAPDy2fpvGUkug6Wr62y8K/3EH7EKPVh8RCQMA== X-Received: by 10.129.102.193 with SMTP id a184mr9344892ywc.63.1472153554271; Thu, 25 Aug 2016 12:32:34 -0700 (PDT) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.129.79.209 with HTTP; Thu, 25 Aug 2016 12:31:53 -0700 (PDT) In-Reply-To: <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> From: Keith Winstein Date: Thu, 25 Aug 2016 12:31:53 -0700 X-Google-Sender-Auth: 46klo0JGB27DbEsAsPCeKpnL0xg Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 19:32:36 -0000 On Wed, Aug 24, 2016 at 9:23 PM, Ilari Liusvaara wrote: > The generations are not specified as integers. It is just some abstract > sequence (nowhere in protocol is that generations are integers used). The current draft requires that upon receipt of a KeyUpdate, "the receiver MUST update their receiving keys and if they have not already updated their sending state up to or past the then current receiving generation MUST send their own KeyUpdate prior to sending any other messages." This requires the generation counts to be comparable for inequality. Implementations will have to keep track of the generations, or the difference between them, in an integer counter. (How else would you do it?) > Due to design, one can't do a reciproal rekey. Hmm, there must be some misunderstanding. In the current draft, *every* time a node receives KeyUpdate #N (rekeying the incoming direction), it MUST reciprocate by rekeying its outgoing direction unless it has already sent at least N KeyUpdates. Current text: "This mechanism allows either side to force an update to the entire connection." >> (3) Fire-and-later-check. The TLS implementation exposes #2 above, but >> also `tls_session_generations()`, which returns a pair of integers >> giving the current sending and receiving generations. >> >> Any application we might want to build can be built on top of #3. > > Nope, the KeyUpdate is designed to deal with arbitrary latency in > order to fully decouple the direction (any coupling there would lead > to API problems, which apparently are more major than I initially > thought). Not quite sure what you're disagreeing with. Our proposal is also designed to deal with arbitrary latency. It's a field piggybacking on the otherwise-unmodified KeyUpdate messages. -Keith From nobody Thu Aug 25 13:43:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F2C12B077 for ; Thu, 25 Aug 2016 13:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Djq5U_DIiG1 for ; Thu, 25 Aug 2016 13:43:06 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98ABD126D74 for ; Thu, 25 Aug 2016 13:43:06 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id v123so58060869qkh.2 for ; Thu, 25 Aug 2016 13:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7M+wJXNPoaY2IIVDmz8YjpX6wUD7SwOH2RC6F+Ktvc=; b=AtbQmlpZwn5yuKatgs6OiTqSDlWyWIt0W/WYvdwXZ4Kmy7peDTbVnTwUsuUAdjR2fy C7PLMnwWugXnTF1KgTSk7Xd2QiK8yw1Sahbl1GLcK5Jm5fEU64fDx7GNLEFQ7AY9NgF0 qs7hP2Ynu3ZZvO8aT4hJeam03AaiqV4EXj5q0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7M+wJXNPoaY2IIVDmz8YjpX6wUD7SwOH2RC6F+Ktvc=; b=WV1Kso6oAvrQSOGER+DzFB+T6FeMac/vcMFfbCZbNY/6cI15upez176+fTQX3/s8If 6XBS0xWpOJnSzrsydVGsIWIEtjdRlmX8HHMEAs6zvyIEiiqlQpH0xAVz6O8Cj+e5PZjo MKW5YrterSrQOSXE2BkwWklL+McxCBYpojFDIezrWpLntGz0NdTDDhYYpdmehkIya6M4 v1plwizKbBihJeMHcz8W7XfWMJ9GMmuh8xgeyEpAWud47wHx9UUFG3BLQ5Xp6gNVWuz6 Ge79gyMXGhRr0DWFD8DvCvNALATOxI2oV4nn9JKfH5dCEtJztYGCyg8RHqaYdMRNdSVo qiKA== X-Gm-Message-State: AE9vXwNnBn7TnNBVJ2B+qT30F+tmrvp/Ixdx9ILg8WoBD7C3cL04gIcxT6oYpVSIcE+Ixg== X-Received: by 10.55.137.3 with SMTP id l3mr13320265qkd.128.1472157785729; Thu, 25 Aug 2016 13:43:05 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id 18sm8526893qkm.32.2016.08.25.13.43.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 13:43:04 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <1470232754152.68803@bosch.com> Date: Thu, 25 Aug 2016 16:43:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52BDE689-120E-4F95-98B9-1D83B1097B2B@sn3rd.com> References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> <1470148363699.24362@bosch.com> <4ff68fa1-0d8e-ed1e-064c-8bb5bbf5935a@akamai.com> <1470232754152.68803@bosch.com> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 20:43:08 -0000 Any more thoughts on these? spt > On Aug 03, 2016, at 09:59, Bauer Johannes (HOME/EFS) = wrote: >=20 > Hi Ben, >=20 > On Tue, Aug 2, 2016 at 17:05, Benjamin Kaduk wrote: > > The next step is for someone to write proposed text that would be = more clear. > > Maybe you have thoughts about how things could change? >=20 > Sure, I can give it a shot. Below is my proposal. Curious to hear your > thoughts on it. I propose slight wording changes in three parts and a = new > Sect. 4.6 which sums up what is to do for minimal implementations. >=20 > Cheers, > Johannes >=20 >=20 >=20 > Sect. 3.4 (Client Behavior: Initial Handshake) >=20 > o When the handshake has completed, the client needs to save the > client_verify_data and server_verify_data values for future use. >=20 > could be clarified as follows: >=20 > o When the handshake has completed, a client that supports = renegotiation > needs to save the client_verify_data and server_verify_data = values for=20 > future use. >=20 >=20 >=20 > Sect. 3.6 (Server Behavior: Initial Handshake) >=20 > o When the handshake has completed, the server needs to save the > client_verify_data and server_verify_data values for future use. >=20 > could be clarified as follows: > =20 > o When the handshake has completed, a server that supports = renegotiation > needs to save the client_verify_data and server_verify_data = values for=20 > future use. >=20 >=20 >=20 > Sect 4.3 (Server Considerations) >=20 > In order to enable clients to probe, even servers that do not = support > renegotiation MUST implement the minimal version of the extension > described in this document for initial handshakes, thus signaling > that they have been upgraded. >=20 > could be clarified as follows: >=20 > In order to enable clients to probe, even servers that do not = support > renegotiation MUST implement the minimal version of the extension > described in this document for initial handshakes, thus signaling > that they do not suffer from an insecure renegotiation = vulnerability. >=20 >=20 >=20 > New Sect 4.6 (Minimal Implementation) >=20 > Signaling that insecure renegotiation is not supported is a useful = effect > of the adaptation of this RFC regardless of whether or not a = specific > implementation supports renegotation or not. Since minimal = implementations > typically do not support renegotation, they also are implicitly not > vulnerable to the attacks described in the beginning of this = document. >=20 > Therefore it is sufficient for clients that do not support any kind = of > renegotation to simply include the = TLS_EMPTY_RENEGOTIATION_INFO_SCSV > signaling cipher suite value in the ClientHello, as described in = Sect. 3.4. >=20 > For TLS servers which do not support renegotiation, it is = sufficient to > parse ClientHello messages for either the > TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value or = an empty > renegotiation_info TLS extension. In either cases, the server MUST = respond > with an empty renegotation_info TLS extension, as described in = Sect. 3.6. >=20 > Neither servers nor clients which do not support renegotiation will > therefore have the need to store additional variable data in memory = during=20 > runtime. >=20 >=20 > --=20 > Johannes Bauer >=20 > Engineering Field Services (HOME/EFS)=20 > Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 = Stuttgart-Vaihingen | GERMANY | www.bosch-smarthome.com > Tel. +49(711)81112906 | johannes.bauer@bosch.com > Registergericht: Amtsgericht Stuttgart, HRB 754585;=20 > Gesch=E4ftsf=FChrung: Dr. Peter Schnaebele, Veronika Danner=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Aug 25 16:02:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3D612D0C8 for ; Thu, 25 Aug 2016 16:02:11 -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, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u95OQwBYhC_f for ; Thu, 25 Aug 2016 16:02:09 -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 09D3B12B026 for ; Thu, 25 Aug 2016 16:02:09 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 8AC3733D1F0; Thu, 25 Aug 2016 23:02:08 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Tony Arcieri References: From: Geoffrey Keating Date: 25 Aug 2016 16:02:08 -0700 In-Reply-To: Message-ID: Lines: 31 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: "cfrg@irtf.org" , "" Subject: Re: [TLS] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Aug 2016 23:02:11 -0000 Tony Arcieri writes: > This attack was published today[*]: > > https://sweet32.info/ > > I bring it up because I think the threat model is similar to the threats > that lead to RC4 "diediedie" > > https://www.rfc-editor.org/info/rfc7465 > > Should there be a 3DES "diediedie"? I think so. > I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense > for it to be banned from TLS 1.3. At least one purpose of such a RFC would be to replace the MTI ciphersuite with a different ciphersuite. > [*] Lest anyone claim the contrary, I am not surprised by this attack, and > have pushed to have 3DES removed from TLS prior to the publication of this > attack, and can probably find a TLS implementer who can back me up on that. The problem has even been described previously on this very mailing list (the original is off here: ). From nobody Fri Aug 26 00:58:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B812D11C for ; Fri, 26 Aug 2016 00:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4woYBXn92mOw for ; Fri, 26 Aug 2016 00:58:40 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC5512D10C for ; Fri, 26 Aug 2016 00:58:39 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id f93so51179471lfi.2 for ; Fri, 26 Aug 2016 00:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=boTcQ7K8fIxJiEapU1RWMKOAyzjDwY5g3JG8zxVyVXA=; b=dinbOzJHuHiIgxdSB/idlT3k7ocJKZ5SCAMnqvxsGnDhWxxEj+4O7Oy4SoaeiGolvo qNwy9g51mtQinpkmMLndz3ND7BxduapXiCKsKXegjGRkxFQciVk+htQA12rMo426l66H Kp93BSXDC+RCYjxWXVx3iOl/tr6yCi7lCIyb3fPaRhwyZIUzvgMDKgdhoP+8HxFjtvAb qLFqZMdkQhuHp4KoeTlREkLFdvfnAYY5OmHgWtsGbHUOkfoK93Q74bs6tusAn47e0x2f DKa43XOO01j+n/Tz8M8lKi9GJLRmmvlsCrvzKjHEpAU161NcHs47M87inKrc+892fjT8 z7kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=boTcQ7K8fIxJiEapU1RWMKOAyzjDwY5g3JG8zxVyVXA=; b=EFHEvz7ngb69+E1qQsl3dDWh9xnOb5gHu4gkmgx1YROc3JkYdPZpeQoBBq8TTxzTTu JbmxLElUSoUhFexfjnSmVzoLvPyOJVwOlBTF1MAL4tMS7BzC6NiHwQQJidV/C5ftkXgR pb0J/UN5LERBbZRWijVEzfILvYQu6AKbWTo5pNrDg+p5xbR9HN8hOvufLSIu4EpGFYRo uYSDgsykJJwic7Ve4+JFwKVxjb5VUu/7QSdrJ6hn8Cv9aRB5sCHRzOZilczMDY0g1QZh E8XmaOdajSpCXA82VZIuf31iGGtk5qT+sE/LNHImsacsFAgfS5whZ11cqNaQ98yDjJoy 8+cA== X-Gm-Message-State: AE9vXwO9YuElqLn1RYTY6ECdW2u7nKarsu6JAHht4jrB8/Vg1tF+aJ0UcSYg5VshNRGh269Ae2DjnlO/zF0MIg== X-Received: by 10.25.139.135 with SMTP id n129mr555943lfd.111.1472198317933; Fri, 26 Aug 2016 00:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.218.5 with HTTP; Fri, 26 Aug 2016 00:58:37 -0700 (PDT) In-Reply-To: References: From: Dmitry Belyavsky Date: Fri, 26 Aug 2016 10:58:37 +0300 Message-ID: To: Tony Arcieri Content-Type: multipart/alternative; boundary=001a113fc2f6c78b36053af4e1d7 Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Aug 2016 07:58:43 -0000 --001a113fc2f6c78b36053af4e1d7 Content-Type: text/plain; charset=UTF-8 Hello all, Regarding the discussion of the Sweet32 attack, it's worth mentioning that there is a specification of so called key meshing for the Russian GOST cipher (which has 64-bit block as well). Key meshing is a procedure of a predictable change of the current key after processing an certain amount of data. It is described in RFC 4357, Section 2.3 ( https://tools.ietf.org/html/rfc4357#section-2.3). This key meshing defends against any attack that uses a big portion of data encrypted with the same key. May be it is useful to specify the similar procedure for modern ciphers too. On Thu, Aug 25, 2016 at 5:08 AM, Tony Arcieri wrote: > This attack was published today[*]: > > https://sweet32.info/ > > I bring it up because I think the threat model is similar to the threats > that lead to RC4 "diediedie" > > https://www.rfc-editor.org/info/rfc7465 > > Should there be a 3DES "diediedie"? > > I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense > for it to be banned from TLS 1.3. > > [*] Lest anyone claim the contrary, I am not surprised by this attack, and > have pushed to have 3DES removed from TLS prior to the publication of this > attack, and can probably find a TLS implementer who can back me up on that. > > -- > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- SY, Dmitry Belyavsky --001a113fc2f6c78b36053af4e1d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

Regarding the dis= cussion of the Sweet32 attack, it's worth mentioning that=C2=A0
there is a specification of so called key meshing for the Russian GOST c= ipher (which has 64-bit block as well).
Key meshing is a procedur= e of a predictable change of the current key after processing an certain am= ount of data.=C2=A0
It is described in RFC 4357, Section 2.3 (https://tools.ietf= .org/html/rfc4357#section-2.3).=C2=A0

This key= meshing defends against any attack that uses a big portion of data encrypt= ed with the same key.

May be it is useful to speci= fy the similar procedure for modern ciphers too.


On Thu, Aug 25, 2016 at= 5:08 AM, Tony Arcieri <bascule@gmail.com> wrote:
This attack was= published today[*]:


I bring= it up because I think the threat model is similar to the threats that lead= to RC4 "diediedie"


Should there be a 3DE= S "diediedie"?

I believe 3DES is MTI for= TLS 1.0/1.1(?) but I think it would make sense for it to be banned from TL= S 1.3.

[*] Lest anyone claim the contrary, I am no= t surprised by this attack, and have pushed to have 3DES removed from TLS p= rior to the publication of this attack, and can probably find a TLS impleme= nter who can back me up on that.

--
Tony Arci= eri

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




--
SY, Dmitry Belyav= sky
--001a113fc2f6c78b36053af4e1d7-- From nobody Fri Aug 26 01:10:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C94F12D09C for ; Fri, 26 Aug 2016 01:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0kdbIKwkKGY for ; Fri, 26 Aug 2016 01:10:31 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE49C12D12E for ; Fri, 26 Aug 2016 01:04:30 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id l2so69479182qkf.3 for ; Fri, 26 Aug 2016 01:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i3J25FPSzx4HFloejYJGq7AniBOyNdpjCGsaFPRIOxs=; b=c0l5cPdj2G56HNcCxMHVPFnGcyGhLD2jvtl/wZIQBco+aDkZ47hpS9W8TfR24V0Lxs BQQfDiO9cC3YD2YPKs9rSb18qoqgT8s2PkOUrqUvneSaBccVtnmN7Xo5CslTZRqa8/Yw WqK+PSYtSVzeEf5nqKszeJqy6iBBwOFYjIEFHgk+3bG0X6bVMDt62RsvESzmMEAo3bLg vgB6C8vG+Sv8AFHvhBSB8qtFfzM+muOOMYLqjoqMSVgtafTated9268hiKeOA5DS117Y bibn9IK0fO34o6hsX6oUVDnA3k/r54aCqj9ZafaJlKsxeTfIBjbxwoGDu5rzHmhl8O0Y BenQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i3J25FPSzx4HFloejYJGq7AniBOyNdpjCGsaFPRIOxs=; b=RbV3pAtDs93TCT/B4+QzaOMpAHurR1GkB3lyBNWIvuj+8wzS+lB0sM7Y3ELx53yOCb FgI1xfcy6kz25sTNk55+1GzzxlZys+2QerhcNwp7hu0chPdGtTMh8Sg8uk5qpWtiMk1W OAFpTGL1Yg+hGTpdhNteTlZLUrIXIzrh8znS87sl4fMULvKPM169RWsjc6sS6+rcZE3f MpP7MO9ZUN9joJhY1pble564JXYiDiHR7S0ZhlXp7b8qlyRAWYVhmX95oyvb6jmU+Sjh MyadqGHGWLruQ+rn6CX1oN6vltKtrxWZ+/eT4NCPOcOzTSTKxmjwWZjlLqrY/ESx9yX3 AMFw== X-Gm-Message-State: AE9vXwOrqxZbidd7T1xa8k1XjRrjOZitSv55i366lvS2gym7TL5QXLGXHfHWW/8+Gmzu16MlMNXL+l80FufQTw== X-Received: by 10.55.209.142 with SMTP id o14mr1914750qkl.266.1472198670103; Fri, 26 Aug 2016 01:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.50.86 with HTTP; Fri, 26 Aug 2016 01:04:29 -0700 (PDT) In-Reply-To: References: From: "Stanislav V. Smyshlyaev" Date: Fri, 26 Aug 2016 11:04:29 +0300 Message-ID: To: Dmitry Belyavsky Content-Type: multipart/alternative; boundary=001a11479db0c53f48053af4f634 Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Aug 2016 08:10:32 -0000 --001a11479db0c53f48053af4f634 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear colleagues! I'd like to add that the described key meshing procedures (procedures to increase the lifetime of a key) are proven to be secure (and increasing security) in case of usage of CTR mode =E2=80=93 see preprint at http://eprint.iacr.org/2016/628.pdf In case of CBC/CFB modes an additional separate key for key meshing should be used. Kindest regards, Stanislav 2016-08-26 10:58 GMT+03:00 Dmitry Belyavsky : > Hello all, > > Regarding the discussion of the Sweet32 attack, it's worth mentioning tha= t > there is a specification of so called key meshing for the Russian GOST > cipher (which has 64-bit block as well). > Key meshing is a procedure of a predictable change of the current key > after processing an certain amount of data. > It is described in RFC 4357, Section 2.3 (https://tools.ietf.org/html/ > rfc4357#section-2.3). > > This key meshing defends against any attack that uses a big portion of > data encrypted with the same key. > > May be it is useful to specify the similar procedure for modern ciphers > too. > > > On Thu, Aug 25, 2016 at 5:08 AM, Tony Arcieri wrote: > >> This attack was published today[*]: >> >> https://sweet32.info/ >> >> I bring it up because I think the threat model is similar to the threats >> that lead to RC4 "diediedie" >> >> https://www.rfc-editor.org/info/rfc7465 >> >> Should there be a 3DES "diediedie"? >> >> I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense >> for it to be banned from TLS 1.3. >> >> [*] Lest anyone claim the contrary, I am not surprised by this attack, >> and have pushed to have 3DES removed from TLS prior to the publication o= f >> this attack, and can probably find a TLS implementer who can back me up = on >> that. >> >> -- >> Tony Arcieri >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --001a11479db0c53f48053af4f634 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear colleagues!

I'd like to add that th= e described key meshing procedures (procedures to increase the lifetime of = a key) are proven to be secure (and increasing security) in case of usage o= f CTR mode =E2=80=93 see preprint at=C2=A0http://eprint.iacr.org/2016/628.pdf

In case of CBC/CFB modes an additional sep= arate key for key meshing should be used.

<= div dir=3D"ltr">Kindest regards,
Stanislav

2016-08-26 10:58 GMT+03:00 Dmitry Belyavsky = <beldmit@gmail.com>:
Hello all,

Reg= arding the discussion of the Sweet32 attack, it's worth mentioning that= =C2=A0
there is a specification of so called key meshing for the = Russian GOST cipher (which has 64-bit block as well).
Key meshing= is a procedure of a predictable change of the current key after processing= an certain amount of data.=C2=A0
It is described in RFC 4357, Se= ction 2.3 (https://tools.ietf.org/html/rfc4357#section-2.3).=C2= =A0

This key meshing defends against any attack th= at uses a big portion of data encrypted with the same key.

May be it is useful to specify the similar procedure for modern ci= phers too.


On Thu, Aug 25, 2016 at 5:08 AM, Tony = Arcieri <bascule@gmail.com> wrote:
This attack was published today[*]:


I bring it up because I think the threat model is similar = to the threats that lead to RC4 "diediedie"

<= div>h= ttps://www.rfc-editor.org/info/rfc7465

Should there be a 3DES "diediedie"?

I= believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense for= it to be banned from TLS 1.3.

[*] Lest anyone cla= im the contrary, I am not surprised by this attack, and have pushed to have= 3DES removed from TLS prior to the publication of this attack, and can pro= bably find a TLS implementer who can back me up on that.

--
Tony Arcieri

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


=

--
SY, Dmitry Belyavsky

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--001a11479db0c53f48053af4f634-- From nobody Fri Aug 26 01:13:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C2127077 for ; Fri, 26 Aug 2016 01:13:09 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mET1wyEKhCQN for ; Fri, 26 Aug 2016 01:13:07 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D407512D09C for ; Fri, 26 Aug 2016 01:13:06 -0700 (PDT) Received: from pc1 (dslb-188-102-031-228.188.102.pools.vodafone-ip.de [::ffff:188.102.31.228]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 26 Aug 2016 10:13:05 +0200 id 000000000000007D.0000000057BFFA11.00005DC1 Date: Fri, 26 Aug 2016 10:13:04 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: Tony Arcieri Message-ID: <20160826101304.4815eecb@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-24001-1472199185-0001-2" Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Aug 2016 08:13:09 -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-24001-1472199185-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 24 Aug 2016 19:08:02 -0700 Tony Arcieri wrote: > Should there be a 3DES "diediedie"? I think a 3des diediedie rfc would be a good idea. I was wondering yesterday whether I should disable 3des on my servers. I'd likely exclude a small portion of my visitors for a very small security gain. Having a diediedie rfc would indicate that a significant portion of the net agrees that we want to hard-deprecate 3des. I'd feel more comfortable disabling it on my servers if I know that a reasonable number of other servers will do the same thing, because users with a 3des/rc4-only browser will not only see failures on my site, they will see failures all the time and will be forced to switch. Forcing them to switch is also probably almost always a good thing. Even for users who are stuck on Windows XP for whatever reason probably have better options than sticking to builtin IE - e.g. they can use Firefox, which is still supporting XP and offers modern ciphers. Appart from that more operational argument, as far as I can see the attack scenarios for RC4 and 3DES are in the same ballpark of complexity. Not very practical, but practical enough to make us feel uneasy, because we want TLS to provide reasonable protection even against ulikely scenarios. We decided to deprecate RC4 with an RFC, so it seems logical to deprecate 3DES as well. (while we are at it: I'm not sure, do we have any official RFC deprecating the even older ciphers - Single-DES, RC2 etc. - yet? We could just stuff that in) --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 --=_zucker.schokokeks.org-24001-1472199185-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXv/oQAAoJEKWIAHK7tR5CpvgP/jycmHREWG6wKpVKtziODOSa AwmpZYf2hFeA3NBS0mZqwsfbcFklJJABi5Bt+eieDloAz2d2AFWsmkiFPJBfIaTD ETRAJ8zDEx0ZDnER5M68ChGwv7qVNKQ7KxzitbaABSIoWE3gxgTQIzAiqNKk/qqv si6BkoxVysIJOKLThHI9yG7rllJGDdi3CWUEmhKffcdGQIEpKuLf4eW0IB4pe22B SaF25QHdKzYBOzPuaI48KCi2WLAPIgNevB20cmr8QzxSROjQCJEpf6AVZxW4za1D c8LdFq7RT7fwH3j7rKzKGW0l7fTDKfhv4mafGGcPmVN66fsKiKzU4bVUrP90WINL 2PhjHndGLJGcwIj/QS/Qu7bxOk+WhqYQbwI1Xt4sjowLZKLSn4HiJBIS+4TsP8kY WiJXN9TCTPNbdKvta9rrKeRzrPwi4SsbPuZvVHsEjp4Eq0BSS1TwGVd3dJ3JJFj9 iaTpV0WftCvX59mrkcotYzWfx455dYRSUwXj8OndFWJt7hml1XQwX5bNiM8dcSuB FB00mFC2vmH7mVicVfPiCRsTyw4PMAf03LyPLv110MtE4Lj7uztl4I7kz1v3ik0X O96oyrZp412A3PkYoWSc1qKszpkAi/kMhC48L25bRXp5krYBlkMHxkhjxrJ/f6xN su4+ggt+AKJfkjuo6lEd =y90o -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-24001-1472199185-0001-2-- From nobody Fri Aug 26 07:03:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F35812D768 for ; Fri, 26 Aug 2016 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFOnCm8irp8v for ; Fri, 26 Aug 2016 07:03:28 -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 8251D12D8E1 for ; Fri, 26 Aug 2016 06:52:29 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22A1B9E617 for ; Fri, 26 Aug 2016 13:52:29 +0000 (UTC) Received: from pintsize.usersys.redhat.com (vpn1-4-42.ams2.redhat.com [10.36.4.42]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7QDqRY6003983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Aug 2016 09:52:28 -0400 From: Hubert Kario To: "tls@ietf.org" Date: Fri, 26 Aug 2016 15:52:22 +0200 Message-ID: <4863811.CEEb377QKO@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3741598.7CzYjNqApN"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 26 Aug 2016 13:52:29 +0000 (UTC) Archived-At: Subject: [TLS] IANA Alert registry does not include ALPN alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Aug 2016 14:03:32 -0000 --nextPart3741598.7CzYjNqApN Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" The IANA TLS Alert Registry[1] does not include the=20 no_application_protocol(120) alert from RFC7301[2] (a.k.a. Application-Laye= r=20 Protocol Negotiation Extension) What's the procedure to fix it? 1 - https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#t= ls-parameters-6 2 - https://tools.ietf.org/html/rfc7301#section-3.2 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart3741598.7CzYjNqApN 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 iQIcBAABCgAGBQJXwEmWAAoJEJKo0bgB0vX1jXsP/i3ZQuxKZa8tEfY0sjgeaB0L o3Wzmxu7nmjlWJbYI1ktHc6S601QD7neD7DsSoOSiYl6eVg/FX+L1hbwkxEjxw6W 2/sISF0YMegNwiy49ehZWlZ7Q2ZXwHXNmR+ScSE5XyQgiiAmzsjn4/xlm4TsA8EB +OdOcmfDSCV30ql4M/9uL8FSHrAis0TvJo25UZgZ00EwJ+gRWLfRtIlT2CFwzGpX RkXG0+J9LUEhtENR2CwTTFo0CbGXuFS94zmSDPALPDDhDEf80BjetBB+p4sD10Rp giYkQPdtg4Q59mC4FNzEV3K3n7OccBj6b06q0N/EhcVlxi+C08Gn6KF719mmqqNo pg66nM/vj/fvTqSSURJej9DWc9XPT8/I09LmCJ+0ZiuKbLwLSBy1C3qugNicZXl0 srMlWihMu3sclVMaFBGnkQyfX+XMeexk8FhjHOyLn10VnDDa29G6peZtOryfTdpm DElISB4ETZrMtJnALBTt4k+fV3lNrFjKKLtX89QdTe9p1CbFtAyciW5AH5B/lRnI JsW/Sk5uqcyMG3HBfdmxD72XZKtfL8T/vOYc8jx+rSMIdoB0xLe0CF6TUY8X1mCG VU0WIJ3TCACw59VXLWMAlpu7kA7TDX0a6bYC4satDSMlQWpbM+ZVCIJBC2+aZOKN 4S22E2WlCAmG7b37sV9o =6ef0 -----END PGP SIGNATURE----- --nextPart3741598.7CzYjNqApN-- From nobody Fri Aug 26 07:31:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7333812D6A7 for ; Fri, 26 Aug 2016 07:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ireRg8IIEpzA for ; Fri, 26 Aug 2016 07:31:41 -0700 (PDT) Received: from BLU004-OMC4S8.hotmail.com (blu004-omc4s8.hotmail.com [65.55.111.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821F812B018 for ; Fri, 26 Aug 2016 07:27:36 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com ([65.55.111.135]) by BLU004-OMC4S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 26 Aug 2016 07:27:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XOKh/XlvQcBa2ptUWHi9xtIamnkqUF31R4GrjwqkN/c=; b=XG9JKTwhzAvJMMnBrI+efRA8fNTUzmb6otBGDiDETgw8UCFXj4ElEOY1mWWX9nLCbh1ewq6yd/GNj0qQMXgXTbNeFPdlxaudH7L0dOooTW3JQ4rBwBsNjsWi6sbQ57zQxtoerJ/eJgTy1e1AVBgTp8aY104ob7FIfX7URgTIqf8q3WINeBJMtfByQVD1OFaGEnHAEztyXkZVzVQwjJTmlwEA8gbb8V3uiGpOzu2OAuvDeZVdL843X+WZ28ZaQPbLkY8Ql1nqyP3YkqXYpOty5qh2YI8583PkgnBNqlKtwar3gMVVv3RY677B2/XHa8SI+JWnVnu+PpQ3uXGqLKA7fw== Received: from BN3NAM04FT036.eop-NAM04.prod.protection.outlook.com (10.152.92.58) by BN3NAM04HT115.eop-NAM04.prod.protection.outlook.com (10.152.93.11) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Fri, 26 Aug 2016 14:27:34 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.92.57) by BN3NAM04FT036.mail.protection.outlook.com (10.152.93.184) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Fri, 26 Aug 2016 14:27:34 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0587.013; Fri, 26 Aug 2016 14:27:32 +0000 From: Xiaoyin Liu To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] IANA Alert registry does not include ALPN alert Thread-Index: AQHR/6KoyTbbOc7MuE+nb2LyaHEb/6BbTK4q Date: Fri, 26 Aug 2016 14:27:32 +0000 Message-ID: References: <4863811.CEEb377QKO@pintsize.usersys.redhat.com> In-Reply-To: <4863811.CEEb377QKO@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.92.57) smtp.mailfrom=outlook.com; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.92.57 as permitted sender) x-tmn: [VqBTohwPZkUt4Mie1D8cCAFA5l7hUHnX] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.92.57; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM04HT115; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; BN3NAM04HT115; 6:dH0UvlP+OHdEMdCOSR1w87YY0I3rrTNjqd31gSEMEZMy1/iFrLfaG5NI0b7xTq5sn5p5jN2r9ub7cogsoFFfLiZu1vmhIWMr2M1JozR5fE06c1Ik8WWtIRqYxLRjjdCdtOq4UAFUeAfISPUh1qEvhYk9G9fsZsOb/SdaJPfWqTopX6PhswGRuCunCOxyGD459yaWXVgm+UtKdijZTBwUcgaf1ddu8jNxdKosNL917cVt3PNfdQ0cK3NZlL1gZQtgOGis5zOEFkMSaU+hrx+Xd0h/lDqUJaV3kQ28Ov9yNuu2+sqP1uT02X2s8AHBZS6RdH78rNXebIFYaskASZZyzA==; 5:92ALjrHElQYvhDKuRBc+XpwbpF9BCy5x+MTj3il/XoQ+ZYw5z1JuDfPbcEDL/mLt8nSXYOvXDvduNYTSdNsx3k8Brd8KAn0jaMcerSm8f1oFOE+MwLNyWyt0DIeUh35mnXRxzrgQNIm8624NwQljvw==; 24:zXZgXA1BYI0aUUXMcxiybAhsXPSrk+NmLgmWrQ7mjld+MrywxMG3FJLHbTpEDL2sUV5lN+7pQGp584afAVNr42n3boAiibQ0L6lTEpnO1ok=; 7:T0x0DA0Q6KOx3O8W8zoLBnqjSH+/psFzr5WE2aWGxdA2Nbdz7d9asVL0wG+v55nbB4+e9r4Tq3xvEgUvb/POyZTzeHlOW4LTJHQUx3TrjgHTcQBrlwEx4o88bOJjSgJOC28fIkHtaRsQ7u41AC0kvj7SopDAGXRs7oG6UCpYgnowcQmI/wKZLGLpzzONFvdnMRLtTj7jnCBmfKAIy6/i+NWjhUznaVvjAZmRLzP9BtDvLQakTxFM6fqmyOvLVxHc x-ms-office365-filtering-correlation-id: bbf7f7df-ebdd-457d-f2a4-08d3cdbd1e47 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1601125047); SRVR:BN3NAM04HT115; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BN3NAM04HT115; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM04HT115; x-forefront-prvs: 00462943DE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778325C9D42BFC71EA4C360FFEC0CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2016 14:27:32.8555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT115 X-OriginalArrivalTime: 26 Aug 2016 14:27:35.0533 (UTC) FILETIME=[FD54B9D0:01D1FFA5] Archived-At: Subject: Re: [TLS] IANA Alert registry does not include ALPN alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Aug 2016 14:31:45 -0000 --_000_CY1PR15MB0778325C9D42BFC71EA4C360FFEC0CY1PR15MB0778namp_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable I guess the reason is that this new alert is not mentioned in the IANA Cons= iderations section in RFC7301. I don=92t know how to fix it though. Best, Xiaoyin From: Hubert Kario Sent: Friday, August 26, 2016 10:03 To: tls@ietf.org Subject: [TLS] IANA Alert registry does not include ALPN alert The IANA TLS Alert Registry[1] does not include the no_application_protocol(120) alert from RFC7301[2] (a.k.a. Application-Laye= r Protocol Negotiation Extension) What's the procedure to fix it? 1 - https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#t= ls-parameters-6 2 - https://tools.ietf.org/html/rfc7301#section-3.2 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=F2ova 99/71, 612 45, Brno, Czech Republic --_000_CY1PR15MB0778325C9D42BFC71EA4C360FFEC0CY1PR15MB0778namp_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

I guess the reason is that this new alert is not m= entioned in the IANA Considerations section in RFC7301. I don=92t know how = to fix it though.

 

Best,

Xiaoyin

 

 

 

From: Hubert Kario
Sent: Friday, August 26, 2016 10:03
To: tls@ietf.org
Subject: [TLS] IANA Alert registry does not include ALPN alert

 

The IANA TLS Alert Registry[1] does not include th= e
no_application_protocol(120) alert from RFC7301[2] (a.k.a. Application-Laye= r
Protocol Negotiation Extension)

What's the procedure to fix it?

 1 - https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa= rameters-6
 2 - https= ://tools.ietf.org/html/rfc7301#section-3.2
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=F2ova 99/71, 612 45, Brno, Czech Republic
 --_000_CY1PR15MB0778325C9D42BFC71EA4C360FFEC0CY1PR15MB0778namp_-- From nobody Fri Aug 26 07:42:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C4F12B007 for ; Fri, 26 Aug 2016 07:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ64HpGYRqdc for ; Fri, 26 Aug 2016 07:42:09 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6111C12B010 for ; Fri, 26 Aug 2016 07:42:09 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id j12so49665842ywb.2 for ; Fri, 26 Aug 2016 07:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KqvVwHxfzx66OlByLX4X0Rkqgfuip3ojxJAcpFp7HDU=; b=GrDcRV2kiA0hbot6XM8DVFun2CfWJVUnIuti9iiKBlXMFIf0GSEZ9qCdEjkBqK1WrU 7qsI5yptV3jFE+e5UUc0w8WHUT7rs0vlQvOsB/oPct66A2MUdoiJET8mjlULBWJFHm4P vLdYYBUiQjBu0uHvdSid2EH7uSUq6T7b9XebwRL1omB6XLkXQ8+yytHB+hLdHcH8s0sN VkGChAKVg2erDhOA22FJexVC1QeZMIvb6a8VhDVTvvXhrKN0Qprc/Dvd66exSHI5AmGJ Mlc8avCvFMRUEN0yODLH+x2ktsd/mYpqm1l9Qy9Q3FK+3whfYdjfIxMKqy99Ux1MdobN 9yjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KqvVwHxfzx66OlByLX4X0Rkqgfuip3ojxJAcpFp7HDU=; b=SVGsO8Se1X3+6ihdL2uKsECpI0nDQ7Y/LEayxE0zVVLTfxeQkulkrJkYUM+kfr98Bt A75I7PAbzZl17cr9HpHQ0abPGFY4p9ejsKvhXqHwNXtpt4KLm2aBZ3KY06Tokoq7PPWh zCfmNEdnc7apt9yA55fEGz8iYtuG23kdUSVDGlz9XZfGth+/nFLqZSHGAVfeJMBYzXLK XIgEDvniEnXNzHtLbfRT+owArHq1WFB1Eb8Xfl2cmKg7wtdeEpOujByzmTku+GtKSXCV Yd9LXuaG3YBzgFj0EGNSMK/otEXUXlix7nvOJtXEojNt6ZIzUx1k42cZ7lZRepT885MY iGag== X-Gm-Message-State: AE9vXwNxn74GMCNQ6qrFlWicYQ7XK2PqOLTPdD7fFB8e30rsIWyCN4TGrzvgjyMQafsyZjkBJ2fbflJaQXSATw== X-Received: by 10.129.39.200 with SMTP id n191mr3628516ywn.16.1472222528636; Fri, 26 Aug 2016 07:42:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Fri, 26 Aug 2016 07:41:28 -0700 (PDT) In-Reply-To: References: <4863811.CEEb377QKO@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Fri, 26 Aug 2016 07:41:28 -0700 Message-ID: To: Xiaoyin Liu Content-Type: multipart/alternative; boundary=001a1141826ad9bbe4053afa841f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] IANA Alert registry does not include ALPN alert X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Aug 2016 14:42:13 -0000 --001a1141826ad9bbe4053afa841f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe the chairs are preparing an IANA update RFC. We can cram it in there. -Ekr On Fri, Aug 26, 2016 at 7:27 AM, Xiaoyin Liu wrote: > I guess the reason is that this new alert is not mentioned in the IANA > Considerations section in RFC7301. I don=E2=80=99t know how to fix it tho= ugh. > > > > Best, > > Xiaoyin > > > > > > > > *From: *Hubert Kario > *Sent: *Friday, August 26, 2016 10:03 > *To: *tls@ietf.org > *Subject: *[TLS] IANA Alert registry does not include ALPN alert > > > The IANA TLS Alert Registry[1] does not include the > no_application_protocol(120) alert from RFC7301[2] (a.k.a. > Application-Layer > Protocol Negotiation Extension) > > What's the procedure to fix it? > > 1 - https://www.iana.org/assignments/tls-parameters/ > tls-parameters.xhtml#tls-parameters-6 > 2 - https://tools.ietf.org/html/rfc7301#section-3.2 > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1141826ad9bbe4053afa841f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe the chairs are preparing an IANA update RFC. We = can cram it in there.

-Ekr


On Fri, Aug 26, 2016= at 7:27 AM, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:<= br>

I guess the reason is that this new alert is not mentioned in the IANA C= onsiderations section in RFC7301. I don=E2=80=99t know how to fix it though= .

=C2=A0

Best,

Xiaoyin

=C2=A0

=C2=A0

=C2=A0

=C2=A0


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


--001a1141826ad9bbe4053afa841f-- From nobody Fri Aug 26 10:55:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0962E12D507 for ; Fri, 26 Aug 2016 10:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w3f4jgfgpyJ for ; Fri, 26 Aug 2016 10:55:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1526D12D504 for ; Fri, 26 Aug 2016 10:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8926; q=dns/txt; s=iport; t=1472234119; x=1473443719; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rXWPx3FJglC3HbHfn01Qr3K2GiDyghvrxQX2L6VSM7c=; b=MlekeNSZKPHJqrBczmb6GmDCMicHlhExehVEOotqQaUT8lt9Zz4/wVLQ 4IOFfpGlviv7HxiX9dLHhKXbNET5Iajb9vdBykvqG4F4rDxOH/K8k6ykn RrXRkA4F6xfZuR/kjGWc4YpQFMxaIJyoE7ALB/4+2ZjqDba03cjrXt2T1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5EAChgcBX/49dJa1dgw4zAQEBAQEeV?= =?us-ascii?q?nwHhCSnS4cnhQmCASCFfQIcgTI6EgECAQEBAQEBAV4nhGEBAQMCI2YCAQgOAwM?= =?us-ascii?q?BAigDAgICHxEUCQgCBAESiB4DFw6wIYteDYNOAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBYgmCIJNghAzgh2CYiuCLwWTcIUoNAGGH4Y+gkuKeoRYiDqECYN4ASUCLYQ?= =?us-ascii?q?ccAGFTH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,581,1464652800"; d="scan'208,217";a="142102898" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Aug 2016 17:55:19 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u7QHtJ0S019328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Aug 2016 17:55:19 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 Aug 2016 12:55:18 -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.1210.000; Fri, 26 Aug 2016 12:55:18 -0500 From: "David McGrew (mcgrew)" To: Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/nWfoW+SS6smqUOyCtdxrLUgKaBbmdgA Date: Fri, 26 Aug 2016 17:55:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.10.228] Content-Type: multipart/alternative; boundary="_000_F42128A0968240428C7EE3686743B314ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Aug 2016 17:55:22 -0000 --_000_F42128A0968240428C7EE3686743B314ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KVGhhbmtzIGZvciBicmluZ2luZyB0aGlzIHVwOyBhbiBSRkMgZGVwcmVjYXRp bmcgYW5kL29yIGRpc2NvdXJhZ2luZyAzREVTIHdvdWxkIGJlIGEgZ29vZCB0aGluZy4gIFRoZSBv bmx5IGdvb2QgcmVhc29uIHRvIHVzZSBpdCBpcyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgYW5k IHRvbyBtYW55IGFwcGxpY2F0aW9ucyBkb27igJl0IGhlZWQgdGhlIGJpcnRoZGF5IGJvdW5kLg0K DQpUaGVyZSBpcyBhbm90aGVyIGlzc3VlIHRvIGJlIGNvbnNpZGVyZWQsIHRob3VnaC4gICBNb3N0 IG9mIHRoZSBsaWdodHdlaWdodCDigJxkZXNpZ25lZCBmb3IgSW9U4oCdIGJsb2NrIGNpcGhlcnMg aGF2ZSBhIDY0IGJpdCBibG9jayBzaXplIChhbmQgc29tZXRpbWVzIGV2ZW4gc21hbGxlcik7IHNl ZSBmb3IgaW5zdGFuY2UgVGFibGUgMS4xIG9mIGh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTMv NDA0LnBkZiAgICAgU28gcGVyaGFwcyB3aGF0IHRoZSBJbnRlcm5ldCBuZWVkcyBoZXJlIGlzIHNv dW5kIGd1aWRhbmNlIG9uIGhvdyB0byB1c2UgNjQtYml0IGJsb2NrIGNpcGhlcnMuICAgQmVzdCBw cmFjdGljZXMgaGVyZSBpbmNsdWRlIGJvdGggbWFuZGF0b3J5IHJla2V5aW5nIHdlbGwgYmVsb3cg dGhlIGJpcnRoZGF5IGJvdW5kIGFuZC9vciB0aGUgdXNlIG9mIHNlY3VyZSBiZXlvbmQgdGhlIGJp cnRoZGF5IGJvdW5kIG1vZGVzIG9mIG9wZXJhdGlvbiBzdWNoIGFzIEl3YXRh4oCZcyBDRU5DLg0K DQpCZXN0LA0KDQpEYXZpZA0KDQpGcm9tOiBDZnJnIDxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmc8bWFp bHRvOmNmcmctYm91bmNlc0BpcnRmLm9yZz4+IG9uIGJlaGFsZiBvZiBUb255IEFyY2llcmkgPGJh c2N1bGVAZ21haWwuY29tPG1haWx0bzpiYXNjdWxlQGdtYWlsLmNvbT4+DQpEYXRlOiBXZWRuZXNk YXksIEF1Z3VzdCAyNCwgMjAxNiBhdCAxMDowOCBQTQ0KVG86ICJ0bHNAaWV0Zi5vcmc8bWFpbHRv OnRsc0BpZXRmLm9yZz4iIDx0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4+LCAiY2Zy Z0BpcnRmLm9yZzxtYWlsdG86Y2ZyZ0BpcnRmLm9yZz4iIDxjZnJnQGlydGYub3JnPG1haWx0bzpj ZnJnQGlydGYub3JnPj4NClN1YmplY3Q6IFtDZnJnXSAzREVTIGRpZWRpZWRpZQ0KDQpUaGlzIGF0 dGFjayB3YXMgcHVibGlzaGVkIHRvZGF5WypdOg0KDQpodHRwczovL3N3ZWV0MzIuaW5mby8NCg0K SSBicmluZyBpdCB1cCBiZWNhdXNlIEkgdGhpbmsgdGhlIHRocmVhdCBtb2RlbCBpcyBzaW1pbGFy IHRvIHRoZSB0aHJlYXRzIHRoYXQgbGVhZCB0byBSQzQgImRpZWRpZWRpZSINCg0KaHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NDY1DQoNClNob3VsZCB0aGVyZSBiZSBhIDNERVMg ImRpZWRpZWRpZSI/DQoNCkkgYmVsaWV2ZSAzREVTIGlzIE1USSBmb3IgVExTIDEuMC8xLjEoPykg YnV0IEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSBmb3IgaXQgdG8gYmUgYmFubmVkIGZyb20g VExTIDEuMy4NCg0KWypdIExlc3QgYW55b25lIGNsYWltIHRoZSBjb250cmFyeSwgSSBhbSBub3Qg c3VycHJpc2VkIGJ5IHRoaXMgYXR0YWNrLCBhbmQgaGF2ZSBwdXNoZWQgdG8gaGF2ZSAzREVTIHJl bW92ZWQgZnJvbSBUTFMgcHJpb3IgdG8gdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgYXR0YWNrLCBh bmQgY2FuIHByb2JhYmx5IGZpbmQgYSBUTFMgaW1wbGVtZW50ZXIgd2hvIGNhbiBiYWNrIG1lIHVw IG9uIHRoYXQuDQoNCi0tDQpUb255IEFyY2llcmkNCg== --_000_F42128A0968240428C7EE3686743B314ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCkhpIFRvbnksPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NClRoYW5rcyBmb3IgYnJpbmdp bmcgdGhpcyB1cDsgYW4gUkZDIGRlcHJlY2F0aW5nIGFuZC9vciBkaXNjb3VyYWdpbmcgM0RFUyB3 b3VsZCBiZSBhIGdvb2QgdGhpbmcuICZuYnNwO1RoZSBvbmx5IGdvb2QgcmVhc29uIHRvIHVzZSBp dCBpcyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgYW5kIHRvbyBtYW55IGFwcGxpY2F0aW9ucyBk b27igJl0IGhlZWQgdGhlIGJpcnRoZGF5IGJvdW5kLjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpU aGVyZSBpcyBhbm90aGVyIGlzc3VlIHRvIGJlIGNvbnNpZGVyZWQsIHRob3VnaC4gJm5ic3A7IE1v c3Qgb2YgdGhlIGxpZ2h0d2VpZ2h0IOKAnGRlc2lnbmVkIGZvciBJb1TigJ0gYmxvY2sgY2lwaGVy cyBoYXZlIGEgNjQgYml0IGJsb2NrIHNpemUgKGFuZCBzb21ldGltZXMgZXZlbiBzbWFsbGVyKTsg c2VlIGZvciBpbnN0YW5jZSBUYWJsZSAxLjEgb2YNCjxhIGhyZWY9Imh0dHBzOi8vZXByaW50Lmlh Y3Iub3JnLzIwMTMvNDA0LnBkZiI+aHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxMy80MDQucGRm PC9hPiZuYnNwOyAmbmJzcDsgJm5ic3A7U28gcGVyaGFwcyB3aGF0IHRoZSBJbnRlcm5ldCBuZWVk cyBoZXJlIGlzIHNvdW5kIGd1aWRhbmNlIG9uIGhvdyB0byB1c2UgNjQtYml0IGJsb2NrIGNpcGhl cnMuICZuYnNwOyBCZXN0IHByYWN0aWNlcyBoZXJlIGluY2x1ZGUgYm90aCBtYW5kYXRvcnkgcmVr ZXlpbmcgd2VsbCBiZWxvdyB0aGUgYmlydGhkYXkNCiBib3VuZCBhbmQvb3IgdGhlIHVzZSBvZiBz ZWN1cmUgYmV5b25kIHRoZSBiaXJ0aGRheSBib3VuZCBtb2RlcyBvZiBvcGVyYXRpb24gc3VjaCBh cyBJd2F0YeKAmXMgQ0VOQy4gJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkJlc3QsPC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij4NCkRhdmlkPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVm dDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDog bWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURE SU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklH SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Q2ZyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNmcmctYm91 bmNlc0BpcnRmLm9yZyI+Y2ZyZy1ib3VuY2VzQGlydGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9m IFRvbnkgQXJjaWVyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhc2N1bGVAZ21haWwuY29tIj5iYXNj dWxlQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiBhdCAxMDowOCBQTTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86Y2ZyZ0BpcnRmLm9yZyI+Y2ZyZ0BpcnRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpjZnJnQGlydGYub3JnIj5jZnJnQGlydGYub3JnPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltDZnJnXSAzREVTIGRp ZWRpZWRpZTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNv bGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgZGlyPSJsdHIiPlRoaXMgYXR0YWNrIHdhcyBwdWJsaXNoZWQgdG9kYXlbKl06DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3N3ZWV0MzIuaW5mby8iPmh0dHBzOi8v c3dlZXQzMi5pbmZvLzwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYnJpbmcg aXQgdXAgYmVjYXVzZSBJIHRoaW5rIHRoZSB0aHJlYXQgbW9kZWwgaXMgc2ltaWxhciB0byB0aGUg dGhyZWF0cyB0aGF0IGxlYWQgdG8gUkM0ICZxdW90O2RpZWRpZWRpZSZxdW90OzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv aW5mby9yZmM3NDY1Ij5odHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc0NjU8L2E+ PC9kaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2hvdWxkIHRoZXJlIGJlIGEg M0RFUyAmcXVvdDtkaWVkaWVkaWUmcXVvdDs/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5JIGJlbGlldmUgM0RFUyBpcyBNVEkgZm9yIFRMUyAxLjAvMS4xKD8pIGJ1dCBJIHRoaW5rIGl0 IHdvdWxkIG1ha2Ugc2Vuc2UgZm9yIGl0IHRvIGJlIGJhbm5lZCBmcm9tIFRMUyAxLjMuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bKl0gTGVzdCBhbnlvbmUgY2xhaW0gdGhlIGNvbnRy YXJ5LCBJIGFtIG5vdCBzdXJwcmlzZWQgYnkgdGhpcyBhdHRhY2ssIGFuZCBoYXZlIHB1c2hlZCB0 byBoYXZlIDNERVMgcmVtb3ZlZCBmcm9tIFRMUyBwcmlvciB0byB0aGUgcHVibGljYXRpb24gb2Yg dGhpcyBhdHRhY2ssIGFuZCBjYW4gcHJvYmFibHkgZmluZCBhIFRMUyBpbXBsZW1lbnRlciB3aG8g Y2FuIGJhY2sgbWUgdXAgb24gdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8YnI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiIGRhdGEtc21hcnRtYWlsPSJnbWFpbF9zaWdu YXR1cmUiPlRvbnkgQXJjaWVyaTxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F42128A0968240428C7EE3686743B314ciscocom_-- From nobody Fri Aug 26 10:59:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2512D501 for ; Fri, 26 Aug 2016 10: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iykgrS6qNzQX for ; Fri, 26 Aug 2016 10:59:47 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 27EAB12D504 for ; Fri, 26 Aug 2016 10:59:47 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id m60so110337764uam.3 for ; Fri, 26 Aug 2016 10:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QW5mCSwNpSs1OuJC/gHtnhJ++e/IxMaNgs2sVU6LyR4=; b=Gp4rvjvT01+1H9iddg4qHVbhMD+wzMGNHhxsjV8f/B/RacpS+emJOHM5MFVdiX9b9K 22YywMguJNfy3iCfHYHi9bp3rXmPA+327vTJwKwz4REitVMkIVGhJJHc7x2FdKW77ajp Kq7tfaQJxZvPy88YbFgc7oz0b24zp9TkR3yqRJ2qRD7eJdRH7/LWt3dMp11smJhKO/qu qFsuSY+ONkBhsg9DwHioUkX42lV0nGl3PKkYlT83h3S2SxJBvoUCwaZ6IQgREUhUtgrE GH34Y9/mgsYtIY+mi3lhOsMiq4WNcejXCmYVb9IdHOtC7DAy4RhZ5+5MvAGPCV/gvwsx GNCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QW5mCSwNpSs1OuJC/gHtnhJ++e/IxMaNgs2sVU6LyR4=; b=mIFT5VLcIRrrBfgdnYjEe2Io1I3UCMEMt+kdgsRvIG4Q0DQc3uJI60Nuyrl/KVPUFk ZExyGEhIR7I6xW7/CLtCXOHrhftdotkxS/1G7psuanyBBXPmzNLKEP/OU/jwJ6YS4sa9 VzysReZXhy0DZcTiZeIaF6iPATiS3I7GH0YzHWJ5BCz3somGvXj96pK3a/kMJYPz2qQ5 oGXmkUjQEBa/FeRDabgxbmafyNOez67Rdiuam+7vHewezQF+vmAbb0kt21q9bfqYNiSm S4ufPwA+8GaF93l9kdZZHjT72/sFU6ZdPqdagH9kMZSEkQ3cuNTMeJXZpTjlZAmOuq4w YDRw== X-Gm-Message-State: AE9vXwOxcNfc1y26a9opGnxGEo4skRslu9qILa5hCFAbr3b8b9jdUuuJQbbjoH39nRMz6NgjAn8CaNjYNS/8tw== X-Received: by 10.159.37.101 with SMTP id 92mr2944606uaz.109.1472234385250; Fri, 26 Aug 2016 10:59:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Fri, 26 Aug 2016 10:59:44 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Fri, 26 Aug 2016 10:59:44 -0700 Message-ID: To: "David McGrew (mcgrew)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Aug 2016 17:59:48 -0000 On Fri, Aug 26, 2016 at 10:55 AM, David McGrew (mcgrew) wrote: > Hi Tony, > > Thanks for bringing this up; an RFC deprecating and/or discouraging 3DES > would be a good thing. The only good reason to use it is backwards > compatibility, and too many applications don=E2=80=99t heed the birthday = bound. > > There is another issue to be considered, though. Most of the lightweigh= t > =E2=80=9Cdesigned for IoT=E2=80=9D block ciphers have a 64 bit block size= (and sometimes > even smaller); see for instance Table 1.1 of > https://eprint.iacr.org/2013/404.pdf So perhaps what the Internet nee= ds > here is sound guidance on how to use 64-bit block ciphers. Best practic= es > here include both mandatory rekeying well below the birthday bound and/or > the use of secure beyond the birthday bound modes of operation such as > Iwata=E2=80=99s CENC. Or use PRF instead of PRP for counter mode. I'm happy to check the arithmetic if we want an RFC for this, but am very overcommitted on editing right now. > > Best, > > David > > From: Cfrg on behalf of Tony Arcieri > > Date: Wednesday, August 24, 2016 at 10:08 PM > To: "tls@ietf.org" , "cfrg@irtf.org" > Subject: [Cfrg] 3DES diediedie > > This attack was published today[*]: > > https://sweet32.info/ > > I bring it up because I think the threat model is similar to the threats > that lead to RC4 "diediedie" > > https://www.rfc-editor.org/info/rfc7465 > > Should there be a 3DES "diediedie"? > > I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense = for > it to be banned from TLS 1.3. > > [*] Lest anyone claim the contrary, I am not surprised by this attack, an= d > have pushed to have 3DES removed from TLS prior to the publication of thi= s > attack, and can probably find a TLS implementer who can back me up on tha= t. > > -- > Tony Arcieri > > > _______________________________________________ > 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 Sat Aug 27 04:32:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4412D0CF for ; Sat, 27 Aug 2016 04:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am1SISmyFOtc for ; Sat, 27 Aug 2016 04:32:39 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36A012B042 for ; Sat, 27 Aug 2016 04:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472297559; x=1503833559; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1XMWx5mDZ05vGsXOqW6iO8Smnfu+Tx25ZbfICk4Tqqg=; b=vjdaO2wnY/QMXuFlyd7srD0peR3eKpLJZsTOuQjino+ie5QVpmiTza47 0MZdR0qCN/JmW2UWDl7OOkXKEO79B06jA2DGiFmzuk/UMsqi4lHBSvxiG 7A1IVdOE/Td8h+66Oed/Fa4gJh5P4er6MaYiCCNFIdNImI6iC3F3Eg7IA 0twNSAUwvwH49Rkj2iL1nC6IfaY+DYvEdCjLlgnvGyaztpr3RDApD6EP0 Au6b53SscqYn5X468RxXQ/L7EiGW40Opjr44WBdxBGvWIQ61/WtHqcaxR uEMoIO8dqObnlUkuddRgvetyH0bpf3AM2IpGY8gaWEE1spOXw9Y8etWOg A==; X-IronPort-AV: E=Sophos;i="5.28,586,1464609600"; d="scan'208";a="103682142" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Aug 2016 23:32:35 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Sat, 27 Aug 2016 23:32:35 +1200 From: Peter Gutmann To: Tony Arcieri Thread-Topic: [TLS] 3DES diediedie Thread-Index: AQHR/nYBgGFjWg5clEOyDz4J8naNqqBZBEfx//85uoCABHJHVQ== Date: Sat, 27 Aug 2016 11:32:34 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D046C2@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D01F6E@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 27 Aug 2016 11:32:43 -0000 Tony Arcieri writes:=0A= =0A= >As someone who works professionally in the payments industry alongside peo= ple=0A= >who are directly implementing EMV protocols, let me note: those are not IE= TF=0A= >protocols and should not have bearing on IETF/IRTF decisions regarding=0A= >deprecations of protocols in TLS or other IETF protocols. But I'm mainly= =0A= >concerned with TLS...=0A= =0A= Some of those uses are in TLS...=0A= =0A= >So does ChaCha20.=0A= =0A= Widely supported on z/OS, Tandem NSK, and HSMs, is it?=0A= =0A= (Sorry, couldn't resist. You know what I mean :-).=0A= =0A= >..but is not a terribly dissimilar traffic volume to recover plaintexts fr= om=0A= >similar attacks against RC4, which received "diediedie" in RFC7465.=0A= =0A= RC4 has serious cryptographic weaknesses, 3DES doesn't.=0A= =0A= Peter.= From nobody Sat Aug 27 05:21:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C5312B046 for ; Sat, 27 Aug 2016 05:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYvB76lPLAYS for ; Sat, 27 Aug 2016 05:21:13 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D1312B00D for ; Sat, 27 Aug 2016 05:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472300473; x=1503836473; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+H9EosnlMnTK+2oM2IFLwkGLFc05wjKA2A7sWFWU3Sk=; b=yFHWCTSwkg6Pw477EN1W8+PuhMr2WCSIKXwxt3DU3dnxirKCMjqUuCNe YrcOtPd1LoNL5NXlZNCzthXeMqxCGy7wakTm2B+g33igzLyhMimllU/rx KgGG/d3S1b+iJMyc5mMhRWB45g02W+tMsTlyYse8xX7e0w+uzgyYmhhgN KyF8opfyDMoBEHSESBESial93b+8gCr+4nYUybyf4S5MUFo6SNgXtxmei LygNSAz0DWgIsJigPFOGqa/oawS3HhV6NKVVvxAH8olkTpO10PW9t5M12 /89l3FWmBX/l32zMr4J3oE4Z4hHuPZU+lfrp/VVylN2ieCo0LfHodd5cV Q==; X-IronPort-AV: E=Sophos;i="5.28,586,1464609600"; d="scan'208";a="103684428" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Aug 2016 00:21:10 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Sun, 28 Aug 2016 00:21:11 +1200 From: Peter Gutmann To: "David McGrew (mcgrew)" , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1 Date: Sat, 27 Aug 2016 12:21:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 27 Aug 2016 12:21:14 -0000 David McGrew (mcgrew) writes:=0A= =0A= >Most of the lightweight =93designed for IoT=94 block ciphers have a 64 bit= block=0A= >size (and sometimes even smaller); see for instance Table 1.1 of=0A= >https://eprint.iacr.org/2013/404.pdf So perhaps what the Internet needs he= re=0A= >is sound guidance on how to use 64-bit block ciphers. Best practices her= e=0A= >include both mandatory rekeying well below the birthday bound and/or the u= se=0A= >of secure beyond the birthday bound modes of operation such as Iwata=92s C= ENC.=0A= =0A= IoT devices are, pretty much by default, insecure. And I mean, really, rea= lly=0A= insecure, I've heard phrases like "hack like it's 199x" a number of times= =0A= during talks on all the holes people have found in these things. In additi= on,=0A= the reason why devs are using lightweight ciphers in IoT devices is because= =0A= they know that their device can't use anything more powerful, in the same w= ay=0A= they they know that a strcpy() into a ten-byte fixed-size buffer is a good = way=0A= to decode network packets.=0A= =0A= Looking at it from the other side, your typical IoT device will be sending,= =0A= for example, a 12-byte message every 15 minutes, meaning it'll take, if my= =0A= calculations are right, just under two million years to collect the 785GB o= f=0A= data required to perform the attack.=0A= =0A= So you've got something where the devices aren't vulnerable to the problem= =0A= (and nor, in any practical case, is anything else), for which the devs=0A= involved won't even know that any guidance on the situation exists, and for= =0A= which, if anyone really wants to attack them, they can use any of the dozen= s=0A= of insecure-by-design holes that are present in the device to own the whole= =0A= thing, at which point what you do with your crypto becomes meaningless.=0A= =0A= So what you're proposing is essentially a non-solution to a non-problem...= =0A= still, if you feel like writing the memo for it, don't let me stand in your= =0A= way.=0A= =0A= Peter.= From nobody Sat Aug 27 05:53:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A2612D51A for ; Sat, 27 Aug 2016 05:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzdmBRXdklQq for ; Sat, 27 Aug 2016 05:53:11 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F2412D113 for ; Sat, 27 Aug 2016 05:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3346; q=dns/txt; s=iport; t=1472302390; x=1473511990; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zs1FoM5LXE4cGj5OranKFgCbO6DyASmtAess9LBV8zI=; b=JbLcZO08QLpY3usK0vg4JlQ/jfxTOrPou9iC31FwUsSmLQ32ha9tuJPE EakAz0cElRuVU95JmzHAwCFHulvJJwOlwi4M2QR5gKFRE99UkWzmJn9xI EvNF3EbqP/Ivn3kG4oVg5vxAffLqJ3as3DHqvQd5jMtXTcSrHFIED13zr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAQChjMFX/5hdJa1dDgwBAQEBAgEBA?= =?us-ascii?q?QGDKQEBAQEBHld8B4NAiWiqeYIBIIV9AhyBJjgUAQIBAQEBAQEBXieEYgEBAgI?= =?us-ascii?q?jEVUCAQgODAImAgICMBUQAgQBEhuIJQ6wSo8zAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFwWBA4cjglWCEIITAQEbgwIrgi8FhhKTPQGGH4I9gz6DEI9VkDwBHjaCNBy?= =?us-ascii?q?BETtwAYQsgSB/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,586,1464652800"; d="scan'208";a="314578619" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2016 12:53:09 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7RCr9ZO013092 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 27 Aug 2016 12:53:09 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 27 Aug 2016 07:53:09 -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.1210.000; Sat, 27 Aug 2016 07:53:08 -0500 From: "David McGrew (mcgrew)" To: Peter Gutmann , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/nWfoW+SS6smqUOyCtdxrLUgKaBbmdgAgAF4CoD//8XhAA== Date: Sat, 27 Aug 2016 12:53:08 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.10.228] Content-Type: text/plain; charset="utf-8" Content-ID: <2092DCF482106A4B8AA88B2A25DAE0D2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 27 Aug 2016 12:53:12 -0000 SGkgUGV0ZXIsDQoNCg0KDQoNCk9uIDgvMjcvMTYsIDg6MjEgQU0sICJQZXRlciBHdXRtYW5uIiA8 cGd1dDAwMUBjcy5hdWNrbGFuZC5hYy5uej4gd3JvdGU6DQoNCj5EYXZpZCBNY0dyZXcgKG1jZ3Jl dykgPG1jZ3Jld0BjaXNjby5jb20+IHdyaXRlczoNCj4NCj4+TW9zdCBvZiB0aGUgbGlnaHR3ZWln aHQg4oCcZGVzaWduZWQgZm9yIElvVOKAnSBibG9jayBjaXBoZXJzIGhhdmUgYSA2NCBiaXQgYmxv Y2sNCj4+c2l6ZSAoYW5kIHNvbWV0aW1lcyBldmVuIHNtYWxsZXIpOyBzZWUgZm9yIGluc3RhbmNl IFRhYmxlIDEuMSBvZg0KPj5odHRwczovL2VwcmludC5pYWNyLm9yZy8yMDEzLzQwNC5wZGYgU28g cGVyaGFwcyB3aGF0IHRoZSBJbnRlcm5ldCBuZWVkcyBoZXJlDQo+PmlzIHNvdW5kIGd1aWRhbmNl IG9uIGhvdyB0byB1c2UgNjQtYml0IGJsb2NrIGNpcGhlcnMuICAgQmVzdCBwcmFjdGljZXMgaGVy ZQ0KPj5pbmNsdWRlIGJvdGggbWFuZGF0b3J5IHJla2V5aW5nIHdlbGwgYmVsb3cgdGhlIGJpcnRo ZGF5IGJvdW5kIGFuZC9vciB0aGUgdXNlDQo+Pm9mIHNlY3VyZSBiZXlvbmQgdGhlIGJpcnRoZGF5 IGJvdW5kIG1vZGVzIG9mIG9wZXJhdGlvbiBzdWNoIGFzIEl3YXRh4oCZcyBDRU5DLg0KPg0KPklv VCBkZXZpY2VzIGFyZSwgcHJldHR5IG11Y2ggYnkgZGVmYXVsdCwgaW5zZWN1cmUuICBBbmQgSSBt ZWFuLCByZWFsbHksIHJlYWxseQ0KPmluc2VjdXJlLCBJJ3ZlIGhlYXJkIHBocmFzZXMgbGlrZSAi aGFjayBsaWtlIGl0J3MgMTk5eCIgYSBudW1iZXIgb2YgdGltZXMNCj5kdXJpbmcgdGFsa3Mgb24g YWxsIHRoZSBob2xlcyBwZW9wbGUgaGF2ZSBmb3VuZCBpbiB0aGVzZSB0aGluZ3MuICBJbiBhZGRp dGlvbiwNCj50aGUgcmVhc29uIHdoeSBkZXZzIGFyZSB1c2luZyBsaWdodHdlaWdodCBjaXBoZXJz IGluIElvVCBkZXZpY2VzIGlzIGJlY2F1c2UNCj50aGV5IGtub3cgdGhhdCB0aGVpciBkZXZpY2Ug Y2FuJ3QgdXNlIGFueXRoaW5nIG1vcmUgcG93ZXJmdWwsIGluIHRoZSBzYW1lIHdheQ0KPnRoZXkg dGhleSBrbm93IHRoYXQgYSBzdHJjcHkoKSBpbnRvIGEgdGVuLWJ5dGUgZml4ZWQtc2l6ZSBidWZm ZXIgaXMgYSBnb29kIHdheQ0KPnRvIGRlY29kZSBuZXR3b3JrIHBhY2tldHMuDQo+DQo+TG9va2lu ZyBhdCBpdCBmcm9tIHRoZSBvdGhlciBzaWRlLCB5b3VyIHR5cGljYWwgSW9UIGRldmljZSB3aWxs IGJlIHNlbmRpbmcsDQo+Zm9yIGV4YW1wbGUsIGEgMTItYnl0ZSBtZXNzYWdlIGV2ZXJ5IDE1IG1p bnV0ZXMsIG1lYW5pbmcgaXQnbGwgdGFrZSwgaWYgbXkNCj5jYWxjdWxhdGlvbnMgYXJlIHJpZ2h0 LCBqdXN0IHVuZGVyIHR3byBtaWxsaW9uIHllYXJzIHRvIGNvbGxlY3QgdGhlIDc4NUdCIG9mDQo+ ZGF0YSByZXF1aXJlZCB0byBwZXJmb3JtIHRoZSBhdHRhY2suDQo+DQo+U28geW91J3ZlIGdvdCBz b21ldGhpbmcgd2hlcmUgdGhlIGRldmljZXMgYXJlbid0IHZ1bG5lcmFibGUgdG8gdGhlIHByb2Js ZW0NCj4oYW5kIG5vciwgaW4gYW55IHByYWN0aWNhbCBjYXNlLCBpcyBhbnl0aGluZyBlbHNlKSwg Zm9yIHdoaWNoIHRoZSBkZXZzDQo+aW52b2x2ZWQgd29uJ3QgZXZlbiBrbm93IHRoYXQgYW55IGd1 aWRhbmNlIG9uIHRoZSBzaXR1YXRpb24gZXhpc3RzLCBhbmQgZm9yDQo+d2hpY2gsIGlmIGFueW9u ZSByZWFsbHkgd2FudHMgdG8gYXR0YWNrIHRoZW0sIHRoZXkgY2FuIHVzZSBhbnkgb2YgdGhlIGRv emVucw0KPm9mIGluc2VjdXJlLWJ5LWRlc2lnbiBob2xlcyB0aGF0IGFyZSBwcmVzZW50IGluIHRo ZSBkZXZpY2UgdG8gb3duIHRoZSB3aG9sZQ0KPnRoaW5nLCBhdCB3aGljaCBwb2ludCB3aGF0IHlv dSBkbyB3aXRoIHlvdXIgY3J5cHRvIGJlY29tZXMgbWVhbmluZ2xlc3MuDQoNCkkgZG9u4oCZdCB0 aGluayB5b3UgdW5kZXJzdG9vZCBteSBwb2ludC4gIElvVCBpcyBhYm91dCBzbWFsbCBkZXZpY2Vz IGNvbm5lY3RpbmcgdG8gdGhlIEludGVybmV0LCBhbmQgSUVURiBzdGFuZGFyZHMgc2hvdWxkIGV4 cGVjdCBkZXNpZ25lZC1mb3ItSW9UIGNyeXB0byB0byBiZSBpbmNyZWFzaW5nbHkgaW4gc2NvcGUu ICBJdCBpcyBpbXBvcnRhbnQgdG8gbm90IGZvcmdldCBhYm91dCB0aGVzZSBkZXZpY2VzLCBhbWlk c3QgdGhlIGN1cnJlbnQgYXR0ZW50aW9uIGJlaW5nIHBhaWQgdG8gbWlzdXNlcyBvZiA2NC1iaXQg YmxvY2sgY2lwaGVycywgd2hpY2ggd2FzIHRoZSB1bHRpbWF0ZSBjYXVzZSBvZiB0aGlzIG1haWwg dGhyZWFkLg0KDQoNCg0KPg0KPlNvIHdoYXQgeW91J3JlIHByb3Bvc2luZyBpcyBlc3NlbnRpYWxs eSBhIG5vbi1zb2x1dGlvbiB0byBhIG5vbi1wcm9ibGVtLi4uDQo+c3RpbGwsIGlmIHlvdSBmZWVs IGxpa2Ugd3JpdGluZyB0aGUgbWVtbyBmb3IgaXQsIGRvbid0IGxldCBtZSBzdGFuZCBpbiB5b3Vy DQo+d2F5Lg0KDQpHZWUsIHRoYW5rcy4gIA0KDQpEYXZpZA0KDQo+DQo+UGV0ZXIuDQo= From nobody Sat Aug 27 06:27:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9BE12D580 for ; Sat, 27 Aug 2016 06:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnNKl8fGWoP3 for ; Sat, 27 Aug 2016 06:27:24 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A8E12D579 for ; Sat, 27 Aug 2016 06:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472304444; x=1503840444; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=crNqxH0GaCBvjQZMnEWDjEAATu8H1YM1c0KEcOkyJV0=; b=MYhpb/B+VflRkF3kunuTmUt6dXjNtwTlCQxLPlDBBqHd29ajkr9bW443 5IT5BLxV3+hzK4AENLNxzkI8E2Ff7t2e6PCJXR1WKyltmssvBkOV0lvQn 4ZMc/mfiUOfoeEQSPKaAWSSGWPMtc40tgLHz0QyccY6/rnUdiBwtxMjbg 6rrFqQy59xVr1lIejVNW+YyHaSyNSEdywn5KfD9Hb0jBFfp7DGMVFMOt/ yERjhvD6QLDZ8Rigj5v68q7YUY+MTaLzM+ortDlTk407IlW8tAVOo2GWT v3I6xMo7yZ7NnSeltl6JqE84adWzACxT4g52iDaskhSVg9a6xoYPxLqd4 w==; X-IronPort-AV: E=Sophos;i="5.28,586,1464609600"; d="scan'208";a="103687333" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Aug 2016 01:27:15 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Sun, 28 Aug 2016 01:27:15 +1200 From: Peter Gutmann To: David Benjamin , Geoffrey Keating Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Thread-Index: AQHR+kiDZXbZlYKpgUOnaUdD5zLR56BP1VcAgA0Cxf4= Date: Sat, 27 Aug 2016 13:27:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 13:27:26 -0000 David Benjamin writes:=0A= =0A= >TLS 1.3 will resolve this with the new cipher suite negotiation, but I agr= ee=0A= >this makes the specification basically undeployable with TLS 1.2. This iss= ue=0A= >also got brought up here:=0A= >https://www.ietf.org/mail-archive/web/tls/current/msg18697.html=0A= =0A= Hmm, good point. So reading between the lines of the various comments on t= his=0A= issue, the feeling seems to be "ignore this RFC". That more or less answer= s=0A= my question, I'll leave it out of TLS-LTS apart from mentioning it as anoth= er=0A= source of DH groups.=0A= =0A= >Barring unforeseen problems, Chrome will also lose DH in the next release.= =0A= =0A= Which will be yet another headache for people working with SCADA devices, w= ho=0A= are seeing themselves locked out more and more from being able to admin the= ir=0A= systems when browser vendors arbitrarily decide to deprecate long-establish= ed=0A= mechanisms. I know of operators who are running IE 6 in XP VMs because tha= t's=0A= the only thing that'll still talk to some devices they use (OK, old version= s=0A= of FF and Chrome will do it too if you can find them, but then they always= =0A= want to update themselves to less old versions that stop working again). = =0A= =0A= Couldn't Chrome include an optional legacy mode that just works with existi= ng=0A= systems, perhaps triggered by access to a device at an RFC 1918 address?=0A= There really is, in some cases, nothing available any more that will talk t= o=0A= entire families of SCADA devices because browsers assume the only thing tha= t=0A= matters is the public WWW and won't accommodate anything that isn't.=0A= =0A= (At some point someone's going to figure out they can make a lot of money b= y=0A= taking Firefox 3.0, rebranding it, and selling it as an embedded device=0A= management solution, because it'll talk to all the things that current=0A= browsers won't any more).=0A= =0A= Peter.= From nobody Sat Aug 27 07:28:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E6812D5A2 for ; Sat, 27 Aug 2016 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwg4cWd4UzzJ for ; Sat, 27 Aug 2016 07:28:34 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4883112D590 for ; Sat, 27 Aug 2016 07:28:34 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id o80so29920320wme.1 for ; Sat, 27 Aug 2016 07:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KJ5sg8qjbK6sd8XRcApluEa01QuPhBHPHGeUctwskl0=; b=LF/AJGPI56l9zDnbuRSwZzKIBCNN0bhlxu/5qPjLrX7R4EE5Dz+mbS3J7NCDVNeCAK Hu8mYtCdFgqk0llPXSW2Ly7fSVg9ERjZMldoCW+IB/8SX9CQw36WoQmCnG5srV0l7mxY 7PSJ1aJ8v24U6KXvnMpJGHvPT5oXb59IzlKPQtgBAKDV4GTERcj42/YAAXnzDvCjJwa3 Ldrey8ifTFmSpASm47vGVAhLNzNAW3ghX+E4WKvcO+QoVfgtqkZ4qVHtloZcGeFr6t/R f84rwpnjq/NGwO154NdZjPL5rmET5GXlP0nieDoG/MEcYV6hZ3vg9v9reB+2llCRcUKg 5iZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KJ5sg8qjbK6sd8XRcApluEa01QuPhBHPHGeUctwskl0=; b=hj2U8edJqGE2KY3sLec9bBw4TRXSGBokk/MCw/PouuuoNaH7SEiZBx6tWgPfmgm+xM l0DKEUQLUZUpkoecPfUq0ujTKidZ/B/Njdo9XisQinhQBmJCx5GL18+wsban7lGEvUya zI6zt6ZLYdiWw7DxRr0vbLUhMsYc/Bd46yrYVQ2ofvIra5J6+64XJ6aHqqgpyRmiBbCU 3FYcNaNnYLoV7Cw4td7XgauN+Gkgcsu4Yckbcx/J4y8ulnktxH41Oaqu/fqR2QJSr2zi jV2cKSoVZeawUEbMJLbAItF2bNpu3e3oA/+V/TLdwQ56zyVlj175XEmjaXB5rTRbHwhi AaSA== X-Gm-Message-State: AE9vXwMCaf9zAcbJxSxy6DpKVXKMrn/Ux1Q37wqFIVOOSppJtyzCrh/vOiG8kEHZcfeaBlSaoKrZ6UzDkvRIaw// X-Received: by 10.28.145.137 with SMTP id t131mr3475218wmd.110.1472308112539; Sat, 27 Aug 2016 07:28:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.68 with HTTP; Sat, 27 Aug 2016 07:28:31 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz> From: Ryan Hamilton Date: Sat, 27 Aug 2016 07:28:31 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a1145a97c0caeb6053b0e7294 Archived-At: Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 14:28:36 -0000 --001a1145a97c0caeb6053b0e7294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 27, 2016 at 6:27 AM, Peter Gutmann wrote: > David Benjamin writes: > > >TLS 1.3 will resolve this with the new cipher suite negotiation, but I > agree > >this makes the specification basically undeployable with TLS 1.2. This > issue > >also got brought up here: > >https://www.ietf.org/mail-archive/web/tls/current/msg18697.html > > Hmm, good point. So reading between the lines of the various comments on > this > issue, the feeling seems to be "ignore this RFC". That more or less > answers > my question, I'll leave it out of TLS-LTS apart from mentioning it as > another > source of DH groups. > > >Barring unforeseen problems, Chrome will also lose DH in the next releas= e. > > Which will be yet another headache for people working with SCADA devices, > who > are seeing themselves locked out more and more from being able to admin > their > systems when browser vendors arbitrarily decide to deprecate > long-established > mechanisms. I know of operators who are running IE 6 in XP VMs because > that's > the only thing that'll still talk to some devices they use (OK, old > versions > of FF and Chrome will do it too if you can find them, but then they alway= s > want to update themselves to less old versions that stop working again). > > Couldn't Chrome include an optional legacy mode that just works with > existing > systems, perhaps triggered by access to a device at an RFC 1918 address? > =E2=80=8BAlternatively, someone could write a "Legacy TLS" to "Current TLS"= proxy, which could run on the client's computer to sit in front of these legacy devices. This would allow browsers to continue adding new security features to protect users, while still allowing access to legacy systems.=E2=80=8B > There really is, in some cases, nothing available any more that will talk > to > entire families of SCADA devices because browsers assume the only thing > that > matters is the public WWW and won't accommodate anything that isn't. > > (At some point someone's going to figure out they can make a lot of money > by > taking Firefox 3.0, rebranding it, and selling it as an embedded device > management solution, because it'll talk to all the things that current > browsers won't any more). > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1145a97c0caeb6053b0e7294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 27, 2016 at 6:27 AM, Peter Gutmann = <pgut001@cs.auckland.ac.nz> wrote:
David Benjamin <davidben@chromium.org> writes:
>TLS 1.3 will resolve this with the new cipher suite negotiation, but I = agree
>this makes the specification basically undeployable with TLS 1.2. This = issue
>also got brought up here:
>https://www.ietf= .org/mail-archive/web/tls/current/msg18697.html

Hmm, good point.=C2=A0 So reading between the lines of the various c= omments on this
issue, the feeling seems to be "ignore this RFC".=C2=A0 That more= or less answers
my question, I'll leave it out of TLS-LTS apart from mentioning it as a= nother
source of DH groups.

>Barring unforeseen problems, Chrome will also lose DH in the next relea= se.

Which will be yet another headache for people working with SCADA dev= ices, who
are seeing themselves locked out more and more from being able to admin the= ir
systems when browser vendors arbitrarily decide to deprecate long-establish= ed
mechanisms.=C2=A0 I know of operators who are running IE 6 in XP VMs becaus= e that's
the only thing that'll still talk to some devices they use (OK, old ver= sions
of FF and Chrome will do it too if you can find them, but then they always<= br> want to update themselves to less old versions that stop working again).
Couldn't Chrome include an optional legacy mode that just works with ex= isting
systems, perhaps triggered by access to a device at an RFC 1918 address?

=E2=80=8BAlternatively, someo= ne could write a "Legacy TLS" to "Current TLS" proxy, w= hich could run on the client's computer to sit in front of these legacy= devices. This would allow browsers to continue adding new security feature= s to protect users, while still allowing access to legacy systems.=E2=80=8B=
=C2=A0
There really is, in some cases, nothing available any more that will talk t= o
entire families of SCADA devices because browsers assume the only thing tha= t
matters is the public WWW and won't accommodate anything that isn't= .

(At some point someone's going to figure out they can make a lot of mon= ey by
taking Firefox 3.0, rebranding it, and selling it as an embedded device
management solution, because it'll talk to all the things that current<= br> browsers won't any more).

Peter.
_____________________= __________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo= /tls

--001a1145a97c0caeb6053b0e7294-- From nobody Sat Aug 27 07:38:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2FB12D5A9 for ; Sat, 27 Aug 2016 07:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLGFR51KZ4Ty for ; Sat, 27 Aug 2016 07:38:32 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23312D59A for ; Sat, 27 Aug 2016 07:38:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 0EDEDD79E for ; Sat, 27 Aug 2016 17:38:31 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 06tq9J72mI4L for ; Sat, 27 Aug 2016 17:38:30 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 74E80C4 for ; Sat, 27 Aug 2016 17:38:30 +0300 (EEST) Date: Sat, 27 Aug 2016 17:38:20 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160827143820.leudxrgh2abm5fpg@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 14:38:35 -0000 On Sat, Aug 27, 2016 at 01:27:15PM +0000, Peter Gutmann wrote: > David Benjamin writes: > > >TLS 1.3 will resolve this with the new cipher suite negotiation, but I agree > >this makes the specification basically undeployable with TLS 1.2. This issue > >also got brought up here: > >https://www.ietf.org/mail-archive/web/tls/current/msg18697.html > > Hmm, good point. So reading between the lines of the various comments on this > issue, the feeling seems to be "ignore this RFC". That more or less answers > my question, I'll leave it out of TLS-LTS apart from mentioning it as another > source of DH groups. The bad thing about allowing server to specify arbitrary group is that the group can be such that the client does not like it. E.g. - Too short modulus - Bad modulus - Used subgroup not big enough. The first one is essentially what kills the DH in TLS 1.2. > >Barring unforeseen problems, Chrome will also lose DH in the next release. > > Which will be yet another headache for people working with SCADA devices, who > are seeing themselves locked out more and more from being able to admin their > systems when browser vendors arbitrarily decide to deprecate long-established > mechanisms. It is not "arbitrarily". Thinking back, every TLS-related deprecation I am aware of is because at least one of: - The mechanism is known to have serious security issues. - The mechanism causes serious usability issues. - Virtually nobody uses it (and any use is probably due to misconfig). And with browsers, deprecating stuff takes way more time than it should because of "compatiblity". Most of this is because of bad design. Back in 2002 we would have had all the technology necressary to design stuff that would still be standing 14 years later in 2016, with no hint of breaking in near future. Sure, it would be relatively slow, but that's no security issue. TLS is full of bad decisions (many inherited from SSL v3) that are still haunting us, and it takes pretty much radical redesign (a.k.a. TLS 1.3) to fix it. > Couldn't Chrome include an optional legacy mode that just works with existing > systems, perhaps triggered by access to a device at an RFC 1918 address? > There really is, in some cases, nothing available any more that will talk to > entire families of SCADA devices because browsers assume the only thing that > matters is the public WWW and won't accommodate anything that isn't. Even supporting systems like that is serious security issue. Basically if one even supports weak crypto, there usually are ways to enable it when it should not be enabled, totally compromising security. Whitness the multitude of attacks against TLS that exploit support for weak crypto or bad protocol versions. Even if "disabled". > (At some point someone's going to figure out they can make a lot of money by > taking Firefox 3.0, rebranding it, and selling it as an embedded device > management solution, because it'll talk to all the things that current > browsers won't any more). Well, I'm not aware of anything stopping anyone from doing that... -Ilari From nobody Sat Aug 27 09:36:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8F12B008 for ; Sat, 27 Aug 2016 09:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMP0PKV3ChcV for ; Sat, 27 Aug 2016 09:36:02 -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 6A84512B014 for ; Sat, 27 Aug 2016 09:36:02 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id z190so103926822qkc.0 for ; Sat, 27 Aug 2016 09:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNoMXmKYkIczqbrXF3X8I4spaZqofIFOgM/GsJ91eyU=; b=fXJhGT7pm9AS89n6pOjML7KZLivUCbRftLJTxpv2+pibpc5VwR+cTWOE/MdjkQYNV1 HeHIrof/AASRbmTaBDxdhd4mE4TI2JXLSgpfD44/y4VPqPP5iUTfK2GY5QVQBKDDm3br YnEdSUgpCujKsgrVbMFqAryFukFkN8tIZIgQrAUaE7oYTkhsISmm+a+9Nuq7HoTYrWCt wZJNAjT8yMJPTkHbeCbAAFuIia8Lm0Z1MBwvd0H8DVTuqDOc72HaSZwEJ/p5uTVB1BZE /tL3Wf0PaSz0oA2Zzhc8BliEeL3LfILt+Cjd+7z71BH6hEUEK6ngQW54+85EAsvFPfq+ jO/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNoMXmKYkIczqbrXF3X8I4spaZqofIFOgM/GsJ91eyU=; b=MTi/MrZ6HlkPJV/OTNAd7JV+HENVHHyqaxW83hCbnSWri1kMNkTNNA27xrh8Tv1DSd weOHBmqZ+7WzeK3REVPKpf+0bdwbeXvc8Md3P8CwO6AzjdRevxDIXAGTAKcf9PKzdVUZ 9SDWfqOtmZ36rOq+rKhWqoO18zWNPiTC8ijOCWxLBcnUEckwztIfrjfx10IZuEepB25p 6h+nabgRQnVj3ZlsYMvOvfWDKxUSxyRCLbLAu4iKhU2h3ugREsFDJUxdPbXo+4PC78vp 57U3jKWZa+hLW22e1TS+L4i5n6kbDViHud8G4ZcCQ+hCyi/jAqXcxat12Vf/IJb2Kt1d FTeQ== X-Gm-Message-State: AE9vXwNPPb+/OvPBRdvbGqHL9frLuWa7jzvTXdmPpAqm65IsptuThynZEGOcGBilpwuCzg== X-Received: by 10.55.82.8 with SMTP id g8mr8768615qkb.33.1472315761549; Sat, 27 Aug 2016 09:36:01 -0700 (PDT) Received: from [192.168.0.100] ([71.181.71.184]) by smtp.gmail.com with ESMTPSA id y36sm13399423qtc.46.2016.08.27.09.35.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 27 Aug 2016 09:36:00 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Karthikeyan Bhargavan In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> Date: Sat, 27 Aug 2016 12:35:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F61CE56-4F24-4B88-889E-344F11AEB4D5@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "David McGrew \(mcgrew\)" , "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 27 Aug 2016 16:36:04 -0000 > Looking at it from the other side, your typical IoT device will be = sending, > for example, a 12-byte message every 15 minutes, meaning it'll take, = if my > calculations are right, just under two million years to collect the = 785GB of > data required to perform the attack. I agree that it would be wise to evaluate each deployment scenario to = decide which vulnerabilities have higher priority. But just a brief comment. If every message IoT device sends is a 16 bytes message consisting of = one 8 byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we only need roughly 64GB in order to get a = meaningful collision (50% chance of recovering the secret). The 768GB value we gave was for recovering cookies from realistic web = browser traffic that could be triggered from JavaScript. It is true that in other TLS use cases (such as IoT) some attacks may no = longer be relevant, but unless we are careful some HTTPS attacks may even be worse in these scenarios. Best regards, Karthik >=20 > So you've got something where the devices aren't vulnerable to the = problem > (and nor, in any practical case, is anything else), for which the devs > involved won't even know that any guidance on the situation exists, = and for > which, if anyone really wants to attack them, they can use any of the = dozens > of insecure-by-design holes that are present in the device to own the = whole > thing, at which point what you do with your crypto becomes = meaningless. >=20 > So what you're proposing is essentially a non-solution to a = non-problem... > still, if you feel like writing the memo for it, don't let me stand in = your > way. >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Aug 28 03:48:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA5F12D105 for ; Sun, 28 Aug 2016 03:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqi90ZZLIGUY for ; Sun, 28 Aug 2016 03:48:03 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E261112D0B7 for ; Sun, 28 Aug 2016 03:48:02 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id 52so56791953qtq.3 for ; Sun, 28 Aug 2016 03:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=mOUN216xTOQQqE0RrLvb6hO1FZ6ksvIyphAfitLTOmk=; b=YaZJnAOfNdq2Y7ie+TVjb60GNfLknl+LCwAhudkXv1Mu0eQ2vrWJ+QhESNhnKjkOcQ 5JvJyqO0vQDTcvKqF4chmkdzl7Vog+Sp390CG3mgtp5agVpU0OL/AL9hXLNSFEYd/j1k HScNMCDcQ+dz0d+gnA+bu5qzHiLWSoDZZosu7I0gWwpanY/dj8WQaH9v0xQgBYIor8B1 FPFxCVbYJXexzd4246G3bv6Q7IebVeD9S/8TGeEqJ6J6IrOt6Ut33IJIO3H4BEkhTzcq 7+b4py9NiurdBj8Gf8U/EqQqHxQpYS+Y1ih+3jY1pmRk1V2sSuAriGwzt/KBtxOSaoHw l/Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mOUN216xTOQQqE0RrLvb6hO1FZ6ksvIyphAfitLTOmk=; b=OwWPRtzGz2Lowh1eddAyoemmXwhe2pSMm5cSz55jrAeQH+A58XvUBbbZsMt8pFgfS2 /rJJa4R3K+cz4ukwnZIQqxNc0pThjDKO9UyhPYYM655r6lXZERDJceJvh6fVLIQeSRal DrT733ru98oOdtDqrYMgrr5650hpPZAhAP9WGLyv22V9cz55tH/v2EApqS9GK689ZLZV WIKGIk3utOVssTJ3MzDVFWv/hm+yZA2k5rXjyBL1XcdwEtSCQORWezF2xB6+8ARx1h6+ SjG60UqS0IwIqWjVH90LCYUi1dh1hIaTaFVPk0exCZZJAbjIYy/2TMZvvsGer87pQlcz xylg== X-Gm-Message-State: AE9vXwOwuvwdKcjAhqFYEBdQhin922d3I7014mEm4rQ+S1yDiszeL6TDatPwqSLF2RVVPXiiss4dQfeiBVAtJA== X-Received: by 10.200.52.193 with SMTP id x1mr12345297qtb.65.1472381282034; Sun, 28 Aug 2016 03:48:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.50.86 with HTTP; Sun, 28 Aug 2016 03:48:01 -0700 (PDT) From: "Stanislav V. Smyshlyaev" Date: Sun, 28 Aug 2016 13:48:01 +0300 Message-ID: To: "cfrg@irtf.org" , Mihir Bellare , Paul Lambert , "Paterson, Kenny" , Mike Hamburg , "" Content-Type: multipart/alternative; boundary=001a114757864a292c053b1f7bf7 Archived-At: Subject: [TLS] Document on increasing the lifetime of session keys X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 10:48:04 -0000 --001a114757864a292c053b1f7bf7 Content-Type: text/plain; charset=UTF-8 Dear colleagues, Since there is a considerable interest to the question of increasing session keys lifetime (several productive off-the-list personal discussions about CryptoPro key meshing algorithms and http://eprint.iacr.org/2016/628 started after the Friday posting), maybe we should think about getting started a work on a document on efficient re-keying (about techniques without secret state and/or techniques with it (like in M. Abdalla and M. Bellare work, https://cseweb.ucsd.edu/~mihir/papers/rekey.html)) mechanisms for common cipher modes (CTR, CCM, GCM, CBC, CFB) in CFRG? If you consider it reasonable, we can prepare a first version of such a draft based on our results (both included in that our preprint and new ones which we are working on currently) before IETF 97 to be able to have a discussion on this issue there in Seoul. Kindest regards, Stanislav Smyshlyaev --001a114757864a292c053b1f7bf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear colleagues,

Since there is a co= nsiderable interest to the question of increasing session keys lifetime (se= veral productive off-the-list personal discussions about CryptoPro key mesh= ing algorithms and=C2=A0http://= eprint.iacr.org/2016/628=C2=A0started after the Friday posting), maybe = we should think about getting started a work on a document on efficient re-= keying (about techniques without secret state and/or techniques with it (li= ke in M. Abdalla and M. Bellare work, https://cseweb.ucsd.edu/~mihir/papers/rekey.html)) mechanisms for common cipher modes (CTR, CCM, GCM, CBC, CFB) in CFRG?= =C2=A0

If you consider it reasonable, we can prepare a first version = of such a draft based on our results (both included in that our preprint an= d new ones which we are working on currently) before IETF 97 to be able to = have a discussion on this issue there in Seoul.

--001a114757864a292c053b1f7bf7-- From nobody Sun Aug 28 04:49:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20A12D1BE for ; Sun, 28 Aug 2016 04:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyg9c9p-tbXf for ; Sun, 28 Aug 2016 04:48:59 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711CC12D539 for ; Sun, 28 Aug 2016 04:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472384938; x=1503920938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c3S7nAuldDQHq/KXBv6XFiOIT16mlOOZfLi5SufC9y0=; b=q8LHuK75dEq22hrBSPN8hUCc9gXB1a7OEOtwZcJsBqp1YK3IIsOr8AY5 5ekuHSJsWIsvTDQkPhtOe09qQPfiJP5/u61J6Lz6Zshh2Eo+QyWvviNlJ 9j1CfPf2pf8QHyC/uLs4WVfH8aepH62Kz+5ImhcLQe8CsihI6rRLUsCCp pOcrXDdzM05IXngtXHF6RKOKeB7/C/E0GYQDP3Lxlm42G9ur941kZBwHg fxlljDPak92/GFMBf86pCKDH6abRmQGwmulwepIED+n6xD6rf0gtBVqWD LUseEOP/G2OWK3GxLGfy6tKDTvN104YJu6TxwWXAzmgXJKbr8bs3csDT6 A==; X-IronPort-AV: E=Sophos;i="5.28,590,1464609600"; d="scan'208";a="103741703" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Aug 2016 23:48:53 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Sun, 28 Aug 2016 23:48:54 +1200 From: Peter Gutmann To: Ryan Hamilton Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Thread-Index: AQHR+kiDZXbZlYKpgUOnaUdD5zLR56BP1VcAgA0Cxf7//0i6gIACLpuB Date: Sun, 28 Aug 2016 11:48:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D0524E@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CF009C@uxcn10-5.UoA.auckland.ac.nz> <20160816145548.GQ4670@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4CF1AC9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4CF416C@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D04810@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 11:49:01 -0000 Ryan Hamilton writes:=0A= =0A= >Alternatively, someone could write a "Legacy TLS" to "Current TLS" proxy,= =0A= >which could run on the client's computer to sit in front of these legacy= =0A= >devices. This would allow browsers to continue adding new security feature= s=0A= >to protect users, while still allowing access to legacy systems.?=0A= =0A= Yep, that'd be the other way of doing the "embedded device management=0A= solution". Mind you I think these already exist, they're just called=0A= antivirus proxies and security scanners [0].=0A= =0A= Peter.=0A= =0A= [0] Referring to the number of these that ignore cert checking, allow weak= =0A= keys and ciphers, and so on.=0A= =0A= From nobody Sun Aug 28 05:02:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDF012D555 for ; Sun, 28 Aug 2016 05:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipHtZTzRmerB for ; Sun, 28 Aug 2016 05:02:14 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6629112D0FE for ; Sun, 28 Aug 2016 05:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472385734; x=1503921734; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7vok7lxny8YWwrQOHmTr095CyKyjDn680s/jJtxsOnE=; b=4Owemty03ww4dtF6gEH283A+VEkEng1b8S+FswUx0+XGXaP9ZCzfLS9g aw+WW9EDuZTMMt2fXMWY/LA33C9/HZq6obm4M06JzZNG7scXGBhtdppFE /6cLQuswGTEMoe97ystZRpSGCpIW0qkF3jlXLLtomt1V/zdPXvZjbZL/Z pHhiLO9yO/S79mX9Cs5Xo4UCltCpgpe171WDE19osj8L6PRm/q4rXJXuk +/0v/p2j3NStBVNrTcJlENviLcGAdmKsL0pPnHLkx8X+Y4vW54aEqCBTT cvnanqXnkH7NYIoeD4bL4aIZThhUgOO0dFTkg+h6upHtC8wcP/yX8HEgY w==; X-IronPort-AV: E=Sophos;i="5.28,591,1464609600"; d="scan'208";a="103742355" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Aug 2016 00:01:48 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 29 Aug 2016 00:01:48 +1200 From: Peter Gutmann To: "David McGrew (mcgrew)" , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1//9AtgCAAkz7eQ== Date: Sun, 28 Aug 2016 12:01:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 12:02:16 -0000 David McGrew (mcgrew) writes:=0A= =0A= >I don=92t think you understood my point. IoT is about small devices connec= ting=0A= >to the Internet, and IETF standards should expect designed-for-IoT crypto = to=0A= >be increasingly in scope. It is important to not forget about these devic= es,=0A= >amidst the current attention being paid to misuses of 64-bit block ciphers= ,=0A= >which was the ultimate cause of this mail thread.=0A= =0A= But the IETF has a long history of creating standards that completely ignor= e=0A= IoT. I can't think of a single general-purpose IETF security standard (TLS= ,=0A= SSH, IPsec, etc) that has any hope of working with IoT devices (say a 40Mhz= =0A= ARM-core ASIC with 32kB RAM and 64kB flash). This is why the ITU/IEC and a= =0A= million lesser-known standards bodies are all busy inventing their own=0A= exquisitely homebrew crypto protocols, most of which make WEP look like a= =0A= model of good design.=0A= =0A= (I've always wanted to sit down and design a generic "encrypted pipe from A= to=0A= B using minimal resources" spec, and I'm sure many other people have had th= e=0A= same thought at one time or another).=0A= =0A= So it seems like you've got:=0A= =0A= - The "TLS =3D the web" crowd (browser vendors and the like) who will imple= ment=0A= whatever's trendy at the moment and assume everyone has a quad-core 2GHz = CPU=0A= with gigabytes of RAM and access to weekly live updates and hotfixes.=0A= =0A= - Embedded/SCADA folks who need to deal with 10-15 year product cycles (see= my=0A= TLS-LTS draft for more on this) and are kind of stuck.=0A= =0A= - IoT people, who can't use any standard protocol and will get the least=0A= unqualified person on staff to invent something that seems OK to them.=0A= =0A= I'm not sure that a draft on theoretical weaknesses in 64-bit block ciphers= is=0A= going to affect any of those...=0A= =0A= Peter.= From nobody Sun Aug 28 05:16:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC0012D0FE for ; Sun, 28 Aug 2016 05:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6DCH-KkM_Ps for ; Sun, 28 Aug 2016 05:16:19 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D1F12D600 for ; Sun, 28 Aug 2016 05:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472386578; x=1503922578; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IcPZTVF09HKWBmY/W+NjjsXFdmPCsE+3514GuOW0fzA=; b=bG4c/+wBklhQjTtURmXeNsNeq/O5I4T1kvBtXBNSsO+g4xNdxkJkaaCI R6EbgPNspAL6wxZzlkHMzJm+iBhHRCnNjNS3b3DPvdPNYkpvhUrMgVJ5i zypRYcOPnP+eoqFFDYn7zQ9bWCTwXyULnP6kVCEid0nSJulm1r4GCfqnW bPxge6FssCCecn5p1hd1HSOt1R1F9HIX8p/NI6rfiv2P4JRXBzFBIXFoK dfA9ENceTWNZGlmxJKH4HVTzmv4s8jdGruPKU94+D8YOpgE4QVt8ZrHyP DR7vITq7/KFdoXvbTFmYVxhMMJZhtARCHZxAS5fx8ywLOkqKwXDoHkLK4 w==; X-IronPort-AV: E=Sophos;i="5.28,591,1464609600"; d="scan'208";a="103742998" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Aug 2016 00:16:16 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 29 Aug 2016 00:16:16 +1200 From: Peter Gutmann To: Karthikeyan Bhargavan Thread-Topic: [TLS] [Cfrg] 3DES diediedie Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1//9++oCAAhKmbg== Date: Sun, 28 Aug 2016 12:16:16 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D052A9@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz>, <3F61CE56-4F24-4B88-889E-344F11AEB4D5@gmail.com> In-Reply-To: <3F61CE56-4F24-4B88-889E-344F11AEB4D5@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "David McGrew \(mcgrew\)" , "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 12:16:20 -0000 Karthikeyan Bhargavan writes:=0A= =0A= >If every message IoT device sends is a 16 bytes message consisting of one = 8=0A= >byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we= =0A= >only need roughly 64GB in order to get a meaningful collision (50% chance = of=0A= >recovering the secret). The 768GB value we gave was for recovering cookies= =0A= >from realistic web browser traffic that could be triggered from JavaScript= .=0A= =0A= Sure, and I picked the 768GB value because it looks especially unrealistic= =0A= :-). However, for typical SCADA/IoT even a value of 100MB is probably=0A= unrealistic in practice, for the combined reasons that the device just isn'= t=0A= interesting to attack, it doesn't send enough data to collect lots of it=0A= unless you're prepared to wait a really long time, and, most importantly,= =0A= there are a thousand easier ways to get in if you really want to.=0A= =0A= Has anyone every seen a SCADA device that stood up to even the smallest amo= unt=0A= of analysis/pen-testing? I've currently got a rather pricey security=0A= monitoring box sitting here awaiting investigation, and I can pretty much= =0A= guarantee I'll find something like unencrypted C&C, calling home to random= =0A= addresses overseas, unauthenticated firmware updates, and who knows what el= se,=0A= just from simple Pineapple or Ettercap check, let alone any kind of active= =0A= pen-testing.=0A= =0A= So I think it's important to distinguish between a cool demo in the lab and= =0A= something an attacker would actually do. Of all the talks and demos I've s= een=0A= of people compromising SCADA and IoT devices, precisely zero even looked at= =0A= the crypto, let alone tried to attack it [0]. So if it's something that no= -=0A= one bothers attacking because there's always an easier way, it doesn't matt= er=0A= how strong or weak it is.=0A= =0A= As Ian Grigg recently put it:=0A= =0A= The problem we have is not how to get stronger crypto in place, it's how = to=0A= get more crypto in place.=0A= =0A= Securing something like MQTT would be a good start...=0A= =0A= Peter.=0A= =0A= [0] Alongside simply ignoring the fact that crypto may or may not be presen= t,=0A= I'm also taking things like "fails to check cert issuers" and "allows= =0A= unauthenticated remote firmware updates" as "not looking at the crypto"= .= From nobody Sun Aug 28 05:26:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0212B042 for ; Sun, 28 Aug 2016 05:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-nLl5Gtqf7q for ; Sun, 28 Aug 2016 05:26:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF44A12D11D for ; Sun, 28 Aug 2016 05:26:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C51ADBE29; Sun, 28 Aug 2016 13:26:09 +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 vZJcMzSm3Tcw; Sun, 28 Aug 2016 13:26:07 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 61494BE25; Sun, 28 Aug 2016 13:26:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472387167; bh=a6TVWHLRZpMy1pfwIxOjruotYScitl1XCiTg7QaG8o8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=k1vMO/vfJHhHIgbThqQZSc6DELZ9vtade78Fy5j79xRS9nXI0iwKoGh+Wb5Su9N1b 2ZmzFBKy3q8YFfezV02D/vkyOlGkKnIZOvBHfqe62RiJl93bkrmZqSJPlZ/F5z3+4L oHcseA3e3mlFexzGq+nR8TJ5yY2LxY6lpPkk3o/w= To: Peter Gutmann , "David McGrew (mcgrew)" , Tony Arcieri , "" , "cfrg@irtf.org" References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 28 Aug 2016 13:26:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020207040104090309010201" Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 12:26:15 -0000 This is a cryptographically signed message in MIME format. --------------ms020207040104090309010201 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Peter, On 28/08/16 13:01, Peter Gutmann wrote: > David McGrew (mcgrew) writes: >=20 >> I don=E2=80=99t think you understood my point. IoT is about small devi= ces connecting >> to the Internet, and IETF standards should expect designed-for-IoT cry= pto to >> be increasingly in scope. It is important to not forget about these d= evices, >> amidst the current attention being paid to misuses of 64-bit block cip= hers, >> which was the ultimate cause of this mail thread. >=20 > But the IETF has a long history of creating standards that completely i= gnore > IoT. =20 IIRC the IoT marketing term doesn't have a very long history so I don't really know what substance lies behind that remark. > I can't think of a single general-purpose IETF security standard (TLS, > SSH, IPsec, etc) that has any hope of working with IoT devices (say a 4= 0Mhz > ARM-core ASIC with 32kB RAM and 64kB flash). This is why the ITU/IEC a= nd a > million lesser-known standards bodies are all busy inventing their own > exquisitely homebrew crypto protocols, most of which make WEP look like= a > model of good design. >=20 > (I've always wanted to sit down and design a generic "encrypted pipe fr= om A to > B using minimal resources" spec, and I'm sure many other people have ha= d the > same thought at one time or another). Then why don't you do that? If others found it useful, then I'm sure they'd want to use it and there'd be support for it in the IETF. (And to be clear, I don't think your lts draft for TLS matches the above.) One wrinkle though is that it seems that there's a real demand for "encrypted pipe from A to B and hundreds of others using minimal resources" spec - I'm not sure that the two party version is really the main missing spec here. S. >=20 > So it seems like you've got: >=20 > - The "TLS =3D the web" crowd (browser vendors and the like) who will i= mplement > whatever's trendy at the moment and assume everyone has a quad-core 2= GHz CPU > with gigabytes of RAM and access to weekly live updates and hotfixes.= >=20 > - Embedded/SCADA folks who need to deal with 10-15 year product cycles = (see my > TLS-LTS draft for more on this) and are kind of stuck. >=20 > - IoT people, who can't use any standard protocol and will get the leas= t > unqualified person on staff to invent something that seems OK to them= =2E >=20 > I'm not sure that a draft on theoretical weaknesses in 64-bit block cip= hers is > going to affect any of those... >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms020207040104090309010201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4Mjgx MjI2MDdaMC8GCSqGSIb3DQEJBDEiBCDPuXTzlbMiPY9raLEDcepeh1MjBkPkx7uk1BDBQzwz bTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAdGrzZSxMPFy4AV/yHdP/01vcq+3Ski6LiITHesbWmOPWoubvRNOOk VqaOdOV9nc9L8I+G5uGyBv3MNr0M0y3kpJY4q0A7jEr0VcUgQgo4ZcYANQ94SRfVjxCzAqAJ KeNY8EiWxp4EGmvTVHg+U1Sh/Ep8z8Xq06OmjKzMgHvvmFIL1sprmlNHk2gCxQURyF17Lsvz o1g4U9tqDT/7BM7CbvhDpa+R0hnMFhf1RtqiwreklMUmKgGATLHWTbgr5M6sm26Qedu1I1ji F2u8I1d3dn3knfbdL0uoxz9RNDQkq0pSsjO4p6lvheYfYtpl6tmxCDIjvvLWFr40TNIU+wre AAAAAAAA --------------ms020207040104090309010201-- From nobody Sun Aug 28 06:52:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B5812B00B for ; Sun, 28 Aug 2016 06:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO1saGz2rmsk for ; Sun, 28 Aug 2016 06:52:33 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9E612B009 for ; Sun, 28 Aug 2016 06:52:33 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u134so73097937ywg.3 for ; Sun, 28 Aug 2016 06:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uL1ns/HISJBhSMxlcpPpQRj0t03oGbHvMJeGjMgckQw=; b=MDmSkrMkkr1mujCgNWm+cq5AhVPeyUg+qt9+uTRyShSP4AgxG40CCEJQdL+izDFZFu Fh4zyEVJSi1OolZNZ3+jY9xINSME0+mSxlK6t6TmseHn/oo2pGPycEbU8ahsAWdq/juh zZZ/Fgi0mKXZw55CEpM3MEONibBI7Jw4IMry32NxjaYa0XSi3A7XTiUbWBYxSqr/OoqQ wNdtyh2jGtG4brw18LsgFgs1VqxmNB928eKinupeDpNBTYawIEYLxzTdZEt0e0DvYEDG whE2D+RZ42qb74PWxjcc2YLOjcRpmL4crnKziC2s9haLoqVv80IoIjrIPyfyVe9IaH8p 2kNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uL1ns/HISJBhSMxlcpPpQRj0t03oGbHvMJeGjMgckQw=; b=L5cTeyae71IXTcf9MVlLHAHKAkNPFe+bxHxXA253vivcuKzHgwFighR/U81RB9ql4t OGgsQdqQWDiT8YMA1rZvqHeoaDK4slQoIzbM9QfLGBv3UkCyq5PMYAh9+kRAklltiC4i q31CQluhvyT0aEr3mwlppXr0L11hpq5epUHPnU+6x7j6aFaY/tjNP8DsI2e2UAEnmPzz UB+1Ez7x6hkIqf0JsZDHtxZhkX3+ioV0uL5hytDeM5TZxX+timHB7PMvqwKfLoo0oSGB w52kHsCMvaiguiognsDTcK/Q6bB+xE4IzKyxv+Ozbdp4B+/LFyRbq1nvTyPmsNJsHxky ttQg== X-Gm-Message-State: AE9vXwPyX1lIpovxNWwLooGnRw/Y7fwoXjBtO9fg4bk1Eyl+IeMYwIYy3V6fJdx+Sj9eEecGKcZrA2k8LSkk/w== X-Received: by 10.129.161.129 with SMTP id y123mr12169375ywg.214.1472392352658; Sun, 28 Aug 2016 06:52:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Sun, 28 Aug 2016 06:51:52 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 28 Aug 2016 06:51:52 -0700 Message-ID: To: "Stanislav V. Smyshlyaev" Content-Type: multipart/alternative; boundary=001a114f8db226a89f053b220f8d Archived-At: Cc: Mihir Bellare , "cfrg@irtf.org" , "" , Paul Lambert Subject: Re: [TLS] Document on increasing the lifetime of session keys X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 13:52:35 -0000 --001a114f8db226a89f053b220f8d Content-Type: text/plain; charset=UTF-8 Stanislav, TLS 1.3 incorporates a rekeying mechanism (KeyUpdate) similar to that if Abdalla and Bellare 1(b). -Ekr On Sun, Aug 28, 2016 at 3:48 AM, Stanislav V. Smyshlyaev wrote: > Dear colleagues, > > Since there is a considerable interest to the question of increasing > session keys lifetime (several productive off-the-list personal discussions > about CryptoPro key meshing algorithms and http://eprint.iacr.org/2016/628 started > after the Friday posting), maybe we should think about getting started a > work on a document on efficient re-keying (about techniques without secret > state and/or techniques with it (like in M. Abdalla and M. Bellare work, > https://cseweb.ucsd.edu/~mihir/papers/rekey.html)) mechanisms for common > cipher modes (CTR, CCM, GCM, CBC, CFB) in CFRG? > > If you consider it reasonable, we can prepare a first version of such a > draft based on our results (both included in that our preprint and new ones > which we are working on currently) before IETF 97 to be able to have a > discussion on this issue there in Seoul. > Kindest regards, > Stanislav Smyshlyaev > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114f8db226a89f053b220f8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stanislav,

TLS 1.3 incorporates a rekey= ing mechanism (KeyUpdate) similar to that if Abdalla and Bellare 1(b).

-Ekr

On Sun, Aug 28, 2016 at 3:48 AM, Stanislav V. = Smyshlyaev <smyshsv@gmail.com> wrote:

Dear colleagues,

Since there is a considerable i= nterest to the question of increasing session keys lifetime (several produc= tive off-the-list personal discussions about CryptoPro key meshing algorith= ms and=C2=A0h= ttp://eprint.iacr.org/2016/628=C2=A0started after the Friday posti= ng), maybe we should think about getting started a work on a document on ef= ficient re-keying (about techniques without secret state and/or techniques = with it (like in M. Abdalla and M. Bellare work, https://cseweb.ucsd.ed= u/~mihir/papers/rekey.html)) mechanisms for common cipher modes (C= TR, CCM, GCM, CBC, CFB) in CFRG?=C2=A0

If you consider it reasonable,= we can prepare a first version of such a draft based on our results (both = included in that our preprint and new ones which we are working on currentl= y) before IETF 97 to be able to have a discussion on this issue there in Se= oul.

Kindest regards,
Stanislav Smyshlyaev

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


--001a114f8db226a89f053b220f8d-- From nobody Sun Aug 28 06:55:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C24612B00B for ; Sun, 28 Aug 2016 06:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kkCx03m1pZ0 for ; Sun, 28 Aug 2016 06:55:50 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCC012B009 for ; Sun, 28 Aug 2016 06:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472392550; x=1503928550; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=unBSma0q9IPv//s4e317Rn1Lmqgw2jshSM1Y4Xk/pdY=; b=bCV1Dp5ByChOJixvpGzHmuGn1MXp8dE164Ck+1/MturRQIAMTITVf3Nt BeyK498UGgr6mGawI4jM+mLUGSIuEAfalYuUj0hcmfcJ9j3dPw5X6+9XU wAwwhm8ELWYyZWPFVC6ftnttqMe/MTewj2JW2IWhTJQEHe4GpyGvMFQjs Kz5sUPQEbK4/wBPzEMC23Nigl7WK9ABVnPhSeOOcGTzutIbXVAeyMrUWQ kaY7UOUtJlQlzC0MWCcVDlnQx6+Q9cohOzRzk3ol6xdsnuXjYfHQ5/Cw8 w1ZugMLync6tYR35lJEzi+BVdMwQ/EgDObLDzv2vYc+oorY9h3QGBtP6H w==; X-IronPort-AV: E=Sophos;i="5.28,591,1464609600"; d="scan'208";a="103747894" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Aug 2016 01:55:47 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 29 Aug 2016 01:55:47 +1200 From: Peter Gutmann To: Stephen Farrell , "David McGrew (mcgrew)" , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [TLS] [Cfrg] 3DES diediedie Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1//9AtgCAAkz7ef//Pc6AgADiEHs= Date: Sun, 28 Aug 2016 13:55:47 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D053AB@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 13:55:52 -0000 Stephen Farrell writes:=0A= =0A= >IIRC the IoT marketing term doesn't have a very long history so I don't=0A= >really know what substance lies behind that remark.=0A= =0A= I just used "IoT" because someone else had used it, since it's about as wel= l-=0A= defined as "Web 2.0" I agree that it's not terribly useful to define a feat= ure=0A= set. What I meant was low-power embedded, smart meters and the like, IoT i= n=0A= the sense of "little internet-enabled things".=0A= =0A= >>(I've always wanted to sit down and design a generic "encrypted pipe from= A=0A= >>to B using minimal resources" spec, and I'm sure many other people have h= ad=0A= >>the same thought at one time or another).=0A= >=0A= >Then why don't you do that?=0A= =0A= It's a bit like designing a new { OS | programming language | network proto= col=0A= | ... }, everybody who works in the relevant field would like to have a go = at=0A= something like this, and probably have a lot of fun fiddling with it, but I= 'm=0A= not sure how much appeal it would have to anyone apart from the person play= ing=0A= with it. So the answer is "for the same reason I haven't had a go at=0A= designing a new OS, programming language, network protocol, etc".=0A= =0A= Peter.= From nobody Sun Aug 28 07:42:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AF912D098 for ; Sun, 28 Aug 2016 07:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61AxAQlM_j_K for ; Sun, 28 Aug 2016 07:42:24 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010: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 0258B12B04C for ; Sun, 28 Aug 2016 07:42:24 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id g62so85179069lfe.3 for ; Sun, 28 Aug 2016 07:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=xrw66QyWF7UMh7uLhJ/mOwz0oG+ekBTR2wBTkownCA8=; b=w+fwxZPNjTL7HOThAS7QmUloQP3ADoTEXU7m7zYHMSmn4sfRf+gjYEwDlZJI7r2+8f giHddPX3PndL29JuVHUg1DZFo2Vk/XH1od/BeZbav1foHb5BJhOPeVcThgmKf7i1yeWl aF4R0CkYjm1kwDD4NfsvspilC6l/VIqSe2mxpW1mhqxEB/yLUcpk4kYhQbsdp5gSn3u5 QHg/Tbw6LkJaisGkG+B2fY+cWdxFYTcnnr0bEr3zVx+0NBd0ySYVCSWwEgu1zFVKMuzK 7D4Pvs1z0F7vPu/zcl1VXEsr6ZAweoCPzHAbZOOEu8PWY4H88HygyeGJrndT9326G5ff zcag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=xrw66QyWF7UMh7uLhJ/mOwz0oG+ekBTR2wBTkownCA8=; b=JaxP6t4MAGc99+cBqGAasDRnzj/9M4qq36JYT162r4+MqLQb/+j20M7hw5XyYsqxYg 72ipDWAOcgbSD4yBQge4CAHZHqhmGdZ8/RFXlkmz7tVBlkVcDp3PdCw3DMOHbgNIitnF o6Imu4qeQICoutfJ88/JaQxh9mQx4tXUe3f2G4oJK73KSDP0hxCPLI8Q0aGjELFgbXiF bifdxONU6wmoCi21wCxzZ5c38YvqtpnojjHvELa+ZC1e1DnNRxE/FXTYGfPOOUHSANsl iHArlHFctYgzC5X0z1pz8+mBj1QjFUczMMFO2dqeaJqW9t4m1Pr0hrSxfULA7XAWYiBw XUvQ== X-Gm-Message-State: AE9vXwP7sJbT2umJTMnQRAu5bA2YKCjE5CdZI9kT/zpTbJLsXAA4d3zkutRDiXSyHduPEA== X-Received: by 10.25.159.205 with SMTP id i196mr4194531lfe.45.1472395341965; Sun, 28 Aug 2016 07:42:21 -0700 (PDT) Received: from [127.0.0.1] ([213.87.134.26]) by smtp.gmail.com with ESMTPSA id 74sm5714418ljb.36.2016.08.28.07.42.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 28 Aug 2016 07:42:21 -0700 (PDT) Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160828144220.5828688.24760.6532@gmail.com> Date: Sun, 28 Aug 2016 17:42:20 +0300 From: "Stanislav V. Smyshlyaev" In-Reply-To: References: To: Eric Rescorla Archived-At: Cc: Mihir Bellare , cfrg@irtf.org, "" , Paul Lambert Subject: Re: [TLS] Document on increasing the lifetime of session keys X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 14:42:26 -0000 =
=E2=80=8EDear Eric,

Thank you for your co= mment - indeed, re-keying mechanisms based on secret state are widely used = in the protocols (key trees are usual practice in ESP with GOSTs for more t= han 10 years, for example). My point is that a simple (e.g. without any add= itional keys or structures) and effective mechanism to increase =E2=80=8Ebl= ock cipher modes limitations on plaintext size can be helpful itself, witho= ut incorporating to a protocol. 

About connectio= n with TLS 1.3 draft - for example, we don't want the GCM mode be defined i= nside some protocol RFC, it should be defined separately, isn't it?  S= o the question is that if such mechanisms are needed, than separate documen= ts on them can be a better solution.

And m= y primary point here is about stateless techniques: as follows from t=E2=80= =8Ehe preprint I cited before, the key lifetime for CTR can be increased qu= adratically, for example. 

Kindest regards,
Stanislav

=
= =
=D0=9E=D1=82: Eric Rescorla
=D0=9E=D1= =82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE: =D0=B2=D0=BE=D1=81= =D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 28 =D0=B0=D0=B2=D0=B3=D1= =83=D1=81=D1=82=D0=B0 2016 =D0=B3., 16:52
=D0=9A=D0=BE=D0= =BC=D1=83: Stanislav V. Smyshlyaev
=D0=9A=D0=BE=D0=BF=D0= =B8=D1=8F: cfrg@irtf.org; Mihir Bellare; Paul Lambert; Paterson, Kenny;= Mike Hamburg; <tls@ietf.org>
=D0=A2=D0=B5=D0=BC=D0=B0: = Re: [TLS] Document on increasing the lifetime of session keys

<= div id=3D"_originalContent" style=3D"">
Stanislav,

=
TLS 1.3 incorporates a rekeying mechanism (KeyUpdate) similar to= that if Abdalla and Bellare 1(b).

-Ekr
=

On Sun,= Aug 28, 2016 at 3:48 AM, Stanislav V. Smyshlyaev <smyshsv@gmail.com&g= t; wrote:

Dear colleagues,<= /p>

Since there is a considerable interest to the question of increasing = session keys lifetime (several productive off-the-list personal discussions= about CryptoPro key meshing algorithms and http://eprint.iacr.org/2016/628 started after the Friday posting), maybe we should think about getti= ng started a work on a document on efficient re-keying (about techniques wi= thout secret state and/or techniques with it (like in M. Abdalla and M. Bel= lare work, https://cseweb.ucsd.edu/~mihir/papers/rekey.html)) = mechanisms for common cipher modes (CTR, CCM, GCM, CBC, CFB) in CFRG? =

If you consider it reasonable, we can prepare a first version of suc= h a draft based on our results (both included in that our preprint and new = ones which we are working on currently) before IETF 97 to be able to have a= discussion on this issue there in Seoul.

Kindest regards,
Stanislav Smyshlyaev

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



From nobody Sun Aug 28 10:53:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CE712B050 for ; Sun, 28 Aug 2016 10:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwRQpCtTA7UO for ; Sun, 28 Aug 2016 10:53:55 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C1712B018 for ; Sun, 28 Aug 2016 10:53:55 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id j12so74902190ywb.2 for ; Sun, 28 Aug 2016 10:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V4EEDUWmnzwW0J9su7aFQI7broCglulO86hLjZVV2A8=; b=pXNIFUCG8+gtndQOON4huZrFJDY3cQXVkVM1gRlcmtOqJcAeb7jZxeXyiLOK8BebSz BcdlZf+Mo8/OXKHV1V0/DakqQeXOdZts1RTyURs4Ee5nSIOufHyqb+GapgIAbAqJjbRl sulqtE6IOvmHZzjzckrUCMGnH7Du7A4CQeLquxdODmmNJy0v+HSo9rXuJ94MidyW5or/ JmIY6/jUL26BgascyFOa62d5MHsz4xPamuZOdMxrKTVK6z61vWA5aA5MiyYo1clxIhFp ANxkoMseHsH22nD2ec8qyn0x5IvKoc1wUxNsiCMVGXkKUWrylYmDHsePF7DZngI2yPeJ y2hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V4EEDUWmnzwW0J9su7aFQI7broCglulO86hLjZVV2A8=; b=YzTF5ahkqRekGQnccJ9s4JD+JF/rhzDOX7+Pur7gVT3R8VZf4T9mIRhb4LHV8L1wT8 GwMsw/0LP679AvG/YWJHC94SjLILMwFfxnMUrUrxAQNOzfu/E8j5AIvSK+maZ5IxgdrJ dMAYe43b55OuRkUS0HvNO/VLqaat0Xv4Ml5XgNyfpXbgBxizQZhKgGlXEBDJg8Vl/7HS 6ON1CME7Gd6cxk9FXXJCLAPn/NzbmZUtDVccgXGmK8BjYSWplvUgDBmIj2Dnjl361UUE aRak1D5FV/+xkTwwm3jC/hGro1lQ6a7K3EonGHoal+EX3YX6KYF3CRTVqy6p4v3VAmsc 2WFg== X-Gm-Message-State: AE9vXwPsWZoN9pdrYSm7PvdwtP4XE5G1XC0Oj9r0Yq4fpMDXMKjKvzdFHs0FYvlOX1prQt/NhIgJrcfusL3zWg== X-Received: by 10.129.125.135 with SMTP id y129mr12174763ywc.107.1472406834962; Sun, 28 Aug 2016 10:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Sun, 28 Aug 2016 10:53:14 -0700 (PDT) In-Reply-To: References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 28 Aug 2016 10:53:14 -0700 Message-ID: To: Keith Winstein Content-Type: multipart/alternative; boundary=001a11492ce85d21f9053b256e06 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 17:53:58 -0000 --001a11492ce85d21f9053b256e06 Content-Type: text/plain; charset=UTF-8 I'd like to close this discussion if we can. I'd prefer to keep things as simple as possible here and from that perspective, I think any indicator from side A to side B that it wants a key change over and above the KeyUpdate is extra complexity. I do, however, want to retain the property that one side can ask the other one to rekey [0]. I believe we can get this by modifying the rule in the spec by treating a run of KeyUpdates as a single generation. Specifically. "Upon receiving a KeyUpdate, the receiver MUST update its receiving keys. If the receiver has sent any data records since receiving the last KeyUpdate it MUST also increment its min_send_generation counter by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior to sending a record, if min_send_generation is greater than the current sending generation, the sender MUST first send a KeyUpdate." This still leaves open the question of whether we should advertise the current receiving generation or have two ladders, but I believe those are orthogonal to David's issue. Does anyone see a reason why this won't work? -Ekr [0] My reasoning here is that it allows implementations who learn about new limits for a cipher or are otherwise more conservative than their peer to get more aggressive updates even if it's the other side doing most of the sending. On Thu, Aug 25, 2016 at 12:31 PM, Keith Winstein wrote: > On Wed, Aug 24, 2016 at 9:23 PM, Ilari Liusvaara > wrote: > > The generations are not specified as integers. It is just some abstract > > sequence (nowhere in protocol is that generations are integers used). > > The current draft requires that upon receipt of a KeyUpdate, "the > receiver MUST update their receiving keys and if they have not already > updated their sending state up to or past the then current receiving > generation MUST send their own KeyUpdate prior to sending any other > messages." > > This requires the generation counts to be comparable for inequality. > Implementations will have to keep track of the generations, or the > difference between them, in an integer counter. (How else would you do > it?) > > > Due to design, one can't do a reciproal rekey. > > Hmm, there must be some misunderstanding. In the current draft, > *every* time a node receives KeyUpdate #N (rekeying the incoming > direction), it MUST reciprocate by rekeying its outgoing direction > unless it has already sent at least N KeyUpdates. Current text: "This > mechanism allows either side to force an update to the entire > connection." > > >> (3) Fire-and-later-check. The TLS implementation exposes #2 above, but > >> also `tls_session_generations()`, which returns a pair of integers > >> giving the current sending and receiving generations. > >> > >> Any application we might want to build can be built on top of #3. > > > > Nope, the KeyUpdate is designed to deal with arbitrary latency in > > order to fully decouple the direction (any coupling there would lead > > to API problems, which apparently are more major than I initially > > thought). > > Not quite sure what you're disagreeing with. Our proposal is also > designed to deal with arbitrary latency. It's a field piggybacking on > the otherwise-unmodified KeyUpdate messages. > > -Keith > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11492ce85d21f9053b256e06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd like to close this discussion if we can.

<= /div>
I'd prefer to keep things as simple as possible here and from= that perspective, I think any indicator from side A to side B that it want= s a key change over and above the KeyUpdate is extra complexity. I do, howe= ver, want to retain the property that one side can ask the other one to rek= ey [0]. I believe we can get this by modifying the rule in the spec by trea= ting
a run of KeyUpdates as a single generation.

Specifically.
"Upon receiving a KeyUpdate, the rece= iver MUST update its receiving
keys. If the receiver has sent= any data records since receiving the
last KeyUpdate it MUST also= increment its min_send_generation counter
by 1. Otherwise, the m= in_send_generation MUST remain unchanged. Prior
to sending a reco= rd, if min_send_generation is greater than the
current sending ge= neration, the sender MUST first send a KeyUpdate."

This still leaves open the question of whether we should advertise th= e current
receiving generation or have two ladders, but I believe= those are orthogonal to
David's issue. Does anyone see a rea= son why this won't work?

-Ekr

[0] My reasoning here is that it allows implementations who learn = about new limits for a cipher or are otherwise more conservative than their= peer to get more aggressive updates even if it's the other side doing = most of the sending.



On Thu, Aug 25, 2016 at 12:31 = PM, Keith Winstein <keithw@cs.stanford.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Wed, Aug 24, 2016 at 9:23= PM, Ilari Liusvaara
<ilariliusvaara@welho.com> wrote:
> The generations are not specified as integers. It is just some abstrac= t
> sequence (nowhere in protocol is that generations are integers used).<= br>
The current draft requires that upon receipt of a KeyUpdate, "t= he
receiver MUST update their receiving keys and if they have not already
updated their sending state up to or past the then current receiving
generation MUST send their own KeyUpdate prior to sending any other
messages."

This requires the generation counts to be comparable for inequality.
Implementations will have to keep track of the generations, or the
difference between them, in an integer counter. (How else would you do
it?)

> Due to design, one can't do a reciproal rekey.

Hmm, there must be some misunderstanding. In the current draft,
*every* time a node receives KeyUpdate #N (rekeying the incoming
direction), it MUST reciprocate by rekeying its outgoing direction
unless it has already sent at least N KeyUpdates. Current text: "This<= br> mechanism allows either side to force an update to the entire
connection."

>> (3) Fire-and-later-check. The TLS implementation exposes #2 above,= but
>> also `tls_session_generations()`, which returns a pair of integers=
>> giving the current sending and receiving generations.
>>
>> Any application we might want to build can be built on top of #3.<= br> >
> Nope, the KeyUpdate is designed to deal with arbitrary latency in
> order to fully decouple the direction (any coupling there would lead > to API problems, which apparently are more major than I initially
> thought).

Not quite sure what you're disagreeing with. Our proposal is als= o
designed to deal with arbitrary latency. It's a field piggybacking on the otherwise-unmodified KeyUpdate messages.

-Keith

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

--001a11492ce85d21f9053b256e06-- From nobody Sun Aug 28 11:41:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F229A12B032 for ; Sun, 28 Aug 2016 11:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I34VWCe_fud2 for ; Sun, 28 Aug 2016 11:41:19 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id F41D0127078 for ; Sun, 28 Aug 2016 11:41:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id D8C5BFF4C; Sun, 28 Aug 2016 21:41:16 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Xo0ujq-lkaLw; Sun, 28 Aug 2016 21:41:16 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 7C9FE2313; Sun, 28 Aug 2016 21:41:16 +0300 (EEST) Date: Sun, 28 Aug 2016 21:41:06 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160828184105.yvrnbispbnpomk4s@LK-Perkele-V2.elisa-laajakaista.fi> References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@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.6.2-neo (2016-08-21) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 18:41:21 -0000 On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: > > I'd prefer to keep things as simple as possible here and from that > perspective, I think any indicator from side A to side B that it wants a > key change over and above the KeyUpdate is extra complexity. I do, however, > want to retain the property that one side can ask the other one to rekey > [0]. I believe we can get this by modifying the rule in the spec by treating > a run of KeyUpdates as a single generation. > > Specifically. > "Upon receiving a KeyUpdate, the receiver MUST update its receiving > keys. If the receiver has sent any data records since receiving the > last KeyUpdate it MUST also increment its min_send_generation counter > by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior > to sending a record, if min_send_generation is greater than the > current sending generation, the sender MUST first send a KeyUpdate." Timing- and propagation-wise, it looks workable (also, could be done with two flags[1], no need for counter). Yes, this causes lots more desync between sides, but existing mechanism needed to cope with that already. However, one problem: Because both sides take their keys from one ladder, if one side is behind the other, one can extract past keys of other side from the one that is behind (running separate ladders in both directions[2][3] would fix this). [1] Specifically: - last_tx_key_update: Was the last record I sent a KeyUpdate? - next_tx_key_update: Will the next record I send be a KeyUpdate? [2] Any current implementation likely already has per-direction traffic secrets (at least mine certainly does). [3] Allowing multiple steps at once would open things up for DoS attacks. -Ilari From nobody Sun Aug 28 11:51:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6572912B054 for ; Sun, 28 Aug 2016 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT1zItl82LKx for ; Sun, 28 Aug 2016 11:51:09 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABEE12B032 for ; Sun, 28 Aug 2016 11:51:09 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u134so75323410ywg.3 for ; Sun, 28 Aug 2016 11:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+2yGIKrjNSJl5N2qLncCYqwHDejTvcBtds/BTezLkOE=; b=I6yu24lyaGkrRSnJQK4SRuXT/vFxppXgpXBN/ZTsP9LzlMTz9RqrjYtRNIAUsVtOUJ +2hJGlMfRDIvJ5rPGbrrF7xKSengVegE+UXAzWRGc/3MtK9vuO1Bnpq6SOf6nQVq4Jh/ KdVmYEHB17zsfZgksE7arRkGrIy663KW301Rv0v1t9r+rfzGaMjvVQ3a0oCvsY9w5Qq9 q6lew1KwqyDm3LRrFRTfKjMf+uUbk/N0EM/wzvDuRl0GBfrAtlxyQc2q24HFs3AKzS/I 0XUyVSrhuHMNRTurNaRqXeR95ZGzWRJGSLyDpfIeXtU6xMxN+inDZ3+zeYVZpc+WBUWg snNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+2yGIKrjNSJl5N2qLncCYqwHDejTvcBtds/BTezLkOE=; b=kCHyNBIFMyuvlR3gYu7b6lElQocQMqcFDZqqQY0Kaq7GMnRBZPoGaO6eJazCKB0LOO m4omrCZk9ZTBmedZiELBmZTMcfK8bfI1S+GxKLFpO89FmM3aOkDfKyRIHX+YpBj7mRWV Wns6HxucngH2t8oioiPrd6hWzW4Hw8NbrfmqKZKZpjheWspug4rUd5voVgCOEOlfy7G+ dI6XptYojrzOj70hRYPDHTQNtRs0Foe4mvDAYuc2g8AG99m145A03sVPpZPyhZ+TpxW1 0UfrC8+rtYAVkfI3xA3VUp12rFFOma/GowfZ4rA+GTgwPKZkm1JrZqxT7crjMaytFbSk /AbA== X-Gm-Message-State: AE9vXwOA/SYS0bun/4iL9vckHhvmHN3th9McBuHoVduqA0XR3VBLL6tTz506QcY6X407MlspvyQLJlVmTq3cJw== X-Received: by 10.13.220.1 with SMTP id f1mr12231352ywe.289.1472410268399; Sun, 28 Aug 2016 11:51:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Sun, 28 Aug 2016 11:50:27 -0700 (PDT) In-Reply-To: <20160828184105.yvrnbispbnpomk4s@LK-Perkele-V2.elisa-laajakaista.fi> References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> <20160828184105.yvrnbispbnpomk4s@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 28 Aug 2016 11:50:27 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0809f0032c78053b263bb2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2016 18:51:10 -0000 --94eb2c0809f0032c78053b263bb2 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara wrote: > On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: > > > > I'd prefer to keep things as simple as possible here and from that > > perspective, I think any indicator from side A to side B that it wants a > > key change over and above the KeyUpdate is extra complexity. I do, > however, > > want to retain the property that one side can ask the other one to rekey > > [0]. I believe we can get this by modifying the rule in the spec by > treating > > a run of KeyUpdates as a single generation. > > > > Specifically. > > "Upon receiving a KeyUpdate, the receiver MUST update its receiving > > keys. If the receiver has sent any data records since receiving the > > last KeyUpdate it MUST also increment its min_send_generation counter > > by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior > > to sending a record, if min_send_generation is greater than the > > current sending generation, the sender MUST first send a KeyUpdate." > > Timing- and propagation-wise, it looks workable (also, could be done > with two flags[1], no need for counter). > > Yes, this causes lots more desync between sides, but existing > mechanism needed to cope with that already. > > > However, one problem: Because both sides take their keys from one > ladder, if one side is behind the other, one can extract past keys > of other side from the one that is behind (running separate ladders > in both directions[2][3] would fix this). > Yes, I agree separate ladders would fix this. I don't necessarily object to this change, but I'm not sure it's that big a deal either, because you really only get into this case when there's a big asymmetry in sending rate, so much that one side wants to send multiple updates before the other side has sent any data at all. Note: it's also possible to avoid the rollback problem with the existing single-ladder system: when you send a key update you compute: traffic_secret_N+1 read_key_N+1 write_key_N+1 You then discard traffic_secret N, write_key_N, but key read_key_N, so if you are M updates ahead of the other side, you have M read keys outstanding, but these cannot be used to produce the write keys. However, this probably isn't simpler than just running two ladders if we think this is important. -Ekr --94eb2c0809f0032c78053b263bb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: >
> I'd prefer to keep things as simple as possible here and from that=
> perspective, I think any indicator from side A to side B that it wants= a
> key change over and above the KeyUpdate is extra complexity. I do, how= ever,
> want to retain the property that one side can ask the other one to rek= ey
> [0]. I believe we can get this by modifying the rule in the spec by tr= eating
> a run of KeyUpdates as a single generation.
>
> Specifically.
> "Upon receiving a KeyUpdate, the receiver MUST update its receivi= ng
> keys. If the receiver has sent any data records since receiving the > last KeyUpdate it MUST also increment its min_send_generation counter<= br> > by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior<= br> > to sending a record, if min_send_generation is greater than the
> current sending generation, the sender MUST first send a KeyUpdate.&qu= ot;

Timing- and propagation-wise, it looks workable (also, could be done=
with two flags[1], no need for counter).

Yes, this causes lots more desync between sides, but existing
mechanism needed to cope with that already.


However, one problem: Because both sides take their keys from one
ladder, if one side is behind the other, one can extract past keys
of other side from the one that is behind (running separate ladders
in both directions[2][3] would fix this).

Yes, I agree separate ladders would fix this. I don't necessarily ob= ject to this
change, but I'm not sure it's that big a dea= l either, because you really only get
into this case when there&#= 39;s a big asymmetry in sending rate, so much that
one side wants= to send multiple updates before the other side has sent
any data= at all.

Note: it's also possible to avoid the= rollback problem with the existing
single-ladder system: when yo= u send a key update you compute:

traffic_secret_N+= 1
read_key_N+1
write_key_N+1

Y= ou then discard traffic_secret N, write_key_N, but key read_key_N, so if yo= u
are M updates ahead of the other side, you have M read keys out= standing,
but these cannot be used to produce the write keys. How= ever, this probably
isn't simpler than just running two ladde= rs if we think this is important.

-Ekr
<= br>
--94eb2c0809f0032c78053b263bb2-- From nobody Mon Aug 29 05:00:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747BB12D0B7 for ; Mon, 29 Aug 2016 05:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.47 X-Spam-Level: X-Spam-Status: No, score=-7.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdJ_b_apgvyd for ; Mon, 29 Aug 2016 05:00:45 -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 D2C5612D729 for ; Mon, 29 Aug 2016 05:00:43 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 30485A0771; Mon, 29 Aug 2016 12:00:42 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7TC0eVS014926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Aug 2016 08:00:41 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 29 Aug 2016 14:00:39 +0200 Message-ID: <2123223.JzJ8ujFHJJ@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D053AB@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D053AB@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2215477.aiTK73ayqa"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 29 Aug 2016 12:00:43 +0000 (UTC) Archived-At: Cc: "cfrg@irtf.org" , "David McGrew \(mcgrew\)" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 12:00:46 -0000 --nextPart2215477.aiTK73ayqa Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Sunday, 28 August 2016 13:55:47 CEST Peter Gutmann wrote: > Stephen Farrell writes: > >IIRC the IoT marketing term doesn't have a very long history so I don't > >really know what substance lies behind that remark. >=20 > I just used "IoT" because someone else had used it, since it's about as > well- defined as "Web 2.0" I agree that it's not terribly useful to define > a feature set. What I meant was low-power embedded, smart meters and the > like, IoT in the sense of "little internet-enabled things". while others define it as "anything that is not a general purpose computer,= =20 tablet or phone", in effect including also SCADA, TVs, ATMs, traffic lights= ,=20 etc. and for those you need proper encryption =20 > >>(I've always wanted to sit down and design a generic "encrypted pipe fr= om > >>A > >>to B using minimal resources" spec, and I'm sure many other people have > >>had > >>the same thought at one time or another). > > > >Then why don't you do that? >=20 > It's a bit like designing a new { OS | programming language | network > protocol > | ... }, everybody who works in the relevant field would like to have a go > | at >=20 > something like this, and probably have a lot of fun fiddling with it, but > I'm not sure how much appeal it would have to anyone apart from the person > playing with it. So the answer is "for the same reason I haven't had a go > at designing a new OS, programming language, network protocol, etc". we have enough problems weeding out implementation mistakes in TLS, we don'= t=20 need yet another protocol and two dozen implementations that come with it =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2215477.aiTK73ayqa 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 iQIcBAABCgAGBQJXxCPnAAoJEJKo0bgB0vX1QoMP/1NWwtorP36t79Da1RVFRkhP 2cDecOIkW8qX2oJGODCwVmKZhp4/lzjhLw0K0DH/I1d5VZOaIoLu1veD/WRcNUkm hbvRgcXmDyJxweQT/vQLGt/Ybwx/WkqK3+htS+Yi44NNwGg0BCgpz9zQZHKOC/tK qdSR+77jkZtyTMA59PwIZ/yn/NIsXf8D/8cuKM0RMzcCWOWvsAhiTSg8kUTgFABi vTsRDZ90f1wS5SSwDZONoeq+Fb5YDnqIRGhGfXHhaQdM8t1Ky6wmMT4odrMuCODF tInz3jaje2GrF20sokVs+X4WzZVdMIHwJDfr52hd9VE5PJm4FaUvLGH+DyYppoEW KxYhOcIxB8P2dN99YU/BL7YEzcH67m6CnhoDgc9MLfOFC/p2e9fcmsUEJYPy8NMW 3uTO7/4KI2vbw0oXckewfXXUrdiSXpNcBgCa6mep1so5c0iCTZ5RTioENAbGCnIR 7xynXurWDNAKI69KjQ4SUWDNTBOw77pRpljcZGjQwo4o3MHbtmBZ95Iw32pe7iCr N5PBaMksnW3JQYBsaIAGdhIJRe1Dh9f3ruizwZRW7OESl6wH9lg+OQzfgJdk9jiM QPaTH4gzAqN1RN2gQeVM6Kvi69LIhpVpP7Lp0jR8sWgZx77TuVkEFfbfES8EXiCJ /B0l9NLr65BbslxVQuAh =q2eQ -----END PGP SIGNATURE----- --nextPart2215477.aiTK73ayqa-- From nobody Mon Aug 29 05:44:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05CC12D539 for ; Mon, 29 Aug 2016 05:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RE0DNZWos3H for ; Mon, 29 Aug 2016 05:44:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805E012D555 for ; Mon, 29 Aug 2016 05:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3720; q=dns/txt; s=iport; t=1472474684; x=1473684284; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wc/z0nTzceVj3ErQgg98EPtfwKLv8eeI5T15A+1bUz0=; b=c4+9Evy5tdDH9G4bMGswsBiBOdiJ/h19WlLWKUmy/t0VfC7FS1y3l9WI l2YOx1GH19zBuodPAAuTWDaunrBi+wFpcH5+H0lOqdCelu+XdVVJMcGXI y0BrglcOy/+uGcs7Fmz2ORO77Rej/k6PdMcuHzBOHFHOhDKsXH3w8AV0P Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQA6LcRX/5pdJa1cDgwBAQEBAgEBA?= =?us-ascii?q?QGDKQEBAQEBHld8B40nqneCASaFdwIcgSc4FAECAQEBAQEBAV4nhGIBAQICIxF?= =?us-ascii?q?VAgEIDgwCJgICAjAVEAIEARKIQA6uCo8vAQEBAQEBAQEBAQEBAQEBAQEBAQEdg?= =?us-ascii?q?QOHI4JVghCCEwEBgx0rgi8FhhKTPQGGH4I9gz6DEII7jRqQPAEeNoI0HIERO3A?= =?us-ascii?q?BhCyBIH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,596,1464652800"; d="scan'208";a="140705387" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2016 12:44:43 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7TCihAB021445 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Aug 2016 12:44:43 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 29 Aug 2016 07:44: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.1210.000; Mon, 29 Aug 2016 07:44:42 -0500 From: "David McGrew (mcgrew)" To: Peter Gutmann , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/nWfoW+SS6smqUOyCtdxrLUgKaBbmdgAgAF4CoD//8XhAIABxwsAgAFbRAA= Date: Mon, 29 Aug 2016 12:44:42 +0000 Message-ID: <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.10.228] Content-Type: text/plain; charset="utf-8" Content-ID: <522EA66CF2E28E43A944C93BD1A91FF5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 12:44:48 -0000 SGkgUGV0ZXIsDQoNCllvdSBtYWtlIGEgYnVuY2ggb2YgZ29vZCBwb2ludHMuICAgQnV0IGl0IGlz IGFsc28gd29ydGggbm90aW5nIHRoYXQgc29tZSBwZW9wbGUgZmVlbCB0aGF0IGN1cnJlbnQgY3J5 cHRvIHN0YW5kYXJkcywgaW5jbHVkaW5nIElFVEYgc3RhbmRhcmRzLCBhcmUgc3VpdGFibGUgZm9y IElvVC4gICBTZWUgZm9yIGluc3RhbmNlIHNsaWRlcyA4IGFuZCA5IG9mIERhbmllbCBTaHVtb3cn cyB0YWxrIGF0IE5JU1TigJlzIExXQyB3b3Jrc2hvcCBsYXN0IHllYXI6IGh0dHA6Ly9jc3JjLm5p c3QuZ292L2dyb3Vwcy9TVC9sd2Mtd29ya3Nob3AyMDE1L3ByZXNlbnRhdGlvbnMvc2Vzc2lvbjQt c2h1bW93LnBkZiAgIEFsc28sIENvQVAgaXNu4oCZdCBvbiBoaXMgbGlzdCwgYnV0IGl0IGNvdWxk IGJlLCBhbmQgaXQgdXNlcyBEVExTLiAgIFNvIHdoaWxlIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBv dmVydXNlIG9mIGEgNjQtYml0IGJsb2NrIGNpcGhlciBpcyBmYXIgZnJvbSB0aGUgYmlnZ2VzdCBz ZWN1cml0eSBjb25jZXJuIGZvciBJb1QsIHRoZSBJRVRGIHNob3VsZCBleHBlY3QgaXRzIHByb3Rv Y29scyB0byBiZSB1c2VkIGluIHNvbWUgSW9UIHNjZW5hcmlvcy4gIA0KDQpUaGUgbWFsbGVhYmls aXR5IG9mIHRoZSB0ZXJtIElvVCBpcyBjYXVzaW5nIHRyb3VibGUgaGVyZS4gICBTbGlkZSA2IG9m IERhbmllbOKAmXMgdGFsayBpcyBxdWl0ZSByZXZlYWxpbmcuICBUbyBteSB0aGlua2luZywgYnkg ZGVmaW5pdGlvbiBJb1QgZGV2aWNlcyBhcmUgY29ubmVjdGVkIHRvIHRoZSBJbnRlcm5ldCBpbiBz b21lIHdheS4NCg0KRGF2aWQNCg0KDQoNCk9uIDgvMjgvMTYsIDg6MDEgQU0sICJQZXRlciBHdXRt YW5uIiA8cGd1dDAwMUBjcy5hdWNrbGFuZC5hYy5uej4gd3JvdGU6DQoNCj5EYXZpZCBNY0dyZXcg KG1jZ3JldykgPG1jZ3Jld0BjaXNjby5jb20+IHdyaXRlczoNCj4NCj4+SSBkb27igJl0IHRoaW5r IHlvdSB1bmRlcnN0b29kIG15IHBvaW50LiBJb1QgaXMgYWJvdXQgc21hbGwgZGV2aWNlcyBjb25u ZWN0aW5nDQo+PnRvIHRoZSBJbnRlcm5ldCwgYW5kIElFVEYgc3RhbmRhcmRzIHNob3VsZCBleHBl Y3QgZGVzaWduZWQtZm9yLUlvVCBjcnlwdG8gdG8NCj4+YmUgaW5jcmVhc2luZ2x5IGluIHNjb3Bl LiAgSXQgaXMgaW1wb3J0YW50IHRvIG5vdCBmb3JnZXQgYWJvdXQgdGhlc2UgZGV2aWNlcywNCj4+ YW1pZHN0IHRoZSBjdXJyZW50IGF0dGVudGlvbiBiZWluZyBwYWlkIHRvIG1pc3VzZXMgb2YgNjQt Yml0IGJsb2NrIGNpcGhlcnMsDQo+PndoaWNoIHdhcyB0aGUgdWx0aW1hdGUgY2F1c2Ugb2YgdGhp cyBtYWlsIHRocmVhZC4NCj4NCj5CdXQgdGhlIElFVEYgaGFzIGEgbG9uZyBoaXN0b3J5IG9mIGNy ZWF0aW5nIHN0YW5kYXJkcyB0aGF0IGNvbXBsZXRlbHkgaWdub3JlDQo+SW9ULiAgSSBjYW4ndCB0 aGluayBvZiBhIHNpbmdsZSBnZW5lcmFsLXB1cnBvc2UgSUVURiBzZWN1cml0eSBzdGFuZGFyZCAo VExTLA0KPlNTSCwgSVBzZWMsIGV0YykgdGhhdCBoYXMgYW55IGhvcGUgb2Ygd29ya2luZyB3aXRo IElvVCBkZXZpY2VzIChzYXkgYSA0ME1oeg0KPkFSTS1jb3JlIEFTSUMgd2l0aCAzMmtCIFJBTSBh bmQgNjRrQiBmbGFzaCkuICBUaGlzIGlzIHdoeSB0aGUgSVRVL0lFQyBhbmQgYQ0KPm1pbGxpb24g bGVzc2VyLWtub3duIHN0YW5kYXJkcyBib2RpZXMgYXJlIGFsbCBidXN5IGludmVudGluZyB0aGVp ciBvd24NCj5leHF1aXNpdGVseSBob21lYnJldyBjcnlwdG8gcHJvdG9jb2xzLCBtb3N0IG9mIHdo aWNoIG1ha2UgV0VQIGxvb2sgbGlrZSBhDQo+bW9kZWwgb2YgZ29vZCBkZXNpZ24uDQo+DQo+KEkn dmUgYWx3YXlzIHdhbnRlZCB0byBzaXQgZG93biBhbmQgZGVzaWduIGEgZ2VuZXJpYyAiZW5jcnlw dGVkIHBpcGUgZnJvbSBBIHRvDQo+QiB1c2luZyBtaW5pbWFsIHJlc291cmNlcyIgc3BlYywgYW5k IEknbSBzdXJlIG1hbnkgb3RoZXIgcGVvcGxlIGhhdmUgaGFkIHRoZQ0KPnNhbWUgdGhvdWdodCBh dCBvbmUgdGltZSBvciBhbm90aGVyKS4NCj4NCj5TbyBpdCBzZWVtcyBsaWtlIHlvdSd2ZSBnb3Q6 DQo+DQo+LSBUaGUgIlRMUyA9IHRoZSB3ZWIiIGNyb3dkIChicm93c2VyIHZlbmRvcnMgYW5kIHRo ZSBsaWtlKSB3aG8gd2lsbCBpbXBsZW1lbnQNCj4gIHdoYXRldmVyJ3MgdHJlbmR5IGF0IHRoZSBt b21lbnQgYW5kIGFzc3VtZSBldmVyeW9uZSBoYXMgYSBxdWFkLWNvcmUgMkdIeiBDUFUNCj4gIHdp dGggZ2lnYWJ5dGVzIG9mIFJBTSBhbmQgYWNjZXNzIHRvIHdlZWtseSBsaXZlIHVwZGF0ZXMgYW5k IGhvdGZpeGVzLg0KPg0KPi0gRW1iZWRkZWQvU0NBREEgZm9sa3Mgd2hvIG5lZWQgdG8gZGVhbCB3 aXRoIDEwLTE1IHllYXIgcHJvZHVjdCBjeWNsZXMgKHNlZSBteQ0KPiAgVExTLUxUUyBkcmFmdCBm b3IgbW9yZSBvbiB0aGlzKSBhbmQgYXJlIGtpbmQgb2Ygc3R1Y2suDQo+DQo+LSBJb1QgcGVvcGxl LCB3aG8gY2FuJ3QgdXNlIGFueSBzdGFuZGFyZCBwcm90b2NvbCBhbmQgd2lsbCBnZXQgdGhlIGxl YXN0DQo+ICB1bnF1YWxpZmllZCBwZXJzb24gb24gc3RhZmYgdG8gaW52ZW50IHNvbWV0aGluZyB0 aGF0IHNlZW1zIE9LIHRvIHRoZW0uDQo+DQo+SSdtIG5vdCBzdXJlIHRoYXQgYSBkcmFmdCBvbiB0 aGVvcmV0aWNhbCB3ZWFrbmVzc2VzIGluIDY0LWJpdCBibG9jayBjaXBoZXJzIGlzDQo+Z29pbmcg dG8gYWZmZWN0IGFueSBvZiB0aG9zZS4uLg0KPg0KPlBldGVyLg0K From nobody Mon Aug 29 05:56:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4012D58A for ; Mon, 29 Aug 2016 05:56:42 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkCyyudweIO0 for ; Mon, 29 Aug 2016 05:56:40 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A97F12D0FE for ; Mon, 29 Aug 2016 05:56:40 -0700 (PDT) Received: from Knubbis.local (unknown [80.252.219.34]) by mail.frobbit.se (Postfix) with ESMTPSA id DA4E421EEE; Mon, 29 Aug 2016 14:56:37 +0200 (CEST) Message-ID: <57C43102.7090902@secworks.se> Date: Mon, 29 Aug 2016 14:56:34 +0200 From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "David McGrew (mcgrew)" References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> In-Reply-To: <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 12:56:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! As a side note, there has been a bunch of lightweight block ciphers suggested the last few years, most of them with a block size of 64 bits. And there has been discussion on IETF maillists about IETF accepting them. For example the SIMON and SPECK ciphers. These ciphers can have block sizes as small as 32 bits. https://www.cryptolux.org/images/a/a0/Beaulieu-DAC2015.pdf https://eprint.iacr.org/2015/209.pdf Yours JoachimS David McGrew (mcgrew) wrote: > Hi Peter, > > You make a bunch of good points. But it is also worth noting that > some people feel that current crypto standards, including IETF > standards, are suitable for IoT. See for instance slides 8 and 9 of > Daniel Shumow's talk at NIST’s LWC workshop last year: > http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf > Also, CoAP isn’t on his list, but it could be, and it uses DTLS. So > while I agree with you that overuse of a 64-bit block cipher is far > from the biggest security concern for IoT, the IETF should expect its > protocols to be used in some IoT scenarios. > > The malleability of the term IoT is causing trouble here. Slide 6 > of Daniel’s talk is quite revealing. To my thinking, by definition > IoT devices are connected to the Internet in some way. > > David > > > > On 8/28/16, 8:01 AM, "Peter Gutmann" > wrote: > >> David McGrew (mcgrew) writes: >> >>> I don’t think you understood my point. IoT is about small devices >>> connecting to the Internet, and IETF standards should expect >>> designed-for-IoT crypto to be increasingly in scope. It is >>> important to not forget about these devices, amidst the current >>> attention being paid to misuses of 64-bit block ciphers, which >>> was the ultimate cause of this mail thread. >> But the IETF has a long history of creating standards that >> completely ignore IoT. I can't think of a single general-purpose >> IETF security standard (TLS, SSH, IPsec, etc) that has any hope of >> working with IoT devices (say a 40Mhz ARM-core ASIC with 32kB RAM >> and 64kB flash). This is why the ITU/IEC and a million >> lesser-known standards bodies are all busy inventing their own >> exquisitely homebrew crypto protocols, most of which make WEP look >> like a model of good design. >> >> (I've always wanted to sit down and design a generic "encrypted >> pipe from A to B using minimal resources" spec, and I'm sure many >> other people have had the same thought at one time or another). >> >> So it seems like you've got: >> >> - The "TLS = the web" crowd (browser vendors and the like) who will >> implement whatever's trendy at the moment and assume everyone has a >> quad-core 2GHz CPU with gigabytes of RAM and access to weekly live >> updates and hotfixes. >> >> - Embedded/SCADA folks who need to deal with 10-15 year product >> cycles (see my TLS-LTS draft for more on this) and are kind of >> stuck. >> >> - IoT people, who can't use any standard protocol and will get the >> least unqualified person on staff to invent something that seems OK >> to them. >> >> I'm not sure that a draft on theoretical weaknesses in 64-bit block >> ciphers is going to affect any of those... >> >> Peter. > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJXxDECAAoJEF3cfFQkIuyNY1UP/2lUJo53s27wlqvgPWpZYWzi HViof7jYA7yvbZm9SeYkV88y4sOMUQrhSsAWUZ7GfwcjkjC8+sL8mD7uacPx0zpW rAnLnAHJbnU8rkWRT2OKWiZBvwMpMNw/UYGy13dwilRExj22N4dsLK98vath3r52 FjAIL2GpCWUuzPB6P5d+B8MjEwEr1tEYzvlvWo032RB91irOOKveryGGe5ifnSKj SP1a9CbakaLdTHMkrhOre0I4Ckr2A97eI3oo/5QjRJ81zKJ/4VZzOOe3lGjPkXhO kzkANctte+Eb5ttlaXcg/dL7lStzaYo8rnm3PRHsBKpHr/oNEgbdJti1U78/MfLf o0v+s4TbY7YBPXOU7zKWpo9VD1Mcq9eMAslIQokEE2CfIq3wBSEEgKwJXu6HVSht Ohahc7HUBnz2+uXJ+x4hl/bW/qM3DFhTfhPCYQ11IiXpPlxhsAnxbszBe4XtHd7y z2Uc+Jef8aUq7sEGYBdcnGs+SSNFQwtUIicKI3pU61xvtAhqRriNOsfmCVvC2V7Z iz5EodInPjUBkVMwDbmiFd5lp782SqYZsivwabPGE1p2GG+o421KZmQJ3VRC3ctw xjwk2HszIv7Wo+gomL0hqF7Wi0YIP556rRYrRMc9gLV513xzxD5T99eR+2HtiRJF TvYYPXZjzP087liGF7SA =Z0iM -----END PGP SIGNATURE----- From nobody Mon Aug 29 06:21:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EE812B028 for ; Mon, 29 Aug 2016 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlowTCPe9GwZ for ; Mon, 29 Aug 2016 06:20:55 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA5212D112 for ; Mon, 29 Aug 2016 06:20:55 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-af-57c436b52fd8 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id DA.95.02553.5B634C75; Mon, 29 Aug 2016 15:20:53 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.215]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0301.000; Mon, 29 Aug 2016 15:20:49 +0200 From: John Mattsson To: "David McGrew (mcgrew)" , Peter Gutmann , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/8MHpyiCNxbgBkyiSa8rLoEeV6Bcme6AgAAI8ACAAYP9AIABnlEAgAArnoA= Date: Mon, 29 Aug 2016 13:20:49 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> In-Reply-To: <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: <655B9B4838F88A44865C5CCFF947DF4E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7me5WsyPhBvd2aFlcetzCZNH94yCT xdVVf9gtXr57zmrx6XwXowOrx5TfG1k9LjYeYPLYOesuu8eSJT+ZPCZvPMwWwBrFZZOSmpNZ llqkb5fAlfH9cSNTwR7tiodbUhoY12h1MXJySAiYSLzd+Yepi5GLQ0hgPaPEsRkzmUASQgJL GCXu7OAEsdkEDCTm7mlgAykSETjIKPFs+VI2kISwgJLE4eZm5i5GDqCEssS01/EgYREBP4lp 6zvYQWwWAVWJyV0rmUFsXgFzie2Pp7BALPvNJPG6aRIjSIJTwFbi/8eFLCA2o4CYxPdTa8CO YBYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+xwpiiwroSTw7uZgRIq4osfNsO9g9zAKaEut36UOM sZa4fHIxG4StKDGl+yE7xD2CEidnPmGZwCg2C8m2WQjds5B0z0LSPQtJ9wJG1lWMosWpxUm5 6UZGeqlFmcnFxfl5enmpJZsYgfF4cMtvgx2ML587HmIU4GBU4uFNeHcoXIg1say4MvcQowQH s5II7xvTI+FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUa GI2L2rcvu9SxRvPciT0zUwIeZ7W2JuzP4NL4Wb+Rff7+TcmL7p76uPLFIUaRdVd239X/XHDq SOf0kD8y/39xnp6w/MNuIZFe2z4GO9ad2k5tkvtDFlpLCv/1lM6J9TC21Lx4Y6bXstl/D0ks f5HSzeEj+pE3c66U5s3jdlPyvv97uervrSSf3v9KLMUZiYZazEXFiQBEUGtcwwIAAA== Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 13:21:00 -0000 SGkgRGF2aWQgYW5kIFBldGVyLA0KDQpJIHRoaW5rIERhbmllbHMgcHJlc2VudGF0aW9uIGlzIGEg Z29vZCBzdW1tYXJ5IGFuZCBJIHRlbmQgdG8gYWdyZWUgd2l0aA0KdGhlIOKAnE5vIGxpZ2h0d2Vp Z2h0IGNyeXB0b2dyYXBoeSBpbiBzb2Z0d2FyZeKAnS4gQnV0IGhvdyByZWxldmFudCBpcw0KbGln aHR3ZWlnaHQgY3J5cHRvZ3JhcGh5IGluIElvVCBoYXJkd2FyZT8gSSBiZWVuIGhlYXJpbmcgc29t ZSBoYXJkd2FyZQ0KcGVvcGxlIHN0YXRpbmcgdGhhdCB0aGUgbnVtYmVyIG9mIGdhdGVzIGlzIG1v cmUgYW5kIG1vcmUgaXJyZWxldmFudCBhbmQNCnRoYXQgdGhlIGFkZGl0aW9uYWwgY29zdCBvZiAx MDAwIEdFIGlzIG5lZ2xpZ2libGUgd2l0aCBjdXJyZW50DQptYW51ZmFjdHVyaW5nIHRlY2huaXF1 ZXMgKGkuZS4gMTAwMCBHRSBpcyBzbWFsbCBjb21wYXJlZCB0byB0aGUgYXJlIG5lZWRlZA0KdG8g Y3V0IG91dCB0aGUgY2lyY3VpdCBhbmQgY29ubmVjdGluZyBpdCkuIFdlIGFscmVhZHkga25vdyB0 aGF0IHRoZSBlbmVyZ3kNCmNvc3Qgb2Ygc3ltbWV0cmljICBjcnlwdG8gaXMgbmVnbGlnaWJsZSBj b21wYXJlZCB0byB3aXJlbGVzcyBjb21tdW5pY2F0aW9uDQoodGhpcyBtaWdodCBob3dldmVyIGNo YW5nZSB3aXRoIHBhc3NpdmUgcmFkaW8pLg0KDQpXb3VsZCBiZSBpbnRlcmVzdGluZyB0byBoZWFy IG1vcmUgaW5wdXQgb24gdGhlIHJlbGV2YW5jZSBvZiBBRVMtIGFuZA0KU0hBLXJlcGxhY2VtZW50 cyBpbiBJb1QgaGFyZHdhcmUuIERlcGVuZGluZyBvbiB0aGUgb3V0Y29tZSB0aGUgQ0ZSRyB3YXkN CmZvcndhcmQgc2hvdWxkIGJlIGVpdGhlcjoNCg0KIC0gUmVjb21tZW5kYXRpb24gaG93IHRvIHVz ZSBibG9jayBjaXBoZXJzIHdpdGggNjQgYml0IGJsb2NrIHNpemUNCiAtIFJlY29tbWVuZGF0aW9u IG5vdCB0byB1c2UgYmxvY2sgY2lwaGVycyB3aXRoIDY0IGJpdCBibG9jayBzaXplDQoNCkpvaG4N Cg0KDQpPbiAyOS8wOC8xNiAxNDo0NCwgIkNmcmcgb24gYmVoYWxmIG9mIERhdmlkIE1jR3JldyAo bWNncmV3KSINCjxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgb24gYmVoYWxmIG9mIG1jZ3Jld0BjaXNj by5jb20+IHdyb3RlOg0KDQo+SGkgUGV0ZXIsDQo+DQo+WW91IG1ha2UgYSBidW5jaCBvZiBnb29k IHBvaW50cy4gICBCdXQgaXQgaXMgYWxzbyB3b3J0aCBub3RpbmcgdGhhdCBzb21lDQo+cGVvcGxl IGZlZWwgdGhhdCBjdXJyZW50IGNyeXB0byBzdGFuZGFyZHMsIGluY2x1ZGluZyBJRVRGIHN0YW5k YXJkcywgYXJlDQo+c3VpdGFibGUgZm9yIElvVC4gICBTZWUgZm9yIGluc3RhbmNlIHNsaWRlcyA4 IGFuZCA5IG9mIERhbmllbCBTaHVtb3cncw0KPnRhbGsgYXQgTklTVOKAmXMgTFdDIHdvcmtzaG9w IGxhc3QgeWVhcjoNCj5odHRwOi8vY3NyYy5uaXN0Lmdvdi9ncm91cHMvU1QvbHdjLXdvcmtzaG9w MjAxNS9wcmVzZW50YXRpb25zL3Nlc3Npb240LXNodQ0KPm1vdy5wZGYgICBBbHNvLCBDb0FQIGlz buKAmXQgb24gaGlzIGxpc3QsIGJ1dCBpdCBjb3VsZCBiZSwgYW5kIGl0IHVzZXMNCj5EVExTLiAg IFNvIHdoaWxlIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBvdmVydXNlIG9mIGEgNjQtYml0IGJsb2Nr IGNpcGhlcg0KPmlzIGZhciBmcm9tIHRoZSBiaWdnZXN0IHNlY3VyaXR5IGNvbmNlcm4gZm9yIElv VCwgdGhlIElFVEYgc2hvdWxkIGV4cGVjdA0KPml0cyBwcm90b2NvbHMgdG8gYmUgdXNlZCBpbiBz b21lIElvVCBzY2VuYXJpb3MuDQo+DQo+VGhlIG1hbGxlYWJpbGl0eSBvZiB0aGUgdGVybSBJb1Qg aXMgY2F1c2luZyB0cm91YmxlIGhlcmUuICAgU2xpZGUgNiBvZg0KPkRhbmllbOKAmXMgdGFsayBp cyBxdWl0ZSByZXZlYWxpbmcuICBUbyBteSB0aGlua2luZywgYnkgZGVmaW5pdGlvbiBJb1QNCj5k ZXZpY2VzIGFyZSBjb25uZWN0ZWQgdG8gdGhlIEludGVybmV0IGluIHNvbWUgd2F5Lg0KPg0KPkRh dmlkDQo+DQo+DQo+DQo+T24gOC8yOC8xNiwgODowMSBBTSwgIlBldGVyIEd1dG1hbm4iIDxwZ3V0 MDAxQGNzLmF1Y2tsYW5kLmFjLm56PiB3cm90ZToNCj4NCj4+RGF2aWQgTWNHcmV3IChtY2dyZXcp IDxtY2dyZXdAY2lzY28uY29tPiB3cml0ZXM6DQo+Pg0KPj4+SSBkb27igJl0IHRoaW5rIHlvdSB1 bmRlcnN0b29kIG15IHBvaW50LiBJb1QgaXMgYWJvdXQgc21hbGwgZGV2aWNlcw0KPj4+Y29ubmVj dGluZw0KPj4+dG8gdGhlIEludGVybmV0LCBhbmQgSUVURiBzdGFuZGFyZHMgc2hvdWxkIGV4cGVj dCBkZXNpZ25lZC1mb3ItSW9UDQo+Pj5jcnlwdG8gdG8NCj4+PmJlIGluY3JlYXNpbmdseSBpbiBz Y29wZS4gIEl0IGlzIGltcG9ydGFudCB0byBub3QgZm9yZ2V0IGFib3V0IHRoZXNlDQo+Pj5kZXZp Y2VzLA0KPj4+YW1pZHN0IHRoZSBjdXJyZW50IGF0dGVudGlvbiBiZWluZyBwYWlkIHRvIG1pc3Vz ZXMgb2YgNjQtYml0IGJsb2NrDQo+Pj5jaXBoZXJzLA0KPj4+d2hpY2ggd2FzIHRoZSB1bHRpbWF0 ZSBjYXVzZSBvZiB0aGlzIG1haWwgdGhyZWFkLg0KPj4NCj4+QnV0IHRoZSBJRVRGIGhhcyBhIGxv bmcgaGlzdG9yeSBvZiBjcmVhdGluZyBzdGFuZGFyZHMgdGhhdCBjb21wbGV0ZWx5DQo+Pmlnbm9y ZQ0KPj5Jb1QuICBJIGNhbid0IHRoaW5rIG9mIGEgc2luZ2xlIGdlbmVyYWwtcHVycG9zZSBJRVRG IHNlY3VyaXR5IHN0YW5kYXJkDQo+PihUTFMsDQo+PlNTSCwgSVBzZWMsIGV0YykgdGhhdCBoYXMg YW55IGhvcGUgb2Ygd29ya2luZyB3aXRoIElvVCBkZXZpY2VzIChzYXkgYQ0KPj40ME1oeg0KPj5B Uk0tY29yZSBBU0lDIHdpdGggMzJrQiBSQU0gYW5kIDY0a0IgZmxhc2gpLiAgVGhpcyBpcyB3aHkg dGhlIElUVS9JRUMNCj4+YW5kIGENCj4+bWlsbGlvbiBsZXNzZXIta25vd24gc3RhbmRhcmRzIGJv ZGllcyBhcmUgYWxsIGJ1c3kgaW52ZW50aW5nIHRoZWlyIG93bg0KPj5leHF1aXNpdGVseSBob21l YnJldyBjcnlwdG8gcHJvdG9jb2xzLCBtb3N0IG9mIHdoaWNoIG1ha2UgV0VQIGxvb2sgbGlrZSBh DQo+Pm1vZGVsIG9mIGdvb2QgZGVzaWduLg0KPj4NCj4+KEkndmUgYWx3YXlzIHdhbnRlZCB0byBz aXQgZG93biBhbmQgZGVzaWduIGEgZ2VuZXJpYyAiZW5jcnlwdGVkIHBpcGUNCj4+ZnJvbSBBIHRv DQo+PkIgdXNpbmcgbWluaW1hbCByZXNvdXJjZXMiIHNwZWMsIGFuZCBJJ20gc3VyZSBtYW55IG90 aGVyIHBlb3BsZSBoYXZlIGhhZA0KPj50aGUNCj4+c2FtZSB0aG91Z2h0IGF0IG9uZSB0aW1lIG9y IGFub3RoZXIpLg0KPj4NCj4+U28gaXQgc2VlbXMgbGlrZSB5b3UndmUgZ290Og0KPj4NCj4+LSBU aGUgIlRMUyA9IHRoZSB3ZWIiIGNyb3dkIChicm93c2VyIHZlbmRvcnMgYW5kIHRoZSBsaWtlKSB3 aG8gd2lsbA0KPj5pbXBsZW1lbnQNCj4+ICB3aGF0ZXZlcidzIHRyZW5keSBhdCB0aGUgbW9tZW50 IGFuZCBhc3N1bWUgZXZlcnlvbmUgaGFzIGEgcXVhZC1jb3JlDQo+PjJHSHogQ1BVDQo+PiAgd2l0 aCBnaWdhYnl0ZXMgb2YgUkFNIGFuZCBhY2Nlc3MgdG8gd2Vla2x5IGxpdmUgdXBkYXRlcyBhbmQg aG90Zml4ZXMuDQo+Pg0KPj4tIEVtYmVkZGVkL1NDQURBIGZvbGtzIHdobyBuZWVkIHRvIGRlYWwg d2l0aCAxMC0xNSB5ZWFyIHByb2R1Y3QgY3ljbGVzDQo+PihzZWUgbXkNCj4+ICBUTFMtTFRTIGRy YWZ0IGZvciBtb3JlIG9uIHRoaXMpIGFuZCBhcmUga2luZCBvZiBzdHVjay4NCj4+DQo+Pi0gSW9U IHBlb3BsZSwgd2hvIGNhbid0IHVzZSBhbnkgc3RhbmRhcmQgcHJvdG9jb2wgYW5kIHdpbGwgZ2V0 IHRoZSBsZWFzdA0KPj4gIHVucXVhbGlmaWVkIHBlcnNvbiBvbiBzdGFmZiB0byBpbnZlbnQgc29t ZXRoaW5nIHRoYXQgc2VlbXMgT0sgdG8gdGhlbS4NCj4+DQo+PkknbSBub3Qgc3VyZSB0aGF0IGEg ZHJhZnQgb24gdGhlb3JldGljYWwgd2Vha25lc3NlcyBpbiA2NC1iaXQgYmxvY2sNCj4+Y2lwaGVy cyBpcw0KPj5nb2luZyB0byBhZmZlY3QgYW55IG9mIHRob3NlLi4uDQo+Pg0KPj5QZXRlci4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkNmcmcgbWFp bGluZyBsaXN0DQo+Q2ZyZ0BpcnRmLm9yZw0KPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4v bGlzdGluZm8vY2ZyZw0KDQo= From nobody Mon Aug 29 06:26:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46EF12D5EC for ; Mon, 29 Aug 2016 06:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J26bA2svNdI2 for ; Mon, 29 Aug 2016 06:26:38 -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 4B60712D619 for ; Mon, 29 Aug 2016 06:26:35 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id t7so137173262qkh.1 for ; Mon, 29 Aug 2016 06:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=oSbXFj9Wy3vRGhlwz0fa0s+4xLeLxGwN1RcbliviTY8=; b=HQHSaDNq2R9VyplPnqk15ZdkfZ+I5EEaKMJANmtNDHGK+9vYVDkp4L97mut9XX7L+n UTef5NirGI3ydadCFHvzx24Lw3GR1moti68M/jOC4Ce1HRmEa07FrRLYv4wtgp0AXGii OYRZENYxmfssHTIFsZjSGv3TYyZ4wo2QyX6hmOvbJ/5MptCc2c8X22v2Rl2nQ6cVOGUv iE0T/+YEVqwxiOdqw05XeaCDdyeT7SJSMFMTuwboYXiBFVgLNCNK2qectg+AlFN9EcLF tMnCBHUb+Dl3aUr5z89pINZ+5iv+xV+3aSrzYpGx133CvkCUQH5BJf4mdwdHlzwUO8UL usfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oSbXFj9Wy3vRGhlwz0fa0s+4xLeLxGwN1RcbliviTY8=; b=ltOgUtSkxATaYw14Cc2d12IgXCyKWIHahQ21qEDhpWJlMPlFBVXr7ruArstS89/cle 0nFQz/dj/mjylsHp7ly8vBrBxE+4K/MXvjegFeYP9ipN8FMPNz1w2LKj1xaQ9aHYDhDg ZMVlFUGRpptFO2VWnBh4loV2jCoGRc5xkRCUHnCjlrdjrAaBVM7TRlZPiI/deGWSG+YC JNRlAaQMrOik9ABkfaZz6bs9As2NV7rzmPAhdPqrZjoOvHsBY3PNayPFhWQ1dJmRxOYJ lVPjdlzA+eNlpaauNqboUEm4MF/CzTZR2lmL+lRF2iwxMzkeHV99j0RzFqWwcxlpwvAF YzMA== X-Gm-Message-State: AE9vXwMMyC+9ck2R4DL9K/OlstSO57eD/hHRgXXFbEU//KIKmqz2SltKp5aqmNAuvnARlg== X-Received: by 10.55.48.10 with SMTP id w10mr18790946qkw.43.1472477194219; Mon, 29 Aug 2016 06:26:34 -0700 (PDT) Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [174.112.186.144]) by smtp.gmail.com with ESMTPSA id c26sm18598415qte.1.2016.08.29.06.26.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 06:26:33 -0700 (PDT) To: =?UTF-8?Q?Joachim_Str=c3=b6mbergson?= , "David McGrew (mcgrew)" References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <57C43102.7090902@secworks.se> From: Rene Struik Message-ID: Date: Mon, 29 Aug 2016 09:26:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57C43102.7090902@secworks.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "cfrg@irtf.org" , "" Subject: [TLS] (confusing the issues) Re: [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 13:26:41 -0000 I think it is a mistake to think that simply using block ciphers with a larger block size is enough to counter attacks, as the literature on successful side channel attacks on such block cipher demonstrates. The real message is that one should not reuse keys ad infinitum, which unfortunately seems hard to sink in. Singling out 3-DES in this respect does not seem to tackle the real issue (which is a system security issue often only paid lip service to in practice). Rene On 8/29/2016 8:56 AM, Joachim Strömbergson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Aloha! > > As a side note, there has been a bunch of lightweight block ciphers > suggested the last few years, most of them with a block size of 64 bits. > And there has been discussion on IETF maillists about IETF accepting > them. For example the SIMON and SPECK ciphers. These ciphers can have > block sizes as small as 32 bits. > > https://www.cryptolux.org/images/a/a0/Beaulieu-DAC2015.pdf > https://eprint.iacr.org/2015/209.pdf > > Yours > JoachimS > > > > David McGrew (mcgrew) wrote: >> Hi Peter, >> >> You make a bunch of good points. But it is also worth noting that >> some people feel that current crypto standards, including IETF >> standards, are suitable for IoT. See for instance slides 8 and 9 of >> Daniel Shumow's talk at NIST’s LWC workshop last year: >> http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf >> Also, CoAP isn’t on his list, but it could be, and it uses DTLS. So >> while I agree with you that overuse of a 64-bit block cipher is far >> from the biggest security concern for IoT, the IETF should expect its >> protocols to be used in some IoT scenarios. >> >> The malleability of the term IoT is causing trouble here. Slide 6 >> of Daniel’s talk is quite revealing. To my thinking, by definition >> IoT devices are connected to the Internet in some way. >> >> David >> >> >> >> On 8/28/16, 8:01 AM, "Peter Gutmann" >> wrote: >> >>> David McGrew (mcgrew) writes: >>> >>>> I don’t think you understood my point. IoT is about small devices >>>> connecting to the Internet, and IETF standards should expect >>>> designed-for-IoT crypto to be increasingly in scope. It is >>>> important to not forget about these devices, amidst the current >>>> attention being paid to misuses of 64-bit block ciphers, which >>>> was the ultimate cause of this mail thread. >>> But the IETF has a long history of creating standards that >>> completely ignore IoT. I can't think of a single general-purpose >>> IETF security standard (TLS, SSH, IPsec, etc) that has any hope of >>> working with IoT devices (say a 40Mhz ARM-core ASIC with 32kB RAM >>> and 64kB flash). This is why the ITU/IEC and a million >>> lesser-known standards bodies are all busy inventing their own >>> exquisitely homebrew crypto protocols, most of which make WEP look >>> like a model of good design. >>> >>> (I've always wanted to sit down and design a generic "encrypted >>> pipe from A to B using minimal resources" spec, and I'm sure many >>> other people have had the same thought at one time or another). >>> >>> So it seems like you've got: >>> >>> - The "TLS = the web" crowd (browser vendors and the like) who will >>> implement whatever's trendy at the moment and assume everyone has a >>> quad-core 2GHz CPU with gigabytes of RAM and access to weekly live >>> updates and hotfixes. >>> >>> - Embedded/SCADA folks who need to deal with 10-15 year product >>> cycles (see my TLS-LTS draft for more on this) and are kind of >>> stuck. >>> >>> - IoT people, who can't use any standard protocol and will get the >>> least unqualified person on staff to invent something that seems OK >>> to them. >>> >>> I'm not sure that a draft on theoretical weaknesses in 64-bit block >>> ciphers is going to affect any of those... >>> >>> Peter. >> _______________________________________________ TLS mailing list >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > - -- > Med vänlig hälsning, Yours > > Joachim Strömbergson - Alltid i harmonisk svängning. > ======================================================================== > Joachim Strömbergson Secworks AB joachim@secworks.se > ======================================================================== > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBCAAGBQJXxDECAAoJEF3cfFQkIuyNY1UP/2lUJo53s27wlqvgPWpZYWzi > HViof7jYA7yvbZm9SeYkV88y4sOMUQrhSsAWUZ7GfwcjkjC8+sL8mD7uacPx0zpW > rAnLnAHJbnU8rkWRT2OKWiZBvwMpMNw/UYGy13dwilRExj22N4dsLK98vath3r52 > FjAIL2GpCWUuzPB6P5d+B8MjEwEr1tEYzvlvWo032RB91irOOKveryGGe5ifnSKj > SP1a9CbakaLdTHMkrhOre0I4Ckr2A97eI3oo/5QjRJ81zKJ/4VZzOOe3lGjPkXhO > kzkANctte+Eb5ttlaXcg/dL7lStzaYo8rnm3PRHsBKpHr/oNEgbdJti1U78/MfLf > o0v+s4TbY7YBPXOU7zKWpo9VD1Mcq9eMAslIQokEE2CfIq3wBSEEgKwJXu6HVSht > Ohahc7HUBnz2+uXJ+x4hl/bW/qM3DFhTfhPCYQ11IiXpPlxhsAnxbszBe4XtHd7y > z2Uc+Jef8aUq7sEGYBdcnGs+SSNFQwtUIicKI3pU61xvtAhqRriNOsfmCVvC2V7Z > iz5EodInPjUBkVMwDbmiFd5lp782SqYZsivwabPGE1p2GG+o421KZmQJ3VRC3ctw > xjwk2HszIv7Wo+gomL0hqF7Wi0YIP556rRYrRMc9gLV513xzxD5T99eR+2HtiRJF > TvYYPXZjzP087liGF7SA > =Z0iM > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Mon Aug 29 06:39:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACC012D614 for ; Mon, 29 Aug 2016 06:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIZiINkH8ZI6 for ; Mon, 29 Aug 2016 06:39:01 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5F97A12D5FF for ; Mon, 29 Aug 2016 06:39:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 938B4FE95; Mon, 29 Aug 2016 16:38:59 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id zGh8Ao71un19; Mon, 29 Aug 2016 16:38:59 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 652DB2310; Mon, 29 Aug 2016 16:38:59 +0300 (EEST) Date: Mon, 29 Aug 2016 16:38:49 +0300 From: Ilari Liusvaara To: "David McGrew (mcgrew)" Message-ID: <20160829133849.vmslsp4x3mhtaug6@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: ilariliusvaara@welho.com Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 13:39:03 -0000 On Mon, Aug 29, 2016 at 12:44:42PM +0000, David McGrew (mcgrew) wrote: > > The malleability of the term IoT is causing trouble here. Slide 6 > of Daniel’s talk is quite revealing. To my thinking, by definition > IoT devices are connected to the Internet in some way. Yes, the variability of capabilities of IoT devices is extreme. From devices that just barely can run some cipher gated to PSK, to ones that can easily run TLS without any hacks to save resources. There is no way to make TLS realistically work for the first kind, since just the flexibility of TLS would impose unreasonable burden, even if profiled down. If one limits oneself to the low end, I would think that anything that can realistically handle any profile of TLS can probably handle a real symmetric cipher (>=128 blocks, >=128 bit keys). -Ilari From nobody Mon Aug 29 10:03:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79512D5F2 for ; Mon, 29 Aug 2016 10:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_yXVNYOR3_H for ; Mon, 29 Aug 2016 10:03:51 -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 26F8312D098 for ; Mon, 29 Aug 2016 10:03:51 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id z190so144242648qkc.0 for ; Mon, 29 Aug 2016 10:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=p84lw8XM4/W58vlvYbcvxxT5BFiQVg5H5AEefrc1pv8=; b=IBeKjTHQ+R9S2AmxKhIbM7gFK5qukioYTH+8O0XXgYa1jtgNS6LTU1Pe7iP3XGr5/O dazYRvLd/cyrwsMuVJwhplO4nTPTCIQ7mIX2rbfd1+rzC3pvxceKuyu2+EURpbACqIJG q1sQ18QdD5CfRcn3QOff+85qalw7hYpaGRCOTGngeefvjuX517pisN0uA6ec9zF5Xj4u YHmxzzIchIqUV7gH17+ZK+zCiLGfbE5gwqsPe5+xGXW4g2rHnzLL3SoNDYtAW5/oxQcR W44D69LdPbw4Q51Ah5ToyPmgYBFQjQpM/7QTqDp4the3gnhwfwy2uiWbOfY+Ya5kFaJ7 MLFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=p84lw8XM4/W58vlvYbcvxxT5BFiQVg5H5AEefrc1pv8=; b=Ld/iF6iiUQRYBkujX9U1Lq8rQWXLZmqXaCvFcZaCg2ZZODRBlu5uKR1e5bxdTGzc79 TDxE4FJIzGKgrt/QKIFAwn1WLmx10FdBAtsRDChSJMTd2+uHx9HHQSliVDyUpHAMk7c1 eIyRNtW2rRolOA+CmHp0x8SxVekmxfZliaCugaKQlMBC1MenVNL9cf/1tt/RMTzXKk+o EPzBhJ+iGPEByXR3l92b9ZsgRrEFso+SJCjrRB0/Bh1r33D/BA1E49ZmBcBFc/0XBC5S cOXs1OLvreosj/fK47T5wf8UAtJUpTbUAAQXgZIlQSHaMi2RhK3dIMHt0cafSFFSKaNG gv7w== X-Gm-Message-State: AE9vXwNU7wyhwKuRJufCLJKstSPIoLFr5Cjoc5FjbEOkCQDk/gdxcr+I4mHCcGZpefTjgA== X-Received: by 10.55.41.86 with SMTP id p83mr20307841qkh.93.1472490227194; Mon, 29 Aug 2016 10:03:47 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id v68sm19054502qkd.9.2016.08.29.10.03.46 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 29 Aug 2016 10:03:46 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 29 Aug 2016 13:03:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <57C43102.7090902@secworks.se> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201608291303.45728.davemgarrett@gmail.com> Archived-At: Cc: "David McGrew \(mcgrew\)" , "cfrg@irtf.org" Subject: Re: [TLS] (confusing the issues) Re: [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 17:03:53 -0000 Within this line of thought, an unlimited-key-use-diediedie would have far = more value. An RFC precisely defining a set of key data limits would addres= s both this 3DES issue as well as AES and any other cipher. As cited on htt= ps://sweet32.info/ , data limits is a primary way Mozilla is dealing with t= his attack. Dave On Monday, August 29, 2016 09:26:18 am Rene Struik wrote: > I think it is a mistake to think that simply using block ciphers with a=20 > larger block size is enough to counter attacks, as the literature on=20 > successful side channel attacks on such block cipher demonstrates. The=20 > real message is that one should not reuse keys ad infinitum, which=20 > unfortunately seems hard to sink in. >=20 > Singling out 3-DES in this respect does not seem to tackle the real=20 > issue (which is a system security issue often only paid lip service to=20 > in practice). >=20 > Rene >=20 > On 8/29/2016 8:56 AM, Joachim Str=C3=B6mbergson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Aloha! > > > > As a side note, there has been a bunch of lightweight block ciphers > > suggested the last few years, most of them with a block size of 64 bits. > > And there has been discussion on IETF maillists about IETF accepting > > them. For example the SIMON and SPECK ciphers. These ciphers can have > > block sizes as small as 32 bits. > > > > https://www.cryptolux.org/images/a/a0/Beaulieu-DAC2015.pdf > > https://eprint.iacr.org/2015/209.pdf > > > > Yours > > JoachimS > > > > > > > > David McGrew (mcgrew) wrote: > >> Hi Peter, > >> > >> You make a bunch of good points. But it is also worth noting that > >> some people feel that current crypto standards, including IETF > >> standards, are suitable for IoT. See for instance slides 8 and 9 of > >> Daniel Shumow's talk at NIST=E2=80=99s LWC workshop last year: > >> http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4= =2Dshumow.pdf > >> Also, CoAP isn=E2=80=99t on his list, but it could be, and it uses DTL= S. So > >> while I agree with you that overuse of a 64-bit block cipher is far > >> from the biggest security concern for IoT, the IETF should expect its > >> protocols to be used in some IoT scenarios. > >> > >> The malleability of the term IoT is causing trouble here. Slide 6 > >> of Daniel=E2=80=99s talk is quite revealing. To my thinking, by defin= ition > >> IoT devices are connected to the Internet in some way. > >> > >> David > >> > >> > >> > >> On 8/28/16, 8:01 AM, "Peter Gutmann" > >> wrote: > >> > >>> David McGrew (mcgrew) writes: > >>> > >>>> I don=E2=80=99t think you understood my point. IoT is about small de= vices > >>>> connecting to the Internet, and IETF standards should expect > >>>> designed-for-IoT crypto to be increasingly in scope. It is > >>>> important to not forget about these devices, amidst the current > >>>> attention being paid to misuses of 64-bit block ciphers, which > >>>> was the ultimate cause of this mail thread. > >>> But the IETF has a long history of creating standards that > >>> completely ignore IoT. I can't think of a single general-purpose > >>> IETF security standard (TLS, SSH, IPsec, etc) that has any hope of > >>> working with IoT devices (say a 40Mhz ARM-core ASIC with 32kB RAM > >>> and 64kB flash). This is why the ITU/IEC and a million > >>> lesser-known standards bodies are all busy inventing their own > >>> exquisitely homebrew crypto protocols, most of which make WEP look > >>> like a model of good design. > >>> > >>> (I've always wanted to sit down and design a generic "encrypted > >>> pipe from A to B using minimal resources" spec, and I'm sure many > >>> other people have had the same thought at one time or another). > >>> > >>> So it seems like you've got: > >>> > >>> - The "TLS =3D the web" crowd (browser vendors and the like) who will > >>> implement whatever's trendy at the moment and assume everyone has a > >>> quad-core 2GHz CPU with gigabytes of RAM and access to weekly live > >>> updates and hotfixes. > >>> > >>> - Embedded/SCADA folks who need to deal with 10-15 year product > >>> cycles (see my TLS-LTS draft for more on this) and are kind of > >>> stuck. > >>> > >>> - IoT people, who can't use any standard protocol and will get the > >>> least unqualified person on staff to invent something that seems OK > >>> to them. > >>> > >>> I'm not sure that a draft on theoretical weaknesses in 64-bit block > >>> ciphers is going to affect any of those... From nobody Mon Aug 29 10:30:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9812D7C2 for ; Mon, 29 Aug 2016 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4aLaJ9lSrQe for ; Mon, 29 Aug 2016 10:30:17 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD5612D7B9 for ; Mon, 29 Aug 2016 10:30:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id F3B7EFB8D; Mon, 29 Aug 2016 20:30:15 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id u7E6IdMCItTE; Mon, 29 Aug 2016 20:30:15 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B33C62313; Mon, 29 Aug 2016 20:30:15 +0300 (EEST) Date: Mon, 29 Aug 2016 20:30:05 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160829173005.qfmfm2vfdumvolg2@LK-Perkele-V2.elisa-laajakaista.fi> References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> <20160828184105.yvrnbispbnpomk4s@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.6.2-neo (2016-08-21) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 17:30:19 -0000 On Sun, Aug 28, 2016 at 11:50:27AM -0700, Eric Rescorla wrote: > On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara > wrote: > > > On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: > > > > > > I'd prefer to keep things as simple as possible here and from that > > > perspective, I think any indicator from side A to side B that it wants a > > > key change over and above the KeyUpdate is extra complexity. I do, > > however, > > > want to retain the property that one side can ask the other one to rekey > > > [0]. I believe we can get this by modifying the rule in the spec by > > treating > > > a run of KeyUpdates as a single generation. > > > > > > Specifically. > > > "Upon receiving a KeyUpdate, the receiver MUST update its receiving > > > keys. If the receiver has sent any data records since receiving the > > > last KeyUpdate it MUST also increment its min_send_generation counter > > > by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior > > > to sending a record, if min_send_generation is greater than the > > > current sending generation, the sender MUST first send a KeyUpdate." > > > > Timing- and propagation-wise, it looks workable (also, could be done > > with two flags[1], no need for counter). I tried to implement this, and probably got it wrong somehow: Test setup consisists of multi-Gbps stream in one direction and fairly slow one in another. Very low latencies. Also, TLS stack can't do new flights. 1) The fast stream eventually (~5min) reaches the rekey threshold, triggering a KeyUpdate. 2) The other side receives the KeyUpdate. Since last record it sent was not KeyUpdate, it marks KeyUpdate to be sent. 3) The slow stream transmits something. Since KeyUpdate is pending, it is sent, along with something else (so last record is not a KeyUpdate. 4) The fast sender receives the KeyUpdate. Since last record it sent was not a KeyUpdate (it has sent more data since) it schedules a KeyUpdate to be sent. 5) Almost immediately new data arrives, and since KeyUpdate is pending, it is sent, along with something else (so last record is not a KeyUpdate). 6) Goto 2. The result is ping-pong of KeyUpdate's that starts as soon as one side sends one (at rate determined by the send rate of the slower peer, which still can be pretty high). -Ilari From nobody Mon Aug 29 10:33:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6811312D7B9 for ; Mon, 29 Aug 2016 10:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OTG0TyUDQDs for ; Mon, 29 Aug 2016 10:33:34 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE65012D73C for ; Mon, 29 Aug 2016 10:33:33 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id e31so50710889ybi.3 for ; Mon, 29 Aug 2016 10:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V71miqtQCD6RD7PpOr1o11l60h+OpOGIt6WUdT4FF8Q=; b=1jNUhlW4ezg0rTvz8IG7ZPbgglRJcgmMFlGcPEFTVcv6DdD0iDvmrwYUT3/B3OQIgJ hVxsmaOhyc/4KG6nNnFivMXxdOTC/717ecjFVGvAMoV71B/z0wcCFftxxqxJwyf8ok4W fLCftZnT4HVR5hogaysDgTq1UnOvkWNpvQeS/dm+xBBEjSlih/i0A1j2Lvwwdpy9YnF4 6l5W/8GE0pFK9fWafiLRbZRAr16ThqXQaEPob9RTr2O+0EO8g55zLYrn4y3hTHPHZVOl Vd9szHFQIVR6ZPkgfVFAXfD38LdUm19N1H52H2qh5IzZsw/pUnFFg3rIGWN3P20Hjdq3 +mbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V71miqtQCD6RD7PpOr1o11l60h+OpOGIt6WUdT4FF8Q=; b=dX2x7C0rnnwUyhPtaV4cfPgxx+9S4/rw1VPO41gOZWkUS6qaGyskey4MJNGEVYCg/p 4z4s9/lRmyzFVjgqEV/jOZWIuR/hR/n/wijRhMP/oyyer+LJ0YkmQi/A3o9eRNVEPPjH DpNaoI7GOW1U8WrJmiv6w0ZAqQoqzhkMDUzjgV9Nw44mbjw0/DAnge/tJkVY3AqD/ce4 MiI0sBe4Gax9fhS1Uic+pV4WLGe2/meSmD3kUXo2LnwGo0XJS+QgohgUJ49fRC2Sv11L K/Q7zHjxf62GGKRqpIy8KwCIi21sIj1vCZIU5/U+JMzhk8lZ1q3J4L5Fioft12prdxJV xHpw== X-Gm-Message-State: AE9vXwPoCdVpUhEpGh13lEUMxS1pRxdvq2JEUIbzS65O4jZkQcmQP5d2KTW5e/vqfvm8H9R8bE0oWDqYJQwQFA== X-Received: by 10.37.64.78 with SMTP id n75mr6190031yba.162.1472492013034; Mon, 29 Aug 2016 10:33:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Mon, 29 Aug 2016 10:32:52 -0700 (PDT) In-Reply-To: <20160829173005.qfmfm2vfdumvolg2@LK-Perkele-V2.elisa-laajakaista.fi> References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> <20160828184105.yvrnbispbnpomk4s@LK-Perkele-V2.elisa-laajakaista.fi> <20160829173005.qfmfm2vfdumvolg2@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 29 Aug 2016 10:32:52 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c03ea05f71e8053b3943ca Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 17:33:35 -0000 --001a11c03ea05f71e8053b3943ca Content-Type: text/plain; charset=UTF-8 On Mon, Aug 29, 2016 at 10:30 AM, Ilari Liusvaara wrote: > On Sun, Aug 28, 2016 at 11:50:27AM -0700, Eric Rescorla wrote: > > On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: > > > > > > > > I'd prefer to keep things as simple as possible here and from that > > > > perspective, I think any indicator from side A to side B that it > wants a > > > > key change over and above the KeyUpdate is extra complexity. I do, > > > however, > > > > want to retain the property that one side can ask the other one to > rekey > > > > [0]. I believe we can get this by modifying the rule in the spec by > > > treating > > > > a run of KeyUpdates as a single generation. > > > > > > > > Specifically. > > > > "Upon receiving a KeyUpdate, the receiver MUST update its receiving > > > > keys. If the receiver has sent any data records since receiving the > > > > last KeyUpdate it MUST also increment its min_send_generation counter > > > > by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior > > > > to sending a record, if min_send_generation is greater than the > > > > current sending generation, the sender MUST first send a KeyUpdate." > > > > > > Timing- and propagation-wise, it looks workable (also, could be done > > > with two flags[1], no need for counter). > > I tried to implement this, and probably got it wrong somehow: > > Test setup consisists of multi-Gbps stream in one direction and fairly > slow one in another. Very low latencies. Also, TLS stack can't do new > flights. > > 1) The fast stream eventually (~5min) reaches the rekey threshold, > triggering a KeyUpdate. > 2) The other side receives the KeyUpdate. Since last record it sent > was not KeyUpdate, it marks KeyUpdate to be sent. > 3) The slow stream transmits something. Since KeyUpdate is pending, > it is sent, along with something else (so last record is not a > KeyUpdate. > 4) The fast sender receives the KeyUpdate. Since last record it > sent was not a KeyUpdate (it has sent more data since) it > schedules a KeyUpdate to be sent. > 5) Almost immediately new data arrives, and since KeyUpdate is pending, > it is sent, along with something else (so last record is not a > KeyUpdate). > 6) Goto 2. > > The result is ping-pong of KeyUpdate's that starts as soon as one side > sends one (at rate determined by the send rate of the slower peer, > which still can be pretty high). > Did you use the "flags" approach or the generation approach, since it seems like in the latter approach, at that point it would be in send=2, recv=1 and it wouldn't update. -Ekr > > -Ilari > --001a11c03ea05f71e8053b3943ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 29, 2016 at 10:30 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Sun, Aug 28, 2016 at 11:50:27AM -0700, Eric Rescorla wrote: > On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: > > >
> > > I'd prefer to keep things as simple as possible here and= from that
> > > perspective, I think any indicator from side A to side B tha= t it wants a
> > > key change over and above the KeyUpdate is extra complexity.= I do,
> > however,
> > > want to retain the property that one side can ask the other = one to rekey
> > > [0]. I believe we can get this by modifying the rule in the = spec by
> > treating
> > > a run of KeyUpdates as a single generation.
> > >
> > > Specifically.
> > > "Upon receiving a KeyUpdate, the receiver MUST update i= ts receiving
> > > keys. If the receiver has sent any data records since receiv= ing the
> > > last KeyUpdate it MUST also increment its min_send_generatio= n counter
> > > by 1. Otherwise, the min_send_generation MUST remain unchang= ed. Prior
> > > to sending a record, if min_send_generation is greater than = the
> > > current sending generation, the sender MUST first send a Key= Update."
> >
> > Timing- and propagation-wise, it looks workable (also, could be d= one
> > with two flags[1], no need for counter).

I tried to implement this, and probably got it wrong somehow:

Test setup consisists of multi-Gbps stream in one direction and fairly
slow one in another. Very low latencies. Also, TLS stack can't do new flights.

1) The fast stream eventually (~5min) reaches the rekey threshold,
=C2=A0 =C2=A0triggering a KeyUpdate.
2) The other side receives the KeyUpdate. Since last record it sent
=C2=A0 =C2=A0was not KeyUpdate, it marks KeyUpdate to be sent.
3) The slow stream transmits something. Since KeyUpdate is pending,
=C2=A0 =C2=A0it is sent, along with something else (so last record is not a=
=C2=A0 =C2=A0KeyUpdate.
4) The fast sender receives the KeyUpdate. Since last record it
=C2=A0 =C2=A0sent was not a KeyUpdate (it has sent more data since) it
=C2=A0 =C2=A0schedules a KeyUpdate to be sent.
5) Almost immediately new data arrives, and since KeyUpdate is pending,
=C2=A0 =C2=A0it is sent, along with something else (so last record is not a=
=C2=A0 =C2=A0KeyUpdate).
6) Goto 2.

The result is ping-pong of KeyUpdate's that starts as soon as one side<= br> sends one (at rate determined by the send rate of the slower peer,
which still can be pretty high).

Did yo= u use the "flags" approach or the generation approach, since it s= eems
like in the latter approach, at that point it would be in se= nd=3D2, recv=3D1 and
it wouldn't update.

=
-Ekr



-Ilari

--001a11c03ea05f71e8053b3943ca-- From nobody Mon Aug 29 11:11:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678E612B04E for ; Mon, 29 Aug 2016 11:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYPQgc24vcei for ; Mon, 29 Aug 2016 11:11:15 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD1712B00B for ; Mon, 29 Aug 2016 11:11:14 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id l2so146441013qkf.3 for ; Mon, 29 Aug 2016 11:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=keC+eim757xcTlamGIc2BvpwzXPhhBnxdlFTBmME/zg=; b=i82PxU0CeGsQpqkWPq+8k57ekmbs5fVTt93brXmyRkfQpjDhHZTyQNuy3h8WATCZwb 53ysc+uwsvW0aLTrM263TiM6OC8BuO9Xv0jZeEDx2Sdn411i1Y/ofrVxYRyCOOieutJH v1PuQbEEVgDxkInGUYKUWPh9ZQUEskPmE9ApoPMsnOktd2YV9JQ/Ic8z+NBTNwPaloeK ge4tZbJyCPfGlnF7NiUg39sUsnHWwvla43tW4Q3uYfWwx0mxdyCqH1dKBsuK7tZyaXbi YxcHGD4dex0eXeGVxoPnpSuA9gD63eCEpwQD5pLUw8xx6qmGIsKgsh/jdQ2vi7zLFfdd 9ilQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=keC+eim757xcTlamGIc2BvpwzXPhhBnxdlFTBmME/zg=; b=k+G5BXLGnYbFq45FCdLTResO8lofuMV52qynPlSaMe/Pz5OsmKmk/p4WNJVoAOdZYt EDP3/2mGkMi5NY5AN43U+t8G3mYnMpaQ+yEjRLdRIVzZVCWxn66hN/kEeCIVo/e8toRK irqyME1FDHKTpj4oyU0r6JFcDi+CdfzYrtWp/HFVOpt05KLNvzNpRTURBw06LVjFuoet St6B+51lNBJhhsuXv+J7iZjDBIgaU8v7aeiLkd3vJ66/d1RFm+Hx+sBOEeTyHW/tPHfi gw7folpADJ1ta6/HsKvOBt460SBfNWK6C9w3J3mVdTeUPDndqU+mMtuvWY9auzo2/ToL eSKQ== X-Gm-Message-State: AE9vXwO+fY7l7osiCM8Va7w+Mz4SVsAwucwTDgOVKsvgP2Hy5BlPCdo9KdEvd44pEYSmOXDtfZ21OM4EGpDc5w== X-Received: by 10.55.160.70 with SMTP id j67mr16738837qke.274.1472494273995; Mon, 29 Aug 2016 11:11:13 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.200.36.199 with HTTP; Mon, 29 Aug 2016 11:11:12 -0700 (PDT) In-Reply-To: References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> <20160828184105.yvrnbispbnpomk4s@LK-Perkele-V2.elisa-laajakaista.fi> From: Adam Langley Date: Mon, 29 Aug 2016 11:11:12 -0700 X-Google-Sender-Auth: wVhCy8TB3qOHIsfEaa_fpQlm3iQ Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 18:11:16 -0000 On Sun, Aug 28, 2016 at 11:50 AM, Eric Rescorla wrote: > Yes, I agree separate ladders would fix this. I don't necessarily object to > this > change, but I'm not sure it's that big a deal either, because you really > only get > into this case when there's a big asymmetry in sending rate, so much that > one side wants to send multiple updates before the other side has sent > any data at all. I think that cases where there's a big asymmetry in sending rates are in the majority. > Note: it's also possible to avoid the rollback problem with the existing > single-ladder system: when you send a key update you compute: > > traffic_secret_N+1 > read_key_N+1 > write_key_N+1 > > You then discard traffic_secret N, write_key_N, but key read_key_N, so if > you > are M updates ahead of the other side, you have M read keys outstanding, > but these cannot be used to produce the write keys. However, this probably > isn't simpler than just running two ladders if we think this is important. That works but I agree that splitting the ladders is nicer and I think that we should do that. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Aug 29 12:15:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA5312D820 for ; Mon, 29 Aug 2016 12:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7a4ZI5XAG3M for ; Mon, 29 Aug 2016 12:15:50 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 E2A2512D81F for ; Mon, 29 Aug 2016 12:15:49 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id h3so30473577ybi.2 for ; Mon, 29 Aug 2016 12:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YBQP6aKrnvh82b5VJ+XSbw80PiTvOlfha3dusz1RtJo=; b=k48ZhFNwXY6NBmmBG+H2rbgeSkYwUmP/M3nawErqHwtaOiJwsXuNTswECBuMQwR9WG buZTv5zCBSHRvDGIPQXPDbpwsFF0Jgdf/LZyL5Q2RN6Js8aJf4zH29mBDXxts27jHf6g XpaFrrjMg3E52XbcQ3vh/TnPieQGz96NZuXnuHGqoxiKzu0C0I3ZIQqs/7tRtLjnbmxE mV44roz6gXrjVtC09go6LyyoFcZOG+xXzw//0RBI7AXiE7Zv8gO34kGuHW+7nce6C/9E BD1tYcjL06SjRFaz0K/52Gl9yMUfZoJkaMJQYZCgqt1lDli2KENBdEakvEosxALT6A/I t4Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YBQP6aKrnvh82b5VJ+XSbw80PiTvOlfha3dusz1RtJo=; b=ZMlCOCaycqA0IOn1lfpCjjLxD7ugzJYvRbe/Ppj+hXMm2hugvuw9GdV8l+sBxGDgmo shyon4mSm77A2hs3jqGVNRWAyZR3FGpN8N88+kvTea1C8nUSGNVyhy8NH786QDCkvJa5 peO3yQGRYORmG0yUm7M06XehnO1H9EvEew33SM+T3av3zVH97EF0Alja4+6OriVPR5Fa yMCirw1BZ17t3VFo63sWHyx2qq/++AuD06vKRve83d+Bzy+fIEwMZ8dk68IaeCQrblOX ikLMxq0NWO66ZUAQ6sFsAhau2ktjE6bwRSLKzzCfucub82xM5koJ6AuMuw3qpHpQL6/M oysw== X-Gm-Message-State: AE9vXwOnBGVnVh22fo+NdGDVKvCEBdeQ1cPevOfjKFoAuo7oVba1ticlbOUpEGy/3rnV8hTvmOFTb+JDePddeQ== X-Received: by 10.37.2.66 with SMTP id 63mr13743465ybc.146.1472498149161; Mon, 29 Aug 2016 12:15:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Mon, 29 Aug 2016 12:15:08 -0700 (PDT) In-Reply-To: References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> <20160828184105.yvrnbispbnpomk4s@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 29 Aug 2016 12:15:08 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=001a113d4af01d3491053b3ab123 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 19:15:52 -0000 --001a113d4af01d3491053b3ab123 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 29, 2016 at 11:11 AM, Adam Langley wrote: > On Sun, Aug 28, 2016 at 11:50 AM, Eric Rescorla wrote: > > Yes, I agree separate ladders would fix this. I don't necessarily object > to > > this > > change, but I'm not sure it's that big a deal either, because you really > > only get > > into this case when there's a big asymmetry in sending rate, so much that > > one side wants to send multiple updates before the other side has sent > > any data at all. > > I think that cases where there's a big asymmetry in sending rates are > in the majority. > Well, it has to be more than just asymmetric in terms of traffic volume, but I take your point. > Note: it's also possible to avoid the rollback problem with the existing > > single-ladder system: when you send a key update you compute: > > > > traffic_secret_N+1 > > read_key_N+1 > > write_key_N+1 > > > > You then discard traffic_secret N, write_key_N, but key read_key_N, so if > > you > > are M updates ahead of the other side, you have M read keys outstanding, > > but these cannot be used to produce the write keys. However, this > probably > > isn't simpler than just running two ladders if we think this is > important. > > That works but I agree that splitting the ladders is nicer and I think > that we should do that. > I'm fine with that. Unless someone objects soon I'm going to prepare a PR to do this along with the rule above (both changes are required). -Ekr > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > --001a113d4af01d3491053b3ab123 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 29, 2016 at 11:11 AM, Adam Langley <agl@imperialviole= t.org> wrote:
On Sun, Aug 28, 2016 at 11:50 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> Yes, I agree separate ladders would fix this. I don't necessarily = object to
> this
> change, but I'm not sure it's that big a deal either, because = you really
> only get
> into this case when there's a big asymmetry in sending rate, so mu= ch that
> one side wants to send multiple updates before the other side has sent=
> any data at all.

I think that cases where there's a big asymmetry in sending rate= s are
in the majority.

Well, it has to be mor= e than just asymmetric in terms of traffic volume, but I take
you= r point.


= > Note: it's also possible to avoid the rollback problem with the ex= isting
> single-ladder system: when you send a key update you compute:
>
> traffic_secret_N+1
> read_key_N+1
> write_key_N+1
>
> You then discard traffic_secret N, write_key_N, but key read_key_N, so= if
> you
> are M updates ahead of the other side, you have M read keys outstandin= g,
> but these cannot be used to produce the write keys. However, this prob= ably
> isn't simpler than just running two ladders if we think this is im= portant.

That works but I agree that splitting the ladders is nicer and I thi= nk
that we should do that.

I'm fine wi= th that. Unless someone objects soon I'm going to prepare a PR to do th= is
along with the rule above (both changes are required).

-Ekr
=C2=A0


Cheers

AGL

--
Adam Langley agl@imperialviolet.o= rg https://www.imperialviolet.org

--001a113d4af01d3491053b3ab123-- From nobody Mon Aug 29 13:00:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE2412D870 for ; Mon, 29 Aug 2016 13:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmC4TPW9one3 for ; Mon, 29 Aug 2016 13:00:33 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003: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 C1DB212B032 for ; Mon, 29 Aug 2016 12:52:51 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id c15so211084236oig.0 for ; Mon, 29 Aug 2016 12:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=MsCbORbVun0gUbRLH7oQ/yJ5pP9M9XvXa9SUX6jor1U=; b=SGE00v4GjkUiSu+mX4ol5d5GHzvfZD2zKJig+LPS0kpKM2tG+oRvYnyM7Sjxm5Udtd Ekq9ZBc8L/I5zI12IlYNCWubzSbNvNdpWFYgrqVgkwU6WaxaqMEWBer8FkRO+F2wvnVv TxuCG7exBSLbsNx/FEdvRICOd+bs7QsktenvU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MsCbORbVun0gUbRLH7oQ/yJ5pP9M9XvXa9SUX6jor1U=; b=SEOUY8YdZeGfUPVMb52i8Bo4HtrFPoaIGHZNFFRRv5TKHIttFDm8U8+wQu6G3KL9+e EbUO3ahUOgWpWmfjh6Pug6ocwyC8mnsXrjiunWF8pr3M0m5jrUhRW2TsDFwKw9WokByR ud+1zm6MY5UVd1mR1NPATL3mR3QRbX5NPB/gm2T4Dfc089irzG0UiB2/vKsAW9pN6mbu yVz8tTWln1a4NtZocPCYi10mzYv+F4z9IRQ8xjg+VO2568B1Zuww1YjoybMSK/sj3s2U 5LKLaghW7muVVbfxYV/O6zophDivJSX7bGA46USCy6+51xMv+hyYY8L4KKGHWYSN7Nzy mnkw== X-Gm-Message-State: AE9vXwNv2r85PbJqYOVUgO4GZ9flVudKWA6Wh0hS+uivXuSf8j1/jsYBy63bYRuleQpUQCRIVA/bRdzbcwATtLAc X-Received: by 10.202.205.77 with SMTP id d74mr12615843oig.63.1472500370898; Mon, 29 Aug 2016 12:52:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.70.71 with HTTP; Mon, 29 Aug 2016 12:52:50 -0700 (PDT) From: Zhenfei Zhang Date: Mon, 29 Aug 2016 15:52:50 -0400 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11476fac8a181b053b3b35ab Archived-At: Subject: [TLS] PR #604 Change "supported_groups" to "supported_kems" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 20:00:36 -0000 --001a11476fac8a181b053b3b35ab Content-Type: text/plain; charset=UTF-8 Hi list, I have created a pull request https://github.com/tlswg/tls13-spec/pull/604 I would like to suggest that we change the terminology "NamedGroup" to "KeyExchangeMethod". In [1], it is suggested that we redefine the syntax, which leads to the separation of public key crypto and symmetric crypto during a handshake. Because of this separation, new terminology was defined for key exchange algorithms and authentication algorithms for public key crypto in the key exchange extension. "NamedGroup" was used to refer the underlying key exchange parameters, which comes from the "Supported Elliptic Curves" in previous versions. The use of "NamedGroup" implicitly requests the key exchange algorithm to be Deffie-Hellman type. While it is safe for now, it would be nice to have some crypto agility, and future proof. It would make the transition to other key exchange primitives (such as lattice based key exchange) or methods (such as key encapsulation mechanism) easier in the future, if we do not restrict the key exchange by certain "Group". Knowing that NIST has planned to standardize quantum-safe cryptography within 7 years of time (which can and should be accelerated), and those algorithms cannot be described in terms of "group", the current terminology will due for a redesign by then. So I would suggest to change the "NamedGroup" now rather than later. Overall, this will have the following impact 1. HelloRetryRequest Change HelloRetryRequest structure to struct { ProtocolVersion server_version; KeyExchangeMethod selected_kem; Extension extensions<0..2^16-1>; } HelloRetryRequest; 2. Negotiated Groups Throughout, change "supported_groups" to "supported_kems"; change "NamedGroupList" to "KeyExchangeMethodList"; change "named_group_list" to "kem_list"; change NamedGroup to KeyExchangeMethod 3. Key Share: Change KeyShareEntry structure to struct { KeyExchangeMethod kem; opaque key_exchange<1..2^16-1>; } KeyShareEntry; [1] https://github.com/ekr/tls13-spec/blob/15126cf5a08c445aeed97c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md Thanks for your time. Zhenfei Zhang --001a11476fac8a181b053b3b35ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi list,

=

I have created a pull request

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

I would like to suggest that we change the ter= minology "NamedGroup" to "KeyExchangeMethod".


In [1], it is suggested that we rede= fine the syntax, which leads to the separation of public key crypto=C2=A0

and symmetric crypto during a handshake. Because of this separation, new terminology was defined

for key exchange algorithms and authentication algorithms for public key crypto in = the key exchange=C2=A0

extension. "NamedGroup&qu= ot; was used to refer the underlying key exchange parameters, which comes=C2=A0

from t= he "Supported Elliptic Curves" in previous versions.


The use of "NamedGroup" implicitly requests the key exchange algorithm to be Deffie-Hellman type.=C2=A0

While it is safe for now, it would be nice to have some crypto agility, and future proof. It would make= =C2=A0

the transition to other key exchange primitives (such as lattice based key exchange) or methods=C2=A0

(such as key encapsula= tion mechanism) easier in the future, if we do not restrict the key exchange

by= certain "Group".


Knowing that NIST has planned to standardize quantum-safe cryptography within 7 years of time=C2=A0

(which = can and should be accelerated), and those algorithms cannot be described in terms of "group",

the current terminology will due for a redesign by then. So I would suggest to change t= he=C2=A0

"NamedGroup" now rather than l= ater.


Overall, this will have the following impact


1. HelloRetryRequest


Change HelloRetryRequest stru= cture to


struct {<= /p>

ProtocolVersion server_version;

KeyExchangeMethod selected_kem;

Extensio= n extensions<0..2^16-1>;

} HelloRetryReques= t;


2. Negotiated G= roups


Throughout, = change "supported_groups" to "supported_kems"; change "NamedGroupList" to
"KeyExchangeMethodList";= change "named_group_list" to "kem_list"; change NamedGroup to<= /p>

KeyExchangeMethod


<= /p>

3. Key Share:

Change Ke= yShareEntry structure to


struct {

KeyExchangeMethod kem;

opaque key_exchange<1..2^16-1>;

} KeyShareEntry;

[1] https://github.com/ekr/tls13-spec/= blob/15126cf5a08c445aeed97c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md


Thanks for your tim= e.


Zhenfei Zhang

--001a11476fac8a181b053b3b35ab-- From nobody Mon Aug 29 14:46:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5420312B056 for ; Mon, 29 Aug 2016 14:46:52 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eKL7OzxvF0s for ; Mon, 29 Aug 2016 14:46:50 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id B9324126FDC for ; Mon, 29 Aug 2016 14:46:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 4F749A14A691; Mon, 29 Aug 2016 14:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFIXoK-9-9sP; Mon, 29 Aug 2016 14:46:49 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id E2253A14A681; Mon, 29 Aug 2016 14:46:49 -0700 (PDT) Received: from [10.119.8.127] ([173.245.83.244]) by keys.merrymeet.com (PGP Universal service); Mon, 29 Aug 2016 14:46:49 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 29 Aug 2016 14:46:49 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> Date: Mon, 29 Aug 2016 14:46:47 -0700 Message-Id: <89A46793-73A1-4C71-9954-37BF6ED6F297@callas.org> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> To: "David McGrew (mcgrew)" X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "cfrg@irtf.org" , Jon Callas , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 21:46:52 -0000 > On Aug 29, 2016, at 5:44 AM, David McGrew (mcgrew) = wrote: >=20 > Hi Peter, >=20 > You make a bunch of good points. But it is also worth noting that = some people feel that current crypto standards, including IETF = standards, are suitable for IoT. See for instance slides 8 and 9 of = Daniel Shumow's talk at NIST=E2=80=99s LWC workshop last year: = http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shu= mow.pdf Also, CoAP isn=E2=80=99t on his list, but it could be, and it = uses DTLS. So while I agree with you that overuse of a 64-bit block = cipher is far from the biggest security concern for IoT, the IETF should = expect its protocols to be used in some IoT scenarios. =20 >=20 > The malleability of the term IoT is causing trouble here. Slide 6 of = Daniel=E2=80=99s talk is quite revealing. To my thinking, by definition = IoT devices are connected to the Internet in some way. Definitely. But to quote Shumow's talk on Slide 10 (which has the title = "IoT Does Not Need Its Own Crypto Standards"): =E2=80=A2 Current cryptographic standards work for IoT =E2=80=A2 Current standards are not a limit on IoT performance. =E2=80=A2 Perspective: Common IoT platforms are approximately as=20= powerful as PCs from 15 years ago when AES was standardized. And on Slide 11: =E2=80=A2 Adding new standards can be problematic: =E2=80=A2 New standards, especially with lower key sizes could = be=20 used in scenarios where they aren=E2=80=99t intended. Example: Standardizing ECC over 160bit prime for an RFID card and it ends up being used for https; block cipher with 80bit key space ends up being used to encrypt hard drives. His conclusion (slide 13) says that we don't need Lightweight Crypto in = software, but admits there are some hardware places (like RFID) for it. And that gets to Peter's basic, good points. While Peter is being brash, = his larger point is the same point as Shumow's, that we should just be = using our existing toolbox and that even *that* has too many choices. = The AllJoyn suite, which is the most stripped down, is brilliantly = simple: RSA, ECDSA/ECDHE P256, and AES-CCM. You can quibble with it, but = it's to the point. (My quibbles would be to toss RSA and Curve 41417 = instead because it has an ARM NEON implementation that's as fast as = P-160. But those are quibbles.) Folding back up to the subject here -- AES is faster than DES. That is = one of the reasons it was selected as AES. (So are Twofish and Serpent.) = We need to toss all 64-bit block ciphers. They were okay way back in the = 1900s. It is no longer then. AES is cheap and getting cheaper. We don't = need to patch up any of those old ciphers with meshing or what. We just = need to use what's in our toolbox. 3DES needs to go solely because it's = a patch on DES that needs to be patched for its small block size. I know = it's boring to just use AES, but it meets all the goals. Jon From nobody Mon Aug 29 14:48:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A699312D89C for ; Mon, 29 Aug 2016 14:48:43 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCMWVll9OfVw for ; Mon, 29 Aug 2016 14:48:42 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id D5D74126FDC for ; Mon, 29 Aug 2016 14:48:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id AB856A14A76F; Mon, 29 Aug 2016 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB5ytJ+pqddC; Mon, 29 Aug 2016 14:48:42 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 75ACCA14A762; Mon, 29 Aug 2016 14:48:42 -0700 (PDT) Received: from [10.119.8.127] ([173.245.83.244]) by keys.merrymeet.com (PGP Universal service); Mon, 29 Aug 2016 14:48:42 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 29 Aug 2016 14:48:42 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-Reply-To: Date: Mon, 29 Aug 2016 14:48:40 -0700 Message-Id: <8699AC5D-AD51-4287-A302-55CF9549A7FC@callas.org> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <57C43102.7090902@secworks.se> To: Rene Struik X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" , "David McGrew \(mcgrew\)" , "cfrg@irtf.org" , Jon Callas Subject: Re: [TLS] [Cfrg] (confusing the issues) Re: 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 21:48:43 -0000 > On Aug 29, 2016, at 6:26 AM, Rene Struik = wrote: >=20 > I think it is a mistake to think that simply using block ciphers with = a larger block size is enough to counter attacks, as the literature on = successful side channel attacks on such block cipher demonstrates. The = real message is that one should not reuse keys ad infinitum, which = unfortunately seems hard to sink in. >=20 > Singling out 3-DES in this respect does not seem to tackle the real = issue (which is a system security issue often only paid lip service to = in practice). Yes, we should just stop using 64-bit block ciphers and deal with the = issues you mention within the context of larger blocks. Jon From nobody Mon Aug 29 15:16:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37CD12D8A3 for ; Mon, 29 Aug 2016 15:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgw9KPVKxlXi for ; Mon, 29 Aug 2016 15:15:44 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E9212D8C0 for ; Mon, 29 Aug 2016 15:06:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 01DF63005B5 for ; Mon, 29 Aug 2016 18:06:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5vOWi5A9DRXx for ; Mon, 29 Aug 2016 18:06:29 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id F19ED3002C2; Mon, 29 Aug 2016 18:06:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 29 Aug 2016 18:06:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <95C31431-189C-41ED-A2D2-E370A5FB8F7A@vigilsec.com> References: <7e9c315a-f0e6-f547-e5e9-a3f48f8d12ff@cs.tcd.ie> <974CF78E8475CD4CA398B1FCA21C8E99565C26C5@PRN-MBX01-4.TheFacebook.com> <20160825042343.w6bg6kg75tujhexg@LK-Perkele-V2.elisa-laajakaista.fi> <20160828184105.yvrnbispbnpomk4s@LK-Perkele-V2.elisa-laajakaista.fi> To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF TLS Subject: Re: [TLS] KeyUpdate and unbounded write obligations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Aug 2016 22:15:56 -0000 Eric: > Yes, I agree separate ladders would fix this. I don't necessarily = object to this > change, but I'm not sure it's that big a deal either, because you = really only get > into this case when there's a big asymmetry in sending rate, so much = that > one side wants to send multiple updates before the other side has sent > any data at all. I can think of many situations where one side sends a lot more data than = the other. > Note: it's also possible to avoid the rollback problem with the = existing > single-ladder system: when you send a key update you compute: >=20 > traffic_secret_N+1 > read_key_N+1 > write_key_N+1 >=20 > You then discard traffic_secret N, write_key_N, but key read_key_N, so = if you > are M updates ahead of the other side, you have M read keys = outstanding, > but these cannot be used to produce the write keys. However, this = probably > isn't simpler than just running two ladders if we think this is = important. That seems to work. However, I think that splitting the ladders seems = to marry well with the many situations where one side sends a lot more = than the other. So, I suggest that we split the ladders. Russ From nobody Mon Aug 29 18:21:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A03112B063; Mon, 29 Aug 2016 18:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-6cfQQRXZel; Mon, 29 Aug 2016 18:21:51 -0700 (PDT) Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F7D12B05E; Mon, 29 Aug 2016 18:21:51 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id u7U1K42x015563; Mon, 29 Aug 2016 21:21:40 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 46E1C6D; Mon, 29 Aug 2016 21:21:40 -0400 (EDT) Received: from sendprodmail03.cc.columbia.edu (sendprodmail03.cc.columbia.edu [128.59.72.15]) by hazelnut (Postfix) with ESMTP id 254BE6D; Mon, 29 Aug 2016 21:21:40 -0400 (EDT) Received: from [192.168.2.25] (smb-gw.apt.columbia.edu [128.59.107.140]) (user=smb2132 mech=PLAIN bits=0) by sendprodmail03.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id u7U1LdYW018785 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Aug 2016 21:21:39 -0400 From: "Steven M. Bellovin" To: "Jon Callas" Date: Mon, 29 Aug 2016 21:21:38 -0400 Message-ID: <5CF32AA8-59CC-4918-8951-A2ACBD233C19@cs.columbia.edu> In-Reply-To: <89A46793-73A1-4C71-9954-37BF6ED6F297@callas.org> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <89A46793-73A1-4C71-9954-37BF6ED6F297@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (2.0BETAr6052) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.15 Archived-At: Cc: David McGrew , "cfrg@irtf.org" , tls@ietf.org Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 01:21:53 -0000 On 29 Aug 2016, at 17:46, Jon Callas wrote: > >> On Aug 29, 2016, at 5:44 AM, David McGrew (mcgrew) = >> wrote: >> >> Hi Peter, >> >> You make a bunch of good points. But it is also worth noting that = >> some people feel that current crypto standards, including IETF = >> standards, are suitable for IoT. See for instance slides 8 and 9 of = >> Daniel Shumow's talk at NIST=E2=80=99s LWC workshop last year: = >> http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4= -shumow.pdf = >> Also, CoAP isn=E2=80=99t on his list, but it could be, and it uses D= TLS. = >> So while I agree with you that overuse of a 64-bit block cipher is = >> far from the biggest security concern for IoT, the IETF should expect = >> its protocols to be used in some IoT scenarios. >> >> The malleability of the term IoT is causing trouble here. Slide 6 = >> of Daniel=E2=80=99s talk is quite revealing. To my thinking, by defin= ition = >> IoT devices are connected to the Internet in some way. > > Definitely. But to quote Shumow's talk on Slide 10 (which has the = > title "IoT Does Not Need Its Own Crypto Standards"): > > =E2=80=A2 Current cryptographic standards work for IoT > =E2=80=A2 Current standards are not a limit on IoT performance. > =E2=80=A2 Perspective: Common IoT platforms are approximately as > powerful as PCs from 15 years ago when AES was standardized. > > And on Slide 11: > > =E2=80=A2 Adding new standards can be problematic: > =E2=80=A2 New standards, especially with lower key sizes could be > used in scenarios where they aren=E2=80=99t intended. > > Example: Standardizing ECC over 160bit prime for an RFID > card and it ends up being used for https; block cipher > with 80bit key space ends up being used to encrypt hard > drives. > > His conclusion (slide 13) says that we don't need Lightweight Crypto = > in software, but admits there are some hardware places (like RFID) for = > it. > > And that gets to Peter's basic, good points. While Peter is being = > brash, his larger point is the same point as Shumow's, that we should = > just be using our existing toolbox and that even *that* has too many = > choices. The AllJoyn suite, which is the most stripped down, is = > brilliantly simple: RSA, ECDSA/ECDHE P256, and AES-CCM. You can = > quibble with it, but it's to the point. (My quibbles would be to toss = > RSA and Curve 41417 instead because it has an ARM NEON implementation = > that's as fast as P-160. But those are quibbles.) > > Folding back up to the subject here -- AES is faster than DES. That is = > one of the reasons it was selected as AES. (So are Twofish and = > Serpent.) We need to toss all 64-bit block ciphers. They were okay way = > back in the 1900s. It is no longer then. AES is cheap and getting = > cheaper. We don't need to patch up any of those old ciphers with = > meshing or what. We just need to use what's in our toolbox. 3DES needs = > to go solely because it's a patch on DES that needs to be patched for = > its small block size. I know it's boring to just use AES, but it meets = > all the goals. Yes. To a large extent, the "IoT devices are too puny for real crypto" = is a hangover from several years ago. It was once true; for the most = part, it isn't today, but people haven't flushed their cache from the = old received wisdom. It pays to look again at David Wagner's slides from 2005, on sensor nets = and crypto: https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf --Steve Bellovin, https://www.cs.columbia.edu/~smb From nobody Mon Aug 29 18:32:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0970E12B063 for ; Mon, 29 Aug 2016 18:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8577WiIBCYcI for ; Mon, 29 Aug 2016 18:32:05 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BC512B02F for ; Mon, 29 Aug 2016 18:32:04 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 52so2440863qtq.3 for ; Mon, 29 Aug 2016 18:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qBb/WbPCtjnAjNY0L+lrfvtMjbt7AVY9ZqbL3nZGZXw=; b=JLB0m0pwh7/mdmU9Pp4ru+S5T1Z5jUcECnDylUq/ukR9Pcw/x7Wxc9rOYS3Lht5Fvd vte/LCIZCgBu/fMJ+fOP9doUmnxIs9pcc8qgRqzUXNDvNjP+O0rbgWUFOKNjfzfGQIzG lxWaHUkA3v5mE5Pdgij/c5U3YMmLcnLWauTE+7VhlPWjeL9bNk2C13Tqz2CJ6FwPDxX8 T6TFBD50u6lpNf6XCV5sLWwPCd9TcXD/rrEU/NzQLiEFMqkStPeyW4+Pzs4VeeqFF62m x6SRoJ92nH0BFpe65tAytYKxumNngYV2zQV9VZcTb3sO3IRHDhDjq0RiTNzKPMtq455r Vcfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qBb/WbPCtjnAjNY0L+lrfvtMjbt7AVY9ZqbL3nZGZXw=; b=lb1HbnERZw/mu3Qoxk0En2hGUPQgjSbr7KhCFfSJo/eMNqrBfmB/oXgktGdOtgJXOL kYEJZTWeFmag3Kc5JCnwEOtmeIl0EEw0PWnk/GxbyLjgsLWm2igd+F3AsO5ylA28w0Tz ysw3gZoz4zcHkFYGpz7YOjZtziwoLu/ELLRAiwi7InekQmD+0qwtYo9Tar5+FvgB9Fsm 3cgrLyADubcmaZohua3M+ch1d8cQnGyRaTlvuDt3ODELi+anaM1k2m5J4t37P9hYm3wM lJh531jrBa1QP0S3CCUHGQSLrSc67ShcPee71Ls/PcEy1yWsa879euG0Utbx3ID5qfBb yL0Q== X-Gm-Message-State: AE9vXwPIrcKBp+7HDoEZfW2aJb3d7PnIbwkbays4Zm3nNZVQ7ECGD0q7EJVGWyCoOltGcA== X-Received: by 10.237.33.111 with SMTP id 102mr1226633qtc.56.1472520723952; Mon, 29 Aug 2016 18:32:03 -0700 (PDT) Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [174.112.186.144]) by smtp.gmail.com with ESMTPSA id m4sm20222969qkf.29.2016.08.29.18.32.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 18:32:03 -0700 (PDT) To: Jon Callas References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <57C43102.7090902@secworks.se> <8699AC5D-AD51-4287-A302-55CF9549A7FC@callas.org> From: Rene Struik Message-ID: <7f01301d-f96f-9b99-7841-e43b5a2d12ea@gmail.com> Date: Mon, 29 Aug 2016 21:31:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8699AC5D-AD51-4287-A302-55CF9549A7FC@callas.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "David McGrew \(mcgrew\)" , "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] (confusing the issues) Re: 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 01:32:06 -0000 My argument was aimed at focusing on the real topic at hand, not at mixing this with "religious" beliefs as ditching ciphers without clear justification (no matter how ancient 3-DES may be [I was in elementary school then]). I think it is unwise thinking too lightly about writing IETF drafts with "die-die-die" in the title, just because one feels like it, in an almost context-free manner. Or, is the idea to launch an entire series of die-die-die drafts, because one finds some excuse to do so? I cannot deny I also like shiny new things and we may all suffer from not-invented-here syndromes, but acknowledging this playing in the background of our perceptions should also give us some reason to pause and have some restraint here. Rene On 8/29/2016 5:48 PM, Jon Callas wrote: >> On Aug 29, 2016, at 6:26 AM, Rene Struik wrote: >> >> I think it is a mistake to think that simply using block ciphers with a larger block size is enough to counter attacks, as the literature on successful side channel attacks on such block cipher demonstrates. The real message is that one should not reuse keys ad infinitum, which unfortunately seems hard to sink in. >> >> Singling out 3-DES in this respect does not seem to tackle the real issue (which is a system security issue often only paid lip service to in practice). > Yes, we should just stop using 64-bit block ciphers and deal with the issues you mention within the context of larger blocks. > > Jon > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Mon Aug 29 22:15:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7078212D0C9 for ; Mon, 29 Aug 2016 22:15:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seer-grog.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HszPUw5inyrE for ; Mon, 29 Aug 2016 22:15:06 -0700 (PDT) Received: from homiemail-a75.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D3012B00B for ; Mon, 29 Aug 2016 22:15:06 -0700 (PDT) Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id C4AC65EC07F; Mon, 29 Aug 2016 22:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= seer-grog.net; bh=MfB3NY38M03RLbWndG8/S9Rc4m8=; b=24chl7vrpPfaZa w2ii+U8vQkj46sDL2OumlKLtn6jmao80I7BicCPw68CpTQvRVsdw0jn6osaI9Pus Qn6dCeCwSljct8m5kvG+4td4zM+lA26RY9PL3x4MDL4emFlARxWN+9nrUeIDcuVY H8btZM7zcT1m/OdfWP/gpIxqu6eSA= Received: from [10.0.1.5] (cpe-76-167-195-197.san.res.rr.com [76.167.195.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 961C55EC079; Mon, 29 Aug 2016 22:15:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Greg Rose In-Reply-To: <7f01301d-f96f-9b99-7841-e43b5a2d12ea@gmail.com> Date: Mon, 29 Aug 2016 22:15:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13E782F9-CAD4-4098-AE6F-3EDE7A0CD3CD@seer-grog.net> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <57C43102.7090902@secworks.se> <8699AC5D-AD51-4287-A302-55CF9549A7FC@callas.org> <7f01301d-f96f-9b99-7841-e43b5a2d12ea@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jon Callas , "cfrg@irtf.org" , Greg Rose , "David McGrew \(mcgrew\)" , "" Subject: Re: [TLS] [Cfrg] (confusing the issues) Re: 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 05:15:08 -0000 Rene, thanks for clarifying my thoughts on this. You're right, in one = sense, piling on on the bandwagon is often counterproductive. I'm = reminded of Dijkstra's article "goto statement considered harmful", in = 1968, which was cogent and important, but inspired any number of "XXX = considered harmful" statements that weren't ...=20 But, if you're writing in C (which I think we mostly shouldn't be any = more, but that's a different question), there's no practical alternative = to using goto! Check this, then check that, then check the other = thing... You can't maintain code that has this as one big "if" = statement, and you won't get it right if there are 18 layers of nested = "if" statements either. But back to the original question: In my job I had to continually face = the objection that "security [any form] was too expensive to implement". = My personal breakthrough was understanding the legal concept of "burden = of proof". Was it my job to prove that the security wasn't too = expensive? Or was it the (non-security) people's job, in the face of the = requirement for security (agreed by management), to prove that it WAS = too expensive? I could at least argue that measuring the answer was = cheaper than either (a) continuing to argue, or (b) implementing it. = Guess what the answer was? I believe that there's a place for 64-bit block ciphers, still. But I = believe that there's a corresponding requirement that the analysis be = done, and that provision for re-keying must be engineered in, before = they can be used. The alternative, just go to 128-bit blocks, is = sometimes cheaper, and sometimes easier, and sometimes both. But no = handwaving is required... do the analysis! Greg. > On Aug 29, 2016, at 18:31 , Rene Struik wrote: >=20 > My argument was aimed at focusing on the real topic at hand, not at = mixing this with "religious" beliefs as ditching ciphers without clear = justification (no matter how ancient 3-DES may be [I was in elementary = school then]). >=20 > I think it is unwise thinking too lightly about writing IETF drafts = with "die-die-die" in the title, just because one feels like it, in an = almost context-free manner. Or, is the idea to launch an entire series = of die-die-die drafts, because one finds some excuse to do so? I cannot = deny I also like shiny new things and we may all suffer from = not-invented-here syndromes, but acknowledging this playing in the = background of our perceptions should also give us some reason to pause = and have some restraint here. >=20 > Rene >=20 > On 8/29/2016 5:48 PM, Jon Callas wrote: >>> On Aug 29, 2016, at 6:26 AM, Rene Struik = wrote: >>>=20 >>> I think it is a mistake to think that simply using block ciphers = with a larger block size is enough to counter attacks, as the literature = on successful side channel attacks on such block cipher demonstrates. = The real message is that one should not reuse keys ad infinitum, which = unfortunately seems hard to sink in. >>>=20 >>> Singling out 3-DES in this respect does not seem to tackle the real = issue (which is a system security issue often only paid lip service to = in practice). >> Yes, we should just stop using 64-bit block ciphers and deal with the = issues you mention within the context of larger blocks. >>=20 >> Jon >>=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg Phone: +1 619 890 8236=20 GPG/PGP: 1081A37C 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C From nobody Tue Aug 30 02:41:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89FC12B02C for ; Tue, 30 Aug 2016 02:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9cJbBdw_pYF for ; Tue, 30 Aug 2016 02:41:42 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFFC12B024 for ; Tue, 30 Aug 2016 02:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472550102; x=1504086102; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8eJWKD/kJz+55GDSJ6UGR11LkR9Nofyo3urfHwh9s3Q=; b=svOyMIxHe39PB+PZAyCEVyCxwxQaF/qihyJoKms9FW+heUAyo7fw5jTd 9My1bKt6vsoNC9/bnKdwjVCem6mNZSUVBjxahcEUgt9bduqei0x2FOVkx /cwUinXjfumRl3dREFWy7nQjwXSGrDddNFn+iv5z/KLZxiDcF/bVuVEDJ TGwuwxH9ma9oGv7/mJiWoDOGPLX39sHkSQIkavH0ijdNiXx5MBQE52Oka jSEElb1GO98eZnVJJD7jcVFqq+25Qhjj71muFmijzOjlEfIPLUOdnsign Y75ZqyVguGr3lvn71ID5HrXM0SgtmoDqnxzG2QsBJkO8Z/PHnuDHn4xkm g==; X-IronPort-AV: E=Sophos;i="5.30,255,1470657600"; d="scan'208";a="104041592" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Aug 2016 21:41:37 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Tue, 30 Aug 2016 21:41:37 +1200 From: Peter Gutmann To: "David McGrew (mcgrew)" , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1//9AtgCAAkz7eYAA1VQAgAImRw0= Date: Tue, 30 Aug 2016 09:41:36 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D073D4@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz>, <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> In-Reply-To: <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 09:41:46 -0000 David McGrew (mcgrew) writes:=0A= =0A= >See for instance slides 8 and 9 of Daniel Shumow's talk at NIST=92s LWC=0A= >workshop last year:=0A= >http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shu= mow.pdf=0A= =0A= So looking at slide 6 from that, the first four systems he lists are deskto= p=0A= PCs (in all but form factor), it's only the last two that are down at the= =0A= resource levels of IoT. I'm not sure why he picked the Arduinos there beca= use=0A= I wouldn't really consider them terribly representative of IoT devices, was= it=0A= to get something that people are familiar with? Even if you're wanting to= =0A= restrict yourself to well-known complete systems I think at least an ESP826= 6=0A= (80Mhz SoC with 96K RAM, 64K flash, no multiply or divide by default) shoul= d=0A= get a mention.=0A= =0A= Slide 9 is even further removed from IoT practicality, that stuff may be fi= ne=0A= on the PC-equivalents but won't work on real IoT gear.=0A= =0A= I'm currently working with some embedded systems guys to come up with a lis= t=0A= of requirements for IoT crypto (as with the TLS-LTS stuff, various IP/legal= =0A= issues means many contributors don't want to say anything in public), I'll= =0A= post it to the list when we've finished arguing :-).=0A= =0A= Peter.= From nobody Tue Aug 30 02:50:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245BE12D0BB for ; Tue, 30 Aug 2016 02:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQxPZTMYjYTa for ; Tue, 30 Aug 2016 02:50:48 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827B712B00F for ; Tue, 30 Aug 2016 02:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472550647; x=1504086647; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cpgaarezaVIKF4dyg3lHDhKQPtmva+qxtRxR0/y9X/E=; b=1CMl0tFvcR+YJAjVq4MpNJDE78ax/zB2DTO3CWivgQ+zur3ElNNFWq8z 4HXzNunbChZ6a7R+zTYYqnKNWgjek10uULiMVaXfBx4jGjcW/ruW3Alca /yWw1putb4hjqa9YhUD01bU01k8SyBOsD9DoG1iMSqG5k6qS1oP4xWFbM 42qjOzhdOyvpOX6sD0JMJKZ554Z4EeAEvMhC+pSi42W6WCPCXAJC8/uau vmNyarKOE1/DqQeFA4NCunb7aZRiDkQpJuepHIH/dZM+y6JJqL+KubU8P X9w7asLXdDIEPjiyfEUixjHX76KcEI9Qtciqqk1waMgxygkz4qXVoeK4K A==; X-IronPort-AV: E=Sophos;i="5.30,255,1470657600"; d="scan'208";a="104042073" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Aug 2016 21:50:45 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 30 Aug 2016 21:50:45 +1200 From: Peter Gutmann To: Jon Callas , "David McGrew (mcgrew)" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1//9AtgCAAkz7eYAA1VQAgACXdYCAAZM+DQ== Date: Tue, 30 Aug 2016 09:50:44 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D0741F@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com>, <89A46793-73A1-4C71-9954-37BF6ED6F297@callas.org> In-Reply-To: <89A46793-73A1-4C71-9954-37BF6ED6F297@callas.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cfrg@irtf.org" , "" Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 09:50:49 -0000 Jon Callas writes:=0A= =0A= >Current cryptographic standards work for IoT=0A= =0A= That's only if you use the circular argument that IoT is defined to be=0A= whatever can run DTLS (or whatever you take as "current cryptographic=0A= standards", the slides mention DTLS). An yeah, I can then define my IoT to= be=0A= "whatever can't run DTLS" :-). Stand by for a requirements list coming fro= m a=0A= bunch of IoT/embedded people...=0A= =0A= Peter.= From nobody Tue Aug 30 04:25:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C27312D19F for ; Tue, 30 Aug 2016 04:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u3y98qB58FU for ; Tue, 30 Aug 2016 04:25:22 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8214012D0BB for ; Tue, 30 Aug 2016 04:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1472556322; x=1473765922; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LCJGLaDi2hGPZ3qrtnSarQHNJWqcAhMQDB4/jZHNgrI=; b=A9fNCOgjYfAsGjiOSNVU91Qt9T3lPjbKkS64qomh54+fTUxrJGxJtyrv 2elGQrtUdscsgaEF3zZmHPIKj9YBK82Jelpg2EPX4afsOOhqKvFPBeQIt uAVYO9Cxy0599oE3ej0O9RN63Ba7EGDLcIcTq8FonVvtwoTQ8c5OBHCMd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/BgADbMVX/5hdJa1cDoM/AQEBAQEeV?= =?us-ascii?q?3wHg0C0ZoIBJoV3AhyBRzoSAQIBAQEBAQEBXieEYgEDAiMRVQIBCA4MAiYCAgI?= =?us-ascii?q?wFRACBAESiEQOrlyPPwEBAQEBAQEBAQEBAQEBAQEBAQEBHYEDhyOCVYIQhTIrg?= =?us-ascii?q?i8Fk3SFXAGGH4kOgjuIQIRckEABJQcog3U7cAGGFn8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,256,1470700800"; d="scan'208";a="317189754" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2016 11:25:21 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7UBPLwl027335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Aug 2016 11:25:21 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 Aug 2016 06:25:20 -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.1210.000; Tue, 30 Aug 2016 06:25:20 -0500 From: "David McGrew (mcgrew)" To: Peter Gutmann , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/nWfoW+SS6smqUOyCtdxrLUgKaBbmdgAgAF4CoD//8XhAIABxwsAgAFbRACAAaI6AP//2e4A Date: Tue, 30 Aug 2016 11:25:20 +0000 Message-ID: <7C844B58-5B3E-4A47-AA67-471C50620323@cisco.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <9A043F3CF02CD34C8E74AC1594475C73F4D073D4@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D073D4@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.10.229] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 11:25:25 -0000 SGkgUGV0ZXIsDQoNCg0KDQpPbiA4LzMwLzE2LCA1OjQxIEFNLCAiUGV0ZXIgR3V0bWFubiIgPHBn dXQwMDFAY3MuYXVja2xhbmQuYWMubno+IHdyb3RlOg0KDQo+RGF2aWQgTWNHcmV3IChtY2dyZXcp IDxtY2dyZXdAY2lzY28uY29tPiB3cml0ZXM6DQo+DQo+PlNlZSBmb3IgaW5zdGFuY2Ugc2xpZGVz IDggYW5kIDkgb2YgRGFuaWVsIFNodW1vdydzIHRhbGsgYXQgTklTVOKAmXMgTFdDDQo+Pndvcmtz aG9wIGxhc3QgeWVhcjoNCj4+aHR0cDovL2NzcmMubmlzdC5nb3YvZ3JvdXBzL1NUL2x3Yy13b3Jr c2hvcDIwMTUvcHJlc2VudGF0aW9ucy9zZXNzaW9uNC1zaHVtb3cucGRmDQo+DQo+U28gbG9va2lu ZyBhdCBzbGlkZSA2IGZyb20gdGhhdCwgdGhlIGZpcnN0IGZvdXIgc3lzdGVtcyBoZSBsaXN0cyBh cmUgZGVza3RvcA0KPlBDcyAoaW4gYWxsIGJ1dCBmb3JtIGZhY3RvciksIGl0J3Mgb25seSB0aGUg bGFzdCB0d28gdGhhdCBhcmUgZG93biBhdCB0aGUNCj5yZXNvdXJjZSBsZXZlbHMgb2YgSW9ULiAg SSdtIG5vdCBzdXJlIHdoeSBoZSBwaWNrZWQgdGhlIEFyZHVpbm9zIHRoZXJlIGJlY2F1c2UNCj5J IHdvdWxkbid0IHJlYWxseSBjb25zaWRlciB0aGVtIHRlcnJpYmx5IHJlcHJlc2VudGF0aXZlIG9m IElvVCBkZXZpY2VzLCB3YXMgaXQNCj50byBnZXQgc29tZXRoaW5nIHRoYXQgcGVvcGxlIGFyZSBm YW1pbGlhciB3aXRoPyAgRXZlbiBpZiB5b3UncmUgd2FudGluZyB0bw0KPnJlc3RyaWN0IHlvdXJz ZWxmIHRvIHdlbGwta25vd24gY29tcGxldGUgc3lzdGVtcyBJIHRoaW5rIGF0IGxlYXN0IGFuIEVT UDgyNjYNCj4oODBNaHogU29DIHdpdGggOTZLIFJBTSwgNjRLIGZsYXNoLCBubyBtdWx0aXBseSBv ciBkaXZpZGUgYnkgZGVmYXVsdCkgc2hvdWxkDQo+Z2V0IGEgbWVudGlvbi4NCj4NCj5TbGlkZSA5 IGlzIGV2ZW4gZnVydGhlciByZW1vdmVkIGZyb20gSW9UIHByYWN0aWNhbGl0eSwgdGhhdCBzdHVm ZiBtYXkgYmUgZmluZQ0KPm9uIHRoZSBQQy1lcXVpdmFsZW50cyBidXQgd29uJ3Qgd29yayBvbiBy ZWFsIElvVCBnZWFyLg0KPg0KPkknbSBjdXJyZW50bHkgd29ya2luZyB3aXRoIHNvbWUgZW1iZWRk ZWQgc3lzdGVtcyBndXlzIHRvIGNvbWUgdXAgd2l0aCBhIGxpc3QNCj5vZiByZXF1aXJlbWVudHMg Zm9yIElvVCBjcnlwdG8gKGFzIHdpdGggdGhlIFRMUy1MVFMgc3R1ZmYsIHZhcmlvdXMgSVAvbGVn YWwNCj5pc3N1ZXMgbWVhbnMgbWFueSBjb250cmlidXRvcnMgZG9uJ3Qgd2FudCB0byBzYXkgYW55 dGhpbmcgaW4gcHVibGljKSwgSSdsbA0KPnBvc3QgaXQgdG8gdGhlIGxpc3Qgd2hlbiB3ZSd2ZSBm aW5pc2hlZCBhcmd1aW5nIDotKS4NCj4NCj5QZXRlci4NCg0KVGhhdOKAmXMgZ3JlYXQsIGZhY3Rz IGxlYXZlbiBhIGRlYmF0ZS4NCg0KdGhhbmtzDQoNCkRhdmlkIA0K From nobody Tue Aug 30 11:19:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9073212D7AB for ; Tue, 30 Aug 2016 11:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTmNdQtR2LbT for ; Tue, 30 Aug 2016 11:19:36 -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 8A70312D7A7 for ; Tue, 30 Aug 2016 11:19:36 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id t7so27410306qkh.1 for ; Tue, 30 Aug 2016 11:19: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:mime-version :content-transfer-encoding:message-id; bh=pjZzg7aiZe+dKyXaQtDsnEidFWJ0g1AEj6ToX+tsbms=; b=R+ANcAYDIDmqqgJ72uGFizH8t1iCxA445459rPYwtaGfEkuots1rcm5ka4atNHmyH6 dZ3CwI0aATAwnvhDNA3VCtOfE4TieuIVVPTRVBaFBdz4T1qwuRGxUfcHjryBsdw/3bAt SyyRbiNksdqBzAhDpG9+J7EMVsKFUWVMdb3H2aY3GZmH6qEriIErvGx+hYSbSkmDDyDF lqISIm1JyIL4JUOKbx3BDxzkesPlxaS9d3mSRW45ct1/YVJQyfi9xkHto7Ovd3bLrU0V ONygRcveCv1XcxWDR7t/z4aiK412NCWhoi5JXSkNmOiT/Cdlyc6d4CacfTVzgxoEAVil n09A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:mime-version :content-transfer-encoding:message-id; bh=pjZzg7aiZe+dKyXaQtDsnEidFWJ0g1AEj6ToX+tsbms=; b=fdwTFEvnXtWhCtwNs/jUCx8EJK5qytQT5TI6mEfJFeaL43GaSNbPV9D7w7yW7MOpPu KMpCt7lxogtyQjcAKyu6QbFu1KYFcxCXROSKtOr5g1XOSCqIp4kB2G9t0tvKa989lytb OH/cbCdZn5PveEKCN0CzuMOlf/cZkEgfdsqQTvvjNqFbtt9/Am/WON7tTnBxjgJqDy3c iolZe2mL+lsEvDhYjgErIdqx2r9ILSU/QhkEkZ1Gy2C4wcLlROMqWrf6ITV5yWyiI/3E jotj1uaFYb7THpfYDnwifJlCdFoiM8gc53OUPuWaHsIxuAAZQ5SgPopUP+KBO17wxA3c RKyg== X-Gm-Message-State: AE9vXwMIBs6vSdu5Eng51eXqnxIeIo0q8ssmMNSrstPJ49dSxXhslRgMSvCYMcRoX/wQMA== X-Received: by 10.55.163.18 with SMTP id m18mr4506978qke.40.1472581175307; Tue, 30 Aug 2016 11:19:35 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id x201sm1071532qkx.32.2016.08.30.11.19.34 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 30 Aug 2016 11:19:34 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 30 Aug 2016 14:19:33 -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: <201608301419.33620.davemgarrett@gmail.com> Archived-At: Subject: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 18:19:37 -0000 I occasionally see people ask why we're calling it TLS 1.3 when so much has changed, and I used to simply think that it was too bikesheddy to bother changing at this point. However, now that we've redone negotiation, we have new TLS 1.3+ only cipher suites. The old are not compatible with the new (new codepoints needed for old ciphers) and the new are not backwards compatible with the old (they'll just be ignored). We actually risk misconfiguration in the future if the distinction isn't made clear. I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a major version seems more appropriate. Note that contrary to what some people seem to think, version numbers are not completely without meaning. To someone who doesn't really know/care that much what TLS is, making sure to use the latest major version of a security protocol carries more weight than a minor version. It also makes it clear that there are new features here (e.g. 0-RTT). There's some de facto standardization in versioning which does carry some useful information. We're not just dealing with programmers here; this stuff needs to be clear for managers and non-professionals. If we want to get everyone upgraded eventually, messaging is important. Specific proposed changes: * Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2) * Keep the version ID as { 3, 4 } (already weird counting; changing risks more intolerance) * Rename the new cipher suites to have a "TLS2_" prefix to be less confusing for the registry & end configuration * Add a sentence noting the development history here, and that all documents that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2) This is a relatively simple set of changes to make that I think can be beneficial in the long run, and is essentially just editorial. Rebranding might not be something everyone really wants to bother with, but if we expect this to be in use for a decade or more (whether we like it or not), we should probably make sure to be as clear as possible at the start. Dave From nobody Tue Aug 30 11:33:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3812D7C5 for ; Tue, 30 Aug 2016 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IncmttEALg7K for ; Tue, 30 Aug 2016 11:33:11 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0117.outbound.protection.outlook.com [104.47.38.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CD212D7BC for ; Tue, 30 Aug 2016 11:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P1mmn+4HfSjyXvQb2VYSWBv8vUtte1tDOE6d3KNZv98=; b=BJbbiGZGzWM798yfO1ZCze/tSUgh73a+e8A5JdPBeVqZuQ8YvCsOb/nH2zHrQpAS3PjYsqMNz5n9ndAEHOWZcRJ2P7K3D/3U6ld4ud0Czxcl4vdDI8Cs4fFUQcDgW1AJcmXBlrGarRQIstUSoT7KY9kTMOiI36GkHqoyNEy/qRo= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Tue, 30 Aug 2016 18:33:07 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 18:33:07 +0000 From: Andrei Popov To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 -> TLS 2.0? Thread-Index: AQHSAusYjJy9RihUK02VuirsRGaRIKBh0wSg Date: Tue, 30 Aug 2016 18:33:05 +0000 Message-ID: References: <201608301419.33620.davemgarrett@gmail.com> In-Reply-To: <201608301419.33620.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 13ea3ae4-a800-4a38-c7b1-08d3d104163c x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:uok8E64kBmyP5LyKcQfesok0FrLSByyWer0MgFRNKFMctPKSTTVMQS4+HPKnoJVTXmW6W3s1KyeKaDme8SpcimwdqNSuq25VEE9anYwbTRthYJrEFa1Ge6oRyk4AEfDQiFqJhR7188eqnJe4Ms8rCU+IngvDtGG1LY8Y4FWsXAINew37qH9nB+ynxdLtod6Qcd9Wf+KKRDV3Kr1We9wjMxfbe7/kPfc7qhGk5hFGYyj5QiPcGNcr0A7yQELuGMCnvcT0msUmxedEVHybTxoEXPll7MZkLlG+cT+6BdIGNEjNx/v3Ldr4GAX69zvFqe/2VjOmqEBjmdUzWxrwaAFo1Q==; 5:HTrFwd/UnUhdgE/rh3KMmPAMVP90yt4SQfbx5IlR/iAxk7X4eVgRkeyYwTgVzhVGQ30jAJfADFa1w2f5gTiO+GPPg2MXb9dV0NE9eS+/x6gQ8cWlTKKTa/UiDdTVu8ZOaSiZYF13rNfujMARjl8OrA==; 24:3xQaMM9iRBjit/F58z0vJuPHfEeYU2cN9sFT9zP0rVnz0zFFG4sJQg9OpO/izLemSrj99eMmAd5oLG9YGK4t4dq2xG8wc6BDOOiry8OJkYw=; 7:ONcQFvn+I3OGJW0Srxnarm93eqnh5GSuoJ5hceYKXHKdOJj91KanPhOtqfu+lp49+8uYloDAsmZzcl19szS/W9q/DmG6NKhVW+1WTQSnKEcvj6UpmlG12wb5j0AnlJ10XLV+sb+vyGGTVR9olzrPrSdu79bYlbmLhU9mrIZtRBgex1Y2kg+x+WTBW1mCsHv46PFW85TFoklaej4Hvs9CZWgnyD1A+GdGpIeSwXDu6TyQDR+I21TYlLtMhEYeXSRM x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(199003)(189002)(5002640100001)(76576001)(122556002)(6116002)(77096005)(86362001)(15975445007)(102836003)(2501003)(5660300001)(107886002)(106356001)(5001770100001)(586003)(3280700002)(19580405001)(2906002)(97736004)(189998001)(2950100001)(92566002)(8936002)(2900100001)(19580395003)(5005710100001)(105586002)(87936001)(86612001)(10290500002)(33656002)(50986999)(101416001)(106116001)(8990500004)(7846002)(54356999)(305945005)(74316002)(10400500002)(76176999)(7696003)(9686002)(7736002)(10090500001)(3660700001)(68736007)(81156014)(99286002)(8676002)(81166006)(11100500001)(561944003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 18:33:05.5384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 18:33:12 -0000 This proposal makes a lot of sense to me. I've had numerous conversations e= xplaining to folks that TLS 1.3 is really TLS 2.0. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dave Garrett Sent: Tuesday, August 30, 2016 11:20 AM To: tls@ietf.org Subject: [TLS] TLS 1.3 -> TLS 2.0? I occasionally see people ask why we're calling it TLS 1.3 when so much has= changed, and I used to simply think that it was too bikesheddy to bother c= hanging at this point. However, now that we've redone negotiation, we have = new TLS 1.3+ only cipher suites. The old are not compatible with the new (n= ew codepoints needed for old ciphers) and the new are not backwards compati= ble with the old (they'll just be ignored). We actually risk misconfigurati= on in the future if the distinction isn't made clear. I think it's time we = just renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a = major version seems more appropriate. Note that contrary to what some people seem to think, version numbers are n= ot completely without meaning. To someone who doesn't really know/care that= much what TLS is, making sure to use the latest major version of a securit= y protocol carries more weight than a minor version. It also makes it clear= that there are new features here (e.g. 0-RTT). There's some de facto stand= ardization in versioning which does carry some useful information. We're no= t just dealing with programmers here; this stuff needs to be clear for mana= gers and non-professionals. If we want to get everyone upgraded eventually,= messaging is important. Specific proposed changes: * Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2) * Keep the version ID as { 3, 4 } (already weird counting; changing risks m= ore intolerance) * Rename the new cipher suites to have a "TLS2_" prefix to be less confusin= g for the registry & end configuration * Add a sentence noting the development history here, and that all document= s that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2) This is a relatively simple set of changes to make that I think can be bene= ficial in the long run, and is essentially just editorial. Rebranding might= not be something everyone really wants to bother with, but if we expect th= is to be in use for a decade or more (whether we like it or not), we should= probably make sure to be as clear as possible at the start. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Aug 30 11:36:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715EC12D606 for ; Tue, 30 Aug 2016 11:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.507 X-Spam-Level: * X-Spam-Status: No, score=1.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmJgqo7K-056 for ; Tue, 30 Aug 2016 11:36:54 -0700 (PDT) Received: from COL004-OMC4S2.hotmail.com (col004-omc4s2.hotmail.com [65.55.34.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25D112D763 for ; Tue, 30 Aug 2016 11:36:53 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com ([65.55.34.200]) by COL004-OMC4S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 30 Aug 2016 11:36:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ntZmCOg+FTMBy/GMX2iFSNeOrDb3VBvIrcmcHP4T0qE=; b=AcXKj5AXmHPlgzLImSpSh30bOQRtkdDcHx7frDa4uvrchg5TFih477us4wlc7XCcq85QkJQNi4ew1fZD6UZyaIAytR1c4Y3/gcKxfMGUbADAhZNB0qrR5bQy4w90ssb5ekD8JHE2E/CO0QvyZuXd+YykFJJO6BaBt5NNh9Kgf1cl8boYMe46dMH4/DfNoQAefYZ2bTybJ94y9xCKD6Pz2dKyn2v7ubWLkkhqN5DgId1CDfrhjQ5dJfEYiOssMuBL5KxDIcKNkha6bbYp+MQ2Riah6MNPT/R+JNJmkZETw46XfSyUMhJ+KQa4tmVj11FhA39DAH3047lLe3TSNIFCZg== Received: from CO1NAM03FT012.eop-NAM03.prod.protection.outlook.com (10.152.80.55) by CO1NAM03HT177.eop-NAM03.prod.protection.outlook.com (10.152.81.156) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Tue, 30 Aug 2016 18:36:52 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.80.52) by CO1NAM03FT012.mail.protection.outlook.com (10.152.80.99) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.6 via Frontend Transport; Tue, 30 Aug 2016 18:36:52 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0587.013; Tue, 30 Aug 2016 18:36:51 +0000 From: Xiaoyin Liu To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 -> TLS 2.0? Thread-Index: AQHSAusWOU//EHg9i0ibaRgnTsxODaBh1RpW Date: Tue, 30 Aug 2016 18:36:51 +0000 Message-ID: References: <201608301419.33620.davemgarrett@gmail.com> In-Reply-To: <201608301419.33620.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.80.52) smtp.mailfrom=outlook.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.80.52 as permitted sender) x-incomingtopheadermarker: TopHeader x-tmn: [q4SH6q6LCPnkuJVB1gfMiK5h71zXHqHt] x-incomingheadercount: 38 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.80.52; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM03HT177; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; CO1NAM03HT177; 6:3SJbGQTWcBNIN2N3GigIBiVLQkBMuqLg7Im7pWiPMBg75HcvhLcCsxmNdRqXBKKEv9C/RJZc8tYXskK1U+tyFh9ioJd9DFpcWVNaWTUh+sxM0Jbrkb/EpPeW7638BMPQIIDQ6EfaLoRcK+4bB5yA+N1poiHpaD51Xafybrp3eIOkuidUPYeqeZc3NsT9mLd7tuAOg6J6UeauC9ufQR7tN2wf0Q19/biU3NAXmseOxxuei60MXPfv17XIPpMmCV74A9O+e9aBpTFUX+oCyJ920bYAtk7pSV4/nQzfhoD9qfCvrJRJJBWLZ3/wh6uJ91No; 5:Je7LVY0whrzpCSziNHbdVA9eLDa/vxa9aOYAs7PEhZuUOZqWvKRlP7pDmQkTrLy4yNPJZskdEQRC382prPnqUtpDS+pFKpwBbwq0cDYr/MvBVwkhw0qh6OvYgv2XQktsbZaq9WNvUSaqicyA5/MsUA==; 24:YTQlt8MvmpavvI1ZqYgAngo7ULUs9zcQJorV3rV9ZCVF7OuKXWF8LD6I4bU7FaaO05T7ahc3GoXADRkrXuM2Kenu2JkpxAI4T5mr257d3Rg=; 7:qVDSIfFRZCAGG7P6My7ADDWLNanHZV9kGK5mkGQuzy8uuISm5xHxt5PTaG8J9oDaZp5LkfxW3+MlMeoFr0b2khrRHqavvdmnnYT9aYk5F3DEuA6Hc/dNsYRj+edL2XHFqnTb66h4/vvPxLRiCeGuOFeTNvL4IDjNJv/fIafohK2xv/hhNjh3z85IVmdma/G17b6TPw4fJpOAtCMNsurvIyw3h7xJNOZ7+x7FqqVWaVJNtzYVT4iGjpgpVSCVj3QO x-ms-office365-filtering-correlation-id: 0936db3f-f9f9-40f6-c634-08d3d1049bc1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1601125047); SRVR:CO1NAM03HT177; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CO1NAM03HT177; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM03HT177; x-forefront-prvs: 0050CEFE70 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB077803AB565FB6CD20098CEAFFE00CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 18:36:51.2013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT177 X-OriginalArrivalTime: 30 Aug 2016 18:36:53.0547 (UTC) FILETIME=[7AA787B0:01D202ED] Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 18:36:55 -0000 --_000_CY1PR15MB077803AB565FB6CD20098CEAFFE00CY1PR15MB0778namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this change as long as there is no technical change (version ID r= emains 0x0304). Best, Xiaoyin From: Dave Garrett Sent: Tuesday, August 30, 2016 2:19 PM To: tls@ietf.org Subject: [TLS] TLS 1.3 -> TLS 2.0? I occasionally see people ask why we're calling it TLS 1.3 when so much has= changed, and I used to simply think that it was too bikesheddy to bother c= hanging at this point. However, now that we've redone negotiation, we have = new TLS 1.3+ only cipher suites. The old are not compatible with the new (n= ew codepoints needed for old ciphers) and the new are not backwards compati= ble with the old (they'll just be ignored). We actually risk misconfigurati= on in the future if the distinction isn't made clear. I think it's time we = just renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a = major version seems more appropriate. Note that contrary to what some people seem to think, version numbers are n= ot completely without meaning. To someone who doesn't really know/care that= much what TLS is, making sure to use the latest major version of a securit= y protocol carries more weight than a minor version. It also makes it clear= that there are new features here (e.g. 0-RTT). There's some de facto stand= ardization in versioning which does carry some useful information. We're no= t just dealing with programmers here; this stuff needs to be clear for mana= gers and non-professionals. If we want to get everyone upgraded eventually,= messaging is important. Specific proposed changes: * Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2) * Keep the version ID as { 3, 4 } (already weird counting; changing risks m= ore intolerance) * Rename the new cipher suites to have a "TLS2_" prefix to be less confusin= g for the registry & end configuration * Add a sentence noting the development history here, and that all document= s that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2) This is a relatively simple set of changes to make that I think can be bene= ficial in the long run, and is essentially just editorial. Rebranding might= not be something everyone really wants to bother with, but if we expect th= is to be in use for a decade or more (whether we like it or not), we should= probably make sure to be as clear as possible at the start. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CY1PR15MB077803AB565FB6CD20098CEAFFE00CY1PR15MB0778namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this change as long as there is no techn= ical change (version ID remains 0x0304).

 

Best,

Xiaoyin

From: Dave Garrett
Sent: Tuesday, August 30, 2016 2:19 PM
To: tls@ietf.org
Subject: [TLS] TLS 1.3 -> TLS 2.0?

 

I occasionally see people ask why we're calling it= TLS 1.3 when so much has changed, and I used to simply think that it was t= oo bikesheddy to bother changing at this point. However, now that we've red= one negotiation, we have new TLS 1.3+ only cipher suites. The old are not compatible with the new (new codepoint= s needed for old ciphers) and the new are not backwards compatible with the= old (they'll just be ignored). We actually risk misconfiguration in the fu= ture if the distinction isn't made clear. I think it's time we just renamed TLS 1.3 to TLS 2.0. There are maj= or changes, so labeling it a major version seems more appropriate.

Note that contrary to what some people seem to think, version numbers are n= ot completely without meaning. To someone who doesn't really know/care that= much what TLS is, making sure to use the latest major version of a securit= y protocol carries more weight than a minor version. It also makes it clear that there are new features here (= e.g. 0-RTT). There's some de facto standardization in versioning which does= carry some useful information. We're not just dealing with programmers her= e; this stuff needs to be clear for managers and non-professionals. If we want to get everyone upgraded ev= entually, messaging is important.

Specific proposed changes:
* Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2)
* Keep the version ID as { 3, 4 } (already weird counting; changing risks m= ore intolerance)
* Rename the new cipher suites to have a "TLS2_" prefix to be les= s confusing for the registry & end configuration
* Add a sentence noting the development history here, and that all document= s that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2)

This is a relatively simple set of changes to make that I think can be bene= ficial in the long run, and is essentially just editorial. Rebranding might= not be something everyone really wants to bother with, but if we expect th= is to be in use for a decade or more (whether we like it or not), we should probably make sure to be as cl= ear as possible at the start.


Dave

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
 --_000_CY1PR15MB077803AB565FB6CD20098CEAFFE00CY1PR15MB0778namp_-- From nobody Tue Aug 30 12:35:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8A712D7F4 for ; Tue, 30 Aug 2016 12:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt8QLGOjgdG4 for ; Tue, 30 Aug 2016 12:35:31 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C576512D7E2 for ; Tue, 30 Aug 2016 12:29:51 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id l2so29469807qkf.3 for ; Tue, 30 Aug 2016 12:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=SqIWAyRYicdY74vSavv90R6V0VF4N/QRt46Jo00pnZI=; b=C0CyRXC1CYwHe+O6xpgWVOeipS1FkXv96z1NrnI2N6YfdiKIPxM7wXqGrqv5ZN9mIK RDD0vrq+VsQmgxFc0IY88J0uiC9ZYL52SQUYv/rmwzJdsg+4KGSZcm3KE+k9Gel8j/5b odpGqPjlzAecn1yN2zw/I0RPyYMNd98yXyhXG+Tf60yNSYDnKjA2UyuNjEGtn+t0YBg7 Zh+LDlBFpXmFvJWqJ1iK8jWaYNZpaevR9Xkvbpkr0IZVjGZmVnrETZ11ug3Zsal8ZYI2 vIpVH8FBfTj71SoHDNe7I2s4XNULeX3jieF8bKI4lVYOIj67pHBRemyfrBjA/StB8hkN jMSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=SqIWAyRYicdY74vSavv90R6V0VF4N/QRt46Jo00pnZI=; b=L/95D+DnETRcX8Z754CXZrYT9L+u62l/AXwaNp+q+NjEPOgRBBG74ftVj+HosopnV4 nO8WTkKYl6ZFpKpt4FitmBWMOc8XzLwL/5rKw1PcwmH1bN7HOek/VP+OvAcW8SH7JNZb 93+bceOolr93LeWb/GjpNMYxD3FOKX1og2hnwRx6T65n73wVX84D5wjW7vRFGk9kVyAn V2DXO/hCXxXqdYCkphbHXGx2AtmRePbR5Af/9+HR2b0fHuNKGR2a331J/NZKzkSmoKEW Q7VkPVpwlNa1vyJdmQ3nMhmflabmZNhFRVLL2APH6PiFeLmWdW4+QI3B0jq+Y7XnPIfs QFzw== X-Gm-Message-State: AE9vXwMhiVpXtFkVNkZvCxSRctL1aq8EQugcjG90uhyBiPooMQaJHe0rs5KYrZOMHCen3g== X-Received: by 10.55.25.40 with SMTP id k40mr6642880qkh.230.1472585391012; Tue, 30 Aug 2016 12:29:51 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id n55sm10095581qtb.11.2016.08.30.12.29.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 30 Aug 2016 12:29:50 -0700 (PDT) From: Dave Garrett To: Xiaoyin Liu Date: Tue, 30 Aug 2016 15:29:49 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201608301419.33620.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201608301529.49488.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 19:35:33 -0000 On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote: > I support this change as long as there is no technical change (version ID remains 0x0304). To reiterate, I am also against changing the version ID. However, I do think it's worth updating the context string version number, otherwise it'd be a little unnecessarily confusing there. (trivial change to key derivation, but not wire format) I've also made a point to tweak references to the on-the-wire version value to refer to it as a "version ID" rather than just version, to make it very clear that this is really just an arbitrary codepoint and shouldn't be read as 3.4. I've made the changes for a WIP branch, here (not a PR, as of yet): https://github.com/tlswg/tls13-spec/compare/master...davegarrett:tls2rebranding Going through the motions of doing the renaming now is useful to see if there's anything that is more affected than initially expected, such as the context strings having the version in there directly as a string (they're designed to be updated as-needed, so this shouldn't be a problem). Dave From nobody Tue Aug 30 13:14:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CEA12D7F6 for ; Tue, 30 Aug 2016 13:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.964 X-Spam-Level: X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXh0Zp911OEy for ; Tue, 30 Aug 2016 13:14:18 -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 E0FD612D818 for ; Tue, 30 Aug 2016 13:14:18 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3D8D9BAEE; Tue, 30 Aug 2016 20:14:18 +0000 (UTC) Received: from pintsize.usersys.redhat.com (vpn1-4-252.ams2.redhat.com [10.36.4.252]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7UKEGPl027177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2016 16:14:17 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 30 Aug 2016 22:14:06 +0200 Message-ID: <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; ) In-Reply-To: <201608301419.33620.davemgarrett@gmail.com> References: <201608301419.33620.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1747182.j4EHdBP6Dl"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 30 Aug 2016 20:14:18 +0000 (UTC) Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 20:14:20 -0000 --nextPart1747182.j4EHdBP6Dl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: > * Keep the version ID as { 3, 4 } (already weird counting; changing risks > more intolerance)=20 IMNSHO this alone is enough of a reason not to do this it's enough explaining to people that SSLv3.3 is really TLSv1.2, now we'll= =20 have SSLv3.4 =3D=3D TLSv1.3 =3D=3D TLSv2.0 it's silly at this point =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1747182.j4EHdBP6Dl 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 iQIcBAABCgAGBQJXxekOAAoJEJKo0bgB0vX1NbEP/ixd/CuAQmx9cJ0yJfaMwqXa Afz34nHjpue/Lf5rD4zpX7Wmrvqv4Opg6t7J6yZkdRIygWtfVaQS4WnSNpCp2akY D4d+8DoZTIsb8gAd/PWoQhda5p/oO3SVAF/sMbi8xYsfbia1Q58c0UxVUbT7kEJO UOyHdxa/cpIb0tk1eXC8IcRsC5JMWcpVXeq5bnffk3k4BblQ0IosgQno6SVRgSzO r6OvBe+8YUXKiTRLSjwOnQ9ZwYLsvkkBE0an8ux+AOQDptYs4x8/ppTWtm3Ole1Y OrFYxdy3ob6YU4L/rSeIkVg074TjrkMNWGLRni03Gj3hNTb/P5R4y0f4St2fBG2l 6hVI2VEk2BerF9o8KykKf/FS4swHSHfoeke59ONGlTIz/3NEQ83vfNBWJ5WWnt+X L3UfPnKrELTDWm8WA4aQwmgiKVyV1o1N4u5GM2pwWN57B+Y0Kw6UVmLnUkTMjIif 4A7lL68lSQwxCemG/MuSMxaQev7nz2aruoiT+WVvzb/uEZ54rgNsMhsHNHPPwoom qoTlyRWNZivSmGYmBehj797byGmpfhG8W0HrxZ91aScWtzwalFS9fLxVmHLvzl+B eEHfMxaFxv5R+yE7H59AA9SUbVZ1GY0Xvz7dx0njmL/zVBDB/Ho9tjvV0jrQd6yP a6VLhQxix6+Cin0xm7lP =YA7H -----END PGP SIGNATURE----- --nextPart1747182.j4EHdBP6Dl-- From nobody Tue Aug 30 13:20:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A5912D7F6 for ; Tue, 30 Aug 2016 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 469NQLpxdJ3Z for ; Tue, 30 Aug 2016 13:20:14 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 36CBC12D7F0 for ; Tue, 30 Aug 2016 13:20:14 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id n75so7239622ith.1 for ; Tue, 30 Aug 2016 13:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Mqik7LrEhiRez9xXMkaM3hiM0Ezd1100Ysm4/ACyIQU=; b=DuoD3FlwewjYfytIEvsQHn/DIUqrgXPQB7G8ntKlmGNZNwi1i0Y2qWk2wwiah7+XJ2 T/4ItpT7gkX/wqT+Iv5HDCLV7AnW1B2tt3cXPSWvRJGiTXfutyiF9S48C0LxDNn+o7TA UO2+5EHXYXRoJObJefVzdkIozbnwAF0kt7trZiGWSwv9rMSKalqDN5PF3oOxpdHY+PB9 apBUc6xW8vxqE6QkCCtcRukYBpKZPS+T4k23Rl7EzIbEV3H3CUUg2IaEQj08h1rT+cUx 3H2RhXuKGNyavLZRG0zEfCnAoicA0dTWt0Xn8v+N9PkZteF5vTV9JMzOSm/2cN4j8QGY owFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Mqik7LrEhiRez9xXMkaM3hiM0Ezd1100Ysm4/ACyIQU=; b=EPAAFv53mKMep3cZ9vJmYA2NqXpylWh0cd9um3B7iAKCImfYll+8sI/A4iYoY4btM0 5yg7Ani5djWNvFCmnxciLr+IXOQlLjI3aB7VBnUKh45Eg/HKKNFXEcqtsjDghBFk7Rum hMnAa7W9jRhxnjEzMS9lrNvdjg9x36KKA8z5D1BKk5VElLAkCRi5EWzlnhN7SrepwMoM UdDQW4RlBLM/N/5XE2T2THg0j9GxzTP9KF68VgWUINnzKwngWLgAWrVbHCtnDxcMBF3m v1d+5sLfmmZK8oCrw+0SgrV59xfc9E72g1J61sb2+cnjGzDKV4Tsrqec6vmDVUPO9gN0 rHhQ== X-Gm-Message-State: AE9vXwNAP2Pp73Naivy857VWuD6ObMfKr0aR5leT/WQicvSUkJ1dCPsqND2FJ+fFKqvxecz+qRAljCffTk65jA== X-Received: by 10.36.9.196 with SMTP id 187mr9365902itm.82.1472588413376; Tue, 30 Aug 2016 13:20:13 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.107.137.69 with HTTP; Tue, 30 Aug 2016 13:20:12 -0700 (PDT) Received: by 10.107.137.69 with HTTP; Tue, 30 Aug 2016 13:20:12 -0700 (PDT) In-Reply-To: <201608301529.49488.davemgarrett@gmail.com> References: <201608301419.33620.davemgarrett@gmail.com> <201608301529.49488.davemgarrett@gmail.com> From: Erik Nygren Date: Tue, 30 Aug 2016 16:20:12 -0400 X-Google-Sender-Auth: hX9yVMWwS1zRaVDZN3QRWglKp9E Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a1143e20847c3a1053b4fb530 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 20:20:15 -0000 --001a1143e20847c3a1053b4fb530 Content-Type: text/plain; charset=UTF-8 I'm also very supportive for the reasons you outline. However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5. In particular, much of the non-technical audience still calls it "SSL" (pet peeve of many of us, I suspect) and having a version number clearly greater than SSLv3 and not confusing with SSLv2 would be quite valuable. "TLS 2" may have risk for unfortunate confusions with SSLv2 and SSLv3. Another reason to avoid 1.3 is Western culture negative connotations around "tls13" which TLS 1.3 will get abbreviated as. - Erik [Sent from my IPv6 connected T-Mobile 4G LTE mobile device] On Aug 30, 2016 3:35 PM, "Dave Garrett" wrote: > On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote: > > I support this change as long as there is no technical change (version > ID remains 0x0304). > > To reiterate, I am also against changing the version ID. However, I do > think it's worth updating the context string version number, otherwise it'd > be a little unnecessarily confusing there. (trivial change to key > derivation, but not wire format) I've also made a point to tweak references > to the on-the-wire version value to refer to it as a "version ID" rather > than just version, to make it very clear that this is really just an > arbitrary codepoint and shouldn't be read as 3.4. > > I've made the changes for a WIP branch, here (not a PR, as of yet): > https://github.com/tlswg/tls13-spec/compare/master... > davegarrett:tls2rebranding > > Going through the motions of doing the renaming now is useful to see if > there's anything that is more affected than initially expected, such as the > context strings having the version in there directly as a string (they're > designed to be updated as-needed, so this shouldn't be a problem). > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1143e20847c3a1053b4fb530 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm also very supportive for the reasons you outline.

However, I think we should consider calling it TLS 4 or TLS = 4.0 or TLS 5.

In particular, much of the non-technical audience still call= s it "SSL" (pet peeve of many of us, I suspect) and having a vers= ion number clearly greater than SSLv3 and not confusing with SSLv2 would be= quite valuable.=C2=A0 "TLS 2" may have risk for unfortunate conf= usions with SSLv2 and SSLv3.

Another reason to avoid 1.3 is Western culture negative conn= otations around "tls13" which TLS 1.3 will get abbreviated as.

- Erik

=C2=A0=C2=A0=C2=A0=C2=A0 [Sent from my IPv6 connected T-Mobi= le 4G LTE mobile device]


On Aug 30, 2016 3= :35 PM, "Dave Garrett" <davemgarrett@gmail.com> wrote:
On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu w= rote:
> I support this change as long as there is no technical change (version= ID remains 0x0304).

To reiterate, I am also against changing the version ID. However, I do thin= k it's worth updating the context string version number, otherwise it&#= 39;d be a little unnecessarily confusing there. (trivial change to key deri= vation, but not wire format) I've also made a point to tweak references= to the on-the-wire version value to refer to it as a "version ID"= ; rather than just version, to make it very clear that this is really just = an arbitrary codepoint and shouldn't be read as 3.4.

I've made the changes for a WIP branch, here (not a PR, as of yet):
https://github.com/tl= swg/tls13-spec/compare/master...davegarrett:tls2rebranding
Going through the motions of doing the renaming now is useful to see if the= re's anything that is more affected than initially expected, such as th= e context strings having the version in there directly as a string (they= 9;re designed to be updated as-needed, so this shouldn't be a problem).=


Dave

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1143e20847c3a1053b4fb530-- From nobody Tue Aug 30 14:04:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B5512D734 for ; Tue, 30 Aug 2016 14:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSlnoocFc1wb for ; Tue, 30 Aug 2016 14:04:23 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 F2D5F12D815 for ; Tue, 30 Aug 2016 14:04:22 -0700 (PDT) Received: (qmail 18188 invoked by uid 1004); 30 Aug 2016 21:04:20 -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; Tue, 30 Aug 2016 22:04:20 +0100 Received: (qmail 3288 invoked by uid 1000); 30 Aug 2016 21:04:20 -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; Tue, 30 Aug 2016 22:04:20 +0100 To: tls@ietf.org References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> From: Rob Stradling Message-ID: Date: Tue, 30 Aug 2016 22:04:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 21:04:27 -0000 On 30/08/16 21:14, Hubert Kario wrote: > On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: >> * Keep the version ID as { 3, 4 } (already weird counting; changing risks >> more intolerance) > > IMNSHO this alone is enough of a reason not to do this > > it's enough explaining to people that SSLv3.3 is really TLSv1.2, now we'll > have SSLv3.4 == TLSv1.3 == TLSv2.0 > > it's silly at this point It's been silly for nearly two decades already! https://plus.google.com/+IlyaGrigorik/posts/BesDRVDqB4h So... On 30/08/16 21:20, Erik Nygren wrote: >> However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5. >> >> In particular, much of the non-technical audience still calls it "SSL" >> (pet peeve of many of us, I suspect) and having a version number clearly >> greater than SSLv3 and not confusing with SSLv2 would be quite >> valuable. "TLS 2" may have risk for unfortunate confusions with SSLv2 >> and SSLv3. How about we drop the "TLS" name completely, and simply call it "SSLv4" or "SSLv5" ? Then the non-technical audience that still calls it "SSL" would magically become correct again. :-) Returning to a previous name seems to be trendy at the moment... https://en.wikipedia.org/wiki/Mac_OS -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Aug 30 15:20:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D39A12D828 for ; Tue, 30 Aug 2016 15:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.487 X-Spam-Level: X-Spam-Status: No, score=0.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aGdq4QA6SzI for ; Tue, 30 Aug 2016 15:20:48 -0700 (PDT) Received: from BAY004-OMC3S7.hotmail.com (bay004-omc3s7.hotmail.com [65.54.190.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340CC12D7DE for ; Tue, 30 Aug 2016 15:20:48 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com ([65.54.190.189]) by BAY004-OMC3S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 30 Aug 2016 15:20:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zH5aGzvufdXQ57wAC9g078MF+ohAyvpdcdRpLYsN+wo=; b=msmC4yRK5b4ToF9OviJQXFVkQEIBGZkycC2ijOMdqOkG6QIi0HkD6PAoXVfsVz3tydfdBxSEO0RhQj4eqd9QOEly0GGkjzf026hAZhJ0kAUe73nHKA9wseVHjrXErkq0rAnpD6LUfJOzQQcWr//d9VfYnf+em3Rpz5a9z1Qb8Fhj6iiKIr7zxmnV0eDgQUkvxDKBqDXpEVm1USsIjbx3i3LorARlVtYUA/2I0do2jrqyVvYxxD5xQz3OhYZFdFhyFgHigXGeTk3/4vkVwfnMo5RU2qOK7QH7kO8CBAvCzMeZw72TLFBUUHzhbGDUMsswsj9foSuH6AJvqHERmA6+mQ== Received: from CY1NAM02FT017.eop-nam02.prod.protection.outlook.com (10.152.74.59) by CY1NAM02HT241.eop-nam02.prod.protection.outlook.com (10.152.74.70) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Tue, 30 Aug 2016 22:20:47 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.74.55) by CY1NAM02FT017.mail.protection.outlook.com (10.152.75.181) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Tue, 30 Aug 2016 22:20:46 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0587.013; Tue, 30 Aug 2016 22:20:45 +0000 From: Xiaoyin Liu To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 -> TLS 2.0? Thread-Index: AQHSAvscyIlLjDDf4Uiibi8FH237r6BiDNqw Date: Tue, 30 Aug 2016 22:20:45 +0000 Message-ID: References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> In-Reply-To: <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.74.55) smtp.mailfrom=outlook.com; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.74.55 as permitted sender) x-tmn: [1evcZqUaT17fCebwLb29LSudXWhvHkdC] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.74.55; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1NAM02HT241; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; CY1NAM02HT241; 6:eBByIQBmsYrf196IzVT2SItRwQBr+VPlpdd6iK1moz0bbsDtsFpdlN+L3LfWQmZr6B4exQkp5tbaDiB/2UqXpW+DuvX7nzs4+5Z+f5cKj14mVlEdJWndV3UB0oUjhjL9kUSkcge76qZ2j1Ux7MOMICeODgu6CjK1tloE5COc02K0IhiMUPw1yE1eR8iIG8tSAADzb6i4pP04VAXW4d/GXzTuBqAQSMEu24hUXoi1xsMjOAQRjKbGs4XMRiJ6T44saec2lk2gMV0wJiHB33pCPOJfCpgnfgyrGlX7o2MeGntqs3ymzdc2iq1qolIyTOhW; 5:F4GO9zEcFr0XpgTcRVZTEdLfDhHmany+CYpoFVZUhlpkceE4vLTaJpmRujdCFy75zt+VFnCbCVDtXBuTg38fjs004bH/aL8HYRRDa5zkC1jzjkYfj7krqYcpQrpY+7QcD9dmJf4V+hYYTF3eXYdlzw==; 24:fjrDB1Qxgp0Zi5GwPbTf5tfJI0udviImYeZfpQnOWEUl1IiUPcOe9Yh3mOY2Fvb8RAQaTBBbGRgBia4XPHDbgKyDCYmPISms45C4e9lgmHQ=; 7:gle/EdOpsfP5Le8ie6bZS+aop/fWAU7AVrF87ZE22emFwMVCGB+fs7uxawMJDjkywVXNiGrcnfkLjcqq4vlhpsKZt77pSOONgT2qzPE8hKSRlzAgciRFswGbvE2o8mnDfSO2Aj/QOJX8+00SYxbru7VfABCv4Y8lGMAcPBEe6kGgX6+X+WrVyfon63euHC8TDFWs/Pr37CX37zUUvmPOc1qi+S4m0elAmtjPchLz8ukfx6gEUK9PoaHPPV/w5eB4 x-ms-office365-filtering-correlation-id: 6a7160fe-dff6-4043-caaf-08d3d123e303 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1601125047); SRVR:CY1NAM02HT241; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CY1NAM02HT241; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT241; x-forefront-prvs: 0050CEFE70 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 22:20:45.1688 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT241 X-OriginalArrivalTime: 30 Aug 2016 22:20:48.0279 (UTC) FILETIME=[C260F270:01D2030C] Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 22:20:49 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1YmVydCBLYXJpbw0KPiBTZW50OiBUdWVzZGF5 LCBBdWd1c3QgMzAsIDIwMTYgNDoxNCBQTQ0KPiBUbzogdGxzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbVExTXSBUTFMgMS4zIC0+IFRMUyAyLjA/DQo+IA0KPiBPbiBUdWVzZGF5LCAzMCBBdWd1 c3QgMjAxNiAxNDoxOTozMyBDRVNUIERhdmUgR2FycmV0dCB3cm90ZToNCj4gPiAqIEtlZXAgdGhl IHZlcnNpb24gSUQgYXMgeyAzLCA0IH0gKGFscmVhZHkgd2VpcmQgY291bnRpbmc7IGNoYW5naW5n DQo+ID4gcmlza3MgbW9yZSBpbnRvbGVyYW5jZSkNCj4gDQo+IElNTlNITyB0aGlzIGFsb25lIGlz IGVub3VnaCBvZiBhIHJlYXNvbiBub3QgdG8gZG8gdGhpcw0KPiANCj4gaXQncyBlbm91Z2ggZXhw bGFpbmluZyB0byBwZW9wbGUgdGhhdCBTU0x2My4zIGlzIHJlYWxseSBUTFN2MS4yLCBub3cgd2Un bGwgaGF2ZQ0KPiBTU0x2My40ID09IFRMU3YxLjMgPT0gVExTdjIuMA0KDQpJIGRvbid0IHRoaW5r IHRoaXMgaXMgYSBwcm9ibGVtLiBQZW9wbGUgd2lsbCBmb3JnZXQgIlRMUyAxLjMiIGFuZCB3aWxs IG9ubHkgcmVtZW1iZXIgIlRMUyAyLjAiIGFmdGVyIHNvbWUgdGltZS4gSnVzdCBsaWtlIGZldyBw ZW9wbGUgc3RpbGwgcmVtZW1iZXIgIldpbmRvd3MgOSIgdG9kYXksIGV2ZW4gaWYgIldpbmRvd3Mg OSIgaGFkIGJlZW4gcnVtb3JlZCBpbiB0aGUgbmV3cyBldmVyeSBkYXkgYmVmb3JlIE1pY3Jvc29m dCBvZmZpY2lhbGx5IGFubm91bmNlZCAiV2luZG93cyAxMCIuDQoNCkFsc28gdGhpcyBzcGVjIGhh c24ndCByZWFjaGVkIFdHTEMsIHNvIEkgZG9uJ3QgdGhpbmsgaXQncyB0b28gbGF0ZSB0byBtYWtl IGEgY2hhbmdlIHRvIGl0cyBuYW1lLg0KDQoNClhpYW95aW4NCg== From nobody Tue Aug 30 16:51:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B977312D851 for ; Tue, 30 Aug 2016 16:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc7_6-kgGdhH for ; Tue, 30 Aug 2016 16:50:57 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E5D12D835 for ; Tue, 30 Aug 2016 16:50:57 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id r9so21329025ywg.0 for ; Tue, 30 Aug 2016 16:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ipBrIj1hbhGHzzpqWoUvh7kwIMOeYN/QzeOqN0XIVkk=; b=fpu8dgetfWms62Cixi4usy5CNRdGMfjhEYbNU1q4U/aJFGrY8bfTWb3ZScayGC59Hz Pm/Xv5g5XNEVRUB372P5yLI3CVzpfQr5LjkcftbvsFTViDkV6dv8CGs+Z29NPOGyZ9uT mDE1om7L6RQaVc6PROu/ppqWEjsfYZa86yfpFEJ8SkPG01hdwRdb4+HqZRCU3Cxo2uMU EWrRZzUHgp3CxZqyMM5QedK0wscgejROfvZDgG4pXjmrDyGaUVw2TOuzfkXhF9j9O5gS aQJteA0UZBoq1D6sGwh5xccN5PfosBLdcH2qzcp4t1yEOawLRJqh3+6jZSjDsl3fevcW t+pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ipBrIj1hbhGHzzpqWoUvh7kwIMOeYN/QzeOqN0XIVkk=; b=htFR+3VRUBQtwSF1gx+VQIyOOamkMwY9bJ/xsZ/xBiYrY1JLMi/8YIJLgPdSprhtgU ghpKYzBwwL0egFk+bI9psrg7LhTjS8ZFNUxnNbWs2Y9ui5ZU45YlUdmdGtdQFOktNSr2 B38BheYw46MqAlFje9nAir/6zJ4bVvHMmqlV4NxXpd9FEpJ842vtCsJLvAN0oci+MV+U j/Gg/jlfWfNB7vS59RkDBJkVHcMqCs9wXAmRdjeXTqGjm+DIo2fUF8OwG5XxXQhV+twv ABHgPKjqua7MgaVPa4XALrjmMWA5nFGu9/ihYbYCchwsLEkXsYCD/mBTsACYkhuYEbJe H1aA== X-Gm-Message-State: AE9vXwP+O0YbAQ087Rrya7b3AOrILKymbHrMgA4wzocwIDKwXTzhTq8K0HQdxXoEt55orxvzmMavul3jLjTjOQ== X-Received: by 10.13.244.197 with SMTP id d188mr5868321ywf.276.1472601056092; Tue, 30 Aug 2016 16:50:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Tue, 30 Aug 2016 16:50:15 -0700 (PDT) From: Eric Rescorla Date: Tue, 30 Aug 2016 16:50:15 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c086548d8544b053b52a618 Archived-At: Subject: [TLS] Issue 588: Code point assignment for ticket_early_data_info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Aug 2016 23:50:59 -0000 --94eb2c086548d8544b053b52a618 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/588 I neglected to assign a code point for this in draft-15. I note, however, that we currently have it occupying a different code point space than hello extensions. I am sort of wondering if it would be more useful for them to be in the same space. Probably not, but I thought I would ask before assigning 1, which is the natural code point otherwise. https://tlswg.github.io/tls13-spec/#rfc.section.4.5.1 -Ekr --94eb2c086548d8544b053b52a618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://github.com/tlswg/tls13-spec/issues/588

= I neglected to assign a code point for this in draft-15. I note, however, t= hat
we currently have it occupying a different code point space t= han hello extensions.
I am sort of wondering if it would be more = useful for them to be in the same
space. Probably not, but I thou= ght I would ask before assigning 1, which is
the natural code poi= nt otherwise.


-Ekr

--94eb2c086548d8544b053b52a618-- From nobody Tue Aug 30 23:07:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D42512D0F9 for ; Tue, 30 Aug 2016 23:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.964 X-Spam-Level: X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHkq5DKPqUNE for ; Tue, 30 Aug 2016 23:07:28 -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 7C7C412D0E7 for ; Tue, 30 Aug 2016 23:07:28 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1D8877DD39 for ; Wed, 31 Aug 2016 06:07:28 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.54]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7V67QOA007057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 31 Aug 2016 02:07:27 -0400 Message-ID: <1472623645.2310.0.camel@redhat.com> From: Nikos Mavrogiannopoulos To: tls@ietf.org Date: Wed, 31 Aug 2016 08:07:25 +0200 In-Reply-To: <201608301419.33620.davemgarrett@gmail.com> References: <201608301419.33620.davemgarrett@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 31 Aug 2016 06:07:28 +0000 (UTC) Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 06:07:29 -0000 On Tue, 2016-08-30 at 14:19 -0400, Dave Garrett wrote: > I occasionally see people ask why we're calling it TLS 1.3 when so > much has changed, and I used to simply think that it was too > bikesheddy to bother changing at this point. However, now that we've > redone negotiation, we have new TLS 1.3+ only cipher suites. The old > are not compatible with the new (new codepoints needed for old > ciphers) and the new are not backwards compatible with the old > (they'll just be ignored). We actually risk misconfiguration in the > future if the distinction isn't made clear. I think it's time we just > renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a > major version seems more appropriate. I agree with the proposal. From nobody Tue Aug 30 23:24:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D858012B03F for ; Tue, 30 Aug 2016 23:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ScnNmkONQ7O for ; Tue, 30 Aug 2016 23:24:00 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502A912D0B3 for ; Tue, 30 Aug 2016 23:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472624640; x=1504160640; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tRZPIzEQcYKuzsPhOaRaeBhQ/6bOICSmh5Aq0/6Q69U=; b=FiulRwI7hxNfkm3QcE51LRurx348lCzMRcCt0K1+qv1JITlE/rIazeJg tHaDoHzkeWR/PYyT1LzICzCNE3QCpezuHH0djbmmHHLF6aKDMmcBf/zUp str/L3VM8aoAr/hPGIzBXVcaveA/GveAIBgIV3z+HjG0SSsnLnTEPM3vX Zw2SBdt51iUsHVm9qNWSDBCJUsz4JpQiPQqXLLEkYsIrYsCmBernWyJax LFY5lhiDnhKvGOlZurnzHqGcHzndtFJbTnzUYSiVmEzNoiKId91zVvZbp 5y3uUtf7vNhsPInl8mNqVb51+bN7TJtUHZrJ/sVNP4vxIaltVMAOP5eQO A==; X-IronPort-AV: E=Sophos;i="5.30,260,1470657600"; d="scan'208";a="104171701" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 31 Aug 2016 18:23:57 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Wed, 31 Aug 2016 18:23:57 +1200 From: Peter Gutmann To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 -> TLS 2.0? Thread-Index: AQHSAusYmOtRZuHEjkubaeZ5bnh78qBimokT Date: Wed, 31 Aug 2016 06:23:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D0844B@uxcn10-5.UoA.auckland.ac.nz> References: <201608301419.33620.davemgarrett@gmail.com> In-Reply-To: <201608301419.33620.davemgarrett@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 06:24:04 -0000 Dave Garrett writes:=0A= =0A= >I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major=0A= >changes, so labeling it a major version seems more appropriate.=0A= >=0A= >[...]=0A= =0A= +1 to all of this. As people on the list know, I've been calling it =0A= "TLS 2.0-called-1.3" for a long time now. It really is a new protocol rath= er=0A= than something in the 1.x family, and it's quite misleading calling it 1.3.= =0A= =0A= Peter.= From nobody Wed Aug 31 00:35:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BCA12D0DA for ; Wed, 31 Aug 2016 00:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDIJ1W5YFSnX for ; Wed, 31 Aug 2016 00:35:45 -0700 (PDT) Received: from 11.mo7.mail-out.ovh.net (11.mo7.mail-out.ovh.net [87.98.173.157]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AFB12D09A for ; Wed, 31 Aug 2016 00:35:45 -0700 (PDT) Received: from player796.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 3686210005E1 for ; Wed, 31 Aug 2016 09:35:40 +0200 (CEST) Received: from RCM-mail356.ha.ovh.net (unknown [193.104.162.7]) (Authenticated sender: julien@trigofacile.com) by player796.ha.ovh.net (Postfix) with ESMTPSA id 2D3305C0099; Wed, 31 Aug 2016 09:35:38 +0200 (CEST) Received: from [193.104.162.7] by ssl0.ovh.net with HTTP (HTTP/1.1 POST); Wed, 31 Aug 2016 09:35:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 31 Aug 2016 09:35:38 +0200 From: =?UTF-8?Q?Julien_=C3=89LIE?= To: tls@ietf.org Organization: TrigoFACILE Message-ID: <6b05e1f2c2bd0fb699f4650182b8ddd4@trigofacile.com> X-Sender: julien@trigofacile.com User-Agent: Roundcube Webmail/1.1.3 X-Originating-IP: 193.104.162.7 X-Webmail-UserID: julien@trigofacile.com X-Ovh-Tracer-Id: 9857253687864983025 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeluddrgeejgdduvdehucdltddurdefledtrddttddmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: [TLS] Terminology clarification around SSL & TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 07:35:47 -0000 Hi all, Following a recent discussion about how to name the successor of TLS 1.2, I wish to share an idea about a possible terminology clarification. I believe it could help to conciliate people understanding of SSL & TLS. We would have 3 notions: 1/ the technology, 2/ the protocols, 3/ the protocol versions. The technology is SSL, and is sometimes also refered to as SSL/TLS. (Note that bare TLS is not a technology.) The protocols are: - deprecated eponym SSL, - TLS, - DTLS. The protocol versions are: - 1.0, 2.0 and 3.0 for SSL, - 1.0, 1.1, 1.2 and 2.0 for TLS, - 1.0, 1.2 and 2.0 for DTLS. Any comments about that proposal? -- Julien ÉLIE From nobody Wed Aug 31 00:41:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9025012D82E for ; Wed, 31 Aug 2016 00:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF82pkiovuN3 for ; Wed, 31 Aug 2016 00:41:18 -0700 (PDT) Received: from mo53.mail-out.ovh.net (mo53.mail-out.ovh.net [178.32.228.53]) (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 800F312D7FE for ; Wed, 31 Aug 2016 00:41:18 -0700 (PDT) Received: from player159.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo53.mail-out.ovh.net (Postfix) with ESMTP id BAD4D43DB4 for ; Wed, 31 Aug 2016 09:41:16 +0200 (CEST) Received: from RCM-mail356.ha.ovh.net (unknown [193.104.162.7]) (Authenticated sender: julien@trigofacile.com) by player159.ha.ovh.net (Postfix) with ESMTPSA id 73AD84800A2; Wed, 31 Aug 2016 09:41:15 +0200 (CEST) Received: from [193.104.162.7] by ssl0.ovh.net with HTTP (HTTP/1.1 POST); Wed, 31 Aug 2016 09:41:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 31 Aug 2016 09:41:15 +0200 From: =?UTF-8?Q?Julien_=C3=89LIE?= To: tls@ietf.org Organization: TrigoFACILE In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D0844B@uxcn10-5.UoA.auckland.ac.nz> References: <201608301419.33620.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4D0844B@uxcn10-5.UoA.auckland.ac.nz> Message-ID: <7a56f6b950b46eeb07353805f020c9b8@trigofacile.com> X-Sender: julien@trigofacile.com User-Agent: Roundcube Webmail/1.1.3 X-Originating-IP: 193.104.162.7 X-Webmail-UserID: julien@trigofacile.com X-Ovh-Tracer-Id: 9951829279543721457 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeluddrgeejgdduvdejucdltddurdefledtrddttddmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 07:41:19 -0000 Hi all, >> I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major >> changes, so labeling it a major version seems more appropriate. > > +1 to all of this. As people on the list know, I've been calling it > "TLS 2.0-called-1.3" for a long time now. It really is a new protocol > rather > than something in the 1.x family, and it's quite misleading calling it > 1.3. I am also in favour of a TLS 1.3 -> TLS 2.0 renaming. Considering that possible change, wouldn't it be useful to go on working on draft-gutmann-tls-lts-05, and consider TLS-LTS not as a TLS extension but as a real 1.3 version of the 1.x series? -- Julien ÉLIE From nobody Wed Aug 31 00:52:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D624412D981 for ; Wed, 31 Aug 2016 00:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiZ1eyIzYW9o for ; Wed, 31 Aug 2016 00:52:46 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781EA12D8E0 for ; Wed, 31 Aug 2016 00:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472629966; x=1504165966; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8NK76EjJuWkURLXs/xMeTbKrrPOLhOkypUF9DQkibKE=; b=m7qep5f6e3V+4w9Hk217S8pa3whjOJ7UV/dZ3FFjeV1hpwa3WCRgPYHo 4VwzoTXVVuQiWPUoYoaJd7YX8CBr+gPVrbpTIGzy8I36PLU9rspYubwPj IeRnXSc3KHU+0NUo/b/lnpV+M8cc2z7ITf3TGU9YEaROzewlwp0UowoO4 AyFiezPDgsC7vEjbxkdRja30+K+nlah2Kovq1UbB2YtnkNvnnvkjwQ63G z0VDeKnltQT1eWXHhcmVqp3BctE/C38bSMpSeHJQaJDWEOj5r1cl1pUq0 +/ThdoZd8sJvONIT8WDuuHJfa9rTNirBiM3S/mm3MmXQzgUXhy+7XI0q6 A==; X-IronPort-AV: E=Sophos;i="5.30,261,1470657600"; d="scan'208";a="104176092" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 31 Aug 2016 19:52:44 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Wed, 31 Aug 2016 19:52:45 +1200 From: Peter Gutmann To: =?iso-8859-1?Q?Julien_=C9LIE?= , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 -> TLS 2.0? Thread-Index: AQHSA1sd5YN270KA4EyZGbZlB+NgVqBisnYz Date: Wed, 31 Aug 2016 07:52:44 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D08BDD@uxcn10-5.UoA.auckland.ac.nz> References: <201608301419.33620.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4D0844B@uxcn10-5.UoA.auckland.ac.nz>, <7a56f6b950b46eeb07353805f020c9b8@trigofacile.com> In-Reply-To: <7a56f6b950b46eeb07353805f020c9b8@trigofacile.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 07:52:48 -0000 Julien =C9LIE writes:=0A= =0A= >Considering that possible change, wouldn't it be useful to go on working o= n=0A= >draft-gutmann-tls-lts-05, and consider TLS-LTS not as a TLS extension but = as=0A= >a real 1.3 version of the 1.x series?=0A= =0A= If the current 2.0-called-1.3 is renamed to 2.0, I'd be open to calling LTS= =0A= "1.3", although I think it's more a 1.2.1 :-). Its real goal though is to = be=0A= exactly what it says on the label, an LTS version of the TLS 1.x line that = can=0A= be used in devices with long lifecycles that are based on the 1.x family an= d=0A= need a best-of-breed version of that. So LTS would be the final, wrap-up= =0A= version of the 1.x line for people who need, well, an LTS version of the=0A= protocol.=0A= =0A= Peter.= From nobody Wed Aug 31 01:00:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6B12D9EB for ; Wed, 31 Aug 2016 01:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yaiJqod5IY9 for ; Wed, 31 Aug 2016 01:00:13 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FFB12D9E6 for ; Wed, 31 Aug 2016 01:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472630412; x=1504166412; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=n/2977qS10WrsierepRatEk6WOe7AfHNmGO69HyCrK4=; b=cVKyF10P5+mNa5bJNzWVtqZnylUyk46/k/NvpOv4YlFu63jT/K9JWSMG 5r3W4FZIPUoadbQwMYKTLthcffy7CqdkfaZrwa+5wP9Hepy/A0eOpl+zN /dDWziKpBcuBZPZeteHpvqVpsYybTS4hFg/43L9600ubpSfaq9KNCXQXI i6N905qV9AdNmKvis8rm14VJ9lp7Z/Lg8IAY4QLiW8++aXzJru3XSp2nw Zgx+1xG+SV5eeKOOQYyVwf3kGbzoN7Ew7fs/zjjQIzJd/G3eGVt8PzMIU Joh3VPup7TpZJw5TzKrDuD2BY/h9h26Nc0WGftdvIoyJlYGr4jbh70BWd g==; X-IronPort-AV: E=Sophos;i="5.30,261,1470657600"; d="scan'208";a="104176516" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 31 Aug 2016 20:00:11 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Wed, 31 Aug 2016 20:00:11 +1200 From: Peter Gutmann To: "David McGrew (mcgrew)" , Tony Arcieri , "" , "cfrg@irtf.org" Thread-Topic: [Cfrg] 3DES diediedie Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1//9AtgCAAkz7eYAA1VQAgAImRw3//1XhAIACIh2z Date: Wed, 31 Aug 2016 08:00:10 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D08C06@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <9A043F3CF02CD34C8E74AC1594475C73F4D073D4@uxcn10-5.UoA.auckland.ac.nz>, <7C844B58-5B3E-4A47-AA67-471C50620323@cisco.com> In-Reply-To: <7C844B58-5B3E-4A47-AA67-471C50620323@cisco.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 08:00:20 -0000 David McGrew (mcgrew) writes:=0A= =0A= >That=92s great, facts leaven a debate.=0A= =0A= Yeah, but they also make it really boring, sigh. *Opinions*, now those are= =0A= fun...=0A= =0A= Peter.= From nobody Wed Aug 31 01:48:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2C312DA33 for ; Wed, 31 Aug 2016 01:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.964 X-Spam-Level: X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEJvLKsLi3Oi for ; Wed, 31 Aug 2016 01:48:14 -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 5006412DA3A for ; Wed, 31 Aug 2016 01:48:14 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C8E164E4CC; Wed, 31 Aug 2016 08:48:13 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7V8mC4h015941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2016 04:48:13 -0400 From: Hubert Kario To: Xiaoyin Liu Date: Wed, 31 Aug 2016 10:47:59 +0200 Message-ID: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; ) In-Reply-To: References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2202313.4GiWJ3qK4H"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 31 Aug 2016 08:48:13 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 08:48:16 -0000 --nextPart2202313.4GiWJ3qK4H Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 30 August 2016 22:20:45 CEST Xiaoyin Liu wrote: > > -----Original Message----- > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Hubert Kario > > Sent: Tuesday, August 30, 2016 4:14 PM > > To: tls@ietf.org > > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? > >=20 > > On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: > >=20 > > > * Keep the version ID as { 3, 4 } (already weird counting; changing > > > risks more intolerance) > >=20 > >=20 > > IMNSHO this alone is enough of a reason not to do this > >=20 > > it's enough explaining to people that SSLv3.3 is really TLSv1.2, now we= 'll > > have SSLv3.4 =3D=3D TLSv1.3 =3D=3D TLSv2.0 >=20 >=20 > I don't think this is a problem. People will forget "TLS 1.3" and will on= ly > remember "TLS 2.0" after some time. well, that's not the experience of our support engineers, people still conf= use=20 SSLv3 with TLSv if the WG really wants a TLSvX.0 name, the X really should be bigger than 3 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2202313.4GiWJ3qK4H 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 iQIcBAABCgAGBQJXxpm/AAoJEJKo0bgB0vX1hUwP/2WgAZkEiWfpNp2Rgy5jNKO2 dIYaXxqqSIjZW2bCI5fzAYquH3WsT1/le8cAvTfY8YSDCjbvBc6jHxCCS3tLSuwB J9QcrXNYvecSdhL4fJblEt3KrTigtvjcH3ZII/BgU/Bbz0HSaq1BGXkT+v6u4l4x Hd3+Waq8Wvm4DwBIPjpv1c/AYTTzD34APHi9J+lExmxQZYhuWnP1NedcP/iTLUIW 90QvJJtXmDYkQ24aTExKsgA361OJMZYYKwGR4ESGjklKLHsf57B6JOLHUOH61QwV EoVSDy1uH3hDGPYeStgP7oCLDFj9Jnad+FW5O9n7DNlLi7vqDq7n4KPtz0VRI9RO +9L8I12cGTmHp9hkCR7xceREqzK3K5LFR1d+ZSRhbXcDq4Rzn6TUt6HsWh74LgD1 F69j9LHEH8QThI4CVDvQawJqYBCpFcVZbvqiV9fkfw4US3SUjko33opPoZvAxsyv +hbD/M2K9uecYIFmULNhCAiJ3utZegqLDl+Px9TMXZifXWsZPmN9Re9uGcGb0ILt nodQEi0okUZs/oWEuU0aRk5yHrrKvbhlGKYNCGWQWgBKPshmTMFvZoJmUQjwdlGj u25rgoQeV6AwcHCnJPPUNDO1vJBXXp8QM+X1x706YmJ3YDovpNybdZjz5XDkDFSo /FeEf5V6S8mpYGDG1cma =O2nb -----END PGP SIGNATURE----- --nextPart2202313.4GiWJ3qK4H-- From nobody Wed Aug 31 02:35:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB612D8D1 for ; Wed, 31 Aug 2016 02:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.487 X-Spam-Level: X-Spam-Status: No, score=0.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBiCkWomq4fk for ; Wed, 31 Aug 2016 02:35:55 -0700 (PDT) Received: from COL004-OMC2S9.hotmail.com (col004-omc2s9.hotmail.com [65.55.34.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6DD12D0CB for ; Wed, 31 Aug 2016 02:35:51 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com ([65.55.34.73]) by COL004-OMC2S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 31 Aug 2016 02:35:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RToSeoXhleq4d65zll8OC4yAYCV9QxUakXBB4/fFq2A=; b=dsVy4dthxZWltYE2u8xJEZG7IE40vUJV5x4Us45ix6YeDbSGruswWTtAFcs65/+8uig+Xph65pmy5UUcbpF9UH3+y/y/cdHcH7P2WstkVW7yVw0AvPinItmBy8T2vIIJN75Uk+OumX8ce6ZOEBFjn4sdqVVlYwnazESzNQmDZgh4vwcOW6Nd4IEesf0sYLz9e+d9YJ6r/8waV0YJ/CbxMFwqSPPwpxOw51JFTX9DRbUKL7S5YMX0G5ldy98DFyp5Q8GzWGbP4jLsl/FluSrS+xDFsghzIKg9BB82822oVXqTxYaZZcbuTRiUAwP/ZH5ZlmdOAuZivJUGGjIHwlAKVw== Received: from BN3NAM01FT020.eop-nam01.prod.protection.outlook.com (10.152.66.58) by BN3NAM01HT201.eop-nam01.prod.protection.outlook.com (10.152.66.205) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Wed, 31 Aug 2016 09:35:49 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.66.55) by BN3NAM01FT020.mail.protection.outlook.com (10.152.67.227) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Wed, 31 Aug 2016 09:35:49 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0587.013; Wed, 31 Aug 2016 09:35:47 +0000 From: Xiaoyin Liu To: Hubert Kario Thread-Topic: [TLS] TLS 1.3 -> TLS 2.0? Thread-Index: AQHSAvscyIlLjDDf4Uiibi8FH237r6BiDNqwgAC174CAAACY8A== Date: Wed, 31 Aug 2016 09:35:47 +0000 Message-ID: References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> <3453142.248EJ6K14H@pintsize.usersys.redhat.com> In-Reply-To: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.66.55) smtp.mailfrom=outlook.com; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.66.55 as permitted sender) x-tmn: [DKQvYdT8Sm6o2uGpMqOiNrflEtL4+qhq] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.66.55; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM01HT201; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; BN3NAM01HT201; 6:sSJZwOWI5XKOu12Fi8G2Xej1hGy0xJm79hb9XovRRfsiKOhPuowWPr7kr2DjvReLaE29ZN46PLotSp4l/xRHfNsJe2UFpe8eFVCpFxXEXfp/aJMXFi+ciBxmn3tp7QQEeQ5ZBAkbdv6gXtTAe0M1RrN4I/i6qBlBsUpbg5Y5c2SvaphcIHNAvFnOZDdFu3Xpt0MWegPcew43S87oC0zBAD3b+YL6gF1jIvenKn2GWbDJ/cwj7d+whhM5BgBp2dQnRCPNdD+7/j8oLL6zBaaedJeRmGAEgqEpTJZsbG7ZyuGWtU7Nn3/KaFE/OsApRD21; 5:Hu3iK4GcUz3JqyxtOhGVs7CZx1d2yO8iO93Mp+KIBG/DGMOHo4cqcVJZZQCrlf3vs5RByUGjGWEEAZ2np+OrcWAN4yDvcQl7JkX5hw7aAYDDjtYXdQN+XIMmlgu08jwqpec4oKlxn8Gpg5PLYB14jQ==; 24:sH+0+7zIoVKZt2SvWtqVOxe860ru6oeC6uX+ANv8EKLLIdrl1D0SzBP/Ssf1UGc+lAU6ul6K89W18yX01pGI/8Br4pxbRVD9pKFLvwTKVpw=; 7:EBLjuRAQdFkNlgCHGHtXXjDxp5L3R0XQ8oR52O3yhiZGoJete41dS6BPGLvmdwt1PIlPEMQ5UJ3hK2c9/fnD5Ihbp2hegl9N8WH3z1Ppu7i5+n1UBioR6zRBc9+9Gu6zO31o4j3q6Vm/DRBm9TahzAhcOH8DeGkZcfd/osmg6q7GydaQvzPiuWZOpiSR7BjDiEToVPqugHE/EkXTz73KJ5/mSEi+WPQytuwHynnR7ZXAO8V/ky5N/YKGdEIifDWs x-ms-office365-filtering-correlation-id: 4cbecd44-21b0-42b1-d541-08d3d1823082 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103074)(1601125047); SRVR:BN3NAM01HT201; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BN3NAM01HT201; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT201; x-forefront-prvs: 00514A2FE6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 09:35:47.6483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT201 X-OriginalArrivalTime: 31 Aug 2016 09:35:51.0539 (UTC) FILETIME=[1033F430:01D2036B] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 09:35:56 -0000 PiBGcm9tOiBIdWJlcnQgS2FyaW8gW21haWx0bzpoa2FyaW9AcmVkaGF0LmNvbV0NCj4gU2VudDog V2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgNDo0OCBBTQ0KPiBUbzogWGlhb3lpbiBMaXUgPHhp YW95aW4ubEBvdXRsb29rLmNvbT4NCj4gQ2M6IHRsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W1RMU10gVExTIDEuMyAtPiBUTFMgMi4wPw0KPiANCj4gT24gVHVlc2RheSwgMzAgQXVndXN0IDIw MTYgMjI6MjA6NDUgQ0VTVCBYaWFveWluIExpdSB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEh1YmVydCBLYXJpbw0KPiA+ID4gU2VudDogVHVlc2RheSwgQXVndXN0 IDMwLCAyMDE2IDQ6MTQgUE0NCj4gPiA+IFRvOiB0bHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6 IFJlOiBbVExTXSBUTFMgMS4zIC0+IFRMUyAyLjA/DQo+ID4gPg0KPiA+ID4gT24gVHVlc2RheSwg MzAgQXVndXN0IDIwMTYgMTQ6MTk6MzMgQ0VTVCBEYXZlIEdhcnJldHQgd3JvdGU6DQo+ID4gPg0K PiA+ID4gPiAqIEtlZXAgdGhlIHZlcnNpb24gSUQgYXMgeyAzLCA0IH0gKGFscmVhZHkgd2VpcmQg Y291bnRpbmc7DQo+ID4gPiA+IGNoYW5naW5nIHJpc2tzIG1vcmUgaW50b2xlcmFuY2UpDQo+ID4g Pg0KPiA+ID4NCj4gPiA+IElNTlNITyB0aGlzIGFsb25lIGlzIGVub3VnaCBvZiBhIHJlYXNvbiBu b3QgdG8gZG8gdGhpcw0KPiA+ID4NCj4gPiA+IGl0J3MgZW5vdWdoIGV4cGxhaW5pbmcgdG8gcGVv cGxlIHRoYXQgU1NMdjMuMyBpcyByZWFsbHkgVExTdjEuMiwgbm93DQo+ID4gPiB3ZSdsbCBoYXZl DQo+ICBTU0x2My40ID09IFRMU3YxLjMgPT0gVExTdjIuMA0KPiA+DQo+ID4NCj4gPiBJIGRvbid0 IHRoaW5rIHRoaXMgaXMgYSBwcm9ibGVtLiBQZW9wbGUgd2lsbCBmb3JnZXQgIlRMUyAxLjMiIGFu ZCB3aWxsDQo+ID4gb25seSByZW1lbWJlciAiVExTIDIuMCIgYWZ0ZXIgc29tZSB0aW1lLg0KPiAN Cj4gd2VsbCwgdGhhdCdzIG5vdCB0aGUgZXhwZXJpZW5jZSBvZiBvdXIgc3VwcG9ydCBlbmdpbmVl cnMsIHBlb3BsZSBzdGlsbCBjb25mdXNlDQo+IFNTTHYzIHdpdGggVExTdjxhbnk+DQoNCkl0J3Mg bm9ybWFsIHRoYXQgcGVvcGxlIGNvbmZ1c2UgU1NMdjMgd2l0aCBUTFMuIFNTTCAzLjAgd2FzIGEg cmVsZWFzZWQgYW5kIHdpZGVseSBkZXBsb3llZCBwcm90b2NvbCwgYW5kIHRoZSB0ZXJtICJTU0wi IGlzIHN0aWxsIHdpZGVseSB1c2VkIHRvZGF5IHRvIHJlZmVyIHRvIFRMUy4gQnV0IHRoZSBzaXR1 YXRpb24gaXMgbXVjaCBiZXR0ZXIgaWYgd2UgcmVuYW1lIFRMUyAxLjM6IFRMUyAxLjMgc3BlYyBo YXMgbm90IGJlZW4gcmVsZWFzZWQsIGl0IGlzIG5vdCBzdXBwb3J0ZWQgYnkgYW55IG5vbi10ZXN0 aW5nIGNsaWVudHMgb3Igc2VydmVycywgYW5kIHRoZXJlIGFyZSBub3QgbWFueSBkb2N1bWVudHMs IHBhcGVycyBvciBibG9ncyBtZW50aW9uaW5nIFRMUyAxLjMuIFRoaXMgaXMgd2h5IEkgc2FpZCAi VExTIDEuMyIgaXMgc2ltaWxhciB0byAiV2luZG93cyA5IiBpbiB0ZXJtcyBvZiBuYW1pbmcuDQoN Cj4gaWYgdGhlIFdHIHJlYWxseSB3YW50cyBhIFRMU3ZYLjAgbmFtZSwgdGhlIFggcmVhbGx5IHNo b3VsZCBiZSBiaWdnZXIgdGhhbiAzDQo+IA0KDQpXZWxsLCBJIHByZWZlciBUTFMgMi4wLCBiZWNh dXNlIGl0IHNvdW5kcyBtb3JlIG5hdHVyYWwgdGhhdCBtYWpvciB2ZXJzaW9uIDIgY29tZXMgYWZ0 ZXIgbWFqb3IgdmVyc2lvbiAxLiBCdXQgVExTIHs+M30uMCBpcyBhbHNvIGZpbmUgdG8gbWUsIGlm IHRoZSBXRyB0aGlua3MgcGVvcGxlIG1heSBnZXQgY29uZnVzZWQgYmV0d2VlbiBTU0wgMi4wIGFu ZCBUTFMgMi4wLg0KDQpYaWFveWluDQo= From nobody Wed Aug 31 03:47:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0712D14A for ; Wed, 31 Aug 2016 03:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.964 X-Spam-Level: X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy_TnEHf3RFe for ; Wed, 31 Aug 2016 03:47:20 -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 DA94E12D137 for ; Wed, 31 Aug 2016 03:47:20 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9B8078553E; Wed, 31 Aug 2016 10:47:20 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7VAlJh2008427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2016 06:47:20 -0400 From: Hubert Kario To: Xiaoyin Liu Date: Wed, 31 Aug 2016 12:47:14 +0200 Message-ID: <4549539.ex8BfFD3QY@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; ) In-Reply-To: References: <201608301419.33620.davemgarrett@gmail.com> <3453142.248EJ6K14H@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1813493.Ln0pRTUV2Q"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 31 Aug 2016 10:47:20 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 10:47:22 -0000 --nextPart1813493.Ln0pRTUV2Q Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 31 August 2016 09:35:47 CEST Xiaoyin Liu wrote: > > From: Hubert Kario [mailto:hkario@redhat.com] > > Sent: Wednesday, August 31, 2016 4:48 AM > > To: Xiaoyin Liu > > Cc: tls@ietf.org > > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? > >=20 > > On Tuesday, 30 August 2016 22:20:45 CEST Xiaoyin Liu wrote: > >=20 > > > > -----Original Message----- > > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Hubert Kario > > > > Sent: Tuesday, August 30, 2016 4:14 PM > > > > To: tls@ietf.org > > > > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? > > > > > > > > > > > > > > > > On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: > > > > > > > > > > > > > > > > > * Keep the version ID as { 3, 4 } (already weird counting; > > > > > changing risks more intolerance) > > > > > > > > > > > > > > > > > > > > IMNSHO this alone is enough of a reason not to do this > > > > > > > > > > > > > > > > it's enough explaining to people that SSLv3.3 is really TLSv1.2, now > > > > we'll have > > =20 > > SSLv3.4 =3D=3D TLSv1.3 =3D=3D TLSv2.0 > > =20 > > > > > > > > > > > > I don't think this is a problem. People will forget "TLS 1.3" and will > > > only remember "TLS 2.0" after some time. > >=20 > >=20 > > well, that's not the experience of our support engineers, people still > > confuse > SSLv3 with TLSv >=20 >=20 > It's normal that people confuse SSLv3 with TLS. SSL 3.0 was a released and > widely deployed protocol, and the term "SSL" is still widely used today to > refer to TLS. But the situation is much better if we rename TLS 1.3: TLS > 1.3 spec has not been released, it is not supported by any non-testing > clients or servers, and there are not many documents, papers or blogs > mentioning TLS 1.3. This is why I said "TLS 1.3" is similar to "Windows 9" > in terms of naming. it's not, Microsoft didn't release anything similar to Windows that would h= ave=20 "9" or "10" in the name (even DOS stopped at 6). But there was both SSLv2 a= nd=20 SSLv3. It's closer to the RHL 7 (Red Hat Linux) being confused with RHEL 7 (Red Ha= t=20 Enterprise Linux), and yes, it's still happening the problem is not that people will not know when you talk about TLSv2.0 yo= u=20 mean TLSv1.3 (or vice versa). The problem is that people will think that wh= en=20 you talk about TLSv2.0 you mean SSLv2 *because* people use the SSL and TLS= =20 terms interchangeably! > > if the WG really wants a TLSvX.0 name, the X really should be bigger th= an > > 3 =20 >=20 >=20 > Well, I prefer TLS 2.0, because it sounds more natural that major version= 2 > comes after major version 1. But TLS {>3}.0 is also fine to me, if the WG > thinks people may get confused between SSL 2.0 and TLS 2.0. =20 > Xiaoyin =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1813493.Ln0pRTUV2Q 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 iQIcBAABCgAGBQJXxrWyAAoJEJKo0bgB0vX1/1UP+wTQ19v4PLxf0Oo8JWdC1IOE /Vq053VM31iwWus3f3ID/bhWpsF1x6WUEurA0AJsNBYYWAMQmkuwgiSvogOJxPa+ /v5TDNloQ6rHEBWR4ZES6uxA2bNakOdzv8RwXn4PhJl4u208LbFmE3bQDQtNsepw MjT9x/TJsoRs+SL3R1wPNaf1Lje+PmbhPTdkLR9F943iW89sVZGuo0XFrpifa8M2 7sHEXdPzGfPyEfF3WQBjGo0Nit/8LTxQLBR8TResCapeNo8MpusUX9BU7ps3NWdC c4wtKSGNYya6iFTh2SFnL4Us6x2cubGcy5uaVlb+NGdQdU0H+wTuDBxI6g9i3qqX wpaUs/zkjHj1xqJxWPvITs9gx06bTQfjwG3lodHTMsAw/VDnU35HBbCQ1kBqZgPP E31HVqaDNm+JmJRNxtKPaEkJcSCW11n/ECmzY3ZpoESH4CZh1v3sLi3KNCHPHe0Q p+c4MOYPuTft1ojcpA8uinOKH+YpPfVF/QYBtazD/22pmeqpPJk11Amlr2/wEuPZ UDdYsNLbAktropUGZYCZsPGQaCT+DgIZLxNUyF2rFnjHdDrh4Rw4IsMcL/Yi2HLd sEH7H05W2p66mynvhM0Uvn3yCZQU3IHB7IkRXTdQTNnHb3TmhNRhEFmJyJfA+m7f ZPUHmq06XSe5PWhN0QVA =486k -----END PGP SIGNATURE----- --nextPart1813493.Ln0pRTUV2Q-- From nobody Wed Aug 31 07:09:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFFF12DC0D for ; Wed, 31 Aug 2016 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgTxNdiA-bjZ for ; Wed, 31 Aug 2016 07:09:41 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8559712DC7C for ; Wed, 31 Aug 2016 06:53:46 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 8D918F98B; Wed, 31 Aug 2016 09:53:45 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A03C2201E8; Tue, 30 Aug 2016 17:21:24 -0400 (EDT) From: Daniel Kahn Gillmor To: Hubert Kario , tls@ietf.org In-Reply-To: <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> User-Agent: Notmuch/0.22.1+88~g8d09e96 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 30 Aug 2016 17:21:21 -0400 Message-ID: <878tvex8a6.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] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 14:09:46 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue 2016-08-30 16:14:06 -0400, Hubert Kario wrote: > On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: >> * Keep the version ID as { 3, 4 } (already weird counting; changing risks >> more intolerance)=20 > > IMNSHO this alone is enough of a reason not to do this > > it's enough explaining to people that SSLv3.3 is really TLSv1.2, now we'l= l=20 > have SSLv3.4 =3D=3D TLSv1.3 =3D=3D TLSv2.0 > > it's silly at this point Who are you talking to who's fine with looking at the bytes on the wire but isn't fine with understanding that a 16-bit field might not map directly to our imagination of decimal? If that mapping really matters, We could combine this with Erik Nygren's version inflation suggestion and just jump straight to TLS 34 :P https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml doesn't have a "TLS version" registry. Would it be simpler to have IANA create that and just populate it with: Value | Description | Reference ------+-------------+---------- 0x30 | SSLv3 | RFC 6101, RFC 7568 0x31 | TLSv1.0 | RFC 2246 0x32 | TLSv1.1 | RFC 4346 0x33 | TLSv1.2 | RFC 5246 0x34 | TLSv4 | RFC XXXX Then you could tell people to just look it up in the table. --dkg, tongue only marginally in cheek --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJXxfjRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKPWMQAIJE2zq0SsLS7ebLcWo04Lc7 COcCi5HziDezYndRSPAWHtWPCcphGmGWBmgP3FqaiqT/nS9QZqK7y4KrHo8w43b9 ydo2QUWdWO14abym9jS9yuIJdb6hDWFNwIPYUn7uRcwCLff/bBEqKrimX6JXE31z GwmHSfZxAfaJmvL2w5T4mXuvpKjHKNoutrKf2kb5zsweEqb+RzZFRqUWFzY5Vh1g VlhCyPqB6kv+P/GxdR06s4/CJ5JKaze23EJONgL7VWNLhxqljEtWx8zLA5MPqHN2 gxUCbG5D7+hXmb0rbBFZDNO7xDsItACRMsfAHPrCU02CP+d6W8CX06DSaBhCd2GK 087jX9H8VZdbgi4rsGVUtRgL0Nuvs2KAVvbGqknVSwu5KP1v6Lj2Z+cbuNSHVvuX AiQMfWmvZjH7LV7w+IQqyCWYL5wCsvWamxSGwp2f6EwJ9KH7ZjNzAYavAnntHXAZ 6uEwhLHzFin/+AIrnIwKbggKWJzCudoN9aqrUF6ltdvb4s/fPZBNU/IAOICh1lJF aP6j6VP3KRPWHZj2H5RVvFd4XYsReTzo8/mlkqHkMN2/OpYxYBNQF+cv7A5c6KlS XKVDFQaY9UnMQ4S57Zp5UpbeouKUFHy887ExlCire53x8VQWWo2Io1zpb8SH9R2A myTKB2KyxYiLH/CIIEKd =bquT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 31 07:42:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2B812DCE8 for ; Wed, 31 Aug 2016 07:42: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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9bj1sy0CLOf for ; Wed, 31 Aug 2016 07:42:09 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4657112DC40 for ; Wed, 31 Aug 2016 07:17:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C393FE2048; Wed, 31 Aug 2016 10:17:30 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26909-08; Wed, 31 Aug 2016 10:17:26 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:2001:470:e448:2:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 79176E2047; Wed, 31 Aug 2016 10:17:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1472653046; bh=Nd0TSGqcKhRApTY6Uf8zNgvF2DR68SIzcCLcicaZdcw=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=oj6qj9sehM6n3TUXINGqeqrJzp09wAjG+febhxFVCfBYRpOB9l4RmvrZlW6rP4040 Bc2nDfDYA/ZX0Uql7CLy5HGqHz2/zrhXzH9fJx3sVRTzBxhWCOxa9W9EawYVYATosC xx+iju8m9HQz9Rp6GhAXYHqJClQFI9jaJr8KgFpk= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u7VEHPY4021937; Wed, 31 Aug 2016 10:17:25 -0400 From: Derek Atkins To: "Steven M. Bellovin" References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <89A46793-73A1-4C71-9954-37BF6ED6F297@callas.org> <5CF32AA8-59CC-4918-8951-A2ACBD233C19@cs.columbia.edu> Date: Wed, 31 Aug 2016 10:17:25 -0400 In-Reply-To: <5CF32AA8-59CC-4918-8951-A2ACBD233C19@cs.columbia.edu> (Steven M. Bellovin's message of "Mon, 29 Aug 2016 21:21:38 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: David McGrew , "cfrg@irtf.org" , Jon Callas , tls@ietf.org Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 14:42:13 -0000 "Steven M. Bellovin" writes: > Yes. To a large extent, the "IoT devices are too puny for real > crypto" is a hangover from several years ago. It was once true; for > the most part, it isn't today, but people haven't flushed their cache > from the old received wisdom. This is certainly true for AES, mostly because many small chips are including AES accelerators in hardware. It's not quite true for public key solutions; there are still very small devices where even ECC takes too long (and yes, there are cases where 200-400ms is still too long). > It pays to look again at David Wagner's slides from 2005, on sensor > nets and crypto: > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 31 07:50:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E8012D151 for ; Wed, 31 Aug 2016 07:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-aVJcnDum2A for ; Wed, 31 Aug 2016 07:50:05 -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 42C6512D5CE for ; Wed, 31 Aug 2016 07:25:44 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D231F3F402C; Wed, 31 Aug 2016 14:25:37 +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 BB2423F4018; Wed, 31 Aug 2016 14:25:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472653537; bh=GxRRGxosrY291WDtZtFVIZWicYivius7cQwTmNWx6s4=; l=580; h=From:To:Date:References:In-Reply-To:From; b=yPHdkHBfgzmusvPpf/NgJqokWaZnac6DFRlTVvcgJNkys68jLwDEVq3LTMdTVSp2l fPobrZkdZaVEvZa5aouziosZjPumR0Mtf885BJrpXFzMQ2KtQ5l5qkbGlFHbp9FRug vToymU/F+dUnNf4RZeN+ECE1AXcqXcc9YTOCH1nw= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id B761B1FC8E; Wed, 31 Aug 2016 14:25:37 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 Aug 2016 10:25:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 31 Aug 2016 10:25:37 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 -> TLS 2.0? Thread-Index: AQHSAvsfpppC6VBs5E+wcHnswhmM4qBiRgCAgADa8ZA= Date: Wed, 31 Aug 2016 14:25:37 +0000 Message-ID: References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> <878tvex8a6.fsf@alice.fifthhorseman.net> In-Reply-To: <878tvex8a6.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.41.161] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 14:50:10 -0000 > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml > doesn't have a "TLS version" registry. Would it be simpler to have IANA > create that and just populate it with: >=20 > Value | Description | Reference > ------+-------------+---------- > 0x30 | SSLv3 | RFC 6101, RFC 7568 > 0x31 | TLSv1.0 | RFC 2246 > 0x32 | TLSv1.1 | RFC 4346 > 0x33 | TLSv1.2 | RFC 5246 > 0x34 | TLSv4 | RFC XXXX YES. Do this no matter what the last Description value ends up being. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Wed Aug 31 08:24:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6164D12D67F for ; Wed, 31 Aug 2016 08:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUK1Zy8AVtDY for ; Wed, 31 Aug 2016 08:24:17 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 8574E12DBE6 for ; Wed, 31 Aug 2016 07:55:27 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id i5so94785288wmg.0 for ; Wed, 31 Aug 2016 07:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=A7oCNE3QaSzY+IuKdNXN9ZWE12uEBAOwpY2XGEsGv0o=; b=PhIQFFIXk+lZCO0mZl++5L3i39JZK4MfN/jT0ZvmQb1h5HvP8u25lvkhkvnP4Z2o3e aQ9IK3B2Q68R7ZuB3nX9RVIBWmoQDPM5bfXiyNGPpkQXu5gy+AME8ZUP2VyJP0lynWtt jQMJ+VH8tgVqAo+tzXF27tv9/qa1iCDifE8/ewYlgmU/xxwZ1/wxEkeNbvQ0Zlum+QnD ZQsl5QTlJd1JCl4fIulo5WdwT4fdp/CLsubFbO1PwKQeEutixF3BUEfUGLJum1UZc3sG jyKM2wmIJ/HMhwO+R+LUNMdLP+oPnCp9B2Cxdx+Tnbs3cTwyzJ6VuMGik471rDLS+ECc YE3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=A7oCNE3QaSzY+IuKdNXN9ZWE12uEBAOwpY2XGEsGv0o=; b=dh25guGSvNToHvXNJou3/AxqAqdAZ+Wj23UnWWb1I6LxBTULRfZOFrv1n0yw1XEAuc qt+Tbn1zI4I/86wX4tBNn3QsMHB0NNIZymqIbZ45SIHLYlkeUMuNmMny27BMsGWsHV5P VemsyFBKROJjMnJ2SLG/cBDSNxXC9lf7YMJvNQykMUeIv075DwXGuovyL3x0R+BzPKFy kIxcJuLGecE6zI71elsPIGpZ4gqsDbSibmMdnZu2dDx2crpVp/mmEHXskSm+27cL0fie dD/sKWqY3nmhEs2240F5O0k0j+rQPW+58st+Wd1mV+Eft0xbQkgmZAFNzzdHUp5AvCyc VL+w== X-Gm-Message-State: AE9vXwOSfyYyMlhn59JFEgT8Zek6jkbM5sAmjsUqCq3obb1SBZpTESyz8zFis90+rDqlcA== X-Received: by 10.194.38.137 with SMTP id g9mr9298983wjk.107.1472655326007; Wed, 31 Aug 2016 07:55:26 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id cw7sm235117wjb.38.2016.08.31.07.55.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 07:55:25 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DBBD145D-21CD-47CE-A225-A7F54F3A19CE"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Yoav Nir In-Reply-To: <878tvex8a6.fsf@alice.fifthhorseman.net> Date: Wed, 31 Aug 2016 17:55:29 +0300 Message-Id: References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> <878tvex8a6.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 15:24:21 -0000 --Apple-Mail=_DBBD145D-21CD-47CE-A225-A7F54F3A19CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 31 Aug 2016, at 12:21 AM, Daniel Kahn Gillmor = wrote: >=20 > On Tue 2016-08-30 16:14:06 -0400, Hubert Kario wrote: >> On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: >>> * Keep the version ID as { 3, 4 } (already weird counting; changing = risks >>> more intolerance) >>=20 >> IMNSHO this alone is enough of a reason not to do this >>=20 >> it's enough explaining to people that SSLv3.3 is really TLSv1.2, now = we'll >> have SSLv3.4 =3D=3D TLSv1.3 =3D=3D TLSv2.0 >>=20 >> it's silly at this point >=20 > Who are you talking to who's fine with looking at the bytes on the = wire > but isn't fine with understanding that a 16-bit field might not map > directly to our imagination of decimal? No they don=E2=80=99t always look at the 16-bit field (although they = might), but they look at you funny when you tell them that 1.0 > 3.0 and = that you should totally disable 3.0 and prefer to use 1.2 instead. --Apple-Mail=_DBBD145D-21CD-47CE-A225-A7F54F3A19CE 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----- iQEcBAEBCAAGBQJXxu/iAAoJECXR4BOacZZUuccH/2axEiucJAWcX6s2MwGZwfcL q09bZJ4VDUI+XHtu04OoAlX6xCrvnA/kJTafIhRGoOrXc3/wQfzYUjVjAvzzuPCO /TWtZOagOL1I1aDPy0LAfqVb9a+sHTUvLJYbR/Z6RxQE/bQyGmQET2W3Z13bpoZ9 JprI2YceDk6T/i2sysTDITUl12aTy0ydGyJ16IwkTHIAtFrXBCN43gsD1rYFZ79o BpkvRWIurIU9vwQIdOo2qwmUgIfra39LZcd/um1SSnyKOISB9zsKWspTj14RpgQj NAAsZzXuYFMqZ0NKybyetkwwLw4VI+/Awlu/PfS0cSgUsI/OgVnXu6qkQBLnl8w= =ulXj -----END PGP SIGNATURE----- --Apple-Mail=_DBBD145D-21CD-47CE-A225-A7F54F3A19CE-- From nobody Wed Aug 31 08:40:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DFC12D179 for ; Wed, 31 Aug 2016 08:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZyU0K7tAexB for ; Wed, 31 Aug 2016 08:40:34 -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 9EDC912D54D for ; Wed, 31 Aug 2016 08:21:54 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id v123so54565874qkh.2 for ; Wed, 31 Aug 2016 08:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R0mwvGHznfYNaeJcNnplJ2itGGicltf5vg457RnNfq4=; b=M8WwwOiOV+8bawLIk5QIoFhZ+0TEqUMLX3IU0SiabPC94QcbfY4NMk/FXWgJnac7iR l7WmmqWMaU3XOiaWeNkUJvmvLQAurupKbyyirV+osP0lWJtStUO3Gy70qN9r58blb5DP C0I/5z9w6e91BrRn+OIghyv1b4R4HVvCw2HkrZn/GdGFLx+KGd8SZ7r9Ll9r6tC6PbHz QIUP3BiOCS09cmssYjidLDzKIeRoCycsp606H5HtH1Moz+dH7l7w63I7tqfVlyVPL/e6 5GWFYb2FYFRwHAexJycDjjienbCMFBzvOw74tdFBYye9dPn8uaTtzrBeSkgcQf1w3eAq BTmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R0mwvGHznfYNaeJcNnplJ2itGGicltf5vg457RnNfq4=; b=STqEyYu3XIiibIbMbn5ZtPYRsX7VBB7oQqEKOBQamhX678iwOEmoLWniCD0W6ZYhvr raUW4t3n0CAtieigt5/hutveJHDqjlmtLOZC8tGrqlCDtnkWtJcVtJwc2sBz8sQzyyfR LELTWXbuKXd6AxhL49EKDQXX/wjJCmHNhgAQI56oynRcBZfG4N9o0zG6CNPXU9cgIiaC WvKj7HboVPMaWbM3jGlF7NPMoRIhO1Gbe/DXH51wSuaAKV5QzNDiWh43H8xex0QQu2Zo 7TS2krQIzy2kXhnYbta7Jpfy+LOleBpSFqiaS8TZk/ISDdSTRqhLC8t4+S2V+CtqEO70 BNZA== X-Gm-Message-State: AE9vXwOT/aEWo7gd9Eyi3zViVWVI6491XMH00Ns+KOzYAyeStzhW2Dtg3uuUd6eK8XP8kz4ZhWOI3vpRrJFIAw== X-Received: by 10.55.11.131 with SMTP id 125mr10856299qkl.169.1472656913853; Wed, 31 Aug 2016 08:21:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Wed, 31 Aug 2016 08:21:53 -0700 (PDT) In-Reply-To: <52BDE689-120E-4F95-98B9-1D83B1097B2B@sn3rd.com> References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> <1470148363699.24362@bosch.com> <4ff68fa1-0d8e-ed1e-064c-8bb5bbf5935a@akamai.com> <1470232754152.68803@bosch.com> <52BDE689-120E-4F95-98B9-1D83B1097B2B@sn3rd.com> From: Martin Thomson Date: Thu, 1 Sep 2016 01:21:53 +1000 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 15:40:39 -0000 On 26 August 2016 at 06:43, Sean Turner wrote: > Any more thoughts on these? I have no problem with implementations that don't use R-I (in either extension or SCSV form) if they don't intend to ever renegotiate. I know that that disagrees with RFC 5746, but there you have it. From nobody Wed Aug 31 09:04:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57BD12D0D3; Wed, 31 Aug 2016 09:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX-SgXofcMuE; Wed, 31 Aug 2016 09:04:21 -0700 (PDT) Received: from f430.i.mail.ru (f430.i.mail.ru [185.5.136.101]) (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 BE11A12B075; Wed, 31 Aug 2016 09:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=iv3L8Ap8j+0J0/CzBZe3PN+c7WovJhoK/FLOXTG5Mrs=; b=fOt/4PbCENqLwJ8yd6y5hdckD1N9URr+1oNUlR6xLMkiLrPrqKut9zxPLQxSiEEMg/Z/RZdyZ9ZVwPi7DRGiURNwvuQ6UDrqa/ybLkrJlPMz/9Yw18Tw2tEUgweryqIB+5tKJI2zh0sleRQJ9WoAkVXz07cE9v8DVbnDlOinUyY=; Received: from [193.37.157.2] (ident=mail) by f430.i.mail.ru with local (envelope-from ) id 1bf7yd-0003VY-OL; Wed, 31 Aug 2016 19:03:00 +0300 Received: from [193.37.157.2] by e.mail.ru with HTTP; Wed, 31 Aug 2016 19:02:59 +0300 From: =?UTF-8?B?0JXQstCz0LXQvdC40Lkg0JDQu9C10LrRgdC10LXQsg==?= To: =?UTF-8?B?RXJpYyBSZXNjb3JsYQ==?= , =?UTF-8?B?TWloaXIgQmVsbGFyZQ==?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [193.37.157.2] Date: Wed, 31 Aug 2016 19:02:59 +0300 X-Priority: 3 (Normal) Message-ID: <1472659379.924523441@f430.i.mail.ru> Content-Type: multipart/alternative; boundary="--ALT--5gUGANTJBxvYyK2E1zJ1BCxHWrtw0jn31472659379" X-Mailru-Sender: 534CBB7A632DDA3F5EA110A820F45F9DAB11BC7CA93B0BD4A6D8A2E306644B2B1B2587948E2613F0 X-Mras: OK X-Spam: undefined In-Reply-To: <20160828144220.5828688.24760.6532@gmail.com> References: <20160828144220.5828688.24760.6532@gmail.com> Archived-At: Cc: cfrg@irtf.org, =?UTF-8?B?PHRsc0BpZXRmLm9yZz4=?= , =?UTF-8?B?U3RhbmlzbGF2IFYuIFNteXNobHlhZXY=?= Subject: Re: [TLS] =?utf-8?q?=5BCfrg=5D__Document_on_increasing_the_lifetime_o?= =?utf-8?q?f_session_keys?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: =?UTF-8?B?0JXQstCz0LXQvdC40Lkg0JDQu9C10LrRgdC10LXQsg==?= List-Id: "This is the mailing list 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, 31 Aug 2016 16:04:25 -0000 ----ALT--5gUGANTJBxvYyK2E1zJ1BCxHWrtw0jn31472659379 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CkhlbGxvLCBFcmljIGFuZCBNaWhpciEKT25lIG90aGVyIGNvbnNpZGVyYXRpb24gYWJvdXQgdGhl IGNvbm5lY3Rpb24gYmV0d2VlbiBrZXkgbWVzaGluZyBhbmQgdXNhZ2Ugb2YgS0RGcyAod2l0aCBz ZXNzaW9uIGtleXMgZGVyaXZlZCBmcm9tIGEgbWFzdGVyIGtleSBpbiB0aGUgbW9tZW50IG9mIOKA nEtleSB1cGRhdGXigJ0pOiB0aGV5IGNhbiAoYW5kIGluIGEgbG90IG9mIGNhc2VzIHRoZXkgc2hv dWxkKSBiZSB1c2VkIHRvZ2V0aGVyLCBpZiB5b3UgaGF2ZSByZWFsbHkgc3RyaWN0IGxpbWl0YXRp b25zIG9uIGtleSBsaWZldGltZS4gSW4gdGhlc2UgY2FzZXMgS0RGIG1heSBiZSB1c2VkIGZvciBk ZXJpdmluZyBrZXlzIGZvciB0aGUgbWVzc2FnZSAob3IgcGFja2V0IG9yIHNvbWUgb3RoZXIgYmxv Y2sgb2YgZGF0YSB0aGF0IGlzIHRvIGJlIGhhbmRsZWQgc2VwYXJhdGVseSkgYW5kIGtleSBtZXNo aW5nIHRvIG1ha2UgaXQgcG9zc2libGUgdG8gaGFuZGxlIHJhdGhlciBsb25nIG1lc3NhZ2VzLgpG b3IgZXhhbXBsZSwgaWYgeW91IGhhdmUgdG8gbGltaXQga2V5IHVzYWdlIHdpdGggNCBLQiAoZS5n LiB5b3VyIHBvdGVudGlhbCBhZHZlcnNhcnkgaGFzIHRydWx5IHBvd2VyZnVsIGNhcGFiaWxpdGll cyBvZiBpbnRlcmNlcHRpbmcgc2lkZS1jaGFubmVsIGxlYWthZ2Ugb2YgYSBrZXkgb24gb3BlcmF0 aW9ucyB3aXRoIGl0KSBhbmQgeW91IGhhbmRsZSBtZXNzYWdlcyBvZiB2YXJpYWJsZSBsZW5ndGgs IHlvdSBjYW4gS0RGIGEgbmV3IHNlc3Npb24ga2V5IGZvciBlYWNoIG1lc3NhZ2UgYW5kIHRoZW4g d29yayBhcyB1c3VhbCDigJMga25vd2luZyB0aGF0IHdoZW4gdGhlIGxlbmd0aCBvZiBhIG1lc3Nh Z2UgZXhjZWVkcyA0IEtCLCBrZXkgbWVzaGluZyB3aWxsIHdvcmsgYW5kIHlvdSB3b3VsZCBiZSBh YmxlIHRvIGNvbnRpbnVlIHdvcmtpbmcuIEFuZCBpdOKAmWxsIGJlIGRvbmUgdHJhbnNwYXJlbnRs eSDigJMganVzdCBsaWtlIHlvdSBhcmUgdXNpbmcgYSBtb2RpZmllZCBibG9jayBjaXBoZXIgbW9k ZSwgd2hpY2ggZXhwYW5kcyBrZXkgbGlmZXRpbWUuCk90aGVyd2lzZSB5b3XigJlsbCBoYXZlIGVp dGhlciB0byBsaW1pdCB0aGUgc2l6ZSBvZiBtZXNzYWdlcyAod2hpY2ggaXMgbm90IGFsd2F5cyBz dWl0YWJsZSksIG9yIGdldCBzZXZlcmFsIEtERmVkIHNlc3Npb24ga2V5cyBmcm9tIHRoZSBtYXN0 ZXIga2V5IGZvciBhIG1lc3NhZ2UgaWYgaXTigJlzIGxvbmcgZW5vdWdoIOKAkyB3aGljaCBtZWFu cyBoYXJkIGZyYWdtZW50YXRpb24gb2YgbWVzc2FnZXMgYW5kIGFkZGl0aW9uYWwgY29zdHMgZm9y IHN0YXJ0aW5nL3N0b3BwaW5nIGVuY3J5cHRpb24gdGhyZWFkLgrCoC0twqAgUmVnYXJkcywKRXZn ZW55IEFsZWtzZWV2CkNyeXB0b1BybwoKCj7QktC+0YHQutGA0LXRgdC10L3RjNC1LCAyOCDQsNCy 0LPRg9GB0YLQsCAyMDE2LCAxNzo0MiArMDM6MDAg0L7RgiAiU3RhbmlzbGF2IFYuIFNteXNobHlh ZXYiIDxzbXlzaHN2QGdtYWlsLmNvbT46Cj4KPuKAjkRlYXIgRXJpYywKPgo+VGhhbmsgeW91IGZv ciB5b3VyIGNvbW1lbnQgLSBpbmRlZWQsIHJlLWtleWluZyBtZWNoYW5pc21zIGJhc2VkIG9uIHNl Y3JldCBzdGF0ZSBhcmUgd2lkZWx5IHVzZWQgaW4gdGhlIHByb3RvY29scyAoa2V5IHRyZWVzIGFy ZSB1c3VhbCBwcmFjdGljZSBpbiBFU1Agd2l0aCBHT1NUcyBmb3IgbW9yZSB0aGFuIDEwIHllYXJz LCBmb3IgZXhhbXBsZSkuIE15IHBvaW50IGlzIHRoYXQgYSBzaW1wbGUgKGUuZy4gd2l0aG91dCBh bnkgYWRkaXRpb25hbCBrZXlzIG9yIHN0cnVjdHVyZXMpIGFuZCBlZmZlY3RpdmUgbWVjaGFuaXNt IHRvIGluY3JlYXNlIOKAjmJsb2NrIGNpcGhlciBtb2RlcyBsaW1pdGF0aW9ucyBvbiBwbGFpbnRl eHQgc2l6ZSBjYW4gYmUgaGVscGZ1bCBpdHNlbGYsIHdpdGhvdXQgaW5jb3Jwb3JhdGluZyB0byBh IHByb3RvY29sLsKgCj4KPkFib3V0IGNvbm5lY3Rpb24gd2l0aCBUTFMgMS4zIGRyYWZ0IC0gZm9y IGV4YW1wbGUsIHdlIGRvbid0IHdhbnQgdGhlIEdDTSBtb2RlIGJlIGRlZmluZWQgaW5zaWRlIHNv bWUgcHJvdG9jb2wgUkZDLCBpdCBzaG91bGQgYmUgZGVmaW5lZCBzZXBhcmF0ZWx5LCBpc24ndCBp dD8gwqBTbyB0aGUgcXVlc3Rpb24gaXMgdGhhdCBpZiBzdWNoIG1lY2hhbmlzbXMgYXJlIG5lZWRl ZCwgdGhhbiBzZXBhcmF0ZSBkb2N1bWVudHMgb24gdGhlbSBjYW4gYmUgYSBiZXR0ZXIgc29sdXRp b24uCj4KPkFuZCBteSBwcmltYXJ5IHBvaW50IGhlcmUgaXMgYWJvdXQgc3RhdGVsZXNzIHRlY2hu aXF1ZXM6IGFzIGZvbGxvd3MgZnJvbSB04oCOaGUgcHJlcHJpbnQgSSBjaXRlZCBiZWZvcmUsIHRo ZSBrZXkgbGlmZXRpbWUgZm9yIENUUiBjYW4gYmUgaW5jcmVhc2VkIHF1YWRyYXRpY2FsbHksIGZv ciBleGFtcGxlLsKgCj4KPktpbmRlc3QgcmVnYXJkcywKPlN0YW5pc2xhdgo+Cj7QntGCOiAgRXJp YyBSZXNjb3JsYQo+0J7RgtC/0YDQsNCy0LvQtdC90L46ICDQstC+0YHQutGA0LXRgdC10L3RjNC1 LCAyOCDQsNCy0LPRg9GB0YLQsCAyMDE2wqDQsy4sIDE2OjUyCj7QmtC+0LzRgzogIFN0YW5pc2xh diBWLiBTbXlzaGx5YWV2Cj7QmtC+0L/QuNGPOiAgY2ZyZ0BpcnRmLm9yZzsgTWloaXIgQmVsbGFy ZTsgUGF1bCBMYW1iZXJ0OyBQYXRlcnNvbiwgS2Vubnk7IE1pa2UgSGFtYnVyZzsgPCB0bHNAaWV0 Zi5vcmcgPgo+0KLQtdC80LA6ICBSZTogW1RMU10gRG9jdW1lbnQgb24gaW5jcmVhc2luZyB0aGUg bGlmZXRpbWUgb2Ygc2Vzc2lvbiBrZXlzCj4KPlN0YW5pc2xhdiwKPgo+VExTIDEuMyBpbmNvcnBv cmF0ZXMgYSByZWtleWluZyBtZWNoYW5pc20gKEtleVVwZGF0ZSkgc2ltaWxhciB0byB0aGF0IGlm IEFiZGFsbGEgYW5kIEJlbGxhcmUgMShiKS4KPgo+LUVrcgo+Cj4KPk9uIFN1biwgQXVnIDI4LCAy MDE2IGF0IDM6NDggQU0sIFN0YW5pc2xhdiBWLiBTbXlzaGx5YWV2ICA8IHNteXNoc3ZAZ21haWwu Y29tID4gd3JvdGU6Cj4+RGVhciBjb2xsZWFndWVzLAo+PlNpbmNlIHRoZXJlIGlzIGEgY29uc2lk ZXJhYmxlIGludGVyZXN0IHRvIHRoZSBxdWVzdGlvbiBvZiBpbmNyZWFzaW5nIHNlc3Npb24ga2V5 cyBsaWZldGltZSAoc2V2ZXJhbCBwcm9kdWN0aXZlIG9mZi10aGUtbGlzdCBwZXJzb25hbCBkaXNj dXNzaW9ucyBhYm91dCBDcnlwdG9Qcm8ga2V5IG1lc2hpbmcgYWxnb3JpdGhtcyBhbmTCoCBodHRw Oi8vZXByaW50LmlhY3Iub3JnLzIwMTYvNjI4IMKgc3RhcnRlZCBhZnRlciB0aGUgRnJpZGF5IHBv c3RpbmcpLCBtYXliZSB3ZSBzaG91bGQgdGhpbmsgYWJvdXQgZ2V0dGluZyBzdGFydGVkIGEgd29y ayBvbiBhIGRvY3VtZW50IG9uIGVmZmljaWVudCByZS1rZXlpbmcgKGFib3V0IHRlY2huaXF1ZXMg d2l0aG91dCBzZWNyZXQgc3RhdGUgYW5kL29yIHRlY2huaXF1ZXMgd2l0aCBpdCAobGlrZSBpbiBN LiBBYmRhbGxhIGFuZCBNLiBCZWxsYXJlIHdvcmssICBodHRwczovL2NzZXdlYi51Y3NkLmVkdS9+ bWloaXIvcGFwZXJzL3Jla2V5Lmh0bWwgKSkgbWVjaGFuaXNtcyBmb3IgY29tbW9uIGNpcGhlciBt b2RlcyAoQ1RSLCBDQ00sIEdDTSwgQ0JDLCBDRkIpIGluIENGUkc/wqAKPj5JZiB5b3UgY29uc2lk ZXIgaXQgcmVhc29uYWJsZSwgd2UgY2FuIHByZXBhcmUgYSBmaXJzdCB2ZXJzaW9uIG9mIHN1Y2gg YSBkcmFmdCBiYXNlZCBvbiBvdXIgcmVzdWx0cyAoYm90aCBpbmNsdWRlZCBpbiB0aGF0IG91ciBw cmVwcmludCBhbmQgbmV3IG9uZXMgd2hpY2ggd2UgYXJlIHdvcmtpbmcgb24gY3VycmVudGx5KSBi ZWZvcmUgSUVURiA5NyB0byBiZSBhYmxlIHRvIGhhdmUgYSBkaXNjdXNzaW9uIG9uIHRoaXMgaXNz dWUgdGhlcmUgaW4gU2VvdWwuCj4+S2luZGVzdCByZWdhcmRzLAo+PlN0YW5pc2xhdiBTbXlzaGx5 YWV2Cj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj5U TFMgbWFpbGluZyBsaXN0Cj4+VExTQGlldGYub3JnCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90bHMKPj4KPgo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+Q2ZyZyBtYWlsaW5nIGxpc3QKPkNmcmdAaXJ0Zi5vcmcKPmh0dHBz Oi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZwoK ----ALT--5gUGANTJBxvYyK2E1zJ1BCxHWrtw0jn31472659379 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 CjxIVE1MPjxCT0RZPjxwPkhlbGxvLCBFcmljIGFuZCBNaWhpciE8L3A+PHA+T25lIG90aGVyIGNv bnNpZGVyYXRpb24gYWJvdXQgdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBrZXkgbWVzaGluZyBhbmQg dXNhZ2Ugb2YgS0RGcyAod2l0aCBzZXNzaW9uIGtleXMgZGVyaXZlZCBmcm9tIGEgbWFzdGVyIGtl eSBpbiB0aGUgbW9tZW50IG9mIOKAnEtleSB1cGRhdGXigJ0pOiB0aGV5IGNhbiAoYW5kIGluIGEg bG90IG9mIGNhc2VzIHRoZXkgc2hvdWxkKSBiZSB1c2VkIHRvZ2V0aGVyLCBpZiB5b3UgaGF2ZSBy ZWFsbHkgc3RyaWN0IGxpbWl0YXRpb25zIG9uIGtleSBsaWZldGltZS4gSW4gdGhlc2UgY2FzZXMg S0RGIG1heSBiZSB1c2VkIGZvciBkZXJpdmluZyBrZXlzIGZvciB0aGUgbWVzc2FnZSAob3IgcGFj a2V0IG9yIHNvbWUgb3RoZXIgYmxvY2sgb2YgZGF0YSB0aGF0IGlzIHRvIGJlIGhhbmRsZWQgc2Vw YXJhdGVseSkgYW5kIGtleSBtZXNoaW5nIHRvIG1ha2UgaXQgcG9zc2libGUgdG8gaGFuZGxlIHJh dGhlciBsb25nIG1lc3NhZ2VzLjwvcD48cD5Gb3IgZXhhbXBsZSwgaWYgeW91IGhhdmUgdG8gbGlt aXQga2V5IHVzYWdlIHdpdGggNCBLQiAoZS5nLiB5b3VyIHBvdGVudGlhbCBhZHZlcnNhcnkgaGFz IHRydWx5IHBvd2VyZnVsIGNhcGFiaWxpdGllcyBvZiBpbnRlcmNlcHRpbmcgc2lkZS1jaGFubmVs IGxlYWthZ2Ugb2YgYSBrZXkgb24gb3BlcmF0aW9ucyB3aXRoIGl0KSBhbmQgeW91IGhhbmRsZSBt ZXNzYWdlcyBvZiB2YXJpYWJsZSBsZW5ndGgsIHlvdSBjYW4gS0RGIGEgbmV3IHNlc3Npb24ga2V5 IGZvciBlYWNoIG1lc3NhZ2UgYW5kIHRoZW4gd29yayBhcyB1c3VhbCDigJMga25vd2luZyB0aGF0 IHdoZW4gdGhlIGxlbmd0aCBvZiBhIG1lc3NhZ2UgZXhjZWVkcyA0IEtCLCBrZXkgbWVzaGluZyB3 aWxsIHdvcmsgYW5kIHlvdSB3b3VsZCBiZSBhYmxlIHRvIGNvbnRpbnVlIHdvcmtpbmcuIEFuZCBp dOKAmWxsIGJlIGRvbmUgdHJhbnNwYXJlbnRseSDigJMganVzdCBsaWtlIHlvdSBhcmUgdXNpbmcg YSBtb2RpZmllZCBibG9jayBjaXBoZXIgbW9kZSwgd2hpY2ggZXhwYW5kcyBrZXkgbGlmZXRpbWUu PC9wPjxwPk90aGVyd2lzZSB5b3XigJlsbCBoYXZlIGVpdGhlciB0byBsaW1pdCB0aGUgc2l6ZSBv ZiBtZXNzYWdlcyAod2hpY2ggaXMgbm90IGFsd2F5cyBzdWl0YWJsZSksIG9yIGdldCBzZXZlcmFs IEtERmVkIHNlc3Npb24ga2V5cyBmcm9tIHRoZSBtYXN0ZXIga2V5IGZvciBhIG1lc3NhZ2UgaWYg aXTigJlzIGxvbmcgZW5vdWdoIOKAkyB3aGljaCBtZWFucyBoYXJkIGZyYWdtZW50YXRpb24gb2Yg bWVzc2FnZXMgYW5kIGFkZGl0aW9uYWwgY29zdHMgZm9yIHN0YXJ0aW5nL3N0b3BwaW5nIGVuY3J5 cHRpb24gdGhyZWFkLjwvcD48cD4mbmJzcDstLSZuYnNwOzwvcD5SZWdhcmRzLDxicj5Fdmdlbnkg QWxla3NlZXY8YnI+Q3J5cHRvUHJvPGJyPjxicj48YnI+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl ci1sZWZ0OjFweCBzb2xpZCAjMDg1N0E2OyBtYXJnaW46MTBweDsgcGFkZGluZzowIDAgMCAxMHB4 OyI+CgnQktC+0YHQutGA0LXRgdC10L3RjNC1LCAyOCDQsNCy0LPRg9GB0YLQsCAyMDE2LCAxNzo0 MiArMDM6MDAg0L7RgiAiU3RhbmlzbGF2IFYuIFNteXNobHlhZXYiICZsdDtzbXlzaHN2QGdtYWls LmNvbSZndDs6PGJyPgoJPGJyPgoJPGRpdiBpZD0iIj4KCgoKCgoKCgoKCgoKCgoKCgoKCQoKCgoK CgoKCgoKCgo8ZGl2IGNsYXNzPSJqcy1oZWxwZXIganMtcmVhZG1zZy1tc2ciPgoJPHN0eWxlIHR5 cGU9InRleHQvY3NzIj48L3N0eWxlPgogCTxkaXY+CgkJPGJhc2UgdGFyZ2V0PSJfc2VsZiIgaHJl Zj0iaHR0cHM6Ly9lLm1haWwucnUvIj4KCQkKICAgICAgICAgICAgPGRpdiBpZD0ic3R5bGVfMTQ3 MjM5NTM2NDAwMDAwMDA4NThfQk9EWSI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 IHN0eWxlPSJ3aWR0aDogMTAwJTtmb250LXNpemU6IGluaXRpYWw7Zm9udC1mYW1pbHk6IENhbGli cmksICdTbGF0ZSBQcm8nLCBzYW5zLXNlcmlmLCBzYW5zLXNlcmlmO2NvbG9yOiByZ2IoMzEsIDcz LCAxMjUpO3RleHQtYWxpZ246IGluaXRpYWw7YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+4oCORGVhciBFcmljLDwvZGl2PjxkaXYgc3R5bGU9IndpZHRoOiAxMDAlO2ZvbnQt c2l6ZTogaW5pdGlhbDtmb250LWZhbWlseTogQ2FsaWJyaSwgJ1NsYXRlIFBybycsIHNhbnMtc2Vy aWYsIHNhbnMtc2VyaWY7Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7dGV4dC1hbGlnbjogaW5pdGlh bDtiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YnI+PC9kaXY+PGRpdiBz dHlsZT0id2lkdGg6IDEwMCU7Zm9udC1zaXplOiBpbml0aWFsO2ZvbnQtZmFtaWx5OiBDYWxpYnJp LCAnU2xhdGUgUHJvJywgc2Fucy1zZXJpZiwgc2Fucy1zZXJpZjtjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTt0ZXh0LWFsaWduOiBpbml0aWFsO2JhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPlRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50IC0gaW5kZWVkLCByZS1rZXlpbmcgbWVj aGFuaXNtcyBiYXNlZCBvbiBzZWNyZXQgc3RhdGUgYXJlIHdpZGVseSB1c2VkIGluIHRoZSBwcm90 b2NvbHMgKGtleSB0cmVlcyBhcmUgdXN1YWwgcHJhY3RpY2UgaW4gRVNQIHdpdGggR09TVHMgZm9y IG1vcmUgdGhhbiAxMCB5ZWFycywgZm9yIGV4YW1wbGUpLiBNeSBwb2ludCBpcyB0aGF0IGEgc2lt cGxlIChlLmcuIHdpdGhvdXQgYW55IGFkZGl0aW9uYWwga2V5cyBvciBzdHJ1Y3R1cmVzKSBhbmQg ZWZmZWN0aXZlIG1lY2hhbmlzbSB0byBpbmNyZWFzZSDigI5ibG9jayBjaXBoZXIgbW9kZXMgbGlt aXRhdGlvbnMgb24gcGxhaW50ZXh0IHNpemUgY2FuIGJlIGhlbHBmdWwgaXRzZWxmLCB3aXRob3V0 IGluY29ycG9yYXRpbmcgdG8gYSBwcm90b2NvbC4mbmJzcDs8L2Rpdj48ZGl2IHN0eWxlPSJ3aWR0 aDogMTAwJTtmb250LXNpemU6IGluaXRpYWw7Zm9udC1mYW1pbHk6IENhbGlicmksICdTbGF0ZSBQ cm8nLCBzYW5zLXNlcmlmLCBzYW5zLXNlcmlmO2NvbG9yOiByZ2IoMzEsIDczLCAxMjUpO3RleHQt YWxpZ246IGluaXRpYWw7YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJy PjwvZGl2PjxkaXYgc3R5bGU9IndpZHRoOiAxMDAlO2ZvbnQtc2l6ZTogaW5pdGlhbDtmb250LWZh bWlseTogQ2FsaWJyaSwgJ1NsYXRlIFBybycsIHNhbnMtc2VyaWYsIHNhbnMtc2VyaWY7Y29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7dGV4dC1hbGlnbjogaW5pdGlhbDtiYWNrZ3JvdW5kLWNvbG9yOiBy Z2IoMjU1LCAyNTUsIDI1NSk7Ij5BYm91dCBjb25uZWN0aW9uIHdpdGggVExTIDEuMyBkcmFmdCAt IGZvciBleGFtcGxlLCB3ZSBkb24ndCB3YW50IHRoZSBHQ00gbW9kZSBiZSBkZWZpbmVkIGluc2lk ZSBzb21lIHByb3RvY29sIFJGQywgaXQgc2hvdWxkIGJlIGRlZmluZWQgc2VwYXJhdGVseSwgaXNu J3QgaXQ/ICZuYnNwO1NvIHRoZSBxdWVzdGlvbiBpcyB0aGF0IGlmIHN1Y2ggbWVjaGFuaXNtcyBh cmUgbmVlZGVkLCB0aGFuIHNlcGFyYXRlIGRvY3VtZW50cyBvbiB0aGVtIGNhbiBiZSBhIGJldHRl ciBzb2x1dGlvbi48c3BhbiBzdHlsZT0iZm9udC1zaXplOiBpbml0aWFsO2xpbmUtaGVpZ2h0OiBp bml0aWFsO3RleHQtYWxpZ246IGluaXRpYWw7Ij48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0id2lk dGg6IDEwMCU7Zm9udC1zaXplOiBpbml0aWFsO2ZvbnQtZmFtaWx5OiBDYWxpYnJpLCAnU2xhdGUg UHJvJywgc2Fucy1zZXJpZiwgc2Fucy1zZXJpZjtjb2xvcjogcmdiKDMxLCA3MywgMTI1KTt0ZXh0 LWFsaWduOiBpbml0aWFsO2JhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxi cj48L2Rpdj48ZGl2IHN0eWxlPSJ3aWR0aDogMTAwJTtmb250LXNpemU6IGluaXRpYWw7Zm9udC1m YW1pbHk6IENhbGlicmksICdTbGF0ZSBQcm8nLCBzYW5zLXNlcmlmLCBzYW5zLXNlcmlmO2NvbG9y OiByZ2IoMzEsIDczLCAxMjUpO3RleHQtYWxpZ246IGluaXRpYWw7YmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyI+QW5kIG15IHByaW1hcnkgcG9pbnQgaGVyZSBpcyBhYm91dCBz dGF0ZWxlc3MgdGVjaG5pcXVlczogYXMgZm9sbG93cyBmcm9tIHTigI5oZSBwcmVwcmludCBJIGNp dGVkIGJlZm9yZSwgdGhlIGtleSBsaWZldGltZSBmb3IgQ1RSIGNhbiBiZSBpbmNyZWFzZWQgcXVh ZHJhdGljYWxseSwgZm9yIGV4YW1wbGUuJm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0id2lkdGg6IDEw MCU7Zm9udC1zaXplOiBpbml0aWFsO2ZvbnQtZmFtaWx5OiBDYWxpYnJpLCAnU2xhdGUgUHJvJywg c2Fucy1zZXJpZiwgc2Fucy1zZXJpZjtjb2xvcjogcmdiKDMxLCA3MywgMTI1KTt0ZXh0LWFsaWdu OiBpbml0aWFsO2JhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgJ1NsYXRlIFBybycsIHNhbnMtc2VyaWYsIHNhbnMt c2VyaWY7Zm9udC1zaXplOiBpbml0aWFsO3RleHQtYWxpZ246IGluaXRpYWw7bGluZS1oZWlnaHQ6 IGluaXRpYWw7Ij48YnI+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9IndpZHRoOiAxMDAlO2ZvbnQt c2l6ZTogaW5pdGlhbDtmb250LWZhbWlseTogQ2FsaWJyaSwgJ1NsYXRlIFBybycsIHNhbnMtc2Vy aWYsIHNhbnMtc2VyaWY7Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7dGV4dC1hbGlnbjogaW5pdGlh bDtiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksICdTbGF0ZSBQcm8nLCBzYW5zLXNlcmlmLCBzYW5zLXNlcmlmO2Zv bnQtc2l6ZTogaW5pdGlhbDt0ZXh0LWFsaWduOiBpbml0aWFsO2xpbmUtaGVpZ2h0OiBpbml0aWFs OyI+S2luZGVzdCByZWdhcmRzLDwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJ3aWR0aDogMTAwJTtm b250LXNpemU6IGluaXRpYWw7Zm9udC1mYW1pbHk6IENhbGlicmksICdTbGF0ZSBQcm8nLCBzYW5z LXNlcmlmLCBzYW5zLXNlcmlmO2NvbG9yOiByZ2IoMzEsIDczLCAxMjUpO3RleHQtYWxpZ246IGlu aXRpYWw7YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCAnU2xhdGUgUHJvJywgc2Fucy1zZXJpZiwgc2Fucy1zZXJp Zjtmb250LXNpemU6IGluaXRpYWw7dGV4dC1hbGlnbjogaW5pdGlhbDtsaW5lLWhlaWdodDogaW5p dGlhbDsiPlN0YW5pc2xhdjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJ3aWR0aDogMTAwJTtmb250 LXNpemU6IGluaXRpYWw7Zm9udC1mYW1pbHk6IENhbGlicmksICdTbGF0ZSBQcm8nLCBzYW5zLXNl cmlmLCBzYW5zLXNlcmlmO2NvbG9yOiByZ2IoMzEsIDczLCAxMjUpO3RleHQtYWxpZ246IGluaXRp YWw7YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpLCAnU2xhdGUgUHJvJywgc2Fucy1zZXJpZiwgc2Fucy1zZXJpZjtm b250LXNpemU6IGluaXRpYWw7dGV4dC1hbGlnbjogaW5pdGlhbDtsaW5lLWhlaWdodDogaW5pdGlh bDsiPjxicj48L3NwYW4+PC9kaXY+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0YWJsZSB3aWR0aD0iMTAwJSIgc3R5bGU9ImJh Y2tncm91bmQtY29sb3I6d2hpdGU7Ym9yZGVyLXNwYWNpbmc6MHB4OyIgY2xhc3M9Im1jZUl0ZW1U YWJsZSI+IDx0Ym9keT48dHI+PHRkIGNvbHNwYW49IjIiIHN0eWxlPSJmb250LXNpemU6IGluaXRp YWw7dGV4dC1hbGlnbjogaW5pdGlhbDtiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1 NSk7Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6 IHNvbGlkIG5vbmUgbm9uZTtib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7Ym9y ZGVyLXRvcC13aWR0aDogMXB0O3BhZGRpbmc6IDNwdCAwaW4gMGluO2ZvbnQtZmFtaWx5OiBUYWhv bWEsICdCQiBBbHBoYSBTYW5zJywgJ1NsYXRlIFBybyc7Zm9udC1zaXplOiAxMHB0OyI+ICA8ZGl2 PjxiPtCe0YI6IDwvYj5FcmljIFJlc2NvcmxhPC9kaXY+PGRpdj48Yj7QntGC0L/RgNCw0LLQu9C1 0L3QvjogPC9iPtCy0L7RgdC60YDQtdGB0LXQvdGM0LUsIDI4INCw0LLQs9GD0YHRgtCwIDIwMTYm bmJzcDvQsy4sIDE2OjUyPC9kaXY+PGRpdj48Yj7QmtC+0LzRgzogPC9iPlN0YW5pc2xhdiBWLiBT bXlzaGx5YWV2PC9kaXY+PGRpdj48Yj7QmtC+0L/QuNGPOiA8L2I+Y2ZyZ0BpcnRmLm9yZzsgTWlo aXIgQmVsbGFyZTsgUGF1bCBMYW1iZXJ0OyBQYXRlcnNvbiwgS2Vubnk7IE1pa2UgSGFtYnVyZzsg Jmx0OzxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT4mZ3Q7PC9k aXY+PGRpdj48Yj7QotC10LzQsDogPC9iPlJlOiBbVExTXSBEb2N1bWVudCBvbiBpbmNyZWFzaW5n IHRoZSBsaWZldGltZSBvZiBzZXNzaW9uIGtleXM8L2Rpdj48L2Rpdj48L3RkPjwvdHI+PC90Ym9k eT48L3RhYmxlPjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lO2JvcmRl ci10b3AtY29sb3I6IHJnYigxODYsIDE4OCwgMjA5KTtib3JkZXItdG9wLXdpZHRoOiAxcHQ7Zm9u dC1zaXplOiBpbml0aWFsO3RleHQtYWxpZ246IGluaXRpYWw7YmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyI+PC9kaXY+PGJyPjxkaXY+PGRpdiBkaXI9Imx0ciI+U3RhbmlzbGF2 LDxkaXY+PGJyPjwvZGl2PjxkaXY+VExTIDEuMyBpbmNvcnBvcmF0ZXMgYSByZWtleWluZyBtZWNo YW5pc20gKEtleVVwZGF0ZSkgc2ltaWxhciB0byB0aGF0IGlmIEFiZGFsbGEgYW5kIEJlbGxhcmUg MShiKS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi1Fa3I8L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2Pjxicj48ZGl2Pk9uIFN1biwgQXVnIDI4LCAyMDE2IGF0IDM6NDggQU0sIFN0YW5pc2xhdiBW LiBTbXlzaGx5YWV2IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNteXNoc3ZA Z21haWwuY29tIj5zbXlzaHN2QGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgZGlyPSJsdHIiPjxkaXY+PGRpdiBkYXRhLXNtYXJ0 bWFpbD0iZ21haWxfc2lnbmF0dXJlIj48ZGl2IGRpcj0ibHRyIj48cD5EZWFyIGNvbGxlYWd1ZXMs PC9wPjxwPlNpbmNlIHRoZXJlIGlzIGEgY29uc2lkZXJhYmxlIGludGVyZXN0IHRvIHRoZSBxdWVz dGlvbiBvZiBpbmNyZWFzaW5nIHNlc3Npb24ga2V5cyBsaWZldGltZSAoc2V2ZXJhbCBwcm9kdWN0 aXZlIG9mZi10aGUtbGlzdCBwZXJzb25hbCBkaXNjdXNzaW9ucyBhYm91dCBDcnlwdG9Qcm8ga2V5 IG1lc2hpbmcgYWxnb3JpdGhtcyBhbmQmbmJzcDs8YSBocmVmPSJodHRwOi8vZXByaW50LmlhY3Iu b3JnLzIwMTYvNjI4IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDE2 LzYyODwvYT4mbmJzcDtzdGFydGVkIGFmdGVyIHRoZSBGcmlkYXkgcG9zdGluZyksIG1heWJlIHdl IHNob3VsZCB0aGluayBhYm91dCBnZXR0aW5nIHN0YXJ0ZWQgYSB3b3JrIG9uIGEgZG9jdW1lbnQg b24gZWZmaWNpZW50IHJlLWtleWluZyAoYWJvdXQgdGVjaG5pcXVlcyB3aXRob3V0IHNlY3JldCBz dGF0ZSBhbmQvb3IgdGVjaG5pcXVlcyB3aXRoIGl0IChsaWtlIGluIE0uIEFiZGFsbGEgYW5kIE0u IEJlbGxhcmUgd29yaywgPGEgaHJlZj0iaHR0cHM6Ly9jc2V3ZWIudWNzZC5lZHUvfm1paGlyL3Bh cGVycy9yZWtleS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jc2V3ZWIudWNzZC5lZHUv fm1paGlyL3BhcGVycy9yZWtleS5odG1sPC9hPikpIG1lY2hhbmlzbXMgZm9yIGNvbW1vbiBjaXBo ZXIgbW9kZXMgKENUUiwgQ0NNLCBHQ00sIENCQywgQ0ZCKSBpbiBDRlJHPyZuYnNwOzwvcD48cD5J ZiB5b3UgY29uc2lkZXIgaXQgcmVhc29uYWJsZSwgd2UgY2FuIHByZXBhcmUgYSBmaXJzdCB2ZXJz aW9uIG9mIHN1Y2ggYSBkcmFmdCBiYXNlZCBvbiBvdXIgcmVzdWx0cyAoYm90aCBpbmNsdWRlZCBp biB0aGF0IG91ciBwcmVwcmludCBhbmQgbmV3IG9uZXMgd2hpY2ggd2UgYXJlIHdvcmtpbmcgb24g Y3VycmVudGx5KSBiZWZvcmUgSUVURiA5NyB0byBiZSBhYmxlIHRvIGhhdmUgYSBkaXNjdXNzaW9u IG9uIHRoaXMgaXNzdWUgdGhlcmUgaW4gU2VvdWwuPGJyPjwvcD48ZGl2PktpbmRlc3QgcmVnYXJk cyw8L2Rpdj48ZGl2PlN0YW5pc2xhdiBTbXlzaGx5YWV2PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ CjwvZGl2Pgo8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+ClRMUyBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmci PlRMU0BpZXRmLm9yZzwvYT48YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnI+Cjxicj48L2Jsb2NrcXVv dGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2Pgo8YnI+PC9kaXY+Cgo8L2Rpdj4KICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICA8ZGl2Pl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpDZnJnIG1haWxpbmcgbGlzdDxi cj4KPGEgaHJlZj0ibWFpbHRvOkNmcmdAaXJ0Zi5vcmciPkNmcmdAaXJ0Zi5vcmc8L2E+PGJyPgo8 YSBocmVmPSJodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmciIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nmcmc8L2E+ PGJyPgo8L2Rpdj4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgCiAgICAgICAgCgkJPGJh c2UgdGFyZ2V0PSJfc2VsZiIgaHJlZj0iaHR0cHM6Ly9lLm1haWwucnUvIj4KCTwvZGl2PgoKCQo8 L2Rpdj4KCgo8L2Rpdj4KPC9ibG9ja3F1b3RlPgo8YnI+PC9CT0RZPjwvSFRNTD4K ----ALT--5gUGANTJBxvYyK2E1zJ1BCxHWrtw0jn31472659379-- From nobody Wed Aug 31 09:08:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D0912D0A0 for ; Wed, 31 Aug 2016 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 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_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN8DCHrOV4zv for ; Wed, 31 Aug 2016 09:08:03 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id B805012D1D5 for ; Wed, 31 Aug 2016 09:06:26 -0700 (PDT) Received: (qmail 28024 invoked by uid 0); 31 Aug 2016 16:06:24 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 31 Aug 2016 16:06:24 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id ds5W1t00c2UhLwi01s5ZSj; Wed, 31 Aug 2016 10:05:37 -0600 X-Authority-Analysis: v=2.1 cv=BO0g8jgG c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=77f3tqhD720A:10 a=7z1cN_iqozsA:10 a=I0CVDw5ZAAAA:8 a=sflH_3mnCkT-QSPtHskA:9 a=QEXdDO2ut3YA:10 a=YdXdGVBxRxTCRzIkH2Jn:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=VrWc3k+/oBLlAI/b5DpZy4vn998srlUD9do/EUuNsRw=; b=aJ2uue3Z4n3+W+MKPRLPgAYrKW O3NaOe1AnANHYja0o4fVlbRuDqpCAEshHPAJ/jFik1SlrTRFweoQUTRa+bIigQjqgXJMV3OxM5O2m uRHpgRj7dOjnJEu3NBlgNGyut; Received: from [173.224.162.69] (port=8962 helo=[10.225.80.36]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1bf816-0007Pa-7Q for tls@ietf.org; Wed, 31 Aug 2016 10:05:32 -0600 To: IETF TLS WG From: =JeffH Message-ID: Date: Wed, 31 Aug 2016 09:05:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 173.224.162.69 authed with jeff.hodges+kingsmountain.com} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-Source-IP: 173.224.162.69 X-Exim-ID: 1bf816-0007Pa-7Q X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.36]) [173.224.162.69]:8962 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 16:08:07 -0000 +10k Rich Salz responded: > DKG proposed: >> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml >> doesn't have a "TLS version" registry. Would it be simpler to have IANA >> create that and just populate it with: >> >> Value | Description | Reference >> ------+-------------+---------- >> 0x30 | SSLv3 | RFC 6101, RFC 7568 >> 0x31 | TLSv1.0 | RFC 2246 >> 0x32 | TLSv1.1 | RFC 4346 >> 0x33 | TLSv1.2 | RFC 5246 >> 0x34 | TLSv4 | RFC XXXX > > YES. Do this no matter what the last Description value ends up being. From nobody Wed Aug 31 09:25:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD512D1A2 for ; Wed, 31 Aug 2016 09:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zZolsSHh0Ko for ; Wed, 31 Aug 2016 09:25:50 -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 0782612B074 for ; Wed, 31 Aug 2016 09:25:50 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id z190so56852841qkc.0 for ; Wed, 31 Aug 2016 09:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0nROxjQqwsFOtFaGxlLVkMi9TdfQM4OxZk7lj0GZt0o=; b=x/CNM4XhMloZ3E9aadfn2l83ZjJTUGBBY9TNP0Is3gNLMhkrXYZ38nxoy13ilGLlLq V8KwhBDluslsNMO0aJcx4Dfvc8uUcYqWEgb3QXpb3nYGsi3k315lU8dk86lspDBRvYKm kDFwRj9sTXvN8eM2fw33jcgT8jkOx8CHeH3QMAbnlWXsF16eqWeZNpgcZ6hwcuRwSaCC bEVDeynEqOxSxvg7VGdvKJEBYnvmfs/IzABhkjzTy1Nc1a4BDvfX0S2ehGfJAuff4r0W lPCDFWVrX82l8pHT9YIideXqxOlOiiMzLeoDyp97/+4LDQxkK6ujzP5vGfuRRd4fa07v gHdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0nROxjQqwsFOtFaGxlLVkMi9TdfQM4OxZk7lj0GZt0o=; b=UUUZj9U6W/y7m9p41je922BLL/zR8M6LZMGOOWAUHOnKwmsdwuXvu/GY9rbsPLDFic f2TYFHJGsMQf+0+gBKyVE6t1wp71j83C56TDiATqv82FtoO60up1aJBQDOoZNgChhCul 9mNvXxg96kLAR8WyFd1Rg1QvpvkgfBd2QlRsFXsR5x0qBzLdDtYPgM4PHCXx1roAXI9G iVcMCjWZ0bbrUzosxzliTYY66dYT7KCxTrQJh7S5jb9bfkwnwDvc1KjB+K5Bo+m9VEMo uaHBHkPeZtj2lgXURJmD8DiH6nfphPlgITOZ9vP7rKxw1lofdD08uk32dR3UG8lDLsiH sVyA== X-Gm-Message-State: AE9vXwMTcMp7Grj3rKUPx29wgMGk5/X2BEBBs+BeVFw1G1AkISzdZpSUk1l4XiA3HP38Sg== X-Received: by 10.55.165.65 with SMTP id o62mr12603274qke.282.1472660749191; Wed, 31 Aug 2016 09:25:49 -0700 (PDT) Received: from [192.168.0.100] ([71.181.110.73]) by smtp.gmail.com with ESMTPSA id l1sm327371qtd.49.2016.08.31.09.25.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 09:25:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Wed, 31 Aug 2016 12:25:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> <1470148363699.24362@bosch.com> <4ff68fa1-0d8e-ed1e-064c-8bb5bbf5935a@akamai.com> <1470232754152.68803@bosch.com> <52BDE689-120E-4F95-98B9-1D83B1097B2B@sn3rd.com> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 16:25:52 -0000 Recall that the original renegotiation attack relied on a client that = has no intention to renegotiate but was still fooled into renegotiating the attackers=E2=80= =99s connection to the server. To prevent this attack, it is essential that the client includes an = empty R-I in its client hello. This negative acknowledgment is as useful as a positive one. This is particularly true on the client side. A server that does not = support renegotiation may be able to get away with not supporting R-I, but this probably also = leads to=20 some (weak) attacks. > On 31 Aug 2016, at 11:21, Martin Thomson = wrote: >=20 > On 26 August 2016 at 06:43, Sean Turner wrote: >> Any more thoughts on these? >=20 > I have no problem with implementations that don't use R-I (in either > extension or SCSV form) if they don't intend to ever renegotiate. I > know that that disagrees with RFC 5746, but there you have it. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Aug 31 09:56:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A5512D1E4; Wed, 31 Aug 2016 09:56: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR5pdELMJpI1; Wed, 31 Aug 2016 09:56:11 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.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 C9BC312D1AD; Wed, 31 Aug 2016 09:56:11 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1bf8o3-0004fh-5D; Wed, 31 Aug 2016 10:56:07 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1bf8nm-0006u1-3R; Wed, 31 Aug 2016 10:56:01 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u7VGtPPJ027046; Wed, 31 Aug 2016 10:55:25 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u7VGtOt0027045; Wed, 31 Aug 2016 10:55:24 -0600 Date: Wed, 31 Aug 2016 10:55:24 -0600 Message-Id: <201608311655.u7VGtOt0027045@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: cfrg@irtf.org, tls@ietf.org X-XM-SPF: eid=1bf8nm-0006u1-3R; ; ; mid=<201608311655.u7VGtOt0027045@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1+OR+mt9arxZCzjxJByooPQ X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;cfrg@irtf.org, tls@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 4260 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 7 (0.2%), b_tie_ro: 6 (0.1%), parse: 1.08 (0.0%), extract_message_metadata: 21 (0.5%), get_uri_detail_list: 2.4 (0.1%), tests_pri_-1000: 2.7 (0.1%), tests_pri_-950: 1.13 (0.0%), tests_pri_-900: 0.89 (0.0%), tests_pri_-400: 18 (0.4%), check_bayes: 17 (0.4%), b_tokenize: 4.4 (0.1%), b_tok_get_all: 5 (0.1%), b_comp_prob: 2.0 (0.0%), b_tok_touch_all: 2.8 (0.1%), b_finish: 0.68 (0.0%), tests_pri_0: 710 (16.7%), check_dkim_signature: 0.45 (0.0%), check_dkim_adsp: 498 (11.7%), tests_pri_500: 3496 (82.1%), poll_dns_idle: 3489 (81.9%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: "This is the mailing list 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, 31 Aug 2016 16:56:13 -0000 > From: Derek Atkins > Date: Wed, 31 Aug 2016 10:17:25 -0400 > "Steven M. Bellovin" writes: > > Yes. To a large extent, the "IoT devices are too puny for real > > crypto" is a hangover from several years ago. It was once true; for > > the most part, it isn't today, but people haven't flushed their cache > > from the old received wisdom. > This is certainly true for AES, mostly because many small chips are > including AES accelerators in hardware. It's not quite true for public > key solutions; there are still very small devices where even ECC takes > too long (and yes, there are cases where 200-400ms is still too long). > > It pays to look again at David Wagner's slides from 2005, on sensor > > nets and crypto: > > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf > > Unattended sensors with wifi present an unsolved crypto problem. They can last 10 years on an AA battery without crypto, probably well less than a year if they have to do any kind of encryption. These things will be everywhere, providing the data that will underly all kinds of decision-making. Although much of the solution may lie in hardware innovation, the world really does need minimal crypto algorithms. Hilarie From nobody Wed Aug 31 10:17:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B3812D12B for ; Wed, 31 Aug 2016 10:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI8OsaKwIKSk for ; Wed, 31 Aug 2016 10:17:12 -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 7442E12D10B for ; Wed, 31 Aug 2016 10:17:12 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A5D3F423710; Wed, 31 Aug 2016 17:17:11 +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 8427042370A; Wed, 31 Aug 2016 17:17:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472663831; bh=uWo6M2Cn0iFeOFf7xG7LK+VOhyOrN6QztFpaSiWMo4s=; l=3338; h=To:References:From:Date:In-Reply-To:From; b=Zh4GXsJAHRe/cVJGF/9M4DflZQerQqN3GeeHaRerIimCY6to6vmx16SFiogvqmrNG CfmAHMaIZ0pPPNWQ0v3wNYaL2/AL0TDWidi1/aKyx+0gpFHd34HWqvx9LPNwJOjHGu v3IwlhRItJxM+VAXQtlLIpc0ntGOdjjozvM7Fg2I= 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 4E6131FC8E; Wed, 31 Aug 2016 17:17:11 +0000 (GMT) To: Eric Rescorla , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <57573467-35ec-f026-ebc7-3020bc0717ca@akamai.com> Date: Wed, 31 Aug 2016 12:17:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------57EA0B8D9A6501FEFB6940E4" Archived-At: Subject: Re: [TLS] Issue 588: Code point assignment for ticket_early_data_info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 17:17:14 -0000 This is a multi-part message in MIME format. --------------57EA0B8D9A6501FEFB6940E4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/30/2016 06:50 PM, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/588 > > > I neglected to assign a code point for this in draft-15. I note, > however, that > we currently have it occupying a different code point space than hello > extensions. > I am sort of wondering if it would be more useful for them to be in > the same > space. Probably not, but I thought I would ask before assigning 1, > which is > the natural code point otherwise. > > https://tlswg.github.io/tls13-spec/#rfc.section.4.5.1 > > It seems to make more sense to keep them in separate numberspaces, to me. -Ben --------------57EA0B8D9A6501FEFB6940E4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/30/2016 06:50 PM, Eric Rescorla wrote:
https://github.com/tlswg/tls13-spec/issues/588

I neglected to assign a code point for this in draft-15. I note, however, that
we currently have it occupying a different code point space than hello extensions.
I am sort of wondering if it would be more useful for them to be in the same
space. Probably not, but I thought I would ask before assigning 1, which is
the natural code point otherwise.



It seems to make more sense to keep them in separate numberspaces, to me.

-Ben
--------------57EA0B8D9A6501FEFB6940E4-- From nobody Wed Aug 31 10:20:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED312D13F for ; Wed, 31 Aug 2016 10:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtgNMKcKCl7U for ; Wed, 31 Aug 2016 10:20:16 -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 615C112D10B for ; Wed, 31 Aug 2016 10:20:16 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 04496200057; Wed, 31 Aug 2016 17:20:16 +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 E27A320000B; Wed, 31 Aug 2016 17:20:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472664015; bh=6+CGOPBd+GoUv3dIJtWtQ7DfIItuSMDQwA7sHS3rtVg=; l=2175; h=From:To:In-Reply-To:References:Date:From; b=TOtcinots3p6+qkpDJ2Pfxx7JF9j5m6vlFTztV4ueqUhQHf0lKF+/7mL/btUdvmq3 VUwPmLtTKq9O0f+tjNdFYVnKAD4+n/46LPPUhDwjFfnbEMuxOSXX2Q0IdStuR+a+T3 n8SHW3fLWd5uwT6u1mBU68x4S3NZ0be/iQELk9t4= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id CA3591E084; Wed, 31 Aug 2016 17:20:15 +0000 (GMT) Received: from usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 Aug 2016 10:20:15 -0700 Received: from USMA1EX-CAS1.msg.corp.akamai.com (172.27.123.30) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 Aug 2016 10:20:15 -0700 Received: from bos-mpeve.kendall.corp.akamai.com (172.28.16.165) by USMA1EX-CAS1.msg.corp.akamai.com (172.27.123.30) with Microsoft SMTP Server id 15.0.1178.4 via Frontend Transport; Wed, 31 Aug 2016 13:19:53 -0400 From: Brian Sniffen To: Hilarie Orman , , In-Reply-To: <201608311655.u7VGtOt0027045@rumpleteazer.rhmr.com> References: <201608311655.u7VGtOt0027045@rumpleteazer.rhmr.com> User-Agent: Notmuch/0.22.1 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-apple-darwin13.4.0) Date: Wed, 31 Aug 2016 13:19:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 17:20:17 -0000 Hilarie Orman writes: >> From: Derek Atkins >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > >> "Steven M. Bellovin" writes: > >> > Yes. To a large extent, the "IoT devices are too puny for real >> > crypto" is a hangover from several years ago. It was once true; for >> > the most part, it isn't today, but people haven't flushed their cache >> > from the old received wisdom. > >> This is certainly true for AES, mostly because many small chips are >> including AES accelerators in hardware. It's not quite true for public >> key solutions; there are still very small devices where even ECC takes >> too long (and yes, there are cases where 200-400ms is still too long). > >> > It pays to look again at David Wagner's slides from 2005, on sensor >> > nets and crypto: >> > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf >> > > > Unattended sensors with wifi present an unsolved crypto problem. They > can last 10 years on an AA battery without crypto, probably well less > than a year if they have to do any kind of encryption. These things > will be everywhere, providing the data that will underly all kinds of > decision-making. Assuming there are *some* integrity requirements for the data, and that they are deploying 32-bit ARM with AES support (stipulating that ~every CPU will have AES support in a few years, as ~every CPU sold does today), we're talking about *either* an ECDHE negotiation every few months or a pre-shared key, good for ten years. AES-GCM with hardware support compares favorably to SHA-2 without hardware support, so if they've been able to last 10 years before, they should do just fine in the future. The old devices won't last forever, and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us for ten years after 1.3 is out. -Brian > Although much of the solution may lie in hardware innovation, the > world really does need minimal crypto algorithms. > > Hilarie > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Aug 31 10:23:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECD012D1A5 for ; Wed, 31 Aug 2016 10:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hALLY7KULXsK for ; Wed, 31 Aug 2016 10:23:25 -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 93BD012D19B for ; Wed, 31 Aug 2016 10:23:25 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 36B7D3F402B; Wed, 31 Aug 2016 17:23:25 +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 201E83F4009; Wed, 31 Aug 2016 17:23:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472664205; bh=55N+79rHjmz9UKsKCJ3zQdJa94V0l7hQXFpady1+Q9s=; l=2411; h=From:To:CC:In-Reply-To:References:Date:From; b=Q5MR7WFsZon2QwfPV/czpeMWWG38DAAvjoiduMyuoBWWvn+soAhoaCGYu8pJq7iZs W2nm9VqZVHDBRwT+2+t9ufgY4HCw7egAVIXASDp8XcMirnyJHHCPvp/By3cTIxGh2c PuXP+IowIQmERjpdaAMNlvtR5OQ7hG1EF/pTX0OI= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1C3901FC88; Wed, 31 Aug 2016 17:23:25 +0000 (GMT) Received: from usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 Aug 2016 13:23:24 -0400 Received: from USMA1EX-CAS2.msg.corp.akamai.com (172.27.123.31) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 Aug 2016 10:23:24 -0700 Received: from bos-mpeve.kendall.corp.akamai.com (172.28.16.165) by USMA1EX-CAS2.msg.corp.akamai.com (172.27.123.31) with Microsoft SMTP Server id 15.0.1178.4 via Frontend Transport; Wed, 31 Aug 2016 13:23:24 -0400 From: Brian Sniffen To: Erik Nygren , Dave Garrett In-Reply-To: References: <201608301419.33620.davemgarrett@gmail.com> <201608301529.49488.davemgarrett@gmail.com> User-Agent: Notmuch/0.22.1 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-apple-darwin13.4.0) Date: Wed, 31 Aug 2016 13:23:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 17:23:27 -0000 Erik Nygren writes: > I'm also very supportive for the reasons you outline. > > However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5. > > In particular, much of the non-technical audience still calls it "SSL" (pet > peeve of many of us, I suspect) and having a version number clearly greater > than SSLv3 and not confusing with SSLv2 would be quite valuable. "TLS 2" > may have risk for unfortunate confusions with SSLv2 and SSLv3. That is wise. What discussions were deferred as "this is just 1.3, wait for 2.0" that will legitimately come back out of the woodwork if this is renamed to TLS X, X > 1.9? -Brian > Another reason to avoid 1.3 is Western culture negative connotations around > "tls13" which TLS 1.3 will get abbreviated as. > > - Erik > > [Sent from my IPv6 connected T-Mobile 4G LTE mobile device] > > On Aug 30, 2016 3:35 PM, "Dave Garrett" wrote: > >> On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote: >> > I support this change as long as there is no technical change (version >> ID remains 0x0304). >> >> To reiterate, I am also against changing the version ID. However, I do >> think it's worth updating the context string version number, otherwise it'd >> be a little unnecessarily confusing there. (trivial change to key >> derivation, but not wire format) I've also made a point to tweak references >> to the on-the-wire version value to refer to it as a "version ID" rather >> than just version, to make it very clear that this is really just an >> arbitrary codepoint and shouldn't be read as 3.4. >> >> I've made the changes for a WIP branch, here (not a PR, as of yet): >> https://github.com/tlswg/tls13-spec/compare/master... >> davegarrett:tls2rebranding >> >> Going through the motions of doing the renaming now is useful to see if >> there's anything that is more affected than initially expected, such as the >> context strings having the version in there directly as a string (they're >> designed to be updated as-needed, so this shouldn't be a problem). >> >> >> Dave >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Aug 31 10:28:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36A12B004 for ; Wed, 31 Aug 2016 10:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efVkkFvCkbGv for ; Wed, 31 Aug 2016 10:28:35 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBA0126579 for ; Wed, 31 Aug 2016 10:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ExsWFd6QztGbKe6yg8VuAxUYrNq5sd2meCASneO+9gU=; b=V9/jInbX9e/iAE5693++tYfeFUPGkZE6UF+c3i+SKzMmWN396yPKhXKGtwaWJohpr+QPoMK9Pk3RMs/42S/Qn5Vo80CfZdQH4qL7x/EinHVUfkx8UmN0wgvYN7X+rQqUaPItrqbZTCk+EUwQOJZ7DcgBCLiOVRWEuLdZm4xfVTY= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 17:28:32 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 17:28:32 +0000 From: Andrei Popov To: Yoav Nir , Daniel Kahn Gillmor Thread-Topic: [TLS] TLS 1.3 -> TLS 2.0? Thread-Index: AQHSAvsf5dWhQdHM/0+bK3BNgr/S/KBiAvGAgAEmhoCAACk+EA== Date: Wed, 31 Aug 2016 17:28:31 +0000 Message-ID: References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> <878tvex8a6.fsf@alice.fifthhorseman.net> 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:9::1d2] x-ms-office365-filtering-correlation-id: 4e79a674-6c26-47d4-3198-08d3d1c43ad6 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:aCgYi+bg/Ilc4MF/4syTw/6lILmP5ABOcCxinGLmcrAfCuPqzwKarVIEk//tOZCuaofVSlmldUaUNFegV0r75wI5Cu9mCf5NCKPung5E2kqlL4jC5lP5u4crQvUJ0pVe/Quwn9MDN7KJUHzkN+mtgVntfchr8JFYUzsryHG2HAg7L3x2teI8RE+cpoLJvFSwfhqXatWdn76/LSdMa6YvJaUtqaVJsiifzybIvN7+AgVJGDT2bBqo+3rD70oH11ggI8BLQWY2NbjLP29C//9xO6QGHrLpfqT62XmH7Sl0tZaFqtc8OYiQQSXzvR36Wh6ufGSIoOvClOf+S7FoGyMxqw==; 5:4ByilsTjXQCefvw1taZVaQNyMiwX1MlaD5MmAycBa3XRai3VHXes1wXs2gOckzSPv/ZZkbyuTaodzDexCgG89sWq3m+HJWZLmVtqh75fpBlfaqLlVhdoUssHURl6+Ajk6r527B2Qm2JgfT7gLfzlFg==; 24:iiVC4thl3OFy5GUx2NqIZemNztYz7zhmtaojN2Fhd4BarnHP2hb2+7rtqF9g1+M73ZcxV+W6pAnCuZrlVDqo12AlmclT70ZSerqVB1WJ/GM=; 7:fm+M9PbB1vuxgZrEET8jRmKMKb5wuLVejQG+Esv1bwjSm5Tw1inERT3yirRQTxbJkJHc74MTYIdfqcGwBxhrccfzwk/pzFnOgy1HVcR52S5hhDX4nQDO0zySI+CA2PdkDlLOM9zV32mpA/zd7PR+D59RF8xixhmyhviGACq0ZXIFuDa4T6OtZcXfCbnYJ8lygfPsUn2e8ABXLeuGyz2usmSTrmWNPK9jVOqoFh2ehgU1Xhb0SRxTVbi//+U/HPGG x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(199003)(189002)(377454003)(13464003)(377424004)(24454002)(74316002)(3660700001)(305945005)(10400500002)(9686002)(76176999)(7736002)(7696003)(8990500004)(106116001)(7846002)(50986999)(33656002)(101416001)(54356999)(11100500001)(10090500001)(68736007)(8676002)(99286002)(81156014)(81166006)(93886004)(5660300001)(106356001)(586003)(5001770100001)(102836003)(4326007)(122556002)(86362001)(76576001)(5002640100001)(77096005)(6116002)(2950100001)(87936001)(105586002)(86612001)(5005710100001)(19580395003)(8936002)(97736004)(10290500002)(2900100001)(2906002)(92566002)(19580405001)(3280700002)(189998001)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 17:28:31.8451 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 17:28:37 -0000 PiBObyB0aGV5IGRvbuKAmXQgYWx3YXlzIGxvb2sgYXQgdGhlIDE2LWJpdCBmaWVsZCAoYWx0aG91 Z2ggdGhleSBtaWdodCksIGJ1dCB0aGV5IGxvb2sgYXQgeW91IGZ1bm55IHdoZW4geW91IHRlbGwg dGhlbSB0aGF0IDEuMCA+IDMuMCBhbmQgdGhhdCB5b3Ugc2hvdWxkIHRvdGFsbHkgZGlzYWJsZSAz LjAgYW5kIHByZWZlciB0byB1c2UgMS4yIGluc3RlYWQuDQo6KSBUcnVlLCBidXQgd2hlbiB0aGlz IGhhcHBlbnMsIEkgc2ltcGx5IHRlbGwgdGhlbSB0aGF0IGFsbCBTU0wgdmVyc2lvbnMgYXJlIGJy b2tlbiwgc28gdGhleSBoYXZlIHRvIHVzZSBUTFMuDQpJJ2QgcmF0aGVyIGhhdmUgYSBjb25zaXN0 ZW50IHZlcnNpb25pbmcgc3RvcnkgZm9yIFRMUyAoMS4wLT4xLjEtPjEuMi0+Mi4wKSwgcmF0aGVy IHRoYW4gdHJ5aW5nIHRvIGZpeCB0aGUgU1NMMy0+VExTMS4wIGluY29uc2lzdGVuY3kgYXQgdGhp cyBwb2ludC4NCkl0J3MgYWxyZWFkeSBmdW4gZW5vdWdoIHRvIGV4cGxhaW4gd2h5IERUTFMganVt cGVkIGZyb20gMS4wIHRvIDEuMiAob3IgV2luZG93cyBmcm9tIDggdG8gMTAsIGZvciB0aGF0IG1h dHRlcikuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUTFMgW21haWx0bzp0 bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFlvYXYgTmlyDQpTZW50OiBXZWRuZXNk YXksIEF1Z3VzdCAzMSwgMjAxNiA3OjU1IEFNDQpUbzogRGFuaWVsIEthaG4gR2lsbG1vciA8ZGtn QGZpZnRoaG9yc2VtYW4ubmV0Pg0KQ2M6IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW1RMU10gVExTIDEuMyAtPiBUTFMgMi4wPw0KDQoNCj4gT24gMzEgQXVnIDIw MTYsIGF0IDEyOjIxIEFNLCBEYW5pZWwgS2FobiBHaWxsbW9yIDxka2dAZmlmdGhob3JzZW1hbi5u ZXQ+IHdyb3RlOg0KPiANCj4gT24gVHVlIDIwMTYtMDgtMzAgMTY6MTQ6MDYgLTA0MDAsIEh1YmVy dCBLYXJpbyB3cm90ZToNCj4+IE9uIFR1ZXNkYXksIDMwIEF1Z3VzdCAyMDE2IDE0OjE5OjMzIENF U1QgRGF2ZSBHYXJyZXR0IHdyb3RlOg0KPj4+ICogS2VlcCB0aGUgdmVyc2lvbiBJRCBhcyB7IDMs IDQgfSAoYWxyZWFkeSB3ZWlyZCBjb3VudGluZzsgY2hhbmdpbmcgDQo+Pj4gcmlza3MgbW9yZSBp bnRvbGVyYW5jZSkNCj4+IA0KPj4gSU1OU0hPIHRoaXMgYWxvbmUgaXMgZW5vdWdoIG9mIGEgcmVh c29uIG5vdCB0byBkbyB0aGlzDQo+PiANCj4+IGl0J3MgZW5vdWdoIGV4cGxhaW5pbmcgdG8gcGVv cGxlIHRoYXQgU1NMdjMuMyBpcyByZWFsbHkgVExTdjEuMiwgbm93IA0KPj4gd2UnbGwgaGF2ZSBT U0x2My40ID09IFRMU3YxLjMgPT0gVExTdjIuMA0KPj4gDQo+PiBpdCdzIHNpbGx5IGF0IHRoaXMg cG9pbnQNCj4gDQo+IFdobyBhcmUgeW91IHRhbGtpbmcgdG8gd2hvJ3MgZmluZSB3aXRoIGxvb2tp bmcgYXQgdGhlIGJ5dGVzIG9uIHRoZSANCj4gd2lyZSBidXQgaXNuJ3QgZmluZSB3aXRoIHVuZGVy c3RhbmRpbmcgdGhhdCBhIDE2LWJpdCBmaWVsZCBtaWdodCBub3QgDQo+IG1hcCBkaXJlY3RseSB0 byBvdXIgaW1hZ2luYXRpb24gb2YgZGVjaW1hbD8NCg0KTm8gdGhleSBkb27igJl0IGFsd2F5cyBs b29rIGF0IHRoZSAxNi1iaXQgZmllbGQgKGFsdGhvdWdoIHRoZXkgbWlnaHQpLCBidXQgdGhleSBs b29rIGF0IHlvdSBmdW5ueSB3aGVuIHlvdSB0ZWxsIHRoZW0gdGhhdCAxLjAgPiAzLjAgYW5kIHRo YXQgeW91IHNob3VsZCB0b3RhbGx5IGRpc2FibGUgMy4wIGFuZCBwcmVmZXIgdG8gdXNlIDEuMiBp bnN0ZWFkLg0K From nobody Wed Aug 31 10:34:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E237012D552 for ; Wed, 31 Aug 2016 10:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nay1Q4_uouAT for ; Wed, 31 Aug 2016 10:34:25 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6188C12D13B for ; Wed, 31 Aug 2016 10:34:25 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id c133so42576673wmd.1 for ; Wed, 31 Aug 2016 10:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5eEFMozev+eR0kUgJpC16TeQvjm412fjYhzkQskB3ds=; b=JQ+CP9BXjdOXgyMwVIzKOM0c7fByJ/B/sGrIPaYalX1mqZXVz6BHhHwP2T7DU5cPsY lq6ETBZSJoV9xyH+AVdBKI3+8I2aqpmvCAy2TzNMa416Ix52CuigPKt47zrUJI+msh89 8ej5Pr4myMTHX/YiT18YXh0oBptdWqGg6vm5kUCAwIch2yzhlsE9yNKumTaeIEAS71CX SeM8JJWhSgOPTROOx79Hl0/fXMNAzfE1llFGjUtbnWJmbfNT+GURAEi8kSkb8XZ5sOCQ kqfAJqBhCdS3gfLg908Ii+a0F+b1Nm7aD0PjfMCZDCu8VXO4Kq8WlAN25gzaqPy3AhHV 5IaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5eEFMozev+eR0kUgJpC16TeQvjm412fjYhzkQskB3ds=; b=WPQ0gDzUzy3zzP8/3spOZ2KGYvRB7rjkPy/T/8DFi+suVzaaaH5whZtLi5KNCXy0QX 9Ec9yOPUTJCHqEo9dzXP/8s3TtoFBdAM/UENRgcmR39t7pYiuOqOA9/Fcga/MSa+ADFd 7O+F/lLq1Ze9rHCBQ6yLOSbc4GTqRpXXtT4nCh9dAOr6/dukXncCR9OlmU3NGnmWpu1p xpjDxbRLPvcjHaEKYjajeY5pDCaZ2MauGFs/jsmgecz4mG9GiCPQZHMivOSplmXxiMlY /1mcCBGkaokP61j5TU2faaZLJdCC6+/U3VHHCGxTgEZCr8/oPZ6M3eUt9m7h2DJ9hxI/ bY5A== X-Gm-Message-State: AE9vXwO++CHH2WSp31lOJ6OpmXQlYJIaySHgLgDXj4lUfvjmxpDTHeRPbBEnaIKJLsN0mQ== X-Received: by 10.194.89.73 with SMTP id bm9mr11118417wjb.76.1472664863645; Wed, 31 Aug 2016 10:34:23 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m81sm24759238wmf.1.2016.08.31.10.34.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 10:34:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_026F708B-E99F-4049-8E53-5B0418BB1E4F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Wed, 31 Aug 2016 20:34:28 +0300 Message-Id: <29F42251-E802-44A1-988D-EA615BBC2143@gmail.com> References: <201608301419.33620.davemgarrett@gmail.com> <2135572.Ea2pKTvtKx@pintsize.usersys.redhat.com> <878tvex8a6.fsf@alice.fifthhorseman.net> To: Andrei Popov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 17:34:27 -0000 --Apple-Mail=_026F708B-E99F-4049-8E53-5B0418BB1E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 31 Aug 2016, at 8:28 PM, Andrei Popov = wrote: >=20 >> No they don=E2=80=99t always look at the 16-bit field (although they = might), but they look at you funny when you tell them that 1.0 > 3.0 and = that you should totally disable 3.0 and prefer to use 1.2 instead. > :) True, but when this happens, I simply tell them that all SSL = versions are broken, so they have to use TLS. > I'd rather have a consistent versioning story for TLS = (1.0->1.1->1.2->2.0), rather than trying to fix the SSL3->TLS1.0 = inconsistency at this point. > It's already fun enough to explain why DTLS jumped from 1.0 to 1.2 (or = Windows from 8 to 10, for that matter). I once had to explain to a GUI designer why this piece of UI genius was = not a good idea Choose the minimal support SSL / TLS version: | | +-------+ | 1.0 | | 1.1 | | 1.2 | | 2.0 | | 3.0 | +-----+ =20 =20 --Apple-Mail=_026F708B-E99F-4049-8E53-5B0418BB1E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 31 Aug 2016, at 8:28 = PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

No they don=E2=80=99t = always look at the 16-bit field (although they might), but they look at = you funny when you tell them that 1.0 > 3.0 and that you should = totally disable 3.0 and prefer to use 1.2 instead.
:) True, but when this happens, I simply tell = them that all SSL versions are broken, so they have to use TLS.
I'd rather have a consistent versioning story for TLS = (1.0->1.1->1.2->2.0), rather than trying to fix the = SSL3->TLS1.0 inconsistency at this point.
It's already = fun enough to explain why DTLS jumped from 1.0 to 1.2 (or Windows from 8 = to 10, for that matter).

I once had to explain to a GUI designer why this piece = of UI genius was not a good idea

  =   Choose the minimal support SSL / TLS = version:
         |   =     |
        =  +-------+
          | 1.0 = |
          | 1.1 = |
          | 1.2 = |
          | 2.0 = |
          | 3.0 = |
          = +-----+
    
         

= --Apple-Mail=_026F708B-E99F-4049-8E53-5B0418BB1E4F-- From nobody Wed Aug 31 10:38:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5A12D0FD for ; Wed, 31 Aug 2016 10:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MscnhQVp4W-L for ; Wed, 31 Aug 2016 10:38:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id ED68212D0CE for ; Wed, 31 Aug 2016 10:38:26 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 2AEE8F999; Wed, 31 Aug 2016 13:38:25 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 57B9420A34; Wed, 31 Aug 2016 12:44:03 -0400 (EDT) From: Daniel Kahn Gillmor To: Julien =?utf-8?Q?=C3=89LIE?= , tls@ietf.org In-Reply-To: <6b05e1f2c2bd0fb699f4650182b8ddd4@trigofacile.com> References: <6b05e1f2c2bd0fb699f4650182b8ddd4@trigofacile.com> User-Agent: Notmuch/0.22.1+88~g8d09e96 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 31 Aug 2016 12:44:02 -0400 Message-ID: <87shtkevn1.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Terminology clarification around SSL & TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:38:28 -0000 On Wed 2016-08-31 03:35:38 -0400, Julien ÉLIE wrote: > Following a recent discussion about how to name the successor of TLS > 1.2, I wish to share an idea about a possible terminology clarification. > I believe it could help to conciliate people understanding of SSL & TLS. > > We would have 3 notions: > 1/ the technology, > 2/ the protocols, > 3/ the protocol versions. > > The technology is SSL, and is sometimes also refered to as SSL/TLS. > (Note that bare TLS is not a technology.) please no. the technology is TLS. The time for us to have made the other decision was 17 years ago before TLS 1.0 was formalized. i would like to continue to be able to say unambiguously that all known versions of SSL are badly broken and should be avoided. Let's not muddy those waters further. --dkg From nobody Wed Aug 31 10:39:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8866412D0CE for ; Wed, 31 Aug 2016 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FKv2SfGq_tg for ; Wed, 31 Aug 2016 10:39: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 7655D12D0FD for ; Wed, 31 Aug 2016 10:39:39 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 11DC842374F; Wed, 31 Aug 2016 17:39:39 +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 ECC45423748; Wed, 31 Aug 2016 17:39:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472665178; bh=DbCv9ayffqCRJQTUTT158NuHp5qsAYC0eNRtSIZ2jgo=; l=382; h=From:To:Date:References:In-Reply-To:From; b=US2mEnal03c7opML3tI6D/KcoDxQaXjySsr34iNWn3IY+PHl0e+jw+j9ync9QPzFn ykmR17JicXHLrmFWQItQ/E2Siqa8A1ulMkkyQOKqxhmBhJxagvluDgrkUYflXkQLON XsphXonQug/jgQkVuw47yert8103g9ughalbYW4I= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E95081FC88; Wed, 31 Aug 2016 17:39:38 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 Aug 2016 10:39:38 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 31 Aug 2016 13:39:38 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , =?utf-8?B?SnVsaWVuIMOJTElF?= , "tls@ietf.org" Thread-Topic: [TLS] Terminology clarification around SSL & TLS Thread-Index: AQHSA1pNIz/T763XOEKmK+U52V5Oz6BjihsA///MZtA= Date: Wed, 31 Aug 2016 17:39:37 +0000 Message-ID: References: <6b05e1f2c2bd0fb699f4650182b8ddd4@trigofacile.com> <87shtkevn1.fsf@alice.fifthhorseman.net> In-Reply-To: <87shtkevn1.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.41.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Terminology clarification around SSL & TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:39:40 -0000 PiBpIHdvdWxkIGxpa2UgdG8gY29udGludWUgdG8gYmUgYWJsZSB0byBzYXkgdW5hbWJpZ3VvdXNs eSB0aGF0IGFsbCBrbm93bg0KPiB2ZXJzaW9ucyBvZiBTU0wgYXJlIGJhZGx5IGJyb2tlbiBhbmQg c2hvdWxkIGJlIGF2b2lkZWQuICBMZXQncyBub3QgbXVkZHkNCj4gdGhvc2Ugd2F0ZXJzIGZ1cnRo ZXIuDQoNCisxDQoNCi0tICANClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMN CklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg0KDQoNCg== From nobody Wed Aug 31 10:50:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F68812D5AF for ; Wed, 31 Aug 2016 10:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz0verYvo4fL for ; Wed, 31 Aug 2016 10:50:24 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0134.outbound.protection.outlook.com [104.47.42.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF0812D5AA for ; Wed, 31 Aug 2016 10:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=djLHz+PVE30GzavcH4ZaBQOGU58kLxWoFR748XrwWgs=; b=cLpTXvoaf/S5thTodlLS7rFi6TOvJ3eYZYAgZyj5A50+9BNjlEY4491fjOtQf6+0S2N2YHzuAmqiIvWFD0ZwP1m12RENgLIgmc1oKuIsn4zIha0i8sGglhwcGMwMAzwzJ8tWRKJIRX1BZ5Nnam23eVdCjiS00t9nHfoMtHtTZVY= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 17:50:21 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 17:50:20 +0000 From: Andrei Popov To: "Salz, Rich" , Daniel Kahn Gillmor , =?iso-8859-1?Q?Julien_=C9LIE?= , "tls@ietf.org" Thread-Topic: [TLS] Terminology clarification around SSL & TLS Thread-Index: AQHSA1pSZmrA/Ygnr0yF98ZdW/udRaBjRw0AgAAPh4CAAAJ7gA== Date: Wed, 31 Aug 2016 17:50:20 +0000 Message-ID: References: <6b05e1f2c2bd0fb699f4650182b8ddd4@trigofacile.com> <87shtkevn1.fsf@alice.fifthhorseman.net> 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:9::1d2] x-ms-office365-filtering-correlation-id: 0d029315-e649-4011-c317-08d3d1c746cf x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 6:9/qp6tJ8jxKPeMWrbmc/TDYPEddVlNsWiDJm1WfExLasX64/Z0jwIpqQN8+Ife1O+cfhMd5ftRl5zRD+pDK/THMn7z/enlvBrq6maKtCxXufuiRH10HmwWHw2ROuNUK+xpAB6bQ8z63FFjzfS5BvizWs4oBb4iMbM+5a1HORTGPPJ+mGXvPCnP+Pqs40m/tu76a6LZLSk2pbJQGsFtidudACvoL/v0uQOD9LWF80qGhC20lmUEMtziaDQYPAjQCnqlVnwtAm+HC6x848S6w0mdIq+DhigJZ/2HklDRVZOLG8iY42qLYyeIPbbyTWjNsFl2kiyHOKRouDro3VkABBYQ==; 5:mYkUFM70xKHUvEd8BYyLim1cld2orOYaTKNnZqRvOyrlQHnNcHBC6MoQ40c9bt6m6JgUyBmfTuQB5SUHSVSIK7N8tk4IFJ6GtlT8YB3LNb/PygT2hgI/06d1NhFRZquqHXTJ2GMpU6afL24yv755fg==; 24:E53VdsRxZhDI6nz5Ka9qX9mV8EDLbGTxtuniNtoEA3FJKX6+jBwTPiFpTQuQHCI1mJcZWMWTJgUM3TiHgwlq12mReanIjOoOgBFmnLD5MBQ=; 7:Os9QPZpumgwBrYiiL+L7CVXPR6CTSy0gDOT35HhxcccG2GjEtfjUZdOA4AVHcElK/2ONO1hcPSfj7e1J62Psqdby7rVGcA0zxkUxqjczLtZifrg2sKxcI0X5eQYhY5IuxHXcaUdEGWAfU9mrsjXa1xDXMKcvAmp4f4vx9T74JwfrdmHhSXF68qVYewv3RmN1m3CkAZ0OtrlPMEwYtS4gFz8dKBbIECiB/9FazuFT2+y8LFuxDjHUTmstOEmSjkmY x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148322886591682); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(377454003)(13464003)(2906002)(7696003)(86612001)(2950100001)(305945005)(92566002)(2900100001)(33656002)(68736007)(3280700002)(5002640100001)(10400500002)(122556002)(101416001)(5001770100001)(97736004)(107886002)(9686002)(189998001)(81156014)(8936002)(74316002)(3660700001)(15975445007)(8676002)(77096005)(10290500002)(87936001)(7846002)(586003)(81166006)(102836003)(76176999)(7736002)(10090500001)(2501003)(8990500004)(5005710100001)(5660300001)(50986999)(54356999)(19580395003)(6116002)(106116001)(19580405001)(105586002)(86362001)(76576001)(99286002)(106356001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 17:50:20.4929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Subject: Re: [TLS] Terminology clarification around SSL & TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:50:26 -0000 +1. Let's not use a proprietary protocol name for a standard protocol. Conv= eniently, all SSL is broken now, long live TLS! -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich Sent: Wednesday, August 31, 2016 10:40 AM To: Daniel Kahn Gillmor ; Julien =C9LIE ; tls@ietf.org Subject: Re: [TLS] Terminology clarification around SSL & TLS > i would like to continue to be able to say unambiguously that all=20 > known versions of SSL are badly broken and should be avoided. Let's=20 > not muddy those waters further. +1 -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Aug 31 11:14:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D550112D630 for ; Wed, 31 Aug 2016 11:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.47 X-Spam-Level: X-Spam-Status: No, score=-7.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMoLhXUhL8px for ; Wed, 31 Aug 2016 11:14:35 -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 B8C0112D624 for ; Wed, 31 Aug 2016 11:14:35 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2AA7481112 for ; Wed, 31 Aug 2016 18:14:35 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7VIEXex022115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Aug 2016 14:14:34 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 31 Aug 2016 20:14:33 +0200 Message-ID: <6918283.boJRZ9WqjH@pintsize.usersys.redhat.com> User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6140466.7ZuFn2xtLx"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 31 Aug 2016 18:14:35 +0000 (UTC) Archived-At: Subject: [TLS] 0-RTT encrypted data limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 18:14:37 -0000 --nextPart6140466.7ZuFn2xtLx Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Current draft has the following text in it: If any of these checks fail, the server MUST NOT respond with the extension and must discard all the remaining first flight data (thus falling back to 1-RTT). If the client attempts a 0-RTT handshake but the server rejects it, it will generally not have the 0-RTT record protection keys and must instead trial decrypt each record with the 1-RTT handshake keys until it finds one that decrypts properly, and then pick up the handshake from that point. My understanding of that, in case client does 0-RTT but server rejects it=20 (because the PSK is too old or its time is different enough) is that the=20 server needs to keep on reading arbitrarily large amounts of data it has no= =20 idea what to do with. All using slow path (thinking exception handling in=20 particular). Is my understanding correct? Why is there no limit on the amount of data that can be encrypted using PSK= =20 keys (0-RTT)? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart6140466.7ZuFn2xtLx 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 iQIcBAABCgAGBQJXxx6JAAoJEJKo0bgB0vX15NAP/1w/A9AxI0YI6tsB5LZmh1Ni HRhdmB297G0yTwPFdL1vyPE7NlFbZTuJi1UFz0PV9VaTBr/xB6h5wF46rCr2Y0Fb b5u35xiipFYCeYFa5aJpuGzJDegKxzscBRSQ1XREUTNaX7RJFfm7Yy05rFhctWwn p4BSE7H/J3phge13jy3N2w1/8a6hVCFkfi8ZS3AQ2OOFzMUKd1WXKXMLJrcW0WI4 +Q5ZfVw/FZ/TVt6G4/ffuXk261cm7yhZ93FMfnm6Cfz/4GmXc7uTQfDdiAT4GBAn USgo1ijhvnBk3zlRoy6e1Fhr2IzunJ5bmzonbpGqFiC3rFf0EVvuhnDhCXF8FJW+ er72+WJxvMwsN8rttfgd3sgz4HHfu02ywWMAlEyRntWQDfUeJ9opmDRds34ormOs x2mzyj0p03Sg5q6+l+FoepmJopRC6j4L9dY4Tf+EnyraTw3M57fy9BZj6DZxLXId qJLcxKyBN5zhTASYsMJI7NPP5IGXBe11tZ346vfBx2na2deFaAiEJxxdWhsCxTYF YlpKvfdLtDg0o0tuobkSCpWaBgoNj8zfdkRZDZFCXKVBkDlp7jb2U4wklvqOL8D0 U8+1UdZWAyQ2IYxJIQqm/ehw6/3u2iN/8bCUizaHni7jwo3F3WW9PWru7F2jb/XQ N20Z40Kk2Vp/lT4w+TiC =AFG1 -----END PGP SIGNATURE----- --nextPart6140466.7ZuFn2xtLx-- From nobody Wed Aug 31 11:23:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ED412D668 for ; Wed, 31 Aug 2016 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXhLfDYQTh72 for ; Wed, 31 Aug 2016 11:23:53 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079E212D642 for ; Wed, 31 Aug 2016 11:23:53 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id r9so36088599ywg.0 for ; Wed, 31 Aug 2016 11:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PrRI+XvWxicrTwnQYRBzjNGlLRA61LJ4mWbkEhVl2Yc=; b=RJa/4pMc7onjDyQeZ93HozIUqIHKboYR5+wH4VlcNY+wDAQJlv14kizkXzIKh5y4iG Aw0iGQz4DBbKASZZwHc8oNajaZcuXoDrlEwjVqMdf1mUNBVgooW48+FskPuB7PDnGY+R /OIgj8ErZrzI2/pRv07fbJVolcd7mFW3aGYL3dZTevc3WrB+eUAf4sqvaYKx1QDEjnzj obJHAu6hWBf7UXHCRwYm/MmwRSTCibGZR6sJBLogi58dn081xHJbkOwM3RR3toYR0KaI QP4L8IK8slsvZGTfefX5+sV2gA2Pf4EWWHmh9h1OzKgH3QucfUjH69ExYrhcIjWOfe10 AtMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PrRI+XvWxicrTwnQYRBzjNGlLRA61LJ4mWbkEhVl2Yc=; b=nDleZEB5LrpLqK/9RULeHz3DoOf9QkzOtuYgPBPfEmhjCESXzOq/U/PeWpi+4rm6br gP70bJtJglJELs1L9llFnWp8mLOQDg3S/xKhSahAdUVvQYT6Gl1ja0hUZ/vVKCiFTZ2S G/v8GxojlWoGsfma0dK6MRJkzM+kVcPSFokrbKs6EtQs1EcK/B4WOxmyfbRQ5RbRKPWf V5h/ZM/4KNdxRWfpm/KCTWIyfF6La9fvdXjg+Zeb3HouSmL9Lb261gnkoFYBSYMBYW3C ozg4ITZ0cLu4p093f8UP0LzDXFAqxXtJgdL39r/FrR74UM532KNR6egDUUTRIgAhtCaG kI5A== X-Gm-Message-State: AE9vXwOU3g/iGXi0t5zO8++4PnyfT8E9HoF1ZAUuoLyJBhvo8knBpmm7RGUVQ71/bAY+zo8NPcl71cPzOslO2g== X-Received: by 10.13.221.198 with SMTP id g189mr9653193ywe.93.1472667832333; Wed, 31 Aug 2016 11:23:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Wed, 31 Aug 2016 11:23:11 -0700 (PDT) In-Reply-To: <6918283.boJRZ9WqjH@pintsize.usersys.redhat.com> References: <6918283.boJRZ9WqjH@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 31 Aug 2016 11:23:11 -0700 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=94eb2c0779ce04eb65053b62337b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT encrypted data limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 18:23:56 -0000 --94eb2c0779ce04eb65053b62337b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario wrote: > Current draft has the following text in it: > > If any of these checks fail, the server MUST NOT respond > with the extension and must discard all the remaining first > flight data (thus falling back to 1-RTT). If the client attempts > a 0-RTT handshake but the server rejects it, it will generally > not have the 0-RTT record protection keys and must instead > trial decrypt each record with the 1-RTT handshake keys > until it finds one that decrypts properly, and then pick up > the handshake from that point. > > My understanding of that, in case client does 0-RTT but server rejects it > (because the PSK is too old or its time is different enough) is that the > server needs to keep on reading arbitrarily large amounts of data it has = no > idea what to do with. All using slow path (thinking exception handling in > particular). > > Is my understanding correct? > It's not clear to me that it's particularly slow. You get a MAC failure and rejecting the packet is slightly faster than processing it. Why is there no limit on the amount of data that can be encrypted using PSK > keys (0-RTT)? > I don't think this would usefully improve things. -Ekr -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0779ce04eb65053b62337b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 31, 2016 at 11:14 AM, Hubert Kario <hkario@redhat.com&= gt; wrote:
Current draft has the f= ollowing text in it:

=C2=A0 =C2=A0 If any of these checks fail, the server MUST NOT respond
=C2=A0 =C2=A0 with the extension and must discard all the remaining first =C2=A0 =C2=A0 flight data (thus falling back to 1-RTT). If the client attem= pts
=C2=A0 =C2=A0 a 0-RTT handshake but the server rejects it, it will generall= y
=C2=A0 =C2=A0 not have the 0-RTT record protection keys and must instead =C2=A0 =C2=A0 trial decrypt each record with the 1-RTT handshake keys
=C2=A0 =C2=A0 until it finds one that decrypts properly, and then pick up =C2=A0 =C2=A0 the handshake from that point.

My understanding of that, in case client does 0-RTT but server rejects it (because the PSK is too old or its time is different enough) is that the server needs to keep on reading arbitrarily large amounts of data it has no=
idea what to do with. All using slow path (thinking exception handling in particular).

Is my understanding correct?

It's n= ot clear to me that it's particularly slow. You get a MAC failure and r= ejecting
the packet is slightly faster than processing it.
<= div>

Why is there no limit on the amount of data that can be encrypted using PSK=
keys (0-RTT)?

I don't think this wo= uld usefully improve things.

-Ekr

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c0779ce04eb65053b62337b-- From nobody Wed Aug 31 11:26:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD82012D668 for ; Wed, 31 Aug 2016 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8YSZTqpLvcI for ; Wed, 31 Aug 2016 11:26:12 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id BC4BA12D661 for ; Wed, 31 Aug 2016 11:26:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 278F911400; Wed, 31 Aug 2016 21:26:09 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 5bZ6h2WGIQJ9; Wed, 31 Aug 2016 21:26:09 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id EF1DE21C; Wed, 31 Aug 2016 21:26:08 +0300 (EEST) Date: Wed, 31 Aug 2016 21:25:58 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20160831182558.g5aak2skih25utfj@LK-Perkele-V2.elisa-laajakaista.fi> References: <6918283.boJRZ9WqjH@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6918283.boJRZ9WqjH@pintsize.usersys.redhat.com> User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] 0-RTT encrypted data limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 18:26:13 -0000 On Wed, Aug 31, 2016 at 08:14:33PM +0200, Hubert Kario wrote: > Current draft has the following text in it: > > If any of these checks fail, the server MUST NOT respond > with the extension and must discard all the remaining first > flight data (thus falling back to 1-RTT). If the client attempts > a 0-RTT handshake but the server rejects it, it will generally > not have the 0-RTT record protection keys and must instead > trial decrypt each record with the 1-RTT handshake keys > until it finds one that decrypts properly, and then pick up > the handshake from that point. > > My understanding of that, in case client does 0-RTT but server rejects it > (because the PSK is too old or its time is different enough) is that the > server needs to keep on reading arbitrarily large amounts of data it has no > idea what to do with. All using slow path (thinking exception handling in > particular). Yes, read the data and attempt to decrypt it with handshake keys (with GCM and POLY1305, failed decryptions are faster than successful ones, of course there is exception overhead if those are used). -Ilari From nobody Wed Aug 31 12:17:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A2112D6B5 for ; Wed, 31 Aug 2016 12:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdckpbR6ZZGV for ; Wed, 31 Aug 2016 12:17:01 -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 7C8CA12D6AC for ; Wed, 31 Aug 2016 12:17:01 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id v123so61844490qkh.2 for ; Wed, 31 Aug 2016 12:17: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-transfer-encoding:message-id; bh=RX9KhshcDg+McRwnTIU15uOEEycVJWKeYGXFoceO5m4=; b=y2w2VbKzj8KWnKhAlCA+A+TGGCMYXfc7Ets6OgDHoiNC+x1YTR1g1sj4EsfOdGM23V di2qPUpJXGoqqg85njOihur1WuTBPcNrdEI26WIHgSR0vUb4PRBO3uDnNBhlZQNtJ/Cp KgPir3rX3sopYYOjs9jid5Gb8dSTMQsLOIckcnn+14yfcQHi/pC8PxtZVtsiUQEacjAo N37qE2Hirswscu8BAC49WCNZXtP/VSYRiuRCzlj/pqu0oyg0KOpbWdvcXXy6LWp4WGHf G38yQEHWGTSUpIaLFF4jbU4uT8NEj2GxpQQvmcxPuOTsGppx0RZgfDaQ1jVBOzriGOsl H1dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=RX9KhshcDg+McRwnTIU15uOEEycVJWKeYGXFoceO5m4=; b=ADRy18wW6LrqtYu7C8riGWWP4n6yV8HKo8HNhAQFJ/OdnhtAW1ZC5a7zr9oT48WyGl U+GaTro2CXJ6rYjB2oCRwUMVP0N2jVeBvDRK5RAxkBvn8Iw+yUYqm9BrVVgPtjc+pQNL kaneW1xN7ZYKUtyGwPrDJav8KQeBV/SOeFFOaeVvgqVbPUUbShcuiC7SwPDwBfuDYHHR 9gtD08yPLeRzH+/EwPluoXDqxH1GUjp2qWUe4fbioiAl1/lRT5qfn+sMxbTsst7pFK+Q L3byiimfCo0yEBDfuQG+YAveU54rSbZoT/Rb2MYCV+mtVjtIwPw0kz9Ohxy4/+0uhU4b R/rQ== X-Gm-Message-State: AE9vXwOkNHh37djnUpWA4SNByJXLanRS2Fmh44WOYM/Bf53QvlR0tLB6d1jnf5o1k6JkyQ== X-Received: by 10.55.187.68 with SMTP id l65mr12514112qkf.82.1472671020400; Wed, 31 Aug 2016 12:17:00 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id w94sm738326qte.40.2016.08.31.12.16.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 31 Aug 2016 12:16:59 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 31 Aug 2016 15:16:57 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201608301419.33620.davemgarrett@gmail.com> <7a56f6b950b46eeb07353805f020c9b8@trigofacile.com> <9A043F3CF02CD34C8E74AC1594475C73F4D08BDD@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D08BDD@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201608311516.58569.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 19:17:03 -0000 (replies to 4 separate but related posts, below) On Wednesday, August 31, 2016 03:52:44 am Peter Gutmann wrote: > Julien =C9LIE writes: > >Considering that possible change, wouldn't it be useful to go on working= on > >draft-gutmann-tls-lts-05, and consider TLS-LTS not as a TLS extension bu= t as > >a real 1.3 version of the 1.x series? >=20 > If the current 2.0-called-1.3 is renamed to 2.0, I'd be open to calling L= TS > "1.3", although I think it's more a 1.2.1 :-). Its real goal though is t= o be > exactly what it says on the label, an LTS version of the TLS 1.x line tha= t can > be used in devices with long lifecycles that are based on the 1.x family = and > need a best-of-breed version of that. So LTS would be the final, wrap-up > version of the 1.x line for people who need, well, an LTS version of the > protocol. You can't really do that. The HTTP/2 spec explicitly refers to TLS 1.3 and = up as not needing the security restrictions on TLS 1.2 it lays out. Any TLS= 1.2 LTS will need to be 1.2.x to deal with old documents citing the draft.= (there's also citations of analysis of TLS 1.3 that reference it) On Tuesday, August 30, 2016 05:21:21 pm Daniel Kahn Gillmor wrote: > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml > doesn't have a "TLS version" registry. Would it be simpler to have IANA > create that and just populate it with: >=20 > Value | Description | Reference > ------+-------------+---------- > 0x30 | SSLv3 | RFC 6101, RFC 7568 > 0x31 | TLSv1.0 | RFC 2246 > 0x32 | TLSv1.1 | RFC 4346 > 0x33 | TLSv1.2 | RFC 5246 > 0x34 | TLSv4 | RFC XXXX I've already dropped the struct major/minor labels and changed the type to = just uint8x2 in my draft of this proposal. Explicitly adding a registry to = go with this sounds good to me. On Wednesday, August 31, 2016 05:35:47 am Xiaoyin Liu wrote: > It's normal that people confuse SSLv3 with TLS. SSL 3.0 was a released an= d widely deployed protocol, and the term "SSL" is still widely used today t= o refer to TLS.[...] "Normal" people have no clue what SSL or TLS is. Personally, I say that any= one saying "SSL" should be interrupted by saying "SSL is dead, long live TL= S". All of SSL has been diediedied, so it's a reasonable cutoff point to su= pport expectations for the moment, at least. SSL/TLS is a mess of over 20 y= ears of stuff; we can't clean it up fully, but we can try to make it a litt= le more clear. ;) On Wednesday, August 31, 2016 04:47:59 am Hubert Kario wrote: > if the WG really wants a TLSvX.0 name, the X really should be bigger than= 3 We can call it TLS-2016 in addition to 2.0, which could help with some peop= le, but doing the disjoint versioning thing is not a good idea, IMO (and a = fair portion of the WG seems to be notably against it). I don't want to do = a confusing thing to try to mitigate another confusing thing. Dave From nobody Wed Aug 31 12:24:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A7712D73F for ; Wed, 31 Aug 2016 12:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.785 X-Spam-Level: X-Spam-Status: No, score=0.785 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5bwBT2amB2i for ; Wed, 31 Aug 2016 12:24:36 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C6D12D73E for ; Wed, 31 Aug 2016 12:24:36 -0700 (PDT) Received: from [173.75.83.97] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1bfB7e-0002UZ-2T for tls@ietf.org; Wed, 31 Aug 2016 15:24:30 -0400 Date: Wed, 31 Aug 2016 12:24:30 -0700 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7905749c1ff73b7e8b6f162d72570fa0ed350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.97 Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 19:24:37 -0000 We could call it TLS 3.4 which would match the internal ID. :-) BTW, I think using something other than 1.3 is a good idea. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 From nobody Wed Aug 31 12:27:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833AE12D746 for ; Wed, 31 Aug 2016 12:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE9_8jSbZ79x for ; Wed, 31 Aug 2016 12:27:55 -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 497D512D747 for ; Wed, 31 Aug 2016 12:27:55 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id t7so62377015qkh.1 for ; Wed, 31 Aug 2016 12:27: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:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=umzwsuz27cGTSMCMzLbBIuxa9FZx2k5ZBr62+KUsfR8=; b=qB9SVJj+5gxDYcAtKk83Burc1+f2QdHQnMVg1a3jrfboa4nR2zoOUBKkLCIrHNmkF8 Fi55M6W6JSqEv/ARQSUQV1urlS6zXa2HauwWWSFKArjzMEMVWY+s21dNKJ5ei7qdCaJk y0zHrlWw5E1dHSL9PGh0ukdGlbja5mPiYVSO+Lsc0IckVL2CVKVBDy+o1wT+I7+yaOlm D2bk2jOb/DuGiCnK2hmDHLVRT0YV7nIUrpRoD01ecoLlhbI26I+dYnNrCP2l6Iom7cBe GQh8Z0/OV8iaQTsu0y62P4ee2mVSFUrClpB1Rl7MDK6nPrLoNTqjlqB/dZc553Mvkg+K EcuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=umzwsuz27cGTSMCMzLbBIuxa9FZx2k5ZBr62+KUsfR8=; b=cUWcgaIEYRZCfOjd/8bIVyl+kXWLpA6eMs4vGX7VtQAR4HvTL3u4Dq7BNuM8JDbRAU RMwE313WcuxIgIS8kzq/W7ST0egFIxfiX/wXsW1CgLutEapDMoHB5EU6BYMEm2o0RzCL 6fwTMMdJE7VE9DAKdmJ3suqTfbINAWBajBg9ju7VR1w5T+0H7l8SrHISDadifu/d2sPD qNI7iYCGoH1UVTO+VuRFRlcA160jHhZ15sycijDVvizJiz9/X+hWOqrAi+JXqw7fs06w qZkKqNokcVYOs2agzX9ah7Gu9sXo4LLSIWtFWmIxUI3kU60tsGax484maHSozJCKTLvO VHrQ== X-Gm-Message-State: AE9vXwPPLRoVlkdsCQ+Bhum5nVaPlQC7iIjt4NPUvl53b3Vp6SHZErf9RKlrFEVdtatEAA== X-Received: by 10.55.178.196 with SMTP id b187mr13303574qkf.121.1472671674522; Wed, 31 Aug 2016 12:27:54 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id i65sm791353qtb.18.2016.08.31.12.27.53 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 31 Aug 2016 12:27:53 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 31 Aug 2016 15:27:52 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <6b05e1f2c2bd0fb699f4650182b8ddd4@trigofacile.com> <87shtkevn1.fsf@alice.fifthhorseman.net> In-Reply-To: <87shtkevn1.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201608311527.52985.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Terminology clarification around SSL & TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 19:27:56 -0000 On Wednesday, August 31, 2016 12:44:02 pm Daniel Kahn Gillmor wrote: > i would like to continue to be able to say unambiguously that all known > versions of SSL are badly broken and should be avoided. Let's not muddy > those waters further. +1 From nobody Wed Aug 31 12:48:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A435812D76A; Wed, 31 Aug 2016 12:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb7oKJkXrJth; Wed, 31 Aug 2016 12:48:25 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.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 9307712D763; Wed, 31 Aug 2016 12:48:25 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1bfBUm-0004xP-FS; Wed, 31 Aug 2016 13:48:24 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1bfBUh-0006Gr-7y; Wed, 31 Aug 2016 13:48:24 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u7VJmCVo018787; Wed, 31 Aug 2016 13:48:12 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u7VJmChl018731; Wed, 31 Aug 2016 13:48:12 -0600 Date: Wed, 31 Aug 2016 13:48:12 -0600 Message-Id: <201608311948.u7VJmChl018731@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: tls@ietf.org, cfrg@irtf.org In-reply-to: Yourmessage X-XM-SPF: eid=1bfBUh-0006Gr-7y; ; ; mid=<201608311948.u7VJmChl018731@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1+5F8eDz/iICr5a6fraBVca X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;tls@ietf.org, cfrg@irtf.org X-Spam-Relay-Country: X-Spam-Timing: total 4804 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.4 (0.1%), b_tie_ro: 2.4 (0.1%), parse: 0.68 (0.0%), extract_message_metadata: 21 (0.4%), get_uri_detail_list: 2.0 (0.0%), tests_pri_-1000: 8 (0.2%), tests_pri_-950: 1.22 (0.0%), tests_pri_-900: 1.01 (0.0%), tests_pri_-400: 24 (0.5%), check_bayes: 23 (0.5%), b_tokenize: 6 (0.1%), b_tok_get_all: 9 (0.2%), b_comp_prob: 2.8 (0.1%), b_tok_touch_all: 3.8 (0.1%), b_finish: 0.69 (0.0%), tests_pri_0: 255 (5.3%), check_dkim_signature: 0.48 (0.0%), check_dkim_adsp: 6 (0.1%), tests_pri_500: 4488 (93.4%), poll_dns_idle: 4480 (93.3%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: "This is the mailing list 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, 31 Aug 2016 19:48:27 -0000 > From: Brian Sniffen > >> From: Derek Atkins > >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > > > >> "Steven M. Bellovin" writes: > > > >> > Yes. To a large extent, the "IoT devices are too puny for real > >> > crypto" is a hangover from several years ago. It was once true; for > >> > the most part, it isn't today, but people haven't flushed their cache > >> > from the old received wisdom. > > > >> This is certainly true for AES, mostly because many small chips are > >> including AES accelerators in hardware. It's not quite true for public > >> key solutions; there are still very small devices where even ECC takes > >> too long (and yes, there are cases where 200-400ms is still too long). > > > >> > It pays to look again at David Wagner's slides from 2005, on sensor > >> > nets and crypto: > >> > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf > >> > > > > > Unattended sensors with wifi present an unsolved crypto problem. They > > can last 10 years on an AA battery without crypto, probably well less > > than a year if they have to do any kind of encryption. These things > > will be everywhere, providing the data that will underly all kinds of > > decision-making. > Assuming there are *some* integrity requirements for the data, and that > they are deploying 32-bit ARM with AES support (stipulating that ~every > CPU will have AES support in a few years, as ~every CPU sold does > today), we're talking about *either* an ECDHE negotiation every few > months or a pre-shared key, good for ten years. > AES-GCM with hardware support compares favorably to SHA-2 without > hardware support, so if they've been able to last 10 years before, they > should do just fine in the future. The old devices won't last forever, > and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us > for ten years after 1.3 is out. > -Brian > > Although much of the solution may lie in hardware innovation, the > > world really does need minimal crypto algorithms. > > > > Hilarie > > An ARM is far too much hardware to throw at "read sensor/munge data/send data". Hilarie From nobody Wed Aug 31 13:07:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B59412D770 for ; Wed, 31 Aug 2016 13:07:58 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7rcnh1bLP03 for ; Wed, 31 Aug 2016 13:07:57 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555DC12D763 for ; Wed, 31 Aug 2016 13:07:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 9F791E2043; Wed, 31 Aug 2016 16:07:55 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29739-01; Wed, 31 Aug 2016 16:07:53 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 52FCDE2047; Wed, 31 Aug 2016 16:07:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1472674073; bh=GXtNRrQpTh5DfqBvTHFGIJKxWZbQxfSqWTDOXWNP70k=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=Y1C1BdigjmgfV+MCgNKtpUQB97GGxWltYz2RNTssD/cH89Q4LNwOwFC+0SzczGxeD OZC9DkDXWC8fxzmtDZMhNCLc1Ka/0cHtyWIKw2nIK+9JpP6SSbcNo5DlJ5QKiYSfQo LSskAntfxi4LePKlpA2uBuUFhHKMNL1w7jTt0Oog= Received: from 2001:470:e448:2:ea2a:eaff:fe7d:235 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 31 Aug 2016 16:07:53 -0400 Message-ID: In-Reply-To: <201608311948.u7VJmChl018731@rumpleteazer.rhmr.com> References: <201608311948.u7VJmChl018731@rumpleteazer.rhmr.com> Date: Wed, 31 Aug 2016 16:07:53 -0400 From: "Derek Atkins" To: "Hilarie Orman" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: cfrg@irtf.org, tls@ietf.org Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 20:07:58 -0000 On Wed, August 31, 2016 3:48 pm, Hilarie Orman wrote: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > data". What about an 8051? > Hilarie -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 31 13:22:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6919712D76F for ; Wed, 31 Aug 2016 13:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUhdxlx6xCsu for ; Wed, 31 Aug 2016 13:22:25 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F215112D6A2 for ; Wed, 31 Aug 2016 13:22:24 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id n66so4299076qkf.0 for ; Wed, 31 Aug 2016 13:22:24 -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-transfer-encoding:message-id; bh=jl43gjGIEdzjTfwE4N42oZ/OxqvD/dVgVbaZ+rmnQMA=; b=E/ctl6lHkN6+dfkiDRquU7n36Mu56+/lPkTJ1huJ9PKSgPJNmNwAONzF8Wmop45kbp xDVRpi0RQp8sjwqasvqlLE6daNKiISa2lAUhU4ORpG9lUhFakTsA0YTlEpRgfDlDMXPc gMEFRFLAUt8Q9o8i8G3A1MlfBU3qkE6/iXKZEmR55TyO5Gcl5Ekz7p95cjsyN2Ew63Kz vHIQh2K4johJ8OtJQL8jzys8dA+ZA6glpu5sGVtO65L/LAJ6sr9Mp93ROb0eMfzgVirx W7V20Cw3vCyQiDJiupYA5W2Ig61iqj/gdCkOPNku8WnLDWtBNCEcEnudU2qEdb1lYGyj LCtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:mime-version :content-transfer-encoding:message-id; bh=jl43gjGIEdzjTfwE4N42oZ/OxqvD/dVgVbaZ+rmnQMA=; b=UfqXbV9OnPQQhkcbT81CXixALYt4RfeC0h1wmv3n6m8VgkFxzWhwzICG2OQDh8EiEM ylg78pGrUCWeBqpVwlybKkeHq38fO+jxUZpKp4mUeUDkc87iswvrcbu5EfzZclKbiQqA +BA5hxgYGRzhWmh9v5ACNYmz5ZESpBLgCLVJffrO9WuRz1MSA6d/LD+ExKYibqT5nJ08 lL+LAiBpDos5YF22gQVzTTJ+UXYfRE9jS9L92WpYS/2LfJcZfb0+oV+RzFCXSITyZrh5 2s6Tzv+OdvOiN5DtCnKSnzv6lJ/EzY4z7AmGJI5gj6rwZXSXaAe1i25ay7car26YL0YD s/5Q== X-Gm-Message-State: AE9vXwPossXEqX/U8XtELrKQwGGrXbsVWEyULhTBG1L1EFHbAP+br9O8ZE98B5wjGy330Q== X-Received: by 10.55.59.202 with SMTP id i193mr12422903qka.125.1472674943936; Wed, 31 Aug 2016 13:22:23 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id v65sm883659qte.41.2016.08.31.13.22.23 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 31 Aug 2016 13:22:23 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 31 Aug 2016 16:22:22 -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: <201608311622.22325.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 20:22:26 -0000 I've updated my WIP based on feedback and submitted it as a PR here: https://github.com/tlswg/tls13-spec/pull/612 If anyone else catches another spot that needs some updating, please comment on the PR. As this is a rather notable change, I do propose this remain open for discussion for at least a week or so before the chair assesses consensus. Dave From nobody Wed Aug 31 15:35:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F1012D7B5 for ; Wed, 31 Aug 2016 15:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-FlSQ7gR8Sl for ; Wed, 31 Aug 2016 15:35:25 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 AF0D912D7A6 for ; Wed, 31 Aug 2016 15:35:25 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id i184so36227557itf.1 for ; Wed, 31 Aug 2016 15:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qu7JAn10K6LFG0jzrLaA2cCDLB9BdPIYjIVqvVmOd94=; b=Vicm56IwYZx6cQIr/0JHI456Mf9vDwmbwoqQNnX0qYt4FpZ9w7ikKd69kDndeZkvUx 9ytflW5fIq8COJc8IABr/JKq8HtU/9tyjPNIS5JKOivXEfffKYnbeVZGM72MBmppVh8y 4JBO53tn8UO2xILJfXU6Ux7FFpEHiOxzrrB/mtfk8TwSh2WUARoE8IXTtd8GIW0GYBB7 bRBdpoIh7KrPXm2XxEh4qRD0Lk81aaSgLs+3dSjJmdegCoUURz2rz7STsd6psR9oGLGS Lq2cm5zsVEiEvxL/+92TUlxGiHJiFPTkTTWSzLkYiQw/tQMWGguXIQXobxI3aftE0lOr L9Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qu7JAn10K6LFG0jzrLaA2cCDLB9BdPIYjIVqvVmOd94=; b=iX9+Nams1RI24ultZbNqAzx74FFmNizqZ0WjqR0EZXg87cOekEZzadFdCxkS41npvL 7hbGFAlhZa5y2iyJAfJIF2Ou0sWqWm1q/18b5XC9Jj7214MIO6GU4nZouv+H3ACI5uVL QhbkvdFtiyPyQ8uYDyaxU9vPIug/QaDy/rGktz6uw58Er53rCaqZplkCGQOWLP1/kfRO 2twB0axD2DDbq4sjPgjwejJHzA3+5m1RK2nDpkXJ4OlHl1Z+H8EwyPigSLlOzS8dXql8 B0DeMT37mosCkAhNVgQWtOzj+2kyuUJlDgF5N44N1eTRt2OouW5x24oAOrkZOYd+DcTG /S3A== X-Gm-Message-State: AE9vXwNh4k55WqTiFp6yWB3+CitsNqhCAaFkO14eUYgVn+rFCQQRQNsH1LOa2Y18HBcjguagU22K9jAFTca88w== X-Received: by 10.36.230.69 with SMTP id e66mr1766066ith.36.1472682923815; Wed, 31 Aug 2016 15:35:23 -0700 (PDT) MIME-Version: 1.0 References: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> In-Reply-To: From: Nick Sullivan Date: Wed, 31 Aug 2016 22:35:13 +0000 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=94eb2c11cbe48a77ca053b65b6c2 Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 22:35:27 -0000 --94eb2c11cbe48a77ca053b65b6c2 Content-Type: text/plain; charset=UTF-8 I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a few immediate issues with the proposal: - it causes confusion with SSL 2.0 - it implies wire incompatibility with TLS 1.2 - it suggests there will be a forthcoming TLS 2.1 with only minor changes If we're dead set on bumping the major version for a mostly backwards compatible protocol change, we should just drop the minor version and go with TLS/2. Nick On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz wrote: > We could call it TLS 3.4 which would match the internal ID. :-) > > BTW, I think using something other than 1.3 is a good idea. > > Cheers - Bill > > ------------------------------------------------------------------------- > Bill Frantz | When it comes to the world | Periwinkle > (408)356-8506 | around us, is there any choice | 16345 Englewood Ave > www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c11cbe48a77ca053b65b6c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am reluctant to endorse a name change from TLS 1.3 = to TLS 2.0. I see a few immediate issues with the proposal:
- it = causes confusion with SSL 2.0
- it implies wire incompatibility w= ith TLS 1.2
- it suggests there will be a forthcoming TLS 2.1 wit= h only minor changes

If we're dead set on bump= ing the major version for a mostly backwards compatible protocol change, we= should just drop the minor version and go with TLS/2.

=
Nick

On Wed,= Aug 31, 2016 at 12:24 PM Bill Frantz <frantz@pwpconsult.com> wrote:
We could call it TLS 3.4 which would match the internal ID. :-)
BTW, I think using something other than 1.3 is a good idea.

Cheers - Bill

------------------------------------------------------------------------- Bill Frantz=C2=A0 =C2=A0 =C2=A0 =C2=A0 | When it comes to the world=C2=A0 = =C2=A0 =C2=A0| Periwinkle
(408)356-8506=C2=A0 =C2=A0 =C2=A0 | around us, is there any choice | 16345 = Englewood Ave
= www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 950= 32

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--94eb2c11cbe48a77ca053b65b6c2-- From nobody Wed Aug 31 15:42:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776FD12D77C for ; Wed, 31 Aug 2016 15:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvevivaEp0-z for ; Wed, 31 Aug 2016 15:42:30 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 014F712B049 for ; Wed, 31 Aug 2016 15:42:29 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id i184so36478263itf.1 for ; Wed, 31 Aug 2016 15:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=llBqBDgxsgxNAmwzY4DXWZ5lYtIObZ8ECZZv34TVVaw=; b=ZwotSTn9PAgjTQjJgvWDdlIDZFd5YVCx5wO6YgJCwP/lzlbIjicc+cEl99ULNBhh/N z/4PScurv2pilJwIYuWuTE0NYrlWwyy2UDDm+MPQa9Gz7gBeZPG/iQKjyue8QA11Rb8R MT7ID9JS/uE9YQWqhp7zkvyji9uRGBwlo+RMn3Kdir/NL2QGDrjia53W/8GW93c37u4P mz6IHkXD72ARlYIGeqjvjwwsyTOSTbFnjOQrn30WjzDwL/58LovWb3qpCFb8u+/q5JOC RqSKgSF+SiSDMPxuXojP51Fi3K3p1KgTGpKQx7AF1o9Cz4cbiJIMIAfkZhucFz7Ka/4O /dpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=llBqBDgxsgxNAmwzY4DXWZ5lYtIObZ8ECZZv34TVVaw=; b=D5JcYeJLtipfukheUXIt9500r5gHk+4vwVAmHsO5lcAWuiBHUDorygeGyw+VfM3y4F tZ2ZuVpWifcqg+OMSKvMDd73D7q1qJcZOZa1z1werNvnY140AE6b53XTxVpB5fG2T1mw 05ZN55xQFaNKVYC7mU1/kBQpxT0V+zdQjXuZgomA7y+uc71YdSGLeIEQVMQppedDb1Ns n+PbhwmvK4q/IPeWrFmBm7pdL1aTEPHRxgTGiqykPtiT2BHpQ6Dr0gskoyKVpQ0w0SbM aEXellEvj1MvL107UK56NM0k9X06DgwD7LlDgxsW/tZusNcbtrjBmf7fWuNMNpHsL+3P HWpw== X-Gm-Message-State: AE9vXwO0+cHCWTzezb4dRhTaxhd+5MOU5xDUEm1xu4UasDW1xQY5Ke0MFuONaA5EuIpHb1HKNkbAxB7BOEN5yg== X-Received: by 10.36.158.213 with SMTP id p204mr31874682itd.99.1472683349346; Wed, 31 Aug 2016 15:42:29 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.107.137.69 with HTTP; Wed, 31 Aug 2016 15:42:28 -0700 (PDT) In-Reply-To: References: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> From: Erik Nygren Date: Wed, 31 Aug 2016 18:42:28 -0400 X-Google-Sender-Auth: Gju76kP9JJGBVw1VCdU6Lh1JyAQ Message-ID: To: Nick Sullivan Content-Type: multipart/alternative; boundary=94eb2c05f97ee78ee6053b65cf6f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 22:42:31 -0000 --94eb2c05f97ee78ee6053b65cf6f Content-Type: text/plain; charset=UTF-8 Is it worth having a poll (hate it, neutral, love it) on options to judge preference It seems like options are (I may have missed some): - TLS 1.3 (ie, the default if we do nothing) - TLS 2.0 - TLS 2 - TLS/2 - TLS 4.0 - TLS/4 - TLS 4 - TLS 34 On the topic of "what does this re-open", I'm not convinced it does. The concept of doing a rename shortly before the last call goes way back and has been correctly deferred as bike-shedding until now. What color do we want our bike shed? Erik On Wed, Aug 31, 2016 at 6:35 PM, Nick Sullivan wrote: > I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a > few immediate issues with the proposal: > - it causes confusion with SSL 2.0 > - it implies wire incompatibility with TLS 1.2 > - it suggests there will be a forthcoming TLS 2.1 with only minor changes > > If we're dead set on bumping the major version for a mostly backwards > compatible protocol change, we should just drop the minor version and go > with TLS/2. > > Nick > > On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz > wrote: > >> We could call it TLS 3.4 which would match the internal ID. :-) >> >> BTW, I think using something other than 1.3 is a good idea. >> >> Cheers - Bill >> >> ------------------------------------------------------------------------- >> Bill Frantz | When it comes to the world | Periwinkle >> (408)356-8506 | around us, is there any choice | 16345 Englewood Ave >> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 >> >> _______________________________________________ >> 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 > > --94eb2c05f97ee78ee6053b65cf6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is it wo= rth having a poll (hate it, neutral, love it) on options to judge preferenc= e
It seems like options are (I may have missed some):

- TLS= 1.3=C2=A0 (ie, the default if we do nothing)
- TLS 2.0
-= TLS 2
- TLS/2
- TLS 4.0
- TLS/4
- TLS 4
<= /div>- TLS 34

On the topic of "what does this re-open&quo= t;, I'm not convinced it does.
The concept of doing a rename s= hortly before the last call goes way back
and has been correc= tly deferred as bike-shedding until now.
What color= do we want our bike shed?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Erik



On Wed, Aug 31, 2016 at 6:35 PM, Nick Su= llivan <nicholas.sullivan@gmail.com> wrote:
I am reluctant to endorse= a name change from TLS 1.3 to TLS 2.0. I see a few immediate issues with t= he proposal:
- it causes confusion with SSL 2.0
- it im= plies wire incompatibility with TLS 1.2
- it suggests there will = be a forthcoming TLS 2.1 with only minor changes

I= f we're dead set on bumping the major version for a mostly backwards co= mpatible protocol change, we should just drop the minor version and go with= TLS/2.

=
Nick

On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz = <frantz@pwpco= nsult.com> wrote:
We could= call it TLS 3.4 which would match the internal ID. :-)

BTW, I think using something other than 1.3 is a good idea.

Cheers - Bill

-----------------------------------------------------------------= --------
Bill Frantz=C2=A0 =C2=A0 =C2=A0 =C2=A0 | When it comes to the world=C2=A0 = =C2=A0 =C2=A0| Periwinkle
= (408)356-8506=C2=A0 =C2=A0 =C2=A0 | around us, is there any choice | 16= 345 Englewood Ave
= www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 950= 32

_______________________________________________
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


--94eb2c05f97ee78ee6053b65cf6f-- From nobody Wed Aug 31 15:43:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA44A12D7B2 for ; Wed, 31 Aug 2016 15:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0iAmJ5jO68U for ; Wed, 31 Aug 2016 15:43:23 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43F512D77C for ; Wed, 31 Aug 2016 15:43:22 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id v123so67258505qkh.2 for ; Wed, 31 Aug 2016 15:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=/YpVrk6cqpvghk95WQZRVC18tYMcgTu+vxqMv65qBQY=; b=mY6PlU+aSXxFtLgsC+vlk/3/Gp2mqTD6pOBOvLClJEZYOGwF1yIA0vFvdGs7mxwSDE 8iQufzGZbWzWGWqz5YCwTAwmTBK6rJ+t8fXVahUDHayTJdWkrDMGNyWvAduXno2lItSp voVGbgxbP/GsuwKI99N7vxp6l59WjSjoGDJ5DLnS/gDxZIno8eCv2B4VNJTTCofy1pHV j05+vWAV8/AarhuJLFenhdVNFvUrkibz7cGMYCbokJOz0JJj/ab0SYBwdyEEJJghFeNS QLijRQ0RKp3r9dIbX071QNYd7DlkmKjTDW0lFQdUQbclgCSCG3o7NppGID7qCy1lWJwq xkDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=/YpVrk6cqpvghk95WQZRVC18tYMcgTu+vxqMv65qBQY=; b=YtVfCbr7B10eC2DNOzjpgRRZixKSDywDJYxg3h568NML24ihdA0RkLcEcVGiCK2M3X l4ePGwtXGm0KEPBe7kweOVCulPsyI2u/CGs6kmqarVzx2ktmcdJg9k08NRUkrNgygCAh c5XSBuxTVcyW+JWgGv44dc6EOLXjqh/dhuAEVklXMt7KsUFcT2X6KWb1/rXA9DGt/rOz 07DMpg5DjVfgveWMM7TAInOSiB7ljdfvHtFM7KilMx38bRl5WYuMtVV7+zsNOUlaLFSN NM6fjTcJgs/qCA7aAYHXwoHyP/LR9URlDgK+lvxuABVllBI7PW5a1jnPcMt3iLeziCgJ /zTA== X-Gm-Message-State: AE9vXwN1Zpy65M9woDja25a3X2SmBR7nwHx1ZJvLdl4eKtLiK2Ey1pJz5BuoO4DfvwUJIQ== X-Received: by 10.55.8.4 with SMTP id 4mr13780597qki.196.1472683402121; Wed, 31 Aug 2016 15:43:22 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id d133sm1194800qke.20.2016.08.31.15.43.21 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 31 Aug 2016 15:43:21 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 31 Aug 2016 18:43:20 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201608311843.20382.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 22:43:24 -0000 On Wednesday, August 31, 2016 06:35:13 pm Nick Sullivan wrote: > I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I was too, until we created a new cipher suite negotiation incompatible with previous versions. > I see a few immediate issues with the proposal: > - it causes confusion with SSL 2.0 I disagree. There is a perpetual confusion between SSL and TLS, but this doesn't really make it that much worse. > - it implies wire incompatibility with TLS 1.2 SSL 3.0 and TLS 1.0 share compatible hellos. A TLS 2 only client won't be able to connect to a TLS 1.2 only server, but that's true with all version changes. I don't see how a major version bump implies any more wire incompatibility, especially when we bend over backwards to maintain hello compatibility with SSL 3. > - it suggests there will be a forthcoming TLS 2.1 with only minor changes There could be, if we wanted to. I don't see a problem with that. > If we're dead set on bumping the major version for a mostly backwards > compatible protocol change, we should just drop the minor version and go > with TLS/2. I don't have a problem with dropping the ".0", but I don't see the point in the HTTP/2 style slash. TLS 2 is fine. Dave From nobody Wed Aug 31 16:05:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8654612B043 for ; Wed, 31 Aug 2016 16:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqGIyk-kjG3E for ; Wed, 31 Aug 2016 16:05:48 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 8421312B02A for ; Wed, 31 Aug 2016 16:05:48 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id l94so115748321ual.0 for ; Wed, 31 Aug 2016 16:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=72K1dGQOn00fMTA3Idq7W/cL5UT6Xj8mUSG/jNylhxM=; b=CyOmdfbAid2fRKH4/ju6j/5+JGkTSwNSTdZzMGlo3rtnS2LQieGagyWbgPSxlHDI2m 3qUpVOTmoZO5wM2QZ+NbJ1n+K5dVnRzDCVGfzo3qL6+P2LLpxxVVEZC5ejUsghlWFBGP Oi20SS0tbTswA0ZwTIqg/bOGyD3VmdSfbTeCTqhVaVDj6HlawFqHGGhecR7yLiViprRc YpbIqkZXtduB/IK//VGhVENer/wZzljSpXKBiZvhaqhFfeSzrynRTsPLc0pziN65d54Q pYii3EZomk7gZPPnyT8i/iwVLzuS7jAyISy/MgCQC2Jx7yBncswGlbv9jXYVYgOSSO9D CLWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=72K1dGQOn00fMTA3Idq7W/cL5UT6Xj8mUSG/jNylhxM=; b=aA5gWkBV+5XSBCSOYFXjuJI2XUneFobkwj4MCCirUxM4vcF5yBgkq9HO3QHSj8G925 t/QNIDtJ1BUwxd4l2sUNGAv9sgFOl1Fm9wpPzhQLo7eCNVsej1nYFOipPiavI1zH/LFk GIq6RsBZU7uLR27+DRozJD3Y2lB6PvxaE7ZARCTy1J/U8Z/9GyARfWPp+ZYYqnV8N17C 7xBc6kJ6Pn1sFY3IZjRSZWCd/o0S8canFhZEuVB40wrkB3UG8ynjxD+hZmiVZy5SAJ5U OaHazdzr930mEVhzT7Gw24BHybiu82W6dnMBGFp1BTwt+zXc5c5jTbq3tcOw/AOhLlk+ WhlA== X-Gm-Message-State: AE9vXwP9eEuRrUCxBBXDrEFC4Q+vCLClQgDwmk7lSsMK2LUNq2TFd5K4xuNOR0YI7jsVoZ8V9Tde+6rZF/eDGg== X-Received: by 10.176.69.168 with SMTP id u37mr6486360uau.16.1472684747539; Wed, 31 Aug 2016 16:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.53.133 with HTTP; Wed, 31 Aug 2016 16:05:46 -0700 (PDT) In-Reply-To: References: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> From: Richard Barnes Date: Wed, 31 Aug 2016 19:05:46 -0400 Message-ID: To: Nick Sullivan Content-Type: multipart/alternative; boundary=94eb2c11c9e63e5b2f053b662333 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 23:05:49 -0000 --94eb2c11c9e63e5b2f053b662333 Content-Type: text/plain; charset=UTF-8 I am in total agreement with Nick here. "TLS 1.3" accurately describes what we're doing here, and it's consistent with our past naming scheme. There is no upside to changing away from 1.3, and as Nick notes, lots of potential downside. --Richard On Wednesday, August 31, 2016, Nick Sullivan wrote: > I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a > few immediate issues with the proposal: > - it causes confusion with SSL 2.0 > - it implies wire incompatibility with TLS 1.2 > - it suggests there will be a forthcoming TLS 2.1 with only minor changes > > If we're dead set on bumping the major version for a mostly backwards > compatible protocol change, we should just drop the minor version and go > with TLS/2. > > Nick > > On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz > wrote: > >> We could call it TLS 3.4 which would match the internal ID. :-) >> >> BTW, I think using something other than 1.3 is a good idea. >> >> Cheers - Bill >> >> ------------------------------------------------------------------------- >> Bill Frantz | When it comes to the world | Periwinkle >> (408)356-8506 | around us, is there any choice | 16345 Englewood Ave >> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --94eb2c11c9e63e5b2f053b662333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in total agreement with Nick here. =C2=A0"TLS 1.3" accuratel= y describes what we're doing here, and it's consistent with our pas= t naming scheme.=C2=A0

There is no upside to changing aw= ay from 1.3, and as Nick notes, lots of potential downside. =C2=A0

--Richard

On Wednesday, August = 31, 2016, Nick Sullivan <= nicholas.sullivan@gmail.com> wrote:
I am reluctant to endorse a name change from TLS 1.= 3 to TLS 2.0. I see a few immediate issues with the proposal:
- i= t causes confusion with SSL 2.0
- it implies wire incompatibility= with TLS 1.2
- it suggests there will be a forthcoming TLS 2.1 w= ith only minor changes

If we're dead set on bu= mping the major version for a mostly backwards compatible protocol change, = we should just drop the minor version and go with TLS/2.

Nick

On We= d, Aug 31, 2016 at 12:24 PM Bill Frantz <frantz= @pwpconsult.com> wrote:
We c= ould call it TLS 3.4 which would match the internal ID. :-)

BTW, I think using something other than 1.3 is a good idea.

Cheers - Bill

-----------------------------------------------------------------= --------
Bill Frantz=C2=A0 =C2=A0 =C2=A0 =C2=A0 | When it comes to the world=C2=A0 = =C2=A0 =C2=A0| Periwinkle
(408)356-8506=C2=A0 =C2=A0 =C2=A0 | around us, is there any choice | 16345 = Englewood Ave
= www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 950= 32

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--94eb2c11c9e63e5b2f053b662333-- From nobody Wed Aug 31 16:07:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E80C12D52C for ; Wed, 31 Aug 2016 16:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvhv6ZafNjNb for ; Wed, 31 Aug 2016 16:07:53 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D37012D1DA for ; Wed, 31 Aug 2016 16:07:53 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 11so20960189qtc.0 for ; Wed, 31 Aug 2016 16:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=oxwikq8fp5p9BckEx2c8orGitW1AIQFG0LOpla1lNSk=; b=P6904IDgDOzN4/Cp2QpGGgPH3C+hEGGYOCLznPaKi3V9xJWh1aTWSzZFyoWOZENxLT Br11uGYKMfuY8Q/LdFrOu1qKvALsFOYGNjsbi3q+2TdmhkM25F4pn2/06FusHxbnmoeY BE+D+A2Vi8zMZstSkzePqwiqlj5s/RH3caUY1qh5sAXGkxc86/ewfSDrAcGLxxIHQkq5 52f4bQRsEIg+6MetXPOAqCzBOgWDOdSvZGVA/l7mWx5s1k5dP3cQIrCt6lmEdA1EGLB9 joO98n3a8MLvv2NwULYsRjp+Ge7V8Gm0xaDuTG3PjX++rAXHEV5Y9VEVawNUfxemI40g KZCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=oxwikq8fp5p9BckEx2c8orGitW1AIQFG0LOpla1lNSk=; b=bLMfm3DSZ6j0hsrNjG3Z3ffFmrcZItKoFNjMsNrqOvorfpNcvgTwNaIjEnAgM+9Wxg bLtT81A7soRO8mDurtwrr/FrwV4u5mi6lYLdCa16kbeKkoG6MlW3luOYjvk3xfPJfkoI wDkr1NKWBD0RMz9cLXmsCzPKLJOupsC7xtA+diKKfJLW2d3q/rAaMKAY0+Oe0YaVOl68 +dft6xdFrB4sxo8BT3+cCfRdJj9LkRAbIPURxFS4hFlRhQt4Hin9gDFYmHysQpmHGb46 4qKfHhnIwUDWPxm3JCaj/0WutgW569/HVjUbV84uawikBtec+YMSz3Kybpz6N30z87Zr L5+A== X-Gm-Message-State: AE9vXwMCkx2k1lU/+K6xlPK6UxCnSlfWfL2AWsKnRzCkqMHY/XWY9ECgj5DK4pUSjFsI4A== X-Received: by 10.200.56.230 with SMTP id g35mr2504500qtc.29.1472684872358; Wed, 31 Aug 2016 16:07:52 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id 1sm1214887qkj.42.2016.08.31.16.07.51 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 31 Aug 2016 16:07:51 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 31 Aug 2016 19:07:50 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201608311907.50782.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 31 Aug 2016 23:07:54 -0000 On Wednesday, August 31, 2016 06:42:28 pm Erik Nygren wrote: > Is it worth having a poll (hate it, neutral, love it) on options to judge > preference > It seems like options are (I may have missed some): > > - TLS 1.3 (ie, the default if we do nothing) > - TLS 2.0 > - TLS 2 > - TLS/2 > - TLS 4.0 > - TLS/4 > - TLS 4 > - TLS 34 > > On the topic of "what does this re-open", I'm not convinced it does. > The concept of doing a rename shortly before the last call goes way back > and has been correctly deferred as bike-shedding until now. > What color do we want our bike shed? A few of us have specifically had discussions with people about how "TLS 1.3 is really TLS 2.0"; just relabeling it that should be fine. We risk over-complicating things by doing a number jump a la Windows 10. I don't particularly want to have to answer the question "what happened to TLS 3?" for the next decade or so. To repeat what I said in a previous reply, I think TLS 2-2016 or something is an ok way to reference things (outside of the spec doc). Dave From nobody Wed Aug 31 19:02:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E939312D7DD for ; Wed, 31 Aug 2016 19:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt7xCwAfE-Gy for ; Wed, 31 Aug 2016 19:02:28 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5ADF12B03C for ; Wed, 31 Aug 2016 19:02:28 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6DEEF3B490 for ; Wed, 31 Aug 2016 22:02:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=zF22BSeeAGBVS7lqK6lfX9rsIvU=; b=eb38Pq ZVyBp9on3MBfP6SZJYFziEPt0opPmxyWg80bo2uY/ZosfCZw66m1N5AJEIwI+uxO iklKusKSK4t5004xijciKx0V14RIrcUl7BKf5uRWeF66uj0+IGcYTcFTkjOqHC86 +xUg1oI8ceZxDeN4igADAkXCkdBdJFx4dXdLc= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 66E953B48F for ; Wed, 31 Aug 2016 22:02:25 -0400 (EDT) Received: from mail-qt0-f177.google.com (unknown [209.85.216.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 0A0F83B48C for ; Wed, 31 Aug 2016 22:02:25 -0400 (EDT) Received: by mail-qt0-f177.google.com with SMTP id 11so22513722qtc.0 for ; Wed, 31 Aug 2016 19:02:24 -0700 (PDT) X-Gm-Message-State: AE9vXwO8EXS6mtVEICGB/3bkNkxaOg7WAr/ETlkpzTASHvOTGA7ITOH442d4QisAPevRgoWWdyrh1u3ddXfx4Q== X-Received: by 10.200.50.86 with SMTP id y22mr1057398qta.61.1472695344165; Wed, 31 Aug 2016 19:02:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.187 with HTTP; Wed, 31 Aug 2016 19:01:43 -0700 (PDT) In-Reply-To: References: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> From: Eric Mill Date: Wed, 31 Aug 2016 22:01:43 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11405baada03a6053b689a06 X-Pobox-Relay-ID: 208C02C0-6FE8-11E6-B00B-F7BB12518317-82875391!pb-smtp1.pobox.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 01 Sep 2016 02:02:30 -0000 --001a11405baada03a6053b689a06 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes wrote: > I am in total agreement with Nick here. "TLS 1.3" accurately describes > what we're doing here, and it's consistent with our past naming scheme. > > There is no upside to changing away from 1.3, and as Nick notes, lots of > potential downside. > > --Richard > > On Wednesday, August 31, 2016, Nick Sullivan > wrote: > >> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a >> few immediate issues with the proposal: >> - it causes confusion with SSL 2.0 >> - it implies wire incompatibility with TLS 1.2 >> - it suggests there will be a forthcoming TLS 2.1 with only minor changes >> >> If we're dead set on bumping the major version for a mostly backwards >> compatible protocol change, we should just drop the minor version and go >> with TLS/2. >> >> Nick >> > FWIW, I've definitely seen real-world confusion about SSLv3 being a more recent protocol than TLS 1.X, by organizations that should know better. If there's interest and consensus, this could be a good opportunity to reset the situation with TLS/2 or TLS 4.0. I like TLS/2 aesthetically, and represents a similar level of progress/reset that HTTP saw when it jumped from 1.1 to /2. -- Eric > >> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz >> wrote: >> >>> We could call it TLS 3.4 which would match the internal ID. :-) >>> >>> BTW, I think using something other than 1.3 is a good idea. >>> >>> Cheers - Bill >>> >>> ------------------------------------------------------------ >>> ------------- >>> Bill Frantz | When it comes to the world | Periwinkle >>> (408)356-8506 | around us, is there any choice | 16345 Englewood >>> Ave >>> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA >>> 95032 >>> >>> _______________________________________________ >>> 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 > > -- konklone.com | @konklone --001a11405baada03a6053b689a06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wr= ote:
I am in total agr= eement with Nick here. =C2=A0"TLS 1.3" accurately describes what = we're doing here, and it's consistent with our past naming scheme.= =C2=A0

There is no upside to changing away from 1.3, and= as Nick notes, lots of potential downside. =C2=A0

--Richard

On Wednesday, August 31, 2016, Nick Sullivan <nicholas.sullivan@gmail.com> wrote:
I am reluctant to endorse a name change from TLS 1.3 to TLS 2= .0. I see a few immediate issues with the proposal:
- it causes c= onfusion with SSL 2.0
- it implies wire incompatibility with TLS = 1.2
- it suggests there will be a forthcoming TLS 2.1 with only m= inor changes

If we're dead set on bumping the = major version for a mostly backwards compatible protocol change, we should = just drop the minor version and go with TLS/2.

Nic= k

FWIW, I've definitely seen real-world confusion about SSLv3 being a m= ore recent protocol than TLS 1.X, by organizations that should know better.= If there's interest and consensus, this could be a good opportunity to= reset the situation with TLS/2 or TLS 4.0.=C2=A0



<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

=
We could call it TLS 3.4 which wo= uld match the internal ID. :-)

BTW, I think using something other than 1.3 is a good idea.

Cheers - Bill

-----------------------------------------------------------------= --------
Bill Frantz=C2=A0 =C2=A0 =C2=A0 =C2=A0 | When it comes to the world=C2=A0 = =C2=A0 =C2=A0| Periwinkle
= (408)356-8506=C2=A0 =C2=A0 =C2=A0 | around us, is there any choice | 16= 345 Englewood Ave
= www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 950= 32

_______________________________________________
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




--
--001a11405baada03a6053b689a06-- From nobody Wed Aug 31 19:54:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0364F12D0C8 for ; Wed, 31 Aug 2016 19:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnwfJPU7wWJ0 for ; Wed, 31 Aug 2016 19:54:26 -0700 (PDT) Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17910126FDC for ; Wed, 31 Aug 2016 19:54:25 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id u812s7Gb019901; Wed, 31 Aug 2016 22:54:15 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id BC9416D; Wed, 31 Aug 2016 22:54:15 -0400 (EDT) Received: from sendprodmail04.cc.columbia.edu (sendprodmail04.cc.columbia.edu [128.59.72.16]) by hazelnut (Postfix) with ESMTP id B13E46D; Wed, 31 Aug 2016 22:54:15 -0400 (EDT) Received: from [192.168.2.5] (smb-gw.apt.columbia.edu [128.59.107.140]) (user=smb2132 mech=PLAIN bits=0) by sendprodmail04.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id u812sDZM021675 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Aug 2016 22:54:15 -0400 From: "Steven M. Bellovin" To: "Derek Atkins" Date: Wed, 31 Aug 2016 22:54:13 -0400 Message-ID: <1468330B-F858-4E89-B791-B83507475C48@cs.columbia.edu> In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <89A46793-73A1-4C71-9954-37BF6ED6F297@callas.org> <5CF32AA8-59CC-4918-8951-A2ACBD233C19@cs.columbia.edu> MIME-Version: 1.0 X-Mailer: MailMate (2.0BETAr6052) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.16 Archived-At: Cc: David McGrew , "cfrg@irtf.org" , Jon Callas , tls@ietf.org Subject: Re: [TLS] [Cfrg] 3DES diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 01 Sep 2016 02:54:28 -0000 On 31 Aug 2016, at 10:17, Derek Atkins wrote: > "Steven M. Bellovin" writes: > >> Yes. To a large extent, the "IoT devices are too puny for real >> crypto" is a hangover from several years ago. It was once true; for >> the most part, it isn't today, but people haven't flushed their cache >> from the old received wisdom. > > This is certainly true for AES, mostly because many small chips are > including AES accelerators in hardware. It's not quite true for public > key solutions; there are still very small devices where even ECC takes > too long (and yes, there are cases where 200-400ms is still too long). > Certainly plausible. What I'm saying is (a) don't assert, measure; and (b) measure again next year because tech keeps improving. As for your specific points: if AES is indeed feasible, we don't need new ciphers. If elliptic curve is too slow, the only answer is architectures that don't use public key at all; we're not going to find new, cheaper public key algorithms without a *lot* of effort and the people who can do that sort of thing are too busy working on post-quantum crypto. The remaining approach is a cheaper protocol than TLS. That shouldn't be hard at all, especially if we're going back to KDCs. --Steve Bellovin, https://www.cs.columbia.edu/~smb From nobody Wed Aug 31 23:05:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB3812D0AA for ; Wed, 31 Aug 2016 23:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KC5NgUjnY4P for ; Wed, 31 Aug 2016 23:05:27 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 D94C612D094 for ; Wed, 31 Aug 2016 23:05:26 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id c198so25916254ith.1 for ; Wed, 31 Aug 2016 23:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mdltIF1M1Vl3kLSA/lnpblZ/K1+dnyyi5Z13r27pwfY=; b=RCsd7yYfYl3HIn60PHze2WqIYevOvpoHfZJw/2lkEUOHq80D79V13fjMZ8grTScTwq T76jbKn1ryMdeoQJxbxtdKyQT2qH+rMpnOq3Un/AptbGNFup4rZpLNrjHGfndku3F2hn SAhcUn4ZGyLLn1c7+7MCEfBIrjdvmbEBOQxoMfdl9agtr+v7Y2lqAYn85UW43Fxz2nsn auVUbpwQdFyvkrbh97hJwYv0L8n7RjzDBZ9GCcFWjCCAZ7f2pSoy23bXX5GCETvEHYQX 0v9WypXAVzA1kVh4ZWoBcvRYSwJ0cAhR0Z5YF5gU1a8PJobjXmjLhL+dOgcxFkiJyvA3 WYgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mdltIF1M1Vl3kLSA/lnpblZ/K1+dnyyi5Z13r27pwfY=; b=R/VPutFSAepxohFT7F8hljbuEiu60Td0kxYUyhES0j9YpcycwRWipuiPvfLFuEjguT LQNmpQdB2RtiM6dMYIO7iYulP0CkZzRZjH1o3q0e/DvUea8sTaOU+GDmeKNfNMRscJPr yB5OJsgABAEFH48gyxck4fZs5obQwoiy2b6b5iomfXtkh1Rv5ZE86SMnUd/j7EltjVm4 N7QEuj08i9C6Nu01P1ww2QkwfmUxuEVL6Q+84QBKbTSjjNm2rPabew9uNL8PpsR2MgtK KM7nN4reC/d0jd+eF3UFnx26Esa9CDnL8OUXyaFUC9EZVw09M84nsnn2I99KMtkOKwHd uUXQ== X-Gm-Message-State: AE9vXwMtj/mPHu7qPLW0sox2Mo6nXp2f2aXKnNZrrJXgzqEFoakn8XdVj9qYIi5BoCKhrHihoL8GcL9kFMQtaw== X-Received: by 10.36.60.10 with SMTP id m10mr38283097ita.95.1472709926266; Wed, 31 Aug 2016 23:05:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.249.165 with HTTP; Wed, 31 Aug 2016 23:05:25 -0700 (PDT) In-Reply-To: References: <3453142.248EJ6K14H@pintsize.usersys.redhat.com> From: Judson Wilson Date: Wed, 31 Aug 2016 23:05:25 -0700 Message-ID: To: Eric Mill Content-Type: multipart/alternative; boundary=001a114aa5ac032df2053b6c006f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 01 Sep 2016 06:05:28 -0000 --001a114aa5ac032df2053b6c006f Content-Type: text/plain; charset=UTF-8 > > FWIW, I've definitely seen real-world confusion about SSLv3 being a more > recent protocol than TLS 1.X, by organizations that should know better. If > there's interest and consensus, this could be a good opportunity to reset > the situation with TLS/2 or TLS 4.0. > > I like TLS/2 aesthetically, and represents a similar level of > progress/reset that HTTP saw when it jumped from 1.1 to /2. > > What is the slash in the name all about? Is it simply playing off the HTTP start line specification? Does it have any relevance to TLS? On Wed, Aug 31, 2016 at 7:01 PM, Eric Mill wrote: > > > On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes wrote: > >> I am in total agreement with Nick here. "TLS 1.3" accurately describes >> what we're doing here, and it's consistent with our past naming scheme. >> >> There is no upside to changing away from 1.3, and as Nick notes, lots of >> potential downside. >> >> --Richard >> >> On Wednesday, August 31, 2016, Nick Sullivan >> wrote: >> >>> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a >>> few immediate issues with the proposal: >>> - it causes confusion with SSL 2.0 >>> - it implies wire incompatibility with TLS 1.2 >>> - it suggests there will be a forthcoming TLS 2.1 with only minor changes >>> >>> If we're dead set on bumping the major version for a mostly backwards >>> compatible protocol change, we should just drop the minor version and go >>> with TLS/2. >>> >>> Nick >>> >> > FWIW, I've definitely seen real-world confusion about SSLv3 being a more > recent protocol than TLS 1.X, by organizations that should know better. If > there's interest and consensus, this could be a good opportunity to reset > the situation with TLS/2 or TLS 4.0. > > I like TLS/2 aesthetically, and represents a similar level of > progress/reset that HTTP saw when it jumped from 1.1 to /2. > > -- Eric > > > >> >>> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz >>> wrote: >>> >>>> We could call it TLS 3.4 which would match the internal ID. :-) >>>> >>>> BTW, I think using something other than 1.3 is a good idea. >>>> >>>> Cheers - Bill >>>> >>>> ------------------------------------------------------------ >>>> ------------- >>>> Bill Frantz | When it comes to the world | Periwinkle >>>> (408)356-8506 | around us, is there any choice | 16345 Englewood >>>> Ave >>>> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA >>>> 95032 >>>> >>>> _______________________________________________ >>>> 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 >> >> > > > -- > konklone.com | @konklone > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114aa5ac032df2053b6c006f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


FWIW, I've definit= ely seen real-world confusion about SSLv3 being a more recent protocol than= TLS 1.X, by organizations that should know better. If there's interest= and consensus, this could be a good opportunity to reset the situation wit= h TLS/2 or TLS 4.0.=C2=A0

I like TLS/2 aesthetical= ly, and represents a similar level of progress/reset that HTTP saw when it = jumped from 1.1 to /2.
=C2=A0

What i= s the slash in the name all about? Is it simply playing off the HTTP start = line specification? Does it have any relevance to TLS?


On Wed, Aug 31, 2016 at 7:01 PM, Eric Mill <= eric@konklone.com> wrote:


On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes <rlb@ipv= .sx> wrote:
I am in total agreement with Nick here. =C2=A0"TLS 1.3" accur= ately describes what we're doing here, and it's consistent with our= past naming scheme.=C2=A0

There is no upside to changin= g away from 1.3, and as Nick notes, lots of potential downside. =C2=A0

--Richard

On Wednesday, August 31, 2016, Nick Su= llivan <nicholas.sullivan@gmail.com> wrote:
I am reluctant to endorse a nam= e change from TLS 1.3 to TLS 2.0. I see a few immediate issues with the pro= posal:
- it causes confusion with SSL 2.0
- it implies = wire incompatibility with TLS 1.2
- it suggests there will be a f= orthcoming TLS 2.1 with only minor changes

If we&#= 39;re dead set on bumping the major version for a mostly backwards compatib= le protocol change, we should just drop the minor version and go with TLS/2= .

Nick
<= /blockquote>

FWIW, I've definitely seen real-= world confusion about SSLv3 being a more recent protocol than TLS 1.X, by o= rganizations that should know better. If there's interest and consensus= , this could be a good opportunity to reset the situation with TLS/2 or TLS= 4.0.=C2=A0

I like TLS/2 aesthetically, and repres= ents a similar level of progress/reset that HTTP saw when it jumped from 1.= 1 to /2.

-- Eric
=
=C2=A0

On Wed, Aug 3= 1, 2016 at 12:24 PM Bill Frantz <frantz@pwpconsult.com> wrote:=
We could call i= t TLS 3.4 which would match the internal ID. :-)

BTW, I think using something other than 1.3 is a good idea.

Cheers - Bill

-----------------------------------------------------------------= --------
Bill Frantz=C2=A0 =C2=A0 =C2=A0 =C2=A0 | When it comes to the world=C2=A0 = =C2=A0 =C2=A0| Periwinkle
= (408)356-8506=C2=A0 =C2=A0 =C2=A0 | around us, is there any choice | 16= 345 Englewood Ave
= www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 950= 32

_______________________________________________
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




--
<= /div>

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


--001a114aa5ac032df2053b6c006f--