From mailman-bounces@ietf.org Wed Sep 1 10:00:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08882 for ; Wed, 1 Sep 2004 09:37:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2RTO-0005pa-2k for tls-archive@ietf.org; Wed, 01 Sep 2004 05:32:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2R0U-000753-05 for tls-archive@ietf.org; Wed, 01 Sep 2004 05:02:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tls-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Sep 2004 05:00:31 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for tls-archive@ietf.org: List Password // URL ---- -------- tls@lists.ietf.org akviiw https://www1.ietf.org/mailman/options/tls/tls-archive%40ietf.org From tls-bounces@ietf.org Mon Sep 6 23:29:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26232; Mon, 6 Sep 2004 23:29:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4Wii-00021h-25; Mon, 06 Sep 2004 23:32:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Wdt-0002hP-N4; Mon, 06 Sep 2004 23:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4Wb3-0002I6-A0 for tls@megatron.ietf.org; Mon, 06 Sep 2004 23:24:41 -0400 Received: from win.lh.vix.com (win.lh.vix.com [204.152.188.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25959 for ; Mon, 6 Sep 2004 23:24:38 -0400 (EDT) Received: from deimos.treese.org (h0040100cc755.ne.client2.attbi.com [24.91.127.132]) (authenticated) by win.lh.vix.com (8.11.6/8.11.6) with ESMTP id i875c3W12834 for ; Tue, 7 Sep 2004 01:38:03 -0400 Received: from localhost (localhost [127.0.0.1]) by deimos.treese.org (Postfix) with ESMTP id A01001D4129 for ; Mon, 6 Sep 2004 23:24:03 -0400 (EDT) To: tls@ietf.org From: Win Treese X-Mailer: MH-E 7.4.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 06 Sep 2004 23:24:03 -0400 Message-Id: <20040907032403.A01001D4129@deimos.treese.org> Subject: [TLS] Test of new TLS mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 This is a test of the new TLS mailing list. Please ignore. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Sep 7 01:50:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05252; Tue, 7 Sep 2004 01:50:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4YvG-0004R8-Tq; Tue, 07 Sep 2004 01:53:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4YpO-0000fl-7i; Tue, 07 Sep 2004 01:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4YgR-0007Hh-E1 for tls@megatron.ietf.org; Tue, 07 Sep 2004 01:38:23 -0400 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03898 for ; Tue, 7 Sep 2004 01:38:21 -0400 (EDT) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 6 Sep 2004 22:37:47 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Sep 2004 22:37:56 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Sep 2004 22:37:31 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 6 Sep 2004 22:36:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Sep 2004 22:37:50 -0700 Message-ID: <077993C42708BA438E9013BB10111C8207360146@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Comments on the TLS 1.1 draft thread-index: AcSTJ3wqoGE9IWUOT/aeLrL0eWRJzQBc0SGA From: "John Banes" To: X-OriginalArrivalTime: 07 Sep 2004 05:36:44.0132 (UTC) FILETIME=[A8D16240:01C4949C] Content-Transfer-Encoding: quoted-printable Subject: [TLS] RE: Comments on the TLS 1.1 draft X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Adding mention of the AES cipher suites to the TLS 1.1 specification sounds like a good idea to me. I suspect that market forces will encourage most people implementing TLS 1.1 to add support for some subset of the AES cipher suites. This leads me to wonder why the TLS 1.1 specification still lists the legacy 40-bit and 56-bit cipher suites. I would expect that any reasonable TLS 1.1 implementation would forsake these low-encryption-strength cipher suites. About the only reason to support these that I can think of is for backward compatibility, and if the client and server manage to negotiate TLS 1.1, then backward compatibility obviously isn't an issue. If using a 40-bit or 56-bit cipher suite becomes necessary, then I would expect the TLS implementation to fall back to TLS 1.0 or even SSL 3.0. Regards, John -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Sunday, September 05, 2004 2:06 AM To: ietf-tls@lists.certicom.com Subject: Comments on the TLS 1.1 draft Given that this is probably my last chance to gripe about things: Section 6.2.1 says: Application data is generally of lower precedence for transmission than other content types and therefore handshake records may be held if application data is pending. Wouldn't application data be of higher precedence if it can pre-empt handshake data? Section 6.3, this is somewhat misleading, the cipher spec that requires the most key material isn't 3DES_EDE_CBC_SHA but AES_256_CBC_SHA, even if it's defined elsewhere. (Shouldn't the RFC 3268 suites be folded into the TLS 1.1 spec? It seems like a good idea to have them all in the same document, at the moment TLS 1.1 doesn't even hint that there are AES suites, and in particular suites that actually require more keying material than 3DES_EDE_CBC_SHA). More section 6.3: The mention of IV generation for < TLS 1.1 has been completely excised, apart from a passing mention elsewhere that explicit IVs are new for TLS 1.1. Shouldn't there be some mention of this somewhere, either in section 6.3 or in an appendix? There are various historical notes covering older usage (e.g. the lack of a length field in RSA encrypted data in SSLv3), but the only way to find out about previous IV usage is to dig up old copies of the spec. Note that this change also applies to the keying-material note, since with the additional implicit IV data the size increases still further. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Sep 7 03:21:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25694; Tue, 7 Sep 2004 03:21:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4aLF-00061G-Gi; Tue, 07 Sep 2004 03:24:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4aFt-000591-Pm; Tue, 07 Sep 2004 03:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4a5F-0003Y2-EA for tls@megatron.ietf.org; Tue, 07 Sep 2004 03:08:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24431 for ; Tue, 7 Sep 2004 03:08:03 -0400 (EDT) Received: from mailhost.auckland.ac.nz ([130.216.190.13] helo=smtpc.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4a8c-0005f7-5I for tls@ietf.org; Tue, 07 Sep 2004 03:11:35 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 2F8303417C; Tue, 7 Sep 2004 19:07:30 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16184-10; Tue, 7 Sep 2004 19:07:30 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id EAE5533ED6; Tue, 7 Sep 2004 19:07:29 +1200 (NZST) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 01D1437745; Tue, 7 Sep 2004 19:07:29 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1C4a4l-0001fN-00; Tue, 07 Sep 2004 19:07:35 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jbanes@windows.microsoft.com, tls@ietf.org Subject: Re: [TLS] RE: Comments on the TLS 1.1 draft In-Reply-To: <077993C42708BA438E9013BB10111C8207360146@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Message-Id: Date: Tue, 07 Sep 2004 19:07:35 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 "John Banes" writes: >This leads me to wonder why the TLS 1.1 specification still lists the legacy >40-bit and 56-bit cipher suites. I would expect that any reasonable TLS 1.1 >implementation would forsake these low-encryption-strength cipher suites. You need to maintain at least one crippled-crypto suite in the handshake as a canary for older crippled-crypto versions of IIS, which simply drop the connection (without sending an alert) if they get a hello containing only non- crippled suites. If you get the canary back, you know that you're talking to IIS and can display an appropriate warning to the user. (It probably isn't worth retaining crippled suites in the spec for this, just thought I'd mention it as an FYI). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Sep 15 22:01:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03625; Wed, 15 Sep 2004 22:01:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7lfZ-0002oY-7b; Wed, 15 Sep 2004 22:06:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7lWO-0006ez-DA; Wed, 15 Sep 2004 21:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7lPJ-0005eS-53 for tls@megatron.ietf.org; Wed, 15 Sep 2004 21:49:57 -0400 Received: from abraham.cs.berkeley.edu (abraham.CS.Berkeley.EDU [128.32.37.170]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02804 for ; Wed, 15 Sep 2004 21:49:54 -0400 (EDT) Received: from news by abraham.cs.berkeley.edu with local (Exim 4.41) id 1C7lO9-0004GL-Pg for tls@lists.ietf.org; Wed, 15 Sep 2004 18:48:45 -0700 To: tls@ietf.org Path: not-for-mail From: daw@taverner.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-tls Date: Thu, 16 Sep 2004 01:48:45 +0000 (UTC) Organization: University of California, Berkeley Lines: 27 Distribution: isaac Message-ID: References: <125EA890549C8641A72F3809CB80DCCD17834A@esebe056.ntc.nokia.com> <4148A331.8010701@sun.com> NNTP-Posting-Host: taverner.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1095299325 16231 128.32.168.222 (16 Sep 2004 01:48:45 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Thu, 16 Sep 2004 01:48:45 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: daw@taverner.cs.berkeley.edu (David Wagner) Subject: [TLS] Re: Moving forward on draft-ietf-tls-ecc-* X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wagner List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Eric Rescorla wrote: >I'm not disputing these performance numbers, but I think they >rather miss the point. > >There are really two common scenarios in which SSL/TLS is used: >(1) PC client (fast client, fast server) >(2) Handheld client (flow client, fast server) >[...] the party who benefits from ECC is the server. However, this >is not a particularly interesting optimization [...] Well, I don't know. I'm not so sure about this. I won't argue with you about TLS-HTTP (though I'm not convinced that there are no benefits for TLS-HTTP: if you can do in software what would otherwise require a hardware accelerator, that might be a benefit). However, TLS is more than just a way of securing web traffic, and I think the analysis changes when you look at applications other than TLS. When people come to me asking for some way to build a secure channel for use in their custom application, I like to point them to TLS as the canonical way to do it (rather than rolling their own scheme). Many of these custom applications could benefit from something like ECC. If TLS is intended as a general protocol for transport layer security, I don't think it is accurate to say that there is no benefit from ECC. That said, I don't claim to know what the threshold should be for adding new schemes like ECC to TLS, so I'm not making any strong arguments here. P.S. I hope this makes it through the anti-spam filtering. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Sep 16 11:09:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18382; Thu, 16 Sep 2004 11:09:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7xy4-0002Tw-Gh; Thu, 16 Sep 2004 11:14:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7xpm-0003EW-24; Thu, 16 Sep 2004 11:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7xjt-00024g-B5 for tls@megatron.ietf.org; Thu, 16 Sep 2004 11:00:01 -0400 Received: from ray.idi.ntnu.no (ray.idi.ntnu.no [129.241.107.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17736 for ; Thu, 16 Sep 2004 10:59:57 -0400 (EDT) Received: from vier.idi.ntnu.no (vier.idi.ntnu.no [129.241.107.65]) by ray.idi.ntnu.no (8.12.10/8.12.10) with ESMTP id i8GExu4a001413 for ; Thu, 16 Sep 2004 16:59:56 +0200 (MEST) Received: (from josteitv@localhost) by vier.idi.ntnu.no (8.12.10/8.12.9/Submit) id i8GExoK4018086; Thu, 16 Sep 2004 16:59:50 +0200 (MEST) X-Authentication-Warning: vier.idi.ntnu.no: josteitv set sender to Jostein.Tveit@idi.ntnu.no using -f To: tls@ietf.org References: <006301c49bec$403a82a0$6f64a8c0@india.gric.com> From: Jostein Tveit Organization: Norwegian University of Science and Technology Date: Thu, 16 Sep 2004 16:59:50 +0200 In-Reply-To: <006301c49bec$403a82a0$6f64a8c0@india.gric.com> (Avinash Agarwal's message of "Thu, 16 Sep 2004 05:54:02 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=-3.4 required=1 X-Virus-Scanned: by amavisd-new-IDI Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA17736 Subject: [TLS] Re: TLS application data MAC query X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Avinash Agarwal writes: > The rfc (2246) says at =A7 F.2 "protecting application data"=20 > "Outgoing data is protected with a MAC before transmission. To prevent=20 > message replay or modification attacks, the MAC is computed from the= =20 > MAC secret, the sequence number, the message length, the message=20 > contents, and two fixed character strings."=20 > > What are the "two fixed character strings"?=20 That is probably a cut and paste error from the SSL3 standard. SSL3 had a slightly different MAC computation, using two fixed padding strings. See 5.2.3.1 in the SSL3 spec. --=20 Jostein Tveit (Jostein.Tveit@idi.ntnu.no) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Sep 28 01:31:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13258; Tue, 28 Sep 2004 01:31:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCAiJ-0001eX-OL; Tue, 28 Sep 2004 01:39:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCAYY-00084j-LH; Tue, 28 Sep 2004 01:29:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCAXW-0007um-Cz for tls@megatron.ietf.org; Tue, 28 Sep 2004 01:28:38 -0400 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13017 for ; Tue, 28 Sep 2004 01:28:37 -0400 (EDT) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CCAXS-0003tw-00; Tue, 28 Sep 2004 07:28:34 +0200 Received: from [128.32.153.61] (helo=tau.local) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1CCAXS-0004SC-00; Tue, 28 Sep 2004 07:28:34 +0200 Received: by tau.local (Postfix, from userid 500) id 9BFBD2B8EB; Mon, 27 Sep 2004 22:25:48 -0700 (PDT) Date: Mon, 27 Sep 2004 22:25:48 -0700 From: Bodo Moeller To: tls@ietf.org Message-ID: <4158E3CE.5090200@eecs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:2100a517a32aea841b51dac1f7c5a318 Subject: [TLS] Re: Moving forward on draft-ietf-tls-ecc-* X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Eric Rescorla wrote: >There are really two common scenarios in which SSL/TLS is used: > >(1) PC client (fast client, fast server) >(2) Handheld client (flow client, fast server) > >In either situation, the vast majority of connections involve >anonymous clients and authenticated servers. > >So, the cost matrix looks like this: > > Client Server >----------------------------------------------- >RSA | 2 pubkey ops 1 private key op >ECC | ECDSA vfy + ECDH ECDH > >Now, RSA public key ops are MUCH faster (a factor of 2-3 on your >8-bit platforms) than ECDSA verifies or ECDH operations. >This is basically a no-op in the PC client case because the >client is so fast anyway, but in the Handheld client case, >it's a big lose for ECC. > >Because ECDH is much faster than an RSA private key operation, >the party who benefits from ECC is the server. This comparison assumes that you don't care about forward secrecy (i.e. keeping encrypted application data secret against adversaries who recover the secret keys corresponding to the server certificate after the communication has taken place). Sometimes this might be adequate, but usually it is just a bad compromise -- a common scenario indeed, but we shouldn't be too happy about this state of affairs. If we consider forward secrecy, the comparison will have to involve ECDH vs. DH. The ECC TLS draft also provides for ephemeral ECDH with RSA certificates because of the advantages of RSA signatures -- faster verification, and wide-spread deployment. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Sep 28 09:49:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22751; Tue, 28 Sep 2004 09:49:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCIUR-0001iH-7C; Tue, 28 Sep 2004 09:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCIGl-0006Hj-5b; Tue, 28 Sep 2004 09:43:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCIFY-00062f-9U for tls@megatron.ietf.org; Tue, 28 Sep 2004 09:42:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22405 for ; Tue, 28 Sep 2004 09:42:34 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCINN-0001af-Ul for tls@ietf.org; Tue, 28 Sep 2004 09:50:42 -0400 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 8AEB37185; Tue, 28 Sep 2004 06:56:42 -0700 (PDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id 62D7344AE7; Tue, 28 Sep 2004 06:41:55 -0700 (PDT) To: Bodo Moeller Subject: Re: [TLS] Re: Moving forward on draft-ietf-tls-ecc-* References: <4158E3CE.5090200@eecs.berkeley.edu> From: Eric Rescorla Date: Tue, 28 Sep 2004 06:41:54 -0700 In-Reply-To: <4158E3CE.5090200@eecs.berkeley.edu> (Bodo Moeller's message of "Mon, 27 Sep 2004 22:25:48 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Bodo Moeller writes: > This comparison assumes that you don't care about forward secrecy > (i.e. keeping encrypted application data secret against adversaries > who recover the secret keys corresponding to the server certificate > after the communication has taken place). Sometimes this might > be adequate, but usually it is just a bad compromise -- a common > scenario indeed, but we shouldn't be too happy about this state of > affairs. If we consider forward secrecy, the comparison will have to > involve ECDH vs. DH. You're right, I don't care much about forward secrecy. And since this mode has been available with SSL since day one and yet practically noone seems to avail themselves of it, I assert that the market doesn't care about it either. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Sep 28 19:17:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02222; Tue, 28 Sep 2004 19:17:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCRMA-0005R7-R5; Tue, 28 Sep 2004 19:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQzp-0006eo-3r; Tue, 28 Sep 2004 19:02:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQrS-0005AQ-A0 for tls@megatron.ietf.org; Tue, 28 Sep 2004 18:54:18 -0400 Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01059 for ; Tue, 28 Sep 2004 18:54:14 -0400 (EDT) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id D41B1717F for ; Tue, 28 Sep 2004 16:08:24 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Tue, 28 Sep 2004 15:53:42 -0700 From: Eric Rescorla Message-Id: <20040928230824.D41B1717F@sierra.rtfm.com> Subject: [TLS] Straw poll on draft-ietf-ecc-tls-* (Explanation) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Folks, We need to decide what to do with draft-ietf-tls-ecc-*. I am therefore calling for a straw poll. This message contains the background for the straw poll. A message which follows contains the straw poll itself. Please reply to *that message* to register your opinion. The IPR situation for this draft isn't as clear as one might like. Clearly, ECC is a patent minefield, and although the authors assert that that minefield can be skirted, I'm not so sure. That does not mean that the draft cannot go to Proposed. From RFC 3668: In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. You can find a bunch of discussion on this topic in the thread beginning at: http://www.imc.org/ietf-tls/mail-archive/msg04301.html. However, if we decide to advance the document as Informational, we must also deal with the fact that S 4 defines extensions for curve and point format negotiation. These are not essential to the protocol, however, they may be useful. However, RFC 3546 (S 5) requires a Standards Action to add a new extension. As I see it, this leaves us with three reasonable options. A. Advance draft-ietf-tls-ecc-* to Proposed Standard. B. Advance draft-ietf-tls-ecc-* as Informational and remove the extensions. C. Advance draft-ietf-tls-ecc-* as Informational with the extensions. Amend RFC 3456 to allow extensions without a Standards Action. There is a fourth possibility: advance draft-ietf-tls-ecc-* as Informational but create a separate draft that defines only the extensions and advance that as Proposed. I think this is a terrible idea from a WG perspective so I'm not proposing it. In the next message, I will call for a Straw Poll on this topic. Please reply to *that message*, not this one. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Sep 28 19:24:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02819; Tue, 28 Sep 2004 19:24:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCRSx-0005dz-Lc; Tue, 28 Sep 2004 19:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQzs-0006h1-UF; Tue, 28 Sep 2004 19:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCQtH-0005LU-56 for tls@megatron.ietf.org; Tue, 28 Sep 2004 18:56:11 -0400 Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01130 for ; Tue, 28 Sep 2004 18:56:07 -0400 (EDT) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 9FCD1717F for ; Tue, 28 Sep 2004 16:10:22 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Tue, 28 Sep 2004 15:55:39 -0700 From: Eric Rescorla Message-Id: <20040928231022.9FCD1717F@sierra.rtfm.com> Subject: [TLS] Straw poll on draft-ietf-tls-ecc-* X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 This is a Straw Poll in the fate of draft-ietf-tls-ecc-*. Please register your support for one of the following three options, explained in a previous message. A. Advance draft-ietf-tls-ecc-* to Proposed Standard. B. Advance draft-ietf-tls-ecc-* as Informational and remove the extensions. C. Advance draft-ietf-tls-ecc-* as Informational with the extensions. Amend RFC 3456 to allow extensions without a Standards Action. This Straw Poll will run for the next week (through Tuesday October 5th.) Please register your opinion by then, either to me or to the list. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Sep 29 22:10:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14116; Wed, 29 Sep 2004 22:10:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCqXN-0001KG-T4; Wed, 29 Sep 2004 22:19:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCqMO-0004Ix-U9; Wed, 29 Sep 2004 22:07:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCqBa-0000zY-QY for tls@megatron.ietf.org; Wed, 29 Sep 2004 21:56:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13143 for ; Wed, 29 Sep 2004 21:56:44 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.190]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCqJj-00012j-Qu for tls@ietf.org; Wed, 29 Sep 2004 22:05:12 -0400 Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CCqBY-0003dF-00 for tls@ietf.org; Thu, 30 Sep 2004 03:56:44 +0200 Received: from [128.32.153.61] (helo=tau.local) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1CCqBY-0005yD-00; Thu, 30 Sep 2004 03:56:44 +0200 Received: from eecs.berkeley.edu (localhost [127.0.0.1]) by tau.local (Postfix) with ESMTP id 57B4D2D616; Wed, 29 Sep 2004 18:56:00 -0700 (PDT) Message-ID: <415B67B0.80500@eecs.berkeley.edu> Date: Wed, 29 Sep 2004 18:56:00 -0700 From: Bodo Moeller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Straw poll on draft-ietf-tls-ecc-* References: <20040928231022.9FCD1717F@sierra.rtfm.com> In-Reply-To: <20040928231022.9FCD1717F@sierra.rtfm.com> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > This is a Straw Poll in the fate of draft-ietf-tls-ecc-*. [...] > This Straw Poll will run for the next week (through Tuesday > October 5th.) Please register your opinion by then, either > to me or to the list. I vote for option A ("Advance draft-ietf-tls-ecc-* to Proposed Standard"). My reasons include: * IPR: I don't buy the claim "Clearly, ECC is a patent minefield" made in <20040928230824.D41B1717F@sierra.rtfm.com> (http://www.imc.org/ietf-tls/mail-archive/msg04342.html). I am, of course, well aware of the wide-spread *perception* that ECC was a patent minefield. But clearly, there is a lot of prior art preceding any known ECC patents; I cited some of it in <4133DE21.7060306@eecs.berkeley.edu> (http://www.imc.org/ietf-tls/mail-archive/msg04309.html). There are actually no more patent issues to worry about for elliptic curves with ECDH or ECDSA than for conventional DH and DSA, unless you are specifically using certain new patented techniques (which often involve special classes of curves that you wouldn't normally run into unless you are determined to). Some think that the S/MIME ECC RFC 3278, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)" (April 2002), which is Informational, sets an example that the TLS ECC RFC should follow. But actually RFC 3278 uses the MQV protocol which is clearly patented, whether with or without elliptic curves; so I acknowledge that there was a good reason to make RFC 3278 Informational for IPR reasons. This reason does not affect the current TLS ECC draft: draft-ietf-tls-ecc-06.txt does not use MQV (early revisions did, but the specification has since been changed so that it avoids this patent-encumbered technique). There's one thing specified in draft-ietf-tls-ecc-06.txt that requires a patented technique: The draft specifies the use of point compression, as a "MAY". Uncompressed points are the default and a "MUST" (TLS extensions are used to negotiate whether point compression is permissible, so support of point compression cannot affect interoperability, just efficiency). Point compression is affected by patents just in the case of curves over characteristic-2 fields; there's no problem for prime fields. * Technical: One of the advantages of elliptic curve cryptography is that its expected security is better than that of RSA or conventional DH. This is a somewhat fuzzy statement; more precisely, we know that attacks against RSA and DH have subexponential complexity, while attacking ECC requires exponential time (around 2^k steps for ECC over (2k)-bit fields). If 1024-bit RSA remains secure in practice, this is not much to worry about; but we cannot be sure of this (for example, Dan Bernstein is working on efficient factorization circuits, see http://cr.yp.to/talks/2004myths2.pdf and elsewhere; he is going to announce results in February 2005 at the SHARCS conference). Increasing keylengths to improve security has a more noticeable effect on performance for RSA and DH than for ECC (with its exponential complexity of known attacks). Currently (i.e. in the light of just those attacks that are already known to be practical), there's a performance argument in favor of ECC in particular if you want forward secrecy: To create symmetric keys that cannot be recovered by someone who obtains a warrant or just breaks in without asking anyone first to obtain your long-time server key, TLS can used either Diffie-Hellman (with the ciphersuites specified in RFC 2246 and the rfc2246-bis draft) or elliptic curve Diffie-Hellman (ECDH, with the ciphersuites specified in the the TLS ECC draft). Depending on the nature of the content that you are protecting with TLS, forward secrecy may not matter; in particular, it is a waste of time if you are using TLS mainly for authentication and don't worry about the possibility that someone might be able to decrypt the TLS sessions after the fact. But when forward secrecy is desired, having ECDH available certainly is a plus. And of course, there's the potential possibility that RSA might turn out to be insecure when new attacks are discovered. In this case it is good to have an alternative ready to switch to. I am too optimistic to really worry about this, so I am mostly listing this additional argument for completeness. It should be noted that ECC support for TLS has been available in open source software implementations for a while (since 2002): both mozilla.org and OpenSSL have it in appropriate revisions. So when we are discussing the TLS ECC draft, we are not talking about vaporware or about a specification that would only be used by rare commercial products. This is something that would be available for everyone to use without much of a hassle. (You just wouldn't get point compression for characteristic-2 fields unless you license the appropriate patent, but that's a small loss.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Sep 30 08:17:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14636; Thu, 30 Sep 2004 08:17:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD00O-000656-IV; Thu, 30 Sep 2004 08:25:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCzrB-0003y1-R3; Thu, 30 Sep 2004 08:16:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCzqD-0003n5-ML for tls@megatron.ietf.org; Thu, 30 Sep 2004 08:15:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14516 for ; Thu, 30 Sep 2004 08:15:19 -0400 (EDT) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCzyP-00062h-K4 for tls@ietf.org; Thu, 30 Sep 2004 08:23:53 -0400 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id EFF4810116; Thu, 30 Sep 2004 08:15:16 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11881-02; Thu, 30 Sep 2004 08:15:05 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 16CA9100CD; Thu, 30 Sep 2004 08:15:05 -0400 (EDT) In-Reply-To: To: EKR Subject: Re: [TLS] Re: Moving forward on draft-ietf-tls-ecc-* MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Daniel Brown Date: Thu, 30 Sep 2004 08:07:51 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 09/30/2004 08:07:51 AM, Serialize complete at 09/30/2004 08:07:51 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0166065460==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 This is a multipart message in MIME format. --===============0166065460== Content-Type: multipart/alternative; boundary="=_alternative 0043C50F85256F1F_=" This is a multipart message in MIME format. --=_alternative 0043C50F85256F1F_= Content-Type: text/plain; charset="US-ASCII" Eric Rescorla wrote on 09/28/2004 09:41:54 AM: > Bodo Moeller writes: > > This comparison assumes that you don't care about forward secrecy > > (i.e. keeping encrypted application data secret against adversaries > > who recover the secret keys corresponding to the server certificate > > after the communication has taken place). Sometimes this might > > be adequate, but usually it is just a bad compromise -- a common > > scenario indeed, but we shouldn't be too happy about this state of > > affairs. If we consider forward secrecy, the comparison will have to > > involve ECDH vs. DH. > > You're right, I don't care much about forward secrecy. And since this > mode has been available with SSL since day one and yet practically > no one seems to avail themselves of it, I assert that the market > doesn't care about it either. Yesterday, NIST released the first public draft of Special Publication 800-52, Guidelines on the Selection and Use of Transport Layer Security. This draft recommends using the *_DHE_* ciphersuites because they provide forward secrecy. The market of the US Federal Government agencies may soon care about forward secrecy. Here's the announcement: NIST is pleased to announce the first public draft of Special Publication 800-52, Guidelines on the Selection and Use of Transport Layer Security. This document is a guideline for implementing Transport Layer Security in the Federal Government to protect sensitive information. Care must be taken when selecting cryptographic mechanisms for authentication, confidentiality, and message integrity, as some choices are non-compliant with Government standards, or may pose security risks. The comment period for this document will be 30 days, ending on November 1st, 2004. Please direct all comments and questions to Matthew J. Fanto at matthew.fanto@nist.gov. URL for the Drafts page on CSRC is: http://csrc.nist.gov/publications/drafts.html Dan --=_alternative 0043C50F85256F1F_= Content-Type: text/html; charset="US-ASCII"
Eric Rescorla wrote on 09/28/2004 09:41:54 AM:

> Bodo Moeller <bmoeller@eecs.berkeley.edu> writes:
> > This comparison assumes that you don't care about forward secrecy
> > (i.e. keeping encrypted application data secret against adversaries
> > who recover the secret keys corresponding to the server certificate
> > after the communication has taken place).  Sometimes this might
> > be adequate, but usually it is just a bad compromise -- a common
> > scenario indeed, but we shouldn't be too happy about this state of
> > affairs.  If we consider forward secrecy, the comparison will have to
> > involve ECDH vs. DH.
>
> You're right, I don't care much about forward secrecy. And since this
> mode has been available with SSL since day one and yet practically
> no one seems to avail themselves of it, I assert that the market
> doesn't care about it either.
Yesterday, NIST released the first public draft of Special Publication 800-52, Guidelines on the Selection and Use of Transport Layer Security.  This draft recommends using the *_DHE_* ciphersuites because they provide forward secrecy.  The market of the US Federal Government agencies may soon care about forward secrecy.  Here's the announcement:

NIST is pleased to announce the first public draft of Special Publication 800-52, Guidelines on the Selection and Use of Transport Layer Security. This document is a guideline for implementing
Transport Layer Security in the Federal Government to protect sensitive information. Care must be taken when selecting cryptographic mechanisms for authentication, confidentiality, and message integrity, as some choices are non-compliant with Government standards, or may pose
security risks. The comment period for this document will be 30 days, ending on November 1st, 2004. Please direct all comments and questions to Matthew J. Fanto at matthew.fanto@nist.gov.

URL for the Drafts page on CSRC is:
http://csrc.nist.gov/publications/drafts.html

        Dan --=_alternative 0043C50F85256F1F_=-- --===============0166065460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0166065460==-- From tls-bounces@ietf.org Thu Sep 30 10:50:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27606; Thu, 30 Sep 2004 10:50:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD2OL-0001WI-Dl; Thu, 30 Sep 2004 10:58:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD29N-0002El-UX; Thu, 30 Sep 2004 10:43:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCtAK-0007Sa-RX for tls@megatron.ietf.org; Thu, 30 Sep 2004 01:07:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25512 for ; Thu, 30 Sep 2004 01:07:39 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCtIU-0004jh-Bz for tls@ietf.org; Thu, 30 Sep 2004 01:16:08 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i8U57bil022358 for ; Wed, 29 Sep 2004 23:07:37 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4U00EMC8WO41@edgemail1.Central.Sun.COM> for tls@ietf.org; Wed, 29 Sep 2004 23:07:37 -0600 (MDT) Received: from [192.168.1.100] ([67.121.169.113]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4U00KI78UV3Q@mail.sun.net> for tls@ietf.org; Wed, 29 Sep 2004 23:07:36 -0600 (MDT) Date: Wed, 29 Sep 2004 22:06:25 -0700 From: Vipul Gupta Subject: Re: [TLS] Straw poll on draft-ietf-tls-ecc-* In-reply-to: <415B67B0.80500@eecs.berkeley.edu> To: tls@ietf.org Message-id: <7A8A2145-129E-11D9-AE6D-000393BA4712@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20040928231022.9FCD1717F@sierra.rtfm.com> <415B67B0.80500@eecs.berkeley.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 30 Sep 2004 10:43:13 -0400 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7BIT I, too, vote for option A (advance to proposed standard). vipul On Sep 29, 2004, at 6:56 PM, Bodo Moeller wrote: > Eric Rescorla wrote: > >> This is a Straw Poll in the fate of draft-ietf-tls-ecc-*. > [...] >> This Straw Poll will run for the next week (through Tuesday >> October 5th.) Please register your opinion by then, either >> to me or to the list. > > I vote for option A ("Advance draft-ietf-tls-ecc-* to Proposed > Standard"). > > My reasons include: > > * IPR: > > I don't buy the claim "Clearly, ECC is a patent minefield" > made in <20040928230824.D41B1717F@sierra.rtfm.com> > (http://www.imc.org/ietf-tls/mail-archive/msg04342.html). > > I am, of course, well aware of the wide-spread *perception* > that ECC was a patent minefield. But clearly, there is a lot of > prior art preceding any known ECC patents; I cited some of it in > <4133DE21.7060306@eecs.berkeley.edu> > (http://www.imc.org/ietf-tls/mail-archive/msg04309.html). > There are actually no more patent issues to worry about for elliptic > curves with ECDH or ECDSA than for conventional DH and DSA, > unless you are specifically using certain new patented techniques > (which often involve special classes of curves that you wouldn't > normally run into unless you are determined to). > > > Some think that the S/MIME ECC RFC 3278, "Use of Elliptic Curve > Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)" > (April 2002), which is Informational, sets an example that the TLS > ECC > RFC should follow. But actually RFC 3278 uses the MQV protocol which > is clearly patented, whether with or without elliptic curves; > so I acknowledge that there was a good reason to make RFC 3278 > Informational for IPR reasons. This reason does not affect the > current TLS ECC draft: draft-ietf-tls-ecc-06.txt does not use > MQV (early revisions did, but the specification has since been > changed so that it avoids this patent-encumbered technique). > > > There's one thing specified in draft-ietf-tls-ecc-06.txt that > requires a patented technique: The draft specifies the use > of point compression, as a "MAY". Uncompressed points are the > default and a "MUST" (TLS extensions are used to negotiate > whether point compression is permissible, so support of point > compression cannot affect interoperability, just efficiency). > Point compression is affected by patents just in the case of curves > over characteristic-2 fields; there's no problem for prime fields. > > > * Technical: > > One of the advantages of elliptic curve cryptography is that > its expected security is better than that of RSA or conventional DH. > This is a somewhat fuzzy statement; more precisely, we know that > attacks against RSA and DH have subexponential complexity, while > attacking ECC requires exponential time (around 2^k steps for > ECC over (2k)-bit fields). If 1024-bit RSA remains secure in > practice, this is not much to worry about; but we cannot be sure > of this (for example, Dan Bernstein is working on efficient > factorization circuits, see http://cr.yp.to/talks/2004myths2.pdf > and elsewhere; he is going to announce results in February 2005 > at the SHARCS conference). Increasing keylengths to improve > security has a more noticeable effect on performance for RSA and > DH than for ECC (with its exponential complexity of known > attacks). > > Currently (i.e. in the light of just those attacks that are already > known to be practical), there's a performance argument in favor of > ECC > in particular if you want forward secrecy: To create symmetric keys > that cannot be recovered by someone who obtains a warrant or just > breaks in without asking anyone first to obtain your long-time server > key, TLS can used either Diffie-Hellman (with the ciphersuites > specified in RFC 2246 and the rfc2246-bis draft) or elliptic curve > Diffie-Hellman (ECDH, with the ciphersuites specified in the the TLS > ECC draft). Depending on the nature of the content that you are > protecting with TLS, forward secrecy may not matter; in particular, > it > is a waste of time if you are using TLS mainly for authentication and > don't worry about the possibility that someone might be able to > decrypt the TLS sessions after the fact. But when forward secrecy is > desired, having ECDH available certainly is a plus. > > And of course, there's the potential possibility that RSA might turn > out to be insecure when new attacks are discovered. In this case > it is good to have an alternative ready to switch to. I am too > optimistic to really worry about this, so I am mostly listing this > additional argument for completeness. > > > It should be noted that ECC support for TLS has been available in open > source software implementations for a while (since 2002): both > mozilla.org and OpenSSL have it in appropriate revisions. So when > we are discussing the TLS ECC draft, we are not talking about vaporware > or about a specification that would only be used by rare commercial > products. This is something that would be available for everyone to > use without much of a hassle. (You just wouldn't get point compression > for characteristic-2 fields unless you license the appropriate patent, > but that's a small loss.) > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls