From jsalowey@cisco.com Mon May 2 08:13:51 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF50E06AD for ; Mon, 2 May 2011 08:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fPKoll3h0rQ for ; Mon, 2 May 2011 08:13:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 10868E0675 for ; Mon, 2 May 2011 08:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=865; q=dns/txt; s=iport; t=1304349231; x=1305558831; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UkpGnR6ZTIwluIoxD3IrHqkhdRy4vxgq8giCFrTKk4Y=; b=klkapbc74sFAs9cZCNFtAbjedlelbqunQHbZKK7yT/7kcGIKuffJprfu swSeFvYEpDj4tTc1vCTyp3TALdEPjd8n2WTLvT8IK8QRf15JB7Mu9L4Ic YOQhZ6bMovBXb1psPaH5KOJUQjv/te7g3RwTNm9G1jBTT7CIe3qiH3kai 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANfJvk2rRDoI/2dsb2JhbACmHXeIcZwGm3WGAASGDohrhBmKKQ X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="scan'208";a="348666754" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 02 May 2011 15:13:50 +0000 Received: from [10.33.251.67] ([10.33.251.67]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p42FDoSM022454; Mon, 2 May 2011 15:13:50 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <1103696595.157623.1303955970290.JavaMail.root@cm-mail03.mozilla.org> Date: Mon, 2 May 2011 08:13:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D65AC2C-9757-4E63-906E-1AC27A61A567@cisco.com> References: <1103696595.157623.1303955970290.JavaMail.root@cm-mail03.mozilla.org> To: Brian Smith X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 15:13:51 -0000 On Apr 27, 2011, at 6:59 PM, Brian Smith wrote: > Joe Salowey wrote: >> Below is updated charter text reflecting feedback on the list. Please >> indicate if you support this text or if you have issues with the = text. >=20 > Are extensions that add/remove/reorder handshake records acceptable = for TLS 1.2? If so, then I think the the proposed charter looks fine. >=20 [Joe] In most cases I would expect that add/remove/reorder handshake = records would be a significant change and would require a charter = update. If the change had minimal impact it is possible that it could = be made without updating the charter, but I would think that to be the = exception rather than the rule. =20 > Thanks, > Brian > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Mon May 2 15:27:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988DFE07FD for ; Mon, 2 May 2011 15:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.105 X-Spam-Level: X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMG6RWpSzrKi for ; Mon, 2 May 2011 15:27:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id AD6BEE06FF for ; Mon, 2 May 2011 15:27:48 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p42MRiLq027239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2011 00:27:44 +0200 (MEST) From: Martin Rex Message-Id: <201105022227.p42MRhdD015568@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joe Salowey) Date: Tue, 3 May 2011 00:27:43 +0200 (MEST) In-Reply-To: <9D65AC2C-9757-4E63-906E-1AC27A61A567@cisco.com> from "Joe Salowey" at May 2, 11 08:13:52 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2011 22:27:50 -0000 Joe Salowey wrote: > > Brian Smith wrote: > > > > Joe Salowey wrote: > > > Below is updated charter text reflecting feedback on the list. Please > > > indicate if you support this text or if you have issues with the text. > > > > Are extensions that add/remove/reorder handshake records acceptable > > for TLS 1.2? If so, then I think the the proposed charter looks fine. > > [Joe] In most cases I would expect that add/remove/reorder handshake > records would be a significant change and would require a charter update. > If the change had minimal impact it is possible that it could be made > without updating the charter, but I would think that to be the exception > rather than the rule. Over the last couple of years (it looks like mid-of-2006) the TLS WG never updated its charter for adopting new work, it seems, and there were a number of documents since then. http://datatracker.ietf.org/wg/tls/ While I do think TLS WG should improve on updating its charter, I'm slightly irritated by suggestions to become extreme in the other direction and anal about new work items all of a sudden (-- unless there are too many proposals and it becomes necessary to limit the WGs focus to work only on a few of them at a time.) -Martin From pgut001@login01.cs.auckland.ac.nz Wed May 4 01:56:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C7E0688 for ; Wed, 4 May 2011 01:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VieOXX0j7YZy for ; Wed, 4 May 2011 01:56:12 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9E0E068B for ; Wed, 4 May 2011 01:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1304499372; x=1336035372; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20juhovh@iki.fi,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20tls@ietf.org|In-Reply-To:=20<4DBACA 38.2020100@iki.fi>|Message-Id:=20|Date:=20Wed,=2004=20May=202011=202 0:56:01=20+1200; bh=o6tkdvMcSvLJxjUrJVb3Rn/d7/7L9Lox8O2wO9JJggE=; b=VEUEg4ZYFoHWfqXUBXYEUTkNn8UTg5TedYqxb7PoBAaoptVXOV7rVgMY 0nfqjz2BLJGthD5ZZIo+6sdhNeiOKUbESJI6Yv5dD8EDWz3F0WCIaTlld o1URwbf2ugPgEFfRNCA9KPv3k2oeE+f1HVK83EviF9r+y3HnDcjk3FQm1 E=; X-IronPort-AV: E=Sophos;i="4.64,313,1301832000"; d="scan'208";a="59940688" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 May 2011 20:56:02 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QHXsH-0004YR-J7; Wed, 04 May 2011 20:56:01 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QHXsH-0002L9-SA; Wed, 04 May 2011 20:56:01 +1200 From: Peter Gutmann To: juhovh@iki.fi, pgut001@cs.auckland.ac.nz In-Reply-To: <4DBACA38.2020100@iki.fi> Message-Id: Date: Wed, 04 May 2011 20:56:01 +1200 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 08:56:13 -0000 =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= writes: >Actually, I tried to look through RFC 4492 (ECC), RFC 5246 (TLS 1.2) and RFC >5289, but I didn't find a requirement of using SHA-384 for signatures for >that cipher suite. So in this case the server could choose SHA-256 (in case >it can be found from signature_algorithms extension) and use that for >signature hashing, but use SHA-384 for the PRF and therefore perform no hash >truncation. While I haven't actually tried this, I strongly suspect (given the fact that servers generally fail the handshake if you try odd things) that this is another one of those tricks that you don't want to try applying :-). >I think this what makes this worse is that existing TLS 1.0/1.1 >implementations haven't necessarily prepared well for such complicated >cipher suite selection ECC and TLS 1.2 introduce and that makes the >transition a bit difficult. That's quite possible. At the moment both TLS-ECC and TLS 1.2 deployment is so vanishingly small that we have little data to go on, and as an implementer you really can't see how problematic things get until you do implement and deploy something. One of the reasons for getting the draft out there is to try and both point out, and then address the problem before it becomes a real issue. >Should it be added to the draft that for example implementations using >mentioned SHA-256 cipher suites must also send signature_algorithms >extension with corresponding hash and ECDSA pair? Right now it only points >out the used hash functions, but TLS 1.2 specification quite clearly says >that one should default to the {sha1,ecdsa} combination if no extension is >sent. I think this draft doesn't make it clear enough if it overrides that >requirement or not. Hmm, it should already say that: ECDSA signature in Server Key Exchange message: P256 or P384 curve as for ECDH with uncompressed points and SHA1, SHA256 or SHA384 as indicated in the suite name. And for client auth: Client authentication in Certificate Request/Certificate Verify messages: SHA1, SHA256, or SHA384 as indicated in the suite name. In other words "if you're using SHA256 at location X then you should use it at location Y as well" (I can't imagine why you'd want to use, say SHA-1 at point X but then SHA256 at point Y, and if anyone really does want this they can still do it using the existing Chinese-menu option). >Also, the term "Chinese-menu" is a word I haven't seen in any existing TLS >related RFC, even though it is very widely used in your draft and related >discussion. I think it would make sense to at least define the meaning of the >word a bit more clearly if it is going to be used, but it might be worth >changing it to something completely different. I for one have lived in China >for some years and have always managed to agree on the menu and the details, >so I believe at least the Chinese people might find it puzzling. Not to >mention someone might even consider it offending... I used the term "Chinese menu" because it's common usage in the US for a mix- and-match selection of items, the "one from column A, one from column B" selection, and figured using "table d'hote" and "a la carte" might be going a bit too far :-). I'll add a rationale section that discusses the naming (see e.g. http://www.barrypopik.com/index.php/new_york_city/entry/one_from_column_a_one_from_column_b_chinese_menu_ordering/, from a quick Google search, perhaps it's a US-only colloquialism), and also more on why there's a problem and why it's a good idea to address it fairly soon. Peter. From juhovh@iki.fi Wed May 4 03:41:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC8AE0719 for ; Wed, 4 May 2011 03:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3027Uqg4Uvpb for ; Wed, 4 May 2011 03:41:26 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 254C9E070D for ; Wed, 4 May 2011 03:41:25 -0700 (PDT) Received: from mail.visino.fi (84.251.121.70) by jenni1.inet.fi (8.5.133) id 4DC043D300082CB5; Wed, 4 May 2011 13:41:17 +0300 Received: from [130.233.194.202] (tko-add-202.cs.hut.fi [130.233.194.202]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id ACD4D201C5; Wed, 4 May 2011 13:41:12 +0300 (EEST) Message-ID: <4DC12D35.1040805@iki.fi> Date: Wed, 04 May 2011 13:40:53 +0300 From: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 10:41:27 -0000 4.5.2011 11:56, Peter Gutmann kirjoitti: >> I think this what makes this worse is that existing TLS 1.0/1.1 >> implementations haven't necessarily prepared well for such complicated >> cipher suite selection ECC and TLS 1.2 introduce and that makes the >> transition a bit difficult. > That's quite possible. At the moment both TLS-ECC and TLS 1.2 deployment is > so vanishingly small that we have little data to go on, and as an implementer > you really can't see how problematic things get until you do implement and > deploy something. One of the reasons for getting the draft out there is to > try and both point out, and then address the problem before it becomes a real > issue. I think the deployment is very small on the server side, but I would say it is quite common on the client side. I know at least Firefox has had ECC cipher suites enabled by default for quite a long time (3 years or so), and I think that attributes to somewhere close to one third of all browsers globally. (according to Mozilla more than 350 million users) Calling TLS-ECC deployment vanishingly small is a bit of an understatement, don't you think? Should at least carefully consider what implications the draft has on interoperability with existing implementations, especially if the handshake methods are made mutually exclusive. >> Should it be added to the draft that for example implementations using >> mentioned SHA-256 cipher suites must also send signature_algorithms >> extension with corresponding hash and ECDSA pair? Right now it only points >> out the used hash functions, but TLS 1.2 specification quite clearly says >> that one should default to the {sha1,ecdsa} combination if no extension is >> sent. I think this draft doesn't make it clear enough if it overrides that >> requirement or not. > Hmm, it should already say that: > > ECDSA signature in Server Key Exchange message: P256 or P384 curve > as for ECDH with uncompressed points and SHA1, SHA256 or SHA384 as > indicated in the suite name. > > And for client auth: > > Client authentication in Certificate Request/Certificate Verify > messages: SHA1, SHA256, or SHA384 as indicated in the suite name. > > In other words "if you're using SHA256 at location X then you should use it > at location Y as well" (I can't imagine why you'd want to use, say SHA-1 at > point X but then SHA256 at point Y, and if anyone really does want this they > can still do it using the existing Chinese-menu option). That's exactly the parts of the draft I am referring to. This should be combined with the RFC 5246 text: If the client does not send the signature_algorithms extension, the server MUST do the following: ... - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. Your draft does not mandate sending the signature_algorithms extension, but at the same time it does say one should use the SHA256 or SHA386 for signatures. Does it override the above clause of TLS 1.2 or does it implicate signature_algorithms have to be always sent in case any of those cipher suites are to be offered? > I used the term "Chinese menu" because it's common usage in the US for a mix- > and-match selection of items, the "one from column A, one from column B" > selection, and figured using "table d'hote" and "a la carte" might be going a > bit too far :-). I'll add a rationale section that discusses the naming (see > e.g. > http://www.barrypopik.com/index.php/new_york_city/entry/one_from_column_a_one_from_column_b_chinese_menu_ordering/, > from a quick Google search, perhaps it's a US-only colloquialism), and also > more on why there's a problem and why it's a good idea to address it fairly > soon. That explains it much better, I tried to google it before but didn't really get any sensible results. Looks like searching for "chinese menu column" gives more hits, although I wonder how common knowledge it is, because most search results seem to be explaining it to readers even though they are not technical specifications. But I can confirm at least it is not the common way to order food in China. If we go into slight nitpicking, in Chinese menu the choice from column A doesn't affect the choice from column B and the two choices are independent. In case of TLS and ECC cipher suites, the choice from column A enables making the choice from column B making them mutually dependent. I just don't like the term very much, I think referring to the two options as simplified ECC parameter selection and extension based parameter selection or something similar should suffice. But I can wait for the rationale section, I think it's a good idea to add. Juho From pgut001@login01.cs.auckland.ac.nz Mon May 9 08:31:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C21E07CC for ; Mon, 9 May 2011 08:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKQ6HrDE7+GI for ; Mon, 9 May 2011 08:31:44 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5F433E07AD for ; Mon, 9 May 2011 08:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1304955104; x=1336491104; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20juhovh@iki.fi,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20tls@ietf.org|In-Reply-To:=20<4DC12D 35.1040805@iki.fi>|Message-Id:=20|Date:=20Tue,=2010=20May=202011=200 2:00:38=20+1200; bh=8OOjdDl+TxHQ1OcotQXexIXlwPfjk4PSI2tiQ7OKFUw=; b=ihBYu5rwKe+FblnDxXeDZQScWBo7aAQJg17C/m7wQH3syG38Mb5Qqxup 3wVLTpx+oJeG0VmAErxzPTXfjCJkC+8BL0usORgbaQTPCL3cYdOTM0exa oz7YdzRoAbuIV++48VJARicWgMPlLIwFSBItqAIgCc1MG0yhWCV5mL3X4 o=; X-IronPort-AV: E=Sophos;i="4.64,340,1301832000"; d="scan'208";a="60837354" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 May 2011 02:00:44 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QJR0o-0003fW-JI; Tue, 10 May 2011 02:00:38 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QJR0o-0003ui-Tx; Tue, 10 May 2011 02:00:38 +1200 From: Peter Gutmann To: juhovh@iki.fi, pgut001@cs.auckland.ac.nz In-Reply-To: <4DC12D35.1040805@iki.fi> Message-Id: Date: Tue, 10 May 2011 02:00:38 +1200 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 09 May 2011 15:31:45 -0000 =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= writes: >I think the deployment is very small on the server side, but I would say it >is quite common on the client side. I know at least Firefox has had ECC >cipher suites enabled by default for quite a long time (3 years or so), and I >think that attributes to somewhere close to one third of all browsers >globally. (according to Mozilla more than 350 million users) Calling TLS-ECC >deployment vanishingly small is a bit of an understatement, don't you think? "Implemented in the client" != "used" though. The only hard data that we have at the moment, the SSL Observatory, indicates: Number of deployed DSA TLS servers with certs chaining to a trusted root: 25 Number " " ECC " " ": Zero Number " " RSA " " ": Millions For non-trusted certs I think there were a total of six servers doing ECC in the entire world, and I'm guessing most or even all of them are the small number of public interop servers out there. Both of those make it "vanishingly small" (at least for public deployment) as far as I'm concerned :-). >That's exactly the parts of the draft I am referring to. This should be >combined with the RFC 5246 text: > > If the client does not send the signature_algorithms extension, the > server MUST do the following: >... > - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, > ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. > >Your draft does not mandate sending the signature_algorithms extension, but >at the same time it does say one should use the SHA256 or SHA386 for >signatures. Does it override the above clause of TLS 1.2 or does it implicate >signature_algorithms have to be always sent in case any of those cipher >suites are to be offered? Ah, I see what you mean. OK, I'll add a note to address this. RFC 5246 assumes the universal-substrate SHA1 if you forget the signature_algorithms extension as a means of handling the lack of an explicit indication since there's no other way to tell what to use, but the ECC-suites draft makes it explicit what hash to use so there's no need to use the fall-back rules. >That explains it much better, I tried to google it before but didn't really >get any sensible results. Looks like searching for "chinese menu column" gives >more hits, I've added a note to explain it for non-US readers. If you search for "one from column A one from column B" you'll get an awful lot of hits, things like medical papers using that in the title: http://www.ncbi.nlm.nih.gov/pubmed/11827830 The search term "Chinese menu" gets overwhelmed by links to restaurants. Peter. From lloyd@randombit.net Mon May 9 13:15:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E292E0723 for ; Mon, 9 May 2011 13:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3FfgrrZqa3x for ; Mon, 9 May 2011 13:15:43 -0700 (PDT) Received: from chihiro.randombit.net (chihiro.randombit.net [69.48.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id 58FB7E06EC for ; Mon, 9 May 2011 13:15:43 -0700 (PDT) Received: by chihiro.randombit.net (Postfix, from userid 1000) id E8C622F000C6; Mon, 9 May 2011 16:05:43 -0400 (EDT) Date: Mon, 9 May 2011 16:05:43 -0400 From: Jack Lloyd To: tls@ietf.org Message-ID: <20110509200543.GW30682@randombit.net> Mail-Followup-To: tls@ietf.org References: <4DC12D35.1040805@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 09 May 2011 20:15:44 -0000 On Tue, May 10, 2011 at 02:00:38AM +1200, Peter Gutmann wrote: > > "Implemented in the client" != "used" though. The only hard data that we have > at the moment, the SSL Observatory, indicates: > > Number of deployed DSA TLS servers with certs chaining to a trusted root: 25 > Number " " ECC " " ": Zero > Number " " RSA " " ": Millions So, nobody at all has an ECDSA certificate, but it makes sense to only assign ciphersuites to algorithm sets that require ECDSA certificates because that is the common case? I'm having difficult reconciling the above information with the apparent intent of the i-d. -Jack From pgut001@login01.cs.auckland.ac.nz Tue May 10 06:50:52 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D769FE0780 for ; Tue, 10 May 2011 06:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbwF3-vR9une for ; Tue, 10 May 2011 06:50:51 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9A333E0708 for ; Tue, 10 May 2011 06:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305035452; x=1336571452; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20lloyd@randombit.net,=20tls@ietf.org|Subject:=20Re: =20[TLS]=20DSS=20with=20other=20than=20SHA-1=20algorithms |In-Reply-To:=20<20110509200543.GW30682@randombit.net> |Message-Id:=20|Date:=20Wed,=2011=20May=202011=2001:49:35=20+1200; bh=9dQOGSK5vAA2Wi4NDfJSLoxnE5GJs3Osz9kcIi/dda4=; b=LnHPXnX9NTC/Ptm2IHvXgobXYoGcFVdcES+9YKUuJZ0TcQvanqoE4rJ+ 3+9g8rGVujyPrcEX+BMgH3hp4AwDvx3l/xFBDZVXAzo/nUmr+kE39Tp1X FaT6hS3xJIze3DOKdkAbwlMNUesfmIZ7k6gbe5A5M2vNaHQp43bRwpCPQ 8=; X-IronPort-AV: E=Sophos;i="4.64,346,1301832000"; d="scan'208";a="61041772" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 May 2011 01:49:35 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QJnJf-0002CM-Hq; Wed, 11 May 2011 01:49:35 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QJnJf-0003z2-Fg; Wed, 11 May 2011 01:49:35 +1200 From: Peter Gutmann To: lloyd@randombit.net, tls@ietf.org In-Reply-To: <20110509200543.GW30682@randombit.net> Message-Id: Date: Wed, 11 May 2011 01:49:35 +1200 Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 10 May 2011 13:50:53 -0000 Jack Lloyd writes: >So, nobody at all has an ECDSA certificate, Nobody has an ECSDA cert *signed by a trusted CA*, i.e. something that a browser will connect to without setting off all sorts of alarms. >but it makes sense to only assign ciphersuites to algorithm sets that require >ECDSA certificates because that is the common case? It's the common case based on a survey of all (known) publicly-deployed servers running TLS-ECC, representing (at least) Microsoft, Apache (presumably OpenSSL), and NSS. That's the three biggest players in the market (and some smaller ones as well), so I think it's a pretty good representative sample. Peter. From n.mavrogiannopoulos@gmail.com Tue May 10 09:06:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3668E070C for ; Tue, 10 May 2011 09:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFvCeFVn6BSX for ; Tue, 10 May 2011 09:06:29 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2070E0693 for ; Tue, 10 May 2011 09:06:28 -0700 (PDT) Received: by ewy19 with SMTP id 19so2308012ewy.31 for ; Tue, 10 May 2011 09:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=VR4ZpMjv9TGfxsAj1AOBMJvALZM9JBq4M7NB0ut4uSU=; b=sDR4zIqTvS29JHeO22lH3ColIrKevlX/n27gNzog2ibA2nuxwM0cN5YxQ431Ggipk2 Kj7UlvEoFx7opitIEOsjJk3DtFhSf+W0rkjVEiOus6qjHaus8AjLZvQpQ0la3zuR0RPW g8z1Q80fB2kQfA4V2ykNO4l/qsP2S3uVXB1a4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=vFJEri7wE8OohJxM8NT/ez1AE8/P1Z5Zqkqsjny5Y2tJM0jq/vyp1t8Z5UrdNCoF2F VtIHs98Be3kJ9I4OgxgQUCZXcZ91sAdznSesWtozrw4t3PWnvzRID884SczKI6ZuFVEY zly9um/1LyD28bqBkzUdVojIkGn9b+x6F2sdU= Received: by 10.213.102.84 with SMTP id f20mr2943974ebo.134.1305043585363; Tue, 10 May 2011 09:06:25 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id r12sm4434610eeb.4.2011.05.10.09.06.22 (version=SSLv3 cipher=OTHER); Tue, 10 May 2011 09:06:23 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DC9627D.4000208@gnutls.org> Date: Tue, 10 May 2011 18:06:21 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 10 May 2011 16:06:30 -0000 On 05/10/2011 03:49 PM, Peter Gutmann wrote: >> So, nobody at all has an ECDSA certificate, > Nobody has an ECSDA cert *signed by a trusted CA*, i.e. something that a > browser will connect to without setting off all sorts of alarms. Indeed but on the same study you based your point on deprecating DSA. >> but it makes sense to only assign ciphersuites to algorithm sets that require >> ECDSA certificates because that is the common case? > It's the common case based on a survey of all (known) publicly-deployed > servers running TLS-ECC, representing (at least) Microsoft, Apache (presumably > OpenSSL), and NSS. That's the three biggest players in the market (and some > smaller ones as well), so I think it's a pretty good representative sample. I don't really understand. So is ECDSA used for self-signed certificates? Is it used for client certificates (and thus not discovered by this study?). According to me this study would be an argument for the _RSA ecc ciphersuites rather than the ECDSA. regards, Nikos From juhovh@iki.fi Tue May 10 12:30:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45940E0766 for ; Tue, 10 May 2011 12:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ea44oEB3QOT for ; Tue, 10 May 2011 12:30:45 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1A83BE074F for ; Tue, 10 May 2011 12:30:44 -0700 (PDT) Received: from mail.visino.fi (84.251.121.70) by kirsi1.inet.fi (8.5.133) id 4D9982B1019AA051; Tue, 10 May 2011 22:30:31 +0300 Received: from [192.168.1.100] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id E88A3202D9; Tue, 10 May 2011 22:30:25 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1-331110475; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <4DC9627D.4000208@gnutls.org> Date: Tue, 10 May 2011 22:30:24 +0300 Message-Id: <3861CAD1-BB25-47B6-9ACE-4FE16946A61E@iki.fi> References: <4DC9627D.4000208@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 10 May 2011 19:30:46 -0000 --Apple-Mail-1-331110475 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 10, 2011, at 7:06 PM, Nikos Mavrogiannopoulos wrote: >>> but it makes sense to only assign ciphersuites to algorithm sets = that require >>> ECDSA certificates because that is the common case? >> It's the common case based on a survey of all (known) = publicly-deployed >> servers running TLS-ECC, representing (at least) Microsoft, Apache = (presumably >> OpenSSL), and NSS. That's the three biggest players in the market = (and some >> smaller ones as well), so I think it's a pretty good representative = sample. >=20 > I don't really understand. So is ECDSA used for self-signed > certificates? Is it used for client certificates (and thus not > discovered by this study?). According to me this study would be an > argument for the _RSA ecc ciphersuites rather than the ECDSA. I was about to say the same. The draft refers to = http://msdn.microsoft.com/en-us/library/aa374757%28v=3Dvs.85%29.aspx as = a major implementation already doing the suggested suites, but at the = same time drops all ECDHE_RSA ciphersuites from the exact same document = and only includes the ECDHE_ECDSA ciphersuites. If it's true that = there's basically zero ECDSA certs signed by a trusted CA, it would be a = quite strong argument to do the opposite. What's the motivation of dropping ECDHE_RSA suites if there are millions = of RSA certificates? Juho --Apple-Mail-1-331110475 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwNTEwMTkzMDI1WjAjBgkqhkiG9w0BCQQxFgQU1bAx4SI2K6aKfXehW3X2JZLK8WAwgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEAInh9/Rz05NZQ7skJ41/W8rA8xcZ0nfjKOmJsedRCHmxbJAEIQsMHauVkH/CSKBTg06hw MOsx9AqSxevh3IbTtHkOnk7O8lMBZx3JzYpZXuJG8zitlBowGzUqdWiiubdshr8kmU15iMf3p9sh ojULEwk3/ILkjaauVBgzFnjwscr3q9prYRdKFh9X5YJy3e3Sp++PwipuEmma7SiGiLlgIagRKQ4f XsC7/R/ke2wrxnjD1GQxJwVdSXLWA/QDpiK7iQnG/9PLwBR2ka4gy4zVFEjCtPdbUcWis2S0N63b uu8dvyPhopw7id1q+1lrM9VJtWakAbu2wCX7ozW/mKJq+gAAAAAAAA== --Apple-Mail-1-331110475-- From pgut001@login01.cs.auckland.ac.nz Tue May 10 19:31:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16301E06CE for ; Tue, 10 May 2011 19:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMlq6NnxZfyr for ; Tue, 10 May 2011 19:31:56 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 360FCE06B5 for ; Tue, 10 May 2011 19:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305081116; x=1336617116; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nmav@gnutls.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20lloyd@randombit.net,=20tls@ietf.org |In-Reply-To:=20<4DC9627D.4000208@gnutls.org>|Message-Id: =20|Date: =20Wed,=2011=20May=202011=2014:31:46=20+1200; bh=711NLJYiJ5zmI7A/3ZZtMtFjRjmpczgB8xT1seEAukE=; b=L1Qekek2VKyM0/Epv1gNe596sCoN67/kU9/jsa3/mAxb3nYmFjJhHJb0 +8N7M3ubSnI0tBk8AJeIzpE4eYy3PrU6R4Zd61c67DABPyW44erf0DxRA cprKrsEtbwpSj8mwXmXP7lbOs2ldm5TBHz9xy8Pqu0jMj83w5hZZB81Z/ Y=; X-IronPort-AV: E=Sophos;i="4.64,350,1301832000"; d="scan'208";a="61177598" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 May 2011 14:31:46 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QJzDG-0003wW-H6; Wed, 11 May 2011 14:31:46 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QJzDG-0006iS-85; Wed, 11 May 2011 14:31:46 +1200 From: Peter Gutmann To: nmav@gnutls.org, pgut001@cs.auckland.ac.nz In-Reply-To: <4DC9627D.4000208@gnutls.org> Message-Id: Date: Wed, 11 May 2011 14:31:46 +1200 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 02:31:57 -0000 Nikos Mavrogiannopoulos writes: >I don't really understand. So is ECDSA used for self-signed certificates? Yes. >According to me this study would be an argument for the _RSA ecc ciphersuites >rather than the ECDSA. Why? The draft contains the combinations of parameters and options that everything seems to support and everything seems to get right. Why the obsession with _RSA? (Note, if you can document support for, and interoperability among, Microsoft, NSS, OpenSSL, and one or two other implementations, for _RSA, I'll be happy to add it). To reiterate this yet again, the draft collects in one place the various combinations of parameters and options that everything I could find supports and handles correctly. What it doesn't contain is speculative options that may or may not work and may or may not be supported. It is an attempt to document the status quo and point out the best options to use in order to maximise interoperability. Peter. From mrex@sap.com Tue May 10 20:08:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1CFE06E3 for ; Tue, 10 May 2011 20:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.65 X-Spam-Level: X-Spam-Status: No, score=-7.65 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vxb689IYIaDW for ; Tue, 10 May 2011 20:08:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 45B62E065D for ; Tue, 10 May 2011 20:08:49 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p4B38d8E007246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 05:08:39 +0200 (MEST) From: Martin Rex Message-Id: <201105110308.p4B38de3019432@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 11 May 2011 05:08:39 +0200 (MEST) In-Reply-To: from "Peter Gutmann" at May 10, 11 02:00:38 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 03:08:50 -0000 Peter Gutmann wrote: > > "Implemented in the client" != "used" though. The only hard data that we have > at the moment, the SSL Observatory, indicates: > > Number of deployed DSA TLS servers with certs chaining to a trusted root: 25 > Number " " ECC " " ": Zero > Number " " RSA " " ": Millions I believe the EFF slides give a figure of 1.3 million RSA certs issued under a well-known commercial Root. There are probably a number of reasons why we are seeing very few (if any) ECDSA certs issued by commercial CAs. EC algorithms are still patent encumbered, and the licensing scheme by the patent holder was a pay-per-issued-certificate targetting commercial CAs. The other issue is that there still is an awfully large installed base which doesn't support such certs--so as long as RSA is still considered secure, why bother with EC certificates? There seems to be a preference for ECDSA at NIST. But there also was a preference for DSA at NIST, including a bias for the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite in TLSv1.0 that was completely ignored by the marketplace. At the time when the not-EC-capable TLS implementations in the installed base have died off, the current EC-patent issues will also have evaporated... :) -Martin From juhovh@iki.fi Tue May 10 23:59:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C61E06C1 for ; Tue, 10 May 2011 23:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEcC01PybTO8 for ; Tue, 10 May 2011 23:59:06 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 04D00E06B3 for ; Tue, 10 May 2011 23:59:05 -0700 (PDT) Received: from mail.visino.fi (84.251.121.70) by jenni2.inet.fi (8.5.133) id 4D9AC7260191343B; Wed, 11 May 2011 09:58:52 +0300 Received: from [192.168.1.100] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id ADA5B201A6; Wed, 11 May 2011 09:58:46 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-5-372411133; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: Date: Wed, 11 May 2011 09:58:45 +0300 Message-Id: References: To: Peter Gutmann X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 06:59:11 -0000 --Apple-Mail-5-372411133 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 11, 2011, at 5:31 AM, Peter Gutmann wrote: > Nikos Mavrogiannopoulos writes: >> According to me this study would be an argument for the _RSA ecc = ciphersuites >> rather than the ECDSA. >=20 > Why? The draft contains the combinations of parameters and options = that > everything seems to support and everything seems to get right. Why = the > obsession with _RSA? I wouldn't want to repeat myself and I certainly am not obsessed with = _RSA (because in all ways it is a bad solution), but do you have any = data about which implementations didn't support or "get right" the _RSA = ciphersuites?=20 ECDH and ECDSA are basically the same calculation (EC point = multiplication), so it makes much more sense to do ECDHE_ECDSA from = idealistic point of view, but the motivation seems to be purely = practical. The fact is that I can only get RSA certificates from my CA, = so if I want forward secrecy I need to do either DHE_RSA or ECDHE_RSA. > (Note, if you can document support for, and interoperability among, = Microsoft, > NSS, OpenSSL, and one or two other implementations, for _RSA, I'll be = happy to > add it). Microsoft documents them on their website as supported, OpenSSL should = support them as well and NSS based browsers (at least Firefox) are = offering them in ClientHello by default. I can go to do some = interoperability testing, but before that I would like to know did you = ever test the _RSA ciphersuites? I think it is rather rude when people = present a perfectly valid question and the response is to call them = obsessive. And I would love to get some data about how _RSA suites fail = so I wouldn't have to do any tests, but I think this question is = completely in the scope of the draft and should be resolved before = releasing it. It seems the motivation of dropping _RSA suites is either = because they don't interoperate (for a reason that is difficult for me = to see) or because the author rightly believes they are crap and not = worth documenting. Either way the motivation should be known. So to repeat my main point, were the ECDHE_RSA ciphersuites ever tested = for interoperability and is the status of their interoperability known? = Simple yes or no to both will do and you can ignore everything else I = said above. Juho --Apple-Mail-5-372411133 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwNTExMDY1ODQ1WjAjBgkqhkiG9w0BCQQxFgQUJbrVcQMZEllK5rZof7mLIqaUENkwgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEAT10na2Qn9lCoRiBWcJSfIDLEuXCFQCsy1ZdeknDiJZbh1z/YagLVe2t6b5uHHWD5x0cQ sjhjc9rcdGjl1BOvZRABoI1Co+T9bhYDrsKJU6wP5YYVPTZx90N8ZepdOC+GwJAaQr59m8w6iPV7 ebUL+AYWiFOJgbngfNnIrxfv9Vcl1FMqkxbXsMm0tBgr9bHJkDQqVVLYdZ2YzSRfmyGT5KUJwhOc jVkfNi+QIbyYm63ANTrS+HnJOw81RzDZMQD4KYDSA7VdikDWlE+n71HXRmvrHK/6wEyvypM++Nxj HDUJK/s3/olXxZ6+tElW8j4NaJ7Icg14kQZRWDQG8QS0AwAAAAAAAA== --Apple-Mail-5-372411133-- From pgut001@login01.cs.auckland.ac.nz Wed May 11 01:29:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE28E06A3 for ; Wed, 11 May 2011 01:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htWRa10XBp2a for ; Wed, 11 May 2011 01:29:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id C2AADE06A1 for ; Wed, 11 May 2011 01:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305102569; x=1336638569; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20juhovh@iki.fi,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20nmav@gnutls.org,=20tls@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2011=20May=202011=2020:29:25=20+120 0; bh=9R3vE9mkbgM7UeIGkmTeS/ai3DqVHTK7W7wUWYSGk28=; b=HUStHWBlyzMGWeSvpySJRjU8BmGkR3Ax8zDJobxRxY2BWYt0Nbjv+os9 IxzDSZhEEFKwm4jBAoJxlz7YIbBLm9ENdJgN3Ss05wQPeE9QYrk+HyVnp odpKnaF5A8ec8zMwoEwqDy+603SimVeclclmipTMdZ+CMZe3xlv2VhG9Z M=; X-IronPort-AV: E=Sophos;i="4.64,351,1301832000"; d="scan'208";a="61240158" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 May 2011 20:29:26 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QK4nN-0008Pj-HU; Wed, 11 May 2011 20:29:25 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QK4nN-0007AN-Bs; Wed, 11 May 2011 20:29:25 +1200 From: Peter Gutmann To: juhovh@iki.fi, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Wed, 11 May 2011 20:29:25 +1200 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 08:29:30 -0000 =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= writes: >So to repeat my main point, were the ECDHE_RSA ciphersuites ever tested for >interoperability and is the status of their interoperability known? This gets a bit political, see my reply off-list. In short, if there's demonstrated interoperability between the different implementations I'm happy to add it, but the last I saw (and heard from others) this wasn't the case. Peter. From pgut001@login01.cs.auckland.ac.nz Wed May 11 01:38:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9478AE06A1 for ; Wed, 11 May 2011 01:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiNmp5P87wtZ for ; Wed, 11 May 2011 01:38:35 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id B9EB5E06A0 for ; Wed, 11 May 2011 01:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305103115; x=1336639115; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20DSS=20with =20other=20than=20SHA-1=20algorithms|Cc:=20tls@ietf.org |In-Reply-To:=20<201105110308.p4B38de3019432@fs4113.wdf.s ap.corp>|Message-Id:=20|Date:=20Wed,=2011=20May=202011=2020:38:33=20 +1200; bh=+8zRYYNwbceRoqMyzePi+e9czA7afVWW6S5aHsiPuk4=; b=fLuodSdvZDoFZN3IYLsAij95Usny11NLkSxGzp+uG/URKfDvDiIuP6WV /UF02htpXgotJo9HfY1iyN+MHnU9PlbKa/km/HQo3gChyWQeuOyBd3X3c ju3jKP6UCY0SEJCq89LXVhrCUo+jefdmpBJyzkh2+2zsmDmtQ3Nk604/4 c=; X-IronPort-AV: E=Sophos;i="4.64,351,1301832000"; d="scan'208";a="61240710" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 May 2011 20:38:34 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QK4wD-0000GV-Iy; Wed, 11 May 2011 20:38:33 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QK4wD-0007QV-Qp; Wed, 11 May 2011 20:38:33 +1200 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201105110308.p4B38de3019432@fs4113.wdf.sap.corp> Message-Id: Date: Wed, 11 May 2011 20:38:33 +1200 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 08:38:35 -0000 Martin Rex writes: >There are probably a number of reasons why we are seeing very few (if any) >ECDSA certs issued by commercial CAs. EC algorithms are still patent >encumbered, and the licensing scheme by the patent holder was a pay-per- >issued-certificate targetting commercial CAs. Are the CAs impeded by patents? You can do ECC without infringing on any patents, and I would guess the HSMs that do use any patented aspects of ECC have already paid their tithe to Certicom. >The other issue is that there still is an awfully large installed base which >doesn't support such certs--so as long as RSA is still considered secure, why >bother with EC certificates? I think that's the real reason, use of ECC is essentially a fashion statement, and the fact that any use condemns you to Browser Warning Hell makes it a very expensive one. The one upside to this is that after six years we still have next to no (public) deployed base to potentially cause problems, so it's still possible to fix issues without breaking lots of things. Peter. From rob.stradling@comodo.com Wed May 11 03:50:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D865E0720 for ; Wed, 11 May 2011 03:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaU5R2hcoOdl for ; Wed, 11 May 2011 03:50:26 -0700 (PDT) Received: from mcmail1.mcr.colo.comodo.net (mail1.comodogroup.com [91.199.212.133]) by ietfa.amsl.com (Postfix) with ESMTP id 39C78E0679 for ; Wed, 11 May 2011 03:50:25 -0700 (PDT) Received: (qmail 26456 invoked by uid 1008); 11 May 2011 10:50:24 -0000 Received: from mail.india.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mcmail1.mcr.colo.comodo.net (qpsmtpd/0.40) with ESMTP; Wed, 11 May 2011 11:50:24 +0100 Received: (qmail 8615 invoked by uid 1000); 11 May 2011 10:50:23 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Wed, 11 May 2011 11:50:23 +0100 From: Rob Stradling To: tls@ietf.org Date: Wed, 11 May 2011 11:49:12 +0100 User-Agent: KMail/1.13.7 (Linux/2.6.37-gentoo-r4; KDE/4.6.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201105111149.12286.rob.stradling@comodo.com> Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 10:50:27 -0000 On Wednesday 11 May 2011 09:38:33 Peter Gutmann wrote: > Martin Rex writes: > >There are probably a number of reasons why we are seeing very few (if any) > >ECDSA certs issued by commercial CAs. EC algorithms are still patent > >encumbered, and the licensing scheme by the patent holder was a pay-per- > >issued-certificate targetting commercial CAs. > > Are the CAs impeded by patents? The first commercial CA to answer "No" and proceed to issue ECC certs will almost certainly end up in court with an expensive legal bill. Even if the correct answer really is "No". So yes, the CAs are impeded by patents. > You can do ECC without infringing on any patents, and I would guess the HSMs > that do use any patented aspects of ECC have already paid their tithe to > Certicom. nCipher have paid their tithe: http://www.certicom.com/index.php/2005-press-releases/35-2005-press- releases/247-certicom-licenses-intellectual-property-to-ncipher However, last I heard, nCipher will only grant their HSMs' ECC functionality to be enabled for: a) customers who are not CAs. b) customers who are CAs and who have a suitable CA licence from Certicom. > >The other issue is that there still is an awfully large installed base > >which doesn't support such certs--so as long as RSA is still considered > >secure, why bother with EC certificates? > > I think that's the real reason, use of ECC is essentially a fashion > statement, and the fact that any use condemns you to Browser Warning Hell There doesn't have to be Browser Warning Hell. A server could have an RSA cert and an ECC cert. When a client advertises support for any ECC cipher suites in its "ClientHello" message, the server can send its ECC cert in its "Certificate" message. When a client doesn't advertise support for any ECC cipher suites, the server can "fall back" to its RSA cert. I believe that OpenSSL's server code behaves in this way. Of course, configuring 2 certs would be extra hassle (and possibly extra expense) over configuring just 1 cert. So my guess is that many sites would still not bother with ECC certs, even if they were bundled free with paid RSA certs. Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From paul.hoffman@vpnc.org Wed May 11 07:14:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45F4E0758 for ; Wed, 11 May 2011 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIax99xUyNLz for ; Wed, 11 May 2011 07:14:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DDE71E0746 for ; Wed, 11 May 2011 07:14:28 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4BEEAnG012487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 07:14:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201105111149.12286.rob.stradling@comodo.com> Date: Wed, 11 May 2011 07:14:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <92D2BDAA-D76F-410E-80B7-EEEB9CD81ADC@vpnc.org> References: <201105111149.12286.rob.stradling@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 14:14:29 -0000 On May 11, 2011, at 3:49 AM, Rob Stradling wrote: > On Wednesday 11 May 2011 09:38:33 Peter Gutmann wrote: >> Martin Rex writes: >>> There are probably a number of reasons why we are seeing very few = (if any) >>> ECDSA certs issued by commercial CAs. EC algorithms are still = patent >>> encumbered, and the licensing scheme by the patent holder was a = pay-per- >>> issued-certificate targetting commercial CAs. >>=20 >> Are the CAs impeded by patents? >=20 > The first commercial CA to answer "No" and proceed to issue ECC certs = will=20 > almost certainly end up in court with an expensive legal bill. Even = if the=20 > correct answer really is "No". >=20 > So yes, the CAs are impeded by patents. This makes it sound like there are patents are issuing ECC certs. = However, that statement seems to fly in the face of RFC 6090. Can you = clarify? This seems particularly odd because Comodo has issued itself an = ECC certificate that is now widely distributed. --Paul Hoffman From mrex@sap.com Wed May 11 09:20:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F42E07B0 for ; Wed, 11 May 2011 09:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.687 X-Spam-Level: X-Spam-Status: No, score=-8.687 tagged_above=-999 required=5 tests=[AWL=1.562, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f+a29igmMGE for ; Wed, 11 May 2011 09:20:20 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4B6E07A3 for ; Wed, 11 May 2011 09:20:19 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p4BGJxpH025866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 18:19:59 +0200 (MEST) From: Martin Rex Message-Id: <201105111619.p4BGJwjq004242@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 11 May 2011 18:19:58 +0200 (MEST) In-Reply-To: from "Peter Gutmann" at May 11, 11 02:31:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 16:20:23 -0000 Peter Gutmann wrote: > > Nikos Mavrogiannopoulos writes: > > > > According to me this study would be an argument for the _RSA ecc > > ciphersuites rather than the ECDSA. > > Why? The draft contains the combinations of parameters and options that > everything seems to support and everything seems to get right. Why the > obsession with _RSA? > > (Note, if you can document support for, and interoperability among, > Microsoft, NSS, OpenSSL, and one or two other implementations, > for _RSA, I'll be happy to add it). > > To reiterate this yet again, the draft collects in one place the various > combinations of parameters and options that everything I could find supports > and handles correctly. What it doesn't contain is speculative options that > may or may not work and may or may not be supported. It is an attempt to > document the status quo and point out the best options to use in order to > maximise interoperability. I think it is worth considering to describe an interoperable set of _RSA based EC ciphersuites and parameters. In case that there are, in fact, interop problems with the existing definitions in the installed base, TLS WG should try to figure out the kind of problems that exist in the installed base and try to come up with solutions for these interop problems. Possible solutions for interop problems with _RSA cipher suites might be: - describe workarounds to deal with the problem within the currently defined protocol options. - modify the existing (TLS extension) definition (in a backwards-compatible fashion, of course) to overcome the problem - add a new extension - define new cipher suite codepoints to represent the intended purpose and interop-test _before_ shipping implementations this time around -Martin From jsalowey@cisco.com Wed May 11 15:04:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC09E08B9 for ; Wed, 11 May 2011 15:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV+ZHEIvlG2C for ; Wed, 11 May 2011 15:04:42 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id C01A9E0877 for ; Wed, 11 May 2011 15:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2030; q=dns/txt; s=iport; t=1305151482; x=1306361082; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ill1Np52HrONCM1QJiiBFIzVuxzi0bgWWiE7HKvMrvQ=; b=jZ5F3YkLL4+pAT5YQcIDKszAKXibL6lBUtXp/gF+dDq3CL3etSsMFYnT s8ljOjx7ph0lc4+01Mqu8/UPKEeC8XK1ozirLcuHp7Fi2PLgEMnAA1HXY l7voBpXWc03LLsE3571zpKje+f3EoPD9gIXGHfvy/te+fgDdVDyZQMU7X U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwHAAkHy02rRDoG/2dsb2JhbACYEY1yd4hwoVKePYYQBIZDiS2EJ4pa Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 11 May 2011 22:04:42 +0000 Received: from [10.33.249.93] ([10.33.249.93]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4BM4fI9010867; Wed, 11 May 2011 22:04:41 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <201105022227.p42MRhdD015568@fs4113.wdf.sap.corp> Date: Wed, 11 May 2011 15:04:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105022227.p42MRhdD015568@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 22:04:43 -0000 On May 2, 2011, at 3:27 PM, Martin Rex wrote: > Joe Salowey wrote: >>=20 >> Brian Smith wrote: >>>=20 >>> Joe Salowey wrote: >>>> Below is updated charter text reflecting feedback on the list. = Please >>>> indicate if you support this text or if you have issues with the = text. >>>=20 >>> Are extensions that add/remove/reorder handshake records acceptable >>> for TLS 1.2? If so, then I think the the proposed charter looks = fine. >>=20 >> [Joe] In most cases I would expect that add/remove/reorder handshake >> records would be a significant change and would require a charter = update. >> If the change had minimal impact it is possible that it could be made >> without updating the charter, but I would think that to be the = exception >> rather than the rule. =20 >=20 > Over the last couple of years (it looks like mid-of-2006) the TLS WG > never updated its charter for adopting new work, it seems, and there > were a number of documents since then.=20 >=20 > http://datatracker.ietf.org/wg/tls/ >=20 > While I do think TLS WG should improve on updating its charter, I'm = slightly > irritated by suggestions to become extreme in the other direction and = anal > about new work items all of a sudden (-- unless there are too many > proposals and it becomes necessary to limit the WGs focus to work only > on a few of them at a time.) [Joe] The intent is to tighten up the charter so minor work items such, = as cipher suites and extensions, are still in scope and major changes to = the operation of the protocol are out of scope and require a charter = revision. This does not mean that we cannot discuss such changes in the = working group, but before we add add work items to create documents for = these changes we would need to update the charter. While I can envision = cases where updating the charter would be irritating I think in most = cases where we have working group consensus to make the change it would = be relatively easy. =20 >=20 > -Martin From rob.stradling@comodo.com Thu May 12 03:11:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A23FE076D for ; Thu, 12 May 2011 03:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m6MO3R3ir7Z for ; Thu, 12 May 2011 03:11:19 -0700 (PDT) Received: from mcmail1.mcr.colo.comodo.net (mail1.comodogroup.com [91.199.212.133]) by ietfa.amsl.com (Postfix) with ESMTP id 25DBDE0754 for ; Thu, 12 May 2011 03:11:18 -0700 (PDT) Received: (qmail 27355 invoked by uid 1008); 12 May 2011 10:11:17 -0000 Received: from mail.india.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mcmail1.mcr.colo.comodo.net (qpsmtpd/0.40) with ESMTP; Thu, 12 May 2011 11:11:17 +0100 Received: (qmail 28461 invoked by uid 1000); 12 May 2011 10:11:17 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Thu, 12 May 2011 11:11:17 +0100 From: Rob Stradling To: Paul Hoffman Date: Thu, 12 May 2011 11:10:50 +0100 User-Agent: KMail/1.13.7 (Linux/2.6.37-gentoo-r4; KDE/4.6.2; i686; ; ) References: <201105111149.12286.rob.stradling@comodo.com> <92D2BDAA-D76F-410E-80B7-EEEB9CD81ADC@vpnc.org> In-Reply-To: <92D2BDAA-D76F-410E-80B7-EEEB9CD81ADC@vpnc.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201105121110.50586.rob.stradling@comodo.com> Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 10:11:20 -0000 On Wednesday 11 May 2011 15:14:10 Paul Hoffman wrote: > On May 11, 2011, at 3:49 AM, Rob Stradling wrote: > > On Wednesday 11 May 2011 09:38:33 Peter Gutmann wrote: > >> Martin Rex writes: > >>> There are probably a number of reasons why we are seeing very few (if > >>> any) ECDSA certs issued by commercial CAs. EC algorithms are still > >>> patent encumbered, and the licensing scheme by the patent holder was a > >>> pay-per- issued-certificate targetting commercial CAs. > >> > >> Are the CAs impeded by patents? > > > > The first commercial CA to answer "No" and proceed to issue ECC certs > > will almost certainly end up in court with an expensive legal bill. > > Even if the correct answer really is "No". > > > > So yes, the CAs are impeded by patents. > > This makes it sound like there are patents are issuing ECC certs. However, > that statement seems to fly in the face of RFC 6090. Can you clarify? Hi Paul. Thanks for pointing me at RFC 6090. I'd not seen it before. I agree that it appears to claim that issuing ECC certs is unencumbered by patents. I wonder if Certicom are aware of this RFC, and if so, what their opinion of it is. > This seems particularly odd because Comodo has issued itself an ECC > certificate that is now widely distributed. Certicom are aware of our ECC root certificate and they have not raised any objections. Several other CAs are now distributing ECC Roots too. I think Certicom see this activity as increasing the likelihood that CAs will pay to license their patents. However, AIUI, we've been led to believe that Certicom would object if a CA started to issue ECDSA-signed end-entity certs without some kind of license from Certicom. > --Paul Hoffman Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From bsmith@mozilla.com Thu May 12 13:41:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB135E07AA for ; Thu, 12 May 2011 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwZrwrnyptCH for ; Thu, 12 May 2011 13:41:19 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 566ADE067C for ; Thu, 12 May 2011 13:41:19 -0700 (PDT) Received: from mail.mozilla.com (zimbra1.shared.sjc1.mozilla.com [10.2.72.238]) by mail.mozilla.com (Postfix) with ESMTP id A9424AE6467C; Thu, 12 May 2011 13:41:18 -0700 (PDT) Date: Thu, 12 May 2011 13:41:18 -0700 (PDT) From: Brian Smith To: Joe Salowey Message-ID: <1886376336.97108.1305232878619.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [63.245.220.240] X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661) Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 20:41:19 -0000 Joe Salowey wrote: > [Joe] The intent is to tighten up the charter so minor work items > such, as cipher suites and extensions, are still in scope and major > changes to the operation of the protocol are out of scope and require > a charter revision. This does not mean that we cannot discuss such > changes in the working group, but before we add add work items to > create documents for these changes we would need to update the > charter. While I can envision cases where updating the charter would > be irritating I think in most cases where we have working group > consensus to make the change it would be relatively easy. There are a changes that we (Mozilla) are interested in implementing, documenting, and standardizing to improve handshake performance, and to improve the privacy and usability of client cert authentication (especially in Asia), so that more websites will adopt HTTPS. It seems counterproductive to change the charter now in such a way that would require us to debate whether we need to change the charter each time. I would like the charter to clearly indicate that significant changes at least in these areas (handshake performance and client cert authentication) are in scope. Cheers, Brian From rob.stradling@comodo.com Fri May 13 02:56:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56867E0750 for ; Fri, 13 May 2011 02:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQwzau6OY0Mi for ; Fri, 13 May 2011 02:56:01 -0700 (PDT) Received: from mcmail1.mcr.colo.comodo.net (mail1.comodogroup.com [91.199.212.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03DE07C5 for ; Fri, 13 May 2011 02:56:00 -0700 (PDT) Received: (qmail 31637 invoked by uid 1008); 13 May 2011 09:55:59 -0000 Received: from mail.india.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mcmail1.mcr.colo.comodo.net (qpsmtpd/0.40) with ESMTP; Fri, 13 May 2011 10:55:59 +0100 Received: (qmail 10451 invoked by uid 1000); 13 May 2011 09:55:58 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Fri, 13 May 2011 10:55:58 +0100 From: Rob Stradling To: tls@ietf.org Date: Fri, 13 May 2011 10:55:57 +0100 User-Agent: KMail/1.13.7 (Linux/2.6.37-gentoo-r4; KDE/4.6.2; i686; ; ) References: <92D2BDAA-D76F-410E-80B7-EEEB9CD81ADC@vpnc.org> <201105121110.50586.rob.stradling@comodo.com> In-Reply-To: <201105121110.50586.rob.stradling@comodo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201105131055.57556.rob.stradling@comodo.com> Cc: Paul Hoffman Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 09:56:02 -0000 On Thursday 12 May 2011 11:10:50 Rob Stradling wrote: > Hi Paul. Thanks for pointing me at RFC 6090. I'd not seen it before. I > agree that it appears to claim that issuing ECC certs is unencumbered by > patents. > > I wonder if Certicom are aware of this RFC, and if so, what their opinion > of it is. Certicom made an IPR disclosure [1] in relation to draft-03 of what is now RFC 6090. Thanks to those who told me about this off-list. I believe that Certicom's opinion is that commercial CAs would need to license at least [2] and [3] before they could... - verify the parameters of an EC public key supplied by a customer. - use the ECDSA algorithm to sign a certificate for a customer. So I return to my original conclusion: Yes, the CAs are impeded by patents. A colleague recalled a case (identities removed) to me recently: "I remember that one of the biggest hits that Company X took was getting into a patent dispute with Company Y. The Company Y claims were absolute unmitigated crud. Company X won hands down. But it cost them $2 million and it defocused their executive management team for over a year". IANAL or a cryptographer. I don't know if Certicom would win or lose a patent dispute against a commercial CA that issued ECC certs without a license. But even if I was confident that Certicom would lose, I wouldn't want to pay $2M in legal fees. IMHO, commercial CAs will only start issuing ECC certs if Certicom will first devise a suitable licensing scheme. [1] https://datatracker.ietf.org/ipr/1337/ [2] http://www.freepatentsonline.com/6704870.html [3] http://www.freepatentsonline.com/7215773.html Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From jsalowey@cisco.com Fri May 13 08:21:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100A6E0735 for ; Fri, 13 May 2011 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7TKVXxr1Roa for ; Fri, 13 May 2011 08:21:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8CE0734 for ; Fri, 13 May 2011 08:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2167; q=dns/txt; s=iport; t=1305300101; x=1306509701; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8PSbz6J6EX7u8Ig4PX+7whIREpsP/hgDVFU+WcOLNK8=; b=ftcWUidb5PmiOSA0i8Mst+9Wk5el3nOFFAC0gl6Wfu0scstiTh/ShGmy 4vJ5BcUJ4dJSqVeEcxSHCJVRc+xNdwU4Wzy39E7B8Rd7rtsrwd/gELZ0z qMJl0IduLsUmeD1oP6hvYfVoYX5e327gqjqYQl4NoUc88OuM7RmNI0dj6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL1LzU2rRDoI/2dsb2JhbACmCHeIcJ5lnhOGFQSGTYk5hC+KYw X-IronPort-AV: E=Sophos;i="4.64,364,1301875200"; d="scan'208";a="697016647" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 13 May 2011 15:21:41 +0000 Received: from [10.33.249.93] ([10.33.249.93]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4DFLcIR006641; Fri, 13 May 2011 15:21:39 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <1886376336.97108.1305232878619.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Date: Fri, 13 May 2011 08:21:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1886376336.97108.1305232878619.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> To: Brian Smith X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 15:21:42 -0000 On May 12, 2011, at 1:41 PM, Brian Smith wrote: > Joe Salowey wrote: >> [Joe] The intent is to tighten up the charter so minor work items >> such, as cipher suites and extensions, are still in scope and major >> changes to the operation of the protocol are out of scope and require >> a charter revision. This does not mean that we cannot discuss such >> changes in the working group, but before we add add work items to >> create documents for these changes we would need to update the >> charter. While I can envision cases where updating the charter would >> be irritating I think in most cases where we have working group >> consensus to make the change it would be relatively easy. >=20 > There are a changes that we (Mozilla) are interested in implementing, = documenting, and standardizing to improve handshake performance, and to = improve the privacy and usability of client cert authentication = (especially in Asia), so that more websites will adopt HTTPS. It seems = counterproductive to change the charter now in such a way that would = require us to debate whether we need to change the charter each time. I = would like the charter to clearly indicate that significant changes at = least in these areas (handshake performance and client cert = authentication) are in scope. >=20 [Joe] Our security AD has requested that we tighten up the charter such = that significant changes to the protocol require a charter update. We = can certainly discuss the topics you raise without a charter update. It = may be possible to publish documents for some of the things you want = without a charter update. For other things, in particular things that = require significant change to the TLS state machine or other aspects of = the protocol we are going to have to go through the process of updating = the charter. This does not have to be a heavyweight process, but it = does require more review than just adding a working group milestone. = Since TLS is in widespread use in all areas of the IETF this ensures = there is some cross area review before we initiate the work for a major = change > Cheers, > Brian From pgut001@login01.cs.auckland.ac.nz Fri May 13 23:34:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C55E0681 for ; Fri, 13 May 2011 23:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73DU8XxjmWhW for ; Fri, 13 May 2011 23:34:54 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id B2ACAE065D for ; Fri, 13 May 2011 23:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305354894; x=1336890894; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20DSS=20with =20other=20than=20SHA-1=20algorithms|Cc:=20tls@ietf.org |In-Reply-To:=20<201105111619.p4BGJwjq004242@fs4113.wdf.s ap.corp>|Message-Id:=20|Date:=20Sat,=2014=20May=202011=2018:34:52=20 +1200; bh=sX9ZACyiFPAtaRE923qkH5pMyCNL3I6Hos1BqWfLI60=; b=c1PjwccnxuTFeQ1XxNr8AoOX0vDjjMYS7EaEEyFQQ0jI1i0AAXk6huyT BgnI2U10/7VF1KlcF/oTAMZaLDmDhyBi9u+Hy4gssE90/Hjv+4OaqvF+Z kBgx0QGDNLAylbYjNCKE0oeLIyKFXJpfE8Cz2cXdzCTwes+HI5zLsK8ZL Q=; X-IronPort-AV: E=Sophos;i="4.64,367,1301832000"; d="scan'208";a="61741435" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 May 2011 18:34:52 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QL8RA-0000XL-Iu; Sat, 14 May 2011 18:34:52 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QL8RA-0002qg-QO; Sat, 14 May 2011 18:34:52 +1200 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201105111619.p4BGJwjq004242@fs4113.wdf.sap.corp> Message-Id: Date: Sat, 14 May 2011 18:34:52 +1200 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 06:34:54 -0000 Martin Rex writes: >I think it is worth considering to describe an interoperable set of _RSA >based EC ciphersuites and parameters. Sure, as I've said ealier if someone can go around and find a common set of parameters that's supported by, and works, for { Microsoft, NSS, OpenSSL, and one or two others } I'll be happy to add them (meaning, "document that this particular combination works") for the draft. This is a hint to someone else :-). I'll try and get round to it when I can, but I'm a bit busy at the moment, and as I mentioned earlier the last time I looked there didn't seem to be a common set of parameters where things worked. Peter. From paul.hoffman@vpnc.org Sat May 14 11:47:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEF7E0709 for ; Sat, 14 May 2011 11:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdDcx+t2lkrC for ; Sat, 14 May 2011 11:47:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 57F9BE06F0 for ; Sat, 14 May 2011 11:47:08 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4EIl6KW028635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 14 May 2011 11:47:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 14 May 2011 11:47:06 -0700 Message-Id: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] New draft for "next protocol" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 18:47:09 -0000 Greetings again. I have joined Adam as co-author on this draft. After = the discussion of the previous "next protocol" draft at the meeting in = Prague, we realized that the "negotiation" wording was tripping people = up, so we removed it and made it clear that, at the end, this is about = the client telling the server which protocol the client will be using = after the TLS session is setup. To make that clearer, we re-titled the = draft and started over at -00. Please take a look at = and let us know = what you think. --Paul Hoffman From evnikita2@gmail.com Sun May 15 03:47:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3886E06F2 for ; Sun, 15 May 2011 03:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE2bszXLVOh4 for ; Sun, 15 May 2011 03:47:34 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3DA9E06CE for ; Sun, 15 May 2011 03:47:33 -0700 (PDT) Received: by bwz13 with SMTP id 13so3682510bwz.31 for ; Sun, 15 May 2011 03:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type; bh=sMNWUUYdYy4mzfMjwZtSZS+eQeXjNBk5B+0jbCPBdI8=; b=L9GSzpFUpbdlFmNf71mYsU0iC+LGqhFBOYAtleRxgjF5mfn6r8y+aAQAsjUg2tzSjZ fuDz30JtQsAuBsAbBhbZiX3p7wTnd5Cy00JJHr7n4Q+dSL4wRsJIQlarBLRhd9CEgUCB dbLirD3ZBnUAI1ji4Aihjstj/kfzRjuHFPCuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; b=okx2i1SWM8cV3RHPcFAwZAccXCiBkMsi9r7YLqiouACEB1hMJfa+Zlv+GGWezXT97e Ud2WuyQTVyABvktvE3V6DAwJaJ18HxAzh+1Ps65uMcGAKzzuR4xtspUEOMRzxgdN7d6f JASydzoruZjecwhrrAoi6iHCPzGSSeIpCrYxA= Received: by 10.205.82.199 with SMTP id ad7mr2999984bkc.152.1305456452973; Sun, 15 May 2011 03:47:32 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q25sm2358171bkk.22.2011.05.15.03.47.31 (version=SSLv3 cipher=OTHER); Sun, 15 May 2011 03:47:32 -0700 (PDT) Message-ID: <4DCFAF6F.9020808@gmail.com> Date: Sun, 15 May 2011 13:48:15 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ietf-pop3ext@imc.org, tls@ietf.org Content-Type: multipart/alternative; boundary="------------030300080601070901050205" X-Mailman-Approved-At: Sun, 15 May 2011 07:58:20 -0700 Cc: draft-melnikov-pop3-over-tls@tools.ietf.org Subject: [TLS] Soliciting Comments on draft-melnikov-pop3-over-tls-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 10:47:34 -0000 This is a multi-part message in MIME format. --------------030300080601070901050205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, Alexey Melnikov an I have undertaken an attempt to document the POP3 over TLS binding (aka POP3S). The corresponding I-D is draft-melnikov-pop3-over-tls-00 can be found here: http://tools.ietf.org/html/draft-melnikov-pop3-over-tls-00 The draft replaces old draft-yevstifeyev-pops-uri-scheme (http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme-03) you should be aware of. The new document contains more detailed description of different issues concerning POP3S; however the main issue is TRANSACTION vs. AUTHORIZATION state after TLS handshake and the way of signaling it. I'd like to ask you to provide your comments on this draft, not limited to aforementioned issue only. Please, while responding, keep all recipient addresses in the message. Mykyta Yevstifeyev P.S. The most appropriate list for discussing this draft is certainly ietf-pop3ext, but I think it will be useful to direct the message to tls list in order to allow TLS experts review and comment it. Mykyta --------------030300080601070901050205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all,

Alexey Melnikov an I have undertaken an attempt to document the POP3 over TLS binding (aka POP3S).  The corresponding I-D is draft-melnikov-pop3-over-tls-00 can be found here:

http://tools.ietf.org/html/draft-melnikov-pop3-over-tls-00

The draft replaces old draft-yevstifeyev-pops-uri-scheme (http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme-03) you should be aware of.  The new document contains more detailed description of different issues concerning POP3S; however the main issue is TRANSACTION vs. AUTHORIZATION state after TLS handshake and the way of signaling it.

I'd like to ask you to provide your comments on this draft, not limited to aforementioned issue only.  Please, while responding, keep all recipient addresses in the message.

Mykyta Yevstifeyev

P.S.  The most appropriate list for discussing this draft is certainly ietf-pop3ext, but I think it will be useful to direct the message to tls list in order to allow TLS experts review and comment it.  Mykyta
 --------------030300080601070901050205-- From d.holmes@f5.com Sun May 15 20:45:55 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B43E0723 for ; Sun, 15 May 2011 20:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdFtx1m49rk7 for ; Sun, 15 May 2011 20:45:55 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.210.139]) by ietfa.amsl.com (Postfix) with ESMTP id E6DF4E071B for ; Sun, 15 May 2011 20:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=d.holmes@f5.com; q=dns/txt; s=seattle; t=1305517555; x=1337053555; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hBvn1zDbc/5NyXkJvfTlX3978+sv6rZ7RUT7zR+CDWA=; b=soA5rYEmP+grKcFtAAA2o0JcwDSekbbKYX9myUGpqdDutVpqS2yi5koU H6gzVrsmkhPerx/PGk1yTBvXMA7C4qdHswKz+hZOBxszH4hgMJKcY9OxP NUjUU2zuiHWBWOoETv6KwHKa/KYZzJ0noAAx2B428hld0GCUkYtHGWWAh 8=; X-IronPort-AV: E=Sophos;i="4.64,372,1301875200"; d="scan'208";a="27065997" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 16 May 2011 03:45:53 +0000 Received: from TKYEUM02.olympus.F5Net.com (192.168.15.127) by SEAECAS03.olympus.F5Net.com (192.168.16.222) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sun, 15 May 2011 20:45:52 -0700 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by tkyeum02.olympus.F5Net.com ([::1]) with mapi id 14.01.0289.001; Sun, 15 May 2011 20:45:52 -0700 From: David Holmes To: Paul Hoffman , "tls@ietf.org" Thread-Topic: [TLS] New draft for "next protocol" Thread-Index: AQHMEmdiZwkAgOQUW0GswwZjaghjS5SO0Bqw Date: Mon, 16 May 2011 03:45:51 +0000 Message-ID: <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com> References: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> In-Reply-To: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] New draft for "next protocol" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 16 May 2011 03:45:55 -0000 Very interesting! I had assumed that the "next-protocol" extension was to = inform the server (or proxy, or load-balancer) so that it could do better p= re-loading, caching or optimizing. I was surprised to see the extension de= scribed as a countermeasure for a cross-protocol attack. Can you describe in more detail how the extension works against an attacker= ? And let me apologize if this has already been discussed, I don't remembe= r seeing it on the mailing list. From agl@google.com Wed May 18 13:06:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212A0E0778 for ; Wed, 18 May 2011 13:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYp+QMRZfPKQ for ; Wed, 18 May 2011 13:06:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83DE0773 for ; Wed, 18 May 2011 13:06:38 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p4IK6awP016202 for ; Wed, 18 May 2011 13:06:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305749197; bh=2P+QytTBs31UZt1tmfCrJ6VNHaQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZMzo12ssEJvaw0kqiBgGENgyCZCC6cj3vul1mb7vQ/YDtoG/e6bAnztvEUZFS12OS t81WJaXwbJI+sZFV+S1Hw== Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by kpbe19.cbf.corp.google.com with ESMTP id p4IK4lli026409 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 May 2011 13:06:35 -0700 Received: by yxe42 with SMTP id 42so952482yxe.16 for ; Wed, 18 May 2011 13:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=poh0TJgmDlemlcoDXTsUMWrOLDna05jst0wmndHdgJw=; b=G7R84+yplGja4Ma3ZtKYqqyZaZr8KKWgsuCBgI5I4uUjsiUaptm/zlecMe5qKRJgk4 OL86LhNAvfpp8qDG+a4w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iaD3GRnCc34dFBbe12iGjxJa9c/L6t5IEaOMkEnOROyTZ6DwBKZ5HyglXlM8B/5MDz mGGcDz5OzPyTiGnK4Xgg== MIME-Version: 1.0 Received: by 10.150.48.28 with SMTP id v28mr1915183ybv.428.1305749195454; Wed, 18 May 2011 13:06:35 -0700 (PDT) Received: by 10.150.177.1 with HTTP; Wed, 18 May 2011 13:06:35 -0700 (PDT) In-Reply-To: <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com> References: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com> Date: Wed, 18 May 2011 13:06:35 -0700 Message-ID: From: Adam Langley To: David Holmes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] New draft for "next protocol" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 20:06:39 -0000 On Sun, May 15, 2011 at 8:45 PM, David Holmes wrote: > Can you describe in more detail how the extension works against an attack= er? =C2=A0And let me apologize if this has already been discussed, I don't = remember seeing it on the mailing list. Preventing cross-protocol attacks is one of several uses for NPN, although it is the one that is currently most highlighted in the draft. Previous versions of the websockets protocol have had to be reverted[1] because of cross-protocol attacks where an attacker creates confusion about which protocol is being used. As network transparency issues force many other protocols to support running over port 443 the risk of something bad resulting from the n^2 possible confusions keeps going up. NPN simply allows a client to state, unambiguously, which protocol is being spoken. [1] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html Cheers AGL From bsmith@mozilla.com Fri May 20 00:42:06 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACF1E06D1 for ; Fri, 20 May 2011 00:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MizOag-4h-X1 for ; Fri, 20 May 2011 00:42:06 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id F0986E06B2 for ; Fri, 20 May 2011 00:42:05 -0700 (PDT) Received: from mail.mozilla.com (zimbra1.shared.sjc1.mozilla.com [10.2.72.238]) by mail.mozilla.com (Postfix) with ESMTP id 677EFAE64683; Fri, 20 May 2011 00:42:05 -0700 (PDT) Date: Fri, 20 May 2011 00:42:05 -0700 (PDT) From: Brian Smith To: Joe Salowey Message-ID: <839369627.172106.1305877325353.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [173.13.181.177] X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661) Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 07:42:06 -0000 Joe Salowey wrote: > [Joe] Our security AD has requested that we tighten up the charter > such that significant changes to the protocol require a charter > update. We can certainly discuss the topics you raise without a > charter update. It may be possible to publish documents for some of > the things you want without a charter update. For other things, in > particular things that require significant change to the TLS state > machine or other aspects of the protocol we are going to have to go > through the process of updating the charter. This does not have to be > a heavyweight process, but it does require more review than just > adding a working group milestone. Since TLS is in widespread use in > all areas of the IETF this ensures there is some cross area review > before we initiate the work for a major change In the next couple of weeks, I could work on getting some drafts of extensions (and/or resurrect some old ones) that I would like to be considered on the standards track, which we (Mozilla and others) are likely to implement and deploy soon. At least two of these extensions do affect the state machine and most of the changes have already been discussed at length in the working group. I think this would be useful input for the decision of what to include in the initial revision of the charter, and would probably prevent some unnecessary future debates about it. Cheers, Brian From ekr@rtfm.com Mon May 23 06:19:08 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C07E07AC for ; Mon, 23 May 2011 06:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.925 X-Spam-Level: X-Spam-Status: No, score=-101.925 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq2X2nqfUFyb for ; Mon, 23 May 2011 06:19:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (unknown [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE05E079E for ; Mon, 23 May 2011 06:19:04 -0700 (PDT) Received: by iyn15 with SMTP id 15so6043735iyn.31 for ; Mon, 23 May 2011 06:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.136.197 with SMTP id v5mr9131480ict.513.1306156744158; Mon, 23 May 2011 06:19:04 -0700 (PDT) Received: by 10.42.239.7 with HTTP; Mon, 23 May 2011 06:19:04 -0700 (PDT) Date: Mon, 23 May 2011 06:19:04 -0700 Message-ID: From: Eric Rescorla To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Final (hopefully) issues with DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 13:19:08 -0000 Following up on Prague, here is the new text for the 2MSL and the record sequence number issues: MSL: 4.1. Note that because DTLS records may be reordered, a record from epoch 1 may be received after epoch 2 has begun. In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP [TCP] to allow for packet reordering. (Note: the intention here is that implementors use the current guidance from the IETF for MSL, not that they attempt to interrogate the MSL the system TCP stack is using.) Until the handshake has completed, implementations MUST accept packets from the old epoch. ... 4.2.4. In addition, for at least twice the default MSL defined for [TCP], when in the FINISHED state, the node which transmits the last flight (the server in an ordinary handshake or the client in a resumed handshake) MUST respond to a retransmit of the peer's last flight with a retransmit of the last flight. This avoids deadlock conditions Record Sequence Number: When responding to a HelloVerifyRequest the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as it did in the original ClientHello. The server SHOULD use those values to generate its cookie and verify that they are correct upon cookie receipt. The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. Upon receipt of the ServerHello, the client MUST verify that the server version values match. In order to avoid sequence number duplication in case of multiple HelloVerifyRequests, the server MUST use the record sequence number in the ClientHello as the record sequence number in the HelloVerifyRequest. ... When the second ClientHello is received, the server can verify that the Cookie is valid and that the client can receive packets at the given IP address. In order to avoid sequence number duplication in case of multiple cookie exchanges, the server SHOULD use the record sequence number in the ClientHello as the record sequence number in its initial ServerHello. Subsequent ServerHellos will only be sent after the server has created state and MUST increment normally. I believe this matches what I said in Prague, but any objections to this in concept or the way I've written it up. Finally, I've been rethinking the issue of the interaction of the ChangeCipherSpec and the handshake sequence numbers. In Prague I suggested not changing this and just putting a note in the spec that one had to be careful, but at this point I am thinking it might be better to simple suck up the change and put a message sequence number in the CCS. This removes the need to consult the handshake state machine in order to deal with reordering, though not in order to determine whether the CCS is at the appropriate place in the handshake (in order to detect misbehaving or malicious behavior early). The downside for this is that it's a difference from TLS, but it seems like fairly easy code--though I admit I haven't tried to code it up. I don't think either way represents a security issue, but doing it this way means that we won't need to be as careful in the future about having the state machine be completely deterministic prior to the CCS, which seems like the Right Thing. Comments? -Ekr From n.mavrogiannopoulos@gmail.com Mon May 23 07:35:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F9E0792 for ; Mon, 23 May 2011 07:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq+DW5EklqIZ for ; Mon, 23 May 2011 07:35:38 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 55D3AE077A for ; Mon, 23 May 2011 07:35:38 -0700 (PDT) Received: by wwk4 with SMTP id 4so1518826wwk.1 for ; Mon, 23 May 2011 07:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :openpgp:content-type:content-transfer-encoding; bh=O/YVI2iDmxjrOTv5wwmvBNA3fOF8Mq7leHVxfHZHb0M=; b=ApSfiM8AdYgxgrExBkpW5tJTEDkw7u9RbSgO1I+xvgSKU0h4gDerTgBuQc3cJI5R03 2yiA8S0SGF19tAdcX3lW+ftWhKg8g25Y9QMSlFp/zXbTcvTOu7hFCUyijv6lc6WS76qf 8eYQdEpoXhJXwPXOmQSQI616a/wX2Lg+bIYQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=V3pd00WvpStVfcF4gzkOEWL0QwgtekfyOxv1RheZkFeXSW8dlKH7/+ZGc7U+Ed1JAA Ex/PDcP7uzD+iis4TEHGYnwdVpZ9czfzFO9NG9hL10VoP8JYTHtl+g25C2yNyIRg1gG5 1iXyp1jSY4C2C+pIxYlaqLCc9FsxDrCkovoj8= Received: by 10.227.37.14 with SMTP id v14mr2344350wbd.25.1306161337051; Mon, 23 May 2011 07:35:37 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id l24sm4132661wbc.13.2011.05.23.07.35.34 (version=SSLv3 cipher=OTHER); Mon, 23 May 2011 07:35:35 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DDA70B6.9030203@gnutls.org> Date: Mon, 23 May 2011 16:35:34 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 14:35:45 -0000 On 05/23/2011 03:19 PM, Eric Rescorla wrote: Hello, > Record Sequence Number: When responding to a HelloVerifyRequest the > client MUST use the same parameter values (version, random, > session_id, cipher_suites, compression_method) as it did in the > original ClientHello. The server SHOULD use those values to generate > its cookie and verify that they are correct upon cookie receipt. The > server MUST use the same version number in the HelloVerifyRequest > that it would use when sending a ServerHello. Upon receipt of the > ServerHello, the client MUST verify that the server version values > match. In order to avoid What is the rationale of this restriction? Given my points in http://permalink.gmane.org/gmane.ietf.tls/8336 I believe interoperability will be harmed in the future as ciphersuites are being deprecated or restricted to certain protocols. > Finally, I've been rethinking the issue of the interaction of the > ChangeCipherSpec and the handshake sequence numbers. In Prague I > suggested not changing this and just putting a note in the spec that > one had to be careful, but at this point I am thinking it might be > better to simple suck up the change and put a message sequence > number in the CCS. This removes the need to consult the handshake > state machine in order to deal with reordering, though not in order > to determine whether the CCS is at the appropriate place in the > handshake (in order to detect misbehaving or malicious behavior > early). The downside for this is that it's a difference from TLS, > but it seems like fairly easy code--though I admit I haven't tried to > code it up. I don't think either way represents a security issue, but > doing it this way means that we won't need to be as careful in the > future about having the state machine be completely deterministic > prior to the CCS, which seems like the Right Thing. Comments? Which use-case are you trying to solve? Could an implementation solve it using another way (what being careful would mean?). A change like that to changecipherspec is not that trivial as it actually convert it from a signaling message to a handshake message (e.g. in my implementation changecipherspec is not parsed by the handshake layer). regards, Nikos From bsmith@mozilla.com Mon May 23 15:46:18 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2A8E06BA for ; Mon, 23 May 2011 15:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPUGDZ5Qz9JP for ; Mon, 23 May 2011 15:46:17 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id A31D8E0688 for ; Mon, 23 May 2011 15:46:17 -0700 (PDT) Received: from mail.mozilla.com (zimbra1.shared.sjc1.mozilla.com [10.2.72.238]) by mail.mozilla.com (Postfix) with ESMTP id ED5ADAE64672 for ; Mon, 23 May 2011 15:46:16 -0700 (PDT) Date: Mon, 23 May 2011 15:46:16 -0700 (PDT) From: Brian Smith To: tls@ietf.org Message-ID: <618342307.5601.1306190776733.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [63.245.220.240] X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661) Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 22:46:18 -0000 Eric Rescorla wrote: > Can you advise on which drafts you have in mind? 1. draft-pettersen-tls-ext-multiple-ocsp 2. http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00 (NPN) 3. An extension to move the client certificate message to be between its ChangeCipherSuite and Finished messages (next to the NPN message), to protect it. Hopefully we can resurrect one of the previous drafts that proposed to do this. 4. An explicit one-roundtrip False-Start(-like) full handshake. (Needs a new I-D.) We are planning to implement all of these extensions in Firefox. I believe that there are other major implementers that are planning to implement at least the first three. We may also implement the current TLS False Start mechanism, but I think it would be better to have an opt-in one-round-trip handshake mechanism. Such a mechanism would probably involve the client optimistically putting a ClientKeyExchange (probably formatted like a ServerKeyExchange) message in a ClientHello extension, so that the server can send its ChangeCipherSuite and Finished messages immediately after its ServerHelloDone message. Cheers, Brian From n.mavrogiannopoulos@gmail.com Mon May 23 23:49:59 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE6CE06CE for ; Mon, 23 May 2011 23:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2huIFVE0cRRL for ; Mon, 23 May 2011 23:49:58 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 97098E0662 for ; Mon, 23 May 2011 23:49:58 -0700 (PDT) Received: by pxi2 with SMTP id 2so3813104pxi.38 for ; Mon, 23 May 2011 23:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yX+cohlyd3QWuxCE19jCgGeq0nS8kqvKwBdiTCTfNOI=; b=U/00E35kMgDyXlMIUpTGZd17kPkf0EtbpN20SymXRoO+emCssi7aDbumeCFnNnwEXJ izxZMjaSP5b2Xxy+j5rM7SowxJlaUNcj+F1f+sUDRNNHXhhQSDTV92vbEHGv+IG5+/oQ mH4rnJ5YFQMgGXrK2dyfS/4aVfBI86eqepm50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ljfWCIvYzWNi+WJ30b4fP2W192qo3OQEzKleEpGen8iS2f+CqLmXSjOektPNT+zvhP lfeM5rk0prGJGfHgLLrAFu0dWWQ5WWc35YGf+NmxB1tOumfAyhmvtRgwV9wmK8FTgOjW CtwG5Mr2QoHciTxV6Dx0p2EiP2IT7yuvUNyBM= MIME-Version: 1.0 Received: by 10.142.215.18 with SMTP id n18mr980524wfg.332.1306219798201; Mon, 23 May 2011 23:49:58 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.142.245.11 with HTTP; Mon, 23 May 2011 23:49:58 -0700 (PDT) In-Reply-To: <618342307.5601.1306190776733.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <618342307.5601.1306190776733.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Date: Tue, 24 May 2011 08:49:58 +0200 X-Google-Sender-Auth: mOvHkv91PHyekkUmb7spCFInhLQ Message-ID: From: Nikos Mavrogiannopoulos To: Brian Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 06:49:59 -0000 On Tue, May 24, 2011 at 12:46 AM, Brian Smith wrote: > We may also implement the current TLS False Start mechanism, but I think = it would be better to have an opt-in one-round-trip handshake mechanism. Su= ch a mechanism would probably involve the client optimistically putting a C= lientKeyExchange (probably formatted like a ServerKeyExchange) message in a= ClientHello extension, so that the server can send its ChangeCipherSuite a= nd Finished messages immediately after its ServerHelloDone message. Kerberos PKINIT does something similar to that. I found few attacks on that approach when using smart-cards: http://old.nabble.com/-Ietf-krb-wg--PKINIT-with-smart-cards-td31578223.html Being conservative in design (as TLS does) pays off. regards, Nikos From mrex@sap.com Tue May 24 10:54:24 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC69E078F for ; Tue, 24 May 2011 10:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l09S-AeUwxfN for ; Tue, 24 May 2011 10:54:24 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D2AA9E073A for ; Tue, 24 May 2011 10:54:23 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p4OHsLUJ018419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2011 19:54:21 +0200 (MEST) From: Martin Rex Message-Id: <201105241754.p4OHsKM1012733@fs4113.wdf.sap.corp> To: bsmith@mozilla.com (Brian Smith) Date: Tue, 24 May 2011 19:54:20 +0200 (MEST) In-Reply-To: <618342307.5601.1306190776733.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> from "Brian Smith" at May 23, 11 03:46:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:54:24 -0000 Brian Smith wrote: > > 3. An extension to move the client certificate message to be between > its ChangeCipherSuite and Finished messages (next to the NPN message), > to protect it. Hopefully we can resurrect one of the previous drafts > that proposed to do this. What about the CertificateVerify handshake message? In the original TLS handshake, the handshake message hash that goes into CertificateVerify covers the client's Certificate (handshake message), and I think that is an important property. Looking at the existing TLS handshake: http://tools.ietf.org/html/rfc5246#page-36 I thought about just exhanging the Certificate and ClientKeyExchange handshake messages, to be able to compute the MasterSecret before composing the client's Certificate handshake message. Being able to compute the master secret is a prerequisite to being able to protect (at least part of the contents of) the client's Certificate handshake message. However, moving the handshake past ChangeCipherSpec as you suggest, would have the advantage that protection of (at least part of the contents of handshake messages) would continue to use only the existing record layer logic. > > 4. An explicit one-roundtrip False-Start(-like) full handshake. > (Needs a new I-D.) Personally, I see a need for something in the opposite direction. While Browser vendors seem not have an issue with doing reconnect fallbacks with feature-reduced ClientHellos after handshake failures and caching such meta-information on a per-destination basis, I'm much more worried about the server and the programmatic client situations, where failed handshakes, feature-reduced reconnect fallbacks and having to cache meta-information on a per-destination basis are no-goes. I'm much more interested in a reliable negotiation, and I would NOT mind an extra round-trip (crypto-free restart of ClientHello), because >95% of the connects are going to be TLS session resumes anyway, so that an additional round-trip on initial handshakes really does not matter, and is significantly less of a problem than failed full handshakes, because the latter have a huge impact on the application callers, whereas an additional round-trip to obtain a sensible negotiation would be completely transparent/invisible for the application caller. With the migration from 1024-bit RSA to 2048-bit RSA server certificates I'm noticing a signficant performance impact on RSA private key operations. The public key operation is fairly cheap due to the convenient use of e.g. Fermat-4 (0x10001) for the public modulus, But for private key operations I am noticing a 8x performance impact, from 3-5ms for 1024 bit to 25-40ms for 2048 bit. -Martin From turners@ieca.com Wed May 25 17:11:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D45EE0709 for ; Wed, 25 May 2011 17:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF41pK6aSoAV for ; Wed, 25 May 2011 17:11:23 -0700 (PDT) Received: from nm21-vm0.bullet.mail.sp2.yahoo.com (nm21-vm0.bullet.mail.sp2.yahoo.com [98.139.91.220]) by ietfa.amsl.com (Postfix) with SMTP id 1BE95E0680 for ; Wed, 25 May 2011 17:11:23 -0700 (PDT) Received: from [98.139.91.67] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 26 May 2011 00:11:23 -0000 Received: from [98.139.91.43] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 26 May 2011 00:11:23 -0000 Received: from [127.0.0.1] by omp1043.mail.sp2.yahoo.com with NNFMP; 26 May 2011 00:11:23 -0000 X-Yahoo-Newman-Id: 51820.62757.bm@omp1043.mail.sp2.yahoo.com Received: (qmail 25056 invoked from network); 26 May 2011 00:11:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306368683; bh=sA7rlritJoNnlJ3jTxNbCF1uSY5IYEeCJ7KAXEUh3aA=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=6oa3hEQR9ltjmCHWyoNjjDjWQbfIfpaKOz6b6euaDbroppP/yPI6aAz524iWlLWXEPItbFvawGMub3Qb7C7uw0ZZzscxmIBNJ0vKJ+cHqySMPPN6otdq7xwYKWpw6c9R+yx/Ig1x7btSGNcb1HI9Q9zkIqX2y1QqjOaWFxzHiCY= Received: from thunderfish.local (turners@96.241.2.203 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 25 May 2011 17:11:22 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: zQBUJLcVM1lMghCPze0T9yzrQphdS7ccrwkxs8egFVIjhcr j5tB_wmik58ZCa8L4Bz6VWS3qZ3Ly8olK9tuI.iSUsEm5fKIUd7LuDfQCXri E2C0IslVCFnDYRsrYHfGHIh.y1vu84bcWUxjS5qdgnDsXlmBNrkCv7W2y0MX OHYvFMlg.LlhIRs.PNNbW4rLIkJwiPwvGplocQ69qCmdLosg5EmdcQucxZ15 3B_7Txj9co9.m3.U4li0bRIsHk8cOJDITlATIKhF1cz8hDygOoTyQ204tTFN 19o1pEG1i9M37eS1fGjnZ6Bxoknat6qlwrB.oVYA.2V7ZZK5fdIgvSndnHQQ pqfUu2i3bnB4PtG7xjRd0jPrGvG9_YDqwwhDIGiKBxAk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DDD9AA8.5000603@ieca.com> Date: Wed, 25 May 2011 20:11:20 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: tls@ietf.org References: <839369627.172106.1305877325353.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> In-Reply-To: <839369627.172106.1305877325353.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 00:11:26 -0000 On 5/20/11 3:42 AM, Brian Smith wrote: > Joe Salowey wrote: >> [Joe] Our security AD has requested that we tighten up the charter >> such that significant changes to the protocol require a charter >> update. We can certainly discuss the topics you raise without a >> charter update. It may be possible to publish documents for some of >> the things you want without a charter update. For other things, in >> particular things that require significant change to the TLS state >> machine or other aspects of the protocol we are going to have to go >> through the process of updating the charter. This does not have to be >> a heavyweight process, but it does require more review than just >> adding a working group milestone. Since TLS is in widespread use in >> all areas of the IETF this ensures there is some cross area review >> before we initiate the work for a major change > > In the next couple of weeks, I could work on getting some drafts of extensions (and/or resurrect some old ones) that I would like to be considered on the standards track, which we (Mozilla and others) are likely to implement and deploy soon. At least two of these extensions do affect the state machine and most of the changes have already been discussed at length in the working group. I think this would be useful input for the decision of what to include in the initial revision of the charter, and would probably prevent some unnecessary future debates about it. I wanted to give everybody a heads up that I put the charter text Joe sent around on the telechat for tomorrow. The current charter is really out of date and needs to be updated ASAP. If the WG decides to adopt the items suggested by Brian then we can update the charter again (some WGs update their charters every time they finish a certain a draft). Getting a charter through the IESG is not necessarily hard. It can happen in a short time (like two weeks). How long it takes to agree on the text to submit to the IESG is anybody's guess. spt From matt@mattmccutchen.net Thu May 26 09:29:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B43E068D for ; Thu, 26 May 2011 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giMD3TSmyDzH for ; Thu, 26 May 2011 09:29:44 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id B029CE0655 for ; Thu, 26 May 2011 09:29:44 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id DFED7578073; Thu, 26 May 2011 09:29:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=VIt9O3Ng8HOM9rVi0Vf1hNTKJO/KvudYOAdb7SQnR3U hawKxAM8alo5Jyev+sXuNHcxYpxmEQgFjLNYSggwZ1xOOQ/WCSsaWQn345MSsIqV fmCWsxXFxdkd63NyAd4XAfemXTBp8CAiiZPpnI2tM85QGNGu4GD2LPI3o4P9JmuE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=T4NCE6Q/4MENaZghOh2hdK/1GyQ=; b=KBdP3h+DKa XDgx/ad3uEYj79E316ZtDAap8nUV9QxlbgsP+0mij/XcrdkGsc4wUhLI7O4zjf7V 8a/nobWEyOkPxxDx17ztEhFfKLIAt4cfVSUQLgYFKSBE1cQ+ELh79j2B38nt+pst QZpz1f2MelBEhnOFBQ4RR9Fgs9VIFaFDY= Received: from [192.168.1.40] (pool-74-96-131-21.washdc.east.verizon.net [74.96.131.21]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 539D9578059; Thu, 26 May 2011 09:29:43 -0700 (PDT) From: Matt McCutchen To: Adam Langley In-Reply-To: References: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 May 2011 12:29:40 -0400 Message-ID: <1306427380.4099.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] New draft for "next protocol" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:29:45 -0000 On Wed, 2011-05-18 at 13:06 -0700, Adam Langley wrote: > As network > transparency issues force many other protocols to support running over > port 443 And when the firewalls start filtering based on the NPN extension, we will be back to square one. -- Matt From agl@google.com Sun May 29 07:18:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5904EE06F5 for ; Sun, 29 May 2011 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tZG6aAPGr2u for ; Sun, 29 May 2011 07:18:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6639AE0662 for ; Sun, 29 May 2011 07:18:00 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p4TEHw0t007378 for ; Sun, 29 May 2011 07:17:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306678679; bh=jjF6CO5wE7Y52ioPwvrM023js0k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=guFCkFUoTif+v1VQrVKrJBNQTzNU+QQ0853bdtmo+Rc++q+5w1C6dP+CHz9Lr0gz4 dqdAypbdp+bF8hWIAvQBw== Received: from gyh20 (gyh20.prod.google.com [10.243.50.212]) by kpbe18.cbf.corp.google.com with ESMTP id p4TEHu2Z007937 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 29 May 2011 07:17:57 -0700 Received: by gyh20 with SMTP id 20so1904953gyh.22 for ; Sun, 29 May 2011 07:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ViFMlddKAM2E7vFGRzvh6X1623liAW5QxJmPMFH/mOg=; b=bHbS3cYKRT41b3UdukR+sD45vSI8BjRXrdK6tTkcS/OrOj/PE4fronIK2hugO2+6qz B6jWRhNuhXevRrYXx7gQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xi/LHMmCQIX53HNqAj8GqP81ypCh/vWuRi0qws0/hS4FdJKbmAPQcYygT58YM4QK49 9QySOgy/7VPkldg+VQbA== MIME-Version: 1.0 Received: by 10.151.154.8 with SMTP id g8mr3651188ybo.29.1306678676810; Sun, 29 May 2011 07:17:56 -0700 (PDT) Received: by 10.150.177.1 with HTTP; Sun, 29 May 2011 07:17:56 -0700 (PDT) In-Reply-To: <1306427380.4099.18.camel@localhost> References: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com> <1306427380.4099.18.camel@localhost> Date: Sun, 29 May 2011 10:17:56 -0400 Message-ID: From: Adam Langley To: Matt McCutchen Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "tls@ietf.org" Subject: Re: [TLS] New draft for "next protocol" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 29 May 2011 14:18:01 -0000 On Thu, May 26, 2011 at 12:29 PM, Matt McCutchen wrote: > And when the firewalls start filtering based on the NPN extension, we > will be back to square one. Firewalls could filter on a) the presence of nextproto in the ClientHello or b) the protocols in the ServerHello. Since Chrome already sends the nextproto extension, filtering that is hopefully too destructive. b) might become an issue, but that's why the client is free to pick a protocol that wasn't advertised by the server if it has out-of-band knowledge that the server will support it. The client's choice is deliberately sent under encryption and in constant space in order to protect it from filtering. AGL From ekr@rtfm.com Mon May 30 08:38:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBBAE07ED for ; Mon, 30 May 2011 08:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVXpnZWZiZaJ for ; Mon, 30 May 2011 08:38:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73996E07E7 for ; Mon, 30 May 2011 08:38:42 -0700 (PDT) Received: by wyb29 with SMTP id 29so3190661wyb.31 for ; Mon, 30 May 2011 08:38:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.232.23 with SMTP id m23mr4953445weq.26.1306769921510; Mon, 30 May 2011 08:38:41 -0700 (PDT) Received: by 10.216.161.147 with HTTP; Mon, 30 May 2011 08:38:41 -0700 (PDT) In-Reply-To: <4DDA70B6.9030203@gnutls.org> References: <4DDA70B6.9030203@gnutls.org> Date: Mon, 30 May 2011 08:38:41 -0700 Message-ID: From: Eric Rescorla To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 30 May 2011 15:38:44 -0000 On Mon, May 23, 2011 at 7:35 AM, Nikos Mavrogiannopoulos wrote: > On 05/23/2011 03:19 PM, Eric Rescorla wrote: > > Hello, > >> Record Sequence Number: When responding to a HelloVerifyRequest the >> client MUST use the same parameter values (version, random, >> session_id, cipher_suites, compression_method) as it did in the >> original ClientHello. =A0The server SHOULD use those values to generate >> its cookie and verify that they are correct upon cookie receipt. =A0The >> server MUST use the same version number in the HelloVerifyRequest >> that it would use when sending a ServerHello. Upon receipt of the >> ServerHello, the client MUST verify that the server version values >> match. In order to avoid > > What is the rationale of this restriction? Given my points in > http://permalink.gmane.org/gmane.ietf.tls/8336 > I believe interoperability will be harmed in the future as ciphersuites > are being deprecated or restricted to certain protocols. I'm not sure I'm following this concern. The effect of this restriction is to require the client to send the same ClientHello (except with the cookie that he sent initially). This maps to the TLS seman= tics where there is only a single ClientHello message sent which is processed immediately. IMO this makes analysis easier since it makes DTLS behave more like TLS. There's no need for the server to do any negotiation at this point, it should simply generate a HelloVerifyRequest with the highest matching version (regardless of cipher suite considerations) and then process the ClientHello de novo [after checking for matching parameters.] Yes, this lea= ves open the possibility that the handshake will eventually negotiate to some y= et lower TLS version, but that's what happens in one round trip with TLS. I would be happy to add a note to the effect that a yet lower version might be negotiated. Though note that it's arguable that RFC 5246 S 7.4.1.3 prohibits conditioning version on ciphersuite even for TLS "This field will contain the lower of that suggested by the client in the client hello and the highest supported by the server. For this version of the specification, the version is 3.3. (See Appendix E for details about backward compatibility.)" >> Finally, I've been rethinking the issue of the interaction of the >> ChangeCipherSpec and the handshake sequence numbers. In Prague I >> suggested not changing this and just putting a note in the spec that >> one had to be careful, but at this point I am thinking it might be >> better to simple suck up the change and put a message sequence >> number in the CCS. This removes the need to consult the handshake >> state machine in order to deal with reordering, though not in order >> to determine whether the CCS is at the appropriate place in the >> handshake (in order to detect misbehaving or malicious behavior >> early). =A0The downside for this is that it's a difference from TLS, >> but it seems like fairly easy code--though I admit I haven't tried to >> code it up. I don't think either way represents a security issue, but >> doing it this way means that we won't need to be as careful in the >> future about having the state machine be completely deterministic >> prior to the CCS, which seems like the Right Thing. Comments? > > Which use-case are you trying to solve? Could an implementation solve > it using another way (what being careful would mean?). It's less an implementation issue than a spec issue. Currently the order of the handshake messages vis-a-vis the CCS is deterministic, i.e., that you know in advance what set of handshake messages you ought to have received before receiving the CCS. However, if future specs were to break this invariant, then you would be left in a position where you had the CCS but weren't sure if you were expecting another handshake message, so couldn't necessarily process the CCS. > A change like that to changecipherspec is not that trivial as it > actually convert it from a signaling message to a handshake message > (e.g. in my implementation changecipherspec is not parsed by the > handshake layer). Yes, I realize this isn't great. IMO it was a mistake for the CCS not to be a handshake message, but we can't really fix that.... we're left with trying to determine the lesser of two evils. Best, -Ekr From fweimer@bfk.de Tue May 31 00:03:56 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FA1E0798 for ; Tue, 31 May 2011 00:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78xqeCKO934z for ; Tue, 31 May 2011 00:03:55 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA89E068B for ; Tue, 31 May 2011 00:03:55 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QRIzO-0003sX-EV; Tue, 31 May 2011 07:03:48 +0000 Received: by bfk.de with local id 1QRIz2-0005r8-Tf; Tue, 31 May 2011 07:03:20 +0000 From: Florian Weimer To: Adam Langley References: <24ADE5FF-FDEE-493E-A00A-F6C5F274A7C3@vpnc.org> <4851D6E10A7F63448F4B32C3E2814AC91772C79D@SEAEMBX02.olympus.F5Net.com> Date: Tue, 31 May 2011 07:03:20 +0000 In-Reply-To: (Adam Langley's message of "Wed, 18 May 2011 13:06:35 -0700") Message-ID: <82tycbs66f.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] New draft for "next protocol" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 31 May 2011 07:03:56 -0000 * Adam Langley: > Previous versions of the websockets protocol have had to be > reverted[1] because of cross-protocol attacks where an attacker > creates confusion about which protocol is being used. Are you sure that analysis was correct? I'm reasonably certain that it's not. In other words, you got punked. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From wwwrun@ietfa.amsl.com Tue May 31 09:55:54 2011 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id D5E8BE0806; Tue, 31 May 2011 09:55:54 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110531165554.D5E8BE0806@ietfa.amsl.com> Date: Tue, 31 May 2011 09:55:54 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] WG Action: RECHARTER: Transport Layer Security (tls) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 31 May 2011 16:55:54 -0000 The Transport Layer Security (tls) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Transport Layer Security (tls) ---------------------------------- Current Status: Active Working Group Last modified: 2011-05-19 Current status: Active Working Group Chairs: Eric Rescorla Joseph Salowey Area Director: Sean Turner Tech Advisor: Allison Mankin Mailing List Address: tls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: http://www.ietf.org/mail-archive/web/tls/ Description of Working Group The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0, 1.1, and 1.2, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goals of the WG are to maintain: - The TLS protocol, RFC 5246; - The DTLS protocol, draft-ietf-tls-rfc4347-bis. Significant changes to the protocol, such as a new version 1.3, are not within scope of the working group unless they are explicitly added to the charter. The secondary goals of the WG are to publish: - Guidelines for Specifying the Use of TLS/DTLS; - Recommendations for use of TLS (e.g., server ID); - Extensions to TLS and DTLS; and, - Cipher suites. Goals and Milestones Dec 2011 - Heartbeat Extension Sent to IESG