From nobody Mon Dec 1 00:56:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6DE1A1A09 for ; Mon, 1 Dec 2014 00:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 Rzx7MqS92uDe for ; Mon, 1 Dec 2014 00:56:39 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EFC7A1A1A13 for ; Mon, 1 Dec 2014 00:56:38 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id AF0292AC06A; Mon, 1 Dec 2014 00:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=WUdDd6OlI9kjWb3CboDnZ8swBDQ=; b=srXbdIBjq26LFco77 MpDfGueW/eqVE+UbXOVXDwPJtgqcqfXqdLQ9V84d/sedD39bczdkczQPhVFo2Xlm HCwNUqoB8XKVWJLy03wdP/Uy5QCXaYsdwsRE8kuQH6TH96oVRgB22SlBpjviAkr1 8WitDzudXcVkPQpfOZwcqSZ/fo= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id 729BE2AC059; Mon, 1 Dec 2014 00:56:38 -0800 (PST) Received: from 74.125.57.49 (proxying for 74.125.57.49) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 1 Dec 2014 00:56:38 -0800 Message-ID: <6d8b33a4d2ed0a285450e3872bc155e7.squirrel@webmail.dreamhost.com> In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C739B9F7A14@uxcn10-tdc05.UoA.auckland.ac.nz> <9FE323BF-2650-4EA3-9CBB-B46CF3A00298@pahtak.org> Date: Mon, 1 Dec 2014 00:56:38 -0800 From: "Ryan Sleevi" To: "Martin Thomson" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VRDM1u0p-kqRWtzxxOu8snym6O8 Cc: Stephen Checkoway , tls@ietf.org Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 08:56:41 -0000 On Sun, November 30, 2014 11:17 pm, Martin Thomson wrote: > On 30 November 2014 at 13:52, Stephen Checkoway wrote: > > How is the signature algorithm any different from the cipher suite in > > this respect? If the client says it can only do ECDSA, what's the poi= nt > > of giving it an RSA cert that it cannot use? > > I think that the difference is that - at least for most clients - they > support both. Or at least, servers have been able to deploy ECDSA > certs that chain to RSA with the expectation that RSA hasn't gone away > yet. And that's relatively new. > > Peter refers to the fact that servers (and CAs) have picked a > certificate that works based on what they know of clients, and had > just the one. That single cert is offered unconditionally. If the > client doesn't like it, then it can be responsible for choking on it. > CAs could have offered a range of certificates with varying strength > and signature algorithms, but one is always easier in every regard. > > Migrating away from mostly RSA might have changed that a little. > Plus, there are plenty of libraries where the ciphersuite implementation is semi-independent of the certificate validation. Perhaps the largest deployment is Chrome, which uses a separate TLS library (NSS, BoringSSL) than its PKI validation (OS APIs such as CryptoAPI, Security.framework, or Android Keychain Services). You can certainly have skew where the TLS client supports a modern suite of algorithms, but the underlying platform does not. On Windows XP, this is the SHA-2 family (pre-SP3) and ECDSA (pre-Vista), and on OS X, some releases had some buggy ECDSA handling. There are also a number of embedded TLS stacks that provide the cryptographic framework for TLS, but then defer to external components (o= r hardware) for trust validation. I just mention these as real world cases where ciphersuites alone are insufficient (although SignatureAndAlgorithms generally is... except wher= e it isn't) From nobody Mon Dec 1 01:33:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181D01A1A19 for ; Mon, 1 Dec 2014 01:33:21 -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 6dlvkS1LnsxD for ; Mon, 1 Dec 2014 01:33:19 -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 04B731A0145 for ; Mon, 1 Dec 2014 01:33:19 -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 7971B1A2617; Mon, 1 Dec 2014 11:33:16 +0200 (EET) Date: Mon, 1 Dec 2014 11:33:16 +0200 From: Ilari Liusvaara To: Ryan Sleevi Message-ID: <20141201093316.GA4986@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C739B9F7A14@uxcn10-tdc05.UoA.auckland.ac.nz> <9FE323BF-2650-4EA3-9CBB-B46CF3A00298@pahtak.org> <6d8b33a4d2ed0a285450e3872bc155e7.squirrel@webmail.dreamhost.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6d8b33a4d2ed0a285450e3872bc155e7.squirrel@webmail.dreamhost.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AIFLWAMvvSmMN4PpMt7C-BFgSS8 Cc: Stephen Checkoway , tls@ietf.org Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2014 09:33:21 -0000 On Mon, Dec 01, 2014 at 12:56:38AM -0800, Ryan Sleevi wrote: > > Plus, there are plenty of libraries where the ciphersuite implementation > is semi-independent of the certificate validation. > > Perhaps the largest deployment is Chrome, which uses a separate TLS > library (NSS, BoringSSL) than its PKI validation (OS APIs such as > CryptoAPI, Security.framework, or Android Keychain Services). You can > certainly have skew where the TLS client supports a modern suite of > algorithms, but the underlying platform does not. On Windows XP, this is > the SHA-2 family (pre-SP3) and ECDSA (pre-Vista), and on OS X, some > releases had some buggy ECDSA handling. > > There are also a number of embedded TLS stacks that provide the > cryptographic framework for TLS, but then defer to external components (or > hardware) for trust validation. > > I just mention these as real world cases where ciphersuites alone are > insufficient (although SignatureAndAlgorithms generally is... except where > it isn't) Plus, it is easier to implement just ECDH than ECDSA over given curve, so implementations that can do ECDH over curve X but not ECDSA over curve X (but can do ECDSA over some other curve) should not be surprising. This might especially be so for CFRG curves. Vice versa might also happen (can do ECDSA over X, but not ECDH over X). Also, the algorithm lists can't specify restrictions like that ECDSA P-256 only works with SHA-256 and P-384 only works with SHA-384 (because code to do P-256 with SHA-384 is buggy). -Ilari From nobody Mon Dec 1 06:24:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202ED1A1BCC for ; Mon, 1 Dec 2014 06:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.331 X-Spam-Level: ** X-Spam-Status: No, score=2.331 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FSL_HELO_BARE_IP_2=1.999, 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 CmggSXYsJZS1 for ; Mon, 1 Dec 2014 06:24:40 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.41.245.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D381A1BC2 for ; Mon, 1 Dec 2014 06:24:40 -0800 (PST) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id F0543CB0862C4; Mon, 1 Dec 2014 08:24:39 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id CCBC9CB0861EA for ; Mon, 1 Dec 2014 08:24:39 -0600 (CST) Received: from [96.231.218.201] (port=49420 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XvRu3-00062C-5d; Mon, 01 Dec 2014 08:24:39 -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: Date: Mon, 1 Dec 2014 09:24:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <18A87018-87CC-41EA-BED7-1FE91EFF0DB1@ieca.com> References: To: Yoav Nir 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.218.201 X-Exim-ID: 1XvRu3-00062C-5d X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:49420 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s0hjTp2CKfOSJlFjkm9vi_fMfi8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2014 14:24:42 -0000 Yes please do. spt On Nov 27, 2014, at 03:13, Yoav Nir wrote: > Seeing as the 18th has come and gone, can I take the near silence as = confirmation that I can resubmit as a WG draft? >=20 > Yoav >=20 >> On Nov 11, 2014, at 5:17 AM, Sean Turner wrote: >>=20 >> All, >>=20 >> This message is confirming the WG consensus we reached in Toronto = about producing an updated RFC4492 that is bound for standard track.* = Yoav has produced an individual draft that can be found here: >>=20 >> http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ >>=20 >> that we would like the WG to consider adopting. Please let us know = by November 18th whether you object to adopting Yoav=92s draft (and = why). >>=20 >> spt >>=20 >> * This is for pre-TLS 1.3 because the 1.3 spec is going to = incorporate the EC text directly in the base spec. =20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Mon Dec 1 06:28:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B22C1A1BC2 for ; Mon, 1 Dec 2014 06:28:19 -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 i4DxlW-aOOBu for ; Mon, 1 Dec 2014 06:28:17 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7E31A1BB8 for ; Mon, 1 Dec 2014 06:28:17 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so7700345qcy.18 for ; Mon, 01 Dec 2014 06:28: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:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9TtgMW4AUasVq9184X55Mznnlp4j2SFaFb8eLhYTf50=; b=DLS160ClZv//DunwXiyaOChuSPXPhZGP4b52b7M2ho9msaxTHU7971Ib3fl4W5lcD5 ZMTSB6A1qTQZzTWGc3vmdsdGMQc6uC4R9KbPCfBR/X5AGdI+InbefDssB7ufVBSc7vRx fig2cwZXUBQ0Sy7Dn0ZIdjlxtiG79AvSqfvNlaX1z/Flbnkh6YDFBcUm4hu1scolYqos PissujWpiqc+MbpR36LyhYfHjTdQTxsxNVeTrDPJakWl+FSix0qaNslYqAF5+va7IezU 9Jb3TUx6O15Xu0ibH48byOgPEqSMRpTFVvyJ9QAVJLU2h6kuaXsFdCxeUH6qTYW7bDse MpHg== X-Gm-Message-State: ALoCoQko6nF3pG+2mvJZ5gCQMK1KdXmYGQ3SiwWIuYXZmaWL8vSWoIsKHiL+SmqH+PSC4ByYBMV0 X-Received: by 10.224.64.197 with SMTP id f5mr13257092qai.49.1417444096505; Mon, 01 Dec 2014 06:28:16 -0800 (PST) Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id w75sm17411815qgd.14.2014.12.01.06.28.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 06:28:15 -0800 (PST) Received: from ip-122-171.wireless.oberlin.edu (ip-122-171.wireless.oberlin.edu [132.162.122.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 61275AC287F; Mon, 1 Dec 2014 09:28:13 -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: Mon, 1 Dec 2014 09:28:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C739B9F7A14@uxcn10-tdc05.UoA.auckland.ac.nz> <9FE323BF-2650-4EA3-9CBB-B46CF3A00298@pahtak.org> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P0H3hHiLp6U-1K9JV6piBY2B7nU Cc: "" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2014 14:28:19 -0000 On Dec 1, 2014, at 2:17 AM, Martin Thomson = wrote: > On 30 November 2014 at 13:52, Stephen Checkoway wrote: >> How is the signature algorithm any different from the cipher suite in = this respect? If the client says it can only do ECDSA, what's the point = of giving it an RSA cert that it cannot use? >=20 > I think that the difference is that - at least for most clients - they > support both. Or at least, servers have been able to deploy ECDSA > certs that chain to RSA with the expectation that RSA hasn't gone away > yet. And that's relatively new. And clients can indicate that they support multiple options. I think = there's something that I'm missing. A client can indicate that it = supports {sha1, sha224, sha256, sha384, sha512} x {rsa, dsa, ecdsa} (I = assume no one wants to support md5 any longer). The quoted text that Peter objected to required all certs in the chain = to be signed with one of the specified algorithms. It doesn't require = the entire cert chain to be signed by the same algorithm. If the issue is that the extension takes an extra 36 bytes to specify = all combinations and people don't want to waste the bytes on the wire, = then that seems like a reasonable concern to me. But that's not what I = took Peter's point to be. > Peter refers to the fact that servers (and CAs) have picked a > certificate that works based on what they know of clients, and had > just the one. That single cert is offered unconditionally. If the > client doesn't like it, then it can be responsible for choking on it. > CAs could have offered a range of certificates with varying strength > and signature algorithms, but one is always easier in every regard. Sure, but I don't see how that changes the analysis any. If a client = supports n algorithm pairs, it can specify those n pairs. I don't see = how this makes it a "nonsensical requirements in TLS 1.2 that you pretty = much have to ignore in order to get an implementation that works." But = again, I'm probably missing something here. --=20 Stephen Checkoway From nobody Mon Dec 1 06:46:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297261A1BCD for ; Mon, 1 Dec 2014 06:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, 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 7Vmi-ZwIYSoY for ; Mon, 1 Dec 2014 06:46:02 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.34.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE63C1A0173 for ; Mon, 1 Dec 2014 06:46:01 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 269837DBFC08A; Mon, 1 Dec 2014 08:46:01 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 134AD7DBFC004 for ; Mon, 1 Dec 2014 08:46:01 -0600 (CST) Received: from [96.231.218.201] (port=49659 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XvSEi-0001U4-D8; Mon, 01 Dec 2014 08:46:00 -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: <18A87018-87CC-41EA-BED7-1FE91EFF0DB1@ieca.com> Date: Mon, 1 Dec 2014 09:45:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0C529F08-3A0C-4872-A807-0FDBBC851CAA@ieca.com> References: <18A87018-87CC-41EA-BED7-1FE91EFF0DB1@ieca.com> To: Yoav Nir 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.218.201 X-Exim-ID: 1XvSEi-0001U4-D8 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:49659 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SuM2qRarar7pp4Wjjz01esWPn5E Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2014 14:46:03 -0000 Sorry slightly more formally: There were no objections to adopting this draft expressed on the list. = There were some suggested tweaks to the text of the draft, but these = will be incorporated after WG adoption allowing for easy comparison of = 4492 to 4492bis changes using the datatracker. Please submit resubmit = the individual draft as a WG draft. spt On Dec 01, 2014, at 09:24, Sean Turner wrote: > Yes please do. >=20 > spt >=20 > On Nov 27, 2014, at 03:13, Yoav Nir wrote: >=20 >> Seeing as the 18th has come and gone, can I take the near silence as = confirmation that I can resubmit as a WG draft? >>=20 >> Yoav >>=20 >>> On Nov 11, 2014, at 5:17 AM, Sean Turner wrote: >>>=20 >>> All, >>>=20 >>> This message is confirming the WG consensus we reached in Toronto = about producing an updated RFC4492 that is bound for standard track.* = Yoav has produced an individual draft that can be found here: >>>=20 >>> http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ >>>=20 >>> that we would like the WG to consider adopting. Please let us know = by November 18th whether you object to adopting Yoav=92s draft (and = why). >>>=20 >>> spt >>>=20 >>> * This is for pre-TLS 1.3 because the 1.3 spec is going to = incorporate the EC text directly in the base spec. =20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Dec 1 14:29:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF3F1A6F0A for ; Mon, 1 Dec 2014 14:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, 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 oc6xYnfL8622 for ; Mon, 1 Dec 2014 14:28:49 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5051F1A883D for ; Mon, 1 Dec 2014 14:28:49 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so8577636qcx.12 for ; Mon, 01 Dec 2014 14:28:48 -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; bh=sErxzeReTw9Tm78WOGOfnxSgrO9ZeJTMRpJpjuzTm5Y=; b=eb16l2XDSVD/SY6v4atV48uByG/Acx2jPhXqHR2LJ4dH8fQUP2ytIOwy4QNKSa+1FC Dd/063hQomJsUPW3l+csXkYeJGPGRdJRtSoXhDmXopSGY//DbFKJbwd/viRmr/xwQJya LVf07BTB5a/yNEMwzdl2FJZcx8l8cZX550nluLTIQn5iqO7QHK5HOjmjg8fQZGAuhR75 XRh+uZdkurVJOmy0ITOD1dGxcEqwdu6DPtBzD9j3tosgHgWI8lBYR8f0tehRoULLdNmi fILj2jbSYHBclCDG2j6T8k0SGBCfQ9okl7PVwDTfsvLINK81VBXpQaKlC27atN59p1oq 7xeQ== 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=sErxzeReTw9Tm78WOGOfnxSgrO9ZeJTMRpJpjuzTm5Y=; b=bD7qSjhQr0Uh+32oQL7FAO+MMmF2lBj6A22DRX3EW1DQVVkYX88gi70fUnWhoLmrt9 WOp5geND+vsvmMiQ8I+6w4cPUrswy6kkWwSsgH7ZAEdG+b/te60e3Rlby54iS+zMNj4K y9YWG1cTHuoMxo+f9e+ij2WOSPNrJKtcRy13virc4yx+qi9gnfm7JX+IY4wfR8zDUl8V BooGpyOBt6HUQ/Rs3qnRiYD94P+YfcAEBfVdZQkyzKJeXgtwXbBWs7XJYB80+Fqqm0U7 lf0DeXVrmXZEj9UjXmaKNHr03numEO51NMAORekYeQYJn4G2AgT4QD1h34OnyhafZjA+ Ca3A== X-Gm-Message-State: ALoCoQnkVFSv9+Cxiy7HEGDD9kRYm7mI609eHXkubfyhS/bXi1MLZn0habEdbK95rEgF3N4jnlcl X-Received: by 10.224.25.79 with SMTP id y15mr41996906qab.78.1417472928492; Mon, 01 Dec 2014 14:28:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.162.1 with HTTP; Mon, 1 Dec 2014 14:28:28 -0800 (PST) In-Reply-To: References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> From: Adam Langley Date: Mon, 1 Dec 2014 14:28:28 -0800 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HYnTUEV1MU4FlRshvG2Uo0bIXVc Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2014 22:28:50 -0000 On Wed, Nov 26, 2014 at 6:09 AM, Eric Rescorla wrote: > If someone wants to contribute a PR so that we can have something > concrete to look at that would be even better. I have submitted a PR for the padding and context-string changes: https://github.com/tlswg/tls13-spec/pull/100 I did not change the CertificateVerify structure in the same commit because I'm not quite sure that I follow the reasoning. The CertificateVerify implicitly contains the client and server nonce because it contains all the preceding handshake messages. What's the motivation for duplicating them at the beginning? Is it simply to avoid having the opaque signer understand the TLS structure? If so, does the padding and context strings that I've just proposed break that? Cheers AGL From nobody Tue Dec 2 00:29:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AB81A01FA for ; Tue, 2 Dec 2014 00:29:37 -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 pYJ7i3HVhaD8 for ; Tue, 2 Dec 2014 00:29:36 -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 2C8B81A01F6 for ; Tue, 2 Dec 2014 00:29:35 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB28TX5d006215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 2 Dec 2014 03:29:33 -0500 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sB28TUMt001031 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2014 03:29:31 -0500 Message-ID: <1417508969.24362.9.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Adam Langley Date: Tue, 02 Dec 2014 09:29:29 +0100 In-Reply-To: References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.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.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M579KNKX50W407kSjmlHMCHQh-U Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 08:29:37 -0000 On Mon, 2014-12-01 at 14:28 -0800, Adam Langley wrote: > On Wed, Nov 26, 2014 at 6:09 AM, Eric Rescorla wrote: > > If someone wants to contribute a PR so that we can have something > > concrete to look at that would be even better. > > I have submitted a PR for the padding and context-string changes: > https://github.com/tlswg/tls13-spec/pull/100 > I did not change the CertificateVerify structure in the same commit > because I'm not quite sure that I follow the reasoning. The > CertificateVerify implicitly contains the client and server nonce > because it contains all the preceding handshake messages. What's the > motivation for duplicating them at the beginning? Is it simply to > avoid having the opaque signer understand the TLS structure? If so, > does the padding and context strings that I've just proposed break > that? Is this about the comment in https://www.ietf.org/mail-archive/web/tls/current/msg14764.html ? If yes, it is unrelated to the context issue. By having an explicit server random value, a server can delegate the TLS protocol to a worker process, while he can still verify that the connected peer is the intended. For that, the server only needs to explicitly set the server_random data and then verify the client's CertificateVerify message based on that. That would allow designs with privilege separation (e.g., similar to openssh's) to use TLS. Without the explicit random values, the server would have to receive the whole TLS transcript and calculate the hash over it. In short it allows the server or the client to provide a short proof that they established a session with a particular peer. regards, Nikos From nobody Tue Dec 2 05:26:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10B41A889A; Tue, 2 Dec 2014 05:26:30 -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 yAr2rrD7qFcr; Tue, 2 Dec 2014 05:26:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B793A1A1B66; Tue, 2 Dec 2014 05:26:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 05:26:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kE4BhEfL9v50jQaySnQbQ5VEdAE Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.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, 02 Dec 2014 13:26:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Author : Yoav Nir Filename : draft-ietf-tls-rfc4492bis-00.txt Pages : 31 Date : 2014-12-02 Abstract: This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 2 05:48:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C151A1B44 for ; Tue, 2 Dec 2014 05:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 1xBXe9-Tgw5g for ; Tue, 2 Dec 2014 05:48:54 -0800 (PST) Received: from vsp3.ballou.se (vsp3.ballou.se [91.189.40.101]) by ietfa.amsl.com (Postfix) with SMTP id 929EB1A1BAD for ; Tue, 2 Dec 2014 05:48:52 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp3.ballou.se (Halon Mail Gateway) with ESMTP for ; Tue, 2 Dec 2014 14:48:47 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id C39CB1DE96 for ; Tue, 2 Dec 2014 14:48:47 +0100 (CET) Message-ID: <547DC339.80800@streamsec.se> Date: Tue, 02 Dec 2014 14:48:41 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> In-Reply-To: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KiaP_-IodL_HRUdtX7nSmKUzdUQ Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 13:48:56 -0000 Sections 6: Server implementations SHOULD support all of the following cipher suites, and client implementations SHOULD support at least one of them: o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. Isn't this recommendation problematic? I don't think it is very common for servers to have more than one certificate, and a server can't support all four of these cipher suites, unless it has both one RSA certificate and one EC certificate. It makes more sense to require both server implementations and client implementations to support at least one of TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA or TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA and at least one of TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, and recommend servers to be configured to accept either TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA and TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA or TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, and recommend clients to offer at least one. On 2014-12-02 14:26, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier > Author : Yoav Nir > Filename : draft-ietf-tls-rfc4492bis-00.txt > Pages : 31 > Date : 2014-12-02 > > Abstract: > This document describes key exchange algorithms based on Elliptic > Curve Cryptography (ECC) for the Transport Layer Security (TLS) > protocol. In particular, it specifies the use of Elliptic Curve > Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of > Elliptic Curve Digital Signature Algorithm (ECDSA) as a new > authentication mechanism. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-00 > > > 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/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Dec 2 06:34:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187151A1B96 for ; Tue, 2 Dec 2014 06:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.096 X-Spam-Level: * X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AznJWcQKf411 for ; Tue, 2 Dec 2014 06:34:32 -0800 (PST) Received: from vps2.offspark.com (unknown [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5D31A1B69 for ; Tue, 2 Dec 2014 06:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=LYs167qaWCs8MSXHXc/0PvNxx5QQ5GUyHv+wTWaLCbw=; b=ld9tHAnmBFBqI0RY3X8csh3pH6fmgv8Lzfrld+a2DlgkevAwXWjXaKE+5rbpkYRW7YtKZNtMKmMVoHb7JbqPzh9CVThDaawZVM7ElJ1PWfcUhBsmxAVy6umI+vjJEkcXkVOq2JU5LUZeeRCz2rU3FT56YpF9BSRop3pOF6SMyF0=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XvoWy-00061Y-Ky; Tue, 02 Dec 2014 15:34:20 +0100 Message-ID: <547DCDF3.2000206@polarssl.org> Date: Tue, 02 Dec 2014 15:34:27 +0100 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: henrick@streamsec.se, tls@ietf.org References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> <547DC339.80800@streamsec.se> In-Reply-To: <547DC339.80800@streamsec.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M377sr2SdSVkcz9r0SA1Q0-fj3w Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:34:33 -0000 On 02/12/2014 14:48, Henrick Hellstrm wrote: > Server implementations SHOULD support all of the following cipher > suites, and client implementations SHOULD support at least one of > them: > > o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA > o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. > > Isn't this recommendation problematic? I don't think it is very common > for servers to have more than one certificate, and a server can't > support all four of these cipher suites, unless it has both one RSA > certificate and one EC certificate. > I think this is not a problem since the text is about server _implementations_ not actual server deployment. I'm more concerned about the choice of ECDH as opposed to ECDHE for the first two ciphersuites. Manuel. From nobody Tue Dec 2 09:06:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA241A6EDE for ; Tue, 2 Dec 2014 09:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 S0-fWi9xMpN3 for ; Tue, 2 Dec 2014 09:06:13 -0800 (PST) Received: from vsp9.ballou.se (vsp9.ballou.se [91.189.40.105]) by ietfa.amsl.com (Postfix) with SMTP id C282C1A1EFE for ; Tue, 2 Dec 2014 09:05:39 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp9.ballou.se (Halon Mail Gateway) with ESMTP; Tue, 2 Dec 2014 18:05:37 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 6299A1DE89; Tue, 2 Dec 2014 18:05:37 +0100 (CET) Message-ID: <547DF15C.4060804@streamsec.se> Date: Tue, 02 Dec 2014 18:05:32 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= , tls@ietf.org References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> <547DC339.80800@streamsec.se> <547DCDF3.2000206@polarssl.org> In-Reply-To: <547DCDF3.2000206@polarssl.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TsoxbwdIo8AGz4xvoOvOghohw_c Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:06:15 -0000 On 2014-12-02 15:34, Manuel Pégourié-Gonnard wrote: > I think this is not a problem since the text is about server_implementations_ > not actual server deployment. Well, it is a problem if the standard allows fully conformant clients to only support cipher suites that require the server to choose RSA certificates, because that rules out conformant servers to be deployed with only EC certificates. > I'm more concerned about the choice of ECDH as opposed to ECDHE for the first > two ciphersuites. Good point. From nobody Tue Dec 2 09:41:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FECB1A1EEA for ; Tue, 2 Dec 2014 09:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIOApGVL3ISM for ; Tue, 2 Dec 2014 09:41:18 -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 BC0881A6FBB for ; Tue, 2 Dec 2014 09:40:34 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7458A282FD0; Tue, 2 Dec 2014 17:40:33 +0000 (UTC) Date: Tue, 2 Dec 2014 17:40:33 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20141202174033.GW285@mournblade.imrryr.org> References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> <547DC339.80800@streamsec.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547DC339.80800@streamsec.se> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_etXW0RypDFAH2g-LxSPogVCLW4 Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt 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, 02 Dec 2014 17:41:19 -0000 On Tue, Dec 02, 2014 at 02:48:41PM +0100, Henrick Hellstr?m wrote: > Server implementations SHOULD support all of the following cipher > suites, and client implementations SHOULD support at least one of > them: > > o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA > o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. > > Isn't this recommendation problematic? I don't think it is very common for > servers to have more than one certificate, and a server can't support all > four of these cipher suites, unless it has both one RSA certificate and one > EC certificate. Given the far from universal support for ECDSA by clients, a server that wants to use ECDSA when possible, but still wants to interoperate with more than just a select few clients really SHOULD have both ECDSA and RSA certificates. The main reason it is not common for servers to have more than one certificate is that generally they have only RSA certificates, which have (practically) universal support. For what it is worth, Postfix (via OpenSSL) supports simultaneous deployment of both RSA and ECDSA keys/certs. In the near to medium term, any server that wants to deploy ECDSA should also deploy RSA, to avoid interoperability issues with a sizeable fraction of clients. -- Viktor. From nobody Tue Dec 2 10:05:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FF61A6F64 for ; Tue, 2 Dec 2014 10:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 m-iF7TB3NCi9 for ; Tue, 2 Dec 2014 10:05:45 -0800 (PST) Received: from vsp4.ballou.se (vsp4.ballou.se [91.189.40.102]) by ietfa.amsl.com (Postfix) with SMTP id 89CA31A6F2A for ; Tue, 2 Dec 2014 10:05:43 -0800 (PST) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp4.ballou.se (Halon Mail Gateway) with ESMTP for ; Tue, 2 Dec 2014 19:05:40 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 2F3CD1DE91 for ; Tue, 2 Dec 2014 19:05:40 +0100 (CET) Message-ID: <547DFF6F.6080505@streamsec.se> Date: Tue, 02 Dec 2014 19:05:35 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> <547DC339.80800@streamsec.se> <20141202174033.GW285@mournblade.imrryr.org> In-Reply-To: <20141202174033.GW285@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tEmqRVRFNtdAeyVChifQXM6CCrg Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:05:47 -0000 On 2014-12-02 18:40, Viktor Dukhovni wrote: > Given the far from universal support for ECDSA by clients, a server > that wants to use ECDSA when possible, but still wants to interoperate > with more than just a select few clients really SHOULD have both > ECDSA and RSA certificates. Fair enough, but is it really an acceptable outcome that a fully conformant server (that is deployed with only RSA certificates) and a fully conformant client (that only implements one of the mandatory ECDSA cipher suites) will not be able to negotiate a connection? From nobody Tue Dec 2 10:20:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780AB1A6F27 for ; Tue, 2 Dec 2014 10:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMB5hLewxnWF for ; Tue, 2 Dec 2014 10:19:58 -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 4AA641A3BA2 for ; Tue, 2 Dec 2014 10:19:58 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 40B1D282FD0; Tue, 2 Dec 2014 18:19:57 +0000 (UTC) Date: Tue, 2 Dec 2014 18:19:57 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20141202181956.GX285@mournblade.imrryr.org> References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> <547DC339.80800@streamsec.se> <20141202174033.GW285@mournblade.imrryr.org> <547DFF6F.6080505@streamsec.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547DFF6F.6080505@streamsec.se> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Lmi_d-XH9euNzhDDqCDz2c3ch_0 Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt 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, 02 Dec 2014 18:19:59 -0000 On Tue, Dec 02, 2014 at 07:05:35PM +0100, Henrick Hellstr?m wrote: > On 2014-12-02 18:40, Viktor Dukhovni wrote: > >Given the far from universal support for ECDSA by clients, a server > >that wants to use ECDSA when possible, but still wants to interoperate > >with more than just a select few clients really SHOULD have both > >ECDSA and RSA certificates. > > Fair enough, but is it really an acceptable outcome that a fully conformant > server (that is deployed with only RSA certificates) and a fully conformant > client (that only implements one of the mandatory ECDSA cipher suites) will > not be able to negotiate a connection? This document does not replace the mandatory to implement cipher suites in TLS 1.x. So the client and server MUST still both offer the usual (RSA-based) MTI cipher suites for each version of TLS they support. The text in question provides additional ciphersuites that conformant implementations SHOULD support. So in your example, a client that suports ECDH(E) only with ECDSA, will employ neither EC based key agreement nor EC based authentication. The various MTI cipher suites don't require either. This said, perhaps the asymmetry between the client and server requirements deserves more explanation. -- Viktor. From nobody Tue Dec 2 10:54:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561BC1A6FC9 for ; Tue, 2 Dec 2014 10:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, 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 tjAETHOICI65 for ; Tue, 2 Dec 2014 10:54:44 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.41.242.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA041A1A48 for ; Tue, 2 Dec 2014 10:54:44 -0800 (PST) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 2BA7C535E4E84; Tue, 2 Dec 2014 12:54:43 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 19CD4535E4E1A for ; Tue, 2 Dec 2014 12:54:43 -0600 (CST) Received: from [96.231.218.201] (port=60588 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xvsaw-0007hh-Ee; Tue, 02 Dec 2014 12:54:42 -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: Date: Tue, 2 Dec 2014 13:54:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: 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.218.201 X-Exim-ID: 1Xvsaw-0007hh-Ee X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:60588 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PkEBzoeVlglsr7vaMBrTjF0NGUE Cc: draft-thomson-sslv3-diediedie@tools.ietf.org Subject: Re: [TLS] WG adoption: draft-thomson-sslv3-diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:54:45 -0000 All, There have been some mail list discussion about this draft but nobody = objected to adopting this draft. Based on the amount of interest in = discussing the draft, we=92re going to adopt this draft to continue it=92s= evolution as opposed to declaring the discussion out of scope for the = WG. Authors, Please submit a WG version of the draft. Cheers, J&S (as chairs) On Nov 15, 2014, at 18:49, Sean Turner wrote: > All, >=20 > This message serves as a WG call for adoption of "Deprecating Secure = Sockets Layer Version 3.0": >=20 > https://datatracker.ietf.org/doc/draft-thomson-sslv3-diediedie/ >=20 > Please let us know by November 29th whether you object to adopting = this draft as a WG item (and why). >=20 > j/s > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Dec 2 13:40:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818441A6F21 for ; Tue, 2 Dec 2014 13:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.032 X-Spam-Level: * X-Spam-Status: No, score=1.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_71=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 HYx7CscUv2xQ for ; Tue, 2 Dec 2014 13:40:21 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.72.134]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576961A1EF8 for ; Tue, 2 Dec 2014 13:40:21 -0800 (PST) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 868D0EC65E007; Tue, 2 Dec 2014 15:40:20 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 74555EC65DFC1 for ; Tue, 2 Dec 2014 15:40:20 -0600 (CST) Received: from [96.231.218.201] (port=62644 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XvvBD-0008O8-VB for tls@ietf.org; Tue, 02 Dec 2014 15:40:20 -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: <20141202181956.GX285@mournblade.imrryr.org> Date: Tue, 2 Dec 2014 16:40:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> <547DC339.80800@streamsec.se> <20141202174033.GW285@mournblade.imrryr.org> <547DFF6F.6080505@streamsec.se> <20141202181956.GX285@mournblade.imrryr.org> To: 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.218.201 X-Exim-ID: 1XvvBD-0008O8-VB X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:62644 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/niixDuvdc3ixqqMyHFlPUnfapSg Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 21:40:22 -0000 On Dec 02, 2014, at 13:19, Viktor Dukhovni = wrote: > On Tue, Dec 02, 2014 at 07:05:35PM +0100, Henrick Hellstr?m wrote: >=20 >> On 2014-12-02 18:40, Viktor Dukhovni wrote: >>> Given the far from universal support for ECDSA by clients, a server >>> that wants to use ECDSA when possible, but still wants to = interoperate >>> with more than just a select few clients really SHOULD have both >>> ECDSA and RSA certificates. >>=20 >> Fair enough, but is it really an acceptable outcome that a fully = conformant >> server (that is deployed with only RSA certificates) and a fully = conformant >> client (that only implements one of the mandatory ECDSA cipher = suites) will >> not be able to negotiate a connection? >=20 > This document does not replace the mandatory to implement cipher > suites in TLS 1.x. So the client and server MUST still both offer > the usual (RSA-based) MTI cipher suites for each version of TLS > they support. This is correct - RFC 4492 didn=92t change the MTI cipher suites for = TLS1.0-1.2 and since 4492bis is just an update it won=92t change the MTI = cipher suites either. spt > The text in question provides additional ciphersuites that conformant > implementations SHOULD support. So in your example, a client that > suports ECDH(E) only with ECDSA, will employ neither EC based key > agreement nor EC based authentication. The various MTI cipher > suites don't require either. >=20 > This said, perhaps the asymmetry between the client and server > requirements deserves more explanation. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Dec 2 18:59:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06561A0032 for ; Tue, 2 Dec 2014 18:59:37 -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 BQSvlAatsltX for ; Tue, 2 Dec 2014 18:59:37 -0800 (PST) Received: from BLU004-OMC3S8.hotmail.com (blu004-omc3s8.hotmail.com [65.55.116.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239FD1A0025 for ; Tue, 2 Dec 2014 18:59:37 -0800 (PST) Received: from BLU177-W3 ([65.55.116.73]) by BLU004-OMC3S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Dec 2014 18:59:36 -0800 X-TMN: [MRDI9jZIKREHA9A+mWKmr9oIPnqzVbuD] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "tls@ietf.org" Date: Tue, 2 Dec 2014 18:59:36 -0800 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2014 02:59:36.0339 (UTC) FILETIME=[2BF19630:01D00EA5] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zuQmpHuQPdo6ZKGdCy8afiVHmGk Subject: [TLS] Combine TLS 1.0/1.1 into a single RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 02:59:38 -0000 Given that TLS 1.0 is not dying soon=2C I wonder if it would make sense to = combine TLS 1.0 and 1.1 into one RFC=2C given the minor changes involving t= he IV. This would include changing the mandatory to implement cipher suite = for TLS 1.0 to=A0TLS_RSA_WITH_3DES_EDE_CBC_SHA.=0A= =0A= Yuhong Bao = From nobody Tue Dec 2 23:40:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9761A00F8 for ; Tue, 2 Dec 2014 23:40:43 -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, 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 QQP1F6ZLH1TZ for ; Tue, 2 Dec 2014 23:40:39 -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 0C8B71A00F5 for ; Tue, 2 Dec 2014 23:40:38 -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=1417592440; x=1449128440; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=uTEqzvAokBP1Z7+ZupffdZ1BdgWgcL68vFQOxKT07/E=; b=KgIuheYPdinxryTn4SwymnxOYr5Zk9sKCwOHTWGaBCU4UW6tfLhkEZlo NM5EPIic882Yz4rmEIDVlyRt9a5Epoj/M+2TybNFdqm72SQjcGQq3uP97 1Zmt3o0dtTjBW7vGfxEG2i4khnPepCmCHXjGMKavMQuAn8tkRJDq6ByPT M=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="294589325" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Dec 2014 20:40:38 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.139]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 3 Dec 2014 20:40:37 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] WG adoption: draft-nir-tls-rfc4492bis Thread-Index: AdAOzG2PjhCBXx9VT5OuSUfiLwTLiQ== Date: Wed, 3 Dec 2014 07:40:36 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9F9C96@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: http://mailarchive.ietf.org/arch/msg/tls/WjpY2H63i7xaWa7QeYOdfxsC4H0 Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 07:40:43 -0000 Stephen Checkoway writes:=0A= =0A= >That seems wrong. In practice, a client connects and says I'm willing to= =0A= >communicate using protocol parameters X, Y, and Z. If the server can't=0A= >accommodate the client, it closes the connection. How is the signature=0A= >algorithm any different from the cipher suite in this respect?=0A= =0A= TLS conflates the algorithms used with TLS with the algorithms used for=0A= certificates. As others have pointed out, a server has control over the=0A= algorithms used for TLS, but no control over what's used in certificates.= =0A= Those are dictated by the CA. So it's OK for the client to say "I would li= ke=0A= one of the above for TLS", but it has no business saying "I expect your CA,= =0A= and every CA above it up to the root, to also use the algorithm(s) I've ask= ed=0A= for".=0A= =0A= Peter.=0A= From nobody Tue Dec 2 23:47:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A211A00EA for ; Tue, 2 Dec 2014 23:47:26 -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, 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 V3fBoMJ5Y4Gd for ; Tue, 2 Dec 2014 23:47:25 -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 6BF4D1A00E6 for ; Tue, 2 Dec 2014 23:47:25 -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=1417592846; x=1449128846; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=AgIebLdYTluIymZxMOXLPjkpz7+bmZD9bURAe2mhhIk=; b=Uv19vBeALxpaBPQ5deAE0E/lXDZwn56XYjeuh17ast5jJhjNaWjYcv+z GkhajqEN6UWLfxIFR8RQ2bdMkWzndnqepYfzrmJtne8X7YgBEN/GMe+Kz QE9Pp2y1+TTMLW09MP6KfHzPcc6E38x749udLLXbzU1MZ8PiiFS0qszkp o=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="294590289" 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; 03 Dec 2014 20:47:25 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.139]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 3 Dec 2014 20:47:23 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt Thread-Index: AdAOzWAIVtdWjTovTxSJ8Mu9AetCVw== Date: Wed, 3 Dec 2014 07:47:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9F9CAB@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: http://mailarchive.ietf.org/arch/msg/tls/vMbnYHd3IohsKB3qkN7z17YrWi8 Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 07:47:26 -0000 Viktor Dukhovni writes:=0A= =0A= >a server that wants to use ECDSA when possible, but still wants to=0A= >interoperate with more than just a select few clients really SHOULD have b= oth=0A= >ECDSA and RSA certificates.=0A= =0A= Do you want to be the one to tell your CIO that the CA tax on their entire= =0A= server infrastructure just doubled, all in the name of making a fashion=0A= statement?=0A= =0A= Peter.= From nobody Wed Dec 3 00:27:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9AE1A0110 for ; Wed, 3 Dec 2014 00:27: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 Eyv8YTtVlK16 for ; Wed, 3 Dec 2014 00:27:22 -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 CF4D01A00F1 for ; Wed, 3 Dec 2014 00:27:21 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B1025282D5F; Wed, 3 Dec 2014 08:27:20 +0000 (UTC) Date: Wed, 3 Dec 2014 08:27:20 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20141203082720.GH285@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C739B9F9CAB@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9F9CAB@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_ELEU8SttTOCNv4kIMqVpirsebo Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 08:27:24 -0000 On Wed, Dec 03, 2014 at 07:47:23AM +0000, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >a server that wants to use ECDSA when possible, but still wants to > >interoperate with more than just a select few clients really SHOULD have both > >ECDSA and RSA certificates. > > Do you want to be the one to tell your CIO that the CA tax on their entire > server infrastructure just doubled, all in the name of making a fashion > statement? For HTTPS, at this time often no, especially not given what EV certs typically cost. For SMTP with DANE, the marginal cost for a TLSA record is zero. Twice zero is still zero. However, the Let's Encrypt price for "DV" (Domain not Validated, or perhaps Definitively Vacuous) certs may again turn out to be a solution of $2x = x$. And I think they are not first to offer "free" certs, though the deployment cost in administrator effort may be where they prove to be cheaper if successful. Also in terms of software support, IIRC OpenSSL prior to the not quite yet released 1.0.2 does not process chain files for multiple certificates as well as one might expect (there are work-arounds). So I am not expecting multi-certificate deployments (and thus any ECDSA deployments) to become mainstream in the very near term. -- Viktor. From nobody Wed Dec 3 08:50:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0E91A1B3A for ; Wed, 3 Dec 2014 08:50:01 -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 M9pQeLTppkeN for ; Wed, 3 Dec 2014 08:49:59 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE401A1EF3 for ; Wed, 3 Dec 2014 08:49:53 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so18344463igb.0 for ; Wed, 03 Dec 2014 08:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Fc7dZl0kf834RKi0C8e3FJRCUo2WPDWPteA+iGL5cWs=; b=KVG8dcFQJqyakQdVZaVKkn0K9TVYrmHkWD49aRGTipuV4tsbNW4xYsd8IO8JaItt56 KkEX7ReOi3z/aOmrTcN2qIGGny5Xa52Ne5cvzubIBg0sx522c5HuYMFBImX19mlHzMQM ZRsrDRoLMHN7+SxOSvodj807yr666jCdsLHbq6qom2TLZIpPMHBiBkgMa/8Tk2V9b8ZH 8982X2pSeWYOUdsbjRxsHINndH7ScrjshOcehBanY9BMt5fd52hoPUErpEj5eiewmyay icP9RE5m+yzatktPdPUw5PZvw5NzZ0kOk2pIJThD/ByJTqb2PSthTxUUlvkTMiC+w4b6 LDBg== MIME-Version: 1.0 X-Received: by 10.107.4.210 with SMTP id 201mr5419162ioe.88.1417625392645; Wed, 03 Dec 2014 08:49:52 -0800 (PST) Received: by 10.107.134.170 with HTTP; Wed, 3 Dec 2014 08:49:52 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9F9C96@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C739B9F9C96@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 3 Dec 2014 11:49:52 -0500 Message-ID: From: Jeffrey Walton To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p_-UD77x-9g3i-TFG_OYeEOYmyA Cc: "" Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 16:50:01 -0000 On Wed, Dec 3, 2014 at 2:40 AM, Peter Gutmann wrote: > Stephen Checkoway writes: > >>That seems wrong. In practice, a client connects and says I'm willing to >>communicate using protocol parameters X, Y, and Z. If the server can't >>accommodate the client, it closes the connection. How is the signature >>algorithm any different from the cipher suite in this respect? > > TLS conflates the algorithms used with TLS with the algorithms used for > certificates. As others have pointed out, a server has control over the > algorithms used for TLS, but no control over what's used in certificates. > Those are dictated by the CA... Wouldn't that put certificate parameters (like signing algorithms) under the purview of PKIX WG? From nobody Wed Dec 3 15:37:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA7F1A1B93 for ; Wed, 3 Dec 2014 15:37:10 -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 akhZVcaWPyxY for ; Wed, 3 Dec 2014 15:37:08 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B221A1B80 for ; Wed, 3 Dec 2014 15:37:08 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so1927150obc.25 for ; Wed, 03 Dec 2014 15:37:07 -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=OshwyMc3G91hOnfXz9FQenPAR6Kfj1xa5MTNKXu+kOs=; b=b5v3IBq3iZlpIXeXmIkssPNMSSwCaLfIgrn3qvPFl3qAO0J0CZg16OIRIkPzdGH8xM 0GTh6rN+7yMy76uXSfYfoiGrLMBIpcKMsqvasXjv0XvXEkmLS8XjVv1ogBVhWUwAGBal lbllu6yhoE7FBfGuQG1SutFZXInJlQrftaqekipgC5HcR2C7M4JRneGo788kUaZ9zhmr DpcVsJTO3JLhyfVx2NVffF7KSUgCRzfHde1jmD/EgGZ5ZZhRlJ1zBmVipqUt6aHG7tkY PRpbWXWUtIMuTEnszMKV4blCxBMV/SBxzPluTXojGYHIlS5EhfacHbhDcmG5P/uGu6Qa PF2Q== X-Gm-Message-State: ALoCoQm/KVDgm+OgDnc6GgFhToRiACPLZ077WMeXNNt3cRfDKQOhB+g8i2FnzMLzUw4vmHrjTtnU MIME-Version: 1.0 X-Received: by 10.60.65.99 with SMTP id w3mr4911059oes.6.1417649827766; Wed, 03 Dec 2014 15:37:07 -0800 (PST) Received: by 10.76.19.144 with HTTP; Wed, 3 Dec 2014 15:37:07 -0800 (PST) In-Reply-To: <8FB8D433-184E-41DA-8DBD-E929B9E8E9C2@ieca.com> References: <8FB8D433-184E-41DA-8DBD-E929B9E8E9C2@ieca.com> Date: Wed, 3 Dec 2014 15:37:07 -0800 Message-ID: From: Brian Smith To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/At-LvMj07JEe4GrugP_oAQXtyOQ Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 23:37:11 -0000 On Tue, Nov 25, 2014 at 8:46 PM, Sean Turner wrote: > This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02. Please review the document and send your comments to the list by Friday, December 12, 2014. The current draft [1] says "(Since the cipher suite list in the ClientHello is ordered by preference, with the client's favorite choice first, signaling cipher suite values will generally appear after all cipher suites that the client actually intends to negotiate.)" The text in the draft should be changed to read something like "Clients SHOULD put the TLS_FALLBACK_SCSV after all cipher suites that the client actually intends to negotiate." Recently, it has been shown that it is problematic to put the TLS_FALLBACK_SCSV cipher suite ahead of any real cipher suites in the ClientHello, because doing so causes unintended handshake failures. I don't know whether it matters whether the TLS_FALLBACK_SCSV appears before or after the secure renegotiation SCSV (when the secure renegotiation SCSV appears after all the cipher suites that the client actually intends to negotiate). Nit: The current draft says "Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions [...]." The "Section 4" in that statement is a hyperlink to section 4 of the draft, but that is clearly not what was intended. Cheers, Brian [1] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-02 From nobody Wed Dec 3 16:30:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010881AD010 for ; Wed, 3 Dec 2014 16:29:40 -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 jxYmDwp9qUDf for ; Wed, 3 Dec 2014 16:29:38 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645B41AD008 for ; Wed, 3 Dec 2014 16:29:38 -0800 (PST) Received: by mail-oi0-f50.google.com with SMTP id a141so11497244oig.37 for ; Wed, 03 Dec 2014 16:29:37 -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=94f0CNthcy5Ergv8sJhrdZ84wzpXVyMn/OZvkvqhEVM=; b=zZddRCEqQixxyeJ71YR9XTXlQbmkEOtczeHPBZ5CPhyUNmb0EQLOZug+1A+w5YuPqP uOayzrxeKtZ2CvgqBruWIPOBHke5OQalZgR0IOaj6wAe/O1rJl2CtpkusS+mMlSv49QO IclqfR6G5kbk2CUgk5h/Ni745905ay8MlXKeZecpiuOLMr2Rx8YJZHaEXLF2Jrtme9eO +Kl0G5QdDiQBxZ3WKtP62qhEuak+n8bkpXvOdCN7lF4LaKFFqXEYb8rBVYpMLU9ExosY 1gjchT6R7d7UeAoDaIFcmCTKIKeqr08wdYcJM8/SwL1lQaJs4b8FyHES59B9pzHN/Y7e KXTA== MIME-Version: 1.0 X-Received: by 10.60.161.76 with SMTP id xq12mr5000157oeb.59.1417652977743; Wed, 03 Dec 2014 16:29:37 -0800 (PST) Received: by 10.202.115.4 with HTTP; Wed, 3 Dec 2014 16:29:37 -0800 (PST) In-Reply-To: References: <8FB8D433-184E-41DA-8DBD-E929B9E8E9C2@ieca.com> Date: Wed, 3 Dec 2014 16:29:37 -0800 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T50ljNwIsu9XNq4XBpLzp0Lo4qM Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 00:29:40 -0000 Your edit makes sense. On 3 December 2014 at 15:37, Brian Smith wrote: > Nit: The current draft says "Code Components extracted from this > document must include Simplified BSD License text as described in > Section 4.e of the Trust Legal Provisions [...]." The "Section 4" in > that statement is a hyperlink to section 4 of the draft, but that is > clearly not what was intended. That's a tooling problem with the (obviously limited) html conversion, not a draft issue. From nobody Wed Dec 3 18:19:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98CA1A1BD7 for ; Wed, 3 Dec 2014 18:16:52 -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 H1yfvJ3EL3cX for ; Wed, 3 Dec 2014 18:16:50 -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 717521A1AEB for ; Wed, 3 Dec 2014 18:16:50 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 106AB3A20B; Thu, 4 Dec 2014 03:16:48 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 02923429FA; Thu, 4 Dec 2014 03:16:48 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id F06351B03D; Thu, 4 Dec 2014 03:16:47 +0100 (CET) In-Reply-To: To: Brian Smith Date: Thu, 4 Dec 2014 03:16:47 +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: <20141204021647.F06351B03D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W5TufoTwA3EI0MrFB4aNE2oZGfk Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv 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, 04 Dec 2014 02:16:52 -0000 Brian Smith wrote: > Sean Turner wrote: >> This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02. >> Please review the document and send your comments to the list by Friday, >> December 12, 2014. > > The text in the draft should be changed to read something like > "Clients SHOULD put the TLS_FALLBACK_SCSV after all cipher suites that > the client actually intends to negotiate." That is silly. I don't think there is such a weird recommendation in rfc5746. > > Recently, it has been shown that it is problematic to put the > TLS_FALLBACK_SCSV cipher suite ahead of any real cipher suites in the > ClientHello, because doing so causes unintended handshake failures. This statement is self-contradictory. The entire and only purpose of this I-D is to cause handshake failures, which is why this entire proposal is currently totally bogus. Should I ever make any changes to a server in response to this document, then it will be continuing the handshake with ServerHello.server_version = { 3, 1 } if it appears in a ClientHello with ClientHello.client_version = { 3, 0 } plus a configuration setting to keep the server igoring the fallback scsv entirely. -Martin From nobody Wed Dec 3 19:05:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAED1A1B95 for ; Wed, 3 Dec 2014 19:03: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 bOdrvWZJcTR7 for ; Wed, 3 Dec 2014 19:03:32 -0800 (PST) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C911A000B for ; Wed, 3 Dec 2014 19:03:32 -0800 (PST) Received: by mail-oi0-f41.google.com with SMTP id a3so11936521oib.0 for ; Wed, 03 Dec 2014 19:03: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:cc:content-type; bh=PO5HI8pOIVx+cvpYPXeV8XGoBF0ol/N4HXjraND9GVY=; b=b3zrfM7lD9Q4JmaSlhSMOhJiOILHb712HIVoVA5dP7fs784Eq4e+bamLMCQOItOMws S5MPKosPrg1Eqj726rAvV6P7e8IR3L8++To9zx68lLVuvHB9Gh7kFCEQkzp8O0HMcVLj hTWtiwu+0S62rGRuF7j4xcGJpCCB+CHdyatTLnRQNN6PC2AtZRElcizBi4s812bXLJ9I 6Xq3SltXS7KUXnxsKUwMxV5IJc3sEL7h3jo+5+d986kNk65fbXOzZuEbte1ue5zgQ+sv 9sRKjWLbX+oLZSyyhU0tJ5r6DiUrUUnxS4Ub4bTlIu4qW2crpem2/RUV60wGO2MiipIC ALVQ== X-Gm-Message-State: ALoCoQnzVYlTs0tqQqfLt5uF6zFrMoypGG9HlWI6pvOSX/dhtvTjM7CZQRikbbN2Qp/HnZjDV9lG MIME-Version: 1.0 X-Received: by 10.182.205.164 with SMTP id lh4mr5159554obc.5.1417662211750; Wed, 03 Dec 2014 19:03:31 -0800 (PST) Received: by 10.76.19.144 with HTTP; Wed, 3 Dec 2014 19:03:31 -0800 (PST) In-Reply-To: <20141204021647.F06351B03D@ld9781.wdf.sap.corp> References: <20141204021647.F06351B03D@ld9781.wdf.sap.corp> Date: Wed, 3 Dec 2014 19:03:31 -0800 Message-ID: From: Brian Smith To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jVsknDRSZ-1Ro53Gs-qmIDUajac Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 03:03:34 -0000 Martin Rex wrote: > Brian Smith wrote: >> Sean Turner wrote: >>> This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02. >>> Please review the document and send your comments to the list by Friday, >>> December 12, 2014. >> >> The text in the draft should be changed to read something like >> "Clients SHOULD put the TLS_FALLBACK_SCSV after all cipher suites that >> the client actually intends to negotiate." > > That is silly. This suggestion is based on implementation experience, known interoperability issues, and testing that has been already reported on this list and on the openssl-dev list. > I don't think there is such a weird recommendation in rfc5746. Apparently, there is not yet evidence that RFC5746 has similar problems. >> Recently, it has been shown that it is problematic to put the >> TLS_FALLBACK_SCSV cipher suite ahead of any real cipher suites in the >> ClientHello, because doing so causes unintended handshake failures. > > This statement is self-contradictory. > > The entire and only purpose of this I-D is to cause handshake failures, That is true, but *only* in a specific set of circumstances. The problem is that handshake failures occur in other circumstances where the draft does not prescribe a failure. Cheers, Brian From nobody Wed Dec 3 23:42:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6BC1A88CB for ; Wed, 3 Dec 2014 23:42: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, 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 LT4koOd5NgFj for ; Wed, 3 Dec 2014 23:42:19 -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 0C72F1A0074 for ; Wed, 3 Dec 2014 23:42:17 -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=1417678939; x=1449214939; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=7qJ/m2nH2nkBj5Hfbb17h4U7KjWxfSfqd4mxl3Xri64=; b=Vh2gSKTm8MehgzNUH4NM+s9Fev8TeKqCeIF62DHmUdGKkpifgkSbtEKF 93nbH8RHxByhNpuFhZpv4GkcUyvsI5dKy+BPjceb+sDOlAR19dFg7hXU7 7V9UbxR8Re3kNvPt5IzW/l56fNC9mKYy9zkKBDXcnYbD8PPVH/DleMbKa A=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="294835745" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Dec 2014 20:42:15 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.139]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 4 Dec 2014 20:42:14 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] WG adoption: draft-nir-tls-rfc4492bis Thread-Index: AdAPldG0njcyRjMCRke2jv01iiBgXg== Date: Thu, 4 Dec 2014 07:42:13 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9FAA0F@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: http://mailarchive.ietf.org/arch/msg/tls/vp7bnKSQaXbyKXTA3TuRKgPrGBk Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 07:42:23 -0000 Jeffrey Walton yes:=0A= =0A= >Wouldn't that put certificate parameters (like signing algorithms) under t= he=0A= >purview of PKIX WG?=0A= =0A= Yes. That's the problem with this requirement (which others have already= =0A= pointed out), it's a layering violation. The TLS stack should not be=0A= dictating terms to the PKI implementation or the CA.=0A= =0A= That's not to say that PKIX doesn't do the same thing. Their CMP spec=0A= requires that the cert-transport layer pull apart the certificates that are= =0A= being communicated, extract the signature algorithm from the cert, and=0A= authenticate the messaging using the algorithm used to sign the cert. =0A= =0A= Both are a me-centric worldview, for TLS it's "the PKI does what the transp= ort=0A= tells it to", for PKIX it's "the transport does what the PKI tells it to". = If=0A= RFC 1958 gets updated at some point they should add "Redde Caesari quae sun= t=0A= Caesaris" as a design principle.=0A= =0A= Peter.= From nobody Thu Dec 4 00:54:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7131A8966 for ; Thu, 4 Dec 2014 00:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 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_SOFTFAIL=0.665] 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 f65cMLI3YgMP for ; Thu, 4 Dec 2014 00:53:56 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFD91A8963 for ; Thu, 4 Dec 2014 00:53:56 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0LbJdK-1XYv3A0K5a-00kyOI; Thu, 04 Dec 2014 09:53:54 +0100 Received: by mail-ob0-f169.google.com with SMTP id vb8so2483904obc.0 for ; Thu, 04 Dec 2014 00:53:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.111.229 with SMTP id il5mr5810449obb.31.1417683233013; Thu, 04 Dec 2014 00:53:53 -0800 (PST) Received: by 10.60.32.42 with HTTP; Thu, 4 Dec 2014 00:53:52 -0800 (PST) In-Reply-To: References: <8FB8D433-184E-41DA-8DBD-E929B9E8E9C2@ieca.com> Date: Thu, 4 Dec 2014 09:53:52 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e01536896820a430509601900 X-Provags-ID: V02:K0:HWo5m3eGGwsYJ/CfkN1OukV+uqcQ+hvkWHqDvh9IgkP 3dUrzAHU2EpEgRnjGa4egYVSJW7YWEDOOeEk/BY4K2rHOzco5A 80FkSO0XlsfGzFbec73cv7ubUJUrpYCJk0lVrrI04MqwZPqTz/ NsOJw76yVP99xrcaIHo6jV7BH+6IJFybMrcojmw8Dev+6RBPBH FX/TOERFUht08d67Z/SL8XuGNQNFlUYh6oBe+nihdzaAhaJtRK tKP8VGinW5hGxZ41O7LVxxlgOLcALVManQlr59ATQSecr4NjGi cDKiF3ooD+PXpoR0BKZtN7TiDfYdFr3H6vc54o7HQG3jkRUmSW svSYD0zgm+d5drbIOqwsOVhsjqnGhH+6WSBpn5XKtlCIkHrPbW PZaUjC+LmUOPvopW/xZtSLi5p2ICe1ThQpgkZmqWZKUxF8PmTw cX1MQ X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/445pbMS7o6ISak5PpXvtb4pS2M8 Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 08:54:01 -0000 --089e01536896820a430509601900 Content-Type: text/plain; charset=UTF-8 Martin Thomson : > On 3 December 2014 at 15:37, Brian Smith wrote: > > The text in the draft should be changed to read something like > > "Clients SHOULD put the TLS_FALLBACK_SCSV after all cipher suites that > > the client actually intends to negotiate." Your edit makes sense. > Yes, I agree. (The recommended behavior will be exactly the same, the change is only that it will be explicitly RECOMMENDED using RFC 2119 magic words where the current wording is possibly too vague, and certainly too complicated.) Bodo --089e01536896820a430509601900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com>:
On 3 December 2014 at 15:37, Brian= Smith <brian@= briansmith.org> wrote:
=
=C2=A0
> The text in the dra= ft should be changed to read something like
>= "Clients SHOULD put the TLS_FALLBACK_SCSV after all cipher suites tha= t
> the client actually intends to negotiate.= "

= Your edit makes sense.

Yes, I agree.

(The recommended behavior will be exactly the same, = the change is only that it will be explicitly RECOMMENDED using RFC 2119 ma= gic words where the current wording is possibly too vague, and certainly to= o complicated.)

Bodo

--089e01536896820a430509601900-- From SRS0=jrr9=AY=acm.org=bmoeller@srs.kundenserver.de Thu Dec 4 01:02:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AC81A896F for ; Thu, 4 Dec 2014 01:02:44 -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 Y-ddWvPwQpOQ for ; Thu, 4 Dec 2014 01:02:42 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0AC1A8966 for ; Thu, 4 Dec 2014 01:02:42 -0800 (PST) Received: from mail-ob0-f172.google.com ([209.85.214.172]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0MNKx7-1Y3M3y3zwn-006sEw for ; Thu, 04 Dec 2014 10:02:40 +0100 Received: by mail-ob0-f172.google.com with SMTP id wn1so12850969obc.17 for ; Thu, 04 Dec 2014 01:02:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.120.69 with SMTP id la5mr5947229obb.87.1417683758668; Thu, 04 Dec 2014 01:02:38 -0800 (PST) Received: by 10.60.32.42 with HTTP; Thu, 4 Dec 2014 01:02:38 -0800 (PST) In-Reply-To: <20141204021647.F06351B03D@ld9781.wdf.sap.corp> References: <20141204021647.F06351B03D@ld9781.wdf.sap.corp> Date: Thu, 4 Dec 2014 10:02:38 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0139fba6d6e46a05096038fa X-Provags-ID: V03:K0:I2ZxujAYKf+Qt8df14LmCL7PweBObT5CrWTtq4W0IQ3OlC+GuDO e1FohvrFfaTZMHx9tHMNH5jJ+3JQ4Yu7l81ezSA2XX7kv1j/u8tW637h24XIz7WTZ96hPLO ALG0XEB4anWYUR/QlvCweTFILJNVrb5oP6Vrgx4n1nw15GYpftNkvb2yic5gIcXi7Y3VXJF vFdSp2BPyTd3NDBeR7aGg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_8XftUYvORhOBwQ7ysnUbykfo10 Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 09:03:54 -0000 --089e0139fba6d6e46a05096038fa Content-Type: text/plain; charset=UTF-8 Martin Rex : > Brian Smith wrote: > Recently, it has been shown that it is problematic to put the > > TLS_FALLBACK_SCSV cipher suite ahead of any real cipher suites in the > > ClientHello, because doing so causes unintended handshake failures. > > This statement is self-contradictory. > > The entire and only purpose of this I-D is to cause handshake failures, No. The *purpose* is to prevent downgrade attacks. Handshake failures (under certain circumstances) are the *means* towards that purpose. When the server's highest protocol version doesn't exceed ClientHello.client_version, this doesn't apply and there's no point in aborting the handshake, regardless of whether and where TLS_FALLBACK_SCSV appears. I see no contradiction. Bodo --089e0139fba6d6e46a05096038fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:
Brian= Smith wrote:

> Recently, it has been shown that it is problematic to put the
> TLS_FALLBACK_SCSV cipher suite ahead of any real cipher suites in the<= br> > ClientHello, because doing so causes unintended handshake failures.
=C2=A0
This statement is self-contradictory.

The entire and only purpose of this I-D is to cause handshake failures,

No. The *purpose* is to prevent downgrade atta= cks. Handshake failures (under certain circumstances) are the *means* towar= ds that purpose.

When the server's highest pro= tocol version doesn't exceed ClientHello.client_version, this doesn'= ;t apply and there's no point in aborting the handshake, regardless of = whether and where TLS_FALLBACK_SCSV appears. I see no contradiction.
<= div>
Bodo

--089e0139fba6d6e46a05096038fa-- From nobody Thu Dec 4 05:35:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B061A1A22 for ; Thu, 4 Dec 2014 05:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, 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 qV85I0ws8LdQ for ; Thu, 4 Dec 2014 05:35:06 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.166.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E051B1A1A0C for ; Thu, 4 Dec 2014 05:35:05 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 07EE815B272B4; Thu, 4 Dec 2014 07:35:05 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id EB1D115B2727B for ; Thu, 4 Dec 2014 07:35:04 -0600 (CST) Received: from [96.231.218.201] (port=50397 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XwWYi-0006qU-D2 for tls@ietf.org; Thu, 04 Dec 2014 07:35:04 -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: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> Date: Thu, 4 Dec 2014 08:35:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <53C88933-FB85-4E27-B1C5-E0987CA44027@ieca.com> References: <20141202132629.8023.24760.idtracker@ietfa.amsl.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.218.201 X-Exim-ID: 1XwWYi-0006qU-D2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:50397 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/j5ofOuU0iokj3YePJByPsJTUuR4 Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 13:35:11 -0000 Yoav, I=92m sure this is on your list but just in case somebody thinks these = are coming out of nowhere: please ensure that the errata are addressed: = http://www.rfc-editor.org/errata_search.php?rfc=3D4492&rec_status=3D15&pre= sentation=3Dtable Thanks, spt On Dec 02, 2014, at 08:26, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security Working = Group of the IETF. >=20 > Title : Elliptic Curve Cryptography (ECC) Cipher = Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier > Author : Yoav Nir > Filename : draft-ietf-tls-rfc4492bis-00.txt > Pages : 31 > Date : 2014-12-02 >=20 > Abstract: > This document describes key exchange algorithms based on Elliptic > Curve Cryptography (ECC) for the Transport Layer Security (TLS) > protocol. In particular, it specifies the use of Elliptic Curve > Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use = of > Elliptic Curve Digital Signature Algorithm (ECDSA) as a new > authentication mechanism. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Dec 4 05:35:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7608A1AD383 for ; Thu, 4 Dec 2014 05:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, 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 bec6oqHz_8Et for ; Thu, 4 Dec 2014 05:35:14 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [74.52.223.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C0A1AD38A for ; Thu, 4 Dec 2014 05:35:10 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 87AAE881FB366; Thu, 4 Dec 2014 07:35:09 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 74AF2881FB30A for ; Thu, 4 Dec 2014 07:35:09 -0600 (CST) Received: from [96.231.218.201] (port=50397 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XwWYm-0006qU-Up for tls@ietf.org; Thu, 04 Dec 2014 07:35:09 -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: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> Date: Thu, 4 Dec 2014 08:35:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9BBACE0A-481D-4287-A9D8-2CA9A6E1820E@ieca.com> References: <20141202132629.8023.24760.idtracker@ietfa.amsl.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.218.201 X-Exim-ID: 1XwWYm-0006qU-Up X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:50397 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZFYTuUiOaRS1zmd_bK0jHTEJY10 Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 13:35:15 -0000 Yoav, I=92m sure this is on your list but just in case somebody thinks these = are coming out of nowhere: please ensure that the errata are addressed: = http://www.rfc-editor.org/errata_search.php?rfc=3D4492&rec_status=3D15&pre= sentation=3Dtable Thanks, spt On Dec 02, 2014, at 08:26, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security Working = Group of the IETF. >=20 > Title : Elliptic Curve Cryptography (ECC) Cipher = Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier > Author : Yoav Nir > Filename : draft-ietf-tls-rfc4492bis-00.txt > Pages : 31 > Date : 2014-12-02 >=20 > Abstract: > This document describes key exchange algorithms based on Elliptic > Curve Cryptography (ECC) for the Transport Layer Security (TLS) > protocol. In particular, it specifies the use of Elliptic Curve > Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use = of > Elliptic Curve Digital Signature Algorithm (ECDSA) as a new > authentication mechanism. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Dec 4 06:20:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485841AD3D5 for ; Thu, 4 Dec 2014 06:20:22 -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 gBWckqlSQ8Nf for ; Thu, 4 Dec 2014 06:20:19 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120EF1AD3D4 for ; Thu, 4 Dec 2014 06:20:19 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so28104786wid.0 for ; Thu, 04 Dec 2014 06:20:17 -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=XBYGdkX7cJFGtzIDCqt2zeR/7Wy1fgRC9CHhJD1wjmc=; b=HZFD1ztyUCXFVOMm71pWFJm5eHuRgj8r9OFNs1s8J+m+UFSxaO7B2npWhrVP1l3xV+ +gidAsGCE/ov24LAzrHjnevYTJUfAW3S6g6Ke5r+c/h2GSBsE/8coI1TUn5K371OuCUG VxlAAD3YQdAuAU+QkxrbQYDlqVK8zteKvyIPAiW/Q663sOG4TZH3MeiwEgaEyWI8ArZo nb3NRLszA6Hq2sMXpqF3wvdDGUsKZ7KBZtdxRnRO/OSRPJwMSLLq75o3N/kfQz5jISSp aVP+YBSsIRrVkUSH5Zt9jFp9wcP+Lb9ssmourEc7fWVrDGd7FzJEf60JFwPDeMn3x/f5 5eZw== X-Received: by 10.180.13.7 with SMTP id d7mr22291525wic.57.1417702817790; Thu, 04 Dec 2014 06:20:17 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id je12sm30655606wic.22.2014.12.04.06.20.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 06:20:16 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <9BBACE0A-481D-4287-A9D8-2CA9A6E1820E@ieca.com> Date: Thu, 4 Dec 2014 16:20:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00C179D5-0A57-4744-B8FC-DDDE0F4CDE76@gmail.com> References: <20141202132629.8023.24760.idtracker@ietfa.amsl.com> <9BBACE0A-481D-4287-A9D8-2CA9A6E1820E@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gwxXiCm1Nk3JIg3-Z-iZqWAd0X0 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 14:20:22 -0000 OK. > On Dec 4, 2014, at 3:35 PM, Sean Turner wrote: >=20 > Yoav, >=20 > I=92m sure this is on your list but just in case somebody thinks these = are coming out of nowhere: please ensure that the errata are addressed: > = http://www.rfc-editor.org/errata_search.php?rfc=3D4492&rec_status=3D15&pre= sentation=3Dtable >=20 > Thanks, >=20 > spt >=20 > On Dec 02, 2014, at 08:26, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Transport Layer Security Working = Group of the IETF. >>=20 >> Title : Elliptic Curve Cryptography (ECC) Cipher = Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier >> Author : Yoav Nir >> Filename : draft-ietf-tls-rfc4492bis-00.txt >> Pages : 31 >> Date : 2014-12-02 >>=20 >> Abstract: >> This document describes key exchange algorithms based on Elliptic >> Curve Cryptography (ECC) for the Transport Layer Security (TLS) >> protocol. In particular, it specifies the use of Elliptic Curve >> Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use = of >> Elliptic Curve Digital Signature Algorithm (ECDSA) as a new >> authentication mechanism. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Dec 5 10:41:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3617C1AD51C; Fri, 5 Dec 2014 10:41:11 -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 kq02F4S8_ihK; Fri, 5 Dec 2014 10:41:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E881AD51E; Fri, 5 Dec 2014 10:41:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205184109.11527.64092.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 10:41:09 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M_uivpdoELzf-6P7NhKPC1KS-ZM Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-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: Fri, 05 Dec 2014 18:41:11 -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 : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-04.txt Pages : 22 Date : 2014-12-05 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 5 12:19:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF5F1A016A for ; Fri, 5 Dec 2014 12:19:48 -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 m9oJOz5JYbst for ; Fri, 5 Dec 2014 12:19:46 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6C91A0143 for ; Fri, 5 Dec 2014 12:19:46 -0800 (PST) Received: from [10.70.10.53] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id EE36DF984 for ; Fri, 5 Dec 2014 15:19:43 -0500 (EST) Message-ID: <54821354.1040608@fifthhorseman.net> Date: Fri, 05 Dec 2014 15:19:32 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Icedove/34.0 MIME-Version: 1.0 To: tls@ietf.org References: <20141205184109.11527.64092.idtracker@ietfa.amsl.com> In-Reply-To: <20141205184109.11527.64092.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OACCiTDotOUBx9IvXpMktM4vlDTw0iMAp" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rpgELwY30VdGgY5MOlK39d7q7TA Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-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: Fri, 05 Dec 2014 20:19:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OACCiTDotOUBx9IvXpMktM4vlDTw0iMAp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/05/2014 01:41 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. >=20 > Title : Negotiated Finite Field Diffie-Hellman Epheme= ral Parameters for TLS > Author : Daniel Kahn Gillmor > Filename : draft-ietf-tls-negotiated-ff-dhe-04.txt > Pages : 22 > Date : 2014-12-05 The main change here is to reduce the weakest group from ffdhe2432 to ffdhe2048, as the result of the straw poll here. I've published primality proofs of p and q for all four groups online for those who want to verify them: https://dkg.fifthhorseman.net/ffdhe-primality-proofs/ Regards, --dkg --OACCiTDotOUBx9IvXpMktM4vlDTw0iMAp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUghNVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcNbsP/2LbzOVhpS36PQ0xWICKKrjy fc3T5GnLephEkr+6qzzii8fTE/RvZrtbbmOustfM8yOeR0iq/RPqOSWFtmpB58wy f/KuHiYAZkRo7DRg5iDJGHDg8tIxknprxzv8Oe6slWAoH2BIVrKx5L1o8hJa1CO3 K3DsmkEsVZDBICtVuQD8vpqclyzHyaqQm257dI2OdzXGNUooU6UMM7/cYI3wRbNu 5RLt6KkqNvzG7ijqtfxtaYt2/Hk4T0WaKNeWyK4k3joVT/we2UtINdi7CZjhNkFq BJjn18Bl9ocDcrJpZc2UgpIZSxo5bi0Ts5tMsrtcWCItHvm5Sxjd45yb7zO3Vy35 2aisxDWB53Krh1EPGTvQq83AIIQSHrXauz6P+JpcSFG4c2iGPS/oThLCskf/DuIw ilY5x49c1ms6JK+/LvhQt8VQRbDz57pNd+RwsG7udcT/sf22NdDm+VVgi9gLpGkl sfzMYY6IuQeyrObV1pvEY+r2Epje79f4DQvVqiknJdhk9MZV2ThnynoJrceyTKl4 aoX0bPL7CAZGO3fEf6moKBxY623ejooU3Hp0szoaSNrFWeRckiBng/8v8yNvpgV3 OuHORLbXvdUjixQhJ7T48I+eG+rIvNYpcQfz6iPOOsBcE5a2nyMha5QV01qAjcjK 24Qs6dvh08ouZexeGdLw =skqf -----END PGP SIGNATURE----- --OACCiTDotOUBx9IvXpMktM4vlDTw0iMAp-- From nobody Sat Dec 6 01:58:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B2C1A9007 for ; Sat, 6 Dec 2014 01:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 GxRMBCqvj6RP for ; Sat, 6 Dec 2014 01:58:44 -0800 (PST) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (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 DC2C91A88EF for ; Sat, 6 Dec 2014 01:58:44 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sB69wZss023248; Sat, 6 Dec 2014 04:58:35 -0500 Date: Sat, 6 Dec 2014 04:58:35 -0500 (EST) From: Nikos Mavrogiannopoulos To: tls , Peter Gutmann Message-ID: <835421324.7469504.1417859915250.JavaMail.zimbra@redhat.com> In-Reply-To: <545514D4.6010900@polarssl.org> References: <9A043F3CF02CD34C8E74AC1594475C739B9DC255@uxcn10-5.UoA.auckland.ac.nz> <545514D4.6010900@polarssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: rfc7366: status Thread-Index: iqHBHOKLM3FLb5ZGbh3nWYG1ss6P3g== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8I-wgTUnqro7q0KAgac--6wFh3o Subject: [TLS] rfc7366: status X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 09:58:46 -0000 ----- Original Message ----- > > If anyone can come up with a clear one-paragraph note (which, when posted > > to > > the list, no-one complains about :-), I'd be happy to use that. > > > I didn't see people complain about your text here [1], nor about my fixed > text > here [2] so far :) > > [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw > [2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs Hello, Is there any update on RFC7366 errata process? Is there a plan to update the existing text? regards, Nikos From nobody Sat Dec 6 19:09:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9621A7032 for ; Sat, 6 Dec 2014 19:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_37=0.6, 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 9xhLttUl9rnt for ; Sat, 6 Dec 2014 19:09:17 -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 3CEDF1A802A for ; Sat, 6 Dec 2014 19:09:16 -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=1417921756; x=1449457756; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=YMPR0ylEBO/0T9thVZN/g5tUYouU1hdhKML6vT9t7kA=; b=h+XDd3mZeXwdIik8k5dMUC44Q/cB96VTvPAybjDaAfZM4Bf3FDi6Twr1 3qd/r/1x2wPD6yJQ1CBVHf+IZzpGZ4nG3CFbu3pLbuNEELxP60QBdUN3O hzjrWtxS9bJ7P2sxAdcJ6YuhdPyMV0KDnhTLEj0TaLw6EFcTnRJaxsyL4 s=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="295298635" 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; 07 Dec 2014 16:09:14 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.159]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sun, 7 Dec 2014 16:09:14 +1300 From: Peter Gutmann To: "" Thread-Topic: rfc7366: status Thread-Index: AdARyy2xBUfdikGMR7uNIL1XUxOQjA== Date: Sun, 7 Dec 2014 03:09:13 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF329DE@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4b4KeJktxS0N1TmrTQMKlj-3Lg4 Subject: Re: [TLS] rfc7366: status X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 03:09:23 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >Is there any update on RFC7366 errata process? Is there a plan to update t= he=0A= >existing text?=0A= =0A= I'd sent the following as a private message to some of the people involved = in=0A= the discussion, I haven't had any feedback yet so I guess it's OK? In that= =0A= case I'll submit it as an update...=0A= =0A= -- Snip --=0A= =0A= Note that the length value used for the MAC computation differs from the=0A= length value as encoded on the wire since the MAC value is not included in = the=0A= MAC computation. The value of the 'uint16 length' field in the TLSCipherte= xt=0A= record therefore differs from the length value used in the MAC calculation,= =0A= since the TLSCiphertext record contains both the ciphtertext and the MAC,= =0A= while the MAC calculation is performed only over the ciphertext. The lengt= h=0A= value encoded in the TLSCiphertext record is therefore 'length' while the= =0A= length value used in the MAC calculation is 'length -=0A= SecurityParameters.mac_length'.=0A= =0A= More formally, if:=0A= =0A= TLSCiphertext.content =3D ENC(content + padding + padding_length)=0A= =0A= then in TLS notation the MAC calculation for TLS 1.0 without the explicit= =0A= Initialization Vector (IV) is:=0A= =0A= MAC(MAC_write_key, seq_num +=0A= TLSCipherText.type +=0A= TLSCipherText.version +=0A= length of (TLSCiphertext.content) +=0A= TLSCiphertext.content);=0A= =0A= and for TLS 1.1 and greater with an explicit IV is:=0A= =0A= MAC(MAC_write_key, seq_num +=0A= TLSCipherText.type +=0A= TLSCipherText.version +=0A= length of (IV + TLSCiphertext.content) +=0A= IV +=0A= TLSCiphertext.content);=0A= =0A= -- Snip --=0A= =0A= I didn't use TLSCiphertext.fragment since that includes the MAC so I've had= to=0A= invent a new name 'TLSCiphertext.content', not sure if that's the best opti= on.=0A= =0A= Peter.=0A= From nobody Sun Dec 7 21:22:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924351ACEEA; Fri, 5 Dec 2014 08:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_pkY6BL3--j; Fri, 5 Dec 2014 08:05:52 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6206F1ACEE2; Fri, 5 Dec 2014 08:05:50 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so850415lbj.27 for ; Fri, 05 Dec 2014 08:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=bP01U3hW3pQRrqceKcv+mBzoxshrAFhMEM9u2Au6ij4=; b=z5UXXuqMKID/jD2FSmEmAxDk950wX/XXg+dcMcOdx5jT96q1HkW5d8vOGoXOTlYiys qZJuMfCByPnm3OFdR5CXdb5GdsqT7Ik+4zCqAWZs2qgha6PDN4tA+k7awY/VLFlp78Dm o0lIqUHrDxFln9xskCtbA6+sT7lu1BhYuKBrXjrIZE3BFYVU2SNeG86tYi5ric0Oabb+ oggHmzsWrpQV0pcEUH+KZuonnal30Gna3sA+4bFJVlI7Mt3CQw98Djl0l/8a6MoPixQo GZ4JiK4+/lySsU4ltmw1+6iXAf7KaW674WjHEibnyIuCx7b3akZsMs+9JZBARzg59KSR JN8w== MIME-Version: 1.0 X-Received: by 10.112.160.137 with SMTP id xk9mr3550919lbb.99.1417795548760; Fri, 05 Dec 2014 08:05:48 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Fri, 5 Dec 2014 08:05:48 -0800 (PST) Date: Fri, 5 Dec 2014 11:05:48 -0500 X-Google-Sender-Auth: ScrB4ZmkvdirApm0mEwjCLBz7Hg Message-ID: From: Phillip Hallam-Baker To: "pkix@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c38c700c52bf05097a406b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uw-t4Q0F6J9fdt6wetk8WRkpGjU X-Mailman-Approved-At: Sun, 07 Dec 2014 21:22:39 -0800 Subject: [TLS] New version of TLS Feature X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2014 16:05:54 -0000 --001a11c38c700c52bf05097a406b Content-Type: text/plain; charset=UTF-8 https://tools.ietf.org/html/draft-hallambaker-tlsfeature-06 The main difference from the previous one is to reword the processing requirements to state that if you are required to use TLS with a valid certificate because of a protocol specification or security policy requirement the connection has to be refused. It is of course open for the client to chose their course of action in cases where use of TLS is optional. --001a11c38c700c52bf05097a406b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11c38c700c52bf05097a406b-- From nobody Mon Dec 8 04:00:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363B11A0318 for ; Mon, 8 Dec 2014 04:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 4IvOdEIX4C5J for ; Mon, 8 Dec 2014 04:00:16 -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 0DF1D1A028A for ; Mon, 8 Dec 2014 04:00:16 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id B746D3A6DC; Mon, 8 Dec 2014 13:00:13 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 68437413FE; Mon, 8 Dec 2014 13:00:13 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 568D61B04E; Mon, 8 Dec 2014 13:00:13 +0100 (CET) In-Reply-To: <835421324.7469504.1417859915250.JavaMail.zimbra@redhat.com> To: Nikos Mavrogiannopoulos Date: Mon, 8 Dec 2014 13:00:13 +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: <20141208120013.568D61B04E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XegmzGCmFaEJ3vNbZxFxDwpdjVw Cc: tls Subject: Re: [TLS] rfc7366: status 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: Mon, 08 Dec 2014 12:00:18 -0000 Nikos Mavrogiannopoulos wrote: > >>> If anyone can come up with a clear one-paragraph note (which, when posted >>> to >>> the list, no-one complains about :-), I'd be happy to use that. >>> >> I didn't see people complain about your text here [1], nor about my fixed >> text >> here [2] so far :) >> >> [1] http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw >> [2] http://mailarchive.ietf.org/arch/msg/tls/zYBKe9L9n3tNZ_SBWn77ubLzNPs > > Is there any update on RFC7366 errata process? Is there a plan to > update the existing text? I firmly believe that rfc7366 is fubar (fouled up beyond repair--at least beyond the RFC errata process). The protocol part of that document ought to be entirely rewritten, in a fashion that Yngve outlined in his feedback: http://www.ietf.org/mail-archive/web/tls/current/msg14399.html -Martin From nobody Mon Dec 8 06:31:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505201A906E for ; Mon, 8 Dec 2014 06:31:53 -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 Zyj0MtejK96a for ; Mon, 8 Dec 2014 06:31:51 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A751A8760 for ; Mon, 8 Dec 2014 06:31:51 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so4938227wiv.14 for ; Mon, 08 Dec 2014 06:31:50 -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=8/fOS/pGIpyqm9fgT7cVif894mPKxFzaUbmW0VwZTAs=; b=0EVLTcKGUtyYIHLdEQHSVRxgRk99vbhMWP+Ou7igl11V/ec9GZOw9VD9f7DDXrzt2v e6Sa62CaiVB/+PrNoVNU3NPpC2zEdhT9++nzDhTbk05QKzvUHIFSXzFIhiUijlqoYOwL 6YRFXrPHo1M4dH4/Fo8z1tWIoDJdogjRDF5GEDEc3zr30mkY0TkzKC2QuxgJ2KXBD5xV DdEwB+QPp5LGGQlbLAw5VB7PdCOvr20dcJvGeF9jfRXbAOBiZNmufYYg0lVuVR/FJ677 nPQVBCmqhVbdeRIktirmaEKp2tl3azCDaf4oqMw1zGBB+T01u94hgDyrZzai1w9A8cjo 16BQ== X-Received: by 10.180.77.79 with SMTP id q15mr24342304wiw.8.1418049110337; Mon, 08 Dec 2014 06:31:50 -0800 (PST) Received: from [172.24.248.241] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id p5sm10006909wix.7.2014.12.08.06.31.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 06:31:49 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_0CFBD57B-872F-4BFE-81C0-6887711B9469" Message-Id: Date: Mon, 8 Dec 2014 16:31:48 +0200 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/huCd1cUek_n2HOXJrS2RgBZZMNE Subject: [TLS] RFC4492bis - merging errata X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 14:31:53 -0000 --Apple-Mail=_0CFBD57B-872F-4BFE-81C0-6887711B9469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi folks I=E2=80=99ve created PR #1 for merging the errata([1]) for RFC 4492 = ([2]). Let me know if this is controversial https://github.com/tlswg/rfc4492bis/pull/1 = Yoav [1] http://www.rfc-editor.org/errata_search.php?rfc=3D4492 = [2] http://tools.ietf.org/html/rfc4492 = --Apple-Mail=_0CFBD57B-872F-4BFE-81C0-6887711B9469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi folks

I=E2=80=99ve created PR #1 for merging the errata([1]) for = RFC 4492 ([2]).

Let me know if this is controversial

https://github.com/tlswg/rfc4492bis/pull/1

Yoav

[1] http://www.rfc-editor.org/errata_search.php?rfc=3D4492
[2] http://tools.ietf.org/html/rfc4492
= --Apple-Mail=_0CFBD57B-872F-4BFE-81C0-6887711B9469-- From nobody Tue Dec 9 15:56:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB03C1A6EFB; Tue, 9 Dec 2014 15:56: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 v8poJ_SoqZLT; Tue, 9 Dec 2014 15:56:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B0C1A01C6; Tue, 9 Dec 2014 15:56:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141209235638.17332.55238.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 15:56:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HoBfqlD0Kx4MC4zhKY_RA1oqce0 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-sslv3-diediedie-00.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, 09 Dec 2014 23:56:42 -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 : Deprecating Secure Sockets Layer Version 3.0 Authors : Richard Barnes Martin Thomson Alfredo Pironti Adam Langley Filename : draft-ietf-tls-sslv3-diediedie-00.txt Pages : 6 Date : 2014-12-02 Abstract: Secure Sockets Layer version 3.0 (SSLv3) [RFC6101] is no longer secure. This document requires that SSLv3 not be used. The replacement versions, in particular Transport Layer Security (TLS) 1.2 [RFC5246], are considerably more secure and capable protocols. This document updates the backward compatibility sections of the TLS RFCs to prohibit fallback to SSLv3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 9 22:12:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8F1A1B85 for ; Tue, 9 Dec 2014 22:12:12 -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 AkK2Kys354dj for ; Tue, 9 Dec 2014 22:12:11 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375BF1A1B73 for ; Tue, 9 Dec 2014 22:12:11 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id nt9so1861992obb.5 for ; Tue, 09 Dec 2014 22:12:10 -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=XO0S4VJFJRW1k6dNcH7lKdMkNThlkre+S5FYdqvhCRg=; b=UHanIGLGLER4m29wzpfj0RBbSkeAZSVHk55/93emtTsNA7/ajpU0XuuGMO7HJHzgDI KON+YDpsm3ZC6EgWIdKmHKmI1DI0GszgZR/J/ORfzco4guO/t4HmGIOPVunOvKW18pzX 1xK7UXBnd3mCPGQ/vwC+mER4nPbNwv6wT/mpRxgpcPHnYD26fx9lT+6lPswPL/3NpFVz 8+0cUkr/rpYgbkKcyJ5JxTlEza5qecrLAI97omMe/i8u3YnDeS70H2Xn8FhuAL8IZHC9 NZ89UGcDJtqHLGFKS/QrR9pVNhGzFfJcLiXjFeA2cuSri64i/1mwjD9f6t1GhqX+KOl2 iy9g== X-Gm-Message-State: ALoCoQnOXAQZu6nkxtWDLtlaDykPYsAN8gqHi0pjNNJUrOUsHacU12H1jnpGYRCCLfprM3E3EwD6 MIME-Version: 1.0 X-Received: by 10.202.9.142 with SMTP id 136mr1265368oij.89.1418191930538; Tue, 09 Dec 2014 22:12:10 -0800 (PST) Received: by 10.76.19.144 with HTTP; Tue, 9 Dec 2014 22:12:10 -0800 (PST) Date: Tue, 9 Dec 2014 22:12:10 -0800 Message-ID: From: Brian Smith To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Uyw7l9kWC4hWrOCriHHzuN5gUq0 Subject: [TLS] False Start and 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: Wed, 10 Dec 2014 06:12:12 -0000 1. TLS 1.3 will have its own 1-RTT mechanism, so it makes less (no?) sense do do False Start for TLS 1.3. 2. During the development and testing of TLS 1.3, it is far from clear that a TLS 1.3 handshake will be as secure as a TLS 1.2 handshake. It seems likely, in fact, that for some handshakes, due to implementation bugs, and/or problems in new parts of the protocol, that TLS 1.3 could be a security downgrade from TLS 1.2, at least until TLS 1.3 gets its RFC number. 3. During the development of TLS 1.3, my understanding is that an extension will be used to negotiate which draft of TLS 1.3 is being spoken. This extension would only be safe for False Start if every draft were equally secure, which is unlikely. Because of these reasons, the False Start draft should be updated to say that False Start MUST NOT be used for TLS 1.3 and later. Cheers, Brian From nobody Tue Dec 9 22:34:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49B21A1B9A for ; Tue, 9 Dec 2014 22:34:01 -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 56BM1SKLelLU for ; Tue, 9 Dec 2014 22:33:51 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783E91A1B73 for ; Tue, 9 Dec 2014 22:33:51 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id gq1so1743020obb.23 for ; Tue, 09 Dec 2014 22:33:51 -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=IHCB48ljxE5DZn6RgQMXns4pSZDz7lGOB207fe7t+DY=; b=IpMBedvZPmZEzK98dZz5j4LG/5bMWhoem5TBpECf479JGdhjKZ1P/cjfLo7N9gvWJp nfFJ3dsVNSORLdh72m1GKIf3Ke+dVyeEsgkn1LJD9+UdVxunhSrATYM8NHP+5aqbwNK1 dnGVYkXpVg61kZHSlhP4hqe9t+YvmiUdve6J4fL2rjgB3e0MF1KlCKJ1c+b3rA1Ncsro 6l6sG8LkK4rJEE9oEeTwxrdsOxkRSLmq5tCi8cg+rmD+P9cF1CgDd6fsrMrFKGPufETQ ZkuptCvIHCCOAHgFIyGUFLFQmWvQFHPS2jUELlBdiGX1JKns93RKGBwoLmKvcRmNGVP+ +iXg== X-Gm-Message-State: ALoCoQnnfi5krWyuo4/mq53y3X6R+i7jdlMKktawxU8e0Skqg3kpsOSIwxAl5fSRlPVt7wnEjYbE MIME-Version: 1.0 X-Received: by 10.182.5.71 with SMTP id q7mr1549697obq.28.1418193230987; Tue, 09 Dec 2014 22:33:50 -0800 (PST) Received: by 10.76.19.144 with HTTP; Tue, 9 Dec 2014 22:33:50 -0800 (PST) Date: Tue, 9 Dec 2014 22:33:50 -0800 Message-ID: From: Brian Smith To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-9orxj7fDpNqJoT3m-W5G8HEIwc Subject: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 06:34:02 -0000 * The vast majority of servers that pick DHE key exchange, in Firefox at least, are using 1024-bit *or smaller* DHE keys, and/or keys with other problems. * It may be the case that the server is configured with good ECDHE parameters and DHE parameters that aren't as strong as the ECDHE parameters. In fact, most servers that support both ECDHE and DHE key exchange seem to be configured like this: P-256 for ECDHE, and 1024-bit keys for DHE. (Note that the key size may not be the only issue with the DHE parameters, and that the possible problems with DH parameters other than key size are difficult and/or very expensive to check.) An attacker can modify the ClientHello to trick such a server into choosing its weak DHE parameters instead of its strong ECDHE parameters. * The Negotiated FF-DHE draft mechanism is specified in such a way that the server's signature on DHParams does not cover the client or server FF-DHE extensions, because the definition of DHParams was not modified to cover them. This is unfortunate, because it means that these parameters, and thus the entire DHE exchange, cannot be fully validated until the peer's Finished message is validated. In particular, this means that the FF-DHE mechanism, as currently designed, is not useful for enhancing the security of False Start handshakes that use DHE key exchange. * Firefox and Chrome (IIUC) are both removing support for DHE_DSS key exchange, due to non-use by servers and/or too-small key DSS key sizes (almost always 1024 bits). Obviously, there are other implementations to consider, but I think the reasoning behind the Firefox and Chrome decisions likely applies to most/all other implementations that would do False Start. Because of the above issues, the False Start draft should be changed to remove DHE_RSA and DHE_DSS from the list of recommended key exchange algorithms, leaving only ECDHE_RSA and ECDHE_ECDSA in the list. Cheers, Brian From nobody Wed Dec 10 02:33:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB011A1A25 for ; Wed, 10 Dec 2014 02:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 eCnRK2o-M8Fy for ; Wed, 10 Dec 2014 02:33:07 -0800 (PST) Received: from vsp3.ballou.se (vsp3.ballou.se [91.189.40.101]) by ietfa.amsl.com (Postfix) with SMTP id DBE981A1A1E for ; Wed, 10 Dec 2014 02:33:06 -0800 (PST) X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp3.ballou.se (Halon Mail Gateway) with ESMTP for ; Wed, 10 Dec 2014 11:33:03 +0100 (CET) Received: from [192.168.0.195] (c-21cfe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.207.33]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 113781DEB7 for ; Wed, 10 Dec 2014 11:33:03 +0100 (CET) Message-ID: <5488214D.8020504@streamsec.se> Date: Wed, 10 Dec 2014 11:32:45 +0100 From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "TLS@ietf.org (tls@ietf.org)" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lOr9Xf15uQPjDTwkXkAv38VWhJU Subject: [TLS] Trusted CA Keys X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 10:33:09 -0000 Is anyone using the trusted_ca_keys(3) extension for any kind of public services? The security considerations seem a bit discouraging, and almost invites usage of the extension for putting confidential proprietary identifiers in the cert_sha1_hash field. From nobody Wed Dec 10 12:27:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234511A9080 for ; Wed, 10 Dec 2014 12:27:38 -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 UX14yodIzJaE for ; Wed, 10 Dec 2014 12:27:35 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 863D21A90AE for ; Wed, 10 Dec 2014 12:27:30 -0800 (PST) Received: from [10.70.10.53] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D8044F984; Wed, 10 Dec 2014 15:27:27 -0500 (EST) Message-ID: <5488ACB1.6090201@fifthhorseman.net> Date: Wed, 10 Dec 2014 15:27:29 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Icedove/34.0 MIME-Version: 1.0 To: Brian Smith , "" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Vq5q2hGlukGga8khD6Q2L8M76VSnrLeAg" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qL7nLkLpG__qHHjVklN5UZ7h7vY Subject: Re: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 20:27:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vq5q2hGlukGga8khD6Q2L8M76VSnrLeAg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/10/2014 01:33 AM, Brian Smith wrote: > * The Negotiated FF-DHE draft mechanism is specified in such a way > that the server's signature on DHParams does not cover the client or > server FF-DHE extensions, There are no FFDHE-specific extensions in the draft, just a reuse of NamedCurves on the client side to specify FFDHE groups. > because the definition of DHParams was not > modified to cover them. This is unfortunate, because it means that > these parameters, and thus the entire DHE exchange, cannot be fully > validated until the peer's Finished message is validated. If there is a change in the way that you think the signature should be processed in draft-ietf-tls-negotiated-ff-dhe, please suggest a concrete change. I considered making a new Handshake message that differed from ServerKeyExchange (but performed the same function) as the server's response when selecting an offered FFDHE named group. I found it difficult to draft it in such a way that the mechanism would be straightforward for implementers to add, but it's possible that (a) i missed some obvious way to differentiate between a signed DHParams object and one of these new objects, or (b) i was being too conservative about what implementers would find acceptable. (btw, if TLS was already following the excellent suggestion for always using a string-prefix for signing anything, then distinguishing between types of signed dh params would be a much easier call) > In particular, this means that the FF-DHE mechanism, as currently > designed, is not useful for enhancing the security of False Start > handshakes that use DHE key exchange. I'm not sure i reach the same conclusion. consider it from both sides: * abbreviated handshake, server sends first i fail to see the risk here -- in the abbreviated handshake, the client has identified itself by a TLS session ID or ticket, and is resuming the existing session, so no key exchange is necessary. use of an FFDHE ciphersuite (or not) isn't relevant to this case. * full handshake, client sends first In this situation, the client sent the server a list of preferred FFDHE groups. the server either responded with one of them, or did not respond with one of them. If the server responded with one of them, and it was signed by the server's validated public key, why should this preclude the use of FalseStart by the client? The server replied with a value from an acceptable group, and the message (including client and server randoms for freshness) was signed by the server. Why should a client refuse to send traffic early in this case? Perhaps the false start draft should say that a client shouldn't do false start for a server that offers FFDHE but does not send an acceptable named group. --dkg --Vq5q2hGlukGga8khD6Q2L8M76VSnrLeAg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUiKyxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpchksP/3EfaVHbNg4FX4e0kiMf+4BE pC50iw4SIUNaC5xnRMP8WJSYULgE3T9yFFLWeBqIKIZeGs2NeVzVGR8ZJerE9KQL RjA07//dg/iZOO2bN+Y3WBG5TlRl+CfT7VoCxbxwwkZNPuzxNM5dusrdHlC8AC04 cafmqStSHwJE/Tkf0rHOqz3lqhkXXAwq9qulbdrrRkJsws3Okxm8il0eeLyVmr1V KJytco5PJaCnk6604VrEpqgMl07qhS7j63fJstx/qyskw5P5fUEjdoRA7rah1o/A kuTAo1kWU2xblx3Ax/6+V+LRkZPn8bGu2cjmwYEiHc4AHK0+Q5sKJANK90RxX6MI 7Eh95LmWlDPjohOXiQjwQ0QWnfAqc80C8Ylz0MzaI+cQa1ZqwblJ2yxu7uM8AjZu dN2dLK4kggdWeSwpgibJkIJSO55zQ7l2qzWM2qGAZw58qrEJoucWnvTIAM3X6lAz iRapmqMhawRiBBD1taFjjUlgoA4qyg2dT0wKNFDuxWMc67aEff8vi6XW8kGgv1MU dxq2HLSEh8Cprwaq4OHX4Qke583tOfHZwOv60I2ai/j8Gd1ZAsLcs6aamlLXV56H LNLFjIPmtvLXJ0pRM+8ep8CGsovsx3AAFY/Dw2dWcN6on1NbzrAAOrcqbirLsI3o 0NaZmDMZG+drtA9oSWVA =N7rU -----END PGP SIGNATURE----- --Vq5q2hGlukGga8khD6Q2L8M76VSnrLeAg-- From nobody Fri Dec 12 04:12:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448D41A1EEA for ; Fri, 12 Dec 2014 04:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 TfDOfRXQ3JG9 for ; Fri, 12 Dec 2014 04:12:03 -0800 (PST) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23DC1A1A1E for ; Fri, 12 Dec 2014 04:12:03 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id sBCCBhKR027132; Fri, 12 Dec 2014 07:11:44 -0500 Date: Fri, 12 Dec 2014 07:11:43 -0500 (EST) From: Nikos Mavrogiannopoulos To: Peter Gutmann Message-ID: <1081655876.9710742.1418386303811.JavaMail.zimbra@redhat.com> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF329DE@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAF329DE@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: rfc7366: status Thread-Index: AdARyy2xBUfdikGMR7uNIL1XUxOQjCM4ltLV Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4WZCWaO4NA6Y4yzEtHWkGgmmjYs Cc: tls Subject: Re: [TLS] rfc7366: status X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 12:12:05 -0000 ----- Original Message ----- > I'd sent the following as a private message to some of the people involved in > the discussion, I haven't had any feedback yet so I guess it's OK? In that > case I'll submit it as an update... I wouldn't use "length of" as it isn't used in other TLS-related documents, but rather define it as you did for the content, but other than that it looks ok to me. regards, Nikos From nobody Fri Dec 12 13:56:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD22F1ACFB8 for ; Fri, 12 Dec 2014 13:56:47 -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 s9usPa-GZdfP for ; Fri, 12 Dec 2014 13:56:46 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8931A8F46 for ; Fri, 12 Dec 2014 13:56:46 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id r20so5745453wiv.0 for ; Fri, 12 Dec 2014 13:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=49Y1T/3hDtIM1nqKJCsGFVyNp/60YbtoXJPTLRnyVyA=; b=I+khoXCl4jq0YrtB7Bq9H3pf1mt7+hsP8fEFx8hFZX7HrzbmEpi3kw8994KoDEU2Qs aMRECcdwyOfcYzCzE+pRqEH/rAM4db+rH/R6Rk6ymTCeLJWoG8gkGS/TxZh2QRo+aYCC JBalFvMkIyblL5sJcP2D08nyXMRMaIntV4T8F++58BGy9qhzmEE7ID1JrMHKNnjFyNEL jt3Ewx5tdh65Q4C9Qmfri3VJaaO2qjXpmU8wHrPl7s4yp6DS66F9+NXTywnBE9jvAd5Y so1iunE3NzkIJm+aXFPAlh52+me6r8t3BR3S4NMrzKgOCJiGPc9OkdBxk1LMZp90QtQ1 FKkw== X-Received: by 10.194.92.82 with SMTP id ck18mr30802387wjb.103.1418421405039; Fri, 12 Dec 2014 13:56:45 -0800 (PST) Received: from [192.168.1.103] (IGLD-84-228-36-153.inter.net.il. [84.228.36.153]) by mx.google.com with ESMTPSA id p1sm3349780wjy.22.2014.12.12.13.56.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 13:56:44 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_FA202350-DA51-42E6-9D39-5EBE572C9AE5" Message-Id: <9A379F5B-4DCE-4565-984E-20E4EBA116C4@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Date: Fri, 12 Dec 2014 23:56:42 +0200 References: To: "TLS@ietf.org (tls@ietf.org)" In-Reply-To: X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HjMM4Vm5sLvivTg9gSys7CFxojM Subject: Re: [TLS] RFC4492bis - merging errata X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 21:56:48 -0000 --Apple-Mail=_FA202350-DA51-42E6-9D39-5EBE572C9AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 8, 2014, at 4:31 PM, Yoav Nir wrote: >=20 > Hi folks >=20 > I=E2=80=99ve created PR #1 for merging the errata([1]) for RFC 4492 = ([2]). >=20 > Let me know if this is controversial >=20 > https://github.com/tlswg/rfc4492bis/pull/1 = >=20 Guess it wasn=E2=80=99t. Merged. Yoav --Apple-Mail=_FA202350-DA51-42E6-9D39-5EBE572C9AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 8, 2014, at 4:31 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

Hi folks

I=E2=80=99ve created PR = #1 for merging the errata([1]) for RFC 4492 ([2]).

Let me know if this is = controversial

https://github.com/tlswg/rfc4492bis/pull/1


Guess it wasn=E2=80=99t.

Merged.

Yoav


= --Apple-Mail=_FA202350-DA51-42E6-9D39-5EBE572C9AE5-- From nobody Mon Dec 15 05:26:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1B21A1BE7 for ; Mon, 15 Dec 2014 05:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 heIxvUAAhK7J for ; Mon, 15 Dec 2014 05:26:15 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.44.28]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC801A1F70 for ; Mon, 15 Dec 2014 05:26:01 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id ABAE6339E0962; Mon, 15 Dec 2014 07:26:00 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 95FDA339E08F8 for ; Mon, 15 Dec 2014 07:26:00 -0600 (CST) Received: from [96.231.218.201] (port=64767 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0Vey-00049Y-0T for tls@ietf.org; Mon, 15 Dec 2014 07:26:00 -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: Date: Mon, 15 Dec 2014 08:25:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9C9D034A-0336-409D-B878-995CB0C07A85@ieca.com> References: 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.218.201 X-Exim-ID: 1Y0Vey-00049Y-0T X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.218.201]:64767 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JDKqTgofod3IW7ZwsNSZyB640tY Subject: Re: [TLS] [tls13-spec] Pre submit cleanup (#84) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 13:26:16 -0000 On Oct 27, 2014, at 12:51, Rich Salz wrote: > Should remove Dierks.=20 >=20 > =97 > Reply to this email directly or view it on GitHub. >=20 Rich suggested that Tim=92s name be removed from the front of the draft = and have Tim be appropriately acknowledge for work on earlier version of = the protocol later in the draft. I asked whether there were any = objections at the Hawaii interim to doing this and there were none. Joe = and I think it=92s time this change be made so EKR - you should feel = free to make these changes when you get a chance, or somebody can submit = a PR. spt= From nobody Mon Dec 15 06:16:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5121A1B06; Mon, 15 Dec 2014 06:16:29 -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 FI58Tlr-3DpZ; Mon, 15 Dec 2014 06:16:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 350E21A1B1D; Mon, 15 Dec 2014 06:16:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215141627.11153.69398.idtracker@ietfa.amsl.com> Date: Mon, 15 Dec 2014 06:16:27 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hQf4F8ApGUGOzaOWdP6R94oI0e0 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 14:16:29 -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-03.txt Pages : 8 Date : 2014-12-15 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 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-downgrade-scsv-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 15 13:41:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9744A1A0074 for ; Mon, 15 Dec 2014 13:41:20 -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 gcepE7EtY-4N for ; Mon, 15 Dec 2014 13:41:18 -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 6B2BF1A0072 for ; Mon, 15 Dec 2014 13:41:18 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 8B8BA3A254 for ; Mon, 15 Dec 2014 22:41:16 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 25D2644E55 for ; Mon, 15 Dec 2014 22:41:16 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 159171B085; Mon, 15 Dec 2014 22:41:16 +0100 (CET) In-Reply-To: <20141215141627.11153.69398.idtracker@ietfa.amsl.com> To: tls@ietf.org Date: Mon, 15 Dec 2014 22:41:16 +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: <20141215214116.159171B085@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yXeGKuhBeyMOnhm3fm0E79Si0LQ Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt 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: Mon, 15 Dec 2014 21:41:20 -0000 internet-drafts@ietf.org wrote: > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03 The current document seems still silent on the *KNOWN* problem when a client App has been skipping TLS versions on downgrade dance. Andrei had written about the problem here: http://www.ietf.org/mail-archive/web/tls/current/msg13725.html but his suggestion: client app must NOT use FALLBACK SCSV when skipping versions does not look like a viable solution (it removes all protection). MSIE 8 seems to be a browser that skips versions on downgrade dance. MSIE 8 on Win7 with TLSv1.2 enabled, dances like this: TLSv1.2 (+Ext) -> TLSv1.0 (+Ext) -> SSLv3 (no Ext) The scenario where this problem can hit is with non-malicious middleboxes that do not recognize (and therefore do not permit) TLSv1.2 handshakes. I had described such a potential scenario at the end of this message: http://www.ietf.org/mail-archive/web/tls/current/msg14618.html And the problem can easily reappear with TLSv1.3. I would not be surprised to see TLSv1.2 servers implementing this abort TLS handshakes when they receive a ClientHello with client_version={3,1} that contains the TLS_FALLBACK_SCSV -Martin From nobody Mon Dec 15 13:46:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ACE1A0077 for ; Mon, 15 Dec 2014 13:46:51 -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 eBn8Z3aJamyW for ; Mon, 15 Dec 2014 13:46:48 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C255A1A0079 for ; Mon, 15 Dec 2014 13:46:48 -0800 (PST) Received: from [10.70.10.53] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3651DF986 for ; Mon, 15 Dec 2014 16:46:46 -0500 (EST) Message-ID: <548F56C8.70104@fifthhorseman.net> Date: Mon, 15 Dec 2014 16:46:48 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Icedove/34.0 MIME-Version: 1.0 To: tls@ietf.org References: <20141215214116.159171B085@ld9781.wdf.sap.corp> In-Reply-To: <20141215214116.159171B085@ld9781.wdf.sap.corp> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mMw6Od0clQcb9kE3Qw7QGCR2wiUDhS7KX" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VXJU-c0FjzL4UG5A1tL5IsD1XjQ Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 21:46:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mMw6Od0clQcb9kE3Qw7QGCR2wiUDhS7KX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/15/2014 04:41 PM, mrex@sap.com (Martin Rex) wrote: > The scenario where this problem can hit is with non-malicious > middleboxes that do not recognize (and therefore do not permit) > TLSv1.2 handshakes. How do we distinguish between these non-malicious middleboxes that do not permit TLSv1.2 because they don't recognize it and malicious middleboxes that want to force modern peers into a downgrade by not permitting TLSv1.2? Do the non-malicious middleboxes use RFC 3514? --dkg --mMw6Od0clQcb9kE3Qw7QGCR2wiUDhS7KX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUj1bIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEKUkAbEb/fpcvKgP/iueUrOxJndNX2diiF41Ni5I xKqiQ8rWi7kSDO0+YkLIwZ/T7hEvYZbCCyv45VhNtDrJj4GWQKWsidFKl7y4Ut1K y9GsJLAWcHZfjH1LcYCK5PqUeE14YfaaBj6EJMKaXCYfj/Lmm0N+gBjgvcnu1Aqc ZCraQkURZHK/lgTfVceY4tjORhFxXJ1j4UdRCFqna4deavWLQ96QsnWHDyvGKSdU r0zddo+zHJRBwLqarZrgjjd65Lzg105O9HhyEUyDl/OiTrb7otuE0aXQGCYsL18J Vxka7ncAPp77bNlmFPUAaaQ04ISE9glsOAOtDt3afxOZIT1IUyaQeurJq/yDSgEY SE/Ozh3eL6eMzaOw26Vmh2m30ql3pAOzIrtn6xbkM8WboVOwp9jArIonuy5mepjl J67zdUxaShMBGyzVXeDy4FWeq3zHrQClo2nsyNHNyGLWSis1P1KDg4gw5LWWENjk wG7UX+jlZUBy+yv/WjSSv8fRm7Kp+8bM1XYKYC7bi0Sm2zjOaiSbzxAuZ4cxGvdy OG0TYsMwgblzukjJyM5W1CmLbQ1TjXuvUpyiy9clCiDiQqTDgZI3LS+xpbr3wjbI wk7EcUQTCd5ddInAF7C6vvvz0RocwzmfUCKqbxtbRTEx1gegmIoeTMp8nvNTAmnP KTfE35f44TUQAj3YnHxh =AWaB -----END PGP SIGNATURE----- --mMw6Od0clQcb9kE3Qw7QGCR2wiUDhS7KX-- From nobody Mon Dec 15 14:29:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4CD1A0089 for ; Mon, 15 Dec 2014 14:29:14 -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 UROfY-hxwHe5 for ; Mon, 15 Dec 2014 14:29:13 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494341A0070 for ; Mon, 15 Dec 2014 14:29:13 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so11968125wib.1 for ; Mon, 15 Dec 2014 14:29:12 -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=zTvzuEjihE6rcB6aVcMeUIY3FEkP1czngXtGUA69uq0=; b=ExyNsfvvRjSKpT7Fa0NZxSMcDumJpVMbb6SOHZ5vSWOoaEeM3zYMW0XCGiKG1F5wmQ Jsc675WF9DPPl+rj7jwX88NXQkeBZcPkgVThE9p8ohveAyLi0wiGfgM7EkP4hT+eOLto fTkjNtYczY2HtftWr9TVDfpjMcOrYv4S17UcCOTW2XwO6vHyEThcYY3CBP9YsasiXVpk nve7u5nhYNDAuXjj5Lr+TK17Lr0qkhVOVEh3IEMyk1S05ZVojQ4f7Eb6dnVdVdk+U+Fr MvqDsZKlRB+3gda6wk4mMfg8TpbXzZaz6UZ+zNiT8Klctbd8oXsYx61GkfRyohQmx11i bMuw== X-Received: by 10.194.157.4 with SMTP id wi4mr41075526wjb.54.1418682552030; Mon, 15 Dec 2014 14:29:12 -0800 (PST) Received: from [192.168.1.102] (IGLD-84-228-226-50.inter.net.il. [84.228.226.50]) by mx.google.com with ESMTPSA id n8sm14632207wjx.0.2014.12.15.14.29.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 14:29:11 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_C8344C6E-070A-4D21-9DAD-CEB2CCAEAEC4" Message-Id: <274716D0-EC91-4131-A8F7-CD13A9B42CE7@gmail.com> Date: Tue, 16 Dec 2014 00:29:09 +0200 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Kyw27vJKBxAzq6-mPi032jv6IT8 Subject: [TLS] RFC4492bis - Removing ECDH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:29:15 -0000 --Apple-Mail=_C8344C6E-070A-4D21-9DAD-CEB2CCAEAEC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. I=E2=80=99ve created pulll request #2 for removing references to ECDH = (static elliptic curve key) key exchange and ciphersuites. https://github.com/tlswg/rfc4492bis/pull/2 = Nikos suggested it here: = http://www.ietf.org/mail-archive/web/tls/current/msg14555.html = Yes, there are other suggestions there, but I=E2=80=99d like to take = them one by one. Let me know what you think Yoav --Apple-Mail=_C8344C6E-070A-4D21-9DAD-CEB2CCAEAEC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

I=E2=80= =99ve created pulll request #2 for removing references to ECDH (static = elliptic curve key) key exchange and ciphersuites.

https://github.com/tlswg/rfc4492bis/pull/2

Nikos suggested it = here: http://www.ietf.org/mail-archive/web/tls/current/msg14555.html<= /a>
Yes, there are other suggestions there, but = I=E2=80=99d like to take them one by one.

Let me know what you think

Yoav

= --Apple-Mail=_C8344C6E-070A-4D21-9DAD-CEB2CCAEAEC4-- From nobody Mon Dec 15 16:42:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0355A1A6FEC for ; Mon, 15 Dec 2014 16:42:43 -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, LOTS_OF_MONEY=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 xEx5vDF8Rm_j for ; Mon, 15 Dec 2014 16:42:41 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FDAF1A01A9 for ; Mon, 15 Dec 2014 16:42:41 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so12107360ier.28 for ; Mon, 15 Dec 2014 16:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TyU8AQ9llX63+dpkza3XT1N8ktxuotZJwpOHYoRatao=; b=PD7NCaOQT4xl8+3mwulXkdK5W92l3Iy5w+0GGsaNzIz17uEuGXHS1ngbJOMrzHlSo0 YJ/EvD7OCGR4i0NiAhw6nd6pTooVSekBp1l5zacGn+7BWhsIZjb+01OGWR20efahQjxj YQsT+rA+SWhS+YBK+N7EO2ycZm0DHCsyD8lY8qW980xgM/nn5kS7VXDDWUG508iNKxKO iERmBCwpi3JhJzHIAfKuYHc1VncHYjj3A0DwJyKqR28BfZUNC91niIEgQok7PLM8b308 3gb7oTMiSKtWSGuj6SAHoiNZBKH8HUq4JCHUrMpNplhUi0AqcF/ECrcnRiI5nf2evGg5 /vdQ== MIME-Version: 1.0 X-Received: by 10.107.15.73 with SMTP id x70mr31245078ioi.8.1418690560693; Mon, 15 Dec 2014 16:42:40 -0800 (PST) Received: by 10.107.134.170 with HTTP; Mon, 15 Dec 2014 16:42:40 -0800 (PST) In-Reply-To: <548F56C8.70104@fifthhorseman.net> References: <20141215214116.159171B085@ld9781.wdf.sap.corp> <548F56C8.70104@fifthhorseman.net> Date: Mon, 15 Dec 2014 19:42:40 -0500 Message-ID: From: Jeffrey Walton To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/91ZmLPNyPjvqdCCYNPuJW_C7l9M Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 00:42:43 -0000 On Mon, Dec 15, 2014 at 4:46 PM, Daniel Kahn Gillmor wrote: > On 12/15/2014 04:41 PM, mrex@sap.com (Martin Rex) wrote: >> The scenario where this problem can hit is with non-malicious >> middleboxes that do not recognize (and therefore do not permit) >> TLSv1.2 handshakes. > > How do we distinguish between these non-malicious middleboxes that do > not permit TLSv1.2 because they don't recognize it and malicious > middleboxes that want to force modern peers into a downgrade by not > permitting TLSv1.2? > > Do the non-malicious middleboxes use RFC 3514? > That's the million dollar question: how can you tell "good" bad guys from the "bad" bad guys. I think the answer is: you can't. If browsers and other software want to downgrade in an insecure fashion, then they are on their own. Don't placate them in their efforts and weaken the system for everyone else. From nobody Mon Dec 15 16:49:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956801A6ED8 for ; Mon, 15 Dec 2014 16:49: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 bavzhLG8_o00 for ; Mon, 15 Dec 2014 16:48:59 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACCF1A0364 for ; Mon, 15 Dec 2014 16:48:59 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id gq1so20585425obb.9 for ; Mon, 15 Dec 2014 16:48:58 -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=12U/T2blHTq7zEkWan+9B6BIt9Y9zdY5NL9KkkehChw=; b=yekdfBp5yUG3su34mmWDyux2Hq49EuZ6ZRGlgXYM1ZR/SJjd3n8jGGTPy5xDrRoUvf Grd7CRxuUkH40UShyg6QIG0x3Z0K34YD/HY2V4xUqKqCGyYXZLXKdWDKot3g8AY/W+7S CDGcDjcmZQ252mbl6Yi3bfQNXu2kh1l/Xn2Na/YbpzwlBuIY6bK/ACSBXVKgxKD3E1op 1hvq4hxOWpk8/8t9gBikIstmLRqjD8/mJJDTnAu21Sx1u8nYVjuBmYE7Ruu+L0czcsQC uu5cyrNRDLLXjArQPx6Nj1J6v2jEMdm6S+sqTj8eH2O0NlsuNEWhVYEHzVuRwyjeOXkF AXVw== MIME-Version: 1.0 X-Received: by 10.182.16.138 with SMTP id g10mr20656392obd.85.1418690938550; Mon, 15 Dec 2014 16:48:58 -0800 (PST) Received: by 10.202.49.203 with HTTP; Mon, 15 Dec 2014 16:48:58 -0800 (PST) In-Reply-To: References: <20141215214116.159171B085@ld9781.wdf.sap.corp> <548F56C8.70104@fifthhorseman.net> Date: Mon, 15 Dec 2014 16:48:58 -0800 Message-ID: From: Martin Thomson To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TXllcyLx_OsMD0Q5HXsTY-2kqYc Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 00:49:00 -0000 On 15 December 2014 at 16:42, Jeffrey Walton wrote: > If browsers and other software want to downgrade in an insecure > fashion, then they are on their own. Don't placate them in their > efforts and weaken the system for everyone else. That's kinda the point of the draft. Let the server know so it has a choice in the matter. Browsers, as clients, have a choice about what TLS version they are willing to tolerate. With fallback, they signal that they are willing to speak to servers and only opportunistically reach the highest common version. That's weaker than the guarantee that TLS can provide, but it is their choice to do that. You can (and have) noted that this has drawbacks and maybe jump up and down in the hopes that this will change something. But it's not like the choice is made in a vacuum. Personally, I'm more concerned about the use of CBC modes than I am about version downgrades in the current environment. From nobody Mon Dec 15 21:45:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE481A038E for ; Mon, 15 Dec 2014 21:45:24 -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 d3MRZ9HC7GkE for ; Mon, 15 Dec 2014 21:45:23 -0800 (PST) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EF21A037A for ; Mon, 15 Dec 2014 21:45:22 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id g201so271368oib.26 for ; Mon, 15 Dec 2014 21:45:22 -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=rrniMZIVRu7HUMWf+9FCYe0nTCwH/abw5jHFimyuGLQ=; b=W3zMqqAEoarCQwTG3rKOh2pjgaxu7hhfLHCelJRcUfKfPsIgFkqUt+OQ9Hl5oVEccz iyCAj2HLQyAxGJYdcm+3OIU+Ez296dOOYQgDbYogdR8u1DuPS4yLmZyjCUUAXBTOkktw htBrO35iziBuSsM38tUkSp6D+hsJovY1xlYUoHEy8CPIuW3yoPV5xIb5o3WDpMj90m37 AkPJon5qRh1Q3xEnjyIpdbUuhspybfKLQEmwVo4jJ4z6+TrF1GpBpTLvCA1aVraJxepn jteZRrZf4/2jNCT0rNed5n4FUzv4QB6WLXUrlR2/HGlHw2H5PU/RFTOMkZ8Ubdn5A35W dN0w== X-Gm-Message-State: ALoCoQmBC7EqjICIXT3lmTPKI+p0qQMl/LyI3k2ty276RRiTr6SmrleS9i+H0W/hefkBYT3fE/So MIME-Version: 1.0 X-Received: by 10.202.177.65 with SMTP id a62mr20644716oif.92.1418708713781; Mon, 15 Dec 2014 21:45:13 -0800 (PST) Received: by 10.76.19.144 with HTTP; Mon, 15 Dec 2014 21:45:13 -0800 (PST) In-Reply-To: <5488ACB1.6090201@fifthhorseman.net> References: <5488ACB1.6090201@fifthhorseman.net> Date: Mon, 15 Dec 2014 21:45:13 -0800 Message-ID: From: Brian Smith To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EoPsfb6O0oDTdZBziDBxhmUN7KU Cc: "" Subject: Re: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 05:45:24 -0000 On Wed, Dec 10, 2014 at 12:27 PM, Daniel Kahn Gillmor wrote: > On 12/10/2014 01:33 AM, Brian Smith wrote: >> * The Negotiated FF-DHE draft mechanism is specified in such a way >> that the server's signature on DHParams does not cover the client or >> server FF-DHE extensions, > > There are no FFDHE-specific extensions in the draft, just a reuse of > NamedCurves on the client side to specify FFDHE groups. Understood. Sorry for being lazy with the terminology there. >> because the definition of DHParams was not >> modified to cover them. This is unfortunate, because it means that >> these parameters, and thus the entire DHE exchange, cannot be fully >> validated until the peer's Finished message is validated. > > If there is a change in the way that you think the signature should be > processed in draft-ietf-tls-negotiated-ff-dhe, please suggest a concrete > change. I do not think a change to draft-ietf-tls-negotiated-ff-dhe is needed. >> In particular, this means that the FF-DHE mechanism, as currently >> designed, is not useful for enhancing the security of False Start >> handshakes that use DHE key exchange. > > I'm not sure i reach the same conclusion. consider it from both sides: > > * full handshake, client sends first > > In this situation, the client sent the server a list of preferred > FFDHE groups. the server either responded with one of them, or did not > respond with one of them. If the server responded with one of them, and > it was signed by the server's validated public key, why should this > preclude the use of FalseStart by the client? The server replied with a > value from an acceptable group, and the message (including client and > server randoms for freshness) was signed by the server. Why should a > client refuse to send traffic early in this case? The MitM may have tampered with or removed the FFDHE groups from the extension in the ClientHello, misleading the server into thinking the client's capabilities are weaker than they actually are, and thus causing the server to choose weaker DHE parameters. The tampering will be detected by the server when it validates the Client's Finished message, but by that time the client will have already sent data encrypted with keys derived from the weak DHE key material. > Perhaps the false start draft should say that a client shouldn't do > false start for a server that offers FFDHE but does not send an > acceptable named group. I agree that the client could maintain a whitelist of false-start-acceptable FFDHE groups, which should be a subset of the FFDHE groups listed in its supported curves extension. However, wording to that effect, and wording about how to compare the strength of ECDHE groups to FFDHE groups, should be included in the draft if FFDHE support is going to continue to be recommended. IMO, FFDHE is basically obsolete now, so it isn't worth the effort to do this. However, I understand that others might disagree. Cheers, Brian From SRS0=hhoj=BE=acm.org=bmoeller@srs.kundenserver.de Tue Dec 16 00:57:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2A21ACD42 for ; Tue, 16 Dec 2014 00:57:45 -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 0Mrmgbwv5WeC for ; Tue, 16 Dec 2014 00:57:43 -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 599F51A6FC0 for ; Tue, 16 Dec 2014 00:57:43 -0800 (PST) Received: from mail-ob0-f181.google.com ([209.85.214.181]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0MXYso-1YTpZK39QU-00WZad for ; Tue, 16 Dec 2014 09:57:41 +0100 Received: by mail-ob0-f181.google.com with SMTP id gq1so21982554obb.12 for ; Tue, 16 Dec 2014 00:57:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.88.132 with SMTP id m126mr20270983oib.57.1418720259370; Tue, 16 Dec 2014 00:57:39 -0800 (PST) Received: by 10.60.32.42 with HTTP; Tue, 16 Dec 2014 00:57:39 -0800 (PST) In-Reply-To: <20141215214116.159171B085@ld9781.wdf.sap.corp> References: <20141215141627.11153.69398.idtracker@ietfa.amsl.com> <20141215214116.159171B085@ld9781.wdf.sap.corp> Date: Tue, 16 Dec 2014 09:57:39 +0100 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113d550c1878d1050a518db7 X-Provags-ID: V03:K0:rrvCihGgDjiwQxB35ZJ1EQ3/jG5aXrwlhsh+HxR2klaxtuzOzwO XI+8P3yRXrGul1l1S0r4BPiFinVw2OuCWPwF/mIplzpUi9zhHyiEjBopXouxKuILUQe9uHt dwQH2KNxKvCsaKvsYfaG+2nWwLT9rpQB7mxSpbQHYyJmNCLNjpSfJM2qo/Xf5HzS/pgVrU6 7G+05YDm+tGNMCbW0Z20Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q1OtlvFhpOSdfeiDDpViJn6xYyE Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 08:58:32 -0000 --001a113d550c1878d1050a518db7 Content-Type: text/plain; charset=UTF-8 Martin Rex : > http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03 > The current document seems still silent on the *KNOWN* problem when > a client App has been skipping TLS versions on downgrade dance. > > MSIE 8 seems to be a browser that skips versions on downgrade dance. > MSIE 8 on Win7 with TLSv1.2 enabled, dances like this: > > TLSv1.2 (+Ext) -> TLSv1.0 (+Ext) -> SSLv3 (no Ext) > To recap what's been previously said, I don't think that a change to the I-D is warranted. - The (obvious) way to make this work is to not skip versions in the downgrade dance. Often the downgrade will be happening because of a flaky network, not because it is required with a specific server (or induced by an active attacker): in that case, if the server does not recognize TLS_FALLBACK_SCSV, it is more appropriate and generally better for security to fall back to TLS 1.1 rather than to TLS 1.0. - I do realize that some implementors may prioritize latency improvements over the security gain here and hence may still prefer to skip TLS 1.1. I won't encourage that behavior, but draft-ietf-tls-downgrade-scsv-03 doesn't disallow it. In practice, the above sequence (after TLS 1.2, attempt TLS 1.0 with TLS_FALLBACK_SCSV) should generally work well enough because support for TLS_FALLBACK_SCSV in servers with a maximum protocol version of TLS 1.1 will probably remain rare. To maximize interoperability, such clients should attempt TLS 1.1 with TLS_FALLBACK_SCSV later in the downgrade sequence (i.e., after TLS 1.0 with TLS_FALLBACK_SCSV). Bodo --001a113d550c1878d1050a518db7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:

> http://tools.ietf.org/html/draft-ietf-tls-downgrade-scs= v-03
=C2=A0
The current d= ocument seems still silent on the *KNOWN* problem when
a client App has been skipping TLS versions on downgrade dance.
=C2=A0
MSIE 8 seems to be a browser that skips versions on downgrade dance.
MSIE 8 on Win7 with TLSv1.2 enabled, dances like this:

=C2=A0 =C2=A0TLSv1.2 (+Ext) -> TLSv1.0 (+Ext) -> SSLv3 (no Ext)

To recap what's been previously said, I = don't think that a change to the I-D is warranted.

=
- The (obvious) way to make this work is to not skip versions in the d= owngrade dance. Often the downgrade will be happening because of a flaky ne= twork, not because it is required with a specific server (or induced by an = active attacker): in that case, if the server does not recognize TLS_FALLBA= CK_SCSV, it is more appropriate and generally better for security to fall b= ack to TLS 1.1 rather than to TLS 1.0.

- I do real= ize that some implementors may prioritize latency improvements over the sec= urity gain here and hence may still prefer to skip TLS 1.1. I won't enc= ourage that behavior, but draft-ietf-tls-downgrade-scsv-03 doesn't disa= llow it. In practice, the above sequence (after TLS 1.2, attempt TLS 1.0 wi= th TLS_FALLBACK_SCSV) should generally work well enough because support for= TLS_FALLBACK_SCSV in servers with a maximum protocol version of TLS 1.1 wi= ll probably remain rare. To maximize interoperability, such clients should = attempt TLS 1.1 with TLS_FALLBACK_SCSV later in the downgrade sequence (i.e= ., after TLS 1.0 with TLS_FALLBACK_SCSV).

Bodo

--001a113d550c1878d1050a518db7-- From nobody Tue Dec 16 01:58:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734071A1A6F for ; Tue, 16 Dec 2014 01:58:09 -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 YUf4XH52yGjb for ; Tue, 16 Dec 2014 01:58:08 -0800 (PST) Received: from BLU004-OMC3S17.hotmail.com (blu004-omc3s17.hotmail.com [65.55.116.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF941A1A6E for ; Tue, 16 Dec 2014 01:58:08 -0800 (PST) Received: from BLU177-W34 ([65.55.116.74]) by BLU004-OMC3S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 16 Dec 2014 01:58:06 -0800 X-TMN: [jai7K6gRJI8A1wB0ady8pbD0B57p/D8I] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Bodo Moeller , "tls@ietf.org" Date: Tue, 16 Dec 2014 01:58:06 -0800 Importance: Normal In-Reply-To: References: <20141215141627.11153.69398.idtracker@ietfa.amsl.com>, <20141215214116.159171B085@ld9781.wdf.sap.corp>, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Dec 2014 09:58:06.0756 (UTC) FILETIME=[CA49E640:01D01916] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QBdoJukdflij4XMeeeT_Vhcyb8g Subject: Re: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 09:58:09 -0000 > Martin Rex >: =0A= > =0A= > > http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03 =0A= > =0A= > The current document seems still silent on the *KNOWN* problem when =0A= > a client App has been skipping TLS versions on downgrade dance. =0A= > =0A= > MSIE 8 seems to be a browser that skips versions on downgrade dance. =0A= > MSIE 8 on Win7 with TLSv1.2 enabled=2C dances like this: =0A= > =0A= > TLSv1.2 (+Ext) -> TLSv1.0 (+Ext) -> SSLv3 (no Ext) =0A= > =0A= > To recap what's been previously said=2C I don't think that a change to = =0A= > the I-D is warranted. =0A= > =0A= > - The (obvious) way to make this work is to not skip versions in the =0A= > downgrade dance. Often the downgrade will be happening because of a =0A= > flaky network=2C not because it is required with a specific server (or = =0A= > induced by an active attacker): in that case=2C if the server does not = =0A= > recognize TLS_FALLBACK_SCSV=2C it is more appropriate and generally =0A= > better for security to fall back to TLS 1.1 rather than to TLS 1.0. =0A= > =0A= > - I do realize that some implementors may prioritize latency =0A= > improvements over the security gain here and hence may still prefer to = =0A= > skip TLS 1.1. I won't encourage that behavior=2C but =0A= > draft-ietf-tls-downgrade-scsv-03 doesn't disallow it. In practice=2C the = =0A= > above sequence (after TLS 1.2=2C attempt TLS 1.0 with TLS_FALLBACK_SCSV) = =0A= > should generally work well enough because support for TLS_FALLBACK_SCSV = =0A= > in servers with a maximum protocol version of TLS 1.1 will probably =0A= > remain rare. To maximize interoperability=2C such clients should attempt = =0A= > TLS 1.1 with TLS_FALLBACK_SCSV later in the downgrade sequence (i.e.=2C = =0A= > after TLS 1.0 with TLS_FALLBACK_SCSV). =0A= > =0A= > Bodo =0A= =0A= I also noticed that IE11 and later excludes RC4 cipher suites from first ha= ndshake but adds them back when doing the TLS 1.0 fallback=2C and while the= re are servers that would be broken by doing it with TLS_FALLBACK_SCSV=2C I= argue that discouraging the use of RC4 cipher suites with TLS 1.2 is a goo= d thing.=0A= =0A= Yuhong Bao=0A= = From nobody Fri Dec 19 09:11:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB641A8A7C for ; Fri, 19 Dec 2014 09:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 8ST9NjwAZn0S for ; Fri, 19 Dec 2014 09:10:51 -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 E51891A8A6C for ; Fri, 19 Dec 2014 09:10:50 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id E25833AB2A; Fri, 19 Dec 2014 18:10:48 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 8DA8442B84; Fri, 19 Dec 2014 18:10:48 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 83D341B097; Fri, 19 Dec 2014 18:10:48 +0100 (CET) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9F9C96@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann Date: Fri, 19 Dec 2014 18:10:48 +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: <20141219171048.83D341B097@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DyTYvslM7kqPtpLTKC3Xi26Yud4 Cc: tls@ietf.org Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 17:10:59 -0000 Peter Gutmann wrote: > Stephen Checkoway writes: > > >That seems wrong. In practice, a client connects and says I'm willing to > >communicate using protocol parameters X, Y, and Z. If the server can't > >accommodate the client, it closes the connection. How is the signature > >algorithm any different from the cipher suite in this respect? > > TLS conflates the algorithms used with TLS with the algorithms used for > certificates. As others have pointed out, a server has control over the > algorithms used for TLS, but no control over what's used in certificates. > Those are dictated by the CA. So it's OK for the client to say "I would like > one of the above for TLS", but it has no business saying "I expect your CA, > and every CA above it up to the root, to also use the algorithm(s) I've asked > for". I hadn't previously realized that the TLS WG has _already_ retroactively deprecated the relevant paragraph about the algorithm that was used to sign the server certificate from rfc4492 (rfc5246,Appendix A.7,3rd paragraph) https://tools.ietf.org/html/rfc5246#appendix-A.7 A.7. Changes to RFC 4492 [...] As described in Sections 7.4.2 and 7.4.6, the restrictions on the signature algorithms used to sign certificates are no longer tied to the cipher suite (when used by the server) or the ClientCertificateType (when used by the client). Thus, the restrictions on the algorithm used to sign certificates specified in Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, the restrictions on the keys in the end-entity certificate remain. -Martin From nobody Fri Dec 19 10:17:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B391ACD1F; Fri, 19 Dec 2014 10:17:54 -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 E9hHXBI5-kdV; Fri, 19 Dec 2014 10:17:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 980651ACD15; Fri, 19 Dec 2014 10:17:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219181753.32504.21282.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 10:17:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zzNEI3F4WCqCXoP76oLoRe3WTIw Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-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: Fri, 19 Dec 2014 18:17:55 -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 : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-05.txt Pages : 23 Date : 2014-12-19 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-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 Dec 19 10:19:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D32C1A90CF for ; Fri, 19 Dec 2014 10:19:15 -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 bxw2d39rM46y for ; Fri, 19 Dec 2014 10:19:13 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id EE8B11A8A6B for ; Fri, 19 Dec 2014 10:19:12 -0800 (PST) Received: from [192.168.12.125] (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id D38C0F984; Fri, 19 Dec 2014 13:19:10 -0500 (EST) Message-ID: <54946C20.6000404@fifthhorseman.net> Date: Fri, 19 Dec 2014 13:19:12 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Icedove/34.0 MIME-Version: 1.0 To: Brian Smith References: <5488ACB1.6090201@fifthhorseman.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="M3SsfoFrglKvukN8NNuCAMTj5rCvV2blF" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H_7HXPg6xZ3cY4tkvGIbNHMyaVc Cc: "" Subject: Re: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 18:19:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M3SsfoFrglKvukN8NNuCAMTj5rCvV2blF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/16/2014 12:45 AM, Brian Smith wrote: > The MitM may have tampered with or removed the FFDHE groups from the > extension in the ClientHello, misleading the server into thinking the > client's capabilities are weaker than they actually are, and thus > causing the server to choose weaker DHE parameters. The tampering will > be detected by the server when it validates the Client's Finished > message, but by that time the client will have already sent data > encrypted with keys derived from the weak DHE key material. >=20 >> Perhaps the false start draft should say that a client shouldn't do >> false start for a server that offers FFDHE but does not send an >> acceptable named group. >=20 > I agree that the client could maintain a whitelist of > false-start-acceptable FFDHE groups, which should be a subset of the > FFDHE groups listed in its supported curves extension. However, > wording to that effect, and wording about how to compare the strength > of ECDHE groups to FFDHE groups, should be included in the draft if > FFDHE support is going to continue to be recommended. IMO, FFDHE is > basically obsolete now, so it isn't worth the effort to do this. > However, I understand that others might disagree. I've modified the ffdhe draft (as of -05) to include this guidance. https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-05 --dkg --M3SsfoFrglKvukN8NNuCAMTj5rCvV2blF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUlGwgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpca78P/RIXwE0z65x89CNy+oLy2Iat SrYhTbVKhjlqxamiaockiu7TtdVEK8W8olOuJC7f5rwlqq6rIKhKJqit/mF2ahMz DylR9ueB9A+IF8i4KAICGuaawtCyrv1/sFYde0KUfXJNiFmByigDpUSH6F+WIL9Y yF7mAC1897xXEYMKyZg5KW5qp0PXim0V7vvOZpBeExrmUxfg8EbeX6rJlArJgyiC PlZXClc7gOI+bWpgS9IW51BnnivuXOh0vTKDWG/AqmoqD6kMtccTdLLn6aPlh37x wDki8QnTulezemi/k6oSyabgL/8mv6v0pdpsuIqZjnR2dENLIIhU0O79XR5lukVY gQ2rNOvdPXkfBPD7YWDA2P/pDK7bfefmnPf9phN34ZdzCrYLtWN74WaaDejCrxY7 /lHNRTgO4k/VeUnB0fzvraAsuGxs8ofue4VCHhBch1NtubtOLjCeE1veqxFesQIf fQC1c+edfQ7hpj6vbyXz++qVuueyXwj+vy9BrqY5+/oycWbYDjLPXbEDMylXJodw /KYChkh9TDwj4obMTIskRai76tzgghlTjj2Z5vUTEFlQTq00RMN6TA0R7+kQnVl1 dEHMNdwOqKHP/vor2OXuD7qLFfyqjXUNbIJn+2Xw9uSVeWta/fHA58eGO+jqOjc+ fRIQGPRkvlW9GJ0xu9Zl =S2sx -----END PGP SIGNATURE----- --M3SsfoFrglKvukN8NNuCAMTj5rCvV2blF-- From nobody Sat Dec 20 00:53:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211A51A0430 for ; Sat, 20 Dec 2014 00:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.032 X-Spam-Level: * X-Spam-Status: No, score=1.032 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FROM_12LTRDOM=0.01, 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 SEfTz5xEZtGS for ; Sat, 20 Dec 2014 00:53:05 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 1204C1A0AF7 for ; Sat, 20 Dec 2014 00:53:04 -0800 (PST) Received: from monty.local (cm50.kappa90.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBK9Dv8D019803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 20 Dec 2014 09:14:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419066842; bh=l3dJeSr2AwqtDjL5gvudweG9QClesJV3MwIKzo9ByZw=; h=Date:From:To:Subject:From; b=RRgHUg8nITnTc3S5rJpXfCanRaFnfndQXRb1wPRjd74cyHovtZkyh37DjhfI1434m q7CBh5c33KJP94IjhEc9mADxgmgN3CDnCXAwixaAISlhg110Q7r82qXefWRCEd0O/e dh60hBYib8/78yV2FLb8M2o1c0do0/oIt2mqW0X8= Message-ID: <549538E5.7050109@metaparadigm.com> Date: Sat, 20 Dec 2014 16:52:53 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s50LaZh3gCFGqpyLPocE_qQm6Rk Subject: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 08:53:07 -0000 Hi folks, Please bear with me as I am a new to the list. I have been doing some independent research on TLS AEAD ciphers and decided to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM based on the literature and propose considering the addition of AES-EAX to augment TLS security and mitigate against potential future security attacks on AES-GCM. AES-GCM is currently the only widely implemented TLS AEAD cipher. AEAD is now considered essential. AES-CCM is specified but implementations are not widespread (rfc5116, rfc6655). AES-EAX documents improvements to AES-CCM. In fact the EAX2 framework would allow AAED with other ciphers. I apologize if this has already been raised and dismissed. Here goes my series of bullets. AES-GCM vs AES-EAX/AES-CCM: Performance vs Scale vs Security - AES-GCM GHASH, AES-EAX OMAC1/CMAC and AES-CCM CBC-MAC AEAD auth tags are all 128 bits (except for CCM-8 which is 64 bits) - EAX OMAC1/CMAC (sp800-38b) addresses security issues in CCM CBC-MAC (CBC-MAC is secure only for fixed-length messages) - GCM has weak keys. Choose an irreducible polynomial over a finite field; GF(2ⁿ); where n ≠ 128; preferably prime; observe n = 127; (Saarinen GHASH weak keys) - GCM use a 96 bit IV prefix expanded from the nonce suffixed with a 32 bit counter per AES block (gcm-spec) - EAX/CCM uses full IV expanded from nonce as the initial counter so cycling of IV is 2 ^ (n - 32) less frequent than GCM (sp800-38a) - GCM has a 256GB upper limit on encryption due to incrementing only 32 bits of the IV versus the whole IV in CTR mode (gcm-spec, sp800-38a) - GCM has 32 bits less entropy from the nonce in the IV vs EAX/CCM due to counter construction difference from CTR (sp800-38a) - Posit lower IV entropy combined with GHASH weak keys increases the susceptibility of introducing bit errors and forging an AEAD tag - Cipher based CBC-MAC and OMAC1/CMAC with AES are birthday attack vulnerable at 2 ^ 64 blocks with known texts (MAC birthday paradox) - Posit birthday MITM attack on EAX/CCM cipher based MAC are infeasible due to short nonce lifespan in TLS, assuming secure master secret for the PRF and termination of connections on authentication errors. TLS has different attack characteristics compared to generic MITM attacks on CCM in WPA2, IPSec and 802.11i as TLS is connection oriented and the nonce is derived from an ephemeral shared secret versus a pre shared key. - GCM GHASH based AAED is high performance because GHASH partial products can be parallelised and xor reduced over multiple blocks (parallel ghash partial products) - Posit that parallelizability in AES-GCM is a weakness not a strength. Many GCM ‘features’ exist because GCM was designed to be fast i.e. parallelizable in hardware. Performance also assists those with government level resources. GCM is highly parallelizable, has 32 bits less IV entropy, auth tag is limited to 128 bits and there are 2 ^ 9 multiplicative subgroups of GF(128) (Saarinen GHASH weak keys) While it may not be tractable to break the encryption; it may be tractable to introduce bit errors and forge authentication tags by substitution of 1 or more AES blocks i.e. disrupting integrity. - EAX addresses variable size nonce, alignment, in-place operation, algorithm complexity and streaming issues over CCM at the expensive of a small per message overhead. (eax spec) - EAX has a security proof and is not vulnerable to the attacks on the ANSI EAX’ (EAXPrime) variant; given a securely established nonce. EAXPrime for the sake of optimization removed essential EAX security - EAX is the only AES mode besides GCM that has variable size nonce and AAED. i.e. is an exact drop in replacement for GCM (excluding patent encumbered single pass schemes like OCB) - The CCM-8 scheme (rfc6655) only provides for an 8-octet or 64 bit tag This would be potentially more vulnerable to message forgery attacks. - Scalability. EAX/CCM have lower memory usage than table based GCM - Simplicity. EAX appears to be less complex than CCM. CCM has various AD and nonce length, prefix and alignment requirements (sp800-38c) - AES_GCM vs AES_EAX. Credit (Bellare, Rogaway, Wagner) http://www.cs.berkeley.edu/~daw/talks/FSE04eax.ppt Please attack my logic. *** In Summary *** The NIST approved CCM mode is not a drop replacement for GCM as it does not support fully variable length AD and nonce and does not support streaming due to its length prefix and alignment requirements. EAX mode was designed expressly to address flaws and limitations in CCM (sp800-38c, rfc5116, rfc6655) and offers most of the advantages of GCM besides parallelizability. EAX can act as a drop in replacement for GCM as its parameters and output size are equivalent to GCM. The choice of a CCM mode for TLS (rfc5116, rfc6655) may be unrelated to the benefits of EAX; which address flaws in CCM; rather are likely due to the status of CCM being NIST approved. In terms of performance, EAX varies only slightly in per message overhead compared to CCM, however EAX is simpler, more flexible and supports streaming and variable sized nonce. Standardization and security as we know are uncorrelated. AES-EAX software implementation would have performance approximately equivalent to AES-CCM and ~0% to ~70% less performance than AES-GCM depending on GCM acceleration technique however AES-EAX has the advantage that it is the simple to implement. EAX requires two AES cipher encrypt operations per block with low memory overheads. GCM has one encrypt per block and a GHASH computation which can consume considerable memory per connection with table based GHASH approaches. Non table based GCM GHASH implementations in software that conserve memory are slow. Table based GCM implementations require more key setup time than EAX and use more memory. EAX is well suited to low memory environments and for servers where number of connections is more important than single stream performance. EAX cipher based MAC also benefits from AES acceleration primitives such as those on available on recent Intel, ARM and Sparc. Concurrency can ameliorate performance concerns in manycore architectures; versus optimizing single stream performance using parralelization. With AES-NI, EAX performance should be in the order of 5Gbps to 10Gbps per core on modern Intel CPUS. Ideas for TLSv1.3; dropping CCM-8 (rfc5116) and either preserving the widely unimplemented CCM mode (rfc6655) and/or adding EAX mode as an AAED alternatives to GCM. The principle being to reserve EAX/CCM as AAED alternatives to GCM in a putative case where GCM weak keys and parallelizability lead to a future GCM attack; in addition lowering memory requirements (adding scalability). The CCM-8 (rfc6655) schemes seem to offer less authentication value and could perhaps be removed. So propose to either add these (forward secrecy only): CipherSuite TLS_DHE_RSA_WITH_AES_128_EAX_SHA256 CipherSuite TLS_DHE_RSA_WITH_AES_256_EAX_SHA384 CipherSuite TLS_DHE_DSS_WITH_AES_128_EAX_SHA256 CipherSuite TLS_DHE_DSS_WITH_AES_256_EAX_SHA384 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_EAX_SHA256 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_EAX_SHA384 CipherSuite TLS_ECDHE_DSS_WITH_AES_128_EAX_SHA256 CipherSuite TLS_ECDHE_DSS_WITH_AES_256_EAX_SHA384 and/or retain these (forward secrecy only): CipherSuite TLS_DHE_RSA_WITH_AES_128_CCM_SHA256 CipherSuite TLS_DHE_RSA_WITH_AES_256_CCM_SHA384 CipherSuite TLS_DHE_DSS_WITH_AES_128_CCM_SHA256 CipherSuite TLS_DHE_DSS_WITH_AES_256_CCM_SHA384 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CCM_SHA256 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CCM_SHA384 CipherSuite TLS_ECDHE_DSS_WITH_AES_128_CCM_SHA256 CipherSuite TLS_ECDHE_DSS_WITH_AES_256_CCM_SHA384 Lest we put all out eggs in one basket with respect to authenticating all encryption with GHASH. If one of these AEAD schemes is exploited then servers could mitigate by changing cipher advertisement. Performance shouldn't be the only consideration. I am unaffiliated and am just curious why CCM is in TLS (rfc5116, rfc6655) and EAX isn't. EAX appears to have some better properties compared to CCM based on an analysis of the current literature. Q. Besides performance analysis, has anyone done a formal analysis on the difference in eavesdropping and forgery potential between AES-GCM and AES-EAX/AES-CCM? regards, michael From nobody Sat Dec 20 10:21:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141F61A1B78 for ; Sat, 20 Dec 2014 10:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UPPERCASE_50_75=0.008] 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 6Vh685C8zxxs for ; Sat, 20 Dec 2014 10:21:17 -0800 (PST) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FB41A1B56 for ; Sat, 20 Dec 2014 10:21:16 -0800 (PST) Received: from woodstock.owlhill.net (a88-113-163-188.elisa-laajakaista.fi [88.113.163.188]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 800922001F for ; Sat, 20 Dec 2014 20:21:12 +0200 (EET) Received: from [IPv6:2001:14b8:14e:1:a05a:f9b3:645:fc7b] (unknown [IPv6:2001:14b8:14e:1:a05a:f9b3:645:fc7b]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by woodstock.owlhill.net (Postfix) with ESMTP id BE309734B261 for ; Sat, 20 Dec 2014 20:21:12 +0200 (EET) Message-ID: <5495BE11.4040703@iki.fi> Date: Sat, 20 Dec 2014 20:21:05 +0200 From: Tapio Sokura User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <549538E5.7050109@metaparadigm.com> In-Reply-To: <549538E5.7050109@metaparadigm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qgcD8F5mjouqhmUszFLZjwnOWZg Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 18:21:19 -0000 Hello, On 20.12.2014 10:52, Michael Clark wrote: > CipherSuite TLS_DHE_DSS_WITH_AES_128_EAX_SHA256 > CipherSuite TLS_DHE_DSS_WITH_AES_256_EAX_SHA384 > CipherSuite TLS_ECDHE_DSS_WITH_AES_128_EAX_SHA256 > CipherSuite TLS_ECDHE_DSS_WITH_AES_256_EAX_SHA384 > CipherSuite TLS_DHE_DSS_WITH_AES_128_CCM_SHA256 > CipherSuite TLS_DHE_DSS_WITH_AES_256_CCM_SHA384 > CipherSuite TLS_ECDHE_DSS_WITH_AES_128_CCM_SHA256 > CipherSuite TLS_ECDHE_DSS_WITH_AES_256_CCM_SHA384 A bit off-topic on the actual question, but: Is DSS used anymore? Should these be ECDSA instead? Tapio From nobody Sat Dec 20 16:19:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F4A1A008F for ; Sat, 20 Dec 2014 16:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-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 hAkp1GtW4LQV for ; Sat, 20 Dec 2014 16:19:24 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 A17C31A008B for ; Sat, 20 Dec 2014 16:19:24 -0800 (PST) Received: from monty.local (cm50.kappa90.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBL0eI40022218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 21 Dec 2014 00:40:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419122423; bh=UZZTpC0tfbNW9l2/5iaeZ7bnzzyahW0sfm1+Ri0T9x4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=r0YigDEyTENduf/ZJ7PmjVy5jERRerOJsH0vRYFKCrOyGxhjLDerSczZOvvU3mACP 5H/yKFqwqYG/s0pluSioVNyHFb0ZaMkcOuDXyb3kNWSdQelOmi+HmFsclGGXkC9TH1 1ay+d2NVNM7+sUnc6XjfPb+JSIGPRJ47WZlniUmY= Message-ID: <54961200.6030506@metaparadigm.com> Date: Sun, 21 Dec 2014 08:19:12 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Tapio Sokura , tls@ietf.org References: <549538E5.7050109@metaparadigm.com> <5495BE11.4040703@iki.fi> In-Reply-To: <5495BE11.4040703@iki.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Bqb8FWxwISCW-vI1meRxFvdE91U Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2014 00:19:26 -0000 On 21/12/14 2:21 am, Tapio Sokura wrote: > Hello, > > On 20.12.2014 10:52, Michael Clark wrote: >> CipherSuite TLS_DHE_DSS_WITH_AES_128_EAX_SHA256 >> CipherSuite TLS_DHE_DSS_WITH_AES_256_EAX_SHA384 >> CipherSuite TLS_ECDHE_DSS_WITH_AES_128_EAX_SHA256 >> CipherSuite TLS_ECDHE_DSS_WITH_AES_256_EAX_SHA384 >> CipherSuite TLS_DHE_DSS_WITH_AES_128_CCM_SHA256 >> CipherSuite TLS_DHE_DSS_WITH_AES_256_CCM_SHA384 >> CipherSuite TLS_ECDHE_DSS_WITH_AES_128_CCM_SHA256 >> CipherSuite TLS_ECDHE_DSS_WITH_AES_256_CCM_SHA384 > A bit off-topic on the actual question, but: Is DSS used anymore? Should > these be ECDSA instead? Thanks. Yes. I did mean ECDSA, the eliptic curve variant of DSA (DSS). It was a mistake on my part. Someone mentioned off list mentioned the AEAD ChaCha20-Poly1305 draft, however I note the authenticator is still 16 bytes (128 bits). I had seen the draft but wasn't sure if it was going to be included in TLSv1.3. It occurred to me that a (perhaps not fair) comparison would be with using MD5 which is 128 bits. MD5 has collisions. GHASH finite field and the cipher based MACS (including Poly1305) should be safe in this regard due to their construction. My understanding is that cipher based MACS are vulnerable to attacks that reverse rounds of the cipher after a certain number of texts have been seen (birthday attack). The fact that the nonce has a short lifetime probably makes this intractible however I began wondering about the 'designed in' lower entropy in GCM (IV suffix on first block 32-bits starting at 0x00000001 versus incrementing the whole IV and preserving entropy). Both this; and properties of the parallelizability GHASH construction. The IV construction effectively means only 96 bits need to be brute forced to forge an authenticator (unless in practice a random initial counter was used) as we know the counter for each block. It seems to be a designed in weakness along with excellent parallelizability. CCM and EAX are not exploitable in this manner. The main point was besides eavesdropping potential, was the ability of an attacker to inject random bit errors by finding authenticator collisions; i.e. message integrity; and also the parallelizability of GCM. Parallelizability lowering the barrier to anyone with sufficient resources. AES-GCM and AES-CCM are the only two implemented AEAD ciphers. The later is not present in openssl, boringssl, libressl (last time I looked). The thought that occurred to me was the idea of having a 256-bit authenticator with a 256-bit cipher. In practice we use 256-bit and 384-bit MACs. It's whether we consider the AEAD MAC as an "error correction code" or a "cryptographic MAC". People are widely deploying 256-bit and 384-bit MACs in areas where a "cryptographic MAC" is required. I guess it is also dependent on the time window (which in TLS is short) however someone with acres/hectares of computers could make a DHT (Distributed Hash Table). Drives are cheap and DHTs are fast for vast amounts of data. Reasoning is 32 bits lost entropy, n bits in storage, m bits computed online (from looking at table based GHASH). OMAC1/CMAC is limited to the block size of the underlying cipher which is 128 bits even with AES-256. EAX just seems simpler than CCM. Just thought I would question the convention and established thought... Cheers, Michael. From nobody Sat Dec 20 16:32:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4587D1A00D1 for ; Sat, 20 Dec 2014 16:32: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, 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 62pH0MLM-ayw for ; Sat, 20 Dec 2014 16:32:26 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997DC1A00CF for ; Sat, 20 Dec 2014 16:32:26 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so2603253iec.25 for ; Sat, 20 Dec 2014 16:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+rJBjbNyBEb/An4/6310uy+eukRGUakHFDO81YdiROI=; b=AfXbA0kVPqEAcgeuPbb2TAXjySXAYCogAn5yyqDrKSJlCZ72g1fdbFbhKMitsw04m6 2X79FEnDpb49VKcQk1W4mmZzSxQO4Rq5V8XaxKFxGqi0R+yc/AreeSspYP5pwPFIbA+b qFtIwiDnCRfNYN8+hgMfHKsXAbp8e4SN7V5/dtjq5xT3OIJYpHuonvsFIsHj+sgJiaDM YsIbC3Rezu9yudgWlucjK12NdZYA+3yLtcFQqPeGHlQvgKwezHQIDmfjFWM3DuOhNhty 42Xo+OHPlcVnt//371ButPuguPbgFEcd3lmCyHniroEyW4V51l8kSMeW5WAneYf9gVNQ FMsg== MIME-Version: 1.0 X-Received: by 10.50.134.65 with SMTP id pi1mr9967308igb.32.1419121944009; Sat, 20 Dec 2014 16:32:24 -0800 (PST) Received: by 10.107.134.170 with HTTP; Sat, 20 Dec 2014 16:32:23 -0800 (PST) In-Reply-To: <5495BE11.4040703@iki.fi> References: <549538E5.7050109@metaparadigm.com> <5495BE11.4040703@iki.fi> Date: Sat, 20 Dec 2014 19:32:23 -0500 Message-ID: From: Jeffrey Walton To: Tapio Sokura Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BrAbcbgbt6KLMYJ1hOLl25-jOIY Cc: "tls@ietf.org" Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 00:32:29 -0000 On Sat, Dec 20, 2014 at 1:21 PM, Tapio Sokura wrote: > Hello, > > On 20.12.2014 10:52, Michael Clark wrote: >> CipherSuite TLS_DHE_DSS_WITH_AES_128_EAX_SHA256 >> CipherSuite TLS_DHE_DSS_WITH_AES_256_EAX_SHA384 >> CipherSuite TLS_ECDHE_DSS_WITH_AES_128_EAX_SHA256 >> CipherSuite TLS_ECDHE_DSS_WITH_AES_256_EAX_SHA384 >> CipherSuite TLS_DHE_DSS_WITH_AES_128_CCM_SHA256 >> CipherSuite TLS_DHE_DSS_WITH_AES_256_CCM_SHA384 >> CipherSuite TLS_ECDHE_DSS_WITH_AES_128_CCM_SHA256 >> CipherSuite TLS_ECDHE_DSS_WITH_AES_256_CCM_SHA384 > > A bit off-topic on the actual question, but: Is DSS used anymore? ... Also see "[TLS] Deprecating more (DSA?)", http://www.ietf.org/mail-archive/web/tls/current/msg12006.html. From nobody Mon Dec 22 13:33:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D338D1A8755 for ; Mon, 22 Dec 2014 13:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Ki8JS8R7LWtf for ; Mon, 22 Dec 2014 13:33:55 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771311A8753 for ; Mon, 22 Dec 2014 13:33:55 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so9174785wid.6 for ; Mon, 22 Dec 2014 13:33:54 -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:content-type; bh=IARd7nZr6e4j24AkAVI8/34+irnvq4Sph86P/Ft6xDE=; b=ehsaw8T+1z4oDLgqU35/kP9aFNfw7ix88T6oJtSOC5CcaoUcpqn3CDeqD+ZbloCabA 6Z+952A1EciAJpBKOjchGJbi4F6mSEoex4PYLs7rWKnZWawRRGnh/WwFR5s3LPFygkXj 0qK9c9jonWY1tcmI9s3GLQSfEmr86ZJViF38G4n8W9IwaPvW9q7yMF89RgpVGZ+D9Omt LcO6JgkKC2CvMOrBweILcc+SZpOJcjOghSyLjH3Q79RIsJThh0DNYZmJhPyKaYJwTHQz xbJ8mVYOx2ik/T4x7+griLHp5D8UZhxUcByQOkOgna3bvHdO8fZNUV6PftySOxaoRL+/ +XNQ== X-Gm-Message-State: ALoCoQktW/6qkXiuiSgxLFFXaGBgFqyK06vhNPmus0Xu8DLcbfuDivSreU4x/27ZVncATLmF5YUT X-Received: by 10.180.19.193 with SMTP id h1mr35078871wie.10.1419284034117; Mon, 22 Dec 2014 13:33:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Mon, 22 Dec 2014 13:33:13 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 22 Dec 2014 13:33:13 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53d526fb07a73050ad4d03c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EYjH-a06jktMQNDd-VnJypElKKg Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 21:33:58 -0000 --bcaec53d526fb07a73050ad4d03c Content-Type: text/plain; charset=UTF-8 I've posted an updated PR at: https://github.com/tlswg/tls13-spec/pull/89 Note that I did not restore the ChangeCipherSpec message as my sense of the WG discussion and private conversations was that people preferred to have it gone. If you feel strongly about this change one way or the other, and haven't already posted to the list about it, please do so now, as I'd like to resolve this and merge this PR this week. Best, -Ekr On Fri, Nov 7, 2014 at 2:01 PM, Eric Rescorla wrote: > I've created a preliminary pull request to adapt the session hash fix for > TLS 1.3 > for feedback from the WG. > > Points to note: > > - IMPORTANT: Because the initial handshake messages are encrypted > under separate keys from the application data traffic, it seems like we > need > to have 2 sets of CCS messages or none. In anticipation of removing > renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88). > Based on conversations with Alfredo and Martin, it seemed easier > to remove them. Warning: analysis needed here. > > - I created a separate resumption master secret that is fed into the > key hierarchy. This makes the description of that simpler but will > need revisiting if we adopt either Rich's unification of session hash > and tickets or Karthik's PSK-as-tickets unification, but that seemed > like a separate issue. > > - If we adopt the Update proposal we will also need to split the master > keys into two directional keys, but that's distinct as well. > > - I still need to add the names of the session hash authors t > acknowledgements. > > This will probably need another revision before it is ready for merging, > but > I wanted to get it out there for feedback. > > -Ekr > > > > --bcaec53d526fb07a73050ad4d03c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've posted an updated PR at:


Note that I did not restore the = ChangeCipherSpec message as my sense of
the WG discussion and= private conversations was that people preferred to
have it gone.= If you feel strongly about this change one way or the other,
and= haven't already posted to the list about it, please do so now, as I= 9;d
like to resolve this and merge this PR this week.
<= br>
Best,
-Ekr


=

On Fri, Nov 7, 2014 at 2:01 PM, Eric Rescorla <ekr@rtfm.com> wro= te:
I've created a p= reliminary pull request to adapt the session hash fix for TLS 1.3
for f= eedback from the WG.

Points to note:

<= /div>
- IMPORTANT: Because the initial handshake messages are encrypted=
=C2=A0 under separate keys from the application data traffic, it= seems like we need
=C2=A0 to have 2 sets of CCS messages or none= . In anticipation of removing
=C2=A0 renegotiation (see PR=C2=A0<= a href=3D"https://github.com/tlswg/tls13-spec/pull/88" target=3D"_blank">ht= tps://github.com/tlswg/tls13-spec/pull/88).
=C2=A0 Based on c= onversations with Alfredo and Martin, it seemed easier
=C2=A0 to = remove them. Warning: analysis needed here.

- I cr= eated a separate resumption master secret that is fed into the
= =C2=A0 key hierarchy. This makes the description of that simpler but will
=C2=A0 need revisiting if we adopt either Rich's unification o= f session hash
=C2=A0 and tickets or Karthik's PSK-as-tickets= unification, but that seemed
=C2=A0 like a separate issue.
=

- If we adopt the Update proposal we will also need to = split the master
=C2=A0 keys into two directional keys, but that&= #39;s distinct as well.

- I still need to add the = names of the session hash authors t
=C2=A0 acknowledgements.<= /div>

This will probably need another revision bef= ore it is ready for merging, but
I wanted to get it out there for= feedback.

-Ekr




--bcaec53d526fb07a73050ad4d03c-- From nobody Mon Dec 22 13:39:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A831B1A8769 for ; Mon, 22 Dec 2014 13:39:19 -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 Wqc4JwEtkDfa for ; Mon, 22 Dec 2014 13:39:18 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1C61A8758 for ; Mon, 22 Dec 2014 13:39:17 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so7663344wgg.10 for ; Mon, 22 Dec 2014 13:39: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3qiykTTmIfaDxtNIiJ7mOrMApSySkThE31Xl4g+lkYQ=; b=Xx7Evzj38Y0c5L9JqDUg+wsagL7Ip0B5t0uL38NHWXFbD+AGEqrXrqe1ghRRwuNdW9 AqfKYXvlrFP+2LgBsLrx8n3nLPVCL/CsZyM3yiMZG12x1X8K5D6WQaA8mkwptzSqZDAk /YHwPwwpNzLbqR3jTAhTgxoLW+k+DESCo9XsArzAWFBz4TEznOyjBJzoW2G3Cbg6hVw3 sc2DSCQywuFRQkm0Ge/KrBWMMosP7CaGVTwLsQ3pW1u+NW/rGglNbaZc/RiE1SBYGBGn qmf+GCDbEGFnXwPXVVxzxhFGL6+4+FQBsP14P65JXxnIB5cwOFJ23qglSS58rBbkt8Od XFZQ== X-Gm-Message-State: ALoCoQlEJds2WCzCEamWZ9ROOtRbbfU4HLo2mOe1D9lOLVv4QvlyHXx5l7dSsyONLN7zkM70bW5R X-Received: by 10.194.108.98 with SMTP id hj2mr46208300wjb.102.1419284356602; Mon, 22 Dec 2014 13:39:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Mon, 22 Dec 2014 13:38:36 -0800 (PST) In-Reply-To: References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> From: Eric Rescorla Date: Mon, 22 Dec 2014 13:38:36 -0800 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=089e010d8a8ce92830050ad4e353 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cKohnB3JU55P0FMV4psqWXq4sJc Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 21:39:19 -0000 --089e010d8a8ce92830050ad4e353 Content-Type: text/plain; charset=UTF-8 Adam updated his PR to sign the prefix concatenated with the handshake hashes, which makes it easier to have a single hash context. https://github.com/tlswg/tls13-spec/pull/100 I haven't seen any objections to this idea, so I'll merge this on Wednesday unless I hear an objection before then. -Ekr P.S. I note that this doesn't address Nikos's issue ( https://www.ietf.org/mail-archive/web/tls/current/msg14764.html) but that seems separable, and I'd encourage those who think that's a good idea to weigh in on a different thread. On Mon, Dec 1, 2014 at 2:28 PM, Adam Langley wrote: > On Wed, Nov 26, 2014 at 6:09 AM, Eric Rescorla wrote: > > If someone wants to contribute a PR so that we can have something > > concrete to look at that would be even better. > > I have submitted a PR for the padding and context-string changes: > https://github.com/tlswg/tls13-spec/pull/100 > > I did not change the CertificateVerify structure in the same commit > because I'm not quite sure that I follow the reasoning. The > CertificateVerify implicitly contains the client and server nonce > because it contains all the preceding handshake messages. What's the > motivation for duplicating them at the beginning? Is it simply to > avoid having the opaque signer understand the TLS structure? If so, > does the padding and context strings that I've just proposed break > that? > > > Cheers > > AGL > --089e010d8a8ce92830050ad4e353 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam updated his PR to sign the prefix concatenated with t= he handshake
hashes, which makes it easier to have a single hash contex= t.

I haven't seen any objections to this idea, so I'll me= rge this on Wednesday
unless I hear an objection before then.= =C2=A0

-Ekr

P.S. I note t= hat this doesn't address
but that see= ms separable, and I'd encourage those who think that's a good
=
idea to weigh in on a different thread.


On Mon, Dec 1, 2014 a= t 2:28 PM, Adam Langley <agl@google.com> wrote:
On Wed, Nov 26, 2014 at 6:09 AM, Eric R= escorla <ekr@rtfm.com> wrote:
> If someone wants to contribute a PR so that we can have something
> concrete to look at that would be even better.

I have submitted a PR for the padding and context-string changes: = https://github.com/tlswg/tls13-spec/pull/100

I did not change the CertificateVerify structure in the same commit
because I'm not quite sure that I follow the reasoning. The
CertificateVerify implicitly contains the client and server nonce
because it contains all the preceding handshake messages. What's the motivation for duplicating them at the beginning? Is it simply to
avoid having the opaque signer understand the TLS structure? If so,
does the padding and context strings that I've just proposed break
that?


Cheers

AGL

--089e010d8a8ce92830050ad4e353-- From nobody Mon Dec 22 19:05:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957FA1ACD56 for ; Mon, 22 Dec 2014 19:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 XeBuFBRfrOvs for ; Mon, 22 Dec 2014 19:05:11 -0800 (PST) Received: from argon.maxg.info (argon.maxg.info [94.23.252.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FB11ACD57 for ; Mon, 22 Dec 2014 19:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=cF4n4zjs5yS3bmnq7eTwdJtEdTphExMLoHeEy7y/Xe0=; b=QUEdFL1nvEmCDuNTP0+4yikBTfhv9CmR4xD1Gfn9NOCOC/hgAuCklb91I7sQNkfnsZY+g6aOX1SzHpT5jnWo3bl/YjTuxNkbkctElPstkBF+wFAKkXEMcvcGCqOXtRqZ; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (envelope-from ) id 1Y3FmS-000621-Rm ; Tue, 23 Dec 2014 04:05:04 +0100 Message-ID: <5498DBCE.1070909@delignat-lavaud.fr> Date: Tue, 23 Dec 2014 04:04:46 +0100 From: Antoine Delignat-Lavaud User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VN9ZZMxH1OGDv2HOtJ_ij-rqEe4 Cc: Karthik Bhargavan , Alfredo Pironti Subject: [TLS] Remove signature algorithms from cipher suites 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, 23 Dec 2014 03:05:13 -0000 Dear WG, This topic has been brought up in previous discussions but, following private discussion with ekr, I would like to bring it up again. The current draft of TLS 1.3 relies exclusively on signatures to prove ownership of private keys in certificates, dropping support for static DH shares in certificates. Furthermore, it mandates support of a dedicated negotiation mechanism for signature algorithms. This negotiation is a bit asymmetric, since the client sends its supported pairs of algorithm and hash function in the "signature_algorithms" extension while the server uses the "supported_signature_algorithms" field of the CertificateRequest message (I won't elaborate any more on this topic but it may be worth thinking about). In this design, keeping the legacy of including the signature algorithm to be used in the ServerCertificateVerify message within the selected cipher suite name can be a burden to the modularity and extensibility of the protocol, since adding support for new signature algorithms comes at the cost of an exponential increase in the length of the list of cipher suites sent by the client, even though the security guarantees of the handshake are now fully modular w.r.t authentication goals achieved by certificate and signatures. The tensions between cipher suite and signature algorithm negotiation already existed in 1.2 and it led to oddities in the protocol, such as the inability to use FF-DHE authenticated by ECDSA, even though there isn't anything inherently wrong with this combination. The following paragraph, taken from the current 1.3 draft, is another instance of this awkwardness: "If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension. Note that there is a possibility for inconsistencies here. For instance, the client might offer DHE_DSS key exchange but omit any DSA pairs from its "signature_algorithms" extension. In order to negotiate correctly, the server MUST check any candidate cipher suites against the "signature_algorithms" extension before selecting them. This is somewhat inelegant but is a compromise designed to minimize changes to the original cipher suite design." Hence, I am proposing to create a pull request that includes the following changes: - Any new cipher suite introduced from version 1.3 onwards MUST NOT contain any signature algorithm name (e.g. ECDHE_CHACHA20_POLY1305_SHA256). Keeping a hash algorithm even for AEAD ciphers remains necessary to determine the PRF to use; - For compatibility with previous protocol versions, existing cipher suite names are preserved; however, servers MUST NOT select any cipher suite that includes a signature algorithm other than RSA in a 1.3 handshake; - The server must use one of the client's supported signature algorithms in its CertificateVerify message. The precise algorithm used may depend on the client's indicated preferences and on the server's policy (in the spirit of current cipher suite negotiation). All certificates in a chain MUST also be signed with signature algorithms supported by the client. The same requirements apply even if a pre-1.3 cipher suite (such as ECDHE_RSA_AES256_GCM_SHA384) was selected: the algorithm in the cipher suite name is ignored. Do note that there are several possible alternatives to the propositions above, and I am not set on any particular choice. For instance, it may be easier to forbid all pre-1.3 cipher suites and create a fresh list. Even though these changes should be straightforward to understand, it appears that they would require significant edits to many parts of the current draft, which is why I would like to see if a consensus could emerge on this question before proceeding with the necessary work on a pull request. The main motivation for proposing these changes is to introduce support for PSS signatures in TLS and in certificates. You may have heard about the Bleichenbacher-like universal forgery attack in NSS that I recently discovered with Brian this summer (also known as "BERserk", name by Intel): such bugs should remind us that PKCS#1v1.5 is a fragile signature algorithm ([EC]DSA can also be hazardous in its randomized variant, as shown by Sony hack and recent bitcoin thefts), and the fact that TLS not only mandates its use, but also explicitly prohibits better alternatives ("a certificate with RSASSA-PSS signature key cannot be used because TLS defines no corresponding signature algorithm") is hardly acceptable. Hence, I propose to include with this change the introduction of a new SignatureAlgorithm value rsa-pss(4) that denotes PKCS#1v2.2 RSASSA-PSS signatures with default parameters (mgf1SHA1 for mask generation and the length of the message digest function output as salt length). It may take time before this change impacts PKIX and CAs, but it is at least a necessary first step. Best, Antoine From nobody Mon Dec 22 22:07:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2301A00B8 for ; Mon, 22 Dec 2014 22:07:38 -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 KF5-uDS_X2_A for ; Mon, 22 Dec 2014 22:07:36 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D0E1ACD79 for ; Mon, 22 Dec 2014 22:07:36 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id nt9so26743294obb.5 for ; Mon, 22 Dec 2014 22:07:35 -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=VnPXLAPQCXIZprs9FvVN+J0dxJKx2Q/x7vjiTIFMvV0=; b=bpy73SxhNrI0ReZ1sjaBPgRfOJKYlLwMJa4PRxu96+pL1yMPYraNDy/TIR5UcOCXKF CXb4ouMCNg4XYnYK+owDRwzi1LuehwJmEfn53omCBG/D8h/y8FVawbLrYkRByzrE9PCm gXvpCcedrwIOsYbpFP3eJ4Tb1gNu8CsFHtYydgSSSDs9VcfjEDw3HNorh0LsyvyC+ZHR IwN6fpuWJ0rQFzal9brClsGPKygem7+XpNqf9nnjGcyP76S8h3CXZ6upGYGWy0xo951F 6Yw6T2E00WI0HFdLpSgD3gUc3Cm7sDrgEM/sS6KK1u5hQUawYgKiCgz9TegOWht6oGrA Etlw== X-Gm-Message-State: ALoCoQmCQQTffb4VpUeIlsDa5gJrHvdRI2e7qaWEaEY1x4ijrFIrDVlQMz9yBYzjt7fbAze4qNDX MIME-Version: 1.0 X-Received: by 10.202.184.135 with SMTP id i129mr14352744oif.68.1419314855818; Mon, 22 Dec 2014 22:07:35 -0800 (PST) Received: by 10.76.71.228 with HTTP; Mon, 22 Dec 2014 22:07:35 -0800 (PST) In-Reply-To: <5498DBCE.1070909@delignat-lavaud.fr> References: <5498DBCE.1070909@delignat-lavaud.fr> Date: Mon, 22 Dec 2014 22:07:35 -0800 Message-ID: From: Brian Smith To: Antoine Delignat-Lavaud Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2wwyIZErPjHHG0LtMBa8nWchrnY Cc: Karthik Bhargavan , "tls@ietf.org" , Alfredo Pironti Subject: Re: [TLS] Remove signature algorithms from cipher suites 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, 23 Dec 2014 06:07:38 -0000 Antoine Delignat-Lavaud wrote: > The current draft of TLS 1.3 relies exclusively on signatures to prove > ownership of private keys in certificates How would your proposal change if signature-less authentication mechanisms were added (later)? How would we indicate support for the signature-less authentication? > In this design, keeping the legacy of including the signature algorithm to > be used in the ServerCertificateVerify message within the selected cipher > suite name can be a burden to the modularity and extensibility of the > protocol, since adding support for new signature algorithms comes at the > cost of an exponential increase in the length of the list of cipher suites > sent by the client, even though the security guarantees of the handshake are > now fully modular w.r.t authentication goals achieved by certificate and > signatures. In theory, that sounds like a problem. Is it really a problem in practice, if we're not concerned about the specific case of RSA-PSS? > The tensions between cipher suite and signature algorithm negotiation > already existed in 1.2 and it led to oddities in the protocol, such as the > inability to use FF-DHE authenticated by ECDSA, even though there isn't > anything inherently wrong with this combination. On the other hand, nobody has ever seemed to want TLS_DHE_ECDSA_* cipher suites, so it doesn't seem like it caused any problem. > The following paragraph, > taken from the current 1.3 draft, is another instance of this awkwardness: > > "If the client has offered the "signature_algorithms" extension, the > signature algorithm and hash algorithm MUST be a pair listed in that > extension. Note that there is a possibility for inconsistencies here. For > instance, the client might offer DHE_DSS key exchange but omit any DSA pairs > from its "signature_algorithms" extension. In order to negotiate correctly, > the server MUST check any candidate cipher suites against the > "signature_algorithms" extension before selecting them. This is somewhat > inelegant but is a compromise designed to minimize changes to the original > cipher suite design." In other words, the client might offer DHE_DSS cipher suites that are only to be used by older servers that do not understand TLS 1.2 and the signature_algorithms extension, while TLS 1.2 implementations should choose ECDSA. That's pretty reasonable/desirable behavior. > - For compatibility with previous protocol versions, existing cipher suite > names are preserved; however, servers MUST NOT select any cipher suite that > includes a signature algorithm other than RSA in a 1.3 handshake; What is the practical advantage of having this restriction? I would be concerned that there might be an interoperability loss if servers choose TLS_ECDHE_RSA_* but use an ECDSA certificate. It would be good to see some measurement of the effects of doing that, but it is difficult to do such measurement. I think there should be a clear benefit to the restriction in order to justify the effort to measure if it would work. > current cipher suite negotiation). All certificates in a chain MUST also be > signed with signature algorithms supported by the client. The same > requirements apply even if a pre-1.3 cipher suite (such as > ECDHE_RSA_AES256_GCM_SHA384) was selected: the algorithm in the cipher suite > name is ignored. Many (most?) clients already work this way, so I don't think this would be too controversial. But, it seems better for the server to choose the cipher suite that best identifies the signature algorithm that it actually uses (e.g. TLS_x_ECDSA_* for a ECDSA certificate), instead of always using the RSA one. > The main motivation for proposing these changes is to introduce support for > PSS signatures in TLS and in certificates. Why should anybody add any new RSA-based signature scheme now? Shouldn't we let the RSA algorithm die off with Windows XP and other ancient stuff? If we're not happy with ECDSA because of the requirement for a perfect PRNG for randomized signatures, why not just specify that ServerKeyExchange in TLS 1.3 MUST use deterministic ECDSA signatures when an ECDSA certificate is used, or something similar that has similar server-side efficiency as ECDSA? There's got to be better alternatives to spending time tweaking support for RSA. Cheers, Brian From nobody Tue Dec 23 01:26:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB21A6F92 for ; Tue, 23 Dec 2014 01:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWPfpDs70Aw5 for ; Tue, 23 Dec 2014 01:26:34 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745081ACDAE for ; Tue, 23 Dec 2014 01:26:32 -0800 (PST) Received: from pc (ip5b4006da.dynamic.kabel-deutschland.de [::ffff:91.64.6.218]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 23 Dec 2014 10:26:28 +0100 id 000000000000005D.0000000054993544.00001E65 Date: Tue, 23 Dec 2014 10:26:35 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20141223102635.3bda9ed2@pc> In-Reply-To: <5498DBCE.1070909@delignat-lavaud.fr> References: <5498DBCE.1070909@delignat-lavaud.fr> 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-7781-1419326788-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZYvoEAwMjxauoXbmrrDm1vPF8Xw Subject: Re: [TLS] Remove signature algorithms from cipher suites 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, 23 Dec 2014 09:26:36 -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-7781-1419326788-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, On Tue, 23 Dec 2014 04:04:46 +0100 Antoine Delignat-Lavaud wrote: > Hence, I propose to include with this change the introduction of a > new SignatureAlgorithm value rsa-pss(4) that denotes PKCS#1v2.2 > RSASSA-PSS signatures with default parameters (mgf1SHA1 for mask > generation and the length of the message digest function output as > salt length). It may take time before this change impacts PKIX and > CAs, but it is at least a necessary first step. Thanks for bringing PSS for TLS 1.3 up, I wanted to do this for quite some time. Do I understand your proposal right that it'd result in: a) If we use the normal RSA certificates we have today TLS 1.3 would continue using RSA-PKCS#1v1.5 b) If the user gets a designated RSA-PSS key/certificate it'd use PSS? I think this would result in a near-zero-adoption for PSS probably for a very long time because you'd depend on the CA to do anything. Why not go the much simpler route: Define that TLS 1.3 uses PSS by default. Certificates / Keys for RSA-PSS are no different from PKCS#1v1.5 keys. We can just use the existing ones. (Please note that the algorithm identifier for PSS already exists for X509, it's RFC 4055. It allows Keys with an algorithm identifier restricting to PSS, but that's no requirement - you can use the old keys for PSS as well, as technically they're no different.) Best, --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-7781-1419326788-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUmTVLAAoJEKWIAHK7tR5CJ+0P/A0NCCib9MEqpS/YjbNKvOZe iVXcBTBE7OUsw6hut1zR9nWsE7KufoxyO0eEql7/tAo5jIOrJ5JSiUVsZQaBLMzz gEGhgQWOx7/X+emVC93YY48xRki+/5TUjf3qQMSGiCnltYBe0BJS5cwUELHrbqZV j3E+85KRulCGPd7hocUgTXpACwxWAUOCXrYKverpI5k97JuCpKla2++dkQk/VYpe HXXS7aX0yQdnflhOTPIZTWj4u4OvoMUJrZyibFKLT4hDRwyzmWzYgjzVhDBfJ0SR xbpsNMykxFuqhN6t8vkuzPQZXe2b4QyRDXRreKzGicxwb/FWwIkg6BxwRlIjw6BN Ga0fmRNV7hJ7l1soRfMqpnB0rvymJwpgT6MFuA1xzG36fsXE9Imz3XVn9GVr4cXc ZRFMolaqOXAYsHsTIyg3Utsf1hpxDNv+M6RkjCY7IgAf0JOgcfduHvegUALoe20s 9e/buY8NFXMto12PCW4Slx2YMbMUdjv7w36ZjFQ6uWWfcNioN11WPe65/FAUm4yY cljUZPY1CeikD38PALhSNTj0kqGyzB1BEjl1kFd8PhIbIkOL57LbJ3SEDdQe9Yi1 trRUVcdsc8+UTkMaTepZcuhM76zDl/GRf2H3ULZgu9QP3N1DYAEsz9mv44yN5a5R cHHRYdVHfPd8hlvH459m =jpe5 -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-7781-1419326788-0001-2-- From nobody Tue Dec 23 03:26:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4253C1ACDB5 for ; Tue, 23 Dec 2014 03:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 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_LOW=-0.7, 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 S9RvUY8KK5gM for ; Tue, 23 Dec 2014 03:26:53 -0800 (PST) Received: from argon.maxg.info (argon.maxg.info [94.23.252.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9331ACDA9 for ; Tue, 23 Dec 2014 03:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=bUGsN1dFPokCDdaMriQl9qfO9GCjz99e9EFAajYsXOI=; b=ia/7Wk5qgq7CJoh+vII+PE+VLGjsM+M3qbCRR7eIFv/7GhfnINZi51NzujkEgQ4Vkjq3DpflNNkGDgODdXfKdZpVaunxNK5kSIYlNq1uM+LSZlNOT+yTHu0ZZ7rvEmnB; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (envelope-from ) id 1Y3Nc2-00084T-54 ; Tue, 23 Dec 2014 12:26:50 +0100 Message-ID: <54995163.7070004@delignat-lavaud.fr> Date: Tue, 23 Dec 2014 12:26:27 +0100 From: Antoine Delignat-Lavaud User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Hanno_B=F6ck?= , tls@ietf.org References: <5498DBCE.1070909@delignat-lavaud.fr> <20141223102635.3bda9ed2@pc> In-Reply-To: <20141223102635.3bda9ed2@pc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k_9PI6ccVqmKaLufhTZpUzahCt0 Subject: Re: [TLS] Remove signature algorithms from cipher suites 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, 23 Dec 2014 11:26:56 -0000 Hi, Le 12/23/2014 10:26 AM, Hanno Bck a crit : > Do I understand your proposal right that it'd result in: > > a) If we use the normal RSA certificates we have today TLS 1.3 would > continue using RSA-PKCS#1v1.5 > b) If the user gets a designated RSA-PSS key/certificate it'd use PSS? > > I think this would result in a near-zero-adoption for PSS probably for > a very long time because you'd depend on the CA to do anything. No, in my proposal, the algorithm used in CertificateVerify messages is negotiated based on advertised support in the "signature algorithms" extension (and supported_signature_algorithms field in CertificateRequest). Clients are encouraged to prioritize rsa-pss/sha256 over rsa/sha256 or rsa/sha1, and supporting servers may pick PSS even if their certificate chain only contains rsa/sha256 and rsa/sha1. > (Please note that the algorithm identifier for PSS already exists for > X509, it's RFC 4055. It allows Keys with an algorithm identifier > restricting to PSS, but that's no requirement - you can use the old > keys for PSS as well, as technically they're no different.) If anything, my own concern is the opposite. Allowing the same RSA key to be used to sign with both PSS and PKCS#1v1.5 is considered cryptographic malpractice, as the composition of secure and weak signatures may very well be broken. However, servers have the ability to avoid this risk by sending a different certificate depending on whether the client advertises support for PSS or not, even if the two certificates are signed with PKCS#1 (the proof of the protocol will probably assume servers enforce this behavior). Furthermore, one of the issues of PSS in RFC 4055 is its reliance on signature parameters, which have tricky agility characteristics. For everyone's sake, it may help adoption if new OIDs for PSS signatures were used that correspond to fixed parameters. In any case, this discussion is out of the scope of the TLS WG. Best, Antoine From nobody Tue Dec 23 04:11:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DEE1ACDBF for ; Tue, 23 Dec 2014 04:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 gnYBI-gCQI1j for ; Tue, 23 Dec 2014 04:11:29 -0800 (PST) Received: from argon.maxg.info (argon.maxg.info [94.23.252.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBF51ACDB9 for ; Tue, 23 Dec 2014 04:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=LXg72S7uiLiXAXu8IN4zwGyIH3GJKm97VBRpxmiDQsU=; b=U5mMzfWD2unPAnR5s63HxlUn1v5A4XXxoCsTlkzpizRFS02rhSgqrZlYSj5tw17B488AtU1JMTL4mLI9W0xCduGd6bL1vtupt+Q+WUFwduflg+hxr8037kjjPCDyLPqH; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (envelope-from ) id 1Y3OJC-0001OY-LS for tls@ietf.org; Tue, 23 Dec 2014 13:11:28 +0100 Message-ID: <54995BD6.8000504@delignat-lavaud.fr> Date: Tue, 23 Dec 2014 13:11:02 +0100 From: Antoine Delignat-Lavaud User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <5498DBCE.1070909@delignat-lavaud.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b6-1VN32QE4DDNzGTenkgSFuXhs Subject: Re: [TLS] Remove signature algorithms from cipher suites 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, 23 Dec 2014 12:11:32 -0000 Le 12/23/2014 7:07 AM, Brian Smith a crit : > How would your proposal change if signature-less authentication > mechanisms were added (later)? How would we indicate support for the > signature-less authentication? Such schemes would either require an extension or a custom cipher suite because of their different state machine. > >> In this design, keeping the legacy of including the signature algorithm to >> be used in the ServerCertificateVerify message within the selected cipher >> suite name can be a burden to the modularity and extensibility of the >> protocol, since adding support for new signature algorithms comes at the >> cost of an exponential increase in the length of the list of cipher suites >> sent by the client, even though the security guarantees of the handshake are >> now fully modular w.r.t authentication goals achieved by certificate and >> signatures. > In theory, that sounds like a problem. Is it really a problem in > practice, if we're not concerned about the specific case of RSA-PSS? On the other hand, nobody has ever seemed to want TLS_DHE_ECDSA_* cipher suites, so it doesn't seem like it caused any problem. Right now, it isn't a problem in practice, but it is not clear either that DSA (maybe in danger of being removed?), ECDSA and PKCS#1v1.5 are a good set of signature algorithms to commit to for the long run. Even in the short term, a MAC-based signature scheme may be useful for PSK and resumption. > >> - For compatibility with previous protocol versions, existing cipher suite >> names are preserved; however, servers MUST NOT select any cipher suite that >> includes a signature algorithm other than RSA in a 1.3 handshake; > What is the practical advantage of having this restriction? I would be > concerned that there might be an interoperability loss if servers > choose TLS_ECDHE_RSA_* but use an ECDSA certificate. It would be good > to see some measurement of the effects of doing that, but it is > difficult to do such measurement. I think there should be a clear > benefit to the restriction in order to justify the effort to measure > if it would work. An alternative would be to allow any pre-1.3 cipher suite to be used, while allowing the signature algorithm used to authenticate the server may be different from the one included in the cipher suite name (e.g. server picks TLS_DHE_RSA_* but signs CertificateVerify with PSS). > Many (most?) clients already work this way, so I don't think this > would be too controversial. But, it seems better for the server to > choose the cipher suite that best identifies the signature algorithm > that it actually uses (e.g. TLS_x_ECDSA_* for a ECDSA certificate), > instead of always using the RSA one. Indeed, even miTLS works like this in TLS 1.2 even though this behavior is not permitted by current specification. As I said, I am not particularly set on the specifics of how to make the transition from pre-1.3 cipher suite names, and I'm fine with what you suggest. > >> The main motivation for proposing these changes is to introduce support for >> PSS signatures in TLS and in certificates. > Why should anybody add any new RSA-based signature scheme now? > Shouldn't we let the RSA algorithm die off with Windows XP and other > ancient stuff? If we're not happy with ECDSA because of the > requirement for a perfect PRNG for randomized signatures, why not just > specify that ServerKeyExchange in TLS 1.3 MUST use deterministic ECDSA > signatures when an ECDSA certificate is used, or something similar > that has similar server-side efficiency as ECDSA? There's got to be > better alternatives to spending time tweaking support for RSA. It is currently impossible to get a non-RSA certificate signed by any public CA (I know because I tried hard to get one). Only Google can concretely deploy EC certs today. Hence, there's is currently NO alternative to RSA signatures for authentication. By the way, it may be a good idea to recommend or mandate RFC6979-style deterministic ECDSA signatures in TLS to prevent entropy-exhaustion attacks against clients and servers. Off-topic though. Best, Antoine From nobody Tue Dec 23 06:27:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7DA1ACEC8 for ; Tue, 23 Dec 2014 06:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 DfB56BpkkpQW for ; Tue, 23 Dec 2014 06:26:52 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D031ACEC6 for ; Tue, 23 Dec 2014 06:26:51 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 30845188824; Tue, 23 Dec 2014 16:26:48 +0200 (EET) Date: Tue, 23 Dec 2014 16:26:48 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20141223142648.GA11149@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: http://mailarchive.ietf.org/arch/msg/tls/WXjpIISy2RoD-WRmqvrTxHye0W8 Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 14:26:58 -0000 On Mon, Dec 22, 2014 at 01:33:13PM -0800, Eric Rescorla wrote: > I've posted an updated PR at: > > https://github.com/tlswg/tls13-spec/pull/89 > > Note that I did not restore the ChangeCipherSpec message as my sense of > the WG discussion and private conversations was that people preferred to > have it gone. If you feel strongly about this change one way or the other, > and haven't already posted to the list about it, please do so now, as I'd > like to resolve this and merge this PR this week. > (General philosophical note: I'm in favor of more complicated protocol if: - It fixes something that is just plain nasty to analyze, or - It causes bad implementations to break fast instead of being security timebombs.) Regarding CCS removal, I'm very much in favor. Reading through this, some comments: "At this point, the handshake is complete, and the client and server may exchange application layer data, which is protected using a new set of keys derived from both the premaster secret and the handshake transcript (see {{I-D.ietf-tls-session-hash}} for the security rationale for this.)" AFAIK, I-D.ietf-tls-session-hash doesn't really contain security rationale for this. It only has security rationale for hashing exchange keys (which are included in the first keying anyway) and says about including certificates (paraprhased): "Compliant with NIST recommediations" and "SSH does this" (actually, it only does that for server key, not client key). Now, if EncryptedExtensions contains extensions that twiddle with some critical parameters, there is very much reason to rekey after that. "[[OPEN ISSUE: Should we restart the handshake hash? https://github.com/tlswg/tls13-spec/issues/104.]]" I regard restarting the hashes as very dangerous (not that I think that the whole HRR is a good idea, but I don't say more about that). Yes, I know that the hellos MUST be the same. But didn't we have a case of MUST being violated leading into a nasty security hole recently? If hashes are restarted and 1st ClientHello and HelloRetryRequest can be tampered with, the conseqences are not something I want to even try to analyze (implementation-dependent!). If hashes are continued, then it requires MITM to modify anything in key exchange. And the latter authentication pass should be able to detect that MITM. "This master secret value is used to generate the record protection keys used for the handshake, as described in {{key-calculation}}. It is also used with TLS Exporters {{RFC5705}}." Wasn't there an idea for giving TLS Exporter its own master secret? That would stop applications from exporting important system keys. "If the server does not request client authentication, the master secret can be computed at the time that the server sends its Finished, thus allowing the server to send traffic on its first flight (see [TODO] for security considerations on this practice.) If the server requests client authentication, this secret can be computed after the client's Certificate and CertificateVerify have been sent, or, if the client refuses client authentication, after the client's empty Certificate message has been sent." Server can't send data on first flight (to anonymous recipient) if it requests client authentication? E.g. HTTP/2 settings blocks, protocol banners or various other protocol capability negotiations. Obviously, generating the resumption premaster secret has to wait for client finished (otherwise one can run into trouble with just transport glitches, no attackers required). Looks like for the resume case, the ClientHello and ServerHello are hashed into keys. I think this should be done (I don't se attacks otherwise, but that doesn't mean there could not be one... This is another of those "I don't want to analyze that" places). -Ilari From nobody Tue Dec 23 06:37:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B4D1ACEF2 for ; Tue, 23 Dec 2014 06:37:23 -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 aBuWnV8cFQKw for ; Tue, 23 Dec 2014 06:37:22 -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 DEB071ACEEB for ; Tue, 23 Dec 2014 06:37:21 -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 89F7081879; Tue, 23 Dec 2014 16:37:19 +0200 (EET) Date: Tue, 23 Dec 2014 16:37:19 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20141223143719.GB11149@LK-Perkele-VII> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n3lf9eNPbUNqdYqTyAIUNB5UVBA Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 14:37:23 -0000 On Mon, Dec 22, 2014 at 01:38:36PM -0800, Eric Rescorla wrote: > Adam updated his PR to sign the prefix concatenated with the handshake > hashes, which makes it easier to have a single hash context. > > https://github.com/tlswg/tls13-spec/pull/100 > > I haven't seen any objections to this idea, so I'll merge this on Wednesday > unless I hear an objection before then. > Any reason not to fix the hash function per-ciphersuite, so servers and clients don't have to run multiple hashes in parrallel? Suitable hash function is required by the THS fix anyway, and one could just reuse that context if one has implementation capable of intermediate hashes or hash context cloning. If one is worried about cross-hash attacks (even if all hashes should be strong), stick the ciphersuite ID (which fixes the hash) into data to be signed. -Ilari From nobody Tue Dec 23 10:20:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448041A1AB1 for ; Tue, 23 Dec 2014 10:20:27 -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 Jjh_e48W-qXo for ; Tue, 23 Dec 2014 10:20:25 -0800 (PST) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FC31A1AAA for ; Tue, 23 Dec 2014 10:20:25 -0800 (PST) Received: by mail-oi0-f47.google.com with SMTP id v63so14727259oia.6 for ; Tue, 23 Dec 2014 10:20:25 -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 :content-transfer-encoding; bh=dqnnbiRjtjdDBMwgeyxz2nUSFMg5+ETOl2KW6y4YCqk=; b=kIhTox1tPCOciFleooihtLeRyPhdX++HIeDaJnO1kc96ssvfywQ9E36aww+uoI+csp c4uKjJr/9ZjN6oFtbwhaZ4WFpSVN/8oEP8s7iYW+SxEjSpZksR2Iqeri7u2RPFqlJKOE 4LccCx3sHjcQw+aWSjbhyd4zdoEnmKM3py9cFdsD/XKBWa2oYefAdzvGlPDZ2pWYHOpt 9rjYtMFvC4d4wxrC0z7qoREM+uFLzBGySs32Vz1MqBMOuTsox2GOLcmHz+ZcodggkfRC vw+nTppgPK40YnfOyFbwKIFVVIlq0zJ5M18A2euVN2g1F2wgZzR3fM54GbPlRxToGgEh 1FvQ== X-Gm-Message-State: ALoCoQnmxMKOxS1CE7za+Dg+GPkYKnrmTQLDVKBKTXDLSmZiuC8Kx0v0JUjDVqBhKi2HfW5WhbK0 MIME-Version: 1.0 X-Received: by 10.202.177.8 with SMTP id a8mr6713828oif.92.1419358824931; Tue, 23 Dec 2014 10:20:24 -0800 (PST) Received: by 10.76.71.228 with HTTP; Tue, 23 Dec 2014 10:20:24 -0800 (PST) In-Reply-To: <54995BD6.8000504@delignat-lavaud.fr> References: <5498DBCE.1070909@delignat-lavaud.fr> <54995BD6.8000504@delignat-lavaud.fr> Date: Tue, 23 Dec 2014 10:20:24 -0800 Message-ID: From: Brian Smith To: Antoine Delignat-Lavaud Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t_sxWRMWwR_5SmQsl4Id-Gmu1xs Cc: "" Subject: Re: [TLS] Remove signature algorithms from cipher suites 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, 23 Dec 2014 18:20:27 -0000 Antoine Delignat-Lavaud wrote: > Le 12/23/2014 7:07 AM, Brian Smith a =C3=A9crit : >> In theory, that sounds like a problem. Is it really a problem in >> practice, if we're not concerned about the specific case of RSA-PSS? On >> the other hand, nobody has ever seemed to want TLS_DHE_ECDSA_* cipher >> suites, so it doesn't seem like it caused any problem. > > Right now, it isn't a problem in practice, but it is not clear either tha= t > DSA (maybe in danger of being removed?), ECDSA and PKCS#1v1.5 are a good = set > of signature algorithms to commit to for the long run. Even in the short > term, a MAC-based signature scheme may be useful for PSK and resumption. OK. It seems like whether we need to solve the problem of whether cipher suites specify the signature algorithm *now* depends on whether we're going to standardize a replacement for ECDSA, PKCS#1, and DSA *now*. If we're not going to replace them now, then I don't think we need to solve this problem now (for 1.3). > It is currently impossible to get a non-RSA certificate signed by any pub= lic > CA (I know because I tried hard to get one). Only Google can concretely > deploy EC certs today. Hence, there's is currently NO alternative to RSA > signatures for authentication. I am surprised that you had so much trouble getting an ECC cert. Please ping me off-list and I will help you with that. I agree with the more general point that deploying ECDSA certificates is harder than it should be. That is a fixable problem. > By the way, it may be a good idea to recommend or mandate RFC6979-style > deterministic ECDSA signatures in TLS to prevent entropy-exhaustion attac= ks > against clients and servers. Off-topic though. I think it is a good idea to at least explore making RFC6979-style ECDSA mandatory for TLS 1.3 when ECDSA is used. I don't think it is off-topic though. If we did that, that would resolve the main problem with ECDSA, and that would reduce (perhaps eliminate) the need for RSA-PSS or other new/uncommon signature schemes, which would greatly reduce the motivation for making the change you propose. Cheers, Brian From nobody Tue Dec 23 13:24:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB731A9251 for ; Tue, 23 Dec 2014 13:24:22 -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 BJeUQj17oe2Z for ; Tue, 23 Dec 2014 13:24:21 -0800 (PST) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576C71A924B for ; Tue, 23 Dec 2014 13:24:18 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id g201so15339534oib.12 for ; Tue, 23 Dec 2014 13:24: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z4BGnDyo5KZDwBSXGbDAONENHL2ObsA0ilC1UNmDjxQ=; b=G/X+Wj1/OiFkSb/7v2BgWALdkjCD9fL8HhDtn6IOaKtRYxnHSDWccD7+bD0shFEHnK uGOGa8MpgAWXit+1+M31dBXOBfl66tjy182gaSjxdO17NevT8b2YLr0ozk/oS/bOPOXJ 1P5eTlgOZA0zRSoSczgmD86tpnsdYSzNJZxLVnkIo1VcmRtPxUk83R/Uv0gk0ek5bXSO YQLuBNHnvjQ2OsRsvruAVW/L078SuwHvaIicidne04d2ah4Hnfe6PCb2BKdtZACNaNxw 3Cmn9LMtyMVJVwmzvPASuAG88lNMqh+f8EIlhwz47rSaOmBa3l9wzOTA5uN0pO0UhdJJ Lwsg== X-Gm-Message-State: ALoCoQkTAaJvgwOUlz2nW+8DQKyP4BrL56jm0grXh0HiQmnwxeVKEVWl/OUgLGi57dNNW00V+mGS MIME-Version: 1.0 X-Received: by 10.182.97.226 with SMTP id ed2mr3154552obb.5.1419369857619; Tue, 23 Dec 2014 13:24:17 -0800 (PST) Received: by 10.76.71.228 with HTTP; Tue, 23 Dec 2014 13:24:17 -0800 (PST) In-Reply-To: <54946C20.6000404@fifthhorseman.net> References: <5488ACB1.6090201@fifthhorseman.net> <54946C20.6000404@fifthhorseman.net> Date: Tue, 23 Dec 2014 13:24:17 -0800 Message-ID: From: Brian Smith To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KWGEM2aniDC7l8atd42vTLqVhh0 Cc: "" Subject: Re: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:24:23 -0000 Daniel Kahn Gillmor wrote: > I've modified the ffdhe draft (as of -05) to include this guidance. > > https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-05 This looks good. However, I think this text actually belongs in draft-bmoeller-tls-falsestart, not draft-ietf-tls-negotiated-ff-dhe, because (a) it applies even when the negotiated ff-dhe mechanism isn't being used, (b) there are other tamperings besides ff-dhe that can cause a downgrade in DHE strength, and (c) I think it is best to keep all the false start stuff together when practical. I think you can drop "and MUST offer at least one of these in the initial handshake if they contemplate using the False Start protocol modification." What the client actually offers doesn't matter as far as False Start security is concerned; the only thing that matters is what the server receives. I think implementers will need more help in determining what is "cryptographically strong," such as a suggested minimum key sizes and suggested countermeasures against exploits targetting servers misconfigured in a way that would permit small subgroup attacks or other weak keys. For example, the recommendation could be to only do false start when the server uses parameters in the FF-DHE registry, which addresses both small keys and small subgroup attacks. I think that some mention of the attacker controlling the choice of ECDHE vs FF-DHE is also worth mentioning. Cheers, Brian From nobody Tue Dec 23 13:36:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497571A894C for ; Mon, 22 Dec 2014 16:45:40 -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 gEDjvEuRupOX for ; Mon, 22 Dec 2014 16:45:38 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7352F1A8934 for ; Mon, 22 Dec 2014 16:45:38 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id b13so4545635qcw.37 for ; Mon, 22 Dec 2014 16:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=97hdhfIeROBjGH1rzg+GMWUzem+q5jb1eqMPdBHmL4Y=; b=An76x52XAJr8kqxhKrdkz8mIi5bNHqTyPiGkbvOoSjRZ+en20bIiwhx7FxlWmS0S6X GdNtZXDl3STuISfKnFYwSjtvma+hP/yAl4740ZqmJHfChEDg4CAbHFL5M29VFeKH0KjM 44GBwWwTdpVbBlZMLEGIyRzAE2i5wBlViIgviL4DaTzE1r8eFUDLezo7SijIGBo3FS/A YR3vrD+OEuYqvctfpnhVNB76MXnI5TfTv38rdIiH6LcFilKg8gau4KavdKw/eYtUsjeu OM8G9+VrFV7tLaWdWb/7Qow6T8s9XZUlS0Rns7wPlS6UO6dki4+54JzNSk22QLgQxLEZ fECw== X-Received: by 10.224.73.135 with SMTP id q7mr41415467qaj.6.1419295537735; Mon, 22 Dec 2014 16:45:37 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id p49sm17666440qgp.30.2014.12.22.16.45.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 22 Dec 2014 16:45:37 -0800 (PST) From: Dave Garrett To: "TLS@ietf.org (tls@ietf.org)" Date: Mon, 22 Dec 2014 19:45:35 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201412221945.35644.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6hSL81h-8f9CZrGCDRin0s7eblk X-Mailman-Approved-At: Tue, 23 Dec 2014 13:36:10 -0800 Subject: [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, 23 Dec 2014 00:45:40 -0000 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. Eric Rescorla requested I post this to the list, though I would hope that at this point this would be a noncontroversial edit. The only functional difference between this language and RFC 6176 is that servers were still permitted to accept version 2 CLIENT-HELLO messages, though not actually negotiate the protocol. https://tools.ietf.org/html/rfc6176 There's no reason to maintain any backwards support here just for Internet Explorer 2.0 on Windows 3.1. Dave From nobody Tue Dec 23 13:37:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54DE1AC3BB for ; Tue, 23 Dec 2014 13:37:37 -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 7FwW4mgdBpKr for ; Tue, 23 Dec 2014 13:37:36 -0800 (PST) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366411AC3BA for ; Tue, 23 Dec 2014 13:37:36 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id u20so15348054oif.7 for ; Tue, 23 Dec 2014 13:37:35 -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=I0i53jytLCAmU9oQ4cN4JD0UMw1ERq3qL/2Esfdvojo=; b=EtPyboKNIHkiw7hvPNO8z9cqoOBMTpjTAL++AgWmLsZiGB951FuPG2HbeoINqcJI92 TQU/O6wQc9oE71reA2I5egJPNqot+KB/QRkY6d1GjE7uYyNzU/npZQ2iaBbUrJr4/8FL RfOLyXKhwEg2082cmrgktoNpdbsJlvJNJYrq1Gw19G90hyQ1D2Yw2swUcK3/kCZwdZ7d 5jnjQKKk7orgwvqMIrIMkQd3Ubk3As1wMBoM3XSNYrmJZzkCvO4BCAaue/T8ZPPwUtN5 jEp5Xk3znxsN3zLTpnyUNCmeFUbK5kF+XiHhDLswJcxOCFE+mfmFXWQ3Kw2T8WeNmVQj SsOQ== X-Gm-Message-State: ALoCoQn8fB9kcczsdnuhCDcAPSdjJBHvhVPHlDrVL34lszLWpIrLUe3gUrnDWFaUKFeHr6OtqHov MIME-Version: 1.0 X-Received: by 10.60.124.69 with SMTP id mg5mr17904822oeb.73.1419370655631; Tue, 23 Dec 2014 13:37:35 -0800 (PST) Received: by 10.76.71.228 with HTTP; Tue, 23 Dec 2014 13:37:35 -0800 (PST) Date: Tue, 23 Dec 2014 13:37:35 -0800 Message-ID: From: Brian Smith To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oC_OoLtn-tWuh_s9vjd9V-CVVYw Subject: [TLS] Symmetric cipher guidance in draft-bmoeller-tls-falsestart-01 (POODLE, BEAST) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 21:37:37 -0000 draft-bmoeller-tls-falsestart-01 section-6.1 says: Also, various ciphers specified for use with TLS are known to have cryptographic weaknesses regardless of key length (none of the ciphers specified in [RFC4492] and [RFC5246] can be recommended for use with False Start). I think it would be useful to think about, and note, why none of the RFC4492/RFC5246 ciphers are acceptable for False Start. The case against RC4 or weaker-than-AES CBC-mode ciphers is pretty clear, but the case against >=128-bit CBC-mode ciphers is less clear. For example, does POODLE or BEAST really matter for False Start? If an attacker tampered with the handshake, then the client's Finished message will be wrong, and the server (probably) won't process any application data that follows. Thus, it seems unlikely that POODLE is a problem for False Start. Similarly, how could False Start help an attacker succeed using the BEAST attack? Is there something I'm overlooking? Thanks, Brian From nobody Tue Dec 23 13:51:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317EE1A1B49 for ; Tue, 23 Dec 2014 13:51:45 -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 NPE3nezsnNpA for ; Tue, 23 Dec 2014 13:51:43 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AED91A86E7 for ; Tue, 23 Dec 2014 13:51:41 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so27165238obc.0 for ; Tue, 23 Dec 2014 13:51:40 -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=gquazLuEFFHjJHiZ6B+XMNQ6kFDag2pc7mt9HkALD3A=; b=aNCHQLw3+rJdMrTpWn6TfydzmCN6NpmftSfKGDog/tFbtXsyuqyHF6Rzl+GORMoMsA gLp7aMdImiczrcsjmKGeo1KdexEjmvV0KJx+874yzV8Im3z5XVDNCo5GlRFGTK0YH5pA QAH5FOs3Bi40ONuxgGELoZ0vkJb22l12Dh4z7Bpesng1PQm/n3V+wwq6SN1R+2kN9gS1 RRLVz5+MsK7XeMngMXzXc61iisIa8qEeChPtRkCj21iG4Qw+xMFqPdIIL47+4/DR1nHr gqyygId3nP27kGRA9f3/3QkWK6z+h11b5NV9RN+aqsffWKB4VfDpaXCU35WY5lmoKAQp /iNw== X-Gm-Message-State: ALoCoQksD0QVp3TPOMmg8Mbf8vgFNwWmwk87vm8+kgdgGlW4fQ492WXr1YW1skNiDeiE20Ep9IT7 MIME-Version: 1.0 X-Received: by 10.60.124.69 with SMTP id mg5mr17937976oeb.73.1419371500737; Tue, 23 Dec 2014 13:51:40 -0800 (PST) Received: by 10.76.71.228 with HTTP; Tue, 23 Dec 2014 13:51:40 -0800 (PST) In-Reply-To: <201412221945.35644.davemgarrett@gmail.com> References: <201412221945.35644.davemgarrett@gmail.com> Date: Tue, 23 Dec 2014 13:51:40 -0800 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uhEz35tk-72mZR66weg_Bs7rOVk 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: Tue, 23 Dec 2014 21:51:45 -0000 Dave Garrett wrote: > The PR replaces the section with a simple "MUST NOT" send or accept for TLS 1.3 > implementations. It would be best to have your change do exactly that, by shortening the remaining text to: Implementations MUST NOT send or accept an SSL version 2.0 compatible CLIENT-HELLO. Implementations MUST NOT send or accept TLS records with a version less than { 3, 0 }. Note the suggestion to use the term "records" instead of "messages". I think further changes can be made to tighten up the text regarding allowed record versions, but those changes are more open for debate. For example, we might say that the ClientHello's record version MUST be { 3, 1 } and that the version field in all other records MUST equal the negotiated version. But, again, this can be done on top of your changes. Cheers, Brian From nobody Tue Dec 23 22:15:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C731ACD07 for ; Tue, 23 Dec 2014 22:15:31 -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, 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 G0XZ70vPUtfe for ; Tue, 23 Dec 2014 22:15:25 -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 664F61ACD16 for ; Tue, 23 Dec 2014 22:15:23 -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=1419401724; x=1450937724; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=jrfeTyW0Y46Uu/qSYURnFYW+pc/9g1JCP+ParmvlAJI=; b=PdUqytSgEIphMg7rVc8dHTcwL3fA56lLly89qmBtsl0aXNbGzFwsneMA 6L5q1KxDiu0lFL/CxOKbY2eKB3KSmgOFPN6hWuyaQ5mAiCk12VXRDCmyn +yLvCRWrq8QVEYxA+zkdO382majKoNhNbvsW2xzebjGIjpLtgQ1nVGI/R 4=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="298269731" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Dec 2014 19:15:20 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 24 Dec 2014 19:15:21 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis Thread-Index: AdAfQP52ORFNZC22T3iD1RfIzllkiA== Date: Wed, 24 Dec 2014 06:15:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@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: http://mailarchive.ietf.org/arch/msg/tls/_plzHHFDU3kbslPi0_LG6kx4G1M Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 06:15:32 -0000 Michael Clark writes:=0A= =0A= >I have been doing some independent research on TLS AEAD ciphers and decide= d=0A= >to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM=0A= =0A= If you're going to look at these, what about also looking at encrypt-then-M= AC,=0A= which is another AEAD mechanism?=0A= =0A= Peter.=0A= From nobody Tue Dec 23 22:40:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12081ACD07 for ; Tue, 23 Dec 2014 22:40:21 -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 dp5n8vgNvJlt for ; Tue, 23 Dec 2014 22:40:20 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B9D1ACCE4 for ; Tue, 23 Dec 2014 22:40:20 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so12692487wid.17 for ; Tue, 23 Dec 2014 22:40:19 -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=PzHZh0dvWlbBc2aP5eA71gTRwwaH/KGn0fA2ZH8ptnE=; b=QK1HF1zMileBoASzZ1p7tcp21F8ZkuhBFSSRZkz4APvJY3n3ogYVBxZd3e6fELGQw6 gxnykoNOYjsPtwAyLFUA5aoCch5lWPh/KKAihIXNcpm2UiR01qr4y+uRnkawSNjwlLYJ HqrQ4RsuEmP2mnm8achHAKiMESqlMTl2eo0aLH0MIUEyWKAQ7QXGSQmeWJBIs44zw/M2 35qFsNrMqrLfT6KBkpf+zeG23meOGYUaHqtzzqx5IsS8ZAPaBm/rkVKqgeh32XLVvor4 faBwCwZaQz/a3bnlJlnUs7JMw2qMKlMZCbyB09zl/cQFXvUQ8AFdQrDlHkODizfyos1c jVJg== X-Received: by 10.194.201.137 with SMTP id ka9mr61641824wjc.66.1419403218986; Tue, 23 Dec 2014 22:40:18 -0800 (PST) Received: from yoavs-mbp.mshome.net ([109.253.158.55]) by mx.google.com with ESMTPSA id gl5sm23342966wib.0.2014.12.23.22.40.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Dec 2014 22:40:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <201412221945.35644.davemgarrett@gmail.com> Date: Wed, 24 Dec 2014 08:40:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201412221945.35644.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZFRQRm2kK9QIhYcawEyvQJqHje8 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, 24 Dec 2014 06:40:22 -0000 >=20 > There's no reason to maintain any backwards support here just for = Internet=20 > Explorer 2.0 on Windows 3.1. >=20 I=E2=80=99m 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=E2=80=99s best = efforts, there is still a substantial but diminishing install base of = XP. It=E2=80=99s fine for us to break compatibility with these clients, but = let=E2=80=99s not pretend it=E2=80=99s some ancient technology that = doesn=E2=80=99t exist in the market anymore. Yoav =20= From nobody Tue Dec 23 23:03:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E391ACCE6 for ; Tue, 23 Dec 2014 23:03:08 -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 PtP4cMHXvDcz for ; Tue, 23 Dec 2014 23:02:56 -0800 (PST) Received: from BLU004-OMC1S27.hotmail.com (blu004-omc1s27.hotmail.com [65.55.116.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAAB1ACD3C for ; Tue, 23 Dec 2014 23:02:55 -0800 (PST) Received: from BLU177-W51 ([65.55.116.7]) by BLU004-OMC1S27.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 23 Dec 2014 23:02:54 -0800 X-TMN: [9TSERvoiZgjVGLRZTLBD8Ankv2bK8THi] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Yoav Nir , Dave Garrett Date: Tue, 23 Dec 2014 23:02:54 -0800 Importance: Normal In-Reply-To: References: <201412221945.35644.davemgarrett@gmail.com>, Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Dec 2014 07:02:54.0824 (UTC) FILETIME=[A3FE5E80:01D01F47] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2NQPz2WRqpFJwJl2DUasqZ5wVtk 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, 24 Dec 2014 07:03:09 -0000 >>=0A= >> There's no reason to maintain any backwards support here just for Intern= et=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 hyperbole.= The issue is with Internet Explorer 6 on Windows XP=2C which still exists= =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 TL= S 1.2.=0A= I don't think the old SSLv2 ClientHello supports extensions anyway.=0A= =0A= Yuhong Bao = From nobody Wed Dec 24 00:18:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4DB1ACD64 for ; Wed, 24 Dec 2014 00:18:28 -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 UeNuzG3sJ1pD for ; Wed, 24 Dec 2014 00:18:27 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F3D1ACD5D for ; Wed, 24 Dec 2014 00:18:27 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so12910917wiw.1 for ; Wed, 24 Dec 2014 00:18:26 -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=c9kgcfXf+RZqVh6vVHv0T6Xv3MxZvt4GFnKj6XrBpTc=; b=hNIz8yy6/0bSK/ayODW6Hxkq+IWaXWNgSfFwquvM+zNOGay6g5+qLg4mBbqiPoggMw xNrHaEk/kKnTh17/glJeguFdvL7y+jtMcczzNAODxnAXUkMaI1cT0K+IklVp8qRz4qbq hqCSS4ddpF1U/0+fzZYshaEt/gaOfE9+hx0+AEI+cnCZcwUOdDQ521r4JTmkDA5u4Pvd MwwnFLgNmdfM9YQoPWsaWmxy9bJ9Kd0F+HpjKIHwUEm/BuBFw7W4FfBYQsWcu9vL9e9V JBsG4Tx/TsLVZP2viZ8RCkhETLLD+uGbF81JRB4XpqMJnS2eLGXI6P8ZsDaMA7IeUE/j RZbA== X-Received: by 10.180.206.229 with SMTP id lr5mr49125143wic.74.1419409106176; Wed, 24 Dec 2014 00:18:26 -0800 (PST) Received: from [172.24.249.55] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id 18sm30666748wjr.46.2014.12.24.00.18.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Dec 2014 00:18:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <201412240223.46107.davemgarrett@gmail.com> Date: Wed, 24 Dec 2014 10:18:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201412221945.35644.davemgarrett@gmail.com> <201412240223.46107.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Dg9pntazeCfzewOvzyaMdYTHXf8 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, 24 Dec 2014 08:18:29 -0000 > On Dec 24, 2014, at 9:23 AM, Dave Garrett = wrote: >=20 > On Wednesday, December 24, 2014 01:40:10 am you wrote: >>> There's no reason to maintain any backwards support here just for >>> Internet Explorer 2.0 on Windows 3.1. >>=20 >> I=E2=80=99m 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=E2=80=99s best efforts, there is still = a >> substantial but diminishing install base of XP. >=20 > I was not aware Microsoft used an SSL2 ClientHello for SSL3. Thanks = for pointing=20 > that out. Is it not capable of sending an SSL3/TLS Hello at all? If it = were=20 > properly configured to enable TLS1 and disable SSL2/3, would it send = the proper=20 > TLS compatible Hello? (Microsoft really should've pushed an XP update = to flip=20 > that switch years ago) Yes. =46rom the control panel you clicked =E2=80=9CInternet Options=E2=80=9D= , and that had a tab for security, but it wasn=E2=80=99t there. Instead, = it was in the tab for advanced, which had a bunch of options, some = related to security, but it was under =E2=80=9Cencryption=E2=80=9D, not = security. There were checkboxes for support of SSLv2, SSLv3, and TLS = 1.0. By default the SSLv2 and SSLv3 checkboxes were checked, while the = TLS 1.0 box was unchecked. To get rid of the SSLv2 ClientHello you had = to uncheck the SSLv2. I don=E2=80=99t think the kind of people who still = use Windows XP are the same ones who would go into the settings to = disable SSLv2.=20 I might have some of the details wrong. It=E2=80=99s been a few years = since I last set Internet Options on a Windows XP box. Yoav From nobody Wed Dec 24 00:59:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15F01AD002 for ; Wed, 24 Dec 2014 00:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.068 X-Spam-Level: X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 VfkuUeOIkf0m for ; Wed, 24 Dec 2014 00:59:27 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 DB2AA1ACFF6 for ; Wed, 24 Dec 2014 00:59:26 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBO9K6Yv009938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Dec 2014 09:20:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419412813; bh=CMZfkKhtgqBLrPihZjlBrJmF2V0FLlz6QzDhGyeAvZE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gQBfn3A7iqUahWtzcAmTTcN93AHU2mkzIwKvxhxa0PaWAasMqW3Iu0Lro0FRUzPuA zHGgoZV1AgH+qzMvYnuRaX5Tb0+MgZkgQOOtu/gBJdMD1yNySopOhB5it0vxnsOVj6 hoz2os+YA5jsIORUURskTGNzVOb5PfptD2hRRmRQ= Message-ID: <549A804E.6080408@metaparadigm.com> Date: Wed, 24 Dec 2014 16:58:54 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Inn4QNslDj-f--eNGxFdR-XeorM Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 08:59:29 -0000 On 24/12/14 2:15 pm, Peter Gutmann wrote: > Michael Clark writes: > >> I have been doing some independent research on TLS AEAD ciphers and decided >> to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM > > If you're going to look at these, what about also looking at encrypt-then-MAC, > which is another AEAD mechanism? What prompted me to do the analysis of AEAD ciphers was this: https://www.imperialviolet.org/2014/12/08/poodleagain.html "This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken" This statement isn't strictly true. Agreed. CBC mode with AD and MAC is a form of AEAD. I am aware CBC mode was vulnerable due to implementation bugs in the handling of padding not just in SSLv3.0 but also more recently in a particular TLS implementation. However an encrypt-then-MAC AD plus cipher text (with arbitrary MAC) is not strictly equivalent to an AEAD cipher both from a layering perspective and from the collision proof of cipher based MACs and design respect to padding; such as AEAD_AES_EAX and AEAD_CHACHA20_POLY1305. AEAD_AES_GCM implementations had padding bugs too (Fragility of AES-GCM, Gueron). I guess it's a layering issue and a matter of pushing AEAD into the cipher. I understand there is a difference in Cipher based MACs and PRF based MACs which is the difference between birthday attacks and reversing cipher rounds vs finding collisions. Poly1305 has a similar proof to EAX as it is a cipher based MAC, originally AES and now CHACHA20 http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 >From a protocol design perspective (irrespective of TLS) it would be desirable to having AEAD at the one layer as it would allow for specification and implementation simplicity and symmetry, rather than have it duplicated at the TLS implementation layer for some ciphers and not for AEAD ciphers e.g. AEAD_AES_GCM, AEAD_AES_CCM, AEAD_AES_EAX and AEAD_CHACHA20_POLY1305, etc. There is no reason why TLS implementations couldn't support TLSv1.2 to maintain CBC mode and just have AEAD ciphers. If TLSv1.3 only supported AEAD ciphers then a TLSv1.3 implementation would be simpler. Simplicity and composability between layers is a good property. I also saw the post about removing the MAC from the TLS cipher names as they are now included in "signature_algorithms" since TLSv1.2. This makes a lot of sense. I am aware some of the earlier TLS "features" were vestiges of "export controls" i.e. mechanisms to lower cipher strength based on the the certificate. I remember the days of SGC... However that brings me back to the point before about all of the current AEAD ciphers have an 128 bit auth tag (due in part to their proof of non-collision as cipher-based MACs). I don't think this is a major issue due to the nonce lifespan; except for highly parallelizable AEAD schemes such as AEAD_AES_GCM (for reasons I noted). Given proof of no key-independent collisions, then the bit strength of cipher based MACs must be higher than one-way hashes without no-collision proofs. If I were to choose, I'd go for symmetry and start thinking about 256 and 512 bit blocks, so the AEAD tag would be extended this way. But that is futures. We don't have the ciphers. These all have 128 bit tags: AEAD_AES_GCM AEAD_AES_CCM AEAD_AES_EAX AEAD_CHACHA20_POLY1305 Then we couldn't use SHA256 and SHA384 to mitigate attacks on data integrity (tag collisions) in AAED ciphers. In this case the super-symmetry would be to allow CBC style MAC optional on AEAD ciphers and mandatory on non-AEAD ciphers like CBC. AES_256_GCM + SHA256 would mitigate the integrity risk of 128-bit tags. Thanks for prompting the thought. AES_256_GCM 128-bit tags may be more vulnerable to integrity attacks (bit errors) than AES_256_CBC with SHA384 MACs. These would both have 384 bits tags (with a super symmetry design): AES_256_GCM + SHA256 AES_256_CBC + SHA384 Michael. From nobody Wed Dec 24 05:13:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716781ACD9C for ; Wed, 24 Dec 2014 05:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 E5A1oqFEmTl3 for ; Wed, 24 Dec 2014 05:13:06 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 0B2A01ACDB4 for ; Wed, 24 Dec 2014 05:12:58 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBODXrPE010477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Dec 2014 13:33:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419428039; bh=zmFyxn17u9zab0odQIPwuWbV2L+QJd0uQ7RF/1l+a30=; h=Date:From:To:Subject:References:In-Reply-To:From; b=a2LE3MdfyljUEJMMMdGIdslRe8mBO709RECtmkvnbJ+0Q41nL293S74r9V4+jzoOf cXuIlulUTKErafcaSjgD58yAyG1qOxZGd1tcqquMJ2/A5GDa1DmxX268u+u2lLc/TI VIP+P3ej1kTFmvdUcqL2gNn/GQFw8myT52xcL8jI= Message-ID: <549ABBC9.6070406@metaparadigm.com> Date: Wed, 24 Dec 2014 21:12:41 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> <549A804E.6080408@metaparadigm.com> In-Reply-To: <549A804E.6080408@metaparadigm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UWOi04XvwM5F0OvtUw6yy_BY88M Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 13:13:08 -0000 On 24/12/14 4:58 pm, Michael Clark wrote: > On 24/12/14 2:15 pm, Peter Gutmann wrote: >> Michael Clark writes: >> >>> I have been doing some independent research on TLS AEAD ciphers and decided >>> to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM >> >> If you're going to look at these, what about also looking at encrypt-then-MAC, >> which is another AEAD mechanism? CBC is MAC-then-encrypt in TLS1.2, however encrypt-then-MAC is the current best practice? encrypt-then-MAC allows you to verify message integrity before decryption and abort sessions after a (small) error count to mitigate any brute forcing over the wire (without cost of decryption). With MAC-then-encrypt you need to decrypt before you can verify the MAC. Also from TLSv1.2 6.2.3.3. "No MAC key is used." with AEAD. If you replaced MAC-then-encrypt with encrypt-then-MAC in TLSv1.3 then you could alter the behavior of the new encrypt-then-MAC to make it work for non AEAD ciphers like CBC as well to (optionally) augment the message authentication bits for AEAD ciphers that are currently limited to 128 bits. I'm not talking about the common case where AES_128_GCM and 128-bit tags is a good start for SSL everywhere. I'm talking about cases where the overhead of 3 passes may be acceptable. Also consider this a pencil sketch. Of course servers that want to maintain backwards compatibility would need to keep encrypt then Mac. These are just ideas. A TLSv1.3 ClientHello and ServerHello extensions could advertise something like this this: enum { AuthBits128, AuthBits256, AuthBits384, AuthBits512} MessageAuthenticationBits; struct { MessageAuthenticationBits minimum_authentication_bits; MessageAuthenticationBits preferred_authentication_bits; } MessageAuthSecurity; The client and server choose a MacAlgorithm based on the combination of the negotiated cipher's authentication tag bits (0 bits for non AEAD ciphers) and the bits of the mac algorithms present in SecurityParameters.mac_algorithms. A (null) MacAlgorithm may be chosen if the cipher's AEAD tag bits meets the minimum or preferred authentication bits or a suitable MacAlgorithm could be chosen to provide the remaining bits. For non AEAD ciphers a MacAlgorithm would be chosen that matches the minimum or preferred authentication bits. The policy over the the choice of minimum or preferred message authentication bits would need to be considered. A negotiated MessageAuthenticationBits message_authentication_bits could be added to the TLSv1.3 SecurityParameters along with MACAlgorithm mac_algorithm which may or may not be (null) with an AEAD cipher. If the client or server wanted 128 message authentication bits: * AEAD cipher with 128 bit auth tag, (null) MacAlgorithm and no encrypt-then-MAC at the TLS layer. AD would be be passed to the AEAD cipher. * non AEAD cipher, hmac_sha128 with encrypt-then-MAC at the TLS layer. AD would be prefixed in the MAC in the TLS layer encrypt-then-MAC when a non AEAD cipher was used (currently the MAC is a suffixed in the MAC-then-encrypt scheme in TLSv1.2). If the client or server wanted 256 message authentication bits * AEAD cipher with 128 bit auth tag, hmac_sha128 MacAlgorithm with encrypt-then-MAC at the TLS layer. AD would be be passed to the AEAD cipher. * non AEAD cipher, hmac_sha256 with encrypt-then-MAC at the TLS layer. AD would be prefixed in the MAC in the TLS layer encrypt-then-MAC when a non AEAD cipher was used (currently the MAC is a suffixed in the MAC-then-encrypt scheme in TLSv1.2). This is based on the observation that SHA1 is being phased out; however it may well be that based on the nonce lifetime this is not needed. That said some applications may like the idea of having Cipher based MAC in an AEAD cipher combined with a PRF based MAC as they both have different properties And when I refer to the collision properties of Cipher based MACs I'm referring to one block of course (the size of the tag). Michael. From nobody Wed Dec 24 07:17:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C851A8A7C for ; Wed, 24 Dec 2014 07:17:47 -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 IWlQvavZ48t7 for ; Wed, 24 Dec 2014 07:17:46 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EFDA91A8A7A for ; Wed, 24 Dec 2014 07:17:45 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 7B3F09A400D for ; Wed, 24 Dec 2014 10:17:35 -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 zhr7okQGXDLK for ; Wed, 24 Dec 2014 10:17:14 -0500 (EST) Received: from [192.168.2.108] (pool-96-255-26-251.washdc.fios.verizon.net [96.255.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 33CF99A4001 for ; Wed, 24 Dec 2014 10:17:14 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <54961200.6030506@metaparadigm.com> Date: Wed, 24 Dec 2014 10:17:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <05961945-E0EE-4842-B051-BEEE892D0C66@vigilsec.com> References: <549538E5.7050109@metaparadigm.com> <5495BE11.4040703@iki.fi> <54961200.6030506@metaparadigm.com> To: IETF TLS X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mM9Tg_aj4o3IAHVcZ-oi5Hk_Iyk Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 15:17:47 -0000 The folks doing the DTLS profile for low-end devices have chosen AES-CCM = because they have hardware support for it. I think we should include it = to promote interoperability. Russ On Dec 20, 2014, at 7:19 PM, Michael Clark wrote: > On 21/12/14 2:21 am, Tapio Sokura wrote: >> Hello, >>=20 >> On 20.12.2014 10:52, Michael Clark wrote: >>> CipherSuite TLS_DHE_DSS_WITH_AES_128_EAX_SHA256 >>> CipherSuite TLS_DHE_DSS_WITH_AES_256_EAX_SHA384 >>> CipherSuite TLS_ECDHE_DSS_WITH_AES_128_EAX_SHA256 >>> CipherSuite TLS_ECDHE_DSS_WITH_AES_256_EAX_SHA384 >>> CipherSuite TLS_DHE_DSS_WITH_AES_128_CCM_SHA256 >>> CipherSuite TLS_DHE_DSS_WITH_AES_256_CCM_SHA384 >>> CipherSuite TLS_ECDHE_DSS_WITH_AES_128_CCM_SHA256 >>> CipherSuite TLS_ECDHE_DSS_WITH_AES_256_CCM_SHA384 >> A bit off-topic on the actual question, but: Is DSS used anymore? = Should >> these be ECDSA instead? >=20 > Thanks. Yes. I did mean ECDSA, the eliptic curve variant of DSA (DSS). > It was a mistake on my part. >=20 > Someone mentioned off list mentioned the AEAD ChaCha20-Poly1305 draft, > however I note the authenticator is still 16 bytes (128 bits). I had > seen the draft but wasn't sure if it was going to be included in = TLSv1.3. >=20 > It occurred to me that a (perhaps not fair) comparison would be with > using MD5 which is 128 bits. MD5 has collisions. GHASH finite field = and > the cipher based MACS (including Poly1305) should be safe in this = regard > due to their construction. My understanding is that cipher based MACS > are vulnerable to attacks that reverse rounds of the cipher after a > certain number of texts have been seen (birthday attack). The fact = that > the nonce has a short lifetime probably makes this intractible however = I > began wondering about the 'designed in' lower entropy in GCM (IV = suffix > on first block 32-bits starting at 0x00000001 versus incrementing the > whole IV and preserving entropy). Both this; and properties of the > parallelizability GHASH construction. The IV construction effectively > means only 96 bits need to be brute forced to forge an authenticator > (unless in practice a random initial counter was used) as we know the > counter for each block. It seems to be a designed in weakness along = with > excellent parallelizability. CCM and EAX are not exploitable in this = manner. >=20 > The main point was besides eavesdropping potential, was the ability of > an attacker to inject random bit errors by finding authenticator > collisions; i.e. message integrity; and also the parallelizability of > GCM. Parallelizability lowering the barrier to anyone with sufficient > resources. AES-GCM and AES-CCM are the only two implemented AEAD > ciphers. The later is not present in openssl, boringssl, libressl = (last > time I looked). >=20 > The thought that occurred to me was the idea of having a 256-bit > authenticator with a 256-bit cipher. In practice we use 256-bit and > 384-bit MACs. It's whether we consider the AEAD MAC as an "error > correction code" or a "cryptographic MAC". People are widely deploying > 256-bit and 384-bit MACs in areas where a "cryptographic MAC" is > required. I guess it is also dependent on the time window (which in = TLS > is short) however someone with acres/hectares of computers could make = a > DHT (Distributed Hash Table). Drives are cheap and DHTs are fast for > vast amounts of data. Reasoning is 32 bits lost entropy, n bits in > storage, m bits computed online (from looking at table based GHASH). >=20 > OMAC1/CMAC is limited to the block size of the underlying cipher which > is 128 bits even with AES-256. EAX just seems simpler than CCM. >=20 > Just thought I would question the convention and established = thought... >=20 > Cheers, > Michael. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Dec 24 10:22:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B5B1A1A13 for ; Wed, 24 Dec 2014 10:22:48 -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 8KSiROocSEjT for ; Wed, 24 Dec 2014 10:22:46 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7E71A1A29 for ; Wed, 24 Dec 2014 10:22:39 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so14186338wid.3 for ; Wed, 24 Dec 2014 10:22:38 -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=bAJ477BmHIW3QYx4Nxt+ukC1PYIbigJ3lVV/xCF7Pus=; b=NvaX9wXiSrvn4tyYATcnZXYlz+ZrviHqdQ1bJhLya0WbffvnqnHZpgJ8zABB1Yjmhx Fj5Y8aGJvrOCLnbcuJBiNtaZqC58M4Zg0UiM9JpQiUSiNPDtnd1QMqEPjUBLtLuto8n7 gBwJz1wA5pRW9fR1Tn7QXn28coioQowR94RQHCxPd8xKLSQCPDAuJwbvOke9necv8Sse L6xwCKWZ2VaPYT72zq6NkwayQhrxAEgnLhfKTgrOE7uJ0v5IgB7BP1xoqfu1g4/vipjU GXlOXcIoF4mUwPsA2+hvylrHswGVFZVph6xhc5kOyzuQ5YOVpSl/47VgZrKC4ufXR+KS gVzw== X-Gm-Message-State: ALoCoQkFTwRtzcfGWwPfMcVDMwwvEL1T6SzZTjpT2IRfiLMRtjLT4ZlEj+7ztT+wsTDKU/ARj3Jp X-Received: by 10.180.9.241 with SMTP id d17mr54094766wib.13.1419445358457; Wed, 24 Dec 2014 10:22:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 24 Dec 2014 10:21:58 -0800 (PST) In-Reply-To: <20141223143719.GB11149@LK-Perkele-VII> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 24 Dec 2014 10:21:58 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c2a45a5e8c51050afa60a1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_b9rxUQvEX1XbY9Y5OEXYtQMFhw Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 18:22:48 -0000 --001a11c2a45a5e8c51050afa60a1 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 23, 2014 at 6:37 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Mon, Dec 22, 2014 at 01:38:36PM -0800, Eric Rescorla wrote: > > Adam updated his PR to sign the prefix concatenated with the handshake > > hashes, which makes it easier to have a single hash context. > > > > https://github.com/tlswg/tls13-spec/pull/100 > > > > I haven't seen any objections to this idea, so I'll merge this on > Wednesday > > unless I hear an objection before then. > > > > Any reason not to fix the hash function per-ciphersuite, so servers > and clients don't have to run multiple hashes in parrallel? > The client and server may want to use different signature algorithms. -Ekr > Suitable hash function is required by the THS fix anyway, and one > could just reuse that context if one has implementation capable of > intermediate hashes or hash context cloning. > > If one is worried about cross-hash attacks (even if all hashes should > be strong), stick the ciphersuite ID (which fixes the hash) into > data to be signed. > > > -Ilari > --001a11c2a45a5e8c51050afa60a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 23, 2014 at 6:37 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= span class=3D"">On Mon, Dec 22, 2014 at 01:38:36PM -0800, Eric Rescorla wro= te:
> Adam updated his PR to sign the prefix concatenated with the handshake=
> hashes, which makes it easier to have a single hash context.
>
> https://github.com/tlswg/tls13-spec/pull/100
>
> I haven't seen any objections to this idea, so I'll merge this= on Wednesday
> unless I hear an objection before then.
>

Any reason not to fix the hash function per-ciphersuite, so servers<= br> and clients don't have to run multiple hashes in parrallel?

The client and server may want to use different si= gnature algorithms.

-Ekr
=C2=A0
Suitable hash function is required by the THS fix anyway, and one
could just reuse that context if one has implementation capable of
intermediate hashes or hash context cloning.

If one is worried about cross-hash attacks (even if all hashes should
be strong), stick the ciphersuite ID (which fixes the hash) into
data to be signed.


-Ilari

--001a11c2a45a5e8c51050afa60a1-- From nobody Wed Dec 24 10:30:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28021A1A1D for ; Wed, 24 Dec 2014 10:30:18 -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 wsFwB-IsiD19 for ; Wed, 24 Dec 2014 10:30:15 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057641A09C9 for ; Wed, 24 Dec 2014 10:30:15 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so11920191wgh.2 for ; Wed, 24 Dec 2014 10:30:13 -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=WNCpCXxTYAP8GUoDkHh/vPaO0yabYOiHFw9XnMsbtLQ=; b=OElbJJYBnau42MyuyxO8kVJYflvy0cVsFFYKWmxPShfn4F6gTDNIllnabAywQNr6nY PxtFxyenSZncbP40Tm+eUB926gIEKvr1xT9DeOpzoj5V4ONQWxNSQDjwCKe69WhSmRHf EDKWAK9YTkU4saz0m20EgyptAhjKJMNY3M/Ez8e+0ZQ2SDkj8GxOJ1taumDk1spbUaoD HzoF0AEbRpn1Unsj3HeAICMrnO53Tx4+8U28P0PxKuB7RmQnjsHKB4bYMQ3tsqACbejw xKO9AiyyyaqcrWfNco+RxZe3FK3FVj/ppCFNPOJYH57OhS/IGLXyXKM4fkWabSnGwsMc FB8Q== X-Gm-Message-State: ALoCoQnttBHX9ykVHaWAfRzoXI6DZ2A2HDUY5nK+THXJaUBvxwGqBEf4MrW29Jm2K9kCWiX+iT0T X-Received: by 10.194.2.105 with SMTP id 9mr66438539wjt.115.1419445813796; Wed, 24 Dec 2014 10:30:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 24 Dec 2014 10:29:33 -0800 (PST) In-Reply-To: <20141223142648.GA11149@LK-Perkele-VII> References: <20141223142648.GA11149@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 24 Dec 2014 10:29:33 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b3440ee82773f050afa7bf9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GeIERmd1Fq06jwSan-gUY1QMRqg Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 18:30:18 -0000 --047d7b3440ee82773f050afa7bf9 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 23, 2014 at 6:26 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Mon, Dec 22, 2014 at 01:33:13PM -0800, Eric Rescorla wrote: > > I've posted an updated PR at: > > > > https://github.com/tlswg/tls13-spec/pull/89 > > > > Note that I did not restore the ChangeCipherSpec message as my sense of > > the WG discussion and private conversations was that people preferred to > > have it gone. If you feel strongly about this change one way or the > other, > > and haven't already posted to the list about it, please do so now, as I'd > > like to resolve this and merge this PR this week. > > > > (General philosophical note: I'm in favor of more complicated protocol if: > - It fixes something that is just plain nasty to analyze, or > - It causes bad implementations to break fast instead of being security > timebombs.) > > > Regarding CCS removal, I'm very much in favor. > > > Reading through this, some comments: > > "At this point, the handshake is complete, and the client and server may > exchange application layer data, which is protected using a new set of > keys derived from both the premaster secret and the handshake transcript > (see {{I-D.ietf-tls-session-hash}} for the security rationale for this.)" > > AFAIK, I-D.ietf-tls-session-hash doesn't really contain security rationale > for this. It only has security rationale for hashing exchange keys (which > are included in the first keying anyway) and says about including > certificates (paraprhased): "Compliant with NIST recommediations" and > "SSH does this" (actually, it only does that for server key, not client > key). > > Now, if EncryptedExtensions contains extensions that twiddle with some > critical parameters, there is very much reason to rekey after that. > In conversations with the INRIA guys, the general consensus seemed to be that hashing more was more conservative. I'll work with them to get some text around this either here or in the session hash draft. > "[[OPEN ISSUE: Should we restart the handshake hash? > https://github.com/tlswg/tls13-spec/issues/104.]]" > > I regard restarting the hashes as very dangerous (not that I think that > the whole HRR is a good idea, but I don't say more about that). > The expectation in the current draft is that you do not restart the handshake hash, but I know there are different opinions about that, hence the open issue. Let's discuss this separately, since the only change in this area in this PR is to add the issue marker. "This master secret value is used to generate the record protection > keys used for the handshake, as described in {{key-calculation}}. It is > also used with TLS Exporters {{RFC5705}}." > > Wasn't there an idea for giving TLS Exporter its own master secret? > That would stop applications from exporting important system keys. I suggested that, but upon reconsideration it seemed a bit over-complicated. What's the threat model you have in mind here? > "If the server does not request client authentication, the master > secret can be computed at the time that the server sends its Finished, > thus allowing the server to send traffic on its first flight (see > [TODO] for security considerations on this practice.) If the server > requests client authentication, this secret can be computed after the > client's Certificate and CertificateVerify have been sent, or, if the > client refuses client authentication, after the client's empty > Certificate message has been sent." > > Server can't send data on first flight (to anonymous recipient) if > it requests client authentication? E.g. HTTP/2 settings blocks, > protocol banners or various other protocol capability negotiations. > That's correct. This is obviously not ideal but the alternative with this design is to have an even more complicated key schedule. The idea behind PR 95 (https://github.com/tlswg/tls13-spec/pull/95) is to address this, though that's of course not the only way. What are your thoughts here? > Obviously, generating the resumption premaster secret has to wait for > client finished (otherwise one can run into trouble with just > transport glitches, no attackers required). > > > Looks like for the resume case, the ClientHello and ServerHello are > hashed into keys. I think this should be done (I don't se attacks > otherwise, but that doesn't mean there could not be one... This > is another of those "I don't want to analyze that" places). If I am reading this correctly, you are happy with this piece, or are you suggesting a change? Best, -Ekr --047d7b3440ee82773f050afa7bf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 23, 2014 at 6:26 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
On Mon, Dec 22, 2014 at 01:33:13PM -0800, Eric Rescorla wrote:
> I've posted an updated PR at:
>
> https://github.com/tlswg/tls13-spec/pull/89
>
> Note that I did not restore the ChangeCipherSpec message as my sense o= f
> the WG discussion and private conversations was that people preferred = to
> have it gone. If you feel strongly about this change one way or the ot= her,
> and haven't already posted to the list about it, please do so now,= as I'd
> like to resolve this and merge this PR this week.
>

(General philosophical note: I'm in favor of more complicated pr= otocol if:
- It fixes something that is just plain nasty to analyze, or
- It causes bad implementations to break fast instead of being security
timebombs.)


Regarding CCS removal, I'm very much in favor.


Reading through this, some comments:

"At this point, the handshake is complete, and the client and server m= ay
exchange application layer data, which is protected using a new set of
keys derived from both the premaster secret and the handshake transcript (see {{I-D.ietf-tls-session-hash}} for the security rationale for this.)&qu= ot;

AFAIK, I-D.ietf-tls-session-hash doesn't really contain security ration= ale
for this. It only has security rationale for hashing exchange keys (which are included in the first keying anyway) and says about including
certificates (paraprhased): "Compliant with NIST recommediations"= and
"SSH does this" (actually, it only does that for server key, not = client
key).

Now, if EncryptedExtensions contains extensions that twiddle with some
critical parameters, there is very much reason to rekey after that.

In conversations with the INRIA guys, the gene= ral consensus seemed to
be that hashing more was more conservativ= e. I'll work with them to get
some text around this either he= re or in the session hash draft.


= =C2=A0
"[[OPEN ISSUE: Should we restart the handshake hash?
https://github.com/tlswg/tls13-spec/issues/104.]]"


=C2=A0
I regard restarting the hashes as very dangerous (not that I think that
the whole HRR is a good idea, but I don't say more about that).

The expectation in the current draft is that y= ou do not restart the handshake
hash, but I know there are differ= ent opinions about that, hence the open
issue. Let's discuss = this separately, since the only change in this area
in this PR is= to add the issue marker.


"This master secret value is used to generate the record protection keys used for the handshake, as described in {{key-calculation}}. It is
also used with TLS Exporters {{RFC5705}}."

Wasn't there an idea for giving TLS Exporter its own master secret?
=

That would stop applications from exporting important system keys.

I suggested that, but =C2=A0upon reconsiderati= on it seemed a bit
over-complicated. What's the threat model = you have in mind
here?


<= div>=C2=A0
"If the server does not request client authentication, the master
secret can be computed at the time that the server sends its Finished,
thus allowing the server to send traffic on its first flight (see
[TODO] for security considerations on this practice.) If the server
requests client authentication, this secret can be computed after the
client's Certificate and CertificateVerify have been sent, or, if the client refuses client authentication, after the client's empty
Certificate message has been sent."

Server can't send data on first flight (to anonymous recipient) if
it requests client authentication? E.g. HTTP/2 settings blocks,
protocol banners or various other protocol capability negotiations.

That's correct. This is obviously not idea= l but the alternative with this
design is to have an even more co= mplicated key schedule. The idea
address this, though that's of course not t= he only way. What are
your thoughts here?

=C2=A0
Obviously, generating the resumption premaster secret has to wait for
client finished (otherwise one can run into trouble with just
transport glitches, no attackers required).


Looks like for the resume case, the ClientHello and ServerHello are
hashed into keys. I think this should be done (I don't se attacks
otherwise, but that doesn't mean there could not be one... This
is another of those "I don't want to analyze that" places).

If I am reading this correctly, you are happ= y with this piece, or are you
suggesting a change?

=
Best,
-Ekr


--047d7b3440ee82773f050afa7bf9-- From nobody Wed Dec 24 10:50:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C571A1A39 for ; Wed, 24 Dec 2014 10:50:36 -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 nc9OMHZhp6EL for ; Wed, 24 Dec 2014 10:50:34 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C311A1A5B for ; Wed, 24 Dec 2014 10:50:33 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 89B171887EF; Wed, 24 Dec 2014 20:50:31 +0200 (EET) Date: Wed, 24 Dec 2014 20:50:31 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20141224185031.GA4583@LK-Perkele-VII> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> 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: http://mailarchive.ietf.org/arch/msg/tls/n169ixKUuhLgemj__PGxNXQWi60 Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 18:50:36 -0000 On Wed, Dec 24, 2014 at 10:21:58AM -0800, Eric Rescorla wrote: > On Tue, Dec 23, 2014 at 6:37 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > On Mon, Dec 22, 2014 at 01:38:36PM -0800, Eric Rescorla wrote: > > > Adam updated his PR to sign the prefix concatenated with the handshake > > > hashes, which makes it easier to have a single hash context. > > > > > > https://github.com/tlswg/tls13-spec/pull/100 > > > > > > I haven't seen any objections to this idea, so I'll merge this on > > Wednesday > > > unless I hear an objection before then. > > > > > > > Any reason not to fix the hash function per-ciphersuite, so servers > > and clients don't have to run multiple hashes in parrallel? > > > > The client and server may want to use different signature algorithms. I mean the hash in data to be signed (not the internal hash function in signature algortithm). That is, it would be digital signature of: - 32 padding bytes (or ClientRandom) - 32 padding bytes (or ServerRandom) - Context string - Ciphersuite ID (to provode domain separation) - handshake_hash(transcript) Where handshake_hash is the same hash as used by session hash (that one better be CR anyway!) This PR lacks the domain separation and requires both sides to buffer handshake or run potentailly lots of hashes (instead of just running one they need to run anyway). -Ilari From nobody Wed Dec 24 10:56:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4788E1A1A56 for ; Wed, 24 Dec 2014 10:56:37 -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 BQmTolxXQsv8 for ; Wed, 24 Dec 2014 10:56:35 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9ED1A1A3D for ; Wed, 24 Dec 2014 10:56:35 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so11825460wgg.7 for ; Wed, 24 Dec 2014 10:56:34 -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=yPw568t3xvQAbCeubHfg2r7jVU1tYTjWZPVjsKrX8AU=; b=ZvjLfSh+QQ3/pgeXkKyd4PfKoK9RqiZd0tdqb7TPnlf+BVcBnCH3MEiLly6yDup030 5W0db8BoweDUMR1vDUxUXteTImbwrEcWmVTgXrN+jc9LUoN+sWVWairIHvMOZ7YbOd0P 5D6OMjXpufSzt7lzIhkpBApcivNsSw4zmesJzOS0lVUkdOQQvH0pkRD68Ag63mMIh3DJ Vldjr9YPKsm90e7IY7FRygog771jb0c84r9OhO0ikZEitPU2ehUWaTX0ow72ZJAIIq/k I+ZdMrQQPYab3VvevLbACPJ0QbE3/ltKULzstDlEUX1i+BJDA5FDzrV6f5nqHoiWLa+o MtVg== X-Gm-Message-State: ALoCoQnB8ZUgVX7mqTLOm1GBKPVWfscPE1DmNu7WoNAKaSFm60YsN18X189XTHBsYoUnPpOuXZY7 X-Received: by 10.194.63.198 with SMTP id i6mr64762696wjs.90.1419447394025; Wed, 24 Dec 2014 10:56:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 24 Dec 2014 10:55:53 -0800 (PST) In-Reply-To: <20141224185031.GA4583@LK-Perkele-VII> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 24 Dec 2014 10:55:53 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7ba972b8b2da76050afad9f7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bBdSMczsvfaUKV6keTEaW9qWDeA Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 18:56:37 -0000 --047d7ba972b8b2da76050afad9f7 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 10:50 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Dec 24, 2014 at 10:21:58AM -0800, Eric Rescorla wrote: > > On Tue, Dec 23, 2014 at 6:37 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > > > On Mon, Dec 22, 2014 at 01:38:36PM -0800, Eric Rescorla wrote: > > > > Adam updated his PR to sign the prefix concatenated with the > handshake > > > > hashes, which makes it easier to have a single hash context. > > > > > > > > https://github.com/tlswg/tls13-spec/pull/100 > > > > > > > > I haven't seen any objections to this idea, so I'll merge this on > > > Wednesday > > > > unless I hear an objection before then. > > > > > > > > > > Any reason not to fix the hash function per-ciphersuite, so servers > > > and clients don't have to run multiple hashes in parrallel? > > > > > > > The client and server may want to use different signature algorithms. > > I mean the hash in data to be signed (not the internal hash function in > signature algortithm). > > That is, it would be digital signature of: > > - 32 padding bytes (or ClientRandom) > - 32 padding bytes (or ServerRandom) > - Context string > - Ciphersuite ID (to provode domain separation) > - handshake_hash(transcript) > So to be clear, you are proposing that we might (for instance) have a signature with (say) SHA-1 over a handshake hash computed with SHA-256? -Ekr > This PR lacks the domain separation and requires both sides to buffer > handshake or run potentailly lots of hashes (instead of just running > one they need to run anyway). --047d7ba972b8b2da76050afad9f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 24, 2014 at 10:50 AM, Ilari Liusvaara <= ;ilari.liu= svaara@elisanet.fi> wrote:
On Wed, Dec 24, 2014 at 10:21:58AM -0800, Eric Rescorla wrote:
> On Tue, Dec 23, 2014 at 6:37 AM, Ilari Liusvaara <
> ilari.liusvaara@elisane= t.fi> wrote:
>
> > On Mon, Dec 22, 2014 at 01:38:36PM -0800, Eric Rescorla wrote: > > > Adam updated his PR to sign the prefix concatenated with the= handshake
> > > hashes, which makes it easier to have a single hash context.=
> > >
> > > https://github.com/tlswg/tls13-spec/pull/100
> > >
> > > I haven't seen any objections to this idea, so I'll = merge this on
> > Wednesday
> > > unless I hear an objection before then.
> > >
> >
> > Any reason not to fix the hash function per-ciphersuite, so serve= rs
> > and clients don't have to run multiple hashes in parrallel? > >
>
> The client and server may want to use different signature algorithms.<= br>
I mean the hash in data to be signed (not the internal hash function= in
signature algortithm).

That is, it would be digital signature of:

- 32 padding bytes (or ClientRandom)
- 32 padding bytes (or ServerRandom)
- Context string
- Ciphersuite ID (to provode domain separation)
- handshake_hash(transcript)

So to be c= lear, you are proposing that we might (for instance) have
a signa= ture with (say) SHA-1 over a handshake hash computed with
SHA-256= ?

-Ekr

=C2=A0
This PR lacks the domain separation and requires both sides to buffer
handshake or run potentailly lots of hashes (instead of just running
one they need to run anyway).

=C2=A0
<= /div>
--047d7ba972b8b2da76050afad9f7-- From nobody Wed Dec 24 11:21:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D191A1A56 for ; Wed, 24 Dec 2014 11:21:45 -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 SS_xM3sYoQjD for ; Wed, 24 Dec 2014 11:21:42 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FD81A1A60 for ; Wed, 24 Dec 2014 11:21:42 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id z6so4241023yhz.30 for ; Wed, 24 Dec 2014 11:21:41 -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=9A2w0QCkCZxh0HUVaKsoYhSAZ/m/smp9tI8n8sCm7lg=; b=WodSLSCiRvzm2eIQ+gSiklkI18rJnw6i0Axot4g06LtqBILDkU9i3d/NrHDcsNg/HT RjExE4TRNAN7kVsn48cE7MpXvsBT4SQmtUxNxKaWUqgLFFGq3s80uzFbSIDoSBU26Ek6 /kZMJhC1zjmrumikV29UjoytHha8fQrql9dx2SzmxgvLZZaUawr+GFRSCxkU0T4gyFPE OTmepv2ROhcrpmiEuZOJqLoRkWRUtk9UlKM3ONRWtUHN6Zeg+bVDLIPJ5WK/vTKAT+pi Gu2ij5bJT9p2afWruOeephkRm9zKRX1SACN8B/UuTSYke6++59yIcKkIzlaVdYhO65w+ 4wVw== MIME-Version: 1.0 X-Received: by 10.170.89.130 with SMTP id g124mr30958362yka.24.1419448901673; Wed, 24 Dec 2014 11:21:41 -0800 (PST) Received: by 10.170.195.21 with HTTP; Wed, 24 Dec 2014 11:21:41 -0800 (PST) In-Reply-To: References: <20141223142648.GA11149@LK-Perkele-VII> Date: Wed, 24 Dec 2014 14:21:41 -0500 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NKPLIpT0Fw123Nw6GoHtyWfmGjg Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 19:21:45 -0000 On Wed, Dec 24, 2014 at 1:29 PM, Eric Rescorla wrote: > > > On Tue, Dec 23, 2014 at 6:26 AM, Ilari Liusvaara > wrote: >> >> On Mon, Dec 22, 2014 at 01:33:13PM -0800, Eric Rescorla wrote: >> > I've posted an updated PR at: >> > >> > https://github.com/tlswg/tls13-spec/pull/89 >> > >> > Note that I did not restore the ChangeCipherSpec message as my sense of >> > the WG discussion and private conversations was that people preferred to >> > have it gone. If you feel strongly about this change one way or the >> > other, >> > and haven't already posted to the list about it, please do so now, as >> > I'd >> > like to resolve this and merge this PR this week. I don't know why it existed in the first place, so I feel compelled to ask what that reason was and why it doesn't still apply. >> > >> >> (General philosophical note: I'm in favor of more complicated protocol if: >> - It fixes something that is just plain nasty to analyze, or >> - It causes bad implementations to break fast instead of being security >> timebombs.) >> >> >> Regarding CCS removal, I'm very much in favor. >> >> >> Reading through this, some comments: >> >> "At this point, the handshake is complete, and the client and server may >> exchange application layer data, which is protected using a new set of >> keys derived from both the premaster secret and the handshake transcript >> (see {{I-D.ietf-tls-session-hash}} for the security rationale for this.)" >> >> AFAIK, I-D.ietf-tls-session-hash doesn't really contain security rationale >> for this. It only has security rationale for hashing exchange keys (which >> are included in the first keying anyway) and says about including >> certificates (paraprhased): "Compliant with NIST recommediations" and >> "SSH does this" (actually, it only does that for server key, not client >> key). >> >> Now, if EncryptedExtensions contains extensions that twiddle with some >> critical parameters, there is very much reason to rekey after that. > > > In conversations with the INRIA guys, the general consensus seemed to > be that hashing more was more conservative. I'll work with them to get > some text around this either here or in the session hash draft. > > > >> >> "[[OPEN ISSUE: Should we restart the handshake hash? >> https://github.com/tlswg/tls13-spec/issues/104.]]" > > > > >> >> I regard restarting the hashes as very dangerous (not that I think that >> the whole HRR is a good idea, but I don't say more about that). > > > The expectation in the current draft is that you do not restart the > handshake > hash, but I know there are different opinions about that, hence the open > issue. Let's discuss this separately, since the only change in this area > in this PR is to add the issue marker. > > >> "This master secret value is used to generate the record protection >> keys used for the handshake, as described in {{key-calculation}}. It is >> also used with TLS Exporters {{RFC5705}}." >> >> Wasn't there an idea for giving TLS Exporter its own master secret? > > >> That would stop applications from exporting important system keys. > > > I suggested that, but upon reconsideration it seemed a bit > over-complicated. What's the threat model you have in mind > here? Application authors shouldn't depend on magic details for their applications to be secure. So long as the exporter is capable of generating keys used to encrypt or authenticate data, the application author has to ensure that they don't accidentally do that. By making it impossible to mess up, we make the application author's job easier. I'm strongly in favor of making it easy to make secure systems. > > > >> >> "If the server does not request client authentication, the master >> secret can be computed at the time that the server sends its Finished, >> thus allowing the server to send traffic on its first flight (see >> [TODO] for security considerations on this practice.) If the server >> requests client authentication, this secret can be computed after the >> client's Certificate and CertificateVerify have been sent, or, if the >> client refuses client authentication, after the client's empty >> Certificate message has been sent." >> >> Server can't send data on first flight (to anonymous recipient) if >> it requests client authentication? E.g. HTTP/2 settings blocks, >> protocol banners or various other protocol capability negotiations. > > > That's correct. This is obviously not ideal but the alternative with this > design is to have an even more complicated key schedule. The idea > behind PR 95 (https://github.com/tlswg/tls13-spec/pull/95) is to > address this, though that's of course not the only way. What are > your thoughts here? I think we can deal with a more complicated implementation, so long as exposing the feature isn't that complicated. Transporting data ahead of checking who the person is that it is being sent to is very simple to expose: a function to accept data and send it, and one to check if the authentication is complete and who it is. Applications that can't meaningfully deal with this can be written as normal. But I'm still thinking about the right way to do this. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Dec 24 11:39:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200F61A1A69 for ; Wed, 24 Dec 2014 11:39:11 -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 4c8_0v9vD1jd for ; Wed, 24 Dec 2014 11:39:09 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A591A1A63 for ; Wed, 24 Dec 2014 11:39:08 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id EE613188766; Wed, 24 Dec 2014 21:39:06 +0200 (EET) Date: Wed, 24 Dec 2014 21:39:06 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20141224193906.GB4583@LK-Perkele-VII> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> 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: http://mailarchive.ietf.org/arch/msg/tls/hrhKhe25cJW8AbTJNkaB65YoUWc Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 19:39:11 -0000 On Wed, Dec 24, 2014 at 10:55:53AM -0800, Eric Rescorla wrote: > On Wed, Dec 24, 2014 at 10:50 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > On Wed, Dec 24, 2014 at 10:21:58AM -0800, Eric Rescorla wrote: > > > On Tue, Dec 23, 2014 at 6:37 AM, Ilari Liusvaara < > > > ilari.liusvaara@elisanet.fi> wrote: > > > > > > > > Any reason not to fix the hash function per-ciphersuite, so servers > > > > and clients don't have to run multiple hashes in parrallel? > > > > > > > > > > The client and server may want to use different signature algorithms. > > > > I mean the hash in data to be signed (not the internal hash function in > > signature algortithm). > > > > That is, it would be digital signature of: > > > > - 32 padding bytes (or ClientRandom) > > - 32 padding bytes (or ServerRandom) > > - Context string > > - Ciphersuite ID (to provode domain separation) > > - handshake_hash(transcript) > > > > So to be clear, you are proposing that we might (for instance) have > a signature with (say) SHA-1 over a handshake hash computed with > SHA-256? Yes. E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for connection. That would result in SHA-1 signature over SHA-256 hash. The other way around can't happen with any current ciphersuite (because every current one has prf-hash of either SHA-256 or SHA-384). -Ilari From nobody Wed Dec 24 13:02:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FFD1A1ADC for ; Wed, 24 Dec 2014 13:02:28 -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 8vckk-5iqVmi for ; Wed, 24 Dec 2014 13:02:26 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A821A1ADF for ; Wed, 24 Dec 2014 13:02:26 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so14355697wiw.13 for ; Wed, 24 Dec 2014 13:02:25 -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=7zQM87vDg6E9AjjuKnrriJKnpr0SgMrRBdTlVs9Esjs=; b=b4yYCxWeJd2lnplVQivShqsHX44QFyIdO7e2WZ4cSvUDfpTGtQo/NSk765SKtrVOEZ VjBMPfXuX9TYweKZlWvyoRh/qVHd/hqoAdwJprIEUD0HwYKfsDWFPLa8Ja9r1DngaTlq hvZD+KvlPbrLZ9uwe/wpRTKqDP244RKGmmjpzOoQTeuv2woFoI415vq42hrI8y213WqN ff8IGjsp+V6b8PqXd3FmKcOhF5rQ328KD5RzAKIWUIzAJZFC2mttUcRwTZ21FxgAF0ZW 8khBMxw/ABVzzL3u1QLMqrlYMS6bt/+/wKAYHQ+mVv7dlgw703ekaOjHJj6nrBgzv/Ez y0Fg== X-Gm-Message-State: ALoCoQlx6vgX5HXERIYnRvB0WoQOe5Ijf6ttkNDc7X2U2Vj9N/+GsiwT9l8FTGwqFgx7DNAh3nL7 X-Received: by 10.180.21.178 with SMTP id w18mr53767455wie.78.1419454945313; Wed, 24 Dec 2014 13:02:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 24 Dec 2014 13:01:45 -0800 (PST) In-Reply-To: <20141224193906.GB4583@LK-Perkele-VII> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 24 Dec 2014 13:01:45 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7bb70a7cca59d7050afc9b0e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/effvwLbx8O-erDVWarl_xVl3yQc Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 21:02:28 -0000 --047d7bb70a7cca59d7050afc9b0e Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 11:39 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Dec 24, 2014 at 10:55:53AM -0800, Eric Rescorla wrote: > > On Wed, Dec 24, 2014 at 10:50 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > > > On Wed, Dec 24, 2014 at 10:21:58AM -0800, Eric Rescorla wrote: > > > > On Tue, Dec 23, 2014 at 6:37 AM, Ilari Liusvaara < > > > > ilari.liusvaara@elisanet.fi> wrote: > > > > > > > > > > Any reason not to fix the hash function per-ciphersuite, so servers > > > > > and clients don't have to run multiple hashes in parrallel? > > > > > > > > > > > > > The client and server may want to use different signature algorithms. > > > > > > I mean the hash in data to be signed (not the internal hash function in > > > signature algortithm). > > > > > > That is, it would be digital signature of: > > > > > > - 32 padding bytes (or ClientRandom) > > > - 32 padding bytes (or ServerRandom) > > > - Context string > > > - Ciphersuite ID (to provode domain separation) > > > - handshake_hash(transcript) > > > > > > > So to be clear, you are proposing that we might (for instance) have > > a signature with (say) SHA-1 over a handshake hash computed with > > SHA-256? > > Yes. > > E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > for connection. That would result in SHA-1 signature over SHA-256 hash. > > > The other way around can't happen with any current ciphersuite (because > every current one has prf-hash of either SHA-256 or SHA-384). Thanks for the clarification. What do other people think about this suggestion? -Ekr > > > > -Ilari > --047d7bb70a7cca59d7050afc9b0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Dec 24, 2014 at 11:39 AM, Ilari Liusvaara <ilari.liusvaa= ra@elisanet.fi> wrote:
On Wed, Dec 24, 2014 at 10:55:53AM -0800, Eric Rescorla wrote:=
> On Wed, Dec 24, 2014 at 10:50 AM, Ilari Liusvaara <
> ilari.liusvaara@elisane= t.fi> wrote:
>
> > On Wed, Dec 24, 2014 at 10:21:58AM -0800, Eric Rescorla wrote: > > > On Tue, Dec 23, 2014 at 6:37 AM, Ilari Liusvaara <
> > > ilari.liusvaa= ra@elisanet.fi> wrote:
> > > >
> > > > Any reason not to fix the hash = function per-ciphersuite, so servers
> > > > and clients don't have to run multiple hashes in pa= rrallel?
> > > >
> > >
> > > The client and server may want to use different signature al= gorithms.
> >
> > I mean the hash in data to be signed (not the internal hash funct= ion in
> > signature algortithm).
> >
> > That is, it would be digital signature of:
> >
> > - 32 padding bytes (or ClientRandom)
> > - 32 padding bytes (or ServerRandom)
> > - Context string
> > - Ciphersuite ID (to provode domain separation)
> > - handshake_hash(transcript)
> >
>
> So to be clear, you are proposing that we might (for instance) have > a signature with (say) SHA-1 over a handshake hash computed with
> SHA-256?

Yes.

E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for connection. That would result in SHA-1 signature over SHA-256 hash.


The other way around can't happen with any current ciphersuite (because=
every current one has prf-hash of either SHA-256 or SHA-384).
<= div>
Thanks for the clarification. What do other people think= about this suggestion?

-Ekr
=C2=A0



-Ilari

--047d7bb70a7cca59d7050afc9b0e-- From nobody Wed Dec 24 13:04:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1DF1A1AD2 for ; Wed, 24 Dec 2014 13:04:28 -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 QkAS-jlxJP_6 for ; Wed, 24 Dec 2014 13:04:26 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9891A1A91 for ; Wed, 24 Dec 2014 13:04:25 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so11923650wgg.25 for ; Wed, 24 Dec 2014 13:04:24 -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=ikoJK0rH16qg0jf0DLE5/qUpHbrxpM2qEeNg1afq1zI=; b=Ur446PyQmNCKyBtpqf8kHpqcAICIcaEdee7g8g1av+RrfDwndSFXz4IHJJ1thI3ZXI OGdCYf4o+bbEX+qVXv7dqJQ9zQMxYWSLSM4JLxJxTBHalnAJ0MnCqDjH29xHX2SNCPnv YdYxkbsIybsJy0IPEwLhcNekGSOf7MCsi3X7/x//Oz0XznceKMuAGPUkn+evELQht5fT 8wtMM3oCnsXMJZrZKervI9MaLqNcssesMKFkfs6vKhuuHNXpd2mJq19LVzXeicVJFLil sHpKifgPsy1NVQGeXfDzs1+scjpB3k1hu6Kpx7l57aCFXtErEaUX/nilh7jkDbM6L0V+ AJQw== X-Gm-Message-State: ALoCoQm/WxaImXQ6wrl93WxdAZ6JLbVQIsTuRFcMsPrlLELi57ie/ANHP625rK7oRrs1tclVURS8 X-Received: by 10.180.198.164 with SMTP id jd4mr53937672wic.42.1419455064751; Wed, 24 Dec 2014 13:04:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 24 Dec 2014 13:03:44 -0800 (PST) In-Reply-To: References: <20141223142648.GA11149@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 24 Dec 2014 13:03:44 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7b604706e8d6cc050afca29d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DcpKQaUd4Yu2yY9-CASSxHs3cc4 Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for session hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 21:04:28 -0000 --047d7b604706e8d6cc050afca29d Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 11:21 AM, Watson Ladd wrote: > On Wed, Dec 24, 2014 at 1:29 PM, Eric Rescorla wrote > > > >> That would stop applications from exporting important system keys. > > > > > > I suggested that, but upon reconsideration it seemed a bit > > over-complicated. What's the threat model you have in mind > > here? > > Application authors shouldn't depend on magic details for their > applications to be secure. So long as the exporter is capable of > generating keys used to encrypt or authenticate data, the application > author has to ensure that they don't accidentally do that. By making > it impossible to mess up, we make the application author's job easier. > > I'm strongly in favor of making it easy to make secure systems. It seems like the underlying desire is for separation between keys and exporters, right? I know MSJ has asked for context separation to make things more compatible with HSMs. Would that solve the issue here as well, without creating a new MS? >> "If the server does not request client authentication, the master > >> secret can be computed at the time that the server sends its Finished, > >> thus allowing the server to send traffic on its first flight (see > >> [TODO] for security considerations on this practice.) If the server > >> requests client authentication, this secret can be computed after the > >> client's Certificate and CertificateVerify have been sent, or, if the > >> client refuses client authentication, after the client's empty > >> Certificate message has been sent." > >> > >> Server can't send data on first flight (to anonymous recipient) if > >> it requests client authentication? E.g. HTTP/2 settings blocks, > >> protocol banners or various other protocol capability negotiations. > > > > > > That's correct. This is obviously not ideal but the alternative with this > > design is to have an even more complicated key schedule. The idea > > behind PR 95 (https://github.com/tlswg/tls13-spec/pull/95) is to > > address this, though that's of course not the only way. What are > > your thoughts here? > > I think we can deal with a more complicated implementation, so long as > exposing the feature isn't that complicated. Transporting data ahead > of checking who the person is that it is being sent to is very simple > to expose: a function to accept data and send it, and one to check if > the authentication is complete and who it is. Applications that can't > meaningfully deal with this can be written as normal. But I'm still > thinking about the right way to do this See also the PR I point to above for an alternative protocol-level implementation of this. -Ekr --047d7b604706e8d6cc050afca29d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 24, 2014 at 11:21 AM, Watson Ladd <watsonbladd@gmail.c= om> wrote:
On Wed, Dec 24, 2014 at 1:29 PM, Eric Rescorla <ekr@rtfm.com> wrote
>
>> That would stop applications from exporting important system keys.=
>
>
> I suggested that, but=C2=A0 upon reconsideration it seemed a bit
> over-complicated. What's the threat model you have in mind
> here?

Application authors shouldn't depend on magic details for t= heir
applications to be secure. So long as the exporter is capable of
generating keys used to encrypt or authenticate data, the application
author has to ensure that they don't accidentally do that. By making it impossible to mess up, we make the application author's job easier.<= br>
I'm strongly in favor of making it easy to make secure systems.

It seems like the underlying desire is for separat= ion between keys
and exporters, right? I know MSJ has asked for c= ontext separation
to make things more compatible with HSMs. Would= that solve the
issue here as well, without creating a new MS?



>> "If the server does not request client authentication, the ma= ster
>> secret can be computed at the time that the server sends its Finis= hed,
>> thus allowing the server to send traffic on its first flight (see<= br> >> [TODO] for security considerations on this practice.) If the serve= r
>> requests client authentication, this secret can be computed after = the
>> client's Certificate and CertificateVerify have been sent, or,= if the
>> client refuses client authentication, after the client's empty=
>> Certificate message has been sent."
>>
>> Server can't send data on first flight (to anonymous recipient= ) if
>> it requests client authentication? E.g. HTTP/2 settings blocks, >> protocol banners or various other protocol capability negotiations= .
>
>
> That's correct. This is obviously not ideal but the alternative wi= th this
> design is to have an even more complicated key schedule. The idea
> behind PR 95 (https://github.com/tlswg/tls13-spec/pull/95) is to > address this, though that's of course not the only way. What are > your thoughts here?

I think we can deal with a more complicated implementation, so long = as
exposing the feature isn't that complicated. Transporting data ahead of checking who the person is that it is being sent to is very simple
to expose: a function to accept data and send it, and one to check if
the authentication is complete and who it is. Applications that can't meaningfully deal with this can be written as normal. But I'm still
thinking about the right way to do this

See= also the PR I point to above for an alternative protocol-level implementat= ion
of this.

-Ekr
=C2=A0
=

--047d7b604706e8d6cc050afca29d-- From nobody Wed Dec 24 13:21:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912941A1AF0 for ; Wed, 24 Dec 2014 13:21:02 -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 VU67i7UV8eDi for ; Wed, 24 Dec 2014 13:21:00 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0FC1A1AE3 for ; Wed, 24 Dec 2014 13:21:00 -0800 (PST) Received: by mail-yk0-f182.google.com with SMTP id 131so4161508ykp.13 for ; Wed, 24 Dec 2014 13:20:59 -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=pQR3Gdf/8m2uzCRCOU7sthCNOlLBg4ioF2LAEha/9rI=; b=tXeambh6gidQq7RX6iSnQBKK+A6pAEhSLLC4J6v3lNgpY0SMFXx54pH/28Q9EzK8pr tox2pDZHobYdjQ10HHYxyLTKR2ex2I+ZFvuaaFyVRkPi7U3cGbQNGdxp/fVOMNpMrNzR t1DRej3hfzWjG4NRXTM6eI12uTqim0nFwXQB8uO1OvmB4cHseLQ3XU0ijC9hXy9k1LeW 7p7fPYJ6mHrI/mCNgsC/oCjhnVFOyGFbM6wOBShKrcMmzoULM/yMFn9gYgukDd+4NCrM QiQyLVrOIF4uI/3fS1WFoq5gf4MWt3uKKWasC9Gb0ymQGBS9fqwOFwqLtSN37EypW/dg zCPQ== MIME-Version: 1.0 X-Received: by 10.170.91.194 with SMTP id i185mr1575046yka.20.1419456059423; Wed, 24 Dec 2014 13:20:59 -0800 (PST) Received: by 10.170.195.21 with HTTP; Wed, 24 Dec 2014 13:20:59 -0800 (PST) Date: Wed, 24 Dec 2014 16:20:59 -0500 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SZ56IUCdQ8mbCXgoa7jow8KGysg Subject: [TLS] Comments on PR #95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 21:21:02 -0000 Dear all, I've read PR #95 with a critical eye, and in addition to some infelicities of the text, see some more substantial issues. This email is my notes in the order they occurred to me: not necessarily correlated with severity. I've tried to triage them, but may have done so inaccurately. Most of these are editorial in nature. Line 291: we're citing DSA. old text. More broadly, applications don't care how we provide what we provide: they care about the end goals. At some point this should be revised accordingly. Line 418: Security means what exactly? Line 437-453: this needs to be rewritten. Why are we talking about SSL v3, when any similarity is like that of a whale to a platypus? Line 743: I'm confused by the comment on how one finds the length of the signature data: it seems to be sent on the wire, but the document says " The length of the signature is known because the algorithm and key used for the signing are known prior to encoding or decoding this structure.", which is a different method. I recommend removing that last sentence: the parser should parse with as little input as possible from above. Line 836: 800 lines in, and we've gotten about nowhere: defined a PRF, and a representation format. Now we hear that TLS doesn't provide some security properties, but we don't know what those are. A succinct, correct description should appear at the beginning and again in the security considerations section. Line 1015: Zero-length fragments of application data as traffic analysis countermeasure? I think this was written when padding between the fragment and record layers existed, and I'll have to check how this was supposed to work. As it stands, I've not yet gotten to a description of the record layer at the time I read this. Lines 1066-1072: We've got a perfectly good nonce in the sequence number. Why not use that? Oh right, hysterical raisins. Line 1119: Open issue #5. I've got to think about this one. Likely as not this will be a very complicated change, that makes TLS 1.3 a lot harder to implement. Line 1190: More forward references to resumption. Note that authentication status isn't defined as part of what gets resumed. I believe, but am not sure, that this was part of what made the SSL v3 multihoming fallback attack work. Line 1439: Finally, the handshake protocol. In this description there are a ton of forward references, that make understanding this a bit tricky. What's an Encrypted Extensions method, on line 1505? While the earlier description of the Alert protocol was by type of message, this overview is chronological. Line 1623: We're getting to the beef. But the reader already knows this: no need to reintroduce the handshake protocol. Line 1763: It's not clear what servers have to do, or not do, to deal with stolen session IDs. They need to not "breach security", whatever that means. Line 1863: Previously, hello extensions were relegated to a different document. Now they are needed for backwards compatibility. Line 1912: Was anyone using SRP? The more generic we have to make TLS 1.3, and the more we have to shoehorn in, the more complex it gets. This open issue could get hairy. Line 2199: Mandating the presence of the signature_algorithms extension would simplify things considerably. There are a bunch of open issues in the description of the handshake protocol, and some warts. I haven't thought about provability yet. Line 2995: A TODO DTLS, probably related to the possibility of the Update message being lost. I don't remember how DTLS deals with this in the handshake, but there data is not being sent with the new keys before the other side acknowledges receipt. Will think about it. Does ignoring an update still update the record layer? There does not seem to be a way to request a certificate in the update protocol. Line 3151: AES-GCM or AES-CCM seem the logical options here. Line 3165: This doesn't seem to be a very fleshed out security considerations section. Line 3606: Do we need the glossary? The implementation notes needs a substantial amount of work. The advice on random number generation is vintage 90's. The discussion of certificate checks could be substantially expanded. A lot of attacks that have been used in the wild are not discussed here. Line 4015: SSL v2? Really? Line 4034: This is not a security analysis. http://eprint.iacr.org/2014/182.pdf is a security analysis. It would be much more helpful if this was significantly edited: there is some valuable information in here, but much of it is misleading. Line 4185: This reads a bit strangely with things like DANE. Yes, I don't think DNSSEC has adequate security, and it's worth noting that CAs can be a problem. I think it's worth telling implementors to study the lessons of attacks in the past. This version of the draft is very clearly a work in progress. 0-RTT was introduced in a different pull-request, and I've not given it a hard look. Sincerely, Watson Ladd From nobody Wed Dec 24 17:01:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375571A6F53 for ; Wed, 24 Dec 2014 17:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 U6-rMKLHoFct for ; Wed, 24 Dec 2014 17:01:43 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 A4D991A6F51 for ; Wed, 24 Dec 2014 17:01:43 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBP1MaIZ012376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Dec 2014 01:22:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419470563; bh=IaUTLejvQIUAjuluZU3Y/KWt5znJEGB84bBk1rPr6yc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=cgDpyDDBLbZ+DamWT571c9I2U4cj3QWGMlcdsBsnP9ZlkksPnMEBc57abQmTYPlj1 23Ws/dxaySqK8yM5NJGL0B7TiwLQO6HtSKzSNZpgsFAoM66OwUd09rfgDQr5DA8ctF gLQqFsP67sqsjuVWilwEjLeRKubaX3h6fUWZBHzQ= Message-ID: <549B61E4.8080301@metaparadigm.com> Date: Thu, 25 Dec 2014 09:01:24 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/83AyfI1THxBGPhG2_hLr633EVmE Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 01:01:45 -0000 Hi Peter, Someone pointed out RFC 7366 to me off list. I will read. I like the idea of encrypt-then-MAC being a core requirement for TLSv1.3. Before I've read through can we do this with it? AES-256-GCM + hmac_null = 128 bits authentication AES-256-CBC + hmac_sha128 = 128 bits authentication AES-256-GCM + hmac_sha128 = 256 bits authentication AES-256-CBC + hmac_sha256 = 256 bits authentication AES-256-GCM + hmac_sha256 = 384 bits authentication AES-256-CBC + hmac_sha384 = 384 bits authentication I like the idea of >= 256 bits authentication, and the idea of the combination of a cipher based MAC and PRF based MAC for AES-GCM, given the properties of the AES-GCM CTR mode 'variant' and GHASH GF(2^128). Michael. On 24/12/14 2:15 pm, Peter Gutmann wrote: > Michael Clark writes: > >> I have been doing some independent research on TLS AEAD ciphers and decided >> to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM > > If you're going to look at these, what about also looking at encrypt-then-MAC, > which is another AEAD mechanism? > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Dec 24 17:30:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF451A6F61 for ; Wed, 24 Dec 2014 17:30:49 -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 mViytrQbWDQr for ; Wed, 24 Dec 2014 17:30:46 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B871A6F68 for ; Wed, 24 Dec 2014 17:30:46 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so12334145wgh.16 for ; Wed, 24 Dec 2014 17:30:45 -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=+d5gkmaIg+jhsRcNH0Nr/7MX36lIyIB3Yfb+UtCVvys=; b=Mp+gUBwA0QyBfoNJ0OGC0gQrSnu8RhbuxWaLzVXQ8Q7FNRHlRt1NZtxSuaIIsxWL2D 15ySzeH74NNDAJPCfUjz5TDwEwUMXhMjPaAEejbuLgFySvvK9xMy1FSpwuFcA2yd/DaO xxpvaNx/AtDWAltNAOKslge0De2g2PLCeK+7VCkcBPAV4MZsQh03sUn5owLrOkVLSsb/ onwux4EmaYLoG/wQRBoEcc0Zs8YmsUSD56DiBqEwsSI3uUvEEQ9nk1BZE6utB+aYZVyg 70KnZ8pYP5A/hO+zZOqlkIas0qNSngESU833Cp74QF8mmhOTXFAnm6U6kcWEdlIq/m66 6qqQ== X-Gm-Message-State: ALoCoQkNn1RJpMmz15pTXyNMxDwRcp9RY8FQG4LFKSVLX0BG7qhQzr6lvJgDI7k5//96Dwq8qVhw X-Received: by 10.180.206.47 with SMTP id ll15mr57326525wic.34.1419471045057; Wed, 24 Dec 2014 17:30:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 24 Dec 2014 17:30:03 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 24 Dec 2014 17:30:03 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c25c2068f2d1050b005bbc Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YcramL82iplPMQWCXwdW29hCW_w Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on PR #95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 01:30:49 -0000 --001a11c25c2068f2d1050b005bbc Content-Type: text/plain; charset=UTF-8 Watson, Thanks for the comments. Many of these are comments on the draft as a whole (and a lot are text that remains from TLS 1.2 and before). I'll go through these and turn them into Github issues for discussion (though given the holidays it probably won't be this week). Best, -Ekr On Wed, Dec 24, 2014 at 1:20 PM, Watson Ladd wrote: > Dear all, > I've read PR #95 with a critical eye, and in addition to some > infelicities of the text, see some more substantial issues. This email > is my notes in the order they occurred to me: not necessarily > correlated with severity. I've tried to triage them, but may have done > so inaccurately. Most of these are editorial in nature. > > Line 291: we're citing DSA. old text. More broadly, applications don't > care how we provide what we provide: they care about the end goals. At > some point this should be revised accordingly. > > Line 418: Security means what exactly? > > Line 437-453: this needs to be rewritten. Why are we talking about SSL > v3, when any similarity is like that of a whale to a platypus? > > Line 743: I'm confused by the comment on how one finds the length of > the signature data: it seems to be sent on the wire, but the document > says " The length of the signature is known because the algorithm and > key used for the signing are known prior to encoding or decoding this > structure.", which is a different method. > > I recommend removing that last sentence: the parser should parse with > as little input as possible from above. > > Line 836: 800 lines in, and we've gotten about nowhere: defined a PRF, > and a representation format. Now we hear that TLS doesn't provide some > security properties, but we don't know what those are. A succinct, > correct description should appear at the beginning and again in the > security considerations section. > > Line 1015: Zero-length fragments of application data as traffic > analysis countermeasure? I think this was written when padding between > the fragment and record layers existed, and I'll have to check how > this was supposed to work. As it stands, I've not yet gotten to a > description of the record layer at the time I read this. > > Lines 1066-1072: We've got a perfectly good nonce in the sequence > number. Why not use that? Oh right, hysterical raisins. > > Line 1119: Open issue #5. I've got to think about this one. Likely as > not this will be a very complicated change, that makes TLS 1.3 a lot > harder to implement. > > Line 1190: More forward references to resumption. Note that > authentication status isn't defined as part of what gets resumed. I > believe, but am not sure, that this was part of what made the SSL v3 > multihoming fallback attack work. > > Line 1439: Finally, the handshake protocol. In this description there > are a ton of forward references, that make understanding this a bit > tricky. What's an Encrypted Extensions method, on line 1505? While the > earlier description of the Alert protocol was by type of message, this > overview is chronological. > > Line 1623: We're getting to the beef. But the reader already knows > this: no need to reintroduce the handshake protocol. > > Line 1763: It's not clear what servers have to do, or not do, to deal > with stolen session IDs. They need to not "breach security", whatever > that means. > > Line 1863: Previously, hello extensions were relegated to a different > document. Now they are needed for backwards compatibility. > > Line 1912: Was anyone using SRP? The more generic we have to make TLS > 1.3, and the more we have to shoehorn in, the more complex it gets. > This open issue could get hairy. > > Line 2199: Mandating the presence of the signature_algorithms > extension would simplify things considerably. > > There are a bunch of open issues in the description of the handshake > protocol, and some warts. I haven't thought about provability yet. > > Line 2995: A TODO DTLS, probably related to the possibility of the > Update message being lost. I don't remember how DTLS deals with this > in the handshake, but there data is not being sent with the new keys > before the other side acknowledges receipt. Will think about it. > > Does ignoring an update still update the record layer? > > There does not seem to be a way to request a certificate in the update > protocol. > > Line 3151: AES-GCM or AES-CCM seem the logical options here. > > Line 3165: This doesn't seem to be a very fleshed out security > considerations section. > > Line 3606: Do we need the glossary? > > The implementation notes needs a substantial amount of work. The > advice on random number generation is vintage 90's. The discussion of > certificate checks could be substantially expanded. A lot of attacks > that have been used in the wild are not discussed here. > > Line 4015: SSL v2? Really? > > Line 4034: This is not a security analysis. > http://eprint.iacr.org/2014/182.pdf is a security analysis. It would > be much more helpful if this was significantly edited: there is some > valuable information in here, but much of it is misleading. > > Line 4185: This reads a bit strangely with things like DANE. Yes, I > don't think DNSSEC has adequate security, and it's worth noting that > CAs can be a problem. I think it's worth telling implementors to study > the lessons of attacks in the past. > > This version of the draft is very clearly a work in progress. 0-RTT > was introduced in a different pull-request, and I've not given it a > hard look. > > Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c25c2068f2d1050b005bbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Watson,

Thanks for the comments. Many o= f these are comments on the draft as
a whole (and a lot are text = that remains from TLS 1.2 and before). I'll
go through these = and turn them into Github issues for discussion
(though given the= holidays it probably won't be this week).

Bes= t,
-Ekr


=
On Wed, Dec 24, 2014 at 1:20 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
Dear all,
I've read PR #95 with a critical eye, and in addition to some
infelicities of the text, see some more substantial issues. This email
is my notes in the order they occurred to me: not necessarily
correlated with severity. I've tried to triage them, but may have done<= br> so inaccurately. Most of these are editorial in nature.

Line 291: we're citing DSA. old text. More broadly, applications don= 9;t
care how we provide what we provide: they care about the end goals. At
some point this should be revised accordingly.

Line 418: Security means what exactly?

Line 437-453: this needs to be rewritten. Why are we talking about SSL
v3, when any similarity is like that of a whale to a platypus?

Line 743: I'm confused by the comment on how one finds the length of the signature data: it seems to be sent on the wire, but the document
says " The length of the signature is known because the algorithm and<= br> key used for the signing are known prior to encoding or decoding this
structure.", which is a different method.

I recommend removing that last sentence: the parser should parse with
as little input as possible from above.

Line 836: 800 lines in, and we've gotten about nowhere: defined a PRF,<= br> and a representation format. Now we hear that TLS doesn't provide some<= br> security properties, but we don't know what those are. A succinct,
correct description should appear at the beginning and again in the
security considerations section.

Line 1015: Zero-length fragments of application data as traffic
analysis countermeasure? I think this was written when padding between
the fragment and record layers existed, and I'll have to check how
this was supposed to work. As it stands, I've not yet gotten to a
description of the record layer at the time I read this.

Lines 1066-1072: We've got a perfectly good nonce in the sequence
number. Why not use that? Oh right, hysterical raisins.

Line 1119: Open issue #5. I've got to think about this one. Likely as not this will be a very complicated change, that makes TLS 1.3 a lot
harder to implement.

Line 1190: More forward references to resumption. Note that
authentication status isn't defined as part of what gets resumed. I
believe, but am not sure, that this was part of what made the SSL v3
multihoming fallback attack work.

Line 1439: Finally, the handshake protocol. In this description there
are a ton of forward references, that make understanding this a bit
tricky. What's an Encrypted Extensions method, on line 1505? While the<= br> earlier description of the Alert protocol was by type of message, this
overview is chronological.

Line 1623: We're getting to the beef. But the reader already knows
this: no need to reintroduce the handshake protocol.

Line 1763: It's not clear what servers have to do, or not do, to deal with stolen session IDs. They need to not "breach security", what= ever
that means.

Line 1863: Previously, hello extensions were relegated to a different
document. Now they are needed for backwards compatibility.

Line 1912: Was anyone using SRP? The more generic we have to make TLS
1.3, and the more we have to shoehorn in, the more complex it gets.
This open issue could get hairy.

Line 2199: Mandating the presence of the signature_algorithms
extension would simplify things considerably.

There are a bunch of open issues in the description of the handshake
protocol, and some warts. I haven't thought about provability yet.

Line 2995: A TODO DTLS, probably related to the possibility of the
Update message being lost. I don't remember how DTLS deals with this in the handshake, but there data is not being sent with the new keys
before the other side acknowledges receipt. Will think about it.

Does ignoring an update still update the record layer?

There does not seem to be a way to request a certificate in the update prot= ocol.

Line 3151: AES-GCM or AES-CCM seem the logical options here.

Line 3165: This doesn't seem to be a very fleshed out security
considerations section.

Line 3606: Do we need the glossary?

The implementation notes needs a substantial amount of work. The
advice on random number generation is vintage 90's.=C2=A0 The discussio= n of
certificate checks could be substantially expanded. A lot of attacks
that have been used in the wild are not discussed here.

Line 4015: SSL v2? Really?

Line 4034: This is not a security analysis.
http://ep= rint.iacr.org/2014/182.pdf is a security analysis. It would
be much more helpful if this was significantly edited: there is some
valuable information in here, but much of it is misleading.

Line 4185: This reads a bit strangely with things like DANE. Yes, I
don't think DNSSEC has adequate security, and it's worth noting tha= t
CAs can be a problem. I think it's worth telling implementors to study<= br> the lessons of attacks in the past.

This version of the draft is very clearly a work in progress. 0-RTT
was introduced in a different pull-request, and I've not given it a
hard look.

Sincerely,
Watson Ladd

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

--001a11c25c2068f2d1050b005bbc-- From nobody Wed Dec 24 17:34:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9074E1A6F68 for ; Wed, 24 Dec 2014 17:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 fyPDMVB8k6kg for ; Wed, 24 Dec 2014 17:34:47 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 2FF281A6F67 for ; Wed, 24 Dec 2014 17:34:47 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBP1tSca012451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Dec 2014 01:55:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419472533; bh=QhtWBZ4v24o24MGxhBhUWc1tWa2Ek4y9XAHtaywuy/k=; h=Date:From:To:Subject:References:In-Reply-To:From; b=wEmBGgidE2A2TThutCADZ0lmTgN7GOL5sBqL939VyYvppnCunB/No8Y9me26fgStl 5mEjemaNVAII6nuGL/vef5zOclERlrg8+gAEPEsTFrRQ/eImrUJZQE6qocZB9wP+tk wcUdJpw/Txgj7IYBF+BbsbFcPuEOsRAStULjKSaQ= Message-ID: <549B6998.6050405@metaparadigm.com> Date: Thu, 25 Dec 2014 09:34:16 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> <549B61E4.8080301@metaparadigm.com> In-Reply-To: <549B61E4.8080301@metaparadigm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XmeXIu4WVumr91MxOHF3_WV1CEs Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 01:34:48 -0000 The other point being to remove MAC-then-encrypt from TLSv1.3, not necessarily AES-CBC (as its non parallelism is a good property in certain situations). The principle is considering TLSv1.3 from a 'profile' perspective and that the 'known problematic' MAC-then-encrypt could be supported by implementations that choose to offer TLSv1.2 (and older) profiles and drop encrypt-then-MAC and make MAC-then-encrypt mandatory in the TLSv1.3 profile. i.e. a clean up, and improvement to auth integrity. The principle being we shouldn't preserve back compatibility by incorporating old baggage into to the new spec, rather have a design that allows implementations to support older profiles. This would make the spec simpler. TLsv1.3 would be completely encrypt-then-MAC including the ability to augment AEAD ciphers with more authentication bits. i.e. symmetrical (except for a special case of hmac_null where the auth bits equals the tag bits of the AEAD cipher and how the AD is handled for encrypt-then-MAC with an AEAD cipher). my 2 cents. On 25/12/14 9:01 am, Michael Clark wrote: > Hi Peter, > > Someone pointed out RFC 7366 to me off list. I will read. I like the > idea of encrypt-then-MAC being a core requirement for TLSv1.3. > > Before I've read through can we do this with it? > > AES-256-GCM + hmac_null = 128 bits authentication > AES-256-CBC + hmac_sha128 = 128 bits authentication > > AES-256-GCM + hmac_sha128 = 256 bits authentication > AES-256-CBC + hmac_sha256 = 256 bits authentication > > AES-256-GCM + hmac_sha256 = 384 bits authentication > AES-256-CBC + hmac_sha384 = 384 bits authentication > > I like the idea of >= 256 bits authentication, and the idea of the > combination of a cipher based MAC and PRF based MAC for AES-GCM, given > the properties of the AES-GCM CTR mode 'variant' and GHASH GF(2^128). > > Michael. > > > On 24/12/14 2:15 pm, Peter Gutmann wrote: >> Michael Clark writes: >> >>> I have been doing some independent research on TLS AEAD ciphers and decided >>> to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM >> >> If you're going to look at these, what about also looking at encrypt-then-MAC, >> which is another AEAD mechanism? >> >> Peter. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Dec 24 17:37:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29AF1A6F68 for ; Wed, 24 Dec 2014 17:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 nfC3f-Eqluqe for ; Wed, 24 Dec 2014 17:37:10 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 F3C521A6F67 for ; Wed, 24 Dec 2014 17:37:09 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBP1voMO012463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Dec 2014 01:57:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419472674; bh=RDTatSUd89Y4/BaFGDXvdUUS+mPJjH6GumrvBvwCw1I=; h=Date:From:To:Subject:References:In-Reply-To:From; b=XSZhuoAPOfo39vfqxLtMaKsKEwlmY04nqE0WarACRejkkV+4Bt4tYWX3V6vGiVJbi xYQJB9OLxg6jYr1VdEEktEvwa4dlDnMMFMbhXCMZpgqn5KTyu5WePfXqHiteV0eJQg rPMcT3pnO+IG9XO1mXDfn9ZVcUwmpRB0OYvg4w1s= Message-ID: <549B6A26.7020801@metaparadigm.com> Date: Thu, 25 Dec 2014 09:36:38 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> <549B61E4.8080301@metaparadigm.com> <549B6998.6050405@metaparadigm.com> In-Reply-To: <549B6998.6050405@metaparadigm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G-MjxRzV54QO3QY6AhnGU8JmQPk Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 01:37:10 -0000 On 25/12/14 9:34 am, Michael Clark wrote: > The other point being to remove MAC-then-encrypt from TLSv1.3, not > necessarily AES-CBC (as its non parallelism is a good property in > certain situations). > > The principle is considering TLSv1.3 from a 'profile' perspective and > that the 'known problematic' MAC-then-encrypt could be supported by > implementations that choose to offer TLSv1.2 (and older) profiles and > drop encrypt-then-MAC and make MAC-then-encrypt mandatory in the TLSv1.3 correction: drop MAC-then-encrypt and make encrypt-then-MAC mandatory in the TLSv1.3 From nobody Wed Dec 24 17:57:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7F1A6F8C for ; Wed, 24 Dec 2014 17:57: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 rOnGLvmWHNX3 for ; Wed, 24 Dec 2014 17:57:01 -0800 (PST) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653791A6F88 for ; Wed, 24 Dec 2014 17:57:01 -0800 (PST) Received: by mail-yh0-f46.google.com with SMTP id t59so4344337yho.19 for ; Wed, 24 Dec 2014 17:57:00 -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=pHDwrFjvkaoNR1SNFzXzHZ5+vIsgd8iTMFbak6Z1nm0=; b=OjQZS4B3HRP5QokYqB6DWfmX+1OX/ntuzYv8liqciy8J0eX53KY9NSJyTqo1XaJimn d/HjT2FB4ryqOSOMLO79aEOReIhbvHQXt0TIN8MRqMjiJmwP2ur4pu+gHY6GdDMyCJT9 MhRmegVUg9J9vocwyFdVvfkREpNwnUq41FK932MH6JRVP6IzIE6qF+9TFA7PmWJSyM7A cDX435ztvfniY3XYQSIj4JqE+Pna8L3GyaTAgplnK9iEuFAm9EKseMt4oyU4mvx/8bzo aRVjs9VuT3ppLcygjRbgjuTtYzd5zdPM2Hq68HQzs2AoexO/vR1O5StWrYLqL8WvYHti wBiQ== MIME-Version: 1.0 X-Received: by 10.236.22.36 with SMTP id s24mr28748564yhs.138.1419472620561; Wed, 24 Dec 2014 17:57:00 -0800 (PST) Received: by 10.170.195.21 with HTTP; Wed, 24 Dec 2014 17:57:00 -0800 (PST) In-Reply-To: <549B61E4.8080301@metaparadigm.com> References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> <549B61E4.8080301@metaparadigm.com> Date: Wed, 24 Dec 2014 20:57:00 -0500 Message-ID: From: Watson Ladd To: Michael Clark Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HcaKGtakT1vmj8uu5i7PUPIOai8 Cc: "" Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 01:57:03 -0000 On Wed, Dec 24, 2014 at 8:01 PM, Michael Clark wrote: > Hi Peter, > > Someone pointed out RFC 7366 to me off list. I will read. I like the > idea of encrypt-then-MAC being a core requirement for TLSv1.3. And we have already made AEAD modes a requirement in the TLS 1.3 draft. I don't see the argument for adding RFC 7366 in addition to these. > > Before I've read through can we do this with it? > > AES-256-GCM + hmac_null = 128 bits authentication > AES-256-CBC + hmac_sha128 = 128 bits authentication > > AES-256-GCM + hmac_sha128 = 256 bits authentication > AES-256-CBC + hmac_sha256 = 256 bits authentication > > AES-256-GCM + hmac_sha256 = 384 bits authentication > AES-256-CBC + hmac_sha384 = 384 bits authentication > > I like the idea of >= 256 bits authentication, and the idea of the > combination of a cipher based MAC and PRF based MAC for AES-GCM, given > the properties of the AES-GCM CTR mode 'variant' and GHASH GF(2^128). I don't agree with this analysis. For starters, GCM is not a PRF based authenticator. The security of GCM authentication decreases with the length of the message, while the security of HMAC authentication does not, while the numbers above don't recognize this. Secondly, attacks on authentication have to be online, and a failed guess results in connection teardown. An attacker with a 2^{-64} probability of forgery on any given connection would take decades to inject data into a TLS connection, even if the connection restarted 1 million times a second. By contrast, recovering data from a key 64 bits in length is a rather easy computation today, and will be easier tomorrow. Thirdly, the weak keys of GCM are a red herring. Using the logic of those papers, every GCM key is weak, as there is a known difference between messages that will lead to a forgery if a given key is used. One could make the same argument against CBC-MAC: if an attacker knows the key, they can produce forgeries. Fourthly, this ignores performance. Recent Intel chips have a significant amount of acceleration for AES-GCM that cannot be used for other modes. The parallelism of CTR mode permits hiding the latency of the AES instructions, while the carryless multiply can't accelerate HMAC. It also ignores implementation complexity: making two passes over the data, with different algorithms, is more complex than one. In short, there are no real security gains from this proposal. But there are large losses in simplicity and performance, as now the existing record layer transformations have to be redesigned and stacked in ways they aren't currently. One can't say "such and such an algorithm has more bits, therefore it is more secure". You have to look at the exact claims, and see how they apply to the way the algorithms are used. Sincerely, Watson Ladd > > Michael. > > > On 24/12/14 2:15 pm, Peter Gutmann wrote: >> Michael Clark writes: >> >>> I have been doing some independent research on TLS AEAD ciphers and decided >>> to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM >> >> If you're going to look at these, what about also looking at encrypt-then-MAC, >> which is another AEAD mechanism? >> >> Peter. >> >> _______________________________________________ >> 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 -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Dec 24 18:38:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB511A6FDB for ; Wed, 24 Dec 2014 18:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 M5qWSkkt6P78 for ; Wed, 24 Dec 2014 18:38:46 -0800 (PST) Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [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 8E16A1A6FCF for ; Wed, 24 Dec 2014 18:38:46 -0800 (PST) Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBP2xKZP012598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Dec 2014 02:59:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419476367; bh=I1zWmWp5ICyUUg4UN4+nWkH6rxOViJFaYfqdrvcgxFY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=EXILJ5aiU6Xp1sPAwQ4VBjn7AACpbjDiR9sPHnn+Tge0Z/eB1spoo67Xr19l1Ejdt F5+SZ6SD1N/4u7EERKBhZDIr/yvBkqJFxzJY/Ms467YxMlN4zSC5IN2Wx+4IwRAn08 avHQtP+FO3nNRkZlWxfLTBGGVuBHpzfIbr1QLl8Y= Message-ID: <549B7890.9000304@metaparadigm.com> Date: Thu, 25 Dec 2014 10:38:08 +0800 From: Michael Clark Organization: Metaparadigm Pte Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Watson Ladd References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> <549B61E4.8080301@metaparadigm.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Oy9zHZsHtvrp2sqcp0EU4CeCvn4 Cc: "" Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 02:38:48 -0000 On 25/12/14 9:57 am, Watson Ladd wrote: > On Wed, Dec 24, 2014 at 8:01 PM, Michael Clark wrote: >> Hi Peter, >> >> Someone pointed out RFC 7366 to me off list. I will read. I like the >> idea of encrypt-then-MAC being a core requirement for TLSv1.3. > > And we have already made AEAD modes a requirement in the TLS 1.3 > draft. I don't see the argument for adding RFC 7366 in addition to > these. >> >> Before I've read through can we do this with it? >> >> AES-256-GCM + hmac_null = 128 bits authentication >> AES-256-CBC + hmac_sha128 = 128 bits authentication >> >> AES-256-GCM + hmac_sha128 = 256 bits authentication >> AES-256-CBC + hmac_sha256 = 256 bits authentication >> >> AES-256-GCM + hmac_sha256 = 384 bits authentication >> AES-256-CBC + hmac_sha384 = 384 bits authentication >> >> I like the idea of >= 256 bits authentication, and the idea of the >> combination of a cipher based MAC and PRF based MAC for AES-GCM, given >> the properties of the AES-GCM CTR mode 'variant' and GHASH GF(2^128). > > I don't agree with this analysis. > > For starters, GCM is not a PRF based authenticator. The security of > GCM authentication decreases with the length of the message, while the > security of HMAC authentication does not, while the numbers above > don't recognize this. This is kind of my point. There is broken MAC-then-encrypt for non AEAD ciphers and AEAD ciphers with 128-bit tags where the authentication decreases with the length of the messages (non PRF based MACs based on finite fields). > Secondly, attacks on authentication have to be online, and a failed > guess results in connection teardown. An attacker with a 2^{-64} > probability of forgery on any given connection would take decades to > inject data into a TLS connection, even if the connection restarted 1 > million times a second. By contrast, recovering data from a key 64 > bits in length is a rather easy computation today, and will be easier > tomorrow. Sorry I don't have numbers, however if you are attacking a target where you know the message length of a oft repeated transaction and have a 128-bit GCM auth tag (theoretically ~64-bits strength if you have captured texts) then there is a possibility you could forge auth tags. DHTs are fast and disks are cheap. There may be some facilities that have 100 million threads and more drives (if you knew Intel's order book). I say dictionary lookup would be feasible within the next few years which has to be the time domain that is considered. sha1 is being deprecated elsewhere. Sure people have more time to attack CA certs. > Thirdly, the weak keys of GCM are a red herring. Using the logic of > those papers, every GCM key is weak, as there is a known difference > between messages that will lead to a forgery if a given key is used. > One could make the same argument against CBC-MAC: if an attacker knows > the key, they can produce forgeries. > > Fourthly, this ignores performance. Recent Intel chips have a > significant amount of acceleration for AES-GCM that cannot be used for > other modes. The parallelism of CTR mode permits hiding the latency of > the AES instructions, while the carryless multiply can't accelerate > HMAC. It also ignores implementation complexity: making two passes > over the data, with different algorithms, is more complex than one. I understand. I've read the code. I am aware of the properties of GF(2^128) finite fields. There are all arguments for performance and scary when it comes to the potential to forge tags for larger messages. There is huge parallelism potential in AES-GCM. I know software implementations with AES-NI are doing 4 blocks but the potential is not limited to 4 blocks. > In short, there are no real security gains from this proposal. But > there are large losses in simplicity and performance, as now the > existing record layer transformations have to be redesigned and > stacked in ways they aren't currently. One can't say "such and such an > algorithm has more bits, therefore it is more secure". You have to > look at the exact claims, and see how they apply to the way the > algorithms are used. I see it a different way. hmac_null plus AEAD_AES_GCM allows for the current level of integrity. The addition of a PRF based MAC provides more message integrity. No doubt. I can't see a good argument against an option for more integrity if a user wants it. I'm always worried by people who trust the level of integrity in algorithms that have deliberately sacrificed security for performance (32-bits less entropy in IV, not following CTR IV method, along with GCM's parallel GHASH and the properties of GF(2^128). This is all for speed. Good for a SSL-everywhere plain text replacement. Fine for Facebook and Google search. I'm sure the banks wouldn't trust it. Anyway, they have external factors to mitigate flaws in TLS. Consider it like insurance. The 'option' of adding authentication bits with a PRF gives you *added* integrity that does not decrease based on message length. It's up to a server whether it is used or not. I'm not making any argument about what are good defaults, just an option for more integrity. We will have to agree to disagree. I don't trust AES_GCM given my read of the spec. I noticed a shift towards better properties of prime sized fields GF(P) and GF(2^p); where p is prime. It's a fallacy to trust the security of AES_GCM when there are known weaknesses. We don't have to do any math to know that adding integrity with a PRF based MAC would mitigate future flaws in AES_GCM. i.e. reserve. From nobody Wed Dec 24 20:12:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BE21A8029 for ; Wed, 24 Dec 2014 20:12:50 -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 Y3Uw2TLRnuF4 for ; Wed, 24 Dec 2014 20:12:48 -0800 (PST) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7328F1A6FF0 for ; Wed, 24 Dec 2014 20:12:47 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 67FD769976; Thu, 25 Dec 2014 06:12:44 +0200 (EET) Date: Thu, 25 Dec 2014 06:12:44 +0200 From: Ilari Liusvaara To: Michael Clark Message-ID: <20141225041244.GA16354@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> <549B61E4.8080301@metaparadigm.com> <549B7890.9000304@metaparadigm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <549B7890.9000304@metaparadigm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AZdsRPXyxyzHKKQ1NC1UBd1aTuo Cc: "" Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 04:12:51 -0000 On Thu, Dec 25, 2014 at 10:38:08AM +0800, Michael Clark wrote: > On 25/12/14 9:57 am, Watson Ladd wrote: > > Sorry I don't have numbers, however if you are attacking a target where > you know the message length of a oft repeated transaction and have a > 128-bit GCM auth tag (theoretically ~64-bits strength if you have > captured texts) then there is a possibility you could forge auth tags. > DHTs are fast and disks are cheap. There may be some facilities that > have 100 million threads and more drives (if you knew Intel's order > book). I say dictionary lookup would be feasible within the next few > years which has to be the time domain that is considered. sha1 is being > deprecated elsewhere. Sure people have more time to attack CA certs. Without side-channel leakage, nonce reuse or breaking AES, you simply don't have enough information to tell the correct answer from wrong ones (128 bits remain arbitrary). So you can't bruteforce the keyspace offline. (The similar goes for Chacha20-Poly1305 (modulo Chacha20)). -Ilari From nobody Wed Dec 24 22:51:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280DC1A8733 for ; Wed, 24 Dec 2014 22:50:57 -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 p2exUfr2OFpY for ; Wed, 24 Dec 2014 22:50:55 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A75B1A872E for ; Wed, 24 Dec 2014 22:50:55 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so15028127wiv.1 for ; Wed, 24 Dec 2014 22:50:54 -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=SbiYjzBmMWB5KX32P39PE7ED2FO07edbOFfYqS/7kNc=; b=TTPQy1NWRoXHqyuyqree3aCHzvT8wt/ldB/M8Wlr+jGhBkd7MI/4S71e/ZcVtSMU9v qP0wdVJfNkNDVzWBIUhYg62ofM/qWck7fU6KvS3+qQ6v3AiZtxwj5FsQkE/SBC3bTcQ/ X9Qk04EAY0DZj/v9Qh3qfwNeiO2mnUb5UmQLyyIQGhkiBrMgNzXlI10S28l3ktnKz4Cn 0rHBbhZJh3MA1x3oWMJ7bMZ4qXHSmkzdEyqmZSngCfkMSkiwJMzE87HRYqMjxwJmlrXv r2qPWIMxFFr7bGepsP5m4PjH0Ju/pPmhXKqKb6MR8oIpivF+eKmkucTISB1NE7XExhEk HqJg== X-Received: by 10.180.101.200 with SMTP id fi8mr58294284wib.77.1419490254078; Wed, 24 Dec 2014 22:50:54 -0800 (PST) Received: from yoavs-mbp.mshome.net ([109.253.134.140]) by mx.google.com with ESMTPSA id o16sm705269wjw.7.2014.12.24.22.50.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Dec 2014 22:50:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <549B61E4.8080301@metaparadigm.com> Date: Thu, 25 Dec 2014 08:50:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> <549B61E4.8080301@metaparadigm.com> To: Michael Clark X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cj17qoPBvt65BWy-JgPywsuaeRo Cc: "" Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 06:50:57 -0000 > On Dec 25, 2014, at 3:01 AM, Michael Clark = wrote: > I like the idea of >=3D 256 bits authentication, and the idea of the > combination of a cipher based MAC and PRF based MAC for AES-GCM, given > the properties of the AES-GCM CTR mode 'variant' and GHASH GF(2^128). Why? Why do you want 256-bit or more message authentication? There is value in making encryption and key agreement more secure. There = is great value to attackers in recording a session and later breaking = the encryption or the key agreement. Breaking the message authentication = after the TLS session has terminated provides no value to the attacker. = Messages need to be forged online for the attack to be successful.=20 So bit lengths whose only justification is being future-proof for 30 = years are not relevant for message authentication. Even for encryption, = where there is value in after-the-fact breakage, the BCP being written = in UTA recommends 128-bit AES rather than 256-bit. ChaCha20 uses a = 256-bit mostly because of the nature of the algorithm. It would not be = any faster if the key was reduced to 128-bit. The same is not true for = your proposals. Yoav From nobody Thu Dec 25 12:21:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547351A885B for ; Thu, 25 Dec 2014 12:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh_whw8n_fcY for ; Thu, 25 Dec 2014 12:21:37 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB631A885A for ; Thu, 25 Dec 2014 12:21:36 -0800 (PST) Received: from pc (ip5b40064e.dynamic.kabel-deutschland.de [::ffff:91.64.6.78]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 25 Dec 2014 21:21:32 +0100 id 000000000000001A.00000000549C71CC.00006AE7 Date: Thu, 25 Dec 2014 21:21:41 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: Antoine Delignat-Lavaud Message-ID: <20141225212141.61122705@pc> In-Reply-To: <54995163.7070004@delignat-lavaud.fr> References: <5498DBCE.1070909@delignat-lavaud.fr> <20141223102635.3bda9ed2@pc> <54995163.7070004@delignat-lavaud.fr> 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-27367-1419538892-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WZE1YRLK0l0ha4SPhZQHsAKGwWI Cc: tls@ietf.org Subject: Re: [TLS] Remove signature algorithms from cipher suites 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, 25 Dec 2014 20:21:39 -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-27367-1419538892-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Tue, 23 Dec 2014 12:26:27 +0100 Antoine Delignat-Lavaud wrote: > No, in my proposal, the algorithm used in CertificateVerify messages > is negotiated based on advertised support in the "signature > algorithms" extension (and supported_signature_algorithms field in=20 > CertificateRequest). Clients are encouraged to prioritize > rsa-pss/sha256 over rsa/sha256 or rsa/sha1, and supporting servers > may pick PSS even if their certificate chain only contains rsa/sha256 > and rsa/sha1. Okay, then I misinterpreted you. But my point remains: Why not just say "TLS 1.3 has to use RSA with PSS, mo more PKCS #1 1.5"? > If anything, my own concern is the opposite. Allowing the same RSA > key to be used to sign with both PSS and PKCS#1v1.5 is considered=20 > cryptographic malpractice, as the composition of secure and weak=20 > signatures may very well be broken. However, servers have the ability > to avoid this risk by sending a different certificate depending on > whether the client advertises support for PSS or not, even if the two=20 > certificates are signed with PKCS#1 (the proof of the protocol will=20 > probably assume servers enforce this behavior). I am aware that using same key for both protocol versions is bad practice. However are you aware of any sign this may be a real risk? Anyway, for the scenario that TLS 1.3 uses only PSS, could a server send different keys for <=3D1.2 and 1.3? > Furthermore, one of the issues of PSS in RFC 4055 is its reliance on=20 > signature parameters, which have tricky agility characteristics. For=20 > everyone's sake, it may help adoption if new OIDs for PSS signatures=20 > were used that correspond to fixed parameters. In any case, this=20 > discussion is out of the scope of the TLS WG. I know all the problems, I implemented this once :-) cu, --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-27367-1419538892-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUnHHVAAoJEKWIAHK7tR5C1PsP/3gG9J9Mio4J8cSDqVLtE4c7 1M77yGWR/IWOO72tYU0khodGHjbRvRxSepwJzwYCU0J7Vrxe8CtbYw3KYxK2OJI5 aiI1DMW4FKO7SMmDz8dgWTiraw0mMSr0907SdEWHqTHbR5lpHpRs65B1MWbHuYGM 3i2yfDTRZS6BxjrInZM+4kCWuyWDg+X2mfLfN3r6fV9LmITsnIoJFqx16X0klGk2 RCUsFnrZ4ysZhBkR9HPjoph0EEB1UYC5DsX3RxafzePbPgBi4IhOMAccotCDIE01 DpJaEKKQUHY59gqSF9KTmKP4pSqtyC7X4Gxi/zVJIETTy03nmZWtyUBPUJ6MR6N6 zs9HgyvwM4Tbic9G8UGRrQFSdFLbR7KyN4RDYWA1ESTnZVUUPtOF6zsqltp40jTj R9IWfNTuWL6uWumWtgsC/co1eWDsZy+TPotMlD2bVbKtlaeW1LShT67zs09OgPhr IhMjmqZ+YKkkqXDtuuAuc81OtLjRiCscqKEs/NdJCwRj1XlYG9wcIzk9pBZAQI0f ZhGl+DN+qCy0u0MPgxkBByFDGeoN1IYDtva4ldSyRRM8LHx6d2KG/mhORDsrj53m uQzlKTZlGJ6YoW6BBfJ65VtaQqaCTzJ+tObQbq18uZIS3DGBT5fanQsgw/OeUswn rIfMQQevEcWLCYDoaFkU =kP9z -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-27367-1419538892-0001-2-- From nobody Fri Dec 26 08:23:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC41A8834 for ; Tue, 23 Dec 2014 17:46:24 -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 1pCB4MMSfU_F for ; Tue, 23 Dec 2014 17:46:23 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284271A6FF1 for ; Tue, 23 Dec 2014 17:46:23 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id e89so3497252qgf.0 for ; Tue, 23 Dec 2014 17:46:22 -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:cc :mime-version:content-type:content-transfer-encoding:message-id; bh=B3kjKorMScAFuSE/vI5lZBPNvb5fvwdEWaL+C15XJJ0=; b=iyI8t4NX6OMVV4mMy4rdQNF23rTJL20CoYKxI8rnXY091+kZJf+tzQ3qSsBLAXYEsr dwE6+kg4BouZV4djDUIkykuqK7PWGNGXgRwdjwsPvCAL0mrLKM7C2xQL5CV58daWuHZi eG3uyahGd7RaFL8RWcXwnkpeJ+BRF64vz3gjxyTRVgdStXWSMvcWqaCl6r8vwIfm6dSD Q088t8i12smpM5nlo9NAvrCPnsI5NCfLzXq9K5c1sXoAQcu6bB+51Z7jP5I0NLZbEHjS 5Dhw6e6tc+UenbPyjVpIv1kfIOlf4b57VZHWDNOzYz3YC4DhOQj0Wq5eKG3kJK0/ewcz 2Hvg== X-Received: by 10.224.42.202 with SMTP id t10mr50271689qae.21.1419385582404; Tue, 23 Dec 2014 17:46:22 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id q68sm20308353qgq.0.2014.12.23.17.46.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 23 Dec 2014 17:46:21 -0800 (PST) From: Dave Garrett To: Brian Smith Date: Tue, 23 Dec 2014 20:46:20 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201412232046.20657.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GTid5aNR-9lcw9QpIzy3M7avfk4 X-Mailman-Approved-At: Fri, 26 Dec 2014 08:23:03 -0800 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility and prohibit SSL3 negotiation in 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, 24 Dec 2014 01:46:25 -0000 On Tuesday, December 23, 2014 04:51:40 pm Brian wrote: > Dave Garrett wrote: > > The PR replaces the section with a simple "MUST NOT" send or accept for > > TLS 1.3 implementations. > > It would be best to have your change do exactly that, by shortening > the remaining text to: > > Implementations MUST NOT send or accept an SSL > version 2.0 compatible CLIENT-HELLO. Implementations > MUST NOT send or accept TLS records with a version > less than { 3, 0 }. > > Note the suggestion to use the term "records" instead of "messages". I've updated the language for SSL2 based on your suggestions and have added in new language to prohibit SSL3 negotiation. Specifically, I'm using wording based on: https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00 This would have SSL2 connections attempts be ignored and SSL3 connection attempts be refused. Dave PS I do hope the SSL3 "diediedie" name stays around until RFC, as it so nicely carries the appropriate sentiment. ;) From nobody Fri Dec 26 08:23:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A51ACCE6 for ; Tue, 23 Dec 2014 23:23:49 -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 4XzTKonkHWbA for ; Tue, 23 Dec 2014 23:23:48 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED411A1A2F for ; Tue, 23 Dec 2014 23:23:48 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q108so5549809qgd.15 for ; Tue, 23 Dec 2014 23:23:47 -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:cc :mime-version:content-type:content-transfer-encoding:message-id; bh=RtT6Ei7Po+EcqGKQdAxPNWIp0AliIjcWR5p/bG6X5SI=; b=QxYBETuVq+M+gSOodynnq0CvPDS2ahEfI8pHH7UvJAdHofuOuJnvlw8eyVYSHkv1wX 9wIagFHCY9UWKZjfOOxkxtuzVciNGT9C/fRigjag2Bz2FSnSscNjVwdUI228RHu6Dg/9 V063r+ffZrRMithfLB7NTtBYiRI2QKzAv2vZ95iGQO5YYxtmnemuUlnKT3vcJXCuwzT8 0lie7t2Rf43C4V2wubn5B4oniAgdkk6OGXA1Xs8xAzjw9G0CakS5AI93yPj7zw7AXTe0 7d10vcQZAtBr7sq3Ri0eB/pr223T6yB/nSBlFjz6o9Qpa7bhGkmzHDzFu/vFPuNVXOS1 mbbQ== X-Received: by 10.140.81.73 with SMTP id e67mr30316372qgd.90.1419405827808; Tue, 23 Dec 2014 23:23:47 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id k9sm20862212qaj.7.2014.12.23.23.23.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 23 Dec 2014 23:23:47 -0800 (PST) From: Dave Garrett To: Yoav Nir Date: Wed, 24 Dec 2014 02:23:45 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201412240223.46107.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9T3Sg4gPrcD53xqpzBxvQZP9jDU X-Mailman-Approved-At: Fri, 26 Dec 2014 08:23:02 -0800 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, 24 Dec 2014 07:23:50 -0000 On Wednesday, December 24, 2014 01:40:10 am you wrote: > > There's no reason to maintain any backwards support here just for > > Internet Explorer 2.0 on Windows 3.1. >=20 > I=E2=80=99m not objecting to the change, but I am objecting to the hyperb= ole. 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=E2=80=99s best efforts, there is still a > substantial but diminishing install base of XP. I was not aware Microsoft used an SSL2 ClientHello for SSL3. Thanks for poi= nting=20 that out. Is it not capable of sending an SSL3/TLS Hello at all? If it were= =20 properly configured to enable TLS1 and disable SSL2/3, would it send the pr= oper=20 TLS compatible Hello? (Microsoft really should've pushed an XP update to fl= ip=20 that switch years ago) > It=E2=80=99s fine for us to break compatibility with these clients, but l= et=E2=80=99s not > pretend it=E2=80=99s some ancient technology that doesn=E2=80=99t exist i= n the market > anymore. >=20 > Yoav Sad, but I guess that's true. :/ Dave From nobody Fri Dec 26 08:23:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223A41ACD71 for ; Wed, 24 Dec 2014 00:24:40 -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 96Op1aJ4K0j3 for ; Wed, 24 Dec 2014 00:24:38 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7938C1ACD97 for ; Wed, 24 Dec 2014 00:24:38 -0800 (PST) Received: by mail-qg0-f43.google.com with SMTP id z107so5495685qgd.2 for ; Wed, 24 Dec 2014 00:24:37 -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=UNY7HPMtvjT5PBC4lcnS27P8iHSTZBEnwkQCTXQjt5o=; b=v1B9ksTrjXv1MakaX0IuzDAL9/qhm5Y9J3co0PAb4vKQ0FMWdvHwtGFfXxKQOzTa67 lgTIK36JA7YjuWunJe4f5PKqia949jTYa694yry3r7QdUctKKOh6Wy3962tRZTu7zjTl NDh+TIO2xoGfhNb6sFpAAJAAsfE9ihdEhXbwH09NhzkxrLU08OHi5TprMDe4sWfD3YxG HkMbQjaA+tUJAFrKNYS6GxanSHH0kvpLQHFWwRkl4PqyaBCmmUrOy3pPKySEeoP8nImq ao88OAtArVOhIPZASWZslvVAFqIXrqKoltp9Y6yTGK3yctKNry61rN+j9eFdSzSXyVBA JNGw== X-Received: by 10.140.17.70 with SMTP id 64mr38007588qgc.53.1419409477789; Wed, 24 Dec 2014 00:24:37 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id a3sm20930205qag.22.2014.12.24.00.24.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Dec 2014 00:24:37 -0800 (PST) From: Dave Garrett To: Brian Smith Date: Wed, 24 Dec 2014 03:24:35 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201412240324.36125.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8bRQirobS3r6-3OrDpSnkv3Zh0c X-Mailman-Approved-At: Fri, 26 Dec 2014 08:23:03 -0800 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: [TLS] explicitly specify ClientHello record version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 08:24:40 -0000 On Tuesday, December 23, 2014 04:51:40 pm Brian Smith wrote: > I think further changes can be made to tighten up the text regarding > allowed record versions, but those changes are more open for debate. > For example, we might say that the ClientHello's record version MUST > be { 3, 1 } and that the version field in all other records MUST equal > the negotiated version. But, again, this can be done on top of your > changes. Making the revisions for that was straightforward enough. I've also made some small editorial changes to the backwards compatibility section to update things as well as make it a little easier to follow. https://github.com/tlswg/tls13-spec/pull/107 That plus the other PR for dealing with SSL should probably be enough to resolve issue #54, "Rewrite backward compatibility section to deal with TLS 1.3". I'm no expert on the implementation details of working with buggy severs, so it might be warranted to add more information here. I know some implementations already specify the ClientHello in this fashion, yet I don't know if there's a consensus on this topic. I would expect to wait until next year for those who wish to debate this, due to the holiday season. Dave From nobody Fri Dec 26 10:11:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E321A9123 for ; Fri, 26 Dec 2014 10:11:45 -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, 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 1w9_1bY6pQ-o for ; Fri, 26 Dec 2014 10:11:44 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 D22601A907A for ; Fri, 26 Dec 2014 10:11:43 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 4CEAB1C2039; Fri, 26 Dec 2014 19:11:41 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 152A31FE00B2; Fri, 26 Dec 2014 19:11:39 +0100 (CET) Date: Fri, 26 Dec 2014 19:11:39 +0100 From: Kurt Roeckx To: Dave Garrett Message-ID: <20141226181139.GA5321@roeckx.be> References: <201412221945.35644.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201412221945.35644.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sA6NVanSUQh_MzDAsz40dT3CLK4 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: Fri, 26 Dec 2014 18:11:46 -0000 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? On the other hand if you do receive such a client hello you're likely talking to old software that most likely isn't support anymore and might have various security issues. It might be a good indication of clients you prefer not to talk to. PS: I recently actually removed all the SSLv2 support from OpenSSL (in master) except for supporting receiving an SSLv2 compatible client hello. Kurt From nobody Fri Dec 26 11:12:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1EB1ACCDC for ; Fri, 26 Dec 2014 11:12:28 -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 FJGv4oe9a0cJ for ; Fri, 26 Dec 2014 11:12:27 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24C21ACCC7 for ; Fri, 26 Dec 2014 11:12:26 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id vy18so8151882iec.37 for ; Fri, 26 Dec 2014 11:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kt2ROB4ErSNlNZ4rWU5mQ6iHQfp97fqUOK+ngyLX4gQ=; b=wjTnm7fU2OQdLHUxVRYkYjY5PXh7ZoF9my9gHE8AGq74nqSaZLWNc2DK/ll1nofp5K d2+/LScqf3VoLFrc7Y1T2M7i/GYejIzhCKdSB29O343UOfrvRp+n4sr1RL8pc/F4P9sg 3PMFCd+HWwQ1+J9DYuUu3S9SZyaTsVbBFcLlUXiccEntcekcfRoWivLQZWeEeVOnI8o7 4LL8mFp2mF0W6irNy5zXprS5m3EhBy/+P7InK3xeHcjXGBTBUep2TyY1JKGI/s2H4+wd zKSFuWq3gj8uYzSjDWx2VNzBi7pHluR6jePNvmEpFOePK7iGnkP5Rk9fr/ZJ+kw6NajT Nbsw== MIME-Version: 1.0 X-Received: by 10.107.15.73 with SMTP id x70mr39308013ioi.8.1419621145872; Fri, 26 Dec 2014 11:12:25 -0800 (PST) Received: by 10.107.134.170 with HTTP; Fri, 26 Dec 2014 11:12:25 -0800 (PST) In-Reply-To: <20141226181139.GA5321@roeckx.be> References: <201412221945.35644.davemgarrett@gmail.com> <20141226181139.GA5321@roeckx.be> Date: Fri, 26 Dec 2014 14:12:25 -0500 Message-ID: From: Jeffrey Walton To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/niIzGO_1eiTbYzOPMs6Gi10htT8 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 Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 19:12:29 -0000 > PS: I recently actually removed all the SSLv2 support from OpenSSL > (in master) except for supporting receiving an SSLv2 compatible > client hello. > Some folks need this for auditing systems. I have a custom build of SSLscan that exercises it. Eventually, we will get to a point where lack of back patching new features to into a branch coupled with lack of SSLv2 support testing means we won't be able to perform a thorough audit. Jeff From nobody Fri Dec 26 15:26:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FD91ACFC8 for ; Fri, 26 Dec 2014 15:26:30 -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, 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 SUhOOKnqPb7K for ; Fri, 26 Dec 2014 15:26:28 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 182B31A90A5 for ; Fri, 26 Dec 2014 15:26:27 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 077241C2039; Sat, 27 Dec 2014 00:26:26 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 796641FE00B2; Sat, 27 Dec 2014 00:26:25 +0100 (CET) Date: Sat, 27 Dec 2014 00:26:25 +0100 From: Kurt Roeckx To: Dave Garrett Message-ID: <20141226232625.GA7199@roeckx.be> References: <201412221945.35644.davemgarrett@gmail.com> <20141226181139.GA5321@roeckx.be> <201412261747.00959.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201412261747.00959.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-YwG3zt0XcBmqFbh3q7nEyIf-Q8 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: Fri, 26 Dec 2014 23:26:30 -0000 On Fri, Dec 26, 2014 at 05:47:00PM -0500, Dave Garrett wrote: > On Friday, December 26, 2014 01:11:39 pm Kurt Roeckx wrote: > > On the other hand if you do receive such a client hello you're > > likely talking to old software that most likely isn't support > > anymore and might have various security issues. It might be a > > good indication of clients you prefer not to talk to. > > My primary concern is that continuing to maintain official support for a > deprecated format from an insecure protocol leaves a significant amount of > complexity in place just to support woefully out-of-date implementations. Isn't it up to the implementations to decide if they still wish to support it? Does it do any harm to support it other then possible talking to outdated software? (It currently seems to be about 150 lines in OpenSSL, and it seem clear to me that it's just to support that.) > I think that many people agree that one of the main goals of TLS 1.3 needs to be > reduction of complexity. The more legacy features that are removed, the simpler > the protocol will be, and the safer it will be to implement properly. Even if TLS 1.3 reduces complexity, it's not suddenly going to make any implementation less complex. I think it's likely going to make things more complex. It's not like we're going drop support for the older protocols at the same time. We'll add one more that is different then the others. > Refusing to connect to these old clients will also, hopefully, get some of them > upgraded to new ones that actually work with modern protocols. Or prevent the adoption of the new software because it breaks things. > > 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? > > If there were a simple way to detect that, without having to support the old > hello format, and reply with a simple refusal that triggered a negotiation using > TLS, then that might be preferable. However, at some point it's just not worth > it. You just have to cut off backwards compatibility, eventually. > > Also, I'm not sure I agree that TLS 1.0 is still acceptable. Personally, I'd > like to see an official deprecation and an attempt to force implementations to > upgrade to at least 1.2 at some point. HTTP/2 should help here, I hope. (at > least on the web) It would be nice to not have to panic and handle some fatal > flaw in TLS 1.0 like had to be done for SSL 3. I would also like to get rid of TLS 1.0. It's just not realistic to do this at this point in time. Only about 50% of the http servers support TLS 1.2 currently. Kurt From nobody Sat Dec 27 04:29:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ABE1AD510 for ; Sat, 27 Dec 2014 04:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.413 X-Spam-Level: X-Spam-Status: No, score=-104.413 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_37=0.6, 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 JjZjAxhLsglD for ; Sat, 27 Dec 2014 04:29:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id EF6AC1A6FA9 for ; Sat, 27 Dec 2014 04:29:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8D2F3181C67; Sat, 27 Dec 2014 04:28:17 -0800 (PST) To: pgut001@cs.auckland.ac.nz, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, joe@salowey.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141227122817.8D2F3181C67@rfc-editor.org> Date: Sat, 27 Dec 2014 04:28:17 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ir9BiN-5qboWFzJdk154L2ogMAg Cc: rfc-editor@rfc-editor.org, tls@ietf.org Subject: [TLS] [Technical Errata Reported] RFC7366 (4212) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 12:29:09 -0000 The following errata report has been submitted for RFC7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7366&eid=4212 -------------------------------------- Type: Technical Reported by: Peter Gutmann Section: 3 Original Text ------------- In TLS [2] notation, the MAC calculation for TLS 1.0 without the explicit Initialization Vector (IV) is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + TLSCipherText.length + ENC(content + padding + padding_length)); and for TLS 1.1 and greater with an explicit IV is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + TLSCipherText.length + IV + ENC(content + padding + padding_length)); Corrected Text -------------- Note that the length value used for the MAC computation differs from the value of the 'uint16 length' field in the TLSCiphertext record as encoded on the wire. The encoded TLSCiphertext record contains both the ciphtertext and the MAC, while the MAC calculation is performed only over the ciphertext. The length value encoded in the TLSCiphertext record is therefore 'length' while the length value used in the MAC calculation is 'length - SecurityParameters.mac_length'. More formally, if: TLSCiphertext.enc_content = ENC(content + padding + padding_length) then in TLS notation the MAC calculation for TLS 1.0 without the explicit Initialization Vector (IV) is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + length of (TLSCiphertext.enc_content) + TLSCiphertext.enc_content); and for TLS 1.1 and greater with an explicit IV is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + length of (IV + TLSCiphertext.enc_content) + IV + TLSCiphertext.enc_content); Notes ----- After the RFC was published a new set of implementers (who hadn't been part of the pre-publication interop testing) pointed out that the text covering the use of length values could be interpreted in two different ways. This correction attempts to remove the ambiguity by making explicit what's MACd vs. what's encoded on the wire. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7366 (draft-ietf-tls-encrypt-then-mac-03) -------------------------------------- Title : Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Publication Date : September 2014 Author(s) : P. Gutmann Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sat Dec 27 07:32:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2901A88A7 for ; Sat, 27 Dec 2014 07:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VURc5P-NYeNR for ; Sat, 27 Dec 2014 07:32:03 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249541A88B7 for ; Sat, 27 Dec 2014 07:32:03 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so10454616lbj.27 for ; Sat, 27 Dec 2014 07:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LuyoyW2FQyOCGN6eZ+9KLl0wr0RcaupY+N5ihy57nyo=; b=VOT/6wzLKy+UXwvXASG63xQ5abG3EGdZj70POrCn7gRVOCkti0cAJX1IQhbrZeJ9B/ FD5XBhW3wamGIDgUGOUa2a212mF90XK39oQnFfnaF/9WtEnK5e3C24n9iAle1OP41GXp BGdB18wRr/5FMjd+51QaSjvcwO4sWl7oIgZMdWJtLHfxENkpcWT056jSvSG7IRw5/9Pu 9nzku4C9030K6D4L7/T51UXlMX8upoH4r4r8/az0wcnxKijbgyyK8oeMIVxF+F3KSBou 4QKxgNY4QKKSUmgHHMRuS5bIxFrKE9v97UeIGLprOmJLp0AoC6HVpL1YotanKcVaKBr9 MQHQ== MIME-Version: 1.0 X-Received: by 10.112.119.201 with SMTP id kw9mr47588153lbb.99.1419694321436; Sat, 27 Dec 2014 07:32:01 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.114.225 with HTTP; Sat, 27 Dec 2014 07:32:01 -0800 (PST) In-Reply-To: References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> Date: Sat, 27 Dec 2014 16:32:01 +0100 X-Google-Sender-Auth: 9XZQL8BTYJ2tjkv1YVmXpFqiLXY Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UjZpSaehzWBIUZAAytn_8pIIOlM Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 15:32:04 -0000 On Wed, Dec 24, 2014 at 10:01 PM, Eric Rescorla wrote: > Thanks for the clarification. What do other people think about this > suggestion? I think it's a great idea. I'll send a PR after the holiday unless someone beats me to it. Cheers AGL From nobody Sat Dec 27 08:50:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0D1A8970 for ; Sat, 27 Dec 2014 08:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i-_tsK1b-w1k for ; Sat, 27 Dec 2014 08:50:05 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E4B1A896B for ; Sat, 27 Dec 2014 08:50:04 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so8134499qcy.32 for ; Sat, 27 Dec 2014 08:50:04 -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; bh=eiJgH65Nf6t67rLu5xJtxtq3m2sAHqHPUheD9upAegc=; b=K4GTEsMsHs7//OKCU+/cOPy41Y1k4v+YON+GZhD1xMz1Slr3XFDvrV52VMYgTO6tjc n0iyw/2lH1STEe2dv+rUlKhh4cfb5HEMOv/otQPAN6e9Bjubm13JM0M9G5KcdELxSO7Q PXjuNnG4Ngxp9aD55xIceybysGtrlq3+CSLMZl6t4vNOr9BU5l5XWVrWDg1dcfSgXG9B o05FoLaoQsqlh3GkYJOdEu0W9y65b9QWADRMIIw5bHmNq3CU4zh+sa8iu9VMeBqeYvKL fJ4v4hk5Fx0LaXHxY24MRkBwKewPwSfSp1QNuekEc96IXktbI+w2pPzhDCqZmJ6PRXNt STHA== X-Gm-Message-State: ALoCoQmPVcFA1TPZJ55o2Y/cT76WJJDrz8YvuNpgtBsUXif2CEGQ7wVc/Ou382rGiEaNjSgon1r9 X-Received: by 10.224.131.4 with SMTP id v4mr75612455qas.99.1419699004139; Sat, 27 Dec 2014 08:50:04 -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 t2sm28968569qae.6.2014.12.27.08.50.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Dec 2014 08:50:03 -0800 (PST) Message-ID: <549EE32B.7050703@nthpermutation.com> Date: Sat, 27 Dec 2014 11:49:47 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tls@ietf.org References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050502030803040508000004" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jEb49EeTtkSsihouCg4iVnQDhbM Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 16:50:07 -0000 This is a multi-part message in MIME format. --------------050502030803040508000004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/24/2014 4:01 PM, Eric Rescorla wrote: > > > > > > > That is, it would be digital signature of: > > > > > > - 32 padding bytes (or ClientRandom) > > > - 32 padding bytes (or ServerRandom) > > > - Context string > > > - Ciphersuite ID (to provode domain separation) > > > - handshake_hash(transcript) > > > > > > > So to be clear, you are proposing that we might (for instance) have > > a signature with (say) SHA-1 over a handshake hash computed with > > SHA-256? > > Yes. > > E.g ECDSA/SHA1 for signatures and > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > for connection. That would result in SHA-1 signature over SHA-256 > hash. > > > The other way around can't happen with any current ciphersuite > (because > every current one has prf-hash of either SHA-256 or SHA-384). > > > Thanks for the clarification. What do other people think about this > suggestion? > > -Ekr Three items - Doing it this way means that SHA1 is a permanent part of TLS1.3 - every implementation will need it. It also means that the security of the handshake transcript part is no better than that given by SHA1 so if further attacks on SHA1 are discovered, the fix will be TLS1.4. That applies regardless of which hash we select. That said, SHA256 is probably a better choice that SHA1 given that SHA1 is deprecated for signatures [while this isn't exactly using it in signatures, I will note that ECDSA (SHA256(SHA1(data)) has the same strength as ECDSA(SHA1(data)) - I would have to think a bit whether the addition of the 4 possibly fixed (or chosen) elements would increase the security back to SHA256 levels] If the client is willing to negotiate to TLS1.2, the client will still need to run multiple hashes in parallel until it gets the tls version selection confirmation (and the cipher suite selection) from the server as we're not changing how the TLS1.2 signature is calculated. Lastly, if we do the above, please add a uint32 length(transcript) value before handshake_hash(transcript) to at least make extension attacks a bit more difficult. Mike > > > > -Ilari > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------050502030803040508000004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 12/24/2014 4:01 PM, Eric Rescorla wrote:

> >
> > That is, it would be digital signature of:
> >
> > - 32 padding bytes (or ClientRandom)
> > - 32 padding bytes (or ServerRandom)
> > - Context string
> > - Ciphersuite ID (to provode domain separation)
> > - handshake_hash(transcript)
> >
>
> So to be clear, you are proposing that we might (for instance) have
> a signature with (say) SHA-1 over a handshake hash computed with
> SHA-256?

Yes.

E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
for connection. That would result in SHA-1 signature over SHA-256 hash.


The other way around can't happen with any current ciphersuite (because
every current one has prf-hash of either SHA-256 or SHA-384).

Thanks for the clarification. What do other people think about this suggestion?

-Ekr

Three items -

Doing it this way means that SHA1 is a permanent part of TLS1.3 - every implementation will need it. It also means that the security of the handshake transcript part is no better than that given by SHA1 so if further attacks on SHA1 are discovered, the fix will be TLS1.4. That applies regardless of which hash we select. That said, SHA256 is probably a better choice that SHA1 given that SHA1 is deprecated for signatures [while this isn't exactly using it in signatures, I will note that ECDSA (SHA256(SHA1(data)) has the same strength as ECDSA(SHA1(data)) - I would have to think a bit whether the addition of the 4 possibly fixed (or chosen) elements would increase the security back to SHA256 levels]

If the client is willing to negotiate to TLS1.2, the client will still need to run multiple hashes in parallel until it gets the tls version selection confirmation (and the cipher suite selection) from the server as we're not changing how the TLS1.2 signature is calculated.

Lastly, if we do the above, please add a uint32 length(transcript) value before handshake_hash(transcript) to at least make extension attacks a bit more difficult.



Mike





-Ilari



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

--------------050502030803040508000004-- From nobody Sat Dec 27 08:59:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16051A8971 for ; Sat, 27 Dec 2014 08:58:56 -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 BerRjXZWkZId for ; Sat, 27 Dec 2014 08:58:54 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2BB1A896B for ; Sat, 27 Dec 2014 08:58:53 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id a41so5736809yho.28 for ; Sat, 27 Dec 2014 08:58: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; bh=zVNSl4t/WuOaftfKxIrpoFPPYoyI0bKP7VseOmq26sk=; b=qqKPIxEeUzv10LJjdocMfgRxteej8PAtNl99EDqQNAkZDzHtWEaeniPImhlAoiEZ9Y +jIb5ejLEg4BiCaJ63QQOldlzuajsI7V2kc9U+yyxDwTKG/VcG5KZsYOUGTycTMw7Xyo kmpJPwEeOlCcYckHU1GcLTYIad6nDG8igAY23e0n+DMOYdpnfGWRp6NbmqYEpH81EdkA piebKuxh69/Ldlxp4FQENcYA1wAR0X9eRYuLOTpDUoXN06bLDutU7qjZvcVGZp8aXdlx AaMNG3NPqRfBp5K66WZbijk1lHDhZ833G8vOa2HhHA6w4s2NrKDLbZyGFObrz4P6DM8t J1hA== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr34705747yhc.65.1419699532957; Sat, 27 Dec 2014 08:58:52 -0800 (PST) Received: by 10.170.207.6 with HTTP; Sat, 27 Dec 2014 08:58:52 -0800 (PST) Received: by 10.170.207.6 with HTTP; Sat, 27 Dec 2014 08:58:52 -0800 (PST) In-Reply-To: <549EE32B.7050703@nthpermutation.com> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> <549EE32B.7050703@nthpermutation.com> Date: Sat, 27 Dec 2014 11:58:52 -0500 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: multipart/alternative; boundary=089e0122971c598d66050b358e6d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NZxAmp_SROG86eu6qMg5rB2tBJs Cc: tls@ietf.org Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 16:58:57 -0000 --089e0122971c598d66050b358e6d Content-Type: text/plain; charset=UTF-8 On Dec 27, 2014 11:50 AM, "Michael StJohns" wrote: > > On 12/24/2014 4:01 PM, Eric Rescorla wrote: >> >> >>> > > >>> > > That is, it would be digital signature of: >>> > > >>> > > - 32 padding bytes (or ClientRandom) >>> > > - 32 padding bytes (or ServerRandom) >>> > > - Context string >>> > > - Ciphersuite ID (to provode domain separation) >>> > > - handshake_hash(transcript) >>> > > >>> > >>> > So to be clear, you are proposing that we might (for instance) have >>> > a signature with (say) SHA-1 over a handshake hash computed with >>> > SHA-256? >>> >>> Yes. >>> >>> E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>> for connection. That would result in SHA-1 signature over SHA-256 hash. >>> >>> >>> The other way around can't happen with any current ciphersuite (because >>> every current one has prf-hash of either SHA-256 or SHA-384). >> >> >> Thanks for the clarification. What do other people think about this suggestion? >> >> -Ekr > > > Three items - > > Doing it this way means that SHA1 is a permanent part of TLS1.3 - every implementation will need it. It also means that the security of the handshake transcript part is no better than that given by SHA1 so if further attacks on SHA1 are discovered, the fix will be TLS1.4. That applies regardless of which hash we select. That said, SHA256 is probably a better choice that SHA1 given that SHA1 is deprecated for signatures [while this isn't exactly using it in signatures, I will note that ECDSA (SHA256(SHA1(data)) has the same strength as ECDSA(SHA1(data)) - I would have to think a bit whether the addition of the 4 possibly fixed (or chosen) elements would increase the security back to SHA256 levels] I think you are misreading. A certificate may use SHA1 as a supported signing algorithm, while SHA256 is the PRF. In short the order got flipped around, or I misread AGL's proposal/example. The reason for this proposal is a known weakness in TLS 1.2 that narrowly escaped being a vulnerability. > > If the client is willing to negotiate to TLS1.2, the client will still need to run multiple hashes in parallel until it gets the tls version selection confirmation (and the cipher suite selection) from the server as we're not changing how the TLS1.2 signature is calculated. > > Lastly, if we do the above, please add a uint32 length(transcript) value before handshake_hash(transcript) to at least make extension attacks a bit more difficult. This doesn't make any sense. We're talking about signatures, not PRF MAC. Length extension doesn't matter. > > > > Mike > > > >> >>> >>> >>> >>> >>> -Ilari >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e0122971c598d66050b358e6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 27, 2014 11:50 AM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 12/24/2014 4:01 PM, Eric Rescorla wrote:
>>
>>
>>> > >
>>> > > That is, it would be digital signature of:
>>> > >
>>> > > - 32 padding bytes (or ClientRandom)
>>> > > - 32 padding bytes (or ServerRandom)
>>> > > - Context string
>>> > > - Ciphersuite ID (to provode domain separation)
>>> > > - handshake_hash(transcript)
>>> > >
>>> >
>>> > So to be clear, you are proposing that we might (for inst= ance) have
>>> > a signature with (say) SHA-1 over a handshake hash comput= ed with
>>> > SHA-256?
>>>
>>> Yes.
>>>
>>> E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128= _GCM_SHA256
>>> for connection. That would result in SHA-1 signature over SHA-= 256 hash.
>>>
>>>
>>> The other way around can't happen with any current ciphers= uite (because
>>> every current one has prf-hash of either SHA-256 or SHA-384).<= br> >>
>>
>> Thanks for the clarification. What do other people think about thi= s suggestion?
>>
>> -Ekr
>
>
> Three items -
>
> Doing it this way means that SHA1 is a permanent part of TLS1.3 - ever= y implementation will need it.=C2=A0 It also means that the security of the= handshake transcript part is no better than that given by SHA1 so if furth= er attacks on SHA1 are discovered, the fix will be TLS1.4.=C2=A0 That appli= es regardless of which hash we select.=C2=A0=C2=A0 That said, SHA256 is pro= bably a better choice that SHA1 given that SHA1 is deprecated for signature= s [while this isn't exactly using it in signatures, I will note that=C2= =A0 ECDSA (SHA256(SHA1(data)) has the same strength as ECDSA(SHA1(data)) - = I would have to think a bit whether the addition of the 4 possibly fixed (o= r chosen) elements would increase the security back to SHA256 levels]

I think you are misreading. A certificate may use SHA1 as a = supported signing algorithm, while SHA256 is the PRF. In short the order go= t flipped around, or I misread AGL's proposal/example.

The reason for this proposal is a known weakness in TLS 1.2 = that narrowly escaped being a vulnerability.

>
> If the client is willing to negotiate to TLS1.2, the client will still= need to run multiple hashes in parallel until it gets the tls version sele= ction confirmation (and the cipher suite selection) from the server as we&#= 39;re not changing how the TLS1.2 signature is calculated.=C2=A0
>
> Lastly, if we do the above, please add a uint32 length(transcript) val= ue before handshake_hash(transcript) to at least make extension attacks a b= it more difficult.=C2=A0

This doesn't make any sense. We're talking about sig= natures, not PRF MAC. Length extension doesn't matter.

>
>
>
> Mike
>
>
>
>> =C2=A0
>>>
>>>
>>>
>>>
>>> -Ilari
>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.= ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--089e0122971c598d66050b358e6d-- From nobody Sat Dec 27 09:01:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CA81A8970 for ; Sat, 27 Dec 2014 09:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g036eSMAdz-3 for ; Sat, 27 Dec 2014 09:01:35 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2346C1A896B for ; Sat, 27 Dec 2014 09:01:34 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id q1so9635346lam.5 for ; Sat, 27 Dec 2014 09:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UPJGz8RBH+1UEDpM8OSoeBS55R8PYczMly06QxrsoKQ=; b=f2sWmFduWi/lgHHGntHp3N77oK94SEIS7K8oA5hst9nnV7sMzNqx8RAodSSHrl8Nbd EqjDOTtJFEtfXTfV8bN08S16OD3zVDTo8yzVFUSwmQf/52hzG9V1s5BPs8db1kX9T5+8 Hjh4sRefrNfQlqfzFVEKxTEM5qQ7qR1e/ogzyfITCj/3yevjnRQmdpOhpqtlR0ycoYN0 0BlVpVZRyBUyEtaZOvjMH5VubaqQyfGF5tUlUkv9DxW4rt8qudMAs8vQOT6m5X/cAHcD q7hr+04QfjnyJ3LIk0mniYP3o8u1A5SJ/eRwfm7176NnlwuMomCsYUm56IhLlgAcbfRR 5HsA== MIME-Version: 1.0 X-Received: by 10.112.119.201 with SMTP id kw9mr47882560lbb.99.1419699692526; Sat, 27 Dec 2014 09:01:32 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.114.225 with HTTP; Sat, 27 Dec 2014 09:01:32 -0800 (PST) In-Reply-To: <549EE32B.7050703@nthpermutation.com> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> <549EE32B.7050703@nthpermutation.com> Date: Sat, 27 Dec 2014 18:01:32 +0100 X-Google-Sender-Auth: WBVK0xbcv1Cul9uPrqStm_X9sQM Message-ID: From: Adam Langley To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NpDw4pd5JJzKBj4PLVeL8g0J1LE Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 17:01:36 -0000 On Sat, Dec 27, 2014 at 5:49 PM, Michael StJohns wrote: > Doing it this way means that SHA1 is a permanent part of TLS1.3 The signature hash is negotiated, not fixed to SHA-1. TLS 1.2 (and, currently, 1.3) depend on SHA-256 fundamentally as it's the weakest handshake hash allowed. > at least make extension attacks a bit more difficult. Length extension attacks allow hashes of some other input messages to be calculated. Since the input to the signature hashes is already public, that's not a problem. Cheers AGL From nobody Sat Dec 27 09:02:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A042B1A9060 for ; Sat, 27 Dec 2014 09:01:59 -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 uAJAV1W0GIsc for ; Sat, 27 Dec 2014 09:01:57 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2431A8F51 for ; Sat, 27 Dec 2014 09:01:56 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so16021766wgg.25 for ; Sat, 27 Dec 2014 09:01:55 -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=CtL5BTHjUnIMpY4jvLvfVfo+5myHyCKiMjabE48QScs=; b=GHkH+i+TD8gHiUZOy3UOYhhDOX8ZYIkv9p07GCxsBuGibNlJB3n+1bfXFfaT8tn5ky uBGIktjuS3etYkn/KulEn+gA5kotbmKMks5BcCCaEXDoQBjkxliJUSkBwl5UUzhlh/kt 2fK2AdQiqI2/cLyyjSOburcmdfaiGXDHGAPymsIsjipAN3azTFPzEiQ9MiVfNXwK8Mti h9x02YU8QBc7ZS4CpW2VKpbG4QAQ898gOTMFU/hG5/qyKM9itCruZTOc0cpUzBd7Y09p RNuFzXzj0P+YWYq6Px2kXztp3jNkHJ1GBie0/9EE58N63/NYbW2U+dfgBA9BLm++yBdJ fU8A== X-Gm-Message-State: ALoCoQlKyxJcFQOm9VHPmDslh3k5aXsLm9haG7gmtsESC8Xs3+6AmwapTQeZEESlz4EC0RkpFopY X-Received: by 10.180.85.33 with SMTP id e1mr77808358wiz.61.1419699715598; Sat, 27 Dec 2014 09:01:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Sat, 27 Dec 2014 09:01:15 -0800 (PST) In-Reply-To: <549EE32B.7050703@nthpermutation.com> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> <549EE32B.7050703@nthpermutation.com> From: Eric Rescorla Date: Sat, 27 Dec 2014 09:01:15 -0800 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d044280743c81f3050b359963 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hJAGn3qgJfvIGEvx2DTsAC-kR3M Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 17:01:59 -0000 --f46d044280743c81f3050b359963 Content-Type: text/plain; charset=UTF-8 On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns wrote: > On 12/24/2014 4:01 PM, Eric Rescorla wrote: > > > > > >> > > That is, it would be digital signature of: >> > > >> > > - 32 padding bytes (or ClientRandom) >> > > - 32 padding bytes (or ServerRandom) >> > > - Context string >> > > - Ciphersuite ID (to provode domain separation) >> > > - handshake_hash(transcript) >> > > >> > >> > So to be clear, you are proposing that we might (for instance) have >> > a signature with (say) SHA-1 over a handshake hash computed with >> > SHA-256? >> >> Yes. >> >> E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >> for connection. That would result in SHA-1 signature over SHA-256 hash. >> >> >> The other way around can't happen with any current ciphersuite (because >> every current one has prf-hash of either SHA-256 or SHA-384). > > > Thanks for the clarification. What do other people think about this > suggestion? > > -Ekr > > > Three items - > > Doing it this way means that SHA1 is a permanent part of TLS1.3 - every > implementation will need it. It also means that the security of the > handshake transcript part is no better than that given by SHA1 so if > further attacks on SHA1 are discovered, the fix will be TLS1.4. > I don't believe that this is correct. - In the current draft, you sign transcript using whatever signature/hash pair you have selected. Call that hash H1. So, you sign H1(transcript). - In AGL's existing PR, you sign H1(context || H1(transcript)) - In Ilari's proposal, you sign H1(context || H2(transcript)) where H2 is that Hash used by the PRF, which is SHA-256 for the current cipher suites. So, in the case where you want to sign with RSA-SHA1, you would in the first case just sign with SHA1, in the second do SHA1(... || SHA1()), and in the third case do SHA1(...., || SHA256()). > If the client is willing to negotiate to TLS1.2, the client will still > need to run multiple hashes in parallel until it gets the tls version > selection confirmation (and the cipher suite selection) from the server as > we're not changing how the TLS1.2 signature is calculated. > Yes. This is at least in principle also true with TLS 1.3 if we were to define (and the client were to support) a PRF based on some other hash, such as SHA-512. -Ekr --f46d044280743c81f3050b359963 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
On 12/24/2014 4:01 PM, Eric Rescorla wrote:

> >
> > That is, it would be digital signature of:
> >
> > - 32 padding bytes (or ClientRandom)
> > - 32 padding bytes (or ServerRandom)
> > - Context string
> > - Ciphersuite ID (to provode domain separation)
> > - handshake_hash(transcript)
> >
>
> So to be clear, you are proposing that we might (for instance) have
> a signature with (say) SHA-1 over a handshake hash computed with
> SHA-256?

Yes.

E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
for connection. That would result in SHA-1 signature over SHA-256 hash.


The other way around can't happen with any current ciphersuite (because
every current one has prf-hash of either SHA-256 or SHA-384).

Thanks for the clarification. What do other people think about this suggestion?

-Ekr

 Three items -

Doing it this way means that SHA1 is a permanent part of TLS1.3 - every implementation will need it.=C2=A0 It also means that the securit= y of the handshake transcript part is no better than that given by SHA1 so if further attacks on SHA1 are discovered, the fix will be TLS1.4.=C2=A0

I don't believ= e that this is correct.

- In the current draft, yo= u sign transcript using whatever signature/hash pair
=C2=A0 you h= ave selected. Call that hash H1. So, you sign H1(transcript).
- In AGL's existing PR, you sign H1(context || H1(transcrip= t))

- In Ilari's proposal, you sign H1(con= text || H2(transcript)) where H2 is
=C2=A0 that Hash used by the = PRF, which is SHA-256 for the current cipher
=C2=A0 suites.
=

So, in the case where you want to sign with RSA-SHA1, y= ou would in the
first case just sign with SHA1, in the second do = SHA1(... || SHA1()),
and in the third case do SHA1(...., || SHA25= 6()).


=C2=A0
If the client is willing to negotiate to TLS1.2, the client will still need to run multiple hashes in parallel until it gets the tls version selection confirmation (and the cipher suite selection) from the server as we're not changing how the TLS1.2 signature is calculated.=C2=A0

Yes. This = is at least in principle also true with TLS 1.3 if we were to define
<= div>(and the client were to support) a PRF based on some other hash, such
as SHA-512.

-Ekr

--f46d044280743c81f3050b359963-- From nobody Sat Dec 27 09:41:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C58E1A8AB1 for ; Sat, 27 Dec 2014 09:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xUvQOuchNZDw for ; Sat, 27 Dec 2014 09:41:19 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04CD1A8AA0 for ; Sat, 27 Dec 2014 09:41:19 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id dc16so7719139qab.8 for ; Sat, 27 Dec 2014 09:41:18 -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=vUkAqQgGkiO7QBq+QI7avUpLr1W4B88qqVa0lktxdII=; b=DEItS3GLHaCZjd4Z6YgYiUppfuYJOtEQbGoZAwdXqLvg5zBTgaXHxor25kyWxcxj0G 2XwNcXPLH22/Jntxpvr9qWj3/zhIDRuijXHSNhIeORKGUop+DajeRGoW4zOndnPTb422 hlZwailEepp2jRINibnaIKQLonrljT6JWfH+BFhqK6TRKx/lZMR7wFdioUHoe1Hr349b x5oUg6cgRg2FBafmmL08VviTDK9gOXrtvkzPZNMEB10LheDfkrPsrfmfHPedKQlJHDB+ KBcqMR32qPIY8H0mLjsXVeqj1hNW0uxYIzUxZv8+lqdiVdVRLrkRz1vXWj5eVpQ0e5lB EGKw== X-Gm-Message-State: ALoCoQkPV5BeVLpgRH79VATpejrgTwvBeatxWbWb638hckdUqf+JroMSYTmcNGgLs2Kus3raMIWl X-Received: by 10.224.37.5 with SMTP id v5mr79057507qad.25.1419702078842; Sat, 27 Dec 2014 09:41:18 -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 l7sm29041483qai.37.2014.12.27.09.41.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Dec 2014 09:41:18 -0800 (PST) Message-ID: <549EEF43.3020608@nthpermutation.com> Date: Sat, 27 Dec 2014 12:41:23 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Eric Rescorla References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> <549EE32B.7050703@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000104090304020703060406" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4BZTanduoaAVvm9q9YRQ-EgY_W8 Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 17:41:23 -0000 This is a multi-part message in MIME format. --------------000104090304020703060406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/27/2014 12:01 PM, Eric Rescorla wrote: > > > On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns > > wrote: > > On 12/24/2014 4:01 PM, Eric Rescorla wrote: >> >> > > >> > > That is, it would be digital signature of: >> > > >> > > - 32 padding bytes (or ClientRandom) >> > > - 32 padding bytes (or ServerRandom) >> > > - Context string >> > > - Ciphersuite ID (to provode domain separation) >> > > - handshake_hash(transcript) >> > > >> > >> > So to be clear, you are proposing that we might (for >> instance) have >> > a signature with (say) SHA-1 over a handshake hash computed >> with >> > SHA-256? >> >> Yes. >> >> E.g ECDSA/SHA1 for signatures and >> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >> for connection. That would result in SHA-1 signature over >> SHA-256 hash. >> >> >> The other way around can't happen with any current >> ciphersuite (because >> every current one has prf-hash of either SHA-256 or SHA-384). >> >> >> Thanks for the clarification. What do other people think about >> this suggestion? >> >> -Ekr > > Three items - > > Doing it this way means that SHA1 is a permanent part of TLS1.3 - > every implementation will need it. It also means that the > security of the handshake transcript part is no better than that > given by SHA1 so if further attacks on SHA1 are discovered, the > fix will be TLS1.4. > > > I don't believe that this is correct. > > - In the current draft, you sign transcript using whatever > signature/hash pair > you have selected. Call that hash H1. So, you sign H1(transcript). > > - In AGL's existing PR, you sign H1(context || H1(transcript)) > > - In Ilari's proposal, you sign H1(context || H2(transcript)) where H2 is > that Hash used by the PRF, which is SHA-256 for the current cipher > suites. > > So, in the case where you want to sign with RSA-SHA1, you would in the > first case just sign with SHA1, in the second do SHA1(... || SHA1()), > and in the third case do SHA1(...., || SHA256()). I admit to a lot of confusion then as to what you're trying to do here: 1) Client offers a number of cipher suites, with the result that there are multiple hash functions (PRF) possible. 2) Client uses which hash function to summarize the transcript? 3) Server knows which hash function the client is using so it can use the same one? Assuming it implements that. My point here is that I don't see that you're gaining anything as mostly the client doesn't know what the server knows until after the server tells it. The clients choice of which hash (or even which handshake signature algorithm) to use will be prone to error until it gets a response from the server confirming it. I think a client has to maintain parallel hash contexts for all offered hash functions until the server makes its choice known. So the way to get around the above is to: pick a set of handshake algorithms that everyone has to implement and make them fixed. Which led me to the "everyone has to implement SHA1" based on the prior email. > > > If the client is willing to negotiate to TLS1.2, the client will > still need to run multiple hashes in parallel until it gets the > tls version selection confirmation (and the cipher suite > selection) from the server as we're not changing how the TLS1.2 > signature is calculated. > > > Yes. This is at least in principle also true with TLS 1.3 if we were > to define > (and the client were to support) a PRF based on some other hash, such > as SHA-512. Yup - but AFAICT, the only restriction for what goes into the .prf slot in the cipher suite is that it must be a hash function useable with HMAC. I would expect future suites to propose SHA3 based hashes for example as well as regional/national hash functions. And I would expect those to work without changes to the underlying TLS protocol. Mike > > -Ekr > --------------000104090304020703060406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/27/2014 12:01 PM, Eric Rescorla wrote:


On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 12/24/2014 4:01 PM, Eric Rescorla wrote:

> >
> > That is, it would be digital signature of:
> >
> > - 32 padding bytes (or ClientRandom)
> > - 32 padding bytes (or ServerRandom)
> > - Context string
> > - Ciphersuite ID (to provode domain separation)
> > - handshake_hash(transcript)
> >
>
> So to be clear, you are proposing that we might (for instance) have
> a signature with (say) SHA-1 over a handshake hash computed with
> SHA-256?

Yes.

E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
for connection. That would result in SHA-1 signature over SHA-256 hash.


The other way around can't happen with any current ciphersuite (because
every current one has prf-hash of either SHA-256 or SHA-384).

Thanks for the clarification. What do other people think about this suggestion?

-Ekr

 Three items -

Doing it this way means that SHA1 is a permanent part of TLS1.3 - every implementation will need it.  It also means that the security of the handshake transcript part is no better than that given by SHA1 so if further attacks on SHA1 are discovered, the fix will be TLS1.4. 

I don't believe that this is correct.

- In the current draft, you sign transcript using whatever signature/hash pair
  you have selected. Call that hash H1. So, you sign H1(transcript).

- In AGL's existing PR, you sign H1(context || H1(transcript))

- In Ilari's proposal, you sign H1(context || H2(transcript)) where H2 is
  that Hash used by the PRF, which is SHA-256 for the current cipher
  suites.

So, in the case where you want to sign with RSA-SHA1, you would in the
first case just sign with SHA1, in the second do SHA1(... || SHA1()),
and in the third case do SHA1(...., || SHA256()).

I admit to a lot of confusion then as to what you're trying to do here:

1) Client offers a number of cipher suites, with the result that there are multiple hash functions (PRF) possible.
2) Client uses which hash function to summarize the transcript?
3) Server knows which hash function the client is using so it can use the same one?  Assuming it implements that.


My point here is that I don't see that you're gaining anything as mostly the client doesn't know what the server knows until after the server tells it.  The clients choice of which hash (or even which handshake signature algorithm) to use will be prone to error until it gets a response from the server confirming it.  I think a client  has to maintain parallel hash contexts for all offered hash functions until the server makes its choice known.

So the way to get around the above is to: pick a set of handshake algorithms that everyone has to implement and make them fixed.  Which led me to the "everyone has to implement SHA1" based on the prior email.



 
If the client is willing to negotiate to TLS1.2, the client will still need to run multiple hashes in parallel until it gets the tls version selection confirmation (and the cipher suite selection) from the server as we're not changing how the TLS1.2 signature is calculated. 

Yes. This is at least in principle also true with TLS 1.3 if we were to define
(and the client were to support) a PRF based on some other hash, such
as SHA-512.

Yup - but AFAICT, the only restriction for what goes into the .prf slot in the cipher suite is that it must be a hash function useable with HMAC.  I would expect future suites to propose SHA3 based hashes for example as well as regional/national hash functions.  And I would expect those to work without changes to the underlying TLS protocol.

Mike





-Ekr


--------------000104090304020703060406-- From nobody Sat Dec 27 10:07:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA53A1A8F50 for ; Sat, 27 Dec 2014 10:07:08 -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 Kf_iIID2Ywxg for ; Sat, 27 Dec 2014 10:07:06 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEFF1A8F49 for ; Sat, 27 Dec 2014 10:07:05 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so18986679wiv.11 for ; Sat, 27 Dec 2014 10:07:04 -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=87jzx8QsMpaX68l89hlK0vzaBrydfM4hqlmCXrpbgQU=; b=lHawqLmcHam/KsTfiYVAJcrA7H6uMQpWJLIKWm48a/E/JeWhKxxLVvGZEJabBI1Yaa acRrDZVH6dCy3d9XTD7TbKa0VU2X4uu0uVMwlmmIz8YeDA9rMtk4R67Y/WDn49vi+Yo3 P2WgRFH4aE7FzjKDrqYuVDekhTld7ZwoWf4MD+B5x7G6OQv18hS4sgKm5pqkxjlPbJ8T z1B1V0XWAy9KMa03pxUFoTiBdPwUa/sh1Rplk6ogt0aF2+TwimT65G/mEp0g0OlOR4Dw XhgcbhqsVkbgAijROZJd1s1r54jdBHB5ZKH1jIB1mrtkOC24Ih9JR9KbfkGXvwfkhGT2 cC7A== X-Gm-Message-State: ALoCoQlno7QeckVutlrrrjNxXNelkmM9H0Vx1hiNeXMn/qyfz2PFagMqkJB4hjE4E4k1WlFuhvnk X-Received: by 10.180.88.33 with SMTP id bd1mr79311991wib.10.1419703624303; Sat, 27 Dec 2014 10:07:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Sat, 27 Dec 2014 10:06:24 -0800 (PST) In-Reply-To: <549EEF43.3020608@nthpermutation.com> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> <549EE32B.7050703@nthpermutation.com> <549EEF43.3020608@nthpermutation.com> From: Eric Rescorla Date: Sat, 27 Dec 2014 10:06:24 -0800 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d0444e8fd3699a2050b36827a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Bf6QiJsqhnJLyVR4_WJsoDH-Emg Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 18:07:09 -0000 --f46d0444e8fd3699a2050b36827a Content-Type: text/plain; charset=UTF-8 On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns wrote: > On 12/27/2014 12:01 PM, Eric Rescorla wrote: > > > > On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns > wrote: > >> On 12/24/2014 4:01 PM, Eric Rescorla wrote: >> >> >> > > >>> > > That is, it would be digital signature of: >>> > > >>> > > - 32 padding bytes (or ClientRandom) >>> > > - 32 padding bytes (or ServerRandom) >>> > > - Context string >>> > > - Ciphersuite ID (to provode domain separation) >>> > > - handshake_hash(transcript) >>> > > >>> > >>> > So to be clear, you are proposing that we might (for instance) have >>> > a signature with (say) SHA-1 over a handshake hash computed with >>> > SHA-256? >>> >>> Yes. >>> >>> E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>> for connection. That would result in SHA-1 signature over SHA-256 hash. >>> >>> >>> The other way around can't happen with any current ciphersuite (because >>> every current one has prf-hash of either SHA-256 or SHA-384). >> >> >> Thanks for the clarification. What do other people think about this >> suggestion? >> >> -Ekr >> >> >> Three items - >> >> Doing it this way means that SHA1 is a permanent part of TLS1.3 - every >> implementation will need it. It also means that the security of the >> handshake transcript part is no better than that given by SHA1 so if >> further attacks on SHA1 are discovered, the fix will be TLS1.4. >> > > I don't believe that this is correct. > > - In the current draft, you sign transcript using whatever > signature/hash pair > you have selected. Call that hash H1. So, you sign H1(transcript). > > - In AGL's existing PR, you sign H1(context || H1(transcript)) > > - In Ilari's proposal, you sign H1(context || H2(transcript)) where H2 is > that Hash used by the PRF, which is SHA-256 for the current cipher > suites. > > So, in the case where you want to sign with RSA-SHA1, you would in the > first case just sign with SHA1, in the second do SHA1(... || SHA1()), > and in the third case do SHA1(...., || SHA256()). > > > I admit to a lot of confusion then as to what you're trying to do here: > > 1) Client offers a number of cipher suites, with the result that there are > multiple hash functions (PRF) possible. > 2) Client uses which hash function to summarize the transcript? > 3) Server knows which hash function the client is using so it can use the > same one? Assuming it implements that. > > > My point here is that I don't see that you're gaining anything as mostly > the client doesn't know what the server knows until after the server tells > it. The clients choice of which hash (or even which handshake signature > algorithm) to use will be prone to error until it gets a response from the > server confirming it. I think a client has to maintain parallel hash > contexts for all offered hash functions until the server makes its choice > known. > Yes, that's correct, but it's not the end of the analysis. Consider the diagram of the handshake from Figure 1: ClientHello ClientKeyShare --------> ServerHello ServerKeyShare [ChangeCipherSpec] EncryptedExtensions* Certificate* CertificateRequest* CertificateVerify* <-------- Finished [ChangeCipherSpec] Certificate* CertificateVerify* Finished --------> Application Data <-------> Application Data In the current design, the client does not know which digest algorithm the server will sign with until the receipt of the CertificateVerify message, so it must parallel hash the server's entire second flight. Similarly, the server does not know what the client will select so it must parallel hash its entire second flight and the client's Certificate message. By contrast, with the approach Ilari suggests, both sides only need to parallel hash up to the ServerHello. It's also worth noting that the potential set of algorithms used in the PRF is currently much narrower than the set of algorithms that implementations typically support for signature verification (consisting presently of just SHA-256) and so this also reduces the burden on both sides. If the client is willing to negotiate to TLS1.2, the client will still >> need to run multiple hashes in parallel until it gets the tls version >> selection confirmation (and the cipher suite selection) from the server as >> we're not changing how the TLS1.2 signature is calculated. >> > > Yes. This is at least in principle also true with TLS 1.3 if we were to > define > (and the client were to support) a PRF based on some other hash, such > as SHA-512. > > > Yup - but AFAICT, the only restriction for what goes into the .prf slot in > the cipher suite is that it must be a hash function useable with HMAC. I > would expect future suites to propose SHA3 based hashes for example as well > as regional/national hash functions. And I would expect those to work > without changes to the underlying TLS protocol. > Yes, that might well happen (though to my knowledge, we have not yet standardized any regional/national digest functions and I don't see a lot of enthusiasm for SHA-3). But both sides are already required to handle these cases because that is the hash used for the session_hash computation, so Ilari's proposal will often reduce the number of parallel hashes you have to run and will not increase it. -Ekr --f46d0444e8fd3699a2050b36827a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
On 12/27/2014 12:01 PM, Eric Rescorla wrote:


On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 12/24/2014 4:01 PM, Eric Rescorla wrote:

> >
> > That is, it would be digital signature of:
> >
> > - 32 padding bytes (or ClientRandom)
> > - 32 padding bytes (or ServerRandom)
> > - Context string
> > - Ciphersuite ID (to provode domain separation)
> > - handshake_hash(transcript)
> >
>
> So to be clear, you are proposing that we might (for instance) have
> a signature with (say) SHA-1 over a handshake hash computed with
> SHA-256?

Yes.

E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
for connection. That would result in SHA-1 signature over SHA-256 hash.


The other way around can't happen with any current ciphersuite (because
every current one has prf-hash of either SHA-256 or SHA-384).

Thanks for the clarification. What do other people think about this suggestion?

-Ekr

 Three items -

Doing it this way means that SHA1 is a permanent part of TLS1.3 - every implementation will need it.=C2=A0 It also means that the security of the handshake transcript part is no better than that given by SHA1 so if further attacks on SHA1 are discovered, the fix will be TLS1.4.=C2= =A0

I don't believe that this is correct.

- In the current draft, you sign transcript using whatever signature/hash pair
=C2=A0 you have selected. Call that hash H1. So, you sign H1(transcript).

- In AGL's existing PR, you sign H1(context || H1(transcript))

- In Ilari's proposal, you sign H1(context || H2(transcript)) where H2 is
=C2=A0 that Hash used by the PRF, which is SHA-256 for the current cipher
=C2=A0 suites.

So, in the case where you want to sign with RSA-SHA1, you would in the
first case just sign with SHA1, in the second do SHA1(... || SHA1()),
and in the third case do SHA1(...., || SHA256()).

I admit to a lot of confusion then as to what you're trying to do here:

1) Client offers a number of cipher suites, with the result that there are multiple hash functions (PRF) possible.
2) Client uses which hash function to summarize the transcript?
3) Server knows which hash function the client is using so it can use the same one?=C2=A0 Assuming it implements that.


My point here is that I don't see that you're gaining anything = as mostly the client doesn't know what the server knows until after th= e server tells it.=C2=A0 The clients choice of which hash (or even which handshake signature algorithm) to use will be prone to error until it gets a response from the server confirming it.=C2=A0 I think a clien= t=C2=A0 has to maintain parallel hash contexts for all offered hash functions until the server makes its choice known.

Yes, that's correct, but it's not the end of = the analysis. Consider the diagram of
the handshake from Figure 1= :

=C2=A0 =C2=A0 =C2=A0 ClientHello
= =C2=A0 =C2=A0 =C2=A0 ClientKeyShare =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerHe= llo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ServerKeyShare
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[ChangeCipherSpec]
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EncryptedExte= nsions*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Certificate*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 CertificateRequest*
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Certif= icateVerify*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Finished
= =C2=A0 =C2=A0 =C2=A0 [ChangeCipherSpec]
=C2=A0 =C2=A0 =C2=A0 Cert= ificate*
=C2=A0 =C2=A0 =C2=A0 CertificateVerify*
=C2=A0= =C2=A0 =C2=A0 Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 Application Data = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-------> =C2=A0 =C2=A0 =C2=A0 =C2= =A0Application Data


In the cu= rrent design, the client does not know which digest algorithm the server
will sign with until the receipt of the CertificateVerify message, = so it must
parallel hash the server's entire second flight. S= imilarly, the server does not
know what the client will select so= it must parallel hash its entire second
flight and the client= 9;s Certificate message. By contrast, with the approach
Ilari sug= gests, both sides only need to parallel hash up to the ServerHello.

It's also worth noting that the potential set of algo= rithms used in the PRF is
currently much narrower than the set of= algorithms that implementations
typically support for signature = verification (consisting presently of just
SHA-256) and so this a= lso reduces the burden on both sides.



If the client is willing to negotiate to TLS1.2, the client will still need to run multiple hashes in parallel until it gets the tls version selection confirmation (and the cipher suite selection) from the server as we're not changing how the TLS1.2 signature is calculated.=C2=A0

Yes. This is at least in principle also true with TLS 1.3 if we were to define
(and the client were to support) a PRF based on some other hash, such
as SHA-512.

Yup - but AFAICT, the only restriction for what goes into the .prf slot in the cipher suite is that it must be a hash function useable with HMAC.=C2=A0 I would expect future suites to propose SHA3 based hashes for example as well as regional/national hash functions.=C2=A0 A= nd I would expect those to work without changes to the underlying TLS protocol.

Yes, that might wel= l happen (though to my knowledge, we have not yet standardized any
regional/national digest functions and I don't see a lot of enthusias= m for SHA-3). But
both sides are already required to handle these= cases because that is the hash used
for the session_hash computa= tion, so Ilari's proposal will often reduce the number of
par= allel hashes you have to run and will not increase it.

=
-Ekr

--f46d0444e8fd3699a2050b36827a-- From nobody Sat Dec 27 12:34:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E348D1A9172 for ; Sat, 27 Dec 2014 12:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jeqh-XZ8JH_E for ; Sat, 27 Dec 2014 12:34:12 -0800 (PST) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B051A9170 for ; Sat, 27 Dec 2014 12:34:11 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id f51so8046410qge.4 for ; Sat, 27 Dec 2014 12:34:10 -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=4+setz/eYCHXqyyoumRZoKsHJo4FpIQRhhaDqLAssUo=; b=gKomtYLrFewto0e61UlWQHqo6lk4+zlT4pn180sjQ1Lhc4piP3oqcZv/+eJtuWelGm 6rwSSF4y5ENei4hfSwPwndYHXLEv2e8HLtSehkwhz9htCpxgp4vy2sa3X0lCmHnMNAGX nVQ6runcSY86M8YzA8+G5G9H1wwn21gZvXPaRpENJrLgU3fQSb+Dq1Xq46sr020eMRhD S9NE2Lr6dw5Kx/aBkoeK+CIIQ/BvnSDVKs/W8OkwKyy68UiPavtDRrj6mEV88AjgjpeT L36URF9T65bn6S+raWmStiZ9jSGa/R9SyutVoNEsZhWbsORppkaUnAN41Yv2jIbEcHSA 0sKQ== X-Gm-Message-State: ALoCoQnMS1FZE3uM4ZQ+EjVpdhqD+sBUgKy06wkVdUVsJQIvT46mSN1fFRAKDCPIaGM3XrR9iCSC X-Received: by 10.224.32.69 with SMTP id b5mr46747121qad.53.1419712450653; Sat, 27 Dec 2014 12:34:10 -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 f105sm29350906qge.1.2014.12.27.12.34.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Dec 2014 12:34:10 -0800 (PST) Message-ID: <549F17C7.8090003@nthpermutation.com> Date: Sat, 27 Dec 2014 15:34:15 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Eric Rescorla References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> <549EE32B.7050703@nthpermutation.com> <549EEF43.3020608@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030300080206020408040507" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/av47OEhAO-ECdg_X_rFONrN4h14 Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 20:34:15 -0000 This is a multi-part message in MIME format. --------------030300080206020408040507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/27/2014 1:06 PM, Eric Rescorla wrote: > > > On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns > > wrote: > > On 12/27/2014 12:01 PM, Eric Rescorla wrote: >> >> >> On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns >> > wrote: >> >> On 12/24/2014 4:01 PM, Eric Rescorla wrote: >>> >>> > > >>> > > That is, it would be digital signature of: >>> > > >>> > > - 32 padding bytes (or ClientRandom) >>> > > - 32 padding bytes (or ServerRandom) >>> > > - Context string >>> > > - Ciphersuite ID (to provode domain separation) >>> > > - handshake_hash(transcript) >>> > > >>> > >>> > So to be clear, you are proposing that we might (for >>> instance) have >>> > a signature with (say) SHA-1 over a handshake hash >>> computed with >>> > SHA-256? >>> >>> Yes. >>> >>> E.g ECDSA/SHA1 for signatures and >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>> for connection. That would result in SHA-1 signature >>> over SHA-256 hash. >>> >>> >>> The other way around can't happen with any current >>> ciphersuite (because >>> every current one has prf-hash of either SHA-256 or >>> SHA-384). >>> >>> >>> Thanks for the clarification. What do other people think >>> about this suggestion? >>> >>> -Ekr >> >> Three items - >> >> Doing it this way means that SHA1 is a permanent part of >> TLS1.3 - every implementation will need it. It also means >> that the security of the handshake transcript part is no >> better than that given by SHA1 so if further attacks on SHA1 >> are discovered, the fix will be TLS1.4. >> >> >> I don't believe that this is correct. >> >> - In the current draft, you sign transcript using whatever >> signature/hash pair >> you have selected. Call that hash H1. So, you sign H1(transcript). >> >> - In AGL's existing PR, you sign H1(context || H1(transcript)) >> >> - In Ilari's proposal, you sign H1(context || H2(transcript)) >> where H2 is >> that Hash used by the PRF, which is SHA-256 for the current cipher >> suites. >> >> So, in the case where you want to sign with RSA-SHA1, you would >> in the >> first case just sign with SHA1, in the second do SHA1(... || SHA1()), >> and in the third case do SHA1(...., || SHA256()). > > I admit to a lot of confusion then as to what you're trying to do > here: > > 1) Client offers a number of cipher suites, with the result that > there are multiple hash functions (PRF) possible. > 2) Client uses which hash function to summarize the transcript? > 3) Server knows which hash function the client is using so it can > use the same one? Assuming it implements that. > > > My point here is that I don't see that you're gaining anything as > mostly the client doesn't know what the server knows until after > the server tells it. The clients choice of which hash (or even > which handshake signature algorithm) to use will be prone to error > until it gets a response from the server confirming it. I think a > client has to maintain parallel hash contexts for all offered > hash functions until the server makes its choice known. > > > Yes, that's correct, but it's not the end of the analysis. Consider > the diagram of > the handshake from Figure 1: > > ClientHello > ClientKeyShare --------> > ServerHello > ServerKeyShare > [ChangeCipherSpec] > EncryptedExtensions* > Certificate* > CertificateRequest* > CertificateVerify* > <-------- Finished > [ChangeCipherSpec] > Certificate* > CertificateVerify* > Finished --------> > Application Data <-------> Application Data > > > In the current design, the client does not know which digest algorithm > the server > will sign with until the receipt of the CertificateVerify message, so > it must > parallel hash the server's entire second flight. Similarly, the server > does not > know what the client will select so it must parallel hash its entire > second > flight and the client's Certificate message. By contrast, with the > approach > Ilari suggests, both sides only need to parallel hash up to the > ServerHello. OK - That makes more sense. So the TLS1.3 ServerHello contains an indication of which hash will be used over the handshake transcript and that will be the same as the selected hash function for the PRF etc. > > It's also worth noting that the potential set of algorithms used in > the PRF is > currently much narrower than the set of algorithms that implementations > typically support for signature verification (consisting presently of just > SHA-256) and so this also reduces the burden on both sides. It might not exactly be applicable to the current discussion assuming both sides negotiate to TLS1.3 (because of limiting suites to AEAD suites), but RFC 6367 has (section 3.3b): > b. The cipher suites ending with _SHA384 use HMAC-SHA-384 [1 ] as the > MAC algorithm. The PRF is the TLS PRF [8 ] with SHA-384 [13 ] as > the hash function. > > > >> If the client is willing to negotiate to TLS1.2, the client >> will still need to run multiple hashes in parallel until it >> gets the tls version selection confirmation (and the cipher >> suite selection) from the server as we're not changing how >> the TLS1.2 signature is calculated. >> >> >> Yes. This is at least in principle also true with TLS 1.3 if we >> were to define >> (and the client were to support) a PRF based on some other hash, such >> as SHA-512. > > Yup - but AFAICT, the only restriction for what goes into the .prf > slot in the cipher suite is that it must be a hash function > useable with HMAC. I would expect future suites to propose SHA3 > based hashes for example as well as regional/national hash > functions. And I would expect those to work without changes to the > underlying TLS protocol. > > > Yes, that might well happen (though to my knowledge, we have not yet > standardized any > regional/national digest functions and I don't see a lot of enthusiasm > for SHA-3). But > both sides are already required to handle these cases because that is > the hash used > for the session_hash computation, so Ilari's proposal will often > reduce the number of > parallel hashes you have to run and will not increase it. > > -Ekr > --------------030300080206020408040507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/27/2014 1:06 PM, Eric Rescorla wrote:


On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 12/27/2014 12:01 PM, Eric Rescorla wrote:


On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 12/24/2014 4:01 PM, Eric Rescorla wrote:

> >
> > That is, it would be digital signature of:
> >
> > - 32 padding bytes (or ClientRandom)
> > - 32 padding bytes (or ServerRandom)
> > - Context string
> > - Ciphersuite ID (to provode domain separation)
> > - handshake_hash(transcript)
> >
>
> So to be clear, you are proposing that we might (for instance) have
> a signature with (say) SHA-1 over a handshake hash computed with
> SHA-256?

Yes.

E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
for connection. That would result in SHA-1 signature over SHA-256 hash.


The other way around can't happen with any current ciphersuite (because
every current one has prf-hash of either SHA-256 or SHA-384).

Thanks for the clarification. What do other people think about this suggestion?

-Ekr

 Three items -

Doing it this way means that SHA1 is a permanent part of TLS1.3 - every implementation will need it.  It also means that the security of the handshake transcript part is no better than that given by SHA1 so if further attacks on SHA1 are discovered, the fix will be TLS1.4. 

I don't believe that this is correct.

- In the current draft, you sign transcript using whatever signature/hash pair
  you have selected. Call that hash H1. So, you sign H1(transcript).

- In AGL's existing PR, you sign H1(context || H1(transcript))

- In Ilari's proposal, you sign H1(context || H2(transcript)) where H2 is
  that Hash used by the PRF, which is SHA-256 for the current cipher
  suites.

So, in the case where you want to sign with RSA-SHA1, you would in the
first case just sign with SHA1, in the second do SHA1(... || SHA1()),
and in the third case do SHA1(...., || SHA256()).

I admit to a lot of confusion then as to what you're trying to do here:

1) Client offers a number of cipher suites, with the result that there are multiple hash functions (PRF) possible.
2) Client uses which hash function to summarize the transcript?
3) Server knows which hash function the client is using so it can use the same one?  Assuming it implements that.


My point here is that I don't see that you're gaining anything as mostly the client doesn't know what the server knows until after the server tells it.  The clients choice of which hash (or even which handshake signature algorithm) to use will be prone to error until it gets a response from the server confirming it.  I think a client  has to maintain parallel hash contexts for all offered hash functions until the server makes its choice known.

Yes, that's correct, but it's not the end of the analysis. Consider the diagram of
the handshake from Figure 1:

      ClientHello
      ClientKeyShare            -------->
                                                      ServerHello
                                                   ServerKeyShare
                                               [ChangeCipherSpec]
                                             EncryptedExtensions*
                                                     Certificate*
                                              CertificateRequest*
                                               CertificateVerify*
                                <--------                Finished
      [ChangeCipherSpec]
      Certificate*
      CertificateVerify*
      Finished                  -------->
      Application Data          <------->        Application Data


In the current design, the client does not know which digest algorithm the server
will sign with until the receipt of the CertificateVerify message, so it must
parallel hash the server's entire second flight. Similarly, the server does not
know what the client will select so it must parallel hash its entire second
flight and the client's Certificate message. By contrast, with the approach
Ilari suggests, both sides only need to parallel hash up to the ServerHello.

OK - That makes more sense.  So the TLS1.3 ServerHello contains an indication of which hash will be used over the handshake transcript and that will be the same as the selected hash function for the PRF etc.



It's also worth noting that the potential set of algorithms used in the PRF is
currently much narrower than the set of algorithms that implementations
typically support for signature verification (consisting presently of just
SHA-256) and so this also reduces the burden on both sides.

It might not exactly be applicable to the current discussion assuming  both sides negotiate to TLS1.3 (because of limiting suites to AEAD suites), but RFC 6367  has (section 3.3b):

   b.  The cipher suites ending with _SHA384 use HMAC-SHA-384 [1] as the
       MAC algorithm.  The PRF is the TLS PRF [8] with SHA-384 [13] as
       the hash function.






If the client is willing to negotiate to TLS1.2, the client will still need to run multiple hashes in parallel until it gets the tls version selection confirmation (and the cipher suite selection) from the server as we're not changing how the TLS1.2 signature is calculated. 

Yes. This is at least in principle also true with TLS 1.3 if we were to define
(and the client were to support) a PRF based on some other hash, such
as SHA-512.

 Yup - but AFAICT, the only restriction for what goes into the .prf slot in the cipher suite is that it must be a hash function useable with HMAC.  I would expect future suites to propose SHA3 based hashes for example as well as regional/national hash functions.  And I would expect those to work without changes to the underlying TLS protocol.

Yes, that might well happen (though to my knowledge, we have not yet standardized any
regional/national digest functions and I don't see a lot of enthusiasm for SHA-3). But
both sides are already required to handle these cases because that is the hash used
for the session_hash computation, so Ilari's proposal will often reduce the number of
parallel hashes you have to run and will not increase it.

-Ekr


--------------030300080206020408040507-- From nobody Sat Dec 27 13:10:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06991A923E for ; Sat, 27 Dec 2014 13:10:56 -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 oxLitBCC6oTm for ; Sat, 27 Dec 2014 13:10:53 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89881A90B3 for ; Sat, 27 Dec 2014 13:10:52 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so19207925wiw.8 for ; Sat, 27 Dec 2014 13:10:51 -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=dcCaNEF4tqsi0YAqhLlZIKZKZlvk6a/kv1LfMcagx44=; b=PxdMH3uWGLrJBPqpYwB/P8ZAM+7zdHi0LVgcLmQhUEVHeMKrUYkw86mNX9sXFdqmcv iS+psMDXCHybKiwZsLggX1CpjMfiIP+w93Uw1BTjSnxHQfiwDgIb5em5+FFk05861WUC 6HV6g0W2f/3h9K/31wpoo/VLTUc7OwPHxC1Bp2H47DJDe30ZameZ/F7zrpAJ3xTBcpaA gz4Od9UqvphEhYqUvXZZs/5lb8Bv/8NzgCl893aaYhW2qf5XwM5kaobyUq+1iU9sjuU6 jFdUVyu3vhG/HhpfY7xuWsGmpGcpt6k8Cbm+RUEn7TlKocUnsBA2e30GI6fe/ey3wVT+ Hm0g== X-Gm-Message-State: ALoCoQnPRdmRAR84yL7cqpCrhak+8ZQb9pPX45jQKkXXg5EIZ4Za15xVIfuyzga9uqV201BjeDVE X-Received: by 10.194.2.105 with SMTP id 9mr95575392wjt.115.1419714651354; Sat, 27 Dec 2014 13:10:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Sat, 27 Dec 2014 13:10:10 -0800 (PST) In-Reply-To: <549F17C7.8090003@nthpermutation.com> References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> <549EE32B.7050703@nthpermutation.com> <549EEF43.3020608@nthpermutation.com> <549F17C7.8090003@nthpermutation.com> From: Eric Rescorla Date: Sat, 27 Dec 2014 13:10:10 -0800 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=047d7b3440ee7a0da4050b3913f3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LLHhHY1bEwB0aGINPlg51FynzBk Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 21:10:57 -0000 --047d7b3440ee7a0da4050b3913f3 Content-Type: text/plain; charset=UTF-8 On Sat, Dec 27, 2014 at 12:34 PM, Michael StJohns wrote: > On 12/27/2014 1:06 PM, Eric Rescorla wrote: > > > > On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns > wrote: > >> On 12/27/2014 12:01 PM, Eric Rescorla wrote: >> >> >> >> On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns >> wrote: >> >>> On 12/24/2014 4:01 PM, Eric Rescorla wrote: >>> >>> >>> > > >>>> > > That is, it would be digital signature of: >>>> > > >>>> > > - 32 padding bytes (or ClientRandom) >>>> > > - 32 padding bytes (or ServerRandom) >>>> > > - Context string >>>> > > - Ciphersuite ID (to provode domain separation) >>>> > > - handshake_hash(transcript) >>>> > > >>>> > >>>> > So to be clear, you are proposing that we might (for instance) have >>>> > a signature with (say) SHA-1 over a handshake hash computed with >>>> > SHA-256? >>>> >>>> Yes. >>>> >>>> E.g ECDSA/SHA1 for signatures and >>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>>> for connection. That would result in SHA-1 signature over SHA-256 hash. >>>> >>>> >>>> The other way around can't happen with any current ciphersuite (because >>>> every current one has prf-hash of either SHA-256 or SHA-384). >>> >>> >>> Thanks for the clarification. What do other people think about this >>> suggestion? >>> >>> -Ekr >>> >>> >>> Three items - >>> >>> Doing it this way means that SHA1 is a permanent part of TLS1.3 - every >>> implementation will need it. It also means that the security of the >>> handshake transcript part is no better than that given by SHA1 so if >>> further attacks on SHA1 are discovered, the fix will be TLS1.4. >>> >> >> I don't believe that this is correct. >> >> - In the current draft, you sign transcript using whatever >> signature/hash pair >> you have selected. Call that hash H1. So, you sign H1(transcript). >> >> - In AGL's existing PR, you sign H1(context || H1(transcript)) >> >> - In Ilari's proposal, you sign H1(context || H2(transcript)) where H2 >> is >> that Hash used by the PRF, which is SHA-256 for the current cipher >> suites. >> >> So, in the case where you want to sign with RSA-SHA1, you would in the >> first case just sign with SHA1, in the second do SHA1(... || SHA1()), >> and in the third case do SHA1(...., || SHA256()). >> >> >> I admit to a lot of confusion then as to what you're trying to do here: >> >> 1) Client offers a number of cipher suites, with the result that there >> are multiple hash functions (PRF) possible. >> 2) Client uses which hash function to summarize the transcript? >> 3) Server knows which hash function the client is using so it can use the >> same one? Assuming it implements that. >> >> >> My point here is that I don't see that you're gaining anything as mostly >> the client doesn't know what the server knows until after the server tells >> it. The clients choice of which hash (or even which handshake signature >> algorithm) to use will be prone to error until it gets a response from the >> server confirming it. I think a client has to maintain parallel hash >> contexts for all offered hash functions until the server makes its choice >> known. >> > > Yes, that's correct, but it's not the end of the analysis. Consider the > diagram of > the handshake from Figure 1: > > ClientHello > ClientKeyShare --------> > ServerHello > ServerKeyShare > [ChangeCipherSpec] > EncryptedExtensions* > Certificate* > CertificateRequest* > CertificateVerify* > <-------- Finished > [ChangeCipherSpec] > Certificate* > CertificateVerify* > Finished --------> > Application Data <-------> Application Data > > > In the current design, the client does not know which digest algorithm > the server > will sign with until the receipt of the CertificateVerify message, so it > must > parallel hash the server's entire second flight. Similarly, the server > does not > know what the client will select so it must parallel hash its entire second > flight and the client's Certificate message. By contrast, with the approach > Ilari suggests, both sides only need to parallel hash up to the > ServerHello. > > > OK - That makes more sense. So the TLS1.3 ServerHello contains an > indication of which hash will be used over the handshake transcript and > that will be the same as the selected hash function for the PRF etc. > Yes, that sounds right. > > > It's also worth noting that the potential set of algorithms used in the > PRF is > currently much narrower than the set of algorithms that implementations > typically support for signature verification (consisting presently of just > SHA-256) and so this also reduces the burden on both sides. > > > It might not exactly be applicable to the current discussion assuming > both sides negotiate to TLS1.3 (because of limiting suites to AEAD suites), > but RFC 6367 has (section 3.3b): > > b. The cipher suites ending with _SHA384 use HMAC-SHA-384 [1 ] as the > MAC algorithm. The PRF is the TLS PRF [8 ] with SHA-384 [13 ] as > the hash function. > > Ah, good point. Thanks. -Ekr > > > > > > If the client is willing to negotiate to TLS1.2, the client will >>> still need to run multiple hashes in parallel until it gets the tls version >>> selection confirmation (and the cipher suite selection) from the server as >>> we're not changing how the TLS1.2 signature is calculated. >>> >> >> Yes. This is at least in principle also true with TLS 1.3 if we were to >> define >> (and the client were to support) a PRF based on some other hash, such >> as SHA-512. >> >> >> Yup - but AFAICT, the only restriction for what goes into the .prf slot >> in the cipher suite is that it must be a hash function useable with HMAC. >> I would expect future suites to propose SHA3 based hashes for example as >> well as regional/national hash functions. And I would expect those to work >> without changes to the underlying TLS protocol. >> > > Yes, that might well happen (though to my knowledge, we have not yet > standardized any > regional/national digest functions and I don't see a lot of enthusiasm for > SHA-3). But > both sides are already required to handle these cases because that is the > hash used > for the session_hash computation, so Ilari's proposal will often reduce > the number of > parallel hashes you have to run and will not increase it. > > -Ekr > > > --047d7b3440ee7a0da4050b3913f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 27, 2014 at 12:34 PM, Michael StJohns <= ;msj@nthpermuta= tion.com> wrote:
=20 =20 =20
On 12/27/2014 1:06 PM, Eric Rescorla wrote:


On Sat, Dec 27, 2014 at 9:41 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 12/27/2014 12:01 PM, Eric Rescorla wrote:


On Sat, Dec 27, 2014 at 8:49 AM, Michael StJohns &= lt;msj@nthpermu= tation.com> wrote:
On 12/24/2014 4:01 PM, Eric Rescorla wrote:

> >
> > That is, it would be digital signature of:
> >
> > - 32 padding bytes (or ClientRandom)
> > - 32 padding bytes (or ServerRandom)
> > - Context string > > - Ciphersuite ID (to provode domain separation)
> > - handshake_hash(transcript) > >
>
> So to be clear, you are proposing that we might (for instance) have
> a signature with (say) SHA-1 over a handshake hash computed with
> SHA-256?

Yes.

E.g ECDSA/SHA1 for signatures and TLS_ECDHE_ECDSA_WITH_AES_128_GC= M_SHA256
for connection. That would result in SHA-1 signature over SHA-256 hash.


The other way around can't happen with any current ciphersuite (because
every current one has prf-hash of either SHA-256 or SHA-384).

Thanks for the clarification. What do other people think about this suggestion?

-Ekr

Three items -

Doing it this way means that SHA1 is a permanent part of TLS1.3 - every implementation will need it.=C2=A0 It also means that the security of the handshake transcript part is no better than that given by SHA1 so if further attacks on SHA1 are discovered, the fix will be TLS1.4.=C2=A0

I don't believe that this is correct.<= /div>

- In the current draft, you sign transcript using whatever signature/hash pair
=C2=A0 you have selected. Call that hash H= 1. So, you sign H1(transcript).

- In AGL's existing PR, you sign H1(context || H1(transcript))

- In Ilari's proposal, you sign H1(context || H2(transcript)) where H2 is
=C2=A0 that Hash used by the PRF, which is SHA-256 for the current cipher
=C2=A0 suites.

So, in the case where you want to sign with RSA-SHA1, you would in the
first case just sign with SHA1, in the second do SHA1(... || SHA1()),
and in the third case do SHA1(...., || SHA256()).

I admit to a lot of confusion then as to what you're trying to do here:

1) Client offers a number of cipher suites, with the result that there are multiple hash functions (PRF) possible.
2) Client uses which hash function to summarize the transcript?
3) Server knows which hash function the client is using so it can use the same one?=C2=A0 Assuming it implements that.


My point here is that I don't see that you're gaini= ng anything as mostly the client doesn't know what the server knows until after the server tells it.=C2=A0 The clients choice of which hash (or even which handshake signature algorithm) to use will be prone to error until it gets a response from the server confirming it.=C2=A0 I think a client=C2=A0 has to maintain parallel hash contexts for all offered hash functions until the server makes its choice known.

Yes, that's correct, but it's not the end of the analysis. Consider the diagram of
the handshake from Figure 1:

=C2=A0 =C2=A0 =C2=A0 ClientHello
=C2=A0 =C2=A0 =C2=A0 ClientKeyShare =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ServerKeyShare
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ChangeCipherSpec]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EncryptedExtensions*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Certificate*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateRequest*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateVerify*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Finished
=C2=A0 =C2=A0 =C2=A0 [ChangeCipherSpec]
=C2=A0 =C2=A0 =C2=A0 Certificate*
=C2=A0 =C2=A0 =C2=A0 CertificateVerify*
=C2=A0 =C2=A0 =C2=A0 Finished =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 Application Data =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<-------> =C2=A0 =C2=A0 =C2=A0 =C2=A0Application Data


In the current design, the client does not know which digest algorithm the server
will sign with until the receipt of the CertificateVerify message, so it must
parallel hash the server's entire second flight. Similarly, the server does not
know what the client will select so it must parallel hash its entire second
flight and the client's Certificate message. By contrast, with the approach
Ilari suggests, both sides only need to parallel hash up to the ServerHello.

OK - That makes more sense.=C2=A0 So the TLS1.3 ServerHello contains an indication of which hash will be used over the handshake transcript and that will be the same as the selected hash function for the PRF etc.

Yes, that sounds right.
=C2=A0
=C2=A0

It's also worth noting that the potential set of algorithms used in the PRF is
currently much narrower than the set of algorithms that implementations
typically support for signature verification (consisting presently of just
SHA-256) and so this also reduces the burden on both sides.

 It might not exactly be applicable to the current discussion assuming=C2=A0 both sides negotiate to TLS1.3 (because of limiting suit= es to AEAD suites), but RFC 6367=C2=A0 has (section 3.3b):

   b.  The cipher suites ending with _SHA384 use HMAC-SHA-384 [<=
a href=3D"http://tools.ietf.org/html/rfc6367#ref-1" title=3D""HMAC: Ke=
yed-Hashing for Message Authentication"" target=3D"_blank">1] as t=
he
       MAC algorithm.  The PRF is the TLS PRF [8] with SHA-384 [13] as
       the hash function.

Ah, good point. Thanks.

-Ekr
=C2= =A0





If the client is willing to negotiate to TLS1.2, the client will still need to run multiple hashes in parallel until it gets the tls version selection confirmation (and the cipher suite selection) from the server as we're not changing how the TLS1.2 signature is calculated.=C2=A0

Yes. This is at least in principle also true with TLS 1.3 if we were to define
(and the client were to support) a PRF based on some other hash, such
as SHA-512.

 Yup - but AFAICT, the only restriction for what goes into the .prf slot in the cipher suite is that it must be a hash function useable with HMAC.=C2=A0 I would expect future suites to propose SHA3 based hashes for example as well as regional/national hash functions.=C2=A0 And I would expect those to work without changes to the underlying TLS protocol.

Yes, that might well happen (though to my knowledge, we have not yet standardized any
regional/national digest functions and I don't see a lot of enthusiasm for SHA-3). But
both sides are already required to handle these cases because that is the hash used
for the session_hash computation, so Ilari's proposal will often reduce the number of
parallel hashes you have to run and will not increase it.

-Ekr



--047d7b3440ee7a0da4050b3913f3-- From nobody Sat Dec 27 14:07:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CE01ACC87 for ; Sat, 27 Dec 2014 14:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 0_yr8Jc4pu0c for ; Sat, 27 Dec 2014 14:07:19 -0800 (PST) Received: from hauke-m.de (hauke-m.de [5.39.93.123]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166C21AC7E8 for ; Sat, 27 Dec 2014 14:07:19 -0800 (PST) Received: from [IPv6:2001:67c:20a1:1192:224:d7ff:fe5f:d4e4] (unknown [IPv6:2001:67c:20a1:1192:224:d7ff:fe5f:d4e4]) by hauke-m.de (Postfix) with ESMTPSA id 949ED2016F; Sat, 27 Dec 2014 23:07:17 +0100 (CET) Message-ID: <549F2D90.5030305@hauke-m.de> Date: Sat, 27 Dec 2014 23:07:12 +0100 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Yoav Nir , Dave Garrett References: <201412221945.35644.davemgarrett@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J2FjWPOQdypS-bpnkRSww469djY 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: Sat, 27 Dec 2014 22:07:20 -0000 On 12/24/2014 07:40 AM, Yoav Nir 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. > > Yoav 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. Hauke From nobody Sat Dec 27 14:54:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FA11AC3BC for ; Sat, 27 Dec 2014 14:54:28 -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 mfan15cOcYj9 for ; Sat, 27 Dec 2014 14:54:26 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974B21AC3B2 for ; Sat, 27 Dec 2014 14:54:26 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so19306219wiv.11 for ; Sat, 27 Dec 2014 14:54:25 -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=prhcvImHLvdvy/3JtTgNmJQLSU6Fvc+36ZkwMypTn28=; b=MCirBU4Ol05YrMSp7dBbTl1j1WPFQ0qucj4KxIN/BfFttNzlvmDCPDFOmP67TEn46R KQlfZX3ZWLH4A2K6T1js5xg1o9bMyzihCvL6xcIrEJoYGIdKo6ECU6etKhXT5Erm4CUF IL9tuoaueN/YLdBMC2o7euwwkZKqKCNAGgwvxoOlszxvdYtML0xb5+r36My7pqhe8AQw HqPj+OBruG+1vicLazvfAKquvRLkN/jGKdVc5c59vUt6j+u1SJhdF2ZeRHavAJXKRtpj 1o8TUjYZWDQCAXYmBgqvZRq6SbYZHB9Zu8sNLgOOAE9+ZUThHmPyrezS4jexBx7CtGzn TmKA== X-Received: by 10.194.175.2 with SMTP id bw2mr87378742wjc.117.1419720865308; Sat, 27 Dec 2014 14:54:25 -0800 (PST) Received: from [192.168.1.104] (IGLD-84-228-227-214.inter.net.il. [84.228.227.214]) by mx.google.com with ESMTPSA id nj9sm33366471wic.10.2014.12.27.14.54.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Dec 2014 14:54:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <201412271739.24476.davemgarrett@gmail.com> Date: Sun, 28 Dec 2014 00:54:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eMV6nQ4t6AYDVXJj8OWnvpiOnxc 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: Sat, 27 Dec 2014 22:54:28 -0000 Hi, Dave I see a "should" from Hauke and a "should not" from you. But using RFC = 2119 words like =E2=80=9CMUST NOT=E2=80=9D in the spec could mean one of = the following things: 1, That an SSLv2 ClientHello with version equal to whatever we choose = for TLS 1.3 (0x03,0x04?) must be rejected and the connection closed. 2. That any TLS 1.3 implementation MUST remove support for SSLv2 = ClientHellos. 3. That it is no longer prudent to even perform handshakes with clients = that still offer SSLv2. In this case SSLv2 support is used as a proxy = for insecure peer. In your message you said =E2=80=9Cshould not=E2=80=9D. Why do you think = we need to mandate dropping this support from existing products? Yoav > On Dec 28, 2014, at 12:39 AM, Dave Garrett = wrote: >=20 > On Saturday, December 27, 2014 05:07:12 pm Hauke Mehrtens wrote: >> On 12/24/2014 07:40 AM, Yoav Nir wrote: >>> It=E2=80=99s fine for us to break compatibility with these clients, = but let=E2=80=99s not >>> pretend it=E2=80=99s some ancient technology that doesn=E2=80=99t = exist in the market >>> anymore. >>=20 >> 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. >>=20 >> I think a TLS 1.3 Client must not send a SSLv2 ClientHello, but a = server >> should understand it. >=20 > The newest version of TLS should not be have to be written to = accommodate an 8=20 > year old EOL Java version's default settings. >=20 >=20 > Dave From nobody Sat Dec 27 14:59:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA941AC3C2 for ; Sat, 27 Dec 2014 14:59:08 -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, MIME_QP_LONG_LINE=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 ihQTjMIYSgSY for ; Sat, 27 Dec 2014 14:59:06 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6376F1AC3BC for ; Sat, 27 Dec 2014 14:59:06 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id y13so14903165pdi.2 for ; Sat, 27 Dec 2014 14:59:05 -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=mSgzj2jkg63Ajzyiqu49J+55l931sRl0dl5DpXMwABU=; b=lxBUGJlHnQHUF7ML4tkpiIfWtnVTlXEcL3rljrYgkAyh2XOKErsKEW202XBJVRGnTn +2qI7EAtE5n0ufnAkRe0NgHHrUC8JbCfwUFBcS1DvT4ruX16cs/WmkyVB3ghOtH/sH0l gU9jtcQjGGEmVZaYid2YTIeybs6jMAGnUhQVi2e/u2qXETzJWtcWwdMM/t1pk4OqDN86 jeOUO57Rt3D92UCH3EjY1M60d/t3SFUwHT8V3037KldzI/f1ZN29jZSvnqSZmqmpTqMk fd0nMfXo6vR19ubkoSNXM0mCejWlvqsrn5GxX2jEp9uLw20/fCtUWQf7z1+QjM6wT8wr MI7w== X-Received: by 10.68.239.70 with SMTP id vq6mr77260654pbc.110.1419721145667; Sat, 27 Dec 2014 14:59:05 -0800 (PST) Received: from [172.16.42.7] (c-73-15-172-83.hsd1.ca.comcast.net. [73.15.172.83]) by mx.google.com with ESMTPSA id i7sm18692772pdp.3.2014.12.27.14.59.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Dec 2014 14:59:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (12E165) In-Reply-To: <549F2D90.5030305@hauke-m.de> Date: Sat, 27 Dec 2014 14:59:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32B9010C-C209-4D55-9AEA-5BC3EBE738A3@gmail.com> References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> To: Hauke Mehrtens Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jcpkEJysPK2K7Q7FjUG2PhBPlrY Cc: Dave Garrett , "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: Sat, 27 Dec 2014 22:59:08 -0000 > On Dec 27, 2014, at 14:07, Hauke Mehrtens wrote: >=20 >=20 >=20 > On 12/24/2014 07:40 AM, Yoav Nir wrote: >>>=20 >>> There's no reason to maintain any backwards support here just for Intern= et=20 >>> Explorer 2.0 on Windows 3.1. >>=20 >> I=E2=80=99m not objecting to the change, but I am objecting to the hyperb= ole. 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 Windo= ws XP use the same SCHANNEL library as IE would use, so they issue a SSLv2 C= lientHello. Despite Microsoft=E2=80=99s best efforts, there is still a subst= antial but diminishing install base of XP. >>=20 >> It=E2=80=99s fine for us to break compatibility with these clients, but l= et=E2=80=99s not pretend it=E2=80=99s some ancient technology that doesn=E2=80= =99t exist in the market anymore. >>=20 >> Yoav >=20 > 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. >=20 > I think a TLS 1.3 Client must not send a SSLv2 ClientHello, but a server > should understand it. openssl s_client, is also using a SSLv2 hello unless the -no_ssl2 option is u= sed. (At least in the 0.9.8 version shipped on OSX, other may comment if thi= s is still true on other platforms and in more recents OpenSSL version) s_client is often used in scripts and test harness and there is no easy way t= o disable that behavior globally short of recompiling. In my mind, the point of explicitly forbidding v2 hellos on the server side i= s to: - First eventually kill all remaining clients that's still speak v2 by defau= lt.=20 - Once those clients are gone this should finish killing all remaining ssl2 s= ervers. Also, the complexity of implementing the SSLv2 record parsing on the server s= ide for servers that only do TLS is real. Isn't that the origin of the bug t= hat caused server to hang on client hello with specific size? The one that m= otivated the writing of https://tools.ietf.org/html/draft-agl-tls-padding-03= ? I think implementors will be happy to remove that bug prone piece of code fr= om their stacks, eventually. -- Fabrice.=20 > Hauke >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Dec 27 15:37:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFC01ACD08 for ; Sat, 27 Dec 2014 15:37:10 -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 MUh2vfbeFslF for ; Sat, 27 Dec 2014 15:37:09 -0800 (PST) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DAB1ACD03 for ; Sat, 27 Dec 2014 15:37:09 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id i138so21035282oig.2 for ; Sat, 27 Dec 2014 15:37:08 -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 :content-transfer-encoding; bh=q711ukirzPK75ALh+xb5L9ZOaGrZyXhzd0oW8YncH7s=; b=GNAElcUbQo1tVOhEso8uPF5PovypFzTJ8zhB+xx+G4YgxTsIBCZMIIQdKYk3G0gmDN CJzVjjmO4T5t71dtu+yAN+RAnwhaZeHTafNZyQNXat7RsbBV/duT15paJbMGsS0j1jDg yMvEODX3YtkSWzi6tYv5hbfKL6P8C8YXWN96le3vfpd3g97GMsBgBES/X0BatMenyg2h Jv/swrFQDAtKDuAaSlQ6t7wHkaTt89DPiPWEn0PL+fOJZTzoC5H1ndR+aEsgCBcFI8OO CPiz4dcDdttUh4q2su+GKWyL8VHSXeeZJmKVrEcNmYZ9Pd07pxYV3r5+B51DQrfJmqWQ E/QQ== X-Gm-Message-State: ALoCoQnRm/ySHFvI1gc0PQPw5iOTCFmvPEEp1ZYfpXE3MAlGHdWoPqW3p0SWaeR3GDEMPeXcKpdt MIME-Version: 1.0 X-Received: by 10.182.19.135 with SMTP id f7mr5494550obe.5.1419723428577; Sat, 27 Dec 2014 15:37:08 -0800 (PST) Received: by 10.76.71.228 with HTTP; Sat, 27 Dec 2014 15:37:08 -0800 (PST) In-Reply-To: <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> Date: Sat, 27 Dec 2014 15:37:08 -0800 Message-ID: From: Brian Smith To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JJ2eOFHdjSldughfcOHXol421tQ Cc: Dave Garrett , "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: Sat, 27 Dec 2014 23:37:10 -0000 Yoav Nir wrote: > I see a "should" from Hauke and a "should not" from you. But using RFC 21= 19 words like =E2=80=9CMUST NOT=E2=80=9D in the spec could mean one of the = following things: > 1, That an SSLv2 ClientHello with version equal to whatever we choose fo= r TLS 1.3 (0x03,0x04?) must be rejected and the connection closed. The server should be required to (MUST) reject such a client hello, so that we can make some extensions mandatory for the client to send. (SSL2-compatible hellos cannot support extensions.) In particular, signature_algorithms and SNI, at a minimum, should be mandatory to send, at least for HTTPS clients. > 2. That any TLS 1.3 implementation MUST remove support for SSLv2 ClientH= ellos. > > 3. That it is no longer prudent to even perform handshakes with clients = that still offer SSLv2. In this case SSLv2 support is used as a proxy for i= nsecure peer. if the server is allowed to support TLS 1.0, then it should seems reasonable for it to negotiate TLS 1.0 with a client that sent an SSL2-compatible TLS 1.0 ClientHello. However, I think it is fine to say that the server MUST NOT implement support for the SSL2 protocol. And, it is fine to say that all TLS clients MUST NOT use SSL2-compatible ClientHellos, since they wouldn't be able to add extensions if they did. Cheers, Brian From nobody Sat Dec 27 16:39:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E526C1ACE38 for ; Sat, 27 Dec 2014 16:39:10 -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 b7yOCpltfpYy for ; Sat, 27 Dec 2014 16:39:08 -0800 (PST) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD671ACE32 for ; Sat, 27 Dec 2014 16:39:08 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id i138so21110656oig.2 for ; Sat, 27 Dec 2014 16:39:07 -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=bcvj4Z+awYTiJIQyAjSc1+k9fr2+xuPu15NHqxWzqyM=; b=bPS6InoCtNOwMfdm9fZ2DSrROwKofaVd99sj3IsKij5eC8FpuRRVXILj6QWMSIJK9P 18Kf8Rd8jsPbmAQHa2OccCODmv7RwP6EjTo1qC0eBzMmkNHIL5x7CPY3DY6xLFVlxAXy EwTPzmNHDDUnhwBNEJ+/cGJnpETXGm/IeaOS5ZdqLojoF96N7hfwl+rmjBBTlomJjkey ckIp4bux2NVxwWuBpK9uVscsCwuEU/lkb0z5dNpQiiXfDD/uWJo/9h3S2hGKyT5ZSSFy L42P4Pt0EQkNhtWtLAZP8XFrl1+YGqYp5d8GAnu4BKDYKRcx1hwdOr/KJ8pPzZbnDrBi QRFw== X-Gm-Message-State: ALoCoQmxn9hVDbCPcuCjsmWpZ1btR7QZkzDqvx5qEMLJXxBFT9Jt9hWtP2+l3jCuLMzWYD2nEtzS MIME-Version: 1.0 X-Received: by 10.182.148.98 with SMTP id tr2mr4215870obb.28.1419727147844; Sat, 27 Dec 2014 16:39:07 -0800 (PST) Received: by 10.76.71.228 with HTTP; Sat, 27 Dec 2014 16:39:07 -0800 (PST) In-Reply-To: <201412271906.00820.davemgarrett@gmail.com> References: <201412221945.35644.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> <201412271906.00820.davemgarrett@gmail.com> Date: Sat, 27 Dec 2014 16:39:07 -0800 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6O8ijXuK-TX9X-IIuVvMiYBMaL4 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: Sun, 28 Dec 2014 00:39:11 -0000 Dave Garrett wrote: > On Saturday, December 27, 2014 06:37:08 pm Brian Smith wrote: >> if the server is allowed to support TLS 1.0, then it should seems >> reasonable for it to negotiate TLS 1.0 with a client that sent an >> SSL2-compatible TLS 1.0 ClientHello. > > The fact > that some clients are EOL and might not do connect in a way that will work > forever is not something worth worrying about. I don't think it's unreasonable > to expect that 20 years later the "new" hello format should be mandatory. > SSL2 messages should not be tolerated at this point if we want TLS 1.3 to be > considered a specification for a modern security protocol implementation. Like I said in my previous message, I do think that for TLS 1.3, SSL2-compatible ClientHellos must not be used since they don't allow extensions. Further, it is better for the TLS 1.3 spec to remove all the text describing the SSL2-compatible hello stuff, regardless of whether or not supporting SSL2-compatible-ClientHello for TLS 1.0/1.1/1.2 is explicitly prohibited or not. Cheers, Brian From nobody Sat Dec 27 17:39:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C342E1ACE76 for ; Sat, 27 Dec 2014 17:38:58 -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 P56uB-QvXFt7 for ; Sat, 27 Dec 2014 17:38:57 -0800 (PST) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966AE1ACE75 for ; Sat, 27 Dec 2014 17:38:57 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id h136so25720369oig.11 for ; Sat, 27 Dec 2014 17:38:57 -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=fiqrQyCKtbLm2JHXkIhkHs4i7EPpm71e7wwjkYpVXME=; b=KldzzMpELEUt4ljRkT90X1ZoL9zNdPqz60yEcZc/gJ6nKOCDH13h5kYhMl7qFML25b ugRbCKZ/9OGmnVovxhfMR3AKvRtfCpWUNKVdoUk2VDF6qsXkyP1CroPHY4hJ9oRXt/EI CC3VFnCYwryUVxwUEWnAyY4/eWuEJli/4UvI/HwzYxxUX/Bgwn/7kndlez12eFO3Xjvh lDM16bMZXHMK5lsakXvTBr0Wq5RJ6Vau+RXeOE3a2ir2IW/ncGnBKzKvgNOp94WmXqyB /U9LQoUgb/FYnp99ekscv12FVB/gkTwFKbQon9hukOsDcpzLyWcSPrraUiAr1cGvbyDU 6HDg== X-Gm-Message-State: ALoCoQmmx+r5EuMGJM2Pi8aB6pb+3qMG2jErQwl0mjTQRuwVotCgyk9HG2NBOFwxYAksSds2tpSR MIME-Version: 1.0 X-Received: by 10.60.124.69 with SMTP id mg5mr29270881oeb.73.1419730736924; Sat, 27 Dec 2014 17:38:56 -0800 (PST) Received: by 10.76.71.228 with HTTP; Sat, 27 Dec 2014 17:38:56 -0800 (PST) In-Reply-To: <201412272007.52081.davemgarrett@gmail.com> References: <201412221945.35644.davemgarrett@gmail.com> <201412271906.00820.davemgarrett@gmail.com> <201412272007.52081.davemgarrett@gmail.com> Date: Sat, 27 Dec 2014 17:38:56 -0800 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VN9HJsiKdj4QhFkW0mYJDb605QI 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: Sun, 28 Dec 2014 01:38:59 -0000 Dave Garrett wrote: > On Saturday, December 27, 2014 07:39:07 pm Brian Smith wrote: > I'm hesitant to even mention it, but obviously my next most preferred route is > obviously to do that and make acceptance of an SSL2 hello for older TLS versions > a SHOULD NOT rather than a MUST NOT. That seems good to me. > That, however, is basically just RFC 6176 with a wag of a finger thrown in. That's good, because it should be easy for everybody to accept. > There have been bugs caused by supporting this and it should be mandated to no > longer be usable for all implementations. Anyone actually relying on it and not > capable of flipping the client-side switches needed to stop it is not likely to > be a candidate for early adoption of TLS 1.3, anyway. Servers generally cannot flip switches on the client. I want TLS 1.3 to be deployed widely and quickly after it's been standardized, and I want people to be able to put it into production use during the standardization effort so we get the same kind of interop testing that HTTP/2 got. This requires that the TLS 1.3 spec should try to avoid breaking how earlier versions of TLS work, unless there is a very strong reason to do so. Cheers, Brian From nobody Sun Dec 28 02:43:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE901ACF15 for ; Sun, 28 Dec 2014 02:43:53 -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, 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 fAoZpTgwfx3T for ; Sun, 28 Dec 2014 02:43:52 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 EC7411ACF0B for ; Sun, 28 Dec 2014 02:43:51 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 8257C1C211B; Sun, 28 Dec 2014 11:43:49 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 3F5831FE00B3; Sun, 28 Dec 2014 11:43:48 +0100 (CET) Date: Sun, 28 Dec 2014 11:43:48 +0100 From: Kurt Roeckx To: Fabrice Message-ID: <20141228104348.GA19183@roeckx.be> References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> <32B9010C-C209-4D55-9AEA-5BC3EBE738A3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32B9010C-C209-4D55-9AEA-5BC3EBE738A3@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4xdY8lAKL7vqqvd0qsm34532B38 Cc: "TLS@ietf.org \(tls@ietf.org\)" , Dave Garrett 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: Sun, 28 Dec 2014 10:43:53 -0000 On Sat, Dec 27, 2014 at 02:59:02PM -0800, Fabrice wrote: > > openssl s_client, is also using a SSLv2 hello unless the -no_ssl2 option is used. This was changed in OpenSSL 1.0.0. The default cipher list dropped SSLv2 ciphers and it would only use an SSLv2 compatible client hello in case the cipher list didn't include an SSLv2 cipher and there aren't any extentions. OpenSSL 0.9.8 unfurtuantly is still a supported version but we've announce end of line for the end of next year. Kurt From nobody Sun Dec 28 06:43:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAB91AD48F for ; Sun, 28 Dec 2014 06:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 fR9zr_wT2h4Y for ; Sun, 28 Dec 2014 06:43:44 -0800 (PST) Received: from hauke-m.de (hauke-m.de [IPv6:2001:41d0:8:b27b::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA611A6FDB for ; Sun, 28 Dec 2014 06:43:44 -0800 (PST) Received: from [IPv6:2001:67c:20a1:1192:224:d7ff:fe5f:d4e4] (unknown [IPv6:2001:67c:20a1:1192:224:d7ff:fe5f:d4e4]) by hauke-m.de (Postfix) with ESMTPSA id 212EC2016F; Sun, 28 Dec 2014 15:43:42 +0100 (CET) Message-ID: <54A0171D.9070504@hauke-m.de> Date: Sun, 28 Dec 2014 15:43:41 +0100 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Yoav Nir , Dave Garrett References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> In-Reply-To: <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kWQVMeayS-QilbR3AFTYLPVy6H4 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: Sun, 28 Dec 2014 14:43:46 -0000 Hi, as even OpenSSL 0.9.8 sends such ClientHellos in the default settings, I think TLS 1.3 should support the following: 1. TLS 1.3 Clients must only negotiate TLS 1.0 or up. I think with the Poodle attack most servers and clients already deactivated SSL v3 support. This is draft-ietf-tls-sslv3-diediedie-00. 2. A TLS 1.3 Client most not send a SSL v2 or SSL v3 ClientHello. This is draft-ietf-tls-sslv3-diediedie-00. 2. A TLS 1.3 server may or should accept a SSL V2 and V3 compatible ClientHello, but not negotiate these protocol versions. I think for compatibility reasons most implementors would like to stay compatible with old ClientHellos, but I think the RFC should not mandate this. In 10 years TLS servers implementors are probably save to remove support for this old OpenSSL version, Java 6 and probably more stuff. This should be an implementors decision how long they want to stay backwards compatible with old software as long as this does not have negative implications on security. Hauke On 12/27/2014 11:54 PM, Yoav Nir wrote: > Hi, Dave > > I see a "should" from Hauke and a "should not" from you. But using RFC 2119 words like “MUST NOT” in the spec could mean one of the following things: > 1, That an SSLv2 ClientHello with version equal to whatever we choose for TLS 1.3 (0x03,0x04?) must be rejected and the connection closed. > 2. That any TLS 1.3 implementation MUST remove support for SSLv2 ClientHellos. > 3. That it is no longer prudent to even perform handshakes with clients that still offer SSLv2. In this case SSLv2 support is used as a proxy for insecure peer. > > In your message you said “should not”. Why do you think we need to mandate dropping this support from existing products? > > Yoav > > >> On Dec 28, 2014, at 12:39 AM, 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. >> >> >> Dave > From nobody Sun Dec 28 08:44:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453331A8885 for ; Sun, 28 Dec 2014 08:44:26 -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, 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 wnQ2ZB41EhsL for ; Sun, 28 Dec 2014 08:44:24 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (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 745401A8884 for ; Sun, 28 Dec 2014 08:44:24 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 2282E1C211B; Sun, 28 Dec 2014 17:44:22 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 7BA151FE00B3; Sun, 28 Dec 2014 17:44:21 +0100 (CET) Date: Sun, 28 Dec 2014 17:44:21 +0100 From: Kurt Roeckx To: Hauke Mehrtens Message-ID: <20141228164421.GA5437@roeckx.be> References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> <54A0171D.9070504@hauke-m.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A0171D.9070504@hauke-m.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ro4ddfM7_gwaM15auVPby9ZVXNQ Cc: Dave Garrett , "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: Sun, 28 Dec 2014 16:44:26 -0000 On Sun, Dec 28, 2014 at 03:43:41PM +0100, Hauke Mehrtens wrote: > Hi, > > as even OpenSSL 0.9.8 sends such ClientHellos in the default settings, I > think TLS 1.3 should support the following: > > 1. TLS 1.3 Clients must only negotiate TLS 1.0 or up. I think with the > Poodle attack most servers and clients already deactivated SSL v3 > support. This is draft-ietf-tls-sslv3-diediedie-00. > 2. A TLS 1.3 Client most not send a SSL v2 or SSL v3 ClientHello. This > is draft-ietf-tls-sslv3-diediedie-00. > 2. A TLS 1.3 server may or should accept a SSL V2 and V3 compatible > ClientHello, but not negotiate these protocol versions. Maybe some people would like to see that TLS 1.3 should never be set up using an SSLv2 compatible client hello. Kurt From nobody Sun Dec 28 09:06:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3591AD5A6 for ; Sun, 28 Dec 2014 09:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 dWJ6G834KUQi for ; Sun, 28 Dec 2014 09:06:46 -0800 (PST) Received: from hauke-m.de (hauke-m.de [IPv6:2001:41d0:8:b27b::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC02E1A6FF2 for ; Sun, 28 Dec 2014 09:06:45 -0800 (PST) Received: from [IPv6:2001:67c:20a1:1192:224:d7ff:fe5f:d4e4] (unknown [IPv6:2001:67c:20a1:1192:224:d7ff:fe5f:d4e4]) by hauke-m.de (Postfix) with ESMTPSA id 4CABC20114 for ; Sun, 28 Dec 2014 18:06:40 +0100 (CET) Message-ID: <54A0389F.2070800@hauke-m.de> Date: Sun, 28 Dec 2014 18:06:39 +0100 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nfV4OpDBtT0A53Cu4lA281lfvS8 Subject: [TLS] make ChangeCipherSpec a handshake message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 17:06:48 -0000 Why is ChangeCipherSpec a special type and not just a handshake message? It is only send in the handshake and preceded and followed by handshake messages. DTLS has some functionality for reordering of handshake messages. All the handshake messages have a message_seq field which is used to bring the messages into the right order again and detect duplicates. The messages can get into the wrong order if they are send independently and not the hole flight in one turn. This gets even messier when the packages are getting retransmitted. When packages are getting retransmitted all packages from a flight are getting retransmitted even if just one of these packages were not received. With the message_seq field one can detect if this package was already received and what is the next package to handle. The ChangeCipherSpec package does not have a message_seq field, but it also has to get reordered and retransmitted like the handshake packages. RFC 6347 already says there is a problem in DTLS: https://tools.ietf.org/html/rfc6347#section-4.2.5 I worked on a DTLS 1.2 implementation some time ago and there I had to do some magic to support reordering of the ChangeCipherSpec message. My proposal for TLS 1.3 is to make ChangeCipherSpec a normal handshake message. This should make DTLS implementations based on TLS 1.3 easier and TLS 1.3 gets rid of one special case. When this gets changed the enum in the ChangeCipherSpec message can get removed as it only contains one static value. The ChangeCipherSpec message would be similar to the ServerHelloDone message. Hauke From nobody Sun Dec 28 09:16:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3421AD5D0 for ; Sun, 28 Dec 2014 09:16:31 -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 E2LiTars73tK for ; Sun, 28 Dec 2014 09:16:29 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332661AD5F1 for ; Sun, 28 Dec 2014 09:15:23 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id va2so38257912obc.8 for ; Sun, 28 Dec 2014 09:15:22 -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=1Z7bzeko6bOa4bxmEIx/NhY0CfHan0QGLAgJvvuOzrg=; b=DCIaRuIXokhFGF20zG30KTL6qnReR+m1HBt0ZoSFOWpoNHny0wxwUCPh8n800bhi7X 01wOSoFI0UOy5PGUHueCzFW5UdYmGAAzf2Q/yeaobXcS4LuHIjwX8Ldp8K/UReO7y5Ly FrKoFIORgmLzbeDBaYPYSXN8/OawDPJwFF8vde0u4r8S9MBqpGDRBcXErQWGErLUMZ8A HZfZoaxSYKNDm/CJAN/RpJs+C8Mvpg/wzbo0ETJjmDlZ67ZYZ41NFvg2jOEvOc4S98Jb exKxmIxFyTs0jBJCpSFep1redNSajDtM3rnYr27fn294YVjKcMQml6x4Olbln63WrA0W w1KQ== X-Gm-Message-State: ALoCoQntSYsXmlAQ7x55tsHabmw0m4ybYVHSV2pQjldMYJuCg9O4p+O/fb40ZmRkQcHk4DIsdA2k MIME-Version: 1.0 X-Received: by 10.202.177.8 with SMTP id a8mr19563449oif.92.1419786922377; Sun, 28 Dec 2014 09:15:22 -0800 (PST) Received: by 10.76.71.228 with HTTP; Sun, 28 Dec 2014 09:15:22 -0800 (PST) In-Reply-To: <201412280713.10015.davemgarrett@gmail.com> References: <201412280713.10015.davemgarrett@gmail.com> Date: Sun, 28 Dec 2014 09:15:22 -0800 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4eeJd5RuqKpipRq9WXxgiZKEOGg Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] backwards compatibility section updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 17:16:31 -0000 Dave Garrett wrote: > Suggestions for other things that might be warranted to add: > > 1) Require SCSV? No. Anything related to non-secure fallback should be put in the separate downgrade-scsv draft, and not in the TLS specification, since implementations shouldn't be doing the non-secure downgrade anyway. > 2) Require/recommend Encrypt-then-MAC on fallback? No. The TLS 1.3 spec should focus on specifying TLS 1.3, which doesn't allow CBC-mode cipher suites. Another document can deal with recommending Encrypt-then-MAC. > 3) Add note about ClientHello length bug in certain implementations? > (what officially happened to the padding extension?) IIUC, F5 servers that have the ClientHello length bug probably also have the POODLE bug, so a client implementing the padding extension may actually be a loss for security. Also, some Cisco server implementations do not work with the padding extension. So, I don't think it makes sense to recommend the padding extension in the spec. Cheers, Brian From nobody Sun Dec 28 09:21:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A834B1AD5D9 for ; Sun, 28 Dec 2014 09:21:01 -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 VWl_fCbKRavS for ; Sun, 28 Dec 2014 09:20:59 -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 431821AD5D7 for ; Sun, 28 Dec 2014 09:20:59 -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 88D4981812; Sun, 28 Dec 2014 19:20:56 +0200 (EET) Date: Sun, 28 Dec 2014 19:20:56 +0200 From: Ilari Liusvaara To: Hauke Mehrtens Message-ID: <20141228172056.GA31928@LK-Perkele-VII> References: <54A0389F.2070800@hauke-m.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54A0389F.2070800@hauke-m.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sLLWXOO9C0_HTHdqelGyqzpy08s Cc: tls@ietf.org Subject: Re: [TLS] make ChangeCipherSpec a handshake message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 17:21:02 -0000 On Sun, Dec 28, 2014 at 06:06:39PM +0100, Hauke Mehrtens wrote: > Why is ChangeCipherSpec a special type and not just a handshake message? > It is only send in the handshake and preceded and followed by handshake > messages. > > DTLS has some functionality for reordering of handshake messages. All > the handshake messages have a message_seq field which is used to bring > the messages into the right order again and detect duplicates. The > messages can get into the wrong order if they are send independently and > not the hole flight in one turn. This gets even messier when the > packages are getting retransmitted. When packages are getting > retransmitted all packages from a flight are getting retransmitted even > if just one of these packages were not received. With the message_seq > field one can detect if this package was already received and what is > the next package to handle. I think the plan is to rip out CCS entierely, that is, rely on handshake state machine to initate the key transitions (which should make it more difficult to get wrong). -Ilari From nobody Sun Dec 28 09:48:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72331AD630 for ; Sun, 28 Dec 2014 09:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 TwQ4wcXVrrgO for ; Sun, 28 Dec 2014 09:48:53 -0800 (PST) Received: from hauke-m.de (hauke-m.de [5.39.93.123]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D549C1AD62E for ; Sun, 28 Dec 2014 09:48:52 -0800 (PST) Received: from [IPv6:2001:67c:20a1:1192:224:d7ff:fe5f:d4e4] (unknown [IPv6:2001:67c:20a1:1192:224:d7ff:fe5f:d4e4]) by hauke-m.de (Postfix) with ESMTPSA id 8CE542016F; Sun, 28 Dec 2014 18:48:51 +0100 (CET) Message-ID: <54A04282.1050403@hauke-m.de> Date: Sun, 28 Dec 2014 18:48:50 +0100 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Ilari Liusvaara References: <54A0389F.2070800@hauke-m.de> <20141228172056.GA31928@LK-Perkele-VII> In-Reply-To: <20141228172056.GA31928@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3kdel6Es-h6EyFU_vpp9Z59jOIw Cc: tls@ietf.org Subject: Re: [TLS] make ChangeCipherSpec a handshake message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 17:48:53 -0000 On 12/28/2014 06:20 PM, Ilari Liusvaara wrote: > On Sun, Dec 28, 2014 at 06:06:39PM +0100, Hauke Mehrtens wrote: >> Why is ChangeCipherSpec a special type and not just a handshake message? >> It is only send in the handshake and preceded and followed by handshake >> messages. >> >> DTLS has some functionality for reordering of handshake messages. All >> the handshake messages have a message_seq field which is used to bring >> the messages into the right order again and detect duplicates. The >> messages can get into the wrong order if they are send independently and >> not the hole flight in one turn. This gets even messier when the >> packages are getting retransmitted. When packages are getting >> retransmitted all packages from a flight are getting retransmitted even >> if just one of these packages were not received. With the message_seq >> field one can detect if this package was already received and what is >> the next package to handle. > > I think the plan is to rip out CCS entierely, that is, rely on handshake > state machine to initate the key transitions (which should make it more > difficult to get wrong). Removing CCS entirely is the best solution. I haven't seen any discussions about this plan. I just looked into the TLS 1.3 handshake in more detail and it should be pretty easy to detect where a CCS should be. As long as all handshakes are using ECDHE, DHE or something with a similar handshake I do not see a problem with just removing the CCS message, but when something like static PSK Cipher are getting added and the handshake is very different there it could cause some problem. (I haven't thought in detail about this) Actually in the DTLS implementation I worked on, I placed the CCS message more or less by guessing form the context. Hauke From nobody Sun Dec 28 10:44:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38A01A8A57 for ; Sun, 28 Dec 2014 10:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hlwdRc9Yccqr for ; Sun, 28 Dec 2014 10:44:29 -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 168281A8A51 for ; Sun, 28 Dec 2014 10:44:28 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3736347625; Sun, 28 Dec 2014 18:44:27 +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 2929047622; Sun, 28 Dec 2014 18:44:27 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 206DD2026; Sun, 28 Dec 2014 18:44:27 +0000 (GMT) Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 28 Dec 2014 13:44:26 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.15]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sun, 28 Dec 2014 13:44:26 -0500 From: "Salz, Rich" To: Hauke Mehrtens , Yoav Nir , "Dave Garrett" Date: Sun, 28 Dec 2014 13:44:25 -0500 Thread-Topic: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft Thread-Index: AdAirLfuH0ji0W6WRb2WgzO63fXRKgAIVovw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D53@USMBX1.msg.corp.akamai.com> References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> <54A0171D.9070504@hauke-m.de> In-Reply-To: <54A0171D.9070504@hauke-m.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TGIR1yQapjKtpsrTbLTHbw4f3jE 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: Sun, 28 Dec 2014 18:44:30 -0000 VExTIDEuMyBpcyBnb2luZyB0byByZXF1aXJlIG5ldyBjb2RlLiAgQSBjbGllbnQgc3VwcG9ydGlu ZyBUTFMgY2FuIGlzc3VlIGEgcG9zdC1TU0wyIGhhbmRzaGFrZS4gQSBzZXJ2ZXIgc3VwcG9ydGlu ZyBvbGQgY2xpZW50cyBjYW4gdHJ5IHRoZSBuZXcgaGFuZHNoYWtlLCBhbmQgdGhlbiBmYWxsYmFj ayBhbmQgcmUtcGFyc2UgaWYgaXQgZG9lc24ndCB3b3JrLg0KDQpUaGlzIGlzIGEgbmV3IHByb3Rv Y29sIHZlcnNpb24sIG5vdCBhIEJDUC4gIElmIG5vdCBub3csIHdoZW4gQ0FOIHdlIG1vdmUgdGhp bmdzIGZvcndhcmQ/DQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlciwgQWthbWFp IFRlY2hub2xvZ2llcw0KSU06IHJzYWx6QGphYmJlci5tZSBUd2l0dGVyOiBSaWNoU2Fseg0KDQoN Cg== From nobody Sun Dec 28 10:55:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC601A8960 for ; Sun, 28 Dec 2014 10:55: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 YnI-F5hf1Kcw for ; Sun, 28 Dec 2014 10:55:04 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C951A89F2 for ; Sun, 28 Dec 2014 10:55:04 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 131so6010937ykp.31 for ; Sun, 28 Dec 2014 10:55:03 -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=G3laXNRtQ0Sus/WhJzVz1rc/MBOQ8XWN3SRjM6QS61g=; b=MNxeEhzx/PqnJbiCEDm+7dJqDbBgF/cmcVnbPBuuv0zgu5bUyV71b4wpc+C8+WqLZz n5YGbXi6oiqiNx/6R6lec2o0uL1AfLKUN1caWd4xRIzu61UtU7MLQs3K2YmupN/8c78j +eMMXKTKOUkVVJDgvTiqGvbH6U3tjwV6wZ6kU2Rqsbo4TY1IC26efIJpXoNwTfaYU3y8 xW6UU/WfOQUqq+b/QHLqKcmeaWcAI2k9Mu3ZGpui2F3hp71YgtjsuvepL4lqJbkxlUlS Q1soye0682c3tvY8OEkGa0yDWhRrIRv94+n2RAW52f2SSN7JrksXB3IMTiVAc3Mtz0fu L9ZA== MIME-Version: 1.0 X-Received: by 10.236.30.168 with SMTP id k28mr20297888yha.163.1419792903806; Sun, 28 Dec 2014 10:55:03 -0800 (PST) Received: by 10.170.207.6 with HTTP; Sun, 28 Dec 2014 10:55:03 -0800 (PST) In-Reply-To: <20141228164421.GA5437@roeckx.be> References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> <54A0171D.9070504@hauke-m.de> <20141228164421.GA5437@roeckx.be> Date: Sun, 28 Dec 2014 13:55:03 -0500 Message-ID: From: Watson Ladd To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dcMECk9hdA1FqmBqVrhXif_8PMY Cc: "TLS@ietf.org \(tls@ietf.org\)" , Dave Garrett 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: Sun, 28 Dec 2014 18:55:06 -0000 On Sun, Dec 28, 2014 at 11:44 AM, Kurt Roeckx wrote: > On Sun, Dec 28, 2014 at 03:43:41PM +0100, Hauke Mehrtens wrote: >> Hi, >> >> as even OpenSSL 0.9.8 sends such ClientHellos in the default settings, I >> think TLS 1.3 should support the following: >> >> 1. TLS 1.3 Clients must only negotiate TLS 1.0 or up. I think with the >> Poodle attack most servers and clients already deactivated SSL v3 >> support. This is draft-ietf-tls-sslv3-diediedie-00. >> 2. A TLS 1.3 Client most not send a SSL v2 or SSL v3 ClientHello. This >> is draft-ietf-tls-sslv3-diediedie-00. >> 2. A TLS 1.3 server may or should accept a SSL V2 and V3 compatible >> ClientHello, but not negotiate these protocol versions. > > Maybe some people would like to see that TLS 1.3 should never be > set up using an SSLv2 compatible client hello. I am really confused as to what the proposed v2 compatible, TLS 1.3 hello would look like. TLS 1.3 demands extension support, and the SSLv2 and v3 protocols do not support extensions. We've already seen bugs and workarounds (padding extensions) resulting from continued support of SSLv2. There is a working version negotiation mechanism in TLS 1.0 and above which doesn't have these issues. We should use it: a tiny handful of old clients don't matter. Sincerely, Watson Ladd > > > Kurt > > _______________________________________________ > 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 Sun Dec 28 14:38:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD241AC3E4 for ; Sun, 28 Dec 2014 14:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1bewJRf-QPj for ; Sun, 28 Dec 2014 14:38:12 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D901AC3CF for ; Sun, 28 Dec 2014 14:38:12 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 9so6125845ykp.36 for ; Sun, 28 Dec 2014 14:38:11 -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=iuy4xWrRavMJUOrL3UQZIpLlELJnnCayQjvB2Ts03pM=; b=dU6//ABhdd52g4xT442JEIh03ZSYmDNKsZdk69Y3eFToqrOHgn51MAasrJ8CI2FKJO r2Bms7RXKywSJk399tBsCtrQd5Nd2ByqAbqKHkWd5mzM+xjdlhF7S2jdio0KWBUbv6ge 7xWScUKC6XDSrROLJFbokRK56q/ou9rZj1A8+tW9oA2CLIWnPwEHpIo+T8scZe2xuqxo 8oD3qoOPhsaOqiJeY2lcDS8b3da7uG4L+/8VkrbvM1QriaMG2xrjVb7joDLPfD7BlKN0 ifGsj9UZdc6XaJkAecSzDyAy90rllJTJpM2YR2gj2ZmP0VUknAKRqi71v11PESZ4Eujk JB7A== MIME-Version: 1.0 X-Received: by 10.170.220.195 with SMTP id m186mr8665660ykf.58.1419806291222; Sun, 28 Dec 2014 14:38:11 -0800 (PST) Received: by 10.170.207.6 with HTTP; Sun, 28 Dec 2014 14:38:11 -0800 (PST) Date: Sun, 28 Dec 2014 17:38:11 -0500 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0VjRY8gkKOAFwUnzQwKTYt4VwTc Subject: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 22:38:13 -0000 Dear all, I invite you to consider the following interesting sources http://www.spiegel.de/media/media-35511.pdf http://www.spiegel.de/media/media-35510.pdf These show that the NSA has a comparatively easy time exploiting static RSA. >From this it seems that performance actually matters: the slow speed of DH exchange compared to ECC explains why ECC, and not DH is replacing RSA. DH is also being attacked by PHOENIX: I can wild mass guess that this is batch FFS: I don't know if this has been researched extensively, and even batch NFS has only an asymptotic analysis. Given the low usage of the DH handshake, and potential vulnerabilities (not potential, but certainly not as well understood) should we keep it in TLS 1.3? Sincerely, Watson Ladd From nobody Mon Dec 29 03:58:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BCC1A039D for ; Mon, 29 Dec 2014 03:58:52 -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 KP3Ya7x9oxpi for ; Mon, 29 Dec 2014 03:58:47 -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 70DCB1A0394 for ; Mon, 29 Dec 2014 03:58:45 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 396B93A0E9; Mon, 29 Dec 2014 12:58:43 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 2FF0B43198; Mon, 29 Dec 2014 12:58:43 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 258CD1B0B4; Mon, 29 Dec 2014 12:58:43 +0100 (CET) In-Reply-To: <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> To: Yoav Nir Date: Mon, 29 Dec 2014 12:58:43 +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: <20141229115843.258CD1B0B4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PVyTHxlNUNTHRXyJbTKgeY-t9kQ Cc: Dave Garrett , "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 Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 11:58:53 -0000 Yoav Nir wrote: > > I see a "should" from Hauke and a "should not" from you. > But using RFC 2119 words like ?MUST NOT? in the spec could > mean one of the following things: Using RFC2119 words "MUST NOT" in the spec would mean, according to section 6 of RFC2119, that such a requirement would be NULL and VOID. > >> Dave Garrett wrote: >> >> December 27, 2014 05:07:12 pm Hauke Mehrtens wrote: >>> 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. JDK 1.6 might be past its "End of Public Updates", but it is still fully supported and pretty omnipresent, in particular in company environments and the majority of server-side (J2EE) installations. http://www.oracle.com/technetwork/java/javase/eol-135779.html You can start the JavaVM with the additional command line parameter -Dhttps.protocols="TLSv1" but the default seems to be the use of a SSL VERSION 2.0 CLIENT-HELLO at the beginning of a new connection. OpenSSL 0.9.8 is also in use with enterprise installations, such as SUSE SLES-11(up to and including sp3), for which the General supports ends on 31-Mar-2019 and extended support ends on 31-Mar-2022 https://www.suse.com/lifecycle/ Breaking backwards interop just for the sake of the fun of it is a bad idea and will slow down adoption. Poor backwards interop slowed and is still slowing down adoption of TLSv1.2, and same for IPv6. -Martin From nobody Mon Dec 29 04:02:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9221A038E for ; Mon, 29 Dec 2014 04:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.295 X-Spam-Level: * X-Spam-Status: No, score=1.295 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, 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 bytqdewM7x5J for ; Mon, 29 Dec 2014 04:02:08 -0800 (PST) Received: from smtp-01-out.s.azet.sk (smtp-07-out.s.azet.sk [91.235.53.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1624C1A0390 for ; Mon, 29 Dec 2014 04:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1419854526; bh=x8Jv4vN6aZIj6JhegsR1ZWoQZxbsx3zOZpOglquSHvY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=XzZApafx6LRWGEgdWjJEKUHStatThhaVAIk21FeW43YTN9sBfMWla/ITg8ltjo/JA naw/v7M2L61A244T12/b5TW4oTjpXN/+toj/nyzinJJTItdzaEf9BRAZtGIzG++3rQ gnXRZ8QrD0TWJdPbOdM3l+p5GEsqpPNX2KcjYo6E= X-Virus-Scanned: by AntiSpam at azet.sk Received: from [0.0.0.0] (weltgehirnmaschine.de [5.9.107.38]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 9038988 for ; Mon, 29 Dec 2014 13:02:03 +0100 (CET) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 9038988 Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk Message-ID: <54A142BA.2010302@azet.sk> Date: Mon, 29 Dec 2014 13:02:02 +0100 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FdUxTk1X1tEnsOnnyhZtHr6BaoU Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 12:02:10 -0000 On 28.12.2014 23:38, Watson Ladd wrote: > Dear all, > > I invite you to consider the following interesting sources > > http://www.spiegel.de/media/media-35511.pdf > http://www.spiegel.de/media/media-35510.pdf > > These show that the NSA has a comparatively easy time exploiting static RSA. > >>From this it seems that performance actually matters: the slow speed > of DH exchange compared to ECC explains why ECC, and not DH is > replacing RSA. DH is also being attacked by PHOENIX: I can wild mass > guess that this is batch FFS: I don't know if this has been researched > extensively, and even batch NFS has only an asymptotic analysis. > > Given the low usage of the DH handshake, and potential vulnerabilities > (not potential, but certainly not as well understood) should we keep > it in TLS 1.3? > > Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > http://www.spiegel.de/media/media-35537.pdf NSA is very carefully watching all crypto, metadata and SIGINT related development at IETF. For example: "New session policy extensions may improve our ability to passively target two sided communications," says a brief write-up of an IETF meeting in San Diego on an NSA-internal Wiki. From nobody Mon Dec 29 04:53:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7891A1A1B01 for ; Mon, 29 Dec 2014 04:53:07 -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, 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 90xMovWmePCX for ; Mon, 29 Dec 2014 04:53:05 -0800 (PST) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2AC1A1B12 for ; Mon, 29 Dec 2014 04:50:19 -0800 (PST) Message-ID: <54A14E11.6060002@akr.io> Date: Mon, 29 Dec 2014 12:50:25 +0000 From: Alyssa Rowan MIME-Version: 1.0 To: "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IBTglnP0_O91_ayvGaFLK71HKlk Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 12:53:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 28/12/2014 22:38, Watson Ladd wrote: > These show that the NSA has a comparatively easy time exploiting > static RSA. When SIGINT/LE agencies later steal the keys; absolutely, they would, as there's no forward-security. (Of course, we're fixing that.) They also namedrop the Debian key low-entropy issue as a practical attack. Nice historical graphs. No surprises. (Maybe we could FOIA and get their statistical trends data to contribute on top of researchers' existing TLS survey metrics! Might as well be good for something. Of course, that would mean admitting they're doing mass surveys… ) > From this it seems that performance actually matters: the slow > speed of DH exchange compared to ECC explains why ECC, and not DH > is replacing RSA. Agreed. There was also the issue of >1024-bit DHE field selection, interoperability, and Java 6. > DH is also being attacked by PHOENIX: I can wild mass guess that > this is batch FFS: I don't know if this has been researched > extensively, and even batch NFS has only an asymptotic analysis. They say PHOENIX is "publicly known" - so maybe it's simpler than that and something already extensively researched in (what they would call) the "open source" literature. (The active attack replacing the field with a trivially-attacked one that's addressed in TLS 1.2 by the ffdhe draft may be a potential candidate, although I'm not sure if active attacks fit in the flowchart there.) > Given the low usage of the DH handshake, and potential > vulnerabilities (not potential, but certainly not as well > understood) should we keep it in TLS 1.3? Given the speed penalty, and the ffdhe difficulty, and this - I'd say no, drop it. Finite-field DHE is worse than good ECDHE (and/or X25519). (Non-ephemeral key agreement definitely needs to go, too; didn't Eric already call for consensus on that?) - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUoU4RAAoJEOyEjtkWi2t6cecP/3c0E3Z0qaPCMEOuUhf2Z5Ym 1WJ6Y3N6srX0z6l3JwOqqqllUHWHnj2/aqoQDU++z1L5Y1vXppgUzPvCKvb6aMtN Fjr9GeFXW/tWcOwSrtmB2Ta7knh85luu8bMaLp2SdrU+41h0sfFYYBUGec6RAiiF HLMv5fpFavOOdDfMIfUfnfvDMKeC9Hkw5d16GJTPZZP93BetwUgQypf+Tedl/ATH KbGAhqFB6c/svkUevdzXGhHcBoqlMbwG3RQNIjhHw6YinDgIuwZdCD9alxhSoQdb lwKYG3smIcTCpRdiTcEZRpV3SCN36Q3ClkZWf0sVBCNM9LessyT3TRlXnjj8pec4 O8ZwfXjmc4YxLlrd787Eri2DRzv0nP1+V/Jdyz5uDhfn1LCArz8/cnJcW9PNd3Me 0FFZ3kL8n2PzXo4+K57K0jD8LpfbvWeIT6nUvBTfrAPTo4r8WCRLRxc3St5Zx2qL fy9L6RHOlZEjC8cjI1YCxgrMlOQvK5j6WJY9K8GqltlQpcDkPhJNXEa9xBHuu12V fO8VEIzHZOD6TZRTuK6oyXl102TVGVTbVGDE1H0gzsZWBJXNE6Ks5LbvkqJKE2ob 3v0wu5BF+xLPw/LdTQZaJowHXOFajU7LBlDIpH2PaCkk5n3ipSQejZceoGU0P0w0 7m0+CztnK1pFUAnp2jqD =8Rac -----END PGP SIGNATURE----- From nobody Mon Dec 29 09:03:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2321A89BB for ; Mon, 29 Dec 2014 09:03: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 kC5MGZORMSCq for ; Mon, 29 Dec 2014 09:03:29 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C133E1A89B5 for ; Mon, 29 Dec 2014 09:03:28 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so22609638wib.4 for ; Mon, 29 Dec 2014 09:03:27 -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=5vZrraY40+yqooI8EluUDnnEtAa0V9gAyOmQijR+fok=; b=FbpqMe4PRs7NHe3MKsrr4HCY6j/dfpYnggTl7fgaOXPIg82FjeT4Se/cPXJW1wKQa7 gBwbTOesLABoWb+XtiHFudxzslvaJw0LrMLEtOUjsE+vBd+t2HTs2Os533za0dPaNq71 nlaVl/Oww+VtYRu2TFOhRkG4tUzaCWw4cHoq2W8UNEe4DP1xpXyUX5oYgDkoJpkAAclU EoxQ8BhK7UxcHRcaUix4ahK6mATDc6K3woefIF6bcy70marFuI4Q4LZV8PmUz+GkwGHL SRLcK5e3gRZTtjzMJZEj5D3YmNjczTjYuLUkDgN14W4MRVHViNHG87SBT3m1DFONUWLS aVcw== X-Gm-Message-State: ALoCoQlwyx+MZYUUy+iXI6P0OBC85gP1SpIqw0afkpsatmpOTTzzmE3qQe52s3/Xgr1UcM7jfrwG X-Received: by 10.194.235.193 with SMTP id uo1mr110111241wjc.105.1419872607425; Mon, 29 Dec 2014 09:03:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Mon, 29 Dec 2014 09:02:47 -0800 (PST) In-Reply-To: References: <860778484.3559563.1416987612674.JavaMail.zimbra@redhat.com> <20141223143719.GB11149@LK-Perkele-VII> <20141224185031.GA4583@LK-Perkele-VII> <20141224193906.GB4583@LK-Perkele-VII> From: Eric Rescorla Date: Mon, 29 Dec 2014 09:02:47 -0800 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=089e01419e0264725d050b5ddaee Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3sxFDnBB2njcu-g0KtVvQTBzvw8 Cc: "tls@ietf.org" Subject: Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:03:30 -0000 --089e01419e0264725d050b5ddaee Content-Type: text/plain; charset=UTF-8 I've updated AGL's PR as described above. https://github.com/tlswg/tls13-spec/pull/110 I'll be merging this later today. Please comment on the PR if I introduced any errors. -Ekr On Sat, Dec 27, 2014 at 7:32 AM, Adam Langley wrote: > On Wed, Dec 24, 2014 at 10:01 PM, Eric Rescorla wrote: > > Thanks for the clarification. What do other people think about this > > suggestion? > > I think it's a great idea. I'll send a PR after the holiday unless > someone beats me to it. > > > Cheers > > AGL > --089e01419e0264725d050b5ddaee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've updated AGL's PR as described above.

=

I= 9;ll be merging this later today. Please comment on the PR if I introduced<= /div>
any errors.

-Ekr


On Sat, Dec 27, 2014 a= t 7:32 AM, Adam Langley <agl@imperialviolet.org> wrote:=
On Wed, Dec 24, 2014 at 10:01 PM, Eric Rescorla = <ekr@rtfm.com> = wrote:
> Thanks for the clarification. What do other people think about this > suggestion?

I think it's a great idea. I'll send a PR after the holiday = unless
someone beats me to it.


Cheers

AGL

--089e01419e0264725d050b5ddaee-- From nobody Mon Dec 29 09:10:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4891ACF7C for ; Fri, 26 Dec 2014 14:47:07 -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 2qCDIWy-cL8c for ; Fri, 26 Dec 2014 14:47:06 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03C51ACF80 for ; Fri, 26 Dec 2014 14:47:05 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id v10so4105261qac.25 for ; Fri, 26 Dec 2014 14:47:05 -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=By4ZwkP6Rnp3YXpA7Ddy6mOILxgEoUcx9eHY4mjc0tQ=; b=DYH+gYwjbS5FnPcNc1dvyxxh3GupsKVQMSsHSBUAVlE4OKQp9bQB7bsFLvz0cEjZvl LSbIx1jbl7ruqNeOmtdN+Sn3ZI4wUbe2YtDYJNQsCBfN1tJZBGqHdHorfo9xf2In+0Rt xyRzxv//evja2m/oEsoRK+g7Y54hIQw/LfJK90HshkZBnNV+V5pXCVYleet0oD0SqAiQ X66sY8dluSBrx9Pa3x7tuNbdXEpnHayur3cIiYVdmBiJxqopU1aSnDs8fgRsgMi6p6Gm xSpy1+sxNKnVJw1CbfpxiS9JSsHQrV8NcP0Sdm//dJ4XvHLnXv7K9DoH3JD+dAqZQii5 CfJg== X-Received: by 10.224.25.139 with SMTP id z11mr37616748qab.17.1419634025100; Fri, 26 Dec 2014 14:47:05 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id k4sm27119397qaf.0.2014.12.26.14.47.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Dec 2014 14:47:04 -0800 (PST) From: Dave Garrett To: Kurt Roeckx Date: Fri, 26 Dec 2014 17:47:00 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> <20141226181139.GA5321@roeckx.be> In-Reply-To: <20141226181139.GA5321@roeckx.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412261747.00959.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/My9fZSSNnc0Gh0SMQKYD-ZL6A90 X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 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: Fri, 26 Dec 2014 22:47:07 -0000 On Friday, December 26, 2014 01:11:39 pm Kurt Roeckx wrote: > On the other hand if you do receive such a client hello you're > likely talking to old software that most likely isn't support > anymore and might have various security issues. It might be a > good indication of clients you prefer not to talk to. My primary concern is that continuing to maintain official support for a deprecated format from an insecure protocol leaves a significant amount of complexity in place just to support woefully out-of-date implementations. I think that many people agree that one of the main goals of TLS 1.3 needs to be reduction of complexity. The more legacy features that are removed, the simpler the protocol will be, and the safer it will be to implement properly. Refusing to connect to these old clients will also, hopefully, get some of them upgraded to new ones that actually work with modern protocols. > 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? If there were a simple way to detect that, without having to support the old hello format, and reply with a simple refusal that triggered a negotiation using TLS, then that might be preferable. However, at some point it's just not worth it. You just have to cut off backwards compatibility, eventually. Also, I'm not sure I agree that TLS 1.0 is still acceptable. Personally, I'd like to see an official deprecation and an attempt to force implementations to upgrade to at least 1.2 at some point. HTTP/2 should help here, I hope. (at least on the web) It would be nice to not have to panic and handle some fatal flaw in TLS 1.0 like had to be done for SSL 3. Dave From nobody Mon Dec 29 09:10:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60A91ACFB7 for ; Fri, 26 Dec 2014 15:58:25 -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 f0BDQiP770Ht for ; Fri, 26 Dec 2014 15:58:23 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9DA1ACFB6 for ; Fri, 26 Dec 2014 15:58:23 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id bm13so7550252qab.3 for ; Fri, 26 Dec 2014 15:58:22 -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=2T0K78o2LpXlbPWFqXbqJiyEiAjg6H0BqPBvjhRUXU0=; b=bLpGELNSi+Lf1mGzJbdHeGEe11QroAjWhUeN5QN+i12FHjBk6KvCjd4zOsnbI0J7PT CmvbjEReRyneFp8FFDmj7KIjAcW/XBDfkKNdzxYO5b9czrnkl1D0wyriXT7Yuxn6CK0a 5zNqeTnQRuynutYggSMXPuvRELla0+dh+dN/GREbo2vPuPmB+W7y6l3yJ62QH7vtr9mt Xjq4Qnf6wnL8/GoyDzACwGPA9tYGPu+eXy8kd0mG2eQ21hrwEWnKUXjvFfODKpSdZjEp q85lJp80jxTdF++cgenbxco2qOp06ufBzC6xR2wU6tWZeSiR2ePE7iEi2Bx/TXaHO7ai yz9Q== X-Received: by 10.140.95.71 with SMTP id h65mr6251575qge.92.1419638302843; Fri, 26 Dec 2014 15:58:22 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id j3sm18464617qas.19.2014.12.26.15.58.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Dec 2014 15:58:22 -0800 (PST) From: Dave Garrett To: Kurt Roeckx Date: Fri, 26 Dec 2014 18:58:19 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> <201412261747.00959.davemgarrett@gmail.com> <20141226232625.GA7199@roeckx.be> In-Reply-To: <20141226232625.GA7199@roeckx.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412261858.20140.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mHywVYvrp-NczYWki1J7r1511sk X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 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: Fri, 26 Dec 2014 23:58:26 -0000 On Friday, December 26, 2014 06:26:25 pm Kurt Roeckx wrote: > Isn't it up to the implementations to decide if they still wish to > support it? Does it do any harm to support it other then possible > talking to outdated software? > > (It currently seems to be about 150 lines in OpenSSL, and it seem > clear to me that it's just to support that.) It's always possible for some implementation to have a bug in how it handles hellos. Having to decipher which is which is not as clean as one would hope. Just because it's probably being done correctly now, doesn't mean some (new) implementation couldn't do something bad here. If there is a problem, it's probably not going to be properly tested, seeing as it's an obsolete format. It's yet another thing to worry about. > Even if TLS 1.3 reduces complexity, it's not suddenly going to > make any implementation less complex. I think it's likely going > to make things more complex. It's not like we're going drop > support for the older protocols at the same time. We'll add one > more that is different then the others. Well, strictly speaking, the goal is to add as little new complexity as possible, in total. Dropping SSL3 support is at least another drop in complexity, as well. > > Refusing to connect to these old clients will also, hopefully, get some > > of them upgraded to new ones that actually work with modern protocols. > > Or prevent the adoption of the new software because it breaks > things. Anyone using software that old has probably already made that choice. :/ > I would also like to get rid of TLS 1.0. It's just not realistic > to do this at this point in time. Only about 50% of the http > servers support TLS 1.2 currently. I agree. I'm certainly not in favor of an SSL2/3 style prohibition RFC, or anything. I'm just saying that it would be far better to attempt to put some pressure on them rather than just waiting around. Unfortunately, I admit that changing UIs to indicate HTTP as insecure, and releasing HTTP/2 and letsencrypt.org are prerequisites to getting serious about not tolerating out- of-date security. An official "please stop using TLS 1.0" from the IETF is about the best one could hope for, at the moment. I guess we'll get that to some degree with: https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08 Dave From nobody Mon Dec 29 09:10:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239D81AC3AC for ; Sat, 27 Dec 2014 14:39: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, 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 NnQkl-a7AKxk for ; Sat, 27 Dec 2014 14:39:28 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30481A1AA9 for ; Sat, 27 Dec 2014 14:39:27 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id dc16so7849099qab.8 for ; Sat, 27 Dec 2014 14:39:27 -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=GmSwZ8i1G21PTYU7hxrv9LoaAfjuEtg9u1BXHK6UAR0=; b=vzkdfsQChpuTIAYaAR+iNsEyE2ibLk6KcCMT8rHa9R4CvGRn7DdwamG3nkVA/X0Iua s1E08BmLCJzIwGWDQSxQuu9kMvlt7ZKfMkL11I9tLzh8cUp9Q0BrLN3QORMsGexeYchC efRyC8mS4xZ8G7vkcC0v+2rhGF4thT0bwYSpvZiiji7NdqrJkvvL1NxB7xRmnnMMA0Sn 6zSLQ9ufjj8xmjGHccubVRZJ/U/L89h2tCh+oH100rpdYSVffR7PkUAAhqOto6kCjU6r rluFU/AUFakhoW1IWCEe0zVIztsj9M9XUK7cBc13WOTxNp4GJV/S78y1Br8Ew+L0gD4Z UQlg== X-Received: by 10.229.135.202 with SMTP id o10mr79146520qct.9.1419719966983; Sat, 27 Dec 2014 14:39:26 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id f11sm23288111qga.42.2014.12.27.14.39.26 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 27 Dec 2014 14:39:26 -0800 (PST) From: Dave Garrett To: Hauke Mehrtens Date: Sat, 27 Dec 2014 17:39:24 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> <549F2D90.5030305@hauke-m.de> In-Reply-To: <549F2D90.5030305@hauke-m.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201412271739.24476.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ltL8qJhqaJCShjjugwpmLcwEYCk X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 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: Sat, 27 Dec 2014 22:39:29 -0000 On Saturday, December 27, 2014 05:07:12 pm Hauke Mehrtens wrote: > On 12/24/2014 07:40 AM, Yoav Nir wrote: > > It=E2=80=99s fine for us to break compatibility with these clients, but= let=E2=80=99s not > > pretend it=E2=80=99s some ancient technology that doesn=E2=80=99t exist= in the market > > anymore. >=20 > 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. >=20 > 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 a= n 8=20 year old EOL Java version's default settings. Dave From nobody Mon Dec 29 09:10:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917241ACD0E for ; Sat, 27 Dec 2014 15:42:24 -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 M4uk43tVFgoG for ; Sat, 27 Dec 2014 15:42:23 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B33F1ACD0B for ; Sat, 27 Dec 2014 15:42:23 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id m20so8381513qcx.31 for ; Sat, 27 Dec 2014 15:42:22 -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=wnIB7vnuiMImUZIn7QFPbiN1yeudovZvs/JroO73fAI=; b=VVMGzdVRYlR/CGCU2nmzh1n3z0xziGNkgPm0Cj51xPjLIpf4mK1Y/wo3YyBj9Zjiof smhDOMFOvKMHogXGPrkz4c0DWCBsDCNzqGVZTa0mFRtwfBs8TYqYABc+GYo8QhjMwas9 mJeaTORYxKNZONRxY1CgRhYGRYClxqWMlm6WHcT0N4+Jvk4DYZdsnKYgDBvZU8gvdld3 uTAwoSgFnY6DPY5Cuj2Rm+Ub3F6gzbj3G915QFHm8tfvX7L2w07pTh2F3fQa9MWtGXVB 7SxsdhuA2s3rOKp+XQDuxRAmQqfKJUNaIOXm3KtmR2t8dVglNnnNJ8g+N25orKmBzrIy 16GQ== X-Received: by 10.224.111.194 with SMTP id t2mr76297168qap.86.1419723742438; Sat, 27 Dec 2014 15:42:22 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id p49sm29693977qgp.30.2014.12.27.15.42.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 27 Dec 2014 15:42:21 -0800 (PST) From: Dave Garrett To: Yoav Nir Date: Sat, 27 Dec 2014 18:42:20 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> <201412271739.24476.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> In-Reply-To: <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201412271842.20834.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AgpIP5nWDBJWOi0u8nPVD0WTv4I X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 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: Sat, 27 Dec 2014 23:42:24 -0000 On Saturday, December 27, 2014 05:54:22 pm Yoav Nir wrote: > I see a "should" from Hauke and a "should not" from you. But using RFC 21= 19 > words like =E2=80=9CMUST NOT=E2=80=9D in the spec could mean one of the f= ollowing things: > 1, That an SSLv2 ClientHello with version equal to whatever we choose for > TLS 1.3 (0x03,0x04?) must be rejected and the connection closed. 2. That > any TLS 1.3 implementation MUST remove support for SSLv2 ClientHellos. 3. > That it is no longer prudent to even perform handshakes with clients that > still offer SSLv2. The intent of the language used is #3. Specifically, neither the version no= r the=20 hello format from 1995 should be considered acceptable in 2015. > In this case SSLv2 support is used as a proxy for insecure peer. Indirectly, yes, though not directly. I'm simply stating that having to=20 implement the obsolete format is an unreasonable kludge to keep around. If = it=20 weren't for the differing format, I'd be suggesting simply refusing to nego= tiate=20 SSL2 as is already expected. > In your message you said =E2=80=9Cshould not=E2=80=9D. Why do you think w= e need to mandate > dropping this support from existing products? Inverted: Can you really make a full justification for keeping this around = still? =46abrice's reply gives a specific example of breakage from this, if you wa= nt one. Dave From nobody Mon Dec 29 09:10:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D521ACD45 for ; Sat, 27 Dec 2014 16:06:05 -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 OhgT992CRXJX for ; Sat, 27 Dec 2014 16:06:04 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25541ACD32 for ; Sat, 27 Dec 2014 16:06:03 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id e89so6529516qgf.28 for ; Sat, 27 Dec 2014 16:06: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=Q6VAshypFBxYabzJBgSF0Dj8wamDlsNZvl9QEErP7cE=; b=B5NS47xN2w52R42+P7MDbBvqYcF+92T/MImYBh3bqRmEnoVGBUo6M2Do/1CuBgunz0 L8pklS+sliStarJqMVzfrYfDaBeLJwARpGutQwtUyct7gT34iBxw5OzzFMvxmNsYdiZL 2uxg8IlmXEx0fvnRDKHE47HNii1XkQ86W8Yll7UORTpm223qcJyNYq1BNrUIesLvlXPj 7iEGFfM0qN0d5DtnsHtuWdQ1DzcJ60w/LmmV7N4p27ck0jASSXnLZ3vnx51qqS7vpg5W TLBDUkFF9krUDLGx5dJjsQGoS4J+8Q5CEcHx1NxjcY+qUUAplKw6ka+pLbPpvddLvqyR YLhg== X-Received: by 10.224.25.139 with SMTP id z11mr44640634qab.17.1419725162998; Sat, 27 Dec 2014 16:06:02 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id y10sm29523854qad.23.2014.12.27.16.06.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 27 Dec 2014 16:06:02 -0800 (PST) From: Dave Garrett To: Brian Smith Date: Sat, 27 Dec 2014 19:06:00 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201412271906.00820.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NTw1CZddN5esinTHb2YMS_oR-bA X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 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: Sun, 28 Dec 2014 00:06:06 -0000 On Saturday, December 27, 2014 06:37:08 pm Brian Smith wrote: > if the server is allowed to support TLS 1.0, then it should seems > reasonable for it to negotiate TLS 1.0 with a client that sent an > SSL2-compatible TLS 1.0 ClientHello. TLS 1.0 is perfectly capable of negotiating using the proper hello. The fact that some clients are EOL and might not do connect in a way that will work forever is not something worth worrying about. I don't think it's unreasonable to expect that 20 years later the "new" hello format should be mandatory. Let's stop and think about this for a moment. We're discussing a message format from a two decade old protocol, generally considered to be woefully insecure and unfit for any use. It has been listed in the "backwards compatibility" section since SSL3 in 1996. The following has been in there for 19 years: "Warning: The ability to send version 2.0 client hello messages will be phased out with all due haste. Implementers should make every effort to move forward as quickly as possible." SSL2 messages should not be tolerated at this point if we want TLS 1.3 to be considered a specification for a modern security protocol implementation. > However, I think it is fine to > say that the server MUST NOT implement support for the SSL2 protocol. > And, it is fine to say that all TLS clients MUST NOT use > SSL2-compatible ClientHellos, since they wouldn't be able to add > extensions if they did. That is already agreed upon via RFC 6176. https://tools.ietf.org/html/rfc6176 Dave From nobody Mon Dec 29 09:10:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFA11ACE70 for ; Sat, 27 Dec 2014 17:07:58 -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 HY47KL22gHb9 for ; Sat, 27 Dec 2014 17:07:54 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E6D1ACE75 for ; Sat, 27 Dec 2014 17:07:54 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id f51so8330578qge.35 for ; Sat, 27 Dec 2014 17:07: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=xpThICAeYBFnpmzEOw/On5xU5JgqZtWZJbQsTe2rHHg=; b=jbg7l74zPpGgHLL4R+ypNU3Sd4u6GhEhK2VRjymExlv9fAUrjtd1wrn4eHsVx/yl0E 8eR4RcHqlv73HH3uqAAo2X5nqjeFSSEhMQt/Vv4n6q/1qy4AX+goOAnhJrluUEZamO1z l9P3GFKkXbChq8twspL4W/u0UVjmMhKWEYBYADp2IW6kfnt6jAAMAYH4Kl7aslyIX/hY nia/5/AcWGhU2b5OfJil8xDC33dbCe1Pk6wnHSmp9XkiWUJU5C1HW89XbK0jEuhFQ8f8 eNI1k7Vif6/2if/4Acdjop4ixM/tKa/NHnxJ45QL6yLMVnPrLTY4ACN5ZTSaxmEkg6P4 8DXA== X-Received: by 10.229.99.134 with SMTP id u6mr79740528qcn.10.1419728873330; Sat, 27 Dec 2014 17:07:53 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id b39sm28159234qge.10.2014.12.27.17.07.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 27 Dec 2014 17:07:52 -0800 (PST) From: Dave Garrett To: Brian Smith Date: Sat, 27 Dec 2014 20:07:51 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> <201412271906.00820.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201412272007.52081.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_4rHW3AhlPIScc6I3IdFTrM-ZaI X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 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: Sun, 28 Dec 2014 01:07:58 -0000 On Saturday, December 27, 2014 07:39:07 pm Brian Smith wrote: > Dave Garrett wrote: > > On Saturday, December 27, 2014 06:37:08 pm Brian Smith wrote: > >> if the server is allowed to support TLS 1.0, then it should seems > >> reasonable for it to negotiate TLS 1.0 with a client that sent an > >> SSL2-compatible TLS 1.0 ClientHello. > > > > The fact > > that some clients are EOL and might not do connect in a way that will > > work forever is not something worth worrying about. I don't think it's > > unreasonable to expect that 20 years later the "new" hello format should > > be mandatory. > > > > SSL2 messages should not be tolerated at this point if we want TLS 1.3 to > > be considered a specification for a modern security protocol > > implementation. > > Like I said in my previous message, I do think that for TLS 1.3, > SSL2-compatible ClientHellos must not be used since they don't allow > extensions. Further, it is better for the TLS 1.3 spec to remove all > the text describing the SSL2-compatible hello stuff, regardless of > whether or not supporting SSL2-compatible-ClientHello for TLS > 1.0/1.1/1.2 is explicitly prohibited or not. I'm hesitant to even mention it, but obviously my next most preferred route is obviously to do that and make acceptance of an SSL2 hello for older TLS versions a SHOULD NOT rather than a MUST NOT. That, however, is basically just RFC 6176 with a wag of a finger thrown in. If the TLS WG was doing the proper thing, namely writing a TLS 1.3 that was just an update of TLS designed to make implementing modern security easier and saving other changes for TLS 1.4, then I would probably agree with your position. It's not though; HTTP/2 is having to be released with a messy hack to attempt to make TLS 1.2 palatable. The response I got to suggesting a more iterative approach was that people wanted to fix all the problems and get it right. That's a bit of a contradiction with considering this hello format valid for any use. There have been bugs caused by supporting this and it should be mandated to no longer be usable for all implementations. Anyone actually relying on it and not capable of flipping the client-side switches needed to stop it is not likely to be a candidate for early adoption of TLS 1.3, anyway. Dave From nobody Mon Dec 29 09:10:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33C11ACE7D for ; Sat, 27 Dec 2014 17:51:25 -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 9DlqXYO9ML2A for ; Sat, 27 Dec 2014 17:51:24 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDAD1ACE7C for ; Sat, 27 Dec 2014 17:51:24 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so8241585qcx.41 for ; Sat, 27 Dec 2014 17:51:23 -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=+gx5b+ux7PijjHykeozLOXcrTvf/JBPvmxDqlvIplMk=; b=SZJM+t8zBz9Y/B9G9Ajld5xW9Wpu76PZzQEWUZ9p8ClmZ8tw+QVNDe9vCiaI8Vh9N9 wDJvsqZMnQXJ0rSK+7nNLEIjjZIZfS6eY09CWmKde5dLJMS7V+CuGquPvevB0GsoWHM+ R8n2K0xb9tFU3OaKMwG9NHuUXeN8SIxRpeb8UvwYyTYJnU83V9juf4o+L18TG4ncuskI BB/429kD5iKzNh/WElRdUcml/G0RsUBPyIPJnkMzbDplLT4RqWkkUdfDc5QiahlxJGe2 q3IfBmKoCZ/jcWBgZGQHSbEOQbUPaVFvtfFRG1Z8R/btw4eNXpYot2nXWR/gRUYfknTb rBZQ== X-Received: by 10.224.103.195 with SMTP id l3mr66048139qao.38.1419731483285; Sat, 27 Dec 2014 17:51:23 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id k9sm30019926qaj.7.2014.12.27.17.51.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 27 Dec 2014 17:51:22 -0800 (PST) From: Dave Garrett To: Brian Smith Date: Sat, 27 Dec 2014 20:51:21 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> <201412272007.52081.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201412272051.21819.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KsvUajph3SNR0t2-uuB0WRgpL80 X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 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: Sun, 28 Dec 2014 01:51:26 -0000 On Saturday, December 27, 2014 08:38:56 pm Brian Smith wrote: > Servers generally cannot flip switches on the client. I'm referring to situations where an organization has legacy software they use with old clients and an old server. In a case like that, they would be capable of pushing a pref change to their clients easily enough. If we're talking about obsolete clients on the general web, then no, obviously. I just prefer breakage over perpetuating its legitimacy. > I want TLS 1.3 to be deployed widely and quickly after it's been > standardized, and I want people to be able to put it into production > use during the standardization effort so we get the same kind of > interop testing that HTTP/2 got. This requires that the TLS 1.3 spec > should try to avoid breaking how earlier versions of TLS work, unless > there is a very strong reason to do so. Very much agreed, however I argue that legacy complexity and its resultant risks are strong enough, and that not enough clients would break to justify keeping it. (the later could unfortunately be swayed with stats that say otherwise) Dave From nobody Mon Dec 29 09:10:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476261ACFFE for ; Sun, 28 Dec 2014 04:13:14 -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 fXYm7B3GRXBQ for ; Sun, 28 Dec 2014 04:13:12 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2063E1ACFF8 for ; Sun, 28 Dec 2014 04:13:12 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id x3so8587615qcv.15 for ; Sun, 28 Dec 2014 04:13: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:mime-version:content-type :content-transfer-encoding:message-id; bh=qooEoSx4xXlfqMQpQ7u9cREq0m5/g4ihXF76blbe46A=; b=jXRXM3Lb4Xb+V4Vr1asUaZFq1DIlW8V27hncbDSss4R0bqzOI7hEAXqtIKdRn3nAUQ PaKzm1vrQdaoQ+o/IX52dx5bwh0A5nctVVRXZv0p4aXRUyGdZgxfxd1ltpiNPy20+oUz 89SvMHbC12hyFyo1MbMkRnR9sOEESj02Zj8kdkLi8wv5QnEbpbcu5BkrpjquvoJB/UJA btoIoEoKx5PNUbD/pRwhfhj8TGaGuXdx7G9ZP/Ed3WIcjhUYxXpfNTyxReAkAGeYHnpv 78KhlkePVbC/Pdg4bx0l64DhUsIzQ4h6J1My6SQY17XXx3s/URzEFyVZ7L15hijLBBhh JuSQ== X-Received: by 10.224.14.66 with SMTP id f2mr17352580qaa.81.1419768791336; Sun, 28 Dec 2014 04:13:11 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id p35sm31040036qgd.5.2014.12.28.04.13.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 28 Dec 2014 04:13:10 -0800 (PST) From: Dave Garrett To: Brian Smith Date: Sun, 28 Dec 2014 07:13:09 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201412280713.10015.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OXNNT0G__GsRf6OQCvoTfqGOfrA X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: [TLS] backwards compatibility section updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 12:13:14 -0000 I've updated my PR for revisions to the TLS 1.3 backwards compatibility section. https://github.com/tlswg/tls13-spec/pull/107 (SSL changes in PR 105) Suggestions for other things that might be warranted to add: 1) Require SCSV? 2) Require/recommend Encrypt-then-MAC on fallback? 3) Add note about ClientHello length bug in certain implementations? (what officially happened to the padding extension?) Anything else in here that needs fixing/updating? Note that Encrypt-then-MAC sounds good, but I don't know if enough implementations will support it but not TLS 1.3 to be worth mandating. Dave From nobody Mon Dec 29 09:10:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648F91A89F2 for ; Sun, 28 Dec 2014 11:01:16 -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 yUxru7oQboBw for ; Sun, 28 Dec 2014 11:01:15 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7BC1A8A98 for ; Sun, 28 Dec 2014 11:01:14 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id b13so9866063qcw.34 for ; Sun, 28 Dec 2014 11:01:14 -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=0GJFZgIVkr3Cq8j3RnSYd5aQLSgIOKQYj/EfEl2ow5Q=; b=sb8twTpN0tQ1xJr5pyy0wLGn+yz7KmRLYXOvn88l/dWuy2uMrUXkHIWdR74WwskZqI 6k3Buahm6Hb5t6qRklNpeXJa5JDigaMnsu0o63w2rmDzYX5SbXU8+v9BgAVr3EP0ZKOS sWYGWyQohMiZ6mtDWkDFfDK/MmIM3Q8y+mmcoIuK63Nt2F/aGc71/XgQWLfnGWi+bzdE qAuHq32NGYQ06OXUbQrhRuFd8L7fUWr53OCVSveK9nvWjMB3xj4NLczsLn6vvWBSIi9/ rV666BLqLFnm3/bRqYkrCIVVSxr0PuOdiPO6ceCvxioVSfA7eC8exrSxXHXkYe6kgBzd ES4A== X-Received: by 10.140.89.176 with SMTP id v45mr70302325qgd.44.1419793274039; Sun, 28 Dec 2014 11:01:14 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id r12sm31785775qax.38.2014.12.28.11.01.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 28 Dec 2014 11:01:13 -0800 (PST) From: Dave Garrett To: Hauke Mehrtens Date: Sun, 28 Dec 2014 14:01:11 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <201412221945.35644.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> <54A0171D.9070504@hauke-m.de> In-Reply-To: <54A0171D.9070504@hauke-m.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201412281401.11441.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5ViikHZ43JVZDMNkqR1yyuGNpa8 X-Mailman-Approved-At: Mon, 29 Dec 2014 09:10:39 -0800 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: Sun, 28 Dec 2014 19:01:16 -0000 On Sunday, December 28, 2014 09:43:41 am Hauke Mehrtens wrote: > as even OpenSSL 0.9.8 sends such ClientHellos in the default settings http://openssl.6102.n7.nabble.com/OpenSSL-0-9-8-End-Of-Life-Announcement- td54154.html OpenSSL 0.9.8 will be EOL next year and is receiving only security updates until then. Servers still using it will not be affected by whatever is specified in TLS 1.3. What client would still be using this? (and why should we care?) Java 6 has been EOL for a couple years now. New security protocols should not be written to accommodate dead software, especially if there's no plausible reason to legitimately use it still. I restate again, that even these EOL implementations are perfectly capable of interoperating with the proposed spec if properly configured. SSL2 & SSL3 should not be enabled. This is already agreed upon. (pending second RFC passage for official status) The desire to continue supporting SSL2 hellos requires the acceptance that it is legitimate to expect an insecurely configured implementation to work forever. This is not a safe thought process. Also, it breaks things. It'd be nice to stop that. Dave From nobody Mon Dec 29 09:42:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1E11A889F for ; Mon, 29 Dec 2014 09:42: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 shmIiauOAW7l for ; Mon, 29 Dec 2014 09:42:54 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A491A8885 for ; Mon, 29 Dec 2014 09:42:54 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id b13so19434067wgh.32 for ; Mon, 29 Dec 2014 09:42:51 -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=w+Os0geiBeXItUgrx2Xi1q2npif1PCk+94lfthoVmDw=; b=tGg5CkG9YxfQ/DIz+BHxOwRSHgv+Nhb5yks3OzpT0UEFuFBI/YwWk6Y2hjirgb0guH U91xz0M5OLgxb9JOJwjN9ykiwGsjUymCv0YEX+oYOUx7XqiEwnE08WFyOZgFpajMdAb8 QsfELNfxqzjn1h+qcagUKYQwRC/N9e+oRt6wbT7Zvbn/c9taPLfmuFEQPMUJRpcxEj8i 7OhsAoIqSPG4KvDeLmGrmK/34SCzpQlHFRQFjFujp+0qBfEfakO8O5uxU4Wsg5LCEagO izuhlSdo9peAdlwXGQOLKUyqopeCvOOYMfIzE121sw0wKEyimI4rbXOO8rcI7ORo9SrO SrRA== X-Received: by 10.180.20.50 with SMTP id k18mr99729469wie.31.1419874971336; Mon, 29 Dec 2014 09:42:51 -0800 (PST) Received: from [192.168.1.104] (IGLD-84-228-227-214.inter.net.il. [84.228.227.214]) by mx.google.com with ESMTPSA id wv8sm50742121wjc.44.2014.12.29.09.42.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Dec 2014 09:42:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Mon, 29 Dec 2014 19:42:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E137973-DFFA-44D6-A59A-CC8DF0972828@gmail.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t5UVMNIpwX_ekRMLHxqv-D4h2uE Cc: "tls@ietf.org" Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:42:56 -0000 I don=E2=80=99t know of any reason besides legacy compatibility to = support regular DH. In IKE it is necessary, because DH (and forward = secrecy) was mandatory from the start. In TLS PFS has been defined = forever, but it only became popular fairly recently, when ECDHE was = already defined and implemented. So speaking only for myself, I have no plan to add FF DH in my TLS = implementation. I=E2=80=99ve said as much when TLS was considering = DKG=E2=80=99s draft.=20 Yoav > On Dec 29, 2014, at 12:38 AM, Watson Ladd = wrote: >=20 > Dear all, >=20 > I invite you to consider the following interesting sources >=20 > http://www.spiegel.de/media/media-35511.pdf > http://www.spiegel.de/media/media-35510.pdf >=20 > These show that the NSA has a comparatively easy time exploiting = static RSA. >=20 >> =46rom this it seems that performance actually matters: the slow = speed > of DH exchange compared to ECC explains why ECC, and not DH is > replacing RSA. DH is also being attacked by PHOENIX: I can wild mass > guess that this is batch FFS: I don't know if this has been researched > extensively, and even batch NFS has only an asymptotic analysis. >=20 > Given the low usage of the DH handshake, and potential vulnerabilities > (not potential, but certainly not as well understood) should we keep > it in TLS 1.3? >=20 > Sincerely, > Watson Ladd From nobody Mon Dec 29 11:03:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935FD1A9042 for ; Mon, 29 Dec 2014 11:03: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 jU8Ow8iAvkMh for ; Mon, 29 Dec 2014 11:03:33 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432A71A903E for ; Mon, 29 Dec 2014 11:03:31 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id g201so30067438oib.12 for ; Mon, 29 Dec 2014 11:03:30 -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=se0uU6kEec2vrSLrSdaC92X5X2IwvNQndrX+4ehdiD0=; b=nmxWpWXujsE8rgzIfKB3oJBMiIjJIVc8vphoJwP8X7+8/U978/mI4WSO/zyMMki2gw qpcfzcSOnrVq8XV7ex7M/ZRrX19SS7U9oCLQfIlYcWLMo17h21OIKoFxbtcQu7xIK/B9 iQ9NinFGGrqSljcN3F93wgyF41n9vV4xbVJwkwrpSbHVdzJtT5buqJhC/nNTdkL7uJbo BEdTi368e17addl9LxORqESA7dX1R4Y2/IsveRKYJJNrO/TmQ3M4mBcoz12Mpa38CDxJ 5A7uBhagd1YHZdgA/xXxiqRzowJL9ODorZOmYPgxhokPrZ/OV0O4Lez71Z87MVEPIwHH vmXg== MIME-Version: 1.0 X-Received: by 10.202.89.213 with SMTP id n204mr8063142oib.77.1419879810385; Mon, 29 Dec 2014 11:03:30 -0800 (PST) Received: by 10.202.49.203 with HTTP; Mon, 29 Dec 2014 11:03:30 -0800 (PST) In-Reply-To: <20141229115843.258CD1B0B4@ld9781.wdf.sap.corp> References: <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> <20141229115843.258CD1B0B4@ld9781.wdf.sap.corp> Date: Mon, 29 Dec 2014 11:03:30 -0800 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yWKDGWtyJrwzDzt-TKFulchFTrk Cc: Dave Garrett , "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: Mon, 29 Dec 2014 19:03:36 -0000 On 29 December 2014 at 03:58, Martin Rex wrote: > Breaking backwards interop just for the sake of the fun of it is a bad > idea and will slow down adoption. Poor backwards interop slowed and is > still slowing down adoption of TLSv1.2, and same for IPv6. I think that - as I think Brian suggested earlier - requiring TLS 1.3 clients not to offer SSLv2/3; and requiring TLS 1.3 servers not to negotiate 1.3 with clients that offer SSLv2/3; is perfectly reasonable. As a practical matter, we'll be relying on Hello extensions, so those combinations are impossible anyway. No one is going to change what Java 6 does. And mandates on what any deployment should do outside of what is required for TLS 1.3 would be inappropriate for this draft. Our separate recommendations on SSLv2/3 elsewhere should suffice. You might agree to ignore those recommendations. That is, as always, your prerogative. RFC compliance being essentially voluntary. From nobody Mon Dec 29 11:27:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DBE1A90DB for ; Mon, 29 Dec 2014 11:27:02 -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 DmbVESxbVhtd for ; Mon, 29 Dec 2014 11:27:00 -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 EDCD31A90C9 for ; Mon, 29 Dec 2014 11:26:59 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id B8C5C3A207; Mon, 29 Dec 2014 20:26:57 +0100 (CET) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id AD03B421D5; Mon, 29 Dec 2014 20:26:57 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A288B1B0B6; Mon, 29 Dec 2014 20:26:57 +0100 (CET) In-Reply-To: <201412291408.24237.davemgarrett@gmail.com> To: Dave Garrett Date: Mon, 29 Dec 2014 20:26:57 +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: <20141229192657.A288B1B0B6@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7qJRA65zJb6luXfxj3A4WmSLF9s 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 Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 19:27:02 -0000 Dave Garrett wrote: > Martin Rex wrote: >> JDK 1.6 might be past its "End of Public Updates", but it is still >> fully supported and pretty omnipresent, in particular in company >> environments and the majority of server-side (J2EE) installations. > > Server-side usage would not be affected by the proposed changes. Server-side usage will be significantly adversely affected by a silly MUST NOT accept TLSv1.2 offered in SSL Version 2.0 CLIENT-HELLO > > Server and client usage in company environments are where it is easiest > to deal with the proposed changes. The clients' settings just need to be > changed to stop using SSL entirely and send only v3 hellos. The Server's setting will have to be changed to modify the client connections originating from a J2EE server that is using Java 6. > > I'll restate again, this is already the consensus. > (again, assuming no surprises with the SSL3 I-D) > > http://tools.ietf.org/html/rfc6176 You might be misreading that document: http://tools.ietf.org/html/rfc6176#section-3 o TLS servers MAY continue to accept ClientHello messages in the version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2], Appendix E.2. A SSL Version 2.0 CLIENT-HELLO offering TLSv1.2 is perfectly sufficient to negotiate the mandatory-to-implement TLSv1.2 TLS cipher suite: https://tools.ietf.org/html/rfc5246#section-9 > > "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT- > HELLO message format" This applies only to *NEW* clients. This does not affect the behaviour of the installed base at all. The Server-side needs to address the behaviour of the installed base for the purpose of interop. > > With both SSL2 & SSL3 prohibited, there should be no v2 hellos. But there still are plenty of them around in the installed base. > > Put bluntly, any environment that actually HAS v2 hellos is already > ignoring IETF RFCs. Behaviour of the installed base is well known to be unaffected by documents published by the IETF (or any other organization, or government). -Martin From nobody Mon Dec 29 12:28:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2883D1AC3EF for ; Mon, 29 Dec 2014 12:28:18 -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 yf7IglM2VOzH for ; Mon, 29 Dec 2014 12:28:15 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943521A8AD7 for ; Mon, 29 Dec 2014 12:28:15 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q108so9892876qgd.1 for ; Mon, 29 Dec 2014 12:28:14 -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=HN4/1Wr/VVwGVdCHovPtEF7H746m+IfYfvrZ+bSklGI=; b=Y8skp1QFA0USg/10M1s4bS/6P2dbdIiMbKxp03MC9RyeFV3XMRgEWIoeVQoBmfwMHS 7pjJlJDgWoFLY2IzhQvUFYNs9l7tZ0U8SneHdQGY9x162LhpsNSJKiWN1ICtBviyzPlC O5JVVoodJoXEc4QW29KKci+zTNU3/CFThvAotFms8wGqzHmUcm9lOyUrLtBqppD7u7qC mMn4mhGV9ZsCXpUorXSdCGltkeK5CJOkzp3JN2gIt/boLyluO9T80j+EZFTRtw82hgjL ONBhSTh4b9JZmETw/BeV3wY0DMq21xiW6mi8QgccWHO3B4j/+MpFoQN+Q7Hyvjh16lia 7vqg== X-Received: by 10.224.131.4 with SMTP id v4mr92150913qas.99.1419884894742; Mon, 29 Dec 2014 12:28:14 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id b1sm15768493qac.34.2014.12.29.12.28.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 29 Dec 2014 12:28:14 -0800 (PST) From: Dave Garrett To: mrex@sap.com Date: Mon, 29 Dec 2014 15:28:11 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <20141229192657.A288B1B0B6@ld9781.wdf.sap.corp> In-Reply-To: <20141229192657.A288B1B0B6@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412291528.11915.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_NeeEE3dgPff60Nha9VvZEfsTA4 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: Mon, 29 Dec 2014 20:28:18 -0000 On Monday, December 29, 2014 02:26:57 pm Martin Rex wrote: > Server-side usage will be significantly adversely affected by a silly > MUST NOT accept TLSv1.2 offered in SSL Version 2.0 CLIENT-HELLO This is a semantical disagreement. The server will continue to work fine, just dropping v2 connection attempts. It's the client sending the v2 hello that will be disaffected. (it could be phrased from either perspective; the client initiates the connection, so I significantly prefer this one) > o TLS servers MAY continue to accept ClientHello messages in the > version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2], > Appendix E.2. Yes, in 2011 optional backwards compatibility was left in place. In 2015 I'm saying that it shouldn't be expected anymore. (or let's be realistic, 2016, when the slow to update get around to considering this) > A SSL Version 2.0 CLIENT-HELLO offering TLSv1.2 is perfectly sufficient > to negotiate the mandatory-to-implement TLSv1.2 TLS cipher suite: > > https://tools.ietf.org/html/rfc5246#section-9 Wrong reference? That's just the MTI cipher. SSL2 compatibility in TLS 1.2 is here: https://tools.ietf.org/html/rfc5246#appendix-E.2 What it does say is: "However, even TLS servers that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO messages." It's only sufficient if the server is willing to do so. It's not to be expected. This is a "MAY" and not a "SHOULD". Clients MUST send v2 to connect to SSL2 servers, but that's it. It is important to remember, however, that this section is not a valid reference as-is. RFC 6176 amends it. https://tools.ietf.org/html/rfc6176 > > "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT- > > HELLO message format" > > This applies only to *NEW* clients. Please cite to me where it says that RFC 6176 only applies to new clients. (is there actually some other reference I'm missing that says that? that's certainly possible) It simply says: "Updates: 2246, 4346, 5246" & "This document updates the backward compatibility sections found in the Transport Layer Security (TLS)." Thus, anything that implements any of the updated TLS 1.x RFCs is expected to implement this amendment in full. If there's some policy I'm missing here, please do point it out. However, I'm under the impression that this is fairly unambiguous and SSL2 is not to be considered acceptable anywhere. This does not seem like a controversial position to take in 2015. > > With both SSL2 & SSL3 prohibited, there should be no v2 hellos. > > But there still are plenty of them around in the installed base. > > > Put bluntly, any environment that actually HAS v2 hellos is already > > ignoring IETF RFCs. > > Behaviour of the installed base is well known to be unaffected by documents > published by the IETF (or any other organization, or government). I certainly can't disagree with that. I can disagree that it should be the overriding force in deciding what to do next. ----- Let me sum things up this way. There are two categories here: A) Obsolete implementations that are insecure and supported by nobody. B) Obsolete implementations that are at least maintained by some group. Category B is the enterprise situation. Their IT & the software they use maintains this old stuff in some way. Disabling SSL2 & SSL3 is not an unreasonable expectation for continued maintenance if their desire is to switch servers over to TLS 1.3 capability. If they don't want to adopt TLS 1.3 servers yet, they are not affected until they do. TLS 1.3 clients would only fail to connect to SSL only servers. Complying with intervening RFCs is simply a requirement to implement the new RFC. Category A is forsaken. There is no expectation of a secure connection with those clients. Dragging along backwards compatibility forever for them would be irresponsible. If they break, they will have to be replaced with something that continues to work. If this was half the population of the Internet, then yeah, we'd have to pathetically work around them, but that is not the case. Modern clients are fine here and have more than enough widespread use. If IE6 breaks, nobody can argue in good conscience that TLS 1.3 should be modified to accommodate that. And again, it is entirely possible to click a few checkboxes in its security options to fix the issue. (IE has generally had decent configurability here) I don't know about you, but I'd like to see a world where the only pages old versions of IE can connect to are ones that let you download a new browser or at least upgrade its security slightly. Is there some specific real-world case this opposition is coming from? An argument to defend a specific widely used client, with justification for its continued use, would be far more persuasive. Simply "ahh, but Java 6" doesn't feel like a particularly useful argument when Java 7 & 8 are long since available. Give me significant hard numbers and I'll certainly change my opinion to a "SHOULD NOT" rather than a "MUST NOT" for all but pure TLS 1.3 connections. (the idea that TLS 1.3 should be negotiatable via an SSL2 hello is insane) Dave From nobody Mon Dec 29 12:32:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA5C1A8AD7 for ; Mon, 29 Dec 2014 12:32:44 -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 WP9JW5e350yE for ; Mon, 29 Dec 2014 12:32:43 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1967E1A8AEB for ; Mon, 29 Dec 2014 12:32:43 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id x3so9985562qcv.29 for ; Mon, 29 Dec 2014 12:32:42 -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=n57PPar5nI3zS8quVmj+cSMYGGejtqMQ50UPC7fgqxQ=; b=vzEUkHROESGerMo+j7JNOHZ9h+oJ/r6yJlW9oEuQnGrM7/7hyp7AHG05FEwCdPJa4l TZd6FaosVQPb4Sm5ZMdzv3+2TOsKZJD2tA1W6jySlMbmYunmCEC7ZKyNIl+Iu4ppYWvQ 60AiaFOtx+YUaE/CNVXuekUVO5Ye/RaqNK9V+j+9/8CfKKYJ3FFNadaZZP2xdycQOyh4 Ei0JhBsPHJ9KBonc28i+Kf2KR8Vt7O+VkDy6zjQe3bdxD7mbZ4wMsqPR5esh2jvQzkB7 E6M8gD2AJ9mgyXiLYiAEbvKzWNBP3s9zwuChOc3y/HyZxEylFNlFGiT6v4U05vqhkbhS F6wg== X-Received: by 10.224.112.9 with SMTP id u9mr85908795qap.18.1419885162214; Mon, 29 Dec 2014 12:32:42 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id r16sm34361193qay.10.2014.12.29.12.32.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 29 Dec 2014 12:32:41 -0800 (PST) From: Dave Garrett To: mrex@sap.com, "TLS@ietf.org (tls@ietf.org)" Date: Mon, 29 Dec 2014 15:32:39 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <20141229192657.A288B1B0B6@ld9781.wdf.sap.corp> <201412291528.11915.davemgarrett@gmail.com> In-Reply-To: <201412291528.11915.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412291532.39846.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xiDBrKdcuy6_rNfUKTN_vFCJyDM 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: Mon, 29 Dec 2014 20:32:45 -0000 On Monday, December 29, 2014 03:28:11 pm Dave Garrett wrote: > On Monday, December 29, 2014 02:26:57 pm Martin Rex wrote: > > A SSL Version 2.0 CLIENT-HELLO offering TLSv1.2 is perfectly sufficient > > to negotiate the mandatory-to-implement TLSv1.2 TLS cipher suite: > > https://tools.ietf.org/html/rfc5246#section-9 > > Wrong reference? That's just the MTI cipher. SSL2 compatibility in TLS 1.2 > is here: > https://tools.ietf.org/html/rfc5246#appendix-E.2 Sorry, misunderstanding what you were referencing there. The backwards compatibility is in the appendix. The MTI cipher _itself_ is in section 9. Dave From nobody Mon Dec 29 14:28:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249511A9172 for ; Mon, 29 Dec 2014 14:28:19 -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 KTkZxkdvNrWw for ; Mon, 29 Dec 2014 14:28:17 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519341A9131 for ; Mon, 29 Dec 2014 14:28:17 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so19734749wgh.22 for ; Mon, 29 Dec 2014 14:28: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:mime-version:from:date:message-id:subject:to :content-type; bh=eyP7aNpPYfEFLaWq+7MI4BH3y1HzQq0aaEyEKKY4IaY=; b=frZNIlQQoHiFEHJy0dTwcN8pl2PNZoyJln/qsfWN21i/Qwevbvtv//1ILWBYPC2PlU 5hKltqhIrn2PuTV7VSSnXMFgQFp50orGjpfmPdrkRuLN6yN1gwK0ZXe91VT0XM8P6Pjf xWanrg0Ju1FRhJlC0LRDIF4hiQhoH6V4HkjSCAVt2gbPu0r3lORp5AXBMtfT0pEBlSfc D40tH7i3RNUi1fZKb/iYEnZM+CfygciHzjM5BiMyQyFKiqHsyJ/qTRrI3ALyBh/zDPEB CNQhm5LgxI/Q9ht8RR+rCYCtcYXr9Ep0Rfh0Ow6Ux82N+NyVBPrCCLrlxMi0lyXI78va 7Z7g== X-Gm-Message-State: ALoCoQm4gz0h1/Percq1O1NOGCqP+2UGEmR7pF2JJ5Qi0JcGchY+pjzMmBM3vekJKybms2Q+wXeT X-Received: by 10.181.13.42 with SMTP id ev10mr98817132wid.78.1419892096157; Mon, 29 Dec 2014 14:28:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Mon, 29 Dec 2014 14:27:35 -0800 (PST) From: Eric Rescorla Date: Mon, 29 Dec 2014 14:27:35 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d04388df102de33050b62642c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bEAOsG08hedMH0nVpyz7aUPjjxk Subject: [TLS] Changing handshake code points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 22:28:19 -0000 --f46d04388df102de33050b62642c Content-Type: text/plain; charset=UTF-8 grubba pointed out some issues with the handshake type numbers in 1.3, so I created https://github.com/tlswg/tls13-spec/pull/111. Modulo someone find a problem in the next few hours, I'll merge this tonight. -Ekr --f46d04388df102de33050b62642c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
grubba pointed out some issues with the handshake type num= bers
Modulo someone find a problem in the next few hours, I'll m= erge
this tonight.

-Ekr


--f46d04388df102de33050b62642c-- From nobody Mon Dec 29 20:35:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6421ACD20 for ; Mon, 29 Dec 2014 20:34:58 -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 CMO8qD2-V9Gs for ; Mon, 29 Dec 2014 20:34:54 -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 0B9121ACD19 for ; Mon, 29 Dec 2014 20:34:53 -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=1419914094; x=1451450094; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=7z9Txa+cy3w3szoAPi6xQPumVuAW1+zKoitJTWoUlmg=; b=TONsIKiUuW0XOCkb49Gh0x65WErvP/0p39Ipki1FbaUTjx+X4/Ulj5La rVADIv+X3qhWzHmytwW1f93/zpU1cDDViw86QR1zgGO1TcjGmrEAXK2aH zcQX7w94uiXaPF5ecyGhdMqkpnk67JYmJid8Xzm81qRCmJlZR4XHzidis A=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="298823653" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Dec 2014 17:34:52 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 30 Dec 2014 17:34:51 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Do we need DH? Thread-Index: AdAj6fNGG3O9pH7CSo6QkGgH8wnwBg== Date: Tue, 30 Dec 2014 04:34:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF4C7B5@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: http://mailarchive.ietf.org/arch/msg/tls/DjxDRoaC8bEBvcL5k4ktt_c8vLQ Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 04:34:59 -0000 Watson Ladd writes:=0A= =0A= >I invite you to consider the following interesting sources=0A= >=0A= >http://www.spiegel.de/media/media-35511.pdf=0A= >http://www.spiegel.de/media/media-35510.pdf=0A= >=0A= >DH is also being attacked by PHOENIX: I can wild mass guess that this is= =0A= >batch FFS: I don't know if this has been researched extensively, and even= =0A= >batch NFS has only an asymptotic analysis.=0A= =0A= Where did you see this? All I saw was a note (in 35511) that "EDH key=0A= exchange not exploitable by the 'easy' way" (I assume 'easy' is "grab the= =0A= private key", since that's what's referred to for RSA in the line above). = The=0A= only PHOENIX reference was "pushing new moduli for testing against publicly= =0A= known weaknesses", which could mean anything ("we're checking whether=0A= anything's vulnerable to the small-subgroup attack circa 1997, so far we=0A= haven't found anything"). So if anything it's a ringing endorsement of EDH= .=0A= =0A= In any case I doubt it's FFS (or any other cryptanalytic technique), given= =0A= that the rest of the documents talk about using implants, stealing config= =0A= files with static keys, and similar techniques. That's the cryptographers= =0A= fallacy, "The NSA can attack TLS, they must have some amazing new=0A= cryptanalytic technique that we don't know about". No, they just lifted th= e=0A= static keys from the config file (c.f. the XKCD "hit him with this $5 wrenc= h=0A= until he tells us the password" approach).=0A= =0A= I also note that 35511 seems to be a case of rampant over-classification,= =0A= there's nothing in there that's remotely sensitive or novel, it's just an S= SL=0A= 101 talk. 35510 is barely better, I've seen more detailed data on public= =0A= security blogs.=0A= =0A= Further, interesting to note from 35521 that GCHQ (via FLYING PIG) identifi= ed=0A= the Iranian government using Diginotar certs to target their own citizens.= =0A= =0A= Peter.= From nobody Mon Dec 29 23:23:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CBF1AC3AC for ; Mon, 29 Dec 2014 23:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.048 X-Spam-Level: X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJxYQGibFY5l for ; Mon, 29 Dec 2014 23:23:35 -0800 (PST) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4481A903C for ; Mon, 29 Dec 2014 23:23:34 -0800 (PST) Received: from woodstock.owlhill.net (a88-113-163-188.elisa-laajakaista.fi [88.113.163.188]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id E75B24005F for ; Tue, 30 Dec 2014 09:23:31 +0200 (EET) Received: from [IPv6:2001:14b8:14e:1:e41e:50e5:5314:6c22] (unknown [IPv6:2001:14b8:14e:1:e41e:50e5:5314:6c22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by woodstock.owlhill.net (Postfix) with ESMTP id 2A65A734B261 for ; Tue, 30 Dec 2014 09:23:31 +0200 (EET) Message-ID: <54A252EA.1010905@iki.fi> Date: Tue, 30 Dec 2014 09:23:22 +0200 From: Tapio Sokura User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xddVYti7g_bGqjLgWsJieqkNwpE Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 07:23:37 -0000 On 29.12.2014 0:38, Watson Ladd wrote: > Given the low usage of the DH handshake, and potential vulnerabilities > (not potential, but certainly not as well understood) should we keep > it in TLS 1.3? I'm a bit vary of putting all eggs in the same basket (here ECDH). Why not allow the pre-parametrised form of DH described in draft-ietf-tls-negotiated-ff-dhe in TLS 1.3 and drop the current way of server sending the explicit group parameters? With regards to all eggs being in the same basket, AES is also something that really should have a realistic alternative standardized and deployed _before_ (/if) AES is broken. Like SHA-3 is coming around the corner while SHA-2 is still well alive and kicking. Tapio From nobody Tue Dec 30 00:12:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E411ACEC7 for ; Tue, 30 Dec 2014 00:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[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 GFJ9tBdNBvsa for ; Tue, 30 Dec 2014 00:12:27 -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 33C081ACDC3 for ; Tue, 30 Dec 2014 00:12:26 -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=1419927147; x=1451463147; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OCMU3nEna8yX8lE9lRbtZ1sRMJZy2hWxM5U38tYrknQ=; b=C4fH3NLBVefQ1FbYqFWxidv2bUbmV7afSh9iw4uepzleRyp50bvM7Kg+ d8p2PNu2pphIvoJIv2GvGQpfl3eQ/ol2NRwF2snP+hB4pWu0nDxbS/K3T /kobT32QXuoDMJtPhr3nGiBU0n8USgSaV1YDoqr+Owq2auDKozzPEaNML A=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="298842968" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Dec 2014 21:12:22 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 30 Dec 2014 21:12:23 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft Thread-Index: AdAkCFZdyRPhUar6QYmBW0Klcr+WqQ== Date: Tue, 30 Dec 2014 08:12:22 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF4C93B@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: http://mailarchive.ietf.org/arch/msg/tls/SRSzDQ5SZ2Iex0EV50-xrqDBywg 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, 30 Dec 2014 08:12:29 -0000 Dave Garrett writes:=0A= =0A= >The following has been in there for 19 years:=0A= >=0A= >"Warning: The ability to send version 2.0 client hello messages will be=0A= >phased out with all due haste. Implementers should make every effort to mo= ve=0A= >forward as quickly as possible."=0A= =0A= Another way to look at it is from the truth-in-advertising perspective: cha= nge=0A= the text to match actual practice:=0A= =0A= "Warning: SSL 2.0 is an obsolete, insecure protocol from twenty years ago= ,=0A= however support for version 2.0 client hello messages will be retained in= =0A= perpetuity in order to deal with an increasingly irrelevant remnant of=0A= obsolete software that still uses it. Implementers don't need to make an= y=0A= effort to ever move forward."=0A= =0A= This is simply the existing text rephrased to match actual practice.=0A= =0A= Peter.=0A= From nobody Tue Dec 30 00:20:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEA51ACF1A for ; Tue, 30 Dec 2014 00:20:38 -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=[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 ydARuQ34Azzn for ; Tue, 30 Dec 2014 00:20:36 -0800 (PST) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDAD1ACF02 for ; Tue, 30 Dec 2014 00:20:35 -0800 (PST) Received: by mail-oi0-f50.google.com with SMTP id x69so31747862oia.9 for ; Tue, 30 Dec 2014 00:20:34 -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=cwClB28WWS2vOsi3llGaX0bhxBYmahHkmYAbhEfvSDw=; b=XlwiR+H70m+Loy3nqYfHmRHd91Q6tfcUQnJFgpv75WbSBoF/EtYlZtq2t25+Uwa+aK Fzu9D/GZ2r55e/bTTWZNuWTt2arSKMwIEYR7LLvoe39zEOZhrbjP8BGJ0Ftkb5NlyzkE dGYszdX68XXPxL/YNsIeo1e5zWYwqX+kgQWkA+f3+TE/P99T396JRU4Eh3NgrmU0IZ4l 3O5hkKd5YXn0Z4t6lfEJKXUDLboujq6bU0vtf7gar1RyXGDoPqH/jlxOxMS2Xz1Zov62 INmMvSJoZf1wHoa9plxFwP12Bzuj5XQzO5Z6LaKDMTO0nO5Bn0lrIiDOsk9cQpAQP+ld gPUg== X-Gm-Message-State: ALoCoQm/UXt97+BUN/hXEDusqZuHVfugn2yLQsk6w+qBVvk9iwzmYBJQPIOrRnVoAY207WInQhED MIME-Version: 1.0 X-Received: by 10.60.52.101 with SMTP id s5mr7700191oeo.33.1419927634823; Tue, 30 Dec 2014 00:20:34 -0800 (PST) Received: by 10.76.71.228 with HTTP; Tue, 30 Dec 2014 00:20:34 -0800 (PST) In-Reply-To: <201412291528.11915.davemgarrett@gmail.com> References: <20141229192657.A288B1B0B6@ld9781.wdf.sap.corp> <201412291528.11915.davemgarrett@gmail.com> Date: Tue, 30 Dec 2014 00:20:34 -0800 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uIIUOvb3xU2p5b6KHaGCKNSRg78 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: Tue, 30 Dec 2014 08:20:38 -0000 Dave Garrett wrote: > Yes, in 2011 optional backwards compatibility was left in place. In 2015 I'm > saying that it shouldn't be expected anymore. (or let's be realistic, 2016, when > the slow to update get around to considering this) The change you are suggesting is likely to make people even more slow to update. >> > "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT- >> > HELLO message format" I think everybody agrees with that. The only disagreement is whether the server MUST refuse to accept a v2-compatible TLS 1.0/1.1/1.2 ClientHello, which is a different thing. > Thus, anything that implements any of the updated TLS 1.x RFCs is expected to > implement this amendment in full. No, because we don't expect everybody to conform to every RFC. We regularly have to deal with implementations that do not conform to RFCs. In particular, just because some RFC says that a clients MUST NOT use a SSv2-compatible hello doesn't mean that some servers don't have legitimate need to deal with clients that do send SSv2-compatible hellos. > However, I'm > under the impression that this is fairly unambiguous and SSL2 is not to be > considered acceptable anywhere. This does not seem like a controversial position > to take in 2015. Zero people are arguing that. > A) Obsolete implementations that are insecure and supported by nobody. > B) Obsolete implementations that are at least maintained by some group. > Category A is forsaken. There is no expectation of a secure connection with > those clients. Dragging along backwards compatibility forever for them would be > irresponsible. If they break, they will have to be replaced with something that > continues to work. If this was half the population of the Internet, then yeah, > we'd have to pathetically work around them, but that is not the case. Modern > clients are fine here and have more than enough widespread use. If IE6 breaks, > nobody can argue in good conscience that TLS 1.3 should be modified to > accommodate that. Dave, I think there is pretty strong agreement that: * The client MUST NOT use an SSLv2-compatible ClientHello. (RFC 6176 already says this.) * The server MUST reject an SSLv2-compatible ClientHello when its version field is higher than TLS 1.2. (Somebody else said that this is already the case because some extensions are mandatory for the client to send, and extensions aren't allowed in the SSLv2-compatible ClientHello.) * All the other text regarding SSLv2 should be removed from the TLS 1.3 spec. The only disagreement is whether the TLS 1.3 spec should say that the server MUST reject any SSLv2-compatible ClientHello, regardless of what TLS version is being offered by the client. So, why not break up your changeset into two parts in two separate issues?: One that does the three things that there is agreement on, and a new changeset for a new issue about whether all SSLv2-compatible ClientHellos must be rejected. Then at least we don't hold up the significant progress of those three changes while we resolve whether to make the last change. Cheers, Brian From nobody Tue Dec 30 00:25:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F3F1ACF24 for ; Tue, 30 Dec 2014 00:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 i3fRZplveFK7 for ; Tue, 30 Dec 2014 00:25:20 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635C01ACEEA for ; Tue, 30 Dec 2014 00:25:20 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so7794301qae.41 for ; Tue, 30 Dec 2014 00:25:19 -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=rMXPKz4boDqUWw/+lig/LTct1OF/XZrlfR/uqbUTjSs=; b=oJxY8p00ExYedt/U9uURkd52SVVEGerXX6wPMVyESdm7Zvk00UWVlxb7HVJGb2ywd2 QZXW3OZR/KIgsBj1djUf3Rqyg1iyOp9HfJt4GwbldJxC77kGQLbes9lKPFXyjw/VRELL N780RO65m++YxYATGQp/Y8RPktO9/AoxLvv+KnSZe7b9yS7VFN3auJBpXREpqnWUyLn/ 1VeD2qmHVGF4n7yn7nk2dQNJYeOizQWxpDglr5qInTFZ6G1CLTRLBhTk5NVG3/0rQn9b kC4kyP5Zp0JOInLhlrU5CZZLEV5fm0riV+1zDW6JpzatebiiWAbyrxowhRSYd1XRIZrf tjCA== X-Received: by 10.224.47.8 with SMTP id l8mr27838563qaf.20.1419927919597; Tue, 30 Dec 2014 00:25:19 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id s2sm35568084qam.45.2014.12.30.00.25.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 00:25:18 -0800 (PST) From: Dave Garrett To: Brian Smith Date: Tue, 30 Dec 2014 03:25:17 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <20141229192657.A288B1B0B6@ld9781.wdf.sap.corp> <201412291528.11915.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201412300325.17988.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J4P_WvdOS5CVwvTUEBI4zMmgfDs 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: Tue, 30 Dec 2014 08:25:22 -0000 On Tuesday, December 30, 2014 03:20:34 am Brian Smith wrote: > I think there is pretty strong agreement that: > > * The client MUST NOT use an SSLv2-compatible ClientHello. (RFC 6176 > already says this.) > > * The server MUST reject an SSLv2-compatible ClientHello when its > version field is higher than TLS 1.2. (Somebody else said that this is > already the case because some extensions are mandatory for the client > to send, and extensions aren't allowed in the SSLv2-compatible > ClientHello.) > > * All the other text regarding SSLv2 should be removed from the TLS 1.3 > spec. > > The only disagreement is whether the TLS 1.3 spec should say that the > server MUST reject any SSLv2-compatible ClientHello, regardless of > what TLS version is being offered by the client. > > So, why not break up your changeset into two parts in two separate > issues?: One that does the three things that there is agreement on, > and a new changeset for a new issue about whether all SSLv2-compatible > ClientHellos must be rejected. Then at least we don't hold up the > significant progress of those three changes while we resolve whether > to make the last change. Agreed. Will do. Dave From nobody Tue Dec 30 00:34:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA91A8A0B for ; Tue, 30 Dec 2014 00:34:52 -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=[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 QNorXDEC8jYP for ; Tue, 30 Dec 2014 00:34:48 -0800 (PST) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244DC1A8768 for ; Tue, 30 Dec 2014 00:34:48 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id u20so31736588oif.7 for ; Tue, 30 Dec 2014 00:34:47 -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=oWsskznYxHjQc8FC1lEYYhwrQbe5HWtk2oj+pBpoVGM=; b=l6teqAI697CBt6fgUyYpcOc0FK/jCtgSBnmT+2spKIBiKHO3nSKIwDxUHxETT2OAVo A959mavdhyb1hImsCa3vJdGIADl0s3YiAkz6XDYCy3s70wjBRo7zh98xOe/qWfqh+wRq LCYdI2apFUgrpdp37KREuA2ED1QDsS1+l2Vd8GV9NKwI/Ge8gpw3Cn6teE8Zglc5xGEO YMTFsDJMYoNIXFzVLx6g9Pevb0pXsFd6/d+bzv83fVJLV383K6TV5FoDY2Ii5wMi47O0 8RONKWdqWjt+6hwYmqeOzuVOIcZ0i2nxGQG/AO7HF0XN8dlKgXL+0TouW5HxMmi82Hsd Wvxg== X-Gm-Message-State: ALoCoQlUPRbNqAu+uYpz0Ts2WS9BeBgYCLVpBUGZD6ErFMC9bPWip/ApHteYKm5thbEgklSzvbwU MIME-Version: 1.0 X-Received: by 10.182.125.72 with SMTP id mo8mr35554418obb.61.1419928487592; Tue, 30 Dec 2014 00:34:47 -0800 (PST) Received: by 10.76.71.228 with HTTP; Tue, 30 Dec 2014 00:34:47 -0800 (PST) In-Reply-To: <54A252EA.1010905@iki.fi> References: <54A252EA.1010905@iki.fi> Date: Tue, 30 Dec 2014 00:34:47 -0800 Message-ID: From: Brian Smith To: Tapio Sokura Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c_0_FQ5GWX2XkiyXjhLXSnaoYCI Cc: "" Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 08:34:52 -0000 Tapio Sokura wrote: > I'm a bit vary of putting all eggs in the same basket (here ECDH). The main problems with FF-DHE as a fallback mechanism for if/when ECC-DH is borken are (1) It seems unlikely that the ECC-DH problem will be solved without solving the FF-DH problem too, (2) Even if that were to happen, FF-DH with acceptable security parameters would result in unacceptable performance. Consequently, I don't think it makes sense to consider FF-DH a reasonable fallback for ECC-DH. Cheers, Brian From nobody Tue Dec 30 02:03:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22981A006F for ; Tue, 30 Dec 2014 02:03:07 -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 cPGp6vKeLdlM for ; Tue, 30 Dec 2014 02:03:06 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384D41A0041 for ; Tue, 30 Dec 2014 02:03:06 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so10113690qcv.8 for ; Tue, 30 Dec 2014 02:03:05 -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:mime-version:content-type :content-transfer-encoding:message-id; bh=b7Wj1yC3oQsgvlfaUWsttIAOpp3Rsev9Tg9FlEaNCq8=; b=PMaZJ6Baa0aTLiLuw+vcYzT7LGYvPAxRC5bZQxE4dR3UK2LPJHaBGdJdkF8hto3pKt nuSvfKxH4cr4k6BogGNTZNDvNtOEAGW/rzdWZER3L0Nwbrh0t9sZFe8yUMZLHXUgPsie Ot1Lp3YUGXZc/CKDwbYcI+erMcHsirJRS2G1qd7YQAoaYN3ZFZDmuNNU9Mb6LWlo7dsU GMowno7wdAi0bxy6lf5yTtCb+J0TyjpLqetpv0CnNZp4OjyWYf6qGmU5fFTSgeZL+eGT LJIJ8Y7lASLERd8xxjDYXCUSUMKo152nEHUJF2BBGvp/d5EnoQ9/nAeZUPZda1oQ/4VS nAJA== X-Received: by 10.140.43.195 with SMTP id e61mr91324059qga.13.1419933785287; Tue, 30 Dec 2014 02:03:05 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id y11sm27318231qaw.42.2014.12.30.02.03.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 02:03:04 -0800 (PST) From: Dave Garrett To: "TLS@ietf.org (tls@ietf.org)" Date: Tue, 30 Dec 2014 05:03:03 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201412300503.03923.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SEdUwHGbsxNoCGkkvR61YfsOGpw Subject: [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: Tue, 30 Dec 2014 10:03:08 -0000 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 cut 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 From nobody Tue Dec 30 06:40:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C371A00C5 for ; Tue, 30 Dec 2014 06:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 gJlPS0BA9Xoc for ; Tue, 30 Dec 2014 06:40:51 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64421A00BF for ; Tue, 30 Dec 2014 06:40:50 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id hq12so5652313vcb.7 for ; Tue, 30 Dec 2014 06:40: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 :content-type; bh=gjqc4BZiGKoF+cDNLuEWkLkYalLuVSvPySqdDURO3uU=; b=ivh/YBJTldqrPF7G9xUXhDfMpaFXs5ktrX8tjb4jLY7+5JuDjjn3SRBb3Oys2CiWSX fMrXMg0o+10wtGaiT3Ll7dAsN0kI+1QVML5CcUdj4sJcOpRlm6JluX2jm0aE2+GiWQrf slDQ5Egu0o8MSOyj2ayHDdY7fNwGSkYY42FAkxsvG5HJhZuXd8rC7NHexMx5CDCZXyeQ 9gCChOeXjNGW2WgQ4qGqR4hxegz9qO/OjU+3QAfbVJALp7uPWGCDryU0AqrDY09Ko4C7 0rbjdZMy9zG34XEuswu7AevuBleizhMiL6aBYkqFXoi0sw95/tb81SSX5yO61tXmEzY3 JTiA== MIME-Version: 1.0 X-Received: by 10.220.102.20 with SMTP id e20mr31723391vco.12.1419950449957; Tue, 30 Dec 2014 06:40:49 -0800 (PST) Received: by 10.52.142.171 with HTTP; Tue, 30 Dec 2014 06:40:49 -0800 (PST) In-Reply-To: <54A252EA.1010905@iki.fi> References: <54A252EA.1010905@iki.fi> Date: Tue, 30 Dec 2014 15:40:49 +0100 Message-ID: From: Maarten Bodewes To: tls@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a94422b20d8050b6ffae6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M08EO3rh5fbqPVZphKjIzqUjlps Subject: Re: [TLS] Do we need DH? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 14:40:52 -0000 --047d7b3a94422b20d8050b6ffae6 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 30, 2014 at 8:23 AM, Tapio Sokura wrote: > > With regards to all eggs being in the same basket, AES is also something > that really should have a realistic alternative standardized and > deployed _before_ (/if) AES is broken. Like SHA-3 is coming around the > corner while SHA-2 is still well alive and kicking. > Although it doesn't invalidate the rest of your argument, the SHA-3 competition was started up when SHA-1 was under significant attack. It wasn't clear at that time if SHA-2 would be affected as well. By now no SHA-1 collisions have been found, and - more importantly - the attacks on SHA-1 don't seem to translate to SHA-2. This is probably a main reason why at the time of writing SHA-3/Keccak is still not finalized as a standard (although I expect it will be soon). The main problem with ECDH is that it can be executed without performing enough verification on the parameters or public key. But those issues are present for DH as well. So in my opinion the main thing speaking for DH is it's relative simplicity of implementation compared to ECDH (for some libraries ECDH is slower than DH for comparative levels of security for this reason alone!). Regards, Maarten --047d7b3a94422b20d8050b6ffae6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 30, 2014 at 8:23 AM, Tapio Sokura <tapio.sokura@iki.fi&g= t; wrote:

With regards to all eggs being in the same basket, AES is also something that really should have a realistic alternative standardized and
deployed _before_ (/if) AES is broken. Like SHA-3 is coming around the
corner while SHA-2 is still well alive and kicking.

Although it = doesn't invalidate the rest of your argument, the SHA-3 competition was= started up when SHA-1 was under significant attack. It wasn't clear at= that time if SHA-2 would be affected as well. By now no SHA-1 collisions h= ave been found, and - more importantly - the attacks on SHA-1 don't see= m to translate to SHA-2. This is probably a main reason why at the time of = writing SHA-3/Keccak is still not finalized as a standard (although I expec= t it will be soon).

The main problem with ECDH is that it= can be executed without performing enough verification on the parameters o= r public key. But those issues are present for DH as well. So in my opinion= the main thing speaking for DH is it's relative simplicity of implemen= tation compared to ECDH (for some libraries ECDH is slower than DH for comp= arative levels of security for this reason alone!).

Regar= ds,
Maarten
--047d7b3a94422b20d8050b6ffae6-- From nobody Tue Dec 30 08:56:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8EC1A9077 for ; Mon, 29 Dec 2014 11:08:30 -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 qBBFiMVUrTWo for ; Mon, 29 Dec 2014 11:08:28 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7879C1A904C for ; Mon, 29 Dec 2014 11:08:28 -0800 (PST) Received: by mail-qg0-f52.google.com with SMTP id a108so9527857qge.39 for ; Mon, 29 Dec 2014 11:08:27 -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=Jv+LzE2pisNaV0Q3+SE/wc8JILatbuXGAyF0XegL3+A=; b=EyMDNQcwz8DEVX34gA+DMM7UGw92fu+4JHObURBJ0dlrAbshAmiGB3g6hGt9PeblOg /CbGEGF6wYgQUBcVzpxUZjyT9zslt8oCUKbG/FLiq24exR1u7Q/DVYNjZywR6G155q2S +xnlS//v7Yo5EjY8HVo1kI+0GdSUNkg8MGNThclr7Ny/eYo8fPnS69Ul91camyec710L 4jHT2xfnoV32v3cSpv/frM1TDDae6jD0gogk2F/bsc4IdFxUe1cdMc6dIMhDPJtLkQlH /Bcn3oIQpWEWlr73zj+IVTE2HSk9dyWbAkP4+xPKK3REKWLpsWbUXOceJdgXR7YmD6UZ CSLg== X-Received: by 10.229.24.6 with SMTP id t6mr15777380qcb.17.1419880107556; Mon, 29 Dec 2014 11:08:27 -0800 (PST) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id r16sm34196671qay.10.2014.12.29.11.08.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 29 Dec 2014 11:08:27 -0800 (PST) From: Dave Garrett To: mrex@sap.com Date: Mon, 29 Dec 2014 14:08:23 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; ) References: <20141229115843.258CD1B0B4@ld9781.wdf.sap.corp> In-Reply-To: <20141229115843.258CD1B0B4@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412291408.24237.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r3zB5mBYe4GStG8qQtFgAsQRQOM X-Mailman-Approved-At: Tue, 30 Dec 2014 08:55:59 -0800 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: Mon, 29 Dec 2014 19:08:30 -0000 On Monday, December 29, 2014 06:58:43 am Martin Rex wrote: > JDK 1.6 might be past its "End of Public Updates", but it is still > fully supported and pretty omnipresent, in particular in company > environments and the majority of server-side (J2EE) installations. Server-side usage would not be affected by the proposed changes. TLS 1.3 clients would be sending v3 hellos which would be read just fine. Server and client usage in company environments are where it is easiest to deal with the proposed changes. The clients' settings just need to be changed to stop using SSL entirely and send only v3 hellos. I'll restate again, this is already the consensus. (again, assuming no surprises with the SSL3 I-D) http://tools.ietf.org/html/rfc6176 http://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00 To directly quote RFC 6176 (2011): "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT- HELLO message format" With both SSL2 & SSL3 prohibited, there should be no v2 hellos. Put bluntly, any environment that actually HAS v2 hellos is already ignoring IETF RFCs. They will potentially ignore the proposed change for this RFC. They cannot be the basis for decisions on what gets into new RFCs. Dave From nobody Tue Dec 30 10:36:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5711A1A20 for ; Tue, 30 Dec 2014 10:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.701 X-Spam-Level: X-Spam-Status: No, score=-99.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, 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 Ukqng7cTHlUv for ; Tue, 30 Dec 2014 10:36: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 C2B4B1A1A0C for ; Tue, 30 Dec 2014 10:36:15 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 292B89A4006; Tue, 30 Dec 2014 13:36:05 -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 CouQcTuJAgsm; Tue, 30 Dec 2014 13:35:42 -0500 (EST) Received: from [192.168.2.100] (pool-71-163-125-120.washdc.fios.verizon.net [71.163.125.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 86E259A4005; Tue, 30 Dec 2014 13:35:42 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <20141225212141.61122705@pc> Date: Tue, 30 Dec 2014 13:35:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4DDA505A-DC75-480E-88A3-216CDE9AE033@vigilsec.com> References: <5498DBCE.1070909@delignat-lavaud.fr> <20141223102635.3bda9ed2@pc> <54995163.7070004@delignat-lavaud.fr> <20141225212141.61122705@pc> To: =?iso-8859-1?Q?Hanno_B=F6ck?= X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q7OxrSDJLBLPxsi5Qgz7oXSAbJY Cc: IETF TLS Subject: Re: [TLS] Remove signature algorithms from cipher suites 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, 30 Dec 2014 18:36:16 -0000 Hanno: > But my point remains: Why not just say "TLS 1.3 has to use RSA with > PSS, mo more PKCS #1 1.5"? I am not aware of any "real" risk of new attacks on RSA signatures = enabled by using the same key pair for both PKCS #1 v1.5 and PSS. The = good structure in PSS would probably meant that the security wouldn't = get any worse by allowing PSS signatures than with PKCS #1 v1.5 alone. That said, I believe that the PSS security proof makes the assumption = that the key is only used with PSS. The proof would probably need some = modification to allow for the possibility that some signatures would be = computed with PKCS #1 v1.5 and others with PSS. Does anyone know of = work on this topic? Russ From nobody Tue Dec 30 12:19:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796161A1BCE for ; Tue, 30 Dec 2014 12:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 bNGr1lyexYRo for ; Tue, 30 Dec 2014 12:19:49 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B811A1B70 for ; Tue, 30 Dec 2014 12:19:49 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so21060989wgh.22 for ; Tue, 30 Dec 2014 12:19: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=A/rzagpsUokExxDhV9pvj6nY76ZZouOhiAfEwqSWYI8=; b=YJYLfLXSqf0oXLV72rPyicAW/DMQtse+621sSHwNNYrMbra89iPlFG7zHerDyQI1Oa Gii6EoxEB1EaIpw+RzfYdutfokWC9x6J04m3iHh+fiobsdaa9hFtADh7xPCSZX/vJO2Z rA15YhPa9SBWmaMt5j15WWdXyqKP/wTVW+P5IF5C/onHNR3ac1pXqyRbbrrD9UoYg7oL jIjdAV5CR9vvbof2QuJVve6+GY3uHoGiVyh8utum6yGKaRSxQzXCVZydHe+TPvf+Zud3 xrwYvV55SLkxlCA5+iGFdf2LtiqiWlAzgVz4AqwusMHUDasYGhx/liD3hdsvt7CuFpcY K05g== X-Gm-Message-State: ALoCoQnY4H/cUsC/qWfUNOeOw1hyjG+zN/cWdNIwzwNw3ugyDENQj7rdqwaPpBBE79EySqVp39Aa X-Received: by 10.180.84.98 with SMTP id x2mr106727272wiy.14.1419970788156; Tue, 30 Dec 2014 12:19:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 30 Dec 2014 12:19:07 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 30 Dec 2014 12:19:07 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d044401b26b8381050b74b6be Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9luoH4mYawXXmYnnRnsm83NiEpo Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on PR #95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 20:19:54 -0000 --f46d044401b26b8381050b74b6be Content-Type: text/plain; charset=UTF-8 Thanks again for the detailed comments. On Wed, Dec 24, 2014 at 1:20 PM, Watson Ladd wrote: > Dear all, > I've read PR #95 with a critical eye, and in addition to some > infelicities of the text, see some more substantial issues. This email > is my notes in the order they occurred to me: not necessarily > correlated with severity. I've tried to triage them, but may have done > so inaccurately. Most of these are editorial in nature. > > Line 291: we're citing DSA. old text. I agree that it would be better to cite ECDSA here. I'll fix. > More broadly, applications don't > care how we provide what we provide: they care about the end goals. At > some point this should be revised accordingly. > I'm not sure I agree with this. This text isn't targeted only at application developers, and it is is important to know roughly what kind of thing is being specified here. Line 418: Security means what exactly? > Yes, it would be useful to provide some more context here, though note that this is an introductory paragraph so it's necessarily going to be a bit handwavy. Probably the right thing to do here is have slightly more detail and then point to a security considerations section. https://github.com/tlswg/tls13-spec/issues/114 Line 437-453: this needs to be rewritten. Why are we talking about SSL > v3, when any similarity is like that of a whale to a platypus? > https://github.com/tlswg/tls13-spec/issues/115 > Line 743: I'm confused by the comment on how one finds the length of > the signature data: it seems to be sent on the wire, but the document > says " The length of the signature is known because the algorithm and > key used for the signing are known prior to encoding or decoding this > structure.", which is a different method.I recommend removing that last > sentence: the parser should parse with as little input as possible from above. > Agreed. > Line 836: 800 lines in, and we've gotten about nowhere: defined a PRF, > and a representation format. Now we hear that TLS doesn't provide some > security properties, but we don't know what those are. A succinct, > correct description should appear at the beginning and again in the > security considerations section. > Seems like https://github.com/tlswg/tls13-spec/issues/114 again. Line 1015: Zero-length fragments of application data as traffic > analysis countermeasure? I think this was written when padding between > the fragment and record layers existed, and I'll have to check how > this was supposed to work. As it stands, I've not yet gotten to a > description of the record layer at the time I read this. > Yes, this doesn't work if you don't have padding. However, I know this is something that there is interest in having, so I suggest we leave in for now. See: https://github.com/tlswg/tls13-spec/issues/69 > Lines 1066-1072: We've got a perfectly good nonce in the sequence > number. Why not use that? Oh right, hysterical raisins. > There are two things going on here: 1. Some AEAD ciphers have nonces that are longer than the TLS sequence number, so you need to somehow specify that construction. 2. There was a desire to have the nonce be output by the AEAD cipher rather than input to it, so that the AEAD cipher itself could guarantee non-reuse. Note that there are other constructions that could work here (e.g., having a specified pattern and requiring the cipher to enforce that). > Line 1119: Open issue #5. I've got to think about this one. Likely as > not this will be a very complicated change, that makes TLS 1.3 a lot > harder to implement. > Can you elaborate more on why you think that? Line 1190: More forward references to resumption. Note that > authentication status isn't defined as part of what gets resumed. I > believe, but am not sure, that this was part of what made the SSL v3 > multihoming fallback attack work. > If you want to provide some text, that would be welcome. > Line 1439: Finally, the handshake protocol. In this description there > are a ton of forward references, that make understanding this a bit > tricky. What's an Encrypted Extensions method, on line 1505? While the > earlier description of the Alert protocol was by type of message, this > overview is chronological. > Yeah, it's always hard to figure out how to make this work editorially. If you have some concrete suggestions, that would certainly be welcome. I suppose we could push this section to later. > Line 1623: We're getting to the beef. But the reader already knows > this: no need to reintroduce the handshake protocol. > I'm not sure how much you'd like to shorten here. Can you propose a concrete change. Line 1763: It's not clear what servers have to do, or not do, to deal > with stolen session IDs. They need to not "breach security", whatever > that means. > Yeah, I see what you mean. I can clean this up when we do the sessionid/ticket merge. > Line 1863: Previously, hello extensions were relegated to a different > document. Now they are needed for backwards compatibility. > Hello extensions are actually in 5246. https://tools.ietf.org/html/rfc5246#section-7.4.1.4 Line 1912: Was anyone using SRP? The more generic we have to make TLS > 1.3, and the more we have to shoehorn in, the more complex it gets. > This open issue could get hairy. > Agreed. I think we should remove SRP support. > Line 2199: Mandating the presence of the signature_algorithms > extension would simplify things considerably. > Yes. Let's do that. https://github.com/tlswg/tls13-spec/issues/116 Line 2995: A TODO DTLS, probably related to the possibility of the > Update message being lost. I don't remember how DTLS deals with this > in the handshake, but there data is not being sent with the new keys > before the other side acknowledges receipt. Will think about it. > The general way you deal with this in the handshake is that the last flight is used as an acknowledgement of the previous flight. The sender of the previous flight has to retransmit until they receive the last flight and the sender of the last flight has to keep their state around long enough to be able to handle the retransmit or up to 2MSL. This general pattern should work here, but we need to work out the details for DTLS, hence the TODO. Does ignoring an update still update the record layer? > Yes, it should. You're just saying "I updated my state but I have no idea what you wanted". > There does not seem to be a way to request a certificate in the update > protocol. > This is deliberate. > Line 3151: AES-GCM or AES-CCM seem the logical options here. > Well, we need to specify the public key algorithms as well. But GCM does seem like probably the choice. Line 3165: This doesn't seem to be a very fleshed out security > considerations section. > I'd certainly welcome contributions here. Line 3606: Do we need the glossary? > Unsure. Comments welcome: https://github.com/tlswg/tls13-spec/issues/117 > The implementation notes needs a substantial amount of work. The > advice on random number generation is vintage 90's. The discussion of > certificate checks could be substantially expanded. A lot of attacks > that have been used in the wild are not discussed here. > I'd welcome contributions here as well. > Line 4015: SSL v2? Really? > There's been a bunch of mailing list discussion on this recently. See also: https://github.com/tlswg/tls13-spec/pull/105 https://github.com/tlswg/tls13-spec/pull/107 Line 4034: This is not a security analysis. > http://eprint.iacr.org/2014/182.pdf is a security analysis. It would > be much more helpful if this was significantly edited: there is some > valuable information in here, but much of it is misleading. > > Line 4185: This reads a bit strangely with things like DANE. Yes, I > don't think DNSSEC has adequate security, and it's worth noting that > CAs can be a problem. I think it's worth telling implementors to study > the lessons of attacks in the past. > I'd welcome contributions here. -Ekr > > --f46d044401b26b8381050b74b6be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks again for the detailed comments.



On Wed, Dec = 24, 2014 at 1:20 PM, Watson Ladd <watsonbladd@gmail.com>= wrote:
Dear all,
I've read PR #95 with a critical eye, and in addition to some
infelicities of the text, see some more substantial issues. This email
is my notes in the order they occurred to me: not necessarily
correlated with severity. I've tried to triage them, but may have done<= br> so inaccurately. Most of these are editorial in nature.

Line 291: we're citing DSA. old text.

= I agree that it would be better to cite ECDSA here. I'll fix.

=C2=A0
More broadly, applications don= 't
care how we provide what we provide: they care about the end goals. At
some point this should be revised accordingly.

I'm not sure I agree with this. This text isn't targeted on= ly at application
developers, and it is is important to know roug= hly what kind of thing
is being specified here.
=C2=A0<= br>

Line 418: Security means what exactly?

= Yes, it would be useful to provide some more context here, though note
that this is an introductory paragraph so it's necessarily going = to be a
bit handwavy. Probably the right thing to do here is have= slightly
more detail and then point to a security considerations= section.


Line 437-453: this needs to be rewritten. Why are we talking about SSL
v3, when any similarity is like that of a whale to a platypus?


=C2=A0
Line 743: I'm confused by the comment on how one finds the length of the signature data: it seems to be sent on the wire, but the document
says " The length of the signature is known because the algorithm and<= br> key used for the signing are known prior to encoding or decoding this
structure.", which is a different method.I recommend removing that las= t sentence: the parser should parse with
as little input as possible from above.

Agreed.

=C2=A0
Line 836: 800 lines in, and we've gotten about nowhere: defined a PRF,<= br> and a representation format. Now we hear that TLS doesn't provide some<= br> security properties, but we don't know what those are. A succinct,
correct description should appear at the beginning and again in the
security considerations section.



Line 1015: Zero-length fragments of application data as traffic
analysis countermeasure? I think this was written when padding between
the fragment and record layers existed, and I'll have to check how
this was supposed to work. As it stands, I've not yet gotten to a
description of the record layer at the time I read this.

Yes, this doesn't work if you don't have padding.= However, I know this
is something that there is interest in havi= ng, so I suggest we leave in for

=C2=A0
Lines 1066-1072: We've got a perfectly good nonce in the sequence
number. Why not use that? Oh right, hysterical raisins.

There are two things going on here:

1. Some AEAD ciphers have nonces that are longer than the TLS sequence
number, so you need to somehow specify that construction.

2. There was a desire to have the nonce be output by the A= EAD cipher
rather than input to it, so that the AEAD cipher itsel= f could guarantee
non-reuse. Note that there are other constructi= ons that could work
here (e.g., having a specified pattern and re= quiring the cipher to enforce
that).
=C2=A0
Line 1119: Open issue #5. I've got to think about this one. Likely as not this will be a very complicated change, that makes TLS 1.3 a lot
harder to implement.

Can you elaborate = more on why you think that?


Line 1190: More forward references to resumption. Note that
authentication status isn't defined as part of what gets resumed. I
believe, but am not sure, that this was part of what made the SSL v3
multihoming fallback attack work.

If yo= u want to provide some text, that would be welcome.

=C2=A0
Line 1439: Finally, the handshake protocol. In this description there
are a ton of forward references, that make understanding this a bit
tricky. What's an Encrypted Extensions method, on line 1505? While the<= br> earlier description of the Alert protocol was by type of message, this
overview is chronological.

Yeah, it'= ;s always hard to figure out how to make this work editorially.
I= f you have some concrete suggestions, that would certainly be welcome.
<= /div>
I suppose we could push this section to later.
=C2=A0
Line 1623: We're getting to the beef. But the reader already knows
this: no need to reintroduce the handshake protocol.
<= br>
I'm not sure how much you'd like to shorten here. Can= you propose
a concrete change.


Line 1763: It's not clear what servers have to do, or not do, to deal with stolen session IDs. They need to not "breach security", what= ever
that means.

Yeah, I see what you mean. = I can clean this up when we do the sessionid/ticket
merge.
<= div>
=C2=A0
Line 1863: Previously, hell= o extensions were relegated to a different
document. Now they are needed for backwards compatibility.
=

Hello extensions are actually in 5246.


Line 1912: Was anyone using SRP? The more generic we ha= ve to make TLS
1.3, and the more we have to shoehorn in, the more complex it gets.
This open issue could get hairy.

Agreed= . I think we should remove SRP support.

=C2=A0
Line 2199: Mandating the presence of the signature_algorithms
extension would simplify things considerably.

Yes. Let's do that.

=C2=A0


Line 2995: A TODO DTLS, probably related to the possibility of the
Update message being lost. I don't remember how DTLS deals with this in the handshake, but there data is not being sent with the new keys
before the other side acknowledges receipt. Will think about it.

The general way you deal with this in the handsha= ke is that the last
flight is used as an acknowledgement of t= he previous flight. The sender
of the previous flight has to retr= ansmit until they receive the last flight
and the sender of the l= ast flight has to keep their state around long
enough to be able = to handle the retransmit or up to 2MSL.

This gener= al pattern should work here, but we need to work out the
details = for DTLS, hence the TODO.


Does ignoring an update still update the record layer?

Yes, it should. You're just saying "I updated my s= tate but I have no idea what
you wanted".

=C2=A0
There does not seem to be a way to request a certificate in the update prot= ocol.

This is deliberate.=C2=A0

=C2=A0
Line 3151: AES-GCM or AES-CCM seem the logical options here.

Well, we need to specify the public key algorithms as= well. But GCM does
seem like probably the choice.

=

Line 3165: This doesn't seem to be a very fleshed out security
considerations section.

I'd certain= ly welcome contributions here.


Line 3606: Do we need the glossary?

Uns= ure. Comments welcome:

=C2=A0
The implementation notes needs a substantial amount of work. The
advice on random number generation is vintage 90's.=C2=A0 The discussio= n of
certificate checks could be substantially expanded. A lot of attacks
that have been used in the wild are not discussed here.

I'd welcome contributions here as well.

=
=C2=A0
Line 4015: SSL v2? Really?

There's = been a bunch of mailing list discussion on this recently.
See als= o:


Line 4034: This is not a security analysis.
http://ep= rint.iacr.org/2014/182.pdf is a security analysis. It would
be much more helpful if this was significantly edited: there is some
valuable information in here, but much of it is misleading.

Line 4185: This reads a bit strangely with things like DANE. Yes, I
don't think DNSSEC has adequate security, and it's worth noting tha= t
CAs can be a problem. I think it's worth telling implementors to study<= br> the lessons of attacks in the past.

I&#= 39;d welcome contributions here.

-Ekr

--f46d044401b26b8381050b74b6be-- From nobody Wed Dec 31 08:54:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26541AC3CD for ; Wed, 31 Dec 2014 08:54:05 -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_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNjtCSEYji6G for ; Wed, 31 Dec 2014 08:54:04 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C855D1AC3CC for ; Wed, 31 Dec 2014 08:54:03 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id c41so8026333yho.17 for ; Wed, 31 Dec 2014 08:54:03 -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=wmWAbPsz5KWHzVpGOSLLIrtnozAZ9D8Fepjvq1WqSJE=; b=QlMiIdek3qJVYJZlXPKCAwrrSvfK/ZwUq9m6IGIjgVUtPXGajE6fsvJVGN4SdJgpT7 efL2r1CIe9n7aSOnPbs/Sw8spBOE61OD/dBvXXpKS7Hb/Nj+B3CAOnCpDq0DFk+8N77j gx4nGf4qR67pL22ePMnJkOOLwp2zmisTcv9X9mzg0gTKtJbPflqcjUI/QgyOVSV2Q7/N o3irdFqxyz7YVpCsJ0LWpa0lI5vn8r4x8Qp+6YnJ3jN8OELt5FYj4w0ImtYkAbH3MvZf h4zjF32ahunWKqjDkDVQa2mIOyhM4n+maZkgPAZ3GN25tE+GftG4S91nnbrppCmmrFEF 2gcA== MIME-Version: 1.0 X-Received: by 10.236.61.8 with SMTP id v8mr43579128yhc.44.1420044842990; Wed, 31 Dec 2014 08:54:02 -0800 (PST) Received: by 10.170.207.6 with HTTP; Wed, 31 Dec 2014 08:54:02 -0800 (PST) In-Reply-To: References: Date: Wed, 31 Dec 2014 11:54:02 -0500 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IjGivyTiNexQE4FVv4w8Ly2qOLY Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on PR #95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 16:54:06 -0000 On Tue, Dec 30, 2014 at 3:19 PM, Eric Rescorla wrote: > Thanks again for the detailed comments. > > > >> >> Line 1119: Open issue #5. I've got to think about this one. Likely as >> not this will be a very complicated change, that makes TLS 1.3 a lot >> harder to implement. > > > Can you elaborate more on why you think that? Right now the key calculation is the same as TLS 1.2. Changing this to separate the generated nonce would be annoying. Probably the easiest solution is to not generate the nonce from the master secret, and so have all PRF outputs be used only as keys. But this has knock-on effects. > > >> Line 1190: More forward references to resumption. Note that >> authentication status isn't defined as part of what gets resumed. I >> believe, but am not sure, that this was part of what made the SSL v3 >> multihoming fallback attack work. > > > If you want to provide some text, that would be welcome. How about "In certain cases, servers may have multiple identities. In this case resumption does not guarantee that the client and server share the same view of which identity is involved. For examples of security vulnerabilities introduced by neglecting this detail, see Virtual Host Confusion https://bh.ht.vc/vhost_confusion.pdf" > > >> >> Line 1439: Finally, the handshake protocol. In this description there >> are a ton of forward references, that make understanding this a bit >> tricky. What's an Encrypted Extensions method, on line 1505? While the >> earlier description of the Alert protocol was by type of message, this >> overview is chronological. > > > Yeah, it's always hard to figure out how to make this work editorially. > If you have some concrete suggestions, that would certainly be welcome. > I suppose we could push this section to later. > >> >> Line 1623: We're getting to the beef. But the reader already knows >> this: no need to reintroduce the handshake protocol. > > > I'm not sure how much you'd like to shorten here. Can you propose > a concrete change. Removing lines 1634-1674? They just seem repetitive to me. > > >> Line 1763: It's not clear what servers have to do, or not do, to deal >> with stolen session IDs. They need to not "breach security", whatever >> that means. > > > Yeah, I see what you mean. I can clean this up when we do the > sessionid/ticket > merge. > > >> >> Line 1863: Previously, hello extensions were relegated to a different >> document. Now they are needed for backwards compatibility. > > > Hello extensions are actually in 5246. > https://tools.ietf.org/html/rfc5246#section-7.4.1.4 You are right, and I was wrong. > > >> Line 1912: Was anyone using SRP? The more generic we have to make TLS >> 1.3, and the more we have to shoehorn in, the more complex it gets. >> This open issue could get hairy. > > > Agreed. I think we should remove SRP support. > > >> >> Line 2199: Mandating the presence of the signature_algorithms >> extension would simplify things considerably. > > > Yes. Let's do that. > https://github.com/tlswg/tls13-spec/issues/116 > > > > >> Line 2995: A TODO DTLS, probably related to the possibility of the >> Update message being lost. I don't remember how DTLS deals with this >> in the handshake, but there data is not being sent with the new keys >> before the other side acknowledges receipt. Will think about it. > > > The general way you deal with this in the handshake is that the last > flight is used as an acknowledgement of the previous flight. The sender > of the previous flight has to retransmit until they receive the last flight > and the sender of the last flight has to keep their state around long > enough to be able to handle the retransmit or up to 2MSL. > > This general pattern should work here, but we need to work out the > details for DTLS, hence the TODO. I don't think this is right. After A sends an update, they change the encryption keys for data from A to B. Now if the update arrives late, we get a bad MAC when the data A sent arrives at B. One solution is to carefully trim down the size of updates, and send an update along with the data, until confirmation comes that we can stop. This is a much messier mechanism, but may be necessary if we want DTLS to be able to use update. > > >> Does ignoring an update still update the record layer? > > > Yes, it should. You're just saying "I updated my state but I have no idea > what > you wanted". That wasn't clear from the text to me. I'll think about clarifications. > > >> >> There does not seem to be a way to request a certificate in the update >> protocol. > > > This is deliberate. So how do servers tell clients what sorts of certificates they want? Are we kicking this to higher layers? This prevents drop in replacement as I seem to remember HTTP+client cert doesn't work like that. > > >> >> Line 3151: AES-GCM or AES-CCM seem the logical options here. > > > Well, we need to specify the public key algorithms as well. But GCM does > seem like probably the choice. > > >> Line 3165: This doesn't seem to be a very fleshed out security >> considerations section. > > > I'd certainly welcome contributions here. > > >> Line 3606: Do we need the glossary? > > > Unsure. Comments welcome: > https://github.com/tlswg/tls13-spec/issues/117 > > >> >> The implementation notes needs a substantial amount of work. The >> advice on random number generation is vintage 90's. The discussion of >> certificate checks could be substantially expanded. A lot of attacks >> that have been used in the wild are not discussed here. > For all of these I'll try making a Pull Request, separated by where in the doc they appear. Sincerely, Watson Ladd > > -Ekr >> >> > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Dec 31 09:09:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872AD1AC3F6 for ; Wed, 31 Dec 2014 09:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DRDcT90TfgI for ; Wed, 31 Dec 2014 09:09:33 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BAC1AC3F5 for ; Wed, 31 Dec 2014 09:09:26 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so25781035wid.15 for ; Wed, 31 Dec 2014 09:09:24 -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=PU5kWYQSHxo9F05Xp0q1FK9iXpSEHIv5/eKRohJ79vA=; b=ML1eDvCYzux7hlH6cOQs9Qxn/3mGNMlBjT9k3UwTIKB9ScjLY4Z/KZblDLyZ93r2SH 7YBH9DKrwnVGDcT7Z37bS7fluqjkZNipOVmmuhlVecPe3Il84w8/rE57SZIUaQlu9AuE +xLbcGZewu0vLLA4ApC5alj2K8LChQloYvzZuIfTgXlRguTmQKpK9SeHHEz7vkS7UPaM fQJhsD2KUGNuBIjrmERrn3K1ABiWgtVv0BBo1WfSYDap0M4HrdP7be0hhQPdtyyqhD5A fJmoTcR35kMx17wXjaoSSO3nW6lhLms2CeqSjzoh6RLnNFjGrg/lDT3S4tIP3GdDigUX wa6A== X-Gm-Message-State: ALoCoQmUHHrf7OT9XpaNBBtvqr2mz86XW7Wwz+LNVfC+VhuiASRnR1AgxsEaYRY/2/La4nWYK/rv X-Received: by 10.194.60.243 with SMTP id k19mr29030446wjr.88.1420045764800; Wed, 31 Dec 2014 09:09:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 31 Dec 2014 09:08:44 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 31 Dec 2014 09:08:44 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7b8736cc604bb1050b862bb4 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OqWrXqUeZ9V5u_AE-D35gpoW1rM Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on PR #95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 17:09:34 -0000 --047d7b8736cc604bb1050b862bb4 Content-Type: text/plain; charset=UTF-8 [Trimming aggressively] On Wed, Dec 31, 2014 at 8:54 AM, Watson Ladd wrote: > On Tue, Dec 30, 2014 at 3:19 PM, Eric Rescorla wrote: > > Thanks again for the detailed comments. > > > > > > > > >> > >> Line 1119: Open issue #5. I've got to think about this one. Likely as > >> not this will be a very complicated change, that makes TLS 1.3 a lot > >> harder to implement. > > > > > > Can you elaborate more on why you think that? > > Right now the key calculation is the same as TLS 1.2. Changing this to > separate the generated nonce would be annoying. Probably the easiest > solution is to not generate the nonce from the master secret, and so > have all PRF outputs be used only as keys. But this has knock-on > effects. I don't think this is going to be too bad, but I guess we'll find out when we go to do it :) > >> Line 2995: A TODO DTLS, probably related to the possibility of the > >> Update message being lost. I don't remember how DTLS deals with this > >> in the handshake, but there data is not being sent with the new keys > >> before the other side acknowledges receipt. Will think about it. > > > > > > The general way you deal with this in the handshake is that the last > > flight is used as an acknowledgement of the previous flight. The sender > > of the previous flight has to retransmit until they receive the last > flight > > and the sender of the last flight has to keep their state around long > > enough to be able to handle the retransmit or up to 2MSL. > > > > This general pattern should work here, but we need to work out the > > details for DTLS, hence the TODO. > > I don't think this is right. After A sends an update, they change the > encryption keys for data from A to B. Now if the update arrives late, > we get a bad MAC when the data A sent arrives at B. > You'll have to update the DTLS epoch value so that you can distinguish which set of keys it uses. In DTLS 1.2, the epoch was used for rehandshake, but we don't need that here, so it's a natural fit. > >> There does not seem to be a way to request a certificate in the update > >> protocol. > > > > > > This is deliberate. > > So how do servers tell clients what sorts of certificates they want? > Are we kicking this to higher layers? This prevents drop in > replacement as I seem to remember HTTP+client cert doesn't work like > that. The situation here is a bit messy. In TLS 1.3 presently, the server sends a CertificateRequest which contains the same information as it did in TLS 1.2. So we have a number of options here: 1. Leave client auth as-is. 2. Have client auth in update but allowed only once with CertificateRequest used to indicate which certificate you expect. 3. Do client auth in update but with only application level signaling. 4. Some combination of these. I don't think there's consensus on the best approach because it's partly about interaction with upper layer semantics. Best, -Ekr --047d7b8736cc604bb1050b862bb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Trimming aggressively]

On Wed, Dec 31, 2014 at 8:54 AM, Watson Ladd <w= atsonbladd@gmail.com> wrote:
On Tue, Dec 30, 2014 at 3:19 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Thanks again for the detailed comments.
>
>
>
<snip>
>>
>> Line 1119: Open issue #5. I've got to think about this one. Li= kely as
>> not this will be a very complicated change, that makes TLS 1.3 a l= ot
>> harder to implement.
>
>
> Can you elaborate more on why you think that?

Right now the key calculation is the same as TLS 1.2. Changing this = to
separate the generated nonce would be annoying. Probably the easiest
solution is to not generate the nonce from the master secret, and so
have all PRF outputs be used only as keys. But this has knock-on
effects.

I don't think this is going to= be too bad, but I guess we'll find out when
we go to do it := )

=C2=A0
>> Line 2995: A TODO DTLS, probably related to the possibility of the=
>> Update message being lost. I don't remember how DTLS deals wit= h this
>> in the handshake, but there data is not being sent with the new ke= ys
>> before the other side acknowledges receipt. Will think about it. >
>
> The general way you deal with this in the handshake is that the last > flight is used as an acknowledgement of the previous flight. The sende= r
> of the previous flight has to retransmit until they receive the last f= light
> and the sender of the last flight has to keep their state around long<= br> > enough to be able to handle the retransmit or up to 2MSL.
>
> This general pattern should work here, but we need to work out the
> details for DTLS, hence the TODO.

I don't think this is right. After A sends an update, they chang= e the
encryption keys for data from A to B. Now if the update arrives late,
we get a bad MAC when the data A sent arrives at B.
You'll have to update the DTLS epoch value so that you can= distinguish
which set of keys it uses. In DTLS 1.2, the epoch wa= s used for
rehandshake, but we don't need that here, so it= 9;s a natural fit.


>> There does not seem to be a way to request a certificate in the up= date
>> protocol.
>
>
> This is deliberate.

So how do servers tell clients what sorts of certificates they want?=
Are we kicking this to higher layers? This prevents drop in
replacement as I seem to remember HTTP+client cert doesn't work like that.

The situation here is a bit messy.

In TLS 1.3 presently, the server sends a Certificate= Request which contains
the same information as it did in TLS 1.2.= So we have a number of options here:

1. Leave cli= ent auth as-is.
2. Have client auth in update but allowed only on= ce with CertificateRequest used
to indicate which certificate you= expect.
3. Do client auth in update but with only application le= vel signaling.
4. Some combination of these.

=
I don't think there's consensus on the best approach because i= t's partly
about interaction with upper layer semantics.

Best,
-Ekr

<= /div> --047d7b8736cc604bb1050b862bb4--