From nobody Sun Feb 1 06:10:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BE61A88AC for ; Sun, 1 Feb 2015 06:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67scleMDKxpx for ; Sun, 1 Feb 2015 06:10:09 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532371A8861 for ; Sun, 1 Feb 2015 06:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1422799810; x=1454335810; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=B3cDh+VXEg57bG/HF2xMJaovvOelYlan7uQnuhIJ3qo=; b=aqGpzaWhi+BROmPxaOjs2/WRvqC3kCRYt0132e995rUhg20ZMzpccxXd 5fkaf+WcZ+v1AYDHus7pwww2FU08UCetUMDdB5Sg8Ro5U6Vb/BImQA4cY wYHLsiW1QMnRzTCUXWixKK+kQgoeQziSLY8bnCLRvjSalSR3axzuaOTt5 s=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="305030390" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Feb 2015 03:10:07 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 2 Feb 2015 03:10:06 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00 Thread-Index: AdA+KMcs5PuUvTrOQeCk5D+YFbe5yQ== Date: Sun, 1 Feb 2015 14:10:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF6D99D@uxcn10-tdc05.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: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 14:10:18 -0000 Kurt Roeckx writes:=0A= =0A= >We're now between 50% and 70% that support TLS 1.2 depending on who you as= k.=0A= =0A= That's the publicly-visible servers, i.e. standard PCs (including ones in= =0A= racks in data centres). In the embedded space, support for TLS 1.2 is... l= ow.=0A= OS-based support (e.g. in VxWorks, claimed to be the world most widely-used= =0A= RTOS) is nonexistent, you need to go to third-party libraries for this, and= =0A= even then it's not common.=0A= =0A= >My current expectation is that it's most likely going to take until 2020 t= o=0A= >actually get TLS 1.2 support to the level we now see for TLS 1.0 (around= =0A= >99.5%) for both client and server.=0A= =0A= For embedded it's going to be much longer than that...=0A= =0A= Peter.= From nobody Mon Feb 2 13:59:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA8E1A885A; Mon, 2 Feb 2015 10:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9N0QsUnN6iw; Mon, 2 Feb 2015 10:33:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5921A1A20; Mon, 2 Feb 2015 10:33:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: Rosa De Vivero X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150202183354.30380.30799.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 10:33:54 -0800 Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 13:58:52 -0800 Cc: Christian Groves , Scott mansfield , Kathleen Moriarty , Transport Layer Security Discussion List Subject: [TLS] New Liaison Statement, "Response to LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:33:59 -0000 Title: Response to LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4] Submission Date: 2015-02-02 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1379/ From: Transport Layer Security (Sean Turner ) To: ITU-T Q3/16 (Rosa De Vivero ) Cc: Joseph Salowey ,Stephen Farrell ,Kathleen Moriarty ,Transport Layer Security Discussion List ,Scott mansfield Response Contact: Christian Groves Technical Contact: Purpose: In response Referenced liaison: LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4] (http://datatracker.ietf.org/liaison/1363/) Body: Thanks for your questions about (D)TLS. What follows is a response to your questions; questions proceeded by Q# and answers by A#. If you have additional question please let us know. Q1. [What is] the distinction between (D)TLS session and (D)TLS connection (which implies a definition for each term, beyond the available descriptions / glossary from RFC side) A1. A TLS session is shared cryptographic state established by a full TLS handshake between two peers. The session’s cryptographic state is used to establish the cryptographic key material for a TLS connection. A TLS connection is a transport relationship established between two peers that contains the cryptographic state to cryptographically protect data sent and received on the connection established through a full or abbreviated (session resumption) TLS handshake. A TLS session may span one or more TLS connections. Every TLS connection is associated with one TLS session. If session resumption (abbreviated handshake) is not used then the TLS session and TLS connection will essentially be the same. A TLS session is identified by a Session ID in the client and server hellos. A TLS connection is usually identified by a host addresses and port numbers. Q2. The DTLS association concept, e.g., is it equivalent to a DTLS session or DTLS connection or something in addition? A2. The DTLS association is the same as a DTLS connection Q3. The TLS renegotiation procedure: what is the definition and at which level (TLS session or TLS connection level) does this procedure occur? Q4. The TLS resumption procedure: what is the definition and relation to TLS renegotiation? A3 and A4: Resumption refers to the use of the state from an existing TLS session to establish a new TLS connection using an abbreviated handshake. During resumption the cryptographic parameters (algorithms etc.) remain the same. TLS renegotiation is the process of executing a new TLS handshake to establish new cryptographic parameters for a TLS connection (effectively a new TLS connection using the same host addresses and ports as the previous one). If the handshake is a full handshake then both a new session and a new connection are established and the renegotiated session may have different parameters. Please note that session resumption and renegotiation are optional features; though TLS 1.2 recommended support for renegotiation; renegotiation was also updated by RFC 5746. Please note that TLS 1.3 is currently under development and these features are being reviewed. Attachments: No document has been attached From nobody Tue Feb 3 08:51:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41121A1A5F for ; Tue, 3 Feb 2015 08:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNizB4WEV15i for ; Tue, 3 Feb 2015 08:24:09 -0800 (PST) Received: from itu4out.svc.unicc.org (itu4out.svc.unicc.org [206.155.102.67]) (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 823391A1AA4 for ; Tue, 3 Feb 2015 08:24:09 -0800 (PST) Received: from TUCM03.TUECSP.UNICC.ORG (unknown [10.81.38.70]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iccpfxor04.svc.unicc.org (Postfix) with ESMTPS id DBEF460FDB; Tue, 3 Feb 2015 16:24:07 +0000 (UTC) Received: from TUCM02.TUECSP.UNICC.ORG (10.81.6.71) by TUCM03.TUECSP.UNICC.ORG (10.81.38.70) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 3 Feb 2015 16:24:06 +0000 Received: from TUCM02.TUECSP.UNICC.ORG ([10.81.6.71]) by TUCM02.TUECSP.UNICC.ORG ([10.81.6.71]) with mapi id 15.00.0847.030; Tue, 3 Feb 2015 16:24:06 +0000 From: "Angeles-Leon De Vivero, Rosa" To: Liaison Statement Management Tool , turn , "turners@ieca.com" Thread-Topic: New Liaison Statement, "Response to LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]" Thread-Index: AQHQPxbRtquPBkKi402JS37tpABQf5zfHDvA Date: Tue, 3 Feb 2015 16:24:06 +0000 Message-ID: References: <20150202183354.30380.30799.idtracker@ietfa.amsl.com> In-Reply-To: <20150202183354.30380.30799.idtracker@ietfa.amsl.com> Accept-Language: fr-CH, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.81.64.102] Content-Type: multipart/related; boundary="_004_fd2ceb1a695d41d28778229a25b91e38TUCM02TUECSPUNICCORG_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 Feb 2015 08:51:57 -0800 Cc: Christian Groves , "Campos, Simao" , Scott mansfield , Kathleen Moriarty , Transport Layer Security Discussion List , "TSB SG16 Secretariat, ITU" Subject: Re: [TLS] New Liaison Statement, "Response to LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Feb 2015 16:24:13 -0000 --_004_fd2ceb1a695d41d28778229a25b91e38TUCM02TUECSPUNICCORG_ Content-Type: multipart/alternative; boundary="_000_fd2ceb1a695d41d28778229a25b91e38TUCM02TUECSPUNICCORG_" --_000_fd2ceb1a695d41d28778229a25b91e38TUCM02TUECSPUNICCORG_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBNciBUdXJuZXIsDQoNCldlIHdpc2ggdG8gYWNrbm93bGVkZ2UgcmVjZWlwdCBvZiB5b3Vy IHJlcGx5IExTIHJlY2VpdmVkIGZvciBJVFUtVCBTdHVkeSBHcm91cCAxNi4gSXQgd2lsbCBiZSBw cm9jZXNzZWQgc2hvcnRseSBhbmQgYXZhaWxhYmxlIGluIG91ciBTRzE2IHdlYnNpdGUuDQoNCk1h bnkgdGhhbmtzLg0KDQpLaW5kIHJlZ2FyZHMsDQoNCltjaWQ6aW1hZ2UwMDIuanBnQDAxRDAzRkQ2 LjM1RjRDN0QwXQ0KDQoNClJvc2EgQW5nZWxlcy1MZW9uIERlIFZpdmVybw0KQWRtaW5pc3RyYXRp dmUgQXNzaXN0YW50IGZvciBJVFUtVCBTdHVkeSBHcm91cCAxNiwgSVBUVi1HU0ksIEpDQS0gSVBU ViAmIElSRy1BVkENCkludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb24gVW5pb24NClBsYWNl IGRlcyBOYXRpb25zDQpDSC0xMjExIEdlbmV2YSAsIFN3aXR6ZXJsYW5kDQpUZWwgOis0MSAyMiA3 MzAgNTQ0NQ0KRmF4IDorNDEgMjIgNzMwIDU4NTMNCnRzYnNnMTZAaXR1LmludDxtYWlsdG86dHNi c2cxNkBpdHUuaW50Pg0KdHNiaXB0dkBpdHUuaW50PG1haWx0bzpyb3NhLmFuZ2VsZXNsZW9uZGV2 QGl0dS5pbnQ+DQp3d3cuaXR1LmludDxodHRwOi8vd3d3Lml0dS5pbnQvPg0KDQoNCg0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExpYWlzb24gU3RhdGVtZW50IE1hbmFn ZW1lbnQgVG9vbCBbbWFpbHRvOmxzbXRAaWV0Zi5vcmddDQpTZW50OiAwMiBGZWJydWFyeSAyMDE1 IDE5OjM0DQpUbzogQW5nZWxlcy1MZW9uIERlIFZpdmVybywgUm9zYQ0KQ2M6IEpvc2VwaCBTYWxv d2V5OyBTdGVwaGVuIEZhcnJlbGw7IEthdGhsZWVuIE1vcmlhcnR5OyBUcmFuc3BvcnQgTGF5ZXIg U2VjdXJpdHkgRGlzY3Vzc2lvbiBMaXN0OyBTY290dCBtYW5zZmllbGQ7IENocmlzdGlhbiBHcm92 ZXMNClN1YmplY3Q6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIlJlc3BvbnNlIHRvIExTIG9uIFRM UyBhbmQgRFRMUyB0ZXJtaW5vbG9neSBbdG8gM0dQUEEgU0EzLCBJRVRGIFdHIFRMUywgM0dQUCBD VDRdIg0KDQoNCg0KVGl0bGU6IFJlc3BvbnNlIHRvIExTIG9uIFRMUyBhbmQgRFRMUyB0ZXJtaW5v bG9neSBbdG8gM0dQUEEgU0EzLCBJRVRGIFdHIFRMUywgM0dQUCBDVDRdIFN1Ym1pc3Npb24gRGF0 ZTogMjAxNS0wMi0wMiBVUkwgb2YgdGhlIElFVEYgV2ViIHBhZ2U6IGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9saWFpc29uLzEzNzkvDQoNCg0KDQpGcm9tOiBUcmFuc3BvcnQgTGF5ZXIgU2Vj dXJpdHkgKFNlYW4gVHVybmVyIDx0bHMtY2hhaXJzQHRvb2xzLmlldC5vcmc8bWFpbHRvOnRscy1j aGFpcnNAdG9vbHMuaWV0Lm9yZz4+KQ0KDQpUbzogSVRVLVQgUTMvMTYgKFJvc2EgRGUgVml2ZXJv IDxyb3NhLmFuZ2VsZXNsZW9uZGV2QGl0dS5pbnQ8bWFpbHRvOnJvc2EuYW5nZWxlc2xlb25kZXZA aXR1LmludD4+KQ0KDQpDYzogSm9zZXBoIFNhbG93ZXkgPGpvZUBzYWxvd2V5Lm5ldDxtYWlsdG86 am9lQHNhbG93ZXkubmV0Pj4sU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNk LmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4sS2F0aGxlZW4gTW9yaWFydHkg PEthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzpLYXRobGVlbi5Nb3JpYXJ0 eS5pZXRmQGdtYWlsLmNvbT4+LFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSBEaXNjdXNzaW9uIExp c3QgPHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPj4sU2NvdHQgbWFuc2ZpZWxkIDxz Y290dC5tYW5zZmllbGRAZXJpY3Nzb24uY29tPG1haWx0bzpzY290dC5tYW5zZmllbGRAZXJpY3Nz b24uY29tPj4gUmVzcG9uc2UgQ29udGFjdDogQ2hyaXN0aWFuIEdyb3ZlcyA8Y2hyaXN0aWFuLmdy b3Zlc0BudGVjem9uZS5jb208bWFpbHRvOmNocmlzdGlhbi5ncm92ZXNAbnRlY3pvbmUuY29tPj4g VGVjaG5pY2FsIENvbnRhY3Q6DQoNClB1cnBvc2U6IEluIHJlc3BvbnNlDQoNClJlZmVyZW5jZWQg bGlhaXNvbjogTFMgb24gVExTIGFuZCBEVExTIHRlcm1pbm9sb2d5IFt0byAzR1BQQSBTQTMsIElF VEYgV0cgVExTLCAzR1BQIENUNF0gKGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29u LzEzNjMvKQ0KDQpCb2R5OiBUaGFua3MgZm9yIHlvdXIgcXVlc3Rpb25zIGFib3V0IChEKVRMUy4g IFdoYXQgZm9sbG93cyBpcyBhIHJlc3BvbnNlIHRvIHlvdXIgcXVlc3Rpb25zOyBxdWVzdGlvbnMg cHJvY2VlZGVkIGJ5IFEjIGFuZCBhbnN3ZXJzIGJ5IEEjLiAgSWYgeW91IGhhdmUgYWRkaXRpb25h bCBxdWVzdGlvbiBwbGVhc2UgbGV0IHVzIGtub3cuDQoNCg0KDQpRMS4NCg0KDQoNCltXaGF0IGlz XSB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiAoRClUTFMgc2Vzc2lvbiBhbmQgKEQpVExTIGNvbm5l Y3Rpb24gKHdoaWNoIGltcGxpZXMgYSBkZWZpbml0aW9uIGZvciBlYWNoIHRlcm0sIGJleW9uZCB0 aGUgYXZhaWxhYmxlIGRlc2NyaXB0aW9ucyAvIGdsb3NzYXJ5IGZyb20gUkZDIHNpZGUpDQoNCg0K DQpBMS4NCg0KDQoNCkEgVExTIHNlc3Npb24gaXMgc2hhcmVkIGNyeXB0b2dyYXBoaWMgc3RhdGUg ZXN0YWJsaXNoZWQgYnkgYSBmdWxsIFRMUyBoYW5kc2hha2UgYmV0d2VlbiB0d28gcGVlcnMuICBU aGUgc2Vzc2lvbuKAmXMgY3J5cHRvZ3JhcGhpYyBzdGF0ZSBpcyB1c2VkIHRvIGVzdGFibGlzaCB0 aGUgY3J5cHRvZ3JhcGhpYyBrZXkgbWF0ZXJpYWwgZm9yIGEgVExTIGNvbm5lY3Rpb24uICBBIFRM UyBjb25uZWN0aW9uIGlzIGEgdHJhbnNwb3J0IHJlbGF0aW9uc2hpcCBlc3RhYmxpc2hlZCBiZXR3 ZWVuIHR3byBwZWVycyB0aGF0IGNvbnRhaW5zIHRoZSBjcnlwdG9ncmFwaGljIHN0YXRlIHRvIGNy eXB0b2dyYXBoaWNhbGx5IHByb3RlY3QgZGF0YSBzZW50IGFuZCByZWNlaXZlZCBvbiB0aGUgY29u bmVjdGlvbiBlc3RhYmxpc2hlZCB0aHJvdWdoIGEgZnVsbCBvciBhYmJyZXZpYXRlZCAoc2Vzc2lv biByZXN1bXB0aW9uKSBUTFMgaGFuZHNoYWtlLiAgQSBUTFMgc2Vzc2lvbiBtYXkgc3BhbiBvbmUg b3IgbW9yZSBUTFMgY29ubmVjdGlvbnMuICBFdmVyeSBUTFMgY29ubmVjdGlvbiBpcyBhc3NvY2lh dGVkIHdpdGggb25lIFRMUyBzZXNzaW9uLiAgSWYgc2Vzc2lvbiByZXN1bXB0aW9uIChhYmJyZXZp YXRlZCBoYW5kc2hha2UpIGlzIG5vdCB1c2VkIHRoZW4gdGhlIFRMUyBzZXNzaW9uIGFuZCBUTFMg Y29ubmVjdGlvbiB3aWxsIGVzc2VudGlhbGx5IGJlIHRoZSBzYW1lLiAgQSBUTFMgc2Vzc2lvbiBp cyBpZGVudGlmaWVkIGJ5IGEgU2Vzc2lvbiBJRCBpbiB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgaGVs bG9zLiAgQSBUTFMgY29ubmVjdGlvbiBpcyB1c3VhbGx5IGlkZW50aWZpZWQgYnkgYSBob3N0IGFk ZHJlc3NlcyBhbmQgcG9ydCBudW1iZXJzLg0KDQoNCg0KUTIuDQoNCg0KDQpUaGUgRFRMUyBhc3Nv Y2lhdGlvbiBjb25jZXB0LCBlLmcuLCBpcyBpdCBlcXVpdmFsZW50IHRvIGEgRFRMUyBzZXNzaW9u IG9yIERUTFMgY29ubmVjdGlvbiBvciBzb21ldGhpbmcgaW4gYWRkaXRpb24/DQoNCg0KDQpBMi4N Cg0KDQoNClRoZSBEVExTIGFzc29jaWF0aW9uIGlzIHRoZSBzYW1lIGFzIGEgRFRMUyBjb25uZWN0 aW9uDQoNCg0KDQpRMy4NCg0KDQoNClRoZSBUTFMgcmVuZWdvdGlhdGlvbiBwcm9jZWR1cmU6IHdo YXQgaXMgdGhlIGRlZmluaXRpb24gYW5kIGF0IHdoaWNoIGxldmVsIChUTFMgc2Vzc2lvbiBvciBU TFMgY29ubmVjdGlvbiBsZXZlbCkgZG9lcyB0aGlzIHByb2NlZHVyZSBvY2N1cj8NCg0KDQoNClE0 Lg0KDQoNCg0KVGhlIFRMUyByZXN1bXB0aW9uIHByb2NlZHVyZTogd2hhdCBpcyB0aGUgZGVmaW5p dGlvbiBhbmQgcmVsYXRpb24gdG8gVExTIHJlbmVnb3RpYXRpb24/DQoNCg0KDQpBMyBhbmQgQTQ6 DQoNCg0KDQpSZXN1bXB0aW9uIHJlZmVycyB0byB0aGUgdXNlIG9mIHRoZSBzdGF0ZSBmcm9tIGFu IGV4aXN0aW5nIFRMUyBzZXNzaW9uIHRvIGVzdGFibGlzaCBhIG5ldyBUTFMgY29ubmVjdGlvbiB1 c2luZyBhbiBhYmJyZXZpYXRlZCBoYW5kc2hha2UuICBEdXJpbmcgcmVzdW1wdGlvbiB0aGUgY3J5 cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzIChhbGdvcml0aG1zIGV0Yy4pIHJlbWFpbiB0aGUgc2FtZS4g IFRMUyByZW5lZ290aWF0aW9uIGlzIHRoZSBwcm9jZXNzIG9mIGV4ZWN1dGluZyBhIG5ldyBUTFMg aGFuZHNoYWtlIHRvIGVzdGFibGlzaCBuZXcgY3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzIGZvciBh IFRMUyBjb25uZWN0aW9uIChlZmZlY3RpdmVseSBhIG5ldyBUTFMgY29ubmVjdGlvbiB1c2luZyB0 aGUgc2FtZSBob3N0IGFkZHJlc3NlcyBhbmQgcG9ydHMgYXMgdGhlIHByZXZpb3VzIG9uZSkuIElm IHRoZSBoYW5kc2hha2UgaXMgYSBmdWxsIGhhbmRzaGFrZSB0aGVuIGJvdGggYSBuZXcgc2Vzc2lv biBhbmQgYSBuZXcgY29ubmVjdGlvbiBhcmUgZXN0YWJsaXNoZWQgYW5kIHRoZSByZW5lZ290aWF0 ZWQgc2Vzc2lvbiBtYXkgaGF2ZSBkaWZmZXJlbnQgcGFyYW1ldGVycy4NCg0KDQoNClBsZWFzZSBu b3RlIHRoYXQgc2Vzc2lvbiByZXN1bXB0aW9uIGFuZCByZW5lZ290aWF0aW9uIGFyZSBvcHRpb25h bCBmZWF0dXJlczsgdGhvdWdoIFRMUyAxLjIgcmVjb21tZW5kZWQgc3VwcG9ydCBmb3IgcmVuZWdv dGlhdGlvbjsgcmVuZWdvdGlhdGlvbiB3YXMgYWxzbyB1cGRhdGVkIGJ5IFJGQyA1NzQ2LiAgUGxl YXNlIG5vdGUgdGhhdCBUTFMgMS4zIGlzIGN1cnJlbnRseSB1bmRlciBkZXZlbG9wbWVudCBhbmQg dGhlc2UgZmVhdHVyZXMgYXJlIGJlaW5nIHJldmlld2VkLg0KDQpBdHRhY2htZW50czoNCg0KDQoN Ck5vIGRvY3VtZW50IGhhcyBiZWVuIGF0dGFjaGVkDQoNCg0K --_000_fd2ceb1a695d41d28778229a25b91e38TUCM02TUECSPUNICCORG_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0 LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+RGVhciBN ciBUdXJuZXIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tR0IiPldlIHdpc2ggdG8gYWNrbm93bGVkZ2UgcmVjZWlwdCBvZiB5b3Vy IHJlcGx5IExTIHJlY2VpdmVkIGZvciBJVFUtVCBTdHVkeSBHcm91cCAxNi4gSXQgd2lsbCBiZSBw cm9jZXNzZWQgc2hvcnRseSBhbmQgYXZhaWxhYmxlIGluIG91ciBTRzE2IHdlYnNpdGUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t R0IiPk1hbnkgdGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNl OmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iMTI1IiB2YWxpZ249InRvcCIg c3R5bGU9IndpZHRoOjkzLjZwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGltZyB3aWR0aD0iMTc1IiBoZWlnaHQ9IjEzOCIgaWQ9Il94MDAwMF9p MTAyNSIgc3JjPSJjaWQ6aW1hZ2UwMDIuanBnQDAxRDAzRkQ2LjM1RjRDN0QwIj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8dGQgd2lkdGg9IjMwOCIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoy MzAuNzVwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtjb2xvcjojNTQ4REQ0Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwLjBwdCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjojNTQ4REQ0Ij5Sb3NhIEFuZ2VsZXMtTGVv biBEZSBWaXZlcm88L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwLjBwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtjb2xvcjojNTQ4REQ0Ij5BZG1pbmlzdHJhdGl2ZSBBc3Npc3RhbnQgZm9yIElUVS1UIFN0 dWR5IEdyb3VwIDE2LCBJUFRWLUdTSSwgSkNBLSBJUFRWICZhbXA7IElSRy1BVkE8L3NwYW4+PC9p PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEwLjBwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjojNTQ4REQ0Ij5J bnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0aW9uIFVuaW9uPC9zcGFuPjwvaT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOjMuMHB0O2xpbmUt aGVpZ2h0OjEwLjBwdCI+PHNwYW4gbGFuZz0iRlItQ0giIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Y29sb3I6IzU0OERENCI+UGxhY2UgZGVzIE5hdGlvbnM8YnI+DQpDSC0xMjExIEdlbmV2YSAsIFN3 aXR6ZXJsYW5kIDwvc3Bhbj48c3BhbiBsYW5nPSJGUi1DSCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtjb2xvcjojNTQ4REQ0Ij5UZWwgOiYjNDM7NDEgMjIgNzMw IDU0NDU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTAuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOiM1 NDhERDQiPkZheCA6JiM0Mzs0MSAyMiA3MzAgNTg1Mzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMC4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Y29sb3I6IzVCOUJENSI+PGEgaHJlZj0ibWFpbHRvOnRzYnNnMTZA aXR1LmludCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1QjlCRDUiPnRzYnNnMTZAaXR1LmludDwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5QkQ1Ij48YnI+DQo8YSBocmVmPSJt YWlsdG86cm9zYS5hbmdlbGVzbGVvbmRldkBpdHUuaW50Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguNXB0O2NvbG9yOiM1QjlCRDUiPnRzYmlwdHZAaXR1LmludDwvc3Bhbj48L2E+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTAuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOiM1QjlCRDUiPjxhIGhy ZWY9Imh0dHA6Ly93d3cuaXR1LmludC8iPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5QkQ1Ij53d3cu aXR1LmludDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IExpYWlzb24gU3RhdGVtZW50 IE1hbmFnZW1lbnQgVG9vbCBbbWFpbHRvOmxzbXRAaWV0Zi5vcmddIDxicj4NClNlbnQ6IDAyIEZl YnJ1YXJ5IDIwMTUgMTk6MzQ8YnI+DQpUbzogQW5nZWxlcy1MZW9uIERlIFZpdmVybywgUm9zYTxi cj4NCkNjOiBKb3NlcGggU2Fsb3dleTsgU3RlcGhlbiBGYXJyZWxsOyBLYXRobGVlbiBNb3JpYXJ0 eTsgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IERpc2N1c3Npb24gTGlzdDsgU2NvdHQgbWFuc2Zp ZWxkOyBDaHJpc3RpYW4gR3JvdmVzPGJyPg0KU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50 LCAmcXVvdDtSZXNwb25zZSB0byBMUyBvbiBUTFMgYW5kIERUTFMgdGVybWlub2xvZ3kgW3RvIDNH UFBBIFNBMywgSUVURiBXRyBUTFMsIDNHUFAgQ1Q0XSZxdW90OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+VGl0bGU6IFJlc3Bv bnNlIHRvIExTIG9uIFRMUyBhbmQgRFRMUyB0ZXJtaW5vbG9neSBbdG8gM0dQUEEgU0EzLCBJRVRG IFdHIFRMUywgM0dQUCBDVDRdIFN1Ym1pc3Npb24gRGF0ZTogMjAxNS0wMi0wMiBVUkwgb2YgdGhl IElFVEYgV2ViIHBhZ2U6DQo8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlh aXNvbi8xMzc5LyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEzNzkvPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPkZyb206IFRyYW5zcG9ydCBMYXllciBTZWN1cml0 eSAoU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0bHMtY2hhaXJzQHRvb2xzLmlldC5v cmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj50 bHMtY2hhaXJzQHRvb2xzLmlldC5vcmc8L3NwYW4+PC9hPiZndDspPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRvOiBJVFUt VCBRMy8xNiAoUm9zYSBEZSBWaXZlcm8gJmx0OzxhIGhyZWY9Im1haWx0bzpyb3NhLmFuZ2VsZXNs ZW9uZGV2QGl0dS5pbnQiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5yb3NhLmFuZ2VsZXNsZW9uZGV2QGl0dS5pbnQ8L3NwYW4+PC9hPiZndDspPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tR0IiPkNjOiBKb3NlcGggU2Fsb3dleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZUBzYWxvd2V5 Lm5ldCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PmpvZUBzYWxvd2V5Lm5ldDwvc3Bhbj48L2E+Jmd0OyxTdGVwaGVuIEZhcnJlbGwgJmx0OzxhIGhy ZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZTwvc3Bhbj48L2E+Jmd0OyxLYXRobGVlbg0KIE1vcmlhcnR5ICZsdDs8YSBocmVmPSJtYWlsdG86 S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5LYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWls LmNvbTwvc3Bhbj48L2E+Jmd0OyxUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgRGlzY3Vzc2lvbiBM aXN0ICZsdDs8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+dGxzQGlldGYub3JnPC9zcGFuPjwvYT4m Z3Q7LFNjb3R0DQogbWFuc2ZpZWxkICZsdDs8YSBocmVmPSJtYWlsdG86c2NvdHQubWFuc2ZpZWxk QGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPnNjb3R0Lm1hbnNmaWVsZEBlcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDsgUmVz cG9uc2UgQ29udGFjdDogQ2hyaXN0aWFuIEdyb3ZlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz dGlhbi5ncm92ZXNAbnRlY3pvbmUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+Y2hyaXN0aWFuLmdyb3Zlc0BudGVjem9uZS5jb208L3NwYW4+ PC9hPiZndDsNCiBUZWNobmljYWwgQ29udGFjdDogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPlB1cnBvc2U6IEluIHJlc3Bv bnNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tR0IiPlJlZmVyZW5jZWQgbGlhaXNvbjogTFMgb24gVExTIGFuZCBEVExTIHRlcm1p bm9sb2d5IFt0byAzR1BQQSBTQTMsIElFVEYgV0cgVExTLCAzR1BQIENUNF0gKDxhIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEzNjMvIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2xpYWlzb24vMTM2My88L3NwYW4+PC9hPik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+Qm9keTogVGhhbmtzIGZv ciB5b3VyIHF1ZXN0aW9ucyBhYm91dCAoRClUTFMuJm5ic3A7IFdoYXQgZm9sbG93cyBpcyBhIHJl c3BvbnNlIHRvIHlvdXIgcXVlc3Rpb25zOyBxdWVzdGlvbnMgcHJvY2VlZGVkIGJ5IFEjIGFuZCBh bnN3ZXJzIGJ5IEEjLiZuYnNwOyBJZiB5b3UgaGF2ZSBhZGRpdGlvbmFsIHF1ZXN0aW9uIHBsZWFz ZSBsZXQgdXMga25vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPlExLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1HQiI+W1doYXQgaXNdIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIChEKVRMUyBzZXNz aW9uIGFuZCAoRClUTFMgY29ubmVjdGlvbiAod2hpY2ggaW1wbGllcyBhIGRlZmluaXRpb24gZm9y IGVhY2ggdGVybSwgYmV5b25kIHRoZSBhdmFpbGFibGUgZGVzY3JpcHRpb25zIC8gZ2xvc3Nhcnkg ZnJvbSBSRkMgc2lkZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPkExLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1HQiI+QSBUTFMgc2Vzc2lvbiBpcyBzaGFyZWQgY3J5cHRvZ3JhcGhpYyBzdGF0ZSBl c3RhYmxpc2hlZCBieSBhIGZ1bGwgVExTIGhhbmRzaGFrZSBiZXR3ZWVuIHR3byBwZWVycy4mbmJz cDsgVGhlIHNlc3Npb27igJlzIGNyeXB0b2dyYXBoaWMgc3RhdGUgaXMgdXNlZCB0byBlc3RhYmxp c2ggdGhlIGNyeXB0b2dyYXBoaWMga2V5IG1hdGVyaWFsIGZvciBhIFRMUyBjb25uZWN0aW9uLiZu YnNwOyBBIFRMUw0KIGNvbm5lY3Rpb24gaXMgYSB0cmFuc3BvcnQgcmVsYXRpb25zaGlwIGVzdGFi bGlzaGVkIGJldHdlZW4gdHdvIHBlZXJzIHRoYXQgY29udGFpbnMgdGhlIGNyeXB0b2dyYXBoaWMg c3RhdGUgdG8gY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdCBkYXRhIHNlbnQgYW5kIHJlY2VpdmVk IG9uIHRoZSBjb25uZWN0aW9uIGVzdGFibGlzaGVkIHRocm91Z2ggYSBmdWxsIG9yIGFiYnJldmlh dGVkIChzZXNzaW9uIHJlc3VtcHRpb24pIFRMUyBoYW5kc2hha2UuJm5ic3A7DQogQSBUTFMgc2Vz c2lvbiBtYXkgc3BhbiBvbmUgb3IgbW9yZSBUTFMgY29ubmVjdGlvbnMuJm5ic3A7IEV2ZXJ5IFRM UyBjb25uZWN0aW9uIGlzIGFzc29jaWF0ZWQgd2l0aCBvbmUgVExTIHNlc3Npb24uJm5ic3A7IElm IHNlc3Npb24gcmVzdW1wdGlvbiAoYWJicmV2aWF0ZWQgaGFuZHNoYWtlKSBpcyBub3QgdXNlZCB0 aGVuIHRoZSBUTFMgc2Vzc2lvbiBhbmQgVExTIGNvbm5lY3Rpb24gd2lsbCBlc3NlbnRpYWxseSBi ZSB0aGUgc2FtZS4mbmJzcDsgQSBUTFMgc2Vzc2lvbiBpcw0KIGlkZW50aWZpZWQgYnkgYSBTZXNz aW9uIElEIGluIHRoZSBjbGllbnQgYW5kIHNlcnZlciBoZWxsb3MuJm5ic3A7IEEgVExTIGNvbm5l Y3Rpb24gaXMgdXN1YWxseSBpZGVudGlmaWVkIGJ5IGEgaG9zdCBhZGRyZXNzZXMgYW5kIHBvcnQg bnVtYmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPlEyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1HQiI+VGhlIERUTFMgYXNzb2NpYXRpb24gY29uY2VwdCwgZS5nLiwgaXMgaXQgZXF1aXZhbGVu dCB0byBhIERUTFMgc2Vzc2lvbiBvciBEVExTIGNvbm5lY3Rpb24gb3Igc29tZXRoaW5nIGluIGFk ZGl0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+QTIuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LUdCIj5UaGUgRFRMUyBhc3NvY2lhdGlvbiBpcyB0aGUgc2FtZSBhcyBhIERUTFMgY29ubmVjdGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+UTMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5U aGUgVExTIHJlbmVnb3RpYXRpb24gcHJvY2VkdXJlOiB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIGFu ZCBhdCB3aGljaCBsZXZlbCAoVExTIHNlc3Npb24gb3IgVExTIGNvbm5lY3Rpb24gbGV2ZWwpIGRv ZXMgdGhpcyBwcm9jZWR1cmUgb2NjdXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5RNC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoZSBUTFMgcmVzdW1wdGlvbiBwcm9jZWR1cmU6IHdoYXQg aXMgdGhlIGRlZmluaXRpb24gYW5kIHJlbGF0aW9uIHRvIFRMUyByZW5lZ290aWF0aW9uPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1HQiI+QTMgYW5kIEE0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+ UmVzdW1wdGlvbiByZWZlcnMgdG8gdGhlIHVzZSBvZiB0aGUgc3RhdGUgZnJvbSBhbiBleGlzdGlu ZyBUTFMgc2Vzc2lvbiB0byBlc3RhYmxpc2ggYSBuZXcgVExTIGNvbm5lY3Rpb24gdXNpbmcgYW4g YWJicmV2aWF0ZWQgaGFuZHNoYWtlLiZuYnNwOyBEdXJpbmcgcmVzdW1wdGlvbiB0aGUgY3J5cHRv Z3JhcGhpYyBwYXJhbWV0ZXJzIChhbGdvcml0aG1zIGV0Yy4pIHJlbWFpbiB0aGUNCiBzYW1lLiZu YnNwOyBUTFMgcmVuZWdvdGlhdGlvbiBpcyB0aGUgcHJvY2VzcyBvZiBleGVjdXRpbmcgYSBuZXcg VExTIGhhbmRzaGFrZSB0byBlc3RhYmxpc2ggbmV3IGNyeXB0b2dyYXBoaWMgcGFyYW1ldGVycyBm b3IgYSBUTFMgY29ubmVjdGlvbiAoZWZmZWN0aXZlbHkgYSBuZXcgVExTIGNvbm5lY3Rpb24gdXNp bmcgdGhlIHNhbWUgaG9zdCBhZGRyZXNzZXMgYW5kIHBvcnRzIGFzIHRoZSBwcmV2aW91cyBvbmUp LiBJZiB0aGUgaGFuZHNoYWtlIGlzIGEgZnVsbA0KIGhhbmRzaGFrZSB0aGVuIGJvdGggYSBuZXcg c2Vzc2lvbiBhbmQgYSBuZXcgY29ubmVjdGlvbiBhcmUgZXN0YWJsaXNoZWQgYW5kIHRoZSByZW5l Z290aWF0ZWQgc2Vzc2lvbiBtYXkgaGF2ZSBkaWZmZXJlbnQgcGFyYW1ldGVycy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tR0IiPlBsZWFzZSBub3RlIHRoYXQgc2Vzc2lvbiByZXN1bXB0aW9uIGFuZCBy ZW5lZ290aWF0aW9uIGFyZSBvcHRpb25hbCBmZWF0dXJlczsgdGhvdWdoIFRMUyAxLjIgcmVjb21t ZW5kZWQgc3VwcG9ydCBmb3IgcmVuZWdvdGlhdGlvbjsgcmVuZWdvdGlhdGlvbiB3YXMgYWxzbyB1 cGRhdGVkIGJ5IFJGQyA1NzQ2LiZuYnNwOyBQbGVhc2Ugbm90ZSB0aGF0IFRMUyAxLjMgaXMgY3Vy cmVudGx5DQogdW5kZXIgZGV2ZWxvcG1lbnQgYW5kIHRoZXNlIGZlYXR1cmVzIGFyZSBiZWluZyBy ZXZpZXdlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1HQiI+QXR0YWNobWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5O byBkb2N1bWVudCBoYXMgYmVlbiBhdHRhY2hlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_fd2ceb1a695d41d28778229a25b91e38TUCM02TUECSPUNICCORG_-- --_004_fd2ceb1a695d41d28778229a25b91e38TUCM02TUECSPUNICCORG_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=5088; creation-date="Tue, 03 Feb 2015 16:24:06 GMT"; modification-date="Tue, 03 Feb 2015 16:24:06 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCACKAK8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooqve31vp1uZ7uURRAgbj6mmlfRA3bcsUVm2niHTL65W3trtZJXztUKef0rSocXHdCUk9gooqB 7y2jcq9xCrDqC4BFKw7k9FV/t9p/z9Qf9/BR9vtP+fqD/v4KdmK6LFFV/t9p/wA/UH/fwVYpWHcK KhuJxbmNn/1bMFY+hPQ/nx+NTUAFFFQPeW0Zw9xCp9C4FFguT0VHHPFN/qpUf/dYGpKACiiigAoo ooAKKKKAKd/qtlpig3lwkW4EqD1P0FcF4n8Sf206Q26slrGdw3dXPqfSun8T+HbjXJbdreWKMRBg d+ec49PpXH614euNDSFriWKQSkgbM8Y+td2FjS0bfvHFiZVNVbQk8I/8jNa/8C/9BNenV5j4R/5G a1/4F/6Ca9OqMb/EXoXhPgfqMlkWKJ5HOFRSxPsK8fu5zeXk1w/LSuXP4mvR/GF59k8PTAHDzERL +PX9M1wOi2f2/WbS3IyrSAt9Byf5VrhFyxc2Z4p80lBFf7Dc/wDPpN/36P8AhR9guf8An0n/AO/R /wAK9ioqfrz7D+prueT6Zpc8+qWkb20qo0q7iYyABnntXrFFFc9as6rTaN6NFUk9SK4gS5t5IZR8 kilT9K4+fxrJZWn2VEWe8iJjaYnKNjgNx1zTPF/iVnkfTrJyEXiaRT1P90e3rWAmh3p0h9S8rFuh HH8TD1A9K6KNCKjep12MK1Z81qfQS51XU9Xm2yTzysekcecf98inp4a1aUZGnzf8CAH867bQdJsT pUEttPMyOgJKPs57524PX1rRbS4VUlJLlCO6zv8A1NOWKUXyxVhRwzkuaTPNZtF1SxUyyWdxEq8l 1HA/EVb07xXqenMFaU3EY6xzcn8+orp/JRbWKa5uo7uWZAxhuMseR0Xb0/I1kyadb6got/slzHeo cFZCF3DsQWPXGOP0q1WjNWmiHScHeDOn0bxDZ61HiEmOdRloX+8PceorVryae0vNHmhuBvjySYpR 1yDgg+h9RXoHhvXl1uy+fC3UXEijv/tD2Nc9egormhsdFGvzPllubNFFFcp0hRRRQAVx3xC/497H /ff+Qrsa474hf8e9j/vv/IVvhv4qMcR/DZheEf8AkZrX/gX/AKCa9OrzHwj/AMjNa/8AAv8A0E16 dWmN/iL0M8J8D9ThPH155l7bWiniJDIw9zwP0H603wDZ+bqNxdMOIU2qfdv/AKw/WsfxE88uuXU1 xFJHuchQ6kfKOB+gqrZ6hd2Dl7S4khJ67TwfqOhrrVJujyROV1Eq3Mz1+iuE07x5cRYTUIVmXvJH 8rfl0P6V2GnapaarB5tnMHA6joV+orzqlGdP4kd9OtCezLdZPiXVDpOjySocTSfu4/Ynv+Aya1q4 Px/dF9QtrYH5Yoy5HuT/AICnQhz1EmFefJBsy/DOlLq+rpHPkwoC7/7WO2ffNd9q+p2Wk2ai8VvJ kzGAiZHTp+VYWiPZaHp2nS3dwkMkyvKwYHJDYx0HsK1dUk07XPDtw/2lfsw6TYOEYd62rS56ib+E xox5KbS3OO8O+IP7EvWjLM9jI3zDHK/7QH867qNp9URZVkMFowyuw/PIPUn+Eew5+leb/wBmxf8A QTsf++n/APia2tA1R9Fby21KymtCeYy75X3U7f0rWvSUvejuZUKjj7stjq4rQ6RI5tLcSWznLImN 6H2z94e3Wq1zeWMmoATrJ5c8e10eFwQynKnpnOCenpV+TWbCKwjvXuVFtIcLJg4J/wAg1XfUrTUY Yp7KcSrBcJuKg8ZO3+TVxq+7R1u2yZSNks1pPa6hHJ9kupMwyyffjbAA3ehOOD+fJrj7K4n8N+IP 3mQYX2SgfxJ3/TkV6Lql/YWcATUpUSKbK4YH5vXpXB+JhFP9mvIJ0nRt0JkXOW29Cc98HB+ldOGk 5XjJaM58RFRtJPVHpCOsiK6EFWGQR3FOrF8JXZu/DtuWOWizEfw6fpitquOceWTidcZc0UwoooqS grjviF/x72P++/8AIV0t9q1jprIt5cpCzglQ2ea4/wAaarZalDaCzuEmKOxYLnjgV04aMvaJ20Of ESXs2rmb4R/5Ga1/4F/6Ca9Oryzw1dQ2WvW89zII4l3ZY9B8pr0O013Tb64EFrdxySkEhRnPFaYy Lc7pdDPCSSha/UuyRRzIUlRXU9QwyKw7/wAGaZeAmJDbSH+KI8f989K36K5IzlH4WdUoRl8SPK9Z 0C70SQecA8LHCyr0PsfQ1UsL+4027S5tX2SL+TD0PtXrN3aRX1rJb3CBo5BgivJb60awv57WTlon K59R2P5V6WHre1TjLc86vS9k1KOx6lo+qRavp0d1FwTw6/3W7iuB8aEnxJcD0RAP++au+A71otUl tCTsnTcB/tL/APWzUHjmAx6/v7SwqfyyP6VnSgqddx8jSrP2lFSJfGiCMaUi9Ft8D9K0vCcQvNAW zkiD28ryGYnPTjAGO5P8qxPEd6uoWWkTr18hlYejAgGt/wAHrcDw+ktsQxSZ90THAccd+xoqXVBe v+YQs6z9P8ij4v0Ow0vToZbO3EbtLtJ3E8YPqapeFtLttSjufPjhklVkEYlYgHgkjg+3vWt41u47 rRoCm5WWcB0cYZTtPBFYuhabcanpd8lm+y4ikjlTnGSA3APY81UG3Q1YppKtojY8Uotv4YitktHt linUBCdy9G6N3qv4U/5AN/6+fHj81qC81a51zRpNPuYiuoWzCTbjBkC8EY/vDOcVU8P6lZW8T2uo ACJpUlD7N2MdRj3pKEvZOPW4Oa9opLaxt/EFg1tZYIOJGzg9OBWBLbq3g+3uP447t0H0Iz/SrPin V7C/W3g02MLFES7ME2gk8dKiv0ksvC1hbTArJPM9xtPULjAz+dXSTjCKfcmo1Kcn5HQ+AHJ0u5Xs s3H5Currm/A1v5WgmQjBmlZvwHH9K6SuGu71JHbQVqaCiiisTU4/xvpt5fXVo1pbSzBUYMUGcciu Y/4R/Vv+gdcf9816vRXVTxUoRUUjmnhozk5NnlH/AAj+rf8AQOuP++a2fCekahaa/FLc2c0UYRgW ZcDpXfVHJPFE6LJIiNIcIGONx9BTli5Ti42FHCxi1K5JRRRXIdQV5l4wAHia52+iZ+u0V6VNNHbw vLMwSNBuZj0AryXU7w6jqdxdYwJXJAPYdv0rtwUXzNnJjJLlSL/hEE+JrTH+1n6bTXSeO9PM+nRX iLlrdsNj+6f/AK+KzvAWntJezXzL8kS+Wh9WPX9P51280KXELwyqGjdSrA9waK9XlrKS6CoU+ai0 +p5/4cubWe3NvfW0U62+5wHTLBD1I+h6j0PtXb6RDDDpcHkRRxrIgkKxjC5Iya851GxuvDWsjy2Y FDvhk/vL/ngiur8OXy3Ngn9nSKJolAmtJDgE/wB5T2z+VPEQuueL0YsPOz5Zbo6C7sLa/QJdwJMo OQHGeaz/ALImhrLPa/YoYGI3iQeX9PmH+FXre/imk8pt0U46xSDDfh6j3FSXVrDe2zwXMYkicYKm uRNrR7HU0nqtzgvEOs6bqJWa3imj1CNuJoyNpx79T7VnQ6tDLMp1Owgul/idR5ch98jAP41a1vwv Np1y4sy1zCq72CjLxj/aqDw7a6XeXoj1OZ4yT8i9FY+hbtXpx9mqd1qvxPOlzudno/wOn0seHpCJ NLsDcTKMkFSTH9SxwK5bW9Qn1zWSQFJyIYlQ5HX175Jra8Ra5aWNs+laKkcan5ZpIxgAd1B7n1NH gnQi8o1O4TEacQAjqe7f4VlD92nVl8r7msvfapx+djsNOs10/Tre1XpEgXPqe/61Zoorz27u53JW VgooopDCiiigArzrxtdzz6yIpI3jhhXEW4YDHuw/z2r0Wobm1gvIjFcxJLGf4XGa1o1FTlzNXMq1 N1I8qZ5zp/i/U7BQhkW4jHRZuSPx61qH4gzbOLCPd6mQ4/lWld+BNOmJNu81uT2U7h+RqmPh7Hnn UHx/1yH+NdbnhpatHMoYiOiZzureIr/WBsuJAkOc+VGML+PrSaNoV1rU4WFSkIPzzEcL9PU+1dnZ +CdLtiGmElyw/wCejcfkK3440hjCRoqIowFUYApSxUYrlpoccNKT5qjIbCxh02zjtrddsaD8Se5P vVmiiuFu7uzsStoijqulW+sWZt7lfdHHVD6ivO9S0fUPDt2JcuFU/u7iPgf/AFj7GvUqa6LIpV1D KeCCMg1tSryp6boyq0VU12ZwNt40aSEQ6tZpdIP41wG+uPX6Yq4fFlqGVLO8uYIyPmNxH5oX2Hcn 6nFal74L0u7JaNHt3PeI8fkeKy3+HvP7vUDj/ai/+vW6lh5eRg414+Y1PGcFhHst4RcEnLP8ylj6 nOea53V9UGrXfnC0htye0Y5b6nua6iD4fQggz30jDuEQL+vNbuneHtO0shre3BkH/LR/mb8z0/Cm qtGm7w1YvZVqitLRHC2Xh29i8m8vNOmltM5eJCA5H+71xXoWnXtpe2ytZOpRBt2AYKexHardV5bK CWUSlAso6SJw35iuerWdX4jop0vZ/CWKKaoKqAWLH1NOrA2CiiigBCyg4JAP1pa5Txlp8Cm1vwH8 9riOMnccbee1dXVyilFSXUiMm5NdhpdVYKWAJ6AnrTq4O5so9QXxBfXTyG4tZSsLbyNgHTFdfo80 lxo9nLKS0jwqWJ7nFVOnyq9yYVOZ2sXCQBkkAe9LXM+I2F9rWm6YWCxBvtE+TgbR0z+tdKOnHSpl HlSfcuMrtrsBYL1IH1oBB5BB+lcp4njtZ/EWnxahJ5dqIZGdi+36c/WtzRLaxttPC6Y/mW7MWDb9 3Pfn8KcoJRUu5MZtycexoUUUVmaDd679u4bj2zzTq4HUdLmtdJudVvfNj1P7VmJt/wDDkYAx+P5V 3cRZoULjDFQT9a1nTUUmnczhNydmrCs6qQGYAnoCetOribqwj1W+8QT3bSNJZjEGGICYUn+ldJ4e nkudAspZmLSNEMseponT5Y3uKFTmlaxo7lzjIz6Zpa5XWLGG28WaVcx7hLcTHzMtwcKMcV1JOBmp lFJJrqVGTbafQTev94fnTq4Pw9Y6PdKj30+L152MaeaQThuOK7ynUgoOwqc3NXCiiiszQKKKKAOd 8Z/8g6z/AOvyP+tdFWfrOkjV7eGIymLy5llyFznHatCrlJOCXqRFNSbODuNPXVI/EF9LJIkkMrKq ocKQo43DvXX6NcNdaNZzOAGeJSQowOlZV54Uae5uWt9Qmt7e7bdPCqghj3we1bttbx2ltHBCMRxq FUewrWrNSikn/VjOlBxk20crd6db6p4w1GO7UukdopUZIweK0/B8jy+GrYuxYqWUE+gY4pdV8Otf XxvLS9ktJnj8qQoMh1rR03T4tL0+K0hyUjGMnqT1JpTmnBK/YIQam3buZ97b6ZdeJLWO6R5LtYS0 aEZjK89feq3gwBLK+ReFW7cKPQcVc1fQ21C6hu7a7e0uoVKiRRnKntirGj6VHo9l9njdpGZi7yN1 Zj1NDmvZ2uNRftL2G6tb6nOsX9l3cVuRnf5ibs+lXoQ6woJWDSBQGYDgnuafRWLeljW2tzmtV/4n Hie001eYLQfaJ/Qn+Ef59a6Wua/4RS6W7uLiHWZ4ZLhtzlIwM+nftXRRKUiRWYuyqAWPU+9aVHGy UWZ007tyRysH+t8V/j/6Aa2PC/8AyLVh/wBchVTUPC7XV5cTW1/LapdAC4jVch/8K2rS1jsrSK2h BEcShVz6VVScXHTy/ImnCSlr/Wpia/8A8jDoP/XZ/wCQrfkIWNi3QAk4qjf6UL7ULG6MpQ2jlgoX O7P8qvkBgQRkHrUSkmort/maRTTkzhtRtdMj8M2tzpaNta8UiWQfP1OefTiu6rmo/B6pMkbX0zWE cvmpbEcA/Wulqqsk7JO5FKLV21YKKKKxNgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKAP//Z --_004_fd2ceb1a695d41d28778229a25b91e38TUCM02TUECSPUNICCORG_-- From nobody Tue Feb 3 10:26:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A6D1A6FFB for ; Tue, 3 Feb 2015 10:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDwHaUkmuBf2 for ; Tue, 3 Feb 2015 10:26:46 -0800 (PST) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6971A6FF5 for ; Tue, 3 Feb 2015 10:26:45 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id i50so53696017qgf.8 for ; Tue, 03 Feb 2015 10:26:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7yTFQ4bgxTXSAv2R0SEmS88MxMY6AdfbFLFYYUE+OcA=; b=Ldxx6ru1vgNRXbbA4UVW0t9n4NpHkr+XvUZZipjmKMLBzAhH+pRvQhYp6WBB+q6Xs0 rAaZIX5he8eJjqDq4Lb643XPsjqqKU6HyzTpj8Sv6gYc+eIp25kXab2tr2Va6BysVDER GUn1OYSvD6eo5mzCGKAGVVQXoRu1jbODFegs1XMrFILJihTdEeLPW/f+twwCRkHEcicF 6BpPqYvMa95wRuGXFhlAwZy9nTtdCBlQzSi20FoMZwxf/hMJm7ts0Ty1E3IJDsDDyZkq PNWO0IPvRe+pmfMb7tper/Yy2cyU+98KfSnTsS/+3ee0B3Oozh79aht7JXj4PcIMBtvf 6RrQ== X-Gm-Message-State: ALoCoQmOcmzLMkU5NDFXSGXRgfJAW3OGVMZWpQ2Htf9XeCOpNeV8cM7oLT8l43GUfqJQt80gAtPs MIME-Version: 1.0 X-Received: by 10.140.92.161 with SMTP id b30mr6212471qge.59.1422988004682; Tue, 03 Feb 2015 10:26:44 -0800 (PST) Received: by 10.96.238.73 with HTTP; Tue, 3 Feb 2015 10:26:44 -0800 (PST) X-Originating-IP: [50.206.82.141] In-Reply-To: References: Date: Tue, 3 Feb 2015 10:26:44 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1139baf08a049f050e333663 Archived-At: Subject: Re: [TLS] TLS Face-to-Facce Interim in March X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Feb 2015 18:26:48 -0000 --001a1139baf08a049f050e333663 Content-Type: text/plain; charset=UTF-8 Based on the response to the Doodle Poll (http://doodle.com/fe84eh263zfv73rs) we will have the interim meeting 3/10-3/11 in the Seattle area. Thanks, Joe On Fri, Jan 23, 2015 at 11:54 AM, Joseph Salowey wrote: > We'd like to have another face-to-face interim in March. I'm proposing to > have the interim Seattle area. The preferred dates are 3/5 and 3/6, but > 3/9-3/11 are options as well. I've set up a Doodle poll to see how many > folks can make this time. > > http://doodle.com/fe84eh263zfv73rs > > If you are interested in attending this meeting please enter your > availability by Friday, January 30, 2015. > > Thanks, > > Joe > --001a1139baf08a049f050e333663 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on the response to the Doodle Poll (http://doodle.com/fe84eh26= 3zfv73rs) =C2=A0we will have the interim meeting 3/10-3/11 in the Seatt= le area. =C2=A0

Thanks,

Joe

On Fri, J= an 23, 2015 at 11:54 AM, Joseph Salowey <joe@salowey.net> wrot= e:
We'd like to have another face-to-face interim in March.=C2= =A0 I'm proposing to have the interim Seattle area.=C2=A0 The preferred= dates are 3/5 and 3/6, but 3/9-3/11 are options as well.=C2=A0 I've se= t up a Doodle poll to see how many folks can make this time. =C2=A0<= div style=3D"font-size:13px">

If you are interested in attending this meeting = please enter your availability by Friday, January 30, 2015.=C2=A0

Thanks,

J= oe

--001a1139baf08a049f050e333663-- From nobody Tue Feb 3 12:28:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30C01A895C; Tue, 3 Feb 2015 12:28:05 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcNhlSELwlzF; Tue, 3 Feb 2015 12:28:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABABA1A88E3; Tue, 3 Feb 2015 12:28:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203202804.23548.7987.idtracker@ietfa.amsl.com> Date: Tue, 03 Feb 2015 12:28:04 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] TLS WG Interim Meeting: 10-11 March 2015, Seattle X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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, 03 Feb 2015 20:28:06 -0000 The Transport Layer Security (TLS) working group will hold a face-to- face interim meeting in Seattle, WA on 10-11 March 2015. The exact location will be announced later. Date: 10-11 March 2015 Time: 9am-5pm Location: Seattle, WA, USA Additional information will be announced on the TLS WG mailing list: http://www.ietf.org/mail-archive/web/tls/current/maillist.html From SRS0=eR1q=CW=acm.org=bmoeller@srs.kundenserver.de Wed Feb 4 09:03:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EE11A1A09 for ; Wed, 4 Feb 2015 09:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MYqenxdZDij for ; Wed, 4 Feb 2015 09:03:42 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 96F481A8F49 for ; Wed, 4 Feb 2015 09:03:41 -0800 (PST) Received: from mail-la0-f44.google.com ([209.85.215.44]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0LzFPp-1XX1900Oy9-014WGW for ; Wed, 04 Feb 2015 18:03:39 +0100 Received: by mail-la0-f44.google.com with SMTP id gf13so2745032lab.3 for ; Wed, 04 Feb 2015 09:03:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.144.164 with SMTP id sn4mr26382234lbb.2.1423069418698; Wed, 04 Feb 2015 09:03:38 -0800 (PST) Received: by 10.25.25.194 with HTTP; Wed, 4 Feb 2015 09:03:38 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Feb 2015 18:03:38 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a858831413b050e462b79 X-Provags-ID: V03:K0:D0G/Vcu7jtpP4Ndzszl6Tk12q0rCIilmCSQ5YtpofdHJuC89qXL MjLUGtmfTd0leiPZUau5S0gwO6+YL13gzwBKpDiq5uAXDv5u1XLB/wxiIUwWLOO+kzzKSlo HGjT3sizMnPcdLt+0alsopYZImU7pDH2pTYOkpHAvPf6C7QuZHqgBce0wG/y9+VM2ttXz5f 1WvUH0FqlHqfLSOd+FiNg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Feb 2015 17:04:48 -0000 --047d7b3a858831413b050e462b79 Content-Type: text/plain; charset=UTF-8 Joseph Salowey : This is a working group last call for draft-ietf-tls-sslv3-diediedie-00. > Please reply to the TLS working group list with an indication of whether or > not the draft is ready for publication and any other comments you may > have. Please respond by February 16, 2015. > I think that the I-D is essentially ready for publication, and support its publication as a Standards Track RFC. (There are a few places where the writing could be improved: it seems a bit odd, for example, that Section 4 refers to DTLS as a "cryptographic operation" that SSL 3.0 can't benefit from. I sort of get the idea, but if you use non-DTLS TLS, you don't use DTLS anyway, so how does it matter for DTLS whether non-DTLS TLS handshakes can negotiate SSL 3.0? However, this is just a detail in the rationale and doesn't affect the normative interpretation of the document; its overall message is very clear.) Bodo --047d7b3a858831413b050e462b79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jose= ph Salowey <joe@salowey.net>:

This is a working group last call for=C2=A0draft-ietf-tls-sslv3-die= diedie-00.=C2=A0 Please reply to the TLS working group list with an indicat= ion of whether or not the draft is ready for publication and any other comm= ents you may have.=C2=A0 Please respond by February 16, 2015.

I think that the I-D is essentially ready fo= r publication, and support its publication as a Standards Track RFC.
<= div>
(There are a few places where the writing could be impro= ved: it seems a bit odd, for example, that Section 4 refers to DTLS as a &q= uot;cryptographic operation" that SSL 3.0 can't benefit from.=C2= =A0 I sort of get the idea, but if you use non-DTLS TLS, you don't use = DTLS anyway, so how does it matter for DTLS whether non-DTLS TLS handshakes= can negotiate SSL 3.0?=C2=A0 However, this is just a detail in the rationa= le and doesn't affect the normative interpretation of the document; its= overall message is very clear.)

Bodo
--047d7b3a858831413b050e462b79-- From nobody Wed Feb 4 15:02:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717441A0011 for ; Wed, 4 Feb 2015 15:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I4gEspqYIQ4 for ; Wed, 4 Feb 2015 15:02:14 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 0F8241A0015 for ; Wed, 4 Feb 2015 15:02:14 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id wo20so4191801obc.7 for ; Wed, 04 Feb 2015 15:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PcSooobZn5VdyUrJLiseS8OEAbYkJ0j8O56DbF9DM0s=; b=eD369TdwlCyods9p+lA6qIfKBStyhee4Gn3bGNBEFxmHODpus2wfS5yLZlsA7QpTAh ybK8qfFizutM6jLgcskV3TjmiNxieh4BsE3r1PZ6vJ/wo1wwFKu1w4/n4o32I88NsaS2 B+NDEIPOpYbSJiOPjCqqo+HbSNcWSSQ+OLbMfyIbo3ZHyVhe4VySmJ3bz1Qe+rEY1cc5 REfixb8d7kdmBsCaIr4hOzpYSplktXIOG5K3EspY5n01UAVnGKpjnyU7VyoL3YqwYvME y5tUXhaYegpV8bc748GrLN88X2msE6jIi7Kjv6jmR3CFGq1VcDK7n7TIxrdcd5gs5RQa 622Q== MIME-Version: 1.0 X-Received: by 10.202.185.198 with SMTP id j189mr460570oif.72.1423090933299; Wed, 04 Feb 2015 15:02:13 -0800 (PST) Received: by 10.202.225.135 with HTTP; Wed, 4 Feb 2015 15:02:13 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2015 10:02:13 +1100 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Feb 2015 23:02:17 -0000 On 5 February 2015 at 04:03, Bodo Moeller wrote: > (There are a few places where the writing could be improved: it seems a bit > odd, for example, that Section 4 refers to DTLS as a "cryptographic > operation" that SSL 3.0 can't benefit from. I sort of get the idea, but if > you use non-DTLS TLS, you don't use DTLS anyway, so how does it matter for > DTLS whether non-DTLS TLS handshakes can negotiate SSL 3.0? However, this > is just a detail in the rationale and doesn't affect the normative > interpretation of the document; its overall message is very clear.) Hi Bodo, I've tweaked the text that you pointed out. If you have any more quibbles or suggestions, I'm happy to integrate changes in any way that suits you. Pull requests are preferred, of course: https://github.com/tlswg/sslv3-diediedie From nobody Wed Feb 4 19:12:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB3C1A0367 for ; Wed, 4 Feb 2015 19:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzko4rjDVX-O for ; Wed, 4 Feb 2015 19:12:51 -0800 (PST) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0C81A032D for ; Wed, 4 Feb 2015 19:12:51 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id p6so4655808qcv.8 for ; Wed, 04 Feb 2015 19:12:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3jdRuDD4iBF2TDsJt5TQy1OXU6srrzb5BUvsV1KgdwQ=; b=HCUIk1tCo/o5bU5uhCyp0U/o4lh+x8oEGBnU2vGvMX4VVo5AmrziSqLBcgqscqOpcE 8b5bPrlaDQ1CYaC26N/VA3gXG+Hf1eiZxsXQyNuCMR2ycUzyI6QcIJCVdCekuU+A84Nl YeJKBWlWTlNhoIoXwfLg4ZRym2CRXX1urBj+i3QmKPOX0dgvr/LLBd1QWJWYBaGHbcT4 dutDNHChPEFW6t8KB4NEFfG2oEKRefOKv9wHHUaF+M2WRkNDc8+nYgjwQlC4z/6Y/y2T Xo9Wi2AegBp1rfz4fd6LX5CMY+qItKY7rT46FZeiVy+uGWA3XE5vF5BZaDjwuSZgJ9ZU g9xQ== X-Gm-Message-State: ALoCoQlZMCfRxU5BGvVmMXr0FnQu65tKUvuYXaQOxRWV5fej9lyBFnvbpnASwOJmQy0/MGchP9H+ X-Received: by 10.140.95.114 with SMTP id h105mr3624454qge.64.1423105970455; Wed, 04 Feb 2015 19:12:50 -0800 (PST) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id u5sm3700574qar.12.2015.02.04.19.12.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 19:12:49 -0800 (PST) Received: from [10.0.0.44] (unknown [12.206.98.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id DD1C5AC283F; Wed, 4 Feb 2015 22:12:46 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: Date: Wed, 4 Feb 2015 22:12:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5C010B2A-BDD9-402F-B25C-6A0BF8B9CD25@pahtak.org> References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Feb 2015 03:12:53 -0000 Hi Martin, This is _super_ minor but I think the security considerations section = can be slightly sharpened by changing from "This entire document aims to = improve security by identifying a protocol that is not secure." to "This = entire document aims to improve security by prohibiting the use of a = protocol that is not secure." But regardless, this I-D seems ready to go and has my support. --=20 Stephen Checkoway From nobody Thu Feb 5 14:37:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4A51A8035 for ; Thu, 5 Feb 2015 14:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEOwNtAOIQcw for ; Thu, 5 Feb 2015 14:36:53 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0467C1A876A for ; Thu, 5 Feb 2015 14:36:53 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id n4so8161000qaq.12 for ; Thu, 05 Feb 2015 14:36:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=rEFYq6ATHw8FDhw8PJ3hQIE4xNQAdouS81L/p+OJRrM=; b=Yse74iyR89BB8fKCOgMQ/eELn0IwGlZNkoxe6xJmt0YyBb+kS/DZvPwrsw8RY1Z8pg sHEPgdSR/m4SAdKPb6Zlty7HdjCpodvLhGPt7OIfowdlYtziwKCmPvqHGU/+X7pCUjof yxXF9H+vf0X96vTWTPqkZql9EKsRccpNtot2GpwXkJPYPFl07yYlq2/TRxIAxV9mTSES bawMLOXzxlNaA+CnqPVHdp0i2h86CP5STVdvYJ5hHas4/Pra0hSwWoeWRYkSSr1k6MFq +2z451zMK7vKUOEIrFUc5ZhZscpwhr89zyznR5tnh6ll/fq8+XYYTbRVkEeCY3nuikDp rA0g== X-Gm-Message-State: ALoCoQlSL4IiBgXCIZCRLAscm+SImfNhE1SfyBmkAppd0mOZPg0FRPQNpMmn8cRsz9DugBV+nNbw MIME-Version: 1.0 X-Received: by 10.140.82.234 with SMTP id h97mr967005qgd.75.1423175812248; Thu, 05 Feb 2015 14:36:52 -0800 (PST) Received: by 10.96.238.73 with HTTP; Thu, 5 Feb 2015 14:36:52 -0800 (PST) X-Originating-IP: [50.206.82.141] Date: Thu, 5 Feb 2015 14:36:52 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c135d8be1208050e5ef049 Archived-At: Subject: [TLS] TLS Interim attendance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Feb 2015 22:36:57 -0000 --001a11c135d8be1208050e5ef049 Content-Type: text/plain; charset=UTF-8 If you are planning to attend the interim meeting on 3/10 and 3/11 in Seattle please send me an email so I can get an accurate count of participants for planning. Thanks, Joe --001a11c135d8be1208050e5ef049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you are planning to attend the interim meeting on 3/10 = and 3/11 in Seattle please send me an email so I can get an accurate count = of participants for planning. =C2=A0

Thanks,
<= br>
Joe
--001a11c135d8be1208050e5ef049-- From nobody Fri Feb 6 06:11:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9DC1A1AC6 for ; Fri, 6 Feb 2015 06:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyun0oFIzxQS for ; Fri, 6 Feb 2015 06:10:55 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4A11A001B for ; Fri, 6 Feb 2015 06:10:54 -0800 (PST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 73E7D40026; Fri, 6 Feb 2015 15:10:52 +0100 (CET) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPS id 0002640020; Fri, 6 Feb 2015 15:10:51 +0100 (CET) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id t16EApIZ012607; Fri, 6 Feb 2015 15:10:51 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id t16EAp6E012606; Fri, 6 Feb 2015 15:10:51 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Adam Langley References: Date: Fri, 06 Feb 2015 15:10:51 +0100 In-Reply-To: (Adam Langley's message of "Thu, 8 May 2014 10:35:17 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Feb 2015 14:10:59 -0000 Adam Langley writes: > On Thu, May 8, 2014 at 12:32 AM, Niels Möller wrote: >> Is this something you'd want to address? After all, high performance is >> one of the primary design goals for both chacha and poly1305. The easiest >> way I see is to change the formatting for authentication to >> >> ad | pad1 | cryptotext | pad2 | length(ad) | length(cryptotext) > > I think this might be a good idea, thanks! I've now updated my implementation to match draft-irtf-cfrg-chacha20-poly1305-08 (https://git.lysator.liu.se/nettle/nettle/blob/master/chacha-poly1305.c). I have a couple of comments on the testcases. In section 2.4.2, the test vector for the chacha20 cipher, I think it would be good to have an example with initial counter = 0. I think that's going to be the typical case when using chacha as cipher only. In section 2.8.2, the nonce is given in two pieces, an "IV" and a "32-bit fixed common part". It's not crystal clear how to put then together. Please also write out the complete 12-byte nonce explicitly. For naming, I think it would be more consistent with the (admittedly confused) terminology used in the literature to consistently write "chacha", not "chacha20", and "salsa20", not "salsa". Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From mixoftix@gmail.com Thu Feb 5 01:17:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED91A0070 for ; Thu, 5 Feb 2015 01:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.127 X-Spam-Level: ** X-Spam-Status: No, score=2.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hEA5uKzNxNr for ; Thu, 5 Feb 2015 01:17:19 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::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 3D98C1A0021 for ; Thu, 5 Feb 2015 01:17:19 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id hv19so4866762lab.10 for ; Thu, 05 Feb 2015 01:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Xe4HBMQvpuH07eoKawIoJzduu6e757VmfMEMIuPeaxM=; b=S049LbevoUTZwMPnYaj5E+qSxsLw2kKUDlRxe8OdTQLKRiullGoO/pf7o8uCMXe9mA RtPsLF1DUuANbmcW/JTEq/AdDi4tGjlM0URAm65mnpX8tRYbXkGh0Raa9J4157FVGhIK wHQf+UbHmFSEqe7nXfamURUzp7XpkcCAKaue8+5CN8VgJV3jiqjx2KSGZZ/qaoxyS+EC v8sVsUEeSXnYj89+2psO1+SVZr2olX3MQW0+TH7xcXWx8+R62lZvk02fBdYVSHFz6Wa/ EpscJAMHH3+qTDHGD/VQIYB2iik5RD7V2C6FUgClghpwe/3yl9tXC6GMSR9KT7TWsPs5 hJwg== MIME-Version: 1.0 X-Received: by 10.152.185.72 with SMTP id fa8mr2222176lac.73.1423127837656; Thu, 05 Feb 2015 01:17:17 -0800 (PST) Received: by 10.112.156.8 with HTTP; Thu, 5 Feb 2015 01:17:17 -0800 (PST) Date: Thu, 5 Feb 2015 12:47:17 +0330 Message-ID: From: Shahin Noursalehi To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: X-Mailman-Approved-At: Fri, 06 Feb 2015 08:10:04 -0800 Cc: abadi@cs.ucsc.edu, ChristopherA@alacritymanagement.com Subject: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Feb 2015 09:19:45 -0000 Dear Sir/Madam, Refer to discussions around TLS 1.3 in Linkedin group "Cryptographers and Cryptanalysts", contributor experts agree on the idea of using multiple keys with multiple certificate authorities in a TLS session. So if one certificate authority is compromised hopefully the others are not. The suggested solution would be like the process bellow: Refer to the way that TLS generates the *master_secret*: master_secret = PseudoRandomFunction(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) We could generate multiple peer-to-peer pre_master_secret(s) for each public-key that we receive from the server and XOR them all together. So, our offered method of calculation of master_secret will convert to: master_secret = PseudoRandomFunction(multiple_pre_master_secret, "master secret", ClientHello.random + ServerHello.random) where: multiple_pre_master_secret = XOR(pre_master_secret_1, pre_master_secret_2, .. pre_master_secret_n) and aim at preventing basic attacks that are known against one-time-pad, we could add a circular-bit-rotation(m) to the calculation above - each time we do an XOR: multiple_pre_master_secret = ROT(XOR(pre_master_secret_1, pre_master_secret_2, .. pre_master_secret_n), m) Please let us know about your point of views, then we could continue discussing the TLS. With best regards Shahin Noursalehi Reference: https://www.linkedin.com/groups/what-are-new-methods-attack-3901854.S.5958888203401314306 From nobody Fri Feb 6 08:32:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30331A6F1E for ; Fri, 6 Feb 2015 08:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.226 X-Spam-Level: ** X-Spam-Status: No, score=2.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, FRT_BELOW2=2.154, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT0OVR8sA3yr for ; Fri, 6 Feb 2015 08:32:35 -0800 (PST) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE141A066B for ; Fri, 6 Feb 2015 08:32:35 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 7513E81853; Fri, 6 Feb 2015 18:32:32 +0200 (EET) Date: Fri, 6 Feb 2015 18:32:31 +0200 From: Ilari Liusvaara To: Shahin Noursalehi Message-ID: <20150206163231.GA29809@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: abadi@cs.ucsc.edu, tls@ietf.org, ChristopherA@alacritymanagement.com Subject: Re: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Feb 2015 16:32:37 -0000 On Thu, Feb 05, 2015 at 12:47:17PM +0330, Shahin Noursalehi wrote: > Dear Sir/Madam, > > Refer to discussions around TLS 1.3 in Linkedin group "Cryptographers > and Cryptanalysts", contributor experts agree on the idea of using > multiple keys with multiple certificate authorities in a TLS session. > So if one certificate authority is compromised hopefully the others > are not. The suggested solution would be like the process bellow: > > Refer to the way that TLS generates the *master_secret*: > > master_secret = PseudoRandomFunction(pre_master_secret, "master > secret", ClientHello.random + ServerHello.random) TLS 1.3 fixed a mistake (security problem) in this, it is now: master_secret = PRF(pre_master_secret, "handshake master secret", hash(handshake)) > We could generate multiple peer-to-peer pre_master_secret(s) for each > public-key that we receive from the server and XOR them all together. > So, our offered method of calculation of master_secret will convert > to: You don't need multiple premaster secrets. One could just end the certificate chains in common host key. This way one only needs a new certificate format and no other changes to TLS. It would also work in earlier versions. Of course, it seems doubtful to me that multiple certificate chains are useful. -Ilari From nobody Fri Feb 6 09:08:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961B11A701C for ; Fri, 6 Feb 2015 09:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.127 X-Spam-Level: ** X-Spam-Status: No, score=2.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oKYVokdI552 for ; Fri, 6 Feb 2015 09:08:01 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::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 E9F3E1A7013 for ; Fri, 6 Feb 2015 09:08:00 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x3so9382181wes.3 for ; Fri, 06 Feb 2015 09:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5JAOakBoo34t9NbxS1zD6PSDvDtROTXCGfyVk/10CX4=; b=pJ7wnYGO+MUUp9TOMkIyn0OfuNTfAcpgUKSVPVAEJiLl71dNCNizkltLYMUnGSTYsl 2o2YRHz+pxKsdh0MuGix8mYCd1QcqoTRJ9BqeXmMJ9bOOXNqHXpevVl26H1knE8yOYvF BMJclkl/Hwh6/J1GKMr+gLBkWV0OxxWJQiuYr4GHDdqBwyfEvNRRCk6OPaWQj5nuX0AO XuRvj37OQ/Nlvt8ohgzrttGljqOsYB1feIuFLpdt5wIuoiqG5Qe4Y14x6bE8gvPRrPA5 MiZRt7vVvh8NgQvis13EOFCddGtGqr1c8PF1LTOzo6axBtF/DeovlFZ8niQoQnA43gqL 1WRg== X-Received: by 10.194.10.68 with SMTP id g4mr9846409wjb.5.1423242479704; Fri, 06 Feb 2015 09:07:59 -0800 (PST) Received: from [192.168.1.44] (41.92.69.86.rev.sfr.net. [86.69.92.41]) by mx.google.com with ESMTPSA id fi10sm2229946wib.13.2015.02.06.09.07.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Feb 2015 09:07:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 6 Feb 2015 18:07:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FE6EA13-AF0F-4838-9F1F-CB0DEC158225@gmail.com> References: To: Shahin Noursalehi X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: abadi@cs.ucsc.edu, tls@ietf.org, ChristopherA@alacritymanagement.com Subject: Re: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Feb 2015 17:08:03 -0000 This scheme seems to assume an RSA key exchange which no longer exists = in TLS 1.3. To adapt the multiple PMS design to (EC)DHE would require more work, and = it is not clear what the benefit would be. -Karthik On 05 Feb 2015, at 10:17, Shahin Noursalehi wrote: > Dear Sir/Madam, >=20 > Refer to discussions around TLS 1.3 in Linkedin group "Cryptographers > and Cryptanalysts", contributor experts agree on the idea of using > multiple keys with multiple certificate authorities in a TLS session. > So if one certificate authority is compromised hopefully the others > are not. The suggested solution would be like the process bellow: >=20 > Refer to the way that TLS generates the *master_secret*: >=20 > master_secret =3D PseudoRandomFunction(pre_master_secret, "master > secret", ClientHello.random + ServerHello.random) >=20 > We could generate multiple peer-to-peer pre_master_secret(s) for each > public-key that we receive from the server and XOR them all together. > So, our offered method of calculation of master_secret will convert > to: >=20 > master_secret =3D PseudoRandomFunction(multiple_pre_master_secret, > "master secret", ClientHello.random + ServerHello.random) >=20 > where: >=20 > multiple_pre_master_secret =3D XOR(pre_master_secret_1, > pre_master_secret_2, .. pre_master_secret_n) >=20 > and aim at preventing basic attacks that are known against > one-time-pad, we could add a circular-bit-rotation(m) to the > calculation above - each time we do an XOR: >=20 > multiple_pre_master_secret =3D ROT(XOR(pre_master_secret_1, > pre_master_secret_2, .. pre_master_secret_n), m) >=20 > Please let us know about your point of views, then we could continue > discussing the TLS. >=20 > With best regards >=20 > Shahin Noursalehi >=20 >=20 > Reference: >=20 > = https://www.linkedin.com/groups/what-are-new-methods-attack-3901854.S.5958= 888203401314306 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Feb 6 10:15:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1071A870A for ; Fri, 6 Feb 2015 10:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFeKgrzifuOV for ; Fri, 6 Feb 2015 10:15:42 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 610821A017F for ; Fri, 6 Feb 2015 10:15:42 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id l89so12515389qgf.6 for ; Fri, 06 Feb 2015 10:15:41 -0800 (PST) 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:content-type:content-transfer-encoding; bh=rzJZ24zp1HnOvl5BvPOxeW3F6WVbiGROUrDxJDWx54M=; b=SwDp2qeFZc76dJUqM5hd1xpOFJvv1307j7KRUuTdF9MFlaRxL6Ot3hZTzDDT5/tgqA 27yRNYrMJk+Ko+t0ANbPLmKK0iyq91sbT4YmSberh0iuJiBHXTIGqKy68v0XZUOmDXvo JdoCJEMs9g/vmGlOk2IRV0wTkfxQSEfKDWyNC/ZVLGuNFX4XWVbItDpfUp1kCovpmZYU L8dQz8vHDADTW5Gal9K1mdFOPkMZghfXtwT5WrchZ3AUSN0AD+oskturx13ptAGo6jZd JqBD97FwLQAWVkQ894m+dpLK2XIw889Z0P5qwGun8QbaNvzI9Avo3FQBglWiaztocnLR c3JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=rzJZ24zp1HnOvl5BvPOxeW3F6WVbiGROUrDxJDWx54M=; b=DB689VH7HFDZIkGpNoPWf8makj3SaeuxMgbLmN2oySXTkTmYFJyjOyqD5QSC0WSy2b C+AK1hCNdXUkPf+loJfoJGZLq3Y2dt80BCvp/uxcsEnlQ8Vtq6LICVj/9uEmv/XDGQC4 rOf/e5ILHlR6ZSzU31dQUpELqVxhtalyWLaccpij3SwrhX9drueHcd/uGJ/WMkcnFGnA iGsayyiGP9mq2djWBRp6xEVFuZ06Yw8vSRJvI1a0ziO3BidjP1vdfJAq9boMbZwqabOT JocH+KPHOvx76ZI9rcZ93O/7Zh/gOGovEt6DHIrqpP+tam6lG8rpFPMuCCbMVl+2/zNa JDzg== X-Gm-Message-State: ALoCoQlOO0TQz4b1flyRwr+Q+Zl45ao9Re+4E4A8HQxvgS5LcCZhioNZu4KxeZX729EGQoGXKAsd X-Received: by 10.140.22.234 with SMTP id 97mr10199714qgn.21.1423246541399; Fri, 06 Feb 2015 10:15:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.40.67 with HTTP; Fri, 6 Feb 2015 10:15:21 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Fri, 6 Feb 2015 10:15:21 -0800 Message-ID: To: =?UTF-8?Q?Niels_M=C3=B6ller?= , Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Feb 2015 18:15:44 -0000 On Fri, Feb 6, 2015 at 6:10 AM, Niels M=C3=B6ller wr= ote: > Adam Langley writes: > >> On Thu, May 8, 2014 at 12:32 AM, Niels M=C3=B6ller wrote: >>> Is this something you'd want to address? After all, high performance is >>> one of the primary design goals for both chacha and poly1305. The easie= st >>> way I see is to change the formatting for authentication to >>> >>> ad | pad1 | cryptotext | pad2 | length(ad) | length(cryptotext) >> >> I think this might be a good idea, thanks! > > I've now updated my implementation to match > draft-irtf-cfrg-chacha20-poly1305-08 > (https://git.lysator.liu.se/nettle/nettle/blob/master/chacha-poly1305.c). > I have a couple of comments on the testcases. +Yoav, so that he sees this, as he's doing the editing work on this draft in practice. > In section 2.4.2, the test vector for the chacha20 cipher, I think it > would be good to have an example with initial counter =3D 0. I think > that's going to be the typical case when using chacha as cipher only. The draft defines an AEAD so I think it's ok that the examples are focused on that. > In section 2.8.2, the nonce is given in two pieces, an "IV" and a > "32-bit fixed common part". It's not crystal clear how to put then > together. Please also write out the complete 12-byte nonce explicitly. It does seem that this section might be a little IPSec focused. The nonce is called an nonce elsewhere in the draft, but is given as an "IV" and "fixed-common part" here, but those terms are never used elsewhere. Possibly they should be merged and called an nonce, although I'm sure that Yoav will decide what's best here. > For naming, I think it would be more consistent with the (admittedly > confused) terminology used in the literature to consistently write > "chacha", not "chacha20", and "salsa20", not "salsa". ChaCha is the family and ChaCha20 is an instance with a specific number of rounds. I think the two names are ok, although I do think there's a little confusion at the beginning of section 2.3 where it might be worth mentioning that the the ChaCha20 block function is specifically the ChaCha block function with 20 rounds. Cheers AGL From nobody Fri Feb 6 11:50:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDF81A1BC7 for ; Fri, 6 Feb 2015 11:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtzsdZu2l5oW for ; Fri, 6 Feb 2015 11:50:35 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7371A87D0 for ; Fri, 6 Feb 2015 11:49:41 -0800 (PST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C01B64002C; Fri, 6 Feb 2015 20:49:39 +0100 (CET) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPS id 673D640010; Fri, 6 Feb 2015 20:49:39 +0100 (CET) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id t16Jndb0027342; Fri, 6 Feb 2015 20:49:39 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id t16Jncaa027341; Fri, 6 Feb 2015 20:49:38 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Adam Langley References: Date: Fri, 06 Feb 2015 20:49:38 +0100 In-Reply-To: (Adam Langley's message of "Fri, 6 Feb 2015 10:15:21 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Feb 2015 19:50:37 -0000 Adam Langley writes: >> In section 2.4.2, the test vector for the chacha20 cipher, I think it >> would be good to have an example with initial counter = 0. I think >> that's going to be the typical case when using chacha as cipher only. > > The draft defines an AEAD so I think it's ok that the examples are > focused on that. Now I see that there are additional test vectors in appendix A.2, that's nice, sorry I missed that initially. But I think it would be valuable to add a test vector with a non-zero nonce, say 01 02 03 04 05 06 07 08 09 0a 0b 0c, a non-zero key, and a zero initial counter, and two blocks of data. That should test for most of the formatting pitfalls with a single test-case for the most basic encryption interface, without random-access-features. >> In section 2.8.2, the nonce is given in two pieces, an "IV" and a >> "32-bit fixed common part". It's not crystal clear how to put then >> together. Please also write out the complete 12-byte nonce explicitly. > > It does seem that this section might be a little IPSec focused. The > nonce is called an nonce elsewhere in the draft, but is given as an > "IV" and "fixed-common part" here, but those terms are never used > elsewhere. Possibly they should be merged and called an nonce, > although I'm sure that Yoav will decide what's best here. I think that division can also be found in RFC 5116, but I think it's important that it's crystal clear what the inputs are. It's fine to list both the pieces and the combined 12-byte nonce, if you think the division is important. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Fri Feb 6 16:31:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098AD1A049A for ; Fri, 6 Feb 2015 16:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfCSCrltve6O for ; Fri, 6 Feb 2015 16:31:51 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 8C39A1A0282 for ; Fri, 6 Feb 2015 16:31:51 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so16542956obc.9 for ; Fri, 06 Feb 2015 16:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o3fX1AKe2odEbjtEXiP/yH5rgZlPKdktexQX/W+pAiY=; b=nlPA+LPtku2RMF6KlXK7uCWtGZ8/WQ3UP4R2My8eeJ/40nQn9RObKHV6r7inSPv7rI HeWHA3aVOQPbpgrJh2t2Dqdk5vf6u/mwATysalK+kNs0OKm/DjR2/+4TCHd8nH/BJ36X dOD43Uheq3DF4GIve7+ilva3qWBCkE2d7PZ5Tl58CZ0WElrcnO4Jhj9Y5FOGJW8Y7dmE LmvRrbFANrS0Pf4wBGCLPH7AAy8YeNtbWuEHwMo3IyTOKB8j7l8wSUVCgPii+lkt+zfA n8RZ/UKy5ZUxdl5IXXNCxUEsWM0JpNSzjqoPJWT72oeo+Ah8lT8AAq2DSy1PivxgA+AZ +rMg== MIME-Version: 1.0 X-Received: by 10.182.68.12 with SMTP id r12mr4308687obt.84.1423269110770; Fri, 06 Feb 2015 16:31:50 -0800 (PST) Received: by 10.202.225.135 with HTTP; Fri, 6 Feb 2015 16:31:50 -0800 (PST) In-Reply-To: <5C010B2A-BDD9-402F-B25C-6A0BF8B9CD25@pahtak.org> References: <5C010B2A-BDD9-402F-B25C-6A0BF8B9CD25@pahtak.org> Date: Sat, 7 Feb 2015 11:31:50 +1100 Message-ID: From: Martin Thomson To: Stephen Checkoway Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Feb 2015 00:31:53 -0000 On 5 February 2015 at 14:12, Stephen Checkoway wrote: > This is _super_ minor but I think the security considerations section can= be slightly sharpened by changing from "This entire document aims to impro= ve security by identifying a protocol that is not secure." to "This entire = document aims to improve security by prohibiting the use of a protocol that= is not secure." Thanks, that is better. Fixed. From nobody Fri Feb 6 18:22:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976BE1A1A38 for ; Fri, 6 Feb 2015 18:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.773 X-Spam-Level: X-Spam-Status: No, score=-97.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, FRT_BELOW2=2.154, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSPo2yrRrRwH for ; Fri, 6 Feb 2015 18:22:15 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D00B91A038D for ; Fri, 6 Feb 2015 18:22:14 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 2CFB19A41CD; Fri, 6 Feb 2015 21:22:04 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 5PejcZNLtxNd; Fri, 6 Feb 2015 21:21:43 -0500 (EST) Received: from [5.5.33.218] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 98EDC9A4044; Fri, 6 Feb 2015 21:21:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Fri, 6 Feb 2015 21:21:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Shahin Noursalehi X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF TLS Subject: Re: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Feb 2015 02:22:16 -0000 You ideas seem to be based on TLS 1.2 and earlier. In TLS 1.3, = Ephemeral DH or Ephemeral ECDH will be used to produce the session key. = The ephemeral key will be signed, and a public key from the certificate = will be used to validate the signature. This approach offers much = better forward secrecy. Russ On 05 Feb 2015, at 10:17, Shahin Noursalehi wrote: > Dear Sir/Madam, >=20 > Refer to discussions around TLS 1.3 in Linkedin group "Cryptographers > and Cryptanalysts", contributor experts agree on the idea of using > multiple keys with multiple certificate authorities in a TLS session. > So if one certificate authority is compromised hopefully the others > are not. The suggested solution would be like the process bellow: >=20 > Refer to the way that TLS generates the *master_secret*: >=20 > master_secret =3D PseudoRandomFunction(pre_master_secret, "master > secret", ClientHello.random + ServerHello.random) >=20 > We could generate multiple peer-to-peer pre_master_secret(s) for each > public-key that we receive from the server and XOR them all together. > So, our offered method of calculation of master_secret will convert > to: >=20 > master_secret =3D PseudoRandomFunction(multiple_pre_master_secret, > "master secret", ClientHello.random + ServerHello.random) >=20 > where: >=20 > multiple_pre_master_secret =3D XOR(pre_master_secret_1, > pre_master_secret_2, .. pre_master_secret_n) >=20 > and aim at preventing basic attacks that are known against > one-time-pad, we could add a circular-bit-rotation(m) to the > calculation above - each time we do an XOR: >=20 > multiple_pre_master_secret =3D ROT(XOR(pre_master_secret_1, > pre_master_secret_2, .. pre_master_secret_n), m) >=20 > Please let us know about your point of views, then we could continue > discussing the TLS. >=20 > With best regards >=20 > Shahin Noursalehi >=20 >=20 > Reference: >=20 > = https://www.linkedin.com/groups/what-are-new-methods-attack-3901854.S.5958= 888203401314306 >=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 From nobody Fri Feb 6 23:45:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501101A7028 for ; Fri, 6 Feb 2015 23:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.127 X-Spam-Level: ** X-Spam-Status: No, score=2.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iN81pxrzsDVl for ; Fri, 6 Feb 2015 23:45:13 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFF91A7026 for ; Fri, 6 Feb 2015 23:45:13 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id n3so7171969wiv.1 for ; Fri, 06 Feb 2015 23:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3qHGX/RwQaIY8szhyab6arwjfsB5ZsV8rGS3pESfbhA=; b=AdQg60WPAUX1yHUB5s+J944+Gf0sqGAE6LVdzVs35z8yIwYM+H9oAOs9hXo0rRpL8P AJwUYSLtKlHqDvp85S4KBubAHbyb/jgtlqeV5G/D0SgKWWwaTFiNGJeLkniEjBmPSCUA x/z3UZk4SPRCJheNkLkPrhvUVEg4pl9t6vGmhQ0OaH0BEbZPBd4oEd57uOGMEU5R/MHM w4xDPFDmFzLcKusoLqT5Qy0E3Z2+6/kAfjjEWy1sDXO30hPo77kB+v2hO07dvHQSYoFY 7MkpLGa54FAXUJ9O5r3WtGcVES4Q6XgBJ98iGIydL/TIa91pR43tv6cacZ3UWUOVUya5 on/Q== X-Received: by 10.194.186.200 with SMTP id fm8mr16328957wjc.138.1423295112371; Fri, 06 Feb 2015 23:45:12 -0800 (PST) Received: from [192.168.1.44] (41.92.69.86.rev.sfr.net. [86.69.92.41]) by mx.google.com with ESMTPSA id hd5sm4608138wib.21.2015.02.06.23.45.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Feb 2015 23:45:11 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: <3FE6EA13-AF0F-4838-9F1F-CB0DEC158225@gmail.com> Date: Sat, 7 Feb 2015 08:45:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3FE6EA13-AF0F-4838-9F1F-CB0DEC158225@gmail.com> To: Karthikeyan Bhargavan X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: abadi@cs.ucsc.edu, Shahin Noursalehi , ChristopherA@alacritymanagement.com, tls@ietf.org Subject: Re: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Feb 2015 07:45:15 -0000 To obtain your multi-certificate guarantee as an extension to the = standard TLS 1.3 (EC)DHE exchanges, you do not need multiple pre-master = secrets. The server could send multiple Certificate and = CertificateVerify messages, all of which sign the same handshake, that = is, the same client and server keyshares. So, unless all the signing = keys were compromised, the attacker cannot hijack the connection (since = he cannot tamper with the server=92s keyshare). So a single PMS =3D KDF(g^xy + =85..(handshake hash)=85.)=20 but multiple server signatures over the handshake with different signing = keys. However, I would be wary of changing the TLS state machine in so = substantial a way without sufficient formal analysis. On 06 Feb 2015, at 18:07, Karthikeyan Bhargavan = wrote: > This scheme seems to assume an RSA key exchange which no longer exists = in TLS 1.3. >=20 > To adapt the multiple PMS design to (EC)DHE would require more work, = and it is not clear what the benefit would be. >=20 > -Karthik >=20 > On 05 Feb 2015, at 10:17, Shahin Noursalehi = wrote: >=20 >> Dear Sir/Madam, >>=20 >> Refer to discussions around TLS 1.3 in Linkedin group "Cryptographers >> and Cryptanalysts", contributor experts agree on the idea of using >> multiple keys with multiple certificate authorities in a TLS session. >> So if one certificate authority is compromised hopefully the others >> are not. The suggested solution would be like the process bellow: >>=20 >> Refer to the way that TLS generates the *master_secret*: >>=20 >> master_secret =3D PseudoRandomFunction(pre_master_secret, "master >> secret", ClientHello.random + ServerHello.random) >>=20 >> We could generate multiple peer-to-peer pre_master_secret(s) for each >> public-key that we receive from the server and XOR them all together. >> So, our offered method of calculation of master_secret will convert >> to: >>=20 >> master_secret =3D PseudoRandomFunction(multiple_pre_master_secret, >> "master secret", ClientHello.random + ServerHello.random) >>=20 >> where: >>=20 >> multiple_pre_master_secret =3D XOR(pre_master_secret_1, >> pre_master_secret_2, .. pre_master_secret_n) >>=20 >> and aim at preventing basic attacks that are known against >> one-time-pad, we could add a circular-bit-rotation(m) to the >> calculation above - each time we do an XOR: >>=20 >> multiple_pre_master_secret =3D ROT(XOR(pre_master_secret_1, >> pre_master_secret_2, .. pre_master_secret_n), m) >>=20 >> Please let us know about your point of views, then we could continue >> discussing the TLS. >>=20 >> With best regards >>=20 >> Shahin Noursalehi >>=20 >>=20 >> Reference: >>=20 >> = https://www.linkedin.com/groups/what-are-new-methods-attack-3901854.S.5958= 888203401314306 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Feb 8 00:51:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15601A890B for ; Sat, 7 Feb 2015 00:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.326 X-Spam-Level: *** X-Spam-Status: No, score=3.326 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AlfzS8v0vOO for ; Sat, 7 Feb 2015 00:29:22 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8CE1A88E4 for ; Sat, 7 Feb 2015 00:29:21 -0800 (PST) Received: by labge10 with SMTP id ge10so5292563lab.12 for ; Sat, 07 Feb 2015 00:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xw6Im2rH91bl7kUU757ZN/qD4t10qGHQ2v6t1rCZWTY=; b=CZPPK3PRUqsU28X1CiU4manmPk4PYFG1PcV4/Vkclba/9l6vtSAguLHa49AiSWydkl fUGl4CACyj71GZ+BLNpr9RRq2JgVazvMnqmr9w8+mHOFJtnsVZotGr61U6410MCfkuzw 2vhDvD80ZVpv9nB80ZV+eyL27WEnKb81N7vrGIprMVl1ehcIkzQm9jF0X334KpzHzX6b y48VDiQRGpu96dj/eF3OMsNSrmbBwnKPT06c4+7n42Dnx11NaRM3JMEnFjeCrgGD+tAJ /CT8FQwieXEF1lMCRWno0RznktQGQfFLlTd4mlP8aV94c7anAI1zuNIzSV0D39Ffvg0A ql/Q== MIME-Version: 1.0 X-Received: by 10.112.53.137 with SMTP id b9mr6470550lbp.66.1423297760379; Sat, 07 Feb 2015 00:29:20 -0800 (PST) Received: by 10.112.156.8 with HTTP; Sat, 7 Feb 2015 00:29:20 -0800 (PST) In-Reply-To: References: <3FE6EA13-AF0F-4838-9F1F-CB0DEC158225@gmail.com> Date: Sat, 7 Feb 2015 11:59:20 +0330 Message-ID: From: Shahin Noursalehi To: Karthikeyan Bhargavan Content-Type: text/plain; charset=ISO-8859-1 Archived-At: X-Mailman-Approved-At: Sun, 08 Feb 2015 00:51:00 -0800 Cc: abadi@cs.ucsc.edu, tls@ietf.org, ChristopherA@alacritymanagement.com Subject: Re: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Feb 2015 08:29:24 -0000 sorry, I am new in ietf. it seems I should reply-all. Thanks for all valid comments & updates,, about migration from TLS 1.2 to 1.3 and higher, while we focus on the value of "pre_master_secret", the idea is still valid: master_secret = PRF(multiple_pre_master_secret, "handshake master secret", hash(handshake)) I think this could simply makes itself compatible with old versions of TLS too. new versions of TLS in client side could understand it from the amount of received public keys (from server) after beginning the handshake phase and then run the proper routines. I have implemented this idea in lab. I only see an over-load in key-exchange phase. The goal of getting multiple certificate authorities involved in a TLS session is *mitigating the problems of implementation* - not more privacy by improvement in maths behind TLS. as you know better, human mistakes/ attacks based on social engineering always threatens a good implementation. Anyway, this would be an optional process - so abides by the policies of QoS too. After 2014, enterprises may look for a method that reduces the risk of being victim of "fake SSL certificate issuers" or those who "put a backdoor in RSA key-pairs". When we have sensitive data, the cost among benefits is nothing. Sometimes a simple email in internet among a patient and a physician that contains some critical health information may jeopardize his/her life style and can not roll-back. ~ Shahin On 2/7/15, Karthikeyan Bhargavan wrote: > To obtain your multi-certificate guarantee as an extension to the standard > TLS 1.3 (EC)DHE exchanges, you do not need multiple pre-master secrets. The > server could send multiple Certificate and CertificateVerify messages, all > of which sign the same handshake, that is, the same client and server > keyshares. So, unless all the signing keys were compromised, the attacker > cannot hijack the connection (since he cannot tamper with the server's > keyshare). > > So a single PMS = KDF(g^xy + .....(handshake hash)....) > but multiple server signatures over the handshake with different signing > keys. > > However, I would be wary of changing the TLS state machine in so substantial > a way without sufficient formal analysis. > > > On 06 Feb 2015, at 18:07, Karthikeyan Bhargavan > wrote: > >> This scheme seems to assume an RSA key exchange which no longer exists in >> TLS 1.3. >> >> To adapt the multiple PMS design to (EC)DHE would require more work, and >> it is not clear what the benefit would be. >> >> -Karthik >> >> On 05 Feb 2015, at 10:17, Shahin Noursalehi wrote: >> >>> Dear Sir/Madam, >>> >>> Refer to discussions around TLS 1.3 in Linkedin group "Cryptographers >>> and Cryptanalysts", contributor experts agree on the idea of using >>> multiple keys with multiple certificate authorities in a TLS session. >>> So if one certificate authority is compromised hopefully the others >>> are not. The suggested solution would be like the process bellow: >>> >>> Refer to the way that TLS generates the *master_secret*: >>> >>> master_secret = PseudoRandomFunction(pre_master_secret, "master >>> secret", ClientHello.random + ServerHello.random) >>> >>> We could generate multiple peer-to-peer pre_master_secret(s) for each >>> public-key that we receive from the server and XOR them all together. >>> So, our offered method of calculation of master_secret will convert >>> to: >>> >>> master_secret = PseudoRandomFunction(multiple_pre_master_secret, >>> "master secret", ClientHello.random + ServerHello.random) >>> >>> where: >>> >>> multiple_pre_master_secret = XOR(pre_master_secret_1, >>> pre_master_secret_2, .. pre_master_secret_n) >>> >>> and aim at preventing basic attacks that are known against >>> one-time-pad, we could add a circular-bit-rotation(m) to the >>> calculation above - each time we do an XOR: >>> >>> multiple_pre_master_secret = ROT(XOR(pre_master_secret_1, >>> pre_master_secret_2, .. pre_master_secret_n), m) >>> >>> Please let us know about your point of views, then we could continue >>> discussing the TLS. >>> >>> With best regards >>> >>> Shahin Noursalehi >>> >>> >>> Reference: >>> >>> https://www.linkedin.com/groups/what-are-new-methods-attack-3901854.S.5958888203401314306 >>> >>> _______________________________________________ >>> 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 Sun Feb 8 01:44:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187D41A8903 for ; Sun, 8 Feb 2015 01:44:03 -0800 (PST) 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_50=0.8, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oC5tqMoMy8L for ; Sun, 8 Feb 2015 01:44:01 -0800 (PST) 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 2E5681A1A75 for ; Sun, 8 Feb 2015 01:44:01 -0800 (PST) Received: from pc (ip25053127.dynamic.kabel-deutschland.de [::ffff:37.5.49.39]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Sun, 08 Feb 2015 10:43:58 +0100 id 0000000000000072.0000000054D72FDE.00006283 Date: Sun, 8 Feb 2015 10:43:57 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20150208104357.405debbd@pc> In-Reply-To: References: <3FE6EA13-AF0F-4838-9F1F-CB0DEC158225@gmail.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-25219-1423388638-0001-2" Archived-At: Subject: Re: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2015 09:44:03 -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-25219-1423388638-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 7 Feb 2015 11:59:20 +0330 Shahin Noursalehi wrote: > Anyway, this would be an optional process - so abides by the policies > of QoS too. After 2014, enterprises may look for a method that reduces > the risk of being victim of "fake SSL certificate issuers" or those > who "put a backdoor in RSA key-pairs". When we have sensitive data, > the cost among benefits is nothing. Sometimes a simple email in > internet among a patient and a physician that contains some critical > health information may jeopardize his/her life style and can not > roll-back. I don't understand how your proposal makes "fake ssl certificate issuers" less likely. You propose to use two keys signed from different CAs. However, in what way does this make it less likely that a completely different CA may issue a rogue cert for the same domain? The attacked user will never see your two keys. If you want to make fake ssl certificates less likely you should use key pinning (right now only available for https, unfortunately not for other protocols) and certificate transparency. I don't see what your proposal adds to that. Also I don't understand your threat scenario "put a backdoor in RSA key-pairs". What do you mean by that? I know that there are some CAs that provide to create the key for you. If you are worried about that just don't do that. Use CSRs and create the key yourself. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-25219-1423388638-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJU1y/dAAoJEKWIAHK7tR5CjMkQAK9cU2nsOs4bSQEbteuVBBw6 FSDOOcxoauJsM6A3D/hfdJ3MVQbMbQ4dQIdf+GJncfG94jbN2P+yjV2y7iruevxe 0/Q1sUs6GF4jRKLpaA1HxKL617UUcIMUnLcx8AavyP5QuCKgt0cOqVooCxGgFoML vw9nvJ+elDgL4yXJ5n+ow7kgToWXyaDoo+9aiVr7lGazQr8ykb7M6uEYF3q5ZbRk IsPKV38cBFmkmxKQMmsB7g0dp3oZPIN6gbSxntNeDBKAXtm0hmZ1shGbnXkWqA+E M15CraoAziqACOvH8JuHtZ0Vvqkjrz8xWERGwMcuOd82gBDBGVTV+H8Rn1Y0mJ1x YooZbFZsRNtxtlhtvEI8/6nF7vyU1uNBhH11A7H9MFvGWWMjlV6j95FeuV0W2eAE Y6jJYc6SZy+OzwOynYXhuH2dOPT3B58YCYHo52jyIxzBIUYi/i5QMXr+mB6CMthD wIwoMpw8/te2u0uyGxmmiSzja5ecEnK/f9nVnlhf+RycIxrBWAvg+hOgI3rYf8f5 49eR79LaiZDfni25KCp4Epuv4JO2nDzAIbvwjiKCqhht2Qs8wPRsNeHSn57ESi7x kQBbsS9YorHc931LcCkIR8R19HNLVo0JU0a/1GYPciXdEwyc5KgTc1yCN+re/+F3 jV8TrknsPTvpnro6/KL4 =Bn1Q -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-25219-1423388638-0001-2-- From nobody Tue Feb 10 23:46:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8585F1A86F2 for ; Tue, 10 Feb 2015 23:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z72CbcBq-4dn for ; Tue, 10 Feb 2015 23:46:53 -0800 (PST) Received: from BLU004-OMC1S36.hotmail.com (blu004-omc1s36.hotmail.com [65.55.116.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9F31A7113 for ; Tue, 10 Feb 2015 23:46:53 -0800 (PST) Received: from BLU177-W18 ([65.55.116.8]) by BLU004-OMC1S36.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 10 Feb 2015 23:46:53 -0800 X-TMN: [cnK0KVnWDfJZv4jge4ejDWAVeJc2w3e4] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Yoav Nir , Dave Garrett Date: Tue, 10 Feb 2015 23:46:52 -0800 Importance: Normal In-Reply-To: References: <201412221945.35644.davemgarrett@gmail.com>, , <201412240223.46107.davemgarrett@gmail.com>, Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2015 07:46:53.0196 (UTC) FILETIME=[E6D3BCC0:01D045CE] Archived-At: Cc: "TLS@ietf.org tls@ietf.org" Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Feb 2015 07:46:55 -0000 >> On Dec 24=2C 2014=2C at 9:23 AM=2C Dave Garrett = wrote:=0A= >>=0A= >> On Wednesday=2C December 24=2C 2014 01:40:10 am you wrote:=0A= >>>> There's no reason to maintain any backwards support here just for=0A= >>>> Internet Explorer 2.0 on Windows 3.1.=0A= >>>=0A= >>> I=92m not objecting to the change=2C but I am objecting to the hyperbol= e. The=0A= >>> issue is with Internet Explorer 6 on Windows XP=2C which still exists= =2C but=0A= >>> more importantly=2C a lot of web service clients running on top of Wind= ows=0A= >>> XP use the same SCHANNEL library as IE would use=2C so they issue a SSL= v2=0A= >>> ClientHello. Despite Microsoft=92s best efforts=2C there is still a=0A= >>> substantial but diminishing install base of XP.=0A= >>=0A= >> I was not aware Microsoft used an SSL2 ClientHello for SSL3. Thanks for = pointing=0A= >> that out. Is it not capable of sending an SSL3/TLS Hello at all? If it w= ere=0A= >> properly configured to enable TLS1 and disable SSL2/3=2C would it send t= he proper=0A= >> TLS compatible Hello? (Microsoft really should've pushed an XP update to= flip=0A= >> that switch years ago)=0A= >=0A= > Yes. From the control panel you clicked =93Internet Options=94=2C and tha= t had a tab for security=2C but it wasn=92t there. Instead=2C it was in the= tab for advanced=2C which had a bunch of options=2C some related to securi= ty=2C but it was under =93encryption=94=2C not security. There were checkbo= xes for support of SSLv2=2C SSLv3=2C and TLS 1.0. By default the SSLv2 and = SSLv3 checkboxes were checked=2C while the TLS 1.0 box was unchecked. To ge= t rid of the SSLv2 ClientHello you had to uncheck the SSLv2. I don=92t thin= k the kind of people who still use Windows XP are the same ones who would g= o into the settings to disable SSLv2.=0A= >=0A= > I might have some of the details wrong. It=92s been a few years since I l= ast set Internet Options on a Windows XP box.=0A= =0A= In fact=2C i think you can disable the SSLv2 ClientHello globally for all u= sers of SChannel using the following reg key:=0A= =0A= Windows Registry Editor Version 5.00=0A= =0A= [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHA= NNEL\Protocols\Multi-Protocol Unified Hello\Client]=0A= "Enabled"=3Ddword:00000000 = From nobody Wed Feb 11 04:26:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C561A8857 for ; Wed, 11 Feb 2015 04:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.839 X-Spam-Level: X-Spam-Status: No, score=-3.839 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEfKKqgrgwow for ; Wed, 11 Feb 2015 04:26:17 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E561A8856 for ; Wed, 11 Feb 2015 04:26:17 -0800 (PST) Received: from mail1.sbs.de (localhost [127.0.0.1]) by thoth.sbs.de (8.14.3/8.14.3) with ESMTP id t1BCQFkI000309 for ; Wed, 11 Feb 2015 13:26:15 +0100 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.14.3/8.14.3) with ESMTP id t1BCQEsq007116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Feb 2015 13:26:15 +0100 Received: from DENBGAT9ERJMSX.ww902.siemens.net (139.22.70.139) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 11 Feb 2015 13:26:14 +0100 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.229]) by DENBGAT9ERJMSX.ww902.siemens.net ([139.22.70.139]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 13:26:13 +0100 From: "Fries, Steffen" To: "tls@ietf.org" Thread-Topic: OCSP Stapling in RFC 6066 Thread-Index: AdBF9exNOGm/PrWhQsmE6GzwNtr/qA== Date: Wed, 11 Feb 2015 12:26:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.50] Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B33781D3E82DENBGAT9EH2MSXww9_" MIME-Version: 1.0 Archived-At: Subject: [TLS] OCSP Stapling in RFC 6066 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Feb 2015 12:26:21 -0000 --_000_E6C9F0E527F94F4692731382340B33781D3E82DENBGAT9EH2MSXww9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've got a question to the OCSP stapling approach described in RFC 6066 usi= ng the Certificate Status Request extension. It seems that this extension h= as been defined in a way to allow only a client to request the OCSP respons= e from a server during the ClientHello message. From my understanding, it d= oes not support the other way around to let the client also sent OCSP respo= nse for his certificates, when doing a client side authentication. So my q= uestion is simply if this is the right observation and if there is a (stand= ard compliant) way to also let the client sent his OCSP response (maybe thr= ough the generic extension mechanism?)? The background of this question is that in energy automation or smart grid = standards like IEC 62351 require mutual authentication based on certificate= s as part of the TLS handshake. Moreover, the server application often resi= des on field devices and the connecting application is control center. Henc= e, the TLS client side may be more powerful and may have better connectivit= y to OCSP server. Any ideas? Regards Steffen Steffen Fries Siemens AG Corporate Technology Research & Technology Center CT RTC ITS Otto-Hahn-Ring 6 81739 Muenchen, Germany Tel.: +49 89 636-633604 Fax: +49 89 636-48000 mailto:steffen.fries@siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Off= icer; Roland Busch, Lisa Davis, Klaus Helmrich, Hermann Requardt, Siegfried= Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; = Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; = WEEE-Reg.-No. DE 23691322 --_000_E6C9F0E527F94F4692731382340B33781D3E82DENBGAT9EH2MSXww9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’ve got a question to the OCSP stapling appro= ach described in RFC 6066 using the Certificate Status Request extension. I= t seems that this extension has been defined in a way to allow only a clien= t to request the OCSP response from a server during the ClientHello message. From my understanding, it does not support= the other way around to let the client also sent OCSP response for his &nb= sp;certificates, when doing a client side authentication. So my question is= simply if this is the right observation and if there is a (standard compliant) way to also let the client sent his= OCSP response (maybe through the generic extension mechanism?)?=

 

The background of this question is that in energy au= tomation or smart grid standards like IEC 62351 require mutual authenticati= on based on certificates as part of the TLS handshake. Moreover, the server= application often resides on field devices and the connecting application is control center. Hence, the TLS c= lient side may be more powerful and may have better connectivity to OCSP se= rver.

 

Any ideas?

 

Regards

Steffen

 

Steffen Fries
Siemens AG
Corporate Technology
Research & Technology Center
CT RTC ITS
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Tel.: +49 89 636-633604
Fax: +49 89 636-48000
mai= lto:steffen.fries@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Bo= ard: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Ch= ief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Hermann Requardt, Siegfried Russwurm, Ralf P. Thomas; Registered= offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlot= tenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322=

 

--_000_E6C9F0E527F94F4692731382340B33781D3E82DENBGAT9EH2MSXww9_-- From nobody Wed Feb 11 05:13:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB61A886A for ; Wed, 11 Feb 2015 05:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaUSR6XOX1yT for ; Wed, 11 Feb 2015 05:12:56 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 987601A0163 for ; Wed, 11 Feb 2015 05:12:56 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1BDCtUr027129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 11 Feb 2015 08:12:55 -0500 Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1BDCsci028631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 11 Feb 2015 08:12:55 -0500 Message-ID: <54DB5555.6070207@redhat.com> Date: Wed, 11 Feb 2015 14:12:53 +0100 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tls@ietf.org References: <201412221945.35644.davemgarrett@gmail.com>, In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Feb 2015 13:12:58 -0000 On 12/24/2014 08:02 AM, Yuhong Bao wrote: >>> >>> There's no reason to maintain any backwards support here just for Internet >>> Explorer 2.0 on Windows 3.1. >>> >> >> I’m not objecting to the change, but I am objecting to the hyperbole. The issue is with Internet Explorer 6 on Windows XP, which still exists, but more importantly, a lot of web service clients running on top of Windows XP use the same SCHANNEL library as IE would use, so they issue a SSLv2 ClientHello. Despite Microsoft’s best efforts, there is still a substantial but diminishing install base of XP. >> >> It’s fine for us to break compatibility with these clients, but let’s not pretend it’s some ancient technology that doesn’t exist in the market anymore. >> > If needed, one suggestion would be to cap the old SSLv2 ClientHello to TLS 1.2. At least make it TLS 1.1 instead. With TLS 1.2, the SSLv2 ClientHello cannot include the signature algorithms extension, so SHA-1 is used instead of the concatenation of MD5 and SHA-1, and this usually not what is wanted. -- Florian Weimer / Red Hat Product Security From nobody Wed Feb 11 05:17:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573921A8880 for ; Wed, 11 Feb 2015 05:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T5Hc9Dp4QV2 for ; Wed, 11 Feb 2015 05:17:39 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 24C4F1A0163 for ; Wed, 11 Feb 2015 05:17:39 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1BDHc2H031185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 11 Feb 2015 08:17:38 -0500 Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1BDHbNQ018748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 11 Feb 2015 08:17:38 -0500 Message-ID: <54DB5670.8070009@redhat.com> Date: Wed, 11 Feb 2015 14:17:36 +0100 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tls@ietf.org References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com> In-Reply-To: <201412271739.24476.davemgarrett@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Feb 2015 13:17:42 -0000 On 12/27/2014 11:39 PM, Dave Garrett wrote: > On Saturday, December 27, 2014 05:07:12 pm Hauke Mehrtens wrote: >> On 12/24/2014 07:40 AM, Yoav Nir wrote: >>> It’s fine for us to break compatibility with these clients, but let’s not >>> pretend it’s some ancient technology that doesn’t exist in the market >>> anymore. >> >> In addition the Oracle Java Runtime Environment in Version 6 uses a SSL >> v2 compatible ClientHello in the default settings. It supports SSL v3 >> and TLS 1.0. In Java JRE 7 a SSLv3 ClientHello is used by default. >> >> I think a TLS 1.3 Client must not send a SSLv2 ClientHello, but a server >> should understand it. > > The newest version of TLS should not be have to be written to accommodate an 8 > year old EOL Java version's default settings. I could reproduce the behavior with OpenJDK 6 which is still supported: https://bugzilla.redhat.com/show_bug.cgi?id=880223 Because it's not EOL, we can still fix the defaults, although this may not be what some users expect or need. (FWIW, Android does not use “Java 6”, it's an independent implementation with different behavior and defaults.) -- Florian Weimer / Red Hat Product Security From nobody Wed Feb 11 07:11:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D451A19FE for ; Wed, 11 Feb 2015 07:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxeQlbZD4aAK for ; Wed, 11 Feb 2015 07:11:01 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 490B01A0162 for ; Wed, 11 Feb 2015 07:10:01 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E5F7A4761C; Wed, 11 Feb 2015 15:10:00 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CFB8D47618; Wed, 11 Feb 2015 15:10:00 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B8AD62082; Wed, 11 Feb 2015 15:10:00 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 11 Feb 2015 09:09:59 -0600 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.0913.011; Wed, 11 Feb 2015 09:09:59 -0600 From: "Salz, Rich" To: "Fries, Steffen" , "tls@ietf.org" Thread-Topic: OCSP Stapling in RFC 6066 Thread-Index: AdBF9exNOGm/PrWhQsmE6GzwNtr/qAAFoOZQ Date: Wed, 11 Feb 2015 15:09:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.42.238] Content-Type: multipart/alternative; boundary="_000_adf23d68f8a9401ab0b37f7c2cea87efustx2exdag1mb2msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] OCSP Stapling in RFC 6066 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Feb 2015 15:11:04 -0000 --_000_adf23d68f8a9401ab0b37f7c2cea87efustx2exdag1mb2msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are correct; there is no way for a client to include its OCSP status. = Defining a new extension that the client could put in its hello message wo= uld be interesting; it might even work. -- Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz --_000_adf23d68f8a9401ab0b37f7c2cea87efustx2exdag1mb2msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You are correct; there= is no way for a client to include its OCSP status.   Defining a = new extension that the client could put in its hello message would be inter= esting; it might even work.

 

-- 

Principal Security Eng= ineer, Akamai Technologies

IM: rsalz@jabber.me Twitter: RichSalz

--_000_adf23d68f8a9401ab0b37f7c2cea87efustx2exdag1mb2msgcorpak_-- From nobody Wed Feb 11 08:41:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3451A028A for ; Wed, 11 Feb 2015 08:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHRIGS9d9u-Z for ; Wed, 11 Feb 2015 08:41:31 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 49DA11A1A78 for ; Wed, 11 Feb 2015 08:41:31 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5F7B5F984; Wed, 11 Feb 2015 11:41:28 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 877C91FFAB; Wed, 11 Feb 2015 11:41:38 -0500 (EST) From: Daniel Kahn Gillmor To: Kurt Roeckx , Dave Garrett In-Reply-To: <20141226181139.GA5321@roeckx.be> References: <201412221945.35644.davemgarrett@gmail.com> <20141226181139.GA5321@roeckx.be> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 11 Feb 2015 11:41:38 -0500 Message-ID: <871tlwpfi5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Feb 2015 16:41:33 -0000 On Fri 2014-12-26 13:11:39 -0500, Kurt Roeckx wrote: > On Mon, Dec 22, 2014 at 07:45:35PM -0500, Dave Garrett wrote: >> I've submitted a straightforward PR to remove the SSL 2 backwards compatibility >> section from the current TLS 1.3 draft: >> >> https://github.com/tlswg/tls13-spec/pull/105 >> >> SSL 2.0 backwards compatibility was previously deprecated in TLS 1.2 (2008) and >> was warned to be "phased out with all due haste". RFC 6176 (2011) prohibits it >> entirely. It's a section of obsolete complexity still in the draft. >> >> The PR replaces the section with a simple "MUST NOT" send or accept for TLS 1.3 >> implementations. > > I'm having mixed feelings about this. > > It's saying that you should refuse a connection from a client that > supports TLS 1.0 but set it up using a SSLv2 compatible client > hello. If TLS 1.0 is still acceptable, why would you refuse such > a connection? It's not saying that. It says: Implementations MUST NOT negotiate TLS 1.3 or later using an SSL version 2.0 compatible CLIENT-HELLO. Implementations MAY accept an SSL version 2.0 compatible CLIENT-HELLO in order to negotiate older versions of TLS, however this is not recommended. So if the client connects with an SSLv2 handshake, we can negotiate TLS 1.0 with it (while acknowledging that this isn't a recommended state). --dkg From nobody Wed Feb 11 17:19:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7621A88AD; Wed, 11 Feb 2015 17:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt4VEY1Nq46f; Wed, 11 Feb 2015 17:19:20 -0800 (PST) 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 8BF961A8880; Wed, 11 Feb 2015 17:19:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E3D16BEF7; Thu, 12 Feb 2015 01:19:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVBjRr_aAJ72; Thu, 12 Feb 2015 01:19:48 +0000 (GMT) Received: from [172.16.29.97] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F8AFBEEE; Thu, 12 Feb 2015 01:19:47 +0000 (GMT) Message-ID: <54DBFF8F.6000709@cs.tcd.ie> Date: Thu, 12 Feb 2015 01:19:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> In-Reply-To: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 01:19:24 -0000 Folks, I've looked back at the IETF LC for this and chatted with the TLS chairs and my conclusion is that we did end up with rough consensus for this so I've put it on the Feb 19 IESG telechat. I think Sean's shepherd writeup [1] did a fine job of capturing the LC outcome there so I won't try better that. Thanks, S. [1] https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/shepherdwriteup/ On 09/01/15 18:05, The IESG wrote: > > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > - 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing > Protocol Downgrade Attacks' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a Signaling Cipher Suite Value (SCSV) that > prevents protocol downgrade attacks on the Transport Layer Security > (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > From nobody Wed Feb 11 19:38:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA1B1A1F20; Wed, 11 Feb 2015 19:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKDcR8Ozmj-V; Wed, 11 Feb 2015 19:38:01 -0800 (PST) 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 721851A8A8E; Wed, 11 Feb 2015 19:37:56 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 54DCA2ACD5; Thu, 12 Feb 2015 04:37:54 +0100 (CET) X-purgate-ID: 152705::1423712274-000007DF-BFC4B806/0/0 X-purgate-size: 657 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3386A43EF9; Thu, 12 Feb 2015 04:37:54 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 293391B190; Thu, 12 Feb 2015 04:37:54 +0100 (CET) In-Reply-To: <54DBFF8F.6000709@cs.tcd.ie> To: Stephen Farrell Date: Thu, 12 Feb 2015 04:37:54 +0100 (CET) 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: <20150212033754.293391B190@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 03:38:04 -0000 Stephen Farrell wrote: > > I've looked back at the IETF LC for this and chatted with the > TLS chairs and my conclusion is that we did end up with rough > consensus for this so I've put it on the Feb 19 IESG telechat. > > I think Sean's shepherd writeup [1] did a fine job of capturing > the LC outcome there so I won't try better that. Has the IESG given up on "technical leadership", and into rubberstamping? Improving the downgrade-scsv proposal to make it suck *MUCH* less would be trivial, and this would be a prime candidate for the IESG to bounce the current proposal back to the WG and ask them to FIX IT or be gone. -Martin From nobody Wed Feb 11 23:56:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195F21A0399 for ; Wed, 11 Feb 2015 23:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHSN252X_r0s for ; Wed, 11 Feb 2015 23:55:58 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701211A1B35 for ; Wed, 11 Feb 2015 23:55:58 -0800 (PST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by david.siemens.de (8.14.3/8.14.3) with ESMTP id t1C7tsQO020887; Thu, 12 Feb 2015 08:55:54 +0100 Received: from DEFTHW99ERLMSX.ww902.siemens.net (defthw99erlmsx.ww902.siemens.net [139.22.70.136]) by mail2.sbs.de (8.14.3/8.14.3) with ESMTP id t1C7trUI013590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 08:55:53 +0100 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.229]) by DEFTHW99ERLMSX.ww902.siemens.net ([139.22.70.136]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 08:55:53 +0100 From: "Fries, Steffen" To: "Salz, Rich" , "tls@ietf.org" Thread-Topic: OCSP Stapling in RFC 6066 Thread-Index: AdBF9exNOGm/PrWhQsmE6GzwNtr/qAAFoOZQACLbXWA= Date: Thu, 12 Feb 2015 07:55:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.44] Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B33781D47B4DENBGAT9EH2MSXww9_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] OCSP Stapling in RFC 6066 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 07:56:02 -0000 --_000_E6C9F0E527F94F4692731382340B33781D47B4DENBGAT9EH2MSXww9_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rich, thank you for the feedback. Yes, putting it into the ServerHello would prob= ably be the most easy approach, as it allows extensions. It could probably = also be put into the CertificateRequest direcly, but certainly requires mor= e specification. Regards Steffen From: Salz, Rich [mailto:rsalz@akamai.com] Sent: Mittwoch, 11. Februar 2015 16:10 To: Fries, Steffen; tls@ietf.org Subject: RE: OCSP Stapling in RFC 6066 You are correct; there is no way for a client to include its OCSP status. = Defining a new extension that the client could put in its hello message wo= uld be interesting; it might even work. -- Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz --_000_E6C9F0E527F94F4692731382340B33781D47B4DENBGAT9EH2MSXww9_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rich,

 

thank you for the feed= back. Yes, putting it into the ServerHello would probably be the most easy = approach, as it allows extensions. It could probably also be put into the C= ertificateRequest direcly, but certainly requires more specification.

 

Regards

Steffen

 

From: Salz, Rich [mailto:rsalz@akamai.com]
Sent: Mittwoch, 11. Februar 2015 16:10
To: Fries, Steffen; tls@ietf.org
Subject: RE: OCSP Stapling in RFC 6066

 

You are correct; there is no way for a client to include its OCSP st= atus.   Defining a new extension that the client could put in its= hello message would be interesting; it might even work.

 

-- 

Principal Security Engineer, Akamai Technologies

IM: rsalz@jabber.me Twitter: RichSalz

--_000_E6C9F0E527F94F4692731382340B33781D47B4DENBGAT9EH2MSXww9_-- From nobody Thu Feb 12 03:57:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292531A1BA7 for ; Thu, 12 Feb 2015 03:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7msYg1ML2ATj for ; Thu, 12 Feb 2015 03:57:44 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 6FF8D1A1B8C for ; Thu, 12 Feb 2015 03:57:43 -0800 (PST) Received: from [46.33.133.68] (helo=lap.dom.ain) from_AS 51561 by wizmail.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85_42-aebaf3d) id 1YLsOr-0003DC-A3 for tls@ietf.org (return-path ); Thu, 12 Feb 2015 11:57:41 +0000 Message-ID: <54DC9533.7070101@wizmail.org> Date: Thu, 12 Feb 2015 11:57:39 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) Archived-At: Subject: Re: [TLS] OCSP Stapling in RFC 6066 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 11:57:46 -0000 On 11/02/15 12:26, Fries, Steffen wrote: > I've got a question to the OCSP stapling approach described in RFC 6066 Why not jump directly to an RFC 6961 analogue? -- Cheers, Jeremy From nobody Thu Feb 12 10:51:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C251A1B59 for ; Thu, 12 Feb 2015 10:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOAcHyRfRMkL for ; Thu, 12 Feb 2015 10:51:29 -0800 (PST) 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 EEF1E1A1B56 for ; Thu, 12 Feb 2015 10:51:28 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id BA1F54497E; Thu, 12 Feb 2015 19:51:23 +0100 (CET) X-purgate-ID: 152705::1423767087-000007DF-0BA2EA2F/0/0 X-purgate-size: 2071 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 89FEA45456; Thu, 12 Feb 2015 19:51:23 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 81BA01B19A; Thu, 12 Feb 2015 19:51:23 +0100 (CET) In-Reply-To: <54DC9533.7070101@wizmail.org> To: Jeremy Harris Date: Thu, 12 Feb 2015 19:51:23 +0100 (CET) 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: <20150212185123.81BA01B19A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] OCSP Stapling in RFC 6066 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 18:51:31 -0000 Jeremy Harris wrote: > Fries, Steffen wrote: >> I've got a question to the OCSP stapling approach described in RFC 6066 > > Why not jump directly to an RFC 6961 analogue? Your observation is correct that the rfc6066 OCSP extension is limited to a single OCSP response for the server certificate, whereas the TLS extension defined in rfc6961 allows for multiple OCSP responses, including OCSP responses for CA certificates in the certificate chain of the server. But there are a number of differences in the server and client authentication that make these two TLS extensions (or their approach) a bad fit for client certificate authentication. For the server certificate, the Server's decision/choice for a specific server certificate happens (or at least can happen) while the server evaluates the TLS protocol options proposed in ClientHello and composed the ServerHello response _after_ making the selections of TLS protocol options. So when the server composes the ServerHelloExtensions it knows which server certificate it is going to use and can insert the respective OCSP responses into ServerHello. The situation is substantially different for the client, who has to include all TLS protocol options that are up for negotation upfront in ClientHello(Extensions). At this point, the client does not know whether the server is going to request a client certificate at all, nor does the client know, which list of trusted certification_authorities or which algorithms the server supports and is going to select/request. So the approach for conveying OCSP responses for the client certificate from the client to the server should probably be on the second batch of handshake messages from client to server in a full TLS handshake, such as using a "TLS Handshake Message for Supplemental Data" (rfc4680). I agree that the rfc4680 approach is more code to implement, but such an approach would not break when the client has more than one client certificates or additional client certificates other than X.509. -Martin From nobody Thu Feb 12 11:43:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2DB1A1BF2 for ; Thu, 12 Feb 2015 11:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O82bBOnQIdvE for ; Thu, 12 Feb 2015 11:43:35 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CCF1A1B6A for ; Thu, 12 Feb 2015 11:43:35 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hi2so7043990wib.0 for ; Thu, 12 Feb 2015 11:43:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fkva658OK6G4X/PoeyCwZ8+VdtqmeMzYsDVlMaWTwls=; b=T7q/HezUa/eivo2MIazCQPtKtkRV7Z88X2+4kPejKWhqA0n8u/7JY+pPutQBd89srY I7tUNJpbm10pbeuUF4VTz2pkGC4xgHcHM4wqYKuVSzPZI/1FIoAeyC46S4uWuQErPlcr u6wfNNlJ/mYHrUshJRDZyQWxKMdU8SenJb40xdNclgB1CMvsYD/P6QOEKKXdRYfOsMO0 njyLa4YPYUoOVxrtDSBlZDsy5U0zTJqr8VHKydF9kf7BeIQVqd5pOvYQyMS9crvO8gGH B66M5PXI26kxbyrVPiXORSfgS5R6XqcAo3DDOSY7xl5l49LWIfzGvbSFlYCtoN7NWwRM 6Upg== X-Gm-Message-State: ALoCoQlb3N8qF/5XI8KHN5d0EqSGwnE5/uij3rdb/2cTTrNMs1ejxXAsTGZLdIBch/Kysp8tdrkp X-Received: by 10.194.122.38 with SMTP id lp6mr11693552wjb.24.1423770212683; Thu, 12 Feb 2015 11:43:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.219.205 with HTTP; Thu, 12 Feb 2015 11:42:52 -0800 (PST) In-Reply-To: <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com> References: <201412300503.03923.davemgarrett@gmail.com> <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com> From: Eric Rescorla Date: Thu, 12 Feb 2015 11:42:52 -0800 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=089e01227ee4c4f4a3050ee95573 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] consensus on backwards compatibility changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 19:43:38 -0000 --089e01227ee4c4f4a3050ee95573 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have merged PR#105. I am awaiting chair guidance on PR#107. -Ekr On Tue, Jan 27, 2015 at 9:21 AM, Sean Turner wrote: > We believe that what=E2=80=99s reflected in PR #105 reflects list consens= us. But, > we (as chairs) have a couple of thoughts: > > 0) We both hate =E2=80=9CMAY=E2=80=9D requirements language. We=E2=80=99= d prefer that the > following be reworded (this is just a starting point): > > OLD: > > Implementations MAY accept an SSL version 2.0 compatible > CLIENT-HELLO in order to negotiate older versions of TLS, > however this is not recommended. > > NEW: > > Implementations are NOT RECOMMENDED to accept an > SSL version 2.0 compatible CLIENT-HELLO in order to > negotiate older versions of TLS. > > note that the using =E2=80=9CNOT RECOMMENDED=E2=80=9D also means we need = to add that to > the 2119 language clause but we can do that later. Basically: > > s1.1: OLD: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > NEW: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", =E2=80=9CSHALL NO= T=E2=80=9D, > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED=E2=80=9D, > "MAY", and "OPTIONAL" in this document are to be interpreted as describe= d > in RFC 2119 [RFC2119]. > > 1) We=E2=80=99d like to make it crystal clear in the SSL3.0 text whether = you=E2=80=99re > talking about the hello version or record version. We=E2=80=99re pretty s= ure that > =E2=80=9Cprotocol version=E2=80=9D in the following is the hello version = but we think that > should be made clear. > > Implementations MUST NOT send a ClientHello or ServerHello with > the protocol version set to { 3, 0 } or less. Any endpoint receiving a > Hello message with the protocol version set to { 3, 0 } MUST respond > with a "protocol_version" alert message and close the connection. > > spt > > On Jan 25, 2015, at 14:36, Eric Rescorla wrote: > > > Based on reading the mailing list, it seems to me that there is rough > consensus > > on PR#105, but not (yet?) on PR#107. > > > > Chairs, > > I'd like to merge PR#105. Do you agree that there is consensus? If so, > > I will merge. > > > > Can you please advise on how you would like to proceed on PR#107? > > > > -Ekr > > > > > > > > > > On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett > wrote: > > Per Brian's suggestion, I've split the topic of full prohibition of SSL > v2 > > CLIENT-HELLO usage into its own issue, as there is clearly no consensus > on this > > yet. It would be really nice if some real-world stats on how much this = is > > actually used could be provided. (I think continued acceptance of it is > > illegitimate, but hard data is harder to argue with) > > > > Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely > > https://github.com/tlswg/tls13-spec/issues/113 > > > > I have heard notable support for this, including Eric, but I do concede > there > > might be too much desire for infinite backwards compatibility to reach > consensus. > > I'm still hopeful we can come to an agreement that two decades is a > sufficient > > deprecation period. :/ > > > > I have two PRs for the backwards compatibility section. > > > > The first has all SSL backwards compatibility changes. In addition to > RFC 6176 > > SSL 2 language, I've added SSL 3 negotiation prohibition as per Martin'= s > > suggestion (based on the current I-D). The v2 hello documentation is cu= t > out, > > but seeing as it's only valid for prior versions, prior RFCs can be > referenced > > if needed. > > > > PR #105 remove SSL 2 backwards compatibility section & prohibit SSL > negotiation > > https://github.com/tlswg/tls13-spec/pull/105 > > > > The second PR has more general backwards compatibility section > improvements, > > prohibition of RC4 (also based on its current I-D), and Brian's > ClientHello > > version freeze proposal. Currently, I have the ClientHello version > listed as a > > "MUST", but I leave for the possibility that a "SHOULD" might be > appropriate if > > other tactics for dealing with buggy servers should continue to be > permitted. > > Feedback from Microsoft, Oracle, or anyone else implementing alternate > > workarounds here would be greatly appreciated. > > > > PR #107 revise backwards compatibility & fix ClientHello version > > https://github.com/tlswg/tls13-spec/pull/107 > > > > Note that the SSL3 & RC4 language based on current drafts is of course > > contingent on those being passed successfully, though this is generally > > expected. > > > > Both PRs update the Informative References as needed, which I've > hopefully done > > correctly. > > > > > > Dave > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > --089e01227ee4c4f4a3050ee95573 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have merged PR#105. I am awai= ting chair guidance on PR#107.

-Ekr

On Tue, Jan 27, 2015 at 9:21 AM, Sean Turner <turners@iec= a.com> wrote:
We believe th= at what=E2=80=99s reflected in PR #105 reflects list consensus.=C2=A0 But, = we (as chairs) have a couple of thoughts:

0) We both hate =E2=80=9CMAY=E2=80=9D requirements language.=C2=A0 We=E2=80= =99d prefer that the following be reworded (this is just a starting point):=

OLD:

=C2=A0Implementations MAY accept an SSL version 2.0 compatible
=C2=A0CLIENT-HELLO in order to negotiate older versions of= TLS,
=C2=A0however this is not recommended.

NEW:

=C2=A0Implementations are NOT RECOMMENDED to accept an
=C2=A0SSL version 2.0 compatible CLIENT-HELLO in order to<= br> =C2=A0negotiate older versions of TLS.

note that the using =E2=80=9CNOT RECOMMENDED=E2=80=9D also means we need to= add that to the 2119 language clause but we can do that later.=C2=A0 Basic= ally:

s1.1: OLD:

=C2=A0The key words "MUST", "MUST NOT", "REQUIRED&= quot;, "SHALL", "SHALL NOT",
=C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
=C2=A0document are to be interpreted as described in RFC 2119 [RFC2119].
NEW:

=C2=A0The key words "MUST", "MUST NOT", "REQUIRED&= quot;, "SHALL", =E2=80=9CSHALL NOT=E2=80=9D,
=C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED", = "NOT RECOMMENDED=E2=80=9D,
=C2=A0"MAY", and "OPTIONAL" in this document are to be = interpreted as described
=C2=A0in RFC 2119 [RFC2119].

1) We=E2=80=99d like to make it crystal clear in the SSL3.0 text whether yo= u=E2=80=99re talking about the hello version or record version. We=E2=80=99= re pretty sure that =E2=80=9Cprotocol version=E2=80=9D in the following is = the hello version but we think that should be made clear.

=C2=A0Implementations MUST NOT send a ClientHello or ServerHello with
=C2=A0the protocol version set to { 3, 0 } or less. Any endpoint receiving = a
=C2=A0Hello message with the protocol version set to { 3, 0 } MUST respond<= br> =C2=A0with a "protocol_version" alert message and close the conne= ction.

spt

On Jan 25, 2015, at 14:36, Eric Rescorla <ekr@rtfm.com> wrote:

> Based on reading the mailing list, it seems to me that there is rough = consensus
> on PR#105, but not (yet?) on PR#107.
>
> Chairs,
> I'd like to merge PR#105. Do you agree that there is consensus? If= so,
> I will merge.
>
> Can you please advise on how you would like to proceed on PR#107?
>
> -Ekr
>
>
>
>
> On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
> Per Brian's suggestion, I've split the topic of full prohibiti= on of SSL v2
> CLIENT-HELLO usage into its own issue, as there is clearly no consensu= s on this
> yet. It would be really nice if some real-world stats on how much this= is
> actually used could be provided. (I think continued acceptance of it i= s
> illegitimate, but hard data is harder to argue with)
>
> Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely
> https://github.com/tlswg/tls13-spec/issues/113
>
> I have heard notable support for this, including Eric, but I do conced= e there
> might be too much desire for infinite backwards compatibility to reach= consensus.
> I'm still hopeful we can come to an agreement that two decades is = a sufficient
> deprecation period. :/
>
> I have two PRs for the backwards compatibility section.
>
> The first has all SSL backwards compatibility changes. In addition to = RFC 6176
> SSL 2 language, I've added SSL 3 negotiation prohibition as per Ma= rtin's
> suggestion (based on the current I-D). The v2 hello documentation is c= ut out,
> but seeing as it's only valid for prior versions, prior RFCs can b= e referenced
> if needed.
>
> PR #105 remove SSL 2 backwards compatibility section & prohibit SS= L negotiation
> https://github.com/tlswg/tls13-spec/pull/105
>
> The second PR has more general backwards compatibility section improve= ments,
> prohibition of RC4 (also based on its current I-D), and Brian's Cl= ientHello
> version freeze proposal. Currently, I have the ClientHello version lis= ted as a
> "MUST", but I leave for the possibility that a "SHOULD&= quot; might be appropriate if
> other tactics for dealing with buggy servers should continue to be per= mitted.
> Feedback from Microsoft, Oracle, or anyone else implementing alternate=
> workarounds here would be greatly appreciated.
>
> PR #107 revise backwards compatibility & fix ClientHello version > https://github.com/tlswg/tls13-spec/pull/107
>
> Note that the SSL3 & RC4 language based on current drafts is of co= urse
> contingent on those being passed successfully, though this is generall= y
> expected.
>
> Both PRs update the Informative References as needed, which I've h= opefully done
> correctly.
>
>
> Dave
>
> __________________= _____________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--089e01227ee4c4f4a3050ee95573-- From nobody Thu Feb 12 14:15:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34C1A03A0 for ; Thu, 12 Feb 2015 14:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cos2i1mFr0HG for ; Thu, 12 Feb 2015 14:14:57 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 286AA1A0367 for ; Thu, 12 Feb 2015 14:14:57 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id q107so10431664qgd.8 for ; Thu, 12 Feb 2015 14:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=y9nhiAIiY3Q36+/XsepTnmODU4pn+uAyN/zWTL9WkB8=; b=ba5jxZgcEVR0fZb6rqaj8ZHjaRo3ZbHBnyMgnK7ONhro7BiWFHnrtX/7z5vwzzmqj0 Lc84fRwtq4FNrnMWgTfbTPOGaTDvuft3Fsxs3MdvzwUkDgoyYttvOB/Nep6tH/2cN/tM nPiPAqAGnvr+0H7l7W+/OR0u1wRyem/PFZWiMwQG8OJg97e/Fz6G02HUn5oA1AycI0CK cl5gJMj85ZliTs2dxSdG7t5EjF3HbelGxE8/j8n2z/mlkqcxwvfn4IcoGSLSFP2ErUvy ekrMNmNGhwLwEPos9tlkZ7XxF35niZWFiQZ+qToNGLyLW9C5DYsGCorTrJ1xuMW2UB42 JF8Q== X-Received: by 10.140.150.21 with SMTP id 21mr777177qhw.66.1423779296250; Thu, 12 Feb 2015 14:14:56 -0800 (PST) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id q8sm5306812qam.1.2015.02.12.14.14.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Feb 2015 14:14:55 -0800 (PST) From: Dave Garrett To: "TLS@ietf.org (tls@ietf.org)" Date: Thu, 12 Feb 2015 17:14:53 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201412300503.03923.davemgarrett@gmail.com> <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201502121714.54235.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] consensus on backwards compatibility changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 22:15:01 -0000 PR#107 rebased. I believe all comments have all been addressed. https://github.com/tlswg/tls13-spec/pull/107/files To recap the changes: * ClientHello record layer version fixed to {3,1} * other record layer versions explicitly required to be negotiated version * note some security considerations & other suggestions from Brian * some editorial fixups * cite RC4 prohibition draft in backwards compatibility * explicitly forbid ciphers <112 bits for backwards compatibility * added the line: "If an implementation negotiates usage of TLS 1.2, then negotiation of cipher suites also supported by TLS 1.3 SHOULD be preferred, if available." Dave On Thursday, February 12, 2015 02:42:52 pm Eric Rescorla wrote: > I have merged PR#105. I am awaiting chair guidance on PR#107. > > -Ekr From nobody Thu Feb 12 14:27:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944591A1A0B for ; Thu, 12 Feb 2015 14:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk-x6DcTq4sg for ; Thu, 12 Feb 2015 14:27:48 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070E61A0430 for ; Thu, 12 Feb 2015 14:27:27 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id z60so10451060qgd.10 for ; Thu, 12 Feb 2015 14:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:user-agent:mime-version:to:cc:content-type :content-transfer-encoding:message-id; bh=tFdhUAxs8Nv0s84E0/FV9PUJDqW7AjPCGnKFoFxbr5Q=; b=uCGVx2wTo06ATKKnjZBHupr9ZhwCH8ZX6CFTCsIhFPAXxQh6H3Ko83TYMrhRpdWPbg gYdZlDFlC6Y30GJ7eyb7NiXhZLAjNCzK03Nmx+j06d7omw4f4MWrtJfKnitlFhWUaimh fHUIJjQ6LJ4kgj/wn9KJFJCMibIjGHgiwG+vZhir5Jp4zEaThwWSdLy1lIk79TB/WxH3 wmBFsc9CFIkeBuSCVqZsJGOWO5aUu60HerVGsLi3HGKfgjVfTC2rx2+jYPJc4GHHGjCe sLHH4jNcMEBaZHrX3C4lqRIej7mXMlIdFAjkvoXbUiZKTp6E+hLVDFRl2YCNUvj2iCi9 WgWg== X-Received: by 10.140.236.84 with SMTP id h81mr785276qhc.35.1423780046292; Thu, 12 Feb 2015 14:27:26 -0800 (PST) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id y2sm5292619qae.47.2015.02.12.14.27.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Feb 2015 14:27:25 -0800 (PST) From: Dave Garrett Date: Thu, 12 Feb 2015 17:27:24 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 To: "TLS@ietf.org (tls@ietf.org)" Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201502121727.24768.davemgarrett@gmail.com> Archived-At: Cc: Florian Weimer Subject: [TLS] SSL 2 CLIENT-HELLO backwards compatibility compromise X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 22:27:50 -0000 The previous consensus is in the draft now, so resuming discussion on what to do with the SSL 2 CLIENT-HELLO format as was planned. https://github.com/tlswg/tls13-spec/issues/113 I'd like to say there are roughly 3 options on how to deal with SSL 2 CLIENT-HELLO backwards compatibility in TLS 1.3 implementations. (to reiterate, we're talking about the format defined in https://tools.ietf.org/html/rfc5246#appendix-E.2 ) Option #0) Current draft v2 format MUST NOT be sent ever v2 format MUST NOT be used at all for TLS 1.3+ v2 format NOT RECOMMENDED to accept for TLS 1.0-1.2 Option #1) Ditch the format that has been deprecated for 20 years v2 format MUST NOT be sent or accepted for any reason Option #2) Restrict to TLS 1.0 v2 format MUST NOT be sent ever v2 format MUST NOT be used at all for TLS 1.1+ v2 format NOT RECOMMENDED to accept for TLS 1.0 The reason I frame the choices like this is that the TLS 1.0 case was of primary discussion. The TLS 1.2 case was brought up, but seems to have way less justification. Recent discussion also suggested setting TLS 1.1 as allowed and TLS 1.2 as not, however I think focusing only on the primary case of TLS 1.0 could be much better. There has been some limited discussion on how to proceed with deprecating TLS 1.0, and TLS 1.1 has been said to be sufficiently improved as such to not necessarily deprecate it with it. With option #2, once TLS 1.0 is dropped, then for remaining supported TLS versions the situation is the same as option #1; the v2 format is completely prohibited after that point. I think option #2 is a reasonable compromise if enough people are sadly against option #1. Opinions? Dave From nobody Thu Feb 12 14:42:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C11B1A005C; Thu, 12 Feb 2015 14:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYOP1uXyMsGP; Thu, 12 Feb 2015 14:42:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4171A1A31; Thu, 12 Feb 2015 14:42:35 -0800 (PST) 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: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150212224235.19145.44786.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 14:42:35 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:42:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks Authors : Bodo Moeller Adam Langley Filename : draft-ietf-tls-downgrade-scsv-04.txt Pages : 8 Date : 2015-02-12 Abstract: This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. Server update considerations are included. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-downgrade-scsv-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From SRS0=blZG=C6=acm.org=bmoeller@srs.kundenserver.de Thu Feb 12 14:48:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB601A1AFC for ; Thu, 12 Feb 2015 14:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-D9iRP_ygUx for ; Thu, 12 Feb 2015 14:48:28 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (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 2B5F71A1AB9 for ; Thu, 12 Feb 2015 14:48:28 -0800 (PST) Received: from mail-lb0-f181.google.com ([209.85.217.181]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0Lzb6o-1XaNs801nG-014hjl for ; Thu, 12 Feb 2015 23:48:26 +0100 Received: by mail-lb0-f181.google.com with SMTP id b6so12284577lbj.12 for ; Thu, 12 Feb 2015 14:48:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.42.169 with SMTP id p9mr5143072lal.91.1423781305411; Thu, 12 Feb 2015 14:48:25 -0800 (PST) Received: by 10.25.25.194 with HTTP; Thu, 12 Feb 2015 14:48:25 -0800 (PST) In-Reply-To: <20150212224235.19145.44786.idtracker@ietfa.amsl.com> References: <20150212224235.19145.44786.idtracker@ietfa.amsl.com> Date: Thu, 12 Feb 2015 23:48:25 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3507cf271f0050eebea28 X-Provags-ID: V03:K0:33I0fFuDfY4otuAN+JJU6UJjLtOWTBkFnCJivSPkvF5agofI4cc PonKfkhlpth06WAJOzvbrgQkSjWZZHNfp6kJAjOGsS92YWMhDexVSgv52A+7fW58lfLP6Jg lxKzJoXixxnQTlsfLzr2OGD1tx9PjvlyiiCRYxbhq+S6GTiuqjgoGsEYS9mZf20f8z7udkr 4O2PYqcwiOHkL412Ux6lg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:58:04 -0000 --001a11c3507cf271f0050eebea28 Content-Type: text/plain; charset=UTF-8 > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > Title : TLS Fallback Signaling Cipher Suite Value (SCSV) > for Preventing Protocol Downgrade Attacks > Authors : Bodo Moeller > Adam Langley > Filename : draft-ietf-tls-downgrade-scsv-04.txt > Pages : 8 > Date : 2015-02-12 > > Abstract: > This document defines a Signaling Cipher Suite Value (SCSV) that > prevents protocol downgrade attacks on the Transport Layer Security > (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. Server > update considerations are included. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-downgrade-scsv-04 draft-ietf-tls-downgrade-scsv-04 has editorial changes only, namely the following, all in response to the various Last Call reviews: - Abstract: appended "Server update considerations are included." [OPS-Dir review] - Introduction: changed "particularly critical if they mean losing the TLS extension feature (when downgrading to SSL 3.0)" into "particularly harmful when the result is loss of the TLS extension feature by downgrading to SSL 3.0" [Gen-ART review] - Introduction: added "a" with the following result: "... is not a suitable substitute ..." [SecDir review & Gen-ART review] - Introduction: added "the" with the following result: "... if the TLS implementations also include support ..." [SecDir review] - IANA considerations: changed URLs to http://www.iana.org/assignments/tls-parameters. [IANA review] Bodo --001a11c3507cf271f0050eebea28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Transport Layer Security Working Gro= up of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol D= owngrade Attacks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bodo= Moeller
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Adam Langley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-downgrade-scsv-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-02-12

Abstract:
=C2=A0 =C2=A0This document defines a Signaling Cipher Suite Value (SCSV) th= at
=C2=A0 =C2=A0prevents protocol downgrade attacks on the Transport Layer Sec= urity
=C2=A0 =C2=A0(TLS) protocol.=C2=A0 It updates RFC 2246, RFC 4346, and RFC 5= 246.=C2=A0 Server
=C2=A0 =C2=A0update considerations are included.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrad= e-scsv/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-04<= /a>

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-do= wngrade-scsv-04

draft-ietf-tls-downgrad= e-scsv-04 has editorial changes only, namely the following, all=C2=A0in res= ponse to the various Last Call reviews:

- Abst= ract: appended "Server update considerations are included." [OPS-= Dir review]

- Introduction: changed "part= icularly critical if they mean losing the TLS extension feature (when downg= rading to SSL 3.0)" into "particularly harmful when the result is= loss of the TLS extension feature by downgrading to SSL 3.0" [Gen-ART= review]

- Introduction: added "a" with = the following result: "... is not a suitable substitute ..." [Sec= Dir review & Gen-ART review]

- Introductio= n: added "the" with the following result: "... if the TLS im= plementations also include support ..." [SecDir review]
=
- IANA considerations: changed URLs to http://www.iana.org/assignments/tls-p= arameters. [IANA review]

Bodo


--001a11c3507cf271f0050eebea28-- From nobody Thu Feb 12 15:34:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472F01A00FF for ; Thu, 12 Feb 2015 15:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaoGrkQd3-D9 for ; Thu, 12 Feb 2015 15:34:32 -0800 (PST) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694DA1A00D8 for ; Thu, 12 Feb 2015 15:34:32 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id va2so14127461obc.6 for ; Thu, 12 Feb 2015 15:34:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/V5aWCyosI9/3s5ecKRBzfD6p3Rkhi3cAFdIFMTx0+0=; b=TFsvLHzR82ZjjLUZJABK+cRs5QvryxJwa25Q/XD29XD3Sipw57hm2TDXpKdvgUHEDO fVSv4/lU0DCPG3kNjoZpCqVR8/tamAEMFSYJO2/2gVzDKZ1YvAt9wfsjVeEZZkcnPFLD t4qPOVjOoUNy3+EhC2MPj/0PbILgjt4fRnkVHctjUP6/dk05VY+uBcGb84uI+aA9UfHn sIxTjVpCiKHqdvgu3wFb62CbNUNdpIXwcu5m38/CQPuJqQLKcp99LHxHl8Ne5P+tEqPS S1tVmr09o224EYmGZUhs2VDRdCSrfKYu/9cSfHmy+WuDXxU/hTQoQXWPffwph37LYluh f7yA== X-Gm-Message-State: ALoCoQneVg+IFAozT395WKXLT7/CfJ4eGKkOu2FgVsJ3wY/BdcF2gi5ddbFqgx08CdytQZr8Yi5C MIME-Version: 1.0 X-Received: by 10.182.246.69 with SMTP id xu5mr4541379obc.11.1423784071899; Thu, 12 Feb 2015 15:34:31 -0800 (PST) Received: by 10.76.74.167 with HTTP; Thu, 12 Feb 2015 15:34:31 -0800 (PST) In-Reply-To: <201502121727.24768.davemgarrett@gmail.com> References: <201502121727.24768.davemgarrett@gmail.com> Date: Thu, 12 Feb 2015 15:34:31 -0800 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Florian Weimer , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SSL 2 CLIENT-HELLO backwards compatibility compromise X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 23:34:34 -0000 Dave Garrett wrote: > Option #0) Current draft > v2 format MUST NOT be sent ever > v2 format MUST NOT be used at all for TLS 1.3+ > v2 format NOT RECOMMENDED to accept for TLS 1.0-1.2 I think this is fine. We should move on to more important issues. > Option #2) Restrict to TLS 1.0 > v2 format MUST NOT be sent ever > v2 format MUST NOT be used at all for TLS 1.1+ > v2 format NOT RECOMMENDED to accept for TLS 1.0 How to negotiate TLS 1.0 and what is acceptable for TLS 1.0 is out of scope for the TLS 1.3 specification. (More generally, what to do for earlier versions is out of scope.) Cheers, Brian From nobody Thu Feb 12 15:37:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8831A0385 for ; Thu, 12 Feb 2015 15:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV_08eP3OsVF for ; Thu, 12 Feb 2015 15:37:28 -0800 (PST) Received: from BLU004-OMC1S28.hotmail.com (blu004-omc1s28.hotmail.com [65.55.116.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE9E1A00D8 for ; Thu, 12 Feb 2015 15:37:28 -0800 (PST) Received: from BLU177-W51 ([65.55.116.7]) by BLU004-OMC1S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 12 Feb 2015 15:36:11 -0800 X-TMN: [TnE+gDQIA9Ayxu1nagTawg6btgyJnDY/] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Brian Smith , Dave Garrett Date: Thu, 12 Feb 2015 15:36:11 -0800 Importance: Normal In-Reply-To: References: <201502121727.24768.davemgarrett@gmail.com>, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2015 23:36:11.0672 (UTC) FILETIME=[AF233180:01D0471C] Archived-At: Cc: Florian Weimer , "TLS@ietf.org tls@ietf.org" Subject: Re: [TLS] SSL 2 CLIENT-HELLO backwards compatibility compromise X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 23:37:29 -0000 > Dave Garrett wrote:=0A= >> Option #0) Current draft=0A= >> v2 format MUST NOT be sent ever=0A= >> v2 format MUST NOT be used at all for TLS 1.3+=0A= >> v2 format NOT RECOMMENDED to accept for TLS 1.0-1.2=0A= >=0A= > I think this is fine. We should move on to more important issues.=0A= >=0A= >> Option #2) Restrict to TLS 1.0=0A= >> v2 format MUST NOT be sent ever=0A= >> v2 format MUST NOT be used at all for TLS 1.1+=0A= >> v2 format NOT RECOMMENDED to accept for TLS 1.0=0A= >=0A= > How to negotiate TLS 1.0 and what is acceptable for TLS 1.0 is out of=0A= > scope for the TLS 1.3 specification. (More generally=2C what to do for=0A= > earlier versions is out of scope.)=0A= =0A= Maybe do it as a separate BCP draft eventually?=0A= = From nobody Thu Feb 12 15:48:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A137D1A01D5 for ; Thu, 12 Feb 2015 15:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enA2qwcaIJ9G for ; Thu, 12 Feb 2015 15:48:24 -0800 (PST) Received: from BLU004-OMC2S34.hotmail.com (blu004-omc2s34.hotmail.com [65.55.111.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E627B1A0127 for ; Thu, 12 Feb 2015 15:48:23 -0800 (PST) Received: from BLU177-W21 ([65.55.111.73]) by BLU004-OMC2S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 12 Feb 2015 15:48:23 -0800 X-TMN: [4z+NQAdFX+FrT5ES4Pp2O7R42mbmQMW3] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Florian Weimer , "tls@ietf.org" Date: Thu, 12 Feb 2015 15:48:22 -0800 Importance: Normal In-Reply-To: <54DB5555.6070207@redhat.com> References: <201412221945.35644.davemgarrett@gmail.com>, , , , <54DB5555.6070207@redhat.com> Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2015 23:48:23.0179 (UTC) FILETIME=[63264DB0:01D0471E] Archived-At: Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 23:48:26 -0000 > On 12/24/2014 08:02 AM=2C Yuhong Bao wrote:=0A= >>>>=0A= >>>> There's no reason to maintain any backwards support here just for Inte= rnet=0A= >>>> Explorer 2.0 on Windows 3.1.=0A= >>>>=0A= >>>=0A= >>> I=92m not objecting to the change=2C but I am objecting to the hyperbol= e. The issue is with Internet Explorer 6 on Windows XP=2C which still exist= s=2C but more importantly=2C a lot of web service clients running on top of= Windows XP use the same SCHANNEL library as IE would use=2C so they issue = a SSLv2 ClientHello. Despite Microsoft=92s best efforts=2C there is still a= substantial but diminishing install base of XP.=0A= >>>=0A= >>> It=92s fine for us to break compatibility with these clients=2C but let= =92s not pretend it=92s some ancient technology that doesn=92t exist in the= market anymore.=0A= >>>=0A= >> If needed=2C one suggestion would be to cap the old SSLv2 ClientHello to= TLS 1.2.=0A= >=0A= > At least make it TLS 1.1 instead. With TLS 1.2=2C the SSLv2 ClientHello= =0A= > cannot include the signature algorithms extension=2C so SHA-1 is used=0A= > instead of the concatenation of MD5 and SHA-1=2C and this usually not wha= t=0A= > is wanted.=0A= =0A= Just confirmed that IE on Win7 even when misconfigured to enable SSLv2 does= n't send a SSLv2 ClientHello with TLS 1.2 on it which means that SChannel p= robably can't do it at all. Andrei Popov should be able to confirm this.=0A= = From nobody Thu Feb 12 15:53:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7391A1A1E for ; Thu, 12 Feb 2015 15:53:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBLmqGEBxRrC for ; Thu, 12 Feb 2015 15:53:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E6E1A01D5 for ; Thu, 12 Feb 2015 15:53:17 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.81.19; Thu, 12 Feb 2015 23:53:16 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0081.018; Thu, 12 Feb 2015 23:53:16 +0000 From: Andrei Popov To: Yuhong Bao , Florian Weimer , "tls@ietf.org" Thread-Topic: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft Thread-Index: AQHQHviCfkli4qb/ZkyBY/mVwFWNzJyeSvsAgAAGWgCATWmcgIACQ+IAgAABJCA= Date: Thu, 12 Feb 2015 23:53:16 +0000 Message-ID: References: <201412221945.35644.davemgarrett@gmail.com>, , , , <54DB5555.6070207@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: hotmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1252; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(479174004)(24454002)(99286002)(19580405001)(86612001)(86362001)(2656002)(76176999)(54356999)(87936001)(50986999)(19580395003)(107886001)(2501002)(92566002)(74316001)(46102003)(106116001)(62966003)(2950100001)(76576001)(77156002)(93886004)(33656002)(102836002)(2900100001)(122556002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2015 23:53:16.3632 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252 Archived-At: Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2015 23:53:20 -0000 I confirm. Cheers, Andrei -----Original Message----- From: Yuhong Bao [mailto:yuhongbao_386@hotmail.com]=20 Sent: Thursday, February 12, 2015 3:48 PM To: Florian Weimer; tls@ietf.org Cc: Andrei Popov Subject: RE: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3= draft > On 12/24/2014 08:02 AM, Yuhong Bao wrote: >>>> >>>> There's no reason to maintain any backwards support here just for=20 >>>> Internet Explorer 2.0 on Windows 3.1. >>>> >>> >>> I'm not objecting to the change, but I am objecting to the hyperbole. T= he issue is with Internet Explorer 6 on Windows XP, which still exists, but= more importantly, a lot of web service clients running on top of Windows X= P use the same SCHANNEL library as IE would use, so they issue a SSLv2 Clie= ntHello. Despite Microsoft's best efforts, there is still a substantial but= diminishing install base of XP. >>> >>> It's fine for us to break compatibility with these clients, but let's n= ot pretend it's some ancient technology that doesn't exist in the market an= ymore. >>> >> If needed, one suggestion would be to cap the old SSLv2 ClientHello to T= LS 1.2. > > At least make it TLS 1.1 instead. With TLS 1.2, the SSLv2 ClientHello=20 > cannot include the signature algorithms extension, so SHA-1 is used=20 > instead of the concatenation of MD5 and SHA-1, and this usually not=20 > what is wanted. Just confirmed that IE on Win7 even when misconfigured to enable SSLv2 does= n't send a SSLv2 ClientHello with TLS 1.2 on it which means that SChannel p= robably can't do it at all. Andrei Popov should be able to confirm this. =20 From nobody Thu Feb 12 18:24:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9331A005A for ; Thu, 12 Feb 2015 18:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x_VjZFLyfJk for ; Thu, 12 Feb 2015 18:24:52 -0800 (PST) Received: from tlsx.org (tlsx.org [67.207.128.90]) (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 475661A038F for ; Thu, 12 Feb 2015 18:24:52 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.168.20] (may be forged)) (authenticated bits=0) by tlsx.org (8.14.4/8.14.4/Debian-4) with ESMTP id t1D2lHBw006174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 13 Feb 2015 02:47:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1423795644; bh=c+OJukfgl3BXH4hOE44Un43u8KnvcnfysjdO/xEYipI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=tXKoppNB1VXeTM85wRkZX56FVK0ZwocyFvKJcjyf/Wi/L4i26vMcTJC9/xynYxlJ8 7RCwcrCpfXbDRN5zxMD81C+kxuhFhc3haGaLXLJeRjmGxK03jlnGwb8GLDWMvnXQ2Z KAaW7aWp2Kmf39Hda3AN7X7sfPsXlUbsd04exIws= Message-ID: <54DD6065.8000205@metaparadigm.com> Date: Fri, 13 Feb 2015 10:24:37 +0800 From: Michael Clark Organization: Metaparadigm User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dave Garrett , "TLS@ietf.org (tls@ietf.org)" References: <201412300503.03923.davemgarrett@gmail.com> <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com> <201502121714.54235.davemgarrett@gmail.com> In-Reply-To: <201502121714.54235.davemgarrett@gmail.com> Content-Type: multipart/alternative; boundary="------------000701060305000104090406" X-Virus-Scanned: clamav-milter 0.98.5 at klaatu.tlsx.org X-Virus-Status: Clean Archived-At: Subject: Re: [TLS] consensus on backwards compatibility changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2015 02:24:55 -0000 This is a multi-part message in MIME format. --------------000701060305000104090406 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 13/2/15 6:14 am, Dave Garrett wrote: > PR#107 rebased. I believe all comments have all been addressed. > > https://github.com/tlswg/tls13-spec/pull/107/files > > To recap the changes: > * ClientHello record layer version fixed to {3,1} > * other record layer versions explicitly required to be negotiated vers= ion > * note some security considerations & other suggestions from Brian > * some editorial fixups > * cite RC4 prohibition draft in backwards compatibility > * explicitly forbid ciphers <112 bits for backwards compatibility > * added the line: > "If an implementation negotiates usage of TLS 1.2, then negotiation of = cipher > suites also supported by TLS 1.3 SHOULD be preferred, if available." Comments as an observer. 1). Contention on setting the ClientHello record layer version to { 3, 0 } or { 3, 1 } in TLSv1.3 -: The version of the protocol being employed. This document - describes TLS Version 1.3, which uses the version { 3, 4 }. The - version value 3.4 is historical, deriving from the use of {3, 1} - for TLS 1.0. (See {{record-layer-1}}.) Note that a client that - supports multiple versions of TLS may not know what version will - be employed before it receives the ServerHello. See - {{backward-compatibility}} for discussion about what record layer - version number should be employed for ClientHello. +: The version of the protocol being employed in the current record. + TLS clients MUST set this version to { 3, 1 } for the initial ClientHe= llo. + For the ServerHello and all other TLS records this MUST be equal to th= e negotiated version. * In support of https://github.com/tlswg/tls13-spec/issues/113 and SSLv3 deprecation with haste * Observe approximate consensus for TLSv1.3 implementation to not negotiate protocol versions lower than TLSv1.0 with >=3D 128 bit cipher s= uites * Text mentions information leakage. Argue that sending { 3, 1 } { 3, 4 } qualifies as information leakage. * Spec can be explicit that it is NOT RECOMMENDED for TLSv1.3 clients to negotiate SSLv3 { 3, 0 } not to be conflated with the record layer lower bound. * Believe ClientHello { 3, 0 } { 3, 4 } may be more guarded. * The record layer version is not to be conflated with the minimum negotiated TLS protocol version (from the same reasoning we deduce this as information leakage). * If a server sees ClientHello { 3, 0 } { 3, 4 } it knows the ClientHello binary structure changes are additive since { 3, 0 } as it is the record layer binary compatibility boundary. * Given TLSv1.0 is a best practice for a protocol lower bound (separate from TLSv1.3); then a TLSv1.3 client can safely assume servers will be extension tolerant with ClientHello { 3, 0 } { 3, 4 } . * Argue that setting the record layer version to { 3, 0 } leaks less information given it is the record layer binary compatibility boundary (not to be conflated with the minimum supported TLS version). * Observation is that { 3, 0 } { 3, 4 } at the record layer would not be incompatible with a client not supporting versions lower than TLSv1.0 { 3, 1 } * If TLSv1.3 ClientHello is { 3, 1 } { 3, 4 } then so be it; however not pivoting record layer version on backwards incompatible binary changes; leads to { 3, 2 } { 3, 5 } and more information leakage. * The fact that an SSLv3.0 server can parse the first part of the ClientHello is not relevant to the choice of record layer lower bound for the TLSv1.3 ClientHello. Please note these as observations not recommendations. If there is approximate consensus for { 3, 1 } at the record layer then I am in the minority on the *pinned* value; prefer it to the minimum supported backwards compatible record layer version; given an alert indicates a buggy server. Please do not read this as support for SSLv3 backwards compatibility. Flip side: * { 3, 1 } can be regarded as the binary compatibility pivot point due to its extension support. In that case I favor { 3, 1 } * The only argument for { 3, 0 } supports servers that are tolerant of unknown data after the compression methods (in addition to cipher suite tolerance). Flip side: * This tolerance is not a bug. TLS requires extension and version tolerance as it is the forwards compatibility mechanism * This is unknown hello data in view of SSLv3.0 servers that are not even going to be supported * { 3, 0 } leaks less information no matter what the protocol lower bound of the client is Conclusion * Would rather accept ClientHello { 3, 0 } { 3, 5 } and send ServerHello { 3, 4 } { 3, 4 } and not have ClientHello { 3, 0 } { 3, 5} create alerts that lead to downgrade attack vectors * independently from the choice of site operators and clients to drop support for SSLv3.0. i.e. pin the ClientHello record layer at { 3, 0 } * Not in favor of pinning ClientHello record { 3, 1 }. { 3, 0 } should be allowed. * BCP 188 2.) "Negotiating with buggy servers" +### Negotiating with buggy servers + +Some server implementations are known to implement version negotiation +incorrectly. There are buggy TLS servers that simply close the connectio= n +when a client offers a version newer than it supports. Also, it is +known that some servers will refuse the connection if any TLS extensions= are +included in ClientHello. Interoperability with such buggy servers is a c= omplex +topic beyond the scope of this document, and may require multiple connec= tion +attempts by the client. * Primary observation. This section is at odds with the consensus for TLSv1.3 implementation to not negotiate anything lower than TLSv1.0 { 3, 1 } with >=3D TLSv1.2. * While the protocol lower bound may not be in scope for the TLSv1.3 spec; the security concern for bugger servers should be; a small number of buggy servers lead to clients with attack vectors * Buggy servers should not be named or supported in a security protocol draft. As an observer I would prefer to see this text changed from this: "and may require multiple connection attempts by the client." to something like this: "and may require multiple connection attempts by the client, however it is NOT RECOMMENDED that clients make multiple connection attempts as this provides a vector for downgrade attacks" or change the title to: =20 ### Negotiating with version and extension intolerant servers --------------000701060305000104090406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 13/2/15 6:14 am, Dave Garrett wrote:
PR#107 rebased. I believe all comments have all been addressed.

https://github.com/tlswg/tls13-spec/pull/107/files

To recap the changes:
* ClientHello record layer version fixed to {3,1}
* other record layer versions explicitly required to be negotiated version
* note some security considerations & other suggestions from Brian
* some editorial fixups
* cite RC4 prohibition draft in backwards compatibility
* explicitly forbid ciphers <112 bits for backwards compatibility
* added the line:
"If an implementation negotiates usage of TLS 1.2, then negotiation of cipher
suites also supported by TLS 1.3 SHOULD be preferred, if available."

Comments as an observer.


1). Contention on setting the ClientHello record layer version to { 3, 0 } or { 3, 1 } in TLSv1.3

-: The version of the protocol being employed.  This document
-  describes TLS Version 1.3, which uses the version { 3, 4 }.  The
-  version value 3.4 is historical, deriving from the use of {3, 1}
-  for TLS 1.0.  (See {{record-layer-1}}.)  Note that a client that
-  supports multiple versions of TLS may not know what version will
-  be employed before it receives the ServerHello.  See
-  {{backward-compatibility}} for discussion about what record layer
-  version number should be employed for ClientHello.
+: The version of the protocol being employed in the current record.
+  TLS clients MUST set this version to { 3, 1 } for the initial ClientHello.
+  For the ServerHello and all other TLS records this MUST be equal to the negotiated version.

* In support of https://github.com/tlswg/tls13-spec/issues/113 and SSLv3 deprecation with haste
* Observe approximate consensus for TLSv1.3 implementation to not negotiate protocol versions lower than TLSv1.0 with >= 128 bit cipher suites
* Text mentions information leakage. Argue that sending { 3, 1 } { 3, 4 } qualifies as information leakage.
* Spec can be explicit that it is NOT RECOMMENDED for TLSv1.3 clients to negotiate SSLv3 { 3, 0 } not to be conflated with the record layer lower bound.
* Believe ClientHello { 3, 0 } { 3, 4 } may be more guarded.
* The record layer version is not to be conflated with the minimum negotiated TLS protocol version (from the same reasoning we deduce this as information leakage).
* If a server sees ClientHello { 3, 0 } { 3, 4 } it knows the ClientHello binary structure changes are additive since { 3, 0 } as it is the record layer binary compatibility boundary.
* Given TLSv1.0 is a best practice for a protocol lower bound (separate from TLSv1.3); then a TLSv1.3 client can safely assume servers will be extension tolerant with ClientHello { 3, 0 } { 3, 4 } .
* Argue that setting the record layer version to { 3, 0 } leaks less information given it is the record layer binary compatibility boundary (not to be conflated with the minimum supported TLS version).
* Observation is that { 3, 0 } { 3, 4 } at the record layer would not be incompatible with a client not supporting versions lower than TLSv1.0 { 3, 1 }
* If TLSv1.3 ClientHello is { 3, 1 } { 3, 4 } then so be it; however not pivoting record layer version on backwards incompatible binary changes; leads to { 3, 2 } { 3, 5 } and more information leakage.
* The fact that an SSLv3.0 server can parse the first part of the ClientHello is not relevant to the choice of record layer lower bound for the TLSv1.3 ClientHello.

Please note these as observations not recommendations. If there is approximate consensus for { 3, 1 } at the record layer then I am in the minority on the *pinned* value; prefer it to the minimum supported backwards compatible record layer version; given an alert indicates a buggy server. Please do not read this as support for SSLv3 backwards compatibility.

Flip side:

* { 3, 1 } can be regarded as the binary compatibility pivot point due to its extension support. In that case I favor { 3, 1 }
* The only argument for { 3, 0 } supports servers that are tolerant of unknown data after the compression methods (in addition to cipher suite tolerance).

Flip side:

* This tolerance is not a bug. TLS requires extension and version tolerance as it is the forwards compatibility mechanism
* This is unknown hello data in view of SSLv3.0 servers that are not even going to be supported
* { 3, 0 } leaks less information no matter what the protocol lower bound of the client is

Conclusion

* Would rather accept ClientHello { 3, 0 } { 3, 5 } and send ServerHello { 3, 4 } { 3, 4 } and not have ClientHello { 3, 0 } { 3, 5} create alerts that lead to downgrade attack vectors
* independently from the choice of site operators and clients to drop support for SSLv3.0. i.e. pin the ClientHello record layer at { 3, 0 }
* Not in favor of pinning ClientHello record { 3, 1 }. { 3, 0 } should be allowed.
* BCP 188



2.) "Negotiating with buggy servers"

+### Negotiating with buggy servers
+
+Some server implementations are known to implement version negotiation
+incorrectly. There are buggy TLS servers that simply close the connection
+when a client offers a version newer than it supports. Also, it is
+known that some servers will refuse the connection if any TLS extensions are
+included in ClientHello. Interoperability with such buggy servers is a complex
+topic beyond the scope of this document, and may require multiple connection
+attempts by the client.

* Primary observation. This section is at odds with the consensus for TLSv1.3 implementation to not negotiate anything lower than TLSv1.0 { 3, 1 } with >= TLSv1.2.
* While the protocol lower bound may not be in scope for the TLSv1.3 spec; the security concern for bugger servers should be; a small number of buggy servers lead to clients with attack vectors
* Buggy servers should not be named or supported in a security protocol draft.

As an observer I would prefer to see this text changed from this:

    "and may require multiple connection attempts by the client."

to something like this:

    "and may require multiple connection attempts by the client, however it is NOT RECOMMENDED that clients make multiple connection attempts as this provides a vector for downgrade attacks"

or change the title to:
   
### Negotiating with version and extension intolerant servers
--------------000701060305000104090406-- From nobody Thu Feb 12 19:28:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31091A00FB for ; Thu, 12 Feb 2015 19:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAeOV0J5yCr8 for ; Thu, 12 Feb 2015 19:28:04 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0131A00FC for ; Thu, 12 Feb 2015 19:28:04 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id r5so12048230qcx.10 for ; Thu, 12 Feb 2015 19:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=tLX0Bof8kEXGP8B+h4i2wt1XWru+pU7IJDmzYF3Zb3E=; b=TwJBCnf9w1r/0G0Zhz9KxfVRfjz/5IYrOJ0zWvgzFUqcZzt4Rz04lYlAKLnGbstmgs JfnARNuWmCfw5KfUE8F3TbWpWC7NS0ejZpud/RDmhReT2qDa3Rg5l2+AxJmxvp6rcmXt 0HRUXnzwGIC3ei3KIOsXC3h1gG8ErJsECJOTtdY0hZ2NTMjdYcQByZv57WvQMgXmtDNJ yFXjb8fOaCBbWEMKyt79WFT5q0++2Pe4wYQcRvSIekCbPRoJ5ZypJ+e8Degv7N/xuVDD uMBUkNwhIydeOkk87W5gtl0uyUIX8y+rLj/zqM0Byck6n7P1fA03NsCEtY8J6idT6ZfX VTiA== X-Received: by 10.141.28.65 with SMTP id f62mr1321285qhe.90.1423798083722; Thu, 12 Feb 2015 19:28:03 -0800 (PST) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id w5sm5974939qas.41.2015.02.12.19.28.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Feb 2015 19:28:03 -0800 (PST) From: Dave Garrett To: Michael Clark Date: Thu, 12 Feb 2015 22:28:01 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201412300503.03923.davemgarrett@gmail.com> <201502121714.54235.davemgarrett@gmail.com> <54DD6065.8000205@metaparadigm.com> In-Reply-To: <54DD6065.8000205@metaparadigm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201502122228.02125.davemgarrett@gmail.com> Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] consensus on backwards compatibility changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2015 03:28:07 -0000 On Thursday, February 12, 2015 09:24:37 pm Michael Clark wrote: > * Spec can be explicit that it is NOT RECOMMENDED for TLSv1.3 clients to > negotiate SSLv3 { 3, 0 } not to be conflated with the record layer lower > bound. https://tlswg.github.io/tls13-spec/#rfc.appendix.E.2 SSL negotiation total prohibition was committed earlier today. > * Believe ClientHello { 3, 0 } { 3, 4 } may be more guarded. {3,1} is current practice for some clients at the moment. General goal is to fix it to something static that works and makes sense. If we wish to avoid information leakage, the best value is whatever is already used commonly. > prefer it to the minimum supported > backwards compatible record layer version Agreed. It depends on if you consider SSL3 or TLS1 to be that minimum. > * { 3, 1 } can be regarded as the binary compatibility pivot point due > to its extension support. In that case I favor { 3, 1 } My reasoning as well. Either version number is acceptable. The "best" value could be empirically determined by surveying servers for which gets the least intolerance when attempting to negotiate 1.3. > 2.) "Negotiating with buggy servers" > > * Primary observation. This section is at odds with the consensus for > TLSv1.3 implementation to not negotiate anything lower than TLSv1.0 { 3, > 1 } with >= TLSv1.2. > * While the protocol lower bound may not be in scope for the TLSv1.3 > spec; the security concern for bugger servers should be; a small number > of buggy servers lead to clients with attack vectors > * Buggy servers should not be named or supported in a security protocol > draft. > > As an observer I would prefer to see this text changed from this: > > "and may require multiple connection attempts by the client." > > to something like this: > > "and may require multiple connection attempts by the client, however > it is NOT RECOMMENDED that clients make multiple connection attempts as > this provides a vector for downgrade attacks" That block of text is pre-existing, just moved. A NOT RECOMMENDED line sounds appropriate if nobody objects. Insecure fallback is being phased out by Mozilla, at least, and it was never really a good idea. Alternatively, I could just drop the whole paragraph/subsection. This set of changes are to attempt to address this concern better, so maybe they're sufficient without this buggy servers bit? Dave From nobody Thu Feb 12 22:53:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA551A1A79 for ; Thu, 12 Feb 2015 22:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_3Bkq5yaMdn for ; Thu, 12 Feb 2015 22:53:17 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63051A1A27 for ; Thu, 12 Feb 2015 22:53:16 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kq14so16961269pab.3 for ; Thu, 12 Feb 2015 22:53:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=l5Ro4ZFvA0qTP960JSubdfn87QHE5yIXVkVbdbG7Bng=; b=iHWd7We5MlTtux6z+yGLIQA2iNDH6z2wame3R8KVOaBP6U/++v79EdLSv8dr/4r0dT bHKpj4KzR45c/tAm94TeI/5vmTfO3LZzTp86CYusQteXzeClxa0HtUNXSOLY/M0x0eyd Br1OVywjLrk83l2QhJq+HdIDMceiPyTAfRzC6UQMzJJhS0rTQeQj/Q4BLzpCOwPCyfAj bHLBmpl/0zQ56jUh1iSsRTSH3BAOwLpOdm7Wu9c/snCaeUMxHv9hVk29WdkHBGJmaEiu fuihfUgcYNpxcTJcTd7qW8NECNTCGbMM0kOsZTg3oDvyxlolxYH1cgvgMtyf7TxU2x6T RBdg== X-Gm-Message-State: ALoCoQkDgTQS9825BDvfdc2euwgK5rlckE0uj+628j330dg0SJkPyessG78cYG+RQbBsRc6sEf7E X-Received: by 10.70.45.39 with SMTP id j7mr12512027pdm.169.1423810396603; Thu, 12 Feb 2015 22:53:16 -0800 (PST) Received: from [192.168.1.124] ([112.135.106.87]) by mx.google.com with ESMTPSA id o3sm5718757pdj.5.2015.02.12.22.53.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 22:53:15 -0800 (PST) Message-ID: <54DD9F56.5060601@azet.org> Date: Fri, 13 Feb 2015 07:53:10 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <201502121727.24768.davemgarrett@gmail.com> In-Reply-To: <201502121727.24768.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig53F2824F31183508502C1A15" Archived-At: Cc: Florian Weimer , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SSL 2 CLIENT-HELLO backwards compatibility compromise X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2015 06:53:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig53F2824F31183508502C1A15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Dave Garrett wrote: > Option #1) Ditch the format that has been deprecated for 20 years > v2 format MUST NOT be sent or accepted for any reason +1 Aaron --------------enig53F2824F31183508502C1A15 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU3Z9WAAoJEOTbZJL9ubXV5t0QANpq0r27eHmho3OSD1bPlBap xm40Wiw9pN9EmSRad1pdL8Rph6d1HTqAjcu6Dl+ED11FnqgsQL09pODprBgKJ5ay jPikedOX91uu4seb2umDgtQmddgyOYVL0kIF0tf0f028BQLeiVIN1HjdmSsNP4zm 11F5l3exS3+q7i3SMU9ZZkKWAkKsT8hehAlc2iSxXOKWx6A0PFvsuO3L12p/g3oL HnrWTIbba8AMgcpEZanYuqFXtcxAcgEzk3Xlq0lRyOo2sXgMruntcclN8HeKRVku +5EXiBIqoPtPRcBscryVI89LJ/NnipCIZUNhpKDD9EmAu1w7L+GlEkVVxLVUQh2H 8wB+x4SrfED654WeIYsKfd1dz8wEs+6xI29TbBMZ5Z6P/s00ZXAt2an/z4BdJ/E1 5dL4RHDvx146dsam4nrAdGdFhSQ7fdqGNJatGsANeQS/9c0BiF9OiKwdQ31ccOnR r6mb/YCM8iqQb7TOjAgBl6lpdrkZcZbFfoICIJZuD8wjuED0XJbKzQqrhH7MgsrS rsYK+qJcwI9bTCgJLDQLraT783vjcscMiigX5haAXdMrfenQki6jwSVYVN/No6Pf /buc1lkllXAcvAsd2Xq8hEfGuOSy8Fv6VXw4ATGeb9V9YSsm7bOO3jakm+PnlNCF ujN1OPk4owzo8CW83RWJ =hucJ -----END PGP SIGNATURE----- --------------enig53F2824F31183508502C1A15-- From nobody Thu Feb 12 23:48:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A081A1B72 for ; Thu, 12 Feb 2015 23:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaCk7YT9sLxj for ; Thu, 12 Feb 2015 23:48:49 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 167491A1B6E for ; Thu, 12 Feb 2015 23:48:48 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1D7mlAf017278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 13 Feb 2015 02:48:47 -0500 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1D7mitp031186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2015 02:48:46 -0500 Message-ID: <1423813724.2423.0.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Dave Garrett Date: Fri, 13 Feb 2015 08:48:44 +0100 In-Reply-To: <201502122228.02125.davemgarrett@gmail.com> References: <201412300503.03923.davemgarrett@gmail.com> <201502121714.54235.davemgarrett@gmail.com> <54DD6065.8000205@metaparadigm.com> <201502122228.02125.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.23 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] consensus on backwards compatibility changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2015 07:48:51 -0000 On Thu, 2015-02-12 at 22:28 -0500, Dave Garrett wrote: > On Thursday, February 12, 2015 09:24:37 pm Michael Clark wrote: > > * Spec can be explicit that it is NOT RECOMMENDED for TLSv1.3 clients to > > negotiate SSLv3 { 3, 0 } not to be conflated with the record layer lower > > bound. > > https://tlswg.github.io/tls13-spec/#rfc.appendix.E.2 > > SSL negotiation total prohibition was committed earlier today. > > > * Believe ClientHello { 3, 0 } { 3, 4 } may be more guarded. > > {3,1} is current practice for some clients at the moment. ^^^^ Well said. For some. That is, not all. regards, Nikos From nobody Fri Feb 13 01:58:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3431A6EE8 for ; Fri, 13 Feb 2015 01:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoRmO6NYmMis for ; Fri, 13 Feb 2015 01:58:09 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256301A3B9B for ; Fri, 13 Feb 2015 01:58:08 -0800 (PST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by david.siemens.de (8.14.3/8.14.3) with ESMTP id t1D9w72T028225; Fri, 13 Feb 2015 10:58:07 +0100 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail2.sbs.de (8.14.3/8.14.3) with ESMTP id t1D9w6uI001033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Feb 2015 10:58:06 +0100 Received: from DEFTHW99ERFMSX.ww902.siemens.net (139.22.70.67) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 13 Feb 2015 10:58:06 +0100 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.229]) by DEFTHW99ERFMSX.ww902.siemens.net ([139.22.70.67]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 10:58:05 +0100 From: "Fries, Steffen" To: "mrex@sap.com" , Jeremy Harris Thread-Topic: [TLS] OCSP Stapling in RFC 6066 Thread-Index: AQHQRvTzrFnZEWirmUqJHUTKVUgpb5zuUh8A Date: Fri, 13 Feb 2015 09:58:05 +0000 Message-ID: References: <54DC9533.7070101@wizmail.org> <20150212185123.81BA01B19A@ld9781.wdf.sap.corp> In-Reply-To: <20150212185123.81BA01B19A@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.44] 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] OCSP Stapling in RFC 6066 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2015 09:58:12 -0000 Martin, Jeremy, to be frank, I checked RC 6961 before but did not mention it in my initial = request. I did not see the option to also use the extension to transmit the= OCSP information for the client certificate. Hence the question regarding = applying the extension via the generic extensions mechanism.=20 I see Martins point with the order of information sent, as when applied to = the single TLS handshake, the client would have to know he has to authentic= ated using his certificate before getting the request from the server side = for client authentication. This would be probably not such a problem for th= e target environment as here mutual authentication is always required. But = for the generic approach your proposal using RFC 4680 looks promising, as i= n the second round the client could attach his OCSP responses to the Client= Hello. But as you said, it comes with the burden of a second run of the han= dshake.=20 There is some asymmetry, as the server basically sends his certificate and = also the OCSP response(s) in his ServerHello message, while the client send= s his certificate with the second handshake message, while extensions are d= efined for the ClientHello. But I would not see an easier way for now.=20 Steffen -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Donnerstag, 12. Februar 2015 19:51 To: Jeremy Harris Cc: tls@ietf.org Subject: Re: [TLS] OCSP Stapling in RFC 6066 Jeremy Harris wrote: > Fries, Steffen wrote: >> I've got a question to the OCSP stapling approach described in RFC=20 >> 6066 >=20 > Why not jump directly to an RFC 6961 analogue? Your observation is correct that the rfc6066 OCSP extension is limited to a= single OCSP response for the server certificate, whereas the TLS extension= defined in rfc6961 allows for multiple OCSP responses, including OCSP resp= onses for CA certificates in the certificate chain of the server. But there are a number of differences in the server and client authenticati= on that make these two TLS extensions (or their approach) a bad fit for cli= ent certificate authentication. For the server certificate, the Server's decision/choice for a specific ser= ver certificate happens (or at least can happen) while the server evaluates= the TLS protocol options proposed in ClientHello and composed the ServerHe= llo response _after_ making the selections of TLS protocol options. So whe= n the server composes the ServerHelloExtensions it knows which server certi= ficate it is going to use and can insert the respective OCSP responses into= ServerHello. The situation is substantially different for the client, who has to include= all TLS protocol options that are up for negotation upfront in ClientHello= (Extensions). At this point, the client does not know whether the server i= s going to request a client certificate at all, nor does the client know, w= hich list of trusted certification_authorities or which algorithms the serv= er supports and is going to select/request. So the approach for conveying OCSP responses for the client certificate fro= m the client to the server should probably be on the second batch of handsh= ake messages from client to server in a full TLS handshake, such as using a= "TLS Handshake Message for Supplemental Data" (rfc4680). I agree that the rfc4680 approach is more code to implement, but such an ap= proach would not break when the client has more than one client certificate= s or additional client certificates other than X.509. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Feb 13 02:44:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FD61A1BAA for ; Fri, 13 Feb 2015 02:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DryEp880YmCc for ; Fri, 13 Feb 2015 02:44:21 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 8D19E1A1B91 for ; Fri, 13 Feb 2015 02:44:20 -0800 (PST) Received: from [46.33.133.68] (helo=lap.dom.ain) from_AS 51561 by wizmail.org with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85_67-fb3c72e) id 1YMDjM-0004O4-Fc (return-path ); Fri, 13 Feb 2015 10:44:16 +0000 Message-ID: <54DDD57F.9080305@wizmail.org> Date: Fri, 13 Feb 2015 10:44:15 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Fries, Steffen" , "mrex@sap.com" References: <54DC9533.7070101@wizmail.org> <20150212185123.81BA01B19A@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] OCSP Stapling in RFC 6066 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2015 10:44:24 -0000 On 13/02/15 09:58, Fries, Steffen wrote: > to be frank, I checked RC 6961 before but did not mention it in my initial request. I did not see the option to also use the extension to transmit the OCSP information for the client certificate. Hence the question regarding applying the extension via the generic extensions mechanism. Indeed; it's just the support for status on the entire chain I'm suggesting, not the mechanism. -- Cheers, Jeremy From nobody Fri Feb 13 09:43:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403861A0046 for ; Fri, 13 Feb 2015 09:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-9cAwdR3dY8 for ; Fri, 13 Feb 2015 09:43:31 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35491A0018 for ; Fri, 13 Feb 2015 09:43:31 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id bm13so13514347qab.2 for ; Fri, 13 Feb 2015 09:43:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WRzaXti/SYSwYIF03m0L/4zoycjSLSqZf7ObMvQRSXE=; b=GISYpmIdxzIuxHPxRVLS35FR1xIxSY6HGcLfhOoZtmH2l2l6zfyUFxCR1GHq5QZNvx LlvmCyZcyP56upEmWga3exbusNoKajpRVfT0YnFe2rfd99dM3BNZz75jBcSpbbNa9rM9 JdxAoaHTuhijETY7Kn8eGwKZdTA65Ol6Fn/9y97fKyMORyKUvKJOI4Rj0DgfG58eeoZ3 wnAgdPGQ3GyZ/QfaKxOiyJqgErPNLWG4/YgmGQewKafb0nSwBDgy7QmXu4rTCYIQ1OB6 pLt8fzldS5sDEuNO+cVnNr8RpbaMbJZjlxa2iZaFfOLLxfTH27qnIuqd76X8z+TI5lCb PGcA== X-Gm-Message-State: ALoCoQnzyOVMM9DHwMndKR0ajjRtow4pz7bYHka7zrFd3i1OKmo2dH1G6HAEbO5mpSn5x/7pzJrV MIME-Version: 1.0 X-Received: by 10.140.82.234 with SMTP id h97mr24794889qgd.75.1423849410886; Fri, 13 Feb 2015 09:43:30 -0800 (PST) Received: by 10.96.238.73 with HTTP; Fri, 13 Feb 2015 09:43:30 -0800 (PST) X-Originating-IP: [50.206.82.141] In-Reply-To: References: Date: Fri, 13 Feb 2015 09:43:30 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c135d859a379050efbc658 Archived-At: Subject: Re: [TLS] TLS Interim attendance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2015 17:43:33 -0000 --001a11c135d859a379050efbc658 Content-Type: text/plain; charset=UTF-8 I've had a number of responses already, so if it is likely you will attend please let me know as soon as possible so I can have accurate numbers to make sure we have an appropriate space. Thanks, Joe On Thu, Feb 5, 2015 at 2:36 PM, Joseph Salowey wrote: > If you are planning to attend the interim meeting on 3/10 and 3/11 in > Seattle please send me an email so I can get an accurate count of > participants for planning. > > Thanks, > > Joe > --001a11c135d859a379050efbc658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've had a number of responses already, so if it is li= kely you will attend please let me know as soon as possible so I can have a= ccurate numbers to make sure we have an appropriate space.

Thanks,

Joe

On Thu, Feb 5, 2015 at 2:36 PM, Joseph Sa= lowey <joe@salowey.net> wrote:
If you are planning to attend the interim meeting on 3/= 10 and 3/11 in Seattle please send me an email so I can get an accurate cou= nt of participants for planning. =C2=A0

Thanks,

Joe

--001a11c135d859a379050efbc658-- From nobody Sat Feb 14 00:54:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0847F1A1B38 for ; Sat, 14 Feb 2015 00:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r_lItwEYSdX for ; Sat, 14 Feb 2015 00:54:32 -0800 (PST) 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 1B1391A1A68 for ; Sat, 14 Feb 2015 00:54:31 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 7A9CB2A935; Sat, 14 Feb 2015 09:54:29 +0100 (CET) X-purgate-ID: 152705::1423904069-0000765A-5F97AC1B/0/0 X-purgate-size: 2934 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 6F38043B2F; Sat, 14 Feb 2015 09:54:29 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 650061B1A6; Sat, 14 Feb 2015 09:54:29 +0100 (CET) In-Reply-To: To: Yuhong Bao Date: Sat, 14 Feb 2015 09:54:29 +0100 (CET) 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: <20150214085429.650061B1A6@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: [TLS] Downgrade Dance steps (Re: drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 08:54:37 -0000 Yuhong Bao wrote: > > Just confirmed that IE on Win7 even when misconfigured to enable > SSLv2 doesn't send a SSLv2 ClientHello with TLS 1.2 on it which > means that SChannel probably can't do it at all. Andrei Popov > should be able to confirm this. IIRC, Win7 shipped with TLSv1.2 *disabled*. I see the following downgrade dances with MSIE 10 on (a fully patched) 64-bit Win7sp1. What's a little weird about the MSIE downgrade dances: - duplicated attempts with certain Hellos in certain configurations - empty connection attempts when SSLv2 is disabled. The (dummy) server that I had MSIE connect to read the ClientHello from the network waited a second and then closed the network connection. -Martin everything enabled (SSLv2->TLSv1.2): TLS record (3,3) ClientHello.client_version(3,3) with TLS extensions SSL2 record ClientHello.client_version(3,1) SSL2 record ClientHello.client_version(3,0) SSL2 record ClientHello.client_version(0,2) SSLv2 plus default (SSLv3,TLSv1.0,TLSv1.1): SSL2 record ClientHello.client_version(3,2) SSL2 record ClientHello.client_version(3,1) SSL2 record ClientHello.client_version(3,0) SSL2 record ClientHello.client_version(0,2) SSLv2 plus TLSv1.0+TLSv1.1 (this looks weird!): SSL2 record ClientHello.client_version(3,2) SSL2 record ClientHello.client_version(3,1) SSL2 record ClientHello.client_version(0,2) SSL2 record ClientHello.client_version(0,2) For comparison the (hopefully more common scenarios): SSLv3->TLSv1.2: TLS record (3,3) ClientHello.client_version(3,3) with TLS extensions TLS record (3,1) ClientHello.client_version(3,1) with TLS extensions SSL3 record (3,0) ClientHello.client_version(3,0) TCP-connect + TCP-close TLSv1.0+TLSv1.1+TLSv1.2 TLS record (3,3) ClientHello.client_version(3,3) with TLS extensions TLS record (3,1) ClientHello.client_version(3,1) with TLS extensions TCP-connect + TCP-close And finally the more esoteric configurations: TLSv1.1+TLSv1.2 TLS record (3,3) ClientHello.client_version(3,3) with TLS extensions TCP-connect + TCP-close TLSv1.2 alone TLS record (3,3) ClientHello.client_version(3,3) with TLS extensions TCP-connect + TCP-close SSLv3+TLSv1.2 TLS record (3,3) ClientHello.client_version(3,3) with TLS extensions SSL3 record (3,0) ClientHello.client_version(3,0) SSL3 record (3,0) ClientHello.client_version(3,0) TCP-connect + TCP-close TLSv1.0+TLSv1.2 TLS record (3,3) ClientHello.client_version(3,3) with TLS extensions TLS record (3,1) ClientHello.client_version(3,1) TCP-connect + TCP-close SSLv2+TLSv1.2 TLS record (3,3) ClientHello.client_version(3,3) with TLS extensions SSL2 record ClientHello.client_version(0,2) SSL2 record ClientHello.client_version(0,2) SSL2 record ClientHello.client_version(0,2) From nobody Sat Feb 14 09:04:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836611A6FE6 for ; Sat, 14 Feb 2015 09:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61g9uoHz0OQY for ; Sat, 14 Feb 2015 09:04:37 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 9097A1A6FBB for ; Sat, 14 Feb 2015 09:04:37 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id j5so17855573qga.3 for ; Sat, 14 Feb 2015 09:04:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=yaBsMJN5tYNNsciJviaOlPHJyVVcbpAI6E4RTcRBNL8=; b=q/dOQnMAAy8COkQefyoE9YIJBCBPmp0l82RQeGvVLADfStdn0OIprPQz7GH54RbO7b z4cq/Iz4L5IFZhyAcWR2JtVyPW4vTVHszr03kI1LJ2Kid6t16/LADfAlmwv2nsKLt7ii RUiXjNxYdV1r+nUDZIDrb8NefKxnENB310aPl+c/cKhBjBt7rftBqtJsLXt8nN5sYJiX tw2pJm9DPIkq2onIhC1elBM1A13iPACRfMiPBDo5tfukaB646onR0QV6CDyVa0FJQLTs mJf2/kDOQEogAgD4SXRD2TVIPdRKAL37B3T46mORZrNLe9f4L2ZRXd5TolT/C6xxFSxu aYwQ== X-Received: by 10.140.237.6 with SMTP id i6mr8984410qhc.32.1423933476777; Sat, 14 Feb 2015 09:04:36 -0800 (PST) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 7sm1636450qhv.8.2015.02.14.09.04.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 14 Feb 2015 09:04:36 -0800 (PST) From: Dave Garrett To: tls@ietf.org, mrex@sap.com Date: Sat, 14 Feb 2015 12:04:34 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <20150214085429.650061B1A6@ld9781.wdf.sap.corp> In-Reply-To: <20150214085429.650061B1A6@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201502141204.35289.davemgarrett@gmail.com> Archived-At: Cc: Florian Weimer Subject: Re: [TLS] Downgrade Dance steps (Re: drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Feb 2015 17:04:39 -0000 On Saturday, February 14, 2015 03:54:29 am Martin Rex wrote: > What's a little weird about the MSIE downgrade dances: > - duplicated attempts with certain Hellos in certain configurations > - empty connection attempts when SSLv2 is disabled. [...] > everything enabled (SSLv2->TLSv1.2): [...] > SSLv2 plus default (SSLv3,TLSv1.0,TLSv1.1): [...] > SSLv2 plus TLSv1.0+TLSv1.1 (this looks weird!): [...] > SSLv3->TLSv1.2: [...] > TLSv1.0+TLSv1.1+TLSv1.2 [...] > TLSv1.1+TLSv1.2 [...] > TLSv1.2 alone [...] > SSLv3+TLSv1.2 [...] > TLSv1.0+TLSv1.2 [...] > SSLv2+TLSv1.2 Are there any other clients that allow fine-grained enabling/disabling of each version? Firefox and Chrome set min/max. Safari is incompetent and provides no configuration. IE is the only one that seems to allow this wide list of configurations, and the resulting oddities. I'm curious what non-browser clients do here commonly. Dave From nobody Sat Feb 14 11:23:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE3D1A01E7 for ; Sat, 14 Feb 2015 11:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC-jdzO0aFVc for ; Sat, 14 Feb 2015 11:23:34 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::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 97EEE1A0191 for ; Sat, 14 Feb 2015 11:23:31 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id a41so11004362yho.4 for ; Sat, 14 Feb 2015 11:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/Lql4o3H/HcLFd5aysXGPcaiWyImfL/mYTzUPOfqafY=; b=Q7i95e9Q9NCK64W69rysY+jAXkC5bDhsFb9L+MkQgXX9lS4yRUsunL6UfXKFm3X1gj EeslFONmQuAnQdHsKXx0/nrsDIq40RaaN2UhkDqJlPvRFCYjMKOzEfDeHVmuDnteSSbu wL46ZYtNci5YjcKlyglGQUmrqo0bSyhnMOLdqIcLVIwck1GcbtH52xI1APGrrj3akQLx 252C2ITrqoMPn8wfQRjCai/QMBRh/eDhXybG7nt0hKSlAhDjzH7tLEzVPo2lT+TGJFlG oFiB+mmyGXywGRK0hdkaeOYJvHsjwOBeFw3LkKhxNZ60T8fA4BXHAAH0XeTZAHNsWj/b JL2g== MIME-Version: 1.0 X-Received: by 10.236.220.65 with SMTP id n61mr12583378yhp.44.1423941810876; Sat, 14 Feb 2015 11:23:30 -0800 (PST) Received: by 10.170.126.10 with HTTP; Sat, 14 Feb 2015 11:23:30 -0800 (PST) Date: Sat, 14 Feb 2015 11:23:30 -0800 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Thoughts on Hardware Support X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 19:23:37 -0000 Dear all, A while ago I promised Michael St. Johns to think hard about his goal of making it possible to use hardware to secure the record layer without dirty hacks. For those unaware of the problem, the same key is used to derive encryption keys that shouldn't go out on the wire, and IVs that do, and so it becomes difficult to ensure that keys can't be leaked, if you expose the IV generation. I think the easiest way is to eliminate the IV derivation entirely, and have the record layer send the entire nonce each time. if that's too much a waste of bandwidth, then we can specify entirely the portion that is in TLS 1.2 derived from the MS. I think this is in spirit similar to his proposal, but I don't recall the exact details. I'm sure there are disadvantages of this change I am missing, or aspects of the problem that I'm neglecting, but I seem to recall this being the major issue. Sincerely, Watson Ladd From nobody Sat Feb 14 12:24:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA2F1A003A for ; Sat, 14 Feb 2015 12:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McmesaXx8u0p for ; Sat, 14 Feb 2015 12:24:45 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8751A001B for ; Sat, 14 Feb 2015 12:24:45 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id n8so17136548qaq.3 for ; Sat, 14 Feb 2015 12:24:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZoRRPhggYG1/jof31NNj3qy4V8Mq1Z5Kxpcxx87uB4M=; b=E3Q1dSSj+ZfkagR6/ETRqSrTF56geDwYwJKlzQXbV+iCYAWDMkZOGgjqkO4gNXaCqj G7K/u8Tg/AQIwE5w7m0RbLJrYjKXyVAKgINUU5kBA6AP3azZQPapOSYVMT/+rqcF0blI ywQY3nATzbHYSYMj61E4vWpFbNtmN0Uja87J4NLv1ChphJiSiJcMFNYRMP5m+wlsL4LM VoMu51wUIrCadY8EYGHoCeF9S4UxjFVNrLlHrMv++r7D3wAHWWUY+3U2O1X6aByRNyt4 hsgKHOcVtxu9oq8A5PW/ozePXLrElgODVoxU+tOiOMoH6R1Ka/Qk773uPQHKTgfSlMbn 0T8w== X-Gm-Message-State: ALoCoQlIvd+u578qH71Z+1wdpM81C7wQijS5EYunBSudaBs+H7CsP/p44ZsNovff80MIODl6UGc+ X-Received: by 10.140.133.21 with SMTP id 21mr10757308qhf.10.1423945484679; Sat, 14 Feb 2015 12:24:44 -0800 (PST) Received: from [192.168.1.103] (c-69-255-115-150.hsd1.md.comcast.net. [69.255.115.150]) by mx.google.com with ESMTPSA id e13sm10158726qaw.8.2015.02.14.12.24.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Feb 2015 12:24:44 -0800 (PST) Message-ID: <54DFAF19.5060501@nthpermutation.com> Date: Sat, 14 Feb 2015 15:24:57 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Thoughts on Hardware Support X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 20:24:48 -0000 On 2/14/2015 2:23 PM, Watson Ladd wrote: > I think the easiest way is to eliminate the IV derivation entirely, > and have the record layer send the entire nonce each time. if that's > too much a waste of bandwidth, then we can specify entirely the > portion that is in TLS 1.2 derived from the MS. I think this is in > spirit similar to his proposal, but I don't recall the exact details. The other way of doing this is to not make IV derivation dependent on secret material. Basically, I suggested that instead to use the same KDF function, but with a key of zero and a context of the server and client randoms. That makes IV (or for most AEAD counter based thingies - nonce) derivation a straightforward entropy extraction from the two generated random numbers. Alternately, use output of the hash of those two concatenated values plus a counter (so you can get more than 1 block of extracted data) plus a label (so you can use the same randoms for different expansions if you need to). E.g. IVDATA = {}; label = { }; numblocks = CEIL (numBytesNeeded/hashOutputSize); for (i = 1; i < numblocks; i++) { IVDATA = IVDATA || HASH (counter(as uint32 big endian) || label || serverRandom || clientRandom); } return LTRUNC(IVDATA, numBytesNeeded); This uses all public data and functions to produce public data (the IV or Nonce). I apologize as I haven't had the cycles to do a pull request and add the crypto constructs changes I'm proposing. Mike From nobody Sat Feb 14 15:07:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6757F1A0364 for ; Sat, 14 Feb 2015 15:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3qN06LxymUT for ; Sat, 14 Feb 2015 15:07:24 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7409B1A03FF for ; Sat, 14 Feb 2015 15:07:18 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id q107so18554594qgd.6 for ; Sat, 14 Feb 2015 15:07:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PoMTqG+jrQnmywIg6JODZDsbcliQgOgwJhfB2KBE/60=; b=fz7tXu+jgQo4C5ASRsbQbTMdB/29cSKb3qW4mmRTx8OG+8W+sBhVBMykgu0kV3XCiK PSNMWHv02u/3yMGSnq5VDT5gvjN/fXmXuZga9rxp6Ebt1rpfQUs6vgtwJ1WDUze1ERmy BVuXGbUxE80DthmYTlYnD9r1OyZTH493mR/drxw1y90aYLZmZYry7Q/ve5AzFySawFm1 cX/Oh0yF5bka9q962pg61vf13eO4/g4RyWg9SVaU5yrXmoiqothkdow/zUKx/uMbMmWM jSYVJ7BWdMZ+yEU8f+5QZ1a6dUZUbUGe2Xzjb/gM2pO8geALCKJawqbC+al2f/8SrLE6 fZXw== X-Gm-Message-State: ALoCoQn1T/Pxo5ANkTNgvsvl4qDyRSNMdA9gte4iRASBi5jyMPbZhU56rDHkbKK1GNF7Neg3q2fm X-Received: by 10.140.202.141 with SMTP id x135mr11774384qha.96.1423955237622; Sat, 14 Feb 2015 15:07:17 -0800 (PST) Received: from [192.168.1.105] (c-69-255-115-150.hsd1.md.comcast.net. [69.255.115.150]) by mx.google.com with ESMTPSA id d3sm10422911qaf.13.2015.02.14.15.07.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Feb 2015 15:07:17 -0800 (PST) Message-ID: <54DFD532.5070900@nthpermutation.com> Date: Sat, 14 Feb 2015 18:07:30 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tls@ietf.org References: <54DFAF19.5060501@nthpermutation.com> In-Reply-To: <54DFAF19.5060501@nthpermutation.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Thoughts on Hardware Support X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 23:07:29 -0000 A private message indicated that it might be useful if I clarified my thoughts below. The problem is the embedded use of the term "IV" in the TLS documents. The master_secret expansion (section 6.3 of rfc5246) still refers to the last part of the data generated as IVs - but TLS1.2 eliminated the use of these as actual IVs (plus implicit generation of per-message IVs) for the existing non-AEAD, non-counter modes in favor of explicit per-message randomly generated IVs. The AEAD ciphersuite documents resurrected the use of the iv data from the master secret expansion for use as the per-key (identical for all TLS messages in a session) nonce. pure IVs (mostly - check the specific mode) require unpredictability. Nonces (at least for defined modes) only require uniqueness on a per-key basis. Where the mode needs per-message IV unpredictablity, follow section 6.2.3.2 of the TLS1.2 RFC. Where you need to establish a common unique nonce, use an entropy expansion/extraction from client/server random without dependency on key material. There shouldn't be any middle cases. Mike On 2/14/2015 3:24 PM, Michael StJohns wrote: > On 2/14/2015 2:23 PM, Watson Ladd wrote: >> I think the easiest way is to eliminate the IV derivation entirely, >> and have the record layer send the entire nonce each time. if that's >> too much a waste of bandwidth, then we can specify entirely the >> portion that is in TLS 1.2 derived from the MS. I think this is in >> spirit similar to his proposal, but I don't recall the exact details. > > The other way of doing this is to not make IV derivation dependent on > secret material. Basically, I suggested that instead to use the same > KDF function, but with a key of zero and a context of the server and > client randoms. That makes IV (or for most AEAD counter based > thingies - nonce) derivation a straightforward entropy extraction from > the two generated random numbers. Alternately, use output of the hash > of those two concatenated values plus a counter (so you can get more > than 1 block of extracted data) plus a label (so you can use the same > randoms for different expansions if you need to). > > > E.g. > > > IVDATA = {}; > label = { }; > numblocks = CEIL (numBytesNeeded/hashOutputSize); > > for (i = 1; i < numblocks; i++) { > IVDATA = IVDATA || HASH (counter(as uint32 big endian) || label || > serverRandom || clientRandom); > } > > return LTRUNC(IVDATA, numBytesNeeded); > > > This uses all public data and functions to produce public data (the IV > or Nonce). > > > I apologize as I haven't had the cycles to do a pull request and add > the crypto constructs changes I'm proposing. > > Mike > > > From nobody Sat Feb 14 22:54:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65531A047A for ; Sat, 14 Feb 2015 22:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un-9VHY5rfbn for ; Sat, 14 Feb 2015 22:54:26 -0800 (PST) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEBA1A0318 for ; Sat, 14 Feb 2015 22:54:26 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id F0EF51A261D; Sun, 15 Feb 2015 08:54:22 +0200 (EET) Date: Sun, 15 Feb 2015 08:54:22 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20150215065422.GA5364@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Thoughts on Hardware Support X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 06:54:29 -0000 On Sat, Feb 14, 2015 at 11:23:30AM -0800, Watson Ladd wrote: > Dear all, > > A while ago I promised Michael St. Johns to think hard about his goal > of making it possible to use hardware to secure the record layer > without dirty hacks. For those unaware of the problem, the same key is > used to derive encryption keys that shouldn't go out on the wire, and > IVs that do, and so it becomes difficult to ensure that keys can't be > leaked, if you expose the IV generation. IVs derived from keys do not go on the wire, at least not in any AEAD cipher defined for TLS I have seen. The schemes I am aware have two styles here: 1) First 4 octets are fixed per connection (derived from MS), the remaining 8 are given for each record (too short for nondeteministic operation!). 2) First 4 octets are fixed per connection (derived from MS), the remaining 8 are taken from RSN+epoch (saves 8 octets/record). IIRC, the problem was that by specifying garbage parameters for key derivation, it was possible to get the key as IV. > I think the easiest way is to eliminate the IV derivation entirely, > and have the record layer send the entire nonce each time. if that's > too much a waste of bandwidth, then we can specify entirely the > portion that is in TLS 1.2 derived from the MS. I think this is in > spirit similar to his proposal, but I don't recall the exact details. I think his proposal was to feed the key derivation parameters (complete with key types) to the PRF (and doing odd things with the IV). But if one has typed keys, one can easily define a IV type and use that for IVs (safe if the PRF is any good). So I think the simplest fix would be to append a array of (type, length) descriptors to the current client and server randoms in seed for the subkeys PRF invocation (no need for length of array). E.g. AEAD key, 1=>IV, others reserved> For AES-128-GCM: //As currently //As currently 00 10 //AEAD encryption subkey, 16 bytes. 00 10 //AEAD encryption subkey, 16 bytes. 01 04 //IV, 4 bytes. 01 04 //IV, 4 bytes. (Total of 72 bytes). For AES-256-GCM and CHACHA-POLY1305: //As currently //As currently 00 20 //AEAD encryption subkey, 32 bytes. 00 20 //AEAD encryption subkey, 32 bytes. 01 04 //IV, 4 bytes. 01 04 //IV, 4 bytes. (Total of 72 bytes). For XXX-1024-HMAC-YYY256 (128 byte keys, 32 byte IVs): //As currently //As currently 00 80 01 //AEAD encryption subkey, 128 bytes. 00 80 01 //AEAD encryption subkey, 128 bytes. 01 20 //IV, 32 bytes. 01 20 //IV, 32 bytes. (Total of 74 bytes). -Ilari From nobody Tue Feb 17 00:46:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0661A0398 for ; Tue, 17 Feb 2015 00:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcICKlhoqnYq for ; Tue, 17 Feb 2015 00:46:16 -0800 (PST) Received: from BLU004-OMC2S25.hotmail.com (blu004-omc2s25.hotmail.com [65.55.111.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD2D1A0366 for ; Tue, 17 Feb 2015 00:46:16 -0800 (PST) Received: from BLU177-W24 ([65.55.111.71]) by BLU004-OMC2S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 17 Feb 2015 00:45:33 -0800 X-TMN: [a6740mpQHnT81L2+tCQTdilM/TlL1io/] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Florian Weimer , "tls@ietf.org" Date: Tue, 17 Feb 2015 00:45:32 -0800 Importance: Normal In-Reply-To: <54DB5670.8070009@redhat.com> References: <201412221945.35644.davemgarrett@gmail.com>, , <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com>,<54DB5670.8070009@redhat.com> Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Feb 2015 08:45:33.0124 (UTC) FILETIME=[1758A040:01D04A8E] Archived-At: Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Feb 2015 08:46:18 -0000 =0A= > Date: Wed=2C 11 Feb 2015 14:17:36 +0100=0A= > From: fweimer@redhat.com=0A= > To: tls@ietf.org=0A= > Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1= .3 draft=0A= >=0A= > On 12/27/2014 11:39 PM=2C Dave Garrett wrote:=0A= >> On Saturday=2C December 27=2C 2014 05:07:12 pm Hauke Mehrtens wrote:=0A= >>> On 12/24/2014 07:40 AM=2C Yoav Nir wrote:=0A= >>>> It=92s fine for us to break compatibility with these clients=2C but le= t=92s not=0A= >>>> pretend it=92s some ancient technology that doesn=92t exist in the mar= ket=0A= >>>> anymore.=0A= >>>=0A= >>> In addition the Oracle Java Runtime Environment in Version 6 uses a SSL= =0A= >>> v2 compatible ClientHello in the default settings. It supports SSL v3= =0A= >>> and TLS 1.0. In Java JRE 7 a SSLv3 ClientHello is used by default.=0A= >>>=0A= >>> I think a TLS 1.3 Client must not send a SSLv2 ClientHello=2C but a ser= ver=0A= >>> should understand it.=0A= >>=0A= >> The newest version of TLS should not be have to be written to accommodat= e an 8=0A= >> year old EOL Java version's default settings.=0A= >=0A= > I could reproduce the behavior with OpenJDK 6 which is still supported:= =0A= >=0A= > https://bugzilla.redhat.com/show_bug.cgi?id=3D880223=0A= >=0A= > Because it's not EOL=2C we can still fix the defaults=2C although this ma= y=0A= > not be what some users expect or need.=0A= =0A= Even Oracle's latest paid support version of Java 5 and Java 6 have now dis= abled SSLv2Hello:=0A= http://www.oracle.com/us/technologies/java/overview-156328.html=0A= http://www.oracle.com/technetwork/articles/javase/overview-137139.html = = From nobody Tue Feb 17 13:41:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BB61A90DE for ; Tue, 17 Feb 2015 13:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDn2ZacRrXHr for ; Tue, 17 Feb 2015 13:40:59 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 264821A90F6 for ; Tue, 17 Feb 2015 13:40:12 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id l2so38656180wgh.9 for ; Tue, 17 Feb 2015 13:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=AyJxW6eAKuMIj+t1C5S/jpB3ZvB2p3INSKsNO31PNTE=; b=u8Q+FgWHCUj3Hk4LRI3UKQumfZV5SZBy9IhzV8xq3u1+U85dBzm4D74rp2vySze4a5 +jNvIJpEV3r8bJHGcsDRsz8dsSWKfGUqkYnAeLcqGrXZgGb95BiBZ5IwQVaCI62D01DM 6okv6xbXwEZ78aN7Jb6PDAPINVBTfg+CMokbOtd4w2ePMVMkg1TVewl5WgGpnahOWeYD A2I0ZthffhRJrScu/M3hbW7Tf0IriANdxQDSEJfGL8wggmxx4Av84nniwOSTpsm2QW0h wOGI6FKiqpPKOJd0Sj1vwwiylkuO/NPpxmdRkYi8F26+llsQbYkMoCRpepDB6bDHvoMU Tp3w== X-Received: by 10.194.110.233 with SMTP id id9mr66369997wjb.136.1424209210930; Tue, 17 Feb 2015 13:40:10 -0800 (PST) Received: from [192.168.1.15] ([46.120.13.132]) by mx.google.com with ESMTPSA id fd10sm25994620wib.4.2015.02.17.13.40.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 13:40:10 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_4E02107E-FAD7-4CCE-965D-A88BF3A94315" Message-Id: Date: Tue, 17 Feb 2015 23:40:07 +0200 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [TLS] RFC4492bis - pull request #5 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Feb 2015 21:41:04 -0000 --Apple-Mail=_4E02107E-FAD7-4CCE-965D-A88BF3A94315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 https://github.com/tlswg/rfc4492bis/pull/5 = Hi. I=E2=80=99ve created this pull request. The changes are here: = https://github.com/tlswg/rfc4492bis/pull/5/files = Basically, the text in RFC 4492 anticipates a standardization of a = certificate field that will tell us which hash function to use in a = digital signature. Since that never happened pre-TLS1.2 implementations = use SHA-1, while TLS 1.2 has added algorithm identifiers to the = signature structure. The change reflects this. Let me know what you think. Yoav --Apple-Mail=_4E02107E-FAD7-4CCE-965D-A88BF3A94315 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 https://github.com/tlswg/rfc4492bis/pull/5

Hi.

I=E2=80=99ve created = this pull request.  The changes are here: https://github.com/tlswg/rfc4492bis/pull/5/files

Basically, the text in = RFC 4492 anticipates a standardization of a certificate field that will = tell us which hash function to use in a digital signature. Since that = never happened pre-TLS1.2 implementations use SHA-1, while TLS 1.2 has = added algorithm identifiers to the signature structure. The change = reflects this.

Let me know what you think.

Yoav

= --Apple-Mail=_4E02107E-FAD7-4CCE-965D-A88BF3A94315-- From nobody Tue Feb 17 14:25:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A579E1A88CE for ; Tue, 17 Feb 2015 14:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBOynjFI2o3s for ; Tue, 17 Feb 2015 14:25:44 -0800 (PST) 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 4D5BA1A88CF for ; Tue, 17 Feb 2015 14:25:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0E4C7BF08 for ; Tue, 17 Feb 2015 22:25:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJTpwuphzGHQ for ; Tue, 17 Feb 2015 22:25:41 +0000 (GMT) Received: from [172.16.20.132] (unknown [216.127.117.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7425ABEFB for ; Tue, 17 Feb 2015 22:25:41 +0000 (GMT) Message-ID: <54E3BFE3.5080204@cs.tcd.ie> Date: Tue, 17 Feb 2015 22:25:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Feb 2015 22:25:46 -0000 Hiya, In going over the threads on this I think there was one point of Martin's where it wasn't clear to me that the WG considered his proposal. That might be because it was raised just before the holidays and was part of a mega-thread and fairly deeply embedded in a longer message. Anyway, I asked Martin if he could describe it better and he did (see below) so I'd like to just check that the WG don't in fact want this. If you do not want to make this change, silence if fine, but if you would implement this in your TLS stack then please say so in the next few days. (Pretty please: let's not side-track - I'm really only looking for "yes, I'd implement that in my TLS code" responses, or silence:-) I figure it's not likely that the WG will want this, but if there's a groundswell for doing it, we can handle the process stuff, so don't worry about that. Thanks, S. What I've been asking for time and time again is allowing (adding) an additional/alternative server behaviour, which a TLS (server) implementer will be _allowed_ to implement instead of a fatal handshake failure. The most simplistic alternative server behaviour would be for the server to continue the handshake successfully, using ServerHello.server_version = (ClientHello.client_version + 1) i.e. negotiating a _higher_ TLS version instead of aborting the TLS handshake with a fatal error. A client (and this affects only the clients that assert the FALLBACK_SCSV) will be able to recognize that the server supports a higher TLS protocol version than what the TLS client proposed in ClientHello.client_version, and it will be left to that client to decide whether the resulting TLS session properties are OK, or wether the client want to take chances, establishing a new connection, starting a new handshake and proposing other/additional TLS protocol features in ClientHello that it might have omitted (for whatever reason) in the last ClientHello. This alternative behaviour is better, because it provides actual *interoperability* between TLS client and TLS server -- and in many cases the same or reasonably secure TLS session properties without the need for complex heuristics and a whole new connection establishment and handshake through the entire application protocol stack (such as HTTP CONNECT proxy traversals or the stuff before STARTTLS). Keep in mind that I'm NOT asking to make early adopter servers(!) non-compliant. Admittedly, I don't know what exactly the early adopting clients will currently do when they receive ServerHello.server_version = (ClientHello.client_version + 1) From nobody Tue Feb 17 14:35:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530731A88CF for ; Tue, 17 Feb 2015 14:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppmXDi6whbdT for ; Tue, 17 Feb 2015 14:35:34 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 1F57C1A1B3A for ; Tue, 17 Feb 2015 14:35:34 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wp4so58828982obc.0 for ; Tue, 17 Feb 2015 14:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HIUXiQWuq3wEz0FRWyomF21i9LFy11HqBTNEBBOcvcI=; b=gw89eB/T+vzw1TLkdcdBGzClo4JYu8HvrZdKtVOzU9UiBaTYR8DjEKZYWzJ9ZQ9f9X tng03L1cZ0y7Knmisp+N13tRCNrz8oe85iZyZIn0vbHX43zunImG19y8aMsw9NkopMSS ifGCefuEeggU7+mkaQKsU4eTSSjXkXOFWLLsgs5v+JnnpSWwp45fDVA6deBbZwbbj6+v 0B/h/rgBsbAj5++KZn5IwEVXKKD43hzcvPSNJTv9BalTtPQgAfw9U4SGft/zr7i8B9be 54ZIWgnD/Iq8Z9tOq6wtXpSIm6n/jkz9vNih/5CB9pE2hKZ/rKjf2Cgpo4bjKh+nX0sD j/ww== MIME-Version: 1.0 X-Received: by 10.182.60.197 with SMTP id j5mr19949690obr.85.1424212533387; Tue, 17 Feb 2015 14:35:33 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 17 Feb 2015 14:35:33 -0800 (PST) In-Reply-To: <54E3BFE3.5080204@cs.tcd.ie> References: <54E3BFE3.5080204@cs.tcd.ie> Date: Wed, 18 Feb 2015 09:35:33 +1100 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Feb 2015 22:35:36 -0000 FWIW, I just checked and an NSS client would fail the handshake if a server did this. We'd probably need new configuration to avoid the "upgrade attack" if this were permitted. On 18 February 2015 at 09:25, Stephen Farrell wrote: > > Hiya, > > In going over the threads on this I think there was one point of > Martin's where it wasn't clear to me that the WG considered his > proposal. That might be because it was raised just before the > holidays and was part of a mega-thread and fairly deeply embedded > in a longer message. Anyway, I asked Martin if he could describe > it better and he did (see below) so I'd like to just check that > the WG don't in fact want this. > > If you do not want to make this change, silence if fine, but if > you would implement this in your TLS stack then please say so in > the next few days. (Pretty please: let's not side-track - I'm > really only looking for "yes, I'd implement that in my TLS > code" responses, or silence:-) > > I figure it's not likely that the WG will want this, but if > there's a groundswell for doing it, we can handle the process > stuff, so don't worry about that. > > Thanks, > S. > > What I've been asking for time and time again is allowing (adding) > an additional/alternative server behaviour, which a TLS (server) > implementer will be _allowed_ to implement instead of a fatal > handshake failure. > > The most simplistic alternative server behaviour would be for > the server to continue the handshake successfully, using > > ServerHello.server_version = (ClientHello.client_version + 1) > > i.e. negotiating a _higher_ TLS version instead of aborting the > TLS handshake with a fatal error. > > A client (and this affects only the clients that assert the > FALLBACK_SCSV) will be able to recognize that the server supports a > higher TLS protocol version than what the TLS client proposed in > ClientHello.client_version, and it will be left to that client to > decide whether the resulting TLS session properties are OK, or wether > the client want to take chances, establishing a new connection, > starting a new handshake and proposing other/additional TLS protocol > features in ClientHello that it might have omitted (for whatever > reason) in the last ClientHello. > > This alternative behaviour is better, because it provides actual > *interoperability* between TLS client and TLS server -- and in many > cases the same or reasonably secure TLS session properties without > the need for complex heuristics and a whole new connection establishment > and handshake through the entire application protocol stack > (such as HTTP CONNECT proxy traversals or the stuff before STARTTLS). > > Keep in mind that I'm NOT asking to make early adopter servers(!) > non-compliant. Admittedly, I don't know what exactly the early > adopting clients will currently do when they receive > > ServerHello.server_version = (ClientHello.client_version + 1) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 17 15:10:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403641A8862 for ; Tue, 17 Feb 2015 15:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp9zyILCze5C for ; Tue, 17 Feb 2015 15:10:49 -0800 (PST) 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 16B8D1A1AB5 for ; Tue, 17 Feb 2015 15:10:48 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 75EF84472C; Wed, 18 Feb 2015 00:10:46 +0100 (CET) X-purgate-ID: 152705::1424214646-00002D1E-686F7CEC/0/0 X-purgate-size: 1028 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 5B65642F03; Wed, 18 Feb 2015 00:10:46 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 517061B1B1; Wed, 18 Feb 2015 00:10:46 +0100 (CET) In-Reply-To: To: Martin Thomson Date: Wed, 18 Feb 2015 00:10:46 +0100 (CET) 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: <20150217231046.517061B1B1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 23:10:51 -0000 Martin Thomson wrote: > > FWIW, I just checked and an NSS client would fail the handshake if a > server did this. We'd probably need new configuration to avoid the > "upgrade attack" if this were permitted. This NSS behaviour is not necessarily a problem. The more "interesting" question is what the app callers above NSS, that have asked NSS to include FALLBACK_SCSV, will do in response to that behaviour of NSS, or more specifically, will they do the same that they would do in response of a fatal invalid_downgrade alert. But that is a question for the apps on top rather than for NSS. Ultimately, of course, I would prefer for a TLS client implementation that asserts FALLBACK_SCSV, to not fail if the ServerHello comes back with ServerHello.server_version = (ClientHello.client_version) because the semantics of FALLBACK_SCSV clearly is "I do support protocol version (ClientHello.client_version+1) and I really would prefer to use that instead of ClientHello.client_version." -Martin From nobody Tue Feb 17 15:19:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5201A90F3 for ; Tue, 17 Feb 2015 15:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 962jOruTg9GJ for ; Tue, 17 Feb 2015 15:19:39 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698E01A8A55 for ; Tue, 17 Feb 2015 15:19:39 -0800 (PST) Received: by labpv20 with SMTP id pv20so38656408lab.8 for ; Tue, 17 Feb 2015 15:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ue5Jgim5rreUlk7HKofOZeQmnxoVioli+vFhUfJLQHY=; b=IRSsvSAy5NUED4Jfc6Gzb/3pk6QmE2K0qmMNRLmcBl782+8Cjre09cmjBCnio3ByrJ 5y7ZqTs5LUZd930A77SSPq5R5QpIU4Y/w37+MKmIIQEEeBMvgQQTgUPV+L3IlzyWhPuW lHKlMcUiQCVrUOBfbUfWtVGt3CrWRI+f1V14erx/b02dmQ8RGa2C0oheL0THtvhrCUnT iEWkRbF72UIMnlMyHbx3tNXejs5/U0r27reVlUdTpRYyr53ZXLjWmM0u5Ly3+vMhEVEb gsh9+j57r5c9JO5YCWsLnXCskcppEDapweSJzlsV4Hp5jGOX3V3cpH7CgCJksenWy+KC Eb/w== MIME-Version: 1.0 X-Received: by 10.112.39.69 with SMTP id n5mr28510740lbk.1.1424215177988; Tue, 17 Feb 2015 15:19:37 -0800 (PST) Received: by 10.112.241.69 with HTTP; Tue, 17 Feb 2015 15:19:37 -0800 (PST) In-Reply-To: <54E3BFE3.5080204@cs.tcd.ie> References: <54E3BFE3.5080204@cs.tcd.ie> Date: Wed, 18 Feb 2015 00:19:37 +0100 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Feb 2015 23:19:41 -0000 On Tue, Feb 17, 2015 at 11:25 PM, Stephen Farrell wrote: [...] > A client (and this affects only the clients that assert the > FALLBACK_SCSV) will be able to recognize that the server supports a > higher TLS protocol version than what the TLS client proposed in > ClientHello.client_version, and it will be left to that client to > decide whether the resulting TLS session properties are OK, or wether > the client want to take chances, establishing a new connection, > starting a new handshake and proposing other/additional TLS protocol > features in ClientHello that it might have omitted (for whatever > reason) in the last ClientHello. > > This alternative behaviour is better, because it provides actual > *interoperability* between TLS client and TLS server -- and in many > cases the same or reasonably secure TLS session properties without > the need for complex heuristics and a whole new connection establishment > and handshake through the entire application protocol stack > (such as HTTP CONNECT proxy traversals or the stuff before STARTTLS). I consider breaking the obviously broken intervening proxy a feature, as it obviously is broken enough that plain recent TLS doesn't work with it (as otherwise the downgrade wouldn't have been needed), as it would make it obvious to the system maintainer that something is wrong. Hiding broken code behind workarounds like the suggested is almost never a good idea. I also fail to see how you can call this less complex and without new connection establishment, as for the FALLBACK_SCSV to have been asserted there will already have been a reconnect. > Keep in mind that I'm NOT asking to make early adopter servers(!) > non-compliant. Admittedly, I don't know what exactly the early > adopting clients will currently do when they receive Yes, this will break (probably most) early adopters, as good practice in applications (especially those involving crypto) is to validate that all parameters are within the expected range, and it isn't allowed for a server to bump the protocol version above what the client requested. I suspect the most common failure is a protocol_version alert. --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Tue Feb 17 15:44:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB81A902E; Tue, 17 Feb 2015 15:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xblaDH_dJfp6; Tue, 17 Feb 2015 15:44:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6304D1A89A8; Tue, 17 Feb 2015 15:44:45 -0800 (PST) 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: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217234445.3330.11772.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 15:44:45 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-padding-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 23:44:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : A TLS ClientHello padding extension Author : Adam Langley Filename : draft-ietf-tls-padding-01.txt Pages : 4 Date : 2015-02-17 Abstract: This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-padding-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-padding-01 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 davidben@google.com Tue Feb 17 15:46:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9771A895E for ; Tue, 17 Feb 2015 15:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt14j7x4THkd for ; Tue, 17 Feb 2015 15:46:08 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 25D291A6F3F for ; Tue, 17 Feb 2015 15:46:08 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wp18so57047308obc.8 for ; Tue, 17 Feb 2015 15:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=Wq7IwEeLTN2FDU1mDT+NJJb6h27iK0o6VvdSCA0DxvU=; b=icJD3jt3dKOkHVx6brukow86/xlMOWkAuXXPij7SnrUXboSZUR+JPw5WbcRkOZz/iP Z0WjU4TWpNOItULuRUTD/BcRFVYQY9ZS/VAi6rWkOOlu1OD0ogKxj8Q4c7gjRfFe4tJS 1XtOHDnX9O2lym61/JIHRRuNbaWepdpcIDVQQ= 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:from:date:message-id :subject:to:cc:content-type; bh=Wq7IwEeLTN2FDU1mDT+NJJb6h27iK0o6VvdSCA0DxvU=; b=MoZm/33Q21GDQ5xHxVvOY7GKxLzq+vt9M3nprieCXlriva5QY7lZbd5wJh3NP1DEhM bVJViG4XM8VXtsx5aGdOMSauAB1J1wI2sSF1LMb3cEqSyvzJxHtX9RD4QFelDAA+ePk1 DuZIL1EYN+E5Glkxz8QxsT8WV2wcWoF0P7gAhecgUhh33pVPeduE38XON8QWDZfbgXWe NmoHX0HXpbzL83me9T7zfJPY8NozbbDP5HmQzopbZHep9S+CrA7SF0OTrZOOy73SOn1u e9G0EzEPo6WIQ4ddoXFikVpXBovyLcSDcXvWWE/Wv7ZO2JaMBGyLNexR56/m3i9u3sBA Xd9w== X-Gm-Message-State: ALoCoQnv2g2L0gPJ/a7te0YjuFhx2BMJXiE/Qva2hq7C/qTyy+3ARiG07y39ZXi2LHLOymv3ISMs X-Received: by 10.202.196.137 with SMTP id u131mr18932128oif.78.1424216767429; Tue, 17 Feb 2015 15:46:07 -0800 (PST) MIME-Version: 1.0 References: <20150217231046.517061B1B1@ld9781.wdf.sap.corp> From: David Benjamin Date: Tue, 17 Feb 2015 23:46:06 +0000 Message-ID: To: mrex@sap.com, Martin Thomson Content-Type: multipart/alternative; boundary=001a1134f7da819800050f514e62 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Feb 2015 23:46:58 -0000 --001a1134f7da819800050f514e62 Content-Type: text/plain; charset=UTF-8 On Tue Feb 17 2015 at 6:10:55 PM Martin Rex wrote: > This NSS behaviour is not necessarily a problem. The more "interesting" > question is what the app callers above NSS, that have asked NSS to > include FALLBACK_SCSV, will do in response to that behaviour of NSS, > or more specifically, will they do the same that they would do in > response of a fatal invalid_downgrade alert. > > But that is a question for the apps on top rather than for NSS. > Chrome will not treat those the same in either NSS or BoringSSL ports. It'll look like either a generic protocol error or a bad ServerHello version (not sure which on NSS, but it doesn't matter), both of which continue the fallback chain. An inappropriate_fallback alert terminates the fallback chain and restores the original attempt's error code. (So the error code is reported as if there were no version fallback.) I don't really care for adding complexity to support this, either in BoringSSL's server bits or Chrome. I'm especially uninterested in accepting a client_version+1 ServerHello. It opens up questions with client_version-conditioned extensions (signature_algorithms) and isn't a secure version negotiation. FALLBACK_SCSV implies I support client_version+1 but doesn't imply that I do NOT support client_version+2. David --001a1134f7da819800050f514e62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue Feb 17 2015 at 6:10:55 P= M Martin Rex <mrex@sap.com> wrote= :
This NSS behaviour is not necessarily a= problem.=C2=A0 The more "interesting"
question is what the app callers above NSS, that have asked NSS to
include FALLBACK_SCSV, will do in response to that behaviour of NSS,
or more specifically, will they do the same that they would do in
response of a fatal invalid_downgrade alert.

But that is a question for the apps on top rather than for NSS.

Chrome will not treat those the same in either NSS= or BoringSSL ports.

It'll look like either a generic protocol e= rror or a bad ServerHello version (not sure which on NSS, but it doesn'= t matter), both of which continue the fallback chain. An inappropriate_fall= back alert terminates the fallback chain and restores the original attempt&= #39;s error code. (So the error code is reported as if there were no versio= n fallback.)

I don't really care for adding complexity to suppor= t this, either in BoringSSL's server bits or Chrome. I'm especially= uninterested in accepting a client_version+1 ServerHello. It opens up ques= tions with client_version-conditioned extensions (signature_algorithms) and= isn't a secure version negotiation. FALLBACK_SCSV implies I support cl= ient_version+1 but doesn't imply that I do NOT support client_version+2= .

David
--001a1134f7da819800050f514e62-- From nobody Tue Feb 17 15:49:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B29F1A6F3F for ; Tue, 17 Feb 2015 15:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuSZ29bLLHJW for ; Tue, 17 Feb 2015 15:49:42 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 0BB991A88D7 for ; Tue, 17 Feb 2015 15:49:40 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so59378987obc.9 for ; Tue, 17 Feb 2015 15:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L0fzxqp0zuOnWpr824Lpl/tiQ0/oxv1DRwYoPrZP1Ao=; b=tFBkHfKv0hy1iD9wXJKg6fCh3nSyOLLoPdN+d4Zr6xiqJ3GGBIwpIq0JoYDjjnIEfn tfpWIBNU6qRag92jMBPAw09u9P1UDEM+bJRYn09RxGwOQwE7i4af56zwsSUXsKxsIO42 JOd0Kur67eGuvHrAulC0ra+53jLw5gsbrfCv5390qpL+7uSXIrjDFjR06Exg0ZhdMQmR p+7Ofj53UQ0pCJ6PRLBaMTIgDoAXqG8CzD+TiT8BGdXphOZfMIC0zTaWNnTFt7KIh2k5 pGlJrubNzKhfQSE8azTLaRJRWbfjjy8o7lbv236dm60LLWme4j52rVSE7vKlOpJdnBEN 47Ag== MIME-Version: 1.0 X-Received: by 10.202.94.197 with SMTP id s188mr19225375oib.94.1424216979300; Tue, 17 Feb 2015 15:49:39 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 17 Feb 2015 15:49:39 -0800 (PST) In-Reply-To: <20150217231046.517061B1B1@ld9781.wdf.sap.corp> References: <20150217231046.517061B1B1@ld9781.wdf.sap.corp> Date: Wed, 18 Feb 2015 10:49:39 +1100 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Feb 2015 23:49:43 -0000 On 18 February 2015 at 10:10, Martin Rex wrote: > But that is a question for the apps on top rather than for NSS. I have access to one of those as well. That implementation would consider the failure to be *another* sign of version intolerance, triggering further fallback. If the pattern of version+1 responses continues, and I expect it to, it will reset any version intolerance state after exhausting all the options. Of course, that implementation is about to disable fallback, so the window of applicability is extremely narrow in that case. From nobody Tue Feb 17 16:16:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6AD1A910A for ; Tue, 17 Feb 2015 16:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgUtjFHPJmjv for ; Tue, 17 Feb 2015 16:16:10 -0800 (PST) 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 ADC3C1A8840 for ; Tue, 17 Feb 2015 16:16:09 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 61AA72AC04; Wed, 18 Feb 2015 01:16:06 +0100 (CET) X-purgate-ID: 152705::1424218567-0000765A-7D2062A8/0/0 X-purgate-size: 2721 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7990F42FAD; Wed, 18 Feb 2015 01:16:06 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 735991B1B1; Wed, 18 Feb 2015 01:16:06 +0100 (CET) In-Reply-To: To: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= Date: Wed, 18 Feb 2015 01:16:06 +0100 (CET) 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: <20150218001606.735991B1B1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:16:14 -0000 Henrik Grubbstr=F6m wrote: >=20 > I also fail to see how you can call this less complex and without new > connection establishment, as for the FALLBACK_SCSV to have been > asserted there will already have been a reconnect. Just using a connection established with (ClientHello.client_version+1) will be less complexity for clients (that implement this alternative behaviour properly) because the app will not have to establish a new connection and go through the entire app-level protocol preparations again (HTTP CONNECT proxy and/or STARTTLS prologue) >=20 > > Keep in mind that I'm NOT asking to make early adopter servers(!) > > non-compliant. Admittedly, I don't know what exactly the early > > adopting clients will currently do when they receive >=20 > Yes, this will break (probably most) early adopters, In which way does it "break" early adopters. The fatal alert will unconditionally result in complete interop failure on the established connection. The "worst" that could possibly happen is a "different kind of complete interop failure" but an interop failure is an interop failure is an interop failure. So really, making it worse for the current handshake is factually impossible. > > as good practice in applications (especially those involving crypto) > is to validate that all parameters are within the expected range, > and it isn't allowed for a server to bump the protocol version above > what the client requested. It was the CLIENT(!!) who asserted the FALLBACK_SCSV in the first place, complaining loudly that it would really like to use a higher TLS protocol version that what the client placed into ClientHello.client_version, so this reasoning is bogus here. > > I suspect the most common failure is a protocol_version alert. The whole proposal started because the client believes that the protocol options that the server negotiates would be options that the client rather does not want. So what kind of alert the client sends if it wants to abort the current handshake and start a new one, doesn't really matter for the server here. What matters is that the server does not have to take the blame for the handshake failure. This will be left to the client, who started the FALLBACK_SCSV dance. For this particular connection, the server has the necessary state to make this handshake failure "soft" (i.e. not stand out in the traces), when the client aborts in response to the servers selection of ServerHello.server_version =3D (ClientHello.client_version+1) so I really don't mind such a client behaviour. Servers not implementing the alternative approach do not have to bother about this outcome. -Martin From nobody Tue Feb 17 16:28:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AE11A1EEE for ; Tue, 17 Feb 2015 16:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm-kOzEm1CFi for ; Tue, 17 Feb 2015 16:28:06 -0800 (PST) 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 2ED841A8791 for ; Tue, 17 Feb 2015 16:28:06 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id DA63E2AB45; Wed, 18 Feb 2015 01:28:04 +0100 (CET) X-purgate-ID: 152705::1424219284-00003099-5AD58B07/0/0 X-purgate-size: 1074 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id CF3FC42D5E; Wed, 18 Feb 2015 01:28:04 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C59951B1B1; Wed, 18 Feb 2015 01:28:04 +0100 (CET) In-Reply-To: To: Martin Thomson Date: Wed, 18 Feb 2015 01:28:04 +0100 (CET) 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: <20150218002804.C59951B1B1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:28:10 -0000 Martin Thomson wrote: > Martin Rex wrote: >> >> But that is a question for the apps on top rather than for NSS. > > I have access to one of those as well. That implementation would > consider the failure to be *another* sign of version intolerance, > triggering further fallback. If the pattern of version+1 responses > continues, and I expect it to, it will reset any version intolerance > state after exhausting all the options. You mean that this client will fallback further _down_, rather than upwards as the server suggests? I assume this is mostly because the App does the heuristics here and has little information to do its heuristics (it probably doesn't have the ServerHello to look at). But that should be an easy fix to the app heuristics. > > Of course, that implementation is about to disable fallback, so the > window of applicability is extremely narrow in that case. Then the exact semantics of the FALLBACK_SCSV and the server response to it will become a non-issue for that App, I believe. -Martin From nobody Tue Feb 17 16:36:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7391E1A882B for ; Tue, 17 Feb 2015 16:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1OkDb27-zBA for ; Tue, 17 Feb 2015 16:36:18 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 A1C591A1B0A for ; Tue, 17 Feb 2015 16:36:18 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wp4so59786987obc.0 for ; Tue, 17 Feb 2015 16:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n2taThQKDoZPBC3QWiUXlPN4hIGb/XaknSzMtu+AhNk=; b=c8s0AHHxIGeNWPb2cP6hQYVSgA08iCnHgTtVgNnvvpH0ftRYv2YsQ+r0YDVo2LPEsx FuyjfD6TWjZptZZq/K2iVwQhybiyfj4jSFYXETdsOKgi+3oVBI5OZ2yjE9Zw/JhycDha eIy3HY4QMTJ8zpiRX5gjssiQKbzl3AZtgfMQN9OxA+SmUQRDPLVmEXDkEiDCtdjqYDU1 V26FKmcDWuaN3KDtCoh7iNRbBPw2oPzb1JE9K/QyTtG9uTlSNL1z5ZimOd5VJDhlHrkZ Egq1q3ociHE5AwoG1gXaC5wuwkZH4qgp/oE6+hffP6gwx6CXuJwX7mRwRdFoWyW84KTK 2K3g== MIME-Version: 1.0 X-Received: by 10.182.249.102 with SMTP id yt6mr12655165obc.30.1424219778015; Tue, 17 Feb 2015 16:36:18 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 17 Feb 2015 16:36:17 -0800 (PST) In-Reply-To: <20150218001606.735991B1B1@ld9781.wdf.sap.corp> References: <20150218001606.735991B1B1@ld9781.wdf.sap.corp> Date: Wed, 18 Feb 2015 11:36:17 +1100 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Feb 2015 00:36:20 -0000 On 18 February 2015 at 11:16, Martin Rex wrote: >> Yes, this will break (probably most) early adopters, > > In which way does it "break" early adopters. I suspect that not generating the alert will cause early adopters to fall back more. If a long series of fallbacks resets any fallback state before failing completely (like Firefox), then that's not a terminal condition. In fact, it produces the same net result, albeit more slowly, for those. Not sure about other implementations though. David's concern about burying the original reason doesn't bother me much, but it does apply. From nobody Tue Feb 17 16:40:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F3A1A8893 for ; Tue, 17 Feb 2015 16:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdN2mb-3fyQw for ; Tue, 17 Feb 2015 16:39:56 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 0FE5F1A898D for ; Tue, 17 Feb 2015 16:39:55 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so59594341obc.1 for ; Tue, 17 Feb 2015 16:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tLm1dWrwYzghFuKO7mJMgg0SJSRvbNzVKViYSppgV/Q=; b=nngTTCA35ckIEJicB2NC879pW3hhmQLDcnsXLetvYJZzAG7PO1LzU3jYS/I2E2edBR /8HdBm+LBQZ9qho5UF2JLHHWoBXIfyk6x3QaoJJH/Za40OkabVQHsCGciBFdDediBBp4 /+PHf9/CpZrFpD4xaMMy35lQKC6VUz5RdtMHEeBRXvOLbZ9fqGgRSOZq/55OvQ+bEkjv KAcYP/klqGUZ0aOaNNFcNZtGT+s5tzCL/oGBSuOA77YFYTVVed7sXJR/Hm5T6aLxA+ux Mhef5HR64Jzx34rUBcb/6bYXI6dMh7VM/u84vo0IcLfyYcnb5UkE+Qx2Iyxvz1yxu4AS Dq/w== MIME-Version: 1.0 X-Received: by 10.60.132.82 with SMTP id os18mr15885578oeb.0.1424219994443; Tue, 17 Feb 2015 16:39:54 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 17 Feb 2015 16:39:54 -0800 (PST) In-Reply-To: <20150218002804.C59951B1B1@ld9781.wdf.sap.corp> References: <20150218002804.C59951B1B1@ld9781.wdf.sap.corp> Date: Wed, 18 Feb 2015 11:39:54 +1100 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Feb 2015 00:40:03 -0000 On 18 February 2015 at 11:28, Martin Rex wrote: > You mean that this client will fallback further _down_, rather than > upwards as the server suggests? Indeed. I expect that to be a common response. > I assume this is mostly because the App does the heuristics here > and has little information to do its heuristics (it probably doesn't > have the ServerHello to look at). But that should be an easy > fix to the app heuristics. I'm largely talking about apps that don't change here, because if they were to change, then I'd be arguing for disabling fallback. It's actually fairly easy to make the change, because the app is usually well aware of the fact that it is performing a fallback when it does. What is needed is a signal to the TLS stack that it should accept a higher version in the ServerHello. From nobody Tue Feb 17 16:48:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92B51A8846 for ; Tue, 17 Feb 2015 16:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PyCQchpVO5Q for ; Tue, 17 Feb 2015 16:48:30 -0800 (PST) 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 BAAE21A890B for ; Tue, 17 Feb 2015 16:48:28 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id BA2332AC4D; Wed, 18 Feb 2015 01:48:26 +0100 (CET) X-purgate-ID: 152705::1424220507-000007DF-7D5D3A84/0/0 X-purgate-size: 1103 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id AFD3742E7C; Wed, 18 Feb 2015 01:48:26 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A58D21B1B1; Wed, 18 Feb 2015 01:48:26 +0100 (CET) In-Reply-To: To: Martin Thomson Date: Wed, 18 Feb 2015 01:48:26 +0100 (CET) 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: <20150218004826.A58D21B1B1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:48:36 -0000 Martin Thomson wrote: [ Charset UTF-8 unsupported, converting... ] > On 18 February 2015 at 11:28, Martin Rex wrote: > > You mean that this client will fallback further _down_, rather than > > upwards as the server suggests? > > Indeed. I expect that to be a common response. > > > I assume this is mostly because the App does the heuristics here > > and has little information to do its heuristics (it probably doesn't > > have the ServerHello to look at). But that should be an easy > > fix to the app heuristics. > > I'm largely talking about apps that don't change here, because if they > were to change, then I'd be arguing for disabling fallback. It's > actually fairly easy to make the change, because the app is usually > well aware of the fact that it is performing a fallback when it does. > What is needed is a signal to the TLS stack that it should accept a > higher version in the ServerHello. But isn't that signal _already_ there: the request for the FALLBACK_SCSV. How does the App signal that the FALLBACK_SCSV should be included? -Martin From nobody Tue Feb 17 16:55:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83111A9119 for ; Tue, 17 Feb 2015 16:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81Eev3dxmPwb for ; Tue, 17 Feb 2015 16:55:08 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 2B3A51A9117 for ; Tue, 17 Feb 2015 16:55:08 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id vb8so59872244obc.11 for ; Tue, 17 Feb 2015 16:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0r04W03E8y59FbVd/F+O8vRL3vcXp3JmtHXpQyEqOJQ=; b=WhhzWJnjEpntZ60mXn5z+ZZ/Z4ZTnO2ZQfivLtMTL0iiEBPEuwvfQ56fVfX7FkfJYH DwzGgiZXwC0ul4XWGhQAHqNUf/wEkMGzRgovktvn75CufUQ9PtjU5xc62Zq3lQ5CtnJH C4e+GVPtxHVGIXWMpTZGOFZCsZA5poGGsZ0o5XPx4pQxknSxtBjSOXHkvjYUU72kqjK3 lmK682X/CN/5EhJF3HnOeh4xgHHLv6Expxz7emegW2sTohqa+SfRX8zPgi3kez9pIOmn d/3h9CXSTIv1mMvnmTBH8pP83x5RdH6ne0qSuIJbDYfg3vwx3cDpIDBl6+Basbsn1KkY kDwg== MIME-Version: 1.0 X-Received: by 10.60.73.103 with SMTP id k7mr20111028oev.38.1424220907503; Tue, 17 Feb 2015 16:55:07 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 17 Feb 2015 16:55:07 -0800 (PST) In-Reply-To: <20150218004826.A58D21B1B1@ld9781.wdf.sap.corp> References: <20150218004826.A58D21B1B1@ld9781.wdf.sap.corp> Date: Wed, 18 Feb 2015 11:55:07 +1100 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] checking on an scsv point X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Feb 2015 00:55:09 -0000 On 18 February 2015 at 11:48, Martin Rex wrote: > But isn't that signal _already_ there: the request for the FALLBACK_SCSV. Well, we were talking about the legacy case, where the request to include the SCSV doesn't implicitly include permission to negotiate version.max + 1. TLS stacks that care about backward compatibility as deeply as NSS does will want another signal to avoid the overload of semantics. > How does the App signal that the FALLBACK_SCSV should be included? In the APIs I've seen (NSS + OpenSSL), the app configures the stack with a reduced range of versions and they explicitly turn on the SCSV with a separate option. From nobody Tue Feb 17 17:17:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205241A913A for ; Tue, 17 Feb 2015 17:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvGHCVASWT6d for ; Tue, 17 Feb 2015 17:17:48 -0800 (PST) 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 EABFF1A9120 for ; Tue, 17 Feb 2015 17:17:47 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 57786445B5; Wed, 18 Feb 2015 02:17:46 +0100 (CET) X-purgate-ID: 152705::1424222266-00003099-8BF281AE/0/0 X-purgate-size: 2449 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 1BDEA41D37; Wed, 18 Feb 2015 02:17:46 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 121131B1B1; Wed, 18 Feb 2015 02:17:46 +0100 (CET) In-Reply-To: To: Yuhong Bao Date: Wed, 18 Feb 2015 02:17:46 +0100 (CET) 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: <20150218011746.121131B1B1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 01:17:50 -0000 Yuhong Bao wrote: > > Just confirmed that IE on Win7 even when misconfigured to enable > SSLv2 doesn't send a SSLv2 ClientHello with TLS 1.2 on it which > means that SChannel probably can't do it at all. Andrei Popov > should be able to confirm this. Speaking of Windows 7 SChannel, just today I enabled TLSv1.2 for the IIS on my Windows 7 test machine (it is disabled by default) and tried to negotiate TLSv1.2 with it -- but I'm facing handshake failures. I'm sending a pretty vanilla, extension-less ClientHello record=(3,0) and ClientHello.client_version=(3,3) with the following TLS cipher suites: TLS_RSA_WITH_AES128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_3DES_EDE_CBC_SHA and the Microsoft IIS server on my Win7 machine closes the connection. The following two Events get written to the Windows "System" Eventlog: Source: Schannel EventID: 36874 An TLS 1.2 connectin request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed. Source: Schannel EventID: 36888 The following fatal alert was generated: 40. The internal error state is 1205. As some might notice, the ClientHello lists the mandatory-to-implement TLSv1.2 cipher suite (rfc5246, section 9), so it is extremely unexpected to see the handshake fail when proposing TLSv1.2, but succeed when proposing only TLSv1.1. Since I can connect with a browser with TLSv1.2 (and with openssl-1.0.1j) the issue might be the absence of the TLS signature algorithm extension. Per rfc5246, the use of TLS extensions is a MAY for the TLSv1.2 client and accepting a ClientHello without extensions is a MUST for the TLSv1.2 server: (rfc 5246, section 7.4.1.2 ClientHello) https://tools.ietf.org/html/rfc5246#page-42 extensions Clients MAY request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 7.4.1.4. A server MUST accept ClientHello messages both with and without the extensions field, Myself I don't have any Win8 / Win2012 machines, but I assume they're also both affected. I only tried this because the customers ADFS server (2012 I believe) didn't want to interop. -Martin From nobody Wed Feb 18 04:12:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858571A8779 for ; Wed, 18 Feb 2015 04:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwqfn9-7pG2O for ; Wed, 18 Feb 2015 04:12:38 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.93.164.2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64F61A8774 for ; Wed, 18 Feb 2015 04:12:37 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 00F6736345292; Wed, 18 Feb 2015 06:12:37 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway04.websitewelcome.com (Postfix) with ESMTP id E4A7A36345236 for ; Wed, 18 Feb 2015 06:12:36 -0600 (CST) Received: from [96.231.221.128] (port=50355 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YO3Ua-0008T4-AT; Wed, 18 Feb 2015 06:12:36 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com> Date: Wed, 18 Feb 2015 07:12:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.221.128 X-Exim-ID: 1YO3Ua-0008T4-AT X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.221.128]:50355 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: draft-ietf-tls-negotiated-ff-dhe@tools.ietf.org Subject: Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Feb 2015 12:12:39 -0000 On Jan 23, 2015, at 14:30, Sean Turner wrote: > This is the WGLC (working group last call) for = draft-ietf-tls-negotiated-ff-dhe-05: > http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe-05/ > Please send comments on this draft to the TLS list before February 16, = 2015. >=20 > The chairs and our AD are curious about whether switching to use of = =93e=94 as opposed to =93pi=94, as RFC 3526 did, is an issue. The draft = provides rationale for the change, but Stephen asked about this = particular point @ our Hawaii session. >=20 > spt All, The WGLC has concluded. dkg noted he=92d received some comments = off-list and Watson provide some input. We=92ll need a new version to = review the changes to see if it should be progressed or whether another = WGLC is needed. I=92ve updated the datatracker to reflect the new = state. dkg, Any chance of another version before the 2015-03-09 draft submission = deadline? spt= From nobody Wed Feb 18 11:01:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882121A0127 for ; Wed, 18 Feb 2015 11:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlsDqnhqsLet for ; Wed, 18 Feb 2015 11:01:53 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9341A0125 for ; Wed, 18 Feb 2015 11:01:53 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id c9so2534299qcz.1 for ; Wed, 18 Feb 2015 11:01:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=7ZmSnuwVq4Vw1++nzGjDNL9TwCiwH/ccZ51Kq56MPvc=; b=HY1O7W1B1I4m9kw1uSy7wfEwPWW9Rw58NI6cnuCQRA8mp2GoEnZqAXDzrb5Rz6w50k ImCY9IT+0gZrgnk5lPIk/2fXC3KbvOLrZTPDb4ctnomy5gj8F5WzenqLhIiN/3vO/pQp N4QZ8YhaKZaV4nNoYLjbk0YJHieJcwu/TpGxZ3hXW3XYn4ZsOi9Qh1p0guYqX4kv5QJx izZO+rr2xw6D5Ea2AFgrLp8ra1juTLdnaEZpZbAEKYPNYFxiS7rX8ASBzoKZh47nUHm1 T0QJiCf/NyKbqreFy79zJwf5cKTbBw6he/ZGr+yHw07vi/614QaDLmOjk4dDodFOkmb7 E1dw== X-Gm-Message-State: ALoCoQlBlzwYuAx2ML0X2I/daoIwCT2+Pdu3NdFDv18pW1DGUmKsJCOHHOjexQmiN0VwdU9zEtL0 MIME-Version: 1.0 X-Received: by 10.140.107.227 with SMTP id h90mr2972873qgf.71.1424286112367; Wed, 18 Feb 2015 11:01:52 -0800 (PST) Received: by 10.96.121.104 with HTTP; Wed, 18 Feb 2015 11:01:52 -0800 (PST) X-Originating-IP: [50.206.82.141] Date: Wed, 18 Feb 2015 11:01:52 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113a6cf6c978a9050f617381 Archived-At: Subject: [TLS] TLS Interim Location X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Feb 2015 19:01:55 -0000 --001a113a6cf6c978a9050f617381 Content-Type: text/plain; charset=UTF-8 The location of the interim will be hosted at: F5 Networks 401 Elliott Avenue West Seattle, WA 98119-4017 We have a lot of folks singed up for the meeting. I you are thinking of attending let me know now. I will need to know the names of the attendees to facilitate access to the buildings. Thanks, Joe --001a113a6cf6c978a9050f617381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The location of the interim will be hosted at:

F5 Networks
401 Elliott Avenue West
Seattle, WA 98119-40= 17

We have a lot of folks singed up for the me= eting.=C2=A0 I you are thinking of attending let me know now.=C2=A0 I will = need to know the names of the attendees to facilitate access to the buildin= gs.=C2=A0

Thanks,

Joe

--001a113a6cf6c978a9050f617381-- From nobody Wed Feb 18 15:03:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E61A1B85; Wed, 18 Feb 2015 15:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMxy48Ply4yh; Wed, 18 Feb 2015 15:03:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id E12BC1A1B56; Wed, 18 Feb 2015 15:03:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 19E6A181D1F; Wed, 18 Feb 2015 15:03:14 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150218230314.19E6A181D1F@rfc-editor.org> Date: Wed, 18 Feb 2015 15:03:14 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7465 on Prohibiting RC4 Cipher Suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Feb 2015 23:03:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7465 Title: Prohibiting RC4 Cipher Suites Author: A. Popov Status: Standards Track Stream: IETF Date: February 2015 Mailbox: andreipo@microsoft.com Pages: 6 Characters: 8397 Updates: RFC 5246, RFC 4346, RFC 2246 I-D Tag: draft-ietf-tls-prohibiting-rc4-01.txt URL: https://www.rfc-editor.org/info/rfc7465 This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sschaege@googlemail.com Thu Feb 19 07:41:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981941A90F6 for ; Thu, 19 Feb 2015 07:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi-DF0g_81ef for ; Thu, 19 Feb 2015 07:41:15 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 44A441A90EE for ; Thu, 19 Feb 2015 07:41:15 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id uy5so15746876obc.4 for ; Thu, 19 Feb 2015 07:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=icG9//LkCqlDlSMgnfJnoFGPq0wQYgZftiaBceMwDbE=; b=vTmmt9jlZIj0NuZgdntsgjr4xX3Fd61BSq7aA+EbHwF8DY6RAqSO03D0+YdjPO5UPI EL4BWxuulEHminnFwqAYhqFTZ6QR0zCTMTpNFTHilJ/ZZX77wBF4oqbgCsN6el9nz4BC LHY+6Tbr8pt+thD22c7mkQXEhsyI+X3VTYbx79VlowendH55gN5gSrF2lZruxtMH/yEV nfofCeBMxUlT9/4AYaOkLMA3aA4jaIj5WQ+BxCCl2LYw2q44GT2dqg0yCNiI+eFpzYI9 VMCvF/8mBYPNrWGdoVENQpAm5kyXuoQU4M85BsK66GKC/dl/JE9T/hlFd+D/w86tnMRl 0bWw== MIME-Version: 1.0 X-Received: by 10.60.58.137 with SMTP id r9mr3321210oeq.1.1424360474612; Thu, 19 Feb 2015 07:41:14 -0800 (PST) Sender: sschaege@googlemail.com Received: by 10.182.241.200 with HTTP; Thu, 19 Feb 2015 07:41:14 -0800 (PST) In-Reply-To: <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> Date: Thu, 19 Feb 2015 16:41:14 +0100 X-Google-Sender-Auth: iuDNRBJ_K6oQvqpXyyW12j8P7cA Message-ID: From: =?UTF-8?B?U3ZlbiBTY2jDpGdl?= To: Dan Harkins , tls@ietf.org Content-Type: multipart/alternative; boundary=089e0153729e1f1b12050f72c430 Archived-At: Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Feb 2015 15:48:51 -0000 --089e0153729e1f1b12050f72c430 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was just reading through the TLS-PSK related discussions so far and came across your post... 2014-10-20 14:13 GMT+02:00 Dan Harkins : > > On Sun, October 19, 2014 7:35 am, Yoav Nir wrote: > > > > I also understand that in practice, PSK ciphersuites are used only by > > small devices, whereas the web and SMTP and other things never went for > > it. But the standards don=C3=A2=E2=82=AC=E2=84=A2t say that. They don= =C3=A2=E2=82=AC=E2=84=A2t say that PSK > > ciphersuites are especially for constrained devices. So if we insist th= at > > the same TLS 1.3 be used for both, and we don=C3=A2=E2=82=AC=E2=84=A2t = want to say that PSK is > > for weak security, then we should have a good story of why PFS is not > > needed for PSK uses, whereas it=C3=A2=E2=82=AC=E2=84=A2s essential for = all RSA uses. If I > > understand the mechanism correctly, PSKs tend to be long-lived, and a > > subsequent compromise of a PSK (even if it is expired at the time of > > compromise) allows an attacker to decrypt the content of a TLS session. > > The non-PFS PSK ciphersuites are no different than the widely > discredited, and easily cracked, WPA-PSK mode of WiFi security. It would > be a really bad idea to continue with these ciphersuites in TLS 1.3. But > the > issue is not just PFS (or the lack of it), it's that PSK ciphersuites are > susceptible to dictionary attack. > > > So either we believe that PSK compromise is unlikely, or we believe tha= t > > the data in a connection with a PSK ciphersuite is not future-sensitive= . > > If we don=C3=A2=E2=82=AC=E2=84=A2t, we=C3=A2=E2=82=AC=E2=84=A2re saying= that we=C3=A2=E2=82=AC=E2=84=A2re just piling on security > > nice-to-haves because we think the users can handle them. > > There's no way that the protocol can be defined to justify that belief. > What you're talking about is how people end up using the protocol and > that is entirely out of the power of this WG. What we can do is to make > TLS be as _misuse resistant_ as possible. And to do that we should not > allow PSKs in TLS 1.3 unless they are used in a PAKE. > > By the way, I'm surprised that no one is expressing outrageous outrage > at the lack of a security proof for PSK ciphersuites. > Perhaps you might find http://eprint.iacr.org/2014/037 useful. > regards, > > Dan. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > Many greetings, Sven --089e0153729e1f1b12050f72c430 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was just reading through the TLS-PSK related discussions= so far and came across your post...

2014-10-20 14:13 GMT+02:00 Dan Harkins <dharkins@loun= ge.org>:

On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:
>
> I also understand that in practice, PSK ciphersuites are used only by<= br> > small devices, whereas the web and SMTP and other things never went fo= r
> it. But the standards don=C3=A2=E2=82=AC=E2=84=A2t say that. Th= ey don=C3=A2=E2=82=AC=E2=84=A2t say that PSK
> ciphersuites are especially for constrained devices. = So if we insist that
> the same TLS 1.3 be used for both, and we don=C3=A2=E2=82=AC=E2= =84=A2t want to say that PSK is
> for weak security, then we should have a good story o= f why PFS is not
> needed for PSK uses, whereas it=C3=A2=E2=82=AC=E2=84=A2s essent= ial for all RSA uses.=C2=A0 If I
> understand the mechanism correctly, PSKs tend to be l= ong-lived, and a
> subsequent compromise of a PSK (even if it is expired at the time of > compromise) allows an attacker to decrypt the content of a TLS session= .

=C2=A0 The non-PFS PSK ciphersuites are no different than the widely=
discredited, and easily cracked, WPA-PSK mode of WiFi security. It would be a really bad idea to continue with these ciphersuites in TLS 1.3. But th= e
issue is not just PFS (or the lack of it), it's that PSK ciphersuites a= re
susceptible to dictionary attack.

> So either we believe that PSK compromise is unlikely, or we believe th= at
> the data in a connection with a PSK ciphersuite is not future-sensitiv= e.
> If we don=C3=A2=E2=82=AC=E2=84=A2t, we=C3=A2=E2=82=AC=E2=84=A2r= e saying that we=C3=A2=E2=82=AC=E2=84=A2re just piling on security
> nice-to-haves because we think the users can handle t= hem.

=C2=A0 There's no way that the protocol can be defined to justif= y that belief.
What you're talking about is how people end up using the protocol and that is entirely out of the power of this WG. What we can do is to make
TLS be as _misuse resistant_ as possible. And to do that we should not
allow PSKs in TLS 1.3 unless they are used in a PAKE.

=C2=A0 By the way, I'm surprised that no one is expressing outrageous o= utrage
at the lack of a security proof for PSK ciphersuites.
=

Perhaps you might find=C2=A0


useful.


=C2=A0 regards,

=C2=A0 Dan.


_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
Many greetings,
Sven=C2=A0

--089e0153729e1f1b12050f72c430-- From nobody Thu Feb 19 08:21:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD68A1A8833 for ; Thu, 19 Feb 2015 08:21:41 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79vbGZJVdcQP for ; Thu, 19 Feb 2015 08:21:39 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5391A893E for ; Thu, 19 Feb 2015 08:21:38 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hi2so49203487wib.4 for ; Thu, 19 Feb 2015 08:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vx4.de; s=google; h=from:to:cc:references:in-reply-to:subject:date:organization :message-id:mime-version:content-type:thread-index:content-language; bh=jMaveSy8gUgn5U7zIZOUoKA93fCkL6t+4YDVgSjJalc=; b=nrUTN5R8SunjocixMoUDuvZAwn5YkmzKMlmHDGaU5g+FK098xvlhcVzEZGSz457kxc Wvmw+yeRF+PJMBqCAO6U9buca2xYxbiFAB5B3My1GLgLvcR1fX5QSohX+3SmEiG9ff3j 0mqXd9w1JKeYyIZizuiL3L1sH8KkLWeOPaBX8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:content-type:thread-index :content-language; bh=jMaveSy8gUgn5U7zIZOUoKA93fCkL6t+4YDVgSjJalc=; b=ko2EmXfFQyA/YVSpSfm5MHdi1MvNDig9r8ZhL1SGMMjADh38UWF2wAKxnW97J5+ZPx laaQAk8xLyhVmvAcuz9wkHMUpNKgVaZewYeru8CVZJqEQ+UIYVgQi4ABy4iaLjhVMxIh +2Qyoeaxf6Eiyjw9aPQ/NpTzT39/4gce+ueO/ljpf4YD7tDk1MZMeX6/J/JCgpBMz9XN Q4tXBkSPdfMkZOORjYkeGnAT7THpTpVTs/jHaMSiZpkkQ82ac/C+u8JcstzYfcn/h/Lv KRMMqgb3LGjFyy5lh9xSdzQ8FyuSGV0YnQHdWBtZNE5dNAeasfB+e++tLacnAwSv0Zi2 hpqw== X-Gm-Message-State: ALoCoQn7yhTPXaykk1cSCMJYeCR9+qvWTU1w2ULApOufMym4Opm/kgkjcp7ew9OOmYZTwuFlicdu X-Received: by 10.181.13.174 with SMTP id ez14mr8054786wid.72.1424362897273; Thu, 19 Feb 2015 08:21:37 -0800 (PST) Received: from THINK2 ([82.119.170.75]) by mx.google.com with ESMTPSA id nb9sm25187930wic.3.2015.02.19.08.21.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Feb 2015 08:21:36 -0800 (PST) From: "Christian Kahlo" To: =?utf-8?Q?'Sven_Sch=C3=A4ge'?= , "'Dan Harkins'" , References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> In-Reply-To: Date: Thu, 19 Feb 2015 17:21:34 +0100 Organization: VX4.NET Message-ID: <002601d04c60$21f80c60$65e82520$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01D04C68.83BC7460" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBMW5nPYtMYd+mxRRut/641Dx7zXgAAs8Ag Content-Language: de Archived-At: Cc: jens.bender@bsi.bund.de Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Feb 2015 16:21:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01D04C68.83BC7460 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable BTW: We're using TLS_ECDHE_RSA_PSK_WITH_AES_256_CBC_SHA384 on a custom code point for a couple of years now. Works well - even in = customer infrastructure with SPI firewalls. =20 BSI TR-03116-4 requires TLS1.2, EtM (RFC7366) and PFS. For some cases = PSK is needed as a three-party cryptographic binding. When I saw how lazy = RFC7366 standardization was in this WG I just skipped talking about and we = decided to fulfill the requirements out-of-IETF-standard. It's sufficient if we = rely on the basics such as versions, record format, supported minimum, interoperable cipher suites for non-internal infrastructure communication. =20 But maybe this is a pointer how to support PSK-PFS in TLS1.3+. I could = provide pseudo code from the key exchanger part. We would really appreciate = PSK-PFS as a public standard. (No, we don't reveal source code of those projects. But we could add it = to i.e. BouncyCastle.) =20 Best regards, Christian =20 =20 Von: TLS [mailto:tls-bounces@ietf.org] Im Auftrag von Sven Sch=C3=A4ge Gesendet: Donnerstag, 19. Februar 2015 16:41 An: Dan Harkins; tls@ietf.org Betreff: Re: [TLS] PSK in 1.3? =20 I was just reading through the TLS-PSK related discussions so far and = came across your post... =20 2014-10-20 14:13 GMT+02:00 Dan Harkins : On Sun, October 19, 2014 7:35 am, Yoav Nir wrote: > > I also understand that in practice, PSK ciphersuites are used only by > small devices, whereas the web and SMTP and other things never went = for > it. But the standards don=C3=A2=E2=82=AC=E2=84=A2t say that. They = don=C3=A2=E2=82=AC=E2=84=A2t say that PSK > ciphersuites are especially for constrained devices. So if we insist = that > the same TLS 1.3 be used for both, and we don=C3=A2=E2=82=AC=E2=84=A2t = want to say that PSK is > for weak security, then we should have a good story of why PFS is not > needed for PSK uses, whereas it=C3=A2=E2=82=AC=E2=84=A2s essential for = all RSA uses. If I > understand the mechanism correctly, PSKs tend to be long-lived, and a > subsequent compromise of a PSK (even if it is expired at the time of > compromise) allows an attacker to decrypt the content of a TLS = session. The non-PFS PSK ciphersuites are no different than the widely discredited, and easily cracked, WPA-PSK mode of WiFi security. It would be a really bad idea to continue with these ciphersuites in TLS 1.3. But = the issue is not just PFS (or the lack of it), it's that PSK ciphersuites = are susceptible to dictionary attack. > So either we believe that PSK compromise is unlikely, or we believe = that > the data in a connection with a PSK ciphersuite is not = future-sensitive. > If we don=C3=A2=E2=82=AC=E2=84=A2t, we=C3=A2=E2=82=AC=E2=84=A2re = saying that we=C3=A2=E2=82=AC=E2=84=A2re just piling on security > nice-to-haves because we think the users can handle them. There's no way that the protocol can be defined to justify that = belief. What you're talking about is how people end up using the protocol and that is entirely out of the power of this WG. What we can do is to make TLS be as _misuse resistant_ as possible. And to do that we should not allow PSKs in TLS 1.3 unless they are used in a PAKE. By the way, I'm surprised that no one is expressing outrageous outrage at the lack of a security proof for PSK ciphersuites. =20 =20 Perhaps you might find=20 =20 http://eprint.iacr.org/2014/037 =20 useful. =20 regards, Dan. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 Many greetings, Sven=20 =20 ------=_NextPart_000_0027_01D04C68.83BC7460 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

BTW: We're using TLS_ECDHE_RSA_PSK_WITH_AES_256_CBC_SHA384 on = a

custom code point for a couple of years now. Works well - even in = customer

infrastructure with SPI firewalls.

 

BSI TR-03116-4 requires TLS1.2, EtM (RFC7366) and PFS. For some cases = PSK is

needed as a three-party cryptographic binding. When I saw how lazy = RFC7366

standardization was in this WG I just skipped talking about and we = decided to

fulfill the requirements out-of-IETF-standard. It's sufficient if we = rely on the

basics such as versions, record format, supported minimum, = interoperable

cipher suites for non-internal infrastructure = communication.

 

But maybe this is a pointer how to support PSK-PFS in TLS1.3+. I = could provide

pseudo code from the key exchanger part. We would really appreciate = PSK-PFS

as a public standard.

(No, we don't reveal source code of those projects. But we could add = it to

i.e. BouncyCastle.)

 

Best regards,

Christian

 

 

Von:<= /b> = TLS [mailto:tls-bounces@ietf.org] Im Auftrag von Sven = Sch=C3=A4ge
Gesendet: Donnerstag, 19. Februar 2015 = 16:41
An: Dan Harkins; tls@ietf.org
Betreff: Re: = [TLS] PSK in 1.3?

 

I was = just reading through the TLS-PSK related discussions so far and came = across your post...

 

2014-10-20 14:13 GMT+02:00 Dan Harkins <dharkins@lounge.org>:


On Sun, October 19, 2014 7:35 am, Yoav Nir = wrote:
>
> I also understand that in practice, PSK = ciphersuites are used only by
> small devices, whereas the web and = SMTP and other things never went for
> it. But the standards = don=C3=A2=E2=82=AC=E2=84=A2t say that. They don=C3=A2=E2=82=AC=E2=84=A2t = say that PSK
> ciphersuites are especially for constrained = devices. So if we insist that
> the same TLS 1.3 be used for both, = and we don=C3=A2=E2=82=AC=E2=84=A2t want to say that PSK is
> for = weak security, then we should have a good story of why PFS is = not
> needed for PSK uses, whereas it=C3=A2=E2=82=AC=E2=84=A2s = essential for all RSA uses.  If I
> understand the mechanism = correctly, PSKs tend to be long-lived, and a
> subsequent = compromise of a PSK (even if it is expired at the time of
> = compromise) allows an attacker to decrypt the content of a TLS = session.

  The non-PFS PSK ciphersuites are no different = than the widely
discredited, and easily cracked, WPA-PSK mode of WiFi = security. It would
be a really bad idea to continue with these = ciphersuites in TLS 1.3. But the
issue is not just PFS (or the lack = of it), it's that PSK ciphersuites are
susceptible to dictionary = attack.

> So either we believe that PSK compromise is = unlikely, or we believe that
> the data in a connection with a PSK = ciphersuite is not future-sensitive.
> If we = don=C3=A2=E2=82=AC=E2=84=A2t, we=C3=A2=E2=82=AC=E2=84=A2re saying that = we=C3=A2=E2=82=AC=E2=84=A2re just piling on security
> = nice-to-haves because we think the users can handle them.

  = There's no way that the protocol can be defined to justify that = belief.
What you're talking about is how people end up using the = protocol and
that is entirely out of the power of this WG. What we = can do is to make
TLS be as _misuse resistant_ as possible. And to do = that we should not
allow PSKs in TLS 1.3 unless they are used in a = PAKE.

  By the way, I'm surprised that no one is expressing = outrageous outrage
at the lack of a security proof for PSK = ciphersuites.

 

 

Perhaps you might = find 

 


  regards,

  = Dan.

 

Many = greetings,
Sven 

 

------=_NextPart_000_0027_01D04C68.83BC7460-- From nobody Thu Feb 19 15:51:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722021A1A5A; Thu, 19 Feb 2015 15:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2SLV_Gs9g-2; Thu, 19 Feb 2015 15:51:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B89291A1A62; Thu, 19 Feb 2015 15:51:20 -0800 (PST) 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: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219235120.29924.63057.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 15:51:20 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 23:51:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks Authors : Bodo Moeller Adam Langley Filename : draft-ietf-tls-downgrade-scsv-05.txt Pages : 8 Date : 2015-02-19 Abstract: This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFC 2246, RFC 4346, RFC 4347, RFC 5246, and RFC 6347. Server update considerations are included. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-downgrade-scsv-05 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 Fri Feb 20 10:45:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE1F1A88AF for ; Fri, 20 Feb 2015 10:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNwewi6cv5vd for ; Fri, 20 Feb 2015 10:45:54 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AD41A883A for ; Fri, 20 Feb 2015 10:45:54 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id a108so15476478qge.7 for ; Fri, 20 Feb 2015 10:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=U2IM3CoFognErfG0k3sCva2ZcC0JVbXfUpogyU0/WUg=; b=t3WBOn3BNtkaeBotYW05IOM9PaEDc55pSnDdGPzphXQuZa29OresFmaXVx6ldNMpO8 t2cDIj5dwkzjDeSgVLU2DMnT4GfLUE46j/wGgKyYQW4dcGxjxyDKb7tQPeuV/yqihCxD XXE9X+YbDaXXG988V95YZxe+/7Y8neMVjjJVhcK8FjzPmn/eByOz3XnmSDIwAoA4mXWZ nW84DAfRKZxIEMzLsMglgVl7e88HQcMnYFhgzv3sahQToC5WUuoFkshwPM1jYRHj83vq eahM1sVZgUgoyIm7Gx9RzXg9LrGlbZ+FCW8+MrAd0vadA2TygmEajenXsB6s5nrH9+G0 yxfg== X-Received: by 10.140.104.228 with SMTP id a91mr25834473qgf.46.1424457953516; Fri, 20 Feb 2015 10:45:53 -0800 (PST) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f20sm5124030qax.37.2015.02.20.10.45.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Feb 2015 10:45:52 -0800 (PST) From: Dave Garrett To: Michael Clark , David Benjamin Date: Fri, 20 Feb 2015 13:45:51 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201412300503.03923.davemgarrett@gmail.com> <201502121714.54235.davemgarrett@gmail.com> <54DD6065.8000205@metaparadigm.com> In-Reply-To: <54DD6065.8000205@metaparadigm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201502201345.51739.davemgarrett@gmail.com> Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] consensus on backwards compatibility changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Feb 2015 18:45:56 -0000 I've made some editorial improvements to PR 107. I've rewritten a few little bits of prior existing text and simplified the sectioning. I've also fixed some section linking. Insecure fallback is now explicitly listed as "NOT RECOMMENDED" as suggested by Michael Clark. https://github.com/tlswg/tls13-spec/pull/107/files There is one new remaining issue to discuss that was brought up by David Benjamin on GitHub. Essentially, we want to make sure that the wording of what versions are to be used in the record layer is precise, including error cases, such that implementations are consistent here. I'd like to see what the opinion of the list is on the topic. Current PR 107 wording for the record layer version field: ------------------------------ TLS clients MUST set this version to { 3, 1 } for the initial ClientHello. For the ServerHello and all other TLS records this MUST be equal to the negotiated version. ------------------------------ My current consideration (not yet in PR): ------------------------------ Prior to version negotiation, this value MUST be { 3, 1 }. This includes the ClientHello, records sent during negotiation, and errors aborting the negotiation. After version negotiation, this MUST be equal to the negotiated version. This includes the ServerHello and all following records. ------------------------------ I explicitly mention records and errors so as to make sure records in EarlyDataExtension are included. Maybe just call it out by name instead? Anyone think of some better wording here? Once we can agree on the wording of this, I think this set of changes should be ready unless someone else has a concern that has not been addressed. Dave From nobody Fri Feb 20 11:04:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A471A0068 for ; Fri, 20 Feb 2015 11:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQCMOuSAPfx9 for ; Fri, 20 Feb 2015 11:04:33 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C295B1A0358 for ; Fri, 20 Feb 2015 11:04:32 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id C0C044015; Fri, 20 Feb 2015 21:04:29 +0200 (EET) Date: Fri, 20 Feb 2015 21:04:29 +0200 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20150220190429.GA32298@LK-Perkele-VII> References: <201412300503.03923.davemgarrett@gmail.com> <201502121714.54235.davemgarrett@gmail.com> <54DD6065.8000205@metaparadigm.com> <201502201345.51739.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201502201345.51739.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] consensus on backwards compatibility changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Feb 2015 19:04:35 -0000 On Fri, Feb 20, 2015 at 01:45:51PM -0500, Dave Garrett wrote: > I've made some editorial improvements to PR 107. I've rewritten a few little bits of prior existing text and simplified the sectioning. I've also fixed some section linking. Insecure fallback is now explicitly listed as "NOT RECOMMENDED" as suggested by Michael Clark. > > https://github.com/tlswg/tls13-spec/pull/107/files > > There is one new remaining issue to discuss that was brought up by David Benjamin on GitHub. Essentially, we want to make sure that the wording of what versions are to be used in the record layer is precise, including error cases, such that implementations are consistent here. I'd like to see what the opinion of the list is on the topic. > > Current PR 107 wording for the record layer version field: > ------------------------------ > TLS clients MUST set this version to { 3, 1 } for the initial ClientHello. > For the ServerHello and all other TLS records this MUST be equal to the negotiated version. > ------------------------------ > > My current consideration (not yet in PR): > ------------------------------ > Prior to version negotiation, this value MUST be { 3, 1 }. This includes the ClientHello, records sent during negotiation, and errors aborting the negotiation. > After version negotiation, this MUST be equal to the negotiated version. This includes the ServerHello and all following records. > ------------------------------ > > I explicitly mention records and errors so as to make sure records in EarlyDataExtension are included. Maybe just call it out by name instead? Anyone think of some better wording here? > > Once we can agree on the wording of this, I think this set of changes should be ready unless someone else has a concern that has not been addressed. > What about HelloRetryRequest? -Ilari From nobody Sat Feb 21 00:03:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882381A1B83 for ; Sat, 21 Feb 2015 00:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8GE7rZF4NYe for ; Sat, 21 Feb 2015 00:03:00 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4371A1B81 for ; Sat, 21 Feb 2015 00:03:00 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id EB6071FE01F0; Sat, 21 Feb 2015 00:02:59 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 21 Feb 2015 00:03:00 -0800 (PST) Message-ID: <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> In-Reply-To: References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> Date: Sat, 21 Feb 2015 00:03:00 -0800 (PST) From: "Dan Harkins" To: Sven =?iso-8859-1?Q?Sch=C3=A4ge?= User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Feb 2015 08:03:02 -0000 Hi Sven, On Thu, February 19, 2015 7:41 am, Sven Schäge wrote: > I was just reading through the TLS-PSK related discussions so far and came > across your post... > > 2014-10-20 14:13 GMT+02:00 Dan Harkins : > >> >> On Sun, October 19, 2014 7:35 am, Yoav Nir wrote: >> > >> > I also understand that in practice, PSK ciphersuites are used only by >> > small devices, whereas the web and SMTP and other things never went >> for >> > it. But the standards don’t say that. They don’t say >> that PSK >> > ciphersuites are especially for constrained devices. So if we insist >> that >> > the same TLS 1.3 be used for both, and we don’t want to say >> that PSK is >> > for weak security, then we should have a good story of why PFS is not >> > needed for PSK uses, whereas it’s essential for all RSA uses. >> If I >> > understand the mechanism correctly, PSKs tend to be long-lived, and a >> > subsequent compromise of a PSK (even if it is expired at the time of >> > compromise) allows an attacker to decrypt the content of a TLS >> session. >> >> The non-PFS PSK ciphersuites are no different than the widely >> discredited, and easily cracked, WPA-PSK mode of WiFi security. It would >> be a really bad idea to continue with these ciphersuites in TLS 1.3. But >> the >> issue is not just PFS (or the lack of it), it's that PSK ciphersuites >> are >> susceptible to dictionary attack. >> >> > So either we believe that PSK compromise is unlikely, or we believe >> that >> > the data in a connection with a PSK ciphersuite is not >> future-sensitive. >> > If we don’t, we’re saying that we’re just piling >> on security >> > nice-to-haves because we think the users can handle them. >> >> There's no way that the protocol can be defined to justify that >> belief. >> What you're talking about is how people end up using the protocol and >> that is entirely out of the power of this WG. What we can do is to make >> TLS be as _misuse resistant_ as possible. And to do that we should not >> allow PSKs in TLS 1.3 unless they are used in a PAKE. >> >> By the way, I'm surprised that no one is expressing outrageous outrage >> at the lack of a security proof for PSK ciphersuites. >> > > Perhaps you might find > > http://eprint.iacr.org/2014/037 > > useful. No, I don't find that particularly useful. It doesn't assume a powerful active attacker that is able to enumerate, off-line, from a database of secrets that the PSK is likely drawn from. It's saying that if only the client and server know the PSK then the resulting secret will be known only to them too which is not useful at all. It places the security of the protocol in the hands of the people using it and that means the protocol can be really secure or not secure at all. And therefore it's not secure at all. It's model is basically, "in an ideal world where no one misuses anything and does nothing wrong and there are no active adversaries trying to subvert anything…." which is not particularly useful. Protocols that use a shared symmetric key/code/word/phrase as a credential should be judged by the criteria set forth here: http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf Namely, "In a protocol we deem 'good' the adversary's chance to defeat protocol goals will depend on how much she interacts with protocol participants-- it won't significantly depend on her off-line computing time." By that criteria, TLS-PSK is not good. regards, Dan. From laurenz.albe@wien.gv.at Mon Feb 23 02:46:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E161A19F4 for ; Mon, 23 Feb 2015 02:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0i1vPMWG40o for ; Mon, 23 Feb 2015 02:46:33 -0800 (PST) Received: from relay-fr112.magwien.gv.at (relay-fr112.magwien.gv.at [217.149.228.141]) (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 00FB41A000A for ; Mon, 23 Feb 2015 02:46:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by relay-fr112.magwien.gv.at (Postfix) with ESMTP id B41AA205B5 for ; Mon, 23 Feb 2015 11:45:37 +0100 (CET) X-Virus-Scanned: by amavisd-new using Sophie and ClamAV at magwien.gv.at Received: from ntex2010j.host.magwien.gv.at (ntex2010j.host.magwien.gv.at [--]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay-fr112.magwien.gv.at (Postfix) with ESMTPS id A24A720598 for ; Mon, 23 Feb 2015 11:45:37 +0100 (CET) Received: from ntex2010i.host.magwien.gv.at ([169.254.2.42]) by ntex2010j.host.magwien.gv.at ([169.254.4.109]) with mapi id 14.03.0210.002; Mon, 23 Feb 2015 11:46:30 +0100 From: Albe Laurenz To: "tls@ietf.org" Thread-Topic: Substitute for renegotiation in TLS 1.3 Thread-Index: AdBPVfr3TMYz4bcwRuSOLkFAobMc+w== Date: Mon, 23 Feb 2015 10:46:29 +0000 Message-ID: Accept-Language: en-US, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [TLS] Substitute for renegotiation in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Feb 2015 10:57:29 -0000 V2hpbGUgcmVzZWFyY2hpbmcgYSByZW5lZ290aWF0aW9uIHByb2JsZW0gSSBzYXcgdGhhdCBUTFMg MS4zIGhhcyBkb25lIGF3YXkNCndpdGggdGhpcyBmZWF0dXJlIGFsdG9nZXRoZXIuDQoNCkR1cmlu ZyB0aGUgZGlzY3Vzc2lvbiB0aGF0IGxlZCB0byB0aGlzDQooaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzEyOTA2Lmh0bWwpDQptb3N0IHBlb3BsZSBz ZWVtZWQgdG8gZmF2b3IgYSBuZXcgInJla2V5IiBmYWNpbGl0eSBhcyBhIHN1YnN0aXR1dGUsDQph bmQgdGhpcyBjb25zZW5zdXMgaXMgZXhwcmVzc2VkIGluDQpodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvdGxzL2N1cnJlbnQvbXNnMTMxNzYuaHRtbA0KDQpJbiBhIGZpcnN0IHRh a2UsIHRoaXMgd2FzIGFjY29tcGxpc2hlZCBieSByZXB1cnBvc2luZyBDaGFuZ2VDaXBoZXJTcGVj DQp0byBjcmVhdGUgYSBuZXcgbWFzdGVyIHNlY3JldDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cxMjYwOS5odG1sDQoNCkhvd2V2ZXIsIGluIGEg bGF0ZXIgY29tbWl0DQooaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvY29tbWl0 LzIxMDk5YmM3ZmYzMzhkOGRlYWU2YzNhZTgzMmYwM2RmZjI5ODQwYzIpDQpDaGFuZ2VDaXBoZXJT cGVjIHdhcyByZW1vdmVkLCBhbmQgSSBjYW4gbmVpdGhlciBmaW5kIHRoZSBkaXNjdXNzaW9uIGxl YWRpbmcNCnRvIHRoYXQgbm9yIGFueSBtZW50aW9uIGluIHRoZSBjb21taXQgaG93ICJyZWtleSIg c2hvdWxkIGJlIGFjY29tcGxpc2hlZCBub3cuDQoNCkRvZXMgdGhhdCBtZWFuIHRoYXQgdGhlcmUg aXMgbm8gcG9zc2liaWxpdHkgdG8gcmVuZWdvdGlhdGUgYW55IG1vcmU/DQpUaGF0IHdvdWxkIGJl IHVuZm9ydHVuYXRlIGZvciBteSB1c2UgY2FzZSAoZW5jcnlwdGVkIGRhdGFiYXNlIGNvbm5lY3Rp b25zIHdoaWNoDQpjYW4gbGFzdCBhcmJpdHJhcmlseSBsb25nKS4NCk1vcmVvdmVyLCBpdCB3b3Vs ZCBnbyBhZ2FpbnN0IHRoZSBjb25zZW5zdXMgb24gdGhlIGxpc3QsIGFzIHF1b3RlIGFib3ZlLg0K DQpZb3VycywNCkxhdXJlbnogQWxiZQ0K From nobody Mon Feb 23 03:45:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907631A1A54 for ; Mon, 23 Feb 2015 03:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1zZMMCHAzQq for ; Mon, 23 Feb 2015 03:45:16 -0800 (PST) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AF31A1A55 for ; Mon, 23 Feb 2015 03:45:15 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 991A9900A0; Mon, 23 Feb 2015 13:45:12 +0200 (EET) Date: Mon, 23 Feb 2015 13:45:11 +0200 From: Ilari Liusvaara To: Albe Laurenz Message-ID: <20150223114511.GA4033@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Substitute for renegotiation in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Feb 2015 11:45:18 -0000 On Mon, Feb 23, 2015 at 10:46:29AM +0000, Albe Laurenz wrote: > While researching a renegotiation problem I saw that TLS 1.3 has done away > with this feature altogether. > > However, in a later commit > (https://github.com/tlswg/tls13-spec/commit/21099bc7ff338d8deae6c3ae832f03dff29840c2) > ChangeCipherSpec was removed, and I can neither find the discussion leading > to that nor any mention in the commit how "rekey" should be accomplished now. > > Does that mean that there is no possibility to renegotiate any more? > That would be unfortunate for my use case (encrypted database connections which > can last arbitrarily long). > Moreover, it would go against the consensus on the list, as quote above. Current editor's copy does not seem to have any way to rekey. However there is PR #94 about adding update protocol that can be used to rekey connections. The other parts of renegotiation are: - Changing server certificate (does not seem useful) - Changing connection parameters (does not seem useful) - Updating authentication (this was later regarded as dangerous). (There is PR #95[2] about "watered down" version of authentication. However I still view this as dangerous[1]). [1] E.g. Try to use it with HTTP/2 mid-connection and watch the things go wrong in possibly exploitable way... In multiplexed protocols, certificate changes need to be coordinated at higher layers. [2] Also, ugh, the PRs building on top of update (update-auth and update-resume) are a bit difficult to read due to duplicating changes later merged into editor's copy. -Ilari From nobody Mon Feb 23 04:39:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302881A1A57 for ; Mon, 23 Feb 2015 04:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLnjq7EzpLfa for ; Mon, 23 Feb 2015 04:39:43 -0800 (PST) Received: from relay-fr112.magwien.gv.at (relay-fr112.magwien.gv.at [217.149.228.141]) (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 E127A1A03A1 for ; Mon, 23 Feb 2015 04:39:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by relay-fr112.magwien.gv.at (Postfix) with ESMTP id E72AB20562; Mon, 23 Feb 2015 13:38:47 +0100 (CET) X-Virus-Scanned: by amavisd-new using Sophie and ClamAV at magwien.gv.at Received: from ntex2010a.host.magwien.gv.at (ntex2010a.host.magwien.gv.at [--]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay-fr112.magwien.gv.at (Postfix) with ESMTPS id 58922205A5; Mon, 23 Feb 2015 13:38:47 +0100 (CET) Received: from ntex2010i.host.magwien.gv.at ([169.254.2.42]) by ntex2010a.host.magwien.gv.at ([169.254.1.26]) with mapi id 14.03.0210.002; Mon, 23 Feb 2015 13:39:40 +0100 From: Albe Laurenz To: Ilari Liusvaara Thread-Topic: [TLS] Substitute for renegotiation in TLS 1.3 Thread-Index: AdBPVfr3TMYz4bcwRuSOLkFAobMc+////6KA///geTA= Date: Mon, 23 Feb 2015 12:39:40 +0000 Message-ID: References: <20150223114511.GA4033@LK-Perkele-VII> In-Reply-To: <20150223114511.GA4033@LK-Perkele-VII> Accept-Language: en-US, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Substitute for renegotiation in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Feb 2015 12:39:44 -0000 SWxhcmkgTGl1c3ZhYXJhIHdyb3RlOg0KPiBPbiBNb24sIEZlYiAyMywgMjAxNSBhdCAxMDo0Njoy OUFNICswMDAwLCBBbGJlIExhdXJlbnogd3JvdGU6DQo+PiBXaGlsZSByZXNlYXJjaGluZyBhIHJl bmVnb3RpYXRpb24gcHJvYmxlbSBJIHNhdyB0aGF0IFRMUyAxLjMgaGFzIGRvbmUgYXdheQ0KPj4g d2l0aCB0aGlzIGZlYXR1cmUgYWx0b2dldGhlci4NCg0KPj4gRG9lcyB0aGF0IG1lYW4gdGhhdCB0 aGVyZSBpcyBubyBwb3NzaWJpbGl0eSB0byByZW5lZ290aWF0ZSBhbnkgbW9yZT8NCj4+IFRoYXQg d291bGQgYmUgdW5mb3J0dW5hdGUgZm9yIG15IHVzZSBjYXNlIChlbmNyeXB0ZWQgZGF0YWJhc2Ug Y29ubmVjdGlvbnMgd2hpY2gNCj4+IGNhbiBsYXN0IGFyYml0cmFyaWx5IGxvbmcpLg0KPj4gTW9y ZW92ZXIsIGl0IHdvdWxkIGdvIGFnYWluc3QgdGhlIGNvbnNlbnN1cyBvbiB0aGUgbGlzdCwgYXMg cXVvdGUgYWJvdmUuDQo+IA0KPiBDdXJyZW50IGVkaXRvcidzIGNvcHkgZG9lcyBub3Qgc2VlbSB0 byBoYXZlIGFueSB3YXkgdG8gcmVrZXkuIEhvd2V2ZXIgdGhlcmUNCj4gaXMgUFIgIzk0IGFib3V0 IGFkZGluZyB1cGRhdGUgcHJvdG9jb2wgdGhhdCBjYW4gYmUgdXNlZCB0byByZWtleQ0KPiBjb25u ZWN0aW9ucy4NCg0KVGhhbmtzIGZvciB0aGUgYW5zd2VyLg0KU28gdGhpcyBpcyBzdGlsbCB3b3Jr IGluIHByb2dyZXNzLCBhbmQgSSBzaG91bGRuJ3Qgd29ycnkgdGhhdCB0aGlzDQpjYXBhYmlsaXR5 IHdpbGwgYmUgbG9zdCBpbiBUTFMgMS4zLg0KDQpZb3VycywNCkxhdXJlbnogQWxiZQ0K From nobody Mon Feb 23 06:55:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782C21A00EC for ; Mon, 23 Feb 2015 06:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nds99QE8kjBV for ; Mon, 23 Feb 2015 06:55:37 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B7B1A1A1D for ; Mon, 23 Feb 2015 06:55:36 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-53-54eb3f67d032 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.6A.04231.76F3BE45; Mon, 23 Feb 2015 15:55:35 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.112]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Mon, 23 Feb 2015 15:55:34 +0100 From: John Mattsson To: Dan Harkins Thread-Topic: [TLS] PSK in 1.3? Thread-Index: AQHQTazXvws9Rg+evUOpC4fBWiiT/Jz+RW8A Date: Mon, 23 Feb 2015 14:55:34 +0000 Message-ID: <17E2EE73-7048-4553-A08A-45D0DB34A88C@ericsson.com> References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> In-Reply-To: <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_17E2EE7370484553A08A45D0DB34A88Cericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+JvjW66/esQgxsfBSyW/vvCYtH2ooXJ 4tP5LkYHZo8lS34yeTzb/ZLF49HsO0wBzFFcNimpOZllqUX6dglcGdvXahT0/GOs+LtPqoHx ym3GLkZODgkBE4lj61awQdhiEhfurQeyuTiEBI4wSizY/YwVwlnCKLG2bzorSBWbgIHE3D0N YB0iAqoSR9/NZgexmQViJP4dXAMU5+AQFpCTuDOtBKJEXuLMtpusIGERASOJ+d8rQcIsQJ3z W5cwg9i8AvYSm1c/Y4FY9YdJYu6m1UwgCU4Bb4mrn/eDrWIEOu77qTVMEKvEJW49mc8EcbSA xJI955khbFGJl4//ge2SEFCSmLY1DaI8WaJhXTs7xC5BiZMzn7BMYBSdhWTSLCRls5CUQcT1 JG5MncIGYWtLLFv4mhnC1pWY8e8QVI21xMM9XYzIahYwcqxiFC1OLS7OTTcy1kstykwuLs7P 08tLLdnECIzMg1t+6+5gXP3a8RCjAAejEg/vhumvQoRYE8uKK3MPMUpzsCiJ89oZHwoREkhP LEnNTk0tSC2KLyrNSS0+xMjEwQmMQ7Xt5/d9KrENjF4aen95uzBjz8SpMU+eqTuzRu+/VB0T vaFq+oeLvLXNrmUePs+7HMQ/dqTah07+a7s978GsN3fqr298dan3+vPO51Xpx1Q3slt9vHtn q2hAavGDsAlmioWKP2ctLduzz+bLPs8l3/9u7j2st3Kves2/o8dz3vK5zy2v//A7WEyJpTgj 0VCLuag4EQAc3Zg2rQIAAA== Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Feb 2015 14:55:40 -0000 --_000_17E2EE7370484553A08A45D0DB34A88Cericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, PSK cipher suites are not only used by small devices. They are well used (b= y e.g. 3GPP) for both terminal <-> server as well as server <-> server comm= unication. Seems to be confusion about PSK and passwords in the discussion. Passwords = are generated by humans, offer low entropy and are weak. PSKs are not gener= ated by humans, offers good entropy and are not weak. Any PSK or RSA implementation that correctly used a good PRNG would not be = susceptible to dictionary attacks. E.g. TLS_DHE_PSK_WITH_AES_128_GCM_SHA256= is a perfectly fine cipher suite. Non-PSF PSK has the same weaknesses as Non-PSF RSA. I think the authenticat= ion and key agreement discussions should be separated. /John On 21 Feb 2015, at 09:03, Dan Harkins > wrote: Hi Sven, On Thu, February 19, 2015 7:41 am, Sven Sch=C3=A4ge wrote: I was just reading through the TLS-PSK related discussions so far and came across your post... 2014-10-20 14:13 GMT+02:00 Dan Harkins >: On Sun, October 19, 2014 7:35 am, Yoav Nir wrote: I also understand that in practice, PSK ciphersuites are used only by small devices, whereas the web and SMTP and other things never went for it. But the standards don=C3=A2=E2,=AC=E2"=A2t say that. They don=C3=A2=E2,= =AC=E2"=A2t say that PSK ciphersuites are especially for constrained devices. So if we insist that the same TLS 1.3 be used for both, and we don=C3=A2=E2,=AC=E2"=A2t want to = say that PSK is for weak security, then we should have a good story of why PFS is not needed for PSK uses, whereas it=C3=A2=E2,=AC=E2"=A2s essential for all RSA = uses. If I understand the mechanism correctly, PSKs tend to be long-lived, and a subsequent compromise of a PSK (even if it is expired at the time of compromise) allows an attacker to decrypt the content of a TLS session. The non-PFS PSK ciphersuites are no different than the widely discredited, and easily cracked, WPA-PSK mode of WiFi security. It would be a really bad idea to continue with these ciphersuites in TLS 1.3. But the issue is not just PFS (or the lack of it), it's that PSK ciphersuites are susceptible to dictionary attack. So either we believe that PSK compromise is unlikely, or we believe that the data in a connection with a PSK ciphersuite is not future-sensitive. If we don=C3=A2=E2,=AC=E2"=A2t, we=C3=A2=E2,=AC=E2"=A2re saying that we=C3= =A2=E2,=AC=E2"=A2re just piling on security nice-to-haves because we think the users can handle them. There's no way that the protocol can be defined to justify that belief. What you're talking about is how people end up using the protocol and that is entirely out of the power of this WG. What we can do is to make TLS be as _misuse resistant_ as possible. And to do that we should not allow PSKs in TLS 1.3 unless they are used in a PAKE. By the way, I'm surprised that no one is expressing outrageous outrage at the lack of a security proof for PSK ciphersuites. Perhaps you might find http://eprint.iacr.org/2014/037 useful. No, I don't find that particularly useful. It doesn't assume a powerful active attacker that is able to enumerate, off-line, from a database of secrets that the PSK is likely drawn from. It's saying that if only the client and server know the PSK then the resulting secret will be known only to them too which is not useful at all. It places the security of the protocol in the hands of the people using it and that means the protocol can be really secure or not secure at all. And therefore it's not secure at all. It's model is basically, "in an ideal world where no one misuses anything and does nothing wrong and there are no active adversaries trying to subvert anything.." which is not particularly useful. Protocols that use a shared symmetric key/code/word/phrase as a credential should be judged by the criteria set forth here: http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf Namely, "In a protocol we deem 'good' the adversary's chance to defeat protocol goals will depend on how much she interacts with protocol participants-- it won't significantly depend on her off-line computing time." By that criteria, TLS-PSK is not good. regards, Dan. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_17E2EE7370484553A08A45D0DB34A88Cericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <284CB370753A9640AB0A43930F627DA2@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

PSK cipher suites are not only used by small devices= . They are well used (by e.g. 3GPP) for both terminal <-> server as w= ell as server <-> server communication. 

Seems to be confusion about PSK and passwords in the= discussion. Passwords are generated by humans, offer low entropy and are w= eak. PSKs are not generated by humans, offers good entropy and are not weak= .

Any PSK or RSA implementation that correctly used a = good PRNG would not be susceptible to dictionary attacks. E.g. TLS_DHE_PSK_= WITH_AES_128_GCM_SHA256 is a perfectly fine cipher suite.

Non-PSF PSK has the same weaknesses as Non-PSF RSA. = I think the authentication and key agreement discussions should be separate= d.

/John


On 21 Feb 2015, at 09:03, Dan Harkins <dharkins@lounge.org> wrote:


 Hi Sven,

On Thu, February 19, 2015 7:41 am, Sven Sch=C3=A4ge wrote:
I was just reading through the TLS-PSK= related discussions so far and came
across your post...

2014-10-20 14:13 GMT+02:00 Dan Harkins <dharkins@lounge.org>:


On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:

I also understand that in practice, PSK ciphersuites are used only by
small devices, whereas the web and SMTP and other things never went
for
it. But the standards don=C3=A2=E2,=AC= =E2"=A2t say that. They don=C3=A2=E2,=AC=E2"=A2t say
that PSK
ciphersuites are especially for constr= ained devices. So if we insist
that
the same TLS 1.3 be used for both, and= we don=C3=A2=E2,=AC=E2"=A2t want to say
that PSK is
for weak security, then we should have= a good story of why PFS is not
needed for PSK uses, whereas it=C3=A2=E2,=AC=E2"=A2s essential for all= RSA uses.
If I
understand the mechanism correctly, PS= Ks tend to be long-lived, and a
subsequent compromise of a PSK (even if it is expired at the time of
compromise) allows an attacker to decrypt the content of a TLS
session.

 The non-PFS PSK ciphersuites are no different than the widely
discredited, and easily cracked, WPA-PSK mode of WiFi security. It would be a really bad idea to continue with these ciphersuites in TLS 1.3. But the
issue is not just PFS (or the lack of it), it's that PSK ciphersuites
are
susceptible to dictionary attack.

So either we believe that PSK compromi= se is unlikely, or we believe
that
the data in a connection with a PSK ci= phersuite is not
future-sensitive.
If we don=C3=A2=E2,=AC=E2"=A2t, w= e=C3=A2=E2,=AC=E2"=A2re saying that we=C3=A2=E2,=AC=E2"=A2re just= piling
on security
nice-to-haves because we think the use= rs can handle them.

 There's no way that the protocol can be defined to justify that
belief.
What you're talking about is how people end up using the protocol and
that is entirely out of the power of this WG. What we can do is to make
TLS be as _misuse resistant_ as possible. And to do that we should not
allow PSKs in TLS 1.3 unless they are used in a PAKE.

 By the way, I'm surprised that no one is expressing outrageous outrag= e
at the lack of a security proof for PSK ciphersuites.


Perhaps you might find

http://eprint.iacr.o= rg/2014/037

useful.

 No, I don't find that particularly useful. It doesn't assume a powerf= ul
active attacker that is able to enumerate, off-line, from a database of
secrets that the PSK is likely drawn from. It's saying that if only the
client
and server know the PSK then the resulting secret will be known only to
them too which is not useful at all. It places the security of the protocol=
in the hands of the people using it and that means the protocol can be
really secure or not secure at all. And therefore it's not secure at all.
 It's model is basically, "in an ideal world where no one misuses=
anything and does nothing wrong and there are no active adversaries
trying to subvert anything.." which is not particularly useful.

 Protocols that use a shared symmetric key/code/word/phrase as a
credential should be judged by the criteria set forth here:

http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf=

Namely, "In a protocol we deem 'good' the adversary's chance to defeat=
protocol goals will depend on how much she interacts with protocol
participants-- it won't significantly depend on her off-line computing
time." By that criteria, TLS-PSK is not good.

 regards,

 Dan.


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

--_000_17E2EE7370484553A08A45D0DB34A88Cericssoncom_-- From nobody Mon Feb 23 08:03:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D7B1A0318 for ; Sat, 21 Feb 2015 00:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZF53oLcShMP for ; Sat, 21 Feb 2015 00:46:00 -0800 (PST) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3546C1A0282 for ; Sat, 21 Feb 2015 00:46:00 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YP5hD-0006De-E3 for tls@ietf.org; Sat, 21 Feb 2015 09:45:55 +0100 Received: from 66-87-139-69.pools.spcsdns.net ([66-87-139-69.pools.spcsdns.net]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Feb 2015 09:45:55 +0100 Received: from eternaleye by 66-87-139-69.pools.spcsdns.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Feb 2015 09:45:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Alex Elsayed Date: Sat, 21 Feb 2015 00:45:45 -0800 Lines: 137 Message-ID: References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 66-87-139-69.pools.spcsdns.net User-Agent: KNode/4.14.3 Archived-At: X-Mailman-Approved-At: Mon, 23 Feb 2015 08:03:02 -0800 Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Feb 2015 08:46:02 -0000 Dan Harkins wrote: > > Hi Sven, > > On Thu, February 19, 2015 7:41 am, Sven Schäge wrote: >> I was just reading through the TLS-PSK related discussions so far and >> came across your post... >> >> 2014-10-20 14:13 GMT+02:00 Dan Harkins : >> >>> >>> On Sun, October 19, 2014 7:35 am, Yoav Nir wrote: >>> > >>> > I also understand that in practice, PSK ciphersuites are used only by >>> > small devices, whereas the web and SMTP and other things never went >>> for >>> > it. But the standards donĂ¢â‚¬â„¢t say that. They donĂ¢â‚¬â„¢t say >>> that PSK >>> > ciphersuites are especially for constrained devices. So if we insist >>> that >>> > the same TLS 1.3 be used for both, and we donĂ¢â‚¬â„¢t want to say >>> that PSK is >>> > for weak security, then we should have a good story of why PFS is not >>> > needed for PSK uses, whereas itĂ¢â‚¬â„¢s essential for all RSA uses. >>> If I >>> > understand the mechanism correctly, PSKs tend to be long-lived, and a >>> > subsequent compromise of a PSK (even if it is expired at the time of >>> > compromise) allows an attacker to decrypt the content of a TLS >>> session. >>> >>> The non-PFS PSK ciphersuites are no different than the widely >>> discredited, and easily cracked, WPA-PSK mode of WiFi security. It would >>> be a really bad idea to continue with these ciphersuites in TLS 1.3. But >>> the >>> issue is not just PFS (or the lack of it), it's that PSK ciphersuites >>> are >>> susceptible to dictionary attack. >>> >>> > So either we believe that PSK compromise is unlikely, or we believe >>> that >>> > the data in a connection with a PSK ciphersuite is not >>> future-sensitive. >>> > If we donĂ¢â‚¬â„¢t, weĂ¢â‚¬â„¢re saying that weĂ¢â‚¬â„¢re just piling >>> on security >>> > nice-to-haves because we think the users can handle them. >>> >>> There's no way that the protocol can be defined to justify that >>> belief. >>> What you're talking about is how people end up using the protocol and >>> that is entirely out of the power of this WG. What we can do is to make >>> TLS be as _misuse resistant_ as possible. And to do that we should not >>> allow PSKs in TLS 1.3 unless they are used in a PAKE. >>> >>> By the way, I'm surprised that no one is expressing outrageous outrage >>> at the lack of a security proof for PSK ciphersuites. >>> >> >> Perhaps you might find >> >> http://eprint.iacr.org/2014/037 >> >> useful. > > No, I don't find that particularly useful. It doesn't assume a powerful > active attacker that is able to enumerate, off-line, from a database of > secrets that the PSK is likely drawn from. Sure, if they draw them from a database. Which would be about as stupid as choosing an RSA key from the Debian weak-keys bug, or doing ECDSA signatures with the same nonce every time, or similar boneheaded maneuvers that invalidate the protocol guarantees. It's not the "pre-shared password" protocol, or even "pre-shared passphrase." It's "pre-shared key," and as such it should be used with a _proper key_ - that is to say, a string chosen uniformly at random from {0,1}^n where 'n' is the key size. > It's saying that if only the client and server know the PSK then the > resulting secret will be known only to them too Yes. That is the guarantee the protocol gives. > which is not useful at all. It places the security of the > protocol in the hands of the people using it and that means the protocol > can be really secure or not secure at all. But this is specious, because it's just as true of any number of other protocols - ECDSA's nonces being a particularly notable example. Reuse them, and you're leaking key bits like a firehose full of porcupines. Sony learned that the hard way. Sure, I think easily-misused APIs are better avoided - but I also feel you are drastically overstating your case, and weakening it by doing so. When faced with people having said multiple times that 'drawing from a database' is user error and an invalid use of the protocol, it comes across as either obtuse or intellectually dishonest - neither of which I believe you are. > And therefore it's not secure at all. Then we really ought to stop using ECDSA... pretty much anywhere, since its nonces require much the same care. > It's model is basically, "in an ideal world where no one misuses > anything and does nothing wrong and there are no active adversaries > trying to subvert anythingÂ…." which is not particularly useful. No, its model is "For shared keys drawn uniformly from {0,1}^n, this is secure". Active adversaries have nothing to do with it, so long as the user fulfils their side of the API contract. > Protocols that use a shared symmetric key/code/word/phrase as a > credential should be judged by the criteria set forth here: > > http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf > > Namely, "In a protocol we deem 'good' the adversary's chance to defeat > protocol goals will depend on how much she interacts with protocol > participants-- it won't significantly depend on her off-line computing > time." By that criteria, TLS-PSK is not good. ...no, if the user isn't screwing up in much the same kind of way as would lead them to horrific misuse of ECDSA, TLS-PSK is just fine. I'm not saying PSK is ideal - it's patently not. A misuse-resistant protocol *that meets the needs of the people using PSK* would be wonderful to have. But claiming it's worse than it is just makes people who see it as their only option feel more pressed to defend it, rather than actually helping to move the discussion forward on finding a viable alternative. > regards, > > Dan. From nobody Mon Feb 23 08:35:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B461A1B9E for ; Mon, 23 Feb 2015 08:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_pSTlTEDyIL for ; Mon, 23 Feb 2015 08:35:42 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6062D1A1B7B for ; Mon, 23 Feb 2015 08:35:41 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 06F0610224008; Mon, 23 Feb 2015 08:35:41 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 23 Feb 2015 08:35:41 -0800 (PST) Message-ID: <92be51f3c17267a19919fa3ce559dbb8.squirrel@www.trepanning.net> In-Reply-To: <17E2EE73-7048-4553-A08A-45D0DB34A88C@ericsson.com> References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <17E2EE73-7048-4553-A08A-45D0DB34A88C@ericsson.com> Date: Mon, 23 Feb 2015 08:35:41 -0800 (PST) From: "Dan Harkins" To: "John Mattsson" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Feb 2015 16:35:49 -0000 Hi John, On Mon, February 23, 2015 6:55 am, John Mattsson wrote: > Hi, > PSK cipher suites are not only used by small devices. They are well used > (by e.g. 3GPP) for both terminal <-> server as well as server <-> server > communication. > Seems to be confusion about PSK and passwords in the discussion. Passwords > are generated by humans, offer low entropy and are weak. PSKs are not > generated by humans, offers good entropy and are not weak. > Any PSK or RSA implementation that correctly used a good PRNG would not be > susceptible to dictionary attacks. E.g. > TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 is a perfectly fine cipher suite. There is no confusion (at least on my part). I think the confusion is that you think that merely by naming ("this is a password", "this is a PSK") the credential used you can make "a perfectly fine cipher suite." A dictionary attack is one in which the advantage gained by the adversary is a function of computation and not interaction. It says nothing about the size, or make up, of the pool from which the shared credential was drawn. A good PRNG just ensures that each credential in the pool has an equally good chance of being chosen. If the protocol you use the shared credential with is susceptible to an attack whose success depends on computation and not interaction with protocol participants than it's susceptible to a dictionary attack. Now, granted, a pool that consisted of words from Webster's starting with the letter "a" would be much smaller than a pool consisting of numbers between 0 and 2^128 and a dictionary attack against the former would, with high probability, return success faster than a dictionary attack against the latter but the attack is identical. Increasing the size of the pool from which the credential was drawn makes a dictionary attack take longer (and possibly prohibitively so) but it doesn't magically make the protocol somehow resistant to dictionary attack. > Non-PSF PSK has the same weaknesses as Non-PSF RSA. I think the > authentication and key agreement discussions should be separated. Key establishment and authentication go hand-in-hand. They have to. And the issue is not key establishment versus authentication, it's misuse resistance. PSKs are not misuse resistant, PAKEs are. And that is because, regardless of the size of the pool from which the shared credential was drawn, a dictionary attack (as defined above) is not possible. Dan. > /John > > On 21 Feb 2015, at 09:03, Dan Harkins > > wrote: > > > Hi Sven, > > On Thu, February 19, 2015 7:41 am, Sven Schäge wrote: > I was just reading through the TLS-PSK related discussions so far and came > across your post... > > 2014-10-20 14:13 GMT+02:00 Dan Harkins > >: > > > On Sun, October 19, 2014 7:35 am, Yoav Nir wrote: > > I also understand that in practice, PSK ciphersuites are used only by > small devices, whereas the web and SMTP and other things never went > for > it. But the standards donââ,¬â"˘t say that. They donââ,¬â"˘t say > that PSK > ciphersuites are especially for constrained devices. So if we insist > that > the same TLS 1.3 be used for both, and we donââ,¬â"˘t want to say > that PSK is > for weak security, then we should have a good story of why PFS is not > needed for PSK uses, whereas itââ,¬â"˘s essential for all RSA uses. > If I > understand the mechanism correctly, PSKs tend to be long-lived, and a > subsequent compromise of a PSK (even if it is expired at the time of > compromise) allows an attacker to decrypt the content of a TLS > session. > > The non-PFS PSK ciphersuites are no different than the widely > discredited, and easily cracked, WPA-PSK mode of WiFi security. It would > be a really bad idea to continue with these ciphersuites in TLS 1.3. But > the > issue is not just PFS (or the lack of it), it's that PSK ciphersuites > are > susceptible to dictionary attack. > > So either we believe that PSK compromise is unlikely, or we believe > that > the data in a connection with a PSK ciphersuite is not > future-sensitive. > If we donââ,¬â"˘t, weââ,¬â"˘re saying that weââ,¬â"˘re just piling > on security > nice-to-haves because we think the users can handle them. > > There's no way that the protocol can be defined to justify that > belief. > What you're talking about is how people end up using the protocol and > that is entirely out of the power of this WG. What we can do is to make > TLS be as _misuse resistant_ as possible. And to do that we should not > allow PSKs in TLS 1.3 unless they are used in a PAKE. > > By the way, I'm surprised that no one is expressing outrageous outrage > at the lack of a security proof for PSK ciphersuites. > > > Perhaps you might find > > http://eprint.iacr.org/2014/037 > > useful. > > No, I don't find that particularly useful. It doesn't assume a powerful > active attacker that is able to enumerate, off-line, from a database of > secrets that the PSK is likely drawn from. It's saying that if only the > client > and server know the PSK then the resulting secret will be known only to > them too which is not useful at all. It places the security of the > protocol > in the hands of the people using it and that means the protocol can be > really secure or not secure at all. And therefore it's not secure at all. > > It's model is basically, "in an ideal world where no one misuses > anything and does nothing wrong and there are no active adversaries > trying to subvert anything.." which is not particularly useful. > > Protocols that use a shared symmetric key/code/word/phrase as a > credential should be judged by the criteria set forth here: > > http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf > > Namely, "In a protocol we deem 'good' the adversary's chance to defeat > protocol goals will depend on how much she interacts with protocol > participants-- it won't significantly depend on her off-line computing > time." By that criteria, TLS-PSK is not good. > > regards, > > Dan. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Mon Feb 23 09:34:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50DA1A1B7F for ; Mon, 23 Feb 2015 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpWV64ktyoxL for ; Mon, 23 Feb 2015 09:34:09 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D8A8D1A1BCB for ; Mon, 23 Feb 2015 09:34:08 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3E8BB10224008; Mon, 23 Feb 2015 09:34:08 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 23 Feb 2015 09:34:08 -0800 (PST) Message-ID: <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> In-Reply-To: References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> Date: Mon, 23 Feb 2015 09:34:08 -0800 (PST) From: "Dan Harkins" To: "Alex Elsayed" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Feb 2015 17:34:12 -0000 Hi Alex, On Sat, February 21, 2015 12:45 am, Alex Elsayed wrote: > Dan Harkins wrote: > >> >> Hi Sven, >> >> On Thu, February 19, 2015 7:41 am, Sven Schäge wrote: >>> I was just reading through the TLS-PSK related discussions so far and >>> came across your post... >>> >>> 2014-10-20 14:13 GMT+02:00 Dan Harkins : >>> >>>> >>>> On Sun, October 19, 2014 7:35 am, Yoav Nir wrote: >>>> > >>>> > I also understand that in practice, PSK ciphersuites are used only >>>> by >>>> > small devices, whereas the web and SMTP and other things never went >>>> for >>>> > it. But the standards donĂ¢â‚¬â„¢t say that. They >>>> donĂ¢â‚¬â„¢t say >>>> that PSK >>>> > ciphersuites are especially for constrained devices. So if we insist >>>> that >>>> > the same TLS 1.3 be used for both, and we donĂ¢â‚¬â„¢t want >>>> to say >>>> that PSK is >>>> > for weak security, then we should have a good story of why PFS is >>>> not >>>> > needed for PSK uses, whereas itĂ¢â‚¬â„¢s essential for all >>>> RSA uses. >>>> If I >>>> > understand the mechanism correctly, PSKs tend to be long-lived, and >>>> a >>>> > subsequent compromise of a PSK (even if it is expired at the time of >>>> > compromise) allows an attacker to decrypt the content of a TLS >>>> session. >>>> >>>> The non-PFS PSK ciphersuites are no different than the widely >>>> discredited, and easily cracked, WPA-PSK mode of WiFi security. It >>>> would >>>> be a really bad idea to continue with these ciphersuites in TLS 1.3. >>>> But >>>> the >>>> issue is not just PFS (or the lack of it), it's that PSK ciphersuites >>>> are >>>> susceptible to dictionary attack. >>>> >>>> > So either we believe that PSK compromise is unlikely, or we believe >>>> that >>>> > the data in a connection with a PSK ciphersuite is not >>>> future-sensitive. >>>> > If we donĂ¢â‚¬â„¢t, weĂ¢â‚¬â„¢re saying that >>>> weĂ¢â‚¬â„¢re just piling >>>> on security >>>> > nice-to-haves because we think the users can handle them. >>>> >>>> There's no way that the protocol can be defined to justify that >>>> belief. >>>> What you're talking about is how people end up using the protocol and >>>> that is entirely out of the power of this WG. What we can do is to >>>> make >>>> TLS be as _misuse resistant_ as possible. And to do that we should not >>>> allow PSKs in TLS 1.3 unless they are used in a PAKE. >>>> >>>> By the way, I'm surprised that no one is expressing outrageous >>>> outrage >>>> at the lack of a security proof for PSK ciphersuites. >>>> >>> >>> Perhaps you might find >>> >>> http://eprint.iacr.org/2014/037 >>> >>> useful. >> >> No, I don't find that particularly useful. It doesn't assume a >> powerful >> active attacker that is able to enumerate, off-line, from a database of >> secrets that the PSK is likely drawn from. > > Sure, if they draw them from a database. Which would be about as stupid as > choosing an RSA key from the Debian weak-keys bug, or doing ECDSA > signatures > with the same nonce every time, or similar boneheaded maneuvers that > invalidate the protocol guarantees. > > It's not the "pre-shared password" protocol, or even "pre-shared > passphrase." It's "pre-shared key," and as such it should be used with a > _proper key_ - that is to say, a string chosen uniformly at random from > {0,1}^n where 'n' is the key size. Then your "database" is all numbers between 0 and 2^n. And you randomly draw from that database. >> It's saying that if only the client and server know the PSK then the >> resulting secret will be known only to them too > > Yes. That is the guarantee the protocol gives. > >> which is not useful at all. It places the security of the >> protocol in the hands of the people using it and that means the protocol >> can be really secure or not secure at all. > > But this is specious, because it's just as true of any number of other > protocols - ECDSA's nonces being a particularly notable example. Reuse > them, > and you're leaking key bits like a firehose full of porcupines. Sony > learned > that the hard way. Yes, ECDSA has a misuse-resistance problem. Happily, that can be hidden from "Joe Random, user of TLS" in a fashion that the PSK problem cannot. > Sure, I think easily-misused APIs are better avoided - but I also feel you > are drastically overstating your case, and weakening it by doing so. When > faced with people having said multiple times that 'drawing from a > database' > is user error and an invalid use of the protocol, it comes across as > either > obtuse or intellectually dishonest - neither of which I believe you are. Thanks. But by equating misuse resistance problems with a PSK with misuse resistance problems with ECDSA you are "drastically overstating your case and weakening it by doing so". "Drawing from a database" is not user error. Every PSK is drawn from a database. You are just playing a semantic game by saying that if n is less than some arbitrary number (which you don't define) then it's a "dictionary" or "database" and if n is larger than some other arbitrary number (which you also don't define) then it's not. >> And therefore it's not secure at all. > > Then we really ought to stop using ECDSA... pretty much anywhere, since > its > nonces require much the same care. Uhm, no. The nonce in ECDSA needs to be unique per signature. The user has no ability to influence this in a general purpose TLS library. Whereas the PSK has to be plumbed, by the user, into the TLS library, thereby opening up the misuse resistance can. >> It's model is basically, "in an ideal world where no one misuses >> anything and does nothing wrong and there are no active adversaries >> trying to subvert anythingÂ…." which is not particularly useful. > > No, its model is "For shared keys drawn uniformly from {0,1}^n, this is > secure". No, it's not. If n=8 then the attack is trivial and succeeds almost instantaneously. If n=128 then with high probability a dictionary attack will not be successful. But in neither case is that "secure". > Active adversaries have nothing to do with it, so long as the user fulfils > their side of the API contract. Active adversaries are the ones launching the attack. They have very much to do with it! >> Protocols that use a shared symmetric key/code/word/phrase as a >> credential should be judged by the criteria set forth here: >> >> http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf >> >> Namely, "In a protocol we deem 'good' the adversary's chance to defeat >> protocol goals will depend on how much she interacts with protocol >> participants-- it won't significantly depend on her off-line computing >> time." By that criteria, TLS-PSK is not good. > > ...no, if the user isn't screwing up in much the same kind of way as would > lead them to horrific misuse of ECDSA, TLS-PSK is just fine. > > I'm not saying PSK is ideal - it's patently not. A misuse-resistant > protocol > *that meets the needs of the people using PSK* would be wonderful to have. And those needs are what? Plumbing the PSK into TLS via some API call or some UI. Which can be easily handled by a misuse-resistant PAKE. In fact, the change from PSK cipher suite to PAKE cipher suite would not be apparent from the point-of-view of "the needs of people using PSK." > But claiming it's worse than it is just makes people who see it as their > only option feel more pressed to defend it, rather than actually helping > to > move the discussion forward on finding a viable alternative. A viable alternative is TLS-SRP. Or TLS-pwd. Since there is no augmentation involved in the latter, it could be swapped in place of your favorite PSK cipher suite and you'd be none the wiser-- plumb the key, hey it works! regards, Dan. From nobody Mon Feb 23 11:16:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2F1A3BA0 for ; Mon, 23 Feb 2015 11:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3x6uZ696XvK for ; Mon, 23 Feb 2015 11:16:10 -0800 (PST) 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 295391A6EDA for ; Mon, 23 Feb 2015 11:16:07 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 231A6282F52; Mon, 23 Feb 2015 19:16:06 +0000 (UTC) Date: Mon, 23 Feb 2015 19:16:06 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150223191605.GM1260@mournblade.imrryr.org> References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 19:16:11 -0000 On Mon, Feb 23, 2015 at 09:34:08AM -0800, Dan Harkins wrote: > "Drawing from a database" is not user error. Every PSK is drawn from > a database. You are just playing a semantic game by saying that if > n is less than some arbitrary number (which you don't define) then it's > a "dictionary" or "database" and if n is larger than some other arbitrary > number (which you also don't define) then it's not. Every AES-128 key is drawn from a database: [0, 2^128-1] Every AES-256 key is drawn from a database: [0, 2^256-1] > No, it's not. If n=8 then the attack is trivial and succeeds almost > instantaneously. If n=128 then with high probability a dictionary attack > will not be successful. But in neither case is that "secure". The PSK is secure once the search cost for the PSK exceeds the cost of brute-forcing the key of the agreed TLS symmetric algorithm. One time pads aside, there are no absolutely "secure" crypto-systems, all practical cryptography assumes a resource-bounded adversary. So a 128-bit (uniformly randomly chosen) PSK used to negotiate an AES-128 key is "secure". So the argument seems to boil down to whether TLS should banish a key management approach that can be fragile in the hands of naive users, but can in fact be used "securely" when practiced properly. Whether misuse of PSK is particularly more likely than various other lapses (say unwitting deployment of MiTM root CAs) is not obvious. Far too few products get the security scrutiny they deserve. Device vendors will always find a way to ship gear with weak factory security settings, whether PAKE, PSK, SSH keys, stock RSA keys, ... I am very much sympathetic to the advantages of PAKE over PSK when one of the key stores is a human brain, or people are involved in the process of generating and distributing the shared secrets. I am not sure that this is sufficient grounds to rule out PSK, or that doing so substantially addresses poor key management practices. -- Viktor. From nobody Mon Feb 23 12:56:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41D61A6F03 for ; Mon, 23 Feb 2015 12:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFRHyMncksp3 for ; Mon, 23 Feb 2015 12:55:53 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13131A6F01 for ; Mon, 23 Feb 2015 12:55:52 -0800 (PST) Received: by qcxm20 with SMTP id m20so13241206qcx.0 for ; Mon, 23 Feb 2015 12:55:52 -0800 (PST) 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:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Ju29lGL7IFi1Spb9hJ5uuXDtZ/XtTTvevXRT3zeOg58=; b=gLbXPr+nsjr2ri8Sxe0tDq6FbK3EqHSik5+8bFIMDbG+xR/4c8RTTtsKRBMfRCXv2B kiGoChvLTXsHvziKZ1dk69/pA2ESuTwrLlXkROMDEPH2nAO489aM263B6X9emrs+SEdV Ie1ZeR2CKQj2VORO6hraFMUpp+3eQ9gkz4fo1+0/Y3hKGU4neSTXbxXKUbSb99q4PU/7 UtXSwseUL/PwPL+DCf56XulGHj8IQo9SEFG1hDd1ts3EWUEq8w0ZZ7+xF3Gm+zdbGDQG HnGYITNBaXX7QFgeS3TKd/+Fyk+oAdyjiy61U5AlRvBZIO6x6fEQ/CE8kIpBoHCWEAZ2 KHaw== X-Gm-Message-State: ALoCoQlYzjdSbzkPQiMz2yiGDP1N15kGC+xlrQEvReAX4nDonC4L4W7H0ZmLPGbExf6MY3eyPUJ4 X-Received: by 10.229.4.4 with SMTP id 4mr29181504qcp.8.1424724952053; Mon, 23 Feb 2015 12:55:52 -0800 (PST) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id r10sm28307267qax.31.2015.02.23.12.55.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 12:55:50 -0800 (PST) Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 1E132AC287E; Mon, 23 Feb 2015 15:55:48 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=iso-8859-1 From: Stephen Checkoway X-Priority: 3 (Normal) In-Reply-To: <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> Date: Mon, 23 Feb 2015 15:55:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Alex Elsayed , tls@ietf.org Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Feb 2015 20:56:08 -0000 On Feb 23, 2015, at 12:34 PM, Dan Harkins wrote: > On Sat, February 21, 2015 12:45 am, Alex Elsayed wrote: >> No, its model is "For shared keys drawn uniformly from {0,1}^n, this = is >> secure". >=20 > No, it's not. If n=3D8 then the attack is trivial and succeeds almost > instantaneously. If n=3D128 then with high probability a dictionary = attack > will not be successful. But in neither case is that "secure". What is your definition of secure then? If drawing uniformly at random from {0,1}^n is not secure for any n, = then doesn't that say that there is no way to use TLS securely? The = master secret is merely a number in {0,1}^384, after all. And common = (EC)DHE key exchanges involve a secret in {0,1}^n for n in [160, 256]. --=20 Stephen Checkoway From nobody Mon Feb 23 16:06:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D436A1A1A80 for ; Mon, 23 Feb 2015 16:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnfHk3q8bV5i for ; Mon, 23 Feb 2015 16:06:52 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D1A761A1A79 for ; Mon, 23 Feb 2015 16:06:52 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2D36F10224008; Mon, 23 Feb 2015 16:06:52 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 23 Feb 2015 16:06:52 -0800 (PST) Message-ID: In-Reply-To: References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> Date: Mon, 23 Feb 2015 16:06:52 -0800 (PST) From: "Dan Harkins" To: "Stephen Checkoway" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 00:06:54 -0000 On Mon, February 23, 2015 12:55 pm, Stephen Checkoway wrote: > > On Feb 23, 2015, at 12:34 PM, Dan Harkins wrote: > >> On Sat, February 21, 2015 12:45 am, Alex Elsayed wrote: >>> No, its model is "For shared keys drawn uniformly from {0,1}^n, this is >>> secure". >> >> No, it's not. If n=8 then the attack is trivial and succeeds almost >> instantaneously. If n=128 then with high probability a dictionary attack >> will not be successful. But in neither case is that "secure". > > What is your definition of secure then? I meant _the protocol_ is not secure in either case. The protocol doesn't magically become secure because it gets used differently. I gave a definition in this thread already. Dan. From nobody Mon Feb 23 17:15:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A56B1A033A for ; Mon, 23 Feb 2015 17:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhlgwdcZh8Lm for ; Mon, 23 Feb 2015 17:15:49 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84341A00CA for ; Mon, 23 Feb 2015 17:15:49 -0800 (PST) Received: by qcvp6 with SMTP id p6so14270347qcv.12 for ; Mon, 23 Feb 2015 17:15:48 -0800 (PST) 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:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xNUViBDQ6ePSOGTriLGsUwwzWgCIvwAK8vFDuJ1Qdrg=; b=hDdZWP08ItW3V39RYpQXYBAZrlfD5Pr/Zu45A9RfVBnxHNYyIacM4dr/8odvGanEXk G4s3kVTpQwguAaQZDafwGB7FquytEhzTcAeWGrdDqtdarDc1Hk8NwxYgdUlr4uIHZ87C B90AAhbzodzueQlQK0Cb+joDxfGsMVsDby3iDHSfLV1GMTMdFK+d2QP21UsimQCWzxJO aSMDOqIzALj20FkQZwFvoxPDYv+0AILiu/2PNT74wio2JhjVmwMSEzk1fKQTfTPWbeq1 K9qANVvIuFSGabC9lb5U2ts7B3e0Q6+wdDBWy3wTklYQrW5w/fKacBra6ZBEYKfohIN/ x3mA== X-Gm-Message-State: ALoCoQnAAH7FI77uz71UQfsmOgCBNI+xybc5XwLbGz9bgA6jz2PkBU5mQu9lV0seVLM1286rwqvL X-Received: by 10.140.232.6 with SMTP id d6mr30727926qhc.99.1424740548673; Mon, 23 Feb 2015 17:15:48 -0800 (PST) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id q5sm11031158qai.47.2015.02.23.17.15.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 17:15:47 -0800 (PST) Received: from [192.168.1.7] (hackintosh.local [192.168.1.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 02496AC287E; Mon, 23 Feb 2015 20:15:43 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=iso-8859-1 From: Stephen Checkoway X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 23 Feb 2015 20:15:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org> References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 01:15:51 -0000 On Feb 23, 2015, at 7:06 PM, Dan Harkins wrote: >=20 > On Mon, February 23, 2015 12:55 pm, Stephen Checkoway wrote: >>=20 >> On Feb 23, 2015, at 12:34 PM, Dan Harkins = wrote: >>=20 >>> On Sat, February 21, 2015 12:45 am, Alex Elsayed wrote: >>>> No, its model is "For shared keys drawn uniformly from {0,1}^n, = this is >>>> secure". >>>=20 >>> No, it's not. If n=3D8 then the attack is trivial and succeeds = almost >>> instantaneously. If n=3D128 then with high probability a dictionary = attack >>> will not be successful. But in neither case is that "secure". >>=20 >> What is your definition of secure then? >=20 > I meant _the protocol_ is not secure in either case. The protocol = doesn't > magically become secure because it gets used differently. I gave a > definition in this thread already. I must be missing something here. You're saying that since an adversary = can, in theory, enumerate 2^n possible pre-shared keys for any n, the = protocol is insecure. I don't see how to square that with Bellare-Pointcheval-Rogaway's = definitions (which I think is what you're using as your definition of = security). You write, > Namely, "In a protocol we deem 'good' the adversary's chance to defeat > protocol goals will depend on how much she interacts with protocol > participants-- it won't significantly depend on her off-line computing > time." By that criteria, TLS-PSK is not good. But that seems to misunderstand the quoted sentence. It's the = adversaries chance to defeat the protocol goals which is deemed to be = good, not the protocol itself. More to the point, the security of a = protocol is defined in terms of an adversary running in time t and = making q queries. If the passwords are drawn from a space of size N, = then the fact that an adversary which runs in time N or makes N queries = can have advantage 1 doesn't really tell us anything. See, for example, = Theorem 1 of the BPR paper. If q_se =3D N, then the advantage is bounded = by 1, but of course it is. That doesn't make the protocol under = consideration insecure due to dictionary attacks. Indeed, see remark 9 = just below noting that making N larger makes dictionary attacks moot. --=20 Stephen Checkoway From nobody Mon Feb 23 18:33:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE61A1B8C for ; Mon, 23 Feb 2015 18:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1NnDdCq5kKb for ; Mon, 23 Feb 2015 18:33:31 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7A87B1A1B8A for ; Mon, 23 Feb 2015 18:33:31 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B0F771FE01F0; Mon, 23 Feb 2015 18:33:30 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 23 Feb 2015 18:33:30 -0800 (PST) Message-ID: <3ce50aefd478490a025d7ff9942d6bf0.squirrel@www.trepanning.net> In-Reply-To: <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org> References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org> Date: Mon, 23 Feb 2015 18:33:30 -0800 (PST) From: "Dan Harkins" To: "Stephen Checkoway" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 02:33:33 -0000 On Mon, February 23, 2015 5:15 pm, Stephen Checkoway wrote: > > On Feb 23, 2015, at 7:06 PM, Dan Harkins wrote: > >> >> On Mon, February 23, 2015 12:55 pm, Stephen Checkoway wrote: >>> >>> On Feb 23, 2015, at 12:34 PM, Dan Harkins wrote: >>> >>>> On Sat, February 21, 2015 12:45 am, Alex Elsayed wrote: >>>>> No, its model is "For shared keys drawn uniformly from {0,1}^n, this >>>>> is >>>>> secure". >>>> >>>> No, it's not. If n=8 then the attack is trivial and succeeds almost >>>> instantaneously. If n=128 then with high probability a dictionary >>>> attack >>>> will not be successful. But in neither case is that "secure". >>> >>> What is your definition of secure then? >> >> I meant _the protocol_ is not secure in either case. The protocol >> doesn't >> magically become secure because it gets used differently. I gave a >> definition in this thread already. > > I must be missing something here. You're saying that since an adversary > can, in theory, enumerate 2^n possible pre-shared keys for any n, the > protocol is insecure. I'm saying that since the security of the protocol depends on it being used right, _the protocol_ cannot be said to be secure. > I don't see how to square that with Bellare-Pointcheval-Rogaway's > definitions (which I think is what you're using as your definition of > security). You write, > >> Namely, "In a protocol we deem 'good' the adversary's chance to defeat >> protocol goals will depend on how much she interacts with protocol >> participants-- it won't significantly depend on her off-line computing >> time." By that criteria, TLS-PSK is not good. > > But that seems to misunderstand the quoted sentence. It's the adversaries > chance to defeat the protocol goals which is deemed to be good, not the > protocol itself. More to the point, the security of a protocol is defined > in terms of an adversary running in time t and making q queries. If the > passwords are drawn from a space of size N, then the fact that an > adversary which runs in time N or makes N queries can have advantage 1 > doesn't really tell us anything. See, for example, Theorem 1 of the BPR > paper. If q_se = N, then the advantage is bounded by 1, but of course it > is. That doesn't make the protocol under consideration insecure due to > dictionary attacks. Indeed, see remark 9 just below noting that making N > larger makes dictionary attacks moot. No, I don't think you understand the quoted sentence. Note how they say, "In a protocol we deem 'good'…" That right there means they're talking about the protocol being good or not, and not the adversary's chance to defeat protocol goals. The adversary's chance of defeating protocol goals will grow (by exploiting the flaw in all protocols that authenticate using a symmetric key/code/word/phrase), it's a matter of how. The _protocol_ is deemed "good" if the adversary's advantage grows as a function of computing, not as a function of interaction with protocol participants. As Remark 8 notes, "The resistance to dictionary attacks is captured by the first term which is the number of send queries divided by the size of the password space." Making q_se = N means that the number of interactions is equal to the size of the password space and that does not capture resistance to dictionary attack. It is obvious that a making n large enough can make a dictionary attack moot. I have not said otherwise. It just doesn't make _the protocol_ resistant to dictionary attack. Dan. From nobody Mon Feb 23 19:08:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CE11A0072 for ; Mon, 23 Feb 2015 19:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_D7NeHybask for ; Mon, 23 Feb 2015 19:08:20 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8C11A001C for ; Mon, 23 Feb 2015 19:08:20 -0800 (PST) Received: by qcwb13 with SMTP id b13so14674371qcw.7 for ; Mon, 23 Feb 2015 19:08:19 -0800 (PST) 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:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LHPHqaKQ+dQ2f5y2GB6RGvPko1MhlH8qshq2IRRm2zw=; b=ctD5dZ1aoWvrBavMM+c33wAykzjOUA2tD8fOTL8tqy/7Vp9YPPRxdPTlVLor64P1jq 8CUl5sQ7DMmBVLWOxxEE/DnQc2OpplVIvU+auipqHf/v37DPCVKkju46LomSYlyPEVm7 j9eLlS720WRAjsFCjPrKhRiZFp8A5j4IzM+WzFBy4BHdktT8tlRUA1Zy1K3LtILcH27g l7pRwGF1Wsc1qt5fOnl+O5N5eXJY/ODaCWmS2DmhKenza3x1SI9qeu2IQcT1OVCvI1as krMVRo8oZreqDTGZtJjtgNMU3y2cpn3UOpstroz0tS/MQZ4Xy9NUwUwx2hjJ8ZAe18rZ 2dpA== X-Gm-Message-State: ALoCoQlRwtYTKrG68dyZmFMnYrQCHXOKHPXeI1Ut9pu19di2JNcLS8KBlnP4C/B0CaAWXDpjxliZ X-Received: by 10.229.191.3 with SMTP id dk3mr32531519qcb.30.1424747299775; Mon, 23 Feb 2015 19:08:19 -0800 (PST) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id t51sm3573649qge.28.2015.02.23.19.08.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 19:08:18 -0800 (PST) Received: from [192.168.1.7] (hackintosh.local [192.168.1.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 0A04CAC287E; Mon, 23 Feb 2015 22:08:17 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Stephen Checkoway X-Priority: 3 (Normal) In-Reply-To: <3ce50aefd478490a025d7ff9942d6bf0.squirrel@www.trepanning.net> Date: Mon, 23 Feb 2015 22:08:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5624F480-B31D-47FC-8CA7-0D879B3E934D@pahtak.org> References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org> <3ce50aefd478490a025d7ff9942d6bf0.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 03:08:22 -0000 On Feb 23, 2015, at 9:33 PM, Dan Harkins wrote: > I'm saying that since the security of the protocol depends on it being > used right, _the protocol_ cannot be said to be secure. Every security protocol's security depends on it being used correctly. = That doesn't seem like a useful metric here. >=20 >> I don't see how to square that with Bellare-Pointcheval-Rogaway's >> definitions (which I think is what you're using as your definition of >> security). You write, >>=20 >>> Namely, "In a protocol we deem 'good' the adversary's chance to = defeat >>> protocol goals will depend on how much she interacts with protocol >>> participants-- it won't significantly depend on her off-line = computing >>> time." By that criteria, TLS-PSK is not good. >>=20 >> But that seems to misunderstand the quoted sentence. It's the = adversaries >> chance to defeat the protocol goals which is deemed to be good, not = the >> protocol itself. More to the point, the security of a protocol is = defined >> in terms of an adversary running in time t and making q queries. If = the >> passwords are drawn from a space of size N, then the fact that an >> adversary which runs in time N or makes N queries can have advantage = 1 >> doesn't really tell us anything. See, for example, Theorem 1 of the = BPR >> paper. If q_se =3D N, then the advantage is bounded by 1, but of = course it >> is. That doesn't make the protocol under consideration insecure due = to >> dictionary attacks. Indeed, see remark 9 just below noting that = making N >> larger makes dictionary attacks moot. >=20 > No, I don't think you understand the quoted sentence. Note how they = say, > "In a protocol we deem 'good'=85" That right there means they're = talking about > the protocol being good or not, and not the adversary's chance to = defeat > protocol goals. You may be right. I was mentally inserting a comma after "in a protocol" = whereas you are inserting one after "good." But my reading doesn't fit = with the rest of the sentence. My mistake. > The adversary's chance of defeating protocol goals will grow > (by exploiting the flaw in all protocols that authenticate using a = symmetric > key/code/word/phrase), it's a matter of how. I don't think this is a matter of using a symmetric key/code/word/phrase = at all. You have exactly the same problem using DHE. I can enumerate (in = theory) the space of secret keys until I find one with a corresponding = public key that appears in the TLS handshake. Now I've recovered the = shared secret and I've done it with zero interaction with the protocol, = purely offline computation. > The _protocol_ is deemed > "good" if the adversary's advantage grows as a function of computing, = not > as a function of interaction with protocol participants. Wait, now you're saying something different. Before, you were saying = that the advantage should grow as a function of interactions and quoted = "the adversary's chance to defeat protocol goals will depend on how much = she interacts with protocol participants--it won't significantly depend = on her off-line computing time." But of course, it depends on both = computation (time) and interactions and both are captured in the formal = definitions given in the paper. >=20 > As Remark 8 notes, "The resistance to dictionary attacks is captured > by the first term which is the number of send queries divided by the = size > of the password space." Making q_se =3D N means that the number of > interactions is equal to the size of the password space and that does > not capture resistance to dictionary attack. In your brute force attack, you're either making N connections to the = server or you're watching a connection passively and computing N = possible master secrets and seeing which enable to you decrypt. Either = takes time at least N and both are captured in the notion of advantage. = So if Adv(t,q) is the maximum advantage of an adversary running in time = t, making q queries (similar to the definition of Adv_G^{dh} on page = 149), we have either Adv(N,N) =3D 1 or Adv(N,0) =3D 1. Neither result is = particularly meaningful and certainly doesn't tell us that TLS-PSK is = insecure. > It is obvious that a making n large enough can make a dictionary = attack > moot. I have not said otherwise. It just doesn't make _the protocol_ > resistant to dictionary attack. This isn't a useful distinction then since no mode of TLS is resistant = to dictionary attacks by what I take to be your definition. --=20 Stephen Checkoway From nobody Mon Feb 23 19:40:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52F41A010F for ; Mon, 23 Feb 2015 19:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-_7QHeGcFT8 for ; Mon, 23 Feb 2015 19:40:45 -0800 (PST) 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 41DA51A00FF for ; Mon, 23 Feb 2015 19:40:45 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A51EC282F52; Tue, 24 Feb 2015 03:40:43 +0000 (UTC) Date: Tue, 24 Feb 2015 03:40:43 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150224034043.GT1260@mournblade.imrryr.org> References: <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org> <3ce50aefd478490a025d7ff9942d6bf0.squirrel@www.trepanning.net> <5624F480-B31D-47FC-8CA7-0D879B3E934D@pahtak.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5624F480-B31D-47FC-8CA7-0D879B3E934D@pahtak.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 03:40:47 -0000 On Mon, Feb 23, 2015 at 10:08:16PM -0500, Stephen Checkoway wrote: > > It is obvious that a making n large enough can make a dictionary attack > > moot. I have not said otherwise. It just doesn't make _the protocol_ > > resistant to dictionary attack. > > This isn't a useful distinction then since no mode of TLS is resistant to dictionary attacks by what I take to be your definition. I'd like to suggest that this thread is going nowhere at present. I don't think any of the below are controversial. * PSK is vulnerable to dictionary attacks when poor key management leads to a reduced key space. * PAKE protocols offer greater resistance to off-line dictionary attacks. * PSK *with properly selected keys* is secure in practice, once the brute force search is at least as expensive as brute-forcing the symmetric-algorithm keyspace. * No key management approach is perfect. At which point it makes sense to step back and decide whether the risk of reduced key-space with PSK warrants dropping support, even though other approaches that are staying also have potential flaws. Is there a suitable PAKE that is ready to replace all applications of PSK? Is it practical in all the environments that would otherwise opt to use PSK? If PSK is simply an obsolete needlessly weaker shared secret system, then good riddance. If not, then the discussion should be about why PSK is more practical despite its limitations. -- Viktor. From nobody Mon Feb 23 21:36:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFA41A1ADB for ; Mon, 23 Feb 2015 21:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-B3XRYyo52p for ; Mon, 23 Feb 2015 21:36:54 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E1D1A0089 for ; Mon, 23 Feb 2015 21:36:54 -0800 (PST) Received: by ykp9 with SMTP id 9so1614250ykp.5 for ; Mon, 23 Feb 2015 21:36:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WTHfttKymmQWSlEB1iEubLS0zVQbtJrXQoz6uYiTXMo=; b=q8Sz8LjNTTxKh1BcmVJnob/SOrK9N5chlY27ruqek4PLygv7qWPPWFXg16a+QLdksV dCNO2vHv9OdPqgZHd53+HQp4Vn5V0bGZilay6EGazKTxv1d7t6eDMJY1MVoul51GOsKs 9++8wh9uKO4QCiUP7one+eTyd7qYD1Uvg666dH8NZkkQIlQpeyosOxBAUD6V9hb0VvOm Gi5dTgub077N6r0zNAWIYvaYj3OO6NPqhPZNh2hc5/JWkS9ADnGhhHM9n5ZmHgndA09r vheO6ofKEPYIRWvZCEQwLRjUucGZNfJWB4ZT+V1XMmuhivR/m0LtMRVkOwHPlcw6+OeU +HMA== MIME-Version: 1.0 X-Received: by 10.236.209.129 with SMTP id s1mr9115169yho.49.1424756213506; Mon, 23 Feb 2015 21:36:53 -0800 (PST) Received: by 10.170.126.10 with HTTP; Mon, 23 Feb 2015 21:36:53 -0800 (PST) In-Reply-To: <5624F480-B31D-47FC-8CA7-0D879B3E934D@pahtak.org> References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org> <3ce50aefd478490a025d7ff9942d6bf0.squirrel@www.trepanning.net> <5624F480-B31D-47FC-8CA7-0D879B3E934D@pahtak.org> Date: Mon, 23 Feb 2015 21:36:53 -0800 Message-ID: From: Watson Ladd To: Stephen Checkoway Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSK in 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 05:36:56 -0000 On Mon, Feb 23, 2015 at 7:08 PM, Stephen Checkoway wrote: > > On Feb 23, 2015, at 9:33 PM, Dan Harkins wrote: > >> I'm saying that since the security of the protocol depends on it being >> used right, _the protocol_ cannot be said to be secure. > > Every security protocol's security depends on it being used correctly. Th= at doesn't seem like a useful metric here. As far as I can tell, neither of you actually are arguing about what you're actually arguing about. The question isn't whether PSK mode satisfies the Bellare-Pointcheval-Rogaway definitions. Instead, it's about using in TLS 1.3 vs replacing it with a mode that uses a PAKE instead. The stated argument is that PSK is getting deployed with passwords instead of keys in many places: that's completely orthogonal to the discussion that's been taking place. As far as how much PAKEs cost, SPAKE2 is 2.5 exponentiations per side. Elligator is 2, but slightly harder to implement. On 32-bit arm processors I think these exponentiations cost around 2 million cycles according to SUPERCOP. So not a completely trivial cost, but most processors will do better, and I think the measurement was borked due to compiler issues. (Elligator might even be possible on genus 2: let me think about that for a while. Certainly on hyper-and-elliptic. ) Sincerely, Watson Ladd > >> >>> I don't see how to square that with Bellare-Pointcheval-Rogaway's >>> definitions (which I think is what you're using as your definition of >>> security). You write, >>> >>>> Namely, "In a protocol we deem 'good' the adversary's chance to defeat >>>> protocol goals will depend on how much she interacts with protocol >>>> participants-- it won't significantly depend on her off-line computing >>>> time." By that criteria, TLS-PSK is not good. >>> >>> But that seems to misunderstand the quoted sentence. It's the adversari= es >>> chance to defeat the protocol goals which is deemed to be good, not the >>> protocol itself. More to the point, the security of a protocol is defin= ed >>> in terms of an adversary running in time t and making q queries. If the >>> passwords are drawn from a space of size N, then the fact that an >>> adversary which runs in time N or makes N queries can have advantage 1 >>> doesn't really tell us anything. See, for example, Theorem 1 of the BPR >>> paper. If q_se =3D N, then the advantage is bounded by 1, but of course= it >>> is. That doesn't make the protocol under consideration insecure due to >>> dictionary attacks. Indeed, see remark 9 just below noting that making = N >>> larger makes dictionary attacks moot. >> >> No, I don't think you understand the quoted sentence. Note how they sa= y, >> "In a protocol we deem 'good'=E2=80=A6" That right there means they're t= alking about >> the protocol being good or not, and not the adversary's chance to defeat >> protocol goals. > > You may be right. I was mentally inserting a comma after "in a protocol" = whereas you are inserting one after "good." But my reading doesn't fit with= the rest of the sentence. My mistake. > >> The adversary's chance of defeating protocol goals will grow >> (by exploiting the flaw in all protocols that authenticate using a symme= tric >> key/code/word/phrase), it's a matter of how. > > I don't think this is a matter of using a symmetric key/code/word/phrase = at all. You have exactly the same problem using DHE. I can enumerate (in th= eory) the space of secret keys until I find one with a corresponding public= key that appears in the TLS handshake. Now I've recovered the shared secre= t and I've done it with zero interaction with the protocol, purely offline = computation. > >> The _protocol_ is deemed >> "good" if the adversary's advantage grows as a function of computing, no= t >> as a function of interaction with protocol participants. > > Wait, now you're saying something different. Before, you were saying that= the advantage should grow as a function of interactions and quoted "the ad= versary's chance to defeat protocol goals will depend on how much she inter= acts with protocol participants--it won't significantly depend on her off-l= ine computing time." But of course, it depends on both computation (time) a= nd interactions and both are captured in the formal definitions given in th= e paper. > >> >> As Remark 8 notes, "The resistance to dictionary attacks is captured >> by the first term which is the number of send queries divided by the siz= e >> of the password space." Making q_se =3D N means that the number of >> interactions is equal to the size of the password space and that does >> not capture resistance to dictionary attack. > > In your brute force attack, you're either making N connections to the ser= ver or you're watching a connection passively and computing N possible mast= er secrets and seeing which enable to you decrypt. Either takes time at lea= st N and both are captured in the notion of advantage. So if Adv(t,q) is th= e maximum advantage of an adversary running in time t, making q queries (si= milar to the definition of Adv_G^{dh} on page 149), we have either Adv(N,N)= =3D 1 or Adv(N,0) =3D 1. Neither result is particularly meaningful and cer= tainly doesn't tell us that TLS-PSK is insecure. > >> It is obvious that a making n large enough can make a dictionary attack >> moot. I have not said otherwise. It just doesn't make _the protocol_ >> resistant to dictionary attack. > > This isn't a useful distinction then since no mode of TLS is resistant to= dictionary attacks by what I take to be your definition. > > -- > Stephen Checkoway > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Feb 24 01:08:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA761A8731 for ; Tue, 24 Feb 2015 01:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3SLjWavDYim for ; Tue, 24 Feb 2015 01:08:01 -0800 (PST) Received: from BLU004-OMC2S20.hotmail.com (blu004-omc2s20.hotmail.com [65.55.111.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C641A8728 for ; Tue, 24 Feb 2015 01:08:00 -0800 (PST) Received: from BLU177-W40 ([65.55.111.72]) by BLU004-OMC2S20.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 24 Feb 2015 01:08:00 -0800 X-TMN: [b++H5oZS1Xb1mdI1va0znDiuOSNU6b6l] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Florian Weimer , "tls@ietf.org" Date: Tue, 24 Feb 2015 01:08:00 -0800 Importance: Normal In-Reply-To: <54DB5670.8070009@redhat.com> References: <201412221945.35644.davemgarrett@gmail.com>, , <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com>,<54DB5670.8070009@redhat.com> Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2015 09:08:00.0198 (UTC) FILETIME=[63280E60:01D05011] Archived-At: Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 09:08:02 -0000 =0A= =0A= ----------------------------------------=0A= > Date: Wed=2C 11 Feb 2015 14:17:36 +0100=0A= > From: fweimer@redhat.com=0A= > To: tls@ietf.org=0A= > Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1= .3 draft=0A= >=0A= > On 12/27/2014 11:39 PM=2C Dave Garrett wrote:=0A= >> On Saturday=2C December 27=2C 2014 05:07:12 pm Hauke Mehrtens wrote:=0A= >>> On 12/24/2014 07:40 AM=2C Yoav Nir wrote:=0A= >>>> It=92s fine for us to break compatibility with these clients=2C but le= t=92s not=0A= >>>> pretend it=92s some ancient technology that doesn=92t exist in the mar= ket=0A= >>>> anymore.=0A= >>>=0A= >>> In addition the Oracle Java Runtime Environment in Version 6 uses a SSL= =0A= >>> v2 compatible ClientHello in the default settings. It supports SSL v3= =0A= >>> and TLS 1.0. In Java JRE 7 a SSLv3 ClientHello is used by default.=0A= >>>=0A= >>> I think a TLS 1.3 Client must not send a SSLv2 ClientHello=2C but a ser= ver=0A= >>> should understand it.=0A= >>=0A= >> The newest version of TLS should not be have to be written to accommodat= e an 8=0A= >> year old EOL Java version's default settings.=0A= >=0A= > I could reproduce the behavior with OpenJDK 6 which is still supported:= =0A= >=0A= > https://bugzilla.redhat.com/show_bug.cgi?id=3D880223=0A= >=0A= > Because it's not EOL=2C we can still fix the defaults=2C although this ma= y=0A= > not be what some users expect or need.=0A= >=0A= > (FWIW=2C Android does not use =93Java 6=94=2C it's an independent impleme= ntation=0A= > with different behavior and defaults.)=0A= =0A= FYI on SMTP=2C IBM Domino was forced to restore SSLv2 ClientHello support u= nder a switch that has to be enabled:=0A= http://www.wiseman.la/web/cpwBlog.nsf/dx/domino-customer-please-call-ibm-su= pport-help-get-smtp-tlsssl-fixed.htm?opendocument&comments#anc1=0A= http://www-10.lotus.com/ldd/ndseforum.nsf/xpTopicThread.xsp?documentId=3DE6= 14F339E975A7A485257D860064343A = From nobody Tue Feb 24 06:22:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C311A06E9 for ; Tue, 24 Feb 2015 06:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH9Fe8yNc7lr for ; Tue, 24 Feb 2015 06:22:18 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36671A1B28 for ; Tue, 24 Feb 2015 06:22:17 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 9198ce45.0.4804050.00-2308.13501176.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 24 Feb 2015 14:22:17 +0000 (UTC) X-MXL-Hash: 54ec891916b2bd2a-d73f2f8f1393e75fe7b6b9b96859bb79434f17ce Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OEMG9j004861 for ; Tue, 24 Feb 2015 09:22:16 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OEMErx004858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Feb 2015 09:22:15 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Tue, 24 Feb 2015 14:22:02 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OEM2LP019388 for ; Tue, 24 Feb 2015 09:22:02 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OELsO0018940 for ; Tue, 24 Feb 2015 09:21:55 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224142153gw1000ceehe>; Tue, 24 Feb 2015 14:21:54 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54EC8900.5000904@att.com> Date: Tue, 24 Feb 2015 09:21:52 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: karthikeyan.bhargavan@inria.fr, antoine.delignat-lavaud@inria.fr, alfredo.pironti@inria.fr, agl@google.com, maray@microsoft.com Content-Type: multipart/alternative; boundary="------------080302070509060407060902" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=EtBlW1gA c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=48vgC7mUAAAA:8 a=9OSF2Kd-Z] X-AnalysisOut: [6BqDURrM8wA:9 a=QEXdDO2ut3YA:10 a=DMp7b8H8LvoYi-Xz2IQA:9 a] X-AnalysisOut: [=_W_S_7VecoQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: tls@ietf.org Subject: [TLS] question on draft-ietf-tls-session-hash-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 14:22:19 -0000 This is a multi-part message in MIME format. --------------080302070509060407060902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have a question on draft-ietf-tls-session-hash-03. In the description I see: As described in [TRIPLE-HS ], in both the RSA and DHE key exchanges, an active attacker can synchronize two TLS sessions so that they share the same "master_secret". For an RSA key exchange where the client is unauthenticated, this is achieved as follows. Suppose a client, C, connects to a malicious server, A. A then connects to a server, S, and completes both handshakes. For simplicity, assume that C and S only use RSA ciphersuites. (Note that C thinks it is connecting to A and is oblivious of S's involvement.) My question is on the parenthetical comment at the end. I'll repeat it here, expanding C, S and A into CLIENT, SERVER and ATTACKER, respectively: (Note that CLIENT thinks it is connecting to ATTACKER and is oblivious of SERVER's involvement.) Am I wrong in thinking that A and S are reversed here, and this should read: (Note that CLIENT thinks it is connecting to SERVER and is oblivious of ATTACKER's involvement.) Or, removing the expansion: (Note that C thinks it is connecting to S and is oblivious of A's involvement.) That is, ATTACKER A is the malicious man in the middle that the client is not aware of. (For that matter, the server is also probably oblivious of A's involvement.) Tony Hansen --------------080302070509060407060902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have a question on draft-ietf-tls-session-hash-03. In the description I see:

   As described in [TRIPLE-HS], in both the RSA and DHE key exchanges,
   an active attacker can synchronize two TLS sessions so that they
   share the same "master_secret".  For an RSA key exchange where the
   client is unauthenticated, this is achieved as follows.  Suppose a
   client, C, connects to a malicious server, A.  A then connects to a
   server, S, and completes both handshakes.  For simplicity, assume
   that C and S only use RSA ciphersuites.  (Note that C thinks it is
   connecting to A and is oblivious of S's involvement.)
My question is on the parenthetical comment at the end. I'll repeat it here, expanding C, S and A into CLIENT, SERVER and ATTACKER, respectively:

					(Note that CLIENT thinks it is
   connecting to ATTACKER and is oblivious of SERVER's involvement.)

Am I wrong in thinking that A and S are reversed here, and this should read:

					(Note that CLIENT thinks it is
   connecting to SERVER and is oblivious of ATTACKER's involvement.)

Or, removing the expansion:

					(Note that C thinks it is
   connecting to S and is oblivious of A's involvement.)

That is, ATTACKER A is the malicious man in the middle that the client is not aware of. (For that matter, the server is also probably oblivious of A's involvement.)

    Tony Hansen
--------------080302070509060407060902-- From nobody Tue Feb 24 06:47:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD51A8713 for ; Tue, 24 Feb 2015 06:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vDiNHgU_0fW for ; Tue, 24 Feb 2015 06:47:33 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B923A1A1B8E for ; Tue, 24 Feb 2015 06:47:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,639,1418079600"; d="scan'208,217";a="123188729" Received: from pool-108-14-101-29.nycmny.fios.verizon.net (HELO [192.168.1.7]) ([108.14.101.29]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Feb 2015 15:47:30 +0100 References: <54EC8900.5000904@att.com> Mime-Version: 1.0 (1.0) In-Reply-To: <54EC8900.5000904@att.com> Content-Type: multipart/alternative; boundary=Apple-Mail-D0EC0626-7863-4F09-AE29-5650392F598C Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12B466) From: Benjamin Beurdouche Date: Tue, 24 Feb 2015 09:47:28 -0500 To: Tony Hansen Archived-At: Cc: "tls@ietf.org" , "antoine.delignat-lavaud@inria.fr" Subject: Re: [TLS] question on draft-ietf-tls-session-hash-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 14:47:35 -0000 --Apple-Mail-D0EC0626-7863-4F09-AE29-5650392F598C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Tony, To me it seems the sentence is correct as C really wants to connect to A thi= nking it is an honest server and doesn't know S is involved. Then S doesn't k= now the involvement of A as A connected unauthentified and forwards info fro= m C. But authors should confirm that in case I am mistaken... Cheers, B. > On 24 Feb 2015, at 9:21 am, Tony Hansen wrote: >=20 > I have a question on draft-ietf-tls-session-hash-03. In the description I s= ee: >=20 > As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, > an active attacker can synchronize two TLS sessions so that they > share the same "master_secret". For an RSA key exchange where the > client is unauthenticated, this is achieved as follows. Suppose a > client, C, connects to a malicious server, A. A then connects to a > server, S, and completes both handshakes. For simplicity, assume > that C and S only use RSA ciphersuites. (Note that C thinks it is > connecting to A and is oblivious of S's involvement.) >=20 > My question is on the parenthetical comment at the end. I'll repeat it her= e, expanding C, S and A into CLIENT, SERVER and ATTACKER, respectively: >=20 > (Note that CLIENT thinks it is > connecting to ATTACKER and is oblivious of SERVER's involvement.) >=20 > Am I wrong in thinking that A and S are reversed here, and this should rea= d: >=20 > (Note that CLIENT thinks it is > connecting to SERVER and is oblivious of ATTACKER's involvement.) >=20 > Or, removing the expansion: >=20 > (Note that C thinks it is > connecting to S and is oblivious of A's involvement.) >=20 > That is, ATTACKER A is the malicious man in the middle that the client= is not aware of. (For that matter, the server is also probably oblivious of= A's involvement.) >=20 > Tony Hansen > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-D0EC0626-7863-4F09-AE29-5650392F598C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Tony,

To me it seems the sentence is correct as C really wants to connect to A thinking it is an honest server and doesn't know S is involved. Then S doesn't know the involvement of A as A connected unauthentified and forwards info from C.
But authors should confirm that in case I am mistaken...

Cheers,
B.



On 24 Feb 2015, at 9:21 am, Tony Hansen <tony@att.com> wrote:

I have a question on draft-ietf-tls-session-hash-03. In the description I see:

   As described in [TRIPLE-HS], in both the RSA and DHE key exchanges,
   an active attacker can synchronize two TLS sessions so that they
   share the same "master_secret".  For an RSA key exchange where the
   client is unauthenticated, this is achieved as follows.  Suppose a
   client, C, connects to a malicious server, A.  A then connects to a
   server, S, and completes both handshakes.  For simplicity, assume
   that C and S only use RSA ciphersuites.  (Note that C thinks it is
   connecting to A and is oblivious of S's involvement.)
My question is on the parenthetical comment at the end. I'll repeat it here, expanding C, S and A into CLIENT, SERVER and ATTACKER, respectively:

					(Note that CLIENT thinks it is
   connecting to ATTACKER and is oblivious of SERVER's involvement.)

Am I wrong in thinking that A and S are reversed here, and this should read:

					(Note that CLIENT thinks it is
   connecting to SERVER and is oblivious of ATTACKER's involvement.)

Or, removing the expansion:

					(Note that C thinks it is
   connecting to S and is oblivious of A's involvement.)

That is, ATTACKER A is the malicious man in the middle that the client is not aware of. (For that matter, the server is also probably oblivious of A's involvement.)

    Tony Hansen
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--Apple-Mail-D0EC0626-7863-4F09-AE29-5650392F598C-- From nobody Tue Feb 24 07:12:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354961A87D0 for ; Tue, 24 Feb 2015 07:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IACnwNQbGkz8 for ; Tue, 24 Feb 2015 07:12:34 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7E31A87CA for ; Tue, 24 Feb 2015 07:12:33 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 1e49ce45.0.4845935.00-2067.13632387.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 24 Feb 2015 15:12:33 +0000 (UTC) X-MXL-Hash: 54ec94e15911f791-e97d5c21d19a1e519603d5787b8d22610bbb306a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OFCWQT029654 for ; Tue, 24 Feb 2015 10:12:32 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OFCRgb029546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Feb 2015 10:12:27 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Tue, 24 Feb 2015 15:12:15 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OFCFZf018703 for ; Tue, 24 Feb 2015 10:12:15 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OFC8q6018353 for ; Tue, 24 Feb 2015 10:12:08 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224151207gw1000ceeje>; Tue, 24 Feb 2015 15:12:08 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54EC94C7.6010806@att.com> Date: Tue, 24 Feb 2015 10:12:07 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: tls@ietf.org References: <54EC8900.5000904@att.com> In-Reply-To: <54EC8900.5000904@att.com> Content-Type: multipart/alternative; boundary="------------010104060109080408010707" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=oC1tkrrm] X-AnalysisOut: [O5p1rXNBpm4A:9 a=QEXdDO2ut3YA:10 a=FSZRKXIxUJNAyw2ce74A:9 ] X-AnalysisOut: [a=_W_S_7VecoQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [TLS] question on draft-ietf-tls-session-hash-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 15:12:35 -0000 This is a multi-part message in MIME format. --------------010104060109080408010707 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thank you for the quick response. In my interpretation, I took things as "C really wants to connect to S, but got A instead". I didn't get your interpretation when I read it and re-read it. But I can see now how what you wrote would also be a valid interpretation. I guess we'll await a response from the authors. Tony Hansen Benjamin Beurdouche > wrote: > Hi Tony, > > To me it seems the sentence is correct as C really wants to connect to > A thinking it is an honest server and doesn't know S is involved. Then > S doesn't know the involvement of A as A connected unauthentified and > forwards info from C. > But authors should confirm that in case I am mistaken... --------------010104060109080408010707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thank you for the quick response. In my interpretation, I took things as "C really wants to connect to S, but got A instead". I didn't get your interpretation when I read it and re-read it. But I can see now how what you wrote would also be a valid interpretation.

I guess we'll await a response from the authors.

    Tony Hansen

Benjamin Beurdouche <benjamin.beurdouche at inria.fr> wrote:
Hi Tony,

To me it seems the sentence is correct as C really wants to connect to A thinking it is an honest server and doesn't know S is involved. Then S doesn't know the involvement of A as A connected unauthentified and forwards info from C.
But authors should confirm that in case I am mistaken...

--------------010104060109080408010707-- From nobody Tue Feb 24 09:05:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2411C1A1BC2; Tue, 24 Feb 2015 09:05:55 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBqhk7f6edNo; Tue, 24 Feb 2015 09:05:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C69181A8868; Tue, 24 Feb 2015 09:05:45 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150224170545.678.71458.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 09:05:45 -0800 Archived-At: Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks' to Proposed Standard (draft-ietf-tls-downgrade-scsv-05.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 17:05:55 -0000 The IESG has approved the following document: - 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks' (draft-ietf-tls-downgrade-scsv-05.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ Technical Summary This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. Working Group Summary Was there anything in the WG process that is worth noting? Yes. Lots and lots of argument:-) See the shepherd writeup for details. The IETF LC mostly repeated arguments already aired and disposed of during the WG process, or was about TLS1.3. Consensus for this is rough, but fairly clear. Document Quality Based on some measurements taken back in November 14.4% of TLS servers on the Internet now support the mechanism described in this draft. Personnel Sean Turner is the document Shepherd, Stephen Farrell is the irresponsible AD. From nobody Tue Feb 24 10:16:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E461A1C03 for ; Tue, 24 Feb 2015 10:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3BQQHHCgmeg for ; Tue, 24 Feb 2015 10:16:07 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74131A1B59 for ; Tue, 24 Feb 2015 10:16:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,640,1418079600"; d="asc'?scan'208,217";a="123224563" Received: from 162.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.162]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 24 Feb 2015 19:16:04 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_45F32348-FDEF-4B66-A557-4F1000249C68"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: <54EC94C7.6010806@att.com> Date: Tue, 24 Feb 2015 19:16:03 +0100 Message-Id: <26E1D2E1-E57A-4D8E-B432-058541EB2E32@inria.fr> References: <54EC8900.5000904@att.com> <54EC94C7.6010806@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] question on draft-ietf-tls-session-hash-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 18:16:09 -0000 --Apple-Mail=_45F32348-FDEF-4B66-A557-4F1000249C68 Content-Type: multipart/alternative; boundary="Apple-Mail=_DF0FD705-B253-4779-9366-D23BDD716801" --Apple-Mail=_DF0FD705-B253-4779-9366-D23BDD716801 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, C wants to connect to A. A independently connects to S. So in the outer TLS connection, there is no attack. (A is like an = application-level proxy.) Then during renegotiation after resumption, C authenticates with a = client certificate to A and A succeeds in forwarding C=92s certificate to S, hence impersonating = C at S. There are other variations of the attack on various TLS channel = bindings,=20 but the above version (initial + resumption + renegotiation) is called = the triple handshake attack. Perhaps we could be a bit clearer about this in the spec? I am currently = revising it to incorporate other comments on the list. Best, -Karthik On 24 Feb 2015, at 16:12, Tony Hansen wrote: > Thank you for the quick response. In my interpretation, I took things = as "C really wants to connect to S, but got A instead". I didn't get = your interpretation when I read it and re-read it. But I can see now how = what you wrote would also be a valid interpretation. >=20 > I guess we'll await a response from the authors. >=20 > Tony Hansen >=20 > Benjamin Beurdouche wrote: >> Hi Tony, >>=20 >> To me it seems the sentence is correct as C really wants to connect = to A thinking it is an honest server and doesn't know S is involved. = Then S doesn't know the involvement of A as A connected unauthentified = and forwards info from C. >> But authors should confirm that in case I am mistaken... >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_DF0FD705-B253-4779-9366-D23BDD716801 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes, C = wants to connect to A. A independently connects to S.
So in the = outer TLS connection, there is no attack. (A is like an = application-level proxy.)

Then during = renegotiation after resumption, C authenticates with a client = certificate to A
and A succeeds in forwarding C=92s = certificate to S, hence impersonating C at = S.

There are other variations of the attack on = various TLS channel bindings, 
but the above version = (initial + resumption + renegotiation) is called the triple handshake = attack.

Perhaps we could be a bit clearer about = this in the spec? I am currently revising it to incorporate other = comments on the = list.

Best,
-Karthik

On 24 Feb 2015, at 16:12, Tony Hansen <tony@att.com> wrote:

=20 =20
Thank you for the quick response. In my interpretation, I took things as "C really wants to connect to S, but got A instead". I didn't get your interpretation when I read it and re-read it. But I can see now how what you wrote would also be a valid = interpretation.

I guess we'll await a response from the authors.

    Tony Hansen

Benjamin Beurdouche <benjamin.beurdouche at inria.fr> wrote:
Hi Tony,

To me it seems the sentence is correct as C really wants to connect to A thinking it is an honest server and doesn't know S is involved. Then S doesn't know the involvement of A as A connected unauthentified and forwards info from C.
But authors should confirm that in case I am = mistaken...

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

= --Apple-Mail=_DF0FD705-B253-4779-9366-D23BDD716801-- --Apple-Mail=_45F32348-FDEF-4B66-A557-4F1000249C68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7L/jAAoJEB/WSo9veuUKDQ0H/ioKKEYYsINaaP2u/16ax33g Lo2nrqkGDroxfH6RiRH0M9c/ohrIwntKuyhOWGNqgTgK7x+rGR02TCMymnfX4kNj FqCZ1+N3eZ3JmN5BiB+QW8YyP6XVl11NUJoo8ITdpqxOYVJWEMSmORWxhQyFnYnk GEbFtMQyyHB9RDnswcc9uli22esr9FZGIKRgBvvxIjr9Qr7Gzy1A1IFMoSGAXzeS dfXLNx8nVTHZFsz/rTr5FsD4lRTbt3hNjgAW4JxaJ3eSLpo3nhLl78K+rkb1Uj1u HakVozNnMSl+qq5Eg5eqSddnjpSjB3CeuvUEzYqCOTjyA1s8UCa2LHUufinNonQ= =u+FI -----END PGP SIGNATURE----- --Apple-Mail=_45F32348-FDEF-4B66-A557-4F1000249C68-- From nobody Tue Feb 24 10:58:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6121A8866 for ; Tue, 24 Feb 2015 10:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UQQEVwRaRBC for ; Tue, 24 Feb 2015 10:58:41 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BE71A8861 for ; Tue, 24 Feb 2015 10:58:38 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id dd9cce45.0.5015760.00-2322.14084130.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 24 Feb 2015 18:58:38 +0000 (UTC) X-MXL-Hash: 54ecc9de6d48536a-388ad09a49735a11ee7676de21a27456484e568d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OIwbLM031221 for ; Tue, 24 Feb 2015 13:58:37 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OIwSY7031125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Feb 2015 13:58:31 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 24 Feb 2015 18:58:19 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OIwJDK011856 for ; Tue, 24 Feb 2015 13:58:19 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OIwF8j011681 for ; Tue, 24 Feb 2015 13:58:15 -0500 Received: from tonys-macbook-pro.local (unknown[135.110.241.46](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224185813gw1000ceete>; Tue, 24 Feb 2015 18:58:14 +0000 X-Originating-IP: [135.110.241.46] Message-ID: <54ECC9C5.4010500@att.com> Date: Tue, 24 Feb 2015 13:58:13 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Karthikeyan Bhargavan References: <54EC8900.5000904@att.com> <54EC94C7.6010806@att.com> <26E1D2E1-E57A-4D8E-B432-058541EB2E32@inria.fr> In-Reply-To: <26E1D2E1-E57A-4D8E-B432-058541EB2E32@inria.fr> Content-Type: multipart/alternative; boundary="------------010902090506070008040307" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=KNft+i5o c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=48vgC7mUAAAA:8 a=eqsbH_jyG] X-AnalysisOut: [TMAaWDpKB4A:9 a=pILNOxqGKmIA:10 a=9gzT7w0QE_rBAufPf8wA:9 a] X-AnalysisOut: [=_W_S_7VecoQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] question on draft-ietf-tls-session-hash-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Feb 2015 18:58:46 -0000 This is a multi-part message in MIME format. --------------010902090506070008040307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thank you for the clarifications Karthik. Here is one suggestion for changing the text: Change: Suppose a client, C, connects to a malicious server, A. A then connects to a server, S, and completes both handshakes. to: Suppose a client, C, connects to an application server, A. C does now know that A is also malicious and that A connects in the background to another server, S. A connects to S and completes both handshakes. Or possibly take some of your text you just posted and add that in. On 2/24/15 1:16 PM, Karthikeyan Bhargavan wrote: > Yes, C wants to connect to A. A independently connects to S. > So in the outer TLS connection, there is no attack. (A is like an > application-level proxy.) > > Then during renegotiation after resumption, C authenticates with a > client certificate to A > and A succeeds in forwarding C’s certificate to S, hence impersonating > C at S. > > There are other variations of the attack on various TLS channel bindings, > but the above version (initial + resumption + renegotiation) is called > the triple handshake attack. > > Perhaps we could be a bit clearer about this in the spec? I am > currently revising it to incorporate other comments on the list. > > Best, > -Karthik > > On 24 Feb 2015, at 16:12, Tony Hansen > wrote: > >> Thank you for the quick response. In my interpretation, I took things >> as "C really wants to connect to S, but got A instead". I didn't get >> your interpretation when I read it and re-read it. But I can see now >> how what you wrote would also be a valid interpretation. >> >> I guess we'll await a response from the authors. >> >> Tony Hansen >> >> Benjamin Beurdouche > > wrote: >>> Hi Tony, >>> >>> To me it seems the sentence is correct as C really wants to connect >>> to A thinking it is an honest server and doesn't know S is involved. >>> Then S doesn't know the involvement of A as A connected >>> unauthentified and forwards info from C. >>> But authors should confirm that in case I am mistaken... >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > --------------010902090506070008040307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Thank you for the clarifications Karthik.

Here is one suggestion for changing the text:

Change:
    Suppose a client, C, connects to a malicious server, A. A then connects to a
    server, S, and completes both handshakes.
to:
    Suppose a client, C, connects to an application server, A. C does now know
    that A is also malicious and that A connects in the background to another
    server, S. A connects to S and completes both handshakes.

Or possibly take some of your text you just posted and add that in.


On 2/24/15 1:16 PM, Karthikeyan Bhargavan wrote:
Yes, C wants to connect to A. A independently connects to S.
So in the outer TLS connection, there is no attack. (A is like an application-level proxy.)

Then during renegotiation after resumption, C authenticates with a client certificate to A
and A succeeds in forwarding C’s certificate to S, hence impersonating C at S.

There are other variations of the attack on various TLS channel bindings, 
but the above version (initial + resumption + renegotiation) is called the triple handshake attack.

Perhaps we could be a bit clearer about this in the spec? I am currently revising it to incorporate other comments on the list.

Best,
-Karthik

On 24 Feb 2015, at 16:12, Tony Hansen <tony@att.com> wrote:

Thank you for the quick response. In my interpretation, I took things as "C really wants to connect to S, but got A instead". I didn't get your interpretation when I read it and re-read it. But I can see now how what you wrote would also be a valid interpretation.

I guess we'll await a response from the authors.

    Tony Hansen

Benjamin Beurdouche <benjamin.beurdouche at inria.fr> wrote:
Hi Tony,

To me it seems the sentence is correct as C really wants to connect to A thinking it is an honest server and doesn't know S is involved. Then S doesn't know the involvement of A as A connected unauthentified and forwards info from C.
But authors should confirm that in case I am mistaken...

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


--------------010902090506070008040307-- From nobody Tue Feb 24 16:45:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41FA1A1A28 for ; Tue, 24 Feb 2015 16:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3xMt0mAeQx6 for ; Tue, 24 Feb 2015 16:45:04 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054961A0AFE for ; Tue, 24 Feb 2015 16:45:04 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id em10so31013881wid.0 for ; Tue, 24 Feb 2015 16:45:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=5LqTl2zD12b+DO6tXurOelRg+RS/g3JnsBaiKMumrXE=; b=WYMZVYsBNyj/0tMWbfwvUxfLi37rZlX1+XPWBYYy5at9cMn+mnoHFIYuor9cp+iLlI GiTbg3rSWY/8MLWtiQJNEu5mP8HjNdtr1qcNXSuahEyYxNG/v92P+NxGxwxWRAHiQFn8 Nw3eVPEYIf5UKl6zzZHDn26F7SAwoK/w+Nto07TMW8NEvJ+0Grlg3dzGXg8vvTB0rbKC t3TkGfk5fIWaQPtSf1HRCUVeMmirz68BrHooQ6/VqANekQE9HMm5f8cjxfIBqe3JUJQm 7FYhNiOTz8jBVCJcO+utrQ95u3v4eKg/ZtQImw9C1RoUxKwVUV1vo/qSNWPEe4q7DEjn 5+NA== X-Gm-Message-State: ALoCoQmtKRfzQ2HBUjYE4TXjWybtyvYBYOpzknj6NcQyAh+qU9xMn8FBfJHOw0D5ILqyeiV1Rwvl X-Received: by 10.194.185.68 with SMTP id fa4mr824843wjc.111.1424825102762; Tue, 24 Feb 2015 16:45:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.214.203 with HTTP; Tue, 24 Feb 2015 16:44:22 -0800 (PST) From: Eric Rescorla Date: Tue, 24 Feb 2015 16:44:22 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bacb11e1e18cc050fdef228 Archived-At: Subject: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Feb 2015 00:45:05 -0000 --047d7bacb11e1e18cc050fdef228 Content-Type: text/plain; charset=UTF-8 Folks, I'd like to get a sense of the WG on whether they want to pursue the Update mechanism [0]. There are several possibilities here, including: - Just do basic Update - Move session ticket establishment to Update - Mode client authentication to Update My sense from the discussion in HNL was that people were generally positive on basic Update and unsure on the other two. If that's right, I'll buff up PR#94 for merge into the spec (pending chair approval). Thanks, -Ekr [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP version of the basic mechanism. --047d7bacb11e1e18cc050fdef228 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I'd like to get a sense of t= he WG on whether they want to pursue the Update
mechanism [0].

There are several possibilities here, including:

- Just do basic Update
- Move session ticke= t establishment to Update
- Mode client authentication to Update<= /div>

My sense from the discussion in HNL was that peopl= e were generally
positive on basic Update and unsure on the other= two. If that's right,
I'll buff up PR#94 for merge into = the spec (pending chair approval).

Thanks,
-Ekr


version of the basic m= echanism.

--047d7bacb11e1e18cc050fdef228-- From nobody Tue Feb 24 17:43:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250FE1A8881 for ; Tue, 24 Feb 2015 17:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ4TlZO6uHdi for ; Tue, 24 Feb 2015 17:43:53 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::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 AA8D01A877F for ; Tue, 24 Feb 2015 17:43:53 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id im6so301628vcb.11 for ; Tue, 24 Feb 2015 17:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=bO6N7KPc36EEqCQ4pdKZdkyoRkjT/cSCYy+TO0UcbRE=; b=z62MDxcnXnbTxZvWw3XaYkEL9MRt+2rQVXeFQC5nRFyPfNU+Q4gyGjpwDZvDAVgxRF 7Ywz4s6HqmJ5qvw/x1VG2ejudsyAClti+efHORf6peWRbJKG36BltE0QTld85XSPpyW5 IcUltklhfJgAB2Qi+c4CEiuFbSO+X5MavBpTDhQ2VjQTSMLPvYVaLbLTGMqILkxeQW90 u0t+f8Mz0uXX6CJaxGCawuzvW1SGxVWpbp9jIBfayuWGEkeX/QR2zlOC24xl3MkWU3XR jkcvv5v63APcQz4iAFjrDXVaceXMdB+j7EMEgXb39MVE0D98SSlkqSkf28lNWlUazqJc DXfg== X-Received: by 10.52.155.104 with SMTP id vv8mr1142251vdb.64.1424828632889; Tue, 24 Feb 2015 17:43:52 -0800 (PST) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id rt15sm5618990vdb.12.2015.02.24.17.43.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Feb 2015 17:43:51 -0800 (PST) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Tue, 24 Feb 2015 20:43:49 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201502242043.50128.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Feb 2015 01:43:55 -0000 On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote: > Folks, > > I'd like to get a sense of the WG on whether they want to pursue the Update > mechanism [0]. > > There are several possibilities here, including: > > - Just do basic Update > - Move session ticket establishment to Update > - Mode client authentication to Update > > My sense from the discussion in HNL was that people were generally > positive on basic Update and unsure on the other two. If that's right, > I'll buff up PR#94 for merge into the spec (pending chair approval). > > Thanks, > -Ekr > > > [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP > version of the basic mechanism. The current proposal says: "An implementation MAY send an UpdateRekey at any time after the handshake completes." Is there a particular reason to not just have an automatic rekey at semi-regular intervals? So, every N records or M minutes (or whichever comes first) an endpoint must send a rekey, and then after a similarly measured interval the other endpoint sends a rekey; repeat ad infinitum. This would also ensure entropy for rekeying comes from both endpoints equally over the course of the connection. I would expect it would be better to not rely on implementations all designing their own heuristics on when to send rekey updates, and also would avoid multiple updates being sent at the same time by each endpoint (and the possible pitfalls of doing so). Dave From nobody Tue Feb 24 18:01:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CFE1A88BE for ; Tue, 24 Feb 2015 18:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag3O_JfaC-l0 for ; Tue, 24 Feb 2015 18:01:28 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7627A1A88A3 for ; Tue, 24 Feb 2015 18:01:27 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so1682660wiv.2 for ; Tue, 24 Feb 2015 18:01:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Q69B03nzJB0hKCpMSn+WiV6zlSCTiIMyggWsWk2ZDgE=; b=PMF+Gb0mdrzwuThp6ahIHYckQqWqvmwgWuVwHkNqpf0hSerC+annlPzrGUI1ulNGoS 2zsFa/YDF3z4vW6l0SKGKRaSyXtR48UV31Q1NRfuZHfwmpthWZ6x1KaN4EC9/T0i8cvF 9x0Ab1SP29rY4pURYJAKFF/7Sp/1p+I86bNulg3S7AE0UN/ibTw1UDaTP43k2dq5JbwY ftqTYqSwGfqFZTEztrTvKBxRBPi+UDC80q2yGARuSbwEHK0/ICIlaraLm7Urzs3W5q9D QcvZ4TerS3KzSkTRwSttZ6y6TSYePqVe9GM3FW0AbqJnv5gXuSJkSn4eOiSU009ArzgA yMLw== X-Gm-Message-State: ALoCoQl0PX8o/1xci345x/KfN+Zw7l6HWpPmSNLGO5nYNWNUpoQN42I9mgmnprJ/jw3DbjD75brq X-Received: by 10.194.235.71 with SMTP id uk7mr1466762wjc.13.1424829686230; Tue, 24 Feb 2015 18:01:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.214.203 with HTTP; Tue, 24 Feb 2015 18:00:46 -0800 (PST) In-Reply-To: <201502242043.50128.davemgarrett@gmail.com> References: <201502242043.50128.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 24 Feb 2015 18:00:46 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=089e01493afa504470050fe00351 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Feb 2015 02:01:30 -0000 --089e01493afa504470050fe00351 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett wrote: > On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote: > > Folks, > > > > I'd like to get a sense of the WG on whether they want to pursue the > Update > > mechanism [0]. > > > > There are several possibilities here, including: > > > > - Just do basic Update > > - Move session ticket establishment to Update > > - Mode client authentication to Update > > > > My sense from the discussion in HNL was that people were generally > > positive on basic Update and unsure on the other two. If that's right, > > I'll buff up PR#94 for merge into the spec (pending chair approval). > > > > Thanks, > > -Ekr > > > > > > [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP > > version of the basic mechanism. > > The current proposal says: > > "An implementation MAY send an UpdateRekey at any time after > the handshake completes." > > Is there a particular reason to not just have an automatic rekey at > semi-regular intervals? So, every N records or M minutes (or whichever > comes first) an endpoint must send a rekey, and then after a similarly > measured interval the other endpoint sends a rekey; repeat ad infinitum. It's not entirely clear that we know how to design a good heuristic here, especially one that covers the entire range of possible algorithms. As a minor nit, it's kind of a pain to say every M minutes because often TLS stacks are driven by the application and don't have internal timers, but you could of course say "first record after M minutes" which would (probably) be close enough. > This would also ensure entropy for rekeying comes from both endpoints > equally over the course of the connection. Can you explain more about why that's an important consideration? > I would expect it would be better to not rely on implementations all > designing their own heuristics on when to send rekey updates, and also > would avoid multiple updates being sent at the same time by each endpoint > (and the possible pitfalls of doing so) The algorithm in this document is intended to be safe in the case of both simultaneous and (I believe) pipelined updates. I'd be interested in knowing if it's not. -Ekr --089e01493afa504470050fe00351 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Tuesday, February 24, 2015 07:44:22 pm Eric Re= scorla wrote:
> Folks,
>
> I'd like to get a sense of the WG on whether they want to pursue t= he Update
> mechanism [0].
>
> There are several possibilities here, including:
>
> - Just do basic Update
> - Move session ticket establishment to Update
> - Mode client authentication to Update
>
> My sense from the discussion in HNL was that people were generally
> positive on basic Update and unsure on the other two. If that's ri= ght,
> I'll buff up PR#94 for merge into the spec (pending chair approval= ).
>
> Thanks,
> -Ekr
>
>
> [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP
> version of the basic mechanism.

The current proposal says:

"An implementation MAY send an UpdateRekey at any time after
the handshake completes."

Is there a particular reason to not just have an automatic rekey at semi-re= gular intervals? So, every N records or M minutes (or whichever comes first= ) an endpoint must send a rekey, and then after a similarly measured interv= al the other endpoint sends a rekey; repeat ad infinitum.
=
It's not entirely clear that we know how to design a goo= d heuristic here,
especially one that covers the entire range of = possible algorithms.

As a minor nit, it's kind= of a pain to say every M minutes because
often TLS stacks are dr= iven by the application and don't have internal
timers, but y= ou could of course say "first record after M minutes"
w= hich would (probably) be close enough.

=C2=A0
This would also ensure entropy for rekeying= comes from both endpoints equally over the course of the connection.

Can you explain more about why that's an imp= ortant consideration?

=C2=A0
I would expect it would be better to not rely on implementa= tions all designing their own heuristics on when to send rekey updates, and= also would avoid multiple updates being sent at the same time by each endp= oint (and the possible pitfalls of doing so)

The algorithm in this document is intended to be safe in the case of both= simultaneous
and (I believe) pipelined updates. I'd be inter= ested in knowing if it's not.

-Ekr
<= br>
--089e01493afa504470050fe00351-- From nobody Tue Feb 24 19:45:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731121A1A04 for ; Tue, 24 Feb 2015 19:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgcf_noU7AwT for ; Tue, 24 Feb 2015 19:45:07 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 0A2571A0266 for ; Tue, 24 Feb 2015 19:45:07 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so1300957obc.9 for ; Tue, 24 Feb 2015 19:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ombWCNy8JKDvCgOLQFoT4PEfwwSnblvTNqPfMAE+cNA=; b=VN/qtM5sDuV/qsj5n8646ydamPT3gEanE37L5v142kiypyGczDqTemAgdwZzq1cQlg IZg+ZxXGSZvFgTrS4KSl18ZttXOnxiWXji79Dw3TDFo2+WXAU43rsDLJfavXB0BqChV9 dlxRLDzSxCRGX32hQsIa1Dq7RTdrLdJoh/tKnSc6IaLNhzEjdBfccwSQ8SrIalv08Nw7 a03xP+LfU67DHnRnkYgrnf64FH8cPS39LewI9KxJ550MY/CP8nhCTZG/8W7oRX5SAscX pzBLAkRNk7GEc6pKJNjPULApiB1P54VcCGfKQO9UhFbNvPrC5DgR2EGDMLpXVDL5j+VN Ugpg== MIME-Version: 1.0 X-Received: by 10.202.94.197 with SMTP id s188mr758232oib.94.1424835905346; Tue, 24 Feb 2015 19:45:05 -0800 (PST) Received: by 10.202.225.135 with HTTP; Tue, 24 Feb 2015 19:45:05 -0800 (PST) In-Reply-To: References: <201502242043.50128.davemgarrett@gmail.com> Date: Wed, 25 Feb 2015 16:45:05 +1300 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Feb 2015 03:45:08 -0000 On 25 February 2015 at 15:00, Eric Rescorla wrote: > As a minor nit, it's kind of a pain to say every M minutes because > often TLS stacks are driven by the application and don't have internal > timers, but you could of course say "first record after M minutes" > which would (probably) be close enough. In addition to this, it seems like more of a policy decision that is driven more by circumstance than any direct security requirement. We might recommend that rekeying occur for long sessions, but it's hard to pick a one-size-fits-all value to recommend. As low as 10 minutes might be appropriate for high-value, high-volume data; whereas an IoT device with low-value, low-volume data might be content with rekeying only for the purposes of session extension (i.e., on a scale of days or weeks). As proposed, there is no significant security benefit to the Update protocol other than to stave off key exhaustion. I think that's a fine thing on its own merits, but I don't think we need to place too much weight on the mechanism. From nobody Tue Feb 24 21:09:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13651A9096 for ; Tue, 24 Feb 2015 21:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-Nfpjgy1THw for ; Tue, 24 Feb 2015 21:09:12 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::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 DFA281A1B88 for ; Tue, 24 Feb 2015 21:09:11 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq11so570306vcb.9 for ; Tue, 24 Feb 2015 21:09:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=5BYIzrORYOxttcLE+FCXADRUD+WDbyev9jTbeDwOwyk=; b=UDPVqR38S7BK/hf5GXlOyGLUjWaJ6Y8bBU9JMHToPWnVKVXksfhO3Wnh+XiH7Y3Roj ipRF8ZQOYsWD8NZm86tztq2Alzgf4Mqng2Ta93KnoFjzVzUhkOGApMeN7hBx7tlV2QBr 7WpyYVTi9a7tyxUrsgs/9FbBtQPSgkeikrnVENTaxvbFXQfpc5Y5ILIxeo20tYwBKf4q jJsyUQSlKCOZ6I16aZOSQAOhgRz8lMawN/3cDItRW0gU19y1pM4VMaGb9za8rrQNCdQn yeSHzR30ut9jWXDtPja1iDLO4c3J3AxkhCVW/qyCssnSdAV1Gj7dAIPmeHMyYUk0ZCCY 6rGQ== X-Received: by 10.52.128.172 with SMTP id np12mr2109327vdb.92.1424840951055; Tue, 24 Feb 2015 21:09:11 -0800 (PST) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id ww6sm5187663vdc.21.2015.02.24.21.09.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Feb 2015 21:09:10 -0800 (PST) From: Dave Garrett To: Eric Rescorla Date: Wed, 25 Feb 2015 00:09:08 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201502242043.50128.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201502250009.08942.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Feb 2015 05:09:13 -0000 On Tuesday, February 24, 2015 09:00:46 pm Eric Rescorla wrote: > On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett > wrote: > > > On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote: > > > [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP > > > version of the basic mechanism. > > > > The current proposal says: > > > > "An implementation MAY send an UpdateRekey at any time after > > the handshake completes." > > > > Is there a particular reason to not just have an automatic rekey at > > semi-regular intervals? So, every N records or M minutes (or whichever > > comes first) an endpoint must send a rekey, and then after a similarly > > measured interval the other endpoint sends a rekey; repeat ad infinitum. > > It's not entirely clear that we know how to design a good heuristic here, > especially one that covers the entire range of possible algorithms. That's sort of my point; this proposal requires implementations to do so. I'm saying that picking one in the spec would be preferable to leaving it up to the whims of whatever the many combinations of implementations end up deciding. Even if some use-case needs to add rekeys, starting from a conservative heuristic in the spec would ensure implementations are provided with at least a general expectation of how to use this. > As a minor nit, it's kind of a pain to say every M minutes because > often TLS stacks are driven by the application and don't have internal > timers, but you could of course say "first record after M minutes" > which would (probably) be close enough. I'm not suggesting a precise heuristic here; just some semi-regular interval that would be more specific than "MAY ... at any time". With it left as vague as proposed, you could get deployments that never rekey or ones that decide to rekey stupidly frequently. (DoS risk if not implemented efficiently?) Picking any arbitrary interval would make things simpler and ensure that this feature is used sufficiently. The simplest route is to just specify a number of records to rekey after. > > This would also ensure entropy for rekeying comes from both endpoints > > equally over the course of the connection. > > Can you explain more about why that's an important consideration? It's just something that occurs to me with the current proposal. It allows for one sided rekeys, whereas the handshake gets randomness in each hello from each endpoint. It just strikes me as notably different to rely on just the one source of entropy here (plus previous). It's a "huh, interesting" thought not a "oh, that's horrible" thought. > > I would expect it would be better to not rely on implementations all > > designing their own heuristics on when to send rekey updates, and also > > would avoid multiple updates being sent at the same time by each endpoint > > (and the possible pitfalls of doing so) > > The algorithm in this document is intended to be safe in the case of both > simultaneous > and (I believe) pipelined updates. I'd be interested in knowing if it's not. Yes, I don't think it's a spec risk. An implementation risk is possible, though. It's a new feature that could end up with a new setting for an admin to fiddle with that probably doesn't need to be highly variable to do the job. Or put another way, it's a feature that I'm overthinking about the possibility of implementations overthinking how to use it. ;) Dave From nobody Wed Feb 25 00:18:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E141A1EF1 for ; Wed, 25 Feb 2015 00:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Kbsmu9YSd10 for ; Wed, 25 Feb 2015 00:18:06 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17211A1C06 for ; Wed, 25 Feb 2015 00:18:05 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 3DD38400D; Wed, 25 Feb 2015 10:18:03 +0200 (EET) Date: Wed, 25 Feb 2015 10:18:02 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150225081802.GA6434@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Feb 2015 08:18:09 -0000 On Tue, Feb 24, 2015 at 04:44:22PM -0800, Eric Rescorla wrote: > Folks, > > I'd like to get a sense of the WG on whether they want to pursue the Update > mechanism [0]. > > There are several possibilities here, including: > > - Just do basic Update This seems pretty okay to me. If there is some cryptographic concerns (that I can't see, and would really appeciate if those were pointed out[1]) of server sending data with pending certificate request[2], could those be addressed by having the client Update the connection after sending certificate and its verification? Regarding misuse potential of that, the client is unidentified at the point, so it seems pretty hard to misuse. Now, with some non-DHE key exchanges (mainly PAKE) you might have identified but unauthenticated client. I think it is reasonable for the TLS library to return error for attempts to obtain the client identification before it is authenticated. The present rule does not help here, since the authentication does not involve a client certificate. > - Move session ticket establishment to Update How does client know when it can resume a session? It takes 1RTT to get connection to state where it can transmit data, but 2RTT to state where it can resume (since server needs to have received client's second flight, or resume is not going to work right). > - Mode client authentication to Update This scares me. Not the crypto parts, but the misuse potential. Even doing it once seems as bad to me as doing it N times. If the protocol is something like imaps, submission(stmp) or ircs, then sure it looks safe. But try to use it e.g. with active HTTP/2 connection, and thing just go badly wrong. This is because adding/dropping certificates with multiplexed protocol needs substantial coordination at application layer to do safely. [1] And if there are such, I think SSH should carefully be analyzed, because it does pretty much exactly this. [2] Would be useful for e.g. protocol feature negotiation, since ALPN does not scale. E.g. consider wanting to use HTTP/2 with tokbind (ChannelID) + Websockets. -Ilari From nobody Wed Feb 25 20:47:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E941A00F9 for ; Wed, 25 Feb 2015 20:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtcM4o0CEki1 for ; Wed, 25 Feb 2015 20:47:51 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48171A000F for ; Wed, 25 Feb 2015 20:47:51 -0800 (PST) Received: by ykt10 with SMTP id 10so3039837ykt.1 for ; Wed, 25 Feb 2015 20:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pt+rmAy0/lTKL67FqHDTdCg9aoX29nnaUpglNwbKlEQ=; b=i1RFe41h6oAhbpR9rj6K81zJyxHEe/NE6Y+qQa/TkBOfUFcIHjlDgxKIUCyMOd/x0j sPGFKEFdI4zreanO9M4Gk2MYJs3tjaJm671tC9xbfExA9sWgZhzHf0HLiFKUogb98U3W K4nLYgb96/J0zYPJRH34hQN7XCJwpVdS7phJteVwa0aqjayhgEX/TU+0dv/Y33uG0rnn Qoq853xM4l22Nn6YEvBJbq8bIumQseRrPcvVGgJH/JuknxY/b9qEYQ6rZuENjQhaaJBg XHsPLuTDxFlDhB1blfLKg3mQlEkhQwhv5jeWy/ZHNFqjzsBxOEQgbGxrwm6hT9uwOabu T0sQ== MIME-Version: 1.0 X-Received: by 10.236.220.65 with SMTP id n61mr6483908yhp.44.1424926070921; Wed, 25 Feb 2015 20:47:50 -0800 (PST) Received: by 10.170.126.10 with HTTP; Wed, 25 Feb 2015 20:47:50 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Feb 2015 20:47:50 -0800 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Feb 2015 04:47:53 -0000 On Tue, Feb 24, 2015 at 4:44 PM, Eric Rescorla wrote: > Folks, > > I'd like to get a sense of the WG on whether they want to pursue the Update > mechanism [0]. > > There are several possibilities here, including: > > - Just do basic Update > - Move session ticket establishment to Update > - Mode client authentication to Update > > My sense from the discussion in HNL was that people were generally > positive on basic Update and unsure on the other two. If that's right, > I'll buff up PR#94 for merge into the spec (pending chair approval). Between update and the changes to the state machine in the Server and Client Hellos, the complexity of a combined TLS 1.2 and TLS 1.3 implementation will be considerable. I appreciate the issues with removing renegotiation wholesale, but this seems to introduce a lot of complexity for the usecases of long-lasting connections and TLS layer client authentication, and I don't think we've solved all the issues with the latter. That said, basic auth doesn't seem too bad, and I think my client authentication question has a lot more to do with semantics and how those are exposed then with the mechanism in the PR. Sincerely, Watson Ladd > > Thanks, > -Ekr > > > [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP > version of the basic mechanism. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Feb 26 08:53:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BAD1A8860 for ; Thu, 26 Feb 2015 08:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM9tzveK78B3 for ; Thu, 26 Feb 2015 08:53:54 -0800 (PST) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4294F1A8752 for ; Thu, 26 Feb 2015 08:53:54 -0800 (PST) Received: by mail-qg0-f46.google.com with SMTP id z107so9551108qgd.5 for ; Thu, 26 Feb 2015 08:53:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SikHtVWbV4KWGUGcrjeQNNtPqf9Udkoc7B6WIrS6u78=; b=ZzYVoyie59rx9em5OeRZIVDPR9+Y6NcMOfwqappXvJYCuVzX6KZx+P9oetP8gy5DpD 8dOhYI+xWX6RIfZyCF5YPWI9Azq3jUwVV1PHctDgU+s2M8ksdy7JIR8RDDTFiUngzf5l wM5hv+aOh+y2oUEhwQ26q7ZnZPxxW5xfpsiZE4ql4w5Wzyu8rO3yIsGfigFn9h8SCls4 Toyrw1OdTbf0W8L8ToqJswM2ZCDTVGcz71MVP+UjivkK5B/uUp1HlNurkUjGvmhp5iuj nsgEEheO+sUA8F4KhxMZY3ib/gdVUpswxk8KAIBKygRh2I9a4bpX7dOIEJyPHc+GihrQ EN/w== X-Gm-Message-State: ALoCoQkwmpVy8tzH0WkyAi7dQAFdsNMr+0uHW0Lb6BM56XeIt82NCqyxcivX2ZBHLsPJZaAjVY6Q MIME-Version: 1.0 X-Received: by 10.140.132.197 with SMTP id 188mr20569540qhe.24.1424969633460; Thu, 26 Feb 2015 08:53:53 -0800 (PST) Received: by 10.96.121.104 with HTTP; Thu, 26 Feb 2015 08:53:53 -0800 (PST) X-Originating-IP: [207.47.24.10] In-Reply-To: References: Date: Thu, 26 Feb 2015 08:53:53 -0800 Message-ID: From: Joseph Salowey To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c081fed1887905100098a1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Feb 2015 16:53:56 -0000 --001a11c081fed1887905100098a1 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 4:44 PM, Eric Rescorla wrote: > Folks, > > I'd like to get a sense of the WG on whether they want to pursue the Update > mechanism [0]. > > There are several possibilities here, including: > > - Just do basic Update > - Move session ticket establishment to Update > - Mode client authentication to Update > > My sense from the discussion in HNL was that people were generally > positive on basic Update and unsure on the other two. If that's right, > I'll buff up PR#94 for merge into the spec (pending chair approval). > > [Joe] I think client authentication should be handled separately. Unless update invalidates a session ticket (which I do not think it should), I think it would be better not to tie update and rekey to keep things simple. It may make sense to tie a client auth and session ticket refresh together. > Thanks, > -Ekr > > > [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP > version of the basic mechanism. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c081fed1887905100098a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 24, 2015 at 4:44 PM, Eric Rescorla <ekr@rtfm.com>= wrote:
Folks,

<= /div>
I'd like to get a sense of the WG on whether they want to pur= sue the Update
mechanism [0].

There are = several possibilities here, including:

- Just do b= asic Update
- Move session ticket establishment to Update
- Mode client authentication to Update

My sense= from the discussion in HNL was that people were generally
positi= ve on basic Update and unsure on the other two. If that's right,
<= div>I'll buff up PR#94 for merge into the spec (pending chair approval)= .


[Joe] I think = client authentication should be handled separately.=C2=A0 Unless update inv= alidates a session ticket (which I do not think it should), I think it woul= d be better not to tie update and rekey to keep things simple. =C2=A0 =C2= =A0

It may make sense to tie a client auth and ses= sion ticket refresh together. =C2=A0
=C2=A0
Thanks,
-Ekr


version of the basic mechanism.


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


--001a11c081fed1887905100098a1-- From nobody Thu Feb 26 12:34:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7321A8729 for ; Thu, 26 Feb 2015 12:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4DbRn2QO1I0 for ; Thu, 26 Feb 2015 12:34:46 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779501A1BE7 for ; Thu, 26 Feb 2015 12:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1546; q=dns/txt; s=iport; t=1424982886; x=1426192486; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=7NXaySA9zaWyw7gEYjtda4X+O9Zw+uFCS2Ul9mjRUls=; b=MwCUQ0jR1gdsDkSQOzvL5ZiZ2VhkA8+RYtEVHWSqxj0kroAOx5IhSPr8 2fxaf/Fx0Eykba3wyq7ftbd7gDb0ivKUdcD6C+BfP8WXX3NLENvTl4ln5 HFsRaxsORztrQpLLEcRj5ddQpHhDY4BDsO1RDWh4SGtnATerrFyB2v88g c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGBQDXgu9U/49dJa1bgwJSvGqFfIUjgXBNAQEBAQEBfIQRBDtEiXMIDa1+qT0BCgEBAQEBGASQHoMBgRQFhGSFdIh3hWWBG4tehlAjhA8dgnQBAQE X-IronPort-AV: E=Sophos;i="5.09,655,1418083200"; d="scan'208";a="399452875" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 26 Feb 2015 20:34:46 +0000 Received: from rtp-vpn6-659.cisco.com (rtp-vpn6-659.cisco.com [10.82.250.149]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1QKYfOk018522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Feb 2015 20:34:44 GMT From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com> Date: Thu, 26 Feb 2015 12:34:44 -0800 To: tls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [TLS] SCSV versioning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Feb 2015 20:34:48 -0000 I recently became aware that Microsoft IE won't implement SCSV. Near as = I can tell, this is the main concern, but it is not terribly detailed = about the concern: = https://connect.microsoft.com/IE/feedback/details/1002874/internet-explore= r-should-send-tls-fallback-scsv > One of the developers pointed out that the TLS_FALLBACK_SCSV feature = has a significant downside-- because it doesn't convey any specific = version information, it becomes a general "never fall back" signal. The = problem is that such signals are too broad; fallbacks were only ever = introduced because servers often use TLS stacks with implementation = bugs. Any "don't fallback" signal sent by such a server will be very bad = for compat. >=20 > Now, the counterargument is that servers should just implement TLS = properly and update when new versions are released and/or bugs are = found, but there's strong precedent showing that this just doesn't = happen. IE's decade long "DocumentMode/CompatibilityView" fiasco comes = from the fact that there was a single "StandardsMode" flag that the = majority of pages had opted-into without actually being standards = compliant. Has this concern been discussed in the working group? Should we resolve = this? (I think a resolution might be along the lines of "I have = previously tried 1.2 and 1.1", but really depends on one's = interpretation of the 'significant downside' concern that an IE = developer has.) Yes, I know SCSV has finished WG review and IESG review. -d From SRS0=DKok=DM=acm.org=bmoeller@srs.kundenserver.de Thu Feb 26 13:06:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938A41A8843 for ; Thu, 26 Feb 2015 13:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEbQyaQwk42V for ; Thu, 26 Feb 2015 13:06:33 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (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 EB21D1A87B0 for ; Thu, 26 Feb 2015 13:06:32 -0800 (PST) Received: from mail-ob0-f179.google.com ([209.85.214.179]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0MOELI-1YUPYI47L2-005Z7R for ; Thu, 26 Feb 2015 22:06:31 +0100 Received: by mail-ob0-f179.google.com with SMTP id wp4so14197101obc.10 for ; Thu, 26 Feb 2015 13:06:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.12.72 with SMTP id 69mr7082702oim.50.1424984789778; Thu, 26 Feb 2015 13:06:29 -0800 (PST) Received: by 10.76.144.230 with HTTP; Thu, 26 Feb 2015 13:06:29 -0800 (PST) In-Reply-To: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com> References: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com> Date: Thu, 26 Feb 2015 16:06:29 -0500 Message-ID: From: Bodo Moeller To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: multipart/alternative; boundary=001a113d0d16348af50510042060 X-Provags-ID: V03:K0:jTnvgMXNpqLY+/qsCjMmWCLooW2OblNPKBiCF6TflHt20isgOfM t0Z9mWtHx6hle5ha0iwdJPd3DVHHxuXcWTdaUnlksggtz8O077ogHfZITdUszL7GIJUfGJ8 kNnX6rijquVJiZ0L83s+g3xZB8eCAYV+KwJyOCtPcyjFJoUN8cb+GBPfsOtxwmmw/sgZcq9 2+frYb0d8p9YDxZjAKCdw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SCSV versioning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Feb 2015 21:07:09 -0000 --001a113d0d16348af50510042060 Content-Type: text/plain; charset=UTF-8 Dan Wing : I recently became aware that Microsoft IE won't implement SCSV. Near as I > can tell, this is the main concern [...]: > > One of the developers pointed out that the TLS_FALLBACK_SCSV feature has > a significant downside-- because it doesn't convey any specific version > information, it becomes a general "never fall back" signal. The problem is > that such signals are too broad; fallbacks were only ever introduced > because servers often use TLS stacks with implementation bugs. Any "don't > fallback" signal sent by such a server will be very bad for compat. > I haven't seen this particular complaint before, and also can't quite make sense of it. TLS_FALLBACK_SCSV is a signal sent by the client, not by the server as that statement implies (and of course, IE acts as a client). The specification (draft-ietf-tls-downgrade-scsv-05) says that clients SHOULD send TLS_FALLBACK_SCSV in fallback handshakes, and that servers MUST react to it in a specific way. This expressly gives clients some latitude, allowing trade-offs that may be needed for the sake of compatibility. (Also, if a client never does a fallback handshake, there's no reason to send TLS_FALLBACK_SCSV in the first place.) A related (in a Chinese-whispers way, anyway) complaint that I *have* seen is the one I've addressed in http://www.ietf.org/mail-archive/web/tls/current/msg14848.html. (See also https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/shepherdwriteup/ .) Bodo --001a113d0d16348af50510042060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dan = Wing <dwing@cisco.com>:

I recently became aware that Microsoft IE won't implemen= t SCSV.=C2=A0 Near as I can tell, this is the main concern [...]:

> One of the developers pointed out that the TLS_FALLBACK_SCSV feature h= as a significant downside-- because it doesn't convey any specific vers= ion information, it becomes a general "never fall back" signal. T= he problem is that such signals are too broad; fallbacks were only ever int= roduced because servers often use TLS stacks with implementation bugs. Any = "don't fallback" signal sent by such a server will be very ba= d for compat.

I haven't seen this p= articular complaint before, and also can't quite make sense of it. TLS_= FALLBACK_SCSV is a signal sent by the client, not by the server as that sta= tement implies (and of course, IE acts as a client). The specification (dra= ft-ietf-tls-downgrade-scsv-05) says that clients=C2=A0SHOULD send TLS_FALLB= ACK_SCSV in fallback handshakes, and that servers MUST react to it in a spe= cific way. This expressly gives clients some latitude, allowing trade-offs = that may be needed for the sake of compatibility. (Also, if a client never = does a fallback handshake, there's no reason to send TLS_FALLBACK_SCSV = in the first place.)

A related (in a Chinese-whisp= ers way, anyway) complaint that I *have* seen is the one I've addressed= in http://www.ietf.org/mail-archive/web/tls/current/msg14848.html. =C2= =A0(See also https://datatracker.ietf.org/doc/draft-ietf-t= ls-downgrade-scsv/shepherdwriteup/.)

Bodo


--001a113d0d16348af50510042060-- From nobody Thu Feb 26 16:26:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C1D1A0125 for ; Thu, 26 Feb 2015 16:26:33 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char F0 hex): Cc: \360\237\224\223Dan Wing ; Thu, 26 Feb 2015 16:26:32 -0800 (PST) Received: from dragaera.releasedominatrix.com (unknown [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 9512D1A00D1 for ; Thu, 26 Feb 2015 16:26:32 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id DC11233D050; Fri, 27 Feb 2015 00:26:01 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Bodo Moeller References: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com> From: Geoffrey Keating Date: 26 Feb 2015 16:26:01 -0800 In-Reply-To: Message-ID: Lines: 28 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] SCSV versioning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Feb 2015 00:26:34 -0000 Bodo Moeller writes: > Dan Wing : > > I recently became aware that Microsoft IE won't implement SCSV. Near as I > > can tell, this is the main concern [...]: > > > > > One of the developers pointed out that the TLS_FALLBACK_SCSV feature has > > a significant downside-- because it doesn't convey any specific version > > information, it becomes a general "never fall back" signal. The problem is > > that such signals are too broad; fallbacks were only ever introduced > > because servers often use TLS stacks with implementation bugs. Any "don't > > fallback" signal sent by such a server will be very bad for compat. > > > > I haven't seen this particular complaint before, and also can't quite make > sense of it. ... I believe it's the same thing I mentioned last year, in http://www.ietf.org/mail-archive/web/tls/current/msg11208.html The implicit assumption made by the SCSV is that all new servers (supporting the SCSV) will not have bugs requiring a fallback. As soon as that first server appears which supports SCSV but requires fallback, this SCSV can't be used. From SRS0=gnoC=DN=acm.org=bmoeller@srs.kundenserver.de Thu Feb 26 17:32:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85261A1AA7 for ; Thu, 26 Feb 2015 17:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqVhNpsbW_pw for ; Thu, 26 Feb 2015 17:32:45 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 7680C1A1AA2 for ; Thu, 26 Feb 2015 17:32:45 -0800 (PST) Received: from mail-ob0-f171.google.com ([209.85.214.171]) by mrelayeu.kundenserver.de (mreue004) with ESMTPSA (Nemesis) id 0MVHys-1Y1I0447lW-00YgSc for ; Fri, 27 Feb 2015 02:32:43 +0100 Received: by mail-ob0-f171.google.com with SMTP id gq1so15503005obb.2 for ; Thu, 26 Feb 2015 17:32:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.183.24.162 with SMTP id ij2mr8329449obd.18.1425000756577; Thu, 26 Feb 2015 17:32:36 -0800 (PST) Received: by 10.76.144.230 with HTTP; Thu, 26 Feb 2015 17:32:36 -0800 (PST) In-Reply-To: References: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com> Date: Thu, 26 Feb 2015 20:32:36 -0500 Message-ID: From: Bodo Moeller To: Geoffrey Keating Content-Type: multipart/alternative; boundary=001a1134a7aee69246051007d719 X-Provags-ID: V03:K0:z+lmDA/chEFokCsXz+6p87uo5Mx37C8PyaC9xBVqhJ3aIja/ihi Hg4/7AqiNy4Rc6c7xkKlFsKCtOWUe9IaasGGSLZP++9SSqcTfKpjkFT5btYm37MHYQohUTj JKvGcVlQzFFZSQ4TSbP7PYb+I9R349kPBJ4hG05Cu5qtvrXvQSlcPjmLW7q4OFAVMIsqolh LM8zczaMwA+D2X3XSzLUw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SCSV versioning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Feb 2015 01:40:27 -0000 --001a1134a7aee69246051007d719 Content-Type: text/plain; charset=UTF-8 > > I believe it's the same thing I mentioned last year, in > > http://www.ietf.org/mail-archive/web/tls/current/msg11208.html > > The implicit assumption made by the SCSV is that all new servers > (supporting the SCSV) will not have bugs requiring a fallback. As > soon as that first server appears which supports SCSV but requires > fallback, this SCSV can't be used. This would affect fallback handshakes from *future* protocol versions to TLS 1.2, as we've seen that it's not a problem in practice when falling back from TLS 1.2 to earlier versions. So it could mean that clients that want to maintain interoperability with servers that can't handle their TLS 1.3 handshake attempts might not want to send TLS_FALLBACK_SCSV in fallback handshake Client Hello messages announcing TLS 1.2. (The document's Security Considerations cover this, by the way.) I don't see how it could be a reason to not use the SCSV when falling back to a version below TLS 1.2. Bodo --001a1134a7aee69246051007d719 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe it's the same thing I mentioned last year, in
http://www.ietf.org/mail-archive/web/tls/current/msg11208= .html

The implicit assumption made by the SCSV is that all new servers
(supporting the SCSV) will not have bugs requiring a fallback.=C2=A0 As
soon as that first server appears which supports SCSV but requires
fallback, this SCSV can't be used.

This= would affect fallback handshakes from *future* protocol versions to TLS 1.= 2, as we've seen that it's not a problem in practice when falling b= ack from TLS 1.2 to earlier versions. So it could mean that clients that wa= nt to maintain interoperability with servers that can't handle their TL= S 1.3 handshake attempts might not want to send TLS_FALLBACK_SCSV in fallba= ck handshake Client Hello messages announcing TLS 1.2. (The document's = Security Considerations cover this, by the way.) I don't see how it cou= ld be a reason to not use the SCSV when falling back to a version below TLS= 1.2.

Bodo

--001a1134a7aee69246051007d719-- From nobody Thu Feb 26 17:53:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B4C1A0115 for ; Thu, 26 Feb 2015 17:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyAvxMtodq3t for ; Thu, 26 Feb 2015 17:52:59 -0800 (PST) Received: from dragaera.releasedominatrix.com (unknown [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 81F011A00E5 for ; Thu, 26 Feb 2015 17:52:59 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id F0AA533D050; Fri, 27 Feb 2015 01:52:28 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Bodo Moeller References: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com> From: Geoffrey Keating Date: 26 Feb 2015 17:52:28 -0800 In-Reply-To: Message-ID: Lines: 27 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] SCSV versioning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Feb 2015 01:53:01 -0000 Bodo Moeller writes: > > The implicit assumption made by the SCSV is that all new servers > > (supporting the SCSV) will not have bugs requiring a fallback. As > > soon as that first server appears which supports SCSV but requires > > fallback, this SCSV can't be used. > > > This would affect fallback handshakes from *future* protocol versions to > TLS 1.2, as we've seen that it's not a problem in practice when falling > back from TLS 1.2 to earlier versions. So it could mean that clients that > want to maintain interoperability with servers that can't handle their TLS > 1.3 handshake attempts might not want to send TLS_FALLBACK_SCSV in fallback > handshake Client Hello messages announcing TLS 1.2. (The document's > Security Considerations cover this, by the way.) I don't see how it could > be a reason to not use the SCSV when falling back to a version below TLS > 1.2. It affects any client which is talking to a server which is buggy and where the bugs can be avoided by a fallback. For example, a server with an issue in its TLS 1.2 implementation (perhaps in an extension), which could be solved by retry and fallback with TLS 1.1 or without the extension, would instead be prevented from working by the SCSV. As far as I know, there are no currently known examples of such servers, but it doesn't seem unreasonable that such a thing might appear in the future. From nobody Thu Feb 26 18:25:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABF41A6FF6 for ; Thu, 26 Feb 2015 18:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa7u1sUa8zLe for ; Thu, 26 Feb 2015 18:25:17 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 750FE1A1B6D for ; Thu, 26 Feb 2015 18:25:17 -0800 (PST) Received: from mail-oi0-f53.google.com ([209.85.218.53]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0M5tNd-1Xc5AI1A77-00xvmZ for ; Fri, 27 Feb 2015 03:25:15 +0100 Received: by mail-oi0-f53.google.com with SMTP id u20so13270378oif.12 for ; Thu, 26 Feb 2015 18:25:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.115.99 with SMTP id jn3mr8469334oeb.68.1425003904087; Thu, 26 Feb 2015 18:25:04 -0800 (PST) Received: by 10.76.144.230 with HTTP; Thu, 26 Feb 2015 18:25:04 -0800 (PST) In-Reply-To: References: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com> Date: Thu, 26 Feb 2015 21:25:04 -0500 Message-ID: From: Bodo Moeller To: Geoffrey Keating Content-Type: multipart/alternative; boundary=089e0116126e81be3f051008932c X-Provags-ID: V03:K0:RWx7vYoSbPawLm7FtIJ6AKU2KRWozoNUIvwUiE190PiPKa4LuEB RNdhejkUbGRYG1c6xYOnNChfukj5PBLR3D5rgBDfp6VHwdl6Xsp8SzRI3HlEpl4MbjZ0Tu9 c5KT6mMz3av4L50jvzQpoYG6vquxbH9yalaNPoMBhXXyM2y6e+N5hHNSNLc2iiLSTsXn+Bb 4QTm3sAYq7b8ZyC/7aiKA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SCSV versioning X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Feb 2015 02:25:19 -0000 --089e0116126e81be3f051008932c Content-Type: text/plain; charset=UTF-8 > > It affects any client which is talking to a server which is buggy and > where the bugs can be avoided by a fallback. For example, a server > with an issue in its TLS 1.2 implementation (perhaps in an extension), > which could be solved by retry and fallback with TLS 1.1 or without > the extension, would instead be prevented from working by the SCSV. > Certainly. However, now that a fair number of clients do support TLS_FALLBACK_SCSV and use it in fallback retries (or may not fall back at all), you should generally notice this kind of problem early as you try to deploy the new server: this server just would be obviously broken and so most likely won't make it far in its deployement. So I think this is extremely unlikely to become a concern in practice. If you really were to try and do everything to interoperate with any kind of theoretical server brokenness in your client, though, you'd end up with lots and lots of retries -- you couldn't even rely on cipher suite negotiation because the server might be getting individual cipher suites wrong, for example. The current reality of downgraded retries obviously isn't quite as complicated, but is more complicated than just protocol versions. TLS_FALLBACK_SCSV can take care of just one dimension, the protocol version, because it's meant to be very simple (yet meaningful for security) and because it would not make sense to perpetuate a snapshot of current implementation brokenness in a protocol change. Bodo --089e0116126e81be3f051008932c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It affects any client which is talking to a server which is bu= ggy and
where the bugs can be avoided by a fallback.=C2=A0 For example, a server with an issue in its TLS 1.2 implementation (perhaps in an extension),
which could be solved by retry and fallback with TLS 1.1 or without
the extension, would instead be prevented from working by the SCSV.

Certainly.=C2=A0 However, now that a fair numb= er of clients do support TLS_FALLBACK_SCSV and use it in fallback retries (= or may not fall back at all), you should generally notice this kind of prob= lem early as you try to deploy the new server: this server just would be ob= viously broken and so most likely won't make it far in its deployement.= =C2=A0 So I think this is extremely unlikely to become a concern in practic= e.

If you really were to try and do everything to = interoperate with any kind of theoretical server brokenness in your client,= though, you'd end up with lots and lots of retries -- you couldn't= even rely on cipher suite negotiation because the server might be getting = individual cipher suites wrong, for example.

The c= urrent reality of downgraded retries obviously isn't quite as complicat= ed, but is more complicated than just protocol versions. TLS_FALLBACK_SCSV = can take care of just one dimension, the protocol version, because it's= meant to be very simple (yet meaningful for security) and because it would= not make sense to perpetuate a snapshot of current implementation brokenne= ss in a protocol change.=C2=A0

Bodo

=
--089e0116126e81be3f051008932c--